ipv6-ops Digest, Vol 159, Issue 1

[Nick Hilliard]

Michael Sturtz wrote on 25/10/2019 16:21:
> Nick I agree!  The problem is from an operational support and
> protocol level we created this monster by selling the idea of "end to
> end connectivity" and "every end site will get a /64" that has been
> sold to even end users.

The problem was more a cultural thing in the ietf - people wanted 
devices to have autonomy and be able to select their own addressing 
mechanism, and not be subject to the whims of the network operator. 
Hence the intent behind /64, and SLAAC, and the difficulties that the 
IETF has with DHCP.

The problem was (and is) that this vision didn't align well with 
reality, particularly enterprise but also content hosting and other 
deployment scenarios.

> I understand that the ISPs really don’t want
> customers to be able to serve content from consumer connections.
> This is likely why they are randomly changing the /64 allocated to
> the end sites especially on consumer lines.

The reason for this relates to address aggregation at the ISP rather 
than wanting to prevent consumers from serving content.  Honestly most 
ISPs don't care whether people put content services on their house 
connections because usually this doesn't create much extra cost (DOCSIS 
and cell-phone systems excluded).  What does cost a lot, though, is when 
you have massive prefix disaggregation and you need to deal with 
provisioning hell and gigantic IGP tables in order to provide people 
static assignments, even if most people don't really need them.  This is 
why it's mostly a commercial problem rather than a protocol issue.

> event occurs.  I have personal experience with multiple devices that
> use SLAAC breaking connectivity for some indeterminate period of time
> when a network renumber event occurs.  Yes this could be due to
> poorly implemented end devices etc. but the end point is people just
> disable IPv6 because of the headaches caused by it.
Yep.

Nick