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

[Alexandre Petrescu <[e-mail]>]

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

> 
> Sent from my iPhone
> 
>> On May 10, 2019, at 4:18 AM, Alexandre Petrescu 
>> <[e-mail]> wrote:
>> 
>> 
>> 
>>> 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?
>>> 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.
>> 
>> The 32bit instance ID responds to ping?
>> 
>> The 32bit instance ID is present in routing tables as next-hop?
>> 
>> Alex
>