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

[Erik Kline <[e-mail]>]

Why is this thread even a thing?!

There is no issue here.

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] <[e-mail]>>
>> Sent: Monday, June 10, 2019 12:47 PM To: Mudric, Dusan (Dusan)
>> <[e-mail] <[e-mail]>> Cc: Tom Herbert
>> <[e-mail] <[e-mail]>>; [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
>> <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] <[e-mail]>> wrote: > On Friday, June 7, 2019 at
>> 3:48 PM Tom Herbert > <[e-mail] <[e-mail]>> wrote > >
>> > > > > > > Message: 3 > > > Date: Fri, 7 Jun 2019 10:53:28 -0700 > > >
>> From: Fred Baker <[e-mail] <[e-mail]>> > >
>> > To: Alexandre Petrescu <[e-mail]
>> <[e-mail]>> > > > Cc: IPv6 <[e-mail]
>> <[e-mail]>> > > > Subject: Re: Is 1111 1110 10 equal to 0xfe80 or
>> 0x3fa? > > > Message-ID: <[e-mail]
>> <[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] <[e-mail]>
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=BRDXJNikWmU_24IGmmgxydVbBKn0npUsCUzJlQGjN50&s=KXz9utU1mhnWkWv2-Qq1lkcJ-zsSoTl5OlPaaUOPd-Y&e=>
>> -------------------------------------------------------------------- *
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>