2.4.9 Next Generation Transition (ngtrans)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.

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 Ngtrans-Tools Working Group

Chaired by (co-chair of ngtrans): Tony Hain, Microsoft

Reported by: ALain Durand and 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

Notes for the minutes courtesy of Alain Durand <durand@imag.fr>

Tools session: Various reports and plans were presented.

Brian Carpenter (IBM, UK) reported that the "6 over 4" draft will be refreshed with no changes.

Tony Hain (Microsoft, US) noted that the charter wording would be cleaned up to address concerns about the appearance we are mandating a scenario, and sent back to the list.

Jim Bound (Digital, US) presented the NNAT concept as a means of dynamically assigning v4 addresses as needed for primarily v6 nodes. Goal is to allow primarily v6 work groups to be deployed soon, without requiring a permanent address in the v4 Internet. Attaining that requires core applications be available over the v6 stack sooner. Also requires a tie between the DNS and some form of DHCP service with a pool of v4 addresses. Some applications may not need or want connections with the v4 Internet, and should not be required to implement the extra code.

Erik Nordmark (Sun, US) noted that the time to start thinking about translators to allow v4 only to v6 only has arrived. Some systems may arrive in the market as v6 only. Erik presented an overview of his ID (draft-ietf-ngtrans-header-trans-00.txt) and the rules for both directions. Tunneling v4 in v6 may be required for v4 compatible node within a v6 only routing system. Another option is a set of stateless translators that would convert the headers on the fly, but would not attempt v4 options.

Pedro Marques (Cisco, US) discussed ideas about transparent translation where hosts were unaware of the translator. Does not require tie to DNS and DHCP, and Cisco has a prototype running. He will submit an ID to the list for comment.

Dan Harrington (Lucent, US) reported that the update to the ID (draft-harrington-ngtrans-dhcp-option-00.txt) would reflect the assigned number from IANA.

ngtrans-6bone WG Meeting

Chaired by (co-chair of ngtrans): Bob Fink ESnet/LBNL

Reported by: 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

Agenda

I. Introduction and Agenda / Fink
II. Status of Action Items from Memphis / Fink
III. New 6bone Registry, Overview and Issues / Kessens
IV. Backbone Planning / Fink, Durand, Davies
V. Test plan for Aggregation-based Addressing / Fink
VI. Operational Issues on the 6bone / various
VII. Implementations in Use on the 6bone / Fink

I. Introduction and Agenda / Fink

Bob Fink convened the meeting, giving a status report on the 6bone.

There are now over 150 sites in 28 countries participating in the 6bone.

BGP4+ has been successfully deployed in the 6bone backbone, with three interoperable implementations (Cisco, Digital and Telebit), and is rapidly replacing RIPng, v6 and static routes in the backbone.

The 6bone now has its own domain, 6bone.net, through which the 6bone web pages and registry database is available.

The primary DNS for 6bone.net is located at LBNL, and the secondary name servers are at RIPE an APNIC.

The 6bone web pages are now available at: http://www.6bone.net

The mail list is available by sending email to: majordomo@isi.edu with subscribe 6bone in the body of the message.

The agenda was accepted without comment.

II. Status of Action Items from Memphis / Fink

Bob Fink reviewed the status of 6bone action items from the Memphis IETF.

2.1 CAIRN Backbone Proposal - Allison Mankin

Allison Mankin will readdress this issue at the December meeting.

2.2 RFC1987 changes to use virtual IPv6 provide ID - Hsin Fang

Hsin Fang removed this item from further consideration as the new Test Aggregation-based addressing plan supercedes it.

2.3 Aggregation-based Addressing structure for the 6bone - Bob Fink

Bob Fink will present his plan, as issued previously to the 6bone mail list, under agenda item 5. below.

2.4 I-D "Representing IPv6 Tunnels in RPSL" - David Meyer

This item is now closed as it has been implemented in the new 6bone registry.

2.5 New 6bone Registry - David Kessens

David Kessens will present the status of the registry under agenda item 3. below.

2.6 DNS for localized 6bone routing registry information - Bill Manning

Bill Manning would like to continue pursuing this idea. He earlier told the chair that he would come forward with a plan in the near future as to how he would like to proceed. The chair will close this item and await further submission from Bill before reactivating it.

2.7 Volunteer for I-D on requirements for new 6bone infrastructure - Bob Fink

Bob Fink reported that he has previously had several offers to help on such a draft. He noted that when the address conversion and backbone restructuring of the 6bone is done, he will reopen this action as appropriate.

2.8 Survey of host and router implementations on the 6bone - Bob Fink

Bob Fink will report on this survey under agenda item 7 below.

III. New 6bone Registry, Overview and Issues / Kessens

David Kessens reported that the conversion away from the old ftp-style 6bone registry to the new RIPE-style 6bone registry was completed in early June. He automatically mapped over all entries. The status of the new database is that there are 172 site objects and 130 persons registered. The query level is at ~200 per day. There are two mirror sites: whois.nic.fr and whois.ra.net,

David noted that his draft on the registry specification, draft-ietf-ngtrans-6bone-registry-01.txt has been updated and it would be processed as an Informational RFC.

David also noted that his registry was ready and capable of becoming an address registry for Aggregation-based Unicast addresses, if it was desirable.

IV. Backbone Planning / Fink, Durand, Davies

Bob Fink spoke about the need to restructure the backbone to minimize peering, as opposed to full mesh peering, and that the renumbering for aggregation-based addressing might be a good time to accomplish this. He also noted the importance of moving to BGP4+ peering.

Alain Durand, of the G6 project in France, spoke on plans to restructure the G6 collaborators for the coming readdressing required for the move to Aggregation-based addressing.

Guy Davies, of UUNET/UK, spoke on plans to restructure the UK academic 6bone backbone, both to cleanup the topology and ready for the readdressing required for the move to Aggregation-based addressing. He also noted the problems in the current 6bone backbone with sloppy peering arrangements and poor aggregation.

A major problem for the UK academic networks is that the 6bone backbone topology is too complex, there is not optimal aggregation, and there are bad RIPng problems. proposal: get academic sites to single homed OR use BGP4+ map of UK sites:

The graphs from Guy's presentation are available at: http://www.pipex.net/~guyd/6bone/IETF-presentation/

V. Test Plan for Aggregation-Based Addressing / Fink

Bob Fink noted that the most important work ahead of the 6bone is conversion to the new Test address format for Aggregation-based Global Unicast addressing that is about to move to experimental RFC status.

At a meeting later in the IETF week (Thursday at 11:30), those interested in the 6bone backbone planning met to discuss issues for the restructuring/cleanup of the backbone, as well as the address conversion. This meeting was reported in an email to the 6bone mail list that evening, and is reproduced as an addendum to these minutes.

Then Bob presented the plan for 6bone use of the Test address format, which is the material presented on the 6bone mail list in late May. This material is reproduced as an addendum to these minutes.

VI. Operational Issues on the 6bone / Various

Matt Crawford spoke on multihoming on the 6bone. He noted that a site multihome to the same provider needs only one prefix if that provider knows how to handle the extra route.

When connected to two or more providers it will (most likely) be necessary to have multiple prefixes.

How much interconnection for backbone sites? There is too much as of today. This is recognized as one topic for discussion as the backbone is restructured for the new addressing format.

VII. Implementations in use on the 6bone / Fink

Bob Fink reported ion his survey of IPv6 implementations.

This survey may not be completely accurate, however, it is fairly close having been circulated for comment on the 6bone mail list.

Host implementations in use on the 6bone are:

Digital OpenVMS Digital Unix
FTP Software Win95 Hitachi NR60
IBM AIX Inria BSD
Linux SICS HP-UX
Sun Solaris UNH for BSD
NRL for BSD WIDE Hydrangea for BSD
WIDE ZETA for BSD WIDE v6d

Host implementations in use on the 6bone are:

Bay Cisco
Digital Fujitsu LR550
Hitachi NR60 Inria BSD
Linux Merit MRT
NRL for BSD Telebit
WIDE Hydrangea for BSD WIDE ZETA for BSD
WIDE v6d

Addendum - Report of ad hoc 6bne Backbone Planning Meeting

6bone backbone planning meeting - 14 August 1997, Munich, DE.

Alain Durand held a BOF for those interested in 6bone backbone planning under the new test aggregation address format. There were 27 people in attendance.

Alain Durand (G6, FR) spoke on the need to minimize backbone tunnels to clean up routing. There were comments for this, explaining the reasons why it is needed at this time, and comments as to why we shouldn't worry about this.

Stephen Stuart (Digital-ca, US) spoke on reasons to cleanup peering, and to have multiple interconnect points for ISP TLA's.

Matt Crawford showed various multi-prefix scenarios.

There was a general consensus that there was a need to simplify the 6bone backbone topology.

Bob Fink (ESnet/LBNL, US) then led a discussion to generate a plan for readdressing and backbone restructuring. This discussion led to the following general agreements:

1. That we assign Testing pTLAs (i.e., pseudo TLAs assigned from the NLA1 field of the 6bone Test address allocation) from the Test Aggregation addressing I-D as follows:

Note: we started at 1 because Bob is nervous about using 0 :-)

2. That we establish October 1 as the start date for renumbering the backbone to testing aggregation addresses, with the goal of November 1 for coming online.

3. That all backbone sites will peer with BGP4+, and only BGP4+.

4. That the old testing addresses (RFC 1897) be discontinued on the backbone as early as October 1 (by sites already renumbered) and not later than November 1 when the newly addressed backbone is scheduled to be fully online.

5. That a call for new pTLA candidates be issued immediately, for inclusion in the October 1 renumbering/restructuring, where the criteria to be applied for inclusion is willingness and ability to actively participate in this timeframe, and demonstrated experience with IPv6 and the 6bone.

6. That a call for existing backbone sites (given a pTLA above) be made to decide themselves if they are able to participate in this renumbering/restructuring effort, and be encouraged to give back their pTLA assignment for now if they aren't able to participate. (Note: any site doing this can easily reapply at a later time.)

Addendum - Call for 6bone Backbone Participants email to 6bone List

Per the 6bone backbone ad hoc meeting in Munich, I am calling for those interested in being an early 6bone test pTLA (i.e., pseudo TLAs assigned from the NLA1 field of the 6bone Test address allocation) when the renumbering to the new Aggregation-based unicast address format is started on 1 October.

Requirements are willingness and ability to actively participate in this timeframe, and demonstrated experience with IPv6 and the 6bone.

Please send your requests to become a 6bone pTLA to the 6bone mail list with text sufficient to describe your interest and qualifications.

I will assign test pTLAs to all reasonable request at this time.

Thanks,
Bob

Slides

IPv4/IPv6 Stateless Header Translator
IPv6-only/IPv4-only Interoperability

Attendees List

go to list

Previous PageNext Page