2.4.8 Next Generation Transition (ngtrans)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 27-May-99


Bob Fink <rlfink@lbl.gov>
Tony Hain <tonyhain@microsoft.com>
A. Durand <durand@imag.fr>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <wijnen@vnet.ibm.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

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

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.



Convert 6bone registry from ftp-based to RIPE-based



Start conversion of 6bone to Aggregatable Unicast Address Format

Nov 97


Testing starts on new Aggregatable Unicast Address Format



RFC 2471 formalizes IPv6 Testing Address Allocation



Hold Interim meeting in Grenoble



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

Jul 99


Submit modified RFC1933 to IESG for consideration as a Draft Standard

Dec 99


Submit 6to4/AIIH-DTI/NAT-PT/BIS I-Ds for IESG processing

Dec 99


Submit Roadmap I-Ds for IESG processing as Informational RFCs

Mar 00


Evaluate state of roadmap, tool and mechanism docs for further work


Request For Comments:







Transition Mechanisms for IPv6 Hosts and Routers



Routing Aspects of IPv6 Transition



6Bone Routing Practice

Current Meeting Report

Minutes of NGtrans WG Meeting
12-13 July 1999

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 ~250.

Alain Durand chaired this meeting as well as organized it due to Bob Fink's extended vacation preceding the meeting.

Administrative information:
Discussion ngtrans: <mailto: ngtrans@sunroof.eng.sun.com>
Subscribe ngtrans: <mailto: majordomo@sunroof.eng.sun.com> "subscribe ngtrans"
Archive ngtrans: (I'll replace with the newer archive)
Web site: <http://www.6bone.net/ngtrans.html>

Discussion 6bone: <mailto: 6bone@isi.edu>|
Subscribe 6bone: <mailto: majordomo@isi.edu> "subscribe 6bone"
Archive 6bone: (I'll replace with the newer archive)
Web site: <http://www.6bone.net>

Monday, July 12 at 1300-1500

6to4 - Brian Carpenter (1 hour)
- issues with draft-ietf-ngtrans-6to4-02.txt
- complex 6to4 scenario discussion
- next steps

Transition tools
- NAT-PT-06 - George Tsirtsis (5min)
- SOCKS -00 - Hiroshi KITAMURA (15min)
- BIS-01 & toolnet6 - Kazuaki Tsuchiya (15min)
- WIDE Camp - Yuji Sekiya
- Tunnel broker-00 - Ivano Guardini (5min)
- Transition of IP multicast - Ivano Guardini(10min)

Tuesday, July 13 at 0900-1130

Transition tools
- Transition mechanism-04 - Erik Nordmark (5min)
- SIIT-06 - Erik Nordmark (5min)
- Bump in the API - Erik Nordmark (5min)
- DTI/AIIH (DSTM-00) - Laurent Toutain (40min)

Roadmap documents & transition scenarios
- draft-ietf-ngtrans-introduction-to-ipv6-transition-01.txt -
- Ronald van der Pol (10min)
- ALG - Hiroshi KITAMURA (10min)
- Roadmap document - Dale Finkerson (5 min)

Unified BSD update - Itojun (1min)
6bone activites
- 6bone report - David Kessens (1min)
- 6bone hardening-00 - Rob Rockell (30min)
- 6TAP - Bob Fink (10min)

Registries report - Mirjam Kuehne (5min)

6to4-02 - Brian Carpenter

Brian Carpenter presented an overview of the new and quite improved 6to4 draft at <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-02.txt>. This presentation may be viewed at <http://www.6bone.net/ngtrans/oslo/6to4-02-prstn.ppt>. The most important enhancements over draft -01 are information on routing, multicast, relay routers and configured tunnels.

Brian then describe example scenarios on how 6to4 might work using cute little symboles too hard to recreate here (please refer to above presentation URL for these scenarios). The scenarios include simple relays, multiple relays, fragmented ipv4 worlds, fragmented ipv6 worlds, and net10 usage.

There was debate about how to find relay routers between native v4 and v6; there is a need to define a v4 anycast address for this.

Brian is expecting the ipng wg proposal for source selection (in the new multihoning proposals) to solve 6to4's problem of address selection.

Need to investigate issues in common with automated tunnels.

Need to define RFC1918 addresses as site local to avoid problem when NAT allocates v4 but does not support 6to4.

May need to split off as a BCP if too many operational issues arise.

A question on how complex 6to4 might be was answered by pointing out that if the goal is to connect a v6 site over the v4 net it isn't too complex. It does quit working when the v4 net is fragmented.

Randy Bush thinks that MBGP could carry routes between isolated 6to4 domains.

Brian feels 6to4 needs help from BGP4+ geeks

Randy Bush will provide routing comments for updated draft.

Keith Moore spoke on several issues (not all recorded here):

To transition each network level without affecting apps, a subtle point is that each level can have a v4 addr that is doing 6to4 within it.

If you have a NAT-like box with 6to4 in it, how does it know how to reach other v6 addresses?

6to4 has no impact on v6 protocol docs, if the new multihoming proposal goes thru (for address selection).

Should draft include text on why MUST is required on toxic waste dump (Brian needs to provide rationales)?

There was consensus on immediately assigning TLA 2010::/16 for 6to4 test use as it is being used already on the 6bone and this use will need to continue to grow as the 6to4 testing grows. Alain will poll the ngtrans mail list on this and if there is general consensus there as well will arrange to ask IANA for the assignment by early next week. (chair note: this probably will be an experimental allocation for now, similar to the 3FFE::/16 6bone allocation, at least until finalization of 6to4 as an Internet standard).

Agreed that a next draft is required before a last call can be done.

Agreed that might need to separate out operational stuff later.

NAT-PT-06 - George Tsirtsis

This draft is available at <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-natpt-06.txt>. There were no presentation slides.

The ONLY significant change from the previous draft(05) was that draft-06 includes text about A6 records, thus a WG last call should not be required.

NAT-PT relies on SIIT so will be processed when SIIT is forwarded.


This work has previously been discussed as two different drafts and has now been merged into one draft at <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-socks-gateway-01.txt>. This presentation may be viewed at <http://www.6bone.net/ngtrans/olso/socks-00-prstn.ppt>.

No protocol is proposed, two implementations exist and have been verified with no performance problems. The source code is available.

Hiroshi asked if it should be processed as Informational or Experimental.

Randy Bush (our fearless ngtrans A-D) agreed it should proceed as Informational.

BIS-00 & toolnet6 - Kazuaki Tsuchiya

This draft is available at <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-bis-00.txt>. This presentation may be viewed at <http://www.6bone.net/ngtrans/oslo/bis-00-prstn.ppt>. (Note this was previously called dual-stacks-host-01.)

It was noted that only binary (i.e., no source) of the BIS implemenation is available.

This work is now ready for wg last call as Informational. (Chair note: the current draft name is confusing and will be changed to bis.)

WIDE Camp - Yuji Sekiya

The recent March 1999 WIDE IPv6 Camp focusing on ipv6-only to ipv4-only interoperation was described. This presentation may be viewed at <http://www.sfc.wide.ad.jp/~sekiya/WideCamp>.

Tunnel broker draft-01 Ivano Gardino

This draft is available at <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-broker-00.txt>.

A few comments have been received on this drafts: the Broker Daemon proposal and Peter Tattam's Dynamic Tunnel Configuration Protocol.

The draft will be revised and needs more technical comments as well as help on English cleanup. Bob Fink agreed to work with Alain on this, then -01 will be issued for wg last call as Informational.

Transition of IP multicast - Ivano Guardini

The concept of a Multicast Session Control Center (MSCC) was presented. The key function for ipv6 is the bridging of multicast traffic between ipv4 and ipv6 networks.

This presentation may be viewed at <http://www.6bone.net/ngtrans/oslo/mscc-prstn.ppt>.

Transition mechanism-04 - Erik Nordmark

This draft is available at <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-04.txt>.

Changes since the -03 draft are:
- a note that TOS change work is underway that might in the future define a different behavior for the TOS byte when tunneling.
- a similar note for decapsulating

The IETF last call on -04 is done, and the IESG will now process it to replace the current Mechanism RFC at Proposed.

SIIT-06 - Erik Nordmark

This draft is available at <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-siit-06.txt>.

Changes since the -05 draft:
- added description on how to handle UDP/IPv4 packets with a zero UDP checksum (drop 1st fragment with zero checksum and log an event
- clarified the scope of the document to be a component of a solution
- updated ftp text to talk about EPRT/EPSV and RFC2428
- editorial fixes

Erik askes again if SIIT needs to be a complete solution:
- how to allocate addresses (same as AIIH/DTI)
- routing implications in site (tunneling v6 inv6)
- separate draft

Need more implementations

Agreed to forward it to the IESG as Proposed Standard along with NAT-PT and BIS that both rely on SIIT.

Bump in the API - Erik Nordmark

The concept of a Bump-in-the-API was presented.

Allow some unmodified socket apps to work without porting (but don't delay porting)

Idea implemented by Erik and Peter Tattam (Trumpet)

App operates on 32 bit tokens using existing socket API

Shim between app and protocol stack, DNS and address parsing, which maps between tokens and v6 addresses


- similar as NAT & BIS but IP level things work (IPsec, MibileIP) assumes v6 stack, IKE etc.
- intercepting inet_addr() and inet_ntoa() makes literal v6 addresses work except ':' sensitive parsers like browsers breaks for apps that parse and print not using these functions e.g., accessing s_addr content directly
- implementation specific how to intercept API might be possible on some platforms
- inet_ntoa() will return longer strings (46 vs 16) in theory apps can crash
- IPPROTO_IP options (source route, etc.) might not work implementation specific
- SOCK_RAW may or may not work
- apps passing socket descriptors to other processes unlikely to work

Erik asked what his next step should be:
- produce draft intended for Informational
- merge with BIS similar limitations but rather different actual mechanisms used

Question about OS's that don't support DLL's: will not work here.

Question about merging with BIS: looking at them as black box, a call happens and bits appear on the wire; what happens in the middle is the difference.

Consensus was to keep separate from BIS and gave a separate draft intended for Informational.

DTI/AIIH (DSTM-00) - Laurent Toutain

This draft is available at <http://www.ietf.org/internet-drafts/draft-toutain-dstm-00.txt>. This presentation may be viewed at <http://www.6bone.net/ngtrans/oslo/dstm-00-prstn.ppt>.

DSTM was previously the AIIH and DTI efforts integrated into one new design, thus a long presentation time was given for Laurent to give a thorough overview of the concepts of DSTM. Please refer to the above URL for this information.

There was concern expressed that DSTM isn't simple (Laurent said he though it is) and it needs to be simple in both concept and implementation to suceed.

The implemenation statusis that DTI has been implemented, but no AIIH has been done yet. Also, DHCPv6 is needed.

It was noted that apps do not need to change.

Erik Nordstom noted that the presentation helped him understand the concepts better and more of the details of the presentation need to be in included in the draft.

Erik also noted that the draft needs to outline the requirements and consraints on DNS implementations.

It was noted by Brian Carpenter that the IAB Network LAyer workshop strongly expresses no more changes to the DNS model.

Hossam Afifi noted that DSTM doesn't rely on the new A6 record.

The question was asked if DSTM should be a wg draft. Brian expressed concern about its compexity, but many felt it should still be a work item with a future decision regarding its forwarding status to be made when appropriate.

It was agreed that an enhanced wg drat version would be generated and further work done.

Roadmap documents & transition scenarios

Alain Durand introduced this part of the agenda noting that the Grenoble meeting resulted in ngtrans descriptive documents more recently called roadmap documents to explain or overview the transition process, transition scenarios to explain how various major transition scenarios would be handled with the ngtrans tools/mechanisms and a matrix of features for each of the tools/mechanisms.

The ngtrans chairs have agreed that Alain will oversee this overall documentation effort for ngtrans.

Dale Finkelson has agreed to be responsible for getting the roadmap/overview part done.

Alain has agreed to be responsible for getting the scenario part done.

Jim Bound has agreed to be responsible for getting the atrix part done, though he has recently been unable to participate (or attend this IETF) due to illness, this Alain will have to ascertain if Jim will still be involved.

The first presentation by Ronald van der Pol is a candidate for the roadmap document.

draft-ietf-ngtrans-introduction-to-ipv6-transition-01.txt - Ronald van der Pol

Ronald van der Pol (SURFnet) gave an overview of work done by Henk Steenman (AT&T), Wim Biemolt (SEC), Marijk Kaat (SEC) and himself.

This draft is available at <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-introduction-to-ipv6-transition-01.txt>. This presentation may be viewed at <http://www.6bone.net/ngtrans/oslo/intro-to-trans-01-prstn.ppt>.

This work, as mentioned above, is a candidate for the Roadmap overview document.

No comments to the presentation were made.

It will continue to be refined in conjunction with Dale Finkelson.


Hiroshi KITAMURA continued to describe Application Level Gateways as included in his SOCKS presentation (see URL above under SOCKS agenda item).

Randy Bush noted that there were IPsec problems with this type of approach.

It was noted that the server location needs to be know.

Roadmap document - Dale Finkelson

Dale noted that there were the three document sets to be generated as noted above. He noted that the Pol, Steenman, et al document was good and definitely a candidate for the Roadmap document. Dale has also submitted this document to non-IPv6 experience network managers for comments as to usefulness.

Work on this draft, as noted above, will continue.

Unified BSD update - Itojun

Itojun gave a brief report of the integration effort to unify the KAME (JP), INRIA (FR) and NRL (US) code for BSD unix.

The implementation will include a 6to4 implementation.

Itojun noted that everyone was too busy, and time zones and design differences have slowed progress.

They are close to a working kernel.

After a kernel is available getting the code out needs to start.

Help is needed, volunteers appreciated.

BSDs are starting to have bundled v6 support:

They will migrate to the unified version as soon as it is available.

More at the next IETF!

6bone report - David Kessens

Number of 6bone registry objects: current (previous)
ipv6-site: 412 (361)
inet6num: 281 (225)
person: 509 (428)
role: 32 (30)
mntner: 160 (135)

Number of countries: 42

3200 queries per day
8 updates per day

6bone hardening-00 - Rob Rockell

Rob Rockell reported on his efforts since the last IETF to develop a newer set of 6bone routing policies to "harden" the quality of 6bone routing.

The goals were to:
- improve the backbone routing stability
- provide for a stronger tested for new services and technology
- provide better quality connectivity to the 6bone

The work was based on the current 6bone routing policy nowpublished as an Informational RFC (see the 6bone homepage for the URL). This draft is available at <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-harden-00.txt>. This presentation may be viewed at <http://www.6bone.net/ngtrans/oslo/harden-00-prstn.ppt>.

This work will soon be circulated for 6bone comment, then ngtrans wg last call, and replace the current Informational RFC with a new one.

6TAP - Bob Fink

Bob Fink announced the 6TAP becoming operational. The 6TAP is a project of the 6REN effort <http://www.6ren.net> to provide a high quality peering point for native IPv6 networks at the Chicago NAP/StarTAP. Any IPv4 service provider with an attachment to the StartTAP/Chicago NAP can establish a native IPv6 ATM PVC to the 6TAP router and pickup all IPv6 routes (6bone, 6REN, etc.) as well as transit service.

The 6TAP is a joint effort of ESnet (who has provided the routing equipment and 7X24 operation) and CANARIE (who will be providing Route Server services).

Registries report - Mirjam Kuehne

The policy draft has been reissued with changes and is at IANA. IANA wants some reverse DNS info which is being done this week. It is hoped that IANA will tell the address registries to start allocating this week.

Chair's note: at the open plenary on wed., the announcement was made that the IANA had approved the policy draft, and given the initial address blocks to the registries so that IPv6 addresses could now be allocated upon request, by the registries per the new policy.