DHCPv6 PD & Routing Questions

Wed Nov 25 02:35:19 UTC 2015

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

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

You might think that would be obvious, but exactly zero (0) commercial
available CPEs has implemented it like that.

THAT means that if you expect the community to do it like this, you do in
fact need to write it in a RFC.

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

Where did you find a "definition of the hint"?

The RFC only has two short sections about the size hint:

"In a message sent by a requesting router to a delegating router, the

   values in the fields can be used to indicate the requesting router's
   preference for those values.  The requesting router may send a value
   of zero to indicate no preference.  A requesting router may set the
   IPv6 prefix field to zero and a given value in the prefix-length
   field to indicate a preference for the size of the prefix to be

   delegated."

and

"If the requesting router includes an IA_PD Prefix option in the IA_PD

   option in its Solicit message, the delegating router MAY choose to
   use the information in that option to select the prefix(es) or prefix

   size to be delegated to the requesting router."

It might be stupid, but the majority of the implementers read the RFC
without your insight. It is poorly worded, because there is no guidance.
You can not expect everyone to figure it out by themselves, especially not
if you want them to come to the same conclusion. In this case people did
come to a conclusion, it was just not the one you wanted.

That conclusion was something like this: Hmm what is my preference for
prefix size? I read NANOG and the cool guys says a /48 is better than /56,
so I think my preference should be /48. I will put in /48 in this field.
The only other option anyone really considered was putting in zero.

> 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.
>
>
That is overly complex and with nothing in a RFC, few to none would
implement it. We do not like to spend time and money on features nobody
else implements.

a) receive a request (as a server), see that we have too little space to
fulfill the size hint
b) go to the upstream server (as a client) and ask for more space
c) if we still have too little space, ignore the size hint and do some
other unspecified other action
d) step a-c are asynchronous (have to wait unspecified time from upstream
server, before we can make our own reply). This could be a problem because
a DHCP server would usually not be programmed in this way.

Fact is just that the DHCPv6 client and the DHCPv6 server are usually two
pieces of a CPE that do not work together. Might even be two pieces of
software from different projects. Then it becomes very complex to get that
kind of coordination between client and server.

I am not saying that it is impossible to implement a sane system using the
framework provided by DHCPv6-PD. But too much was left out. Companies are
not going to fill in the blanks. It will not be done until there is
consensus this is the right way to implement hierarchical CPEs in the home.

Regards,

Baldur