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

[itojun@itojun.org (Jun-ichiro itojun Hagino)]

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

	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.
	- RFC2472 section 4.1 has better way to generate interface ID.
	- SHOULD is too strong as the use of different selection algorithm
	  of link-local address here does not impose any interoperability issue.

	btw, RFC1933 did not have such requirement (SHOULD).  RFC2893
	introduced this.  i did voiced my concern but was not integrated into
	RFC2893.

itojun


>   The Interface Identifier [RFC2373] for such an Interface SHOULD be
>   the 32-bit IPv4 address of that interface, with the bytes in the same
>   order in which they would appear in the header of an IPv4 packet,
>   padded at the left with zeros to a total of 64 bits.  Note that the
>   "Universal/Local" bit is zero, indicating that the Interface
>   Identifier is not globally unique.  When the host has more than one
>   IPv4 address in use on the physical interface concerned, an
>   administrative choice of one of these IPv4 addresses is made when
>   forming the link-local address.