Deploying IPv6 in an ISP network [ was: Best Source for ARIN Region /24 ]

Owen DeLong owen at delong.com
Tue Jan 12 18:03:09 UTC 2016


> On Jan 12, 2016, at 07:08 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> 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.
> 
> 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?

> 
> The mapping is a database with IPv4 /24 as key and IPv6 /40 as value.
> Example:
> 
> 85.204.120.0/24 maps to 2a00:7660:500::/40.
> 
> 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.
> 
> 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.
> 
> 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




More information about the NANOG mailing list