Subject: (ngtrans) link-local addresses in transition-mechanisms

From: Richard Draves <[email-masked]>
Date: Wed, 21 Jun 2000 17:15:08 -0700

To briefly summarize some off-list discussion: the MLD spec says that MLD
messages use a link-local source address. The multicast-over-6to4 draft uses
a degenerate form of MLD over 6to4, so the messages should use a link-local
source address taken from the 6to4 interface. The  6to4 draft says the 6to4
interface forms a link-local address following the rules specified in the
transition-mechanisms draft for configured tunnels. The
transition-mechanisms draft section 3.7 says

   Both the configured and automatic tunnels are IPv6 interfaces (over
   the IPv4 "link layer") thus MUST have link-local addresses.  The
   link-local addresses are used by routing protocols operating over the
   tunnels.

   The Interface Identifier [14] 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.

   The IPv6 Link-local address [14] for an IPv4 virtual interface is
   formed by appending the Interface Identifier, as defined above, to
   the prefix FE80::/64.

The problem is, the 6to4 relay that is receiving MLD joins & leaves from a
6to4 gateway *must* be able to determine the sending 6to4 gateway's v4
address from the MLD message.

If the link-local v6 source is formed as suggested above, then this is
possible because the desired v4 address is the low 32 bits of the v6 source
address. However the SHOULD language means that this is not guaranteed.

I suggest that the transition-mechanisms draft be revised to say something
like "The low 32 bits of the Interface Identifier for such an Interface MUST
be the 32-bit IPv4 address of the interface. The high 32 bits of the
Interface Identifier MAY be non-zero, except that the "Universal/Local" bit
MUST be zero, to indicate that the Interface Identifier is not globally
unique."

Note that there may be several configured tunnels using the same local IPv4
address. The reason for allowing the high 32 bits of the Interface
Identifier to be non-zero is that some implementations that use a separate
interface for each configured tunnel may find it convenient to ensure that
Interface Identifiers are unique across the several configured tunnel
interfaces.

Is this a reasonable change?

Thanks,
Rich

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 22 Jun 2000 09:36:01 +0900

>MUST be zero, to indicate that the Interface Identifier is not globally

	I do not agree with making it mandatory to embed IPv4 address into
	interface identifier.  I find it very useful to decouple IPv6
	address (interface identifier portion) and tunnel endpoint IPv4
	address, since it allows us to renumber IPv4 address without changing
	IPv6 configuration at all.
	Thinking of relationship between IPv6 address and normal layer 2
	like ethernet, we do not usually see tight coupling between those two.
	It is not mandatory to construct interface ID from MAC address, as
	we have seen in privacy draft.

	if the change affects 6to4 interfaces only, I think I'm okay with it.
	I think I'm aginst of changing RFC1993/mech-xx.  Actually, I do not
	find it useful to define interface ID construction in RFC1933/mech-xx,
	and refer it from all tunnel drafts.   Better (IMHO) way to construct
	interface ID is found in RFC2472 (IPv6 over PPP).  basically RFC2472
	suggests: (1) borrow MAC address/EUI64 address from other interface
	with setting U bit into local, (2) use other source that does not
	change across reboot or number generated from that, (3) use random
	number.

	by the way,
>be the 32-bit IPv4 address of the interface. The high 32 bits of the
	do you assume that an IPv4 address is assigned onto 6to4 interface?
	if we implement 6to4 interface as pseudo interface, normally we do not
	have IPv4 address on 6to4 interface.  (implementation issue)

itojun

---

From: Francis Dupont <[email-masked]>
Date: Thu, 22 Jun 2000 12:27:40 +0200

=> I agree with Itojun!

   	by the way,
   
=> I think Richard's wording should be changed because his IPv4 address is
not the address of the interface but the address used in outer headers
(the V4ADDR of 6to4 I-D).

Regards

[email-masked]