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

From: [email-masked]
Date: Sun, 13 Sep 2015 11:00:03 -0700

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Sep 2015 08:43:22 +1200

I believe this document is important and should go forward.

Small issues:

1) Neither the title nor the Abstract mentions IPv6 specifically.

2) In the Introduction:

> In IPv6, each link has a
> virtually unlimited amount of address space [RFC7421].

I suggest making that reference specifically to section 3.1 of RFC7421.
It's a long RFC.

3) Section 8 still says

> Assigning prefixes smaller than a /64 ...

and "smaller" is still confusing. (Also, this would be the place for
a more general reference to RFC7421, which discusses at length the issues
caused by prefixes longer than /64.)

4)

> 9.1.  Stateful addressing and host tracking

I thinking that "auditing" is a better word than "tracking" throughout
this section. (This is another topic that is also discussed in RFC7421.)

Regards
     Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 15 Sep 2015 14:54:19 +0200

I disagree with the following statements:
> If the network requires explicit requests
>    for address space (e.g., if it requires DHCPv6 to connect), it is
>    RECOMMENDED that the network assign a /64 prefix to every host (e.g.,
>    via DHCPv6 PD).

That should be a /63, not a /64.

Please dont make this draft yet another hardcoding of 64.

Alex

Le 13/09/2015 20:00, [email-masked] a écrit :
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 15 Sep 2015 14:59:23 +0200

On table 1:
>    +--------------------------+-------+-------------+--------+---------+
>    |                          | SLAAC |    DHCPv6   | DHCPv6 |  DHCPv4 |
>    |                          |       |   IA_NA /   |   PD   |         |
>    |                          |       |    IA_TA    |        |         |
>    +--------------------------+-------+-------------+--------+---------+
>    | Extend network           |  Yes  |      No     |  Yes   |   Yes   |
>    |                          |       |             |        | (NAT44) |
>    | "Unlimited" endpoints    |  Yes* |     Yes*    |   No   |    No   |
>    | Stateful, request-based  |   No  |     Yes     |  Yes   |   Yes   |
>    | Immune to layer 3 on-    |   No  |     Yes     |  Yes   |   Yes   |
>    | link resource exhaustion |       |             |        |         |
>    | attacks                  |       |             |        |         |
>    +--------------------------+-------+-------------+--------+---------+

SLAAC can indeed extend the network when 64share is used.  But only to a 
certain extent - i.e. only one more subnet.

DHCPv6 PD can also extend the network but to more than just one subnet.

In that sense, SLAAC extends the network with a "Yes, hm"
whereas DHCPv6-PD is a "YES!".

Alex

---

From: Mark Smith <[email-masked]>
Date: Wed, 16 Sep 2015 08:06:13 +1000

> That should be a /63, not a /64.

Can you explain further why?

> Please dont make this draft yet another hardcoding of 64.

RECOMMENDED is not a MUST.

---

From: Mark Smith <[email-masked]>
Date: Wed, 16 Sep 2015 11:38:14 +1000

Hi,

Firstly, I think this is an important document and should be formally published.

Regarding the "Benefits of multiple addresses" I think another example
that could be mentioned is the use of Multipathing (more specifically
MPTCP) to make applications more robust to addressing renumbering
events e.g., an application connection surviving a transition from one
GUA prefix to another.

The main thing that has influenced my thinking is Fred's draft,
"Happier Eyeballs"
(https://tools.ietf.org/html/draft-baker-happier-eyeballs-00), so I
think it should be a reference.

I think the most important and interesting observation in Fred's draft
is that multiple addresses on a host's single interface is also a form
of multi-homing. If an application uses multipathing between the
set(s) of IPv6 addresses on the hosts (of any scope, including
link-locals if the destination host is known to be on-link for the
host's one or more interfaces), then the application connection should
have a much better chance of surviving the expiry/replacement of one
of those addresses. (MPTCP supports IPv4 too, however mentioning that
would probably be out of scope of this draft).

For example, there might be two global prefixes on the link, an old,
being phased out global prefix, and a new, being phased in global
prefix. If the MPTCP host notified its peer of the new address(es) it
generated when the new global prefix became available, the MPTCP hosts
could start using the new global addresses, allowing the MPTCP
connection to then survive the eventual expiry of the old prefix
global addresses. This robustness would also work across different
address scopes (e.g., ULA disappearing while a GUA still available,
GUA and ULAs disappearing while Link-Locals are still (always)
available, assuming the destination host is reachable over an attached
link).

Fred's draft is making it clearer that the Happy Eyeballs technique is
a more general mechanism than one limited to TCP or to web browsers.
I've started to think that HE and MPTCP style multipathing are
complimentary - HE is a single connection set up robustness technique,
where as MPTCP is a multiple connection robustness technique deployed
after a single connection has been established.

It probably isn't in scope for this draft, however I think it would be
beneficial for applications to combine the ideas of both - if there
are multiple source and destination addresses available, try to use
all of them to establish the application session/connection (excepting
link-local destinations unless they're known to be on-link somehow
e.g., MDNS), and then use MPTCP-style multipathing and ongoing
signalling/testing of new and removed addresses to make the connection
robust against addresses changing.

Specific to the text, considering the above, I think:

"Today, there are many host functions that require more than one IP
address to be available to the host:"

should be changed to:

"Today, there are many host functions that require *or would benefit
from* more than one IP address *being* available to the host:"

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 Sep 2015 10:51:27 +0200

Le 16/09/2015 00:06, Mark Smith a écrit :
>
> On 15 Sep 2015 22:55, "Alexandru Petrescu" <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >

Because it is as valid to recommend a /63 as a /64.  Moreover, any value 
between /1 and /127 could be recommended.  There is no reason to 
recommend /64 in particular.

> RECOMMENDED is not a MUST.

I agree.  But I think we can RECOMMEND as much each one of the prefix 
lengths from /1 to /127 (i.e. 1, 2, 3...127).

Alex

>
>  > Alex
>  >
>  >
>  >
>  > Le 13/09/2015 20:00, [email-masked] <mailto:[email-masked]> a écrit :
>  >>
>  >> [email-masked] <mailto:[email-masked]>
>  > [email-masked] <mailto:[email-masked]>

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 16 Sep 2015 11:37:42 +0200

Hello Alex and Mark,

> Le 16 sept. 2015 à 10:51, Alexandre Petrescu <[email-masked]> a écrit :
> 
> 
> 
> Because it is as valid to recommend a /63 as a /64.  Moreover, any value between /1 and /127 could be recommended.  There is no reason to recommend /64 in particular.

I think the spirit of the document is to say that hosts should be assigned *at least* a 64.
It is later stated that a prefix longer than 64 may cause trouble, which is true.
On the other hand, providing a bigger prefix is not likely to cause trouble (I assume a DHCPv6-PD client
failing at receiving a 63 is just broken).

So what about such a change ?

OLD:

NEW:
If the network requires explicit requests
   for address space (e.g., if it requires DHCPv6 to connect), it is
   RECOMMENDED that the network assign prefix of length 64 or less to every host (e.g.,
   via DHCPv6 PD).

- Pierre

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 Sep 2015 13:15:47 +0200

Le 16/09/2015 11:37, Pierre Pfister a écrit :
> Hello Alex and Mark,
>
>
>> Le 16 sept. 2015 à 10:51, Alexandre Petrescu
>> <[email-masked]
>> <mailto:[email-masked]>> a écrit :
>>
>>
>>
>>> <mailto:[email-masked]>
>>>>> If the network requires explicit requests for address space
>>>>> (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED
>>>>> that the network assign a /64 prefix to every host
>>> (e.g.,
>>>>> via DHCPv6 PD).
>>>>
>>>>
>> Because it is as valid to recommend a /63 as a /64.  Moreover, any
>>  value between /1 and /127 could be recommended.  There is no
>> reason to recommend /64 in particular.
>

Sounds reasonable in a sense.

There is a difference between a Host on WiFi and a Host on cellular.

I think one can not say that a Host on WiFi is allocated a /64.  On WiFi
it hears a /64 prefix and forms an address; or it gets allocated an
address with DHCP.  But it is not _allocated_ that /64 only for itself.

On cellular one can consider that the terminal is (currently)
"allocated" a /64 for itself, simply because there's nobody else on that
link.

There is a difference between DHCP-PD and DHCP-Address.  DHCP-Address
only allocates a /128, not /64. DHCP-PD allocates a prefix - but that
prefix is not to be used to form an address on the interface where that
prefix was received.  As such _that_ allocated prefix has nothing to do
with the 64bit length of IPv6-over-Ethernet.

To summarize, that 'RECOMMEND'ation seems to deal with a smartphone
connecting on 4G and using DHCPv6-PD.  As such it has no reason to
RECOMMEND 64.  It should recommend _any_ length.

> It is later stated that a prefix longer than 64 may cause trouble,

YEs, a prefix length greater than 64 in a RA will cause trouble to
stateless address auto-configuration on Ethernet - the kernel complies
in /var/log/messages.  However, it causes no trouble to DHCP.

> On the other hand, providing a bigger prefix is not likely to cause
> trouble (I assume a DHCPv6-PD client failing at receiving a 63 is
> just broken).

I also agree with this.  Allocating a prefix length smaller than 64 will
not cause trouble on Ethernet neither to SLAAC nor to DHCP.
Implementations simply pad zeros up to the 64bit boundary necessary to
SLAAC-over-Ethernet.

> If the network requires explicit requests for address space (e.g., if
> it requires DHCPv6 to connect), it is RECOMMENDED that the network
> assign a /64 prefix to every host (e.g., via DHCPv6 PD).
>
>
> NEW:
>
> If the network requires explicit requests for address space (e.g., if
> it requires DHCPv6 to connect), it is RECOMMENDED that the network
> assign prefix of length 64 or less to every host (e.g., via DHCPv6
> PD).

Still not ok to me.  How about this:

> If the network requires explicit requests for address space (e.g., if
> it requires the use of DHCPv6 at connect time), it is RECOMMENDED
> that the network assigns an address to each host (e.g., via DHCPv6).
> It is also recommended that the network allocates a Prefix to a Host
> if that Host requested it (if Host used DHCP Prefix Delegation).  The
> Prefix Length is RECOMMENDED by the Host and can have any value
> between 1 and 127.

Alex

---

From: Mark Smith <[email-masked]>
Date: Wed, 16 Sep 2015 21:55:13 +1000

>> Prefix Length is RECOMMENDED by the Host and can have any value

So this is again going down the path of providing just enough rather than
more than enough addresses.

Variation and "right sizing" has a cost - more complexity and less
predictability and therefore less ability to plan and easily troubleshoot.
It is far simpler to work with "every host gets a /64", rather than trying
to work with "a host gets what it asks for, up to a /1 (which it won't ever
get), or down to a /127, depending on what applications it is running and
what they would like or need to have at any particular time.".

There is no need for "right sizing" in IPv6 when the address space is 73
billion billion times larger than IPv4's.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Wed, 16 Sep 2015 08:35:45 -0500

> On Sep 16, 2015, at 06:55, Mark Smith <[email-masked]> wrote:
> So this is again going down the path of providing just enough rather than more than enough addresses.
> 
> Variation and "right sizing" has a cost - more complexity and less predictability and therefore less ability to plan and easily troubleshoot. It is far simpler to work with "every host gets a /64", rather than trying to work with "a host gets what it asks for, up to a /1 (which it won't ever get), or down to a /127, depending on what applications it is running and what they would like or need to have at any particular time.".
> 
> There is no need for "right sizing" in IPv6 when the address space is 73 billion billion times larger than IPv4's.
> 
> Regards,
> Mark.
> 
Let's be clear, a /64 is enough addresses for a host to do ANYTHING it could ever possible what to do.  A /64 is only ever NOT enough in the context of wanting more than one subnet, for what ever reason it may be desired.  This Draft is about ensuring a Host has sufficient addresses to do what were it wants to do. I believe a /64 more than fulfills that desire in the context described in the Draft.

A host, user, site or whatever wanting more than on subnet is perfectly appropriate too.  However, it's a different request, requirement, desire, or context then I think is being discussed in this draft.

-- 
===============================================
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: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 Sep 2015 15:44:11 +0200

right-sizing...

Le 16/09/2015 13:55, Mark Smith a écrit :
[...]
>>> (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED that
>>> the network assign a /64 prefix to every host (e.g., via DHCPv6
>>> PD).
>>>
>>>
>>> NEW:
>>>
>>> (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED that
>>> the network assign prefix of length 64 or less to every host
>>> (e.g., via DHCPv6 PD).
>>
>>
>>> (e.g., if it requires the use of DHCPv6 at connect time), it is
>>> RECOMMENDED that the network assigns an address to each host
>>> (e.g., via DHCPv6). It is also recommended that the network
>>> allocates a Prefix to a Host if that Host requested it (if Host
>>> used DHCP Prefix Delegation).  The Prefix Length is RECOMMENDED
>>> by the Host and can have any value between 1 and 127.
>>
>

> It is far simpler to work with "every host gets a /64",

"every host gets at least 32 unagreggatable /128s for self and 32 /64s 
for its tethered" - EHGAT64.

> rather than trying to work with "a host gets what it asks for, up to
> a /1 (which it won't ever get), or down to a /127, depending on what
> applications it is running and what they would like or need to have
> at any particular time.".

I agree, too much.

I think I meant that RECOMMENDing only prefix size (63, or 64) is not 
really giving ensurance that enough addresses be available to a Host.

Alex

>
> There is no need for "right sizing" in IPv6 when the address space
> is 73 billion billion times larger than IPv4's.
>
> Regards, Mark.
>
>>
>> Alex
>>
>>>
>>>
>>>
>>> - Pierre
>>>
>>
>> _______________________________________________ v6ops mailing list

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 16 Sep 2015 13:47:31 +0000

Which prefixes do you expect to be assigned to those that delegate them? Are you saying every organization has to obtain /63 or smaller prefix? Are we approaching /32 IPv4? Can you provide a network hierarchy examples please?

Thanks,
Dusan.

On Sep 16, 2015, at 06:55, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Mark.

David Farmer                          Email: [email-masked]<mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 Sep 2015 16:07:43 +0200

Le 16/09/2015 15:35, David Farmer a écrit :
>>  predictability and therefore less ability to plan and easily
>> troubleshoot. It is far simpler to work with "every host gets a
>> /64", rather than trying to work with "a host gets what it asks
>> for, up to a /1 (which it won't ever get), or down to a /127,
>> depending on what applications it is running and what they would
>> like or need to have at any particular time.".
>>
> Let's be clear, a /64 is enough addresses for a host to do ANYTHING
> it could ever possible what to do.
>
> A /64 is only ever NOT enough in the context of wanting more than one
> subnet, for what ever reason it may be desired.

Ok, 2^64 means many addresses but only if bridged.

And, at the same time, no-one will ever put 2^64 machines on a single
subnet - someone will have to route to scale, which will break bridging.

> This Draft is about ensuring a Host has sufficient addresses to do
> what were it wants to do.

In a sense yes.

But the draft also says "tethering" as benefit of multiple addresses.
Also draft's "Running virtual machines", "per-app addresses" - will
appreciate routing instead of bridging.

> I believe a /64 more than fulfills that desire in the context
> described in the Draft.
>
> A host, user, site or whatever wanting more than on subnet is
> perfectly appropriate too.  However, it's a different request,
> requirement, desire, or context then I think is being discussed in
> this draft.

I think the mechanisms are the same for multiple addresses at a site as
are for multiple addresses inside a Host.

Were the draft to be removed the "tethering" and the virtual machine
benefits, I think it would be left with little to recommend, because the
existing systems already allocate /64s to Hosts.

(if we understand the same thing by "allocating".  To be clear: a prefix
in an RA is not allocation; and DHCPv6-PD containing a /64 means the
Host must not make an address on its interface out of that /64)

Alex

> -- =============================================== David Farmer
> Email: [email-masked] <mailto:[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: Owen DeLong <[email-masked]>
Date: Wed, 16 Sep 2015 19:56:31 -0700

> On Sep 16, 2015, at 06:35 , David Farmer <[email-masked]> wrote:
> 
> 
> 
> 
> On Sep 16, 2015, at 06:55, Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:

Everyone here knows that I am a pretty big fan of profligate address distribution.

Having said that, I oppose the recommendation to assign a /64 or shorter to every host required to get addressing via DHCP.

Few hosts would be able to fully utilize even a /32. However, few networks can support as many as 65,536 hosts.

As such, I would like to advocate that a reasonable tradeoff if we are using DHCP-PD to assign addresses to hosts that the host is _NOT_ expected to delegate downstream would be to assign a /80 from the /64 shared on the media segment or a /64 if it is an isolated media segment.

In this way, the host can manage 64 billion+ addresses as it sees fit and up the subnet still has plenty of chunks for all the likely hosts.

If more than one subnet is needed, then multiple /64s should be assigned accordingly. If an entire subnet is needed, then I support assigning a /64.

If we’re talking about (e.g.) VMs in a datacenter, I think this hybrid /80 approach represents a reasonable tradeoff in many circumstances.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Sep 2015 12:15:30 +0900

On Thu, Sep 17, 2015 at 11:56 AM, Owen DeLong <[email-masked]> wrote:

> As such, I would like to advocate that a reasonable tradeoff if we are
> using DHCP-PD to assign addresses to hosts that the host is _NOT_ expected
> to delegate downstream would be to assign a /80 from the /64 shared on the
> media segment or a /64 if it is an isolated media segment.
>

The problem with using something smaller than /64 is as follows.

Statefully allocating something smaller than /64 (let's use /80 as in your
example) forces any devices that wishes to provide downstream connectivity
(e.g., to VMs, tethered devices, etc) to use stateful address assigment -
presumably using DHCPv6 PD. Because those hosts may well be general-purpose
hosts, then that means that general-purpose hosts need to accept
arbitrarily small prefixes.

The reason is as follows: If I connect my laptop to a network and get a
/80, then I can't give a VM or a tethered device more space than, say, a
/88. That in turn forces any devices that wish to operate downstream to
support stateful address assignment and accept a prefix size of /88. That
means that if a network assigns a device a /88, then it will accept that
prefix, but it will be unable to provide any downstream connectivity, and
will be forced to implement NAT66 if it wishes to do so.

I think any value that is /64 or smaller has this problem. /64 does not
because it allows a device to use non-hierarchical means (such as bridging
and SLAAC) to extend the network.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Sep 2015 12:17:01 +0900

On Thu, Sep 17, 2015 at 11:56 AM, Owen DeLong <[email-masked]> wrote:

> to delegate downstream

Expected by who? By the owner of the host? By the administrator of the
DHCPv6 server? By someone else? Those expectations may well be different.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Sep 2015 16:12:24 +1200

> The problem with using something smaller than /64 is as follows.

And is a major topic of RFC 7421.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Sep 2015 06:52:36 +0200 (CEST)

> believe it to be of operational utility, that is also an important

I have re-read the document as if I never read it before. This is an 
important and valuable document, and I would like it to proceed as 
intended.

However, I have concerns regarding section 9, operational considerations. 
I feel that it should either be expanded with more information (and there 
is a lot to discuss I believe), or it should refer to other documents that 
might already have this information/discussion. Right now it seems to me 
that if someone reads this document that do not have prior experience 
here, it'll leave them either disagreeing with the text because they don't 
have the background and their actual background experience might oppose 
the text in here, and there are no pointers to other documents that might 
have this information. There might also be current use-cases that is not 
brought up in the operational considerations as it stands today.

This document also brings up the whole "cascaded DHCPv6-PD tree structure" 
(what if you're running a VM that requests DHCPv6-PD from a host that has 
received DHCPv6-PD /64 from the network) but doesn't really give any 
guidance on the issue... Lorenzo posted on the list that if you have a /64 
you can PD a /80 to each VM etc. This absolutely makes sense, but I 
am not aware of any document that actually looks into this more deeply? I 
remember Fred B saying we didn't have any text on this when I spoke at the 
mic at IETF75, my first IETF, and I still haven't seen any real text 
giving recommendations on the subject.

Also, the document talks about giving /64 to hosts. It seems to me that 
the whole "what is a host, what is a router" distinction is going away, 
and almost everything is becoming a router of some kind. This is just 
normal progression of technology and this document already has text on 
cases where this is happening, but would it make sense to include a 
paragraph somewhere on the terminology and what is meant? Just for someone 
who might make a hard distinction between hosts and routers (I do not, but 
I've encountered people who seems to do that).

So just to be clear, I do not oppose anything in the document, I think the 
document contains a lot of valuable information and I do not oppose the 
document moving forward, and it might just be more important to get the 
document out the door and create documents that discuss my above concerns 
separately at a later date.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Sep 2015 15:45:05 +0200

[...]
> using DHCP-PD to assign addresses to hosts

DHCP-PD can not be used to assign addresses to Hosts.

If you want to do that then you must come up with a mechanism for the 
Host to form an IP address out of an Interface ID and the prefix 
allocated by DHCP-PD.  Right now there is no such mechanism AFAIK.

Alex

  that the host is _NOT_
> expected to delegate downstream would be to assign a /80 from the /64
> shared on the media segment or a /64 if it is an isolated media segment.
>
> In this way, the host can manage 64 billion+ addresses as it sees fit
> and up the subnet still has plenty of chunks for all the likely hosts.
>
> If more than one subnet is needed, then multiple /64s should be assigned
> accordingly. If an entire subnet is needed, then I support assigning a /64.
>
> If we’re talking about (e.g.) VMs in a datacenter, I think this hybrid
> /80 approach represents a reasonable tradeoff in many circumstances.
>
> Owen
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Sep 2015 22:49:05 +0900

On Thu, Sep 17, 2015 at 10:45 PM, Alexandre Petrescu <
[email-masked]> wrote:

> If you want to do that then you must come up with a mechanism for the Host
> to form an IP address out of an Interface ID and the prefix allocated by
> DHCP-PD.  Right now there is no such mechanism AFAIK.
>

If the whole prefix is assigned to the host, there is no need to specify a
mechanism. The host can just pick whatever address it wants.

There is precedent for this in RFC 7084:

            ... it MUST create
            a global IPv6 address(es) from its delegated prefix(es) and
            configure those on one of its internal virtual network
            interfaces ...

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Sep 2015 15:58:08 +0200

Le 17/09/2015 05:15, Lorenzo Colitti a écrit :
> On Thu, Sep 17, 2015 at 11:56 AM, Owen DeLong <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> As such, I would like to advocate that a reasonable tradeoff if we
> are using DHCP-PD to assign addresses to hosts that the host is _NOT_

WE definitely must use common terminology.

A "smaller than /64" prefix is a prefix containing less addresses, i.e.
a "larger than 64" prefix length?

> Statefully allocating something smaller than /64 (let's use /80 as in
>  your example) forces any devices that wishes to provide downstream
> connectivity (e.g., to VMs, tethered devices, etc) to use stateful
> address assigment - presumably using DHCPv6 PD.

Statefully allocating a prefix whose len is larger than 64 forces any
device wishing to provide tethered connectivity to employ stateful
address assignment e.g. DHCP also on its downstream.  Because the only
way common Hosts (common: on Ethernet and keen kinds of links links,
with built-in SLAAC) can connect to this device is by involving an
Interface ID of length precisely 64 RFC2464.  Any prefix len larger than 
64 added to that Interface ID 64 will overflow the 128bit size of the 
IPv6 addresses.

> Because those hosts may well be general-purpose hosts, then that
> means that general-purpose hosts need to accept arbitrarily small
> prefixes.
>
> The reason is as follows: If I connect my laptop to a network and get
> a /80, then I can't give a VM or a tethered device more space than,
> say, a /88. That in turn forces any devices that wish to operate
> downstream to support stateful address assignment and accept a prefix
> size of /88. That means that if a network assigns a device a /88,
> then it will accept that prefix, but it will be unable to provide any
> downstream connectivity, and will be forced to implement NAT66 if it
> wishes to do so.
>
> I think any value that is /64 or smaller has this problem. /64 does
> not because it allows a device to use non-hierarchical means (such as
>  bridging and SLAAC) to extend the network.

YEs, I agree (provided we mean "any value that is larger than 64", 
because prefix lengths of size smaller than 64 are ok.)

Alex

> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Sep 2015 16:02:13 +0200

Le 17/09/2015 15:49, Lorenzo Colitti a écrit :
> On Thu, Sep 17, 2015 at 10:45 PM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     If you want to do that then you must come up with a mechanism for
>     the Host to form an IP address out of an Interface ID and the prefix
> If the whole prefix is assigned to the host, there is no need to specify
> a mechanism. The host can just pick whatever address it wants.

YEs from the routing perspective: they'll all be routed to it.  But I 
can guess there are exceptions (i.e. don't take 0, no 'ffff', etc.)

>              configure those on one of its internal virtual network

Sure it MUST, but how?

Alex

---

From: David Farmer <[email-masked]>
Date: Thu, 17 Sep 2015 10:09:18 -0500

The primary thesis of this draft is "don't limit hosts to one IPv6 address".  Don't limit them to 2 or 3, or 5, or 10 IPv6 addresses either.  The recommendation is there should be no specific limit at all.  However, if you are going to set a limit, for god sake, don't set it to anything less than 32.

Everything else is discussing the many reasons why hosts want more than one address or mitigating the counter arguments causing people to want to set a limit.  Tethering and virtual hosts are simple among the many reason NOT to limit the number of IPv6 addresses a host can have.  Assigning a /64 and routing is simply a way to mitigate neighbor discovery explosion, if you are worried about that.  It is not specifying when you should or should not do that, just saying there are other options than setting a limit on the number of IPv6 addresses a host can have.

This isn't about telling people how they should tether, or how many addresses to allocate or not to allocate, again the recommendation is "no specific limit" on the number of IPv6 addresses a host can have, that's it.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Sep 2015 20:21:22 +0200

Le 17/09/2015 17:09, David Farmer a écrit :
> The primary thesis of this draft is "don't limit hosts to one IPv6
> address".

Sorry it seems I dont understand.

Nobody limits a host to one IPv6 address.  The Host itself can make
2^64 addresses.  The multiplication of privacy addresses, multi-homing 
and various scopes - they are all in place in each IPv6 Host today.

What limit is this draft referring to?

I do believe there are some limits, but not in the number of addresses 
for a Host.

> Don't limit them to 2 or 3, or 5, or 10 IPv6 addresses either.  The
> recommendation is there should be no specific limit at all.  However,
> if you are going to set a limit, for god sake, don't set it to
> anything less than 32.

It sounds reasonable, if only there were a limit.

> Everything else is discussing the many reasons why hosts want more
> than one address or mitigating the counter arguments causing people
> to want to set a limit.  Tethering and virtual hosts are simple
> among the many reason NOT to limit the number of IPv6 addresses a
> host can have.  Assigning a /64 and routing is simply a way to
> mitigate neighbor discovery explosion, if you are worried about that.
> It is not specifying when you should or should not do that, just
> saying there are other options than setting a limit on the number of
> IPv6 addresses a host can have.
>
> This isn't about telling people how they should tether, or how many
> addresses to allocate or not to allocate, again the recommendation
> is "no specific limit" on the number of IPv6 addresses a host can
> have, that's it.
>

Ok.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Sep 2015 21:42:56 +0200 (CEST)

> What limit is this draft referring to?

The fact that the network administrator might say A=0, M=1 and only give 
out single IA_NA to the host. That is the specific deployment case that 
this draft is trying to say "don't do that".

---

From: 神明達哉 <[email-masked]>
Date: Thu, 17 Sep 2015 13:05:26 -0700

> issues that need to be addressed, please post your comments to the

I think this document raises an important question and generally
provides sensible and useful suggestions.  It's generally well written
overall.

But, I think I'd like to understand some bigger picture, even if this
may be out of scope of this particular document in the end.  Consider
cases like a hotel network where hotel guests are charged connectivity
fee per the number of MAC (layer 2) addresses so every different
"device" is charged separately.  I suspect such setup is not uncommon,
and I guess avoiding the "double charge" is one motivation for
supporting NAT66 for VMs (https://communities.vmware.com/docs/DOC-29954).

Now, specifically what would we propose with this document so we won't
end up using NAT66 in this situation?  Discouraging the operators of
such networks from deploying "per-device" charge is certainly one
option, but since this document actually tries to promote the
(possibility of) use of multiple addresses (which can mean multiple
MAC addresses depending on the underlying technology), we can't say
"it may prove counterproductive if customers respond by using NAT".
So, let's assume (for now) this type of charge won't disappear anyway.
Then another solution would be to suggest using prefix delegation in
such networks, but that is largely up to the operator, and they
probably don't see an incentive to do this since they'd rather have
the possible extra revenue due to the per-device charge.  It may also
not be feasible in terms of address space management for this kind of
network.  Yet another solution would be to implement the RFC7278-style
of prefix sharing in the VM host, but in this case the prefix must be
completely owned by each physical device.  I'm not sure if this
assumption is feasible in this case.

Obviously we won't be able to solve all possible cases, and in any
case it's probably not in the scope of this document to provide *any*
such solution.  But I'd like to see one feasible scenario of
specifically how this document can be used in a scenario like the
above one, and (while it may be only me) I couldn't be sure about that
just by reading the draft.  It would be nice if this is somehow
clarified in this last call discussion, and it would be nicer if some
part of it is applied to the draft itself.

=====

Some specific comments to the draft body:

- On the table in Section 6: I don't understand why the cell for
  'DHCPv6 PD' x '"Unlimited" endpoints' is 'No'.

- (minor nit) Section 7, first sentence: s/section Section/Section/

   If we itemize the use cases from section Section 3, we can estimate

- Section 8:

   Assigning prefixes smaller than a /64 will limit the flexibility of

  I vaguely remember someone already made the same comment, but
  "smaller than a /64" sounds ambiguous to me (is /63 is "smaller" or
  "larger" than /64?).  I suggest:

   Assigning prefixes with the length larger than 64 will limit...

- Section 9.1

   [...]  Additionally, attempts to track this sort
   of information via DHCPv6 are likely to become decreasingly viable
   due to ongoing efforts to improve the privacy of DHCP

  This is true, but isn't it the same for (e.g.) SLAAC due to the
  ongoing efforts to improve privacy (e.g. by employing MAC address
  randomization)?  So this rather seems to be about the discussion of
  how/whether host tracking is performed in general in the privacy
  conscious era, rather than about how the addresses are configured.

- Section 9.1

   Indeed, many large
   enterprise networks, including the enterprise networks of the
   authors, are fully dual-stack but do not currently use or support
   DHCPv6.

  - In this context, host tracking should also be performed in some
    way (otherwise not using DHCPv6 doesn't add any information in the
    context).  Is that the case?
  - A minor point, but I wonder whether this means both Google or
    Apple, or only either of them.  Not that important, but if it's
    the latter I'd say "some authors" instead of "the authors" to be
    accurate.

- Section 9.2, first paragraph

   [...] In IPv6, that is equivalent to assigning one
   /64 per host out of a /48.

  On the first read I didn't get it smoothly.  Maybe it's trivial to
  others, but I'd suggest revising this sentence as:

    In IPv6 with the recommendation of providing each host with
    multiple addresses, that is equivalent to assigning one /64 per
    host out of a /48.

  Same for the second paragraph.

- Section 9.2

   Currently, residential users receive one IPv4 address and a /48, /56
   or /60 IPv6 prefix.  While such networks do not have enough space to
   assign a /64 per device, today such networks almost universally use
   SLAAC.

  I don't get what the second sentence tries to implicate in this
  context.  Some more explanation might help here.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Sep 2015 08:43:51 +1200

On 18/09/2015 08:05, 神明達哉 wrote:
> "device" is charged separately.  

In my experience the system is more often a restriction to two or three
devices per hotel room. My most recent hotel stay was annoying because
we had one laptop and two smartphones with us, and only two of them could
connect simultaneously. But you are correct, this is a common problem.

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.

    Brian

> I suspect such setup is not uncommon,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Sep 2015 22:44:25 +0200 (CEST)

> end up using NAT66 in this situation?  Discouraging the operators of

The proposal is to use DHCPv6-PD because otherwise we'll get NAT66, as you 
already have identified.

The operator(s) needs to understand that they can't charge per-device 
because that doesn't actually work, because then the customer will deploy 
NAT66, then the operator will deploy DPI to look into user-agent string, 
and then the customer will encrypt everythingm and now the operator has 
lost all insight into what the customer is doing, and the operator has 
lost and we're all worse off than when we started.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Sep 2015 22:48:15 +0200 (CEST)

On Fri, 18 Sep 2015, Brian E Carpenter 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.

So while this is extremely true, I'm not sure that this draft is the place 
to try to share this kind of opinion. I've seen people working for 
operators that called it "abuse" when their customers used tethering on a 
non-tethering mobile plan. The only thing the customer really needs to 
tell the operator is source and destination address, and the operator can 
tell the size of the packet. Anything else will become invisible to the 
operator if they try to use this information for differentiation between 
plans.

It's actually taken longer than I thought to get a lot more encryption 
considering the amount of DPI and recompression etc of concent that is 
done in the fly today.

---

From: David Farmer <[email-masked]>
Date: Thu, 17 Sep 2015 23:58:32 -0500

>> On Sep 17, 2015, at 14:42, Mikael Abrahamsson <[email-masked]> wrote:
>> 
> The fact that the network administrator might say A=0, M=1 and only give out single IA_NA to the host. That is the specific deployment case that this draft is trying to say "don't do that".

Ok, I just reread the Draft, and I think it probably needs to say that it is possible to limit the number of IPv6 addresses a host can receive by disabling SLAAC (A=0 in the RA) and implementing a limit within the DHCPv6 server.  Other readers may be under the misimpression that it is not possible to limit the number of IPv6 addresses a host can receive.  If they are under this misimpression, the Draft and its arguments may not completely make sense.

Disabling SLAAC and using the DHCPv6 server to limit the number of IPv6 addresses a host can receive, while the most logical way to achieve such a limit, it is by no mean the only way.  While somewhat perverse, and probably considered malicious activity by many, it would also be possible to use DAD to deny the use of additional addresses by a host even in a SLAAC only environment.  Given that this is just plain evil, only the more conventional DHCPv6 form of limiting the number of IPv6 addresses a host can receive needs to be acknowledged in the Draft.

So while I totally agree with the recommendation of no specific limit on the number of IPv6 addresses that a host should be allowed to use; I think it also should be discussed that network operators may consider a single host using an exorbitant number of IPv6 addresses as malicious activity.  Again, a specific number for what is "exorbitant" isn't going to be possible.  But a general-purpose host using many hundreds or thousands of IPv6 addresses is likely to be considered malicious activity by at least some network operators.

I'll note we have seen hosts on our network consuming many hundreds to more than a thousand IPv6 addresses in a relatively short period (like as little as few hours).  We haven't been able to determine the cause of this; a bug, overly aggressive privacy settings, or genuine malicious activity are all plausible explanations.  We are not limiting hosts with this curious use profile today, and at least at this point, we don't intend to either.  However, if in the future hosts with this profile were to be shown to be a significant source of malicious activity on our network; I suspect we would quickly change our views on this issue and impose some kind of limit.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 18 Sep 2015 07:31:10 +0200 (CEST)

On Thu, 17 Sep 2015, David Farmer wrote:

> Ok, I just reread the Draft, and I think it probably needs to say that 
> it is possible to limit the number of IPv6 addresses a host can receive 
> by disabling SLAAC (A=0 in the RA) and implementing a limit within the 
> DHCPv6 server.  Other readers may be under the misimpression that it is 
> not possible to limit the number of IPv6 addresses a host can receive. 
> If they are under this misimpression, the Draft and its arguments may 
> not completely make sense.

The introduction pretty much says that it's possible to limit the number 
of adresses to 1, but it doesn't say how.

I am not one of the authors, but I'd imagine they didn't want to spell out 
exactly how to limit the addresses to 1 because they don't see this as a 
desired outcome, but I guess it could be included in section 2 that the 
analogy how things are normally done in IPv4 (DHCPv4 single address) for 
IPv6 is DHCPv6 IA_NA single address, A=0, M=1. I'd imagine this is not an 
uncommon deployment model today for IPv6 in some networks, and I have 
heard network administrators express a desire for this outcome. The draft 
is a response to that, and instead suggests that hosts get an address 
range (single block) instead of single address. I believe this is a good 
compromise, but it would require hosts to gain this functionality, and 
network administrators to implement this.

Perhaps you could suggest text and where to put it so the authors can 
consider it?

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 18 Sep 2015 10:43:18 +0200

> this draft is trying to say "don't do that".

That makes sense.

So this is a recommendation for DHCP-Address to deliver more than one 
GUA or ULA address (in case the A/M mix in RA forbids the Host to 
SLAAC).  I agree with it.

 From this, I dont think it should recommend to involve DHCP-PD to solve 
that problem, because (1) there is no specified way to form an address 
out of the prefix in DHCP-PD and (2) the routing established by DHCP-PD 
needs an address already formed on the Host (not out of that prefix).

(for (2) one needs to read draft-petrescu-relay-route-pd-problem-00.txt
  written in 2013)

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 18 Sep 2015 20:52:40 +0200

>>> 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.
>>
>> provides sensible and useful suggestions.  It's generally well
>> written overall.
>>
>> But, I think I'd like to understand some bigger picture, even if
>> this may be out of scope of this particular document in the end.
>> Consider cases like a hotel network where hotel guests are charged
>> connectivity fee per the number of MAC (layer 2) addresses so every
>> different "device" is charged separately.
>
> In my experience the system is more often a restriction to two or
> three devices per hotel room.

I agree, for IPv4.

But is there such hotspot with IPv6 addresses?  I doubt so.  In my
recent travels I never seen one IPV6 hotspot in a hotel, restaurant,
airport, plane, taxi, bus.

I speculate the first public IPv6 hotspots will use SLAAC (not DHCP) and
filter on the MAC addresses with captive portals.

In these cases a good recommendation would be a recommendation on the
firewall (allow multiple MAC addresses), less on DHCP because DHCP is 
not used.

Also, in these cases the risk is - in addition to NAT66 - the end user
multiplexing one MAC address among multiple devices (user tools to set 
MAC addresses, and hardwar supporting it, are widely available), which 
risks breaking other things than the things which NAT66 breaks.

> My most recent hotel stay was annoying because we had one laptop and
> two smartphones with us, and only two of them could connect
> simultaneously. But you are correct, this is a common problem.

Yes, I fully agree.  I experienced same problem.

> 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.

Well, I think one particular IP address can still be used to identify 
one device in order to load balance.  But do not assume there to be as 
many devices as IP addresses are.

I dont know how crude load balancers may work, though.

Alex

>
> Brian
>
>> I suspect such setup is not uncommon, and I guess avoiding the
>> "double charge" is one motivation for supporting NAT66 for VMs
>> (https://communities.vmware.com/docs/DOC-29954).
>>
>> Now, specifically what would we propose with this document so we
>> won't end up using NAT66 in this situation?  Discouraging the
>> operators of such networks from deploying "per-device" charge is
>> certainly one option, but since this document actually tries to
>> promote the (possibility of) use of multiple addresses (which can
>> mean multiple MAC addresses depending on the underlying
>> technology), we can't say "it may prove counterproductive if
>> customers respond by using NAT". So, let's assume (for now) this
>> type of charge won't disappear anyway. Then another solution would
>> be to suggest using prefix delegation in such networks, but that is
>> largely up to the operator, and they probably don't see an
>> incentive to do this since they'd rather have the possible extra
>> revenue due to the per-device charge.  It may also not be feasible
>> in terms of address space management for this kind of network.  Yet
>> another solution would be to implement the RFC7278-style of prefix
>> sharing in the VM host, but in this case the prefix must be
>> case it's probably not in the scope of this document to provide
>> *any* such solution.  But I'd like to see one feasible scenario of
>> above one, and (while it may be only me) I couldn't be sure about
>> that just by reading the draft.  It would be nice if this is
>> somehow clarified in this last call discussion, and it would be
>> nicer if some part of it is applied to the draft itself.
>>
>> =====
>>
>> "smaller than a /64" sounds ambiguous to me (is /63 is "smaller"
>> or "larger" than /64?).  I suggest:
>>
>> [...]  Additionally, attempts to track this sort of information via
>> DHCPv6 are likely to become decreasingly viable due to ongoing
>> efforts to improve the privacy of DHCP
>>
>> randomization)?  So this rather seems to be about the discussion
>> of how/whether host tracking is performed in general in the
>> privacy conscious era, rather than about how the addresses are
>> configured.
>>
>> - Section 9.1
>>
>> Indeed, many large enterprise networks, including the enterprise
>> networks of the authors, are fully dual-stack but do not currently
>> use or support DHCPv6.
>>
>> context).  Is that the case? - A minor point, but I wonder whether
>> this means both Google or Apple, or only either of them.  Not that
>> important, but if it's the latter I'd say "some authors" instead of
>> "the authors" to be accurate.
>>
>> [...] In IPv6, that is equivalent to assigning one /64 per host out
>> of a /48.
>>
>> Currently, residential users receive one IPv4 address and a /48,
>> /56 or /60 IPv6 prefix.  While such networks do not have enough
>> space to assign a /64 per device, today such networks almost
>> universally use SLAAC.
>>
>> -- JINMEI, Tatuya

---

From: Silvia Hagen <[email-masked]>
Date: Fri, 18 Sep 2015 19:43:43 +0000

> But is there such hotspot with IPv6 addresses?  I doubt so.  In my recent travels I never seen one IPV6 hotspot in a hotel, restaurant, airport, plane, taxi, bus.

Then you have not been in Zurich yet, or in the wrong hotel  :-)

Monzoon (http://www.monzoon.net/)  is offering dual-stack wifi for hotels since many years and so any hotel that works with Monzoon has IPv6. Most guests simply don't realize and maybe not even the hotels know. But my IPv6 teachers do :-)

Silvia

---

From: 神明達哉 <[email-masked]>
Date: Fri, 18 Sep 2015 16:05:01 -0700

At Thu, 17 Sep 2015 22:44:25 +0200 (CEST),

> lost and we're all worse off than when we started.

If we can convince those operators about stopping the per-device
charge this way, what we actually need is a "Per-device connectivity
charge is considered ineffective and harmful" draft.  Then the
operators will stop the practice, and there will be no reason for
implementing and deploying NAT66 for, e.g., VMs (at least for this
reason); we don't need the host-addr-availability draft to stop NAT66.

Likewise,

> The proposal is to use DHCPv6-PD because otherwise we'll get NAT66, as you

we won't need to propose this; the straightforward "bridge mode"
should just work without extra charge.  I think this matters, since
the proposal of using DHCPv6-PD requires a certain amount of
implementation and operational cost for both the network operator and
host-side implementors (such as VM vendors).

I don't deny that the host-addr-availability draft may be useful for
other reasons, so I'm not necessarily opposed to advancing this draft
because of this.  But my interpretation of the draft was that it
intends to avoid the proliferation of NAT66 in cases like this
scenario, and I was not sure whether host-addr-availability is really
effective: if we can simply convince hotel network operators, we'll
only need the above "ineffective and harmful" draft; if not, it's
also quite unlikely that those operators are willing to deploy
DHCPv6-PD, so host-addr-availability will be still not effective.

Or, it's also quite possible that I completely misunderstood
something, such as about the purpose of the draft or how it can be
used for the scenario I asked.  If so, I'm happy to be corrected.

--
JINMEI, Tatuya

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 19 Sep 2015 06:19:29 +0200 (CEST)

On Fri, 18 Sep 2015, 神明達哉 wrote:

> If we can convince those operators about stopping the per-device charge 
> this way, what we actually need is a "Per-device connectivity charge is 
> considered ineffective and harmful" draft.  Then the operators will stop 
> the practice, and there will be no reason for implementing and deploying 
> NAT66 for, e.g., VMs (at least for this reason); we don't need the 
> host-addr-availability draft to stop NAT66.

Well, there are operational benefits of using DHCPv6-PD to hosts as well, 
instead of using a lot of individual addresses. When doing BCP38 filtering 
and other operations on packets, it's usually more effective to have fewer 
resources (addresses/prefixes) to act on. Some wifi systems only allow for 
8 addresses simultaneously for a host, and just drop all packets from any 
additional addresses.

> host-side implementors (such as VM vendors).

I'd say most of the cost is on the host OS implementor side, and looking 
at who brought this draft, they are actually the ones suggesting this.

> DHCPv6-PD, so host-addr-availability will be still not effective.

Android does not today support DHCPv6 IA_NA. So if that continues, a large 
part of the mobile device market will not support a DHCPv6 IA_NA 
network, and a network provider trying to do this, will not succeed in 
providing connectivity. I can imagine more devices that do support IA_NA 
will treat that networks as one "with limited capability" and turn off 
some functions. This is how we drive network operators to support IA_PD 
instead, by making the customers aware of what's going on.

There are two ways that actually solves the problem at hand:

Use SLAAC, but give each Wifi connection its own separate /64 using A=1 
(separate broadcast domain per wifi attachment). This works with keeping 
track of who did what etc, just save the mac address or 802.1x credentials 
together with the /64 that was given, you can do filtering on this /64 
etc.

Use DHCPv6-PD and give the device a /XX.

Both of these works exactly the same as in IPv4 with the same tracking 
ability etc that I have heard enterprise and education provider desire to 
keep from their current IPv4 deployments.

But it does require them to move from "One address per device" thinking, 
to "one subnet per device" thinking, which is the exact thing this draft 
tries to propose. I think the current draft tries to do both "single 
address is harmful" and also "here's how to solve it". So I don't think 
it's enough to have a "this is harmful"-draft, we also need proposed 
solution, which this draft proposes.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 19 Sep 2015 15:24:40 +0900

On Fri, Sep 18, 2015 at 5:05 AM, 神明達哉 <[email-masked]> wrote:

> end up using NAT66 in this situation?

What we recommend is that operators do not attempt to do this, because
there is no point in doing so. The reason that there is no point in doing
so is that a device can *always* extend the network, even if it only has
one IP address. All it needs to do is to enable NAT for the devices behind
it. The draft makes this point very clearly:

======
   It is likely
   not desirable for network operators either, as they may suffer higher
   support costs, and even when the decision to assign only one IPv6
   address per device is dictated by the network's business model, there
   may be little in the way of incremental revenue, because devices can
   share their IPv6 address with other devices.
======

So, what we are telling network operators is: "we do not recommend that you
do this, because there's not much point in doing it, and it's worse for
everybody if you do."

If they want to do it anyway, well, there's not much we can do about that.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 19 Sep 2015 15:33:01 +0900

On Sat, Sep 19, 2015 at 8:05 AM, 神明達哉 <[email-masked]> wrote:

> operators will stop the practice

I don't think we will stop operators from doing this just by writing an RFC
saying it's a bad idea. :-)

> should just work without extra charge.

The reason we propose DHCPv6 PD is because some network operators -
particularly enterprise and educational network operators - insist that the
only way their network will assign IPv6 addresses is via DHCP. In many of
these networks (e.g., networks doing 802.1x) bridging isn't even an option.

Once you have decided to use DHCPv6, you have two options: multiple IA_NA
and PD. We believe that DHCPv6 PD is better and more future-proof than
multiple IA_NA for the reasons listed in sections 7 and 8.

---

From: [email-masked]
Date: Sat, 19 Sep 2015 11:30:39 +0200 (CEST)

> 8 addresses simultaneously for a host, and just drop all packets from any 

As an operator, I'd *love* to only give out DHCPv6-PD prefixes, and
get completely rid of IA_NA. Unfortunately, host support for PD is
not exactly great.

Steinar Haug, AS 2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 19 Sep 2015 18:39:06 +0900

> get completely rid of IA_NA. Unfortunately, host support for PD is

Publishing this draft as an RFC will help change that.

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Sep 2015 19:41:57 +1000

> Publishing this draft as an RFC will help change that.

+1

---

From: [email-masked]
Date: Sat, 19 Sep 2015 12:12:39 +0200 (CEST)

> multiple IA_NA for the reasons listed in sections 7 and 8.

Fully agreed. We would like to get to a point where we don't use IA_NA
at all, only DHCPv6 PD.

Steinar Haug, AS 2116

---

From: joel jaeggli <[email-masked]>
Date: Mon, 21 Sep 2015 09:13:00 -0700

On 9/18/15 11:33 PM, Lorenzo Colitti wrote:
> On Sat, Sep 19, 2015 at 8:05 AM, 神明達哉 <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> I don't think we will stop operators from doing this just by writing an
> RFC saying it's a bad idea. :-)

I don't have a problem with the idea of describing a particular approach
as bad on the basis of technical merit.  thou must allow tethering on
the other hand is about business models which I'm really not interested
in delving into. there are diverse methods used dto enforce that however.

> particularly enterprise and educational network operators - insist that
> the only way their network will assign IPv6 addresses is via DHCP. In
> many of these networks (e.g., networks doing 802.1x) bridging isn't even
> an option.

it's unlikely in the context of homenetworks or mobile devices that
bridging is universally acceptable in any event.

> Once you have decided to use DHCPv6, you have two options: multiple
> IA_NA and PD. We believe that DHCPv6 PD is better and more future-proof
> than multiple IA_NA for the reasons listed in sections 7 and 8.
> 
>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 21 Sep 2015 11:57:53 -0700

At Sat, 19 Sep 2015 15:33:01 +0900,

> saying it's a bad idea. :-)

To be clear, I didn't intend to suggest writing an "ineffective and
harmful" draft.  I also know the host-addr-availability draft
explicitly discusses why it doesn't recommend practices like
per-device charge.  What I've been trying to say is:

- the most critical point to prevent the proliferation of NAT66 is to
  convince those operators that per-device charge is a bad idea (or at
  least not effective)
- if they agree on this, we can then discuss better practices of host
  address configuration, DHCPv6-PD for each host, just use SLAAC, etc.
- if they don't agree, having the "better practice" discussions
  won't be very useful, since they won't be willing to deploy
  DHCPv6-PD, and regardless how they assign addresses the number of
  addresses will be still limited anyway.

I said I wanted to see a "bigger picture" in my first message of this
thread because on first read my impression was that the "big goal" (or
at least one important goal) of this draft was to stop NAT66 while it
rather seemed to focus on the "less critical points" (the second and
third bullets above).  But, according to the discussion in this
thread, perhaps I misunderstood this fundamental point.  Perhaps I
should have interpreted it as:

- although we don't like to see NAT66 due to practices like per-device
  charge and we can point out why such a practice might not be a
  good/effective idea, we don't know if it will convince those
  operators.  (and, therefore, NAT66 may or may not be more widely
  used).
- but, *if* they stop those practices with this argument or for some
  other reasons, we can think about better/best ways to assign IPv6
  addresses for end hosts.  This draft focuses on this part in the
  hypothetical environment where there's no such practice as
  per-device charge.

Am I now understanding the intent more accurately?

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Sep 2015 16:18:32 +0900

> Am I now understanding the intent more accurately?

I think you're only focusing on part of the picture - operators that assign
a limited number of addresses per device out of a desire to obtain more
revenue.

Another part of the picture is deployments that only support IPv6
addressing via DHCPv6 and do not support SLAAC. Some of the network
administrators have said they do this partly due to a desire to have "one
GUA per device" or "a limited number of GUAs per device". These networks
are likely *not* concerned with per-device revenue, but they still provide
a limited number of addresses for other reasons (some of which may be
operational, or even scaling reasons). Because they are not concerned with
per-device revenue, even if we convince people that per-device charging is
ineffective to increase revenue, then these networks will still be
assigning a limited number of addresses per device.

This is why the draft makes a more general statement about all networks
that do not provide enough address space, regardless of the reason.

To respond to your earlier concern that we shouldn't recommend DHCPv6 PD
because of the implementation and operational cost, then I would note that:

   1. The draft does not recommend DHCPv6 PD in general, only on networks
   whose policy is to hand out address space only based on explicit requests
   from the host. The vast majority (in terms of number of connected devices)
   of networks, which use SLAAC, do not fall into that category
   2. What's the alternative? If DHCPv6 PD is too much work, then that
   rules out designing a new protocol, since that's even more work. That
   leaves either SLAAC or DHCPv6. If the network has decided that stateful,
   request-based assignment is the only supported way to obtain addresses
   (e.g., for security reasons), then I doubt they're ever going to use SLAAC.
   At that point, it's either multiple IA_NA or DHCPv6 PD, and as set out in
   the draft, there are strong reasons to recommend PD over multiple IA_NA.

Cheers,
Lorenzo

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Sep 2015 08:45:29 +1200

On 22/09/2015 19:18, Lorenzo Colitti wrote:

I'm fundamentally in favour of what the draft is trying to do, but...

> These networks
> operational, or even scaling reasons).

And I don't think your document will succeed in its purpose unless it
explicitly recognises that those operational or scaling reasons may be
reasonable and valid. As you know, operators will do what they need to do.

Let's see: on a campus with a few tens of thousands of students, mainly
connected wirelessly, will we have problems if a few hundred of them run
a popular new app that generates a couple of thousand addresses when
given a /64 to play with?

Ditto if they catch a Trojan that knows how to have fun with its own /64.
How quickly will the whole campus be black-listed?

Will the campus have severe legal problems if a couple of thousand students
use a new address-agile file sharing app that saturates any form of
audit logging, so that offending users can't be identified?

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 23 Sep 2015 06:32:45 +0200 (CEST)

> How quickly will the whole campus be black-listed?

Well, then the other end should blacklist per /64 and not per /128.

> audit logging, so that offending users can't be identified?

You do audit logging on the /64 handed out, I don't see how this is 
different from handing out /128 or single address in IPv4?

---

From: Mark Smith <[email-masked]>
Date: Wed, 23 Sep 2015 16:01:42 +1000

> different from handing out /128 or single address in IPv4?

I'm surprised it seems networks with this auditing security
requirement aren't requiring authentication to attach to them (e.g.,
IEEE 802.1X), which would then provide an opportunity associate a
user's identity with the addresses they're given and/or using during
the authenticated session.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 23 Sep 2015 08:20:59 +0200 (CEST)

On Wed, 23 Sep 2015, Mark Smith wrote:

> I'm surprised it seems networks with this auditing security requirement 
> aren't requiring authentication to attach to them (e.g., IEEE 802.1X), 
> which would then provide an opportunity associate a user's identity with 
> the addresses they're given and/or using during the authenticated 
> session.

A lot of them do. Then fewer of them use first-hop-security (SAVI), so 
it's questionable if it actually buys them real security, but at least it 
logs the mac address of the user when they connect, and perhaps their 
system at least doesn't allow the user more than one mac address or 
changing mac addresses mid-session.

But it's when one brings up SLAAC A=1 with these people that they tend to 
get upset, even when one points out that one can scrape ND tables to find 
out what address belonged to what mac address at a given time. So thus 
this proposed middle ground between multi-address capability and DHCP 
based tracking of who had what IP address(es) at what time, where they can 
keep using their DHCP infrastructure to do the IP/mac/user tracking, but 
instead of single IA_NA they now have single IA_PD to the device.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 23 Sep 2015 19:38:43 +0900

> given a /64 to play with?

It depends whether there are any stateful devices in the path, and how
smart those stateful devices are. A university campus with no stateful
firewall and only IPv6 will never have scaling issues if it assigns a /64
per device. A campus that uses stateful firewalls might - but note that
this is a problem even today, and even in IPv4 - a determined attacker can
attempt to exhaust NAT or firewall state by opening lots of connections to
lots of different IP addresses, for example.

> How quickly will the whole campus be black-listed?

Never, because any server that supports IPv6 today needs to survive in the
presence of residential users with /56 prefixes and spammers / DoSers with
servers in datacenters that get /48s from tunnel brokers. The content
providers and CDNs started seeing and dealing with those attacks a long
time ago.

> audit logging, so that offending users can't be identified?

Not if the campus assigns a /64 per device or per user. They can just pin
the blame on that /64.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Sep 2015 08:40:36 +1200

> Not if the campus assigns a /64 per device or per user. They can just pin

And my whole point: if assigning a /64 does *not* cause scaling, logging
or security problems the draft needs to explain why not, as you and Mikael
and Mark have done. Otherwise, I can pretty much guarantee that those arguments
will be used against it.

(And I forgot to mention ND cache scaling.)

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Thu, 24 Sep 2015 11:29:41 -0700

At Tue, 22 Sep 2015 16:18:32 +0900,

> a limited number of addresses per device out of a desire to obtain more

I was aware there are other cases and the draft discusses those, but
you're probably right that I focused on this particular issue too
much.  I guess that's because I thought the counter argument against
this practice didn't seem very persuading to me (and I thought it
wouldn't for those operators) compared with that for other issues.
Yet the issue looked quite major to me, so I thought if we can't
resolve this case then improvements on other issues won't help much to
prevent wider deployment NAT66.

> because of the implementation and operational cost, then I would note that:

I don't think this is what I tried to say.  This concern was in the
context of my primary focus on the "per-device revenue" case rather
than a general concern about recommending DHCPv6 PD in terms of cost.
My point was just that if we can somehow convince those operators (and
the operators don't have other reasons to use stateful address
management), then other approaches than DHCPv6 PD to provide multiple
global addresses would be more preferable as they are less costly.

To be clear, I'm basically not opposed to anything described in the
draft.  Although some of the arguments against particular operational
practices seemed weak to me, it's just a subjective impression, and I
understand operators will do whatever they want anyway, however strong
counter arguments are.  In this discussion I just tried to understand
what this draft really tries to achieve with what assumptions and
which specific recommendations.  Based on the discussion in this
thread, these seem to be pretty clear for some people, so it may be
only me, but these were not really very clear for me.  That's why I
raised these points.

So, hopefully now understanding the points more clearly, if I may
suggest something for the draft in the context of WGLC, it would have
been clearer for me if the draft was organized this way:

1. describe why we want multiple addresses
2. describe cases that don't allow it and why such practices are employed:
   - per device/address charge
   - host tracking
   - scaling issues
  And explain why we (authors) think these are not effective or are
  even harmful.  Also clarify that it's beyond the scope of this draft
  to full convince those operators (and in fact it will be impossible
  since operators will do whatever they want anyway).
3. recommendations
  - don't do filtering based on the number of L2/L3 addresses per link
    if tracking/scaling is not an issue
  - if tracking/scaling is a concern, use DHCPv6-PD for each host
  - if tracking/scaling is not a concern, just advertising /64 via RA
    may be enough, but applications such as VM should use a bridge
    mode instead of NAT66

The current version of the draft is good about point #1 (described in
Section 3).

I can see point #2 is also covered with a very careful read (except
the "clarification"), but it wasn't clear to me before this thread,
since the information is scattered in multiple sections (per device
charge is described in Section 4 as part of "why harmful" discussion,
tracking issues are in Section 9 after the recommendations section,
etc).  Regarding the "clarification", it would have helped me
understand the draft better since I originally thought convincing
those operators is one major goal of this document.

Point #3 is currently Section 8.  It wasn't very clear to me in terms
of the bullets listed above.  Perhaps it would be better if it
explains in which case each specific recommendation should be used
more clearly.  I think it would also help if it mentioned the need for
using a "VM bridge mode" (or something similar to it).

On a related note, I found the first sentence of Section 8
particularly unclear to me:

   In order to avoid the problems described above, and preserve the

in that what are "the problem" isn't clear.  That's probably because
the related information is scattered, so if the draft is reorganized
it might be resolved automatically; or it may be better to explain
"the problem" more specifically.

--
JINMEI, Tatuya