On Thu, Dec 1, 2011 at 9:42 AM, Chuck Anderson <cra@wpi.edu> wrote:
Jumping in here, how about static ND entries? Then you can use the /64 for P-t-P, but set the few static ND entries you need, and turn off dynamic ND. An out-of-band provisioning system could add static ND entries as needed.
Another idea, perhaps more useful for client LANs, would be to have a fixed mapping between IPv6 IID and MAC address. Use DHCPv6 to force
Chuck, you are certainly correct that if ND resolution can be deactivated for an interface, there won't be an ND exhaustion problem on it. That's why I characterize the problem as ND exhaustion. :-) Whether or not this is practical for a given environment is up to the operators to decide. I, for example, know it is much easier for me to configure a /126 P-t-P than keep static ND entries and disable ND on those links. In my own backbone, your suggestion can be practical, but what about customer links? If the customer changes his device, he may present a different MAC address to my interface. Then I've got a static ND entry pointing to his old MAC address... resulting in a ticket, and ops work, which would not have been necessary with a simple /126. DHCPv6 with snooping and learning disabled would be great for the datacenter LAN if I thought I could get customers to bite off on it. When vendors begin delivering this feature it is something we will strongly consider. I don't know if customers will prefer to have this and need to run a DHCPv6 client, or prefer to have a /120 (or similar) for the approximate number of addresses they plan to use. I am not closed to alternatives. I want to give my customers /64s as soon as it becomes practical and production-ready. That is why we always reserve a /64 for each subnet, even though it is provisioned as a longer subnet. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts