Browse All Articles > IPv6 allocation, assignments and management
A few months ago I attended the Rocky Mountain IPv6 Summit which was a two-day educational event; it was the 3rd annual conference held here in Denver, Colorado that was held at the Hyatt Regency Denver at the Colorado Convention Center. It was an eventful conference with many outstanding speakers: John Curran, Shannon McFarland, Scott Hogg, Chuck Sellers, Danny McPherson, and many others.
The President and CEO of ARIN made it very clear:
As of this writing, we are down to 6 percent of the /8 IANA unallocated address pool. The projected RIR unallocated address pool is expected to be exhausted by March 3rd of 2012. What you might not know is that today, there are organizations attempting to reach your mail, web, and Internet facing applications via IPv6. The Time is Now to get acquainted with IPv6; it is being implemented along the side with IPv4 (Dual Stack) in most carrier infrastructure and ISP markets. IPv6 has been discussed and analyzed for many years now. The time has come where it can no longer be ignored and large service providers such as Comcast acknowledge the need to begin the long and delicate transition to a full IPv6 model; Comcast is currently beta testing phases for the residential and commercial market and is already running IPv6 on their backbone; Many of the Tier1 networks have already implemented or is currently in the process of rolling out IPv6 on their backbones: Level3, NTT, and Qwest.
When the time does come that your organization must implement IPv6, one of the many steps in planning and implementing IPv6 in your network is allocating and assigning IPv6 addresses to layer 3 interfaces (Switches[vlan management interfaces], Routers, Firewalls, Hosts, etc.). IPv6 addresses should be organized into a hierarchical structure, consisting of a public topology, a site topology, and interface identifiers. The information contained in this document is nothing more than work experience and what makes sense to me after many hours of reviewing many RFC's. mailing lists, blogs, and forums. The information that I am providing is a collection of the information to help you decide on your IPv6 addressing plan.
Definitions:
Allocation - To set aside address space to customers (internal and external) for the purpose of subsequent distribution by them.
Customer/End-user - Is a subscriber who has some type of business relationship with an ISP; this can also include internal services to the ISP such as DNS, LDAP, MAIL. Typically, you will setup your internal services as a customer (Mail, DNS, Managed Hosting,etc.).
One of the imperative requirements that should be molded into your policies for allocating and assigning is that there should be absolute uniqueness Internet-wide. With that being said, you should also consider whenever possible that the address space that you allocate and assign be distributed in a hierarchical manner to ensure that route aggregation limits the explosion of the Internet routing tables.
The exact size of the assignment is a local decision for the LIR (ISP) to make, using a minimum value of a /64 up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified.
/64 - when it is known that one and only one subnet is needed
- Typically servers, hosts, or devices that are connected only to one subnet.
/56 - for small sites (no more than 256 Subnets), those expected to need only a few subnets over the next 5 years.
- Possibly DSL/Cable customers
- Assuming 4 bit boundary, your option for subnetting is /60 subnets
- 16 /60 2^4 = 16
/48 - for any customer (End-User and typically assigned by an LIR [ISP])
1. If you are a end-user reading this, then you will more than likely be assigned /48.
- 65536 /64 prefixes
- If you are planning to subnet the /48, assuming 8 bits borrowed, then this will give you 256 /56 prefixes.
- Each /56 will give you 256 /64 prefixes
- This is plenty of room to play with, without having to sacrifice much.
- The funny thing with ipv6 is, subnetting is the same as it was for IPv4
- You have a /48; this gives you 16 bits to subnet
- I recommend that you try and plan on 4 bit boundaries
- Suppose you you have 6 remote sites, and you want to plan for growth of up to 15 sites
- As in ipv4, if you wanted to have 15 sites, you would need at least to borrow 5 bits (2^4 = 16)
- This will give you 16 /52 prefixes which will allow 4096 /64 prefixes per /52.
2. Go with what works for you.
3. Do not worry about VLSM
/32 - minimum allocation from an RIR
- /36 - /40 POPs ([16 /36 prefixes] or [256 /40 prefixes]
- /44 for larger POPs
There have been some heated debates/discussions on the subject of IPv6 address conservation; does it makes sense to assign a /64 to point-to-point links? In some cases based on RFC documents and other sources, there are some contradictions which will leave you in a confused state on that matter; IPv6 address space is a exceptionally large pool of addresses. One thing to keep in mind is that the goal is in trying to be in the best position in the future; mainly it's about trying to avoid unexpected and future renumbering/change of prefix length costs.
Steve Leibson takes a shot at putting it in real world terms:3,374,607,431,768,211,456 to 18,446,744,073,709,551,616. In all honestly, if you are a large network, then you were more than likely allocated a /32 which only gives you a 8-16 bit improvement (16 bit improvement if all you assign are /48s). Once you start planning a practical address plan, the IPv6 allocation that you were assigned is not that big; nothing more than a class B from the v4 land. So all this hype about how large IPv6 is just a far cry, because the truth of the matter is that we will find a way to deplete this so called large IPv6 address space.
So if you run out, you can just ask for more right? Sure if you follow the guidelines, per the ARIN IPv6 Address Allocation and Assignment Policy section 5.4.1 it is justified; however, you should not have to ask for more if you manage your IP addresses so that they are scalable enough so that you do not have to keep on going back and asking for more IPv6 space; this will allow you not to have to worry about your current /32, /48, or /64 allocation and continue to do more interesting things with your companies time.
Other Examples:
In RFC5375 Section 2.4.1 and 2.4.2
Assigning a /64 on point-to-point (P2P) links is very wasteful in my professional opinion; but again, going back to the analogy above, and what the RFCs plainly point out, based on design principles you can with no issues assign a /64 to point-to-point links. I will agree with some aspects of utilizing /64 prefixes on P2P links in that it is much simpler and less prone to error. With that being said, you are still left what is best practice and what should I follow. You as an engineer/architect will need to make the technical decision based on your current infrastructure and research. You will need to understand the ramifications should you decide not to implement /64 prefixes on P2P links (by reading and understanding RFC3627); if this is the case, plan to allocate a /64 and assign the longer prefix should something change in any future RFCs or IETF documents and/or specifications to IPv6 addressing.
Other organizations have have safely utilized /126s for point-to-point links; however, from my professional experience, I would utilized a /126 for P2P links.
Based on what RFC3627 describes and points out; here are some interesting notes taken from several mailing lists and forums regarding IPv6 address configurations on point-to-point links that might or might not help you come to a final decision.
/64
Pro:
1. Go by the book: Technically speaking, you should also take in consideration that this is the way IPv6 was designed; everything to the right of a /64 boundary is reserved for the host portion; RFC4291, section 2.5.1. "Interface Identifiers"
2. Security: Simpler for management and security implementations (ACLs and such).
A. Impossible to guess with 2^64 addresses
B. Reverse DNS on a bit boundary
Con:
1. Operational consideration: anything longer than a /64 there is a possibility of ping-pong on a p-t-p interface
2. Potentially allows for denial-of-service attacks on the routers on the link and that there are only 2 devices on a point to point link.
3. Features: Anything longer than a /64 should note the services provided by the universal/local bits and Mobile IPv6 Home-agents.
A. If you do not plan to use these services, you can safely make use of longer prefixes.
/112
Pro:
1. Standardization of 65535 possible addresses (Also becomes the universal edge interface).
2. Reverse DNS on a bit boundary
3. A /112 is only 16,384 times less efficient than a /126, but is still 281,474,976,710,656 times
more efficient than a /64
A. 1st /112 for loopbacks and 2nd /112 for P2P links
Con:
1. Does not follow the design of IPv6 per RFC4291, section 2.5.1. "Interface Identifiers".
/120
Pro:
1. Easy to remember addresses:
2001:170:C19C::0/120
2001:170:C19C::100/120
2001:170:C19C::200/120
2001:170:C19C::300/120
....
2. On bit boundary
3. One solution from RFC3627, section 4.3 Solutions
4. No conflicts with the reserved anycast address bits (/121 - /126)
Con:
1. Does not follow the design of IPv6 per RFC4291, section 2.5.1. "Interface Identifiers" / RFC3587 Section 3. Address Format
2. With each /64 the highest 128 interface identifier values are reserved for assignment as subnet anycast addresses.
/126
Pro:
1. Using EUI-64 addresses on router-router links is just silly
2. A /126 can be used safely on a point-to-point link (In v4 land, this is similar to a /30)
3. /64 block will last much much longer
A. However, from a infrastructure perspective, there are a lot less of point to point links
Con:
1. Does not follow the design of IPv6 per RFC4291, section 2.5.1. "Interface Identifiers" / RFC3587 Section 3. Address Format
2. Not on bit boundary so it is a bit more complicated to implement reverse DNS and ACLs.
3. With each /64 the highest 128 interface identifier values are reserved for assignment as subnet anycast addresses.
A. Read more: http://www.faqs.org/rfcs/rfc2526.html#ixzz0nlYPD300
/127
Pro:
1. None
Con:
1. Does not make sense from my point of view in the utilizing this prefix as it can possibly break DAD, also note that the Subnet-router anycast address is used. As it is a mandated feature (DAD), I felt that using the /127 on P2P links was not a good idea.
2. Not on bit boundary so it is a bit more complicated to implement reverse DNS and ACLs.
http://iptrack.sourceforge.net/
There are commercial tools, but they are packaged for other protocols as well (DHCP, DNS, TFTP, etc), it is nice to have all that integrated, but for the business I am in, the other services and protocols are just not in the business case:
http://btdiamondip.com/products/IPAM_Software/
http://www.bluecatnetworks.com/
http://www.infoblox.com/solutions/ip-address-management.cfm
In the end you will most very likely want to write the IP address management software yourself for the simple reason of integration.
The President and CEO of ARIN made it very clear:
"As we dip below the 10% mark for available IPv4 resources, it has become more vital for all organizations to implement IPv6 before time runs out"
As of this writing, we are down to 6 percent of the /8 IANA unallocated address pool. The projected RIR unallocated address pool is expected to be exhausted by March 3rd of 2012. What you might not know is that today, there are organizations attempting to reach your mail, web, and Internet facing applications via IPv6. The Time is Now to get acquainted with IPv6; it is being implemented along the side with IPv4 (Dual Stack) in most carrier infrastructure and ISP markets. IPv6 has been discussed and analyzed for many years now. The time has come where it can no longer be ignored and large service providers such as Comcast acknowledge the need to begin the long and delicate transition to a full IPv6 model; Comcast is currently beta testing phases for the residential and commercial market and is already running IPv6 on their backbone; Many of the Tier1 networks have already implemented or is currently in the process of rolling out IPv6 on their backbones: Level3, NTT, and Qwest.
When the time does come that your organization must implement IPv6, one of the many steps in planning and implementing IPv6 in your network is allocating and assigning IPv6 addresses to layer 3 interfaces (Switches[vlan management interfaces], Routers, Firewalls, Hosts, etc.). IPv6 addresses should be organized into a hierarchical structure, consisting of a public topology, a site topology, and interface identifiers. The information contained in this document is nothing more than work experience and what makes sense to me after many hours of reviewing many RFC's. mailing lists, blogs, and forums. The information that I am providing is a collection of the information to help you decide on your IPv6 addressing plan.
Definitions:
Allocation - To set aside address space to customers (internal and external) for the purpose of subsequent distribution by them.
Internal customer: For your internal infrastructure (core, distribution and access layer devices).
External customer: The participants that you are providing services for (end-users).
Assignment - To delegate address space to customers, for the specific use of the Internet infrastructure they operate.
Customer/End-user - Is a subscriber who has some type of business relationship with an ISP; this can also include internal services to the ISP such as DNS, LDAP, MAIL. Typically, you will setup your internal services as a customer (Mail, DNS, Managed Hosting,etc.).
One of the imperative requirements that should be molded into your policies for allocating and assigning is that there should be absolute uniqueness Internet-wide. With that being said, you should also consider whenever possible that the address space that you allocate and assign be distributed in a hierarchical manner to ensure that route aggregation limits the explosion of the Internet routing tables.
The exact size of the assignment is a local decision for the LIR (ISP) to make, using a minimum value of a /64 up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified.
Prefix Allocations
The following information may be useful (These are only guidelines!) Take DNS into consideration on assignments; making assignments on 4bit boundaries (makes life much more simpler):/64 - when it is known that one and only one subnet is needed
- Typically servers, hosts, or devices that are connected only to one subnet.
/56 - for small sites (no more than 256 Subnets), those expected to need only a few subnets over the next 5 years.
- Possibly DSL/Cable customers
- Assuming 4 bit boundary, your option for subnetting is /60 subnets
- 16 /60 2^4 = 16
/48 - for any customer (End-User and typically assigned by an LIR [ISP])
1. If you are a end-user reading this, then you will more than likely be assigned /48.
- 65536 /64 prefixes
- If you are planning to subnet the /48, assuming 8 bits borrowed, then this will give you 256 /56 prefixes.
- Each /56 will give you 256 /64 prefixes
- This is plenty of room to play with, without having to sacrifice much.
- The funny thing with ipv6 is, subnetting is the same as it was for IPv4
- You have a /48; this gives you 16 bits to subnet
- I recommend that you try and plan on 4 bit boundaries
- Suppose you you have 6 remote sites, and you want to plan for growth of up to 15 sites
- As in ipv4, if you wanted to have 15 sites, you would need at least to borrow 5 bits (2^4 = 16)
- This will give you 16 /52 prefixes which will allow 4096 /64 prefixes per /52.
2. Go with what works for you.
3. Do not worry about VLSM
/32 - minimum allocation from an RIR
- /36 - /40 POPs ([16 /36 prefixes] or [256 /40 prefixes]
- /44 for larger POPs
There have been some heated debates/discussions on the subject of IPv6 address conservation; does it makes sense to assign a /64 to point-to-point links? In some cases based on RFC documents and other sources, there are some contradictions which will leave you in a confused state on that matter; IPv6 address space is a exceptionally large pool of addresses. One thing to keep in mind is that the goal is in trying to be in the best position in the future; mainly it's about trying to avoid unexpected and future renumbering/change of prefix length costs.
Steve Leibson takes a shot at putting it in real world terms:
So we could assign an IPV6 address to EVERY ATOM ON THE SURFACE OF THE EARTH, and still have enough addresses left to do another 100+ earths. It isn't remotely likely that we'll run out of IPV6 addresses at any time in the futureThe point being is that this analogy is simply to show that there are an awful lot of addresses and that you should not be too concerned with conserving address space; however, this is to be taken with a grain of salt. I would highly recommend that your address policies should avoid the assignments in a unnecessarily wasteful fashion because it does start to deteriorate from 2^128 to 2^64 (from 340,282,366,920,938,463,46
So if you run out, you can just ask for more right? Sure if you follow the guidelines, per the ARIN IPv6 Address Allocation and Assignment Policy section 5.4.1 it is justified; however, you should not have to ask for more if you manage your IP addresses so that they are scalable enough so that you do not have to keep on going back and asking for more IPv6 space; this will allow you not to have to worry about your current /32, /48, or /64 allocation and continue to do more interesting things with your companies time.
Other Examples:
In RFC5375 Section 2.4.1 and 2.4.2
"Address conservation requirements are less stringent in IPv6, but they should still be observed."
In RFC5375 B.2. Considerations for Subnet Prefixes Longer than /64
"The following subsections describe subnet prefix values that should be avoided - B.2.1. /126 Addresses"
In RFC3177 Section 3 (Address Delegation Recommendations)
"/64 when it is known that one and only one subnet is needed by design."
http://www.getipv6.info/index.php/IPv6_Addressing_Plans - Point 10.
"IETF expects that you will assign a /64 for point-to-point links"
Assigning a /64 on point-to-point (P2P) links is very wasteful in my professional opinion; but again, going back to the analogy above, and what the RFCs plainly point out, based on design principles you can with no issues assign a /64 to point-to-point links. I will agree with some aspects of utilizing /64 prefixes on P2P links in that it is much simpler and less prone to error. With that being said, you are still left what is best practice and what should I follow. You as an engineer/architect will need to make the technical decision based on your current infrastructure and research. You will need to understand the ramifications should you decide not to implement /64 prefixes on P2P links (by reading and understanding RFC3627); if this is the case, plan to allocate a /64 and assign the longer prefix should something change in any future RFCs or IETF documents and/or specifications to IPv6 addressing.
Other organizations have have safely utilized /126s for point-to-point links; however, from my professional experience, I would utilized a /126 for P2P links.
Based on what RFC3627 describes and points out; here are some interesting notes taken from several mailing lists and forums regarding IPv6 address configurations on point-to-point links that might or might not help you come to a final decision.
The most common prefixes are: /64 and /126; One recipe: Customers should "Never" get allocated anything longer than a /64.
/64
Pro:
1. Go by the book: Technically speaking, you should also take in consideration that this is the way IPv6 was designed; everything to the right of a /64 boundary is reserved for the host portion; RFC4291, section 2.5.1. "Interface Identifiers"
2. Security: Simpler for management and security implementations (ACLs and such).
A. Impossible to guess with 2^64 addresses
B. Reverse DNS on a bit boundary
Con:
1. Operational consideration: anything longer than a /64 there is a possibility of ping-pong on a p-t-p interface
2. Potentially allows for denial-of-service attacks on the routers on the link and that there are only 2 devices on a point to point link.
3. Features: Anything longer than a /64 should note the services provided by the universal/local bits and Mobile IPv6 Home-agents.
A. If you do not plan to use these services, you can safely make use of longer prefixes.
/112
Pro:
1. Standardization of 65535 possible addresses (Also becomes the universal edge interface).
2. Reverse DNS on a bit boundary
3. A /112 is only 16,384 times less efficient than a /126, but is still 281,474,976,710,656 times
more efficient than a /64
A. 1st /112 for loopbacks and 2nd /112 for P2P links
Con:
1. Does not follow the design of IPv6 per RFC4291, section 2.5.1. "Interface Identifiers".
/120
Pro:
1. Easy to remember addresses:
2001:170:C19C::0/120
2001:170:C19C::100/120
2001:170:C19C::200/120
2001:170:C19C::300/120
....
2. On bit boundary
3. One solution from RFC3627, section 4.3 Solutions
4. No conflicts with the reserved anycast address bits (/121 - /126)
Con:
1. Does not follow the design of IPv6 per RFC4291, section 2.5.1. "Interface Identifiers" / RFC3587 Section 3. Address Format
2. With each /64 the highest 128 interface identifier values are reserved for assignment as subnet anycast addresses.
/126
Pro:
1. Using EUI-64 addresses on router-router links is just silly
2. A /126 can be used safely on a point-to-point link (In v4 land, this is similar to a /30)
3. /64 block will last much much longer
A. However, from a infrastructure perspective, there are a lot less of point to point links
Con:
1. Does not follow the design of IPv6 per RFC4291, section 2.5.1. "Interface Identifiers" / RFC3587 Section 3. Address Format
2. Not on bit boundary so it is a bit more complicated to implement reverse DNS and ACLs.
3. With each /64 the highest 128 interface identifier values are reserved for assignment as subnet anycast addresses.
A. Read more: http://www.faqs.org/rfcs/rfc2526.html#ixzz0nlYPD300
/127
Pro:
1. None
Con:
1. Does not make sense from my point of view in the utilizing this prefix as it can possibly break DAD, also note that the Subnet-router anycast address is used. As it is a mandated feature (DAD), I felt that using the /127 on P2P links was not a good idea.
2. Not on bit boundary so it is a bit more complicated to implement reverse DNS and ACLs.
IPv6 Management:
Whether you like it or not, IPv6 is coming to a router near you. And if you thought address management was a headache for IPv4, hold on to your hats! As many readers may know, I am very fond of open source software. I have yet to locate a decent open source solution for a IPAM (IP Address Management); however, I have found one that just works:http://iptrack.sourceforge.net/
There are commercial tools, but they are packaged for other protocols as well (DHCP, DNS, TFTP, etc), it is nice to have all that integrated, but for the business I am in, the other services and protocols are just not in the business case:
http://btdiamondip.com/products/IPAM_Software/
http://www.bluecatnetworks.com/
http://www.infoblox.com/solutions/ip-address-management.cfm
In the end you will most very likely want to write the IP address management software yourself for the simple reason of integration.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (1)
Commented:
https://www.cheap-essay-writing.co.uk/assignments-writing-services-uk/