Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?

[Ole Troan <[e-mail]>]

> Why is this thread even a thing?!
> 
> There is no issue here.

Indeed, the sort of self flagellation shown here serves no purpose.

Please stop posting on this thread as well as on any topic along the same vein. 

There are hundreds of participants on this list. Not only does this cost people’s time, it also limits this mailing list from being used for real relevant work. 

Ole,
6man co-chair. 


> 
>> On Mon, 10 Jun 2019 at 09:43, Yucel Guven <[e-mail]> wrote:
>> RFC 4291 sec.2.5.6  does NOT define a range. 10 bits are fixed, 54 bits are zero, and the remaining 64 bits are for interface ID, that's all.
>> 
>> The topic of this thread/chain is: "Is 1111 1110 10 equal to 0xfe80 or 0x3fa?"
>> If you want to make comparison, you must take care of all 128 bits of the 0xfe80,
>> but not only a part of it.
>> In fact it should be written as '0xfe800000000000000000000000000000'
>> because it's a one complete number.
>>  
>> 1111: this is 'f'
>> 1110: this is 'e'
>> 10??: Why do you take only two bits? Your answer will be: "Because it's /10".
>> 
>> That approach is not true when you convert the number back to hexadecimal notation.
>> You MUST think/care of ALL the 128bits, not only a part of it,
>> otherwise you destroy/change the original number.
>> 
>> Reg.'s
>> Yucel
>> 
>>> On Mon, Jun 10, 2019 at 6:09 PM 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
> --------------------------------------------------------------------