IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

Jeff Wheeler jsw at inconcepts.biz
Thu Dec 1 20:13:51 UTC 2011


On Thu, Dec 1, 2011 at 9:42 AM, Chuck Anderson <cra at 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 at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts




More information about the NANOG mailing list