NIST IPv6 document
jbates at brightok.net
Wed Jan 5 09:04:08 CST 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.
More information about the NANOG