On 10 July 2015 at 15:21, George, Wes <wesley.george@twcable.com> wrote:
On 7/10/15, 6:34 AM, "NANOG on behalf of Baldur Norddahl" <nanog-bounces@nanog.org on behalf of baldur.norddahl@gmail.com> wrote:
Perhaps the problem is that DHCPv6-PD is not intelligent enough. Yes there is a provision such that the user CPE could give a hint of how much space is want, but no, it doesn't work. WG] Sorry, [citation needed]. We are using DHCPv6-PD that listens for and responds properly to hints in production for millions of customers.
Thank you for your insight. I went back and checked if I overlooked something. I managed to make a sample of 136 unique CPEs (not unique models, just unique devices). The sample was chosen so none of those had been previously provisioned with IPv6. Zero of them provided hints. It will look like this: (IA_PD IAID:1 T1:0 T2:0) or (IA_PD IAID:660514110 T1:3600 T2:5400) The values differ but none include hints. CPEs that have previously been configured will provide hints, but that is just our own prefix length that is returned back. Eg.: (IA_PD IAID:1 T1:300 T2:600 (IA_PD-prefix 2a00:7660:8ca::/48 pltime:600 vltime:600)) You wouldn't blame the protocol when IPv6 doesn't work for your customers
who use a device that doesn't support IPv6, would you?
No but I believe the RFCs lack useful directions in how CPEs and DHCP servers should use hints. My sample shows that the popular CPEs used by our users simply do not even attempt to use this mechanism.
The user CPE does not understand this issue either and has no information that could make it the smart place to do the decision. Plus which of the multiple CPEs would be in control? WG] IETF Homenet WG is currently chewing on the problem of multiple CPEs in an unmanaged environment. It's not an easy problem if you have to design it so that it works automagically no matter how strangely it's connected together. You may want to check it out: http://datatracker.ietf.org/wg/homenet/charter/
Thank you for the link. It is good to see that someone is working on the issue.
Maybe if the CPEs would go back and ask for more address space, if what they initially got ran out. But DHCPv6-PD does not really have a way to do that. In any case no CPE implements any such thing.
WG] also not exactly true. No, most CPE won't do it automatically, but DHCPv6 can do it. Release existing prefix, request new prefix with bigger hint. Depending on DHCP server policy, you might even be able to do it in the opposite order (make before break) since you can have multiple prefixes. My hunch is that on most residential broadband setups, it's not likely to be hitless, and most cheap plastic routers can probably only do it via a reboot after you reconfigure it to ask for more space in the hint, but it's doable. See above recommendation for homenet if you want it to be automatic.
Actually DHCPv6 does not allow you to request additional prefixes. Section 12.2 from RFC 3633: " A delegating router examines the prefix(es) identified in IA_PD Prefix options (in an IA_PD option) in Renew and Rebind messages and responds according to the current status of the prefix(es). The delegating router returns IA_PD Prefix options (within an IA_PD option) with updated lifetimes for each valid prefix in the message from the requesting router. * If the delegating router finds that any* * of the prefixes are not in the requesting router's binding entry, the* * delegating router returns the prefix to the requesting router with* * lifetimes of 0.* " If you attempt that, you will just get the prefix back with lifetime zero. So the only way is to release the binding and start over. That does not feel like a real solution and is also not anything likely implemented. I am looking for solutions that I can implement today. It appears the right thing to do is to take 4 bits from the user and use at the ISP level. He is still getting his /48 allocation, but we used 4 bits for the first layer of delegating routers. He will see this as multiple sequential /52 delegations. 95% of the users will only connect one CPE and will only be able to use /52 worth of space. But really, we have not seen any actual use case presented where this is a problem. I believe we will be providing a better service by delivering /52 by default and then allow multiple DHCP bindings, than to do a single /48 and refuse multiple bindings. We could implement respecting /48 hints from a CPE, such that a user can override the /52 default behavior by asking his CPE to request a /48. It is just that my sample indicates that most CPEs may not have this option. Regards, Baldur