Minutes of NGtrans WG Meeting
17 July 2002, 0900-1130
Yokohama IETF-54
=======
Chairs:
Alain Durand <Alain.Durand@eng.sun.com>
Tony Hain <tony@tndh.net>
Margaret Wasserman <mrw@windriver.com>
Maragaret, Alain and Tony chaired the meeting. Bob Fink took the minutes.
Attendance was ~ 250-270.
===========================
Administrative information:
Discussion ngtrans: <ngtrans@sunroof.eng.sun.com>
Subscribe ngtrans: <majordomo@sunroof.eng.sun.com> "subscribe ngtrans"
Archive ngtrans: <http://ryouko.dgim.crc.ca/ipv6/ngtrans/>
Web site: <http://www.6bone.net/ngtrans>
WG Status:
<http://www.6bone.net/ngtrans/ngtrans_project-status.html>
Discussion 6bone: <6bone@isi.edu>
Subscribe 6bone: <majordomo@isi.edu> "subscribe 6bone"
Archive 6bone: <http://ryouko.dgim.crc.ca/ipv6/6bone/>
Web site: <http://www.6bone.net>
======
Agenda
---
Introduction and Agenda Bashing -- Chairs
---
Design Team Problem Statements/Scenarios
- Overview of Design Team Concept -- Tony Hain
- 3GPP Team -- Jonne Soininen
<draft-soininen-ngtrans-3gpp-cases-00.txt>
- Unmanaged Networks Team -- Christian Huitema
<draft-ietf-ngtrans-unmanscope-00.txt>
- ISP Team -- Cleve Mickles
<draft-mickles-ngtrans-isp-cases-00.txt>
---
Design Team Evaluations & Solutions
- 3GPP Transition Solutions -- Juha Wiljakka
<draft-wiljakka-3gpp-ipv6-transition-00.txt>
- Unmanaged Networks Evaluation -- Christian Huitema
<No Draft Available>
---
Transition Mechanism Applicability
- Transition Interactions -- Alain Baudot
<draft-ietf-ngtrans-interaction-01.txt>
- DSTM -- Jim Bound
<draft-ietf-ngtrans-dstm-overview-00.txt>
- ISATAP -- Tim Gleeson
<draft-ietf-ngtrans-isatap_scenario-00.txt>
- BGP Tunnels -- Francois Le Faucheur
<draft-lefaucheur-bgp-tunnel-transition-00.txt>
- NAT64/NAT46 Mechanism -- Alain Durand
<draft-durand-ngtrans-nat64-nat46-00.txt>
---
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>
SLIDES:
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/chairs.pdf>
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/chairs.ppt>
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
<http://www.ietf.org/internet-drafts/draft-soininen-ngtrans-3gpp-cases-00.txt>
SLIDES:
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/3gpp-Jonne.pdf>
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/3gpp-Jonne.ppt>
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
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-unmanscope-00.txt>
SLIDES:
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/unmanscope.pdf>
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/unmanscope.ppt>
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
<http://www.ietf.org/internet-drafts/draft-mickles-ngtrans-isp-cases-00.txt>
SLIDES:
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/mickles.pdf>
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/mickles.ppt>
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
<http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-transition-00.txt>
SLIDES:
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/mickles.pdf>
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/mickles.ppt>
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
<No Draft Available>
SLIDES:
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/unmanscope-mech.pdf>
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/unmanscope-mech.ppt>
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
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-interaction-01.txt>
SLIDES:
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/interaction.pdf>
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/interaction.ppt>
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
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-overview-00.txt>
SLIDES:
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/dstm.pdf>
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/dstm.ppt>
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
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-scenario-00.txt>
SLIDES:
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/isatap.pdf>
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/isatap.ppt>
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
<http://www.ietf.org/internet-drafts/draft-lefaucheur-bgp-tunnel-transition-00.txt>
SLIDES:
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/bgp-tunnel.pdf>
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/bgp-tunnel.ppt>
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
<http://www.ietf.org/internet-drafts/draft-durand-ngtrans-nat64-nat46-00.txt>
SLIDES:
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/nat64.pdf>
<http://www.6bone.net/ngtrans/IETF-54-Yokohama/nat64.ppt>
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