(ngtrans) Upcoming update to draft-ietf-ngtrans-mech-04.txt

[Erik Nordmark <[e-mail]>]

Folks,

I'm trying to finalize edits based on some very old comments (going back to
Aug. 1999!).

Before I finish the ID I need to clarify the XXX below (subject of the email
reply I just sent to Itojun).

But I'd appreciate comments on the other changes.
The changes are hand-edited diff -cbi output with '!' indicating changes
and '+' indicating new text.

   Erik

***************
*** 272,290 ****
  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 [6].  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.
  
     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 filter or order the results
     returned to the application in order to influence the version of IP
     packets used to communicate with that node.  In terms of filtering,
     the resolver library has three alternatives:
--- 372,401 ----

  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
!    "A6" has been defined for IPv6 addresses [6] with support for an
!    earlier record named "AAAA".  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 "A6" and "AAAA" records.
  
     DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling
!    both A6/AAAA and A records.  However, when a query locates an A6/AAAA
     record holding an IPv6 address, and an A record holding an IPv4
     address, the resolver library MAY filter or order the results
     returned to the application in order to influence the version of IP
     packets used to communicate with that node.  In terms of filtering,
     the resolver library has three alternatives:

***************
*** 306,320 ****
+ 2.3.  Advertising Addresses in the DNS
+ 
+    There are some constraint placed on the use of the DNS during
+    transition.  Most of these are obvious but are stated here for
+    completeness.
+ 
+    The recommendation is that A6/AAAA records for a node should not be
+    added to the DNS until all of these are true:
+ 
+      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.
+ 
+    If an IPv6 node is isolated from an IPv6 perspective (e.g. it is not
+    connected to the 6bone to take a concrete example) constraint #3
+    would mean that it should not have an address in the DNS.
+ 
+    This works great when other dual stack nodes tries to contact the
+    isolated dual stack node.  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 nodes have A records in the DNS.)
+ 
+    However, this does not work well when the isolated node is trying to
+    establish communication.  Even though it does not have an IPv6
+    address in the DNS it will find A6/AAAA records in the DNS for the
+    peer.  Since the isolated node has IPv6 addresses assigned to at
+    least one interface it will try to communicate 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 hopefully try
+    the IPv4 addresses based on the A records in the DNS, but this will
+    be painfully slow.
+ 
+    A possible implication of the recommendations 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 or communication failure
+    due to unreachability.  (A delay is incurred if the application
+    correctly falls back to using IPv4 if it can not establish
+    communication using IPv6 addresses.  If this fallback is not done the
+    application would fail to communicate in this case.)  Thus it is
+    suggested that either the recommendations be followed, or care be
+    taken to only do so with nodes that will not be impacted by external
+    accessing delays and/or communication failure.
+ 
+    In the future when a site or node removes the support for IPv4 the
+    above recommendations apply to when the A records for the node(s)
+    should be removed from the DNS.

**************
*** 540,551 **** [Section 3.3 Hop Limit]
       implementation dependent manner.  The current suggested value is
       published in the "Assigned Numbers RFC.  Implementations may
       provide a mechanism to allow the administrator to configure the
!      IPv4 TTL.
  
--- 763,776 ----
       implementation dependent manner.  The current suggested value is
       published in the "Assigned Numbers RFC.  Implementations MAY
       provide a mechanism to allow the administrator to configure the
!      IPv4 TTL such as the one specified in the IP Tunnel MIB [17].

***************
*** 700,722 **** [Section 3.6 Decapsulation]
  
!    When decapsulating the packet, the IPv6 header is not modified.  If
     the packet is subsequently forwarded, its hop limit is decremented by
     one.
  
!    The encapsulating IPv4 header is discarded.  [Note that work underway
!    in the IETF is redefining the Type of Service byte and as a result
!    future RFCs might define a different behavior for the ToS byte when
!    decapsulating a tunneled packet.]
--- 944,982 ----
  
! 
!    When decapsulating the packet, the IPv6 header is not modified.
!    [Note that work underway in the IETF is redefining the Type of
!    Service byte and as a result future RFCs might define a different
!    behavior for the ToS byte when decapsulating a tunneled packet.]  If
     the packet is subsequently forwarded, its hop limit is decremented by
     one.
  
!    As part of the decapsulation the node SHOULD silently discard a
!    packet with an invalid IPv4 source address such as a multicast
!    address, a broadcast address, 0.0.0.0, and 127.0.0.1.
  
+    The encapsulating IPv4 header is discarded.
+ 
+    XXX After the decapsulation the node SHOULD silently discard a packet
+    with an invalid IPv6 source address.  This include IPv6 multicast
+    addresses, the unspecified address, and the loopback address but also
+    IPv4-mapped IPv6 source addresses where the IPv4 part of the address
+    is an (IPv4) multicast address, broadcast address, 0.0.0.0, or
+    127.0.0.1.
+ 

***************
--- 1035,1073 ---- [Section 3.8 Neighbor Discovery over Tunnels]
+    For the purposes of Neighbor Discovery the automatic and configured
+    tunnels specified in this document as assumed to NOT have a link-
+    layer address, even though the link-layer (IPv4) does have address.
+    This means that a sender of Neighbor Discovery packets
+  
+     -   SHOULD NOT include Source Link Layer Address options or Target
+         Link Layer Address options on the tunnel link.
+  
+     -   MUST silently ignore any received SLLA or TLLA options on the
+         tunnel link.

***************
--- 1078,1169 ---- [Section 4.2.  Default Configured Tunnel using IPv4
"Anycast Address"]

+      However, care must be taking when using such a default tunnel to
+      prevent different IPv4 fragments from arriving at different routers
+      for reassembly.  This can be prevented by either avoiding
+      fragmentation of the encapsulated packets (by ensuring an IPv4 MTU
+      of at least 1300 bytes) or by preventing frequent changes to IPv4
+      routing.

***************
*** 964,974 **** [Setion 5.3.  Automatic Tunneling Operation]

     The automatic tunneling module must not send to IPv4 broadcast or
     multicast destinations.  It must drop all IPv6 packets destined to
     IPv4-compatible destinations when the embedded IPv4 address is
!    broadcast or multicast.
  
--- 1303,1314 ----

     The automatic tunneling module MUST NOT send to IPv4 broadcast or
     multicast destinations.  It MUST drop all IPv6 packets destined to
     IPv4-compatible destinations when the embedded IPv4 address is
!    broadcast, multicast, the unspecified (0.0.0.0) address, or the
!    loopback address (127.0.0.1).  Note that the sender can only tell if
!    an address is a network or subnet broadcast for broadcast addresses
!    assigned to directly attached links.
  
***************
--- 1542,1552 ---- [Section 10.  Changes from RFC 1933]

+    -    Clarified that decapsulating nodes MUST be capable of
+         reassembling an IPv4 packet that is 1300 bytes (1280 bytes plus
+         IPv4 header).
+ 
+    -    Clarified that when using a default tunnel to an IPv4 "anycast
+         address" the network must either have an IPv4 MTU of least 1300
+         bytes (to avoid fragmentation of minimum size IPv6 packets) or
+         be configured to avoid frequent changes to IPv4 routing to the
+         "anycast address" (to avoid different IPv4 fragments arriving at
+         different tunnel endpoints).
+ 
+    -    Using A6/AAAA instead of AAAA to reference IPv6 address records
+         in the DNS.
+ 
+    -    Specified when to put IPv6 addresses in the DNS.
+ 
+    -    Added reference to the tunnel mib for TTL specification for the
+         tunnels.
+ 
+    -    Added a table of contents.
+ 
+    -    Added checks in the decapsulation checking both an IPv4-
+         compatible IPv6 source address and the outer IPv4 source
+         addresses for multicast, broadcast, all-zeros etc.
+ 
+    -    Added recommendations for use of source and target link layer
+         address options for the tunnel links.