2.4.12 Next Generation Transition (ngtrans)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

Bob Fink <rlfink@lbl.gov>
Tony Hain <tony@tndh.net>
A 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

RFC3089

  

A SOCKS-based IPv6/IPv4 Gateway Mechanism

RFC3068

PS

An anycast prefix for 6to4 relay routers

RFC3142

  

An IPv6-to-IPv4 transport relay translator

Interim Meeting Report

Minutes of Interim NGtrans WG Meeting
1 June 2001
Redmond, WA

=======
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 ~80.

Alain Durand & Tony Hain 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:
----------------------
ISATAP - Intra-site tunneling / Alain Durand & Fred Templin
<draft-ietf-ngtrans-isatap-01.txt>

Matrix of transition mechanisms / Alain Durand & Alain Baudot
<draft-krampell-v6transition-interaction-00.txt>

IPv4 Compatibility Address Deprecation / chairs & others

=============================================================================
ISATAP - Intra-site tunneling / Alain Durand & Fred Templin
<draft-ietf-ngtrans-isatap-01.txt>
-----------------------------------------------------------------------------
Alain Durand presented his issues for ISATAP:

List of issues:
-sending rules?
-how to deprecate ISATAP when v6 native is available?
-gateway discovery (e.g., anycast or DNS based)
-is one prefix per site enough?
-if yes, should we reserve a well known prefix?
-if we do that, do we keep EUI-64 format?

Sending rules:

First case:

2 ISATAP nodes separated by a router, each has native v6 as well. Source address election longest prefix match will choose ISATAP not native path.

Fred responded that the draft will say that when native comes up that forming new sessions won't use ISATAP.

Alain said it isn't just hosts, but all nodes. Christian Huitema said one should pick source addresses first, then the destination. Thus the issue is the destination ordering. Rich Draves noted this is not specific to isatap, e.g., 6to4 has similar issue.

Erik Nordmark asked do we care about what addresses are or that tunnelling occurs. In destination ordering take into account property of interface so tunnels have a lower priority out of the box.

Second case:

both isatap nodes on same subnet, and same match will cause isatap use. Christian said it a source address selection issue with other interface types as well, e.g., Ethernet. Not an issue with ISATAP.

Jim Bound asked if isatap isn't just a different native address. Alain asked if we unnecessarily tunnel?

Dave Thaler, if you treat this as destination address selection, node A is native only so router encapsulates. Rich Draves noted that you don't know if there is tunnelling along the path, so you can fix the easy example 1 above, but not other configurations.

Fred asked if we really should take isatap down or not when native links become available. Tony Hain said why push the tunnelling to the router when the link could continue to configure isatap. Brian Zill said the problem then is how does isatap go away. Christian noted that if destination selection selects isatap, then the source choosing isatap sourced is ok to have end to end tunnelling.

Rich Draves said that he is leaning to the interface choice method to deal with this. Christian does not think we should address these problems by making the source selection draft more complex. Several felt that not trying to change the selection rules. Erik felt that policy configuration not optimal.

Deprecating isatap:

Any isatap node that is not an isatap gateway should deprecate isatap.

Fred Templin then presented changes made to ISATAP since Minneapolis. He also noted the name had changed.

<http://www.6bone.net/ngtrans/IETF-50-Redmond-Interim/Baudot-matrix.ppt>

Requires isatap addresses to use different 64 bit prefixes and thus eliminates the sending rules. Also changed the EUI-64 interface id to local scope.

Jim Bound asked what now identifies this as an isatap address. Fred noted that it is now administrative, so they might differ by SLA, nothing else. Jim then responded that it should be then just treated as a native address, if it works.

Fred doesn't think it is just an issue of endpoints being tunnelled as intervening points may exist that are tunnelled. Tony responded that those are hidden, what matters is when sharing the same prefix on the same wire.

Fred gave an overview of isatap, then covered the old method of forming as EUI (i.e., the IANA OUI approach), how it is formed, and that now it is local. This eliminated special sending rules, address selection considerations, special encoding, thus SHOULD use a common interface ID encoding for sanity checking (but not required).

Brian Zill noted that having it encoded makes it easy to identify externally, e.g., for screen viewing or printing. Dave thinks we MUST do it to make debugging easy.

Alain Durand wanted the new token to be zero, but Dave Thaler disagreed as it might occur commonly.

Fred suggested recommended either 0000:0000:vraddr or 0000:FFFF:v4addr.

Dave Thaler didn't like as it is similar to a PPP link. He still wants the 5FFE style, i.e., what it says now. Christian Huitema felt that what code doesn't matter.

Alain asked opinions of several choices: plain 0000 - no votes; FFFF version - no votes; FFFFFFFE - no votes, IANA style, several folk.

Automatic gateway discovery:

Option 1: Attempt RFC 2462 stateless auto-configuration (Keep trying periodically)

Option 2: Attempt off-link IPv6 gateway discovery as follows:
1. Discover ISATAP IPv4 anycast address (ISATAP_ANY) for site. (Could be IANA reserved; could be site-specific.)
2. Send tunneled Rtsol using node's IPv4 addr (V4ADDR) to ISATAP_ANY:
ipv6_src: FE80::V4ADDR
ipv6_dst: FF02::2 (All Routers Multicast)
ipv4_src: V4ADDR
ipv4_dst: ISATAP_ANY
3. Receive tunneled Rtadv from an ISATAP Router (ISATAP-RTR):
ipv6_src: FE80::ISATAP_RTR
ipv6_dst: FE80::V4ADDR
ipv4_src: ISATAPGW
ipv4_dst: V4ADDR
4. Construct fully-qualified ISATAP Address; default6 route to FE80::ISATAP_RTR
5. Repeat steps 1 thru 4 periodically:
. automatically renumber if any changes occur.
. Discontinue use of ISATAP address and revert to option 1
*immediately* if native Rtadv's arrive

Brian Zill then mentioned the idea of having the anycast server having administrative policy in them to supply the correct router. Christian Huitema noted that anycast works as all of anycast routers should act the same.

Alain Durand asked if the dns solution better than anycast. Christian liked it as it is easier to administer and requires no special configuration of router. Steve asked if you can inject a host route into it.

Dave Thaler noted that when router is not reachable on first RS, so after this (3 times), then host never gets isatap without Fred's last step (5.).

Fred then discussed isatap interactions with NAT.

Case 0: Unmodified NAT boxes
ISATAP tunneled Rtsol's will not be forwarded
ISATAP hosts will not reach an ISATAP router

Case 1: NAT box as ISATAP Transparent Proxy:
Host 'A' behind route sends Rtsol to ISATAP_ANY
NAT 'B' intercepts Rtsol; REMEMBERS 'A'; sends Rtsol to ISATAP_ANY
ISATAP_RTR 'C' sends Rtadv to 'B'

Host 'A' behind route sends Rtsol to ISATAP_ANY
NAT 'B' intercepts Rtsol; REMEMBERS 'A'; sends Rtsol to ISATAP_ANY
ISATAP_RTR 'C' sends Rtadv to 'B'
NAT 'B' sends Rtadv to 'A'
For any V6-in-V4 TCP/UDP. 'B' translates V4ADDR in BOTH IPv4 and IPv6 hdr's

Several folk commented that they don't want ISATAP to cross a NAT as it increases failure modes.

Fred will do another draft to accommodate items from this discussion.

=============================================================================
Matrix of transition mechanisms / Alain Durand & Alain Baudot
<draft-krampell-v6transition-interaction-00.txt>
-----------------------------------------------------------------------------
Alain Baudot presented his current view on how to do the matrix of transition mechanisms:

<http://www.6bone.net/ngtrans/IETF-50-Redmond-Interim/Templin-isatap.ppt>

draft-krampell-v6transition-interaction-00.txt was based on combination of 8 transition mechanisms => 8 x 8 = 64 cases. However, new transition mechanisms have been defined! Up to 16 mechanisms are defined or under definition. Combining all mechanisms with each other results in 256 cases!

Each mechanism solves a particular transition issue ­ it is unlikely that we will reduce the number of mechanisms.
Need to find a new approach reducing the number of cases to check.

Mechanism approach : stack, translation, tunneling
Scope approach : host, site, global

Stack mechanisms
Dual Stack: Host
BIS: Host
BIA: Host

Translation mechanisms
Socks: site
SIIT: site
NAT-PT: site
TRT: site
Proxy: site

Tunneling mechanisms
Configured tunnel: Host x Host
Automatic tunnel: Host x Host + Global
Tunnel broker: Host x Host + Global
6to4: Site x Site + Global
6over4: Host x Host + Site
DSTM: Host x Host + Site

The general mechanism approach resulted in 94 cases to evaluate. This is an exhaustive end-end approach.

The scope approach resulted in 59 cases to evaluate.
Host scope : enables the communication of a single host (8 mechanisms)
Site scope : enables a whole site communication without effect on the Internet (8 mechanisms)
Global scope : enables host or site communication with effect on the Internet (3 mechanisms)
Local or parallel approach, not end-to-end
Assumes that there are no interaction issues outside a scope

It was viewed that the mechanism approach was too exhaustive and that a scope-based approach was more relevant. It would be a local approach, not end-to-end.

Alain Baudot noted that the authors were working together with the authors of draft-ngtrans-introduction-to-ipv6-transition-0x.txt on this project.

Steve Deering asked what the end goal was, once the method was resolved. Jim Bound also asked what the objective was. Informational? Alain Durand stated that Informational was it's goal.

Alain Durand suggested that he proceed and present what he has.

=============================================================================
IPv4 Compatibility Address Deprecation

The issue of what to do with IPv4 Compatibility Addresses was raised. Several folk commented. There seemed to be a general consensus that the usefulness of this format had come to an end.

Bob Hinden stated that he didn't believe that a change to the address architecture was appropriate, rather a change in specs that use them. Tony Hain noted that the transition mechanism specification may eliminate it.

It was noted that BGP-TUNNEL uses it, but there was agreement of several folk and at least one of its authors that this should and could be changed.

==================
Meeting adjourned.
==================

Current Meeting Report

Minutes of NGtrans WG Meeting
7 August 2001
London IETF-51

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

Tony Hain chaired the meeting.

Bob Fink took the minutes.

Attendance was over 200.

===========================
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

---
Agenda bashing

NGtrans Project Status - Fink, 5 mins

DNS OPS Requirements - Alain Durand, 10-20 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dns-ops-req-01.txt>

Bump In the API (BIA) - Myung-Ki Shin, 10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-bia-00.txt>

ISATAP Issues - Fred Templin, 5-10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

ISATAP Router Discovery - Dave Thaler, 10-15 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

NAT traversal discussion - Durand/Huitema, 10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-natreq4ipv6-00.txt>
<http://www.ietf.org/internet-drafts/draft-huitema-shipworm-00.txt>

Denial of Service by 6to4 anonymisation - Alain Durand, 5-10 mins

Moving MECH (RFC2893) forward to DS discussion - Erik/Alain, 10-20 mins
<http://www.ietf.org/rfc/rfc2893.txt>

DSTM & friends update - Jim Bound, 5-10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-04.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstmext1-aiih-00.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-dstm-00.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-siit-dstm-00.txt>
<http://www.ietf.org/internet-drafts/draft-shin-dstm-single-ipv4-00.txt>

BGP Tunnel remaining issue discussion - Jeremy De Clercq, 5-10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

Tunnel Servers/Brokers - Marc Blanchet, 5-10 mins
<http://www.ietf.org/internet-drafts/draft-vg-ngtrans-tsp-00.txt>

MIME-TYPE - Alain, Durand, 3-5 mins
<http://www.ietf.org/internet-drafts/draft-durand-ngtrans-tunnel-mime-type-02.txt>

Example Addressing draft - Marc Blanchet, 3-5 mins
<http://www.ietf.org/internet-drafts/draft-blanchet-ngtrans-exampleaddr-01.txt>

IPv6-SMTP-REQUIREMENTS - Itojun, 3-5 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-02.txt>

An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (MTP) - Kazuaki Tsuchiya, 5 mins
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mtp-00.txt>

Connecting IPV6 islands within a same IPV4 AS - Damien Galand, 5 mins
<http://search.ietf.org/internet-drafts/draft-many-ngtrans-connect-ipv6-igp-00.txt>

=================================
NGtrans Project Status - Bob Fink

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/ngtrans-status.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/ngtrans-status.pdf>

Bob presented the current status of NGtrans projects (see slides above).
For current status of projects, look at:

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

===
DNS OPS Requirements - Alain Durand
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dns-ops-req-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/DNS-OPS-REQ.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/DNS-OPS-REQ.pdf>

Alain noted that a -02 version will be released soon.

Given a requirement for transparent DNS lookups regardless of IP version, there is a need for some sort of bridging solution.

Why is bridging important? While processing the NS chain, a resolver will follow a chain of referrals. In that chain, it may happen that one of them is not directly reachable with the resolver IP stack.

IPv4 bridging vs IPv6 bridging
· Both are necessary
· Although desirable, both solutions do not need to be the same.
· Constraints are different

Bridging IPv6 only resolver to IPv4 only server
· Constraints due to installed base
­ Can modify IPv6 resolver code
­ Can modify IPv6 resolver configuration
· Fall back, last resort forwarder
­ "Forward Last"
­ Recursive
· DNS lookup proxy
­ Non recursive

Bridging IPv4 only resolver to IPv6 only server
· Constraints due to installed base
­ Can not change IPv4 resolver code
­ Can not change IPv4 resolver configuration
· Why?
­ An unmodified IPv4 only MTA may want to check validity of any email address in the DNS, even if this address belongs to an IPv6 only domain.
· Solutions
­ all zones MUST have at least an IPv4 NS
­ ...?

There was no discussion.

Tony noted that we will put a short timer on the -02 review given there were no comments here.

Alain and Tony commented on the joint DNS-EXT/NGTRANS meeting on IPv6 ddresses in the DNS that was held yesterday, noting that a draft of the outcome is coming soon for comment.

===
Bump In the API (BIA) - Myung-Ki Shin
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-bia-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/bia.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/bia.pdf>

BIA History and Status
* IETF-45, July 1999
­ Basic idea was presented. (there was no doc.)
* IETF-50, March 2001
- BIA draft was presented.
- Accepted as working group project with strong guidance to include applicability and disclaimer to prevent misuse
* IETF-51, August 2001
- First wg draft was published, <draft-ietf-ngtrans-bia-00.txt>
* IETF-52, December 2001
- Hopefully finished soon after

A picture comparing BIS (Bump In the Stack) and BIA was shown.

While BIS is for systems with no IPv6 stack, BIA is for systems with an IPv6 stack, but on which some applications are either not yet available on IPv6 or application for which source code is not available or lost.

Required Changes
* Editorial Comments
­ Applicability Statement
­ Disclaimers
­ API functions list intercepted by BIA module [Appendix ?]

* Technical Comments
­ Additional Considerations

Applicability and Disclaimer
* Applicability Statement
­ It's good for early adopters who do not have all applications handy, but not for mainstream production usage.
* Disclaimer
­ We strongly recommend that application programmers SHOULD use this mechanism only when an application source code is not available.
­ Do not take it as an excuse not to port software. (Don't delay porting)

Considerations
* Socket API conversion
­ IPv4 socket API functions are translated into semantically the same IPv6 socket API functions and vice versa.
­ Which Functions are intercepted ?
=> They will be listed up in the second draft - Appendix

Additional Considerations
* Mis-match between DNS value (AAAA) and Application version (v4)

A diagram of this was shown.

* Solution ?
­ Try all the addresses listed in the DNS and just not fail after the first attempt
=> BIA can support this solution by extensions to name resolver and API translator in BIA module

ETRI & i2soft - Implementation
* bia-20010726-beta (second beta release)
* Windows 2000 + MS IPv6 Technology Preview
* Implemented using Windows2000 SPI(Service Provider Interface)
* Available at <http://www.krv6.net/bia/>

Implementation Status
* Currently it works well with
­ HTTP : IE and Netscape
- Telnet : NetTerm and CRT telnet client
­ POP3 : Outlook Express and Netscape Mailer
* It does not work YET with
­ Server program
­ Application with IP addresses embedded in application layer protocols (FTP, etc.)
- Multicast, QoS, etc.

Alain asked what BIA can do help failing after first attempt.

Myung-Ki responded we assume current host has both addresses. Alain said he would take this offline.

===
ISATAP Issues - Fred Templin
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/isatap.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/isatap.pdf>

Fred gave a brief overview of ISATAP, then listed the changes in ISATAP since IETF-50 (that were reported at the Interim in Seattle).

· Name changed to ISATAP
· Added "Terminology" section
· Require ISATAP/non-ISATAP addresses use different /64 prefixes ­ simplifies sending rules
· Changed u/l bit in EUI-64 interface ID to indicate LOCAL scope

He then describe developments since the interim meeting:

· Linux implementation by Nathan Lutchansky:
­ works with all kernel versions 2.2.16 ­ 2.4.6 (with/without USAGI)
­ testing with stateful configuration complete
­ multiple interface support (anticipated configuration scenario for NAT)
­ code for stateless auto-configuration complete; testing begins after IETF51
­ Stay tuned for code release announcements (TBD with Nathan)

Fred concluded with open issues since the interim meeting:

· When to deprecate ISATAP address?
­ Old answer: when native IPv6 Rtadv's heard
­ New answer: when native Rtadv's heard AND ISATAP interface usage drops below some threshold
­ Not conclusive; more study needed

· Will ISATAP addresses be preferred over native IPv6 addresses by longest prefix-match?
­ No ­ destination ordering will fix this (already addressed in source/destination selection draft)

· Will ISATAP present any new security issues? (question from private e-mail)
­ IPv6 source address spoofing seems like biggest issue
­ Nearly finished enumerating cases; spoofing easy to detect in all cases examined thus far
­ Claim: ISATAP secure IFF site's IPv4 network secure
­ Will send analysis to mailing list when complete

· Current draft expires 17 November 2001; new draft coming soon

Steve D asked what supporting multiple i/f means. Fred said two virtual i/f might be used, i.e., two locales in one site.

Alain asked why use it across two domains. Fred said you don't use on public address side, rather when NATs involved.

Christian noted that it is used for partially converted sites where you don't use 6to4.

Brian Zill asked if Nathan's Linux version inter-operates w/Windows yet.
Fred said he had not tried that yet.

===
ISATAP Router Discovery - Dave Thaler
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/isatap-rtrdisc.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/isatap-rtrdisc.pdf>

Problem Summary
· ISATAP makes IPv4 site look like one NBMA link
· Normal router discovery relies on multicast
· Observation:
­ Once you know the address of a router, you can unicast an RS and get a unicast RA
· So how do you discover the address of a router?

Robustness of RA's
· Normally RAs are periodically multicast
· If no RAs known (e.g., routers down)
­ Send RSs at low frequency, say 15 mins
­ Tradeoff between overhead and timeliness
­ Should be a temporary condition
· If RA known
­ Send RS after half of lowest lifetime in RA, to a minimum of the low frequency value above
­ Minimum intended to prevent overhead during renumbering

Several choices were briefly covered with pros and cons: SLP, DHCPv4, well-known host name, SRV record lookup, well-known IPv4 anycast address, and hybrid approaches.

Steve Deering queried that if RA is just one example of mcast, and given that we need to support NBMA links, why is RA specially handled? Dave responded that we need to know router ahead of time. Steve asked again, but why special case RA? Dave noted that it is stateless.

Someone asked if he had onsidered using MARS. Dave replied yes, but that it is too complex and we only need something until native v6 connectivity occurs, not another special (and costly) service

Alain asked about the randomization time choice? Dave replied he needs to add it (and it will be 15 mins).

Alain stated that if using well known router name, he doesn't like unqualified (short) names as going thru resolver it might end up outside of domain, and is vulnerable to DoS attacks.

Fred noted that one could use different DNS responses to establish locality.

Someone asked if anycast is in use. Dave noted it is widely used in v4 today. It's just a host route Tony Hain noted.

Dave asked if there is a preference for a given solution:

Jim B, liked anycast but disagreed that v4 anycast is in wide use, and needs to be tested very thoroughly for v6 before it is specified/used.

Alain noted that as ISATAP is a transition mechanism, it is temporary, thus easy to do is best, and not a hybrid; he wants to choose just one simple to implement approach.

Dave thinks the well known host name is easiest. Alain thinks anycast is as easy. Dave agreed.

Erik Nordmark asked if we want to discover one or more routers. Dave replied that this is something to think about.

Tony cutoff the question queue due to time. He noted that the topic should be taken to the list. He encouraged everyone to actively participate in this discussion online.

===
NAT traversal discussion - Alain Durand/Christian Huitema
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-natreq4ipv6-00.txt>
<http://www.ietf.org/internet-drafts/draft-huitema-shipworm-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/NAT-traversal.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/NAT-traversal.pdf>

<http://www.6bone.net/ngtrans/IETF-51-London/shipworm.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/shipworm.ppt>

Alain first presented two scenarios for a lead in to Christian's topic.
They are both home networking behind a NAT scenarios:

Case 1: NAT box that cannot be upgraded to IPv6
Your ISP gives you just one global IPv4 address

Case 2: double NAT
Your ISP gives you one private IPv4 address

These cause a problem for a 6to4 router placed in the home.

Christian then presented shipworm-00. A shipworm is one that bores holes in a ship's hull (read NAT ;-).

Repeating from the introduction to the draft:

"Classic tunneling methods envisaged for IPv6 transition operate by sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal proposes automatic discovery in this context. A problem with these methods is that they don't work when the IPv6 candidate node is isolated behind a Network Address Translation device: NAT are typically not programmed to allow the transmission of arbitrary payload types; even when they are, the local address cannot be used in a 6to4 scheme. 6to4 will work with NAT if the NAT and 6to4 router functions are in the same box; we want to cover the relatively frequent case when the NAT cannot be readily upgraded to provide a 6to4 router function.

A possible way to solve the problem is to rely on a set of "tunnel brokers." There are however limits to any solution that is based on such brokers: the quality of service is not very good, since the traffic follows a "dog leg" route from the source to the broker and then the destination; the broker has to provide sufficient transmission capacity to relay all packets and thus suffers a high cost. For these two reasons, we tend to prefer solutions that allow for "automatic tunneling", i.e. let the packets follow a direct path to the destination.

The automatic tunneling requirement is indeed at odds with some of the specificities of NATs. Establishing a direct path supposes that the IPv6 Candidate can retrieve a "globally routable" address that results from the translation of its local address by one or several NATs; it also supposes that we can find a way to bypass the various "per destination protections" that many NATs implement. In this memo, we will explain how IPv6 candidates located behind NATs can enlist the help of "v6 UDP routers" to learn their "global address" and to obtain connectivity."

Christian then described the principal design choices:

· Automatic discovery or explicit configuration?
· Stateless or stateful tunnel ? /64 or /128 ?
· Direct transmission or tunneling?
· Optimizing UDP-UDP or not ?

Automatic discovery or explicit configuration?
· Explicit configuration:
­ Tunnel as a "VPN" service
­ Almost never on "direct path"
­ Hard "for the masses"
· Automatic discovery
­ Requires "anycast address"
­ No clear business model => requires low cost service.

Steve Deering noted that if existing tunnel brokers use explicit configuration, doesn't prove that non-automatic explicit configuration is acceptable? Christian disagreed, saying that this does not constitute use by the masses.

Randy asked how congestion control works given it is required that this is addressed by Christian's proposal.

Christian said there are several examples of how it might work, but agreed to include consideration of this in the draft.

Steve Deering asked if you want stability for addresses across days. Christian said that if you have a contract between client and server (statefull) then it is a long term assignment, but he likes stateless systems better.

Steve replied yes, stateless preferred other things being equal, but isn't stability a goal. Christian noted that his specific goal is to be able to run peer-peer apps, thus need a globally reachable address, thus it needs to be known. Need to have a name service.

Steve again stated that we need stability.

Erik Nordmark commented that NATs often release port assignments in varying interval, thus you might get a different port. Christian noted that this is explained in his draft. What differs is interval, it is between 45 secs and 15 minutes, so as long as stream shows activity more often that 45 secs, mapping is maintained.

Steve asked what gives Christian confidence in NAT characteristics. Christian replied market studies.

Tony noted that this is a side issue, and he wanted a hum shipworm becoming a project. There was hum consensus.

Christian will issue new draft, and make it a wg item. The shipworm name will still be used (we all like it).

Steve asked if there were any consequence of this solution for routing. Christian replied no.

===
Denial of Service by 6to4 anonymisation - Alain

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/6to4-dos.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/6to4-dos.pdf>

Alain showed a diagram of a possible denial of service attack via a 6to4 router.

His proposed solution is to do ingress filtering in the 6to4 router, where the IPv4 src address MUST match the IPv4 address embedded in the 6to4 src address.

Christian noted that this situation is covered in the 6to4 RFC already.

Steve Deering asked what if the ipv4 source address is a legitimate 6to4 gateway and thus a test can't be used for filter.

Francis Dupont noted that this is a generic problem when you have two sources.

Alain had asked implementors if they do any source address filter checks, and they said no, in spite of the RFC. Thus Alain believes the text should be stronger.

Erik Nordmark noted that the IETF community needs to understand these type of DoS attacks better, and noted Vern Paxson recent paper on the topic.

Christian commented on how to differentiate a legit and illegit router. One possibility is to use a 6to4 anycast address as source for differentiation. If we don't use ingress source filtering, then attacker can do more than just this DoS attack. Thus don't bother.

Steve said that backinstalling the v4 internet with ingress source filtering not realistic.

Erik agreed the v4 Internet is not up to 100% ingress filtering, but it is good to do and minimize places where attacks can come from.

===
Moving MECH (RFC2893) forward to DS discussion - Erik Normark
<http://www.ietf.org/rfc/rfc2893.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/MECH-DS.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/MECH-DS.pdf>

Erik presented his set of things to do to take MECH to DS.

Update, simplify, remove redudancy
Keep dual stack and configured tunneling

Remove from current RFC?

Automatic tunneling (section 5)
­ 6to4 and ISATAP are more powerful
IPv4-compatible addresses
­ Only used with automatic tunneling
Description of address selection and IPv6/IPv4 selection (much of section 2.2)
­ Superceded by -ipngwg-default-addr-select-
Default configured tunnel (section 4.1, 4.2)
­ Not used??

Next steps:
Issue I-D with edits
Comments are welcome!!
WG chairs to put together implementation report
­ Needed for Draft Standard
­ Will have list of sections in draft with the features/options to be implemented

There was no discussion. A draft will soon be generated to implement these ideas.

===
DSTM & friends update - Jim Bound
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-04.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstmext1-aiih-00.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-dstm-00.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-siit-dstm-00.txt>
<http://www.ietf.org/internet-drafts/draft-shin-dstm-single-ipv4-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/DSTM-update.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/DSTM-update.pdf>

Jim presented an overview of the relationship and status of the various DSTM related drafts.

He noted that as DHCPv6 will soon go to wg last call thus he will soon want to release a new version of DSTM and do a last call for forwarding to the IESG for PS on it.

There was no discussion.

===
BGP Tunnel remaining issue discussion - Jeremy De Clercq
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/bgp-tunnel.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/bgp-tunnel.pdf>

Jeremy presented the status of recent changes made to the BGP Tunnel draft:
editorial changes
added tunnel-specific considerations
added case of multiple IPv4 domains between IPv6 islands
added discussion on v6[v4]addresses in appendix
new co-author

Then Jeremy discussed the choices of v6[v4]addresses:
requirements from the draft
v6[v4] address doesn't need to be routable
v4 address in v6[v4] could be private address
originally "v4-compatible v6", but
deprecated?
not allowed to carry private v4 addresses?
alternatives:
make it configurable => unnecessary confusion
6to4 => only allows global v4 addresses
ISATAP !?

Erik Nordmark asked is v4 address a regular address or? Jeremy replied that yes it was. Erik then why not used a v4 mapped address. Jeremy replied that this may be work and will take it offline. Alain noted that he wants to converge on this on mail list so we can advance this draft as soon as possible.

Jeremy concluded: Next is to adapt draft to include v6[v4] address choice and then it is ready for last call.

===
Tunnel Servers/Brokers - Marc Blanchet
<http://www.ietf.org/internet-drafts/draft-vg-ngtrans-tsp-v6v4profile-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/tsp.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/tsp.pdf>

Marc presented his idea for a protocol between clients and brokers:

For negotiation of parameters:
· Servers Capabilities
· Authentication method
· Client wants a /48, server don't want.

For Keepalive (detection of ipv4 network problems)

For Server policies:
· Lifetime of the tunnel

For Generalization and extensions
· DNS information
· Whois-type information

For Error conditions and protocol feedback (error numbers)

For Easy renegociation of parameters:
· change of ipv4 address
· Can be included in boot sequence (or dhcp lease,...)

He described the characteristics of the protocol:
· Control protocol for tunnel setup
· Uses TCP
· Uses SASL (RFC2222) for:
authentication negociation
and transport encryption negociation
· XML messaging:
easy to describe data, extend, optional parameters, ...
· Protocol version numbering

There is two documents:

· One framework
generic for any kind of tunnels
Supports both tunnel broker and server models
· One specific for ipv6 in ipv4 profile
· Others to come:
IPv4 in IPv6 profile

Considerations:
· Currently implemented in freenet6.net service.
· More work on the detailed specification to be done.
· Ngtrans wg work item?

Dave Thaler asked that most of the requirements can be done in L2TP. Mark said maybe.

Tony asked for hums on making this a wg item. There was little support for this becoming a wg project, thus it will not be accepted as one.

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

NO SLIDES

Alain noted that he is asking an expert on mime types if the draft is ready for last call. If so, then he will last call it.

There was no discussion.

===
Example Addressing draft - Marc Blanchet
<http://www.ietf.org/internet-drafts/draft-blanchet-ngtrans-exampleaddr-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/exampleaddr.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/exampleaddr.pdf>

Marc noted the need to reserve some address space for documentation:
RFCs, drafts, vendor doc, books, examples, ...

He Proposed:
­ Inside the 3ffe: space
­ At the end of the space (3ffe:ff...
­ Length: 24, 28, 32

3ffe:ff00::/24
equiv of the ptla past policy
Enables examples with multiple current tlas (/29)
3ffe:fff0::/28
follows the current ptla policy (anything >28 would consume anyway a ptla
Enables two tlas
3ffe:ffff::/32
Smaller, less space wasted.

Steve Deering asked if we also then need a similar thing in mcast, site local...

Alain noted a site local only conflicts with yourself. Steve replied, yes, but within same site conflict is possible.

Dave Thaler noted that mcast already handled by this draft.

Itojun delt that with enough warnings as to usage, it is not required to reserve space for examples. Francis Dupont disagreed and believed it useful to reserve space.

Tony asked for a hum on making this a working group item, but there was no agreement.

Bob Hinden and Steve Deering stated that they felt this work item belonged in ipngwg, as it reserves address space, so it was agreed to move this to ipng.

===
IPv6-SMTP-REQUIREMENTS - Itojun
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-02.txt>

SLIDES:

Outline

Operational requirements for IPv6 SMTP, and IPv6 DNS MX records
Goal: stable email transport in IPv6/v4 dual stack world

Similar content presented by Kazu, at IETFxx

Outgoing: be careful looking up all MX/A/AAAAs
Incoming: configure MX right, be sure to keep reachability among servers

IPv6 MX lookup (outgoing)

Same, but a bit more complicated

email to foo@example.org

Lookup example.org
MX - use it, based on preference (then A/AAAA)
A/AAAA - use it
CNAME - resolve till get to MX/A/AAAA

Be sure to try all available As and AAAAs
SMTP failure handling (4xx or 5xx) complicates the story

example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN A 1.0.0.1 ; IPv4/v6 dual stack
IN AAAA 3ffe:501:ffff::1
mx10.example.org. IN AAAA 3ffe:501:ffff::2 ; IPv6 only

MX for dual stack sites (incoming)

Be sure to allow emails to get delivered to the final email server

If possible, make the most preferred MX a dual stack node

; easy and good config
easy.com. IN MX 1 v4only.easy.com.
easy.com. IN MX 10 dualstack.easy.com.
; good config
good.com. IN MX 1 dualstack.good.com.
good.com. IN MX 10 v4only.good.com.
; bad config
bad.com. IN MX 1 v4only.bad.com.
bad.com. IN MX 10 v6only.bad.com.

Misc comment/changes

Interpretation of scoped address in MTAs
itojun@[fec0::1]@[3ffe::1]@[fec0::1]
Forbid numerics? Can be a security issue...

The syntax has obsoleted in RFC2822

Deployment/tests

Mononori have made experiments to check readiness of MTAs, regarding to A/AAAA MX records
No implementation (we have seen) choked - it seems safe to declare IPv6 MX records
Sendmail 8.10/11, as well as other IPv6-ready MTAs, work as documented in this draft (outgoing)

Summary

Operational requirements for IPv6 SMTP, and IPv6 DNS MX records
Goal: stable IPv6 email transport

Similar content presented by Kazu, at IETFxx

Outgoing: be careful looking up all MX/A/AAAAs
Incoming: configure MX right, be sure to keep reachability among servers

Would like a last call for informational.

There was no discussion.

===
An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (MTP) - Kazuaki Tsuchiya
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mtp-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/mtp.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/mtp.pdf>

Kazuaki presented the new MTP project (recently accepted as an ngtrans project). See the slides above for pictorial contect.

- Document status
> Accepted as the Ngtrans working group document at the last meeting

- Changes from the previous draft
> Extended applicability to large-scale network systems

- Need to define a specific setup protocol for the interaction between the IPv6 clients and the IPv4 multicast proxy?

> This is outside the scope of the document?

> Nevertheless, for helping implementation efforts, an example should be described in the document?

There was no discussion.

===
Connecting IPV6 islands within a same IPV4 AS - Damien Galand
<http://search.ietf.org/internet-drafts/draft-many-ngtrans-connect-ipv6-igp-00.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/IGP-tunnel.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/IGP-tunnel.pdf>

There was no time for the presentation so it was agreed to take the presentation and discussion to the list. Please see the slides listed above.

There was no discussion.

===
Multicast extensions to BIS (mBIS) - Kazuaki Tsuchiya
<no paper submitted by cutoff>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/mbis.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/mbis.pdf>

There was no time for the presentation.

===
Adjourn

Slides

None received.