V6 still not supported

Thu Mar 17 07:27:54 UTC 2022

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