Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt (fwd)

[Pekka Savola <pekkas@netcore.fi>]

On Sat, 17 Jul 2004, Alain Durand wrote:
> On Jul 17, 2004, at 6:59 AM, Margaret Wasserman wrote:
> 
> >> My opinion is that we should delete section 2.2 DNS all together, as 
> >> out of scope.
> >
> > I am concerned about this option, because it seems to duck the 
> > problem...  Do you really think it would be okay to publish a 
> > specification for dual-stack nodes that is silent on the subject of 
> > address selection?  Without even including a reference to a separate 
> > specification that covers this topic?
> 
> Look at the table of content of the draft:
> 
>    2.  Dual IP Layer Operation..................................    5
>           2.1.  Address Configuration...............................    5
>           2.2.  DNS.................................................    5
>    3.  Configured Tunneling Mechanisms..........................    7
>           3.1.  Encapsulation.......................................    8
>           3.2.  Tunnel MTU and Fragmentation........................    9
>              3.2.1.  Static Tunnel MTU..............................    9
>              3.2.2.  Dynamic Tunnel MTU.............................   10
>           3.3.  Hop Limit...........................................   11
>           3.4.  Handling ICMPv4 errors..............................   12
>           3.5.  IPv4 Header Construction............................   14
>           3.6.  Decapsulation.......................................   15
>           3.7.  Link-Local Addresses................................   18
>           3.8.  Neighbor Discovery over Tunnels.....................   19
>   4.  Threat Related to Source Address Spoofing................   20
>   5.  Security Considerations..................................   21
>   6.  Acknowledgments...............
> 
> The essence of this draft is really about dual stack and tunneling IPv6 
> over IPv4
> as _the_ basic transition mechanisms. There is much more than DNS in the
> operation of a dual stack node, however the draft only mention DNS,
> and, as you mention, is not complete as it does not actually provide
> a satisfactory answer to the overall problem.
> 
> This is the reason why I think we might as well declare the DNS issues 
> out of scope.

I tend to agree with Alain here -- this document does not seem the 
place to describe everything needed on a dual-stack system.

Therefore I removed (in -04, published recently) some specification of 
DNS result ordering, but still kept a shortish summary on IPv6 DNS 
issues which seemed irrespective of that ordering.

Below is what's included in the recent draft:
=======
2.2.  DNS

   The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map
   between hostnames and IP addresses.  A new resource record type named
   "AAAA" has been defined for IPv6 addresses [RFC3596].  Since
   IPv6/IPv4 nodes must be able to interoperate directly with both IPv4
   and IPv6 nodes, they must provide resolver libraries capable of
   dealing with IPv4 "A" records as well as IPv6 "AAAA" records.  Note
   that the lookup of A versus AAAA records is independent of whether
   the DNS packets are carried in IPv4 or IPv6 packets, and that there
   is no assumption that the DNS servers know the IPv4/IPv6 capabilities
   of the requesting node.

   The issues and operational guidelines for using IPv6 with DNS are
   described at more length in other documents [DNSOPV6].

   DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling
   both AAAA and A records.  However, when a query locates an AAAA
   record holding an IPv6 address, and an A record holding an IPv4
   address, the resolver library MAY order the results returned to the
   application in order to influence the version of IP packets used to
   communicate with that specific node -- IPv6 first, or IPv4 first.

   The applications SHOULD be able to specify whether they want IPv4,
   IPv6 or both records [RFC3493].  That defines which address families
   the resolver looks up.  If there isn't an application choice, or if
   the application has requested both, the resolver library MUST NOT
   filter out any records.

   Since most applications try the addresses in the order they are
   returned by the resolver, this can affect the IP version "preference"
   of applications.

   The actual ordering mechanisms are out of scope of this memo.
   Address selection is described at more length in [RFC3484].
====

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings