Re: IPv6 Link Local Addresses

[Alexandre Petrescu <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>> 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 <[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
>>     --------------------------------------------------------------------
>>