(ngtrans) Redmond interim ngtrans minutes

[Bob Fink <[e-mail]>]

NGtrans folk,

Here are the minutes of the Redmond interim ngtrans meeting. Please send me 
any corrections and additions.


Thanks,

Bob

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

=======
Chairs:
Alain Durand <[e-mail]>
Bob Fink <[e-mail]>
Tony Hain <[e-mail]>

This ngtrans meeting reported by Bob Fink.

Attendance was ~80.

Alain Durand & Tony Hain chaired the meeting.

===========================
Administrative information:

Discussion ngtrans: <mailto: [e-mail]>
Subscribe ngtrans: <mailto: [e-mail]> "subscribe ngtrans"
Archive ngtrans: <http://www.wcug.wwu.edu/lists/ngtrans/>
Web site: <http://www.6bone.net/ngtrans>

Discussion 6bone: <mailto: [e-mail]>
Subscribe 6bone: <mailto: [e-mail]> "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.
==================
-end