Re: IPv6 Link Local Addresses [was Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?]

[Dennis Ferguson <[e-mail]>]

> On Jun 10, 2019, at 17:06, Fred Baker <[e-mail]> wrote:
> 
> I think I could argue it either way. Your option #1 assumes that the address is local (an interesting assumption in the context of RFC 4943), which would be consistent with a link-local address, which this address isn't - it's site-local if anything, and site-local is deprecated. Your option #2 assumes that the router knows where to find it, or will drop it if it doesn't, which seems as safe a safe bet as any. The only real question the operator might ask is "why in the world are you sending me these packets?”

I’m assuming I have a default router so the context of RFC 4943 isn’t obviously relevant here.

The site-local addresses aren’t deprecated, only their formerly defined forwarding behavior is. RFC 4291 says

   Site-Local addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |         64 bits            |
   +----------+-------------------------+----------------------------+
   |1111111011|        subnet ID        |       interface ID         |
   +----------+-------------------------+----------------------------+

   The special behavior of this prefix defined in [RFC3513] must no
   longer be supported in new implementations (i.e., new implementations
   must treat this prefix as Global Unicast).

so a site-local address, should you happen to see one, is now forwarded as a global unicast address and option 2. would definitely be correct. Note, however, that the 10 bits at the left in the picture are not the 10 high order bits of fe80:1::1 so I don’t understand why you would call the latter “site local”.

> If anything, I think I might suggest as a third option an "address whose usage is undefined", and discarding it because you don't know what else to do.

The thing is that this bit of 4291 Section 2.4

      Address type         Binary prefix        IPv6 notation   Section
      ------------         -------------        -------------   -------
      Unspecified          00...0  (128 bits)   ::/128          2.5.2
      Loopback             00...1  (128 bits)   ::1/128         2.5.3
      Multicast            11111111             FF00::/8        2.7
      Link-Local unicast   1111111010           FE80::/10       2.5.6
      Global Unicast       (everything else)

divides the entire address space into just 5 "buckets of forwarding behavior” (with some sub-buckets for multicast scopes), none of which is “address whose usage is undefined”. My forwarding path knows what to do with destinations in each of those buckets and those 5 buckets cover the entire address space.

If you think there should be a brand new 6th bucket for “address whose usage is undefined” could you please write an update to the table above describing it so we all could know that? An assertion about what fe80:1::1 isn’t is useless unless accompanied by an assertion about what fe80:1::1 is instead, and if what it is isn’t one of the five buckets above it is brand new invention.

Dennis Ferguson



> 
>> On Jun 10, 2019, at 11:18 AM, Dennis Ferguson <[e-mail]> wrote:
>> 
>> 
>>> On Jun 10, 2019, at 12:44, Bob Hinden <[e-mail]> wrote:
>>> 
>>> This means that link local addresses have a 10 bit prefix (1111111010) followed by 54 bits of zeros.  That is it, nothing more.   Address with different prefixes or with a 1111111010 prefix followed by non-zero 54 bits are not link local addresses.
>>> 
>>> This is not ambiguous.
>> 
>> So if an application asks my implementation to send a packet addressed to fe80:1::1 out a particular link what should the implementation do with it? It seems like there are only 3 choices:
>> 
>>  1. Run ND on that link to see if it can find a neighbor there with that address to send the packet to.
>> 
>>  2. Send the packet to the current default router.
>> 
>>  3. Something else (what?).
>> 
>> I had though 1. was the answer since that is what is done with packets addressed to link-local unicast destinations (which is what that address is according to RFC4191 section 2.4), but that now seems to be ambiguous.
>> 
>> Dennis Ferguson
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------------------
> Victorious warriors win first and then go to war,
> Defeated warriors go to war first and then seek to win.
>     Sun Tzu
>