Minutes of NGTRANS WG Meeting - 25 August 1998 - Chicago IETF Chairs: Bob Fink, Bob Gilligan and Tony Hain Attendance: 218 signed in, more than 250 actually present Marc Blanchet, of Viagenie, announced that he had placed a Cisco IPv6 capable router on the IETF terminal room network for anyone's use to reach the 6bone. The KAME project's IPv6 stack operating on a unix workstation in the terminal room was soon operating over this router using ssh6 back to Japan. Congrats, folks! Tony Hain discussed changes that will be made to the ngtrans charter to more accurately reflect the actual work of the group, which is to develop tools and advice to aid in the eventual transition to IPv6, and to make clear that it is not to specify timelines, plans and policies for such a conversion. Bob Fink discussed the processing of drafts beyond RFC 1933, noting that Experimental will be the preferred status of tools such as SIIT and NAT-PT, and Informational for practice/advice such as 6bone Routing Practice. The Experimental status will allow various ideas to be tried out without full understanding of their final role in transition to IPv6. Erik Nordmark presented recent changes from -00 to -01 for the "IPv6 Transitions Mechanisms" draft for advancement to replace RFC 1933: - Clarified that configured tunnels are unidirectional - Clarified that IPv4-compatibleaddresses areassigned exclusively to nodes that support automatic tunnels,i.e., that can receive such packets - Added tect about formation of link-local addresses and non-use of ND: Zero padding IPv4 address to form 64 bit token, ND and DAD can not be used on unidirectional tunnels, and a bidirectional tunnel should accept and respond to NUD. - Added restriction that decapsulated packets not be forwarded unless source address is acceptable to the decapsulating router (decapsulate and forward without such checks circumvents ingress filtering) He also replayed previous changes made from RFC 1933 to draft -00: - Deleted section on "compatible" IPv4 loopback address (::127.0.0.1) to not require routers to filter that address - Removed the use of IPv6 "raw form" when sending to IPv4-compatible on-link destinations - Revised DNS section to clarify resolver filtering and ordering options - Made the IPv4-compatible addresses only apply to automatic tunneling - Changed the term "IPv6-only addresses" to "IPv6-native address" per current usage - Changed minimum MTU to 1280 bytes - Revised IPv4-compatible address configuration section (5.2) to recognize multiple interfaces - Added discussion ofsource address selection when using IPv4-compatible addresses - Added section on the combination of the default tunneling technique with hosts using automatic tunneling - Added prohibition against automatic tunneling to IPv4 broadcast or multicast destinations He also presented a few remaining issues to be resolved on the mailing list: - Disallow the (asymmetric) use of default configured tunneling in one direction and automatic tunneling in the reverse direction? - Create a DHCPv4 option for configuring the tunnel destination for default configured tunnels? - Require that configured tunnels be biderectional?: Routing protocols need bidirectional, makes ingress filtering easy, but different than tunnels over IPv6 - Require nodes to respond to NUD probes on bidirectional configured tunnels? - Require nodes to send NUD probes on bidirectional configured tunnels? (Omitted for roputer-router links as specified in RFC 1970) As soon as Erik finishes these few remaining issues up a working group last call will be done to approve sending the draft in to replace the current version, RFC 1933, which is at Proposed Standard status. Erik Nordmark presented recent changes from draft -01 to-02 for the "Stateless IP/ICMP Translator (SIIT)" draft for advancement to Experimental RFC: - Clarified generating ICMP "TTL exceeded" when TTL or hoplimit reaches zero - Added 1-1 mapping between IPv4 TOS and IPv6 Traffic Class - Clarified that IPv4-mapped addresses are sent over wire - Introduced the notion of IPv4-translated addresses separate from IPv4-mapped and IPv4-compatible addresses: 0000:0000:0000:0000:FFFF:0000:(IPv4 address) IPv4-compatible: IPv6/IPv4 node that supports automatic tunneling IPv4-mapped: IPv4 node IPv4-translated: IPv6 node Example: IPv6 IPv4 src ::ffff:0:129.0.0.1 src 129.0.0.1 dst ::0:ffff:192.2.2.2 dst 192.2.2.2 - Acquiring IPv4-translatable addresses out of scope A working group last call for comments will now be made to send this in for processing as Experimental. George Tsirtsis presented recent changes from draft -01 to-02 for the "Network Address Translation-Protocol Translation (NAT-PT)" draft for advancement to Experimental RFC. - Various editorial changes - Dropped collocated DNS/NAT section - Added Applicability statement - Added section on the impact of DNS-ALG to DNS-SEC He then discussed several aspects of this proposal: - Protocol Translation Limitations - Impact of address translation - ALGs will be required for certain applications that refer hosts by their IP addresses in payload - Security between IPv6 and IPv4 - IPsec does not work across routing realms - Impact of DNS-ALG on DNS-SEC - DNS traffic across the DNS-ALG can not be signed! A working group last call for comments will now be made to send this in for processing as Experimental. Bertrand Buclin presented recent changes in the "6bone Routing Practices" draft for advancement to Informational RFC. A working group last call for comments will now be made to send this in for processing as Informational. This draft represents the collective experience of 6bone participants and lists best practice when operating over the 6bone between leaf and transit/backbone sites. Kazuaki Tsuchiya presented the Hitachi protocol exchange software for Windows95/98/NT4 systems based on the previous draft . This software is available now for use at http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm. The draft of this work should move forward through ngtrans to Experimental RFC. (Editor's note: subsequent to the meeting it was agreed that the draft would be reworked to emphasize the implementation experience relating to the mechanism previously described and to redescribe the mechanism more accurately, not as a translator but rather as a technique known commonly as "bump-in- the-stack". Also, the INET 98 "Deployment and Experiences of WIDE 6bone" URL was supplied for more details on the various WIDE project's translators http://www.v6.wide.ad.jp/Papers/yamamoto/.) David Kessens and Bob Fink gave a brief review of the status of the 6bone. There are now 302 sites (was 240 last time) in 35 countries (was 32 last time) participating in the 6bone. There are now 47 backbone sites. There are currently about 1500 queries and 7 updates per day to the registry. Greg Miller presented the vBNS 6bone plans, which basically is to provide native IPv6 transport across the US with IPv6 routers located in the Wash. DC, Chicago and San Francisco Bay areas operating over OC3c links into the vBNS OC12c ATM network. This will make a full native cross country IPv6 backbone available to the 6bone! See http://www.vbns.net/IPv6/index.html for more information. Ivano Guardini, of CSELT/IT, presented his new ASpath-tree tool features for monitoring BGP4+ routing inside the 6bone. These tools are up and available at http://carmen.cselt.it/ipv6/bgp/index.htm. ASpath-tree is being used by CSELT to monitor their routing configuration, and is being used by several other pTLAs (ATT-LABS-EUROPE and BT-LABS) as well. Some of the ASpath-tree features are: showing the BGP4+ routing tree, the last 24 hours of routing history, changes in the routing tree, the odd routes report and the routing stability report. Two updated drafts were then presented from previous work presented at the AATN BOF at the previous IETF as a courtesy to that group as they could not easily schedule there own meeting at this IETF. Gabriel Montenegro presented the "Negotiated Address Reuse" draft . His talk is available at http://playground.sun.com/~gab/talks.html. Negotiated Address Reuse proposes a border device that does allow end-to-end traffic like IPSEC, IP tunnels (including Mobile IP and GRE tunnels) and QOS. It does this by extending and complementing NAT and by introducing a control mechanism based on SOCKS. Michael Borella presented the "Distributed Network Address Translation" draft . It is most likely that work on these two drafts will continue elsewhere, unless they have more ready transition application to IPv6 than currently observed.