IPv6 "bloat" history

Fri Apr 1 13:19:39 UTC 2022

Pascal Thubert (pthubert) wrote:

>> You can't expect people still working primarily on v6 have much
>> sense of engineering.
> 
> That includes me

Sorry for confusion. I mean "people still working primarily on v6"
are people who insist on IPv6 and ND as is, because any required
repair on it would delay the day when IPv6 is fully deployed.

Worse, actually, though they insist packet format stay same,
semantics has been randomly changing a lot as they wish.

>> As broadcast/multicast packets are first sent to APs as unicast
>> packets with ACKs, snooping by APs should be reliable at L2.
> 
> Well, up to the N retries. After that the stack is not even aware
> that the multicast was not delivered.

That is a unicast problem.

But, I understand your point. That is, though it can be remedied
by upper layer ACKs, there can be NACKs but no ACKs for DAD.

> Oh but that's just the beginning of the story;

Yup.

> yes we mostly can form
> an initial state and it mostly appears to work and people are mostly
> satisfied. And then you realize:
> 
> - there's no way to know how long the device will you that address

With some interval, an AP can unicast fake DAD to the device,
I think, though it wastes power to do so.

 > - there's no clean way to
 > know is an address is still in use (e.g., without reviving it in the
 > host stack)

See above, though I don't think it clean.

> - there's no way to know which is the most recent
> location of the address (unless you have a fine time distribution and
> that costs)

Yup.

> - there's no way to know if 2 locations are OK (anycast)

If you mean IPv6 anycast to allow 2 or more hosts sharing an
anycast address, it is just broken not useful for any purpose
and ignored.

Instead, IPv4 style anycast is widely deployed for IPv6.

> - there's no way to know for sure that the claimer is the owner

You may use IPSEC, though securely configuring security key
for IPSEC is at least as difficult as securely configuring
address without IPSEC, which means requiring cryptographic
security for DHCP is a bad idea.

> Certainly a bad guy doing impersonation and DOS can play havoc in
> such network, but at least between good guys we get something we can
> operate.

I'm sure there are a lot of security holes in or around IPv6 I
haven't noticed yet.

> I'm not saying that snooping DHCP is fully deterministic but it's
> orders of magnitude better than snooping SLAAC when it comes to
> forming a state like an association than SLAAC.

Of course.

>> So, by snooping DAD, which is ugly, ARP table can be constructed.
> 
> A Proof of Concept, yes, an enterprise-class-quality network, no. If
> you try, start populating the hot-line before you turn the lights on

I merely said "constructed", which does not imply "maintained".

> E.g., a DAD coming from the wire
> that is sent over the wireless is not deterministically delivered and
> a duplicate is often missed.

Even with a single AP, as DAD to terminals is multicast (from
the AP) and unreliable, duplicate is often missed.

> I do not need to continue the endless list do I?

If you think people still working primarily on v6, with my
meaning, have much sense of engineering, you should.

						Masataka Ohta