Creating an IPv6 addressing plan for end users
Hi all, 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: http://bit.ly/IPv6addrplan (PDF) I look forward to your feedback, tips and comments. With kind regards, Nathalie Trenaman RIPE NCC Trainer
For those who don't like clicking on random bit.ly links: http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6 _addr_plan4.pdf --Heather -----Original Message----- From: Nathalie Trenaman [mailto:nathalie@ripe.net] Sent: Wednesday, March 16, 2011 5:05 AM To: nanog@nanog.org Subject: Creating an IPv6 addressing plan for end users Hi all, 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: http://bit.ly/IPv6addrplan (PDF) I look forward to your feedback, tips and comments. With kind regards, Nathalie Trenaman RIPE NCC Trainer
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. -Hammer- "I was a normal American nerd." -Jack Herer On Wed, Mar 16, 2011 at 1:52 PM, Schiller, Heather A < heather.schiller@verizonbusiness.com> wrote:
For those who don't like clicking on random bit.ly links:
http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6 _addr_plan4.pdf
--Heather
-----Original Message----- From: Nathalie Trenaman [mailto:nathalie@ripe.net] Sent: Wednesday, March 16, 2011 5:05 AM To: nanog@nanog.org Subject: Creating an IPv6 addressing plan for end users
Hi all,
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:
http://bit.ly/IPv6addrplan (PDF)
I look forward to your feedback, tips and comments.
With kind regards,
Nathalie Trenaman RIPE NCC Trainer
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.
-----Original Message----- From: Nathalie Trenaman [mailto:nathalie@ripe.net] Sent: Wednesday, March 16, 2011 5:05 AM To: nanog@nanog.org Subject: Creating an IPv6 addressing plan for end users
Hi all,
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:
http://bit.ly/IPv6addrplan (PDF)
I look forward to your feedback, tips and comments.
With kind regards,
Nathalie Trenaman RIPE NCC Trainer
Hi Liudvikas, Thank you very much for your feedback. On Mar 23, 2011, at 4:56 PM, Liudvikas Bukys wrote:
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. Kind regards, Nathalie Trenaman RIPE NCC Trainer
-----Original Message----- From: Nathalie Trenaman [mailto:nathalie@ripe.net] Sent: Wednesday, March 16, 2011 5:05 AM To: nanog@nanog.org Subject: Creating an IPv6 addressing plan for end users
Hi all,
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:
http://bit.ly/IPv6addrplan (PDF)
I look forward to your feedback, tips and comments.
With kind regards,
Nathalie Trenaman RIPE NCC Trainer
On Mar 24, 2011, at 1:06 AM, Nathalie Trenaman wrote:
Hi Liudvikas,
Thank you very much for your feedback.
On Mar 23, 2011, at 4:56 PM, Liudvikas Bukys wrote:
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.
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). Owen
On 3/23/11 6:14 AM, Hammer wrote:
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. http://www.verizonbusiness.com/Products/networking/internet/ipv6/policy.xml is one such example of a transit provider that will carry longer prefixes internally.
-Hammer-
"I was a normal American nerd." -Jack Herer
On Wed, Mar 16, 2011 at 1:52 PM, Schiller, Heather A < heather.schiller@verizonbusiness.com> wrote:
For those who don't like clicking on random bit.ly links:
http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6 _addr_plan4.pdf
--Heather
-----Original Message----- From: Nathalie Trenaman [mailto:nathalie@ripe.net] Sent: Wednesday, March 16, 2011 5:05 AM To: nanog@nanog.org Subject: Creating an IPv6 addressing plan for end users
Hi all,
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:
http://bit.ly/IPv6addrplan (PDF)
I look forward to your feedback, tips and comments.
With kind regards,
Nathalie Trenaman RIPE NCC Trainer
participants (6)
-
Hammer -
Joel Jaeggli -
Liudvikas Bukys -
Nathalie Trenaman -
Owen DeLong -
Schiller, Heather A