Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

[Kristian McColm <[e-mail]>]

> For large ISPs, IPv4 NAT is also annoying from a network management point of view because it is not possible to uniquely number all devices in the network.

For cellular networks, NAT is also very expensive when we talk about CGN (both NAT44 and NAT64) and by simply deploying dual-stacked connectivity to your users you can immediately reduce CG-NAT requirement by around 60%, due to most cellular data traffic being to native IPv6 enabled sites like YouTube, Facebook, Instagram etc.

-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Philip Homburg
Sent: October 28, 2019 04:52
To: [e-mail]
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

> The (only) value (sic) of IPv6 to end-users is retoration of end to 
> end connectivity at the network layer.

End users at not really part of the equation at the moment. Many people have tried to convince their ISPs to provide IPv6 and failed.

For home use, IPv6 is what you get when the ISP has decided that providing IP services over IPv6 instead of or next to IPv4 is worth it.

This is not my ideal world. But realistically, we live in a world that still has to transition away from IPv4. 

> I challenge you to find in the "real world" of end-users many with 
> much trust in the ad-based "you are the product" centralised services 
> in the current Internet.  IPv6 was meant to allow end-users to run 
> decentralized services.

This is a separate issue. The problem started when people paid for connectivity but assumed they paid for internet services. There are plenty of providers for mail, messaging, etc. where you are not the product. But very few customers are willing to pay extra for such services.

At the same time, where an ISP does provide stable addresses, most people find it hard to run services at home.

> - hidden primary DNS - mail - web - home-automation - video 
> conferencing - jabber

Many people have a more or less fixed IPv4 address. Setting up a few port forwards in a CPE is not that hard (and with IPv6, you have to do the same for the firewall in the CPE).

Yet very few people run these services at home.

Basically, the market value for those service at a residential home is zero.

> Assuming all the moving parts required were updated to support flash 
> renumbering (I have little proof they even support graceful 
> renumbering), if the end-user cannot trust the lifetimes in the 
> delegated prefix, DNS with TTL=1s is presumably the only choice?

ISPs that do flash renumbering, typically do that after a link down event.
Assuming those events are rare (and ISPs have an incentive to make them rare because it interferes with watching video), then a TTL of a few minutes should work.

> If making IPv6 no better than IPv4 + NAT, then stick with IPv4 + NAT.  
> IPv4 NAT scales very well as it turns out.
 
IPv4 NAT doesn't scale very well when law enforcement wakes up and find out that a single IP address means lots of different people at the same time.

IPv4 NAT also doesn't scale very well when it comes to bandwidth.

For large ISPs, IPv4 NAT is also annoying from a network management point of view because it is not possible to uniquely number all devices in the network.

Plenty of reasons for an ISP to move to IPv6 even if they don't care about providing end-to-end connectivity.

> We don't need IPv6 to maintain the status quo.

We are out of IPv4 addresses. There is a lot of demand for IPv4 addresses and the lack of them is a barrier against entry.

> And don't get me wrong, I'm all for making IPv6 addressing / onlink 
> behaviour more robust.  But not justified in this way that can be seen 
> to allow for practices that removes any benefit of IPv6 over IPv4/NAT.

The current internet has moved to lots of short lived flows. If we can tune systems that new address information propagates quickly, both on the local network and in DNS, then unstable prefixes could very well something we can live with.

In fact, we can also use the letsencrypt argument: by having short lived certificates letencrypt strongly encourages automating the whole process.
Lots of tooling popped up to support that model.

Right now we are stuck in a model where too many files are hand edited with address and prefix information. At the same time, everybody expects phones and laptops to seemlessly move between networks, picking up new addresses and removing stale ones as they move around.


_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops