[134442] in North American Network Operators' Group
Re: NIST IPv6 document
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jan 6 00:32:40 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4D248868.70705@brightok.net>
Date: Wed, 5 Jan 2011 21:31:37 -0800
To: Jack Bates <jbates@brightok.net>
Cc: Nanog Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 5, 2011, at 7:04 AM, Jack Bates wrote:
> On 1/5/2011 6:29 AM, Dobbins, Roland wrote:
>>=20
>> 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.
>>=20
>=20
> 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?
>=20
> 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).
>=20
> 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.
>=20
> All that said, routers should be /126 or similar for links, with =
special circumstances and layouts for customer edge.
>=20
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=20
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.
>=20
SLAAC cannot function with longer than /64 because SLAAC depends on =
prefix + EUI-64 =3D address.
Owen
