Re: IPv6 Link Local Addresses

[Alexandre Petrescu <[e-mail]>]

Le 12/06/2019 à 20:37, Yucel Guven a écrit :
> 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.

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

> 
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> 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.
>          >
>          >
>         https://datatracker.ietf..org/doc/html/draft-petrescu-6man-ll-prefix-len
>         <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
>         <[e-mail] <mailto:[e-mail]>> 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.
>          > >
>          > > 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.
>          >
>          > Let me illustrate with a typical per-interface FIB:
>          >
>          >  fe80::/10 -> drop
>          >  fe80::/64 -> glean
>          >  fe80::abcd -> neighbor abcd
>          >
>          > Cheers,
>          > Ole
>          >
>         --------------------------------------------------------------------
>          > IETF IPv6 working group mailing list
>          > [e-mail] <mailto:[e-mail]>
>          > Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6
>          >
>         --------------------------------------------------------------------
>          >
>          >
>          > --
>          > Gyan S. Mishra
>          > IT Network Engineering & Technology
>          > Verizon Communications Inc. (VZ)
>          > 13101 Columbia Pike FDC1 3rd Floor
>          > Silver Spring, MD 20904
>          > United States
>          > Phone: [phone]
>          > Email: [e-mail]
>         <mailto:[e-mail]>
>          > www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
>         <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
>          >
> 
>     -- 
> 
>     Gyan S. Mishra
> 
>     IT Network Engineering & Technology
> 
>     Verizon Communications Inc. (VZ)
> 
>     13101 Columbia Pike FDC1 3rd Floor
> 
>     Silver Spring, MD 20904
> 
>     United States
> 
>     Phone: [phone]
> 
>     Email: [e-mail] <mailto:[e-mail]>
> 
>     www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
>     <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
> 
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>