Subject: Re: (ngtrans) When to put IPv6 addresses in the DNS

From: Bob Fink <[email-masked]>
Date: Thu, 13 Jan 2000 14:13:07 -0800

Erik,

At 04:01 PM 12/9/99 -0800, Erik Nordmark wrote:

>Keith Moore has asked me to clarify when to put addresses
>in the DNS in the update to RFC 1933 (draft-ietf-ngtrans-mech-05.txt).
>This would be a very useful clarification.
>My current attempt (not yet submitted as an updated I-D) says:
>
>2.3.  Advertising Addresses in the DNS
>
>      There are some constraint place on the use of the DNS during
>      transition.  Most of these are obvious but are stated here for
>      completeness.
>
>      An A6/AAAA record for a node should not be added to the DNS until
>
>   1.    The address is assigned to the interface on the node.
>
>   2.    The address is configured on the interface.
>
>   3.    The interface is on a link which is connected to the IPv6
>         infrastructure.
>
>(Excuse the borken formatting.)
>The problem is with #3 as I and George discovered when discussing NAT-PT 
>in DC.
>I'd been under the impression that if you follow the above rules things would
>work. If an IPv6 host is isolated from an IPv6 perspective (e.g. it is not
>connected to the 6bone to take a concrete example) rule #3 would mean that it
>should not have an address in the DNS.
>
>This works great when other dual stack hosts tries to contact the isolated
>dual stack host. There is no IPv6 address in the DNS thus the peer doesn't 
>even
>try communicating using IPv6 but goes directly to IPv4 (we are assuming both
>hosts have A records in the DNS.)
>
>The suboptimal behavior occurs when the isolated host is doing the connect.
>It finds A6/AAAA records in the DNS for the peer and it has local IPv6
>addresses configured thus it will try to connect using IPv6.
>If it has no IPv6 route to the 6bone (e.g. because the local router
>was upgraded to advertise IPv6 addresses using Neighbor Discovery
>but that router doesn't have any IPv6 routes) this communication will
>fail. Typically this means a few minutes of delay as TCP times out.
>The TCP specification says that ICMP unreachable messages could be
>due to routing transients thus they should not immediately terminate
>the TCP connection. This means that the normal TCP timeout of a few minutes
>apply.
>Once TCP times out the application will presumably try the IPv4 addresses
>based on the A records in the DNS, but this will be painfully slow.
>
>What should we say in draft-ietf-ngtrans-mech?
>We should at least document the above issue.
>But is there some other advise or recommendation that makes sense?
>A possible but undesirable recommendation is:
>         Don't configure any routers to advertise any IPv6 prefixes in your
>         site until the site is connected to the *global IPv6 infrastructure*
>         (which I don't know what it is except possibly the 6bone) to ensure
>         that when the hosts find A6/AAAA records in the DNS they in fact
>         have an IPv6 path to communicate with those addresses.
>This is undesirable since it doesn't recommend users playing with IPv6
>internally in their site before they get external IPv6 communication.
>
>Any better suggestions?

In looking back over outstanding comments on MECH-05, I found this month 
old question you posed to the ngtrans list re Keith Moore's comments on 
when to put IPv6 addresses in the DNS. I think that we must resolve this in 
favour of the rules you suggest above, as it is key to our transition 
strategy. I.e., if you request a resource on the Internet, and it says it 
has a v6 address, and you have one as well, then you can use v6 to talk to 
it. So I am strongly in favour of these rules, and putting them quite 
explicitly into MECH.

As for your concern about experimenting with v6 on your site network when 
you have no external v6 connectivity, I want to take a simplistic view. 
That is, if one is experimenting with v6 prior to having any external 
connectivity, it is very unlikely you will do so on production server 
resources that are important or critical.

More likely, you will enable less critical systems with IPv6 and experiment 
to see how they work. In this case, it is very unlikely anyone externally 
will see the A6/AAAA entries for these systems (if you do choose to violate 
the rules above), and if someone does, and they suffer a delay, so what. 
They are local use systems under test, not critical resources.

I think that simply stating the issue, and its implications, is sufficient. 
So I would suggest and alternative to your "undesirable" paragraph to 
recognize this.

"A possible implication of the rules above is that, if one enables IPv6 on 
a node on a link without IPv6 infrastructure, and choose to add A6/AAAA 
records to the DNS for that node, then external IPv6 nodes that might see 
these A6/AAAA records will possibly try to reach that node using IPv6 and 
suffer delays due to unreachability. Thus it is recommended that either the 
rules be followed, or care be taken to only do so with nodes that will not 
be impacted by external accessing delays."

Between the 6bone and the upcoming ability to use "6to4", and a growing 
choice of production IPv6 network services, it doesn't seem very likely 
that a site will have much trouble connecting to external IPv6 
infrastructure when they so choose.

Anyway, it would be good to resolve this on the list prior to Adelaide and 
get RFC 1933 replaced at PS.

Thanks for bringing this up.

Bob

---

From: Bill Manning <[email-masked]>
Date: Thu, 13 Jan 100 17:23:11 -0800 (PST)

% 
% "A possible implication of the rules above is that, if one enables IPv6 on 
% a node on a link without IPv6 infrastructure, and choose to add A6/AAAA 
% records to the DNS for that node, then external IPv6 nodes that might see 
% these A6/AAAA records will possibly try to reach that node using IPv6 and 
% suffer delays due to unreachability. Thus it is recommended that either the 
% rules be followed, or care be taken to only do so with nodes that will not 
% be impacted by external accessing delays."

	This is exactly the problem seen today w/ IPv4 labels in the DNS.
	If its not there, then there will be the lookup delay before an
	alternate choice is taken. Granted that in the IPv4 only world, 
	the alternate choice is to report a failure. This will lead people
	to use literals or some splitDNS thing.

	I guess that I I see this as being a bit overbearing on how people
	may wish to do their implementation. Its really a local matter and
	IMHO, is overstating things to call them "rules".  It perhaps would
	be better phrased as, "a recommended procedure for when to add
	IPv6 data to the DNS".

... html cruft.... ick.

% 2.3.&nbsp; Advertising Addresses in the DNS<br>
% <br>
% &nbsp;&nbsp;&nbsp;&nbsp; There are some constraint place on the use of
% the DNS during<br>
% &nbsp;&nbsp;&nbsp;&nbsp; transition.&nbsp; Most of these are obvious but
% are stated here for<br>
% &nbsp;&nbsp;&nbsp;&nbsp; completeness.<br>
% <br>
% &nbsp;&nbsp;&nbsp;&nbsp; An A6/AAAA record for a node should not be added
% to the DNS until<br>
% <br>
% &nbsp; 1.&nbsp;&nbsp;&nbsp; The address is assigned to the interface on
% the node.<br>
% <br>
% &nbsp; 2.&nbsp;&nbsp;&nbsp; The address is configured on the
% interface.<br>
% <br>
% &nbsp; 3.&nbsp;&nbsp;&nbsp; The interface is on a link which is connected
% to the IPv6<br>
% &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; infrastructure.<br>
% <br>
% (Excuse the borken formatting.)<br>
% The problem is with #3 as I and George discovered when discussing NAT-PT
% in DC.<br>
% I'd been under the impression that if you follow the above rules things
% would<br>
% work. If an IPv6 host is isolated from an IPv6 perspective (e.g. it is
% not <br>
% connected to the 6bone to take a concrete example) rule #3 would mean
% that it<br>
% should not have an address in the DNS.<br>
% <br>
% This works great when other dual stack hosts tries to contact the
% isolated<br>
% dual stack host. There is no IPv6 address in the DNS thus the peer
% doesn't even<br>
% try communicating using IPv6 but goes directly to IPv4 (we are assuming
% both<br>
% hosts have A records in the DNS.)<br>
% <br>
% The suboptimal behavior occurs when the isolated host is doing the
% connect.<br>
% It finds A6/AAAA records in the DNS for the peer and it has local
% IPv6<br>
% addresses configured thus it will try to connect using IPv6.<br>
% If it has no IPv6 route to the 6bone (e.g. because the local router<br>
% was upgraded to advertise IPv6 addresses using Neighbor Discovery<br>
% but that router doesn't have any IPv6 routes) this communication
% will<br>
% fail. Typically this means a few minutes of delay as TCP times out.<br>
% The TCP specification says that ICMP unreachable messages could be<br>
% due to routing transients thus they should not immediately 
% terminate<br>
% the TCP connection. This means that the normal TCP timeout of a few
% minutes<br>
% apply.<br>
% Once TCP times out the application will presumably try the IPv4
% addresses<br>
% based on the A records in the DNS, but this will be painfully slow.<br>
% <br>
% What should we say in draft-ietf-ngtrans-mech?<br>
% We should at least document the above issue.<br>
% But is there some other advise or recommendation that makes sense?<br>
% A possible but undesirable recommendation is: <br>
% <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Don't
% configure any routers to advertise any IPv6 prefixes in your <br>
% <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>site until
% the site is connected to the *global IPv6 infrastructure*<br>
% <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>(which I
% don't know what it is except possibly the 6bone) to ensure <br>
% <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>that when
% the hosts find A6/AAAA records in the DNS they in fact <br>
% <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>have an
% IPv6 path to communicate with those addresses.<br>
% This is undesirable since it doesn't recommend users playing with
% IPv6<br>
% internally in their site before they get external IPv6
% communication.<br>
% <br>
% Any better suggestions?<br>
% </blockquote><br>
% In looking back over outstanding comments on MECH-05, I found this month
% old question you posed to the ngtrans list re Keith Moore's comments on
% when to put IPv6 addresses in the DNS. I think that we must resolve this
% in favour of the rules you suggest above, as it is key to our transition
% strategy. I.e., if you request a resource on the Internet, and it says it
% has a v6 address, and you have one as well, then you can use v6 to talk
% to it. So I am strongly in favour of these rules, and putting them quite
% explicitly into MECH.<br>
% <br>
% As for your concern about experimenting with v6 on your site network when
% you have no external v6 connectivity, I want to take a simplistic view.
% That is, if one is experimenting with v6 prior to having any external
% connectivity, it is very unlikely you will do so on production server
% resources that are important or critical. <br>
% <br>
% More likely, you will enable less critical systems with IPv6 and
% experiment to see how they work. In this case, it is very unlikely anyone
% externally will see the A6/AAAA entries for these systems (if you do
% choose to violate the rules above), and if someone does, and they suffer
% a delay, so what. They are local use systems under test, not critical
% resources. <br>
% <br>
% I think that simply stating the issue, and its implications, is
% sufficient. So I would suggest and alternative to your
% &quot;undesirable&quot; paragraph to recognize this.<br>
% <br>
% &quot;A possible implication of the rules above is that, if one enables
% IPv6 on a node on a link without IPv6 infrastructure, and choose to add
% A6/AAAA records to the DNS for that node, then external IPv6 nodes that
% might see these A6/AAAA records will possibly try to reach that node
% using IPv6 and suffer delays due to unreachability. Thus it is
% recommended that either the rules be followed, or care be taken to only
% do so with nodes that will not be impacted by external accessing
% delays.&quot;<br>
% <br>
% Between the 6bone and the upcoming ability to use &quot;6to4&quot;, and a
% growing choice of production IPv6 network services, it doesn't seem very
% likely that a site will have much trouble connecting to external IPv6
% infrastructure when they so choose. <br>
% <br>
% Anyway, it would be good to resolve this on the list prior to Adelaide
% and get RFC 1933 replaced at PS.<br>
% <br>
% <br>
% Thanks for bringing this up.<br>
% <br>
% Bob<br>
% <br>
% </html>
% 
% --=====================_256393089==_.ALT--
% 
% 

-- 
--bill

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Jan 2000 19:29:10 -0800 (PST)

> be impacted by external accessing delays."

Sounds reasonable.
I'll edit it some to point out that the delay occurs only if the applications
fall back to using IPv4 when IPv6 communication can not be established.
If the applications don't do this fallback they will fail to communicate in
this case.

   Erik

---

From: Alain Durand <[email-masked]>
Date: Mon, 17 Jan 2000 12:46:16 +1030

>         be better phrased as, "a recommended procedure for when to add

I agree.
If people want to put stupid things in their DNS, they'll suffer the costs.
This will not impact the Internet at large.
I don't think we can mandate to put only smart entries in their DNS,
we can only recommend that.

         - Alain.