Minutes of NGtrans WG Meeting 17 March 1999 Minneapolis IETF ___ Chairs: Alain Durand Bob Fink Tony Hain This ngtrans meeting reported by Alain Durand, Bob Fink and Tony Hain. Attendance was ~180-190. ___ Administrative information: Discussion ngtrans: ngtrans@sunroof.eng.sun.com Subscribe ngtrans: majordomo@sunroof.eng.sun.com "subscribe ngtrans" Archive ngtrans: ftp://playground.sun.com/pub/ngtrans Web site: http://www.6bone.net/ngtrans.html Discussion 6bone: 6bone@isi.edu Subscribe 6bone: majordomo@isi.edu "subscribe 6bone" Archive 6bone: http://www.ipv6.nas.nasa.gov/6bone/ Web site: http://www.6bone.net Bob Fink announced that Alain Durand (Alain.Durand@imag.fr) has been designated as 3rd co-chair of the NGtrans wg (welcome Alain) and that Randy Bush (randy@psg.com) has replaced Harald Alvestrand as the OPS AD for NGtrans (thanks to Harald and welcome to Randy). ___ Agenda 0900-0905 context for this meeting (Grenoble, etc.) - Bob Fink 0905-1005 6to4 draft - Brian Carpenter/Keith Moore 1000-1015 additional topics (Shu NAKAMAE & Ivano Guardini) 1015-1100 planning roadmap documents - various 1100-1115 6bone hardening proposal - Bob Fink 1545-1800 Tools/mechanisms review for forwarding status (SIIT/AIIH/DTI/BIS/NAT-PT) ___ Context for meeting - Bob Fink Bob then gave a short overview of the NGtrans interim meeting in Grenoble, and the context for the agenda for this meeting: IPng, NGtrans and deployment (ipv6.org) met in Grenoble, France (thanks to Alain Durand and IMAG for a great meeting!!) 2-4 Feb 99. The primary ngtrans goal was to evaluate which transition tools/mechanisms to keep/discard. Consensus was we need them all at some time (and to make them informational not experimental for purposes of conveying more usability). It was also agreed to develop Roadmap Documents to explain transition scenarios and how to use tools/mechanisms. After Grenoble, the OPS ADs wanted NGtrans to make a best (last?) effort to move our tools/ mechanisms to standards track, only relying on other tracks on a case by case basis as appropriate. There has been great interest in the 6to4 draft since Grenoble, indicating that we need to move it aggressively (or not) at this meeting. The IPv6.org deployment group has expressed strong opinions to make 6bone good for early production deployment of ipv6 service. thus necessitating work on the 6bone to harden it for production use. ___ 6to4 draft - Brian Carpenter/Keith Moore Brian Carpenter gave a brief overview of the 6to4 concept (see Draft-ietf-ngtrans-6to4-01.txt). 6to4 uses the global IPv4 Internet as a link layer by assigning a TLA (e.g. 2010::/16) so that a full IPv4 address can be imbedded in the remainder of the external routing prefix (i.e., 2010:IPv4::/48). The IPv4 "NLA" is the IPv4 address of the site border router that supports 6to4 tunneling. The immediate benefit: sites get an IPv6 prefix without going to the registries, as well as automagically tunneling over the v4 cloud separating v6 sites. Basic scenario: Site A & B are 6to4 only Relay scenario: Site A is 6to4 only, site B is multi-homed 6to4 & real v6 network Routing at site A: Site A: prefix is 2010:C001:0203::/48 Egress router has configured internal route to 6to4 encapsulator for 2010::/16 If site A wants to communicate to non 6to4 sites using site B as a relay, it has to configure a default route to relay router of site B. Routing at site B: Site prefixes are 2010:09FE:FDFC::/48 and e.g.; 2001:0600::/48 It advertise routes to 2001:0600::/48 and 2010::/16 into the global IPv6 routing. Issue: what is the scope of those advertisements? Question: can you advertise a longer prefix than 2010::/16? Answer: Brian: donÆt do that. Scope of 6to4 prefix adverts - 2010:xxxx:xxxx::/48 are never advertised into IPv6 routing - 2010::/16 is advertised by relay routers MTU needs to be 1280 but may be 576, in that case, return packet too big ICMP. Encapsulation in IPv4 is as for regular tunnels with protocol type 41. IPv6 multicast is not mapped to IPv4 multicast. 6to4 should use v6 multicast routing. IPv4 NAT? If you collocate the boundary router and the NAT box, it works, but itÆs no different than having a configured tunnel on the NAT box. Issue: what if there is a second (inner) IPv4 NAT? Multicast support need to be worked out, help is required on that topic. We must avoid the Multicast over NBMA swamp. Issue: source address selection In case of multi-home site (6to4 and global IPv6), source address must be 6to4. However, source address selection is not specified in IPv6. For 6to4 it is sufficient for the sender to perform longest match across all source and all destination address. This will affect all hosts, some modification are needed. Issue: you need a route to a default router. How do you find that route? Suggestion: use IPv4 anycast Comment: you can do similar things with tunnel brokers Issue: not only does a relay router need a route to a native IPv6 router, but there must be a route in the other direction. This is just the same as a configured tunnel (but it is in effect a tunnel to a whole 6to4 cloud, not to a single site). Question: if you have several sites behind the ingress 6to4 router? Things might get complex. Comment: 6to4 is using IPv4 as NBMA as a large cloud and not as point to point links. It is having 2 level of routing which do not know each other. Other comments were directed to the mailing list The chair polled the sense of the room as to 6to4 being worth continuing. There appeared to be very near complete consensus to continue refining 6to4. More work is needed, however, before ngtrans can fully evaluate the proposal. Also, more illustrations and concrete examples of how 6to4 works are needed, and guidance on how 6to4 can be useful in the ngtrans toolkit. ___ An IPv6 visualization - Shu Nakamae Shu Nakamae from Keio Univ. and the Wide project, presented his work for a 3D visualization unique to IPv6 that can show topology and hierarchy at once. Entries taken from a registry database, are output as a VRML graph. Bob Fink has set a pointer to this work on the 6bone tools page. ___ Tunnel broker - Ivano Guardini Ivano Guardini from CSELT presented the tunnel broker work that will be published soon as , that provides a service to manage tunnels on behalf of the users, thus making it almost no work to connect to the 6bone. This work is an addition to the current ngtrans tool set. ___ Roadmap document set - various Bob Fink stated the goal as outlining what we want in the roadmap docs, how to structure them, and then assigning the work to be done. He invited those who had prepared comments on the roadmap docs to come forward to present their ideas. Transition roadmap - Jim Bound Put the various scenarios in matrix and have each author address a set of questions. Some of the main entries of the matrix: - transition assumption - evolution assumption of IPv6 - IPv6 deployed at Edges or Core? - IPv4 global addresses required? - how IPv4 addresses are assigned to hosts - is translation required, is tunneling required? - what are the affects to IPsec, to renumbering? - is new software required and where? - how do you retire a mechanism, Question: is this not just duplicating each document into the matrix? Answer: no, just put checkmark or very simple text in the matrix. What are the issues for the end user? - Dale Finkelson What is the problem IPv6 is trying to solve? Meaning of transition Taxonomy of transition mechanism Discussion of real situation Terminology needs to be detailed Information needed by network architects: Alain Durand Network operation models are different from shop to shop, tool documentation is required. This includes: - what problem is the tool trying to solve? - what are its limitations? - how to use it? - what are the requirements? - how does it interact with other tools? - when not to use it? Other documents are needed. Suggestion: call for white papers on general views of transition requirements Suggestion: have a companion document with applicability statement for each transition mechanism General comments - Bob Hinden Separate tool documentation from scenarios. Request that we pick 3 scenarios to focus on - identify requirements for them. Jim Bound agreed to work on a tools/mechanisms comparison document to engage authors to help catgorize their respective efforts. Dale Finkelson agreed to work on a roadmap overview document (using volunteer efforts as appropriate). Alain Durand agreed to work on a transition scenarios document (using volunteer efforts as appropriate). ___ 6bone hardening - Bob Fink Goals for the 6bone are changing: ò The 6bone is almost 3 years old, and has focused mostly on testing out standards and implementations ò There is no restriction on running production traffic over the 6bone (especially with the recent AUP clarification that itÆs up to the 6bone participants to apply their own AUPs as appropriate, not the 6bone) ò There is growing sentiment to harden the 6bone and start running production traffic over it downside/upside? ò Using a 6bone pTLA-derived prefix has only one downsideà eventually everyone has to renumber When that will be is anyoneÆs guess, but it wonÆt be until there is no longer a useful deployment role for the 6bone ò Meanwhile, the 6bone community can decide how to allocate its addresses, and how to operate its networks through the IETF NGtrans WGÆs oversight ò Oh yes, some might think it a downside that the 6bone is under the IETF (you decide) So what might hardening entail? ò Review of "6bone Routing Practiceö I-D ò Route filtering to exclude non TLA routes ò BGP4+ session monitoring to look for instability (a sub question is if the Merit 6bone-routing-report is accurate) ò Tunnel peering strategy to provide better routes ò Registry changes related to improving the backbone ò DNS issues related to improving the backbone ò other issues appropriate (e.g., rules for becoming a pTLA) How to proceed ò A small Task Group to recommend to the the 6bone list, then to NGtrans in Oslo (Bob noted that he had asked Rob Rockell of Sprint to lead the task group) ò Folks volunteering should have strong pTLA and IPv4 routing experience ò Contact Bob Fink to volunteer Other issues ò Might it make sense to have both production and experimental sides of the 6bone to differentiate need for backbone routing stability? (have task group speak to this as well) ò Change in 3FFE:/16 usage structure to allow for more growth Address change: Move to a 13 bit pTLA 19bit NLA and exercise our renumbering skills. Concern: this will make DNS delegation difficult in the absence of the A6 and binary records with this 13 bit boundary Suggestion: 12 bits pTLA to keep bit boundaries multiple of 4. Bob will send out to the 6bone list a proposal for this change. ___ Tools/mechanisms review for forwarding status (SIIT/AIIH/DTI/BIS/NAT-PT) First, Harald Alvestrand as the current OPS AD for NGtrans agreed to give an overview of why and how to make a standard. The purpose of the IETF is to make the Internet work and to provide standards. Who decide if something is a standard? The AD does. Standards: standards specify behavior - Must be asked for - Must be competent (must not have known problems) - May be useful. Need operational experience - Experimental means unstable: please go and experiment, we want to document it, but we will change it - Informational means it will not go standard track - does not belong to IETF - descriptive material ___ SIIT - Erik Nordmak Environment: one part is v6 only or dual stack, but some nodes are v6 only and want to communicate to v4 hosts. SIIT does not specify how does the v6 only host gets the ôtranslatableö address. Open issue: in IPv4 you can send UDP packets without checksum. This is not allowed in IPv6. Question to the room: how important is this? Case of running NFS over UDP. But on large networks, you prefer to use TCP. Question: what about NTP? Is there any other IPv4 UDP application which turn off UDP checksums? Question: can protocol translator be standards? Answer: yes Question: do you need v4 routing within sites? You night use IPv6 in IPv6 tunnels. In the draft, it says ôthe way you route within the site is out of the scope of the documentö Jim Bound general comments: ôexperimental means unstable, the market will not accept itö. Question: SIIT does not do authentication, which is mandatory in IPv6à but you are talking to a v4 system, not a v6, so the rule does not apply. This is the kind of question that the IESG might ask, so weÆd better get ready to answer this before going to standard track. It seems that the SIIT meets the criteria for making it a standard, so ngtrans should attempt to push SIIT forward to PS. Erik agreed to proceed to ready SIIT for PS. ___ AIIH/DTI - im Bound Jim announced that the AIIH and DTO authors have just started the integration of AIIH and DTI into a new draft to be submitted soon. >From AIIH: DNS mechanisms and address assignment, DHCPv6 reconfigure for Ipv6/IPv4 nodes. >From DTI: dynamic tunneling setup/dynamic tunneling interface/dynamic tunneling black box. Required components: - DHCPv6/DNS communication - DTI black boxes - DTI interface on IPv4/IPv6 hosts - Statically configure IPv4 pool of addresses - Statically configure tunnel end-points We should wait for the new draft to decide what to do with the proposal, but there is a good feeling that it meets the criteria to go to Standard Track ___ NAT-PT - Georges Tsirkis Geroge gave a short generic presentation of NAT-PT. He noted that there are 3 implementation of NAT-PT at the moment. NAT-PT is a complement to SIIT, so they are somehow linked. If we standardize SIIT, we should standardize NAT-PT. Also, as NAT-PT references SIIT, it is another incentive to standardize SIIT. Comment: we should wait for the evaluation matrix before having any document going to PS. Comment: none of the draft is well written in good English. Margaret Wasserman volunteered to review the English of NAT-PT Comment: going to PS will draw more attention to the proposal. It seems that the NAT-PT meets the criteria for making it a standard, so ngtrans should attempt to push NAT-PT forward to PS. George agreed to proceed to ready NAT-PT for PS (waiting on Margaret for her review). ___ Bump In the Stack (BIS) - Kazuaki Tsuchiya Kazuaki gave a short general presentation of BIS. Question: how does it relate to NAT-PT? The translation is the same, but they are targeting different scenarios and are placed in different places. Question to the room: is this mechanism useful? Answer: yes. The are no outstanding technical issues with BIS, and it was agreed that this mechanism can be useful. Thus it was agreed that BIS be reviewed for quality by WG as if it would become PS, but accepting the fact that the IESG might decide it should be informational. -meeting adjourned