IPv6 Global Unicast Address Assignments
IPv6 prefix assignment BCOP published as RIPE-690
RIPE-690 outlines best current operational practices for the assignment of IPv6 prefixes (i.e. a block of IPv6 addresses) for end-users, as making wrong choices when designing an IPv6 network will eventually have negative implications for deployment and require further effort such as renumbering when the network is already in operation. In particular, assigning IPv6 prefixes longer than /56 to residential customers is strongly discouraged, with /48 recommended for business customers. This will allow plenty of space for future expansion and sub-netting without the need for renumbering, whilst persistent prefixes (i.e. static) should be highly preferred for simplicity, stability and cost reasons.
The target audience of RIPE-690 is technical staff working in ISPs and other network operators who currently provide or intend to provide IPv6 services to residential or business end-users. Up until now, there have been no clear recommendations on how to assign IPv6 prefixes to customers, and a variety of different and sometimes problematic solutions have been implemented.
By bringing together subject matter experts with practical deployment experience, it’s been possible to identify common practices and problems, and provide recommended solutions to some of the more commonly encountered issues.
The authors of the document were Jan Žorž, Sander Steffann, Primož Dražumerič, Mark Townsley, Andrew Alston, Gert Doering, Jordi Palet, Jen Linkova, Luis Balbinot, Kevin Meynell and Lee Howard. Other contributors were Nathalie Kunneke-Trenaman, Mikael Abrahamsson, Jason Fesler, Martin Levy, Ian Dickinson, Philip Homburg, Ivan Pepelnjak, Matthias Kluth, Ondřej Caletka, Nick Hilliard, Paul Hoffman, Tim Chown, Nurul Islam, Yannis Nikolopoulos and Marco Hogewoning.
The document was submitted to the RIPE BCOP Task Force and then to the RIPE IPv6 Working Group , as part of the Internet community feedback and consensus building process. Thanks should go the Chairs of those groups who ensured the recommendations do conform with actual best operational practice, along with the RIPE NCC staff who facilitated the publishing process.
So now there are some agreed stable recommendations for IPv6 prefix assignment for end-users, we’d ask all network operators to read and consider the document when deploying IPv6 to your customers.
And as always, please visit Deploy360’s Start Here page to find resources on how to get started with IPv6.
Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.
Recent Posts
- Misguided Policies the World over Are Slowly Killing the Open Internet
- What is Section 230 and Why Should I Care About It?
- NDSS Symposium 2023: 30 Years of Cutting Edge Network Security Research
- In One Corner, Large Telecom Operators. In the Other, Everybody Else.
- Building, Expanding and Securing the Internet: Two Funding Programs Now Open for Applications
Related articles
Dns privacy frequently asked questions (faq).
We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...
Introduction to DNS Privacy
Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...
IPv6 Security for IPv4 Engineers
It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...
IPv6 General Prefix
The upper 64 bits of an IPv6 prefix usually consists of a /48 global routing prefix (or site prefix) and the remaining 12 bits are used for more specific prefixes (the subnet). This is explained in detail in the following lesson:
IPv6 address assignment
The IPv6 general (or generic) prefix feature lets you renumber a global prefix on your router or switch. This is a simple but pretty useful feature.
For example, let’s say we have the following global prefix:
- 2001:41f0:4060::/48
And we use the following specific prefixes:
- 2001:41f0:4060:0001::/64
- 2001:41f0:4060:0002::/64
- 2001:41f0:4060:0003::/64
- 2001:41f0:4060:0004::/64
You can configure these prefixes manually on your interfaces but once your global prefix changes, you have to manually reconfigure your IPv6 addresses. With the IPv6 general prefix feature, we can do this automatically.
Configuration
To demonstrate this, I’ll use a router with four interfaces. On each interface, I’ll use the global prefix and specific prefixes from above.
We configure the global prefix with the ipv6 general-prefix command. You can use whatever name you want, I’ll name mine “GLOBAL”:
On the interfaces, we configure an IPv6 address and refer to the general prefix. You have to specify a full IPv6 address, the first 48 bits will be replaced by the general prefix. I’ll use zeroes for the global prefix:
Let’s see what prefixes we ended up with:
This is looking good. You can see we have four prefixes and the global prefix is 2001:41F0:4060.
Let’s see if we can change our global prefix without manually reconfiguring each interface. I’ll use the ipv6 general prefix command again to use a different global prefix:
We're Sorry, Full Content Access is for Members Only...
If you like to keep on reading, Become a Member Now! Here is why:
- Learn any CCNA, CCNP and CCIE R&S Topic . Explained As Simple As Possible.
- Try for Just $1 . The Best Dollar You’ve Ever Spent on Your Cisco Career!
- Full Access to our 758 Lessons . More Lessons Added Every Week!
- Content created by Rene Molenaar (CCIE #41726)
648 Sign Ups in the last 30 days
Tags: Design
Forum Replies
Hi Rene and staff, just a typo in the first stanza: it is 16 bits instead 12 bits, is not it ?
But my question is about the way to change general-prefix The lesson use the no form to suppress manually the old general-prefix So i wonder
- can R1 configure a validtime for a general-prefix, then it could be suppressed automatically ?
- can the ISP router give a validtime for the general prefix that R1 could interpret ? In the router advertisement message format i dont find any field for transmitting this information neither in option. Could a DHCPv6 option do this ?
Hello Dominique
The specific general-prefix feature is one that functions statically. There are no parameters in which you can configure time sensitive validity of the prefix itself. However, if you do want to achieve this, there are a couple of ways that come to mind.
You can use IPv6 DHCPv6 Prefix Delegation which allows for a DHCPv6 server to provide the general prefix to the customer routers, which in turn provide the specific IPv6 addresses based on those general prefixes. These prefixes can be changed and advertised using DHCPv6 rather than using the s
thanks a lot LAZ, i will do a lab to test the EEM solution (and if i succeed i will do a post) I accept also the solution with device programmability although i need to dive deeper in network programmability to config this type of solution
https://cdn-forum.networklessons.com/uploads/default/original/2X/7/77ed1f834fcb08fee0d3908970e4447e96068ef4.png
It has to change C1’s binding with a given value for some reason; for example 1100 has to
The idea behind my mentioning Prefix Delegation was the fact that using DHCPv6, the ISP could indeed change the prefix that is provided to each individual customer whenever they would like. They can do it manually, but they can also set a valid-lifetime and a preferred-lifetime. The command would be issued like so:
prefix-delegation pool poolname [ lifetime valid-lifetime preferred-lifetime ]
Notice this context sensitive help:
Ask a question or join the discussion by visiting our Community Forum
Configuring IPv6 prefix assignment
About ipv6 prefix assignment.
Use the following methods to configure IPv6 prefix assignment:
Configure a static IPv6 prefix binding in an address pool —If you bind a DUID and an IAID to an IPv6 prefix, the DUID and IAID in a request must match those in the binding before the DHCPv6 server can assign the IPv6 prefix to the DHCPv6 client. If you only bind a DUID to an IPv6 prefix, the DUID in the request must match the DUID in the binding before the DHCPv6 server can assign the IPv6 prefix to the DHCPv6 client.
Apply a prefix pool to an address pool —The DHCPv6 server dynamically assigns an IPv6 prefix from the prefix pool in the address pool to a DHCPv6 client.
Restrictions and guidelines
When you configure IPv6 prefix assignment, follow these restrictions and guidelines:
An IPv6 prefix can be bound to only one DHCPv6 client. You cannot modify bindings that have been created. To change the binding for a DHCPv6 client, you must delete the existing binding first.
One address pool can have only one prefix pool applied. You cannot modify prefix pools that have been applied. To change the prefix pool for an address pool, you must remove the prefix pool application first.
You can apply a prefix pool that has not been created to an address pool. The setting takes effect after the prefix pool is created.
Enter system view.
system-view
(Optional.) Specify the IPv6 prefixes excluded from dynamic assignment.
ipv6 dhcp server forbidden-prefix start-prefix/prefix-len [ end-prefix/prefix-len ]
By default, no IPv6 prefixes in the prefix pool are excluded from dynamic assignment.
If the excluded IPv6 prefix is in a static binding, the prefix still can be assigned to the client.
Create a prefix pool.
ipv6 dhcp prefix-pool prefix-pool-number prefix { prefix-number | prefix/prefix-len } assign-len assign-len
This step is required for dynamic prefix assignment.
If you specify an IPv6 prefix by its ID, make sure the IPv6 prefix is in effect. Otherwise, the configuration does not take effect.
Enter DHCP address pool view.
ipv6 dhcp pool pool-name
Specify an IPv6 subnet for dynamic assignment.
network { prefix/prefix-length | prefix prefix-number [ sub-prefix/sub-prefix-length ] } [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ]
By default, no IPv6 subnet is specified for dynamic assignment.
The IPv6 subnets cannot be the same in different address pools.
Configure the prefix assignment. Choose the options to configure as needed:
Configure a static prefix binding:
static-bind prefix prefix/prefix-len duid duid [ iaid iaid ] [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ]
By default, no static prefix binding is configured.
To add multiple static IPv6 prefix bindings, repeat this step.
Apply the prefix pool to the address pool:
prefix-pool prefix-pool-number [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ]
By default, static or dynamic prefix assignment is not configured for an address pool.
© Copyright 2015, 2017 Hewlett Packard Enterprise Development LP
IPv6 Prefix Assignment in Small Networks draft-baker-homenet-prefix-assignment-00
It is necessary to allocate prefixes in small networks, which include residential and Small Office/Home Office (SOHO) networks in a manner that minimizes or eliminates manual configuration. This note suggests an approach.
Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] .
Status of this Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 06, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. introduction, 2. scope of this document, 3. simple tree network case, 3.1. assignment of prefxies in a simple network, 3.1.1. cpe router behavior, 3.1.2. interior router behavior, 3.1.2.1. network with a tree topology, 3.1.2.2. non-tree topologies, 3.1.2.3. multi-homed network, 4. issues in a simple cascade procedure, 4.1. sequence of subnet number allocation, 4.2. multihoming issues, 4.3. race conditions, 4.4. scaling issues, 4.5. prefix stability, 4.6. when you run out of prefixes, 5. router advertisement allocator information element, 6. iana considerations, 7. security considerations, 7.1. privacy considerations, 8. change log, 9. references, 9.1. normative references, 9.2. informative references, authors' addresses.
One of the objectives of the design of IPv6 [RFC2460] has been to reduce or minimize the need for manual configuration in networks. IPv4 [RFC0791] networks, when it became widely deployed in the 1980's, required manual configuration, and the scaling limits of the approach quickly became apparent. One of the outcomes of that was the Dynamic Host Configuration Protocol [RFC2131] (DHCP), which facilitated central administration of desktop computers. In practice, DHCP itself has been of limited utility in the administration of network equipment; while it is conceptually possible to use it for any kind of configuration, more flexible protocols such as the Network Configuration Protocol [RFC6241] [RFC6242] have been preferred.
Allocation of prefixes in small networks calls for an approach that can be completely automated. This note documents a procedure that has been suggested by several. It builds on a few basic assumptions:
- IPv6 prefixes are allocated to a small network by one or more upstream service providers using [RFC3315] and [RFC3363] .
- IPv6 prefixes may allocated to LAN within a small network by the CPE Router using [RFC3315] and [RFC3363] .
- Occasional inefficiencies such as allocating two /64s to a LAN from a given upstream prefix are acceptable, especially if short-lived.
- Small networks, such as described in Home Networking Architecture for IPv6 [I-D.chown-homenet-arch] , are simple enough in structure that the mechanism described in this note is adequate.
These assumptions bear analysis. The first two, that prefixes can and may be allocated using mechanisms designed for the purpose, seems self-evident. The third builds on the IPv6 premise that a host may have more than one prefix on an interface and one or more addresses in each prefix; in such a case, while it may be suboptimal to allocate more than one /64 from the same upstream prefix, the hosts will not complain and the routing protocols will route them. The fourth may be considered the limit of applicability; if a network requires a prefix aggregation design or is otherwise too complex for this procedure to be effective, other procedures are more appropriate.
This document describes a procedure for prefix delegation and assignment. It results in the assignment of a series of /64 prefixes on the links in a small home network.
While this document describes the use of DHCPv6 for prefix delegation, specification of the use of DHCPv6 for address assignment and other purposes is out of scope.
If a network includes interior routers and the CPE router is not directly to all of the links in the network, the routers in the network will need routing information to forward traffic in the network and between the network and the service provider network. The specification of a routing protocol or other mechanism to provide that routing information to the routers is beyond the scope of this document.
The first case to describe is that of a network with a simple tree topology. In this network, there is a single CPE router attached to a single SP network. The interior of the network is organized as a tree. Each interior router has one "upstream" interface and one or more "downstream" interfaces. Each link in the network has a single interior router with a downstream interface attached and zero or more interior routers with an upstream interface attached.
The fundamental procedure for prefix allocation takes three phases:
- Allocating a prefix from the upstream network,
- Prefix allocation by the CPE Router, and
- Prefix allocation by a subsequent router.
This section describes the assignment of prefixes in a simple network. The network is assumed to be tree-structured, including one CPE router that is connected to a SP network and one or more interior routers. The interior routers each have a single "upstream" interface and one or more "downstream" interfaces. The upstream interface of each interior router is connected to a link in the network to which a downstream interface of a router closer to the CPE router is already connected.
The CPE router obtains a delegated prefix for the entire home network, and manages prefix allocations for all of the interior routers. Each interior router uses DHCPv6 on its upstream interface to obtain delegated prefixes from the CPE router for each of the interior routers downstream interfaces.
The CPE router obtains a delegated prefix from the SP provisioning system using [RFC3315] and [RFC3363] and other appropriate provisioning systems. The prefix delegated from the service provider includes a preferred and valid lifetime for the prefix.
Once the CPE router has received a delegated prefix, it assigns a /64 subprefix to each of the links to which the router is attached. The CPE router configures an address to each of its interfaces from the prefix assigned to the link to which the interface is attached. After assigning the interface addresses, the CPE router begins sending Router Advertisement (RA) messages [RFC4861] advertising the appropriate prefix on each attached link.
The CPE router includes a Router Advertisement Allocator Information (RAAI) option, identifying itself as the allocating server for prefixes related to the prefix announced in the RA. The RAs include preferred and valid lifetimes derived from the lifetimes associated with the delegated prefix from the service provider. The RA also advertises the CPE router as the default router for the link. Other fields in the RAs are set as appropriate.
At this point, the links to which the CPE router is attached is now provisioned with prefixes taken from the prefix obtained from the service provider. The CPE router uses ongoing DHCPv6 messages exchanges according to [RFC3315] and [RFC3363] to maintain and update its delegated prefix.
The CPE router uses a DHCPv6 server for prefix subdelegation throughout the rest of the network. In preparation for assigning prefixes to links in the rest of the network, the CPE router makes all of the remaining prefixes from the network prefix available for subdelegation through a DHCPv6 server. The CPE router configures the preferred and valid lifetimes for the subdelegated prefixes from the values received from the service provider.
When an interior router is connected to the home network, its upstream interface is attached to a link in the home network, and its downstream interfaces are connected to other links to be added to the home network.
After the upstream interface is attached to a link, the interior router listens for RAs on the upstream interface and configures the upstream interface according to the information contained in the received RAs.
When the interior router receives an RA with an RAAI option, the router initiates a DHCPv6 message exchange to obtain prefixes from the prefix managed by the allocating router. The interior router requests the delegation of a separate /64 prefix for each of its downstream interfaces. The DHCPv6 service in the home network delivers the DHCPv6 traffic between the interior router and the CPE router.
The CPE router delegates the requested prefixes from the prefix delegated to the network. The interior router then assigns a prefix to each link attached to which a downstream interface is attached, configures those downstream interfaces with addresses from the assigned prefixes and begins sending RAs on the downstream interfaces. The interior router includes an RAAI option in the RAs, indentifying the CPE router as the allocating DHCPv6 server. The preferred and valid lifetimes for the advertised prefix are derived from the lifetimes in the DHCPv6 delegation, and the RAs advertise the interior router as the default router for the link.
It is quite likely that real world deployments will violate the assumption in the previous section that only one downstream interface will be attached to each link in the home network. In this situation, it is desirable that the link only be assigned one prefix and, therefore, only one of the interior routers with a downstream interface on the link be responsible for assigning a prefix and sending RAs on the link.
To avoid duplicate address assignment, a router first listens for RAs on the link attached to its downstream interface. If the router does not receive an RA after listening for INTERVAL1 microfortnights, the router assumes it is responsible for assigning a prefix to that link and initiates the DHCPv6 process for obtaining a delegated prefix.
After the router determines it is responsible for the link attached to its downstream interface, it continues to listen for RAs from other routers on the link. If it receives an RA from another router, it deassigns its delegated prefix from the link, unconfigures any addresses assigned from that prefix and releases the delegated prefix to the CPE router using DHCPv6.
If a router hears an RA such as described in Section 3.1.2 , it uses IPv6 Stateless Address Autoconfiguration [RFC4862] [RFC4941] or a DHCPv6 [RFC3315] request to each announced allocator to generate an address within the prefix for use in that subnet.
After the router determines that some other router is responsible for the link attached to its downstream interface, it continues to listen on the interface for RAs. If the router receives no RA on the interface for INTERVAL2 microfortnights, the router takes responsibility for the link and initiates the process described above to obtain and assign a prefix to the link.
If a network has multiple service provider networks, it will have multiple prefixes. This situation is easiest to describe if the network is connected to each service provider through a separate CPE router.
Each CPE router obtains a delegated prefix from its service provider and then manages the prefix according to the
First layer of interior router get multiple direct DHCPv6 prefixes. Assigns each prefix in parallel. Sets up DHCPv6 relay agent to point to each of the CPE routers.
Next layer receives DHCPv6 transaction from each CPE router because upstream router forwards DHCPv6 messages to each of the CPE routers.
There are a number of potential issues in this procedure.
Apart from cases in which the administration has chosen to fix a given subnet to a given LAN, such as to support server deployment in DNS, it is generally advised that subnet numbers be randomized. This is to make certain network attacks a little more difficult.
One issue is "what happens if one has multiple upstream networks with multiple CPE Routers and therefore multiple allocators?" The design of the RA information element announcing the allocator is intended to simplify that by announcing an allocator.
In the simplest case, there are no race conditions; the home has exactly one router, it obtains a prefix from its upstream network, and sub-allocates to its interfaces. If there are additional routers in the home, however, either there are one or more links that are not attached to the CPE Router or there are zero; in the event that there are one or more such links, they may be connected by one router or by multiple routers.
One race condition is when two interior routers are attached to the same LANs as the CPE. For example, one might have a wireless router in the home that connects both to the wired and the wireless network that the CPE Router is on. In such a case, it will hear and interpret one of the CPE Router's RAs first, and then the other some amount of time later. The purpose of the INTERVAL1 delay in Section 3.1.2 is to allow this race condition to stabilize before the router acts on this information it has.
A second race condition occurs when two "subsequent" routers are on the same LAN but it is not serviced by the CPE Router. These routers will both use the procedure of Section 3.1.2 to attempt to allocate a prefix to the LAN and so create a subnet. It is RECOMMENDED that the allocator allocate at most one prefix per INTERVAL2, ignoring all other requests, in order to allow the "subsequent" routers to sort out this class of race condition. If needed, ignored routers will re-request the allocation.
Due to the possibility of packet loss in the network, it is possible that these race conditions may result in a given LAN developing multiple subnets. While suboptimal, this is not a violation of the architecture and should cause no issues. However, in the event that two routers observe that they are announcing different subnets in the same upstream prefix on the same LAN, the one with the numerically least subnet number SHOULD NOT allow its prefix to expire, but any others SHOULD allow their prefixes to expire.
Obviously, use of this procedure in a complex network results in a serialization of prefix allocation that may take more time to settle than is operationally desirable (number of LANs times INTERVAL2). In such cases, the administration will have to decide how it wants to handle the issue. One approach would be to divide the network into easily-aggregated sections and use the procedure within each section; another would be to use a different procedure.
In such networks, the routers requesting prefixes can also act as a denial of service attack, by flooding the CPE Router with requests. Given that the procedure eventually terminates, this is undesirable but of limited duration.
In networks that contain servers or names that are announced in DNS, it is often valuable to have the same LAN always have the same subnet number applied to it. The procedure as described could accomplish that if the CPE Router maintains memory of what router it has allocated a given prefix to recently, or would fail to provide that if it does not. The distinction is essentially a marketing requirement that the implementation will need to decide for itself.
If a network runs out of subnet numbers and therefore subnet prefixes, this is considered a provisioning failure. It can result when multiple prefixes are allocated to the same LAN, which should be unusual and will end when one of the routers releases its prefix. It can also result when the upstream network allocates a prefix that is too long and as a result contains too few potential prefixes. In that case, the administration is forced to either reorganize its network or negotiate for a shorter prefix.
On a Neighbor Discovery RA, Section 3.1.2 and Section 3.1.2 call for the RA to identify the allocator that a "subsequent" router may use to request a related prefix for use on a different interface. This information element contains a list of the IPv6 addresses of one or more allocators, and an element length option to permit parsing of the information element.
In Section 5 , this note specifies an information element to be carried in the Router Advertisement message specified in Neighbor Discovery.
<TBD>
IPv6 prefix assignment
My LAN interface is assigned an address of XXXX:XXXX:XXXX:1300::1/56. I use prefix delegation to my downstream cisco L3 switch and another virtual router. Is there a way to make the LAN interface use XXXX:XXXX:XXXX:13FF::1/56 instead so I can free up XXXX:XXXX:XXXX:1300::/64 for use downstream?
Sure is, try adding option ip6hint 'FF' to your LAN interface settings in /etc/config/network and then restart your network service.
Actually, I re-read your question. Did you really intend to have /56 assigned to your LAN or /64? With my answer, I assumed /64 since /56 would not be possible.
I have to assign the /56 to the interface so prefix delegation works. The interface ends up with a /64 in reality but it allows for the prefix to be delegated out downstream on that interface. It's confusing I know but it does work. The ip6hint does not work in this manner. Lets say I only wanted to assign a /64 with no prefix delegation, then the hint would work but it leaves me with no downstream IP space.
Yeah, I’m not sure how to go about doing what you’re aiming for there.
the typical advice I've heard is that only the biggest organizations (universities, Microsoft, etc) should do hierarchical routing, and the usual thing should be to hand out /64 at the edge for anyone smaller than say 100 buildings. Are you sure you really need to hierarchically route, or could you reorganize your network concept to push that downstream subnet to the edge on VLANs?
These are very good questions. I'm a network engineer believe it or not lol. I have a VMware cluster set up at home and probably about 200 devices connected on my lan. Probably going to end up doing a network redesign but I don't think there is going to be any easy way out of prefix delegation because I need the layer 3 switch behind my openwrt router. I used Cisco routers in the past but they are no where near as flexible as openwrt.
Does it have to be :1300 ?? why not just request a /64 prefix and then use whatever you get from OpenWrt?
actually, I think what you want is to assign a /64 to LAN and use the ipv6 hint, and then the downstream router should do a PD request, and the openwrt will give it a different /64
I am not a network engineer. I also have not done what I think you are trying to do.
Setting aside those facts and what I suspect is the better advice from the other posters above, have you looked at wide-dhcpv6-server?
I use wide-dhcpv6-client on a DIY ubuntu router for prefix delegation but from the wide-dhcp documentation the server variant might do what you want. I don't see wide-dhcp as an openwrt package but a google search indicates others might have packaged it in the past. You would have to reproduce that and integrate it into openwrt yourself.
Before taking those steps, setting up an linux router to play with isn't too difficult and might be a better option just to see if you can get what you want. Then look at adapting something for openwrt (or look at pfsense).
Regardless, the above will be a bit of work but might be fun if your interested in it.
Wide was what I attempted to use first actually prior to openwrt. The wide implementation of dhcpv6 was bugged with my ISP. It would work after a reboot then around 24 hours out it just dropped all IPv6 address except for the WAN. Openwrt has ran solid nonstop for a couple years now. I'm fiddling around with requesting multiple /64 blocks from the openwrt router instead of a single /60 from the pool. As soon as the wife gets out of her raid, I'm gonna test it.
Well back to the drawing board. I'm sending multiple hints from the switch but only getting a single /64 back. Hard to say if its the switch or openwrt.
IPv6 Prefix Assignment in Small Networks draft-baker-homenet-prefix-assignment-00
It is necessary to allocate prefixes in small networks, which include residential and Small Office/Home Office (SOHO) networks in a manner that minimizes or eliminates manual configuration. This note suggests an approach.
Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] .
Status of this Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 06, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. introduction, 2. scope of this document, 3. simple tree network case, 3.1. assignment of prefxies in a simple network, 3.1.1. cpe router behavior, 3.1.2. interior router behavior, 3.1.2.1. network with a tree topology, 3.1.2.2. non-tree topologies, 3.1.2.3. multi-homed network, 4. issues in a simple cascade procedure, 4.1. sequence of subnet number allocation, 4.2. multihoming issues, 4.3. race conditions, 4.4. scaling issues, 4.5. prefix stability, 4.6. when you run out of prefixes, 5. router advertisement allocator information element, 6. iana considerations, 7. security considerations, 7.1. privacy considerations, 8. change log, 9. references, 9.1. normative references, 9.2. informative references, authors' addresses.
One of the objectives of the design of IPv6 [RFC2460] has been to reduce or minimize the need for manual configuration in networks. IPv4 [RFC0791] networks, when it became widely deployed in the 1980's, required manual configuration, and the scaling limits of the approach quickly became apparent. One of the outcomes of that was the Dynamic Host Configuration Protocol [RFC2131] (DHCP), which facilitated central administration of desktop computers. In practice, DHCP itself has been of limited utility in the administration of network equipment; while it is conceptually possible to use it for any kind of configuration, more flexible protocols such as the Network Configuration Protocol [RFC6241] [RFC6242] have been preferred.
Allocation of prefixes in small networks calls for an approach that can be completely automated. This note documents a procedure that has been suggested by several. It builds on a few basic assumptions:
- IPv6 prefixes are allocated to a small network by one or more upstream service providers using [RFC3315] and [RFC3363] .
- IPv6 prefixes may allocated to LAN within a small network by the CPE Router using [RFC3315] and [RFC3363] .
- Occasional inefficiencies such as allocating two /64s to a LAN from a given upstream prefix are acceptable, especially if short-lived.
- Small networks, such as described in Home Networking Architecture for IPv6 [I-D.chown-homenet-arch] , are simple enough in structure that the mechanism described in this note is adequate.
These assumptions bear analysis. The first two, that prefixes can and may be allocated using mechanisms designed for the purpose, seems self-evident. The third builds on the IPv6 premise that a host may have more than one prefix on an interface and one or more addresses in each prefix; in such a case, while it may be suboptimal to allocate more than one /64 from the same upstream prefix, the hosts will not complain and the routing protocols will route them. The fourth may be considered the limit of applicability; if a network requires a prefix aggregation design or is otherwise too complex for this procedure to be effective, other procedures are more appropriate.
This document describes a procedure for prefix delegation and assignment. It results in the assignment of a series of /64 prefixes on the links in a small home network.
While this document describes the use of DHCPv6 for prefix delegation, specification of the use of DHCPv6 for address assignment and other purposes is out of scope.
If a network includes interior routers and the CPE router is not directly to all of the links in the network, the routers in the network will need routing information to forward traffic in the network and between the network and the service provider network. The specification of a routing protocol or other mechanism to provide that routing information to the routers is beyond the scope of this document.
The first case to describe is that of a network with a simple tree topology. In this network, there is a single CPE router attached to a single SP network. The interior of the network is organized as a tree. Each interior router has one "upstream" interface and one or more "downstream" interfaces. Each link in the network has a single interior router with a downstream interface attached and zero or more interior routers with an upstream interface attached.
The fundamental procedure for prefix allocation takes three phases:
- Allocating a prefix from the upstream network,
- Prefix allocation by the CPE Router, and
- Prefix allocation by a subsequent router.
This section describes the assignment of prefixes in a simple network. The network is assumed to be tree-structured, including one CPE router that is connected to a SP network and one or more interior routers. The interior routers each have a single "upstream" interface and one or more "downstream" interfaces. The upstream interface of each interior router is connected to a link in the network to which a downstream interface of a router closer to the CPE router is already connected.
The CPE router obtains a delegated prefix for the entire home network, and manages prefix allocations for all of the interior routers. Each interior router uses DHCPv6 on its upstream interface to obtain delegated prefixes from the CPE router for each of the interior routers downstream interfaces.
The CPE router obtains a delegated prefix from the SP provisioning system using [RFC3315] and [RFC3363] and other appropriate provisioning systems. The prefix delegated from the service provider includes a preferred and valid lifetime for the prefix.
Once the CPE router has received a delegated prefix, it assigns a /64 subprefix to each of the links to which the router is attached. The CPE router configures an address to each of its interfaces from the prefix assigned to the link to which the interface is attached. After assigning the interface addresses, the CPE router begins sending Router Advertisement (RA) messages [RFC4861] advertising the appropriate prefix on each attached link.
The CPE router includes a Router Advertisement Allocator Information (RAAI) option, identifying itself as the allocating server for prefixes related to the prefix announced in the RA. The RAs include preferred and valid lifetimes derived from the lifetimes associated with the delegated prefix from the service provider. The RA also advertises the CPE router as the default router for the link. Other fields in the RAs are set as appropriate.
At this point, the links to which the CPE router is attached is now provisioned with prefixes taken from the prefix obtained from the service provider. The CPE router uses ongoing DHCPv6 messages exchanges according to [RFC3315] and [RFC3363] to maintain and update its delegated prefix.
The CPE router uses a DHCPv6 server for prefix subdelegation throughout the rest of the network. In preparation for assigning prefixes to links in the rest of the network, the CPE router makes all of the remaining prefixes from the network prefix available for subdelegation through a DHCPv6 server. The CPE router configures the preferred and valid lifetimes for the subdelegated prefixes from the values received from the service provider.
When an interior router is connected to the home network, its upstream interface is attached to a link in the home network, and its downstream interfaces are connected to other links to be added to the home network.
After the upstream interface is attached to a link, the interior router listens for RAs on the upstream interface and configures the upstream interface according to the information contained in the received RAs.
When the interior router receives an RA with an RAAI option, the router initiates a DHCPv6 message exchange to obtain prefixes from the prefix managed by the allocating router. The interior router requests the delegation of a separate /64 prefix for each of its downstream interfaces. The DHCPv6 service in the home network delivers the DHCPv6 traffic between the interior router and the CPE router.
The CPE router delegates the requested prefixes from the prefix delegated to the network. The interior router then assigns a prefix to each link attached to which a downstream interface is attached, configures those downstream interfaces with addresses from the assigned prefixes and begins sending RAs on the downstream interfaces. The interior router includes an RAAI option in the RAs, indentifying the CPE router as the allocating DHCPv6 server. The preferred and valid lifetimes for the advertised prefix are derived from the lifetimes in the DHCPv6 delegation, and the RAs advertise the interior router as the default router for the link.
It is quite likely that real world deployments will violate the assumption in the previous section that only one downstream interface will be attached to each link in the home network. In this situation, it is desirable that the link only be assigned one prefix and, therefore, only one of the interior routers with a downstream interface on the link be responsible for assigning a prefix and sending RAs on the link.
To avoid duplicate address assignment, a router first listens for RAs on the link attached to its downstream interface. If the router does not receive an RA after listening for INTERVAL1 microfortnights, the router assumes it is responsible for assigning a prefix to that link and initiates the DHCPv6 process for obtaining a delegated prefix.
After the router determines it is responsible for the link attached to its downstream interface, it continues to listen for RAs from other routers on the link. If it receives an RA from another router, it deassigns its delegated prefix from the link, unconfigures any addresses assigned from that prefix and releases the delegated prefix to the CPE router using DHCPv6.
If a router hears an RA such as described in Section 3.1.2 , it uses IPv6 Stateless Address Autoconfiguration [RFC4862] [RFC4941] or a DHCPv6 [RFC3315] request to each announced allocator to generate an address within the prefix for use in that subnet.
After the router determines that some other router is responsible for the link attached to its downstream interface, it continues to listen on the interface for RAs. If the router receives no RA on the interface for INTERVAL2 microfortnights, the router takes responsibility for the link and initiates the process described above to obtain and assign a prefix to the link.
If a network has multiple service provider networks, it will have multiple prefixes. This situation is easiest to describe if the network is connected to each service provider through a separate CPE router.
Each CPE router obtains a delegated prefix from its service provider and then manages the prefix according to the
First layer of interior router get multiple direct DHCPv6 prefixes. Assigns each prefix in parallel. Sets up DHCPv6 relay agent to point to each of the CPE routers.
Next layer receives DHCPv6 transaction from each CPE router because upstream router forwards DHCPv6 messages to each of the CPE routers.
There are a number of potential issues in this procedure.
Apart from cases in which the administration has chosen to fix a given subnet to a given LAN, such as to support server deployment in DNS, it is generally advised that subnet numbers be randomized. This is to make certain network attacks a little more difficult.
One issue is "what happens if one has multiple upstream networks with multiple CPE Routers and therefore multiple allocators?" The design of the RA information element announcing the allocator is intended to simplify that by announcing an allocator.
In the simplest case, there are no race conditions; the home has exactly one router, it obtains a prefix from its upstream network, and sub-allocates to its interfaces. If there are additional routers in the home, however, either there are one or more links that are not attached to the CPE Router or there are zero; in the event that there are one or more such links, they may be connected by one router or by multiple routers.
One race condition is when two interior routers are attached to the same LANs as the CPE. For example, one might have a wireless router in the home that connects both to the wired and the wireless network that the CPE Router is on. In such a case, it will hear and interpret one of the CPE Router's RAs first, and then the other some amount of time later. The purpose of the INTERVAL1 delay in Section 3.1.2 is to allow this race condition to stabilize before the router acts on this information it has.
A second race condition occurs when two "subsequent" routers are on the same LAN but it is not serviced by the CPE Router. These routers will both use the procedure of Section 3.1.2 to attempt to allocate a prefix to the LAN and so create a subnet. It is RECOMMENDED that the allocator allocate at most one prefix per INTERVAL2, ignoring all other requests, in order to allow the "subsequent" routers to sort out this class of race condition. If needed, ignored routers will re-request the allocation.
Due to the possibility of packet loss in the network, it is possible that these race conditions may result in a given LAN developing multiple subnets. While suboptimal, this is not a violation of the architecture and should cause no issues. However, in the event that two routers observe that they are announcing different subnets in the same upstream prefix on the same LAN, the one with the numerically least subnet number SHOULD NOT allow its prefix to expire, but any others SHOULD allow their prefixes to expire.
Obviously, use of this procedure in a complex network results in a serialization of prefix allocation that may take more time to settle than is operationally desirable (number of LANs times INTERVAL2). In such cases, the administration will have to decide how it wants to handle the issue. One approach would be to divide the network into easily-aggregated sections and use the procedure within each section; another would be to use a different procedure.
In such networks, the routers requesting prefixes can also act as a denial of service attack, by flooding the CPE Router with requests. Given that the procedure eventually terminates, this is undesirable but of limited duration.
In networks that contain servers or names that are announced in DNS, it is often valuable to have the same LAN always have the same subnet number applied to it. The procedure as described could accomplish that if the CPE Router maintains memory of what router it has allocated a given prefix to recently, or would fail to provide that if it does not. The distinction is essentially a marketing requirement that the implementation will need to decide for itself.
If a network runs out of subnet numbers and therefore subnet prefixes, this is considered a provisioning failure. It can result when multiple prefixes are allocated to the same LAN, which should be unusual and will end when one of the routers releases its prefix. It can also result when the upstream network allocates a prefix that is too long and as a result contains too few potential prefixes. In that case, the administration is forced to either reorganize its network or negotiate for a shorter prefix.
On a Neighbor Discovery RA, Section 3.1.2 and Section 3.1.2 call for the RA to identify the allocator that a "subsequent" router may use to request a related prefix for use on a different interface. This information element contains a list of the IPv6 addresses of one or more allocators, and an element length option to permit parsing of the information element.
In Section 5 , this note specifies an information element to be carried in the Router Advertisement message specified in Neighbor Discovery.
<TBD>
- RIPE Database (Whois)
- Deploy IPv6 Now
- Statistics and Tools
- Training and Materials
- All RIPE NCC Organisational Documents
- Activity Plan and Budget
- Annual Reports
- Charging Schemes
- Member Update
- RIPE Documents by Number
- RIPE Documents by Category
- RIPE Policies
- FTP Archive
- RIPE Document Aliases
- RSS News Feeds
IPv6 Address Allocation and Assignment Policy
Publication date: 16 Mar 2020
This document defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations. It was developed through joint discussions among the APNIC, ARIN and RIPE communities.
1. Introduction 1.1. Overview 2. Definitions 2.1. Internet Registry (IR) 2.2. Regional Internet Registry (RIR) 2.3. National Internet Registry (NIR) 2.4. Local Internet Registry (LIR) 2.5. Allocate 2.6. Assign 2.7. Utilisation 2.8. HD-Ratio 2.9. End Site 3. Goals of IPv6 address space management 3.1. Goals 3.2. Uniqueness 3.3. Registration 3.4. Aggregation 3.5. Conservation 3.6. Fairness 3.7. Minimised Overhead 3.8. Conflict of Goals 4. IPv6 Policy Principles 4.1. Address space not to be considered property 4.2. Routability not guaranteed 4.3. Minimum Allocation 4.4. Consideration of IPv4 Infrastructure 5. Policies for allocations and assignments 5.1. Initial allocation 5.1.1. Initial allocation criteria for LIRs 5.1.2. Initial allocation size 5.2. Subsequent allocation 5.2.1. Subsequent allocation criteria 5.2.2. Applied HD-Ratio 5.2.3. Subsequent Allocation Size 5.3. LIR-to-ISP allocation 5.4. Assignment 5.4.1. Assignment address space size 5.4.2. Assignments shorter than a /48 to a single End Site 5.5. Registration 5.6. Reverse lookup 5.7. Existing IPv6 address space holders 6. Anycasting TLD and Tier 0/1 ENUM Nameservers 7. IPv6 Provider Independent (PI) Assignments 7.1. IPv6 Provider Independent (PI) Assignment Size 7.2. IPv6 Provider Independent (PI) Assignments for LIRs 8. Transfer of IPv6 resources 9. References 10. Appendix A: HD-Ratio 11. Appendix B: Background information 11.1. Background 11.2. Why a joint policy? 11.3. The size of IPv6's address space 11.4. Acknowledgment
1. Introduction
1.1. overview.
This document describes policies for the allocation and assignment of globally unique Internet Protocol version 6 (IPv6) address space.
[ RFC 4291 ] designates 2000::/3 to be global unicast address space that the Internet Assigned Numbers Authority (IANA) may allocate to the RIRs. In accordance with [ RFC 4291 ], IANA allocated initial ranges of global unicast IPv6 address space from the 2000::/3 address block to the RIRs. This document concerns the initial and subsequent allocations of the 2000::/3 unicast address space, for which RIRs formulate allocation and assignment policies. All bits to the left of /64 are in scope.
2. Definitions
[Note: some of these definitions will be replaced by definitions from other RIR documents in order to be more consistent.]
The following terms and their definitions are of particular importance to the understanding of the goals, environment and policies described in this document.
Responsibility for management of IPv6 address spaces is distributed globally in accordance with the hierarchical structure shown below.
2.1. Internet Registry (IR)
An Internet Registry is an organisation that is responsible for distributing IP address space to its members or customers and for registering those distributions. IRs are classified according to their primary function and territorial scope within the hierarchical structure depicted in the figure above.
2.2. Regional Internet Registry (RIR)
Regional Internet Registries are established and authorised by respective regional communities and recognised by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions.
2.3. National Internet Registry (NIR)
A National Internet Registry primarily allocates address space to its members or constituents, which are generally LIRs organised at a national level. NIRs exist mostly in the Asia Pacific region.
2.4. Local Internet Registry (LIR)
A Local Internet Registry is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs.
2.5. Allocate
To “allocate” means to distribute address space to IRs for the purpose of subsequent distribution by them.
2.6. Assign
To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.
Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties.
2.7. Utilisation
The actual usage of addresses within each assignment may be low when compared to IPv4 assignments. In IPv6, "utilisation" is only measured in terms of the bits to the left of the efficiency measurement unit (/56). In other words, "utilisation" effectively refers to the assignment of network prefixes to End Sites and not the number of addresses assigned within individual End Site assignments.
Throughout this document, the term "utilisation" refers to the assignment of network prefixes to End Sites and not the number of addresses assigned within individual subnets within those End Sites.
2.8. HD-Ratio
The HD-Ratio is a way of measuring the efficiency of address assignment [ RFC 3194 ]. It is an adaptation of the H-Ratio originally defined in [ RFC 1715 ] and is expressed as follows:
where (in the case of this document) the objects are IPv6 site addresses assigned from an IPv6 prefix of a given size.
2.9. End Site
An End Site is defined as the location of an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves:
- that service provider assigning address space to the End User location
- that service provider providing transit service for the End User location to other sites
- that service provider carrying the End User's location traffic
- that service provider advertising an aggregate prefix route that contains the End User's location assignment
3. Goals of IPv6 address space management
IPv6 address space is a public resource that must be managed in a prudent manner with regards to the long-term interests of the Internet. Responsible address space management involves balancing a set of sometimes competing goals. The following are the goals relevant to IPv6 address policy.
3.2. Uniqueness
Every assignment and/or allocation of address space must guarantee uniqueness worldwide. This is an absolute requirement for ensuring that every public host on the Internet can be uniquely identified.
3.3. Registration
Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to End Users.
The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws.
3.4. Aggregation
Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs and to limit the expansion of Internet routing tables.
This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing.
IPv6 address policies should seek to avoid fragmentation of address ranges.
Further, RIRs should apply practices that maximise the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation.
3.5. Conservation
Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided.
3.6. Fairness
All policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size, or any other factor.
3.7. Minimised overhead
It is desirable to minimise the overhead associated with obtaining address space. Overhead includes the need to go back to RIRs for additional space too frequently, the overhead associated with managing address space that grows through a number of small successive incremental expansions rather than through fewer, but larger, expansions.
3.8. Conflict of goals
The goals described above will often conflict with each other, or with the needs of individual IRs or End Users. All IRs evaluating requests for allocations and assignments must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole.
In IPv6 address policy, the goal of aggregation is considered to be the most important.
4. IPv6 Policy Principles
To address the goals described in the previous section, the policies in this document discuss and follow the basic principles described below.
4.1. Address space not to be considered property
It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property.
The policies in this document are based upon the understanding that globally unique IPv6 unicast address space is licensed for use rather than owned. Specifically, IP addresses will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license.
RIRs will generally renew licenses automatically, provided requesting organisations are making a “good faith” effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organisation is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license. Note that when a license is renewed, the new license will be evaluated under and governed by the applicable IPv6 address policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment.
4.2. Routability not guaranteed
There is no guarantee that any address allocation or assignment will be globally routable.
However, RIRs must apply procedures that reduce the possibility of fragmented address space which may lead to a loss of routability.
4.3. Minimum allocation
The minimum allocation size for IPv6 address space is /32.
4.4. Consideration of IPv4 infrastructure
Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure.
5. Policies for Allocations and Assignments
5.1. initial allocation, 5.1.1. initial allocation criteria for lirs.
To qualify for an initial allocation of IPv6 address space, an LIR must have a plan for making sub-allocations to other organisations and/or End Site assignments within two years.
5.1.2. Initial allocation size
LIRs that meet the initial allocation criteria are eligible to receive an initial allocation of /32 up to /29 without needing to supply any additional information.
LIRs may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the LIR infrastructure, the hierarchical and geographical structuring of the LIR, the segmentation of infrastructure for security and the planned longevity of the allocation.
5.2. Subsequent allocation
LIRs that have received an IPv6 allocation may receive a subsequent allocation in accordance with the following policies.
5.2.1. Subsequent allocation criteria
Subsequent allocation will be provided when an LIR:
a) Satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56. To this end, the HD-Ratio [ RFC 3194 ] is used to determine the utilisation thresholds. or
b) Can justify new needs (which can't be satisfied within the previous allocation), according to the initial allocation size criteria as described in section 5.1.2.
5.2.2. Applied HD-Ratio
The HD-Ratio value of 0.94 is adopted as indicating an acceptable address utilisation for justifying the allocation of additional address space. Appendix A provides a table showing the number of assignments that are necessary to achieve an acceptable utilisation value for a given address block size.
5.2.3. Subsequent allocation size
When an LIR meets the subsequent allocation criteria, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left.
If an LIR needs more address space, it must provide documentation justifying its new requirements, as described in section 5.1.2. The allocation made will be based on the relevant documentation.
5.3. LIR-to-ISP allocation
There is no specific policy for an LIR to allocate address space to subordinate ISPs. Each LIR organisation may develop its own policy for subordinate ISPs to encourage optimum utilisation of the total address block allocated to the LIR. However, all /48 assignments to End Sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary.
5.4. Assignment
LIRs must make IPv6 assignments in accordance with the following provisions.
5.4.1. Assignment address space size
End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a value of "n" x /64. Section 4.2 of ripe-690 provides guidelines about this.
5.4.2. Assignments shorter than a /48 to a single End Site
Assignments larger than a /48 (shorter prefix) or additional assignments exceeding a total of a /48 must be based on address usage or because different routing requirements exist for additional assignments.
In case of an audit or when making a request for a subsequent allocation, the LIR must be able to present documentation justifying the need for assignments shorter than a /48 to a single End-Site.
5.5. Registration
When an LIR holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database.
These registrations can either be made as individual assignments or by inserting an object with a status value of 'AGGREGATED-BY-LIR' where the assignment-size attribute contains the size of the individual assignments made to End Users. When more than a /48 is assigned to an organisation, it must be registered in the database as a separate object with status 'ASSIGNED'.
In case of an audit or when making a request for a subsequent allocation, the LIR must be able to present statistics showing the number of individual assignments made in all objects with a status of 'AGGREGATED-BY-LIR' in such a way the RIR is able to calculate and verify the actual HD-ratio.
5.6. Reverse lookup
When an RIR/NIR delegates IPv6 address space to an LIR, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each LIR should properly manage its reverse lookup zone. When making an address assignment, the LIR must delegate to an assignee organisation, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address.
5.7. Existing IPv6 address space holders
LIRs that hold one or more IPv6 allocations are able to request extension of each of these allocations up to a /29 without providing further documentation.
The RIPE NCC should allocate the new address space contiguously with the LIRs' existing allocations and avoid allocating non-contiguous space under this policy section.
6. Anycasting TLD and Tier 0/1 ENUM Nameservers
The organisations applicable under this policy are TLD managers, as recorded in the IANA's Root Zone Database and ENUM administrators, as assigned by the ITU. The organisation may receive up to four /48 prefixes per TLD and four /48 prefixes per ENUM. These prefixes must be used for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in BCP126/ RFC 4786 .
Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled " Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region ".
Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for infrastructure providing authoritative TLD or ENUM Tier 0/1 DNS lookup services any longer.
7. IPv6 Provider Independent (PI) Assignments
To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled “ Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region ”.
The RIPE NCC will assign the prefix directly to the End User organisations upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR.
Assignments will be made from a separate 'designated block' to facilitate filtering practices.
The PI assignment cannot be further sub-assigned to other organisations.
7.1. IPv6 Provider Independent (PI) Assignment Size
The minimum size of the assignment is a /48.
The considerations of "5.4.2. Assignments shorter than a /48 to a single End-Site" must be followed if needed.
7.2. IPv6 Provider Independent (PI) Assignments for LIRs
LIRs can qualify for an IPv6 PI assignment for parts of their own infrastructure that are not used for customer end sites. Where an LIR has an IPv6 allocation, the LIR must demonstrate the unique routing requirements for the PI assignment.
The LIR should return the IPv6 PI assignment within a period of six months if the original criteria on which the assignment was based are no longer valid.
8. Transfer of IPv6 resources
The transfer of Internet number resources is governed by the RIPE Document, " RIPE Resource Transfer Policies ".
9. References
[RFC 1715] "The H Ratio for Address Assignment Efficiency", C. Huitema. November 1994, ftp://ftp.ripe.net/rfc/rfc1715.txt
[RFC 2026] "The Internet Standards Process -- Revision 3 IETF Experimental RFC ftp://ftp.ripe.net/rfc/rfc2026.txt see Sec. 4.2.1
[RFC 2462] "IPv6 Stateless Address Autoconfiguration", S. Thomson, T. Narten, 1998, ftp://ftp.ripe.net/rfc/rfc2462.txt
[RFC 4291] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. February 2006, ftp://ftp.ripe.net/rfc/rfc4291.txt
[RFC 2928] "Initial IPv6 Sub-TLA ID Assignments", R. Hinden, S. Deering, R. Fink, T. Hain. September 2000 ftp://ftp.ripe.net/rfc/rfc2928.txt
[RFC 3194] "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", A. Durand, C. Huitema. November 2001, ftp://ftp.ripe.net/rfc/rfc3194.txt
[RFC 4786] "Operation of Anycast Services", J. Abley, K. Lindqvist. December 2006, ftp://ftp.ripe.net/rfc/rfc4786.txt
10. Appendix A: HD-Ratio
The utilisation threshold T, expressed as a number of individual /56 prefixes to be allocated from IPv6 prefix P, can be calculated as:
Thus, the utilisation threshold for an LIR requesting subsequent allocation of IPv6 address block is specified as a function of the prefix size and target HD ratio. This utilisation refers to the use of /56s as an efficiency measurement unit, and does not refer to the utilisation of addresses within those End Sites. It is an address allocation utilisation ratio and not an address assignment utilisation ratio.
In accordance with the recommendations of [ RFC 3194 ], this document adopts an HD-Ratio of 0.94 as the utilisation threshold for IPv6 address space allocations.
The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.94.
11. Appendix B: Background information
11.1. background.
The impetus for revising the 1999 provisional IPv6 policy started with the APNIC meeting held in Taiwan in August 2001. Follow-on discussions were held at the October 2001 RIPE and ARIN meetings. During these meetings, the participants recognised an urgent need for more detailed, complete policies. One result of the meetings was the establishment of a single mailing list to discuss a revised policy together with a desire to develop a general policy that all RIRs could use. This document does not provide details of individual discussions that lead to policies described in this document; detailed information can be found in the individual meeting minutes at the www.apnic.net, www.arin.net, and www.ripe.net web sites.
In September 2002 at the RIPE 43 Meeting in Rhodes, Greece, the RIPE community approved the policy allowing Internet experiments to receive temporary assignments. As a result, Section 6 was added to this document in January 2003.
11.2. Why a joint policy?
IPv6 addresses are a public resource that must be managed with consideration to the long-term interests of the Internet community. Although regional registries adopt allocation policies according to their own internal processes, address policies should largely be uniform across registries. Having significantly varying policies in different regions is undesirable because it can lead to situations where "registry shopping" can occur as requesting organisations request addresses from the registry that has the most favorable policy for their particular desires. This can lead to the policies in one region undermining the efforts of registries in other regions with regards to prudent stewardship of the address space. In cases where regional variations from the policy are deemed necessary, the preferred approach is to raise the issue in the other regional registries in order to develop a consensus approach that all registries can support.
11.3. The size of IPv6's address space
Compared to IPv4, IPv6 has a seemingly endless amount of address space. While superficially true, short-sighted and wasteful allocation policies could also result in the adoption of practices that lead to premature exhaustion of the address space.
It should be noted that the 128-bit address space is divided into three logical parts, with the usage of each component managed differently. The rightmost 64 bits, the Interface Identifier [RFC 4291], will often be a globally unique IEEE identifier (e.g., mac address). Although an "inefficient" way to use the Interface Identifier field from the perspective of maximizing the number of addressable nodes, the numbering scheme was explicitly chosen to simplify Stateless Address Autoconfiguration [ RFC 2462 ].
The middle bits of an address indicate the subnet ID. This field may often be inefficiently utilised, but the operational benefits of a consistent width subnet field were deemed to be outweigh the drawbacks. This is a variable length field, determined by each LIR's local assignment policy.
11.4. Acknowledgment
The initial version of this document was produced by the JPNIC IPv6 policy drafting team consisting of Akihiro Inomata, Akinori Maemura, Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, and Toshiyuki Yamasaki. Special thanks goes out to this team, who worked over a holiday in order to produce an initial document quickly.
An editing team was then organised by representatives from each of the three RIRs (Takashi Arano, Chair of APNIC's Policy SIG, Thomas Narten, Chair of ARIN's IPv6 WG, and David Kessens, Chair of the RIPE IPv6 Working Group).
The editing team would like to acknowledge the contributions to this document of Takashi Arano, John Crain, Steve Deering, Gert Doering, Kosuke Ito, Richard Jimmerson, David Kessens, Mirjam Kuehne, Anne Lord, Jun Murai, Paul Mylotte, Thomas Narten, Ray Plzak, Dave Pratt, Stuart Prevost, Barbara Roseman, Gerard Ross, Paul Wilson, Cathy Wittbrodt and Wilfried Woeber.
The final editing of the initial version of this document was done by Thomas Narten.
RIPE Documents Search
ripe-707 , ripe-699 , ripe-684 , ripe-681 , ripe-655 , ripe-650 , ripe-641 , ripe-589 , ripe-552 , ripe-545 , ripe-538 , ripe-523 , ripe-512 , ripe-481 , ripe-472 , ripe-466 , ripe-465 , ripe-450 , ripe-421 , ripe-412 , ripe-388 , ripe-267 , ripe-246 , ripe-196
- Policy Proposal 2019-06
- Address Policy Working Group
- Skip to primary navigation
- Skip to main content
- Skip to primary sidebar
- Skip to custom navigation
- Cyber Threat Intelligence
- BloxOne® Applications
- Infoblox Community
- Partner Portal
- Why Infoblox
- Support & Services
Home / IPv6 CoE / IPv6 Prefix Allocation Methods – Part Two
IPv6 Prefix Allocation Methods – Part Two
August 5, 2020
Introduction
In part one , we started our discussion of IPv6 prefix allocation methods with the simple reason of why you need them in the first place: a properly sized IPv6 allocation provides a vast amount of IPv6 space and you need to have one or more methods for logically and sensibly dividing and assigning that space based on the types of networks you are addressing. I also listed the four most common methods of IPv6 prefix allocation: next available , sparse , best fit , and random. Part one concluded with a detailed look at the next available allocation technique. If you haven’t read part one and are unfamiliar with IPv6 address planning, I encourage you to read it before reading this post.
In part two, we’ll discuss the remaining IPv6 prefix allocation methods along with how and when to use them. As with our example in part one, the idea is that you’ve been allocated a sufficiently large block of IPv6 addresses to meet your IPv6 addressing needs for decades .
Since we covered the next available prefix allocation method of assigning prefixes (i.e., subnets) of IPv6 address space in detail last time, this time we’ll focus on the three allocation methods that remain. They are:
Sparse Allocation
The simplest description for sparse allocation of IPv6 is the assignment of prefixes with lots of additional unused prefixes (and thus address space) in between them. The basic benefit of this method is not simply leaving space in reserve—after all, it likely wouldn’t be that hard to find available extra IPv6 address space from within the overall IPv6 allocation. What sparse allocation provides is address space in reserve that is more likely to be contiguous .
Fellow routing nerds may recognize immediately that such contiguous space adjacent to the original allocation and reserved for the original allocation’s recipient, is better for enabling route summarization and reducing the size of routing tables (i.e., preventing large prefix disaggregation ). That is precisely why sparse allocation is preferred for service providers that need to allocate large blocks of address space to their customers. And of course, organizations such as the Regional Internet Registries and IANA which are tasked with allocating all IPv6 (and IPv4) addressing to those service providers (and more frequently than before, directly to enterprises) benefit from using sparse allocation mode to guarantee contiguous space held in reserve for any and all allocations.
For example, if an enterprise is allocated a /32 of address space from ARIN (the RIR for North America), it is very likely that such a /32 was allocated from a larger allocation held in reserve for that enterprise. Keep in mind that the enterprise developed enough of an address plan to recognize that they needed a /32 of IPv6 address space. They requested a /32 from ARIN and provided the necessary justification. ARIN approved the request and assigned them a /32. However, perhaps unbeknownst to the enterprise, ARIN reserved, say, a /29 containing 8 /32s, one of which was publicly assigned to the enterprise. If that enterprise needed more IPv6 address space at some point in the future—and as long as that need didn’t exceed the remaining 7 /32s—additional contiguous /32s up to the entire /29 could then be assigned to the enterprise.
Otherwise, the enterprise could certainly be assigned additional IPv6 space from another part of the RIR’s overall IPv6 allocation, but it would not be contiguous. It’s also possible that without contiguous space held in reserve for the enterprise, the RIR could require the return of the original allocation for the new larger one (hello, painful and costly renumbering of the entire network!). Most organizations are used to dealing with disaggregated and non-contiguous IPv4 prefixes, but it creates complexity in managing the address plan. Such complexity typically results in operational errors and more difficult fault isolation.
The above example applies equally well to service providers and their customers. Sparse allocation provides similar benefits. Keep in mind that service provider allocations are almost always Provider Assigned (PA), meaning that the allocation or any part of it is only permitted to be routed through that service provider’s network. (Compare this with the Provider Independent (PI) space RIRs assign, which are allowed to be routed through any provider.)
Here’s a visual example of sparse allocation to hopefully make the concept a bit clearer. Imagine that an organization starts with a /32 of IPv6 address space—in this example the reserved documentation prefix of 2001:db8::/32. The organization could be a Regional Internet Registry like ARIN (where the /32 would come from their much larger pool of a /12). Each entity being assigned prefixes from the /32 by ARIN would be some smaller organization requesting address space from ARIN.
Or the primary /32 allocation could belong to a service provider that has been allocated the /32 from an RIR. In that case, the entities receiving subsequent smaller assignments from the service provider would be their customers.
Another possibility is that the primary /32 allocation could belong to an enterprise. In that case, the entities might represent internal assignments to corporate network locations or regions.
In any of the above cases, the sparse allocation method would be to assign the first available /36 (e.g., 2001:db8::/36) to the entity while reserving some contiguous amount of address space. In our visual example, the equivalent of 3 additional /36s have been held in reserve for each of the first and second entities.
Let’s look at each step of the sparse allocation method in this example. The initial assignment to entity 1 is 2001:db8::/36. Keep in mind that because of zero compression rules for IPv6 addresses, the prefixes for the /32 and the /36 might end up looking exactly the same, but for the CIDR notation at the end of the prefix indicating the prefix length (e.g., 2001:db8::/32 and 2001:db8::/36).
You may notice that in the example graphics, I break this rule in a couple of ways. For instance, in the above graphic, to assist in highlighting the relevant nibble for the /36, I included one zero. In the graphics below, I included four zeroes in the first prefix example in the table column to help maintain a consistent prefix width for visual purposes. Technically, both these examples should be zero compressed to the minimum length (e.g., 2001:db8::/36).
If you read part one of this blog, you may want to briefly recall how the next available allocation method works for comparison purposes. If we were using it, the next entity would get the next available /36, or 2001:db8:1000::/36.
As it happens, the underlying binary arithmetic and resulting bit manipulation for each method provides another perspective on how they compare. Since for either method we’re currently only looking at /36-sized prefixes assigned from a /32, we can restrict our bit manipulation to the most significant nibble in the 3rd hextet.
With the next available method of assignment, the next prefix would be defined by incrementing the least significant (rightmost) bits in that particular nibble. For example:
0 0 0 0 = 2001:db8::/36 (or with the relevant zero included 2001:db8:0::/36)
0 0 0 1 = 2001:db8:1000::/36
0 0 1 0 = 2001:db8:2000::/36
0 0 1 1 = 2001:db8:3000::/36
By comparison, sparse allocation increments the most significant (leftmost) bits in the nibble. Note that if this is done strictly, by incrementing one bit at a time, you’ll observe that it results in a sequence that skips the intervening prefixes in a way that isn’t necessarily intuitive. For example:
0 0 0 0 = 2001:db8::/36 (or with the relevant zero included 2001:db8:0::/36)
1 0 0 0 = 2001:db8:8000::/36
0 1 0 0 = 2001:db8:4000::/36
1 1 0 0 = 2001:db8:c000::/36
We can then reorder the assignments according to their natural decimal order to better align with our entity list order:
So how many entities can I assign /36s to? Well you may observe that once half (or eight) of the available /36s are consumed the sparse method is no longer possible for consistent assignment of remaining prefixes to the remaining entities. In this example, we’ll limit the number of entities to four, which results in each entity having 3 additional contiguous /36s in reserve.
Remember: the contiguous characteristic is definitional for sparse allocation! For example, by continuing to contiguously assign the remaining /36s to the respective entities, we get the following:
When all the IPv6 address space available in the primary allocation is assigned and the entire /32 consumed, each entity will have 4 contiguous /36s. As the above example suggests, these 4 /36s could each be summarized as a single /34. For example:
Entity 1 summary: 2001:db8:0000::/34
Entity 2 summary: 2001:db8:8000::/34
Entity 3 summary: 2001:db8:4000::/34
Entity 4 summary: 2001:db8:c000::/34
This summarization results in no more than 4 entries in the upstream router. By comparison, using any other method could result in as many as 16 routes. That should help demonstrate why sparse allocation is the method of choice for service providers and Regional Internet Registries (RIRs).
It may be obvious to you at this point that in our nibble-aligned example of a /32 divided into 16 /36s, any divisor that permits the assignment of an equal number of contiguous prefixes to each entity could be used.
2 entities = 8 /36s
4 entities = 4 /36s
8 entities = 2 /36s
Of course, we’re not limited to /32s and /36s. The sparse allocation method works just as well for other primary allocation sizes and could include groups of prefixes that don’t conform to nibble-aligned assignment as well.
Though sparse allocation is ideal for service providers, larger enterprises may find it useful as well. For example, an enterprise with locations in many regions supported by larger networks could benefit from using sparse assignments for each region. Future growth of those regions and networks could be accommodated with additional contiguous prefixes helping keep the routing table size to a minimum and simplifying configurations, operations, and troubleshooting.
The two remaining IPv6 allocation methods are best fit and random .
You’re likely intimately familiar with the best fit allocation method from IPv4, where it gets used frequently to conserve IP space—in particular, host addresses. In the best fit method, a prefix that provides the minimum number of smaller prefixes and/or host addresses (in the case of IPv4) is assigned from a larger primary allocation. In the process, as much as possible of the remaining primary allocation is preserved.
In this example, different entities are requesting the number of IPv6 address prefixes they have determined they need. To tailor the example to an enterprise, these entities could be functions or departments (e.g., data center, manufacturing, IT, etc.) responsible for their own networks and in need of address space.
Entity one determines it needs more than one /48 but not more than two. The assignment that would “best fit” that request is a /47 (although it might be odd that a site may outgrow a single /48 and need two). Entity two needs not more than one /48 and receives a /48. Entity three also needs not more than one /48 and receives a /48.
Entity four determines it needs the equivalent of three /48s. Binary dictates that the prefix size has to be some integer power of two, so the assignment that would best fit entity three’s requirement would be one /47 and one /48.
All of this is perfectly reasonable in terms of meeting the basic requirement of a) having enough address space and b) assigning it according to current needs. But veteran network folk can spot the complications immediately.
For one thing our routing table will have the following entries:
2001:db8:a1b0::/47 – Entity 1
2001:db8:a1b2::/48 – Entity 2
2001:db8:a1b3::/48 – Entity 3
2001:db8:a1b4::/47 – Entity 4
2001:db8:a1b6::/48 – Entity 4
Of course these can always be summarized as the primary allocation prefix of 2001:db8:a1b0::/44 but within the immediate routing domain, we have to operationally deal with different prefix sizes, some entities having one prefix in the routing table with others having multiple entries.
By comparison, choosing the entity with the largest /48 requirement and assigning all the entities that size prefix allows us to meet the prefix/address space needs of each entity while reducing both the size and complexity of the routing table:
2001:db8:a1b0::/46 – Entity 1
2001:db8:a1b4::/46 – Entity 2
2001:db8:a1b8::/46 – Entity 3
2001:db8:a1bc::/46 – Entity 4
You’ll notice also that this allows us to use the next available allocation method.
This is typically the point where anxiety about “wasting” address space ramps up. “Entities 2 and 3 only need a /48! Why am I giving them 4 times that amount?!” The answer is that the practically inexhaustible supply of IPv6 results in the ability to make addressing and address plan choices that favor operational ease and efficiency over mere conservation for its own sake (a trade-off simply not available to us in IPv4 given its limited/exhausted supply): e.g., fewer routing table entries and greater ease of identification of network assignments—especially where allocations strictly conform to nibble boundaries (unlike our example immediately above).
The final address allocation method we’ll discuss (if ever-so-briefly) is random . With random allocation, it’s typical to assign every entity the same size prefix but those prefix assignments are randomly selected. For example, a /48 provides 65,536 /64s. These /64 prefixes could be randomly generated and assigned:
2001:db8:a1b0:c290::/64 – Entity 1
2001:db8:a1b0:f0aa::/64 – Entity 2
2001:db8:a1b0:223b::/64 – Entity 3
2001:db8:a1b0:101e::/64 – Entity 4
This method would really only be useful or practical in a limited number of cases—specifically, where the allocation and provisioning process is highly automated and there is some additional benefit to random assignments (for reasons of security for instance, given an automated provisioning environment where the prefixes could be periodically reassigned with new random values). For example, a data center with different clusters that need unique IPv6 address space that will be routed to that cluster dynamically (e.g., Kubernetes).
If the last statement sounds (even vaguely) recognizable, it’s because a qualified example of this method is used all of the time—with “/128 prefixes”; i.e., individual IPv6 addresses! Privacy or temporary addresses are automatically provisioned via SLAAC and there is a presumed security benefit in preserving the anonymity of the IPv6 host (rather than having it be identifiable and traceable by the inclusion of its hardware address as part of the standard, non-random EUI-64 address assignment).
You’ve probably inferred at this point that when first designing (and with early iterations of) your IPv6 address plan, it’s unlikely that you’ll find much benefit to using either the best fit or random allocation methods. The best fit method is probably unavoidable at a much later date—hopefully much, much later—especially if you’ve designed your address plan based on a large enough initial allocation to provide abundant enough prefixes for consistent next available and sparse assignments.
Finally, it should also be pointed out that a good IPAM solution makes any of these IPv6 allocation methods easier to effectively manage. Fortunately, I can recommend a reputable DDI vendor that offers a high-performance solution in this area. 😉
- Tips & Tricks
Tom Coffeen
Co-founder of hexabuild.io.
Tom Coffeen is a network engineer, architect, and author with over twenty years of internetwork design, deployment, administration, and management experience. Tom co-founded HexaBuild, an IT consultancy specializing in the advancement of cloud, IoT, and security deployment best practices through IPv6 adoption. Prior to co-founding HexaBuild, Tom was an IPv6 Evangelist and a Distinguished Architect at Infoblox. Before that Tom was the VP of network architecture at the global CDN Limelight Networks where he led their deployment of IPv6. He is also the author of O’Reilly Media’s IPv6 Address Planning.
You might also be interested in
Understanding DHCPv6 Lease Times
By Scott Hogg
The IPv6 Prefix Information Option or Fun with the L Flag
By Ed Horley
IPv6 Prefix Allocation Methods - Part One (of Two)
By Tom Coffeen
Infoblox Advanced DNS Protection Rules - Viewing the Tip of an Iceberg
The Odd History of Provisioning an IPv6 Address on a Host
IPv6 Projects and “The Human Element”
By Steve Rogers
Assigning prefixes to Amazon EC2 network interfaces
You can assign a private IPv4 or IPv6 CIDR range, either automatically or manually, to your network interfaces. By assigning prefixes, you scale and simplify the management of applications, including container and networking applications that require multiple IP addresses on an instance.
The following assignment options are available:
Automatic assignment — AWS chooses the prefix from your VPC subnet’s IPv4 or IPv6 CIDR block and assigns it to your network interface.
Manual Assignment — You specify the prefix from your VPC subnet’s IPv4 or IPv6 CIDR block, and AWS verifies that the prefix is not already assigned to other resources before assigning it to your network interface.
Assigning prefixes has the following benefits:
Increased IP addresses on a network interface — When you use a prefix, you assign a block of IP addresses as opposed to individual IP addresses. This increases the number of IP addresses for a network interface.
Simplified VPC management for containers — In container applications, each container requires a unique IP address. Assigning prefixes to your instance simplifies the management of your VPCs, as you can launch and terminate containers without having to call Amazon EC2 APIs for individual IP assignments.
Basics for assigning prefixes
Considerations and limits for prefixes.
- Work with prefixes
You can assign a prefix to new or existing network interfaces.
To use prefixes, you assign a prefix to your network interface, attach the network interface to your instance, and then configure your operating system.
When you choose the option to specify a prefix, the prefix must meet the following requirements:
The IPv4 prefix that you can specify is /28 .
The IPv6 prefix that you can specify is /80 .
The prefix is in the subnet CIDR of the network interface, and does not overlap with other prefixes or IP addresses assigned to existing resources in the subnet.
You can assign a prefix to the primary or secondary network interface.
You can assign an Elastic IP address to a network interface that has a prefix assigned to it.
You can also assign an Elastic IP address to the IP address part of the assigned prefix.
We resolve the private DNS host name of an instance to the primary private IPv4 address.
We assign each private IPv4 address for a network interface, including those from prefixes, using the following format:
us-east-1 Region
All other Regions
Take the following into consideration when you use prefixes:
Network interfaces with prefixes are supported with instances built on the Nitro System .
Prefixes for network interfaces are limited to IPv6 addresses and private IPv4 addresses.
The maximum number of IP addresses that you can assign to a network interface depends on the instance type. Each prefix that you assign to a network interface counts as one IP address. For example, a c5.large instance has a limit of 10 IPv4 addresses per network interface. Each network interface for this instance has a primary IPv4 address. If a network interface has no secondary IPv4 addresses, you can assign up to 9 prefixes to the network interface. For each additional IPv4 address that you assign to a network interface, you can assign one less prefix to the network interface. For more information, see IP addresses per network interface per instance type .
Prefixes are included in source/destination checks.
To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.
Thanks for letting us know we're doing a good job!
If you've got a moment, please tell us what we did right so we can do more of it.
Thanks for letting us know this page needs work. We're sorry we let you down.
If you've got a moment, please tell us how we can make the documentation better.
FAQs | New Members | Whistleblowing | Contact Us | WHOIS
- Our Partners
- Our Service Region
- Fees Schedule
- Corporate Documents
- Membership Services
- Internet Number Resources Management
- Internet Routing Registry (IRR)
- DNSSEC Program
- Resource Certification Program (RPKI)
- Training Services
- Support & FAQs
- Online Services Changelog
- DNS Support Program
- Root Server Copy Program
- Products Roadmap
- Publications
- FAQ & Support
- Measurement WG
- Code of Conduct
- Email & Mailing Lists
- Policy Development
- Governments
- IPv4 Exhaustion
- Internet Governance
- Internet Development Programs
- Sponsorship Opportunities
- Hosting Guide
- Training Workshops
- Press Releases
- Presentations
- Contribution Guidelines
- Service Documents
- Deploy IPv6
- Become a Member
- Get Support
- Calculate my fees
How can we help you?
- Support & FAQs
- Membership Services & Operational FAQs
- General Queries
- WHOIS DB - Getting Started
- WHOIS DB FAQs (v202202)
- WHOIS DB - Reference Manual
- WHOIS DB - Objects and Attributes
- WHOIS DB - Publishing Abuse Contact Information
- Protecting your data
- PGP Authentication
- X509 Authentication supporting document
- Creating Customer Assignments
- Lame Delegation
- Mntner Guide (PDF)
- New mntner Object Format
- Mntner FAQs
- Bulk WHOIS FAQs
- Contractual Obligations Check (CoC)
- Prospective Resource Member
- Fees and Billing
- IPv4 Requests Guidelines for LIR Members
IPv6 Policy Implementation
Faqs related to ipv6 prefix rectification.
- My.AFRINIC.net
- Non-Members
- Requesting reverse delegation in AFRINIC region
- How to setup a LIR
- Publishing Abuse Contact Information
- Peering support from AFRINIC
- Good Standing
- AFRINIC Elections
- IRR Definitions
- IRR Best Practices
- IRR How-Tos
- IRR features on MyAFRINIC
- Handling Requests from Law Enforcement Authorities
As a service provider, the minimum prefix you can get from AFRINIC is a /32 Provider Aggregatable prefix.
The current policy makes it mandatory for LIR members to announce an IPv6 PA allocation within 12 months and, to the extent practicable, as a single aggregated prefix, so as to minimize global routing table growth.
In some very special cases, space may not be announced, however, it must be duly justified by the member to AFRINIC.
As an End-User organisation, the minimum prefix you can get from AFRINIC is a /48 Provider Independent prefix.
The organization must deploy the IPv6 provider-independent address space at each end-site, for which addresses are obtained, within twelve (12) months.
If the addressing space justification was that it will be announced, to the extent practicable, the organization should aggregate any announcements of prefixes so as to minimize global routing table growth.
A nibble is 4 bits. A nibble boundary is a network mask that aligns with a boundary of 4 bits. The size of the IPv6 prefix to be delegated should match a nibble-aligned boundary to keep addressing plans easily readable and understandable. Moreover, since DNS reverse delegations for IPv6 are based on the closest 4-bit boundaries, the use of nibble boundaries simplifies the management of DNS reverse delegations. In an IPv6 prefix, each hexadecimal character represents one nibble, which is 4 bits. Therefore, the prefix length of a delegated prefix should always be a multiple of 4.
Some examples of nibble boundary masks; 48, 44, 40, 36, 32, 28, 24, etc.
Example of a non-nibble aligned prefix: 2001:0db8:0:4000::/50
- The subnet only runs from 4000 to 7FFF and hence does not use the entire nibble range.
- To have a DNS reverse zone delegation covering the /50, in total 4 delegation entries should be created for the nearest nibble(one for each /52).
Example of a nibble-aligned prefix; 2001:0db8::/48
- The entire nibble range is used, 0 to f
- Only one DNS delegation may be configured to cover the whole range.
AFRINIC has finalised the implementation of two new IPv6 related policies;
- IPv6 PI Clarification - https://afrinic.net/policy/proposals/2019-v6-001-d2 -
- Adjusting IPv6 PA Policy - https://afrinic.net/policy/proposals/2019-ipv6-002-d1
The policies introduce new sections and amend some, which are explained here.
IPv6 Prefix Announcement
Announcement of pi assignments.
Section 6.8.2 of the Consolidated Policy Manual requires member organizations to justify the number of end-sites and their need for the IPv6 PI address space, and once the IPv6 resources are assigned, the resource member must deploy the IPv6 provider-independent address space at each of their end-site(s) within 12 months from receiving the prefix.
The announcement of disaggregated IPv6 prefix is no longer forbidden by this new policy. However, the policy encourages members to aggregate any announcements of prefixes, to the extent practicable, so as to minimize global routing table growth.
Announcement of PA Allocations
Section 6.5.1.1(D) of the Consolidated Policy Manual makes it mandatory for LIR members to announce an IPv6 PA allocation within 12 months and; to the extent practicable, as a single aggregated prefix, so as to minimize global routing table growth. In some very special cases, the space may not be announced, however, it must be duly justified by the member to AFRINIC.
IPv6 Policy Violation
The IPv6 prefixes which are not in use or not being announced after 12 months are in violation of the respective policies mentioned above and shall be reclaimed and returned to the AFRINIC free pool. The holders of IPv6 prefixes with a valid reason not to announce their IPv6 prefix within 12 months are encouraged to contact AFRINIC (mail to: [email protected] ).
You may check if your IPv6 prefixes are compliant to the policy as follows;
- Log in to https://my.afrinic.net/
- Go to “Resources” > “Policy Violations”
- Click on “IPv6 PI/PA UPDATE POLICY” to view the prefixes which are in violation of the policy.
Rectification of Initial prefix size
Rectification of initial pi assignment.
Section 6.8.4 of the Consolidated Policy Manual allows End-User members to request for rectification of their initial IPv6 PI assignment if it no longer satisfies their needs. The request will be evaluated by AFRINIC and, if approved, the same address block will be “upgraded” to the new required prefix size. However, if the adjacent prefixes are already being used by other organizations or if such assignment would not leave sufficient space for subsequent assignments, the member will have to choose either to:
- Receive a new block which, together with the block that has already been assigned, covers the new justified need, and keeps both blocks, or;
- Receive a new IPv6 block, with the agreement to utilize it for all future deployment and deprecate the old block through attrition, returning when empty. There is no deadline for return at this time
Note that a member can request the rectification of IPv6 PI space only once .
Rectification of initial PA Allocation
There are no new amendments made to the rectification of the initial PA allocation. As stipulated in section 6.5.1.3 of our Consolidated Policy Manual , LIR members may request for a rectification of their initial IPv6 PA allocation if it no longer satisfies their needs without the obligation to prove utilisation thresholds which applies for subsequent IPv6 PA allocations. The request will be evaluated by AFRINIC and, if approved, the same address block will be “upgraded” to the new required prefix size. However, if the adjacent prefixes are already being used by other organizations or if making the allocation would not leave sufficient space for subsequent allocations, the member will have to choose either to:
- Receive a new block with which they shall renumber their network and return the ‘original’ initial allocation within 6 months, or;
- Receive a complementary prefix to complete their addressing plan, and announce both, the ‘original’ initial prefix and the new prefix resulting from the new allocation. In the case of future subsequent allocation requests, both allocations shall be considered as if they were a single allocation.
Note that a member can request the rectification of IPv6 PA space only once .
Evaluation by AFRINIC
Any member requesting for the rectification of the initial assignment or allocation must provide a detailed IPv6 addressing plan demonstrating their needs for the next 12 months. In case the prefix will not be advertised, the member must inform AFRINIC and provide a reasonable justification.
How To Request Rectification
Request for rectification of pi assignments.
To request for rectification of a PI Assignment, please follow the below steps;
- Go to “Resources” > “IPv6 Resource
- Under “End-User Assignments”, click on “Request IPv6 Rectification”
- Select the prefix to be rectified.
- Select the new prefix size. You should select a nibble-aligned prefix size.
- Insert the preferred Netname. The name may be made up of letters, digits, the character underscore "_", and the character hyphen "-"; the first character of the name must be a letter, and the last character of a name must be a letter or a digit.
- Choose whether the prefix will be announced or not within 12 months of receiving the prefix. Examples of cases where the prefix shall not be announced are prefixes to be used for IXP peering LAN or private peering. If the prefix will not be announced, you will need to provide a valid reason.
- You may choose whether to request for a prefix which is adjacent to your existing prefix by selecting “Extend” or “Disaggregate” for a prefix which is not adjacent. Note that if you select “Extend”, a “Check Prefix” option will appear next to the prefix. You may check if the adjacent prefixes are available or not. If the existing prefix cannot be extended to the prefix size you chose, you will need to either choose a longer prefix length or choose Disaggregate.
- The rest of the form is optional, however, we encourage you to share an addressing plan which demonstrates how the requested prefix will be used. The addressing plan is required during the evaluation of your request.
- Once all the required information is provided in the form, click on “Request Rectification”.
Request for rectification of PA Allocations
To request for rectification of a PA Allocation, please follow the below steps;
- Under “Allocation”, click on “Request IPv6 Rectification”
- Add a brief description of the service which you intend to provide.
- For the “Addressing Plan”, insert a brief plan in the format: Immediate / 1yr / Purpose. For example; /32 /30 /Broadband
- The rest of the form is optional, however, we encourage you to share a detailed addressing plan which demonstrates how the requested prefix will be used. The addressing plan is required during the evaluation of your request.
You need to be an AFRINIC resource member with an IPv6 prefix and you must be compliant to the Contractual Obligation Checks.
While submitting the rectification request it is highly recommended to attach a detailed IPv6 addressing plan demonstrating your new needs.
We do not guarantee that your current IPv6 prefix is extendable to the new required prefix size.
Once you submit your request for the rectification of your initial IPv6 prefix, you shall be informed whether your prefix can be extended to the new required size or not.
If you are an LIR member and have opted to return your initial IPv6 prefix, it must be done within 6 months.
There is no timeframe specified in the policy for the return of PI assignment for End-User members, however, a reasonable amount of time will be granted to renumber and return the PI prefix.
- If your request for rectification is approved, you can either return your current prefix or keep it.
- If you will be keeping the existing prefix, we shall allocate a new prefix which together with the existing one would satisfy your needs.
- If you will be returning your existing IPv6 prefix for a new prefix, you will have to delete all assignments, route6 objects, and ROAs if any.
There is no allocation/assignment fee attached to rectifying the size of your initial block. However, for members without IPv4 but holds IPv6 only, this may have an impact on the annual membership fees.
You can request for rectification of your initial IPv6 allocation/assignment if it no longer satisfies your needs, the same address block will be “upgraded” to the new required prefix size.
However, if the adjacent prefixes are already being used by other organizations or if making the allocation would not leave sufficient space for subsequent allocations, then you can choose to receive a new block.
Take note that you can request the rectification of the IPv6 PA space only once.
Service Status | Changelog | Disclaimer
File : IPv6 Prefix Assignment Example-en.svg
File history, file usage on commons, file usage on other wikis.
Original file (SVG file, nominally 695 × 242 pixels, file size: 35 KB)
Summary [ edit ]
Licensing [ edit ].
- to share – to copy, distribute and transmit the work
- to remix – to adapt the work
- attribution – You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
- share alike – If you remix, transform, or build upon the material, you must distribute your contributions under the same or compatible license as the original.
Click on a date/time to view the file as it appeared at that time.
You cannot overwrite this file.
The following page uses this file:
- File:IPv6 Prefix Assignment Example-ar.svg
The following other wikis use this file:
- Internet Assigned Numbers Authority
- Մասնակից:Նելլի Ղազարյան/Ավազարկղ16
- IPv6 համացանցային հաղորդակարգ
- ინტერნეტის სამისამართო სივრცის ადმინისტრაცია
This file contains additional information such as Exif metadata which may have been added by the digital camera, scanner, or software program used to create or digitize it. If the file has been modified from its original state, some details such as the timestamp may not fully reflect those of the original file. The timestamp is only as accurate as the clock in the camera, and it may be completely wrong.
Structured data
Items portrayed in this file, copyright status, copyrighted, copyright license, creative commons attribution-sharealike 4.0 international, 22 september 2018, source of file, original creation by uploader, image/svg+xml.
IMAGES
VIDEO
COMMENTS
What part from this IPv6 address is the prefix and what part identifies the host? Since we use a /64 it means that the first 64 bits are the prefix. Each hexadecimal character represents 4 binary bits so that means that this part is the prefix: 2001:1234:5678:1234 This part has 16 hexadecimal characters. 16 x 4 means 64 bits.
IPv6 Global Unicast Prefix Assignments IANA "owns" the entire IPv6 address space and they assign certain prefixes to the RIRs (Regional Internet Registry). There are 5 RIRs at the moment: AFRINIC: Africa APNIC: Asia/Pacific ARIN: North America LACNIC: Latin America and some Caribbean Islands RIPE NCC: Europe, Middle east and Central Asia
Description The allocation of Internet Protocol version 6 (IPv6) unicast address space is listed here. References to the various other registries detailing the use of the IPv6 address space can be found in the [ IPv6 Address Space registry ]. Reference [ RFC7249] Note
RIPE-690 outlines best current operational practices for the assignment of IPv6 prefixes (i.e. a block of IPv6 addresses) for end-users, as making wrong choices when designing an IPv6 network will eventually have negative implications for deployment and require further effort such as renumbering when the network is already in operation.
The IPv6 general (or generic) prefix feature lets you renumber a global prefix on your router or switch. This is a simple but pretty useful feature. For example, let's say we have the following global prefix: 2001:41f0:4060::/48 And we use the following specific prefixes: 2001:41f0:4060:0001::/64 2001:41f0:4060:0002::/64 2001:41f0:4060:0003::/64
Use the following methods to configure IPv6 prefix assignment: Configure a static IPv6 prefix binding in an address pool —If you bind a DUID and an IAID to an IPv6 prefix, the DUID and IAID in a request must match those in the binding before the DHCPv6 server can assign the IPv6 prefix to the DHCPv6 client.
In IPv6 you assign a short prefix to each end-user site, so they are able to have as many subnets (/64s) as they need. You should not be concerned with exhausting the IPv6 addressing space, and you should think big when planning future requirements.
IPv6 Prefix Assignment in Small Networks draft-baker-homenet-prefix-assignment-00. Abstract. It is necessary to allocate prefixes in small networks, which include residential and Small Office/Home Office (SOHO) networks in a manner that minimizes or eliminates manual configuration.
But chances are due to the natural constraints on the availability of IPv4 address space, you may not be as familiar with a couple of the more commonly used address assignment methods the abundance of IPv6 address space allows for. Four Common IPv6 Assignment Methods. Let's begin with defining four common IPv6 prefix assignment methods. They are:
IPv6 prefix assignment Installing and Using OpenWrt Network and Wireless Configuration jsaiko December 31, 2021, 9:35pm #1 My LAN interface is assigned an address of XXXX:XXXX:XXXX:1300::1/56. I use prefix delegation to my downstream cisco L3 switch and another virtual router.
IPv6 Prefix Assignment in Small Networks draft-baker-homenet-prefix-assignment-00. Abstract. It is necessary to allocate prefixes in small networks, which include residential and Small Office/Home Office (SOHO) networks in a manner that minimizes or eliminates manual configuration.
An IPv6 address is represented as eight groups of four hexadecimal digits, each group representing 16 bits [a] The groups are separated by colons (:). An example of an IPv6 address is: 2001:0db8:85a3:0000:0000:8a2e:0370:7334 The standards provide flexibility in the representation of IPv6 addresses.
IPv6 Address Allocation and Assignment Policy Publication date: 16 Mar 2020 Abstract This document defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations. It was developed through joint discussions among the APNIC, ARIN and RIPE communities. Contents
The initial assignment to entity 1 is 2001:db8::/36. Keep in mind that because of zero compression rules for IPv6 addresses, the prefixes for the /32 and the /36 might end up looking exactly the same, but for the CIDR notation at the end of the prefix indicating the prefix length (e.g., 2001:db8::/32 and 2001:db8::/36).
This is a retouched picture, which means that it has been digitally altered from its original version.Modifications: Translated to Arabic - عُرّبت.The original can be viewed here: IPv6 Prefix Assignment Example-en.svg: .Modifications made by Michel Bakni.
RFC 6177 IPv6 Address Assignment to End Sites March 2011 A second motivation behind the original /48 recommendation was to simplify the management of an end site's addressing plan in the presence of renumbering (e.g., when switching ISPs). In IPv6, a site may simultaneously use multiple prefixes, including one or more public prefixes from ISPs as well as Unique Local Addresses [ULA-ADDRESSES].
The IPv6 prefix that you can specify is /80. The prefix is in the subnet CIDR of the network interface, and does not overlap with other prefixes or IP addresses assigned to existing resources in the subnet. You can assign a prefix to the primary or secondary network interface.
•Target: ISPs deploying IPv6 •Lack of experience or following IPv4 practices bring unexpected or unwanted results -IPv6 "brokenness" = Content providers rejection of your AS -Lack of compliance with new standards such as Homenet •Complete productionnetwork renumbering, etc. BCOP IPv6 Prefix Assignment for end-customers -static, 4
The holders of IPv6 prefixes with a valid reason not to announce their IPv6 prefix within 12 months are encouraged to contact ... Section 6.8.4 of the Consolidated Policy Manual allows End-User members to request for rectification of their initial IPv6 PI assignment if it no longer satisfies their needs. The request will be evaluated by AFRINIC ...
File:IPv6 Prefix Assignment Example-en.svg From Wikimedia Commons, the free media repository File File history File usage on Commons File usage on other wikis Metadata Size of this PNG preview of this SVG file: 695 × 242 pixels. Other resolutions: 320 × 111 pixels | 640 × 223 pixels | 1,024 × 357 pixels | 1,280 × 446 pixels | 2,560 × 891 pixels.