[187002] in North American Network Operators' Group
Re: Deploying IPv6 in an ISP network [ was: Best Source for ARIN
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Jan 12 13:05:19 2016
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAPkb-7AKzO=LgJChnVE4C-8WQJnQumw6fbqvUZry1-Z5mAXx0g@mail.gmail.com>
Date: Tue, 12 Jan 2016 10:03:09 -0800
To: Baldur Norddahl <baldur.norddahl@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On Jan 12, 2016, at 07:08 , Baldur Norddahl =
<baldur.norddahl@gmail.com> wrote:
>=20
> Do you seek information on how to plan subnetting or on more technical
> issues like how to dual stack your network? In the later case, you =
would
> need to tell more about your network. Eg. if you have a MPLS network =
(like
> we do) and you have your internet in a L3VPN enabling IPv6 is really =
easy
> and has almost no impact on the network.
>=20
> As an alternative to the plan that Owen describes, I can offer the way =
we
> did it: Our IPv6 address plan is tied to our IPv4 addressing, such =
that
> there is a mapping from IPv4 address to IPv6 /48 prefix. That way we =
do not
> need to allocate IPv6 as such.
How do you expect that to work out when you have customers without IPv4 =
addresses
or once you start having to share IPv4 addresses among customers?
>=20
> The mapping is a database with IPv4 /24 as key and IPv6 /40 as value.
> Example:
>=20
> 85.204.120.0/24 maps to 2a00:7660:500::/40.
>=20
> Take the user with the IPv4 address 85.204.120.12. This address maps =
to
> 2a00:7660:50b::/48. Note that 12 is "0b" in hexadecimal.
>=20
> We are an eyeball network where most users have only one single IPv4
> address. We assign the IPv4 addresses statically (never changes). A =
few
> users bought extra IPv4 address and that creates a hole in our address
> plan, but we do not care. Officially the extra /48 is not assigned to =
the
> user, because that would be against the rules.
>=20
> Our address plan creates a very efficient allocation scheme, that is =
not
> strictly needed as you have the more loose ARIN rules (we are in =
RIPE).
Your address plan ties your future to your legacy technology that you =
should
be looking forward to deprecating and places limitations on your future
addressing that are coupled to the shortcomings of the legacy addressing
capabilities.
I encourage my competitors to attempt this strategy.
Owen
