Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jul 2015 19:45:24 +1200

I like -01 even better than -00.

As well as the reference [TARP], you might add draft-smith-enhance-vne-with-ipv6
as a use case for a /64 per host (specifically per NVE, network virtual edge).

Regards
   Brian

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 Jul 2015 11:15:42 +0200

Random question: how you doing DHCP PD interact with Homenet's HNCP?

---

From: Mark Smith <[email-masked]>
Date: Sat, 25 Jul 2015 14:07:19 +1000

Hi,

> I like -01 even better than -00.

So do I.

> as a use case for a /64 per host (specifically per NVE, network virtual edge).

I've never really thought of tunnel end-points (NVEs in that draft) as
'hosts', however I suppose they are if they're the final destination
for the packet, as NVEs are for underlay network packets.

I've been thinking a bit recently about how to describe/determine
where the network "finishes" and the host/end "starts", partly in the
context of things like Segment Routing and "service function chaining"
or "network function virtualisation". I've thought the simple and
fundamental rule is that the network ends and the host/end starts at
the "payload don't care/care" boundary. If the receiving device
doesn't care what the payload is (and therefore doesn't care if the
payload is encrypted or not), then it is a device in the network. If
receiving device cares about what the payload is, then it is
performing host/end functions.

By that definition, even though NVEs are only performing layer 2/layer
3 frame/packet processing, they're hosts/ends, because they look at
and process the payload of the packet they receive that are directed
specifically at them (i.e., packet dest addr is their own /64 prefix
in that draft).

Regards,
Mark.

> Regards
>    Brian
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 27 Jul 2015 11:11:24 +0900

In practice, in a homenet network it will make sense to use SLAAC instead
of DHCPv6 PD. The recommendation for PD is to use DHCPv6 PD if a network
"requires explicit requests for address space", i.e., if SLAAC is not
available.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 27 Jul 2015 10:26:05 +0200

>"requires explicit requests for address space", i.e., if SLAAC is not

I didn't keep track, did homenet explictly pick SLAAC over DHCPv6?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 27 Jul 2015 17:28:19 +0900

> I didn't keep track, did homenet explictly pick SLAAC over DHCPv6?

I don't think the architecture specifies anything. That said, because
homenet is dynamic and many hosts don't support RECONFIGURE, using stateful
DHCPv6 in the home is likely a bad idea because it will break things when
renumbering.

---

From: Gert Doering <[email-masked]>
Date: Mon, 27 Jul 2015 11:12:41 +0200

Hi,

> I didn't keep track, did homenet explictly pick SLAAC over DHCPv6?

DHCPv6 or DHCPv6-PD?  You're mixing terms...

For hosts, SLAAC is used, for non-homenet routers behind a homenet,
DHCPv6-PD.  Not sure about DHCPv6 for hosts, though.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Philip Homburg <[email-masked]>
Date: Mon, 27 Jul 2015 12:12:48 +0200

>DHCPv6-PD.  Not sure about DHCPv6 for hosts, though.

My reasoning is, you want DHCPv6-PD for hosts if hosts are doing DHCPv6 because
otherwise they would have to obtain losts of DHCPv6 leases.

Now if homenet has decided that there will never be DHCPv6 for hosts on 
homenet then this is a non-issue.

If they didn't make such a decision, then we have to think how DHCPv6-PD for
hosts would work in a homenet environment.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Jul 2015 07:24:33 -0400

> otherwise they would have to obtain losts of DHCPv6 leases.

You don’t want them to obtain lots of DHCPv6 leases.   Why would that be a good idea?   I would suggest ten as an upper limit, and that’s easily addressed with IA_NA.   IA_PD would be overkill, and hosts don’t support it anyway.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 27 Jul 2015 21:28:20 +0900

On Jul 27, 2015 20:24, "Ted Lemon" <[email-masked]> wrote:
>
> You don’t want them to obtain lots of DHCPv6 leases.   Why would that be
a good idea?   I would suggest ten as an upper limit, and that’s easily
addressed with IA_NA.   IA_PD would be overkill, and hosts don’t support it
anyway.

Ted, please read the draft :-)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Jul 2015 08:32:07 -0400

> Ted, please read the draft :-)

Fair point. :)

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Mon, 27 Jul 2015 15:25:18 +0200

On 7/27/15, Ted Lemon <[email-masked]> wrote:
> You don’t want them to obtain lots of DHCPv6 leases.   Why would that be a
> good idea?   I would suggest ten as an upper limit, and that’s easily
> addressed with IA_NA.
> IA_PD would be overkill, and hosts don’t support it
> anyway.
>

The disjoint nature of IA_NA means a corresponding number of TCAM
entries is required on L3 switches.

A prefix, on the other hand, requires just an entry for the link-local
of the host + an entry for the prefix. Regardless of the prefix
length.

Thus: the scaling properties on the network hardware side are vastly different.

Also, the draft talks about twenty addresses being needed.

--a

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Jul 2015 13:59:44 +0200

Hi,

> of the host + an entry for the prefix. Regardless of the prefix

All true.  But then you excercise pressure on the prefix allocation side
- instead of having "one /64 for that LAN segment, which is big enough
for arbitrary number of hosts" you end up with "a /52[-ish] per LAN segment
to cover DHCP-PD delegation to thousands of hosts".

(Say, 1000 hosts, all doing DHCP-PD and requesting a single /64, you'd
need to provision at least a /54 per segment - which will increase your
prefix usage enormously)

Is that what you want?

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Jul 2015 21:05:05 +0900

> need to provision at least a /54 per segment - which will increase your

It's almost exactly what we have today in IPv4 - see the section in the
draft on address space management.

That said - you don't have this problem if you use SLAAC.

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Jul 2015 14:11:06 +0200

Hi,

> draft on address space management.

Yeah, but who wants to replicate IPv4?  (Besides, it isn't :-) )

> That said - you don't have this problem if you use SLAAC.

If you use SLAAC your devices do not need to store 20 ND associations?

I understood Andrew that this was the reason why he thinks DHCPv6-PD
scales better than getting 20 addresses by other means...

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Jul 2015 14:14:26 +0200

>need to provision at least a /54 per segment - which will increase your

Say you can have at least 100 prefixes per /56. Then that should be enough for
most home installations. 

Then RIRs support a /48 for end users. So it should be easy to reach
1000 devices. I assume most business ISPs can provide a /48. Maybe even PI.

Beyond that, you are probably big enough to document the need for a bigger block
if required.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Jul 2015 21:14:37 +0900

> If you use SLAAC your devices do not need to store 20 ND associations?

Your home CPE will likely have no problem at all storing 20 ND associations
per device.

> scales better than getting 20 addresses by other means...

Oh, I see. Well, of course there's a tradeoff. Something does have to keep
state. You can store that state in routing entries, ND cache entries, /64
prefixes, or NAT66 state tables. I would prefer not to store it in NAT66
state tables.

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Jul 2015 14:21:48 +0200

Hi,

> prefixes, or NAT66 state tables. I would prefer not to store it in NAT66

I think we're all in agreement regarding the NAT66 here.  I was just
wondering whether Andrew has fully thought through his suggestion and
the consequences - especially when talking about "this helps scaling"
and fixing that by moving the pressure elsewhere...

Gert Doering
        -- partly speaking with my address policy hat
-- 
have you enabled IPv6 on something today...?

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Jul 2015 14:22:30 +0200

Hi,

> Say you can have at least 100 prefixes per /56. Then that should be enough for

Andrew wasn't talking about *home* installations, because homes do not have
an issue with ND/CAM/... scaling.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Jul 2015 14:48:07 +0200

>an issue with ND/CAM/... scaling.

If you have more a 100 devices requesting DHCPv6-PD, then maybe it is time to
get a /48?

(no doubt in some markets, ISPs will make that as painful as possible).

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Jul 2015 14:50:04 +0200

Hi,

> If you have more a 100 devices requesting DHCPv6-PD, then maybe it is time to

For each single L2 network in a large enterprise?  Is that covered by RIR
policies?

Please do me the honour to actually *read* what I write.  This is not
about "home", because home does not have scaling issues of the sort Andrew
was talking about.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Jul 2015 15:44:34 +0200

>about "home", because home does not have scaling issues of the sort Andrew

I don't see the problem. You can get a /48 no questions asked. This is 
equivalent to a /16 for IPv4. You can easily reach 10000 devices without nat on
IPv4 out of a /16. Why would it be different for /64s out of a /48?

Of course, the more devices you want in a /48 the more careful you addressing
plan has to be. But certainly for large flat structures it should be easy to
achieve high density.

I don't know if RIR policies allow for one /64 per device from PI. If not, then
maybe somebody should submit a policy proposal.

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Tue, 28 Jul 2015 15:58:04 +0200

> need to provision at least a /54 per segment - which will increase your

I did not look at it as a problem given that every mobile phone on
IPv6 will already get a /64 per host, and the number of mobile phones
is dramatically bigger than the number of fixed installations.

But I pulled that assumption more or less out of my thumb, based on
observed anecdata, so would be happy to be proven wrong.

If we say we want to absolutely avoid NAT, then something has to give,
and I don't know which tradeoff is a better one, both can be argued
for and against. I think we might need both.

--a

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2015 10:27:22 -0400

Having read the document, it seems a bit pie in the sky.   The idea that subdividing a prefix will give users privacy is nonsensical: if it is well known that ISP X provides a /48 to every home, then people will assume that all hosts in any given /48 in that ISP’s allocation will belong to the same person or same household.

Given that, then if there is some performance reason for clustering multiple address assignments to the same host, the way to do it is to delegate a /120 to that host, and have a route to that /120 that points to that host.   If the host needs more than 256 addresses, delegate something bigger, or delegate multiple /120s.

This is really easy to do.   It doesn’t give you a ton of privacy, but I don’t think it gives you less privacy than delegating a /64, and in some sense it gives you more because now you can do multiple allocations and still get the efficiency of address clustering, and the snooper doesn’t have as much information about address allocation patterns.

And if you don’t want to do DHCPv6-PD, then SLAAC is actually ideal for this application, because you can in principle use a random number generator to produce the host part of the address, and just generate a bunch of random numbers with entropy so that a snooper can’t predict which addresses will be held in common by the same host.

But I still really don’t see the point of this.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Jul 2015 14:29:07 +0000

Hi,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Andrew ?? Yourtchenko
> Sent: Tuesday, July 28, 2015 6:58 AM
> To: Gert Doering
> Cc: IPv6 Operations
> Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt
> 

That is correct that /64 per host is what is being done for mobile phones.

Also, DHCPv6 PD has an advantage over SLAAC - there is no need for
DAD on the link over which the prefix is delegated, since the prefix is
not assigned to that link. And, the DHCPv6 server will ensure that
prefixes are uniquely assigned so that there is no duplication.

Thanks - Fred
[email-masked]

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Jul 2015 17:16:16 +0200

Hi,

> is dramatically bigger than the number of fixed installations.

Bigger than then number of L2 *segments*, undoubtly.

But no way bigger than "the number of devices that could attach to
a L2 link" - as all these mobile phone also has wifi, so you have way
more devices that attach to "shared links".

Network structure is also way different - in mobile, all devices attach
to some sort of aggregation router (via 3G PDP tunnels etc) - while
in "classic" networking, you have a multitude of independent segments
that do not normally have aggregation infrastructure or provisioning
available.  Prefix mobility in a typical enterprise networks (where
you'd have enough devices in a L2 segment to start think about scaling)
isn't really there.

> for and against. I think we might need both.

If you want my opinion, I think DHCPv6-PD to single hosts (= not something
that does tethering) is not a reasonable approach.

If something does tethering, you need to decide what you're talking about,
"enterprise-ish", "mobile" or "homenet".  In mobile, DHCPv6-PD, or just
sharing the PDP /64.  In homenet, HNCP or DHCPv6-PD.  In the enterprise?  
No idea what can be implemented with the typical constraints on 
trackability, security, etc.  (like: if the device attaches to *this* 
network, it's permitted to go *there* by IP ACLs - whether or not this 
is a reasonable approach in itself anymore stands to be debated, but it 
will be with us for a long time).

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Jul 2015 00:56:57 +0900

SLAAC might be ideal for this, but there are many (mostly enterprise /
university) network administrators who have stated they will never run
SLAAC.

One goal of this document is to ensure that even on networks don't run
SLAAC, then we as an industry don't end up with substantial deployments of
networks that provide too few addresses. That will over time pressure
devices to implement NAT66, and that would be suboptimal for everybody.

Privacy is only one of the many use cases in the draft. Another pretty
clear example is running VMs in your laptop. What are you going to do if
the network doesn't run SLAAC but provides you with exactly 1 IA_NA and you
want to run a VM? (Other than NAT66, I mean...)

On Tue, Jul 28, 2015 at 11:27 PM, Ted Lemon <[email-masked]> wrote:

> Having read the document, it seems a bit pie in the sky.   The idea that
> subdividing a prefix will give users privacy is nonsensical: if it is well
> known that ISP X provides a /48 to every home, then people will assume that
> all hosts in any given /48 in that ISP’s allocation will belong to the same
> person or same household.
>
> Given that, then if there is some performance reason for clustering
> multiple address assignments to the same host, the way to do it is to
> delegate a /120 to that host, and have a route to that /120 that points to
> that host.   If the host needs more than 256 addresses, delegate something
> bigger, or delegate multiple /120s.
>
> This is really easy to do.   It doesn’t give you a ton of privacy, but I
> don’t think it gives you less privacy than delegating a /64, and in some
> sense it gives you more because now you can do multiple allocations and
> still get the efficiency of address clustering, and the snooper doesn’t
> have as much information about address allocation patterns.
>
> And if you don’t want to do DHCPv6-PD, then SLAAC is actually ideal for
> this application, because you can in principle use a random number
> generator to produce the host part of the address, and just generate a
> bunch of random numbers with entropy so that a snooper can’t predict which
> addresses will be held in common by the same host.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Jul 2015 16:14:42 +0000

Hi,

> From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
> Sent: Tuesday, July 28, 2015 8:16 AM
> To: Andrew ???? Yourtchenko
> Cc: IPv6 Operations

In the enterprise, you can do AERO. Treat the enterprise as one gigantic
link. Use DHCPv6 PD to delegate prefixes to mobile enterprise nodes
on the link. Use IPv6 ND the same as on any other NBMA link. It scales
to as many nodes as can be covered by the enterprise's IPv6 prefix
allocations, and it uses route optimization to avoid tethering. It is a
scalable and incrementally deployable solution for IPv6 deployment
on enterprise mobile nodes. Give each one its own IPv6 prefix, and
let it connect up an Internet of Things as it sees fit.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2015 12:28:14 -0400

On Jul 28, 2015, at 11:56 AM, Lorenzo Colitti <[email-masked]> wrote:
> One goal of this document is to ensure that even on networks don't run SLAAC, then we as an industry don't end up with substantial deployments of networks that provide too few addresses. That will over time pressure devices to implement NAT66, and that would be suboptimal for everybody.
> 
> Privacy is only one of the many use cases in the draft. Another pretty clear example is running VMs in your laptop. What are you going to do if the network doesn't run SLAAC but provides you with exactly 1 IA_NA and you want to run a VM? (Other than NAT66, I mean...)

Okay, that helps put it in context.  I don’t think you should tout privacy as an advantage of this proposal, because I don’t think this proposal really helps with privacy, but I agree that it addresses the use case you’re describing.

I think getting vendors to implement this using PD might be challenging, but there are good reasons to do it that way.   However, I don’t think you need to delegate a /64.   Do you buy my theory about just using a /120 to aggregate a bunch of addresses, or no?   I realize of course that you’d also like it if we delegated /48s instead of /56s, and I don’t really disagree with that, but I think if you advance this proposal it’s going to be a hard sell to require the delegation of a /64 per host, and I don’t think it adds any value other than creating upstream pressure to delegate narrower prefixes.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Jul 2015 01:51:18 +0900

On Wed, Jul 29, 2015 at 1:28 AM, Ted Lemon <[email-masked]> wrote:

> Do you buy my theory about just using a /120 to aggregate a bunch of
> addresses, or no?
>

Well but if if you give a laptop or a device a /120, what is it going to
give its downstream devices / VMs when sharing its internet connection with
them? Does it have to implement a stateful DHCPv6 server and force its
downstream devices/VMs to use it? At that point, the network it offered
would be violating recommendations made in the draft.

A /64 is better because it allows connection sharing mechanisms such as ND
proxying and /64 share which also do not pose hard limits to the number of
addresses a downstream device may have.

A /64 also isn't that much space: the space implications for enterprise
networks are pretty much the same as what we do for IPv4 today (i.e., a
large enterprise that needs all of 10/8 gets 16M endpoints) - except that
the address space implications for the Internet are much better than IPv4
today because said large enterprise with 16M endpoints will only need a
/40, and there are quite a lot of those.

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Tue, 28 Jul 2015 19:02:56 +0200

> more devices that attach to "shared links".

I agree on the principle, though in reality it's even more complicated
since one device can attach to more than one link, etc. -  so I think
it's actually even worse.

> you'd have enough devices in a L2 segment to start think about scaling)

Agreed.

> that does tethering) is not a reasonable approach.

My line of logic was that DHCPv6-PD with a /128 prefix is not much
different from IA_NA.

>From there it is trivial to say "no, thou shalt not do /128, use
something shorter", and have the luxury to not define what is the
value of "shorter" is because it's just a prefix length, and we can
change per-situation.

Going from one IA_NA to 10 IA_NA to 30 IA_NA is much harder, so we
will be forced to freeze on the "right" value.

> will be with us for a long time).

I think you pointed the crux of the issue here: the enterprise network.

An enterprise does not want one uncontrolled device behind another
uncontrolled device, so realistically it will run IA_NA. And because
it will want the cheapest possible hardware to provide the function,
it will try to minimize the number of IA_NAs per host.

And unless the hosts will crash and burn if they can not get X IA_NAs
upfront (they won't), this number will go down to a number providing
the most important 90% of functionality.
The remaining 10% will have to adapt.

--a

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Jul 2015 17:17:18 +0000

Hi,

> Sent: Tuesday, July 28, 2015 10:03 AM
> To: Gert Doering
> Cc: IPv6 Operations

It is different, because unlike IA_NA a delegated prefix (even a /128) is not
to be assigned to the link on which the delegation was coordinated. Also,
the /128 is carried in the routing system, and may not match any on-link
prefixes at all.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2015 13:51:26 -0400

On Jul 28, 2015, at 12:51 PM, Lorenzo Colitti <[email-masked]> wrote:
> Well but if if you give a laptop or a device a /120, what is it going to give its downstream devices / VMs when sharing its internet connection with them? Does it have to implement a stateful DHCPv6 server and force its downstream devices/VMs to use it? At that point, the network it offered would be violating recommendations made in the draft.

So you want the device to be able to use DHCPv6-PD on the upstream, but support SLAAC on the downstream.   So this really isn’t a general mechanism: it’s for the smartphone router use case specifically.

> A /64 is better because it allows connection sharing mechanisms such as ND proxying and /64 share which also do not pose hard limits to the number of addresses a downstream device may have.

For the smartphone router case, I can see that.

> A /64 also isn't that much space: the space implications for enterprise networks are pretty much the same as what we do for IPv4 today (i.e., a large enterprise that needs all of 10/8 gets 16M endpoints) - except that the address space implications for the Internet are much better than IPv4 today because said large enterprise with 16M endpoints will only need a /40, and there are quite a lot of those.

There are 256 times as many /40s as IPv4 addresses.   That’s a _really_ small number unless you see the Internet growth curve flattening out, and your draft suggests that you don't.   The IPv6 address space looks big compared to IPv4, but it seems like everybody wants to pull bits out of it, and when you’re pulling out bits and not addresses, you can only pull out 128 of them before you’re done.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Jul 2015 19:58:36 +0200

>    There are 256 times as many /40s as IPv4 addresses.   Thats a
>    _really_ small number unless you see the Internet growth curve
>    flattening out, and your draft suggests that you don't.   The
>    IPv6 address space looks big compared to IPv4, but it seems like
>    everybody wants to pull bits out of it, and when youre pulling
>    out bits and not addresses, you can only pull out 128 of them
>    before youre done.

Assuming 256 ethernet devices per /40, you run out of MAC addresses first.

Assuming 32-bit ASNs, you need 256 /40s per ASN. And the routing table has
exploded before that.

Is is not like ISPs can just hand out /40s to everybody from their PA space.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2015 14:00:51 -0400

> Is is not like ISPs can just hand out /40s to everybody from their PA space.

Yes, this is what I’m saying.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Jul 2015 06:36:41 +1200

> would be violating recommendations made in the draft.

Not to mention encountering the problems with /120 mentioned
in RFC 7421, which include the problems of only having a /24 in
IPv4. We should be past that.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2015 14:48:24 -0400

> IPv4. We should be past that.

To be clear, I wasn’t proposing /120 prefixes, but the delegation of /120 prefixes as a way of delivering a chunk of contiguous addresses smaller than a /64, which I continue to think is impractical for Lorenzo’s use case.

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 Jul 2015 11:44:08 +1000

Hi Ted,

> But I still really don’t see the point of this.

I think to avoid recommendations like this IPv6 setup for containers,
e.g. specifying to use Neighbor Discovery Proxying and /80 prefix
lengths.

https://docs.docker.com/articles/networking/#ipv6

(As a side note, some discussion in the ID about whether containers
should be treated as hosts, and whether containers should then be
assigned /64s might be useful. I think an argument could be made that
containers are hosts, however given how light weight they are, and
therefore how many people might have, a /64 for each one might be
excessive.)

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Jul 2015 11:01:13 +0900

On Wed, Jul 29, 2015 at 2:51 AM, Ted Lemon <[email-masked]> wrote:

> So you want the device to be able to use DHCPv6-PD on the upstream, but
> support SLAAC on the downstream.   So this really isn’t a general
> mechanism: it’s for the smartphone router use case specifically.
>

Or for laptops that want to run VMs. Or for future protocols that need more
space, or for applications that want per-application IP-addresses. Or
anything else.

What this gives you is that on a network that has tracking requirements
that require the use of DHCPv6, then DHCPv6 can be used all the way to
"where the buck stops", i.e., all the way to the end user of the network.
The end user can then use other mechanisms, such as SLAAC or bridging, to
extend the network.

There are 256 times as many /40s as IPv4 addresses.   That’s a _really_
> small number unless you see the Internet growth curve flattening out, and
> your draft suggests that you don't.
>

The draft only recommends using DHCPv6 PD on if the network "requires
explicit requests for address space". That rules out anything running
SLAAC, which is supported by the vast majority of IPv6 deployments today.
If you want the draft to recommend that networks should not require
explicit requests for address space, then it can do that.

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 Jul 2015 12:07:21 +1000

> would be violating recommendations made in the draft.

For a laptop style scenario, i.e., numbers of VMs in likely low 1s or
no more than 10 to 15, I'd think bridging them onto the existing
ethernet network is easier because it is using existing and operating
SLAAC, DHCP etc. That has been my experience on the few occasions I've
run up a VM or two. It also has the advantage that it doesn't require
anything special from the upstream network that you might not be an
operator of.

I think that means there is a threshold, below which bridging is most
efficient, above which routing via a DHCPv6-PD delegated prefixes is
most efficient.

<snip>

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Jul 2015 11:36:12 +0900

On Wed, Jul 29, 2015 at 11:07 AM, Mark Smith <[email-masked]> wrote:

> SLAAC, DHCP etc.

It is easier, but it will not work on a network that only supports DHCPv6
and assigns only one IPv6 address per MAC address or per wifi association.

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 Jul 2015 13:11:41 +1000

> and assigns only one IPv6 address per MAC address or per wifi association.

So while not quite as easy to configure as bridging pure bridging,
Linux supports creating virtual ethernet interfaces ("macvlan"
interfaces) that have different MAC addresses, so you could use those
to get more than one address per host, but I get your point.

btw, Fred Baker wrote up a draft a while back which might be useful to
have a read of or reference. He pointed out that multi-homing doesn't
require multiple physical interfaces, so in that sense, what is being
described in this ID is making hosts multi-homed or "more
multi-homed".

"Happier Eyeballs"
https://tools.ietf.org/html/draft-baker-happier-eyeballs-00

Regards,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Jul 2015 00:54:50 -0400

On Jul 28, 2015, at 10:01 PM, Lorenzo Colitti <[email-masked]> wrote:
> Or for laptops that want to run VMs. Or for future protocols that need more space, or for applications that want per-application IP-addresses. Or anything else.

Laptop VMs will have DHCP clients, so there’s no reason not to use DHCP.   Only Android doesn’t have a DHCP client.

> What this gives you is that on a network that has tracking requirements that require the use of DHCPv6, then DHCPv6 can be used all the way to "where the buck stops", i.e., all the way to the end user of the network. The end user can then use other mechanisms, such as SLAAC or bridging, to extend the network.

Sure.   The mobile router use case.

> There are 256 times as many /40s as IPv4 addresses.   That’s a _really_ small number unless you see the Internet growth curve flattening out, and your draft suggests that you don't.
> 
> The draft only recommends using DHCPv6 PD on if the network "requires explicit requests for address space". That rules out anything running SLAAC, which is supported by the vast majority of IPv6 deployments today. If you want the draft to recommend that networks should not require explicit requests for address space, then it can do that.

I do not see how your response connects to what I said.   Either we can afford for every host to have a /64, or we can’t.   If we can’t, then we shouldn’t be delegating /64s to hosts.   Also, if sharing addresses from the same /64 on multiple links works in your SLAAC use case, it’s a bit of a stretch to claim that you need to do something drastically different in the DHCP use case.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Jul 2015 14:25:58 +0900

On Wed, Jul 29, 2015 at 1:54 PM, Ted Lemon <[email-masked]> wrote:

> Or for laptops that want to run VMs. Or for future protocols that need
> more space, or for applications that want per-application IP-addresses. Or
> anything else.
>

DHCPv6 is not the issue. The issue that we're recommending that networks
provide enough addresses *at connection time*. If we recommend that
networks should assign every device a /120 (256 addresses) *at connection
time*, then a device getting the /120 cannot respect the recommendations
with respect to any nodes behind it.

> I do not see how your response connects to what I said.   Either we can
> afford for every host to have a /64, or we can’t.   If we can’t, then we
> shouldn’t be delegating /64s to hosts.
>

Your argument does not take into account the reality that RIR policies are
different for different use cases. More specifically, it does not hold
water due to the fact that current practices allow assigning 4096 times as
much address space (/48) to a small/medium enterprise as ISPs often assign
to a small residential user (/60).

More in detail:

   1. Given current RIR policies, we can afford to assign a /48 to every
   enterprise network that needs to support up to
   64k general-purpose endpoints. We have plenty of /48s.
   2. Given current RIR policies, we afford to assign a /64 per device to
   every enterprise network that needs to support more than 64k
   general-purpose endpoints (there aren't that many of these, and we have
   plenty of /40s).
   3. Given current ISP assignments, we cannot afford to assign a /64 per
   device in a home network that only has a /60.

So the only problem here is #3 - home networks. But because home networks
use SLAAC, we don't need to assign a /64 to every host.

---

From: Tore Anderson <[email-masked]>
Date: Wed, 29 Jul 2015 07:44:50 +0200

* Ted Lemon

> To be clear, I wasn’t proposing /120 prefixes, but the delegation
> of /120 prefixes as a way of delivering a chunk of contiguous
> addresses smaller than a /64, which I continue to think is
> impractical for Lorenzo’s use case.

I was thinking something along the same lines, and not agreeing the
draft's statement that DHCPv6-PD cannot cater for «"unlimited"
endpoints». My view was that the problem could be solved, e.g., in this
way:

- Device 1 receives a delegated (<=) /64 from ISP/network (either 3GPP
  or DHCPv6-PD), which it then chops up in (for example) 2^16 /80s
  which may be handed out using DHCPv6-PD to downstream devices or
  local software functions (which would includes including its own
  loopback interface, local containers/VMs, etc.)
- Any downstream device that receives an /80 from the above device
  chops it up in 2^16 /96s which in the same way may be handed out to
  downstream devices or local software functions.
- Any downstream device that receives a /96 from a device at the above
  level can chop it up in 2^16 /112s and use it in the same way.

This would facilitate "unlimited" endpoints, assuming all the endpoints
support DHCPv6-PD. It would preclude the use of SLAAC, though, as any
link prefixes would be >/64. (However, the use of global link prefixes
would not really be necessary in the first place, as all links could be
link-local only).

Anyway, after having discussed this with Lorenzo at IETF93 I realised
that this is not covered because it is considered an invalid
configuration: RFC3633 section 12.1 says «for each IA_PD the requesting
router assigns a subnet from each of the delegated prefixes to each of
the links to which the associated interfaces are attached» and RFC7421
section 1 describes how «a subnet prefix longer than 64 bits is outside
the current IPv6 specifications». Thus, assigning DHCPv6-PD for prefixes
longer than /64 is seen as an invalid network configuration, and thus
not discussed in the draft as a potential solution.

While I am not completely convinced of the validity of that argument (in
particular, I am not entirely convinced that RFC3633 section 12.1
actually *prohibits* a requesting router from assigning a smaller
than /64 chunk of addresses out of a delegated prefix to its loopback
interface for use with local traffic), I suppose the position is fair
enough and I do not intend to argue this point further.

That said, given that the draft is targeted at operators, I think it
would benefit from unequivocally stating that the use of prefixes (both
delegated and link) with lengths >/64 are considered invalid and any
solution involving them is therefore not being discussed - because when
I read the draft while wearing my operator hat only, I see that as a
solution that would actually work just fine from a technical point of
view. RFC 7421 section 4.3.2 appears to confirm I am not alone in this,
stating «DHCPv6 is in widespread use without any dependency on the /64
boundary».

Tore

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Jul 2015 19:12:26 +1200

<snip>

> stating «DHCPv6 is in widespread use without any dependency on the /64

I think we should also note that once we start delegating long prefixes
out of a /64, the privacy properties of a "normal" IPv6 address are
blown away. In fact the draft probably needs a Privacy Considerations
section - presumably it's the /64 that would be of interest for
geolocation, the NSA, RIPA, etc.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Jul 2015 09:51:54 -0400

On Jul 29, 2015, at 1:25 AM, Lorenzo Colitti <[email-masked]> wrote:
> DHCPv6 is not the issue. The issue that we're recommending that networks provide enough addresses *at connection time*. If we recommend that networks should assign every device a /120 (256 addresses) *at connection time*, then a device getting the /120 cannot respect the recommendations with respect to any nodes behind it.

I don’t think we are talking about the same thing.   You are proposing that if we use SLAAC, the host initially gets however many addresses it acquires through SLAAC, typically 1 per prefix, but you propose that it might want, say, 20 or 30.   But if it uses DHCP, it gets a /64.   That’s 18 decimal orders of magnitude more addresses in the DHCP case.   Why the disparity?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Jul 2015 09:59:52 -0400

>  level can chop it up in 2^16 /112s and use it in the same way.

This implies that you are advertising prefixes wider than /64 on the downstream side of these devices.   That’s not what Lorenzo is talking about in his draft, and if that’s not clear to your reading of it, he should probably clarify.   Lorenzo may indeed think that I am proposing to do that, but I’m not.   I’m just proposing that if SLAAC only needs 30 addresses, and we want to allocate 30 addresses on the advertised prefix using DHCP, DHCP PD would be one way to deliver those addresses in such a way that they need only occupy a single slot in the forwarding table for the on-link router(s).   The hierarchical allocation model you are talking about really doesn’t make sense in this context: if some host several hops down the link is sharing the prefix, then it can just get its own /120 (or whatever) chunk of the prefix, rather than getting a chunk of the upstream host’s chunk.

But even going down this rabbit hole shows why this isn’t a great idea: whether you are using SLAAC or DHCP-PD, what you really have here is something akin to a homenet router, and if that’s the case, then you should just own it and not try to pretend that it’s just a host.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Jul 2015 20:16:51 +0200

In your letter dated Tue, 28 Jul 2015 14:00:51 -0400 you wrote:
>On Jul 28, 2015, at 1:58 PM, Philip Homburg <[email-masked]> >wrote:
>> Is is not like ISPs can just hand out /40s to everybody from their PA >space.
>

Looking a the RIPE region, you can easily get a /48 PI or an ISP can give
a /48 to its customers. This is enough for all but the largest organisations
to give every device /64.

RIPE members can easiliy get a /32 or even a bit shorter. That is even for
the largest organisations more than enough to give every device /64.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 Jul 2015 15:24:49 +0000

Hi Philip,

> From: v6ops [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Tuesday, July 28, 2015 11:17 AM
> To: IPv6 Operations
> >On Jul 28, 2015, at 1:58 PM, Philip Homburg <[email-masked]> =
> >wrote:
> >> Is is not like ISPs can just hand out /40s to everybody from their PA =
> >space.
> >
> >Yes, this is what I=E2=80=99m saying.
> 

I agree. We also need to remember that each device that gets a /64
can connect countless billions of other devices using the available
/64 prefix space.

> the largest organisations more than enough to give every device /64.

I agree that large organizations (like Boeing) can get more than enough
prefix space to satisfy their enterprise device numbering requirements.
A single /32 would yield 4B /32s and should satisfy all future scaling
requirements for the organization. Also, again, each device that
receives a /64 can connect countless billions of other devices.

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Thu, 30 Jul 2015 17:37:59 +0200

>can connect countless billions of other devices using the available

I'm not saying that we should give every device a /64 using DHCP-PD. SLAAC is
probably a much better way to distribute addresses locally (at least as long
as we don't mess up IIDs completely).

But, the addressing architecture does allow for one /64 per device. So when
needed, it is better to use that space than to add all kinds of complexity 
while trying to save a few bits.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 Jul 2015 15:49:15 +0000

Hi Philip,

> Sent: Thursday, July 30, 2015 8:38 AM
> To: [email-masked]

You can't give a device a /64 using SLAAC; SLAAC only allows for
autoconfiguration of singleton addresses taken from an on-link
/64 prefix. If you want to give a device a /64, the only choices
I am aware of are administrative configuration or DHCPv6 PD.

That said, once a device has received a /64, address delegation
from the /64 could certainly use SLAAC.

Thanks - Fred

---

From: Tore Anderson <[email-masked]>
Date: Thu, 30 Jul 2015 19:16:29 +0200

* Templin, Fred L

> /64 prefix.

Hi Fred,

Actually, SLAAC works equally well with off-link prefixes. There is no
inherent requirement in SLAAC that prefixes from which the addresses
are auto-configured must be on-link; the L and A bits in an RA's PIO
are completely orthogonal.

> If you want to give a device a /64, the only choices

True, although 3GPP networks is an exception. There a /64 prefix
advertised to the UE via standard RA/PIO with SLAAC can be treated as
if it was a delegated prefix. RFC7278 depends on this.

Tore

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 31 Jul 2015 11:24:01 +0200

Le 30/07/2015 17:49, Templin, Fred L a écrit :
> Hi Philip,
>
>> -----Original Message----- From: v6ops
>> [mailto:[email-masked]] On Behalf Of Philip Homburg Sent:
>> Thursday, July 30, 2015 8:38 AM To: [email-masked] Subject: Re:
>> [v6ops] I-D Action:
>> draft-colitti-v6ops-host-addr-availability-01.txt
>>
>>> I agree. We also need to remember that each device that gets a
>>> /64 can connect countless billions of other devices using the
>>> available /64 prefix space.
>>
>> I'm not saying that we should give every device a /64 using
>> DHCP-PD. SLAAC is probably a much better way to distribute
>> addresses locally (at least as long as we don't mess up IIDs
>> completely).
>
> You can't give a device a /64 using SLAAC;

I agree.

> SLAAC only allows for autoconfiguration of singleton addresses taken
>  from an on-link /64 prefix.

Yes.

> If you want to give a device a /64, the only choices I am aware of
> are administrative configuration or DHCPv6 PD.

I agree.  In addition there may be something with EAP, IKE and OSPF.

> That said, once a device has received a /64, address delegation from
>  the /64 could certainly use SLAAC.

I disagree.  If a device can't get a /64 by using SLAAC then it can't
give a /64 using SLAAC either.  Although yes, if a device gets a /64
with DHCP-PD then it can RA with that /64 on its other interface, only
for the other devices on that other interface.

Alex

>
> Thanks - Fred [email-masked]
>
>> But, the addressing architecture does allow for one /64 per device.
>> So when needed, it is better to use that space than to add all
>> kinds of complexity while trying to save a few bits.
>>
>>
>> _______________________________________________ v6ops mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 31 Jul 2015 15:09:52 +0200

Le 30/07/2015 19:16, Tore Anderson a écrit :
>> autoconfiguration of singleton addresses taken from an on-link /64
>> prefix.
>
> Hi Fred,
>
> Actually, SLAAC works equally well with off-link prefixes. There is
> no inherent requirement in SLAAC that prefixes from which the
> addresses are auto-configured must be on-link; the L and A bits in an
> RA's PIO are completely orthogonal.

I can agree.

> advertised to the UE via standard RA/PIO with SLAAC can be treated
> as if it was a delegated prefix.  RFC7278 depends on this.

IMHO it is wrong to treat it as a delegated prefix.  RFC7278 states
clearly that the right way to get a delegated prefix is DHCPv6-PD.

The treatment 'as if' is what makes operators think that one /64 in RA
is enough space for enough devices behind the UE.

A /64 on a cellular link can only accommodate one device.  Something may
make think that the /64 is a delegated prefix that _could_ accommodate
more than one device:
- the cellular link is a ptp link.  As such the first-hop router in the
   cellular network has a specific routing table entry containing the IP
   address of the UE as next-hop (instead of a '*' if it were a shared
   link) for that /64.  This makes that any address in that /64 is
   reachable through UE's IP address.

However, cellular links continue to advance away from being ptp links
and more be 'shared' links.  Recently 4G ptp links have got 48bit MAC
addresses.  In the future there will be true Neighbor Discovery on these
links, with '*' routes instead of next-hop routes.  At that point, the
assumption that a /64 can accommodate 2^64 devices will no longer hold,
because the first-hop router will issue NSs for the dst address, instead
of issuing RSs for the IP address of the UE.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 31 Jul 2015 17:56:08 +0000

Hi Alex,

> Although yes, if a device gets a /64

Yes, that is what I am saying.

Thanks - Fred

> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Friday, July 31, 2015 2:24 AM
> To: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 31 Jul 2015 18:34:53 +0000

Hi,

> Sent: Friday, July 31, 2015 6:10 AM
> To: [email-masked]

RFC4861 says:

      "L              1-bit on-link flag.  When set, indicates that this
                     prefix can be used for on-link determination.  When
                     not set the advertisement makes no statement about
                     on-link or off-link properties of the prefix.  In
                     other words, if the L flag is not set a host MUST
                     NOT conclude that an address derived from the
                     prefix is off-link.  That is, it MUST NOT update a
                     previous indication that the address is on-link."

Meaning that "L=0" conveys no useful on/off link information about
the IPv6 prefix in the PIO. The node receiving the PIO therefore has
no way of knowing whether the prefix is on/off link and much less
whether the prefix is being "delegated" to the node. At least that
is per standard IPv6ND.

> clearly that the right way to get a delegated prefix is DHCPv6-PD.

Agree.

> is enough space for enough devices behind the UE.

Prefix delegation for any length /64 or shorter should be possible, yes.

Thanks - Fred