up a few thousand meters
the rirs, as the meeting place of those responsible for prudent operation of the network, have traditionally been where the compromise between the three *competing* and *conflicting* vectors of o address space conservation, o routing table growth, and o ease of allocation for isps have responsibly reached compromise. this has not been an easy balance because the three really are in conflict with each-other. but, as prudent operators, and as shepherds of a public good, we have struggled along to manage in a really pretty responsible fashion. witness that one can get and use the ip space one needs, the routing table has not gotten completely unmanageable (especially if you filter prudently <g>), and there is a fair amount of v4 space left. as we move into the v6 world, prudent folk find it hard not to assume that the same or similar forces will be at work. v6 gives us zero leverage on the routing table expansion problem. there is no reason to believe that the seemingly enormous 128 bit address space of v6 will turn out to be any more infinite than the seemingly enormous 32 bit address space did some decades ago. and, as operators, we still have the annoying problems and responsibilities of acquiring, tracking, allocating, ... the address space which is vital to our businesses. in moving forward, it would seem irresponsible to let one consideration obviate all others. e.g. some once thought tlas would solve the routing table growth issue by limiting the global universe to 8k isps. this month, others think ease of allocation is most important, and the problems of address consumption and routing table growth are old-fashioned fears. sadly, as we have discovered in exploring the issues of multi-homing and routing table growth, and as we learned that frequent and rapid renumbering may not be the realities, we seem to need to be a bit cautious about the new world, and not leap to bold conclusions and make radical changes based on yet to be proven assumptions. as isps, in our rush to make life easy for ourselves at the possible expense of other considerations, let us not again demonstrate george santayana's wisdom by repeating history, again creating a swamp, losing track of detailed allocation data, ... as far as i can tell, v6 deployment is not being inhibited by issues surrounding address space allocation. randy
**** Please read Randy's message - again - and once more. I follow the discussions from even higher up than Randy ;-) but they give me a very disturbing and sometimes discouraging sense of deja-vu. Please consider the following -again: - address space, however large, is never quite as infinite as it may seem - V6 per-se does *not at all* solve the routing (table) problem - proper trade-offs between conservation, aggregation and ease of obtaining address space are curcuial, but not easily achieved/agreed and vary with time as technology develops - proper registration data is *crucial* for problem tracking and *security*, read: routing authentication - you can only usefully keep registration data at a neutral registry - it is *extremely hard* to clean up registration data that has not been properly collected and/or maintained We have learned most of this by experience, let's not unlearn it. Daniel
On Tue, 12 Feb 2002, Daniel Karrenberg wrote:
- V6 per-se does *not at all* solve the routing (table) problem
That's true in a technical sense. However, there are a few reasons why we, even though IPv6 does not solve the problem, _can_ solve it: 1) organizations, however large, can be represented by one "dot", a /48. This enables us, at worst, to have O(organizations) routing table entries, not O(organizations * average number of nodes per organization). The former is too big still, but it is still good news and makes aggregation and address space estimations easier. 2) it's all new protocol -- not a win as such, but due to this, we can _reinvent_ the routing system (within some restrictions) the way we see fit, based on earlier experience. Let's not pretend 2) does not exist. There are 6bone routing guidelines, which have been happily adapted by production operators (sTLA) also; they prevent most of the problems we're now facing with IPv4 global routing table growth. Why toss all of that aboard, pretending we cannot work around the routing problem for now when moving to IPv6 (note: I didn't say IPv6 would magically solve the problem!)? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
2) it's all new protocol -- not a win as such, but due to this, we can _reinvent_ the routing system (within some restrictions) the way we see fit, based on earlier experience.
Let's not pretend 2) does not exist.
the possibility to invent does exist. useful inventions do not. and it's almost ten years we've been discussing them.
Why toss all of that aboard, pretending we cannot work around the routing problem for now when moving to IPv6
because my routers do not have a 'pretend' mode and i know of no router vendors testing such a mode. randy
On Tue, 12 Feb 2002, Randy Bush wrote:
Why toss all of that aboard, pretending we cannot work around the routing problem for now when moving to IPv6
because my routers do not have a 'pretend' mode and i know of no router vendors testing such a mode.
Our routers' 'pretend' mode is called route filtering. Perhaps you've heard of it too. There are no problems with route filtering at e.g. sTLA /32 boundary _if_ RIR's would be adamant in their policies not to give a /32 or shorter out to people that don't need them. And once 6bone pTLA's are killed, the table would be clean. .. with IPv4, it's too late to start filtering in significant-enough boundaries like /16-/19.. let's not make the same mistake here. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
-----Original Message----- From: owner-global-v6@lists.apnic.net [mailto:owner-global-v6@lists.apnic.net]On Behalf Of Pekka Savola Sent: Tuesday, February 12, 2002 6:33 AM To: Randy Bush Cc: Daniel Karrenberg; global-v6@lists.apnic.net; ipv6-wg@ripe.net Subject: Re: [GLOBAL-V6] Re: up a few thousand meters
On Tue, 12 Feb 2002, Randy Bush wrote:
Why toss all of that aboard, pretending we cannot work around the routing problem for now when moving to IPv6
because my routers do not have a 'pretend' mode and i know of no router vendors testing such a mode.
Our routers' 'pretend' mode is called route filtering. Perhaps you've heard of it too.
There are no problems with route filtering at e.g. sTLA /32 boundary _if_ RIR's would be adamant in their policies not to give a /32 or shorter out to people that don't need them.
There is the crux of the problem with the originally suggested change of allowing any LIR to get a /32. The RIR's under that policy don't look at need but at membership. So people who don't "need" them can still get them by becoming a member. Of course "Need" is often a subjective thing to measure John Crain
John (and others), Here's a piece of Gert's original message about the discussion at RIPE 41: | - any LIR that is established (has done all the paperwork, paid their | fees, and whatnot) and can document the need for one IPv6 address | can get a /32. No further justification required. I read that to mean that address usage/need would still have to be documented. Maybe it needs to be clarified... I hope this helps. Pierre. On Tue, 12 Feb 2002, John L Crain wrote: [snip]
There is the crux of the problem with the originally suggested change of allowing any LIR to get a /32. The RIR's under that policy don't look at need but at membership. So people who don't "need" them can still get them by becoming a member.
Of course "Need" is often a subjective thing to measure
John Crain
Hi Pierre Note that this is the documentation of 0ne (singular) IPv6 address. i.e. "I have a host." *Not* documentation of a need to number an IPv6 network. John Here's a piece of Gert's original message about the discussion at RIPE 41: | - any LIR that is established (has done all the paperwork, paid their | fees, and whatnot) and can document the need for one IPv6 address | can get a /32. No further justification required. I read that to mean that address usage/need would still have to be documented. Maybe it needs to be clarified... I hope this helps. Pierre. On Tue, 12 Feb 2002, John L Crain wrote: [snip]
There is the crux of the problem with the originally suggested change of allowing any LIR to get a /32. The RIR's under that policy don't look at need but at membership. So people who don't "need" them can still get them by becoming a member.
Of course "Need" is often a subjective thing to measure
John Crain
- - This list (global-v6) is handled by majordomo@lists.apnic.net
**** Please read Randy's message - again - and once more.
I second this. Strongly. Pekka Savola <pekkas@netcore.fi> writes:
However, there are a few reasons why we, even though IPv6 does not solve the problem, _can_ solve it:
1) organizations, however large, can be represented by one "dot", a /48. This enables us, at worst, to have O(organizations) routing table entries, not O(organizations * average number of nodes per organization). The former is too big still, but it is still good news and makes aggregation and address space estimations easier.
I don't understand this comment at all. An O(organizations) size routing table does not appear supportable in practice. How is one result (that doesn't work) any better than another result that also doesn't work?
2) it's all new protocol -- not a win as such, but due to this, we can _reinvent_ the routing system (within some restrictions) the way we see fit, based on earlier experience.
Until someone has a proposal on the table for which there is some reasonable sense within the community that it might actually work, the only prudent thing to do *today* is assume we only have what exists *today*. One thing we want to be very careful about is putting in place policies that we know are risky for the long term and would be hard to reverse down the road without recreating a a haves vs. have nots situation again. Thomas
One thing we want to be very careful about is putting in place policies that we know are risky for the long term and would be hard to reverse down the road without recreating a a haves vs. have nots situation again.
sure could be viewed as all the folk present in the 'room' wanting to vote themselves immediate 'haves', make another super-swamp, and screw the future (some technology will come along to save us from the mess we make). let's all go drill for v6 address space in the alaskan refuge. randy
On Thu, 14 Feb 2002, Thomas Narten wrote:
However, there are a few reasons why we, even though IPv6 does not solve the problem, _can_ solve it:
1) organizations, however large, can be represented by one "dot", a /48. This enables us, at worst, to have O(organizations) routing table entries, not O(organizations * average number of nodes per organization). The former is too big still, but it is still good news and makes aggregation and address space estimations easier.
I don't understand this comment at all. An O(organizations) size routing table does not appear supportable in practice. How is one result (that doesn't work) any better than another result that also doesn't work?
Sorry for being unclear; I didn't mean global routing table here. What I meant is that /48 allocations make the job of an ISP much easier: the size of required address space is set by the number of customers, not their size; address space estimation is easier, and (hopefully) one block would suffice for an ISP for a long time, so global routing table would not be swamped by a number of prefixes per ISP either and aggregation would be easier.
One thing we want to be very careful about is putting in place policies that we know are risky for the long term and would be hard to reverse down the road without recreating a a haves vs. have nots situation again.
I feel that if we want results, we need more policies to cope with all the corner case.. 1) something like modified Gert Doering's solution. This would only be applied to _ISP's_ with _previous experience with allocations_ (e.g. with IPv4), and can surely be shown to be an ISP. If the fact that isp X applied for space was public, this could be put under public review too. 2) alternative policy for new players in the field which have no previous ISP experience with IPv4 or whatever. They would just have to show some plans how they propose to spend their /32, like with Narten et al's global suggested policy. There are not all that many of these. Do we need to tear our hair before we have to? 3) 1 and 2 which need a bigger space need to justify it with e.g. via mechanisms in suggested global v6 policy -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
participants (6)
-
Daniel Karrenberg -
John L Crain -
Pekka Savola -
Pierre Baume -
Randy Bush -
Thomas Narten