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

From: Erik Nordmark <[email-masked]>
Date: Thu, 9 Dec 1999 16:01:25 -0800 (PST)

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?

   Erik

---

From: Bill Manning <[email-masked]>
Date: Fri, 10 Dec 1999 05:08:15 -0800 (PST)

% 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.
% 
......
% But is there some other advise or recommendation that makes sense?
% 
%    Erik

	If I know what things are -supposed- to be present in my infrastructure,
	I put them in the DNS, regardless of whether they are online, present,
	proprerly configured, etc.  (see the normal practice for DHCP pools
	in IPv4 today)  
	Your presumptions as listed above might be fine -if- authenticated
	dynamicDNS were available.
-- 
--bill

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 10 Dec 1999 13:47:13 -0800 (PST)

> 	proprerly configured, etc.  (see the normal practice for DHCP pools

Sure. But in dual stack there is a consideration which is similar to
adding an additional network interface to an existing server.
You want to add the NIC and configure the IP address in it before
you put that IP address in the A RRset for the server.

Adding an A6/AAAA record for an existing host has the same issues.
If you add it to DNS before that address has been configured communication
might fail just as in the multihomed IPv4 server case.
Thus the rules try to capture that.

> 	dynamicDNS were available.

You need these kinds of rules/recommendations even if using manually
administred updates to the zone files.

   Erik