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
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:
· Stateless IP/ICMP Translator (SIIT)
· Transition Mechanisms for IPv6 Hosts and Routers
· Network Address Translation - Protocol Translation (NAT-PT]
· Multihomed routing domain issues for IPv6 aggregatable scheme
· Assignment of IPv4 Global Addresses to IPv6 Hosts (AIIH)
· Dual Stack Hosts using the 'Bump-in-the-Stack' Technique
· Categorizing Translators between IPv4 and IPv6
· Dynamic Tunneling: A new method for the IPv4-IPv6 Transition
· Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels
· Transition Scenarios and Solutions
· A Guide to the Introduction of IPv6 in the IPv4 World
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 | |
Minutes of NGtrans WG Meeting
12-13 July 1999
Oslo IETF
Chairs:
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>
Agenda
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.
SOCKS-00 - Hiroshi KITAMURA
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
Limitations:
- 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.
ALG - Hiroshi KITAMURA
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:
- OpenBSD NRL
- BSDI NRL
- NetBSD KAME
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
AR AT AU BE BG BR CA CH CM CN CZ DE DK ES FI FR GB GR HK HU IE IT JP KR KZ LT MX NL NO NZ PL PT RO RU SE SG SI SK TW UA US ZA
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.