2.4.9 Next Generation Transition (ngtrans)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99

Chair(s):

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.

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.

Done

  

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

Done

  

Start conversion of 6bone to Aggregatable Unicast Address Format

Nov 97

  

Testing starts on new Aggregatable Unicast Address Format

Done

  

RFC 2471 formalizes IPv6 Testing Address Allocation

Done

  

Hold Interim meeting in Grenoble

Done

  

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

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1933

PS

Transition Mechanisms for IPv6 Hosts and Routers

RFC2185

 

Routing Aspects of IPv6 Transition

RFC2546

 

6Bone Routing Practice

Current Meeting Report

Minutes of NGtrans WG Meeting
8 November 1999
Washington DC IETF46

Chairs:

This ngtrans meeting reported by Alain Durand, Bob Fink and Tony Hain.
Attendance was estimated as 200+ (didn't actually count the names).

Alain Durand chaired 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>

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>

Agenda

Tokyo meeting network configuration - Jun-ichiro itojun Hagino

BSD Update - Jun-ichiro itojun Hagino

NGtrans Project Status - Bob Fink

6bone Prequalification for Address Prefix Allocation (6papa-00) - Bob Fink

Transition strategy for transition documentation - Alain Durand

6to4 (6to4-03) - Brian Carpenter

DSTM (dstm-00) - Jim Bound

Tunnel Broker (broker-02) - Ivano Guardini

Tunnel setup protocol - Marc Blanchet

Bump-In-the-Stack (bis-00) - Kazuaki Tsuchiya

IPv6 Operational Topics Meeting (minutes attached at end of these minutes)

Tokyo meeting network configuration - Jun-ichiro itojun Hagino

Itojun described the Tokyo IPng Interim WG meeting network configuration. This network was an IPv6 only network with four IPv6 prefixes advertised and three native IPv6 connections (NTT, IIJ, WIDE), plus an IPv6 to IPv4 translator. Statistics of the meeting's network use are:

80+ attendees
20+ nodes (= IPv6 nodes) in user segment
100 times more IPv6 traffic than IPv4 traffic!
1627 translated TCP connection
878 http, 846 SSL, 88 pop3, 46 telnet, 32 ssh, 16 smtp, 5 ftp
3ffe:501:0:18aa::x.y.z.u gets translated to x.y.z.u
DNS server side hack will automatically enable it

DNS needed IPv4 (root servers)

Src/dst selection, default router selection
Latter seems more important in this config

BSD Update - Jun-ichiro itojun Hagino

Itojun reported on the project to unify IPv6 for *BSD systems by consolidating the best parts of the three NRL, INRIA and KAME stacks. Due to incompatibilites beween the three the *BSD version it was decided to base the *BSD version on KAME, with inputs from NRL and INRIA. NRL and INRIA will also do future IPv6 experiments on KAME.

Status:

You will be able to buy KAME/FreeBSD-ready PC off the shelf!

<http://www.plathome.co.jp/>

NGtrans Project Status - Bob Fink

Bob gave a status review of NGtrans Projects based on the new ngtrans project status webpage that he will keep up-to-date as possible. It may be seen at:
<http://www.6bone.net/ngtrans/ngtrans_project-status.html>

Bob reported on the BT IPR notification and that the next step will be to follow IETF procedures with no discussion in ngtrans until that is done. These procedures call for requesting more information of the IPR holder, in particular details of the IPR and whether they will give low/no-cost licenses for its use. After all available information is in hand, the working group can decide whether or not to proceed with any project that may be affected based on this information.

6bone Prequalification for Address Prefix Allocation (6papa-00) - Bob Fink

Bob gave a brief overview of the 6papa-00 I-D which resulted from the IAB/IANA/RIR IPv6 Prefix Allocation policy process when it was agreed to allow the 6bone as a prequalification process for address prefix allocation as a part of the RIR bootstrap process. See:
<http://www.arin.net/regserv/ipv6/IPv6.txt>, section 4.1.1:

"... The requesting organization must demonstrate that it has experience with IPv6 through active participation in the 6bone project for at least six months, during which time it operated a pseudo-TLA (pTLA) for at least three months. The Regional IRs may require documentation of acceptable 6Bone routing policies and practice from the requesting organization."

Bob noted that the RIRs are asking him (as 6bone lead and ngtrans co-chair) to validate if a subTLA requestor meets the 6bone pTLA requirements, to which he factually replies, not saying whether the requestor should get a subTLA, just that they meet the requirements agreed to by the above policy and the 6bone's own pTLA rules.

Bob asked for consensus from the ngtrans/6bone community for the early RIR agreement by moving it into Informational RFC form and support for him to continue to handle the requests from the RIRs for this for now. Then in addition, help in setting up a 6bone steering group for this purpose so it's not just one person doing it.

As next steps, Bob will issue a cleaned up 6papa draft (-01) for comment on the ngtrans and 6bone lists, and probe the 6bone list re the formation of a 6bone steering group for RIR request recommendations process.

Transition strategy for transition documentation - Alain Durand

Alain presented his ideas on the structure of transition for purposes of writing a transition document. See:
<http://www.6bone.net/ngtrans/IETF46-WashDC/Durand-Strategy.ppt>

Jim Bound asked Alain to remove his comment in the slides about 'no dns trick', as he claimed that customers have asked for it. Alain said that this will be released as separate document, or added to roadmap, TBD.

The slides above show Jim's change.

6to4 (6to4-03) - Brian Carpenter

Brian reported on the substantive changes from -02:
<http://www.6bone.net/ngtrans/IETF46-WashDC/Carpenter-6to4.ppt>

Substantive Changes from -02

Issues:

Brian noted that comments on address selection are deferred until the outcome of IPng WG work on this.

A comment was made that Randy's concern about about routing loops be 'impossible' is too strong.

A comment was made that there needs to be clarity between text and potential implementations.

Jim Bound commented that either cover BGP fully or don't mention it at all.

Brian asked Jim when the rest of his group's comments would come on 6to4 as he had noted in the original comments he made that there would be more. Jim replied that 2 weeks.

Brian noted that he would like to have an additional co-author due to his and Keith Moore's time constraints.

Steve Deering that 6to4 is not a complete solution: dns, basic mechanisms, need to make sure doc is clear about applicatbility, terminology needs to be added, and may need additional specs for host implementations.

It was noted that several implementations were in progress.

Perry Metzger wanted *bsd as default stack implementation.

Jim Bound noted his company is moving into production mode to ship. ; linux focus

Steve Deering noted that boundary routers are the implementation target not host.

Bob Fink noted that a 6to4 relay was being agressivly worked for the 6tap.

DSTM (dstm-00) - Jim Bound

Jim Bound gave a high level overview of the DSTM-00 draft recently issued, noting that it is integrated DTI and AIIH.

Jim promised a new draft soon with reworked diagrams and other improvements. He will submit extensions to the DHCPv6 wg.

He hopes to be able to send DSTM to the IESG for PS in July, 2000.

Brian Carpenter asked Jim to describe the remaining relationship to dns? Jim said there is a gethostnymane call, the AIIH server returns a cname, which will be forwarded to site to the site dns which concatenates it.

Alain Durand asked will the dns part be 'required' to be DSTM. Jim responded that needs to be discussed.

Jim expressed his desire to have no translators be PS.

When asked if there are any implementations, Jim responded that there is one partially done that might be done in a few months.

Tunnel Broker (broker-02) - Ivano Guardini

Ivano gave a tunnel broker status report. See:
<http://www.6bone.net/ngtrans/IETF46-WashDC/Ivano-Tunnel-Broker.ppt>

Ivano asked for links to be placed on well know pages for the tunnel brokers so they can be easily found.

Perry Metzger said that he will put one on v6.org right after this meeting.

Tunnel setup protocol - Marc Blanchet

Marc presented his ideas for tunnel setup:
<http://www.6bone.net/ngtrans/IETF46-WashDC/Blanchet-tunnel-setup.ppt>

He noted that tunnel broker uses scripts which have many limitations. Peter Tattam's protocol have some limitations, one of them is the fact that the authentication scheme is fixed, and negociation between client and server is limited. His proposal is to extend the Peter Tattam's protocol.

Marc was encouraged to update the draft for submission as an ngtrans draft.

Jim Bound asked why not use DHCPv6. MArc was concerned about the time to resolve DHCPv6 and/or to add to it.

Marc was concerned about how a host can send dhcp queries over the IPv4 Internet without a dhcp relay.

Perry Metzger noted that you need to add a DHCPv6 request in v4 packet.

Erik Nordmark noted that, compared to DHCP, this proposal is useful because it takes care of authentication.

Introduction to IPv6 Transition (iit-02) - Henk Steenman

Henk noted that the -02 version included Tim Larder's independent draft, as well as adding examples & tools.

He expecgts completion at the next IETF.

Brian Carpenter noted that the Utrecht meeting recommendation wants ngtrans to address evolution from a NAT-based IPv4 world as well.

Alain Durand noted that one scenario had included NAT.

Perry Metzger noted that ISPs may be blocking some protocol types, which affects use of tunneling.

He noted that GRE over UDP as a tool needs a standard port number.

Bump-In-the-Stack (bis-00) - Kazuaki Tsuchiya

It was noted that bis-oo will be forwarded to the IESG after this IETF.

Kazuaki kindly abbreviated his presentation due to limited meeting time to speak of only the recent Toolnet6 Installation Workshop held during the IETF IPng Interim Meeting in Tokyo last month.

Toolnet6 is a transition tool based on the BIS draft. An early realease of the new version was given to participants, including in its features Stateless Address Autoconfiguration and a DNS resolver function via IPv6.

All participants succeeded in the installation of Toolnet6, which included 1 WinNT and 4 Win98 users.

Meeting adjourned.

IPv6 Operational Topics meeting
IETF46 in Wash DC
11 November 1999

Organizers:

Bob Fink <rlfink@lbl.gov>
Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>

This ngtrans meeting reported by Marc Blanchet and Bob Fink.
Attendance was estimated as 75-100.

Bob Fink chaired the meeting.

This meeting is actually part of the ngtrans/6bone activity, but designed to focus a little more on general operational topics beyond just the 6bone, e.g., 6REN and other early production IPv6 nets, hence the title "IPv6 Ops Topics". Bob Fink asked attendees if they had any preference as to how this meeting be held in future IETFs. Matt Crawford suggested under the IEPG, to which Bob noted that he and Marc had given some IPv6 presentations at at this IETF, but was not sure this was the best time as there is limited attendance on Sundays.

Zombie routes in 6bone

Ikuo Nakagawa and Kunihiro Ishiguro spoke on the phenomenon they called Zombie routes, which are non-aggregated routes that happened to be announced from somewhere, but not actually the neighbor forwarding them, and they are not even in the ASpath.

The behavior is that the originator has announced once, but no more announce it, but someone propagates infinitely. It is most liekly a bug in some routing code. To fix one has to find which site and then find which code they run and then upgrade ASAP.

Marc Blanchet noted that we should not fingerpoint at people, rather we should try to collaborate, as we always have on the 6bone.

Francis Dupont pointed out the need to move to the latest BGP4+ draft.

Ivano Guardini commented that aggregration has to be fixed as it is currently very poor.

Rob Rockell commented that most problems can be fixed by filtering. He asked if we should do a draft on how to filter?

William Maton note that onecould use the registry and RPSL to help filtering.

6bone Registry

David Kessens noted that he would like to soon provide a web interface to help people filtering in config files, which is work that Marc Blanchet and the Viagenie folk have done.

Joao Damas, RIPE NCC, noted that the inet6num object is used by RIPE-NCC and APNIC, but not ARIN at this time.

David Kessens noted that a subgroup of db-rpsl works on the ipv6 features in the current registry.

In reference to keeping RIR ipv6num data commonly available in the 6bone registry, David said he will do a script to automatically fetch v6 objects from the RIR registries.

Alain Durand commented that if we provide tools for filtering, then people will be interested in updating their objects.

Wilfried Woeber commented that instead of throwing away problems by upgrading software, we should fix the problems.

WIDE IPv6 addressing architecture

Kengo Nagahashi <kenken@wide.ad.jp> presented an overview of the WIDE IPv6 addressing architecture.

The WIDE production subTLA (2001:200::/35) has been divided into 2 spaces:

Use policies are:

6PAPA

Bob Fink noted that he had written the 6papa-00 I-D (under ngtrans) to formalize the RIR-6bone pre-qualification process. An updated version will follow soon which will be then sent to WG last call for forwarding to the IESG as an Informational RFC.

NSPIXP-6 v6 exchange in Japan

Akiro Kato gave an overview of the NSPIXP-6 IPv6 exchange in Japan.

It was noted that there are v6-exchanges at:

PingERv6

Bob Fink briefly noted that the US Energy Research PingER (over IPv4) project lead by SLAC now supports IPv6. Ping statistics are gathered with extensive data basing, analysis and graphical display.

Bob asked people to send host addresses to be pinged, or ping sources, as had been previously announced on the 6bone list.

Slides

Tunnel setup protocol
draft-ietf-ngtrans-6to4-03.txt
IPv6 transition strategy
IPv6 Tunnel Broker