2.4.8 Next Generation Transition (ngtrans)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 22-Jan-98

Chair(s):

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 co-ordinate 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.

Done

  

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.

Done

  

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.

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 the Next Generation Transition (ngtrans) Working Group

Chairs: Bob Fink rlfink@lbl.gov
Robert Gilligan gilligan@freegate.com
Tony Hain tonyhain@microsoft.com

Reported by Bob Gilligan, Alain Durand and Bob Fink

ngtrans tools portion of meeting, chaired by Tony Hain

Discussion: ngtrans@sunroof.eng.sun.com
Subscribe: majordomo@sunroof.eng.sun.comá "subscribe ngtrans"
Archive: <ftp://playground.sun.com/pub/ngtrans>ftp://playground.sun.com/pub/ngtrans
Web site: <http://www.6bone.net/ngtrans.html>http://www.6bone.net/ngtrans.html

I. AIIH I-D- Jim Bound

Jim Bound gave an overview on his new Internet-Draft titled "Assignment of IPv4 Global Addresses to IPv6 hosts (AIIH)." Note that the acronym for this proposal has changed from NNAT to AIIH. This Internet-Draft replaces the earlier NNAT I-D.

The general objective of this proposal is to allow IPv6/IPv4 dual hosts configured with permanent global IPv6 and get temporary assignments of IPv4 global addresses to use when communicating with IPv4 hosts. This conserves the IPv4 address space since a small pool of global IPv4 addresses can be used by a larger number of IPv6/IPv4 hosts. This proposal does NOT employ header translation.

The proposal uses an "AIIH server" situated at the boundary between an IPv4 and an IPv6 cloud which operates both as a DNS and DHCP server. The AIIH server handles IPv4 DNS queries for IPv6/IPv4 hosts; assigns temporary IPv4 addresses to IPv6/IPv4 hosts, and manages tunnels to IPv6/IPv4 hosts. The IPv6/IPv4 hosts use DHCP to acquire their temporary IPv4 addresses. Two cases of communication are handled:

IPv4 packets between the IPv6/IPv4 host and the AIIH server can be carried in three forms:

More details on this proposal can be found in Jim's slides are located at:

<ftp://sipper.zk3-x.dec.com/pub/aatn_aiih_0498.zip>ftp://sipper.zk3-x.dec.com/pub/aatn_aiih_0498.zip
<ftp://sipper.zk3-x.dec.com/pub/ngtrans_aiih_0498.zip>ftp://sipper.zk3-x.dec.com/pub/ngtrans_aiih_0498.zip

A few questions were raised in the discussion of this proposal:

· Someone asked what specific changes an IPv6 host implementation would need to make in order to implement AIIH. Jim said that the primary change would be adding the facility to acquire an IPv4 address via DHCP when needed.

Jim would like feedback on this proposal now. He plans on releasing an updated version of this document before the Chicago IETF meeting.

II. NAT-PT I-D- George Tsirtsis & Pyda Srisuresh

George Tsirtsis and Pyda Srisuresh presented their new Internet-Draft titled "Network Address Translation - Protocol Translation (NAT-PT)". This is a revision of his earlier I-D of the same name. This draft adds a lot of new material and is about three times larger than the old version.

The general objective of this proposal is to allow areas of IPv6-only nodes, or IPv6/IPv4 dual nodes using only IPv6 addresses (no IPv4 addresses), to be deployed. This would allow sites to achieve the benefits of converting a site completely to IPv6, avoiding the need to maintain and administer IPv4 throughout the site.

The proposal employs techniques analogous to IPv4 NAT and port translation to allow IPv6 nodes to communicate with IPv4 nodes. It envisions NAT-PT translator nodes being deployed at the borders of IPv6 networks. The same technique could be used for stub dual IPv6/IPv4 networks, or stub IPv4 networks.

The NAT-PT translator nodes perform stateful header translation between IPv4 and IPv6, basing the translation on mappings between IPv6 addresses and IPv4 addresses that are generated on the fly (in response to traffic) or in response to DNS queries. The translators may manage pools of IPv4 addresses that are used for these mappings. Additionally, they may intercept and translate DNS queries and replies.

Changes to the I-D in this version include:

· Extended to allow the use of any prefix
· Added some new DNS interactions
· Added support for port translation
· Merged in the header translation mechanisms from Erik Nordmark's

III. SIIT Internet-Draft

The presentation walked through three different scenarios: one case of an IPv6 node initiating communication with an IPv4 node, and two cases of an IPv4 node initiating communication with an IPv6 node.

More details of the proposal can be found at:

ftp://ftp.labs.bt.com/pub/tsirtsg/41-IETF-NATPT.zip
http://www.livingston.com/Tech/IETF/natpt

Several issues were raised in the discussion that followed:

· Tony Hain pointed out that the document needs to discuss applicability of this technique (what types of sites could use it, what types should not), and also needs to discuss scaling issues.
· Brian Carpenter suggested that the group needs to consider how this technique would combine with the various other transition techniques, and API issues it raises.
· Concern was raised about the translation of DNS queries and replies. It was not clear whether this could be made to work with signed DNS queries/replies.

IV. SMTP issues in IPv4/v6 environment - Kazuhiko Yamamoto

A presentation of SMTP use in dual-stack environments was given by Kazu Yamamoto of the WIDE project. The WIDE project now has dual IPv4/IPv6 stack MTAs ready for testing, and thus experimented with registering MX records for IPv6 MTAs and what happens to IPv4 only MTA servers.

Results were that IPv4-only Sendmail/Bind has no problem with AAAA records(Sendmail 5.61 or later and Bind 4.8.3 or later), but when MX records were used which refer to A and AAAA records there were problems.

Further experimentation is planned and will be reported as appropriate.

(chair's note: this work probably falls more under the 6bone rather than the tools portion of ngtrans, thus will be scheduled there in the future.)

ngtrans 6bone portion of meeting, chaired by Bob Fink

Discussion: 6bone@isi.edu (6BONE Mailer)
Subscribe: majordomo@isi.edu "subscribe 6bone"
Archive: http://www.ipv6.nas.nasa.gov/6bone/
Web site: http://www.6bone.net

I. 6bone Status Report - Bob Fink and David Kessens

A brief status of the 6bone was given by Bob Fink of ESnet and David Kessens of ISI.

II. 6bone Routing Issues I-D - Bertrand Buclin and Alain Durand

A presentation was made of <draft-ietf-ngtrans-6bone-routing-issues-02.txt> was made. This I-D is based on the following routing principles:

The 6bone is a hierarchical network with backbone sites acting as pseudo TLAs (pTLAs) pseudo NLAs (pNLAs) providing transit services below pTLAs leaf sites

pTLAs MUST use BGP4+ between them

Multihomed sites SHOULD use BGP4+

Leaf sites MAY use default routing

Aggregation MUST be performed by border routers. Specially true for pTLAs.

There are a set of rules for

· Link Local prefixes
· Site Local prefixes
· Special case prefixes
· Multicast prefixes
· IPv4 mapped prefixes
· IPv4 compatible prefixes
· Undefined Unicast prefixes
· Default routes
· Aggregation and advertisement issues
· Inter site links

This document will be revised based on minor comments and recirculated.

III. 6bone Routing Reports and Related Issues - Masaki Hirabaru

A presentation of the new Merit 6bone Routing Reports was given by Masaki Hirabaru of Merit. These reports are collected by an MRT routing daemon and processed with the IPMA statistics tool. An email list for the daily reports is available that gives the size of the 6bone routing table, how many unique AS's are in use, how many BGP4+ announcements, withdrawals and unique routes there are, a list of the most poorly aggregated announcements and the top five most active prefixes. A route flap graph is also available.

Initial use of the tool shows too many routing changes for so few routes, thus indicating possible routing software/protocol problems. The reports can also be used to encourage aggregation and detect incorrect configurations. Feedback on, and use of, these reports is encouraged.

The reports can be subscribed to by sending email to majordomo@merit.edu with "subscribe 6bone-routing report" in the message. A hypermail archive is available at: http://www.merit.edu/mail.archives/html/6bone-routing-report

The Rout Flap Graph is at: http://www.merit.edu/mail.archives/~ipma/java/FlapGraph.html

IV. Multihomed Routing Domain Issues for IPv6 Aggregatable Scheme I-D - Francis Dupont

A presentation was made of current ideas for handling IPv6 site multihoming by Francis Dupont of Inria. A one-hour session on this topic was held in the hour preceding this ngtrans meeting. There are several different approaches possible to this problem, several of which share problems and solutions with IPv4.

Francis Dupont can provide multiprovider presentations in FIG, PostScript (A4) and GIF formats upon request: Francis Dupont <Francis.Dupont@inria.fr>

Bob Fink noted that this work may best be done under the Routing Area to encourage wider participation in the discussion and solutions for site multihoming, a path he has agreed to pursue with the head of the Routing Area.

V. 6bone Transit Through CAIRN - Maryann Maher

A brief overview was given of Allison Mankin's CAIRN native IPv6 6bone backbone proposal by Maryann Maher of ISI-East. In brief, the CAIRN project is willing to provide native IPv6 backbone service across the US, on a testing use basis, from CAIRN's points of prescence at LBL, ISI-West, MCI, ISI-East and UCL.

More information can be obtained from: <http://www.cairn.net/>http://www.cairn.net/

VI. IPSEC Proposition - Maryann Maher

Maryann Maher of ISI-East presented Allison Mankin's request to the 6bone project that IPSEC AUTH functionality be required in 6bone routers by the end of the year. Though there was a sense of agreement that it was appropriate for the 6bone to push the development and testing of security for routers, there was also a bit of confusion of just what was meant by this proposal. Bob Fink will request Allison to make a specific proposal that can be considered on the mail list.

VII. Win-NT IPv6 Public Source - Richard Draves

A short presentation of the new Windows NT IPv6 implementation by Microsoft Research was given by Richard Draves of Microsoft. He noted that this work was also being supported by Allison Mankin's group at ISI-East.

The source and binary release was made on March 24, 1988, and can be retrieved from:
<http://www.research.microsoft.com/msripv6>http://www.research.microsoft.com/msripv6

It is being released to promote research, education and testing, and is not intended for commercial use. There is no support for Windows 95 or 98. It is copyrighted and distributed under a license. Richard specifically encouraged those with troubles agreeing to the license to contact him to see if something mutually agreeable can be arranged.

Richard noted that, although it was released for NT version 4, he had been able to easily run it on NT version 5 as well, though he needed to make an installation procedure change.

Initially the following works:

· BaSic IPv6 header processing
· Neighbor Discovery
· Stateless autoconfiguration
· Partial ICMPv6 (basically ping support, but not error messages)
· Partial Multicast Listener Discovery
· Automatic and configure tunnels
· IPv6 over IPv4 per the Carpenter/Jung draft
· UDP and TCP over IPv6
· ping, traceroute, ttcp, ftp/ftpd, NetMon

What's missing:

· Security and Auth headers
· Mobility support
· Routing
· Applications as follows

VIII. pTLA Assignment Rules - Bob Fink

Delayed to an informal lunchtime meeting the day after the ngtrans meeting. When presented to the lunchtime group, there was no further comment on the pTLA assignment rules presented by Bob Fink of ESnet, other than that some folk are unwilling to say a site cannot do something. Bob noted that these rules have been presented before on the 6bone list and that he will continue to require new pTLA requestors to respond to the four criteria, to the list, so general sentiment can be heard. He will then make a decision based on the requestor's response and the sentiment expressed.

Bob encouraged those that do not like any particular policy he is enforcing to comment to him directly or to the list.

IX. Steps to Clean up the Backbone - Bob Fink

Delayed to an informal lunchtime meeting the day after the ngtrans meeting. Bob Fink of ESnet presented some of his problems and possible solutions about the 6bone backbone and its general cleanup:

Various problems

Various solutions

Alain Durand then spoke in favor of terminating pTLA sites that were not following various rules as expressed in the 6bone routing issues I-D. Several folk (Bertrand Buclin, Guy Davies and others) spoke against the harsh enforcement of rules as being inappropriate for the 6bone and its testing nature.

The general consensus seemed to be that report-based enforcement was more appropriate for the 6bone. Thus a set of rules would be agreed upon (say the Buclin/Durand draft) and reports would target those not complying.

It was also agreed that a 6bone-ops list made up of 6bone registry contacts would be a better place for reports than the main 6bone list. This would also help enforce the use of the registry for participating sites.

Bob agreed to publish to the 6bone list a general proposal for a way to start the cleanup process based on discussions from this session.

X. Tools to Help Clean Up the Backbone - Ivano Guardini - 10 minutes

Delayed to an informal lunchtime meeting the day after the ngtrans meeting. Ivano Guardini of CSELT gave a presentation of the new ASpath-tree tool that monitors BGP4+ routing, resulting from work of both Ivano and Paolo Fasano also of CSELT. This tool provides a graphical view of the BGP4+ routing tree towards the 6bone. The results are obtained by elaborating the AS path information available in the BGP4+ routing table of an IPv6 border router terminating BGP4+ capable tunnels. Results are presented automatically as html pages. See: <http://carmen.cselt.it/ipv6/bgp/index.html>http://carmen.cselt.it/ipv6/bgp/index.html

The tools was developed as a set of unix scripts in Perl 5.0, and tested on a Solaris 2.5.1 workstation. BGP4+ routes are collected using rsh commands, and the current script handles Cisco routers. Required inputs for the program are:

Ivano then showed various sample results from a CSELT viewpoint using ASpath-tree. For future work the following was given:

Ivano asked that other pTLA sites install the code, which is available at:
ftp://carmen/cselt.it/pub/ASpath-tree.tar.gz

Slides

Assignment of Ipv4 Global Addresses to Ipv6 Hosts

Attendees List

go to list