2.4.9 Next Generation Transition (ngtrans)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97


Bob Fink <rlfink@lbl.gov>
Robert Gilligan <gilligan@freegate.net>
Tony Hain <tonyhain@microsoft.com>

Operations and Management Area Director(s):

John Curran <jcurran@bbn.com>
Michael O'Dell <mo@uu.net>

Operations and Management Area Advisor:

Michael O'Dell <mo@uu.net>

Mailing Lists:

General Discussion:ngtrans@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: include
Archive: ftp://playground.sun.com/pub/ngtrans

Description of Working Group:

The purpose of this group is to design the mechanisms and procedures to support the transition of the Internet from IPv4 to IPv6.

The work of the group will fall into three areas:

1. Define the processes by which the Internet will 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 the Internet 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.

The group will use the Simple SIPP Transition (SST) overview document, draft-ietf-sipp-sst-overview-00.txt, as the starting point for its work on the IPv6 transition.

The group will work closely with the main IPng Working Group (IPNGWG) and the IPng Address Configuration Working Group (ADDRCONF). The group will coordinate with the TACIT group.

Goals and Milestones:

Dec 94


Submit Internet-Draft on General Overview of Transition.

Dec 94


Submit Internet-Draft of Transition Plan for the Internet.



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

Jan 95


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



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

Jul 95


Submit Specifications of Transition Mechanisms for IPv6 Hosts and Routers to IESG for consideration as a Draft Standard.


Request For Comments:







Transition Mechanisms for IPv6 Hosts and Routers



Routing Aspects of IPv6 Transition

Current Meeting Report

Minutes of the Next Generation Transition (ngtrans) WG

Chair: Bob Gilligan

Reported by: Tony Hain

Discussion: ngtrans@sunroof.eng.sun.com
Subscribe: majordomo@sunroof.eng.sun.com
Archive: ftp://playground.sun.com/pub/ngtrans
Chairs: Bob Fink rlfink@lbl.gov
Robert Gilligan gilligan@freegate.net
Tony Hain tonyhain@microsoft.com

I. Updates to RFC-1933 - Bob Gilligan

Updates to RFC-1933, the current Proposed Standard for Transition Mechanisms, were discussed to move it to Draft Status. An I-D was submitted for review at this meeting which contained, among other things, the following:

Steve Deering noted that use of ND over pt-to-pt links will be discussed in the IPv6 group on Thursday.

Need to clearly define mechanism where configured tunnel is unidirectional with an automatic tunnel back. Issue is where to tunnel back since any router attached to v4 cloud can forward to avoid injecting v4 routing table into v6 cloud. Technique of using well-known v4 anycast as default tunnel is written up, but actual pattern not defined.

Discussion diverted into should we or not, allow asymmetric use of configured and auto tunnels.

Tony Hain commented that we are here to define the mechanisms, not define how they get used.

Discussion about how to document injection of v4 routes or not into v6. Should be a BCP from the 6bone implementers, since it is a topic for that deployment timeframe. Bob Fink said he would handle this one in consultation with Steve Deering.

Bob Gilligan will revise the document as an ID and send to the list.

II. NNAT - Jim Bound

A No NAT (NNAT) draft was presented in Munich - Jim Bound gave an overview and walkthrough of it here.

An IPv4 host requests DNS lookup, where a record is set as forwarder to NNAT server which sends DHCPv6 reconfig message which hosts MUST listen to, which is a temporary v4 address which allows building v4 compatible, then the NNAT server updates DNS and responds back to original requestor.

Open issues:

Concern that temporary assignment may get out of sync if host to be reconfigured is not up at the time. Since the reconfig message is Ack'd, the language will be clarified to note that the NNAT server will not complete the DNS response if the Ack doesn't happen.

III. SIIT - Eric Nordmark

SIIT is a stateless header translator. It is not a single point of failure. Assumes mechanism like NNAT for temporary v4 addr. Transport-mode ESP works

Open issues:

IV. NAT-PT - George Tsirtsis

This is v6 to v4 NAT to connect the clouds. It is a combination of NAT in outbound direction with NNAT in inbound direction. There is a minimal use of compatible/mapped address only v6 hosts need to do anything This breaks end-to-end principle...same issues as any NAT

This is a statefull version of SIIT.

George will work with Eric and Jim to see if a combined document is possible.

V. WIDE Translators - K. Tsuchiya, K. Yamamoto, T. Niinomi

Three translators developed by members of the WIDE project in Japan were presented.

NR60 Translator - K. Tuchiya

A modified DNS, address mapper and header translator used Straight NAT using DNS as resolver in both directions Implemented all on one node

FAITH - K. Yamamoto

Socks64 - T. Niinomi

These three translators represent actual implemented work. The chairs would like to thank the Wide project members for their willingness to come a long distance to share their ideas and extensive experience, and hope that it will continue.

Minutes of the ngtrans 6bone WG meeting

Chair: Bob Fink

Reported by: Ben Crosby, ALain Durand and Bob Fink

Discussion: 6bone@isi.edu (6BONE Mailer)
Subscribe: majordomo@isi.edu "subscribe 6bone"
Archive: http://www.ipv6.nas.nasa.gov/6bone/
Chairs: Bob Fink rlfink@lbl.gov
Robert Gilligan gilligan@freegate.net
Tony Hain tonyhain@microsoft.com
Web site: http://www.6bone.net

Due to limited time in the main ngtrans session, the discussions on 6bone routing issues were handled in two lunchtime discussions on 10/11 December.

I. WIDE 6bone Status - K. Yamamoto

A brief status report of the WIDE 6bone project was given. Of special note is the broad participation of many research/educational and industry partners, and the development of many IPv6 implementations.

WIDE efforts started when, on June 9 1996, NAIST and Tokyo were connected via a 64kbps circuit using v6 and then on July 16, 1996 connection was made to the 6bone.

Currently 28 sites are connected to 4 backbone routers using RIPng. BGP4+ conversion is delayed until later in the month.

Future plans include linking the WIDE registry to the 6bone registry, creating an IPsec testbed, and of course BGP4+.

Again the Chairs want to thank the WIDE project members for sharing their extensive IPv6 experience.

II. 6bone Status - Bob Fink

A brief status report of the 6bone and the backbone conversion project was given.

A brief overview of the inet6num registry object and how it relates to automatic IPv6 address delegation through the registry was given. This is a result of David Kessens' work at ISI.

Discussion of backbone routing policy issues was reserved for the two lunchtime meetings on the following two days (10/11 December).

III. Palo Alto IPv6 Exchange Point - Stephen Stuart

The new PAix IPv6 exchange point was described. A LAN switch has been devoted to native IPv6 transported in the PAix, with DIGITAL-CA, UUNET-UK and NWNET currently peering across it. Stephen encouraged others interested and able to secure rack space in the exchange to participate.

IV. CAIRN 6bone Report - Suresh

CAIRN is a network testbed funded by DARPA. Currently CAIRN's 6bone peering is done with NRL. Future peering is planned with University College London, PAix, and UUNET-UK. The transatlantic link will be native IPv6 peering over T1.

V. UK Status: Ben Crosby

An overview of the current IPv6 links in the UK was given. It was noted that there is a move to native links to janet, and to the University of Southampton.

VI. 6bone Routing Issues I-D - Alain Durand

An early draft outline of 6bone Routing Issues was presented and discussed in greater detail. The following is an outline of the topics covered:

It was suggested making all the changes above and send out to the list as a draft BCP spec for the 6bone. The purpose would be to thus document our operating policies on the 6bone backbone.

VII. 6bone General Planning - Bob Fink

What to do next was discussed, given that the backbone has been converted to the new addressing. It was agreed that it was time to declare all 0ld (5f00) test addresses personna non grata - i.e., as of now we stop routing them.

The general registry issue was also addressed, i.e., a lot of sites' registry entries have not been touched since they were automatically generated. Bob proposed deleting entries not cleaned up, given some warning. It was agreed to discuss this on the mail list.

VIII. Multihomed Sites - Ben Crosby et al

The general multihoming issue, i.e., how to do it at all, was discussed. An example of 2 TLAs, with NLAs allocated in each TLA, and a site multihomed to the 2 NLAs was used for this. One idea was to inject a /48 site level for the given site in both NLA & TLA, which there was general agreement on, i.e., this does not scale!!!

A 2nd idea was to use limited multihoming - the problem is that this loses benefits of multihoming.

In further discussion on Thursday a way was discussed to attempt this by using mobility. Matt Crawford presented the concept during the Ipng meeting on Friday and there was enough interest that it will at least be pursued at the discussion level.

Note that this issue is only slightly different for IPv6 than it is for IPv4, and there needs to be more participation from IPv4 folk experienced in routing and multihoming to help move IPv6's multihoming issue along.


None Received

Attendees List

go to list

Previous PageNext Page