DHCPv6 PD & Routing Questions

Wed Nov 25 05:23:33 UTC 2015

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

Or you could write it as you think it is needed.

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

The cool guys tell the ISP's to hand out /48s.  They don't say request
a /48.  There is a difference.

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

Well write a RFC and implement it.  Thats what I do when I find a
I find something is missing or a problem and should be common to
multiple implementations.  Its not hard to do.  If you leave to
someone else it doesn't get addressed.

Negative caching is a example of this. (RFC 2308)
The DLV record is a example of this. (RFC 5074)
The default local zones is a example of this. (RFC 6303)
The EDNS EXPIRE option is a example of this. (RFC 7314)
The EDNS COOKIE option is a example of this. (in last call)
draft-ietf-dnsop-rfc6598-rfc6303-02 is yet another example (in last call)

draft-andrews-dns-no-response-issue-12 (dnsop call for adoption
					at the moment)
+ others

Most of my developement work is with nameservers but I occasionally
fiddle on the DHCP side.

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

They are usually seperate for in some classes of devices and
integrated in others.  If you are designing a DHCP server for a ISP
you want it to be seperate.  If you designing a DHCP client for a
PC it or tablet it is seperate.  If you are designing for a router
you do a integated server/client (which by the what is what lots
of CPE routers have).

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

DHCPv6-PD described the client/server iteraction necessary to get
a prefix delegated.  There are lots of reasons to requests a
delegation.  You are a border router.  You are a interior router.
You are running VM's and need addresses for them.  You want multiple
addresses and DHCP IA only gives you one.  I'm sure someone else
will figure out some other use for DHCPv6-PD soon enough.

Homenet is looking at plugging together routers in ad-hoc networks
without administators.

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