NIST IPv6 document

Owen DeLong owen at
Wed Jan 5 23:31:37 CST 2011

On Jan 5, 2011, at 7:04 AM, Jack Bates wrote:

> On 1/5/2011 6:29 AM, Dobbins, Roland wrote:
>> Using /64s is insane because a) it's unnecessarily wasteful (no
>> lectures on how large the space is, I know, and reject that argument
>> out of hand) and b) it turns the routers/switches into sinkholes.
> Except someone was kind enough to develop a protocol that requires /64 to work. So then there is the SLAAC question. When might it be used?
> With routers, I usually don't use SLAAC. The exception is end user networks, which makes using SLAAC + DHCPv6-PD extremely dangerous for my edge routers. DHCPv6 IA_TA + DHCPv6-PD would be more sane, predictable, and filterable (and support longer than /64) thought my current edge layout can't support this (darn legacy IOS).
> I would love a dynamic renumbering scheme for routers, but until all routing protocols (especially iBGP) support shifting from one prefix to the next without a problem, it's a lost cause and manual renumbering is still required. Things like abstracting the router id from the transport protocol would be nice. I could be wrong, but I think ISIS is about it for protocols that won't complain.
> All that said, routers should be /126 or similar for links, with special circumstances and layouts for customer edge.
Why shouldn't I use /64 for links if I want to? I can see why you can say you want /126s, and that's fine, as long as 
you are willing to deal with the fall-out, your network, your problem, but, why tell me that my RFC-compliant network
is somehow wrong?

> For server subnets, I actually prefer leaving it /64 and using SLAAC with token assignments. This is easily mitigated with ACLs to filter any packets that don't fall within the range I generally use for the tokens, with localized exceptions for non-token devices which haven't been fully initialized yet (ie, stay behind stateful firewall until I've changed my IP to prefix::0-2FF). I haven't tried it, but I highly suspect it would fail, but it would be nice to use SLAAC with longer than /64.
SLAAC cannot function with longer than /64 because SLAAC depends on prefix + EUI-64 = address.


More information about the NANOG mailing list