On 25 November 2015 at 02:32, Mark Andrews <marka@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