Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 1 Oct 2015 07:59:38 +0000

> On Sep 18, 2015, at 11:52 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
>> However, it may be imposed as a crude load management system. So
>> maybe the draft should point out that the number of IP addresses is
>> not a proxy for the traffic load.

Agree that someone might be trying to manage load. But I suspect it's more about revenue generation. Example: I recently took a cruise on Royal Caribbean (which is a five star hotel on a barge), and paid five star hotel prices for Internet access (well, not really; we didn't buy it). The first device was $15/day, the second was half that, and there wasn't a third device price. Not sure what would have happened if my device had wanted to change its IP address daily (is that a MAC address or an IP address?). I think they saw it as a revenue source, and weren't especially thinking about the amount of space segment or ship-to-shore microwave they were using.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 2 Oct 2015 08:10:24 +1300

>>> not a proxy for the traffic load.

[That was me, not Alexandre]

> Agree that someone might be trying to manage load. But I suspect it's more about revenue generation. Example: I recently took a cruise on Royal Caribbean (which is a five star hotel on a barge), an…

Sure, but in either case it's fundamentally due to a belief that an IP address is
a costly resource, and I think we're trying to say "no it isn't,in IPv6."

Which leaves open the question of what *is* a costly resource that it's reasonable
to charge for, of course.

    Brian

---

From: "George, Wes" <[email-masked]>
Date: Fri, 2 Oct 2015 19:49:17 +0000

I'm late on the actual WGLC, and for that I apologize, but since the
discussion is still going, and I made significant comments on a previous
version of the draft, I wanted to respond.

Generally:
This is a dramatic improvement over the previous versions and addresses
many of my concerns. I think there has been some valuable feedback in the
previous comments that I won't repeat here, and once it and the comments
below are addressed, the draft is ready to move on.

However, given some of the discussion that has taken place on the "A
little pushback" thread, I think you need to remember that those responses
are valuable devil's advocate feedback. Take the points raised and
incorporate your additional explanation and justification as response into
the draft, because the target audience of this draft are going to raise
exactly the same concerns. This draft is essentially trying to put
together a logical argument to convince operators of certain types of
networks to do something a certain way, a way that is significantly
different from the way that they do it today, and your previous efforts to
convince operators of this (NANOG, a certain Android bug ID, etc) have not
gone well. Between that and the fact that IETF unfortunately has a
reputation for being a little tone deaf or ivory tower when it comes to
making recommendations to operators, you're not arguing from a position of
strength, even given the ethos of the author list and the company names
associated, and so there are multiple reasons to really concentrate on
strengthening the supports of your assertions and recommendations. Err on
the side of more justification, more detail, more directly relevant
examples, more citations when making assertions about why this is the
right way.

What I still see specifically outstanding that hasn't already been covered
by others:

Section 8 - I don't find the discussion about the limits of assigning
multiple addresses via IA_NA/TA particularly convincing right now. I think
you make a good point earlier about there being some added complexity and
potential delays associated with having to ask for additional addresses
when the situation changes, and I see why the primary recommendation is
SLAAC or PD. But I think it's naïve to assume that application and device
developers are never going to have to operate in an IA_NA environment such
that they will never have to request additional addresses if the situation
changes, so the complexity to make it robust and a good user experience is
likely unavoidable. I think you'll find network operators who will assert
that their network is set up such that giving you multiple addresses via
IA_NA is easier for them, and they'll give you as many as you actually
have a use for, which does solve the problem asserted here (that modern
devices need multiple addresses) but they don't want to give you an entire
/64, or even 64 addresses unless you actually need that many. So if you
don't ask for enough on the initial request, you might have to ask for
more, and you need to be ready to deal with that, whether it means a
temporary delay, or shifting bindings so that the new thing uses an
existing address(es) while another application(s) that happens to be
dormant requests a new address for itself in the background, etc. I agree
that it's less preferable, but a lot more discussion will be necessary to
support the assertion that asking for more addresses isn't a workable
enough alternative.

Section 9.1 -

A nit: "...the enterprise networks of the authors... *Employers*" would be
more accurate, but since authors are supposed to be working as
individuals, might be better to just say "enterprise networks at Apple and
Google" and leave the authors out of the discussion, since their
affiliations provide some implied credibility to speak authoritatively
about the networks at Apple and Google without further citation. :-)

More substantively: That last paragraph is generally based on one
assertion that I'm not sure is fully formed and supported. There isn't any
discussion of whether the enterprise networks at Apple and Google or
enterprise networks in general are bound by the same requirements to track
host to IP and what method they're using to address that issue. If this
just isn't an issue, either because they're using authentication (.1x or
similar) or because they don't actually need/care to track hosts, than
this isn't adding much in the way of supporting the recommendation and
should probably be removed. Right now, the way I am interpreting it is
that it's more intended to support the assertion that DHCPv6 is generally
not necessary in enterprise networks (i.e. "just because you use DHCPv4
doesn't mean you automatically need DHCPv6") rather than specifically
supporting the assertion that the alternative means of tracking host to IP
presented here are sufficient, and I don't believe that the document
actually provides much in the way of support for the first assertion,
because enterprise networking is not one size fits all.
The assertion that many large universities use the recommended methods for
host tracking should be supported by an example and citation if at all
possible, because otherwise it's also not adding a lot in the way of
support since none of the authors is representing a university and thus it
sounds like hearsay.

Thanks,

Wes

On 9/13/15, 2:00 PM, "v6ops on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>This is to initiate a two week working group last call of
>http://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability.
>Please read it now. If you find nits (spelling errors, minor suggested
>wording changes, etc), comment to the authors; if you find greater
>issues, such as disagreeing with a statement or finding additional
>issues that need to be addressed, please post your comments to the
>list.
>
>We are looking specifically for comments on the importance of the
>document as well as its content. If you have read the document and
>believe it to be of operational utility, that is also an important
>comment to make.
>
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

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.

---

From: "Dale W. Carder" <[email-masked]>
Date: Fri, 02 Oct 2015 15:18:38 -0500

> support since none of the authors is representing a university and thus it

Well, this one does.  So there's one ;-)  

Here's the specific script we were running circa 2008:
http://net.doit.wisc.edu/~dwcarder/scripts/physaddrwatch_ipv6.pl
These days it has been rewritten to screen scrape more modern platforms.

We do the same thing for IPv4 (and historically also did for IPX and appletalk),
regardless of dhcp lease tracking and rfc6939.

Dale

---

From: David Farmer <[email-masked]>
Date: Fri, 2 Oct 2015 19:58:30 -0400

> On Oct 2, 2015, at 16:18, Dale W. Carder <[email-masked]> wrote:
> 

We (UMN) do much the same for both IPv4 and IPv6.  With IPv4 we never relied on just DHCP logging because that doesn't catch manually configured hosts.  So we also collect APR tables from the routers for IPv4.  I'll note that collecting both ARP tables and DHCP logs provides resiliency to errors or other issues in either part of the system for the vast majority of hosts that do DHCP.  Enough about IPv4.

Therefore similarly, we would find relying on only DHCPv6 logging unacceptable for the same reasons.  So we currently use SLAAC, and monitor the routers IPv6 neighbor tables as discussed.  

However, early on, before implementing the IPv6 neighbor collection, we had wished DHCPv6 was universally available on hosts.  Logging from the DHCPv6 server would have been good enough to allow us to move forward with our IPv6 deployment.  It wouldn't have been perfect, but it would have allowed wider deployment earlier on our network.  For us, this was pre-2011 or so, after that we finally got around to implementing collection of IPv6 neighbor tables in our management tools.  

So, I fully support the ideas of this document.  However in the real world everything isn't always ideal.  Therefore, it is critically important for all hosts to support all IPv6 deployment models, SLAAC, classic DHCPv6, DHCPv6-PD, and manual configuration.  It is important to provide all options to those implementing IPv6 in their networks.

As I see it, the primary purpose of this document isn't to tell people how to implement IPv6 on their networks.  It is simple telling them if they restrict a host to one or any other small number of addresses, then they are doing it wrong.

Thanks
-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Oct 2015 16:42:17 +0900

On Fri, Oct 2, 2015 at 4:10 AM, Brian E Carpenter <
[email-masked]> wrote:

> I think they saw it as a revenue source, and weren't especially thinking
> about the amount of space segment or ship-to-shore microwave they were
> using.
>

No, that's not the same. Just because something doesn't cost anything
doesn't mean people won't try to charge for it.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 Oct 2015 15:22:37 +0000

It might be worth discussing DAD implications in this draft; perhaps in Table 1.
With SLAAC and DHCPv6 IA_NA/IA_TA, DAD is required to test for uniqueness
on the link. With DHCPv6 PD, DAD is not required because the delegated prefix
is fully owned by the requesting device and not assigned to the interface over
which the prefix is delegated (although individual addresses from the delegated
prefix can be assigned to the interface).

Thanks - Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Oct 2015 11:26:50 +1300

> doesn't mean people won't try to charge for it.

Well yes, that's how capitalism works, but we need the user community
to understand that addresses are infinite, and not worth paying for
in a free market.

  Brian