Re: IPv6 Link Local Addresses

[Alexandre Petrescu <[e-mail]>]

Le 10/06/2019 à 18:44, Bob Hinden a écrit :
> Hi,
> 
> RFC4291 defines Link Local Address as:
> 
>   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.
> 
> 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.

Bob,

The RFC4291 link local addresses have a 10 bit prefix and 54bits of 
zero.  That is fe80::/64.

The IANA allocation of IPv6 link-local addresses is fe80::/10.

 > fe80::/10 	Link-Scoped Unicast 	[RFC3513][RFC4291] 	

In that sense, the IANA definition and the RFC4291 differ with respect 
to the definition of link-local addresses.

fe80::/10 and fe80::/64 are not the same thing.

Alex

> 
> Bob
> 
> 
> 
>> On Jun 10, 2019, at 9:08 AM, Mudric, Dusan (Dusan) <[e-mail]> wrote:
>>
>>   
>>
>>   
>>
>> From: Yucel Guven <[e-mail]>
>> Sent: Monday, June 10, 2019 12:47 PM
>> To: Mudric, Dusan (Dusan) <[e-mail]>
>> Cc: Tom Herbert <[e-mail]>; [e-mail]
>> Subject: Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?
>>
>>   
>>
>> No need to define as a range.
>>
>> When you specify the prefix-length, it already defines a range.
>>
>> e.g. FE80::/10 (absolutely not  FE8::/10)  has the range of
>>
>> fe80:0000:0000:0000::/10 - febf:ffff:ffff:ffff::/10
>>
>> [Dusan] I agree that FE80::/10 is the FE80::/10 – FEBF::/10 range. However, it is not define like a range in RFC 4291 and if often misinterpreted as just one value of FE80:0000:0000:0000. The question is how to write it to make it clear this definition is a range?
>>
>>   
>>
>> https://tools.ietf.org/html/rfc4291#section-2.5.6 defines LL as the address with 64 bit FE80:0000:0000:0000 prefix, not as the fe80:0000:0000:0000::/10 - febf:ffff:ffff:ffff::/10 range. There are applications that need more flexibility for the LL prefix, like draft-petrescu-6man-ll-prefix-len. For these applications, FE80::/10 would be defined as LL identifier, not a prefix. The LL prefix would start with LL identifier and can have a variable length.
>>
>>   
>>
>> Is there any strong reason to keep 54 bits of zeros in this definition, other than backward compatibility?
>>
>>     |   10     |
>>
>>     |  bits    |         54 bits         |          64 bits           |
>>
>>     +----------+-------------------------+----------------------------+
>>
>>     |1111111010|           0             |       interface ID         |
>>
>>     +----------+-------------------------+----------------------------+
>>
>>   
>>
>>   
>>
>> Reg.'s
>>
>> Yucel
>>
>>   
>>
>> On Mon, Jun 10, 2019 at 3:58 PM Mudric, Dusan (Dusan) <[e-mail]> wrote:
>>
>>> On Friday, June 7, 2019 at 3:48 PM Tom Herbert
>>> <[e-mail]> wrote
>>>>
>>>>>
>>>>> Message: 3
>>>>> Date: Fri, 7 Jun 2019 10:53:28 -0700
>>>>> From: Fred Baker <[e-mail]>
>>>>> To: Alexandre Petrescu <[e-mail]>
>>>>> Cc: IPv6 <[e-mail]>
>>>>> Subject: Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?
>>>>> Message-ID: <[e-mail]>
>>>>> Content-Type: text/plain; charset="us-ascii"
>>>>>
>>>>>
>>>>>
>>>>> If I have prefix fe80::/10, as described in RFC 4291, the next bit
>>>>> is bit 11. Doing the same subdivision of the prefix is fe80::/11 and
>>> fea0::/11.
>>>> [Dusan] The hexadecimal definition for LL address is not syntactically
>>> correct. The binary 10 bit prefix 1111111010 cannot be presented as
>>> hexadecimal FE80::/10. It is rather a range FE80::/10 - FEBF::/10. In this
>>> notation, FE80::/10 = FEBF::/10,  because the first 10 bits are equal and other
>>> 6 should be ignored. 111 1111010 can be defined as FE80::/10 only if every
>>> time it is also mentioned that the trailing 6 bits are all zero.
>>>
>>> By that logic, we'd have to mention that the trailing 118 bits are zero.  E.g.
>>> FE80::/10 == FEBD:F676:BBBB:C654:FEBD:F676:BBBB:C654/10
>>> also. It's obviously convenient canonical notication to express all the trailing
>>> bits as zeroes for a prefix, but not required. For instance, ifconfig shows my
>>> host address as fe80::ac2f:ea58:94a:438/64 which in one string indicates both
>>> a fully qualified address and it's prefix bits.
>> [Dusan] In this example fe80::ac2f:ea58:94a:438/64 is LL address with 0xfe80 0x0000 0x0000 0x0000 prefix. Based on LL prefix definition, this LL address can have a value of feab::ac2f:ea58:94a:438/64 and still have the binary 10 bit prefix 1111111010
>>
>> May be LL address can be defined in hex notation as a range FE8::/10 - FEB::/10? This range always has the same well know LL identifier, the binary 10 bit prefix 1111111010.
>>
>>>
>>> Tom
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [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
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>