NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97
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 coordinate 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:
· A proposal for an IPv6 site database object
· Stateless IP/ICMP Translator (SIIT)
· Transition Mechanisms for IPv6 Hosts and Routers
· IPv6 routing issues
· No Network Address Translation (NNAT) for IPv6
Request For Comments:
RFC |
Status |
Title |
RFC1933 |
PS |
Transition Mechanisms for IPv6 Hosts and Routers |
RFC2185 |
Routing Aspects of IPv6 Transition | |
Minutes of the Next Generation Transition (ngtrans) WG
Chair: Bob Gilligan
Reported by: 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
I. Updates to RFC-1933 - Bob Gilligan
Updates to RFC-1933, the current Proposed Standard for Transition Mechanisms, were discussed to move it to Draft Status. An I-D was submitted for review at this meeting which contained, among other things, the following:
· Remove ::127.0.0.1 from discussion
· Eliminated 'raw IPv6 form' when sending IPv4 on link (implementation complexity, low gain)
· Added definitions for operating mode (dual stack needs to know if one is to be turned off)
· DNS resolver filtering/ordering options clarified
· IPv4 compatible used only with automatic tunneling
· 'v6 only' to 'v6 native'
· update MTU for new 1280 byte min MTU size
· miscellaneous clarifications in text
· Needs definition of link-local address for configured tunnels
· Automatic tunnel operational issues
· Source address selection when automatic tunnel
· Scope of IPv4-compatible address
Steve Deering noted that use of ND over pt-to-pt links will be discussed in the IPv6 group on Thursday.
Need to clearly define mechanism where configured tunnel is unidirectional with an automatic tunnel back. Issue is where to tunnel back since any router attached to v4 cloud can forward to avoid injecting v4 routing table into v6 cloud. Technique of using well-known v4 anycast as default tunnel is written up, but actual pattern not defined.
Discussion diverted into should we or not, allow asymmetric use of configured and auto tunnels.
Tony Hain commented that we are here to define the mechanisms, not define how they get used.
Discussion about how to document injection of v4 routes or not into v6. Should be a BCP from the 6bone implementers, since it is a topic for that deployment timeframe. Bob Fink said he would handle this one in consultation with Steve Deering.
Bob Gilligan will revise the document as an ID and send to the list.
II. NNAT - Jim Bound
A No NAT (NNAT) draft was presented in Munich - Jim Bound gave an overview and walkthrough of it here.
An IPv4 host requests DNS lookup, where a record is set as forwarder to NNAT server which sends DHCPv6 reconfig message which hosts MUST listen to, which is a temporary v4 address which allows building v4 compatible, then the NNAT server updates DNS and responds back to original requestor.
Open issues:
· DHCPv4 use and CNAME fix
· TTL cache
· Hybrid Stack Question
· Tunnels move to egress router
· Use of RFC 1183 records
· Authoritative DNS Server Response
· Update to lifetime for long running clients
· Default reassignment hold-down time
· NNAT name of the draft - open to discussion
Concern that temporary assignment may get out of sync if host to be reconfigured is not up at the time. Since the reconfig message is Ack'd, the language will be clarified to note that the NNAT server will not complete the DNS response if the Ack doesn't happen.
III. SIIT - Eric Nordmark
SIIT is a stateless header translator. It is not a single point of failure. Assumes mechanism like NNAT for temporary v4 addr. Transport-mode ESP works
Open issues:
· use v4 comp as address. Works as long as v6 cloud is clean.
· v4 traceroute
IV. NAT-PT - George Tsirtsis
This is v6 to v4 NAT to connect the clouds. It is a combination of NAT in outbound direction with NNAT in inbound direction. There is a minimal use of compatible/mapped address only v6 hosts need to do anything This breaks end-to-end principle...same issues as any NAT
This is a statefull version of SIIT.
George will work with Eric and Jim to see if a combined document is possible.
V. WIDE Translators - K. Tsuchiya, K. Yamamoto, T. Niinomi
Three translators developed by members of the WIDE project in Japan were presented.
NR60 Translator - K. Tuchiya
A modified DNS, address mapper and header translator used Straight NAT using DNS as resolver in both directions Implemented all on one node
FAITH - K. Yamamoto
· Header conversion has limitations
· Address conversion in legacy applications is difficult
· AH works when translator is trusted and rebuilds connection
Socks64 - T. Niinomi
· No DNS modification or address mapping management
· Application level gateway based on Socks 5
· Distributes fake v4 address for v6 end points
· Only modifies clients where other 2 modify infrastructure
These three translators represent actual implemented work. The chairs would like to thank the Wide project members for their willingness to come a long distance to share their ideas and extensive experience, and hope that it will continue.
Minutes of the ngtrans 6bone WG meeting
Chair: Bob Fink
Reported by: Ben Crosby, 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
Web site: http://www.6bone.net
Due to limited time in the main ngtrans session, the discussions on 6bone routing issues were handled in two lunchtime discussions on 10/11 December.
I. WIDE 6bone Status - K. Yamamoto
A brief status report of the WIDE 6bone project was given. Of special note is the broad participation of many research/educational and industry partners, and the development of many IPv6 implementations.
WIDE efforts started when, on June 9 1996, NAIST and Tokyo were connected via a 64kbps circuit using v6 and then on July 16, 1996 connection was made to the 6bone.
Currently 28 sites are connected to 4 backbone routers using RIPng. BGP4+ conversion is delayed until later in the month.
Future plans include linking the WIDE registry to the 6bone registry, creating an IPsec testbed, and of course BGP4+.
Again the Chairs want to thank the WIDE project members for sharing their extensive IPv6 experience.
II. 6bone Status - Bob Fink
A brief status report of the 6bone and the backbone conversion project was given.
· 206 sites, 30 countries
· 14 hosts and 13 router implementations (probably more at this time)
· 42 sites using aggregation address format
· Auto address delegation done via registry
· Auto map generation from registry daily courtesy of Andrew Scott of Univ. of Lancaster
· Reverse registry courtesy Bill Manning of ISI
· The backbone conversion to aggregation was accomplished on schedule
· Different strategies are emerging for sub-delegation
A brief overview of the inet6num registry object and how it relates to automatic IPv6 address delegation through the registry was given. This is a result of David Kessens' work at ISI.
Discussion of backbone routing policy issues was reserved for the two lunchtime meetings on the following two days (10/11 December).
III. Palo Alto IPv6 Exchange Point - Stephen Stuart
The new PAix IPv6 exchange point was described. A LAN switch has been devoted to native IPv6 transported in the PAix, with DIGITAL-CA, UUNET-UK and NWNET currently peering across it. Stephen encouraged others interested and able to secure rack space in the exchange to participate.
IV. CAIRN 6bone Report - Suresh
CAIRN is a network testbed funded by DARPA. Currently CAIRN's 6bone peering is done with NRL. Future peering is planned with University College London, PAix, and UUNET-UK. The transatlantic link will be native IPv6 peering over T1.
V. UK Status: Ben Crosby
An overview of the current IPv6 links in the UK was given. It was noted that there is a move to native links to janet, and to the University of Southampton.
VI. 6bone Routing Issues I-D - Alain Durand
An early draft outline of 6bone Routing Issues was presented and discussed in greater detail. The following is an outline of the topics covered:
· Identify all special cases
· Link local prefixes MUST NOT be advertised
· Site local only within a site - but what is a site? Should refer IPngwg work on that topic
· Loopback address and unspecified MUST NOT be advertised
· Multicast prefixes - should they be advertised in BGP 4+? Decided that they SHOULD / MUST NOT be advertised
· ipv4 mapped addresses
· Wait on the decisions from NGtrans on "ipv4 translatable" addresses
· This applies only to backbone
· The draft should specify for each section if it applies to all routers or only to backbone routers
· ipv4 compatible SHOULD NOT be advertised on 6bone
· Perhaps they should be banned
· Suggestion that they should only be used on tunnels
· Be careful in case there is a good reason to use them in the future
· Advertise some compatible bridges using a ::/96
· NEW SERVICE
· General consensus not on the backbone
· Dimitri Haskin wants this to happen automatically
· Auto tunnels don't need to have addresses advertised?
· One router to provide auto tunneling ?
· Suggest that this is handled by the IGP ?
· ACTION - Bob to send the idea to the mailing list.
· No cases in which you would accept something that you wouldn't send on
· Stephen Stuart - liberal in receive, but careful in sending
· Alain Durand - Ok to receive, but be careful on what you put on your routing table
· What happens with prefixes that don't yet exist - e.g., not 2000::/8
· Routes SHOULD be discarded
· Aggregation SHOULD be mandatory at every level - SLA, NLA, TLA
· Backbone routers MUST be default free
· Sites MAY have a default route
· Tunnels - prefix length? Which address space? DMZ?
· Point to point tunnels could use a /128
· Hardware implementation problem ? (Some refuse to use /128 prefixes)
· Point about the use of /128 - BGP 4+ problems due to not sharing subnet
· Dimitri says use link local but this raises next hop routing problems
· Then routers automatically change into Site level ?
· Routing entry in IGP to support the /128 ?
· This is an IDR wg issue, not a 6bone one.
· Tunnel meshing/transit issues
· All pTLAs MUST advertise all pTLA routes to/from each other
· For prefixes not in pTLA, should not advertise more specific routes e.g., never advertise less that /24
· Never aggregate for someone else (no proxy aggregation)
It was suggested making all the changes above and send out to the list as a draft BCP spec for the 6bone. The purpose would be to thus document our operating policies on the 6bone backbone.
VII. 6bone General Planning - Bob Fink
What to do next was discussed, given that the backbone has been converted to the new addressing. It was agreed that it was time to declare all 0ld (5f00) test addresses personna non grata - i.e., as of now we stop routing them.
The general registry issue was also addressed, i.e., a lot of sites' registry entries have not been touched since they were automatically generated. Bob proposed deleting entries not cleaned up, given some warning. It was agreed to discuss this on the mail list.
VIII. Multihomed Sites - Ben Crosby et al
The general multihoming issue, i.e., how to do it at all, was discussed. An example of 2 TLAs, with NLAs allocated in each TLA, and a site multihomed to the 2 NLAs was used for this. One idea was to inject a /48 site level for the given site in both NLA & TLA, which there was general agreement on, i.e., this does not scale!!!
A 2nd idea was to use limited multihoming - the problem is that this loses benefits of multihoming.
In further discussion on Thursday a way was discussed to attempt this by using mobility. Matt Crawford presented the concept during the Ipng meeting on Friday and there was enough interest that it will at least be pursued at the discussion level.
Note that this issue is only slightly different for IPv6 than it is for IPv4, and there needs to be more participation from IPv4 folk experienced in routing and multihoming to help move IPv6's multihoming issue along.
None Received