Subject: AYIYA link local address

From: Jeroen Massar <[email-masked]>
Date: Mon, 31 Jan 2005 17:54:30 +0100

Hi,

Somebody nicely noticed that multicast did not work over AYIYA, because
of ... a missing linklocal address, thus causing MLD to fail. This as
tun/tap's are not able to form a link local. The fix is of course to
simply generate a link local address, eg fe80::1 + fe80::2, but as we
want to do it correctly, I thought up the following scheme, which might
be useful in other tunneling scenarios that don't have ll's.

Global IPv6    = 2001:db8:1234:5678:abcd::1/64
The link local = fe80::db8:1234:5678:abcd:1/64

To make the EUI-64 we take the global address, which is known and then
ignore the first 32bits, which describe the ISP's TLA, there is nothing
smaller. We then take the next 32bits (1234:5678:abcd) which together
with the first 32bits actually describe the /64. Assuming that the
tunnel stays inside the ISP, this should thus not cause any collisions,
and should be at least quite unique. We then append the last 16 bits
(::1) so that the remote end can use ::2. As it is not unique we clear
the unique bit 7, it is a host thus we clear bit 8 too.

Anyone has any arguments against doing it like the above or has a better
suggestion? I'll include it in the upcoming update of the AYIYA draft.

Having a LL also allows RA's to work. Which brings up another question:
One can, in some situations, run a RA Daemon on the router side of the
tunnel or even DHCP+PD (Prefix Delegation). The RA on the tunnel could
be seen as useful, though in our setups we normally expect folks to
have ::2 so we can do latency tests, at least ping6'ing ff02::1 is not
that useful as that could return multiple answers, yes even on a tunnel.
Nevertheless, the question is more with the Prefix Delegation. How does
the router know where, on which interfaces, it is allowed to activate
IPv6? I was thinking of actually enabling it, then realized that people
will get a static allocation /48 routed to the ::2 endpoint anyway,
which should not change over time and allowing them to configure their
network as they wish it to be configured. Next to that of course, not
that many end hosts/routers actually support DHCP-PD, let alone a IPv6
DHCP in the first place. I am thus more wondering if the PD setup is
actually a worthwhile deployment system when delegating a complete /48
to an enduser. Especially keeping in mind that the /48 will most likely
never change and the /48 prefix itself can easily be retrieved using
the TIC protocol.

Greets,
 Jeroen

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Colm MacCarthaigh <[email-masked]>
Date: Mon, 31 Jan 2005 17:34:49 +0000

On Mon, Jan 31, 2005 at 05:54:30PM +0100, Jeroen Massar wrote:
> To make the EUI-64 we take the global address, 

EUI-64 is different from an interface-token, EUI-64 is an ethernet
specific algorithim for deriving 64-bit long interface tokens.

> which is known and then
> smaller. We then take the next 32bits (1234:5678:abcd)

That's 48 bits, not 32 :) And your description doesn't match up with the
example above at all. It seems more like you skip the first 16 bits
(2001) and then include the next 64 bits. 

> which togetherwith the first 32bits actually describe the /64.
> Assuming that the tunnel stays inside the ISP, this should thus not
> cause any collisions, and should be at least quite unique. We then
> append the last 16 bits (::1) so that the remote end can use ::2. As
> it is not unique we clear the unique bit 7, it is a host thus we clear
> bit 8 too.
> 
> Anyone has any arguments against doing it like the above or has a
> better suggestion? I'll include it in the upcoming update of the AYIYA
> draft.

It seems overly complicated. Global uniqueness is a non-requirement of
link-local addresses, I can't see why this would change when using
tunnel interfaces.

It's not clear from your description whether the IPv6 global unicast 
addresses you have are the ones you later intend to apply to the
tunnel interfaces themselves or are the tunnel endpoints for a 6-in-6
tunnel.

For tunnel's, it's common to use the underlying protocol identifier
as the interface ID. For example for a protocol 41 6-over-4 tunnel,
using the IPv4 address is common:

	fe80::c101:c33d

for example. This kind of approach seems much more inline with the idea
behind link-local addresses (at least to me anyway). For 6-over-6
ayiya, I'd just use ::1, ::2 and so on, but that's me.

-- 
Colm MacCárthaigh                        Public Key: [email-masked]

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 31 Jan 2005 19:14:22 +0100

> specific algorithim for deriving 64-bit long interface tokens.

s/EUI-64/Interface Identifier/

> (2001) and then include the next 64 bits. 

Oops, cut&paste peepup from the old code, indeed mixed it up the first
time, caused by the 48/64 border ;)

Retry:

global = 2001:0db8:1234:5678:    :    :    :0001 / 64
local  = fe80:    :    :    :0db8:1234:5678:0001 / 64

Skip the first 16 bits, use the next 48bits, use the last 16 bits.

> tunnel interfaces themselves or are the tunnel endpoints for a 6-in-6

The global address is for the inner tunnel, thus this applies for both
6-in-6 and 6-in-4.

> using the IPv4 address is common:

Correct, but what if you don't know the IPv4 address? Which I don't know
in my case. The global IPv6 address is unique and won't change/is
stable, which is mentioned in 2373 to be one of the things one should
use.

> ayiya, I'd just use ::1, ::2 and so on, but that's me.

That indeed works, but then one has fe80::1, say a hundred times on the
same machine, which is for debugging purposes also not very handy.

Greets,
 Jeroen

---

From: Colm MacCarthaigh <[email-masked]>
Date: Mon, 31 Jan 2005 21:54:37 +0000

> stable, which is mentioned in 2373 to be one of the things one should

In order to construct a stable tunnel, there has to be *some* kind of
stable endpoint identifier ;) In the case of ayiya, this seems to be a
complex combination of source address and the optional "identity" field,
which varies between 0 and 256 bytes in size :/

> same machine, which is for debugging purposes also not very handy.

Maybe in the case of ayiya best practise would be to advise such
operators to use identities that can double up as interface identifiers
(a 32-bit integer will happily suffice) ?