2.4.11 Next Generation Transition (ngtrans)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

Chair(s):

Bob Fink <rlfink@lbl.gov>
Tony Hain <tony@tndh.net>
Alain Durand <alain.durand@eng.sun.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.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:

Mar 01

  

Progress 6to4-multicast to PS

Mar 01

  

Decide to either merge 6to4-DSTM with DSTM or move it separately to Informational

Mar 01

  

Decide if BGP-tunnel is Informational or Experimental

Mar 01

  

Progress 6papa to Informational

Mar 01

  

Decide fate of ipv4survey as it has been deleted from I-D registry

Mar 01

  

Progress translator back to IESG for Informational

Mar 01

  

Decide how natreq4ipv6 should be processed

Mar 01

  

Progress socks-gateway back to IESG for Informational

Mar 01

  

Progress tcpudp-relay back to IESG for Informational

Mar 01

  

Decide what to do with personal draft hain-6to4-scaling

Mar 01

  

Decide what to do with personal draft tsao-mobileip-dualstack

Mar 01

  

Decide what to do with personal draft itojun-ipv6-local-experiment

Mar 01

  

Decide what to do with personal draft templin-v6v4compat

Mar 01

  

Decide what to do with personal draft durand-ngtrans-tunnel-endpoint

Mar 01

  

Decide what to do with personal draft tsuchiya-mtp

Aug 01

  

Progress 6to4-dns to either Informational or PS

Aug 01

  

Progress mimetype to PS

Aug 01

  

Progress DSTM to PS (keyed to DHCPv6 forwarding)

Aug 01

  

Progress hometun to Informational

Aug 01

  

Progress Transition description to Informational

Dec 01

  

Progress v4-over-mipv6 to Informational

Mar 02

  

Progress 6to4 to DS

Mar 02

  

Progress MECH to DS

Mar 02

  

Progress SIIT-DSTM to either Informational or PS

Aug 02

  

Progress NAT-PT to DS

Aug 02

  

Progress SIIT to DS

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC2185

  

Routing Aspects of IPv6 Transition

RFC2765

PS

Stateless IP/ICMP Translation Algorithm (SIIT)

RFC2766

PS

Network Address Translation - Protocol Translation (NAT-PT]

RFC2767

  

Dual Stack Hosts using the Bump-In-the-Stack Technique (BIS)

RFC2772

  

6Bone Backbone Routing Guidelines

RFC2893

PS

Transition Mechanisms for IPv6 Hosts and Routers

RFC2921

  

6BONE pTLA and pNLA Formats (pTLA)

RFC3053

  

IPv6 Tunnel Broker

RFC3056

PS

Connection of IPv6 Domains via IPv4 Clouds

Current Meeting Report

Minutes of NGtrans WG Meeting
19 & 22 March 2001
Minneapolis IETF-50

=======
Chairs:
Alain Durand <Alain.Durand@eng.sun.com>
Bob Fink <fink@es.net>
Tony Hain <tonyhain@microsoft.com>

This ngtrans meeting reported by Bob Fink.

Attendance was over 300.

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: <http://www.wcug.wwu.edu/lists/ngtrans/>
Web site: <http://www.6bone.net/ngtrans>

Discussion 6bone: <mailto: 6bone@isi.edu>
Subscribe 6bone: <mailto: majordomo@isi.edu> "subscribe 6bone"
Archive 6bone: <http://www.wcug.wwu.edu/lists/6bone/>
Web site: <http://www.6bone.net>

======
Agenda

======================
Monday meeting agenda:
----------------------
Agenda Bashing
NGtrans Project status - Bob Fink
Status of 6to4-Anycast processing - Tony Hain
6to4 scaling issues - Tony Hain
Status of IPv6 DNS Operational Needs sub-wg - Alain Durand
DSTM Update - Jim Bound
Using a Single IPv4 Global Address in DSTM - Myung-Ki Shin
Dual Stack Hosts using "Bump-in-the-API" - Seungyun Lee
IPv6 SMTP operational requirements - Itojun
Connecting IPv6 Nodes within IPv4 Sites - Fred Templin

========================
Thursday meeting agenda:
------------------------

Short term NAT requirements for IPv6 transition - Christian Huitema
MIME TYPE Definition for Tunnels (MIMETYPE) - Alain Durand
Integration of three drafts on IPv6 Mobility for a dual-stack model- Tsao & Tsirtsis
Viagenie web I/f to 6bone registry - Florent Parent
An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying - Kazuaki Tsuchiya
6to4 Well Known Address & 6to4-DSTM - Alain Durand
<draft-durand-ngtrans-6to4-well-known-address-00.txt>
A Guide to the Introduction of IPv6 in the IPv4 World - Alain Durand
Connecting IPv6 Domains across IPv4 Clouds with BGP - Dirk Ooms
Transitioning DNS from AAAA to A6 - Rob Austein
Transition mechanism interactions - Alain Baudot
6to4-DNS & 6overNAT issues - Keith Moore

===============
Monday meeting:

=============================================================================
NGtrans Project status - Bob Fink
-----------------------------------------------------------------------------

Bob Fink gave a brief status report of ngtrans projects. Project status is always available at:

<http://www.6bone.net/ngtrans/ngtrans_project-status.html>

Bob's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Fink-status.ppt>

---
ngtrans projects overview

Active Projects: 23 total; 12 on stds track, 4 already PS; 10 info rfc; 8 personal drafts pending wg review to be accepted as projects

Standard Track projects: | 6to4 | 6to4-ANYCAST | 6to4-DNS | 6to4-MULTICAST | DSTM | DSTMEXT1-AIIH | MECH | MIMETYPE | NAT-PT | NATREQ4IPv6 | SIIT |SIIT-DSTM |

Experimental RFC projects: none

Informational RFC projects: | 6to4-DSTM | BGP-TUNNEL | HOMETUN | IPv4SURVEY| TCPUDP-RELAY | TRANSITION | TRANSLATOR | v4-OVER-MIPv6 | IPv6-DNS-Ops-Needs | IPv6-SMTP-REQUIREMENT |

Testbed activity: 6BONE

Existing RFC's: 11 total; 4 at PS, 5 info rfc, 2 obsolete rfcs

Proposed Standards: | 6to4 (RFC3056) | NAT-PT (RFC2766) | SIIT (RFC2765) | Transition Mechanisms (RFC2893) |

Informational RFC's: | 6BONE ROUTING (RCF2772) | BIS (RFC2767) | BROKER (RFC3053) | pTLA (RFC2921) | Routing Aspects (RFC2185) |

Obsolete RFC's: | 6BONE ROUTING (RFC2546) | Transition Mechanisms (RFC1933) |

Completed Projects: 7 total| 6BONE ROUTING (RCF2772) | 6PAPA project terminated | BIS (RFC2767) | BROKER (RFC3053) | pTLA (RFC2921) | Routing Aspects (RFC2185) | SOCKS-GATEWAY (RFCxxxx) |

---
ngtrans projects status

MECH - at PS waiting on more experience to move to DS
SIIT - at PS waiting on more experience to move to DS
NAT-PT - at PS waiting on more experience to move to DS
6TO4 - at PS waiting on more experience to move to DS

BROKER - approved by IESG as info RFC3053 (Feb 01)
SOCKS-GATEWAY - approved by IESG for info RFC (Mar 01)

6TO4-ANYCAST - sent to IESG for PS, resolving comments (Feb 01)
6TO4-DNS-02 - waiting for wg comments on new draft (Mar 01)
6TO4-DSTM-00 - new draft, waiting further work (jan 01)
6TO4-MULTICAST - finished wg last call, wait new draft to forward to IESG (mar 01)
BGP-TUNNEL-00 - waiting further work
DSTM-04 - new draft, waiting to go to wg last call for PS forwarding (Feb 01)
DSTMEXT1-AIIH-00 - new project, waiting further work (Feb 01)
HOMETUN-01 - waiting for wg comments on recent draft

IPv4SURVEY-00 - waiting further work and next draft
IPv6-DNS-OPS-NEEDS - no draft yet, still in sub-wg (Mar 01)
IPv6-SMTP-REQUIREMENT-00 - new draft, waiting further work (Mar 01)
MIME-TYPE-02 - new draft, waiting to go to wg last call for PS forwarding (Mar 01)
NATREQ4IPv6-00 - new project, waiting further work (Feb 01)
SIIT-DSTM-00 - new draft, waiting further work (Feb 01)
TCPUDP-RELAY-02 - new draft, resolving IESG comments (Feb 01)
TRANSITION-06 - new draft, working further work (Mar 01)
TRANSLATOR-03 - wait next draft for resolving IESG comments for info rfc

6PAPA - terminated as project, OBE

6BONE- continuing to operate, continued efforts to harden backbone routing, continuing to assign pTLA's (50 countries now participating, 81 networks acting as pTLA backbones)

---
ngtrans new projects since last IETF

Short term NAT requirements for IPv6 transition - Huitema
Dual Stack Transition Mechanism Extensions-1 (AIIH) - Bound
IPv6 DNS Operational Needs - Alain Durand
IPv6 SMTP Requirement - Itojun

---
personal drafts not yet accepted as projects

An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (MTP) - Kazuaki Tsuchiya (Jul 2000)
<draft-tsuchiya-mtp-00.txt>

Guidelines for IPv6 local experiments - Itojun (Sep 2000)
<draft-itojun-ipv6-local-experiment-01.txt>

An IPv6-IPv4 Compatibility Aggregatable Global Unicast Address Format for Incremental Deployment of IPv6 Nodes Within Predominantly IPv4-based Intranets - Fred Templin (Sep 2000)
<draft-templin-ngtrans-v6v4compat-02.txt>

6to4 scaling issues - Tony Hain (Nov 2000)
<draft-hain-6to4-scaling-01.txt>

Using a Single IPv4 Global Address in DSTM - Myung-Ki Shin (Feb 2001)
<draft-shin-dstm-single-ipv4-00.txt>

Dual Stack Hosts using "Bump-in-the-API" (BIA) - Seungyun Lee (Feb 2001)
<draft-sylee-bia-00.txt>

6to4 Well Known Address - Alain Durand (Feb 2001)
<draft-durand-ngtrans-6to4-well-known-address-00.txt>

---
rules for creating new projects

- it fits within the wg charter
- it addresses a relevant issue in a timely fashion
- there is a large enough interest in the wg
- the issue has not been solved previously
- it does not break any existing protocol or code

---
current goals & milestones

Mar 01 Progress 6to4-multicast to PS
Mar 01 Decide to either merge 6to4-DSTM with DSTM or move it separately to Informational
Mar 01 Progress tcpudp-relay back to IESG for Informational
Mar 01 Progress translator back to IESG for Informational
Mar 01 Decide what to do with personal draft hain-6to4-scaling
Mar 01 Decide what to do with personal draft itojun-ipv6-local-experiment
Mar 01 Decide what to do with personal draft templin-v6v4compat
Mar 01 Decide what to do with personal draft tsuchiya-mtp
Mar 01 Decide what to do with personal draft durand-6to4-wka
Mar 01 Decide what to do with personal draft shin-dstm-single-ipv4
Mar 01 Decide what to do with personal draft sylee-bia
Mar 01 Decide what to do with personal draft motonori-ipv6-smtp

===========================================================
Status of 6to4-Anycast processing - Tony Hain
-----------------------------------------------------------

Tony Hain reported that during IESG review of 6to4-anycast there were comments fom both the IESG and IANA. They dealt with two basic issues. One, cleaning up the text and request for an anycast prefix so it did not specify the prefix length and stated what the need was. Two, whether a unique ASN was needed.

These issues are currently being addressed by the author, Tony Hain and Randy Bush.

===========================================================
6to4 scaling issues - Tony Hain
-----------------------------------------------------------

Tony Hain asked if there was interest in the working group in making the draft, available at:

<draft-hain-6to4-scaling-01.txt>

into an ngtrans project. The only response came from Brian Carpenter who felt strongly the work was valuable and should continue.

Tony said that he will review the draft to see if it can be kept as informational only by stripping out any specific standards type content, and report to the list what he will do with the draft.

===========================================================
Status of IPv6 DNS Operational Needs sub-wg - Alain Durand
-----------------------------------------------------------

Alain Durand reported on the status of the IPv6 DNS Operational Needs sub-wg, the new work item created at the last ngtrans meeting by Randy Bush to address the DNSOPS request to understand DNS transition requirements. Basically, there is a need to make the root able to support IPv6-access to the DNS to begin the transition of IPv6. Alain will release a draft report of the sub-wg in a few weeks.

Alain subsequently presented at DNSOPS and worked out an enhancement of his conclusion with Randy Bush, which was then presented at DNSEXT and at the
Thursday ngtrans session. The slides included here are the updated ones.
Alain's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Durand-dns-needs.ppt>

===========================================================
DSTM Update - Jim Bound
-----------------------------------------------------------

Jim Bound gave a DSTM update. The current draft is available at:

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-04.txt>

Jim's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Bound-dstm-04.pdf>

Jim still does not want to go to wg last call until dhcpv6 is released for its wg last call.

Alain Durand asked if Shin's work be included in dstm base spec. Jim said it was good work, but that he would have to review this.

===========================================================
Using a Single IPv4 Global Address in DSTM - Myung-Ki Shin
-----------------------------------------------------------

Myung-Ki Shin presented Using a Single IPv4 Global Address in DSTM, which is available at:

<http://www.ietf.org/internet-drafts/draft-shin-dstm-single-ipv4-00.txt>

Myung-Ki's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Shin-single-ipv4.ppt>

The motivation of this works is:

In order to allow a dual stack host to get an IPv4 global address, DHCPv6 is used. If the dual stack hosts which want to get IPv4 addresses increase at a time, a lot of IPv4 global address will be needed. When the pool of IPv4 addresses is exhausted, newer dual stack hosts cannot establish sessions with the outside IPv4 anymore. To increase the efficiency of using IPv4 addresses, it is proposed to add a new DHCPv6 option which provides a method to assign a single IPv4 global address with TCP/UDP port range to all dual stack hosts in a DSTM domain.

Requirements are:

DHCP Server - When a DHCPv6 Server receives an IPv4 Global Address with
Port Range Option in a DHCPv6 Request message, the server MUST allocate the range of port as well as an IPv4 address.

DHCP Client - When the Server supplies an IPv4 Global Address with Port
Range in the Reply, the Client MUST assign the port range to an interface as well as the address.

Border Router - In addition to the address association between IPv4 and IPv6, a border router MUST keep the port state.

In summary:

Add new DHCPv6 options to support a Single IPv4 Global Address with Port Range. This will allow for a maximum of 63K TCP and 63K UDP sessions. This proposed mechanism increases the utilization of IPv4 address when the pool of IPv4 addresses assigned in DHCPv6 for the purposes of dynamic allocation is exhausted.

Limitations are:

Client applications that do not insist on choosing their own source port.
Inbound traffic (from IPv4 only hosts outside the IPv6 domain) is restricted to one server per service.

Myung-Ki then asked if this should become an ngtrans project, and what relationship it might have w/DSTM.

Steve Deering noted that this approach was limited to only tcp and udp apps, many others exist and won't work.

Erik Nordmark asked how does dhcp server know how many ports to give client? Myung-Ki replied that it depends on dhcp server policy.

Jim Bound stated that he likes this idea, but there are technical questions to resolve offline, and that it probably should not be put in dstm.

===========================================================
Dual Stack Hosts using "Bump-in-the-API" (BIA) - Yong-Jin Kim
-----------------------------------------------------------

Yong-Jin Kim presented Dual Stack Hosts using "Bump-in-the-API", which is available at:

<http://www.ietf.org/internet-drafts/draft-sylee-bia-00.txt>

Yong-Jin's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Kim-BIA.ppt>

The basic concept was introduced at 45th IETF meeting (Oslo) by Erik Nordmark. It allows some unmodified socket apps to work without recompiling, and thus allows the dual stack hosts to communicate with other IPv6 hosts using existing IPv4 applications. The goal is the same as BIS (RFC 2767).

Socket API conversion

IPv4 socket API functions are translated into semantically the same IPv6 socket API functions and vice versa.
ICMP translation : it is possible to handle by intercepting the ICMP message using SOCK_RAW.

Internally assigned IPv4 addresses

The address spool consists of the unassigned IPv4 addresses (e.g., 0.0.0.0 ~ 0.0.0.255).
No potential collision with another use of the private address space

Implementation Specifics

How to intercept socket API functions?
Dynamic linkable libraries
Support the PRELOAD library functions (UNIX System V, e.g., Solaris, Linux, etc)
Support the User-Defined layered protocol (SPI from Windows 2000)

Limitations

does not support the IPv4 packets with option fields and IPv6 packets with option headers.
does not support the multicast functions.

ETRI Implementation

Platform: Windows 2000 with Microsoft IPv6 Technology Preview
The API translator was implemented by the SPI (Service Provider Interface) which allows user to make user-defined layered protocol as a dynamic link library.
Experimental Results:
Currently it works well with Internet Explorer for IPv4.
URL : <http://www.krv6.net/bia/> (will be available on April 2001)

Brian Carpenter asked if Yong-Jin thinks the set of problems are different than the nat approach.

Erik Nordmark noted that the only place where this is better than nat is ipsec, and that he implemented it several years ago and there is a set of problems associated with design choices on multi-user systems, e.g., how many private ipv4 number spaces, is it done in user or system space...

Brian Carpenter asked how big the code is and if it is open source.

Yong-Jin replied about 3000 lines of code, and that it is not yet open source.

Erik Nordmark noted that he didn't pursue a BIA draft as he wanted app writers to convert to the ipv6 api, and as BIA could fool people into thinking it might not be necessary, so he decided not to document it. The real message should be if you can't convert code (no source) then this may be ok, but all others should convert code, not use BIA.

Itojun agreed with Erik's point on message it gives to apps writers.

Alain Durand noted that the problem is that it is known to exist, and thus should be documented with appropriate disclaimers.

Jim Bound commented that if you do this, you are stuck with it forever.

Steve Deering made the meta comment that different platforms and different transition solutions, means diagnosing what is happening. That he is really concerned and wants to publish this with a "don't do this" disclaimer.

Alain noted that there is a new draft discussing interactions between transition mechanisms.

Consensus was to publish as a possible approach.

Christian Huitema commented that he thinks Steve is right, publish it as a don't do, but if we do too many info rfcs, an implementor may have to support this stuff forever.

Jim Bound wanted to publish it as something to be done when an app source code is unavailable, that it is a useful tool.

Erik Nordmark wanted to put a stong applicability statement in it.

It was agreed to accept BIA as a wg project, but have it include disclaimers.

===========================================================
IPv6 SMTP operational requirements - Itojun
-----------------------------------------------------------

Itojun presented IPv6 SMTP operational requirements, recently accepted as an ngtrans project, which is available at:

<http://www.ietf.org/internet-drafts/draft-motonori-ipv6-smtp-requirement-00.txt>

Itojun's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Itojun-ipv6-smtp.htm>

This draft give operational requirements for IPv6 SMTP, and IPv6 DNS MX records. The goal being a stable IPv6 email transport. Similar content was presented by Kazu, at a previous IETF, but not documented at that time.

Brian Carpenter noted that some types of numeric addressses could be a problem, but can't exclude them as you might want to send email when dns is down. He asked if local and site scope should be documented as meaningless.

Erik Nordmark asked if Itojun had looked for similarity in his approach to existing implementations. Itojun responded yes.

===========================================================
Connecting IPv6 Nodes within IPv4 Sites - Fred Templin
-----------------------------------------------------------

Fred Templin presented Connecting IPv6 Nodes within IPv4 Sites, which will soon be available at:

<http://www.ietf.org/internet-drafts/draft-templin-ngtrans-v6v4compat-02.txt>

Fred's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Templin-v6v4compat.ppt>

Fred noted that there had been a change in title and in the sending rule since the last draft.

From the Abstract of the draft:

This document specifies a method for connecting IPv6 hosts and routers (nodes) within predominantly IPv4-based sites. This method is based on an IPv6-IPv4 compatibility aggregatable global unicast address format (described herein) that embeds the IPv4 address of a node within the EUI-64 format interface identifier of an IPv6 address. This document assumes that, during the IPv4 to IPv6 co-existence and transition phase, many sites will deploy IPv6 incrementally within their IPv4 interior routing domains; especially those sites which have large and complex pre-existing IPv4 infrastructures. Within such sites, the address format and methods described in this document will enable IPv6 deployment for nodes that do not share a common multiple access datalink with an IPv6 gateway within their site.

While other works in progress in the NGTRANS working group propose mechanisms for assigning globally-unique IPv6 address prefixes to sites and methods for inter-domain routing between such sites, the approach outlined in this memo enables large-scale incremental deployment of IPv6 for nodes within a site's pre-existing IPv4 infrastructure without incurring aggregation scaling issues at the border gateways nor requiring site-wide deployment of special IPv4 services such as multicast. The approach proposed by this document supports IPv6 routing within both the site-local and global IPv6 routing domains as well as automatic IPv6 in IPv4 tunneling across portions of a site's IPv4 infrastructure which have no native IPv6 support. Moreover, this approach supports automatic tunneling within sites which use non globally-unique IPv4 address assignments, such as when Network Address Translation [NAT] is used.

Steve Deering asked if, when there are lots of hosts, and the router is down, will there be a storm of state creation? Fred felt that it would only be router solicitations.

Steve Deering noted that if a site doesn't do this, but if you don't hear a router advert from a neighbor, and then you start doing this it could be a problem. Fred replied that possible it could be handled by a counter of some sort.

Steve noted that this draft was modeling v4 site topology as nbma, as opposed to what 6over4 assumes, i.e., site-wide multicast.

Rich Draves stated there is danger discovery might extend beyond site boudary. Fred noted that borders might need to filter to handle this.

Rich noted that when he implemented this, normal routing code had no need of specific sending rules.

Steve thinks it is too complex.

Margaret Wasserman asked if the ipv4-address need be globally unique?

Jim Bound stated that he thinks this should be a project.

Dave Thaler thinks it could be useful, wants a good name for it other than "templin" addressing.

Tony Hain noted he had no problem with this draft being a wg project, but there were scaling and leaking issues that need to be addressed. He felt that it should be an experimental draft.

Steve Deering asked if Fred had thought about mcast. Fred replied that he had not gotten to it.

Steve noted that he was torn over this. He felt that it is useful to document, but if we do this, should deprecate 6over4. He would like ngtrans to make a choice between the two.

Christian Huuitema commented that this does solve a problem for sites that can't support native v6 or mcast.

Jim Bound thought that 6over4 was an orthogonal issue. if we supercede something, fine, but don't prejudge what a user can absorb. Different users want, and have, different problem solutions. This is a good draft, thus allow it.

Brian Carpenter agreed with Jim. However, he noted that more solutions add stack complexity. He also noted that the new draft on transition mechanism interactions is very important given the number of mechanisms ngtrans now has.

Randy Bush commented that the Internet puts the smarts at the edge and dumb in center. That this draft puts load on router, not on edge. Fredeplied that he had tabled router interception, as it's not a good way to go. Randy replied that this was good, don't put complexity in router.

Alain Durand asked if this should become a wg project. Consensus to do so.
It will be decided later what track, and what the name should be changed to.

[Note: subsequently it was agreed with the author and chairs that this draft will be called ISATAP and that it would be on Expermental RFC track.]

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-00.txt>

==================
Meeting adjourned
for Wednesday
==================

==================
Thursday meeting

===========================================================
Short term NAT requirements for IPv6 transition - Christian Huitema
-----------------------------------------------------------

Christian Huitema presented Short term NAT requirements for IPv6 transition, which is available at:

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-natreq4ipv6-00.txt>

Christian's slides are avaialble at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Huitema-NAT-6to4.ppt>

From the draft Abstract:

During the next few years, as the Ipv4 address space moves toward exhaustion, it is likely that the deployment of NAT will accelerate. By 2005, millions of NAT devices will likely be deployed on the Internet, both within enterprises and consumer households. Should those NAT devices not support either native Ipv6, or IPv6 transition mechanisms such as 6 to 4, the result would be significant delays in the deployment of IPv6.

This draft presents the requirements that NAT devices must meet in order to enable a future transition to IPv6. Rather than specifying every aspect of a NAT's operation in detail, our focus is solely on identifying those requirements that are absolutely essential to ensure compatibility with what we believe will be the most popular IPv6 transition mechanisms.
---

Alain Durand asked what happens when there are multiple layer of NATS.
Christian said that it doesn't work.

Keith Moore said he liked the idea. One issue is if the NAT receives packet of type 41, translates address, relays to internal host, that it won't work for large environments. Christian said that's ok.

Keith noted that this should also sell this as less growth in ALGs.

Question from the floor: can this be applied to configured tunnel, and if so please change the draft to reflect this? Christian responded yes to this, and he will change the draft.

===========================================================
MIME TYPE Definition for Tunnels - Alain Durand
-----------------------------------------------------------

Alain presented the newest draft of MIME TYPE Definition for Tunnels, which is available at:

<http://www.ietf.org/internet-drafts/draft-durand-ngtrans-tunnel-mime-type-02.txt>

He noted that there is a new co-author, a new draft, and new syntax of mime type. It is now easier to parse.

Alain also noted that he will respond to the need for an example with a new draft, then last call it.

===========================================================
Integration of three drafts on IPv6 Mobility for a dual-stack model- Tsao & Tsirtsis
-----------------------------------------------------------

Charles Tsao and George Tsirtsis presented the integration of three drafts on IPv6 Mobility for a dual-stack model into one draft. This takes Charles' two personal drafts (1. and 2. below) and merges them into the existing ngtrans draft v4-over-mipv6 (3. below).

1. Mobility Support for IPv4 and IPv6 Interconnected Networks based on Dual-Stack Model
<http://www.ietf.org/internet-drafts/draft-tsao-mobileip-dualstack-model-02.txt>

2. Routing Optimization for Mobile IPv4/Mobile IPv6 Interworking
<http://www.ietf.org/internet-drafts/draft-tsao-mobileip-00.txt>

3. IPv4 over Mobile IPv6 for Dual Stack nodes
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-v4-over-mipv6-00.txt>

The slides of this presentation are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Tsao-Tsirtsis-mobile-v4-v6.ppt>

Jim Bound said that this was good work and it should proceed.

Alain asked, and received consensus, that this integration should proceed.
A new draft will follow.

===========================================================
Viagenie web I/f to 6bone registry - Florent Parent, 10 mins
-----------------------------------------------------------

Florent Parent presented the Viagenie web I/f to the 6bone registry, a now well developed wbe-based interface to the production 6bone registry that allows an easier way to add, delete and change entries in the registry. This tool can be seen at:

<http://www.viagenie.qc.ca/en/ipv6/registry/index.shtml>

===========================================================
An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying - Kazuaki Tsuchiya
-----------------------------------------------------------

Kazuaki Tsuchiya presented An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (MTP), available at:

<http://www.ietf.org/internet-drafts/draft-tsuchiya-mtp-01.txt>

Kazuaki's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Tsuchiya-mtp.ppt>

This new draft attempts to answer concerns, from a previous MTP presentation in Pittsburgh, that the solution would not scale.

Dave Thaler thought this is possibly a good idea, and alright to be at ngtrans. He was not sure specific mechanisms are correct. He thought the proxy approach ok, but authentication stuff may not be ok unless way to know address.

Jim Bound asked if BIS part of this. Kazuaki replied that it is not.

Alain asked if this ok to be an ngtrans item, and then to take to the list for further discussion. There was no objection. MTP will become an ngtrans project.

===========================================================
6to4 Well Known Address & 6to4-DSTM - Alain Durand
-----------------------------------------------------------

Alain Durand presented his new draft 6to4 Well Known Address, available at:

<http://www.ietf.org/internet-drafts/draft-durand-ngtrans-6to4-well-known-address-00.txt>

and how George Tsirtsis would use the idea in the 6to4-DSTM draft, available at:

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-dstm-00.txt>

Their slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Durand-6to4-well-known-address.ppt>

This proposes using SLAid-0 as an 6to4router subnet.

SLAid = 0x0000 MUST be reserved as a virtual subnet for all 6to4 routers within a 6to4 domain.

EUI64 = 0000:0000:0000:0000 - all 6to4 routers ANYCAST address.

EUI64 = 0000:0000:0000:0001 - designated 6to4 router UNICAST address.

Erik Nordmark asked what these addresses will be used for.

Matt Crawford noted that when there are multiple prefixes for a site and the site wants to keep the subnet (SLA id's) the same, this approach would preclude that (at least for SLA id = 0).

Dave Thaler stated that we assume only one exit router has a prefix, but each could have a separate prefix. So why do we need this.

Geroge then presented the need.

Dave commented that he still doesn't understand why.

Erik noted that higher robustness is why multiple gateways, but does it work if a gateway goes down.

Dave said scenario not needed, but Alain thinks then 6to4 shuld say only one exit router.

This discussion will be taken to the list.

===========================================================
A Guide to the Introduction of IPv6 in the IPv4 World - Alain Durand
-----------------------------------------------------------

Alain Durand gave the status of the current version of A Guide to the Introduction of IPv6 in the IPv4 World, available at:

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-introduction-to-ipv6-transition-06.txt>

A few more small changes are coming, but it is getting close to done. Still need to verify scope descriptions for each mechanism. Alain expects to go to last call in May.

===========================================================
Connecting IPv6 Domains across IPv4 Clouds with BGP - Dirk Ooms
-----------------------------------------------------------

Dirk Oom presneted Connecting IPv6 Domains across IPv4 Clouds with BGP, available at:

<http://www.ietf.org/internet-drafts/draft-nguyen-ngtrans-bgp-tunnel-00.txt>

Dirk's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Ooms-bgp-tunnel.ppt>

Dirk asked if anything missing, and what next.

Dave Thaler asked if the wording can be changed so it doesn't have to be v4compatable address, but any type. Dirk will do this.

===========================================================
Transitioning DNS from AAAA to A6 - Rob Austein
-----------------------------------------------------------

Rob Austein presented Transitioning DNS from AAAA to A6. His slides are reproduced in entirety below.

He had given this same presentation in DNSEXT the day before.

---
The problems

We have two complete IPv6 DNS solutions
One is standard, the other is deprecated
Known implementations use the deprecated one
This is becoming a real issue for IPv6 deployment

Much concern about complexity of newer stuff and whether we really need it

Some of the new stuff requires extensive infrastructure upgrades

Strong case for the advanced features of the new stuff has not been made

---
Overview of proposed approach for A6

Write AAAA -> A6 transition spec
Almost certainly requires protocol fiddling, hence DNSEXT work
Almost certainly will require updating or augmenting A6 spec

Write "Case For A6" or admit that we can't make one
Recruiting security folks to help with time-to-resign issues
Need to identify and address any other issues

Goal is to have both docs ready by IETF 51 in London
Yes, this is aggressive

---
Why A6 is worth talking about

A6 does provide features that AAAA can not provide

"Degenerate" case of A6 semantically identical to AAAA

We do not yet know whether we need A6's extra features and may not until it's too late

Paranoia therefore suggests that:
We should deploy A6 in case we need it
We should only use it in the degenerate case for now

None of the above to be construed as lessening our need for a "Case For A6" doc

---
Overview of A6 transition plan

NB: This is still wet, and smells faintly of beer

"Real" data will be A6, degenerate case only for now

Stub clients wanting AAAA to be supported by synthesis from A6 data
Synthesis to be performed by entity providing recursive service
Synthesized data probably will not be signed

If a query does not contain EDNS indicator, additional section IPv6 addresses to be AAAA

Root and TLD zones contain only (degenerate) A6, not AAAA

---
Binary labels

Proposal: punt 'em

Binary labels do not provide any features that can't be provided by "nibbles"

Both are ugly. Both need better user interfaces.

Binary labels are painful to deploy, because of the new label type

DNAME can ease some of the pain of the "nibble" solution

---
DNAME

Very dangerous, but also potentially useful

DNAME does provide new functionality that it would be difficult to provide any other way
Not quite impossible (forests of CNAMEs), just prohibitively painful

Deployment problem not as bad as binary labels

Can make "nibble mode" reverse tree less painful

Recommendation: keep DNAME, but discourage gratuitous use
Easy to say, much harder to do
---

Itojun asked where is the appropriate place to discuss this, Rob replied dnsext.

Rob noted that after evaluation, transition will be uglier than just deploying A6, but case for A6 needed anyway.

Keith Moore commented that there is reason to fear not depolying A6 as well. That we need a real comparison of doing or not doing A6. Rob said that he agreed in theory, but implementing the A6 degenerate feature like aaaa is the same.

Keith said that if this A6 degenerate feature is to be put in in case of future use, it needs interoperability deployment testing.

Brian Zill asked how this was received in dnsext. Rob deferred to Olafur Gudmundsson (co-chair of DNSEXT)

Olafur commented that this is a hi-priority item for DNSEXT, that arose as we want to deploy v6 now and converting in future will be difficult. He is working with DNS vendors to look at doing A6 degenerate hack.

Christian Huitmena commented that going for short term approach is fine, but is a bit of a contradiction.

Keith said it would make a more complelling case if there is sensible case for renumbering, which we don't have yet.

Randy Bush (co-chair of DNSEXT and ngtrans AD)commented that until v6 folk do plan well for renumbering, you can't expect DNS to cope with it if not defined. DNS groups are trying to do the right thing with A6 and it is a productive process. Join them.

===========================================================
Transition mechanism interactions - Alain Baudot
-----------------------------------------------------------

Alain Baudot presented Transition mechanism interactions, available at:

<http://search.ietf.org/internet-drafts/draft-krampell-v6transition-interaction-00.txt>

Alain's slides are available at:

<http://6bone.net/ngtrans/IETF-50-Minneapolis/Baudot-transition-interaction.ppt>

Only deals with two mechanism interactions.

Alain Durand said good work, and made several comments:

1) I agree with the first goal: study the effects of combining 2 mechanisms.
This is something that is very useful for the wg.
However, I disagree with the 2nd goal "recommending which mechanism to use".
Those are two different and probably conflicting goals.

2) There are several errors in the analysis. Example the draft says: DSTM and 6to4 can not be combined. This is not true, we had a presentation on this topic earlier

3) The matrix is big, too big. I suggest to split it into smaller matrixes, using the scope of each mechanism as described in introduction to-transition-06

4) This will help to isolate the pathological cases that we should recommend not to use, examples:
- IPv6 - NAT/PT - IPv4 - NAT-PT - IPv6
- DSTM over 6over4
- 6over4 over DSTM

Jim Bound stated that usefullness statements need to come from customers not engineers. Thus state it is a limited study.

Brian Carpenter agreed with what Jim said. Doing it as a BCP isn't possible now. There are missing items: doesn't have a basic dual stack host mech. listed, BIA, Templin. Alain Baudot agreed.

Keith Moore stated that this is good work to be done. It is valuable if work does expose undesirable interactions. The group does need to evaluate conflicts that are possible. More than pair-wise are possible.

Erik Nordmark stated that this is good work. It shouldn't make new mech. describe interactions with old. Yes, people developing new mech. should evaluate, but don't make them decribe it.

Jim Bound noted that SIIT needs to be there as well.

Alain Durand said that Alain Baudot (and other authors) should incorporate comments, publish a new draft, then ngtrans will decide what to do with it next.

===========================================================
6to4-DNS and 6overNAT - Keith Moore
-----------------------------------------------------------

Keith Moore asked to give status of 6to4-DNS. The last feedback was that it was not possible to insist be in client libs., so the current draft comments on this. DNS group should look at DNS-related issues of this draft. No disagreement on this.

Keith also asked folks to read 6overNAT and bring up issues and comments by email or to see him offline.

Slides

TBRPF Applied to MANETs