Subject: [v6ops] WGLC: draft-ietf-v6ops-unique-ipv6-prefix-per-host-02

From: Ron Bonica <[email-masked]>
Date: Tue, 14 Mar 2017 14:40:58 +0000

Folks,

This message initiates a Working Group Last Call (WGLC) for draft-ietf-v6ops-unique-ipv6-prefix-per-host-02. Since IETF is approaching, we will let the last call run a little longer than usual.

Please submit comments to the list by April 11, 2017.

                                                                                            Lee, Fred and Ron

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Mar 2017 09:20:53 +0100

Hi,

Touchscreen and other WiFi, DSL and Cable Boxes of today rarely have
only one network interface.

As such, whereas it can make sense to dedicate an entire prefix to one
interface of such device (instead of sharing a prefix on the direct
link), the following also apply:
- should dedicate multiple such prefixes per device (not just one).
- in case only one such prefix is dedicated, it should not be /64 but a
   different prefix length.

This draft does neither.  It is called "unique prefix per Host"; and it
allocates a /64: "subscriber gets its own unique /64 IPv6 prefix".

If the text needs some example prefix len, please use /63 instead, not /64.

Maybe instead of "unique prefix per Host", would be better to say
"prefixes dedicated to a Host".

If the text needs to take a stance with respect to DHCPv6 PD, then
please make it a MUST.  The following is too ambiguos and delays PD
deployment: "if/when DHCPv6 prefix delegation support is desired".
Because it is not an if, and it is now.  This is really not good.

If this is not taken into account, I am afraid it will add to the pile
of RFCs mandating to allocate a /64 to an end host, use 64share, and
thus make it impossible to extend the network at the edge.

(once it agrees it should rather talk DHCPv6-PD.  Then we can discuss
again.)

(this draft could benefit from experience of earlier RFCs that also
dedicate a single prefix to an - albeit mobile - node - Proxy Mobile IP
RFC5213, Prefix Delegation for PMIP RFC 7248.)

Alex

Le 14/03/2017 à 15:40, Ron Bonica a écrit :
> Folks,
>
> This message initiates a Working Group Last Call (WGLC) for
> draft-ietf-v6ops-unique-ipv6-prefix-per-host-02. Since IETF is
> approaching, we will let the last call run a little longer than
> usual.
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 16 Mar 2017 09:26:39 +0100

Hi,

> only one network interface.
[..]
> This draft does neither.  It is called "unique prefix per Host"; 

All the devices you've listed are not *Hosts*.

This is not about "delegating a prefix to a device that works as an
intermediate router" but about *Hosts*.  If a host acts as a router,
it's not the target audience of this draft.

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: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Mar 2017 09:56:35 +0100

Le 16/03/2017 à 09:26, Gert Doering a écrit :
>> Touchscreen and other WiFi, DSL and Cable Boxes of today rarely
>> have only one network interface.
> [..]

Then let me claim that Hosts as we know them (computer with only one
interface) is a too theoretical term - we rarely find it in practice.

In this class of Hosts (computer with only one IP interface) one can
find a few Tablets or Game consoles.  Even then, they have USB
potentially with USBnet and thus IP on it.

Is this the audience of this draft (Tablet/Game console)?  I doubt so.

What happens in practice is that often drafts like this get widely
deployed and only then we realize they dont support more than, well,
Hosts with precisely 1 interface.

We should stay away from creating new such deployments.

There is a BCP requiring more than one address per device.

>  it's not the target audience of this draft.

I am afraid most Hosts out there act as Routers, and most Routers as
Hosts at times.

In both cases /64-unique-per-Computer makes no sense at all and should stop.

But yes, I agree that the concept of distinct prefixes per Computer
(rather than a shared prefix among multiple Computers) should be
pursued.  Just make it multiple.

Alex

>
> Gert Doering -- NetMaster
>

---

From: Tim Chown <[email-masked]>
Date: Thu, 16 Mar 2017 09:20:40 +0000

> On 16 Mar 2017, at 08:26, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

But the host might want to act as a router temporarily?

Tim

---

From: [email-masked]
Date: Thu, 16 Mar 2017 10:24:17 +0100

> But the host might want to act as a router temporarily?

A little flippant perhaps, but can you give an example of a node that isn't a router anymore?
I think the statement "All hosts are routers" is almost true.

Certainly my phones, laptops, lightbulbs are all routers.

Ole

---

From: joel jaeggli <[email-masked]>
Date: Thu, 16 Mar 2017 02:25:17 -0700

> But the host might want to act as a router temporarily?

then it should probably do PD, otherwise it gets precisely one /64
subnet which might be enough but why constrain youself in that way.

joel

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

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Mar 2017 10:31:51 +0100

> Certainly my phones, laptops, lightbulbs are all routers.

</hat>

I'd like to understand your meaning, if you don't mind.

A router, per RFC 2460, is a system that receives a message, does no processing on its content, but repeats it to another system. A host is one that receives messages and processes their application layer content.

I think it's fair to say that an iPhone etc has more than one interface; WiFi and LTE, perhaps. A laptop often has several interfaces such as physical and wireless Ethernet, USB, Bluetooth, and other things. Having multiple interfaces, however, does not qualify it as a router; what qualifies it as a router is when it receives a message and repeats it, usually on another interface.

Yes, an iPhone acting as a hot spot can route between its WiFi and LTE ports. If it is not configured as a hot spot, however, it generally uses its many interfaces as ways to receive messages, pass them to applications, and respond to them. Absent a specific (and unusual) configuration, an iPhone therefore is a host, not a router.

Are you and I using the words in the same way? I get the feeling that you see multiple interfaces and infer "router".

---

From: [email-masked]
Date: Thu, 16 Mar 2017 10:45:31 +0100

Fred,

> A router, per RFC 2460, is a system that receives a message, does no processing on its content, but repeats it to another system. A host is one that receives messages and processes their applicatio…

2460: router      - a node that forwards IPv6 packets not explicitly addressed to itself.

> I think it's fair to say that an iPhone etc has more than one interface; WiFi and LTE, perhaps. A laptop often has several interfaces such as physical and wireless Ethernet, USB, Bluetooth, and oth…

Phones act as routers when they do tethering.
My laptop acts as a router when the hypervisor running on bare metal routes traffic between the physical NICs and a set of VMs and containers.

> Yes, an iPhone acting as a hot spot can route between its WiFi and LTE ports. If it is not configured as a hot spot, however, it generally uses its many interfaces as ways to receive messages, pass…

Correct, and switching between the two requires a single swipe with suitable finger.
And my lightbulbs, builds up a mesh and forward packets for each other. Aka router.

> Are you and I using the words in the same way? I get the feeling that you see multiple interfaces and infer "router".

No.
Sure, many nodes can be configured to act either as hosts or routers. In IPv4 the typical case is that it pretends to be a host northbound  to the network. Unfortunately that's how it is likely to pan out in IPv6 too...

Cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Thu, 16 Mar 2017 10:56:20 +0100

Hi,

> I think the statement "All hosts are routers" is almost true.

only if ipv6_forwarding = 1

and yes, it can be easily changed, but this is a very relevant change.

Gert Doering
        -- NetMaster

---

From: Tim Chown <[email-masked]>
Date: Thu, 16 Mar 2017 12:01:55 +0000

Hi,

> On 16 Mar 2017, at 09:45, [email-masked] wrote:
> 
> Fred,
> 

Indeed, there are many examples.

> And my lightbulbs, builds up a mesh and forward packets for each other. Aka router.

And the good news is that it’s all pretty transparent to the user, who just enables/disables services.

> Sure, many nodes can be configured to act either as hosts or routers. In IPv4 the typical case is that it pretends to be a host northbound  to the network. Unfortunately that's how it is likely to pan out in IPv6 too…

So that’s a key observation - what can we do to influence that future?  I’d hope RFC 7934, and this draft, would help do so...

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Mar 2017 03:54:40 +1300

> Are you and I using the words in the same way? I get the feeling that you see multiple interfaces and infer "router".

As others have implied, multiple interfaces means *potential* router, and that's the point,
isn't it: if you give a *potential* router only a /64, it can support a single subnet
but it can't support multiple subnets and subsidiary routers. And Alexandre is challenging
that limitation. But we have said elsewhere that ISPs should provide more than a /64
per subscriber; it seems like a different discussion. 

     Brian

---

From: [email-masked]
Date: Thu, 16 Mar 2017 16:03:05 +0100

> per subscriber; it seems like a different discussion.

Take the simple case of a laptop with VMs.
It has to handle the smallest common denominator. As long as networks treat everything that connects to it as hosts.
Then either the host with VMs (aka router) has to pretend to be a host and do one of bridging or NAT. Or with this proposal it can subnet the /64.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Mar 2017 16:21:38 +0100

Le 16/03/2017 à 16:03, [email-masked] a écrit :
>>> A router, per RFC 2460, is a system that receives a message, does
>>> no processing on its content, but repeats it to another system. A
>>> host is one that receives messages and processes their
>>> application layer content.
>>>
>>> I think it's fair to say that an iPhone etc has more than one
>>> interface; WiFi and LTE, perhaps. A laptop often has several
>>> interfaces such as physical and wireless Ethernet, USB,
>>> Bluetooth, and other things. Having multiple interfaces, however,
>>> does not qualify it as a router; what qualifies it as a router is
>>> when it receives a message and repeats it, usually on another
>>> interface.
>>>
>>> Yes, an iPhone acting as a hot spot can route between its WiFi
>>> and LTE ports. If it is not configured as a hot spot, however, it
>>> generally uses its many interfaces as ways to receive messages,
>>> pass them to applications, and respond to them. Absent a specific
>>> (and unusual) configuration, an iPhone therefore is a host, not a
>>> router.
>>>
>>> Are you and I using the words in the same way? I get the feeling
>>> that you see multiple interfaces and infer "router".
>>
>> As others have implied, multiple interfaces means *potential*
>> router, and that's the point, isn't it: if you give a *potential*
>> router only a /64, it can support a single subnet but it can't
>> support multiple subnets and subsidiary routers. And Alexandre is
>> challenging that limitation. But we have said elsewhere that ISPs
>> should provide more than a /64 per subscriber; it seems like a
>> different discussion.
>
> Take the simple case of a laptop with VMs. It has to handle the
> smallest common denominator. As long as networks treat everything
> that connects to it as hosts. Then either the host with VMs (aka
> router) has to pretend to be a host and do one of bridging or NAT. Or
> with this proposal it can subnet the /64.

I am not sure I understand, but it is hard to subnet a /64 further to 
interfaces that want their IIDs to be 64.  Or you want these interfaces 
to not run SLAAC?  Do you have other means to automatically configure 
their addresses?

Alex

> Cheers, Ole

---

From: [email-masked]
Date: Thu, 16 Mar 2017 16:27:25 +0100

> I am not sure I understand, but it is hard to subnet a /64 further to interfaces that want their IIDs to be 64.  Or you want these interfaces to not run SLAAC?  Do you have other means to automatically configure their addresses?

I just enumerated the choices an operator / implementor have in this case.

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Mar 2017 06:31:43 +1300

> I just enumerated the choices an operator / implementor have in this case.

Yes, but only if /64 is no longer sacred. It's going to be tricky if some
of the nodes on the /66 subnets assume SLAAC at /64.

So, it seems clear to me that while getting a /64 is better than getting
a /128, it's even better to get a /56. Or even one of those 15 trillion /48s.
We should make it clear that /64 is not even second-best. Just better
than /128.

   Brian

---

From: [email-masked]
Date: Thu, 16 Mar 2017 18:38:32 +0100

Brian,

> We should make it clear that /64 is not even second-best. Just better

Indeed. I just don't think that's realistic to expect.
The implementation has to accommodate the smallest common denominator. At at the local coffee shop or at your favourite Enterprise you would be very lucky if you got more than a /64 assigned to the host. Enterprises often don't like you to extend their network, nor do the coffee shop want to run multiple provisioning protocols.

Cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Thu, 16 Mar 2017 12:02:03 -0700

> subnet which might be enough but why constrain youself in that way.

We’re not going to refuse to forward packets just because we can’t get a prefix delegated from a customer edge router that supports hosts but won’t delegate prefixes to them. To cope with that scenario, we’re going to do one of two things: either NAT66 (address+port amplification) or ND proxy for /64 sharing. And once we do either one of those, we pretty much don’t need DHCP prefix delegation.

"Choose the form of the destructor!” [1]

--james woodyatt <[email-masked]>

[1] <https://www.youtube.com/watch?v=dNAQ9lbe3kw>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 16 Mar 2017 19:52:41 +0000

Comment below:

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Thursday, March 16, 2017 10:32 AM
> To: [email-masked]; Alexandre Petrescu <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-unique-ipv6-prefix-per-host-02 - multiple prefixes per device
> 
> >> I am not sure I understand, but it is hard to subnet a /64 further to interfaces that want their IIDs to be 64.  Or you want these
> interfaces to not run SLAAC?  Do you have other means to automatically configure their addresses?
> >

FWIW, ICAO expects that airplanes that use IPv6 will get a /56 (or shorter).

Thanks - Fred

---

From: Gert Doering <[email-masked]>
Date: Thu, 16 Mar 2017 21:14:13 +0100

Hi,

> We should make it clear that /64 is not even second-best. Just better

"give any *host* that connects a /48" (and dimension pools on WiFi
hotspots etc. big enough to actually be able to do this) might actually 
be a good way to ensure IPv6 is going to run out faster than expected...

IOW, be careful with the maths here.

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Mar 2017 11:43:47 +1300

> IOW, be careful with the maths here.

Yes, one always needs cautious allocation policies. But still... /64
is not enough in the general case, with today's link-layer media
and today's IPv6 stacks. (We can have the argument about tomorrow
some other time. :-)

   Brian

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Mar 2017 10:26:33 +1100

In message <[email-masked]>, Brian E Carpenter 
> and today's IPv6 stacks. (We can have the argument about tomorrow

And PD allows for a node to do multiple PD requests.  Each router
doesn't need a pool of prefixes to answer PD requests from.  It can
do a upstream request to full fill the downstream request on demand.

A coffee shop is a site or part of a site.  That site should have
a /48 with 65536 /64 subnets to further allocate.  Hosts draw from
that pool.  Yes, that does mean that there are lots of intra site
routing entries for /64's rather than for shorter prefix lengths.
That however shouldn't matter because it is not a excessive number
for even the most inexpensive router to handle and they are summaried
as a /48 in the global routing table.  Even with a few of /48 pools
from different ISPs it still isn't excessive.

When a iPhone requests a PD over its cellular interface it is acting
as a border router.  When it requests a PD over its WiFi interface
(because some app wants lots of addresses or to connect the BT to
the WiFi) it is acting as a interior router.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Mar 2017 22:17:00 -0700

> On Mar 16, 2017, at 2:45 AM, [email-masked] wrote:
> 

Sometimes as an L2 switch. The key is whether the interfaces are on different subnets, and a test is whether their hip counts decrement. If so, it's acting as a router for that traffic.  

Joe

---

From: Gert Doering <[email-masked]>
Date: Fri, 17 Mar 2017 11:13:06 +0100

Hi,

> do a upstream request to full fill the downstream request on demand.

Technically, it could.  Administratively, I'm going to believe that
when I see it - like, in a big enterprise network, individual /64s
being routed randomly across the place because a wifi hotspot needed
another prefix to hand out.

> from different ISPs it still isn't excessive.

A coffee shop has a /48 today (or a /56, given that the RIR policies
where changed based on extrapolations that a /48 for each SoHo customer
connection might not be sustainable).

If we suggest that hosts should "get a /48", and there a a number of 
customers in that coffee shop, then a /48-per-site is not going to
be enough.

But seriously: how many visitors of said coffee shop would need
more than a /64?  Yes, I've heard about the laptop with the VMs running,
in multiple hierarchical virtual networks, and such.  How many of those
laptops exist?  100, 1000?  This is totally niche.  

Normal users want their browsing, e-mail and corporate VPN to work.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Fri, 17 Mar 2017 11:44:52 +0100

>The implementation has to accommodate the smallest common denominator. =
>At at the local coffee shop or at your favourite Enterprise you would be =
>very lucky if you got more than a /64 assigned to the host. Enterprises =
>often don't like you to extend their network, nor do the coffee shop =
>want to run multiple provisioning protocols.

Assuming that homenet takes of, then we can assume the local coffee shop
to be a homenet.

Small companies probably just a get consumer internet connection, set up 
a consumer CPE and that's it.

So if we make sure that what we want works in a homenet environment, then it is
likely going to work in losts of other contexts as well.

For the enterprise, some organisations seems to be set on making sure that
nobody can do any useful work. Obviously, it will be hard to make standard
for that type of environment.

Assuming the enterprise wants to support a 'desk area network' then
one way forward is to recognize each desk network as a separate homenet.
That's relatively easy to spec.

On other hand, I can see a desire to have the enterprise network
infrastructure be in control, with end user devices providing local
connectivity. In that case probably all devices with routing functionality
would have to be DHCP relay agents (or something similar) to allow central
infrastructure to see what is going on.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Mar 2017 12:50:55 +0100

Le 16/03/2017 à 18:38, [email-masked] a écrit :
[...]
> At at the local coffee shop or at your favourite Enterprise you would
> be very lucky if you got more than a /64 assigned to the host.

Why?

> Enterprises often don't like you to extend their network, nor do the
> coffee shop want to run multiple provisioning protocols.

Why dont they want to run multiple provisioning protocols?

Does the hotel like to ask each time a customer how many Devices the 
customer has?  Isnt that too heavy to manage?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Mar 2017 13:05:35 +0100

Le 17/03/2017 à 11:13, Gert Doering a écrit :
>>> Yes, one always needs cautious allocation policies. But still...
>>> /64 is not enough in the general case, with today's link-layer
>>> media and today's IPv6 stacks. (We can have the argument about
>>> tomorrow some other time. :-)
>>
>>  for even the most inexpensive router to handle and they are
>> summaried as a /48 in the global routing table.  Even with a few
>> of /48 pools from different ISPs it still isn't excessive.
>
>  where changed based on extrapolations that a /48 for each SoHo
> customer connection might not be sustainable).
>
> customers in that coffee shop, then a /48-per-site is not going to be
> enough.
>
> But seriously: how many visitors of said coffee shop would need more
> than a /64?

Many visitors use smartphone-smartwatch combinations.

> Yes, I've heard about the laptop with the VMs running,

Smartphones run VMs too, not only laptops.

> in multiple hierarchical virtual networks, and such.  How many of
> those laptops exist?  100, 1000?  This is totally niche.

Even for a 100-sized niche, one needs to plan for 100 times multiple /64 
prefixes per unit.

Even for a 100-sized niche, one can't plan to use a single /64 per unit.

> Normal users want their browsing, e-mail and corporate VPN to work.

New ways dont do any browsing, email or corporate VPN.  They do 
purpose-specific messaging and project management apps.  Often they 
neeed simultaneity between multiple independent such apps - easier with VMs.

Alex

---

From: Gert Doering <[email-masked]>
Date: Fri, 17 Mar 2017 14:06:31 +0100

Hi,

> Many visitors use smartphone-smartwatch combinations.

Those do not need multiple *networks*.

> Smartphones run VMs too, not only laptops.

Really?  So these need multiple *networks* to number the VMs?

> Even for a 100-sized niche, one can't plan to use a single /64 per unit.

"100 world wide", and we should not engineer for those.  They will find
ways to make their stuff work, grumbling about stupid protocols and
everything.

> neeed simultaneity between multiple independent such apps - easier with VMs.

All that is "talk to internet from clients", and a whole /64 per device
would be extremely plenty for that.

You need more than a /64 if you have routed topologies, which you just
do not *have* inside your smartwatch.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Mar 2017 15:15:42 +0100

Le 17/03/2017 à 14:06, Gert Doering a écrit :
>>> more than a /64?

A smatphone-smartwatch combination needs one more subnet than the /64
dedicated to the smartphone by the cellular link.

> Really?  So these need multiple *networks* to number the VMs?

It depends on the number of VMs.  They are very easy to create, so
potentially numerous.

>>> in multiple hierarchical virtual networks, and such.  How many
>>> of those laptops exist?  100, 1000?  This is totally niche.
>>
>> Even for a 100-sized niche, one needs to plan for 100 times
>> multiple /64 prefixes per unit.
>>
> "100 world wide", and we should not engineer for those.  They will
> find ways to make their stuff work, grumbling about stupid protocols
> and everything.

The difference is whether they want something to survive the next
development cycle, be used elsewhere, etc.

> All that is "talk to internet from clients", and a whole /64 per
> device would be extremely plenty for that.

This "talk to internet from clients" exclusive perspective makes remote
software update and other low-latency "ring" notifications impossible,
or simply too CPU-consuming.

> You need more than a /64 if you have routed topologies, which you
> just do not *have* inside your smartwatch.

I didnt mean inside the smartwatch.

I meant the smartphone does route, and the smartphone-smartwatch forms a
subnet that needs a /64 for itself (in addition to the /64 presumably
allocated to the smartphone).

Alex

---

From: Gert Doering <[email-masked]>
Date: Fri, 17 Mar 2017 15:16:30 +0100

Hi,

> dedicated to the smartphone by the cellular link.

no.

Gert Doering
        -- NetMaster

---

From: Fernando Gont <[email-masked]>
Date: Fri, 17 Mar 2017 17:52:44 -0300

> and today's IPv6 stacks. (We can have the argument about tomorrow

Well... /64 is not enough because somehow we choose to waste a large
part of 128-64. IN principle if one were to use 48 bits for the iid (or
even 56) that would still be big enough for randomizing IID, while still
having 16 or 8 bits for "subnetting"...

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Andrews <[email-masked]>
Date: Mon, 20 Mar 2017 11:29:55 +1100

> another prefix to hand out.

Why not?  It's not like it actually is hard to do this.  What I am
seeing here is IPv4 think being applied to IPv6 features.  Handing
out prefixes is a completely different problem to handing out
individual addresses.  There is zero need to break down the prefix
pool into regions like you had to break down the IPv4 address space
into subnets.

> customers in that coffee shop, then a /48-per-site is not going to

A site may have a single host, but hosts, in general, aren't sites.
And who is suggesting that hosts get a /48 for this?  I'm not.

> laptops exist?  100, 1000?  This is totally niche.

Today, not many.  Tomorrow who knows.  We do however have a
provisioning protocol that will work.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Mar 2017 18:28:23 +0900

> of the nodes on the /66 subnets assume SLAAC at /64.

If /64 is no longer fixed then we'll end up with /128 + NAT66 like we
do in IPv4.

> We should make it clear that /64 is not even second-best. Just better

Given that this is an operational draft, then I would suggest an
applicability statement: state that DHCPv6 PD is better, but also state
that best *current* practice is to provide a /64 via RA, because currently
very few hosts have DHCPv6 PD clients and providing PD on the network side
is not going to help the vast majority of clients.

Using shared links on public deployments with untrusted hosts has all sorts
of security and scalability issues (ND spoofing, DAD spoofing, ND cache
exhaustion attacks, etc.) /64 to the host is just a much better solution.

---

From: Ross Chandler <[email-masked]>
Date: Mon, 20 Mar 2017 11:46:22 +0000

> On 20 Mar 2017, at 09:28, Lorenzo Colitti <[email-masked]> wrote:
> 
> Given that this is an operational draft, then I would suggest an applicability statement: state that DHCPv6 PD is better, but also state that best *current* practice is to provide a /64 via RA, because currently very few hosts have DHCPv6 PD clients and providing PD on the network side is not going to help the vast majority of clients.
> 
> Using shared links on public deployments with untrusted hosts has all sorts of security and scalability issues (ND spoofing, DAD spoofing, ND cache exhaustion attacks, etc.) /64 to the host is just a much better solution.

It might also be worth noting in the draft how 3GPP TS.23401 5.3.1.2.6  says prefix shorter than /64 assignment to UEs should work. 

"Optionally a single network prefix shorter than the default /64 prefix may be assigned to a PDN connection. In this case, the /64 default prefix used for IPv6 stateless autoconfiguration will be allocated from this network prefix; the remaining address space from the network prefix can be delegated to the PDN connection using prefix delegation after the default bearer establishment and IPv6 prefix allocation via IPv6 stateless address autoconfiguration as defined in clause 5.3.1.2.2.”

“The UE uses DHCPv6 to request additional IPv6 prefixes (i.e. prefixes in addition to the default prefix) from the PDN GW after completing stateless IPv6 address autoconfiguration procedures.”

Having a single contiguous prefix is allowed for by specifying the minor extra detail of prefix length in CDRs.

Ross

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Mar 2017 14:01:01 +0100

Le 20/03/2017 à 12:46, Ross Chandler a écrit :
>> applicability statement: state that DHCPv6 PD is better, but also
>> state that best *current* practice is to provide a /64 via RA,
>> because currently very few hosts have DHCPv6 PD clients and
>> providing PD on the network side is not going to help the vast
>> majority of clients.
>>
>> Using shared links on public deployments with untrusted hosts has
>> all sorts of security and scalability issues (ND spoofing, DAD
>> spoofing, ND cache exhaustion attacks, etc.) /64 to the host is
>> just a much better solution.
>
>
>
> It might also be worth noting in the draft how 3GPP TS.23401
> 5.3.1.2.6  says prefix shorter than /64 assignment to UEs should
> work.

A-ha!

> "Optionally a single network prefix shorter than the default /64
> prefix may be assigned to a PDN connection. In this case, the /64
> default prefix used for IPv6 stateless autoconfiguration will be
> allocated from this network prefix; the remaining address space from
>  the network prefix can be delegated to the PDN connection using
> prefix delegation after the default bearer establishment and IPv6
> prefix allocation via IPv6 stateless address autoconfiguration as
> defined in clause 5.3.1.2.2.”
>
> “The UE uses DHCPv6 to request additional IPv6 prefixes (i.e.
> prefixes in addition to the default prefix) from the PDN GW after
> completing stateless IPv6 address autoconfiguration procedures.”

This seems to indicate that the PDN GW plays both a role of
DHCPv6-PD Requesting Router aka DHCPv6 Client (when it gets "assigned" a
shorter-than-64 prefix) _and_ the role of
DHCPv6-PD Delegating Router aka DHCPv6 Server (when it delegates
additional IPv6 prefixes to the UE).

This is a little bit awkward for setting up routing.

It would be simpler if the PDN GW were a DHCPv6 Relay.

Has it been considered to make the PDN GW a DHCPv6 Relay?

> Having a single contiguous prefix is allowed for by specifying the
> minor extra detail of prefix length in CDRs.

It makes sense to have a single contiguous prefix, in some cases.

It could also make sense to set an entire /47 to that PDN GW, and run a
DHCPv6 Server on PDN GWs and nowhere else.

It comes down to these two non-awkward options: either set a DHCPv6
Server in each PDN GW, or a single DHCPv6 Server deeper in the core
accompanied by many DHCPv6 Relays in each PDN GW.

Alex

---

From: Ross Chandler <[email-masked]>
Date: Mon, 20 Mar 2017 18:26:26 +0000

> On 20 Mar 2017, at 13:01, Alexandre Petrescu <[email-masked]> wrote:
> 

In the case of /64 per host, the implementation I’ve seen supplies the prefix needed by SLAAC by having the GW address assignment function generate a DHCPv6 PD request which the GW relays either to an internal DHCPv6 server  or to a central server. That is in a TWAG supplied by one of the draft’s authors. It seems to be done in a way ripe for extension to support UE DHCPv6-PD requests after the initial SLAAC /64 is assigned.

Ross

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 21 Mar 2017 10:52:49 +0100

Le 20/03/2017 à 19:26, Ross Chandler a écrit :
>>>  prefix may be assigned to a PDN connection. In this case, the
>>> /64 default prefix used for IPv6 stateless autoconfiguration
>>> will be allocated from this network prefix; the remaining
>>> address space from the network prefix can be delegated to the
>>> PDN connection using prefix delegation after the default bearer
>>> establishment and IPv6 prefix allocation via IPv6 stateless
>>> address autoconfiguration as defined in clause 5.3.1.2.2.”
>>>
>> DHCPv6-PD Requesting Router aka DHCPv6 Client (when it gets
>> "assigned" a shorter-than-64 prefix) _and_ the role of DHCPv6-PD
>> Delegating Router aka DHCPv6 Server (when it delegates additional
>> IPv6 prefixes to the UE).
>>
> In the case of /64 per host, the implementation I’ve seen supplies
> the prefix needed by SLAAC by having the GW address assignment
> function generate a DHCPv6 PD request which the GW relays either to
> an internal DHCPv6 server  or to a central server. That is in a TWAG
> supplied by one of the draft’s authors. It seems to be done in a way
> ripe for extension to support UE DHCPv6-PD requests after the
> initial SLAAC /64 is assigned.

Sounds promising.

We wrote a python DHCPv6 client called "PD tester" that issues DHCPv6 PD
requests to cellular networks.  We tested it on a one cellular network
and no answer until now.

We would like to test it on other cellular networks.

Is the TWAG applied in some cellular network?

Alex

---

From: Ross Chandler <[email-masked]>
Date: Tue, 21 Mar 2017 11:55:20 +0000

> On 21 Mar 2017, at 09:52, Alexandre Petrescu <[email-masked]> wrote:

> Is the TWAG applied in some cellular network?

There’s no cellular access but it is very similar. All the clients are using their WiFi interfaces, their access is tunnelled to the GW where each client gets its own unique /64 by SLAAC.
If the gateway and UE could do DHCPv6-PD over both WiFi & 3GPP interfaces as described in TS.23401 then shorter than /64 prefixes could be assigned in a common manner.

Here is a further quote from TS.23401 clause 5.3.1.2.6 on how the DHCPv6 should operate 

"The total IPv6 address space available for the PDN connection (UE default bearer prefix and UE PDN connection IPv6 address space pool) shall be possible to aggregate into one IPv6 prefix that will represent all IPv6 addresses that the UE may use. If the UE had indicated that it supports prefix exclusion and the prefix to be delegated to the UE includes the /64 prefix that was allocated to the PDN Connection, the PDN GW shall utilise the prefix exclusion feature as specified for DHCPv6 Prefix Delegation in IETF RFC 6603 [70].

The UE uses DHCPv6 to request additional IPv6 prefixes (i.e. prefixes in addition to the default prefix) from the PDN GW after completing stateless IPv6 address autoconfiguration procedures. The UE acts as a "Requesting Router" as described in RFC 3633 [21] and inserts one or more IA_PD option(s) into a DHCPv6 Solicit message sent from the UE to the PDN GW. The PDN GW acts as the DHCP server and fulfils the role of a "Delegating Router" according to RFC 3633 [21]. The UE optionally includes the RAPID_COMMIT option in the DHCPv6 Solicit message to trigger two-message DHCPv6 procedure instead of the four-message DHCPv6 procedure. The UE shall include OPTION_PD_EXCLUDE option code in an OPTION_ORO option to indicate support for prefix exclusion. In response to the DHCPv6 Solicit message, the UE receives a DHCPv6 Reply message with one or more IA_PD prefix(es) for every IA_PD option that it sent in the DHCPv6 Solicit message. The PDN GW delegates a prefix excluding the default prefix with help of OPTION_PD_EXCLUDE. Prefix exclusion procedures shall follow IETF RFC 6603 [70].”

Ross

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 21 Mar 2017 15:59:10 +0000

We have been using DHCPv6 PD client for a long time and have released a proof of
concept implementation:

http://linkupnetworks.org/aero/aero-3.0.2.tgz

We also have an internal-only implementation that runs on Android. We have been
using it for over a year to work with enterprise mobile devices. This not is not a sales
pitch for our code, but rather a proof that the DHCPv6 PD client function is very
lightweight and easy to implement. I will make a plug for KEA, however - it is a
great DHCPv6 server system, open source and standards-compliant:

http://kea.isc.org/wiki

Thanks - Fred
[email-masked]

> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Tuesday, March 21, 2017 2:53 AM
> To: Ross Chandler <[email-masked]>
> Cc: [email-masked]