RE: IPv6 allocations for 6RD
3.5. Conservation and Administrative Ease Although IPv6 provides an extremely large pool of address space, historical evidence shows that what now seems infinit might one day turn out to become a scarce resource, Address policies should avoid unnecessarily wasteful practices of such resources. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided. Assignment of address space based on the sole argument of administrative ease is not permitted. Examples of this include, but are not limited to, ease of billing administration and network management.
I strongly agree with the concern that v6 addresses could be depleted quickly. This problem will never be solved appropriately until you impose fees for addresses that increase with the size of the block being requested. What you seem to be learning, the hard way, is that charging nothing for addresses requires you to ration the address space using highly subjective and purely verbal, unquantifiable criteria. Such as, the term "unnecessarily wasteful" which manages to be both tautological and unprecise. Or the term "administrative ease"; ok, after that becomes a policy no one will admit that they are requesting addresses for administrative ease but will that actually alter their request? Appropriately graduated annual fees enforce conservation AND reclamation while relieving the allocator of engaging in these verbal and categorical games Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org
On 1 dec 2009, at 23:02, Milton L Mueller wrote:
3.5. Conservation and Administrative Ease Although IPv6 provides an extremely large pool of address space, historical evidence shows that what now seems infinit might one day turn out to become a scarce resource, Address policies should avoid unnecessarily wasteful practices of such resources. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided. Assignment of address space based on the sole argument of administrative ease is not permitted. Examples of this include, but are not limited to, ease of billing administration and network management.
I strongly agree with the concern that v6 addresses could be depleted quickly.
This problem will never be solved appropriately until you impose fees for addresses that increase with the size of the block being requested. What you seem to be learning, the hard way, is that charging nothing for addresses requires you to ration the address space using highly subjective and purely verbal, unquantifiable criteria. Such as, the term "unnecessarily wasteful" which manages to be both tautological and unprecise. Or the term "administrative ease"; ok, after that becomes a policy no one will admit that they are requesting addresses for administrative ease but will that actually alter their request?
Appropriately graduated annual fees enforce conservation AND reclamation while relieving the allocator of engaging in these verbal and categorical games
Hi Milton, There is already a coupling between charging and allocation size: http://www.ripe.net/ripe/docs/charging2010.html It might not be enough, but then again if we run out policies will be modified eventually like it happend with v4...from /8 to /21 initial in just 30 years. MarcoH
I strongly agree with the concern that v6 addresses could be depleted quickly.
This problem will never be solved appropriately until you impose fees for addresses that increase with the size of the block being requested.
Wrong! We can solve this problem the same way that we solved IPv4 runout. As long as we have IPv9 ready to deploy by 2050, we can avoid any risks of IPv6 addresses running out. And because of the timeline, we can address other issues such as making the minimum MTU 9192, allocating both global unicast and geographical unicast address ranges, upgrading core routing to BGP5extensible, integrating the RIR's PKI and identifier/locator registry into the routing, and so on. We don't even have to start work on the IPv9 design until 2030 or so, which gives plenty of time for people to gain large-scale IPv6 operational experience. --Michael Dillon P.S. Some problems just melt away when you look up and see the context. It's like looking down the barrel of a loaded 45 magnum pointed at you by a hardened criminal, and looking up to see the TV screen in your living room and attached Playstation 3. What looks like a problem, really isn't one.
On 2 Dec 2009, at 12:03, <michael.dillon@bt.com> wrote:
As long as we have IPv9 ready to deploy by 2050, we can avoid any risks of IPv6 addresses running out.
First, I find it staggering that anyone is contemplating -- even in passing -- a replacement for IPv6 and a shopping list of features for that when the level of IPv6 uptake is so low. It's unwise to assume there is no risk of IPv6 addresses running out. The same mistake was made ~25 years ago when ARPAnet transitioned from NCP to IP. A 32-bit address space was then considered too big to fill. ISTR similar claims being made when 32-bit and 64-bit CPUs were introduced: nobody could ever use all of that address space. The same goes for disks. These are almost always full, no matter how big they get. A variant of Parkinson's Law probably applies here, namely bloat and inefficiency will always expand to fill or exceed whatever addressing capability is provided. Remember too that since each customer will in all probability get a / 64 from their ISP, the effective size of the IPv6 address space in the core of the network is 64 bits. It's still a very big number: just not as big as first thought. And that won't last long if the world and its dog gets a /24 or more for 6RD or whatever...
We don't even have to start work on the IPv9 design until 2030 or so, which gives plenty of time for people to gain large-scale IPv6 operational experience.
Assuming there is wide-scale IPv6 deployment and usage by then. BTW if your claims are correct, this presumes the IETF can complete the development of IPv9 in 20 years. Which seems... well... optimistic. :-) The DNSSEC protocol been chugging through the IETF machine for over 10 years.
First, I find it staggering that anyone is contemplating -- even in passing -- a replacement for IPv6 and a shopping list of features for that when the level of IPv6 uptake is so low.
Some of us are dreamers and wonder what could be done if we could just sweep away the old. If you look at history, sweeping away the old does happen from time to time. Stroll down London's Regent Street and there is not a trace of the squalid slum that was there before the Prince Regent swept it away. On most Central London streets you can still see the traces of the medieval city in the layout and size of the buildings. But not on Regent Street. There are some serious researchers also doing work on redesigning the Internet from scratch. Perhaps the reason for doing this is BECAUSE the uptake of IPv6 is currently so low, and BECAUSE we realize that many of the reasons for this is that IPv6 ideas were tacked onto the IPv4 network and therefore we won't get the benefit of those ideas from upgrading. This lays bare all the inadequacies of IPv6 and people naturally look for ways to remove those inadequacies but replacing IPv6 is not currently feasible. Also, it is likely that a new generation of engineers without the baggage of IPv4, will be better able to make a fresh start on IPv9.
It's unwise to assume there is no risk of IPv6 addresses running out.
That's what I said. Since there is a risk of it running out in 100 years or so, we should plan to create a better replacement for it in 30-50 years, and avoid the whole issue.
The same mistake was made ~25 years ago when ARPAnet transitioned from NCP to IP. A 32-bit address space was then considered too big to fill.
The arithmetic was rather different in those days. You really should read Geoff Huston's. One source of these numbers is this ARIN presentation <https://www.arin.net/participate/meetings/reports/ARIN_XV/PDF/wed/Round _Table.pdf> We really should ask Geoff to revisit the numbers in light of 6RD and the larger allocations that might happen. I get the sense that this would not cause a problem as long as we assume that 6RD will be decommissioned within 5 to 10 years. There is no point in discussing possible runout without some actual figures in the discussion because IPv4 and IPv6 are several orders of magnitude different. It becomes obvious when you work through the figures.
Remember too that since each customer will in all probability get a / 64 from their ISP,
No, a /56 or /48
the effective size of the IPv6 address space in the core of the network is 64 bits.
IPv6 addresses are 128 bits everywhere. The core uses full addresses.
BTW if your claims are correct, this presumes the IETF can complete the development of IPv9 in 20 years. Which seems... well... optimistic. :-)
I never mentioned IETF. In any case, the people who do the work 30 years from now will not be the same people who did the IPv6 work. --Michael Dillon
On Wed, Dec 2, 2009 at 6:53 AM, <michael.dillon@bt.com> wrote:
of 6RD and the larger allocations that might happen. I get the sense that this would not cause a problem as long as we assume that 6RD will be decommissioned within 5 to 10 years.
You are assuming that address space will be returned when 6RD is decommissioned? That doesn't sound likely to me.
Lorenzo Colitti a écrit :
On Wed, Dec 2, 2009 at 6:53 AM, <michael.dillon@bt.com> wrote:
of 6RD and the larger allocations that might happen. I get the sense that this would not cause a problem as long as we assume that 6RD will be decommissioned within 5 to 10 years.
You are assuming that address space will be returned when 6RD is decommissioned? That doesn't sound likely to me.
1. As a matter of fact, it would not even need to be decommissioned in most cases: - If an ISP has only one IPv4 prefix, it doesn't need a more generous prefix than /32 for 6rd. There is nothing to be decommissioned. - If it has several IPv4 prefixes, but also an installed base of more than 64K customers (or a short term plan to have it), then, to assign /48s to its customers as currently recommended, it deserves from its RIR a more generous prefix than a /32 anyway (even when 6rd is replaced by native IPv6 routing). No need to decommission. It is only for those that still have several IPv4 prefixes an no short term plan to exceed 64K customers that the need to decommission would exist. This makes it a secondary consideration. It may IMHO be ignored. 2. IPv6 introduced TTLs of assigned prefixes so that, combined with DNS dynamic updates, renumbering becomes realistic. Some ISPs, when they get a more generous prefix than before, e.g. going from a /32 to a /28, may therefore prefer, after some coexistence delay, to route only on the shorter prefix. They can then be decommissioned without problem. This simplifies their network, and helps keeping tier-1 routing tables short. Regards, RD
On Dec 2, 2009, at 4:03 AM, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
We can solve this problem the same way that we solved IPv4 runout.
Heh. We haven't solved IPv4 runout. We've largely investigated interesting geometries we can rearrange the deck chairs into on the Titanic. As far as I can tell, the jury is still out as to whether IPv6 will win over IPv4 + multilayer NAT.
As long as we have IPv9 ready to deploy by 2050, we can avoid any risks of IPv6 addresses running out.
One of the reasons IPv6 has had some difficulty getting off the ground is due to the large installed base of IPv4 that sees no particular benefit in moving to IPv6. IPv4 is now a core component of critical infrastructure all over the planet. Switching out critical global infrastructure is not something that is trivially done; you need deployable transition plans, business cases, backwards compatibility, etc., all stuff that was not really addressed with IPv6 because it is really, really hard. And (assuming IPv6 does win) you're suggesting that after we've spent half a century of deploying critical infrastructure globally on IPv6 that we'll just go and redeploy IPv9? Are you assuming the Singularity will have been reached and a god-like AI will solve the problems for us? Regards, -drc
participants (7)
-
David Conrad -
Jim Reid -
Lorenzo Colitti -
Marco Hogewoning -
michael.dillon＠bt.com -
Milton L Mueller -
Rémi Després