Using /126 for IPv6 router links
nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Wed Jan 27 05:34:01 UTC 2010
On Wed, 27 Jan 2010 00:11:41 -0500
Christopher Morrow <morrowc.lists at gmail.com> wrote:
> On Tue, Jan 26, 2010 at 11:53 PM, Mark Smith
> <nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
> > The general intent of the /48 allocation is that it is large enough for
> > nearly everybody, with nearly everybody including all but the largest
> 'nearly everybody with a single site' sure. I know of more than a few
> VPN deployments (enterprises with remote offices) that have +1k remote
> sites. For these you're quickly talking about:
> 1) get PA (maybe, maybe not a good plan, see renumbering headaches)
> 2) get a large number of /48's (assume median size is 2048 - 1 /36)
> I know of one vpn deployment with +12k sites: a /34
If it's in the US, I might have worked on the product that was used to
build it about 10 years ago - that had 10K sites.
> I agree that a large majority of 'end sites' (enterprises) will be
> services with a single /48 from PA space, unless they want to
> multihome, or have more than 1 site and want some convenience.
A 'site' is intended to not specifically be geographic. In some
respects, it's meant to be a more generic version of IPv4's Autonomous
System. A geographic location might suit the boundary in some cases,
where as a single large organisation, who may have many
internal geographic sites in it's WAN, dual homed to a single ISP,
would also qualify as a single /48 "site".
> > of organisations. IOW, it's meant to be "nearly one-size-fits-all", to
> > try to ensure almost everybody gets as much address space as they'll
> > ever need at the time of their first request. An addressing plan for
> > anything less than the largest organsation that doesn't fit within
> > a /48 or will exceed it fairly rapidly is probably too inefficent.
> > ps. Remember that I'm one of the ones advocating using /64s everywhere,
> > so what ever you do, don't use "ruthlessly efficient" to describe my
> > position - use that for the /126 or /127 crowd ;-)
> I'd note I'm not a 'ruthless efficiency' guy either, just 'how ops is
> done today' and 'there be dragons, be aware what you step into'.
Sure. However I think people are treating IPv6 as just IPv4 with larger
addresses, yet not even thinking about what capabilities that larger
addressing is giving them that don't or haven't existed in IPv4 for a
very long time. People seem to be even ignoring the maths of how big a
single /48 is, just in terms subnets. I've never worked on an
individual network with 65K subnets (with the Internet being a network
of networks), and I doubt many people on this list have. Yet people
seem to treating a /48 as though all networks will have 65K subnets,
and therefore they'd better start of using longer than /64s because
they might run out of subnets.
I care about this because I don't want to see people have to change
their addressing in the future to /64s, because of that will typically
involve a lot of out of hours work (which could include me if I
inherit a network that has had longer than /64s deployed (there's my
bias)). I'd prefer to see people go the other way - deploy /64s
everywhere, as per the IPv6 Addressing Architecture, and if that proves
to be the wrong case, then go to the effort of deploying longer
prefixes. I think going from /64s to longer prefixes is far less likely
going to be needed than the other way around.
> think, and I'll start a fresh copy of this thread to articulate it,
> there have been 4-5 different issue conflated in this discussion,
> which is making things complicated.
> > Regards,
> > Mark.
More information about the NANOG