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

[Alexandre Petrescu <[e-mail]>]

Le 21/04/2019 à 02:23, Gyan Mishra a écrit :
[...]
> That being said the fe80:1::1 can be coded on both Linux host and a 
> CISCO router with Linux kernel under the hood but that does not make it 
> correct or valid that we should now change the RFC 4291 to allow that to 
> happen.

Noted.

By 'now' do you mean 'not'?

I will add in the draft that Cisco also supports fe80:1::1.  I think I 
forgot that, but now that you say it I trust it too.

> I don’t see any justification to allowing the 54 bits in the network 64 
> bit portion of the link local address to be changed from all 0s.

I dont understand you.

You say fe80:1::1 works on Cisco, but then you say you seee no 
justification to allow the 54bits to change from 0.  The first 1 in 
fe80:1::1 means a change from 0.

So, do you mean Cisco is wrong?

Or do you mean such things are wrong and the RFC is right?

I do not understand you.

Let me rate limit my messages.

Alex

> 
> Please respond back to this email thread if you feel differently and 
> also respond if you agree.
> 
> Thank you
> 
> Gyan
> 
> Sent from my iPhone
> 
> On Apr 20, 2019, at 7:34 PM, Gyan Mishra <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>> 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] 
>> <mailto:[e-mail]>> wrote:
>>
>>> At Fri, 19 Apr 2019 07:00:01 +0000,
>>> "Pascal Thubert (pthubert)" <[e-mail] 
>>> <mailto:[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] <mailto:[e-mail]>
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>