2.4.8 Next Generation Transition (ngtrans)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98

Chair(s):

Bob Fink <rlfink@lbl.gov>
Robert Gilligan <gilligan@freegate.com>
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: include
Archive: ftp://playground.sun.com/

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

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1933

PS

Transition Mechanisms for IPv6 Hosts and Routers

RFC2185

 

Routing Aspects of IPv6 Transition

Current Meeting Report

Minutes of NGtrans WG Meeting
8 December 1998
Orlando IETF

Chairs: Bob Fink fink@es.net

This ngtrans meeting reported by Alain Durand, Bob Fink and Tony Hain

Attendance: 170 signed in, estimated at 200 actually present

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 ngtrans: http://www.ipv6.nas.nasa.gov/6bone/
Web site: http://www.6bone.net

The chairs announced there will be a joint ngtrans/ipng interim meeting in the San Francisco area in early February for future planning of IETF IPv6 work. Further revisions to the ngtrans charter will await these discussions and due process in the WG. An announcement will be made to all the mail lists as soon as possible as to time and place.

Bob Gilligan has resigned as a co-chair of ngtrans due to other commitments. The continuing co-chairs would like to thank Bob for all his past IPv6 work, for the IPng WG and NGtrans WG. Newcomers should be aware that Bob helped craft IPv6's excellent Transition Mechanisms concepts and architecture.

Erik Nordmark from Sun concluded discussion on the I-D for replacement of RFC 1933 (Transition Mechanisms) and will proceed with a last call on this work. Items that will be included in the -01 to -02 version of the I-D are:

Will add clarification that configured tunnels can be unidirectional or bidirectional.

Will add description of bidirectional virtual links as another type of tunnel, and that nodes MUST respond to NUD probes on such links and SHOULD send NUD probes.

Will add reference to [6over4] work.

Will clarify that IPv4-compatible addresses are assigned exclusively to nodes that support automatic tunnels.

Will add text about formation of link-local addresses and use of Neighbor Discovery (ND not used on unidirectional links.)

Will add restriction that decapsulated packets not be forwarded unless the source address is acceptable to the decapsulating router.

Announced conclusion of last call for SIIT, which will now be forwarded for IESG processing as Experimental RFC.

Discussed WG last call for NAT-PT Experimental RFC forwarding with agreement that the author would cleanup references to, and duplication of, SIIT work. Then another last call will be done.

Announced conclusion of last call for 6bone Routing Practices, which will now be forwarded for IESG processing as Informational RFC.

Kazu Yamamoto from the Internet Initiative Japan gave a presentation on "Categorizing Translators Between IPv4 and IPv6" <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-translator-00.txt> (co-author is Munechika Simikawa from Hitachi). This work has value to the transition activity as an Informational RFC, so this will be explored with the authors.

Kazuaki Tsuchiya from Hitachi gave a presentation on "Dual Stack Hosts Using the Bump-in-the-Stack Technique" <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dual-stack-hosts-00.txt> (co-authors are Hidemitsu Higuchi and Yoshifumi Atarashi, also from Hitachi). This work allows IPv6 access to IPv4 applications through a translator installed in the target host. There was some question as to whether this work could progress as is, and whether it should be Informational or Experimental. This will be pursued on the mailing list by the author. The presentation is available at <http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm>

Hiroshi Kitamura from NEC and Shinji Kobayashi from Fujitsu jointly presented their work on "SOCKS5 based Transition Technology" which has been published as <draft-kitamura-socks-ipv6-trans-arch-00.txt> and as <draft-jinzaki-socks64-00.txt> (co-Author Akira Jinzaki from Fujitsu). This presentation is available at <http://www.v6.wide.ad.jp/Presentations/ietf43-ngtrans-socks/>. The three authors will now decide how to jointly prepare an I-D for processing either as Informational or Experimental RFC.

Hossam Afifi presented "A Dynamic Tunneling Interface"
<ftp://ftp.rennes.enst-bretagne.fr/pub/network/draft-toutain-dti-00.txt> (co-author Laurent Toutain from ENST-Bretagne). The motivation for the work was to make the smallest number of modifications to applications and components to communicate between IPv4 and IPv6 applications. IPv4 packets from the application are intercepted in a dynamic tunnel interface (dti) library to look in DNS to see if there is an IPv6 destination address, and a dynamic v4 in v6 tunnel is set up. The authors will submit their I-D as an ngtrans draft and circulate it on the mail list for comment. This work would presumably be eventually processed as an Experimental RFC.

Brian Carpenter (IBM) presented his and Keith Moore's (UTK) ideas for "A '624' TLA for Automatic Tunneling". The concept being that a special TLA would be allocated to indicate that the NLA 32-bit field below it contained the IPv4 address for an IPv6 over IPv4 tunnel endpoint to be used in communicating with the host so advertising that IPv6 address.

Presumably this would be done by hosts with no direct IPv6 connectivity between them. Thus if a TLA=624 was discovered by DNS lookup, IPv6 packets could be automatically encapsulated in IPv4 protocol 41 tunnels to the IPv4 address in the NLA portion of the TLA=624 address.

It is believed that there is no impact to IPv6 routing tables. When IPv4 goes away then these prefixes would also. One open issue identified is that you could not use these addresses for multicast.

Brian will formulate this into an I-D and circulate it.

Florent Parent presented his work on "Manipulating the 6bone Registry Objects Through a Web Interface", work which will integrated with David Kessens' IPv6 registry work. This effort should make the process of IPv6 sites managing and updating their objects much easier. This work is very helpful to all!

Bob Hinden discussed the Sub-TLA block allocation I-D (draft-ietf-ipngwg-iana-tla-00.txt) that was written jointly by the ngtrans and ipng WG chairs to advise the IANA on initial Sub-TLA allocations to APNIC, ARIN and RIPE-NCC. It is hoped that this I-D will allow the initial Sub-TLA registry assignment process to continue to successful conclusion in the first quarter of 1999.

David Kessens gave a brief update of the 6bone. There are now 51 6bone backbone sites and a total of 332 6bone sites in 39 countries. The registry is seeing 1700 queries and 8 updates a day. David announced that he has moved to Quest, and that Quest has agreed to have him move the 6bone registry from ISI to Quest. Thanks as always to David, and now Quest, for his fine efforts on IPv6 registries.

Ivano Guardini from CSELT gave an update of 6bone backbone routing activity and analysis by CSELT. Since the last IETF he has been collecting BGP4+ routing information provided by ASpath-tree. The BGP4+ routing table of their border router is downloaded and analyzed every 5 mins. Then 6bone routing behavior is measured in terms of number of advertised prefixes, overall route availability and overall route unstability.

These studies are showing increasing pTLA route availability, and an unstability of 2.5%. These studies are from CSELT's perspective, and Ivano would like others to join in analyzing this data from their sites perspective. Please contact him at ivano.guardini@cselt.it or Paolo Fasano at paolo.fasano@cselt.it.

The reports and other information is available through <http://carmen.cselt.it/ipv6/index.html>.

Thanks also to Ivano for his fine efforts on helping us understand the stability of routing on the 6bone.

Rob Rockell presented his views on the need to tighten 6bone backbone routing policing, and for everyone to follow the 6bone Routing Practices I-D rules.

He discussed why good 6bone routing policy is needed for proper IPv6 testing, to figure out multi-homing problems, and downstream routing policy concerns.

Policy is needed between pTLAs as addresses aren't portable, and routing is supposed to be simple and aggregated.

He strongly encouraged 6bone pTLA peers to accept only top-level aggregates (i.e., /24s) and reject anything more specific. Only accept more than your neighboring peer pTLA if agreed upon for providing transit for other pTLAs.

Also, pTLAs should not pass on things that cause trouble, don't waste the BGP and line sending unaggregated routes. Therefore, only send your aggregates and whatever other pTLAs you want to give transit for.

Do not allow more specific routes.

Only allow the space that you have delegated (to NLAs below you) to be announced up through you into your AS.

Allowing other TLA space through your routing domain disables the good value of the iPv6 addressing hierarchy.

Bob Fink from ESnet presented the new 6REN production IPv6 Research and Education Networks (RENs) initiative. The 6REN is not a network like the 6bone, rather a collaborative effort, sponsored and established by ESnet, to move RENs to production IPv6 service as soon as possible to allow momentum to be maintained in the release of IPv6 in production systems and routers, and to facilitate getting applications operational over IPv6.

The 6REN effort started in October with production native IPv6 over ATM peerings between ESnet, vBNS, CAIRN and CA*net2. As soon as the regional address registries can allocate Sub-TLAs to these networks (which they have requested), they will renumber out of 6bone space.

The 6ren is a no cost, open to all, initiative, including for-profit production IPv6 networks. It is not an IETF activity, though it will present information as appropriate to the ngtrans WG to assist in transition activities.

Slides

None received.