2.4.7 Next Generation Transition (ngtrans)

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


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.



Submit Internet-Draft on Specifications of Transition Mechanisms for IPv6 Hosts and Routers.



Submit Internet-Draft of Transition Plan for the Internet.



Submit Internet-Draft on Specification of mechanisms for header translating routers.



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



Dec 98



Feb 99


Submit update to RFC1933 to IESG for consideration as a Proposed Standard

Feb 99


Hold Interim meeting in Grenoble


Request For Comments:







Transition Mechanisms for IPv6 Hosts and Routers



Routing Aspects of IPv6 Transition

Current Meeting Report

Minutes of NGtrans WG Meeting
17 March 1999
Minneapolis IETF

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).


0900-0905 context for this meeting (Grenoble, etc.) - Bob Fink
0905-1005 6to4 draft - Brian Carpenter/Keith Moore
1000-1015 additional topics (Shu NAKAMAE & Ivano Guardini)

1015-1100 planning roadmap documents - various
1100-1115 6bone hardening proposal - Bob Fink

1545-1800 Tools/mechanisms review for forwarding status (SIIT/AIIH/DTI/BIS/NAT-PT)

Context for meeting - Bob Fink

Bob then gave a short overview of the NGtrans interim meeting in Grenoble, and the context for the agenda for this meeting:

IPng, NGtrans and deployment (ipv6.org) met in Grenoble, France (thanks to Alain Durand and IMAG for a great meeting!!) 2-4 Feb 99. The primary ngtrans goal was to evaluate which transition tools/mechanisms to keep/discard. Consensus was we need them all at some time (and to make them informational not experimental for purposes of conveying more usability).

It was also agreed to develop Roadmap Documents to explain transition scenarios and how to use tools/mechanisms.

After Grenoble, the OPS ADs wanted NGtrans to make a best (last?) effort to move our tools/ mechanisms to standards track, only relying on other tracks on a case by case basis as appropriate.

There has been great interest in the 6to4 draft since Grenoble, indicating that we need to move it aggressively (or not) at this meeting.

The IPv6.org deployment group has expressed strong opinions to make 6bone good for early production deployment of ipv6 service. thus necessitating work on the 6bone to harden it for production use.

6to4 draft - Brian Carpenter/Keith Moore

Brian Carpenter gave a brief overview of the 6to4 concept (see Draft-ietf-ngtrans-6to4-01.txt). 6to4 uses the global IPv4 Internet as a link layer by assigning a TLA (e.g. 2010::/16) so that a full IPv4 address can be imbedded in the remainder of the external routing prefix (i.e., 2010:IPv4::/48). The IPv4 "NLA" is the IPv4 address of the site border router that supports 6to4 tunneling. The immediate benefit: sites get an IPv6 prefix without going to the registries, as well as automagically tunneling over the v4 cloud separating v6 sites.

Basic scenario: Site A & B are 6to4 only Relay scenario: Site A is 6to4 only, site B is multi-homed 6to4 & real v6 network

Routing at site A:
Site A: prefix is 2010:C001:0203::/48
Egress router has configured internal route to 6to4 encapsulator for 2010::/16
If site A wants to communicate to non 6to4 sites using site B as a relay, it has to configure a default route to relay router of site B.

Routing at site B:
Site prefixes are 2010:09FE:FDFC::/48 and e.g.; 2001:0600::/48
It advertise routes to 2001:0600::/48 and 2010::/16 into the global IPv6 routing.
Issue: what is the scope of those advertisements?
Question: can you advertise a longer prefix than 2010::/16?
Answer: Brian: don't do that.

Scope of 6to4 prefix adverts
- 2010:xxxx:xxxx::/48 are never advertised into IPv6 routing
- 2010::/16 is advertised by relay routers

MTU needs to be 1280 but may be 576, in that case, return packet too big ICMP. Encapsulation in IPv4 is as for regular tunnels with protocol type 41. IPv6 multicast is not mapped to IPv4 multicast. 6to4 should use v6 multicast routing.

IPv4 NAT? If you collocate the boundary router and the NAT box, it works, but it's no different than having a configured tunnel on the NAT box. Issue: what if there is a second (inner) IPv4 NAT?

Multicast support need to be worked out, help is required on that topic. We must avoid the Multicast over NBMA swamp.

Issue: source address selection
In case of multi-home site (6to4 and global IPv6), source address must be 6to4. However, source address selection is not specified in IPv6. For 6to4 it is sufficient for the sender to perform longest match across all source and all destination address. This will affect all hosts, some modification are needed.

Issue: you need a route to a default router. How do you find that route?
Suggestion: use IPv4 anycast
Comment: you can do similar things with tunnel brokers

Issue: not only does a relay router need a route to a native IPv6 router, but there must be a route in the other direction. This is just the same as a configured tunnel (but it is in effect a tunnel to a whole 6to4 cloud, not to a single site).

Question: if you have several sites behind the ingress 6to4 router? Things might get complex.
Comment: 6to4 is using IPv4 as NBMA as a large cloud and not as point to point links. It is having 2 level of routing which do not know each other.

Other comments were directed to the mailing list

The chair polled the sense of the room as to 6to4 being worth continuing. There appeared to be very near complete consensus to continue refining 6to4. More work is needed, however, before ngtrans can fully evaluate the proposal. Also, more illustrations and concrete examples of how 6to4 works are needed, and guidance on how 6to4 can be useful in the ngtrans toolkit.

An IPv6 visualization - Shu Nakamae

Shu Nakamae from Keio Univ. and the Wide project, presented his work for a 3D visualization unique to IPv6 that can show topology and hierarchy at once. Entries taken from a registry database, are output as a VRML graph.


Bob Fink has set a pointer to this work on the 6bone tools page.

Tunnel broker - Ivano Guardini

Ivano Guardini from CSELT presented the tunnel broker work that will be published soon as <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:

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

So what might hardening entail?

How to proceed

Other issues

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.