NIST IPv6 document

Wed Jan 5 15:04:08 UTC 2011

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.

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.

Jack