DHCPv6 PD & Routing Questions

Baldur Norddahl baldur.norddahl at gmail.com
Wed Nov 25 00:34:28 UTC 2015

On 25 November 2015 at 00:36, Mark Andrews <marka at isc.org> wrote:

> Give PD is designed to allow you to have multiple delegation requests
> from one router to the dhcp server (router) and manage them
> independently.  Just request prefixes as you need them.  If the
> dhcp server (router) doesn't have any available it just make a up
> stream request.  Ultimately this will get to the border router and
> be fullfilled there flowing back through all the itermediate servers
> and depending upon how they are configured setting up routes.
> Alternatively the original requesting route injects a route for the
> delegated prefix into the IRP.
> This isn't rocket science.  Just use your @#!Q$# brains when you build
> CPE routers.
> This isn't new.  DHCP servers have got answers from upsteam DHCP
> servers for various IPv4 DHCP options (e.g. DNS servers).  PD isn't
> conceptually different other than it is done on demand rather than
> in advance.
> Mark

Too many details were left out. Without a RFC to guide implementations, you
can have no expectations that a mix of CPE routers on your home network
will behave in any particular way.

DHCPv6-PD allows multiple PD requests. But did anyone actually implement
that? I am not aware of any device that will hand out sub delegations on
one interface, notice that it is out of address space and then go request
more space from the upstream router (*).

DHCPv6-PD allows size hints, but it is often ignored. Also there is no
guidance for what prefix sizes you should ask for. Many CPEs will ask for
/48. If you got a /48 you will give out that /48 and then not honor any
further requests, because only one /48 per site is allowed. If you are an
ISP that gives out /48 and your customers CPE asks for a /56 you will still
ignore his size hint and give him /48.

If a CPE device gets a size hint of /48 from a downstream CPE router, it
will be forced to ignore that hint and give out - what? A /49 because that
is the closest to a /48 that is possible, if you only got a /48 yourself? A
/56 because that is half the available bits for prefixes? A /60 because who
needs more? A /52 because why would you connect more than 16 directly
connected downstream routers? Nothing because it asked for a /48 and you
couldn't give it that, so the request should be ignored (the last option
works really poorly because the DHCPv6 spec has no way to signal "please
ask again for less space").

If we go back to the point I marked with (*) above, then think about when
should you take a size hint seriously enough to go and request more space
from the upstream server? Usually you wouldn't. You would just ignore his
size hint and give him less space than asked for.

Really it is a mess. We have too many options and therefore you will not
see a good working system from multiple vendors in this space as is.

I am aware of the homenet working group, which seems to have taken a
different approach to solve the issues.



More information about the NANOG mailing list