ISP DHCPv6 and /48

Sat Jul 11 10:55:45 UTC 2015

On 10 July 2015 at 15:21, George, Wes <wesley.george at twcable.com> wrote:

> On 7/10/15, 6:34 AM, "NANOG on behalf of Baldur Norddahl"
> <nanog-bounces at nanog.org on behalf of baldur.norddahl at gmail.com> wrote:
>
>
> >Perhaps the problem is that DHCPv6-PD is not intelligent enough. Yes there
> >is a provision such that the user CPE could give a hint of how much space
> >is want, but no, it doesn't work.
> WG] Sorry, [citation needed]. We are using DHCPv6-PD that listens for and
> responds properly to hints in production for millions of customers.

Thank you for your insight. I went back and checked if I overlooked
something. I managed to make a sample of 136 unique CPEs (not unique
models, just unique devices). The sample was chosen so none of those had
been previously provisioned with IPv6. Zero of them provided hints. It will
look like this:

(IA_PD IAID:1 T1:0 T2:0)

or

(IA_PD IAID:660514110 T1:3600 T2:5400)

The values differ but none include hints. CPEs that have previously been
configured will provide hints, but that is just our own prefix length that
is returned back. Eg.:

(IA_PD IAID:1 T1:300 T2:600 (IA_PD-prefix 2a00:7660:8ca::/48 pltime:600
vltime:600))

You wouldn't blame the protocol when IPv6 doesn't work for your customers
> who use a device that doesn't support IPv6, would you?
>

No but I believe the RFCs lack useful directions in how CPEs and DHCP
servers should use hints. My sample shows that the popular CPEs used by our
users simply do not even attempt to use this mechanism.

>
> >The user CPE does not understand this
> >issue either and has no information that could make it the smart place to
> >do the decision. Plus which of the multiple CPEs would be in control?
> WG] IETF Homenet WG is currently chewing on the problem of multiple CPEs
> in an unmanaged environment. It's not an easy problem if you have to
> design it so that it works automagically no matter how strangely it's
> connected together. You may want to check it out:
> http://datatracker.ietf.org/wg/homenet/charter/
>
>
Thank you for the link. It is good to see that someone is working on the
issue.

> >
> >Maybe if the CPEs would go back and ask for more address space, if what
> >they initially got ran out. But DHCPv6-PD does not really have a way to do
> >that. In any case no CPE implements any such thing.
>
> WG] also not exactly true. No, most CPE won't do it automatically, but
> DHCPv6 can do it. Release existing prefix, request new prefix with bigger
> hint. Depending on DHCP server policy, you might even be able to do it in
> the opposite order (make before break) since you can have multiple
> prefixes. My hunch is that on most residential broadband setups, it's not
> likely to be hitless, and most cheap plastic routers can probably only do
> it via a reboot after you reconfigure it to ask for more space in the
> hint, but it's doable. See above recommendation for homenet if you want it
> to be automatic.
>
>
Actually DHCPv6 does not allow you to request additional prefixes.

Section 12.2 from RFC 3633:

"   A delegating router examines the prefix(es) identified in IA_PD
   Prefix options (in an IA_PD option) in Renew and Rebind messages and
   responds according to the current status of the prefix(es).  The
   delegating router returns IA_PD Prefix options (within an IA_PD
   option) with updated lifetimes for each valid prefix in the message
   from the requesting router. * If the delegating router finds that any*
*   of the prefixes are not in the requesting router's binding entry, the*
*   delegating router returns the prefix to the requesting router with*
*   lifetimes of 0.*
"

If you attempt that, you will just get the prefix back with lifetime zero.

So the only way is to release the binding and start over. That does not
feel like a real solution and is also not anything likely implemented.

I am looking for solutions that I can implement today. It appears the right
thing to do is to take 4 bits from the user and use at the ISP level. He is
still getting his /48 allocation, but we used 4 bits for the first layer of
delegating routers. He will see this as multiple sequential /52 delegations.

95% of the users will only connect one CPE and will only be able to use /52
worth of space. But really, we have not seen any actual use case presented
where this is a problem.

I believe we will be providing a better service by delivering /52 by
default and then allow multiple DHCP bindings, than to do a single /48 and
refuse multiple bindings.

We could implement respecting /48 hints from a CPE, such that a user can
override the /52 default behavior by asking his CPE to request a /48. It is
just that my sample indicates that most CPEs may not have this option.

Regards,

Baldur