ngtrans tools WG meeting December 9, 1997 Washington, DC IETF Bob Gilligan chair, Tony Hain reporting Discussion: ngtrans@sunroof.eng.sun.com Subscribe: majordomo@sunroof.eng.sun.com Archive: ftp://playground.sun.com/pub/ngtrans Chairs: Bob Fink rlfink@lbl.gov Robert Gilligan gilligan@freegate.net Tony Hain tonyhain@microsoft.com Updates to RFC-1933 - Bob Gilligan Updates to RFC-1933, the current Proposed standard for Transition Mechanisms, were discussed to move it to Draft status. An I-D was submitted for review at this meeting which contained, among other things, the following: Remove ::127.0.0.1 from discussion Eliminated 'raw IPv6 form' when sending IPv4 on link (implementation complexity, low gain) Added definitions for operating mode (dual stack needs to know if one is to be turned off) DNS resolver filtering/ordering options clarified IPv4 compatible used only with automatic tunneling 'v6 only' to 'v6 native' update MTU for new 1280 byte min MTU size misc. clarifications in text Needs: definition of link-local address for configured tunnels Automatic tunnel operational issues Source address selection when automatic tunnel Scope of IPv4-compatible address Steve Deering noted that use of ND over pt-to-pt links will be discussed in the IPv6 group on Thursday. Need to clearly define mechanism where configured tunnel is unidirectional with an automatic tunnel back. Issue is where to tunnel back since any router attached to v4 cloud can forward to avoid injecting v4 routing table into v6 cloud. Technique of using well-known v4 anycast as default tunnel is written up, but actual pattern not defined. Discussion diverted into should we or not, allow asymmetric use of configured and auto tunnels. Tony Hain commented that we are here to define the mechanisms, not define how they get used. Discussion about how to document injection of v4 routes or not into v6. Should be a BCP from the 6bone implementers, since it is a topic for that deployment timeframe. Bob Fink said he would handle this one in consultation with Steve Deering. Bob Gilligan will revise the document as an ID and send to the list. NNAT - Jim Bound A No NAT (NNAT) draft was presented in Munich - Jim Bound gave an overview and walkthrough of it here. An IPv4 host requests DNS lookup, where a record is set as forwarder to NNAT server which sends DHCPv6 reconfig message which hosts MUST listen to, which is a temporary v4 address which allows building v4 compatible, then the NNAT server updates DNS and responds back to original requestor. Open issues: DHCPv4 use and CNAME fix TTL cache Hybrid Stack Question Tunnels move to egress router Use of RFC 1183 records Authoritative DNS Server Response Update to lifetime for long running clients Default reassignment hold-down time NNAT name of the draft - open to discussion Concern that temporary assignment may get out of sync if host to be reconfigured is not up at the time. Since the reconfig message is Ack'd, the language will be clarified to note that the NNAT server will not complete the DNS response if the Ack doesn't happen. SIIT - Eric Nordmark SIIT is a stateless header translator. It is not a single point of failure. Assumes mechanism like NNAT for temporary v4 addr. Transport-mode ESP works Open issues: use v4 comp as address. Works as long as v6 cloud is clean. v4 traceroute NAT-PT - George Tsirtsis This is v6 to v4 NAT to connect the clouds. It is a combination of NAT in outbound direction with NNAT in inbound direction. There is aminimal use of compatible/mapped address only v6 hosts need to do anything This breaks end-to-end principle...same issues as any NAT This is a statefull version of SIIT. George will work with Eric and Jim to see if a combined document is possible. WIDE Translators - K. Tsuchiya, K. Yamamoto, T. Niinomi Three translators developed by members of the WIDE project in Japa were presented. NR60 Translator - K. Tuchiya A modified DNS, address mapper & header translator used Straight NAT using DNS as resolver in both directions Implemented all on one node FAITH - K. Yamamoto Header conversion has limitations Address conversion in legacy applications is difficult AH works when translator is trusted and rebuilds connection Socks64 - T. Niinomi No DNS modification or address mapping management Application level gateway based on Socks 5 Distributes fake v4 address for v6 end points Only modifies clients where other 2 modify infrastructure These three translators represent actual implemented work. The chairs would like to thank the Wide project members for their willingness to come a long distance to share their ideas and extensive experience, and hope that it will continue. _____________cut here___________________________________________________________ ngtrans 6bone WG meeting December 9, 10 & 11, 1997 Washington, DC IETF Bob Fink chair, Ben Crosby, ALain Durand and Bob Fink reporting Discussion: 6bone@isi.edu (6BONE Mailer) Subscribe: majordomo@isi.edu "subscribe 6bone" Archive: http://www.ipv6.nas.nasa.gov/6bone/ Chairs: Bob Fink rlfink@lbl.gov Robert Gilligan gilligan@freegate.net Tony Hain tonyhain@microsoft.com Web site: http://www.6bone.net Due to limited time in the main ngtrans session, the discussions on 6bpne routing issues were handled in two lunchtime disussions on 10/11 December. WIDE 6bone status - K. Yamamoto A brief status report of the WIDE 6bone project was given. Of special note is the broad participation of many research/educational and industry partners, and the development of many IPv6 implementations. WIDE efforts started when, on June 9 1996, NAIST and Tokyo were connected via a 64kbps circuit using v6 and then on July 16, 1996 connection was made to the 6bone. Currently 28 sites are connected to 4 backbone routers using RIPng. BGP4+ conversion is delayed until later in the month. Future plans include linking the WIDE registry to the 6bone registry, creating an IPsec testbed, and of course BGP4+. Again the Chairs want to thank the WIDE project members for sharing their extensive IPv6 experience. 6bone status - Bob Fink A brief status report of the 6bone and the backbone conversion project was given. 206 sites, 30 countries 14 hosts & 13 router implementations (probably more at this time) 42 sites using aggregation address format auto address delegation done via registry auto map generation from registry daily courtesy of Andrew Scott of Univ. of Lancaster reverse registry courtesy Bill Manning of ISI The backbone conversion to aggregation was accomplished on schedule Different strategies are emerging for sub-delegation A brief overview of the inet6num registry object and how it relates to automatic IPv6 address delegation through the registry was given. This is a result of David Kessens' work at ISI. Discussion of backbone routing policy issues was reserved for the two lunchtime meetings on the following two days (10/11 December). Palo Alto IPv6 Exchange Point - Stephen Stuart The new PAix IPv6 exchange point was described. A LAN switch has been devoted to native IPv6 transported in the PAix, with DIGITAL-CA, UUNET-UK and NWNET currently peering across it. Stephen encouraged others interested and able to secure rack space in the exchange to particpate. CAIRN 6bone Report - Suresh CAIRN is a network testbed funded by DARPA. Currently CAIRN's 6bone peering is done with NRL. Futire peering is planned with University College London, PAix, and UUNET-UK. The transatlantic link will be native IPv6 peering over T1. UK Status: Ben Crosby An overview of the current IPv6 links in the UK was given. It was noted that there is a move to native links to janet, and to the Univ. of Southampton. 6bone Routing Issues I-D - Alain Durand An early draft outline of 6bone Routing Issues was presented and discussed in greater detail. The following is an outline of the topics covered: - Identify all special cases - link local prefixes MUST NOT be advertised - site local only within a site - but what is a site? Should refer IPngwg work on that topic - loopback address and unspecified MUST NOT be advertised - multicast prefixes - should they be advertised in BGP 4+ ? - decided that they SHOULD / MUST NOT be advertised - ipv4 mapped addresses - wait on the decisions from NGtrans on "ipv4 translatable" addresses - this applies only to backbone The draft should specify for each section if it applies to all routers or only to backbone routers - ipv4 compatible SHOULD NOT be advertised on 6bone - perhaps they should be banned - suggestion that they should only be used on tunnels - be careful in case there is a good reason to use them in the future - advertise some compatible bridges using a ::/96 - NEW SERVICE - general consensus not on the backbone - dimitri haskin wants this to happen automatically - auto tunnels dont need to have addresses advertised ? - one router to provide auto tunnelling ? - suggest that this is handled by the IGP ? ACTION - bob to send the idea to the mailing list. - No cases in which you would accept something that you wouldnt send on Stephen Stuart - liberal in recieve, but careful in sending Alain Durand - Ok to receive, but be carefull on what you put on your routing table - what happens with prefixes that dont yet exist - e.g. not 2000::/8 - routes SHOULD be discarded - Aggregation SHOULD be mandatory at every level - SLA, NLA, TLA - Backbone routers MUST be default free - sites MAY have a default route - Tunnels - prefix length ? - which address space ? - DMZ ? - Point to point tunnels could use a /128 - hardware implementation problem ? (some refuse to use /128 prefixes) - point about the use of /128 - BGP 4+ problems due to not sharing subnet - dimitri says use link local but this raises next hop routing problems - then routers automatically change into Site level ? - routing entry in IGP to support the /128 ? This is an IDR wg issue, not a 6bone one. - Tunnel meshing/transit issues - all pTLAs MUST advertise all pTLA routes to/from each other - for prefixes not in pTLA, should not advertise more specific routes - e.g., never advertise less that /24 - never aggregate for someone else (no proxy aggregation) It was suggested making all the changes above and send out to the list as a draft BCP spec for the 6bone. The purpose would be to thus document our operating policies on the 6bone backbone. 6bone General Planning - Bob Fink What to do nextwas discussed, given that the backbone has been converted to the new addressing. It was agreed that it was time to declare all 0ld (5f00) test addresses personna non grata - i.e., as of now we stop routing them. The general registry issue was also addressed, i.e., a lot of sites' registry entries have not been touched since they were automatically generated. Bob proposed deleting entries not cleaned up, given some warning. It was agreed to discuss this on the mail list. Multihomed Sites - Ben Crosby et al The general multihoming issue, i.e., how to do it at all, was discussed. An example of 2 TLAs, with NLAs allocated in each TLA, and a site multihomed to the 2 NLAs was used for this. One idea was to inject a /48 site level for the given site in both NLA & TLA, which there was general agreement on, i.e., this does not scale!!! A 2nd idea was to use limited multihoming - the problem is that this loses benefits of multihoming. In further discussion on Thursday a way was discussed to attempt this by using mobility. Matt Crawford presented the concept during the IPng meeting on Friday. and there was enough interest that it will at least be pursued at the discussion level. Note that this issue is only slightly different for IPv6 than it is for IPv4, and there needs to be more participation from IPv4 folk experienced in routing and multihoming to help move IPv6's multihoming issue along.