Baldur Norddahl <baldur.norddahl@gmail.com> writes:
Note that 12 is "0b" in hexadecimal.
Only when gravity is negative IIRC.
Bjørn
Yes sorry I have program to do the calculation in production. Correcting
the bug is left as an exercise for the reader.
Regards
Baldur
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
> 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.
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.
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.
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 encourage my competitors to attempt this strategy.
I do not believe we have ever been competitors...
Regards,
Baldur
As an end user, you can get an IPv6 /48 and still qualify for the /24 of transitional space as well.
Owen
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 donot
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
There's an option that I forgot to mention:
You can still use an RIR and get a last /22 in the RIPE region provided you
follow their rules, and no, you do not have to be in Europe.
Read carefully:
https://www.ripe.net/participate/policies/proposals/2013-03
Best,
-M<
As an end user, you can get an IPv6 /48 and still qualify for the /24 of transitional space as well.
did ARIN hold back some blocks to service the 'transitional space', or would
that be going to the STLS list?
--jim
The held back a /10 from their final /8 allocation. Details @
https://www.arin.net/policy/nrpm.html#four10 .
if anyone is interested, i have some legacy ARIN space that i'm selling off.
it is registered in the ARIN STLS marketplace, and the easiest way to
follow through would be by pre-qualifying:
https://www.arin.net/resources/transfers/preapproval.html
contact me to negotiate pricing. this is a direct sale, i'm not an agent.
i can currently do blocks from /24 to /16.
--jim