Re: NIST IPv6 document

[Owen DeLong <owen () delong com>]

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.

Owen