Re: IPv6 Link Local Addresses

[Gyan Mishra <[e-mail]>]

On Sat, Jun 15, 2019 at 11:32 AM Alexandre Petrescu <
[e-mail]> wrote:

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

 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
>         there with that address to send the packet to.
>          > >
>          > >   2. Send the packet to the current default router.
>          > >
>          > >   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

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


-- 

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