[187005] 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 14:05:40 2016
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAPkb-7Di6Rzg7Lu8xzXN3PTRAbYU=m6uB3B+LS9Bbsv4vgcqAQ@mail.gmail.com>
Date: Tue, 12 Jan 2016 11:03:33 -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 10:44 , Baldur Norddahl =
<baldur.norddahl@gmail.com> wrote:
>=20
> On 12 January 2016 at 19:03, Owen DeLong <owen@delong.com> wrote:
>=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.
>>=20
>> 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
>>=20
> I fear I will be retired before the first happens. As to the second, =
even
> with CGN they will have an internal IPv4 that can be used for the =
mapping.
Sure, there are ways to work around whatever you need.
>=20
> Please also take notice that there is nothing that prevents you from
> reversing the mapping: assign /48 to customers and then calculate the =
IPv4
> from that. The point here is just that you do not really need to do =
the
> work twice.
OK=E2=80=A6 Now you=E2=80=99ve got a customer that has their own =
internal network serving
a campus with 12 buildings and also they have a WAN connecting 18 remote
sites. All of this is behind NAT with a single IPv4 from you. How do you
give them the 30 /48s that they should be receiving for that network =
with
your current scheme?
> The limitation of the system is that it requires a dense scheme for
> allocating /48 to customers. Unfortunately that is already a =
requirement in
> RIPE land, so it does not add something new.
Actuallly, it isn=E2=80=99t.
You can use a sparse allocation scheme in RIPE land, but in all RIRs, =
the
only limitation is that you don=E2=80=99t get more space until your =
sparse scheme
gets relatively densely packed. Thats intentional and it=E2=80=99s not a =
bad thing.
>> 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.
>>=20
>>=20
> I would say it saves you from doing a lot of work. It will be a long =
time
> before you can skip the IPv4 part entirely and just do IPv6. The =
exception
> being if you use certain transition technologies that tunnels IPv4 on =
top
> of an IPv6 only network, in which case I would probably do something
> different (or maybe not). My scheme works for our network, which uses =
L3VPN
> and MPLS.
I expect it will be about 4 years before we start seeing eyeball =
networks
discontinuing support for IPv4 or at least charging a premium for it.
There are already a growing number of networks that are, in fact, =
providing
IPv4 only as a tunnel over IPv6.
>=20
>=20
>> I encourage my competitors to attempt this strategy.
>>=20
>=20
> I do not believe we have ever been competitors=E2=80=A6
We haven=E2=80=99t. I didn=E2=80=99t say I was encouraging you to =
attempt this strategy.
I did say that I believe my competitors applying this strategy would =
work out
in my favor.
Owen
