Minutes of NGtrans WG Meeting 17 July 2002, 0900-1130 Yokohama IETF-54 ======= Chairs: Alain Durand Tony Hain Margaret Wasserman Maragaret, Alain and Tony chaired the meeting. Bob Fink took the minutes. Attendance was ~ 250-270. =========================== Administrative information: Discussion ngtrans: Subscribe ngtrans: "subscribe ngtrans" Archive ngtrans: Web site: WG Status: Discussion 6bone: <6bone@isi.edu> Subscribe 6bone: "subscribe 6bone" Archive 6bone: Web site: ====== Agenda --- Introduction and Agenda Bashing -- Chairs --- Design Team Problem Statements/Scenarios - Overview of Design Team Concept -- Tony Hain - 3GPP Team -- Jonne Soininen - Unmanaged Networks Team -- Christian Huitema - ISP Team -- Cleve Mickles --- Design Team Evaluations & Solutions - 3GPP Transition Solutions -- Juha Wiljakka - Unmanaged Networks Evaluation -- Christian Huitema --- Transition Mechanism Applicability - Transition Interactions -- Alain Baudot - DSTM -- Jim Bound - ISATAP -- Tim Gleeson - BGP Tunnels -- Francois Le Faucheur - NAT64/NAT46 Mechanism -- Alain Durand --- NGTrans Charter Discussion - Review Proposed Charter Wording -- Chairs - Discuss On-going Work -- Chairs - What should progress, and what should wait for design team output? --- Interim Meeting Discussion -- Margaret Wasserman ================================ Introduction and Agenda Bashing -- Chairs There were no changes to the agenda as shown above. === Design Team Problem Statements/Scenarios --- Overview of Design Team Concept -- Tony Hain SLIDES: Tony Hain talked about the design team concept. The Goal is to: Provide *at least one* complete description for how to deploy IPv6 in common environments. Verify that all components necessary for deployment in a specific environment exist, interoperate correctly, and that any gaps are clearly identified. Provide a context for the IESG to evaluate documents being forwarded for standardization. The chairs established four design teams to create a set of catalyst documents to focus discussion in each area. Initial document drafts are personal submissions which focus on a description of each environment and the set of problems that need to be solved. If additional environments need to be documented, a design team or personal submission may be proposed to the working group. Subsequent revisions as a working group documents will describe how a set of ngtrans tools are used to deploy IPv6 in that environment. What follows are reports from three of these teams on their progress. The fourth led by Yanick Pouffary, was created just a few weeks before this IETF meeting and thus has not had time to prepare anything for this meeting. There were no comments. --- 3GPP Team - Jonne Soininen SLIDES: Jonne presented work of the 3gpp design team: Goals: Identify relevant transition scenarios Map relevant transition mechanisms to the scenarios Identify relevant transition mechanisms Perform Gap Analysis I.e. identify missing transition tools Make recommendations for usage of transition tools Document the scenarios, solutions, gaps, and recommendations for WG discussion A Non-Goal: Specify new transition mechanisms People & Deliverables: Design team members Alain Durand (NGTrans Chair) Margaret Wasserman (NGTrans Chair) Jonne Soininen Juha Wiljakka Hesham Soliman Karim El-Malki Hugh Shieh Niall Murphy Paul Francis Deliverables: Scenarios Document draft-soininen-ngtrans-3gpp-cases-00.txt draft-wiljakka-3gpp-ipv6-transition-00.txt Scenarios Document: GPRS Scenarios Dual Stack UE connecting to IPv4 and IPv6 nodes IPv6 UE connecting to an IPv6 node through an IPv4 network IPv4 UE connecting to an IPv4 node through an IPv6 network IPv6 UE connecting to an IPv4 node IPv4 UE connecting to an IPv6 node Transition scenarios with IMS UE connecting to a node in an IPv4 network through IMS Two IPv6 IMS islands connected via an IPv4 network Target dates: Scenarios document published - 04/02 Design team started - 05/02 First solutions draft published - IETF#54 Solutions draft finalized - IETF#55 Erik Nordmark commented that the scoping looked good. He asked if the design group had talked of the relative importance of the scenarios? Jonne responded yes. There are differences in relevance, and they are identified in the draft. Erik noting that IMS is an e-to-e service, asked if it is part of a gateway to something else? Jonne responded yes, it interworks with other systems. Bob Hinden also felt the results so far are good. He noted that we don't understand about new applications yet. Jonne responded that he was only referring to SIP, there will be other cases. Itojun asked if one could generalize this environment to other environments that are not cell phones? Jonne responded yes Tony noted that 3G has some characteristics that are not general, thus other scenarios needed and thus other teams for non-3G environments. Tony asked if this should become a working group work item. There was a clear consensus (unanimous I believe) to do so. --- Unmanaged Networks Team -- Christian Huitema SLIDES: Christian presented: Looking at Requirements: Decided to not start from mechanisms Instead, start from applications Local Client Server Peer-to-peerq Look at 4 types of requirements Connectivity & addresses Naming Security Local Applications: Connectivity Local addresses Naming Typically ad hoc. Example: SLP Security Isolation of local traffic from the Internet. Client Applications: Connectivity Global addresses, or possibly relay. Naming Access to a DNS resolver. In some cases, address to name mapping is required. Security Isolation of local traffic from the Internet. Privacy of the client. Peer-to-Peer: Peer-to-peer Global addresses, stable during a session Naming Typically ad hoc. Security Restrict communication to authorized peers. Protect local applications Possibly, privacy requirement. Servers: Connectivity Global addresses, stable enough for DNS publishing Naming Publish DNS records for the server. Security Restrict access to the authorized services. Steve Deering noted that for the server model, providing access to the whole world, that there is local use too without global access. Christian agreed, but that there is no knowledge in server of where users may be (and what their ip addresses are). Steve noted that while addresses might be stable during a session lifetime, that for an application such as Gnutella it might need to be longer. Christian agreed that one may want to retain addresses for longer than the length of the session, i.e., between. But yes, it varies with type of session Steve asked if Christian meant to imply there is only one link in these environments? Christian replied yes as multi-links would need a configuration manager. ` Steve responded that during the lifetime of v6 that there will be need to have multi-links, thus to exclude them in this scenario would be short sighted. Christian noted that there are two issues, transition strategy is for a shorter time (open to debate), and others are looking at more complex environments. Margaret noted that there is a fine line here, so we need to decide what to document and where. Randy asked what was specific to v6 in what Christian said, and what is needed to solve in v6 for these environments. Christian responded that this draft is a look at the environment. Margaret noted that we need to look at transition scenarios, not specific tools. this is a scenario (scoping) document. Tony also noted that these are descriptions of environments. Erik Nordmark, returning to echo Steve Deering's earlier point, that during life of v6 transition that the number of links in home will increase, and they won't need to be managed. Christian replied that he will take this into consideration. Christian stated that we need to go to the next step and see what mechanisms we have and what that implies. May have a v4-only host asking for v6 printer, but haven't done this yet. Thomas Narten noted that in reading the draft, so far it didn't mention implications for v4 and v6 (and transition), need to define more. Christian replied that this is a scoping document, then need to drill down. Tony Hain then asked if this should become an ngtrans work item. There was a large consensus to do so. Tony noted that each of these documents are defining the problem space. --- ISP Team -- Cleve Mickles SLIDES: Cleve presented: Design team members: Randy Bush Ron da Silva Gerard Gastaud Vijay Gill Itojun Cleveland Mickles Margaret Wasserman Scope: CORE/Backbone Broadband HFC/Coax Broadband DSL Narrowband Dialup Ethernet to the Home/Home Networking Security Network Management Outline: Topology Physical Logical Hardware Routers Switches CPE (router, modem, pc, gateway, appliance, etc) Routing IGP EGP ( if applicable) IRR Aggregation Policing Filtering Traffic Engineering Security Intrusion Detection Prevention Network Management Out of band, configuration tools, snmp Hosting Gear DNS, radius, tacacs, mail, tools Qustions received: Will most of these areas have similar issues? Where is the IPv6 discussion? What about IX issues? I’d like to work on the CORE network part of the document. Questions for WG: Offers to help in areas other than CORE? Everyone wants to work on CORE Go figure. Need help in other areas. Will this team focus on only describing the environments? Folks are asking about IPv6 issues. Comments on the scope or outline as presented Goal is to have all cases documented by IETF55 Team to create the transition solutions document? IPv6 transition tools are discussed here? Cleve noted that he had sent the outline of what he wants for each environment to the design team, but that there were no comments yet. He also noted that he needs help in other areas than core (everyone wants to work on the core). Steve Deering asked if the hosting services included web caches. Cleve replied yes. Cleve asked if after scoping the work whether multiple design teams will be formed to do the work, or if his current group will? Steve Deering felt that a split of effort along the lines of core vs. access was possible, but may lose details. But definitely don't separate access into different design teams. Overall, don't split the effort is probably right. Tony Hain said that once problem statement is done, solution is next on Cleve's plate (unless he didn't want to ). Tony then asked whether this should become an ngtrans work item. There was unanimous consensus to do so. === Design Team Evaluations & Solutions --- 3GPP Transition Solutions -- Juha Wiljakka SLIDES: Juha presented "IPv6 Transition Solutions for 3GPP Networks": GPRS scenarios 1. Dual stack UE connecting to IPv4 and IPv6 nodes: The most extensive scenario. Dual stack UE: both stacks can be simultaneously active. Managing the IPv4 address pool is a challenge. Use of private IPv4 addresses means use of NATs that should be avoided. 2. IPv6 UE connecting to IPv6 node through an IPv4 network Making the ”IPv6 in IPv4” tunneling in the network. Tunneling can be static or dynamic. Compare with 6bone. 3. IPv4 UE connecting to IPv4 node through an IPv6 network “IPv4 in IPv6” (static or dynamic) tunneling in the network The scenario is not considered very likely in 3GPP networks. 4. IPv6 UE connecting to an IPv4 node Translation is needed, because the UE and the peer node do not share the same IP version. NAT-PT has certain problems, use of NAT64 will be analyzed. 5. IPv4 UE connecting to an IPv6 node Translation is needed, because the UE and the peer node do not share the same IP version. NAT-PT has certain problems, use of NAT64 will be analyzed. IMS scenarios 1. UE connecting to a node in an IPv4 network through IMS UE has IPv6 connection to the IMS and from IMS to an IPv4 node. Translation needed in two levels: SIP and SDP in an ALG User data traffic at IP level. This is a challenging case. 2. Two IMS islands connected via an IPv4 network Closely related to GPRS scenario 2. Connection of two IPv6-only IMS islands has to be made over IPv4 network. Compare with 6bone. NA(P)T-PT issues NAT-PT has its limitations. Those include: NAT-PT is a single point of failure for all ongoing connections. Additional forwarding delays due to further processing, when compared to normal IP forwarding. Problems with source address selection due to the inclusion of a DNS ALG on the same node. Recommended actions: The separation of the DNS ALG from the NAT-PT node. Ensuring that NAT-PT does not become a single point of failure. Load sharing between different translators. A recent “NAT64 - NAT46” (draft-durand-ngtrans-nat64-nat46-00.txt) might provide a solution. IPv4/IPv6 issues related to SIP IMS scenario 1 is challenging due to two levels of translation: SIP / SDP signalling User IP traffic In proposed solution, SIP ALG translates SIP traffic, and also coordinates user IP traffic translation. E.g. setting up the IP addresses in the user traffic translator. Solution to this scenario still needs some work. Initial recommendations Tunneling over the air interface should be avoided, i.e. "IPv6 in IPv4" tunneling should mainly be handled in the network, not in the UEs. The IPv4 / IPv6 interworking should be mainly handled in the network, not in the UEs. Implementation of dual stack for the UEs is recommended, at least during the early phases of IPv6 transition. We are asking for your participation We appreciate comments and input from the people in the Ngtrans wg a lot. Please read the two documents and give comments on the ngtrans mailing list. Comments can also be sent directly to the document editor juha.wiljakka@nokia.com Juha then asked if this draft can become a WG draft? Steve Deering asked why avoid tunneling over the air given header compression. Jim Bound then commented that he had been telling this group for a year to not avoid tunneling, but no change has resulted. He felt confident that it is a low cost thing to do contrary to what the 3gpp have said. Jonne Soininen responded that he was sorry they had made no reply or action, and that they wanted to avoid tunneling because it's not needed. Jim replied that it is needed to prevent other workarounds, like new transports protocols. Another person commented that there is a case to allow tunneling and it's in the draft. Jonne responded that we are recommending to not do tunneling but if you need to do so you can. Francis asked if they had shown this to other bodies, as the scenario shows no competition for network service. Juha responded that this scenario should be covered, that Francis was right. Tony Hain called a halt to discussion. He noted that there are some opinions that we need to have something in this space, but may not be consensus to accept this draft as ngtrans work. So further discussion would be taken to the list. --- Unmanaged Networks Evaluation -- Christian Huitema SLIDES: Christian presented "Transition mechanisms for unmanaged scope networks": How come IPv6 is not there yet? Applications Need upfront investment, stacks, etc. Similar to Y2K, 32 bit vs. “clean address type” Network Need to ramp-up investment No “push-button” transition Restated: how do we get IPv6 deployed? We need a flagship application If possible, something IPv4 cannot do For example, it relies on global addresses We need to convince developers Don’t try to do NAT traversal, we will do it for you… And for that we need IPv6 everywhere Or at least in all unmanaged networks What will be the flagship application? Local applications (file & print sharing) Work OK in current home networks Moderate IPv6 advantage (local addresses) Client applications (web & mail) Work just fine today Peer to peer applications Require connectivity, global addresses ==>First priority Server applications Require connectivity, publishing in the DNS Second priority An Example of “hybrid” P2P, using SIP was shown Getting IPv6 connectivity for P2P Step 1: host based, Teredo (with fix) Deploy IPv6 “despite the NAT” Engineer Teredo for direct transmission Don’t want to proxy voice, video… Step 2: improved NAT with 6to4 NAT also becomes an IPv6 router May be “phase 1” if host has global IPv4 Step 3: improved ISP, dual stack NAT receives prefix from ISP, relay it Example: RA proxy Single stack IPv6 appears “much later” IPv6 based P2P applications still work Beside Connectivity… Security Make the router a “site boundary” Ensures isolation of “local” applications Use privacy addresses Provide NAT-equivalent privacy Make the inside addresses “hard to guess” Use “personal firewall” Don’t seat naked on the Internet And then, naming. For the “client” applications Need to discover a “resolver” Need a “reverse lookup” option Wildcard PTR records ? Automatic generation of PTR & AAAA ? Some solution for 6to4 addresses ? For the “server” applications Need to publish the address Requires stable address, or dynamic updates Christian said that a draft will appear soon. Jim Bound asked if this is just Christian's view of the unmanaged space? Christian replied yes, and as an ngtrans item other views need to be included. Erik Nordmark asked what the relationship of this presentation had with other environments, as it was mostly peer-to-peer. Tony Hain responded that yes it was peer-to-peer, but more comes later. === Transition Mechanism Applicability --- Transition Interactions -- Alain Baudot SLIDES: Alain presented an applicability statement for the Interaction draft: Overview Within a same scope (i.e. global, site, host) different transition mechanisms may interact with each other Implementers and/or users MUST be aware of potential issues. Interaction may impact transition strategies and scenarios, and other real life deployment cases, as well. Applciability statement Interaction document applies to any scenario that may involve several transition tools of a same scope Interaction document applies to other possible/realistic cases involving several transition tools of a same scope. Moving Forward Interaction may be addressed according to two main options: a companion document dedicated (fully or partially) to interaction every transition scenario document include a section dedicated to interaction Alain then covered the pros and cons (please see the presentatiom slides above) Next Step Companion document may be draft-ietf-ngtrans-introduction-to-ipv6-xx : dedicated interaction section may come next to the tools overview, dealing with « pathological » cases. Update study cases, involving every tools (e.g. ISATAP, Teredo) Alain asked if there were any other ideas/proposals? There was no discussion. --- DSTM -- Jim Bound SLIDES: Jim presented on DSTM scoping and applicability for transition: Assumes users want Intranet native IPv6 Local-Area and Routing Domain dominant network infrastructure for deployment. Assumes users want Intranet native IPv6 network management, node services, and applications for their network. Avoids Network Address Translation by assigning temporary IPv4 Addresses to dual-stacked nodes using IPv6. Tunnels IPv4 packets within IPv6 to the Edge of the Network. Useful for Initial and Later periods of IPv6 Transition Extensions Address Assignment Mechanisms: DHCPv6, RPCv6, Manual Configuration Can leverage other Transition Mechanisms: 6to4, RSIPv6 Port Ranges, SIIT, Mobile IPv4/IPv6, 3G, WLAN IPv4/IPv6 Implementations on BSD UNIX, Linux, Microsoft 2000 and XP with trial deployment in process. Applicability: IPv6 Home Network can use DSTM to connect to IPv4 World. IPv6 Mobile Devices use DSTM when requiring access to IPv4 World. IPv6 Manufacturing, Financial, or Military network can use DSTM when accessing IPv4 controls. IPv6 ISP can assign temporary DSTM IPv4 address to reach IPv4 application and avoid NAT at end user site, or integrate use of DSTM with 6to4. Avoids NAT, Maintains End-2-End, and Provides Security between two peers for IPv4 and IPv6 Interoperation. Jim then presented a pictorial overview of DSTM, its architecture, how it works in 6to4 and other extension. Please see the presentation pdf/ppt above for these graphics. Jim Bound made a plea for others to include their assumptions in scoping drafts to ease personal evaluation and interaction, and to help eliminate confusion. Alain Durand commented that if he assumes we already have a native v6 deployment, then say it's early stage. Jim responded that there are customers that want to buy, and can deploy, a native v6 network. Tony Hain commented that just because a native v6 network can be deployed doesn't mean all apps can work. Christian Huitema thought we needed to define scope first, and thinks Jim has done this, but there is a slight difference. Tony noted that the design teams are one effort, and that this presentation was based on an existing tool and does need to state basic assumptions. Particular environments need to be scoped. Erik Nordmark asked if Jim was expanding network scope. Jim agreed need to add scope. Not everyone wants to do v4 and are willing to go to v6. Erik commented that in avoiding nats, there are architectural issues involved with using tunnels instead of translation, and that there needs to be an explicit discussion on this issue. --- ISATAP -- Tim Gleeson SLIDES: Tim presented "ISATAP Applicability": Applicability document Enterprise/managed network environment Deployment scenario for ISATAP Applicability of ISATAP Enterprise/Managed network environment E.g. corporate/academic campus networks ("intranets") Normally organized as arbitrarily-large "stub" networks: may include multiple security compartments may have multiple peering points with global Internet Normally operated by single administrative authority: may be centralized or distributed, but united by commonality of interests/policies Deployment scenario for ISATAP Deploy one or more ISATAP routers, each with Link(s) to IPv4 enterprise network (Possibly) a link to the IPv6 internet One entry in the DNS For isatap.domainname A record for every ISATAP routing interface Clients auto-configure themselves Applicability of ISATAP Automatic tunneling, no configured tunnel state hosts can be added without manual configuration Non globally unique IPv4 addresses useable No special IPv4 services within the site (e.g., multi-cast) Compatible with other mechanisms (e.g., [6TO4]) Supports both stateless address autoconfiguration and manual configuration Eases aggregation issues at border gateways Prefix per site, not per host Feedback Enterprise-internal firewalls may exist May need to split the enterprise into one or more ISATAP sites Native/tunneled IPv6 routing and firewalling between these sites Document future Content updates Growth (and shrinkage) of ISATAP sites Site splitting Relates to growth and internal firewall issues Content location Evolve into a more general document? Contribute ideas to a separate document? There were no comments or discussion. --- BGP Tunnels -- Francois Le Faucheur SLIDES: Francois presented "Operational Environments and Transition Scenarios for 'Connecting IPv6 Islands across IPv4 Clouds with BGP'": Scope Describes two specific Migration Scenarios (i.e. Operational Environments) of Service Providers Describes a Migration Solution for each, based on existing NGTRANS/IP6 mechanisms Francois presented pictorial demonstrations of the bgp-tunnel operational environment and the two scenarios using MP-BGP over v4 and MP-BGP over v6. Please see the presentation pdf/ppt above for these graphics. Summary Two main scenarios for IPv4 SPs wanting to add IPv6 services without core upgrade Respectively addressed by two approaches (which are detailed in draft-ietf-ngtrans-bgp-tunnel-04.txt): MP-BGP over IPv6 MP-BGP over IPv4 Those are particular combinations of NGTRANS/IPv6 techniques Implementations, tests, planned deployments Proposal Feed this two Migration Cases (and associated Migration Solutions) into Cleve’s ISP Design Team document(s) Sorry, this is core stuff again Itojun commented that he didn't see why it is needed as you need to upgrade all ebgp routers anyway, so then one can setup normal RFC2893 (MECH) tunnels and do normal BGP4+ over v6. Alain Durand said that this should be taken to the list. Erik noted that this and other presentations don't recognize/identify that there are two transition approaches, multiple small steps or single large steps. --- NAT64/NAT46 Mechanism -- Alain Durand SLIDES: Alain presented on "Introducing IPv6-only in the Internet: Balkanisation… or Translation?" noting that a layer 3 solution such as a revisited NAT-PT or NAT64/NAT46 could be an interesting avenue. As the presentation was abbreviated due to time, the full set of slides (above) should be used for further understanding and only the synopsis below is given: The presentation focused on the consequences on the introduction of IPv6-only networks in the Internet, example of services that could break and administrative procedures based on dual-stack that could be used to solve the problems. The presentation concluded by observing that several services shared similar properties, and that the administrative solutions suggested share scaling issues, thus a layer 3 solution such as a revisited NAT-PT or NAT64/NAT46 could be an interesting avenue. Itojun asked why this new project was allowed on the agenda given the chairs decision in Minneapolis to put project work on hold to do scoping? Jim Bound made a comment (Jim?). There was no further discussion. === NGTrans Charter Discussion --- Review Proposed Charter Wording -- Chairs Tony talked about the new charter and goals and then accepted comments. Thomas Narten said that at some level the goals are good., but that your goal says "might be used", is it probably, maybe, or what, and that one must really understand this before letting a tool to progress through ngtrans. Jim Bound commented that we need more face to face time, like interim meetings, and that he agreed w/Thomas, but wondered how we determine what is really important, especially if not represented at IETF. He also felt that you can't tell customers how to transition, that we failed in past doing it that way. We need to give them mechanisms. For ngtrans to say how many are too much is not reasonable, and that it needs to be open ended. Margaret noted that we are considering an interim meeting to have more time to work together. Jim note that this is the most important meeting this week as an engineer. Tony Hain noted that we need to prioritize our work. Jim stated that we need to work on all stuff, and that if we can't work here, we may need to go elsewhere. Randy agreed w/Jim. v6 is happening now, and we need to learn lessons on what is happening (noting that there is a v6 operations/deployment panel at this IESG plenary), and that it is possible one of the themes are that lots of standardized tool are needed. Tony noted that this community liked to solve hard problems. and that we need to solve problems that we really need to solve. Randy noted that this is what is driving the development of the scenario/environment documents. There was a question on the context of transition, that we need to distinguish between deployment and transition. Ross Callon commented that work is important on scenarios, and talking about all this is important, including all implications. He noted that with the number of 3gpp sub-scenarios, some of them may be too hard and we may choose not to do them. He also believed that we will end up deploying combinations of mechanisms that won't/don't work together. Deployment scenarios are important. --- Discuss On-going Work -- Chairs What should progress, and what should wait for design team output? There was no time for discussion. === Interim Meeting Discussion -- Margaret Wasserman There was not enough time for this discussion, so it will be taken to the list. The intention is to have an ngtrans interim meeting in mid to late September, but it will be discussed on the list and nothing is decided yet as to agenda, location or exact date. --- The meeting adjourned. end