Re: Standardized IPv6 ULA from PublicKey

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Roman Mamedov <rm@romanrm.net> writes:

> On Mon, 29 Jun 2020 13:03:40 +0200
> Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>> Eh? This is specified pretty clearly in RFC4291, section 2.1:
>
> It also says:
>
> -----
>
> 2.5.6.  Link-Local IPv6 Unicast Addresses
>
>    Link-Local addresses are for use on a single link.  Link-Local
>    addresses have the following format:
>
>    |   10     |
>    |  bits    |         54 bits         |          64 bits           |
>    +----------+-------------------------+----------------------------+
>    |1111111010|           0             |       interface ID         |
>    +----------+-------------------------+----------------------------+
>
>
> -----
>
> So should we also follow the designated format for link-locals, or
> accept that WG's case differs from what they had in mind in those
> sections.

In general I'd say that deviating from the RFC needs a good reason.
Expanding the number of bits we can use for the identifier may be a good
reason to expand the LL interface ID width (although I'm not actually
too worried about collisions even if we only use 64 bits). I have yet to
hear a good reason for not just having LL addresses enabled by default :)

> That the "interface" is a special one, with a "link" that doesn't
> function as other kinds of links do, that there's no "neighbour" per
> se to contact by an all-neighbour multicast for instance, no mechanism
> for the "all routers" multicast to work, etc (i.e. all of what the LLs
> were intended to support).

But it's not special. If wireguard is setup as a single point-to-point
link (allowed-ip ::/0), "all-neighbour multicast" and "broadcast"
already works. If there are multiple peers on the interface it doesn't,
but that is also a bug that should be fixed as far as I'm concerned.

> To be clear I'm not against adding LLs, just that "the RFC says so"
> shouldn't be considered the main argument for that when it comes to
> WG.

Oh sure, to me the main argument is also "because it's useful" rather
than "because the RFC says so". But in my view "because it's useful" is
also the reason that requirement is in the RFC in the first place, so
really it amounts to the same thing.

-Toke