IETF IPv6 address allocation policy being updated.

IETF is now backtracking on /48 IPv6 address allocation by letting anyone do what the hell they like ( to some extent, this got us into a lot of the problems we have today). The following RFC Draft is dated 3rd Jan 2011.

< blockquote>draft-ietf-v6ops-3177bis-end-sites-01: ” RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. 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 reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original 3177 recommendations. Moreover, the document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.

The justification for the change is in the summary:

The IETF recommends that any policy on IPv6 address assignment policy to end sites take into consideration: – it should be easy for an end site to obtain address space to number multiple subnets (i.e., a block larger than a single /64) and to support reasonable growth projections over long time periods (e.g., a decade or more). – the default assignment size should take into consideration the likelihood that an end site will have need for multiple subnets in the future and avoid the IPv4 practice of having frequent and continual justification for obtaining small amounts of additional space – Although a /64 can (in theory) address an almost unlimited number of devices, sites should be given sufficient address space to be able to lay out subnets as appropriate, and not be forced to use address conservation techniques such as using bridging. Whether or not bridging is an appropriate choice is an end site matter. – assigning a longer prefix to an end site, compared with the existing prefixes the end site already has assigned to it, is likely to increase operational costs and complexity for the end site, with insufficient benefit to anyone. – the operational considerations of managing and delegating the reverse DNS tree under on nibble vs. non-nibble boundaries should be given adequate consideration

The EtherealMind View

* end user people must be whining that /64 isn’t enough.
* people who issue addresses are whining that /48 is too much.
* since there is so many IPv6 addresses, conservation is hardly a problem.
* let them eat cake.

Good with that. Shutup and make it so. The IPocalypse is upon us and we must show no fear. And if Geoff Huston says so, I believe it.

Other Posts in A Series On The Same Topic

  1. Why Allocating a /64 is Not Wasteful and Necessary (23rd January 2011)
  2. IPv6 - /48 allocation in /64 chunks - that's a lot of addresses (21st January 2011)
  3. IPocalypse: What's next for the 'End of the Internet' ? (20th January 2011)
  4. The IPocalyse is Nigh - Forced Allocation of IPv4 to RIRs next week ? (19th January 2011)
  5. IETF IPv6 address allocation policy being updated. (12th January 2011)
  6. Scheduling the IPocalypse (25th November 2010)
  • Matt Simmons

    I guess I don’t understand the problem….

    With every site getting a /48, and the standing acceptance of /64 as a subnet mask, did someone, somewhere think that they’d need more than 2^16 subnets, or more than 2^64 addresses in those subnets?

    I mean, in a far away future where _everything_ has multiple IP addresses…even the idea of using more than (or even close to) 2^80 addresses is pretty far fetched. Smart dust indeed.

  • Jani Ekman

    Whatabout then multihomed hosts than obviously require IPv6 addresses from different subnets? Or is the IANA logic here that these would shown as own sites then?
    For some reason I think that having IPv6 addresses of such hosts on server side from a single /48 or even /64 subnet does not make much sense, or does it.

  • Josh

    @Matt Simmons: I don’t think the issue here is people are wanting more than a /48, I think the problem is that the ISPs are starting to give out /64s instead of /48s. This RFC seems to be caving in to pressure from the ISPs who for whatever reason don’t want to give out /48s. It’s basically saying “do what you want, but here’s our opinion”.

    Personally, I don’t want to have to introduce some kind of bridging or NAT scenario in my networks simply because my ISP decided that /64 should be sufficient. Perhaps /48 is too much for many networks, but certainly a single /64 is not enough. I think a /56 would probably do for most small-to-mid size networks, and would be a decent compromise.

    @Greg: Who’s eating the cake here? The whining ISPs or the whining customers? I’d say the more appropriate response is to split the baby in two 😉

  • Greg Ferro

    I think that someone hasn’t thought about it. They’ve taken the restrictions on IP Address allocation from IPv4 and applied them to IPv6 and tried to be restrictive about how many addresses to give out. The people who allocate IP addresses at Service Providers aren’t very bright, and it’s highly probable that no one has taken the time to change the procedures. So I can easily imagine some bureaucrat who issues address saying “you can only have a /64 so we can save addresses”.

    A more evil scenario ? ISPs want to stretch out their investment and by restricting the the routes in the network they can delay backbones upgrades to hold the full routing table. Remember that a router must hold an IPv4 table and (unless they have a separate IPv6 backbone which is highly unlikely) and the IPv6 table. This way they can hold back the tide.

    Tkae your choice of those.

  • Pingback: IPv6 ñ /48 allocation in /64 chunks ñ thatís a lot of addresses ñ My Etherealmind()