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

[Gyan Mishra <[e-mail]>]

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