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

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Aug 2015 17:13:04 +0900

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.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 5 Aug 2015 09:31:26 +0000

> On Aug 5, 2015, at 1:13 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> 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 heard that Cisco does too.

We actually have a couple of implementations, in the ASA firewall product, and the ASR.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Aug 2015 17:01:32 +0200

Le 26/07/2015 03:21, George, Wes a écrit :
>
>
> On 7/15/15, 11:07 AM, "v6ops on behalf of Alexandru Petrescu"
> <[email-masked] on behalf of [email-masked]>
> wrote:
>
>> One problem I see is when operators deliver a single global /64
>> prefix, and that /64 is understood as a single IPv6 global
>> address.
>>
>> Forming multiple IPv6 addresses out of a single /64 is possible
>> for multiple apps running on that device, so that may not be a
>> problem. There may be some privacy concerns though, in that an
>> attacker can identify there is a single device there (the /64 is
>> unique).
>
> WG] that is not a privacy consideration that is unique to this
> document, and as such I recommend that we stay away from it, as it
> just distracts from the main point by essentially asking for rolling
> /64 assignments or multiple /64s. We need to keep the scope of this
> document fairly tight.
>
>>
>> But 'sharing' these IPv6 addresses with some other devices
>> (64share) has more serious drawbacks, typically in the number of
>> subnets - only one subnet is possible.
>
> WG] I fully expect implementations of the type that this draft
> discusses to get by with bridging if they need to share a /64 such as
> for mobile device tethering. If they truly need multiple subnets,
> there is no way to get around supporting DHCP_PD with some sane
> configuration around sending and accepting hints for larger prefixes,
> because that doesn't work for SLACC either. That probably needs to be
> another document, with those specific use cases documented, because
> "always support multiple subnets" is a more significant request than
> "always support multiple addresses"

Makes sense to me.  This document should either say "always support
multiple addresses and always support multiple prefixes" or may we write
another document for the prefixes requirement part.

Alex

>
>
> Thanks,
>
> Wes
>
>
> Anything below this line has been added by my company’s mail server,
> I have no control over it. -----------
>
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or
> subject to copyright belonging to Time Warner Cable. This E-mail is
> intended solely for the use of the individual or entity to which it
> is addressed. If you are not the intended recipient of this E-mail,
> you are hereby notified that any dissemination, distribution,
> copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
>