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