Re: encoding link ID in link-local addrs (Re: about violation of standards)

[Gyan Mishra <[e-mail]>]

Suresh & Alexandre 

There are many implementations worldwide that I have been involved in deployment of IPv6 using a standard architecture that I deploy to all my customers and that involves setting the station id on the link local address so that the next hop is more intuitive and easily recognizable that it’s your local next hop since by default all routers and hosts set the station id to EUI64 format FFFE big stuff into the MAC address between the 3rd and 4th octet which is “non intuitive”

So the IPv6 addressing RFC 4291 states the 1st 10 bits used for fe80 and the next 54 bits must be set to 0 which covers the 64 bit prefix length so the entire station id 64 bits is open to be modified and changed as the end user desires on any platform and that is following the current RFC standard.  

So in Alexandre scenario with BSD setting the LL to FE80::1 would be fine but if you did fe80:1::1 that would be setting 1s in the all 0s 54 bit field of the station id which is not allowed.

So as far a variable link local address I am in favor of variable and you have the entire 64 bit station id to modify which is fine but I am completely not in favor of violating the current standard of writing into the 54 bit all 0s portion of the network prefix.

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         |
   +----------+-------------------------+----------------------------+
   Link-Local addresses are designed to be used for addressing on a
   single link for purposes such as automatic address configuration,
   neighbor discovery, or when no routers are present.
   Routers must not forward any packets with Link-Local source or
   destination addresses to other links.


Sent from my iPhone

> On Apr 19, 2019, at 12:25 PM, 神明達哉 <[e-mail]> wrote:
> 
> At Fri, 19 Apr 2019 07:00:01 +0000,
> "Pascal Thubert (pthubert)" <[e-mail]> wrote:
> 
> > While I completely object with Alexandre’s argument I tend to agree with the end goal.
> > 
> > Some functions in the router are complex to implement because same value for a link local address appears on multiple interfaces.
> 
> Yeah, I see that motivation.  The generic/usual answer of mine to that
> kind of problem is to use the sockaddr_in6::sin6_scope_id (or anything
> similar to it for a non-POSIX platform) and the extended textual
> format for scoped addresses as described in RFC4007.  But I can
> imagine there are cases where they are not enough and/or applicable.
> 
> So...
> 
> > It would be useful to be able to encode an abstract interface ID somewhere in the /64. Legacy 00 would mean unspecified...
> 
> (As a co-author of RFC4007 I can't help correcting it to "link ID"
> instead of "interface ID" but:-)... yes, I can imagine we might reach
> some consensus of using some portion of the 128-bit space to encode
> that information.  But, that will require a lot of considerations,
> including
> 
> - whether the goal is really impossible to achieve with currently
>   available tools
> - especially if the first answer is something like "it can, but it's
>   not convenient", then whether the goal really justifies to consume
>   a particular space of the finite resource of address space
> - whether it has to be inside the upper 64 bits (or in more general,
>   inside the "subnet prefix" part).  If it has to be so, whether it
>   has to be within the first 32 bits (if not, at least it doesn't
>   conflict with the BSD implementation).
> - if, like draft-petrescu-6man-ll-prefix-len suggests, the encoded ID
>   is the same for all nodes in the link, how we assign those IDs and
>   how we ensure their uniqueness, how each node knows the ID on
>   generating addresses, etc.
> 
> When I said "I'm open to discussion", I meant I'm willing to discuss
> these matters.  Of course, since there are so many open questions, I'd
> expect it to take quite a long time, and I can't say at this point
> whether I support the eventual proposal that the WG might come up
> with, or whether we can really expect any WG-wide consensus..  I'm now
> clarifying the intent, as it didn't seem to be clear enough.
> 
> --
> JINMEI, Tatuya
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------