Re: [v6ops] Implementation Status of PREF64

[Owen DeLong <[e-mail]>]

> On Sep 30, 2021, at 00:06 , Lorenzo Colitti <lorenzo=[e-mail]> wrote:
> 
> On Thu, Sep 30, 2021 at 11:16 AM Owen DeLong <owen=[e-mail] <mailto:[e-mail]>> wrote:
> Nonetheless, restoring the e2e addressing model and true peer-to-peer networking _IS_, in fact, worth the effort and expense IMHO.
> 
> Owen, I think you need to realize that IPv6 by itself does not provide end-to-end addressing. It only provides end-to-end addressing if sufficient addresses are available, and if it's possible to inform devices of network configuration changes. DHCP as currently managed and deployed is terrible at both those things. Yes, I know it's possible to *sort of* make DHCPv6 do this via reconfigure, multiple DUIDs, etc., but current implementations and operational models do not do this.

It inherently provides E2E address transparency so long as nobody sticks packet header mutilation (i.e. NAT) in the path.

I understand that there are things you don’t like about DHCPv6, but what you aren’t getting here is that no matter how good or bad those things are, they are what some institutions want and they  WILL NOT DEPLOY IPv6 without IA_NA period.

What you want to allow or not on your own network is fine, but you’re a device manufacturer with significant market share. The fact that you’re holding the entire industry hostage to your personal attitudes by telling people what capabilities they can’t have if they want your devices on their network is going to lead to one of two eventualities and neither of them is the one you want…

1. Enterprises will simply continue to stall on IPv6 until there’s android support.
or
2. Enterprises will simply start selling their android users “too bad, so sad, your device won’t work with our network, get something with proper IPv6 support.”

> As for network changes - sure, it's possible to ensure that things don't change, like an enterprise network that uses PI space.

And there are precisely a lot of enterprises in that boat.

> But as for sufficient addresses... as you said yourself in this thread, (some) operators want to use DHCPv6 in order to ensure a single address per device. This will not result in end-to-end connectivity. It will result in the device getting that single address running NAT66 and and and all the other functions inside that device or connected to it getting private IPv6 addresses and non-end-to-end connectivity. We tried to write this down in RFC 7934 sections 3 and 4 <https://datatracker.ietf.org/doc/html/rfc7934#section-3>.

In the networks that choose to implement it that way, so be it. Frankly, for all practical purposes from the outside perspective, that’s still e2e. There aren’t multiple devices behind that device with whatever crazy NAT scheme is going on in the device (which, frankly, makes little sense and won’t really help anything), so since one address identifies the correct device in a transparent manner, that’s most of what most people care about from an E2E perspective.

As to sections 3 and 4 of RFC7934, I’ll answer as follows:

	Privacy addressing is a myth. It really doesn’t prevent tracking, it just moves it up the stack.

	Multiple processors share addresses on lots of systems without NAT, so it’s not clear to me why this doesn’t work
	The current IWLAN spec is here: 24327-c00.zip <https://www.3gpp.org/ftp/Specs/archive/24_series/24.327/24327-c00.zip> btw. Perhaps I’m misunderstanding the spec, but it looks like
	the application processor would mostly be talking through the tunnel using addresses provided for the tunnel
	interior by its home agent. In that case, it’s not really an issue. However, simultaneous attachment and/or
	roaming between MIPv6 and the corporate LAN is considered undesirable by a number of enterprise security
	departments, so disabling this functionality isn’t exactly viewed as a bad thing in the very cases we are
	discussing.

	For tethering, I think we can all agree that IA_PD is preferable. The handset is a router at that point.

	Most enterprises aren’t wild about supporting random hypervisors they don’t control, so again, disabling
	this capability is viewed as a feature, not a bug in those environments.

	Enterprises that are deploying DHCPv6 are most likely to run dual stack. I think that the tradeoff of
	either DHCPv6 IA_NA single address _OR_ 464XLAT is one administrators can make an informed
	decision about on a network by network basis.

	ILA is a draft which expired in 2017.

	I think that administrators can make an informed decision between whether or not they wish to support
	things like TARP or per-application IPv6 addresses. I don’t think an equipment vendor should be making that
	decision for them.

	DHCPv6 PD is widely available and 3GPP release 10+ is sufficiently widely deployed that I think this concern
	is obsolete.

For section 4:

	These may be valid tradeoffs, but they’re choices that the network administrator should make,
	not something where an equipment vendor should substitute their judgment for the network administrator’s.

	The added latency for provisioning an address via DHCP vs. SLAAC is almost zero and in some cases,
	DHCPv6 can be faster due to the lack of need for DAD.

	In general, the provisioning operation in question will occur at network attachment time anyway and in
	the environments where this is a concern, a self-assigned address isn’t going to get anywhere until the
	provisioning function completes anyway. As such, this doesn’t really provide any additional problems.

	We deal with failures of DHCP in dhcpv4 today and there’s the same challenge if you don’t get an RA
	in response to your RS or if DAD fails too many times or… The alleged increase in complexity is a stretch
	at best.

	The goals of the concluding paragraph of section 4 are laudable, but they ignore some of the other
	reasons that many enterprise networks want to have greater control and accountability on addressing
	that can be achieved with SLAAC, RFC4941, etc.

	It also ignores the possibility of providing additional host configuration information and/or requirements
	via DHCP options that simply cannot be achieved with SLAAC.


> So again: if all we're getting from the transition to IPv6 is 128-bit IPv4 with NAT, then why bother?

Because we need more addresses and it won’t be 128-bit IPv4 with NAT in reality.

In IPv4 with NAT, a single address identifies god-only-knows how many hosts.

At the worst in the scenario you describe, that would only be true with tethering where IA_PD was not
supported, which should be mostly rare. For all other situations, even if there is NAT, it still only identifies
a single physical host, even if there are VMs behind the NAT (and hopefully there aren’t because chances
are that if the network administrators wanted to allow handsets running hypervisors on their WLAN, they’d
be issuing multiple addresses to the handset).

Bottom line, the potential harms described in RFC-7934 are vastly outweighed by the harms of the
deployment delays being caused by android’s lack of IA_NA support.

Further bottom line, appeasing the environments that want this will not cause the vast majority
of other environments to suddenly run DHCPv6 in preference to SLAAC. Where SLAAC meets the
need, nobody is going to go to the trouble of implementing a DHCPv6 server.

Owen