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

Le 10/06/2019 à 19:42, Yucel Guven a écrit :
> RFC 4291 sec.2.5.6  does NOT define a range.

IANA defines the range.  IANA says fe80::/10 and does not say 54 reset bits.

Some people say that IANA allocates and RFC reserves, or vice-versa.  It 
is not clearer.

Ideally RFC would talk fe80::/10 forever set in stone, and IANA would 
allocate fe80::/64 (54 reset bits) for the current use.

Alex

  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) <dmudric@avaya.com 
> <mailto:dmudric@avaya.com>> wrote:
> 
>     ____
> 
>     __
> 
>     ____
> 
>     __
> 
>     *From:* Yucel Guven <yucel.guven@gmail.com
>     <mailto:yucel..guven@gmail.com>>
>     *Sent:* Monday, June 10, 2019 12:47 PM
>     *To:* Mudric, Dusan (Dusan) <dmudric@avaya.com
>     <mailto:dmudric@avaya.com>>
>     *Cc:* Tom Herbert <tom@herbertland.com
>     <mailto:tom@herbertland.com>>; ipv6@ietf.org <mailto:ipv6@ietf.org>
>     *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)
>     <dmudric@avaya.com <mailto:dmudric@avaya.com>> wrote:____
> 
>     ____
>     __
> 
>          > On Friday, June 7, 2019 at 3:48 PM Tom Herbert
>          > <tom@herbertland.com <mailto:tom@herbertland.com>> wrote
>          > >
>          > > >
>          > > > Message: 3
>          > > > Date: Fri, 7 Jun 2019 10:53:28 -0700
>          > > > From: Fred Baker <fredbaker.ietf@gmail.com
>         <mailto:fredbaker.ietf@gmail.com>>
>          > > > To: Alexandre Petrescu <alexandre.petrescu@gmail.com
>         <mailto:alexandre.petrescu@gmail.com>>
>          > > > Cc: IPv6 <ipv6@ietf.org <mailto:ipv6@ietf.org>>
>          > > > Subject: Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?
>          > > > Message-ID:
>         <A722E202-7671-4111-BA92-8A67B3D3B924@gmail.com
>         <mailto:A722E202-7671-4111-BA92-8A67B3D3B924@gmail.com>>
>          > > > 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
>         ipv6@ietf.org <mailto:ipv6@ietf.org>
>         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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 