Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt

[Pekka Savola <pekkas@netcore.fi>]

On Sat, 8 Nov 2003, Jun-ichiro itojun Hagino wrote:
> > On Mon, 3 Nov 2003, Pekka Savola wrote:
> > > This is a WG Last Call for comments on sending
> > > draft-ietf-v6ops-mech-v2-01.txt, "Basic Transition Mechanisms for IPv6
> > > Hosts and Routers", to the IESG for consideration as Proposed Standard:
> 
> 	suggestion in section 3.7 (quoted below) is unneecessary, or seems
> 	too strong.  could we remove it, or make it MAY instead of SHOULD
> 	at least?

FWIW¸ I don't have a strong opinion either way.  RFC2472 can't be listed
as normative reference, and the algorithm is too long to describe.  MAY
could be OK here, with a caveat that this is indeed for bidirectional
tunneling only.

(For example, some mechanisms may want to re-use the encoding to embed the 
tunnel address to the low-end  address.  With bi-dir configured tunneling, 
this should not really be an issue.)
 
> 	reasons:
> 	- coupling link-local address with tunnel endpoint IPv4 address makes
> 	  it harder to switch tunnel endpoint IPv4 address - reconfiguration
> 	  of IPv6 link-local address (usually used for nexthop) is needed.
> 	  therefore i prefer them to be separate.  it is from my long
> 	  operational experience.

Inheriting it from a physical device has its own problems, e.g. if the
hardware fails on the tunnel peer.  A setting independent of MAC address
has some uses.

Note: the document should be clearer that configured tunnels are typically 
point-to-point, and then you typically don't even need the link-local 
addresses, so this becomes practically rather irrelevant..

[...]
> 	- SHOULD is too strong as the use of different selection algorithm
> 	  of link-local address here does not impose any interoperability issue.

True, I don't really see that w/ configured tunneling how the address is 
configured really matters at all..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings