In our IPv6 courses, we often get the question: I give my customers a /48 (or a /56 or a /52) but they have no idea how to distribute that space in their network.
In December Sander Steffann and Surfnet wrote a manual explaining exactly that, in clear language with nice graphics. A very useful document but it was in Dutch,
so RIPE NCC decided to translate that document to English.
Yesterday, we have published that document on our website and we hope this document is able to take away some of the fear that end users seem to have for these huge blocks.
You can find this document here:
Nathalie,
As an end customer (not a carrier) over in ARIN land I purchased a /48
about a year ago for our future IPv6 needs. We have 4 different Internet
touchpoints (two per carrier) all rated at about 1Gbps. Recently, both
carriers told us that the minimum advertisement they would accept PER
CIRCUIT would be a /48. I was surprised to say the least. Basically a /48
would not be enough for us. The arguement was that this was to support all
the summarization efforts and blah blah blah. Even though my space would be
unique to either carrier. So now I'm contemplating a much larger block.
Seems wasteful but I have to for the carriers. Have you heard of this
elsewhere or is this maybe just an ARIN/American thing? Both carriers told
me that in discussions with their peers that they were all doing this.
Hi, I saw your document "Preparing an IPv6 Addressing Plan" after its URL
was posted to NANOG.
I have one small comment that perhaps you would consider in future
revisions:
The use of decimal numbers coded in hexadecimal is introduced in section
3.2, "Direct Link Between IPv4 and IPv6 Addresses", without discussion.
It's also implicit in section 4.9 when encoding decimal VLAN numbers in
hexadecimal address ranges.
My opinion is that this may be a source of confusion, and should be
explicitly described somewhere before section 3.2, as a deliberate
implementation choice that makes it easier for human operators to configure
and recognize deliberately-chosen mappings between decimals in IPv4
addresses and integers and corresponding fields in hexadecimal address
ranges.
Without an explicit discussion, this point may be missed by some readers --
especially since this is a training document.
Just my opinion!
I'm also curious as to whether this describes the way the world has already
settled on, or whether this is a novel, controversial, or
only-occasonally-observed technique. I see that RFC 5963 - IPv6 Deployment
in Internet Exchange Points (IXPs) of August 2010 does mention BCD encoding
of both ASNs and IPV4 digits, so I guess it's not that novel.
Hi, I saw your document "Preparing an IPv6 Addressing Plan" after its URL was posted to NANOG.
I have one small comment that perhaps you would consider in future revisions:
The use of decimal numbers coded in hexadecimal is introduced in section 3.2, "Direct Link Between IPv4 and IPv6 Addresses", without discussion. It's also implicit in section 4.9 when encoding decimal VLAN numbers in hexadecimal address ranges.
My opinion is that this may be a source of confusion, and should be explicitly described somewhere before section 3.2, as a deliberate implementation choice that makes it easier for human operators to configure and recognize deliberately-chosen mappings between decimals in IPv4 addresses and integers and corresponding fields in hexadecimal address ranges.
You are right, we could explain this section in more detail and we have received this feedback from some other readers as well. We will take this into account for future revision.
Without an explicit discussion, this point may be missed by some readers -- especially since this is a training document.
Just my opinion!
I'm also curious as to whether this describes the way the world has already settled on, or whether this is a novel, controversial, or only-occasonally-observed technique. I see that RFC 5963 - IPv6 Deployment in Internet Exchange Points (IXPs) of August 2010 does mention BCD encoding of both ASNs and IPV4 digits, so I guess it's not that novel.
As I'm not the author of the document - only the initiator of the translation - I'm not sure if I'm the right person to answer this question However, I do think it is an interesting discussion on how far "the world has already settled on" different IPv6 implementation techniques. There are relatively only a few mature operational IPv6 implementations at the moment and the intention of this document is to have people think of a structure for their address plan and give them some pointers.
In case you would like to know more of the background of this document, please talk to Sander Steffann (the author). I'm sure he will be happy to answer your questions.
I believe based on my observation and experience that it describes a relatively common practice, but, not
one which has in any way been standardized. It is one approach that is available and which has proven
useful to others. Both the BCD and Hex translation techniques are in relatively common use, but, the BCD
mechanism seems to be somewhat more common.
The important thing to be careful about with BCD is that you do not attempt to represent all four octets of
an address with each cluster representing an octet because you will violate the "first 12 bits of a static
suffix must be zero" rule (following that rule avoids accidental conflicts with stateless autoconf).
Nathalie,
As an end customer (not a carrier) over in ARIN land I purchased a /48
about a year ago for our future IPv6 needs. We have 4 different Internet
touchpoints (two per carrier) all rated at about 1Gbps. Recently, both
carriers told us that the minimum advertisement they would accept PER
CIRCUIT would be a /48. I was surprised to say the least. Basically a /48
would not be enough for us. The arguement was that this was to support all
the summarization efforts and blah blah blah. Even though my space would be
unique to either carrier. So now I'm contemplating a much larger block.
Seems wasteful but I have to for the carriers. Have you heard of this
elsewhere or is this maybe just an ARIN/American thing? Both carriers told
me that in discussions with their peers that they were all doing this.
there are providers that will accept more specific prefixes from the
customers for internal use. since /48 is the minimum arin allocation
there is observed to be general consensus on not accepting prefixes
longer than /48 into the dfz.
is one such example of a transit provider that will carry longer
prefixes internally.
However, I do think it is an interesting discussion on how far "the world has already settled on" different IPv6 implementation techniques. There are relatively only a few mature operational IPv6 implementations at the moment and the intention of this document is to have people think of a structure for their address plan and give them some pointers.