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

[Yucel Guven <[e-mail]>]

 You are interconnecting different/mixed vendors' devices in your lab.
 and saying that one vendor does not comply with or does not follow RFC,
 and trying to base it into the draft.
 I say that this approach is questionable, and not agree with you.
 Simply because it is a router software, and all type of softwares
 can easily be modified to run in expected/requested/modified way.
 This is a fact not only for vendors but also for open source softwares,
 all kinds of operating systems softwares.
 Also, you can not explicitly blame Cisco or Nokia or other vendors
 for not following the RFC. Instead, ring them and share your findings
 with the vendors, and tell them they did not follow the RFC 4291.
 I just wonder:
 1. Is your lab. run by an independent/non-profit organization?
 2. Is your lab. certified to conduct such experiments
    and to publish/share the results?
 3. Do you carry out the experiments in consent of
    or in collaboration with the vendors in question?
 One of the main purposes of so many RFCs is to provide
 information for the 'INTEROPERABILITY'
 for the worldwide Internet community.
 I am sure nobody in the list is against the discussion of RFCs.
 In fact we should obviously discuss if any issue/problem exist
 due to the content of an RFC. That's why we have drafts.
 Regards,
 Yucel

On Wed, Jun 12, 2019 at 11:08 PM Gyan Mishra <[e-mail]> wrote:

> Hi Alex
>
> In your next update can you add comment about mix vendor 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]> 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]> 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
>> --------------------------------------------------------------------
>>
>