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

["Mudric, Dusan (Dusan)" <[e-mail]>]

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]<mailto:[e-mail]>> wrote:
> On Friday, June 7, 2019 at 3:48 PM Tom Herbert
> <[e-mail]<mailto:[e-mail]>> wrote
> >
> > >
> > > Message: 3
> > > Date: Fri, 7 Jun 2019 10:53:28 -0700
> > > From: Fred Baker <[e-mail]<mailto:[e-mail]>>
> > > To: Alexandre Petrescu <[e-mail]<mailto:[e-mail]>>
> > > Cc: IPv6 <[e-mail]<mailto:[e-mail]>>
> > > Subject: Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?
> > > Message-ID: <[e-mail]<mailto:[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]<mailto:[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=>
--------------------------------------------------------------------