Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
I'm comfortable with IPv4 address space allocations. By which I mean: Given services to plan for, or an organization to network, I have a good grasp of how to plan IP address space usage. (or at least, I think I do. :)
Are there any best practices guidance, or case studies, for IPv6 address space layout?
The layout that we are using for our rollout is:
These sizes are mostly taken from the RIPE advisory here.
The old recommendation was to use /64 everywhere even on P2P links and assign a /48 per site.
Using large, empty subnets on point-to-point links can lead to a number of potential security issues, (see RFC6164,) so it's now best practice to use a /127 for P2P links and /128 for loopbacks.
It's not necessary to give a small customer a /48 although you would have plenty addresses to go around if you choose to do so.
Interfaces that are facing customers should be /64 if you want to use SLAAC. If you don't intend to use it you can use another mask.
Here are some good links to go through:
BRKRST-2301 from ciscolive365.com (create free account)
http://www.cisco.com/web/strategy/docs/gov/IPv6_WP.pdf
https://www.rfc-editor.org/rfc/rfc5375.html
https://www.rfc-editor.org/rfc/rfc6177
Some people take their current v4 assignments and convert second and third octet into hex and use that for v6. There are lots of different ways of doing it so you have to choose what feels best.
With IPv6 you no longer have to worry about allocating space for a given number of hosts. All subnets (other than P2P links) should be assigned as a /64 which gives you a ridiculous number of host addresses. This frees you to focus on other topics such as good network layout & design. (A /48 would give you 65,536 /64 networks)
There are (of course) several schools of thought on this. If you are already pretty happy with your IPv4 design, then doing a IPv6 overlay that mirrors things is probably a good option and eases the transition for everyone.
Play around with some of the IPv6 calculators to help you get your head around all of this. Here is an example one: GestioIP Online IPv4/v6 Calculator
This was the hardest thing for me to get over - don't worry about allocating space for hosts! Plan your network -- focus on locations of layer-3 boundaries, services offered, physical location of devices, etc. It is probably going to be years before you have a pure IPv6 network, but you will begin laying the groundwork of good network design now.
A little precision to earlier responses, based on the RIPE IPv6 training session I had a year ago. Basically their recommendation is to focus on aggregation rather than address space preservation.
That is : don't worry to reserve a large amount of IPs for a Point of Presence even if you only have small amount of subnets here (for now). But you should aggregate every subnet "living" in a POP under the same bigger prefix.
Their main concern, now that we have a very large amount of IP at our disposal, is that if everyone announces small prefixes with a fine granularity, the size of the DFZ routing table might explode.
Here is the training material used in the presentation. Especially the first "Training exercise" PDF gives some example of an addressing plan.
In use the following layout myself (datacenter pov)
Colocation customers: one /48.
Dedicated servers: one /64 per server by default.
P2P links (bgp linknets, and so on): /126
As for the IPv4 -> IPv6 transition to a dual stack environment for hosted vlans I match the ipv4 subnet to an ipv6 subnet which is large enough, to contain a /64 for every single ipv4 address.
For example:
Vlan containing one /24 ipv4 (256 ip's), I match that with a /56 Ipv6 (256 unique /64 subnets)
Vlan containing one /23 ipv4 (512 ip's), I match that with a /55 ipv6 (512 unique /64 subnets)
SURFnet wrote a nice IPv6 network plan manual that might be useful
It's a bit intimidating when you see the huge address space available, but in practice, it's not hard to deal with.
Let's say you are allocated a /48. That gives you 65K /64s to play with, each capable of holding rather a lot of addresses. Also the rounding error in 65K gives you a slack handful of other /<64 for other uses.
Personally speaking I call off /64 subnets from the /48 per VLAN. I set the router address as </64>::1 for each VLAN. I use </64>::xxxx for DNS (where xxxx is a repeated digit) and similar for a few other services. It's easier to remember.
Each box gets a SLAAC allocated address and all hosts are encouraged to also set a temporary address. This way we can find a system using the SLAAC address but the system retains a little privacy on the internet - or it would but we generally use a web proxy - ahh but that has a temporary address as well! Still, the ubiquity of IPv4 makes all this moot.
If you have multiple sites then break up the /48 into smaller bits but larger than /64 - enough to cover all eventualities. This will allow you to aggregate routing tables somewhat.
Frankly, assuming you DO have a /48 (I have one for my home, so I don't doubt it) then you should have enough space to cover most eventualities and schemes.
Now, if your setup is bigger - say multi-national and multi site then I suggest you investigate PI and then break that up by country/site/VLAN or country/locality/site/building/VLAN or whatever. You still get plenty of addresses in a /48 for all but the largest set up.
Some network device architectures assume that most of your prefixes will be /64's. Check this column in Ivan Pepelnjak's blog for more info.
The biggest concern is likely to identify where your bottlenecks are going to be, in terms of route aggregation. The basic parameters are likely going to be: each subnet must be a /64 (dictated by IPv6), and you have a /60, /56, or /48 to play with.
As others have said, a /48 gives you 64k subnets, but it's still easy to paint yourself into a corner if you just assign them randomly. Let's say you have 1000 store locations, and give each one a /64 sequentially from the start. Then you find out that the 43rd store needs a second subnet - that means, either renumbering that network, or giving the store two separate subnets that can't be aggregated.
Incidentally, in the IPv4 world, you also get 64k subnets if you use the 10.x.x.x network and subnet it to /24s. Some of the practices you use in that scenario may translate nicely.
One company I work for uses 10.x.x.x internally for about 150 branch offices (with some 100-500 computers at each location). The second byte is the branch number, and they use /22 instead of /24 for their subnets. So each branch office can have up to 64 subnets, which works nicely for them.
IPv6 address space layout best practices
I'm comfortable with IPv4 address space allocations. By which I mean: Given services to plan for, or an organization to network, I have a good grasp of how to plan IP address space usage. (or at least, I think I do. :)
Are there any best practices guidance, or case studies, for IPv6 address space layout?
Super short answer: Starting at /56 try to project what will be used in the next several years and adjust up or down accordingly. People requesting a single address should still have a few allocated for future expansion, avoiding allocation fragmentation is important, moreso than slight over-allocation.
A longer answer:
Internet Engineering Task Force (IETF) - Best Current Practices:
1. Introduction - There are a number of considerations that factor into address assignment policies. For example, to provide for the long-term health and scalability of the public routing infrastructure, it is important that addresses aggregate well [ROUTE-SCALING]. Likewise, giving out an excessive amount of address space could result in premature depletion of the address space. This document focuses on the (more narrow) question of what is an appropriate IPv6 address assignment size for end sites. That is, when end sites request IPv6 address space from ISPs, what is an appropriate assignment size.
...
This document focuses on the (more narrow) question of what is an appropriate IPv6 address assignment size for end sites. That is, when end sites request IPv6 address space from ISPs, what is an appropriate assignment size.
...
This document does not make a formal recommendation on what the exact assignment size should be. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document provides input into those discussions.
...
2. On /48 Assignments to End Sites - Looking back at some of the original motivations behind the /48 recommendation [RFC3177], there were three main concerns. The first motivation was to ensure that end sites could easily obtain sufficient address space without having to "jump through hoops" to do so. For example, if someone felt they needed more space, just the act of asking would at some level be sufficient justification.
As a comparison point, in IPv4, typical home users are given a single public IP address (though even this is not always assured), but getting any more than one address is often difficult or even impossible -- unless one is willing to pay a (significantly) increased fee for what is often considered to be a "higher grade" of service. (It should be noted that increased ISP charges to obtain a small number of additional addresses cannot usually be justified by the real per-address cost levied by RIRs, but additional addresses are frequently only available to end users as part of a different type or "higher grade" of service, for which an additional charge is levied. The point here is that the additional cost is not due to the RIR fee structures, but to business choices ISPs make.)
An important goal in IPv6 is to significantly change the default and minimal end site assignment, from "a single address" to "multiple networks" and to ensure that end sites can easily obtain address space.
...
A change in policy (such as above) would have a significant impact on address consumption projections and the expected longevity for IPv6. For example, changing the default assignment from a /48 to /56 (for the vast majority of end sites, e.g., home sites) would result in a savings of up to 8 bits, reducing the "total projected address consumption" by (up to) 8 bits or two orders of magnitude. (The exact amount of savings depends on the relative number of home users compared with the number of larger sites.)
...
3. Other RFC 3177 Considerations - ... Given the large amount of address space in IPv6, there is plenty of space to grant end sites enough space to be consistent with reasonable growth projections over multi-year time frames. Thus, it remains highly desirable to provide end sites with enough space (on both initial and subsequent assignments) to last several years. Fortunately, this goal can be achieved in a number of ways and does not require that all end sites receive the same default size assignment.".
Abstract - IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length.
Introduction - "Unlike IPv4, IPv6 networks are not forced by address scarcity concerns to provide only one address per host. ... Furthermore, providing multiple addresses has many benefits, including application functionality and simplicity, privacy, and flexibility to accommodate future applications. Another significant benefit is the ability to provide Internet access without the use of Network Address Translation (NAT). Providing only one IPv6 address per host negates these benefits.
2. Common IPv6 Deployment Model - IPv6 is designed to support multiple addresses, including multiple global addresses, per interface (see Section 2.1 of [RFC4291] and Section 5.9.4 of [RFC6434]). Today, many general-purpose IPv6 hosts are configured with three or more addresses per interface: a link- local address, a stable address (e.g., using 64-bit Extended Unique Identifiers (EUI-64) or Opaque Interface Identifiers [RFC7217]), one or more privacy addresses [RFC4941], and possibly one or more temporary or non-temporary addresses obtained using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315].
In most general-purpose IPv6 networks, hosts have the ability to configure additional IPv6 addresses from the link prefix(es) without explicit requests to the network. Such networks include all 3GPP networks ([RFC6459], Section 5.2), in addition to Ethernet and Wi-Fi networks using Stateless Address Autoconfiguration (SLAAC) [RFC4862].".
3. Design Goals
- Stateless autoconfiguration is designed with the following goals in mind: o Manual configuration of individual machines before connecting them to the network should not be required. ... Address autoconfiguration assumes that each interface can provide a unique identifier for that interface (i.e., an "interface identifier"). ...
- Small sites consisting of a set of machines attached to a single link should not require the presence of a DHCPv6 server or router as a prerequisite for communicating. Plug-and-play communication is achieved through the use of link-local addresses. Link-local addresses have a well-known prefix that identifies the (single) shared link to which a set of nodes attach. A host forms a link- local address by appending an interface identifier to the link- local prefix.
- A large site with multiple networks and routers should not require the presence of a DHCPv6 server for address configuration. In order to generate global addresses, hosts must determine the prefixes that identify the subnets to which they attach. Routers generate periodic Router Advertisements that include options listing the set of active prefixes on a link.
- Address configuration should facilitate the graceful renumbering of a site's machines. For example, a site may wish to renumber all of its nodes when it switches to a new network service provider. Renumbering is achieved through the leasing of addresses to interfaces and the assignment of multiple addresses to the same interface. Lease lifetimes provide the mechanism through which a site phases out old prefixes. The assignment of multiple addresses to an interface provides for a transition period during which both a new address and the one being phased out work simultaneously.
Security Considerations:
- Generic Security Considerations
2.1. Addressing Architecture
IPv6 address allocations and overall architecture are an important part of securing IPv6. Initial designs, even if intended to be temporary, tend to last much longer than expected. Although initially IPv6 was thought to make renumbering easy, in practice, it may be extremely difficult to renumber without a good IP Addresses Management (IPAM) system.
Once an address allocation has been assigned, there should be some thought given to an overall address allocation plan. With the abundance of address space available, an address allocation may be structured around services along with geographic locations, which then can be a basis for more structured security policies to permit or deny services between geographic regions.
A common question is whether companies should use PI vs PA space RFC7381], but from a security perspective there is little difference. However, one aspect to keep in mind is who has administrative ownership of the address space and who is technically responsible if/when there is a need to enforce restrictions on routability of the space due to malicious criminal activity. Using PA space exposes the organization to a renumbering of the complete network including security policies (based on ACL), audit system, ... in short a complex task which could lead to some security risk if done for a large network and without automation; hence, for large network, PI space should be preferred.
Other References:
ARIN - "Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments".
ARIN - "Draft Policy ARIN-2011-3: Better IPv6 Allocations for ISPs".
IANA - Main Page - Protocol Registries - IANA-managed Reserved Domains.
IETF - "Considerations on the IPv6 Host density Metric - draft-huston-hd-metric-00.txt".
Wikipedia's Best Current Practices (Currently not up to date).
APNIC - "IPv6 Best Current Practices".
Cloudmark's Whitepaper: "BCP for Near Term SMTP Deployments in IPv6 Networks".
NSRC.org - "Ingress & Egress Filtering Lab - Campus Network Design & Operations Workshop".
RIPE - "IPv6 Address Allocation and Assignment Policy" says (amongst many other things): "The minimum allocation size for IPv6 address space is /32. (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.", "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.", ...
RIPE - "Understanding IP Addressing and CIDR Charts" (also see below) offers these helpful charts:
The original architecture of the Internet consisted mostly of large networks connecting to each other directly, and didn't look much like the hierarchical design used today. It was easy to give one huge address block to the military and another to Stanford University. In that model, routers had to remember only one IP address for each network, and could reach millions of hosts through each of those routes.
Here is an old map of the entire Internet in February 1982 compared with the Internet of today, StackExchange.com is the tiny dot in the center of the right image, click to zoom way in.
RFC 3484 - "Default Address Selection for Internet Protocol version 6 (IPv6)" was obsoleted by RFC 6724 (Sept 2012), new in the update is:
"Sections 2.1.4, 2.2.2, and 2.2.3 of RFC 5220 describe address selection problems related to Unique Local Addresses (ULAs) [RFC4193]. By default, global IPv6 destinations are preferred over ULA destinations, since an arbitrary ULA is not necessarily reachable.".
See: RIPE - "Understanding IP Addressing and CIDR Charts":
"Every device connected to the Internet needs to have an identifier. Internet Protocol (IP) addresses are the numerical addresses used to identify a particular piece of hardware connected to the Internet.
The two most common versions of IP in use today are Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). Both IPv4 and IPv6 addresses come from finite pools of numbers.
For IPv4, this pool is 32-bits (2^32) in size and contains 4,294,967,296 IPv4 addresses.
The IPv6 address space is 128-bits (2^128) in size, containing 340,282,366,920,938,463,463,374,607,431,768,211,456 IPv6 addresses.
Address Allocation Model
Currently, IANA allocates address blocks to the regional registries. The registries in turn assign address blocks to service providers. It is the service provider’s responsibility to hand out addresses to their respective customers.
The current policy varies by region and in the most conservative case dictates that an end user must go through the user’s service provider to get IPv6 address space rather than directly approaching the regional registry for IPv6 address space.
The figure graphically represents how this initial policy is enacted. This assignment model is commonly referred to as a provider assigned (PA) or provider dependent (PD) assignment. The prefix lengths that are shown in the figure are recommendations. The registries and service providers can assign blocks using the processes and procedures that they have established for their regions and customers. This is explained in RFC 6177.
RFC 6177 - "IPv6 Address Assignment to End Sites".
As an example of the policy, IANA has assigned 2600:0000::/12 to ARIN for assignment. This aligns with the top layer of the model. ARIN subsequently has assigned 2600::/29 block to Sprint, 2600:300::/24 to AT&T Mobility, 2600:7000::/24 to Hurricane Electric, etc.
These block assignments do not follow the original model defined in RFC 3177. The service providers subsequently assign blocks to their customers based on their customers’ needs. The Internet service provider (ISP) has the flexibility to assign a wide range of addresses to its customers.
For example, a large enterprise ISP customer might need a /40 assignment while a residential customer would only need a /60 assignment.
There is an exception to this policy enacted by the regional registries that allows end customers to directly approach registries and request IPv6 address space. This exception is known as provider independent (PI) addressing.
RFC 5375 - "IPv6 Unicast Address Assignment Considerations" outlines some issues that also need to be taken into account when building an addressing plan.
You should first decide if you want provider independent address blocks or is provider assigned addressing acceptable?
If the customer has PI addresses the assignment will remain valid providing the criteria for the original assignment are met.
Customers with PA addresses are recommended to obtain a new address space assignment from another LIR and return the PA address space that was assigned by their original LIR. In this
There's more, consulting the IANA and IETF links above is the best way to stay on top of the best practices.
The best way of dividing ipv6 is into /64 subnets. because /64 address can be easily mapped to IPV4 manually
The main differences between v4 and v6
Beyond that it shouldn't be much different from v4, figure out what subnets you need, figure out what logical groupings they fall into and how much room for future expansion you want at each level and start putting together a plan.
