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

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 May 2019 10:32:30 +0200

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 : [email-masked]
Pour : Naveen Kottapalli <[email-masked]>, Loganaden Velvindron 
<[email-masked]>, Alexandre Petrescu <[email-masked]>, 
Gyan Mishra <[email-masked]>, Alexandre Petrescu 
<[email-masked]>

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.

The IETF Secretariat

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 7 May 2019 18:22:34 -0400

Hi Alex

The draft looks good.

In the security section can we add some recommendations for first hop security to protect IPv6 only networks using any DHCPv6 stateful or stateless scenario combinations using security features such as IPv6 snooping, IPv6 source guard to deny traffic from unknown sources and RA guard to only allow RA to be sent from the trusted L2 uplinks to the FHRP routers on the subnet.

Thank you

Gyan

Sent from my iPhone

> On May 7, 2019, at 4:32 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi 6MANners,
> 
> Sujet : New Version Notification for draft-petrescu-6man-ll-prefix-len-17.txt
> Pour : Naveen Kottapalli <[email-masked]>, Loganaden Velvindron <[email-masked]>, Alexandre Petrescu <[email-masked]>, Gyan Mishra <[email-masked]>, Alexandre Petrescu <[email-masked]>
> 
> 
> Title:        The length of the prefix of an IPv6 link-local address ranges from 10 to 127
> 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:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 7 May 2019 19:17:26 -0400

Sorry that was for the IPv6 only flag draft.  Let me forward that in that drafts thread.

Thanks 

Gyan

Sent from my iPhone

> On May 7, 2019, at 6:22 PM, Gyan Mishra <[email-masked]> wrote:
> 
> Hi Alex
> 
> The draft looks good.
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 8 May 2019 00:21:24 -0400

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.

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)

-- 
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
Mobile – 202-734-1000

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 May 2019 16:07:30 +0200

Le 08/05/2019 à 06:21, Gyan Mishra a écrit :
> 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.
> 
> 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'.

> 2.2.2.2      1   FULL/DR         00:00:35    18              

Thanks for illustrating what you mean.

Maybe a Neighbor ID of the form fe80:2::2 could help OSPF IPv6.

Alex

>    Link Local Address FE80:1111:1111:1111:1111:1111:1111:1111, Interface 
> ID 18
>    Link Local Address FE80:1111:1111:1111:1111:1111:1111:2222, Interface 
> ID 18
> On Tue, May 7, 2019 at 4:32 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi 6MANners,
> 
>     De : [email-masked] <mailto:[email-masked]>
>     Pour : Naveen Kottapalli <[email-masked]
>     <mailto:[email-masked]>>, Loganaden Velvindron
>     <[email-masked] <mailto:[email-masked]>>, Alexandre
>     Petrescu <[email-masked]
>     <mailto:[email-masked]>>,
>     Gyan Mishra <[email-masked] <mailto:[email-masked]>>,
>     Alexandre Petrescu
>     <[email-masked] <mailto:[email-masked]>>
> 
> 
>     until the htmlized version and diff are available at tools.ietf.org
>     <http://tools.ietf.org>.
> 
>     The IETF Secretariat
> 
>     [email-masked] <mailto:[email-masked]>
> <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
> Mobile – 202-734-1000
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 9 May 2019 12:14:13 -0400

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 <[email-masked]> wrote:
> 
> 
> 
>> 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.
> 
>> 2.2.2.2      1   FULL/DR         00:00:35    18              GigabitEthernet1/0/2
> 
>>   Link Local Address FE80:1111:1111:1111:1111:1111:1111:1111, Interface ID 18
>>   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
>> 1.1.1.1   1   FULL/BDR        00:00:37    18              GigabitEthernet1/0/2
>>   Link Local Address FE80:1111:1111:1111:1111:1111:1111:2222, Interface ID 18
>>   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
>> On Tue, May 7, 2019 at 4:32 AM Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
>>    Hi 6MANners,
>> 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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 May 2019 18:54:55 +0200

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

Why OSPF(v3) for IPv6 does not use an IPv6 address in the neighbor ID, 
and why does it use an IPv4 address instead?

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 9 May 2019 18:03:24 +0100

> and why does it use an IPv4 address instead?

both OSPFv2 and OSPFv3 use a 32-bit instance ID, which is traditionally 
represented as an ipv4 address.  It's not actually an ipv4 address.

Nick

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 9 May 2019 18:22:39 -0400

Per RFC 5340 due to the ospf header being only 16 bytes for 4 words wide packet x 4 deep thr LSR WG would have to make the header larger to accommodate but also the router id field itself would end up taking up the entire header all 16 bytes.  I think technically speaking the LSR WG which I am a member of would not be get a consensus on gains made by doing so thus has remained a 32 bit field.  I think though down the road as we go towards IPv6 only and IPv4 is eliminated I think we may have to revisit before that happens.  I will bring up with the WG.

Gyan

Sent from my iPhone

> On May 9, 2019, at 1:03 PM, Nick Hilliard <[email-masked]> wrote:
> 
>> Why OSPF(v3) for IPv6 does not use an IPv6 address in the neighbor ID, and why does it use an IPv4 address instead?
> 
> both OSPFv2 and OSPFv3 use a 32-bit instance ID, which is traditionally represented as an ipv4 address.  It's not actually an ipv4 address.
> 
> Nick
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 May 2019 10:18:37 +0200

> represented as an ipv4 address.  It's not actually an ipv4 address.

The 32bit instance ID responds to ping?

The 32bit instance ID is present in routing tables as next-hop?

Alex

---

From: [email-masked]
Date: Fri, 10 May 2019 10:30:55 +0200 (CEST)

>> both OSPFv2 and OSPFv3 use a 32-bit instance ID, which is
>> traditionally represented as an ipv4 address.  It's not actually an
>> ipv4 address.
> 

No.

> The 32bit instance ID is present in routing tables as next-hop?

No.

Think of it as a 32-bit *number*, not as an IPv4 address (because it
*is not* an IPv4 address).

Steinar Haug, AS2116

---

From: tom petch <[email-masked]>
Date: Fri, 10 May 2019 10:38:23 +0000

----- Original Message -----
From: <[email-masked]>
Sent: Friday, May 10, 2019 9:30 AM

No.

No.

<tp>
Absolutely, it is a 32 bit identifier with no semantics at all.

Trouble is, an all too popular manufacturer decided that one way to
specify it was to make it an IPv4 address as well - both 32 bit, what
could go wrong? - sothere are many who now think that it is, even must
be, an address that can be reached over the network.  If you have some
of this kit, and an IPv4 network, then you may indeed be able to use
those 32 bits as a source IP address or a destination IP address but
that would be a case of a manufacturer deciding to go over and beyond
the specification and making future development more complex.

Thank heavens the OSPF WG carried the right concept across to OSPF v3.

Tom Petch

Steinar Haug, AS2116

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 May 2019 13:17:32 +0200

> *is not* an IPv4 address).

In that case, the problem is in the textual representation of a 32bit 
value.  An uint32 cast into a struct in_addr and further converted by 
inet_ntoa to be displayed as a '1.1.1.1' instead of the intuitive 
'16843009' is misleading.

Probably the operating system of that router could be updated to no 
longer display the instance ID as an IP address.

In terms of spec, it seems Router ID of RFC2328 is the culprit, because 
RFC5340 says:
>  When receiving an Hello Packet from a neighbor on a broadcast,
>         Point-to-MultiPoint or NBMA network, set the neighbor
>         structure's Neighbor ID equal to the Router ID found in the
>         packet's OSPF header.
[...]
>     Router ID
>         A 32-bit number that uniquely identifies this router in the AS.
>         One possible implementation strategy would be to use the
>         smallest IP interface address belonging to the router.

RFC5340 OSPFv3 IPv6:
> o  OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the
>       IPv4 size of 32 bits.  They can no longer be assigned as (IPv6)
>       addresses.

It sounds as if it was possible to use IPv6 addresses as Router IDs 
before, but no longer.

Alex

---

From: Ole Troan <[email-masked]>
Date: Fri, 10 May 2019 13:24:06 +0200

Dear Alexandre,

I don’t believe this is in scope for 6man. 

Ole,
Your ever diligent co-chair. 

> On 10 May 2019, at 13:17, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> In that case, the problem is in the textual representation of a 32bit value.  An uint32 cast into a struct in_addr and further converted by inet_ntoa to be displayed as a '1.1.1.1' instead of the intuitive '16843009' is misleading.
> 
> Probably the operating system of that router could be updated to no longer display the instance ID as an IP address.
> 
> In terms of spec, it seems Router ID of RFC2328 is the culprit, because RFC5340 says:
> It sounds as if it was possible to use IPv6 addresses as Router IDs before, but no longer.
> 
> Alex
> 
>> <tp>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 10 May 2019 21:38:13 -0400

Yes it does respond to ping in a dual stacked environment although the router id does not technically have to be routable as it does with mpls LDP.

Sent from my iPhone

> On May 10, 2019, at 4:18 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 13 May 2019 10:46:04 +0200

I am happy to learn that ping router id (an IPv4 address) of OSPF IPv6
responds, because it confirms my expectation.  But I am not happy of
OSPF IPv6 relying on IPv4.

Le 11/05/2019 à 03:38, Gyan Mishra a écrit :
> Yes it does respond to ping in a dual stacked environment although 
> the router id does not technically have to be routable as it does 
> with mpls LDP.

This obviously off topic and I will not continue after this message.

My thought on this this the following: OSPF should update to allow
Router ID to be an IPv6 link-local address, not just an IPv4 address.

MPLS and LDP should update to allow IPv6 addresses everywhere and not
rely on any form of IPv4.

In cellular networks with GTP IPv6 the transport should be IPv6 UDP, not
IPv4 UDP.

The perspective is where IPv4 is not used at all - the IPv4 stack is
turned off (like 'uncheck' IPv4 on GUI on Windows and on MAC) - one
should not even rely on C code that does the textual representation of
IPv4 addresses (inet_ntop/pton), the loopback interface should not have
127.0.0.1, etc.

Alex

>>> Le 09/05/2019 à 19:03, Nick Hilliard a écrit : Alexandre
>>> Petrescu wrote on 09/05/2019 17:54:
>>>> Why OSPF(v3) for IPv6 does not use an IPv6 address in the 
>>>> neighbor ID, and why does it use an IPv4 address instead?
>>> traditionally represented as an ipv4 address.  It's not actually 
>>> an ipv4 address.
>>

---

From: [email-masked]
Date: Mon, 13 May 2019 11:56:57 +0200 (CEST)

> Router ID to be an IPv6 link-local address, not just an IPv4 address.

The OSPF router ID is a 32 bit number, *not* an IPv4 address. I see
no good reason to change this, we simply need to have people stop
*thinking* of it as an IPv4 address.

> rely on any form of IPv4.

LDPv6 already exists:

https://tools.ietf.org/html/rfc7552

Supported in for instance JunOS:

https://www.juniper.net/documentation/en_US/junos/topics/concept/ldp-native-ipv6-support-overview.html

Steinar Haug, AS2116

---

From: Mark Smith <[email-masked]>
Date: Mon, 13 May 2019 21:34:57 +1000

> *thinking* of it as an IPv4 address.

I once caused a little short term confusion by purposely changing a router
we were decommissioning's OSPD ID to 255.255.255.255 for a while before we
finally removed it from the network.

I did it on purpose and knew I could get away with it because the
convention was that OSPF IDs matched the router's unicast management IPv4
address, but in OSPF, the ID is *not* an IPv4 address.

255.255.255.255 was guaranteed to be both unique in our network and to also
work fine in OSPF. And it did.

 (Although even I got a little initially confused when I'd see it in OSPF
status commands. Perhaps next time around I'd use "Class D or E addresses"
- 255.255.255.255 is a really magic 32 bit number.)

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 13 May 2019 09:36:23 -0400

Alex

I will bring up this topic on the LSR (link state routing) WG.

I agree that we need an IPv6 router id 128 bit expanded field and even now with the IPv6-only flag draft of which Microsoft and maybe other vendors are getting on board as major players that enterprises can definitely deploy managed networks to IPv6 only in the access side and use 6to4 nat 6to4 dns and 6to4 proxy for internal and external IPv4 resource access.

Thank you 

Gyan

Sent from my iPhone

---

From: [email-masked]
Date: Mon, 13 May 2019 16:32:47 +0200 (CEST)

> I agree that we need an IPv6 router id 128 bit expanded field

Why? I really doubt you're planning more than 2^32 routers in your
OSPF infrastructure.

> and even now with the IPv6-only flag draft of which Microsoft and maybe other vendors are getting on board as major players that enterprises can definitely deploy managed networks to IPv6 only in the access side and use 6to4 nat 6to4 dns and 6to4 proxy for internal and external IPv4 resource access.

There is no connection between IPv6-only and 32 bit OSPF router ID, as
far as I can see. A 32 bit OSPF router ID won't prevent you from going
IPv6-only.

Steinar Haug, AS2116

---

From: tom petch <[email-masked]>
Date: Tue, 14 May 2019 09:27:58 +0000

----- Original Message -----
From: <[email-masked]>
Sent: Monday, May 13, 2019 3:32 PM

> > and even now with the IPv6-only flag draft of which Microsoft and
maybe other vendors are getting on board as major players that
enterprises can definitely deploy managed networks to IPv6 only in the
access side and use 6to4 nat 6to4 dns and 6to4 proxy for internal and
external IPv4 resource access.
> far as I can see. A 32 bit OSPF router ID won't prevent you from going

Absolutely.  RFC8294 defines router-id as
"A 32-bit number in the dotted-quad format assigned to each
          router.
(note: dotted quad - a convenient way of writing, reading, speaking ...
a 32 bit number which carries no semantic overtones).

MPLS, traffic engineering and such-like require a routable IPv4 or IPv6
(or both) address and those are specified separately and are commonly
referred to as te-rid or Traffic Engineering Router-ID - see for example
draft-ietf-ospf-yang

So I see no problem that was not solved many years ago.

Tom Petch

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 14 May 2019 18:10:53 -0400

The 32 bit router id for both ospf & ldp & te was defined as such based on
the IPv4 address 4 octet notation with no bearing on size of the network
that we would have even 2^32 = 4.2 billion routers in a network.

So same reasoning for having a router id that is an IPv6 address  since at
some point in time IPv4 will be legacy long gone so the router id has to be
based on ipv6 in the future.

So well before IPv4 is long gone we need to have a router id for all
routing protocols that supports using an IPv6 address 128 bit length.  Not
that we would never have an OSPF or MPLS network that has 2^128 routers but
that we need to be able to support a router-id that is now based on IPv6
addressing as well and not just IPv4 for the future elimination of IPv4.

I understand that per Yang model that both ospfv2 & ospfv3  IPv4 & IPv6
address families both use 32 bit number dotted notation

That really has no bearing or prevents any network from going IPv6 having
an IPv4 router-id.  The IPv4 router-id is OK with dual stack but once IPv4
is eliminated then it becomes a problem primarily for MPLS LDP.

Also the router-id technically does not have to be routable for IPv4 but
does have to be routable for LDP for link & targeted LDP for LDP to work so
in most ospf deployments the router-id best practice is to always be
routable.

Once you move to an IPv6 only network technically and IPv4 is gone even for
MPLS LDP IPv6 today supports a dual stacked MPLS core but now once IPv4 is
legacy and removed from the network the IPv4 router id will no longer be
routable and LDP will be broken.

With OSPFv3 technically you are ok and can stay with a 32 bit 4 octet
router-id but for MPLS you cannot and the MPLS WG would have to come up
with a draft for IPv6 based router-id once IPv4 is eliminated from the MPLS
core.

Gyan

---

From: tom petch <[email-masked]>
Date: Wed, 15 May 2019 09:43:57 +0000

----- Original Message -----
From: "Gyan Mishra" <[email-masked]>
Sent: Tuesday, May 14, 2019 11:10 PM

The 32 bit router id for both ospf & ldp & te was defined as such based
on
the IPv4 address 4 octet notation with no bearing on size of the network
that we would have even 2^32 = 4.2 billion routers in a network.

<tp>wrong; the 32 bit router id for OSPFv2 was defined as a 32 bit field
with no semantics. As RFC2328 says
" A 32-bit number that uniquely identifies this router in the AS."  In
some implementations, it is derived from an IPv4 address but that is a
(unfortunate) quirk of the implementation; other implementations are
more flexible;
the 32 bit OSPFv2 TE router id is defined as a reachable IPv4 address;
the 128 bit OSPFv3 TE router id is defined as a reachable IPv6 address

So same reasoning for having a router id that is an IPv6 address  since
at
some point in time IPv4 will be legacy long gone so the router id has to
be
based on ipv6 in the future.

<tp> wrong a router id is not an address, not IPv4, not IPv6 not any
protocol

So well before IPv4 is long gone we need to have a router id for all
routing protocols that supports using an IPv6 address 128 bit length.
Not
that we would never have an OSPF or MPLS network that has 2^128 routers
but
that we need to be able to support a router-id that is now based on IPv6
addressing as well and not just IPv4 for the future elimination of IPv4.

<tp> wrong; a router id is not an address; a TE OSPFv3 router id is an
IPv6 128 bit address. I agree that we are unlikely to need 2^128
different router ids - 2^32 will likely be enough for the foreseeable
future so a 32 bit router id will likely see us through

<tp> YANG defines a lexical format for its types; where this is 32 bit,
it uses, and, sensibly, reuses, the concept of dotted quad which says
nothing about the semantics of the 32 bit

That really has no bearing or prevents any network from going IPv6
having
an IPv4 router-id.  The IPv4 router-id is OK with dual stack but once
IPv4
is eliminated then it becomes a problem primarily for MPLS LDP.

<tp> wrong; a router id is not IPv4 or IPv6 or any other protocol - it
is a router id

Also the router-id technically does not have to be routable for IPv4 but
does have to be routable for LDP for link & targeted LDP for LDP to work
so
in most ospf deployments the router-id best practice is to always be
routable.

<tp> the router id does not have to be routable, ever, which is why
there is a separate TE router id which does have to be routable, IPv4 or
IPv6 depending on context

once you move to an IPv6 only network technically and IPv4 is gone even
for
MPLS LDP IPv6 today supports a dual stacked MPLS core but now once IPv4
is
legacy and removed from the network the IPv4 router id will no longer be
routable and LDP will be broken.

<wrong> the router id is a 32 bit number which is neither IPv4 or IPv6;
where a routable address is needed, then the protocols specify the TE
router id which must be routable, IPv4 or IPv6

With OSPFv3 technically you are ok and can stay with a 32 bit 4 octet
router-id but for MPLS you cannot and the MPLS WG would have to come up
with a draft for IPv6 based router-id once IPv4 is eliminated from the
MPLS
core.

<tp> MPLS, and TE in general, defined the TE router id for this purpose
many years ago so no, the MPLS do not have to come up with a draft -
there is already an RFC.

HTH

Tom Petch

Gyan