NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Chair(s):
Bob Fink <rlfink@lbl.gov>
Robert Gilligan <gilligan@freegate.com>
Tony Hain <tonyhain@microsoft.com>
Operations and Management Area Director(s):
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>
Operations and Management Area Advisor:
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Mailing Lists:
General Discussion:ngtrans@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: include
Archive: ftp://playground.sun.com/
Description of Working Group:
1. Define the processes by which networks can 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 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.
4. Coordinate deployment of an IPv6 testbed (known as the 6bone) to assist in the following:
- Creation of "practice and experience" informational documents that capture the experiences of those who have deployed, and are deploying, various IPv6 technologies.
- Feedback to various IETF IPv6-related activities, such as the IPng WG, based on testbed experience, where appropriate.
- Feedback to various IPv6 product developers, based on testbed experience, where appropriate.
- Development of mechanisms and procedures to aid in the transition to native IPv6, where appropriate.
- Development of mechanisms and procedures for sharing operational information to aid in transition and operation of global IPv6 routing.
5. The group will work closely with the main IPng Working Group (IPNGWG).
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. |
Jun 97 |
|
Convert 6bone registry from ftp-based to RIPE-based |
Oct 97 |
|
Start conversion of 6bone to Aggregatable Unicast Address Format |
Nov 97 |
|
Testing starts on new Aggregatable Unicast Address Format |
Internet-Drafts:
· Transition Mechanisms for IPv6 Hosts and Routers
· Network Address Translation - Protocol Translation (NAT-PT]
· Multihomed routing domain issues for IPv6 aggregatable scheme
Request For Comments:
RFC |
Status |
Title |
RFC1933 |
PS |
Transition Mechanisms for IPv6 Hosts and Routers |
RFC2185 |
Routing Aspects of IPv6 Transition | |
Minutes of NGTRANS WG Meeting - 25 August 1998 - Chicago IETF
Chairs: Bob Fink, Bob Gilligan and Tony Hain
Attendance: 218 signed in, more than 250 actually present
Marc Blanchet, of Viagenie, announced that he had placed a Cisco IPv6 capable router
on the IETF terminal room network for anyone's use to reach the 6bone. The KAME
project's IPv6 stack operating on a unix workstation in the terminal room was soon
operating over this router using ssh6 back to Japan. Congrats, folks!
Tony Hain discussed changes that will be made to the ngtrans charter to more accurately
reflect the actual work of the group, which is to develop tools and advice to aid in the
eventual transition to IPv6, and to make clear that it is not to specify timelines, plans and
policies for such a conversion.
Bob Fink discussed the processing of drafts beyond RFC 1933, noting that Experimental
will be the preferred status of tools such as SIIT and NAT-PT, and Informational for
practice/advice such as 6bone Routing Practice. The Experimental status will allow
various ideas to be tried out without full understanding of their final role in transition to IPv6.
Erik Nordmark presented recent changes from -00 to -01 for the "IPv6 Transitions
Mechanisms" draft <draft-ietf-ngtrans-mech-01.txt> for advancement to replace RFC 1933:
- Clarified that configured tunnels are unidirectional
- Clarified that IPv4-compatibleaddresses areassigned exclusively to nodes that support
automatic tunnels,i.e., that can receive such packets
- Added tect about formation of link-local addresses and non-use of ND: Zero padding
IPv4 address to form 64 bit token, ND and DAD can not be used on unidirectional
tunnels, and a bidirectional tunnel should accept and respond to NUD.
- Added restriction that decapsulated packets not be forwarded unless source address is
acceptable to the decapsulating router (decapsulate and forward without such checks
circumvents ingress filtering)
He also replayed previous changes made from RFC 1933 to draft -00:
- Deleted section on "compatible" IPv4 loopback address (::127.0.0.1) to not require
routers to filter that address
- Removed the use of IPv6 "raw form" when sending to IPv4-compatible on-link
destinations
- Revised DNS section to clarify resolver filtering and ordering options
- Made the IPv4-compatible addresses only apply to automatic tunneling
- Changed the term "IPv6-only addresses" to "IPv6-native address" per current usage
- Changed minimum MTU to 1280 bytes
- Revised IPv4-compatible address configuration section (5.2) to recognize multiple
interfaces
- Added discussion ofsource address selection when using IPv4-compatible addresses
- Added section on the combination of the default tunneling technique with hosts using
automatic tunneling
- Added prohibition against automatic tunneling to IPv4 broadcast or multicast
destinations
He also presented a few remaining issues to be resolved on the mailing list:
- Disallow the (asymmetric) use of default configured tunneling in one direction and
automatic tunneling in the reverse direction?
- Create a DHCPv4 option for configuring the tunnel destination for default configured
tunnels?
- Require that configured tunnels be biderectional?: Routing protocols need bidirectional,
makes ingress filtering easy, but different than tunnels over IPv6
- Require nodes to respond to NUD probes on bidirectional configured tunnels?
- Require nodes to send NUD probes on bidirectional configured tunnels?
(Omitted for roputer-router links as specified in RFC 1970)
As soon as Erik finishes these few remaining issues up a working group last call will be
done to approve sending the draft in to replace the current version, RFC 1933, which is
at Proposed Standard status.
Erik Nordmark presented recent changes from draft -01 to-02 for the "Stateless IP/ICMP
Translator (SIIT)" draft <draft-ietf-ngtrans-header-trans-02.txt> for advancement to
Experimental RFC:
- Clarified generating ICMP "TTL exceeded" when TTL or hoplimit reaches zero
- Added 1-1 mapping between IPv4 TOS and IPv6 Traffic Class
- Clarified that IPv4-mapped addresses are sent over wire
- Introduced the notion of IPv4-translated addresses separate from IPv4-mapped and
IPv4-compatible addresses:
0000:0000:0000:0000:FFFF:0000:(IPv4 address)
IPv4-compatible: IPv6/IPv4 node that supports automatic tunneling
IPv4-mapped: IPv4 node
IPv4-translated: IPv6 node
Example:
IPv6 IPv4
src ::ffff:0:129.0.0.1 src 129.0.0.1
dst ::0:ffff:192.2.2.2 dst 192.2.2.2
- Acquiring IPv4-translatable addresses out of scope
A working group last call for comments will now be made to send this in for processing
as Experimental.
George Tsirtsis presented recent changes from draft -01 to-02 for the "Network Address
Translation-Protocol Translation (NAT-PT)" draft <draft-ietf-ngtrans-natpt-02.txt> for
advancement to Experimental RFC.
- Various editorial changes
- Dropped collocated DNS/NAT section
- Added Applicability statement
- Added section on the impact of DNS-ALG to DNS-SEC
He then discussed several aspects of this proposal:
- Protocol Translation Limitations
- Impact of address translation - ALGs will be required for certain applications that
refer hosts by their IP addresses in payload
- Security between IPv6 and IPv4 - IPsec does not work across routing realms
- Impact of DNS-ALG on DNS-SEC - DNS traffic across the DNS-ALG can not be signed!
A working group last call for comments will now be made to send this in for processing
as Experimental.
Bertrand Buclin presented recent changes in the "6bone Routing Practices" draft
<draft-ietf-ngtrans-6bone-routing-01.txt> for advancement to Informational RFC. A
working group last call for comments will now be made to send this in for processing
as Informational. This draft represents the collective experience of 6bone participants
and lists best practice when operating over the 6bone between leaf and transit/backbone
sites.
Kazuaki Tsuchiya presented the Hitachi protocol exchange software for Windows95/98/NT4
systems based on the previous draft <draft-tsuchiya-ipv4-ipv6-translator-00.txt>. This
software is available now for use at <http://www.hitachi.co.jp/Prod/comp/network/pexv6-
e.htm>http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm. The draft of this work
should move forward through ngtrans to Experimental RFC. (Editor's note: subsequent to
the meeting it was agreed that the draft would be reworked to emphasize the implementation
experience relating to the mechanism previously described and to redescribe the mechanism
more accurately, not as a translator but rather as a technique known commonly as "bump-in-
the-stack". Also, the INET 98 "Deployment and Experiences of WIDE 6bone" URL was
supplied for more details on the various WIDE project's translators http://www.v6.wide.ad.jp/Papers/yamamoto/.)
David Kessens and Bob Fink gave a brief review of the status of the 6bone. There are
now 302 sites (was 240 last time) in 35 countries (was 32 last time) participating in the
6bone. There are now 47 backbone sites. There are currently about 1500 queries and 7
updates per day to the registry.
Greg Miller presented the vBNS 6bone plans, which basically is to provide native IPv6
transport across the US with IPv6 routers located in the Wash. DC, Chicago and San
Francisco Bay areas operating over OC3c links into the vBNS OC12c ATM network.
This will make a full native cross country IPv6 backbone available to the 6bone! See <http://www.vbns.net/IPv6/index.html>http://www.vbns.net/IPv6/index.html for more information.
Ivano Guardini, of CSELT/IT, presented his new ASpath-tree tool features for monitoring
BGP4+ routing inside the 6bone. These tools are up and available at <http://carmen.cselt.it/ipv6/bgp/index.htm>http://carmen.cselt.it/ipv6/bgp/index.htm.
ASpath-tree is being used by CSELT to monitor their routing configuration, and is being
used by several other pTLAs (ATT-LABS-EUROPE and BT-LABS) as well. Some of the
ASpath-tree features are: showing the BGP4+ routing tree, the last 24 hours of routing
history, changes in the routing tree, the odd routes report and the routing stability report.
Two updated drafts were then presented from previous work presented at the AATN BOF
at the previous IETF as a courtesy to that group as they could not easily schedule there
own meeting at this IETF.
Gabriel Montenegro presented the "Negotiated Address Reuse" draft <draft-montenegro-
aatn-nar-00.txt>. His talk is available at http://playground.sun.com/~gab/talks.html.
Negotiated Address Reuse proposes a border device that does allow end-to-end traffic
like IPSEC, IP tunnels (including Mobile IP and GRE tunnels) and QOS. It does this by
extending and complementing NAT and by introducing a control mechanism based on
SOCKS.
Michael Borella presented the "Distributed Network Address Translation" draft
<draft-borella-aatn-dnat-00.txt>.
It is most likely that work on these two drafts will continue elsewhere, unless they have
more ready transition application to IPv6 than currently observed.
None received.