Re: IPv6 Link Local Addresses [was Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?]

[Yucel Guven <[e-mail]>]

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]> 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]> 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]> 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]
>> > 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]
>> > 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]
>
> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>