DHCPv6 PD & Routing Questions

Wed Nov 25 01:32:36 UTC 2015

In message <CAPkb-7D3J8yCdvPkZvwgrWTmxbcunEi7xhGrcnCtAervc5cBYA at mail.gmail.com>
, Baldur Norddahl writes:
> 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.

Does any RFC state copy "DNS servers from upstream DHCP response"?
(the answer is NO by the way).  Not everything should require a
RFC.

> 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 (*).

Then none of the CPE vendors are worth their salt as product
suppliers.

> 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.

It's a hint for the amount of space you need.  What else would you
put in there other than that value.  If you get more than you need
then there is no problem.  If you get less than you need then you
have a problem.

I've got a CPE with 3 internal interfaces.  I would expect it would
ask for a /62 (which wastes 1 /64) or /63 and a /64 or 3 x /64 if
the /62 or /63 could not be met.  It's not that hard to request
what you need.

If you even think about the issue for a couple of seconds which you
did to compose this reply you would realise that asking for a /48
by default is stupid and doesn't meet the definition of the hint
which is the amount of space you need.

> 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").

Which demonstrates that with a little bit of thought *you* could
work though the issue of making the hint be a /48.

> 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.

No.  You go and make a request from the upsteam.  The worst they
can do is deny it.

> 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.
> 
> Regards,
> 
> Baldur
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org