Re: New Version Notification for draft-petrescu-6man-ll-prefix-len-17.txt

[Gyan Mishra <[e-mail]>]

The ospfv3 neighbor id has to be IPv4 4 octet.  That would be nice if it were supported.

Thanks 

Gyan

Sent from my iPhone

> On May 9, 2019, at 10:07 AM, Alexandre Petrescu <[e-mail]> wrote:
> 
> 
> 
>> Le 08/05/2019 à 06:21, Gyan Mishra a écrit :
>> Hi Alex
>> 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 RFC 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.
> 
> So I make a section called 'Justification'.
> 
>> 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
> 
> Thanks for illustrating what you mean.
> 
> Maybe a Neighbor ID of the form fe80:2::2 could help OSPF IPv6.
> 
> Alex
> 
>> 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, May 7, 2019 at 4:32 AM Alexandre Petrescu <[e-mail] <mailto:[e-mail]>> wrote:
>>    Hi 6MANners,
>>    I submitted the version 17 of this draft about variable plen for LLs.
>>    This is the ChangeLog:
>>    -17: added a new use-case for sysadmins in need of an intuitive LL
>>           address (to check with ping) used for next-hop of routing
>>           protocols.
>>    -16: added a description of the behaviour of ifconfig
>>           fe80:1::1/32 on MAC OS and Windows 10 Operating Systems;
>>           added a suggestion about the use of ULA prefixes instead of LL
>>           prefixes;
>>           added a reference to an RFC 7404 about the use of
>>           only LL addresses in an IPv6 network;
>>           explained the result from practice of the use of 'fe80::1:2/64';
>>           explained why the text says 'hidden' for '%' on some OSs;
>>           mentioned the DNS kind of solutions;
>>           added explanation of manual configuration and automation;
>>           added exaplanation of an example of complex to remember and type
>>           link-local addresses;
>>           added explanation of why DNS solution is a problem mouvement, not
>>           problem resolution.
>>    Alex
>>    -------- Message transféré --------
>>    Sujet : New Version Notification for
>>    draft-petrescu-6man-ll-prefix-len-17.txt
>>    Date : Tue, 7 May 2019 01:27:36 -0700
>>    De : [e-mail] <mailto:[e-mail]>
>>    Pour : Naveen Kottapalli <[e-mail]
>>    <mailto:[e-mail]>>, Loganaden Velvindron
>>    <[e-mail] <mailto:[e-mail]>>, Alexandre
>>    Petrescu <[e-mail]
>>    <mailto:[e-mail]>>,
>>    Gyan Mishra <[e-mail] <mailto:[e-mail]>>,
>>    Alexandre Petrescu
>>    <[e-mail] <mailto:[e-mail]>>
>>    A new version of I-D, draft-petrescu-6man-ll-prefix-len-17.txt
>>    has been successfully submitted by Alexandre Petrescu and posted to the
>>    IETF repository.
>>    Name:           draft-petrescu-6man-ll-prefix-len
>>    Revision:       17
>>    Title:          The length of the prefix of an IPv6 link-local
>>    address ranges
>>    from 10 to 127
>>    Document date:  2019-05-06
>>    Group:          Individual Submission
>>    Pages:          14
>>    URL:
>>    https://www.ietf.org/internet-drafts/draft-petrescu-6man-ll-prefix-len-17.txt
>>    Status:
>>    https://datatracker.ietf.org/doc/draft-petrescu-6man-ll-prefix-len/
>>    Htmlized:
>>    https://tools.ietf.org/html/draft-petrescu-6man-ll-prefix-len-17
>>    Htmlized:
>>    https://datatracker.ietf.org/doc/html/draft-petrescu-6man-ll-prefix-len
>>    Diff:
>>    https://www.ietf.org/rfcdiff?url2=draft-petrescu-6man-ll-prefix-len-17
>>    Abstract:
>>         A rejected Erratum to RFC4291 "IPv6 Addr Archi" on the topic of
>>    link-
>>         local addresses 'would need' a draft.  This draft is an answer to
>>         that need.
>>         The length of the prefix of an IPv6 link-local address is variable.
>>         The minimal value is 10 decimal.  The maximum value is 127 decimal.
>>    Please note that it may take a couple of minutes from the time of
>>    submission
>>    until the htmlized version and diff are available at tools.ietf.org
>>    <http://tools.ietf.org>.
>>    The IETF Secretariat
>>    --------------------------------------------------------------------
>>    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 Consultant
>> Routing & Switching / Service Provider MPLS & IPv6 Expert
>> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
>> Mobile – 202-734-1000