Subject: DHCPv6 Prefix Pool Option

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 2 Aug 2012 20:34:01 +0100

Hi,

At the Routing Area meeting this morning, Ted raised some potential DHCP work
that routing folk should look at. Comments ideally go to the DHC working group
or back to Ted.

Adrian

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: 02 August 2012 20:11
> To: [email-masked]
> Subject: DHCPv6 Prefix Pool Option
> 
> Thanks for the time at the mic this morning.   The document I wanted you to
> comment on or solicit comment on is the DHCPv6 Prefix Pool Option draft:
> 
> 	http://tools.ietf.org/html/draft-yeh-dhc-dhcpv6-prefix-pool-opt
> 
> There was a question at the mic about why the DHCP server wouldn't inject the
> route itself, which I think is a good question, and could be argued to be the
right
> thing to do.   However, operationally there are a lot of missing pieces to
this-the
> DHCP server now becomes, in addition to being a DHCP server, also a publisher
of
> routes, and has to have information about the routing topology of the ISP that
I
> think might be nontrivial to maintain.
> 
> The advantage of the current approach, which is improved by this new draft, is
> that it piggybacks on top of the existing relationship between the relay agent
and
> the DHCP server, which is required for DHCP to work.   The DHCP server now
> does not have to know the topology of the network-it sends the prefix
> aggregation information to the router, which presumably already has that
> information, by way of the DHCP relay, which is typically co-located in the
router.
> 
> So despite my protestations of innocence at the mic, I suppose I do really
think
> it's a reasonable way to solve this particular problem.

---

From: Acee Lindem <[email-masked]>
Date: Thu, 2 Aug 2012 15:47:41 -0400

Hi,
I'm not sure what I was thinking this morning when I said that the DHCP server should run a routing daemon and advertise the aggregate route. Rather, the BRAS server that is maintaining subscriber DHCP state should have a configured aggregation policy for the DHCP prefix pool route. This problem has already been solved in commercial BRAS servers and there is no need to add a generic route advertisement mechanism to DHCP. 
Thanks,
Acee

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Aug 2012 15:15:10 -0700

> I'm not sure what I was thinking this morning when I said that the DHCP server should run a routing daemon and advertise the aggregate route. Rather, the BRAS server that is maintaining subscriber…

Has the problem really been solved?   It seems to me that the BRAS has a limited capability to aggregate prefixes—it can only aggregate a group of prefixes when all of the prefixes that are members of that prefix have been assigned.   So if you have a DHCP server doing a fairly random allocation of prefixes out of an aggregate pool to a particular BRAS, in general the BRAS is not going to be able to advertise a route to the larger prefix, but rather only to smaller prefixes.   It may be able to reduce the routing table somewhat by combining adjacent prefixes, but it will never be able to advertise the actual prefix from which CPE prefixes are being allocated, because it can't know what that prefix is until every single prefix within it has been assigned.

Furthermore, as soon as a single prefix from within that prefix expires, the BRAS has to break apart the prefixes it is advertising.   And this has to be done carefully to avoid attracting routes that are no longer configured on the BRAS—it has to be done _before_ the prefix expires.   Whereas if the BRAS can be told "all your routes will be coming out of this prefix," then it can just continually advertise the same prefix, regardless of the comings and goings of DHCP requesting routers and the prefixes that are assigned to them.

---

From: Acee Lindem <[email-masked]>
Date: Fri, 3 Aug 2012 13:54:48 -0400

I'm sorry but it doesn't work this way at all. The BRAS server will advertise the aggregate if it has any component of the aggregate prefix and the BRAS server will know better than the DHCP server as to whether it has any subscribers within the range subsumed by the aggregate route  Any concerns with sub-optimal or routing are independent of whether the policy is in the DHCP server or BRAS router.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Aug 2012 09:27:56 -0400

> I'm sorry but it doesn't work this way at all. The BRAS server will advertise the aggregate if it has any component of the aggregate prefix and the BRAS server will know better than the DHCP server…

As far as I can tell, you are referring to the case where the BRAS has been allocated a prefix, and is acting as a DHCP server.   What you say doesn't really make sense if the BRAS is not the DHCP server.   The whole point of Leaf's draft, as I understand it (perhaps Leaf can jump in and correct me if I get it wrong) is to allow the DHCP server to be responsible for prefix allocation, and pull that intelligence out of the BRAS.   This allows for more flexibility than is possible if each BRAS has to be configured as a DHCP server with a fixed prefix from which to do allocations.

Also, Leaf's solution works generally for provider edge routers without requiring the heavyweight functionality of a BRAS—ultimately, for a straight IPv6 routed network with no PPP tunnels, the PE router can be _much_ simpler using prefix pool allocation than using the configuration technique you are describing.

---

From: Leaf yeh <[email-masked]>
Date: Tue, 7 Aug 2012 11:05:19 +0000

In general speaking, draft (OPTION_PREFIX_POOL) targets the use case when PE router (or BNG in BBF model) acts as the relay, and the centralized DHCPv6 server maintains the information about the prefix delegation pools.

Best Regards,
Leaf

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Monday, August 06, 2012 9:28 PM
To: Acee Lindem
Cc: [email-masked]; [email-masked] Chairs; <[email-masked]>; [email-masked]
Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option

Also, Leaf's solution works generally for provider edge routers without requiring the heavyweight functionality of a BRAS-ultimately, for a straight IPv6 routed network with no PPP tunnels, the PE router can be _much_ simpler using prefix pool allocation than using the configuration technique you are describing.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Aug 2012 08:50:32 -0400

So, I haven't heard any discussion on this topic since I wrote a clarifying message on August 6 about the intended use case for this option.   Does this mean that we've satisfactorily addressed the use case question that Acee raised, and that no-one else objects, or does it mean that everybody is taking a well-deserved break from IETF email following the Vancouver meeting?

---

From: Acee Lindem <[email-masked]>
Date: Fri, 17 Aug 2012 08:38:37 -0400

Hi Ted, 
I've been on vacation. I guess I see this as a case of the tail wagging the dog with the BNG getting routing aggregation policy from the DHCPv6 server. However, I'm certainly not going to let my opinion as a routing chair and developer of a leading BNG platform hold up the will of an entire working group. The "Security  Considerations" section does need to be beefed up as this does increase the exposure - just imagine a subverted DHCPv6 responding with 0::/0.
Thanks,
Acee

---

From: Leaf yeh <[email-masked]>
Date: Wed, 22 Aug 2012 10:44:45 +0000

Acee - The "Security  Considerations" section does need to be beefed up as this does increase the exposure - just imagine a subverted DHCPv6 responding with 0::/0.

I believe draft (OPTION_PREFIX_POOL) will have the same "security considerations" as that for the mechanism of DHCPv6-PD (OPTION_IA_PD), when BNG acts as the DHCPv6 relay for DHCPv6-PD.

DHCPv6-PD (OPTION_IA_PD) does also have the exposure on the routing for the customer network. While OPTION_PREFIX_POOL sets up the aggregation route, OPTION_IA_PD also request to set up route for the customer network on the PE router.

If the subverted PD prefix is ::/0, then the PE router will face the same problem, right?

I suppose the DHCPv6 server, acting as the role of network administrator, needs to prevent this case happen.

Best Regards,
Leaf

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Friday, August 17, 2012 8:39 PM
To: Ted Lemon
Cc: [email-masked]; [email-masked]; [email-masked] Chairs; <[email-masked]>; Leaf yeh
Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option

Hi Ted,

---

From: Acee Lindem <[email-masked]>
Date: Wed, 22 Aug 2012 15:48:51 -0400

Hi Leaf,

> I've been on vacation. I guess I see this as a case of the tail wagging the dog with the BNG getting routing aggregation policy from the DHCPv6 server. However, I'm certainly not going to let my op…

There is discussion of this case in RFC 3633 "Security Considerations". However, I'd now expect the mechanisms to authenticate the DHCP exchanges to be more mature. Also, the threats of readvertisement need to be discussed better than in RFC 3633. 

Thanks,
Acee