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

["George, Wes" <[e-mail]>]

I've read -01. I support the part of the draft that explains why multiple
addresses are necessary. The detail around not having to have every
application on a device bound to the same address is quite important and
not at all intuitive to those used to thinking about IPv4 implementations
with only one address available. However, there are some other sections of
this draft that need some refinement to provide better supporting
arguments for the recommendations being given.

Section 3 -
5th bullet "Translation-based.." Need a reference to the 464XLat doc up
here instead of below, specifically a pointer to the section dictating the
use of a separate address

Section 4- This section is pretty handwavey right now. There are plenty of
things in the mobile space that involve waiting for something to happen in
network provisioning. Connecting to the network isn't instantaneous, nor
is enabling tethering. Many times application launches or actions are
delayed by radio wake-up or network congestion, etc. I agree that there is
an maximum window of what constitutes a good user experience, but if I can
have a DHCPv6 server listening for subsequent requests for addresses and
it gets them back to you within a reasonable window for a good user
experience, you need to explain why that won't work. You also need to
explain why if you know that a certain number of addresses are needed, why
a device couldn't request more than one when connecting to the network
initially. I realize mobile isn't the only case here, so we need to have
the same discussion for other types of applications - since instant isn't
a valid answer, because almost nothing is instant on from cold, what's the
outside envelope for a good user experience? Think in terms of initial
connection to the network (where you might ask for multiple addresses) and
then subsequent wakeup where you already have them.
If there's complexity in dealing with failure cases, or uncertainty on
whether a feature is available, explain those issues in more depth. Again,
mobile devices tell users all the time "service not available" or
"restricted by carrier" or whatever. I'm not defending that as a good user
experience, but I'm not certain we can discount solutions based on what we
don't like about how carriers and devices operate today. In other words,
giving a device as many addresses as it wants isn't going to fix all of
those other things that contribute to a bad user experience because they
are restricted by the carrier or impacted by the behavior of the network,
so I don't see solving that issue here as an imperative. I'm open to being
convinced otherwise, but that's something that the draft needs to discuss.

I think you also need to distinguish in the draft between implementations
or situations that REQUIRE more than one address or else they simply won't
work (such as tethering, VMs, etc) vs implementations where it's simply
easier to use multiple addresses than binding the same address to multiple
application sockets such as you would do with a single IPv4 address. If
you're actually doing an IPv4 NAT within the device today to avoid having
to have multiple applications using the same address in IPv4, then make
that clear in the document.

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.

9.1 is combative, dismissive, and incomplete. The problem is not that
operators have made the argument that DHCPv6 is the only way to...
What they've said is that they require a way to track which IPv6 addresses
are assigned to which hosts for policy and legal reasons, and that is
driving a set of deployment decisions. That's not up for debate or
negotiation, and is part of the reason why other discussions of this issue
have been so...vigorous. IETF needs to get out of the habit of telling
operators that their problem isn't a problem, and focus on discussing the
possible solutions, identifying what consensus says is the best way to
solve the problem.
There are several ways to solve the stated problem. One is DHCPv6. It has
pros and cons, some of which are discussed elsewhere in the document,
mainly in the form of why DHCPv6 to assign a single address is a problem.
Another way is whatever the authors are doing on their own networks. I
assume that it also has pros and cons, but since it's not even discussed,
right now you're basically making an unsupported assertion that it's an
alternative. Further, you make no effort to explain how a dual-stack
enterprise network is the same (i.e. It shares this need for tracking) as
the mentioned examples of academic and other networks that provide third
party services. Discuss the alternatives equally instead of trying to
predispose the reader to agree with your pre-conceived belief that DHCPv6
isn't necessary or not the best way to do this because its cons outweigh
its pros. This is where Erik's suggestion about other methods of logging
belongs as well.


Thanks,

Wes



On 7/6/15, 7:47 AM, "v6ops on behalf of [e-mail]"
<[e-mail] on behalf of [e-mail]> wrote:

>A new draft has been posted, at
>http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability.
>Please take a look at it and comment.
>
>_______________________________________________
>v6ops mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/v6ops


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.