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

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 7 Jun 2019 19:29:50 +0000

> 
> Message: 3
> Date: Fri, 7 Jun 2019 10:53:28 -0700
> From: Fred Baker <[email-masked]>
> To: Alexandre Petrescu <[email-masked]>
> Cc: IPv6 <[email-masked]>
> Subject: Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?
> Message-ID: <[email-masked]>
> 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. But, it is very common to say FE80::/10 is LL prefix, without mentioning the 6 trailing bits to be zeros.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 7 Jun 2019 12:47:53 -0700

On Fri, Jun 7, 2019 at 12:30 PM Mudric, Dusan (Dusan) <[email-masked]> wrote:
> [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.

Tom

>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 9 Jun 2019 17:50:38 +0200

Le 07/06/2019 à 21:29, Mudric, Dusan (Dusan) a écrit :
>> 
>> Message: 3 Date: Fri, 7 Jun 2019 10:53:28 -0700 From: Fred Baker
>> <[email-masked]> To: Alexandre Petrescu
>> <[email-masked]> Cc: IPv6 <[email-masked]> Subject:
>> Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa? Message-ID:
>> <[email-masked]> 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.

I fully agree.  That is what we should be talking about: a range.  The 
fe80::/10 to febf::/10 is the prefix of link local addresses.

The difficulty (not able to say just one hextet fe80, but a range from 
one hextet to another) is due  to the IPv6 notation, the textual 
representation of IPv6 addresses.

It is still strange to say that the bit pattern 1111 1110 10 can not be 
represented in hexa.  Or maybe there is a need of a new base.

> In this notation, FE80::/10 = FEBF::/10,  because the
> first 10 bits are equal and other 6 should be ignored.

I agree.

> 111 1111010
> can be defined as FE80::/10 only if every time it is also mentioned
> that the trailing 6 bits are all zero.

I agree.  And the trailing 6 bits are not all zero.  RFC 4291 makes them 
to be 0, but IANA allocation does not make them to be 0.

> But, it is very common to say
> FE80::/10 is LL prefix, without mentioning the 6 trailing bits to be
> zeros.

I agree.  Whoever I spoke to about LL was saying they are FE80.

On another hand, there is a similar difficulty with fc and fd in ULA 
addresses.  In the v6ops WG, and in the ULA RFC, there seems to be a 
clearer idea about the ULA notation.

In private I am also told to get mind around around CIDR notation.

Alex

> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: James R Cutler <[email-masked]>
Date: Sun, 9 Jun 2019 11:56:48 -0400

> On Jun 9, 2019, at 11:50 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> I fully agree.  That is what we should be talking about: a range.  The fe80::/10 to febf::/10 is the prefix of link local addresses.
> 
> The difficulty (not able to say just one hextet fe80, but a range from one hextet to another) is due  to the IPv6 notation, the textual representation of IPv6 addresses.
> 
> It is still strange to say that the bit pattern 1111 1110 10 can not be represented in hexa.  Or maybe there is a need of a new base.
> 
> I agree.  And the trailing 6 bits are not all zero.  RFC 4291 makes them to be 0, but IANA allocation does not make them to be 0.
> 
> On another hand, there is a similar difficulty with fc and fd in ULA addresses.  In the v6ops WG, and in the ULA RFC, there seems to be a clearer idea about the ULA notation.
> 

	Aye, there’s the nub.
> 
> Alex
> 
>> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
> 
> 
James R. Cutler
[email-masked]
GPG keys: hkps://hkps.pool.sks-keyservers.net

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 10 Jun 2019 13:58:26 +0000

> On Friday, June 7, 2019 at 3:48 PM Tom Herbert
> <[email-masked]> wrote
> >
> > >
> > > Message: 3
> > > 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.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 10 Jun 2019 08:04:25 -0700

> 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.

FE8::/10 - FEB::/10, only three digits in IPv6 notation? So wouldn't
FE8::/10 == 0FE8::/10 == 0FE0::/10 == FE0::/10. I don't think that's
right.

Tom

---

From: Yucel Guven <[email-masked]>
Date: Mon, 10 Jun 2019 18:06:02 +0200

FE8::/10 ?  It is different from FE80::/10. Did you mistype?

Writing the prefix 'FE8::/10' is equal to the prefix '0FE8::/10',  which
are completely different.

On Mon, Jun 10, 2019 at 3:58 PM Mudric, Dusan (Dusan) <[email-masked]>
wrote:

> zero.  E.g.
> [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
> >

---

From: Yucel Guven <[email-masked]>
Date: Mon, 10 Jun 2019 18:25:48 +0200

Tom,
FE8::/10 == 0FE8::/10  up to here OK, but
If prefix-lengh is 10 bits, then it should be:   FE8::/10 == 0FE8::/10 ==
0FC0::/10 == FC0::/10

Right?

On Mon, Jun 10, 2019 at 5:04 PM Tom Herbert <[email-masked]> wrote:

> and
> syntactically
> the trailing

---

From: Yucel Guven <[email-masked]>
Date: Mon, 10 Jun 2019 18:46:39 +0200

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

Reg.'s
Yucel

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 10 Jun 2019 16:08:55 +0000

From: Yucel Guven <[email-masked]>
Sent: Monday, June 10, 2019 12:47 PM
To: Mudric, Dusan (Dusan) <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]
Subject: Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?

[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) <[email-masked]<mailto:[email-masked]>> wrote:
> <[email-masked]<mailto:[email-masked]>> wrote
> >
> > >
> > > Message: 3
> > > From: Fred Baker <[email-masked]<mailto:[email-masked]>>
> > > To: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>
> > > Cc: IPv6 <[email-masked]<mailto:[email-masked]>>
> > > Message-ID: <[email-masked]<mailto:[email-masked]>>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
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=>
--------------------------------------------------------------------

---

From: Yucel Guven <[email-masked]>
Date: Mon, 10 Jun 2019 19:42:45 +0200

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) <[email-masked]>
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *   From: Yucel Guven <[email-masked] <[email-masked]>>
> Sent: Monday, June 10, 2019 12:47 PM To: Mudric, Dusan (Dusan)
> <[email-masked] <[email-masked]>> Cc: Tom Herbert
> <[email-masked] <[email-masked]>>; [email-masked] <[email-masked]>
> 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.
> 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           |
> Reg.'s Yucel   On Mon, Jun 10, 2019 at 3:58 PM Mudric, Dusan (Dusan)
> <[email-masked] <[email-masked]>> wrote: > On Friday, June 7, 2019 at
> 3:48 PM Tom Herbert > <[email-masked] <[email-masked]>> wrote > >
> > > > > > > Message: 3 > > > Date: Fri, 7 Jun 2019 10:53:28 -0700 > > >
> From: Fred Baker <[email-masked] <[email-masked]>> > >
> > To: Alexandre Petrescu <[email-masked]
> <[email-masked]>> > > > Cc: IPv6 <[email-masked]
> <[email-masked]>> > > > Subject: Re: Is 1111 1110 10 equal to 0xfe80 or
> 0x3fa? > > > Message-ID: <[email-masked]
> <[email-masked]>> > > > 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 >
> > 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.
> 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.
> 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 [email-masked] <[email-masked]>
> <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=>
> -------------------------------------------------------------------- *
>

---

From: Bob Hinden <[email-masked]>
Date: Mon, 10 Jun 2019 09:44:07 -0700

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     |

   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

> On Jun 10, 2019, at 9:08 AM, Mudric, Dusan (Dusan) <[email-masked]> wrote:
> 
>  
> 
>  
> 
> On Mon, Jun 10, 2019 at 3:58 PM Mudric, Dusan (Dusan) <[email-masked]> wrote:
>

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 10 Jun 2019 17:47:26 +0000

Sent: Monday, June 10, 2019 1:43 PM

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.
[Dusan] RFC 4291 section 2.5.6 clearly defines the LL prefix value. If there is no comment that 54 bits following 10 bit LL identifier are zeros, like in section 2.4, which RFC defines the meaning on FE80::/10? Can FE80::/10 stand on its own and be clearly interpreted based on the existing RFCs?

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) <[email-masked]<mailto:[email-masked]>> wrote:

From: Yucel Guven <[email-masked]<mailto:[email-masked]>>
Sent: Monday, June 10, 2019 12:47 PM
To: Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>>
Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?

https://tools.ietf.org/html/rfc4291#section-2.5.6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4291-23section-2D2.5.6&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Dm0yrColGfouwgn9pkesvO1Cps-EFn409_tRHPcKjGY&s=BbJ9ig6nTgOxyAm2iyQJBmjoBuKDC38eSMUunZJngbQ&e=> 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.

Reg.'s
Yucel

---

From: Erik Kline <[email-masked]>
Date: Mon, 10 Jun 2019 10:53:56 -0700

Why is this thread even a thing?!

There is no issue here.

On Mon, 10 Jun 2019 at 09:43, Yucel Guven <[email-masked]> 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.
>
>> *   From: Yucel Guven <[email-masked] <[email-masked]>>
>> definition is a range?   https://tools.ietf.org/html/rfc4291#section-2.5..6

---

From: Dennis Ferguson <[email-masked]>
Date: Mon, 10 Jun 2019 14:18:13 -0400

> On Jun 10, 2019, at 12:44, Bob Hinden <[email-masked]> wrote:
> 

So if an application asks my implementation to send a packet addressed to fe80:1::1 out a particular link what should the implementation do with it? It seems like there are only 3 choices:

   1. Run ND on that link to see if it can find a neighbor there with that address to send the packet to.

   2. Send the packet to the current default router.

   3. Something else (what?).

I had though 1. was the answer since that is what is done with packets addressed to link-local unicast destinations (which is what that address is according to RFC4191 section 2.4), but that now seems to be ambiguous.

Dennis Ferguson

---

From: Ross Finlayson <[email-masked]>
Date: Mon, 10 Jun 2019 12:35:41 -0700

> On Jun 10, 2019, at 10:53 AM, Erik Kline <[email-masked]> wrote:
> 

Agreed.  The fact that this thread has lasted so long (or even, that it existed at all) is an illustration of just how far the quality of the IETF has fallen...

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Jun 2019 22:03:23 +0200

> Why is this thread even a thing?!

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, Jun 10, 2019 at 6:09 PM Mudric, Dusan (Dusan) <[email-masked]> wrote:
>>>  
>>> 
>>>  
>>> 
>>> 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.
>>> 
>>>  
>>>

---

From: Fred Baker <[email-masked]>
Date: Mon, 10 Jun 2019 14:06:09 -0700

I think I could argue it either way. Your option #1 assumes that the address is local (an interesting assumption in the context of RFC 4943), which would be consistent with a link-local address, which this address isn't - it's site-local if anything, and site-local is deprecated. Your option #2 assumes that the router knows where to find it, or will drop it if it doesn't, which seems as safe a safe bet as any. The only real question the operator might ask is "why in the world are you sending me these packets?"

If anything, I think I might suggest as a third option an "address whose usage is undefined", and discarding it because you don't know what else to do.

> On Jun 10, 2019, at 11:18 AM, Dennis Ferguson <[email-masked]> wrote:
> 
> 

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Dennis Ferguson <[email-masked]>
Date: Mon, 10 Jun 2019 22:56:02 -0400

> On Jun 10, 2019, at 17:06, Fred Baker <[email-masked]> wrote:
> 
> I think I could argue it either way. Your option #1 assumes that the address is local (an interesting assumption in the context of RFC 4943), which would be consistent with a link-local address, which this address isn't - it's site-local if anything, and site-local is deprecated. Your option #2 assumes that the router knows where to find it, or will drop it if it doesn't, which seems as safe a safe bet as any. The only real question the operator might ask is "why in the world are you sending me these packets?”

I’m assuming I have a default router so the context of RFC 4943 isn’t obviously relevant here.

The site-local addresses aren’t deprecated, only their formerly defined forwarding behavior is. RFC 4291 says

   Site-Local addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |         64 bits            |
   +----------+-------------------------+----------------------------+
   |1111111011|        subnet ID        |       interface ID         |
   +----------+-------------------------+----------------------------+

   The special behavior of this prefix defined in [RFC3513] must no
   longer be supported in new implementations (i.e., new implementations
   must treat this prefix as Global Unicast).

so a site-local address, should you happen to see one, is now forwarded as a global unicast address and option 2. would definitely be correct. Note, however, that the 10 bits at the left in the picture are not the 10 high order bits of fe80:1::1 so I don’t understand why you would call the latter “site local”.

> If anything, I think I might suggest as a third option an "address whose usage is undefined", and discarding it because you don't know what else to do.

The thing is that this bit of 4291 Section 2.4

      Address type         Binary prefix        IPv6 notation   Section
      ------------         -------------        -------------   -------
      Unspecified          00...0  (128 bits)   ::/128          2.5.2
      Loopback             00...1  (128 bits)   ::1/128         2.5.3
      Multicast            11111111             FF00::/8        2.7
      Link-Local unicast   1111111010           FE80::/10       2.5.6
      Global Unicast       (everything else)

divides the entire address space into just 5 "buckets of forwarding behavior” (with some sub-buckets for multicast scopes), none of which is “address whose usage is undefined”. My forwarding path knows what to do with destinations in each of those buckets and those 5 buckets cover the entire address space.

If you think there should be a brand new 6th bucket for “address whose usage is undefined” could you please write an update to the table above describing it so we all could know that? An assertion about what fe80:1::1 isn’t is useless unless accompanied by an assertion about what fe80:1::1 is instead, and if what it is isn’t one of the five buckets above it is brand new invention.

Dennis Ferguson

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Jun 2019 10:43:44 +0200

> I had though 1. was the answer since that is what is done with packets addressed to link-local unicast destinations (which is what that address is according to RFC4191 section 2.4), but that now se…

Let me illustrate with a typical per-interface FIB:

 fe80::/10 -> drop
 fe80::/64 -> glean
 fe80::abcd -> neighbor abcd

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 11 Jun 2019 15:04:49 +0200

>     |  bits    |         54 bits         |          64 bits           |

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

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 11 Jun 2019 13:42:23 -0400

On Tue, Jun 11, 2019 at 9:05 AM Alexandre Petrescu <
[email-masked]> wrote:

> > 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,
>
Bob et al.

Would a correct router implementation base its "must not forward" decision
on the most-significant 10 bits or most significant 64 bits?

Kerry

---

From: Erik Kline <[email-masked]>
Date: Tue, 11 Jun 2019 11:31:37 -0700

> on the most-significant 10 bits or most significant 64 bits?

IMHO, /10.

The well-known prefix on a link is the /64.

The extra empty space between the two does have its uses (
https://www.freebsd.org/doc/en/books/developers-handbook/ipv6.html#ipv6-scope-index),
even if not officially sanctioned by a document.

Kerry

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Jun 2019 11:09:33 +1200

On 12-Jun-19 06:31, Erik Kline wrote:
> 
> On Tue, 11 Jun 2019 at 10:42, Kerry Lynn <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     On Tue, Jun 11, 2019 at 9:05 AM Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>          > fe80::/10    Link-Scoped Unicast     [RFC3513][RFC4291]     
> 

Correct, IMHO, because clearly the whole of that prefix is defined as LL.

However, it might also be appropriate to log an error if the following
54 bits are non-zero, since they are specified to be zero.

     Brian

> The extra empty space between the two does have its uses (https://www.freebsd.org/doc/en/books/developers-handbook/ipv6.html#ipv6-scope-index), even if not officially sanctioned by a document.
> 
>     Kerry
>     [email-masked] <mailto:[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 12 Jun 2019 10:53:34 -0400

6MAN,

I went through this test in the lab a few months ago about verifying across
all Cisco platforms if you can specify non zero values in the all 0's field
in the Link Local prefix hardcoding the prefix and if the OSPF neighbor
would come up and it did come up in an all Cisco environment.

So the main thing this draft accomplishes in my opinion and I think is
necessary gap that it is fixing is interoperability between vendors for the
use case of making the link local intuitive for the next hop by embedding
the entire global unicast address into the iid & 54 bit 0s field.

Cisco happens to all the Link Local to be set and set all the 0s in the
prefix fe80::/10 up to 64 which is a violation of the RFC but it does allow
on all platforms and all codes.  I think we found that some unix flavors
allow the same.

So now the change to the RFC 4291 is making it official that it now can be
allowed across all platforms to help with mixed vendor environments where
you can now embedd the entire global unicast address into the station id
making the default EUI64 station-id now intuitive.

https://datatracker.ietf.org/doc/html/draft-petrescu-6man-ll-prefix-len

**This is a copy/paste from a test I did in the lab a few months ago to
prove my point**

I did a test in the lab for that one use case of making the default link
local EUI64 more intuitive in the lab and Id id a worst case scenario test
populating all the 16 bit nibbles and all hex digits within each nibble so
no :: 0's compression on a Cisco IOS XE router running 16.x code and
confirmed the OSPF neighbor still comes up even though the entire 54 bit
all 0's field per the RFC is populated in effect violating the current RFC
but because its like-like intra-vendor the OSPF adjacency forms.

So I have tested this concept and it works across all Cisco platforms IOS,
XE, XR, NXOS that you can populate the entire 54 bit all 0's field.

So the big caveat with this and justification for this draft is "mix
vendor" environment inter-operability" which is one of the reasons for the
IETF and to have RFC's and standards that allows any device from any vendor
to communicate that supports the RFC.     I think that is a MAJOR point to
add to the justification behind the draft in the use cases where on a
managed IPv6 network that the administrator can now hardcode the IPv6
address fully populating entire 54 bit subnet-id & station-id and routing
protocols will now work and OSPF, ISIS, EIGRP adjacency can now work in a
mix vendor environment.

R1

ipv6 addr fe80:1111:1111:1111:1111:1111:1111:1111 link-local

R2

ipv6 addr fe80:1111:1111:1111:1111:1111:1111:2222 link-local

R1#sh ipv6 ospf nei

            OSPFv3 Router with ID (1.1.1.1) (Process ID 6000)

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface

2.2.2.2      1   FULL/DR         00:00:35    18
GigabitEthernet1/0/2

R1#sh ipv6 ospf int g1/0/2

GigabitEthernet1/0/2 is up, line protocol is up

  Link Local Address FE80:1111:1111:1111:1111:1111:1111:1111, Interface ID
18

  Area 2.2.2.2, Process ID 6000, Instance ID 0, Router ID 1.1.1.1

  Network Type BROADCAST, Cost: 1

  SHA-1 authentication SPI 666661, secure socket UP (errors: 0)

  Transmit Delay is 1 sec, State BDR, Priority 1

  Designated Router (ID) 2.2.2.2, local address
FE80:1111:1111:1111:1111:1111:1111:2222

  Backup Designated router (ID) 1.1.1.1, local address
FE80:1111:1111:1111:1111:1111:1111:1111

  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

    Hello due in 00:00:03

  Graceful restart helper support enabled

  Index 1/5/14, flood queue length 0

  Next 0x0(0)/0x0(0)/0x0(0)

  Last flood scan length is 2, maximum is 9

  Last flood scan time is 0 msec, maximum is 1 msec

  Neighbor Count is 1, Adjacent neighbor count is 1

    Adjacent with neighbor 2.2.2.2  (Designated Router)

  Suppress hello for 0 neighbor(s)

R2#sh ipv6 ospf nei

            OSPFv3 Router with ID (2.2.2.2) (Process ID 6000)

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface

1.1.1.1   1   FULL/BDR        00:00:37    18
GigabitEthernet1/0/2

R2#sh ipv6 ospf int g1/0/2

GigabitEthernet1/0/2 is up, line protocol is up

  Link Local Address FE80:1111:1111:1111:1111:1111:1111:2222, Interface ID
18

  Area 2.2.2.2, Process ID 6000, Instance ID 0, Router ID 104.255.32.2

  Network Type BROADCAST, Cost: 1

  SHA-1 authentication SPI 666661, secure socket UP (errors: 0)

  Transmit Delay is 1 sec, State DR, Priority 1

  Designated Router (ID) 2.2.2.2, local address
FE80:1111:1111:1111:1111:1111:1111:2222

  Backup Designated router (ID) 1.1.1.1, local address
FE80:1111:1111:1111:1111:1111:1111:1111

  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

    Hello due in 00:00:05

  Graceful restart helper support enabled

  Index 1/5/14, flood queue length 0

  Next 0x0(0)/0x0(0)/0x0(0)

  Last flood scan length is 0, maximum is 7

  Last flood scan time is 0 msec, maximum is 1 msec

  Neighbor Count is 1, Adjacent neighbor count is 1

    Adjacent with neighbor 1.1.1.1  (Backup Designated Router)

  Suppress hello for 0 neighbor(s)

On Tue, Jun 11, 2019 at 4:44 AM Ole Troan <[email-masked]> wrote:

> > So if an application asks my implementation to send a packet addressed
> to fe80:1::1 out a particular link what should the implementation do with
> it? It seems like there are only 3 choices:
> >
> > I had though 1. was the answer since that is what is done with packets
> addressed to link-local unicast destinations (which is what that address is
> according to RFC4191 section 2.4), but that now seems to be ambiguous.
>

-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2019 18:26:57 +0200

Hi Gyan,

> I went through this test in the lab a few months ago about verifying across all Cisco platforms if you can specify non zero values in the all 0's field in the Link Local prefix hardcoding the prefix and if the OSPF neighbor would come up and it did come up in an all Cisco environment.  
> 
> So the main thing this draft accomplishes in my opinion and I think is necessary gap that it is fixing is interoperability between vendors for the use case of making the link local intuitive for the next hop by embedding the entire global unicast address into the iid & 54 bit 0s field.
> 
> Cisco happens to all the Link Local to be set and set all the 0s in the prefix fe80::/10 up to 64 which is a violation of the RFC but it does allow on all platforms and all codes.  I think we found that some unix flavors allow the same. 

Bias warning: I was heavily involved in one of the implementations you mention and the choice of how to implement link-local addresses.

That one vendor has chosen to allow the operator to chose if she wants to override the RFC behaviour, isn't in my view an argument for why we should change the standards.

Cheers,
Ole

> 
> So now the change to the RFC 4291 is making it official that it now can be allowed across all platforms to help with mixed vendor environments where you can now embedd the entire global unicast address into the station id making the default EUI64 station-id now intuitive.
> 
> **This is a copy/paste from a test I did in the lab a few months ago to prove my point**
> 
> I did a test in the lab for that one use case of making the default link local EUI64 more intuitive in the lab and Id id a worst case scenario test populating all the 16 bit nibbles and all hex digits within each nibble so no :: 0's compression on a Cisco IOS XE router running 16.x code and confirmed the OSPF neighbor still comes up even though the entire 54 bit all 0's field per the RFC is populated in effect violating the current RFC but because its like-like intra-vendor the OSPF adjacency forms.
>  
> So I have tested this concept and it works across all Cisco platforms IOS, XE, XR, NXOS that you can populate the entire 54 bit all 0's field.
>  
> So the big caveat with this and justification for this draft is "mix vendor" environment inter-operability" which is one of the reasons for the IETF and to have RFC's and standards that allows any device from any vendor to communicate that supports the RFC.     I think that is a MAJOR point to add to the justification behind the draft in the use cases where on a managed IPv6 network that the administrator can now hardcode the IPv6 address fully populating entire 54 bit subnet-id & station-id and routing protocols will now work and OSPF, ISIS, EIGRP adjacency can now work in a mix vendor environment.
>  
> R1
> 2.2.2.2      1   FULL/DR         00:00:35    18              GigabitEthernet1/0/2
>  
>   Link Local Address FE80:1111:1111:1111:1111:1111:1111:1111, Interface ID 18
>   Designated Router (ID) 2.2.2.2, local address FE80:1111:1111:1111:1111:1111:1111:2222
>   Backup Designated router (ID) 1.1.1.1, local address FE80:1111:1111:1111:1111:1111:1111:1111
> 1.1.1.1   1   FULL/BDR        00:00:37    18              GigabitEthernet1/0/2
>  
>   Link Local Address FE80:1111:1111:1111:1111:1111:1111:2222, Interface ID 18
>   Designated Router (ID) 2.2.2.2, local address FE80:1111:1111:1111:1111:1111:1111:2222
>   Backup Designated router (ID) 1.1.1.1, local address FE80:1111:1111:1111:1111:1111:1111:1111

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 12 Jun 2019 12:42:18 -0400

Hi Ole

My reasoning which I gave Alex in assisting in authoring the draft as what
I implemented with my IPv6 customers as our deployment standard was to have
an intuitive link local for next hop adjacencies which we embedded the
global unicast into the link local after the :: but what happened in the
original implementation 16 bits bled over into the all 0s portion of link
local and the ospf adjacencies would not come up with a Citrix Netscaler lb
in 2 arm setup so we went back to our standard realized that Citrix was
following the rfc 4291 and CISCO was not so we had to update our deployment
standard to follow the rfc for mixed vendor environment.

So in this case as some vendors like CISCO chose not to follow the rfc
while others do for the use case of intuitive next hop is the reason to
change the rfc so that the entire global unicast address can be embedded
into the link local and the 16bit or more fields don’t have to be shaved
off making the goal of intuitive next hop slightly better but still not as
desired with the restriction of the all Os field not allowed to be used.

Gyan

On Wed, Jun 12, 2019 at 12:27 PM Ole Troan <[email-masked]> wrote:

> Hi Gyan,
>
> > I went through this test in the lab a few months ago about verifying
> across all Cisco platforms if you can specify non zero values in the all
> 0's field in the Link Local prefix hardcoding the prefix and if the OSPF
> neighbor would come up and it did come up in an all Cisco environment.
> >
> Bias warning: I was heavily involved in one of the implementations you
> mention and the choice of how to implement link-local addresses.
>
> That one vendor has chosen to allow the operator to chose if she wants to
> override the RFC behaviour, isn't in my view an argument for why we should
> change the standards.
>
> Cheers,
> Ole
>
>
> >
> > So now the change to the RFC 4291 is making it official that it now can
> be allowed across all platforms to help with mixed vendor environments
> where you can now embedd the entire global unicast address into the station
> id making the default EUI64 station-id now intuitive.
> >
> > So I have tested this concept and it works across all Cisco platforms
> IOS, XE, XR, NXOS that you can populate the entire 54 bit all 0's field.
> >
> > >> 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.
> > >

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Yucel Guven <[email-masked]>
Date: Wed, 12 Jun 2019 20:37:24 +0200

I agree with Ole.

Referring with the setups in the Lab. with Cisco, or Nokia, or other vendors

should not be taken as a reference or criteria to change the standards.

This type of software modifications are generally called as 'DCR, Design
Change Request',

and requires modification/tailoring of the device software with respect to

what customer requests from vendors.

On Wed, Jun 12, 2019 at 6:43 PM Gyan Mishra <[email-masked]> wrote:

>> https://datatracker.ietf..org/doc/html/draft-petrescu-6man-ll-prefix-len
>> <https://datatracker.ietf.org/doc/html/draft-petrescu-6man-ll-prefix-len>
>>
>> > I did a test in the lab for that one use case of making the default
>> link local EUI64 more intuitive in the lab and Id id a worst case scenario
>> test populating all the 16 bit nibbles and all hex digits within each
>> nibble so no :: 0's compression on a Cisco IOS XE router running 16.x code
>> and confirmed the OSPF neighbor still comes up even though the entire 54
>> bit all 0's field per the RFC is populated in effect violating the current
>> RFC but because its like-like intra-vendor the OSPF adjacency forms.
>> >
>> IOS, XE, XR, NXOS that you can populate the entire 54 bit all 0's field..
>> >
>> > > So if an application asks my implementation to send a packet
>> addressed to fe80:1::1 out a particular link what should the implementation
>> do with it? It seems like there are only 3 choices:
>> > >
>> > > I had though 1. was the answer since that is what is done with
>> packets addressed to link-local unicast destinations (which is what that
>> address is according to RFC4191 section 2.4), but that now seems to be
>> ambiguous.
>> >

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 12 Jun 2019 17:08:06 -0400

Hi Alex

In your next update can you add comment about mix vendor interoperability in that today not all vendors abide by the RFC 4291 which has happed day 1 by Cisco and you mentioned another Linux flavor as well but now the major use case benefit the draft provides is mix vendor interoperability with vendors that don’t follow the RFC as written today and those that do which is a huge impetus for this change as well as allows the next hop for OSPF and ISIS to now be intuitive.  The gain in the intuitive next hops is deciding of the default EUI64 iid multi step process which having an intuitive next hop is the advertising node from which routes have been learned is known immediately similar to IPv4.

With respect to going to the vendor to change their behavior to follow the RFC is not necessarily the issue as being able to modify the all 0s subnet portion of the LL is a benefit for Cisco to Cisco networks so there is no reason for that to change as the next hop is now 100% intuitive as is with IPv4 in that regard and only mix environments do we have to follow the RFC for neighbor adjacencies to form.  

Which really is the major reason that the draft I think really should get consensus approval from the WG to move forward.

Thank you

Gyan

Sent from my iPhone

> On Jun 12, 2019, at 2:37 PM, Yucel Guven <[email-masked]> wrote:
> 
> I agree with Ole.
> 
> 
> This type of software modifications are generally called as 'DCR, Design Change Request',
> 
>> My reasoning which I gave Alex in assisting in authoring the draft as what I implemented with my IPv6 customers as our deployment standard was to have an intuitive link local for next hop adjacencies which we embedded the global unicast into the link local after the :: but what happened in the original implementation 16 bits bled over into the all 0s portion of link local and the ospf adjacencies would not come up with a Citrix Netscaler lb in 2 arm setup so we went back to our standard realized that Citrix was following the rfc 4291 and CISCO was not so we had to update our deployment standard to follow the rfc for mixed vendor environment.
>> 
>> So in this case as some vendors like CISCO chose not to follow the rfc while others do for the use case of intuitive next hop is the reason to change the rfc so that the entire global unicast address can be embedded into the link local and the 16bit or more fields don’t have to be shaved off making the goal of intuitive next hop slightly better but still not as desired with the restriction of the all Os field not allowed to be used.
>> 
>> Gyan
>> 
>>> > So I have tested this concept and it works across all Cisco platforms IOS, XE, XR, NXOS that you can populate the entire 54 bit all 0's field..
>>> >

---

From: Mark Smith <[email-masked]>
Date: Thu, 13 Jun 2019 14:57:57 +1000

> making the default EUI64 station-id now intuitive.

IPv6 has worked with link locals this way for more than 20 years.

There have been many deployments in that time (as an example, I've had IPv6
at home on ordinary production residential ADSL broadband for the past near
8 years). If there was a significant problem to solve with Link Local
addressing, we'd have seen it in this working group by now and solved it by
now.

IPv6 is a much more "plug-and-play" protocol than IPv4 was ever designed to
be (and inspired by the much more plug-and-play late 1980s protocols of
Appletalk and Novell's/Xerox's IPX/XNS).

That is why, for example, Link Local addresses are required on all
interfaces, are automatically generated, and are used automatically by
protocols such as OSPF and IS-IS as their next hop values. The manual
configuration of addresses on an interface to bootstrap routing is
unnecessary when it is easy to have a computer do it automatically.

We could actually make IPv4 operate that way if we wanted to.

"A dirty trick to save a couple of IPv4
addresses on a LAN link"
https://www.ausnog.net/sites/default/files/ausnog-2018/presentations/2.10.2_Mark_Smith_AusNOG2018_Lightning.pdf

Learn the IPv6 way rather than spending effort trying to change it into the
way IPv4 works.

Regards,
Mark.

---

From: Ola Thoresen <[email-masked]>
Date: Thu, 13 Jun 2019 09:01:06 +0200

On 12.06.2019 23:08, Gyan Mishra wrote:

> (...) Cisco to Cisco networks so there is no reason for that to change 
> as the next hop is now 100% intuitive as is with IPv4 in that regard 
> and only mix environments do we have to follow the RFC for neighbor 
> adjacencies to form.
>

Oh.  I thought the whole idea behind IETF was to encourage vendor 
interoperability...

Rgds.

Ola Thoresen

---

From: Yucel Guven <[email-masked]>
Date: Fri, 14 Jun 2019 20:23:58 +0200

You are interconnecting different/mixed vendors' devices in your lab.
 and saying that one vendor does not comply with or does not follow RFC,
 and trying to base it into the draft.
 I say that this approach is questionable, and not agree with you.
 Simply because it is a router software, and all type of softwares
 can easily be modified to run in expected/requested/modified way.
 This is a fact not only for vendors but also for open source softwares,
 all kinds of operating systems softwares.
 Also, you can not explicitly blame Cisco or Nokia or other vendors
 for not following the RFC. Instead, ring them and share your findings
 with the vendors, and tell them they did not follow the RFC 4291.
 I just wonder:
 1. Is your lab. run by an independent/non-profit organization?
 2. Is your lab. certified to conduct such experiments
    and to publish/share the results?
 3. Do you carry out the experiments in consent of
    or in collaboration with the vendors in question?
 One of the main purposes of so many RFCs is to provide
 information for the 'INTEROPERABILITY'
 for the worldwide Internet community.
 I am sure nobody in the list is against the discussion of RFCs.
 In fact we should obviously discuss if any issue/problem exist
 due to the content of an RFC. That's why we have drafts.
 Regards,
 Yucel

On Wed, Jun 12, 2019 at 11:08 PM Gyan Mishra <[email-masked]> wrote:

> Hi Alex
>
> In your next update can you add comment about mix vendor interoperability
> in that today not all vendors abide by the RFC 4291 which has happed day 1
> by Cisco and you mentioned another Linux flavor as well but now the major
> use case benefit the draft provides is mix vendor interoperability with
> vendors that don’t follow the RFC as written today and those that do which
> is a huge impetus for this change as well as allows the next hop for OSPF
> and ISIS to now be intuitive.  The gain in the intuitive next hops is
> deciding of the default EUI64 iid multi step process which having an
> intuitive next hop is the advertising node from which routes have been
> learned is known immediately similar to IPv4.
>
> With respect to going to the vendor to change their behavior to follow the
> RFC is not necessarily the issue as being able to modify the all 0s subnet
> portion of the LL is a benefit for Cisco to Cisco networks so there is no
> reason for that to change as the next hop is now 100% intuitive as is with
> IPv4 in that regard and only mix environments do we have to follow the RFC
> for neighbor adjacencies to form.
>
> Which really is the major reason that the draft I think really should get
> consensus approval from the WG to move forward.
>
> Thank you
>
> Gyan
>
> Sent from my iPhone
>
>> My reasoning which I gave Alex in assisting in authoring the draft as
>> what I implemented with my IPv6 customers as our deployment standard was to
>> have an intuitive link local for next hop adjacencies which we embedded the
>>> > Cisco happens to all the Link Local to be set and set all the 0s in
>>> the prefix fe80::/10 up to 64 which is a violation of the RFC but it does
>>> allow on all platforms and all codes.  I think we found that some unix
>>> flavors allow the same.
>>>
>>> That one vendor has chosen to allow the operator to chose if she wants
>>> to override the RFC behaviour, isn't in my view an argument for why we
>>> should change the standards.
>>>
>>> Cheers,
>>> Ole
>>>
>>>
>>> >
>>> > So now the change to the RFC 4291 is making it official that it now
>>> can be allowed across all platforms to help with mixed vendor environments

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jun 2019 17:09:16 +0200

Le 07/06/2019 à 21:29, Mudric, Dusan (Dusan) a écrit :
> [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, 

I agree.  The IPv6 link-local prefix is not one hextet, but a range of 
hextets: FE80::/10 to FEBF::/10.

Maybe one can come up with a base in which that range of hextets is 
represented as just one number.

Alex

  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. But, it is very common 
to say FE80::/10 is LL prefix, without mentioning the 6 trailing bits to 
be zeros.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jun 2019 17:12:54 +0200

> which in one string indicates both a fully qualified address and it's

Your system (sorry, not anything against your or your system) telling 
fe80::ac2f:ea58:94a:438/64 is relatively against IANA telling a 
link-local prefix is fe80::/10.

IANA telling the link local address is fe80::/10 is just one 
illustration.  It could have said the link-local prefix is fe81::/10 
too.  It is equally right.

RFC4291 saying 54bits are reset is against IANA saying fe80::/10 which 
lets the 54bits be anything.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jun 2019 17:17:19 +0200

Le 09/06/2019 à 17:56, James R Cutler a écrit :
>> On Jun 9, 2019, at 11:50 AM, Alexandre Petrescu 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote:
>>
>>
>>
>>>> <[email-masked] <mailto:[email-masked]>> To: 
>>>> Alexandre Petrescu
>>>> <[email-masked] <mailto:[email-masked]>> 
>>>> Cc: IPv6 <[email-masked] <mailto:[email-masked]>> Subject:
>>>> <[email-masked] 
>>>> <mailto:[email-masked]>> Content-Type:
>> It is still strange to say that the bit pattern 1111 1110 10 can not 
>> be represented in hexa.  Or maybe there is a need of a new base.
>>
>> I agree.  And the trailing 6 bits are not all zero.  RFC 4291 makes 
>> them to be 0, but IANA allocation does not make them to be 0.
>>

What is a nub?

Alex

>>> IETF IPv6 working group mailing list [email-masked] 
>>> <mailto:[email-masked]> Administrative
> [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jun 2019 17:21:34 +0200

> fe80:0000:0000:0000::/10 - febf:ffff:ffff:ffff::/10

YEs, but if you only use the /10 to define a range, you introduce 
ambiguity in notation.

People think that FE80 is the only hextet that can designate a 
link-local address.  That is wrong.  FE81 also is a hextet that 
designates a link-local address.  There are more.

That is a notation problem.

Alex

>      > <[email-masked] <mailto:[email-masked]>> wrote
>      > >
>      > > >
>      > > > Message: 3
>     <mailto:[email-masked]>>
>      > > > Cc: IPv6 <[email-masked] <mailto:[email-masked]>>
>      > > > Message-ID: <[email-masked]
>     <mailto:[email-masked]>>
>     [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
>      >

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jun 2019 17:24:18 +0200

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
>     ____
>     __
>     ____
>     __
>     *From:* Yucel Guven <[email-masked]
>     <mailto:[email-masked]>>
>     *Sent:* Monday, June 10, 2019 12:47 PM
>     *To:* Mudric, Dusan (Dusan) <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Tom Herbert <[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>     *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
>     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)
>     <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>     ____
>     __
> 
>          > > > Message-ID:
>         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
>          >
>         Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6
>         --------------------------------------------------------------------____
> 
>         ____
> 
>     ______
>     _______________
>     __________
>     ______
>     ______
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jun 2019 17:26:01 +0200

Le 10/06/2019 à 21:35, Ross Finlayson a écrit :
> Agreed.  The fact that this thread has lasted so long (or even, that
> it existed at all) is an illustration of just how far the quality of
> the IETF has fallen...

What do you mean,  more precisely?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jun 2019 17:32:47 +0200

> should not be taken as a reference or criteria to change the standards.

But one should not take a reference something that is not a reference 
either.

Let me explain: I came to this LL prefix length topic from the IPWAVE 
WG.  That specifies IPv6-over-OCB.  There are some implementations of 
it.  These implementations accept fe80:1::/32 as a LL prefix.

However, the advise came from knowledgeable people and from AD that we 
must not use /32 for LL.  Why?  Because some implementation does not 
support /32 LL.  But that implementation does not support IPv6-over-OCB 
either.

So the question is: why a reference for LL /64 is a reference for 
everything else when that reference does not implement everything else?

_This_ is very abnormal.

A Reference is something that the best things implement.

Alex

> On Wed, Jun 12, 2019 at 6:43 PM Gyan Mishra <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Ole
> 
>     My reasoning which I gave Alex in assisting in authoring the draft
>     as what I implemented with my IPv6 customers as our deployment
>     standard was to have an intuitive link local for next hop
>     adjacencies which we embedded the global unicast into the link local
>     after the :: but what happened in the original implementation 16
>     bits bled over into the all 0s portion of link local and the ospf
>     adjacencies would not come up with a Citrix Netscaler lb in 2 arm
>     setup so we went back to our standard realized that Citrix was
>     following the rfc 4291 and CISCO was not so we had to update our
>     deployment standard to follow the rfc for mixed vendor environment.
> 
>     So in this case as some vendors like CISCO chose not to follow the
>     rfc while others do for the use case of intuitive next hop is the
>     reason to change the rfc so that the entire global unicast address
>     can be embedded into the link local and the 16bit or more fields
>     don’t have to be shaved off making the goal of intuitive next hop
>     slightly better but still not as desired with the restriction of the
>     all Os field not allowed to be used.
> 
>     Gyan
> 
>     On Wed, Jun 12, 2019 at 12:27 PM Ole Troan <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi Gyan,
> 
>          > I went through this test in the lab a few months ago about
>         verifying across all Cisco platforms if you can specify non zero
>         values in the all 0's field in the Link Local prefix hardcoding
>         the prefix and if the OSPF neighbor would come up and it did
>         come up in an all Cisco environment.
>          >
>          > So the main thing this draft accomplishes in my opinion and I
>         think is necessary gap that it is fixing is interoperability
>         between vendors for the use case of making the link local
>         intuitive for the next hop by embedding the entire global
>         unicast address into the iid & 54 bit 0s field.
>          >
>          > Cisco happens to all the Link Local to be set and set all the
>         0s in the prefix fe80::/10 up to 64 which is a violation of the
>         RFC but it does allow on all platforms and all codes.  I think
>         we found that some unix flavors allow the same.
> 
>         Bias warning: I was heavily involved in one of the
>         implementations you mention and the choice of how to implement
>         link-local addresses.
> 
>         That one vendor has chosen to allow the operator to chose if she
>         wants to override the RFC behaviour, isn't in my view an
>         argument for why we should change the standards.
> 
>         Cheers,
>         Ole
> 
> 
>          >
>          > So now the change to the RFC 4291 is making it official that
>         it now can be allowed across all platforms to help with mixed
>         vendor environments where you can now embedd the entire global
>         unicast address into the station id making the default EUI64
>         station-id now intuitive.
>          >
>          >
>          > I did a test in the lab for that one use case of making the
>         default link local EUI64 more intuitive in the lab and Id id a
>         worst case scenario test populating all the 16 bit nibbles and
>         all hex digits within each nibble so no :: 0's compression on a
>         Cisco IOS XE router running 16.x code and confirmed the OSPF
>         neighbor still comes up even though the entire 54 bit all 0's
>         field per the RFC is populated in effect violating the current
>          > So I have tested this concept and it works across all Cisco
>         platforms IOS, XE, XR, NXOS that you can populate the entire 54
>         bit all 0's field..
>          >
>          > So the big caveat with this and justification for this draft
>         is "mix vendor" environment inter-operability" which is one of
>         the reasons for the IETF and to have RFC's and standards that
>         allows any device from any vendor to communicate that supports
>         the RFC.     I think that is a MAJOR point to add to the
>         justification behind the draft in the use cases where on a
>         managed IPv6 network that the administrator can now hardcode the
>         IPv6 address fully populating entire 54 bit subnet-id &
>         station-id and routing protocols will now work and OSPF, ISIS,
>         EIGRP adjacency can now work in a mix vendor environment.
>          >
>          > R1
>          > On Tue, Jun 11, 2019 at 4:44 AM Ole Troan
>         <[email-masked] <mailto:[email-masked]>> wrote:
>         (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.
>          > >
>          > > So if an application asks my implementation to send a
>         packet addressed to fe80:1::1 out a particular link what should
>         the implementation do with it? It seems like there are only 3
>         choices:
>          > >
>          > >   1. Run ND on that link to see if it can find a neighbor
>         there with that address to send the packet to.
>          > >
>          > > I had though 1. was the answer since that is what is done
>         with packets addressed to link-local unicast destinations (which
>         is what that address is according to RFC4191 section 2.4), but
>         that now seems to be ambiguous.
>          >
>         <mailto:[email-masked]>
>         <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
>          >
> 
>     -- 
> 
>     Gyan S. Mishra
> 
>     Email: [email-masked] <mailto:[email-masked]>
> 
>     <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jun 2019 17:34:31 +0200

Le 12/06/2019 à 23:08, Gyan Mishra a écrit :
> Hi Alex
> 
> In your next update can you add comment about mix vendor 

I can add it.

We already have something about mixed vendor interop, but I can add more.

Also, I wonder whether there can be some perspective for this draft, and 
how.

Alex

> interoperability in that today not all vendors abide by the RFC 4291 
> which has happed day 1 by Cisco and you mentioned another Linux flavor 
> as well but now the major use case benefit the draft provides is mix 
> vendor interoperability with vendors that don’t follow the RFC as 
> written today and those that do which is a huge impetus for this change 
> as well as allows the next hop for OSPF and ISIS to now be intuitive. 
>   The gain in the intuitive next hops is deciding of the default EUI64 
> iid multi step process which having an intuitive next hop is the 
> advertising node from which routes have been learned is known 
> immediately similar to IPv4.
> 
> With respect to going to the vendor to change their behavior to follow 
> the RFC is not necessarily the issue as being able to modify the all 0s 
> subnet portion of the LL is a benefit for Cisco to Cisco networks so 
> there is no reason for that to change as the next hop is now 100% 
> intuitive as is with IPv4 in that regard and only mix environments do we 
> have to follow the RFC for neighbor adjacencies to form.
> 
> Which really is the major reason that the draft I think really should 
> get consensus approval from the WG to move forward.
> 
> Thank you
> 
> Gyan
> 
> Sent from my iPhone
> 
> On Jun 12, 2019, at 2:37 PM, Yucel Guven <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> I agree with Ole.
>>
>>
>>     adjacencies which we embedded the global unicast into the link
>>     local after the :: but what happened in the original
>>     implementation 16 bits bled over into the all 0s portion of link
>>     local and the ospf adjacencies would not come up with a Citrix
>>     Netscaler lb in 2 arm setup so we went back to our standard
>>     realized that Citrix was following the rfc 4291 and CISCO was not
>>     so we had to update our deployment standard to follow the rfc for
>>     mixed vendor environment.
>>
>>     slightly better but still not as desired with the restriction of
>>     the all Os field not allowed to be used.
>>
>>     Gyan
>>
>>         verifying across all Cisco platforms if you can specify non
>>         zero values in the all 0's field in the Link Local prefix
>>         hardcoding the prefix and if the OSPF neighbor would come up
>>         and it did come up in an all Cisco environment.
>>         >
>>         > So the main thing this draft accomplishes in my opinion and
>>         I think is necessary gap that it is fixing is interoperability
>>         > Cisco happens to all the Link Local to be set and set all
>>         the 0s in the prefix fe80::/10 up to 64 which is a violation
>>         of the RFC but it does allow on all platforms and all codes. 
>>         I think we found that some unix flavors allow the same.
>>
>>         That one vendor has chosen to allow the operator to chose if
>>         she wants to override the RFC behaviour, isn't in my view an
>>         all hex digits within each nibble so no :: 0's compression on
>>         a Cisco IOS XE router running 16.x code and confirmed the OSPF
>>         platforms IOS, XE, XR, NXOS that you can populate the entire
>>         54 bit all 0's field..
>>         >
>>         managed IPv6 network that the administrator can now hardcode
>>         the IPv6 address fully populating entire 54 bit subnet-id &
>>         >   Link Local Address
>>         FE80:1111:1111:1111:1111:1111:1111:1111, Interface ID 18
>>         >   Link Local Address
>>         FE80:1111:1111:1111:1111:1111:1111:2222, Interface ID 18
>>         (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.
>>         > >
>>         packet addressed to fe80:1::1 out a particular link what
>>         should the implementation do with it? It seems like there are
>>         only 3 choices:
>>         > >
>>         with packets addressed to link-local unicast destinations
>>         (which is what that address is according to RFC4191 section
>>         2.4), but that now seems to be ambiguous.
>>         >

---

From: Simon Hobson <[email-masked]>
Date: Sat, 15 Jun 2019 22:21:54 +0100

Alexandre Petrescu <[email-masked]> wrote:

> I agree.  The IPv6 link-local prefix is not one hextet, but a range of hextets: FE80::/10 to FEBF::/10.
> 
> Maybe one can come up with a base in which that range of hextets is represented as just one number.

We don't need any new representation.
As others have already said, this thread has gone on far too long, and is really starting to seem like trolling. It is hard to understand how someone involved in networking does not understand CIDR, and someone involved in an IPv6 working group doesn't understand standard IPv6 CIDR notation. I'm sorry if that sounds like an insult, but these are pretty basic concepts.

There is no problem, there is no ambiguity.

Consider the IPv4 notation where someone says "subnet 123.123.252.0/22". That's unambiguous, meaning a subnet 0111 1011 0111 1011 1111 11 expanded to 32 bits with 00 0000 0000 0000, or in hex, FB FB FC 00/22. The fact that the subnet encompasses addresses from 123.123.252.0 through to 123.123.255.255 doesn't alter that, and we don't insist on saying it's subnet 123.123.(252 to 255).(0 to 255). Everyone knows exactly what is meant - if they understand CIDR, which sadly too many networking people don't (you wouldn't believe the number of people who don't understand anything but a /24 !)

In IPv6 notation, the rules are equally clear. FE80::/10 means exactly one thing - the TEN bits 1111 1110 10 followed by 118 zeros. As a prefix (analogous to a subnet in IPv4) that is clear, unambiguous, and understandable by anyone who understands the basics of IPv6 notation. The fact that the prefix can encompass addresses from FE80:: through to FEBF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF does not change the fact that the PREFIX is still FE80/10. So no, it is not necessary to say FE(80 through BF):<stuff>/10 and it would be very confusing to try and do so.

And all that is completely irrelevant to whether any address is link local or not. For example, an address FE81:1:<something> is still within the prefix FE80::/10. So if you wish to take the view that a link local address is allowed to use all 118 bits then the prefix is still FE80/10 and it is still valid to say that a link local address is in the FE80/10 subnet. So whether 54 bits are all zero or can be non-zero (and thus the hex representation can be anything from FE80:stuff to FEBF:stuff) doesn't change that basic notation.

> What is a nub?

It's a manner of speech in some areas, roughly translated it means "the essential point of the issue".

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sat, 15 Jun 2019 23:30:29 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Alexandre Petrescu

ambiguity in notation.

Alex, honestly, I never thought there was any ambiguity, and am surprised this issue lingers.

Consideration 1. The notation fe80::/10 means that the 10 bits represent a *prefix*. A prefix, by definition, the left-most 10 bits. That definition precludes the existence of any leading zeroes. If the 10-bit prefix included leading zeroes, it would have been written quite differently.

Consideration 2: Hex notation represents binary nibbles - groups of 4 bits. Therefore, however the 10-bit prefix is represented in hex, the only bits that matter are the left-most 10 bits.

Done. Now, the number 0xfe81 and the number 0xfe80 are identical, in terms of the left-most 10 bits. But someone might wonder, if you use fe81::/10, why on earth you bothered to set that 16th bit to 1 in your definition, when it was irrelevant to the 10bit prefix!

Bert

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 16 Jun 2019 01:18:08 -0400

Thanks Alex

Yes let me think about how we can add some perspective to this draft.

Also let me review the mix vendor comments and see what additional should
be added.

Gyan

On Sat, Jun 15, 2019 at 11:34 AM Alexandre Petrescu <
[email-masked]> wrote:

> >>         https://datatracker.ietf.
> .org/doc/html/draft-petrescu-6man-ll-prefix-len
> >>         <
> https://datatracker.ietf.org/doc/html/draft-petrescu-6man-ll-prefix-len>
> >>

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 16 Jun 2019 01:53:44 -0400

Ole

This is in reference to the LL hardcoded and set on the router.  That maybe
the perspective that Alex is asking about that maybe pertinent.

When the 54 bits are populated in order to be "on link" it acts as a
"subnet id" it has to match for all hosts on the subnet.  That is why on
"Cisco" even though they don't follow RFC 4291 the two routers are "on net"
and the IPv6 Neighbor adjacency forms and the OSPFv3 neighbor comes up.

In a case where you doing the use case I ran through in the lab mapping the
global unicast address into the link  local address the 54 bits end up
being the higher order common bits in the prefix
and the lower order bits fall into the station id which ends up being
unique per the global uni station id that is mapped over.

In any and all cases per this LL length change we would have to ensure that
all hosts to remain "on link" the managed network admin would have to
populate manually the subnet id 54 bits to be the same and if it were
different or coded incorrectly both devices would not be "on link" to
communicate and the IPv6 neighbor relationship would not form as the hosts
are now "off link" not on the same LL subnet.  I will check the draft to
see if the verbiage is present.

The LL hardcoded on the router goes to through the normal DAD process and
then the NS/NA ICMPv6 type 135 & 136 is sent and all hosts on the subnet
cache the ND entry.  So the neighbor router  that you are running OSPFv3
with now had an ND cache entry for the link local and the OSPFv3 is able to
send packets sourced from the link local "on net" between the two routers
to ff02::5 & ff02::6 and the OSPFv3 adjacency comes up.

So in that scenario #1

>          > >   1. Run ND on that link to see if it can find a
neighbor========> This would happen and the ND cache for the LL would be
populated on both routers and the OSPFv3 neighbor adjacency would come up
>          > >   3. Something else (what?).

So in this router hardcoded with the LL with non zsero bits in the 54 bit
field use case scenario the SLAAC enabled subnet SLAAC goes through the
normal DAD process as well and the RA is sent to the host with global uni
prefix with the new "on net" LL for ::/0 default that is cached on all the
hosts instead of the default EUI64 link local.

I was looking in RFC 4191 and I did not see a section 2.4

The main goal of RFC 4191 was for hosts on a subnet to have the ability to
select RA from one default router over another in a case where 2 routers
sending ::/0 exist on the subnet and now one can send Preference "High" and
the other router has default Preference Medium and using this RFC one is
able to achieve load balancing across all vlans so all host don't end up
hashing to the same Default router for redundancy so if you lose the
default router that all hosts hash to they don't all failover to the other
default router.  So this is prior to FHRP redundancy with Cisco proprietary
HSRP,GLBP and IETF standard VRRP where you have more control with First hop
router redundancy.

Thank you

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347