Current Meeting Report

2.4.12 Next Generation Transition (ngtrans)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at: -- Additional NGTRANS Page
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 06/05/2002

Tony Hain <>
A Durand <>
Margaret Wasserman <>
Operations and Management Area Director(s):
Randy Bush <>
Bert Wijnen <>
Operations and Management Area Advisor:
Randy Bush <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe ngtrans
Description of Working Group:
1. Specify the tools and mechanisms that might be used for transition to IPv6.

2. Write documents outlining how the various transition tools and mechanisms might apply to various scenarios for a transition to IPv6.

3. Coordinate with the IPv6 6bone testbed, operating under the IPv6 Testing Address Allocation allocated in Experimental RFC 2471, to foster the development, testing, and deployment of IPv6.

4. Coordinate appropriately with other IPv6 related IETF activities and activities in other organizations.

Goals and Milestones:
MAR 01  Decide if BGP-tunnel is Informational or Experimental
MAR 01  Progress 6papa to Informational
MAR 01  Decide fate of ipv4survey as it has been deleted from I-D registry
Done  Progress socks-gateway back to IESG for Informational
Done  Progress tcpudp-relay back to IESG for Informational
MAR 01  Decide what to do with personal draft hain-6to4-scaling
MAR 01  Decide what to do with personal draft tsuchiya-mtp
MAR 01  Decide what to do with personal draft templin-v6v4compat
AUG 01  Progress DSTM to PS (keyed to DHCPv6 forwarding)
AUG 01  Progress 6to4-dns to either Informational or PS
AUG 01  Progress mimetype to PS
AUG 01  Progress Transition description to Informational
DEC 01  Progress v4-over-mipv6 to Informational
MAR 02  Progress 6to4 to DS
MAR 02  Progress MECH to DS
MAR 02  Progress SIIT-DSTM to either Informational or PS
AUG 02  Progress NAT-PT to DS
AUG 02  Progress SIIT to DS
  • - draft-ietf-ngtrans-introduction-to-ipv6-transition-08.txt
  • - draft-ietf-ngtrans-dstm-08.txt
  • - draft-ietf-ngtrans-ipv4survey-02.txt
  • - draft-ietf-ngtrans-bgp-tunnel-04.txt
  • - draft-ietf-ngtrans-6to4-multicast-01.txt
  • - draft-ietf-ngtrans-isatap-04.txt
  • - draft-ietf-ngtrans-ipv6-smtp-requirement-06.txt
  • - draft-ietf-ngtrans-mtp-02.txt
  • - draft-ietf-ngtrans-moving-01.txt
  • - draft-ietf-ngtrans-bia-05.txt
  • - draft-ietf-ngtrans-dns-ops-req-04.txt
  • - draft-ietf-ngtrans-shipworm-06.txt
  • - draft-ietf-ngtrans-interaction-01.txt
  • - draft-ietf-ngtrans-tunnel-mime-type-00.txt
  • - draft-ietf-ngtrans-dstm-overview-00.txt
  • - draft-ietf-ngtrans-isatap-scenario-00.txt
  • - draft-ietf-ngtrans-unmanscope-00.txt
  • Request For Comments:
    RFC1933 PS Transition Mechanisms for IPv6 Hosts and Routers
    RFC2185 I Routing Aspects of IPv6 Transition
    RFC2546 I 6Bone Routing Practice
    RFC2766 PS Network Address Translation - Protocol Translation (NAT-PT]
    RFC2767 I Dual Stack Hosts using the Bump-In-the-Stack Technique (BIS)
    RFC2765 PS Stateless IP/ICMP Translation Algorithm (SIIT)
    RFC2772 I 6Bone Backbone Routing Guidelines
    RFC2893 PS Transition Mechanisms for IPv6 Hosts and Routers
    RFC2921 I 6BONE pTLA and pNLA Formats (pTLA)
    RFC3053 I IPv6 Tunnel Broker
    RFC3056 PS Connection of IPv6 Domains via IPv4 Clouds
    RFC3089 I A SOCKS-based IPv6/IPv4 Gateway Mechanism
    RFC3068 PS An anycast prefix for 6to4 relay routers
    RFC3142 I An IPv6-to-IPv4 transport relay translator

    Current Meeting Report

    Minutes of NGtrans WG Meeting
    17 July 2002, 0900-1130
    Yokohama IETF-54

    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: <>
    Subscribe 6bone: <> "subscribe 6bone"
    Archive 6bone: <>
    Web site: <>


    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
    <No Draft Available>

    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
    <no ID>


    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


    Jonne presented work of the 3gpp design team:

    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

    Scenarios Document

    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


    Christian presented:

    Looking at Requirements:
    Decided to not start from mechanisms
    Instead, start from applications
    Look at 4 types of requirements
    Connectivity & addresses

    Local Applications:
    Local addresses
    Typically ad hoc.
    Example: SLP
    Isolation of local traffic from the Internet.

    Client Applications:
    Global addresses, or possibly relay.
    Access to a DNS resolver.
    In some cases, address to name mapping is required.
    Isolation of local traffic from the Internet.
    Privacy of the client.

    Global addresses, stable during a session
    Typically ad hoc.
    Restrict communication to authorized peers.
    Protect local applications
    Possibly, privacy requirement.

    Global addresses, stable enough for DNS publishing
    Publish DNS records for the server.
    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


    Cleve presented:

    Design team members:
    Randy Bush
    Ron da Silva
    Gerard Gastaud
    Vijay Gill
    Cleveland Mickles
    Margaret Wasserman

    Broadband HFC/Coax
    Broadband DSL
    Narrowband Dialup
    Ethernet to the Home/Home Networking
    Network Management

    CPE (router, modem, pc, gateway, appliance, etc)
    EGP ( if applicable)
    Traffic Engineering
    Intrusion Detection
    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


    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 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
    <No Draft Available>


    Christian presented "Transition mechanisms for unmanaged scope networks":

    How come IPv6 is not there yet?
    Need upfront investment, stacks, etc.
    Similar to Y2K, 32 bit vs. “clean address type”
    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


    Alain presented an applicability statement for the Interaction draft:

    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


    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.


    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


    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

    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


    Francois presented "Operational Environments and Transition Scenarios for 'Connecting IPv6 Islands across IPv4 Clouds with BGP'":

    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.

    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

    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


    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.



    Transition requirements of unmanaged scope networks
    NG Transition WG
    IPv6 Transition Solutions for 3GPP Networks
    Transition mechanisms for unmanaged scope networks
    Draft-ietf-ngtrans-interaction-01 Applicability statement
    Dual Stack Transition Mechanism
    ISATAP Applicability
    Operational Environments and Transition Scenarios for 'Connecting IPv6 Islands across IPv4 Clouds with BGP'
    Introducing IPv6-only in the Internet: Balkanisation or Translation?