Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

[Lorenzo Colitti <[e-mail]>]

Wes,

many of these comments will be addressed in a respin, so I'm picking only
one to answer here.

Section 5 - I think we need to cut this section down to a bare minimum or
> eliminate it. Waving the NAT boogeyman isn't really the argument to lead
> with, unless the authors or other OS manufacturers actually see this as a
> credible alternative and are willing to implement it instead of other
> options. Otherwise it's just FUD. It's more accurate at this point to say
> that NAT doesn't exist for IPv6, because the IETF document is experimental
> (IIRC, I'm writing this on a plane and can't check) and no implementations
> really exist in the wild, so another solution is required. We've already
> written plenty about why NATs are bad elsewhere.
>

Unfortunately NAT66 *is* a credible alternative, and implementations
definitely do exist. I know for sure that Juniper ships a fully-stateful
NAT implementation on the SRX (and I don't mean NPTv6, I mean
fully-stateful NAT44-style address+port NAT), and I think I head that Cisco
does too.

That said, this document is about general-purpose hosts, so let's take
Android as an example. Linux has had a fully-stateful NAT66 implementation
since late 2012 -
http://mirrors.bieringer.de/Linux+IPv6-HOWTO/nat-netfilter6..html - and
members of the Android community have proposed enabled it multiple times,
for example:

https://android-review.googlesource.com/#/c/88648/
https://android-review.googlesource.com/#/c/88657/

These changes ended up not being included in the OS, but I think part of
the motivation is that they would not have added any useful functionality
that could not be obtained in a better way. The VPN code was rewritten in
5.0 to use per-app routing instead of in-device NAT (which fixed a series
of IPv4 bugs as well), and that brought IPv6 support without needing to use
NAT66. And even though stock Android does not yet support IPv6 tethering,
NAT66 would not have provided any benefit because Android doesn't support
networks that require explicit requests to obtain IPv6 addresses (i.e.,
DHCPv6-only networks) and thus can use ND proxying for tethering with no
loss of functionality.

On the other hand, for a device that supports DHCPv6-only networks that
provide only one address, NAT66 *would* provide useful functionality: it
would make it possible to provide IPv6 tethering and other functions that
require more than one address on those networks.