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

From: Edwin Cordeiro <[email-masked]>
Date: Mon, 23 May 2016 12:24:52 -0300

Hello all,

Below is the first review from the Internet Draft Review Team that I'm
mentoring.

Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-00

Reviewers: Ricardo Pelaez-Negro, Edwin Cordeiro

Review Date: May 23th 2016

Summary: It is a good suggestion for a BCP, but it needs to add DHCP-PD to
it

Comments: The draft proposes the use of an unique /64 for each user
equipment connected to a WLAN gateway. The proposal highlights the benefit
of such approach but fails to analyse possible consequences. I would
support this draft to move forward if these issues are addressed.

Major Issues:
- The DHCPv6-PD is mentioned for the first time only in section 4.3.1 and
later at the "Future Work" session. From my understanding DHCPv6-PD is
capable of implementing the network as desired in this BCP. Considering the
intended status is BCP, I think that DCHPv6-PD should be added as valid
implementation alternative.
- The draft doesn't mention possible issues of giving one /64 for each UE,
for example, a public WIFI with support for 512 users will need a /55
instead of a single /64.

Minor Issues and Nits:
The document has some Nits problems as detailed in:
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt

Questions:
- Should this document address the best way to logging the prefix assign to
the UE/subscriber?
- Assigning the same unique prefix if the UE/subscriber reconnect to the
same AP, is something that should be considered or avoided?

Best regards,

Edwin Cordeiro

---

From: Ross Chandler <[email-masked]>
Date: Mon, 23 May 2016 17:40:11 +0100

> On 23 May 2016, at 16:24, Edwin Cordeiro <[email-masked]> wrote:
> 
> Major Issues: 
> - The DHCPv6-PD is mentioned for the first time only in section 4.3.1 and later at the "Future Work" session. From my understanding DHCPv6-PD is capable of implementing the network as desired in this BCP. Considering the intended status is BCP, I think that DCHPv6-PD should be added as valid implementation alternative.
> - The draft doesn’t mention possible issues of giving one /64 for each UE, for example, a public WIFI with support for 512 users will need a /55 instead of a single /64.

Edwin,

Some comments on those comments as we’re planning on deploying WLAN-GWs that give out /64 per UE.

/55 is probably unnecessarily parimonious and it isn’t on a nibble boundary to make the address plan easy to understand. 
I’d suggest a minimum of /48 for a pool giving out /64s. A larger pool size will help avoid bringing the IPv4 pool exhaustion problem seen in BNGs into an average WLAN-GW.
 
Regards
Ross

> 
> Minor Issues and Nits: 
> The document has some Nits problems as detailed in: https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt <https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00.txt>
> 
> Questions:
> - Should this document address the best way to logging the prefix assign to the UE/subscriber?
> - Assigning the same unique prefix if the UE/subscriber reconnect to the same AP, is something that should be considered or avoided?
> 
> Best regards,
> 
> Edwin Cordeiro
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Edwin Cordeiro <[email-masked]>
Date: Mon, 23 May 2016 14:34:49 -0300

Our comment was that using a unique /64 per UE would considerably increase
the amount of wasted addresses. It could be a problem in some deployments,
but the document doesn't address this potential issue.

I agree that using /48 makes planning easier, but this is also the standard
size of an enterprise allocation, so a company with this standard
allocation might have problems in following this recommendation.

Edwin Cordeiro

On Mon, May 23, 2016 at 1:40 PM, Ross Chandler <[email-masked]> wrote:

> - The draft doesn’t mention possible issues of giving one /64 for each UE,
> /55 is probably unnecessarily parimonious and it isn’t on a nibble
> boundary to make the address plan easy to understand.
> I’d suggest a minimum of /48 for a pool giving out /64s. A larger pool
> size will help avoid bringing the IPv4 pool exhaustion problem seen in BNGs
> into an average WLAN-GW.
>
> Regards
> Ross
>
>
>
>
> Minor Issues and Nits:

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 23 May 2016 17:48:14 +0000

First, thanks for your comments.

> On May 23, 2016, at 10:34 AM, Edwin Cordeiro <[email-masked]> wrote:
> 
> Our comment was that using a unique /64 per UE would considerably increase the amount of wasted addresses. It could be a problem in some deployments, but the document doesn't address this potential issue.

However, it is consistent with SLAAC and general deployment scenarios. A LAN, and in some cases a chassis, is assigned a /64. Yes, that creates a vast number of potential IIDs. That is intentional in the addressing architecture, and is viewed as a security feature. For example, although we have decided to not continue recommending this, https://tools.ietf.org/html/rfc4291#section-2.5.1 includes the MAC address in the IID, and RFC 7217 essentially provides for a random number that is difficult for an attacker to guess.

My local ISP (which has not yet deployed IPv6, shame on them, but expects to this year) tells me that they expect to deploy a /64, /60, or /56 to a UE depending on what it asks for in DHCP-PD. I would expect that is more common than not in residential broadband networks.

---

From: Adeel Sadiq <[email-masked]>
Date: Mon, 23 May 2016 23:15:47 +0500

Using a /55 does not make it easy at all to understand the address plan. So
why not go for the best of both worlds. Like /56 instead of /64 or /48.

Regards

Adeel Sadiq

On Mon, May 23, 2016 at 10:48 PM, Fred Baker (fred) <[email-masked]> wrote:

> However, it is consistent with SLAAC and general deployment scenarios. A
> LAN, and in some cases a chassis, is assigned a /64. Yes, that creates a
> vast number of potential IIDs. That is intentional in the addressing
> architecture, and is viewed as a security feature. For example, although we
> have decided to not continue recommending this,
> https://tools.ietf.org/html/rfc4291#section-2.5.1 includes the MAC
> address in the IID, and RFC 7217 essentially provides for a random number
> that is difficult for an attacker to guess.
>
> My local ISP (which has not yet deployed IPv6, shame on them, but expects
> to this year) tells me that they expect to deploy a /64, /60, or /56 to a
> UE depending on what it asks for in DHCP-PD. I would expect that is more
> common than not in residential broadband networks.
>

---

From: David Farmer <[email-masked]>
Date: Mon, 23 May 2016 15:27:10 -0500

On Mon, May 23, 2016 at 10:24 AM, Edwin Cordeiro <[email-masked]> wrote:

> of such approach but fails to analyse possible consequences. I would support
> this draft to move forward if these issues are addressed.

That is not the primary recommendation of this Draft.  The primary
recommendation of this Draft is simply to not limit the number of
address provided to a host.  Providing a unique /64 for each user is
really just one of many ways that can be used to provide multiple
addresses per users, it is only brought up as a solution to some
potential issues.  The Draft envision the primary way for this to be
done is through the use of traditional SLAAC.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 May 2016 12:56:14 +1200

> My local ISP (which has not yet deployed IPv6, shame on them, but expects to this year) tells me that they expect to deploy a /64, /60, or /56 to a UE depending on what it asks for in DHCP-PD. I wo…

Whereas my ISP gives me a /48, having noticed that IPv6 prefixes are not scarce.
Also, they give me a different /48 each time I reboot the UE, which is good
for privacy.

BTW what is the WG status of this draft? It hasn't been updated for a while
and is technically expired.

   Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 24 May 2016 01:01:13 +0000

> On May 23, 2016, at 5:56 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> what is the WG status of this draft? It hasn't been updated for a while

The author tells me that there is Comcast-specific content and more general content in the draft as posted. He plans to divide the draft into two parts, posting both before IETF 96.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 25 May 2016 14:44:35 +0200

On 5/23/16 7:48 PM, Fred Baker (fred) wrote:
>> On May 23, 2016, at 10:34 AM, Edwin Cordeiro <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Our comment was that using a unique /64 per UE would considerably
>> increase the amount of wasted addresses. It could be a problem in some
>> deployments, but the document doesn't address this potential issue. 

what's the difference between a router which required a prefix >= 64
when doing PD and a UE doing it. Do we know a priori if a device doing
so is doing so in it's capacity as a host our a router.

> LAN, and in some cases a chassis, is assigned a /64.

a device could practicaly decide to answer for all them save for the
router which will likely defend it's own via dad.

appart from the vast number of nd entries that might create it is
superficially similar to delegating the /64 (save for it being a
connected rather than nexthop pinned rute).

> Yes, that creates a
> architecture, and is viewed as a security feature. For example, although
> we have decided to not continue recommending
> this, https://tools.ietf.org/html/rfc4291#section-2.5.1 includes the MAC
> address in the IID, and RFC 7217 essentially provides for a random
> number that is difficult for an attacker to guess.
> 
> My local ISP (which has not yet deployed IPv6, shame on them, but
> expects to this year) tells me that they expect to deploy a /64, /60, or
> /56 to a UE depending on what it asks for in DHCP-PD. I would expect
> that is more common than not in residential broadband networks.
> 
>

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 25 May 2016 10:14:33 -0500

Hi Edwin,

I appreciate your review, especially the summary you provided.

Thus spake Edwin Cordeiro ([email-masked]) on Mon, May 23, 2016 at 02:34:49PM -0300:
> the amount of wasted addresses.

Well, for just one of our sites we would probably need a /44, so might
as well go with /40 to stay comfortable.  At our other sites, /48 would
work well.  But we have a /28 plus a handful of /32's, so really this 
isn't a concern at all now.  

> It could be a problem in some deployments, but the document doesn't address 
this potential issue.

Those deployments probably should go back to their RIR or upstream
provider based on an updated deployment plan.  Now is the time!

> > implementation alternative.

My thought is that there does not exist enough experience (for now) with
PD in this role to be comfortable for calling it a BCP.  But, as both you 
and the current document point out it is a logical next step.

Dale