nanog mailing list archives

RE: V6 still not supported


From: "Pascal Thubert \(pthubert\) via NANOG" <nanog () nanog org>
Date: Thu, 17 Mar 2022 07:27:54 +0000

Hello Saku:
 
    This is intended to replace ARP, ICMP Router Advertisement, ICMP
    Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the
[IPv6]
    environment. There are also elements of the OSI ES-IS and IS-IS
Hello.

We were forward looking to deployments of thousands of systems per
link, rather than the 30 maximum under then current ethernet
standards.  We needed fewer announcements, less chatty traffic, and
more specific traffic designation.

Please bear with me, after negativity some sobering remarks follow.

And the solution is broken, it assumes snooping packets and creating
near arbitrary amounts of multicast groups and forwarding multicast on
L2 device is cheaper than flooding. It is not, and everyone keeps MLD
off in L2 to simplify and reduce cost.
So in reality the multicast L2 resolution is not used, and useless
complexity. 

True. The issue is not with "IPv6" but specifically with SLAAC. As long one uses DHCP, IPv4 and v6 have similar 
properties WRT to BUM.

Now, hosts having multiple addresses and renewing them when they wish could be a real bonus, if it was not done the 
Woodstock way; IOW if there was a minimum control from the network operator. *The hassle in SLAAC is the SL*.

This is why the IETF introduced RFC 8505 / 8928. This combines the stateful behavior of DHCP and the benefits of 
autoconfiguration. No more multicast DAD or address lookup. No IGMP.


In addition to this problem of changing broadcast to
multicast, the ND can use GUA|LL<->GUA|LL any combination, which makes
almost every input ACL broken, because operators simply are not aware of
this. Very common problem for us is, we change vendor on our end, and
customer IPv6 breaks, customer did 0 changes, so of course they blame
us, and we have difficult task to educate them 'look this is how ND
works, your ACL is broken, because it assumes special case is generic
case, and the special case has changed' because different vendors choose
different GUA|LL <-> GUA|LL for ND, it can be wrong and work until the
far end does some change. The right solution is not to filter by ADDR,
but to filter by hop-limit, but it's too complex for operators to
understand.


True. The "on-link" model is a very bad fit for any managed network. Don't use it outside home 😉. Probably turn off 
redirect when you do that, too.

/MOST/ IPv6 'improvements' are like this, they solve problems that
either didn't exist or make the existing problem worse. Like extension
headers. Like creating large on-link networks, adding a lot more attack
vectors.

True too. The RFC 8505 / 8928 combo creates P2P IP link abstractions regardless of the L2 broadcast domain / L2 
segments. This is how you can avoid BUM and set up a deterministic state for wireless (proxy ARP) and overlays (LISP, 
EVPN...) services. IOW the prefixes are always "not onlink".
 

Ok IPv6 is kinda shit, but it's the only thing we have and we can make
it work with some effort and some cost. And the effort and cost of
making IPv6 work is less than making IPV4+IPV6 work, and we really
really need the larger address space, it trumps all other deltas by a
wide margin. So yes I have an ugly child, but it's the only child I
have, and with my genes, a beautiful child isn't on the cards, so I'll
raise this ugly child as best I can.
I no longer care how bad IPv6 is, that's crying over spilt milk, it
doesn't matter. I care about the cost of doing both IPV4+IPV6.


The child has grown up, at least on paper. But very little of IETF efforts in the last 15 years has made it to 
products. Apart of SRv6 and IoT, which is where RFC 8505 started. 

I assume that user feedback is needed for vendors to implement, and users are not necessarily aware of the specs that 
were developed, so many of them. 

Would you care to extract RFC 8505 / 8928 from the background noise?

Keep safe;

Pascal


Current thread: