On Jan 12, 2016, at 10:44 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 12 January 2016 at 19:03, Owen DeLong <owen@delong.com> wrote:
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?
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.
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… Now you’ve 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’t. You can use a sparse allocation scheme in RIPE land, but in all RIRs, the only limitation is that you don’t get more space until your sparse scheme gets relatively densely packed. Thats intentional and it’s 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.
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.
I encourage my competitors to attempt this strategy.
I do not believe we have ever been competitors…
We haven’t. I didn’t 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