On Mon, Apr 04, 2005 at 10:40:36AM +0200, JORDI PALET MARTINEZ wrote:

Agree, let's go the 200 customers, but keep the /48. Otherwise in order to be coherent, lets change RFC3177 also (which I will not agree).

...

De: Jeroen Massar <jeroen@unfix.org>

The 200 thing can go indeed. The /48, which is the minimum assignment towards that endsite must stay. Otherwise there will be ISP's who are going to give out /56's, /58's, /60's, /62's etc.

The reason for the _minimum_ of a /48 is that when you want to change over to another ISP that you can get the equally sized /48. Or do you want to get, say, 3 IPv6's IP's from your upstream ISP?

If you are so extremely big that you need multiple /48's (which contain 65k /64's as you will know) you are also more than capable of getting your own TLA under the new proposed #gamma policy, and most people will most likely going to just that for a large amount of reasons, especially because they simply want 'an entry in the routing table'...

I'm just not sure this is something we want to be setting in stone. Granted once clause 'd' about 200 assignments is gone, the requirement to assign /48s would no longer seem to be an obstacle for LIRs' allocation request. However, logic still stands that even though one size (/48) may be big enough to contain just about all end-site networks it almost certainly doesn't fit them all. I agree wholeheartedly that RFC3177 should stay. However, RFC3177 contains a recommendation as to how to assign your address space, and we already draw attention to this in ripe-267 5.4.1. So it seems unnecessary (and maybe a little contradictory) to restate its recommendations as requirements; it strikes me that this should be a choice for ISPs to make and for customers to act on rather than making it a box to be ticked when making your allocation request. Andy -- Andy Furnell <andy@linx.net> Mob: +44 (0) 7909 680019 London Internet Exchange http://www.linx.net

Hi, On Mon, Apr 04, 2005 at 12:10:15PM +0200, Sander Steffann wrote:

This I am not so sure about. Fixing the assignment size on /48 makes the structure of address allocations and assignments very clear, but I am not sure if we should make this official policy or just a recommendation. I don't see a problem with assigning a /48 to a customer, but maybe this should be the decision of the LIR...

We're not making this policy, this *is* policy - same document, 5.4.1, and I do not see any proposal to change this. So please don't intermix "initial allocation criteria" (5.1.1) with "end user assignment sizes" (5.4.1) - and *please* don't change 5.4.1 or RFC3177. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

On Mon, 4 Apr 2005, Gert Doering wrote:

On Mon, Apr 04, 2005 at 02:13:20PM +0200, marcelo bagnulo braun wrote:

...

I guess that it may make sense to define a time frame here... i mean, an organization planning to provide IPv6 connectivity in 20 years would qualify here?

Yes. But how much harm can it do? This organization would eat up about 1/4294967296 of the address space, and pay a yearly fee to RIPE to be permitted to keep it. Sounds like a fair deal to me.

If the address space is allocated and doesn't even end up in the routing tables, even better.

I don't think I agree here. So, 1-man consulting companies, providing web hosting for one customer could fulfill the criteria for a /32? Looks like every enterprise out there would also get a /32. Doesn't look like a good idea at all. While I agree that the "200 customers" rule could maybe use a bit of improvement, I don't think removing it completely is the right fix at all. So, I'm opposed to the policy change. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Gert Doering <gert@space.net> writes:

Hi,

On Mon, Apr 04, 2005 at 04:35:23PM +0300, Pekka Savola wrote:

...

...

Yes. But how much harm can it do? This organization would eat up about 1/4294967296 of the address space, and pay a yearly fee to RIPE to be permitted to keep it. Sounds like a fair deal to me.

I don't think I agree here. So, 1-man consulting companies, providing web hosting for one customer could fulfill the criteria for a /32?

If that enterprise is willing to pay RIPE fees for it, it would qualify.

...

Looks like every enterprise out there would also get a /32.

If they are willing to undergo the necessary paperwork, and pay the yearly fees, yes.

And how does this scale going forward? I.e., when folk figure out that all they have to do to get their very own PI address space is join RIPE and pay the fee?

If you're worried about a landslide: let's put an (arbitrary) safety margin in there "only 5000 prefixes are handed out, then we stop and re-evaluate policy".

So, we repeat the IPv4 experience where the early birds get a precious resource, while the late arrivers have to play under changed rules (that they view as being unfair)? I thought one of the goals with IPv6 address policy was _NOT_ to repeat the mistakes of the past. Thomas

On Monday 04 April 2005 17:43, Gert Doering wrote:

Hi,

Yes. This is how it works with IPv4 PA blocks right now (in RIPE land) - and *these* blocks are *not* what's filling the routing tables with 150k routes, given that we have only a few thousand RIPE members.

...

I thought one of the goals with IPv6 address policy was _NOT_ to repeat the mistakes of the past.

The only way to avoid *all* mistakes is to avoid giving anybody address space at all. There is no way to come up with a policy that decides today who is "worthy" that will not be challenged by someone else in 10 years. Or next week.

Personally, I'd go for a handful of mistakes (and I'm willing to put enough RAM in my routers to handle 10.000 entries in the IPv6 BGP tables) if that means "we'll start making progress" - because if IPv6 isn't going to take up soon, it's dead.

There are bound to be mistakes, like you say. However, one of the major mistakes with v4 (imho) was the initial handing out of large amounts of address space to people who had no use for that many addresses. We're not faced with the quite same problems of address space exhaustion with v6, but I see absolutely no reason to repeat the same errors over and over by just wasting the address resources. I'd rather see large routing tables rather than in 10 years time find we're running out of v6 space. Most of this seems to stem from the simple requirement to multihome (anycast or otherwise). Perhaps we should just wait for the final recommendations from multi6 and see what they've come up with. Jon

...

There are bound to be mistakes, like you say. However, one of the major mistakes with v4 (imho) was the initial handing out of large amounts of address space to people who had no use for that many addresses. We're not faced with the quite same problems of address space exhaustion with v6, but I see absolutely no reason to repeat the same errors over and over by just wasting the address resources. I'd rather see large routing tables rather than in 10 years time find we're running out of v6 space. Well, we will also see routers beeing capable to route more than 150K prefixes. We can even see them today.

And there are really PC's with more than 640K of RAM ;-)

At these old days when these 64MB routers were designed, RAM chips had 4 to 16 MBits of RAM. Today we are talking about min. 256MBit SDRAM dies, smaller SDRAM's will have their "call for last order" very soon now.

and we once thought 32 bits of address should be enough for ever randy

On Mon, 2005-04-04 at 21:22 +0200, Oliver Bartels wrote:

On Mon, 4 Apr 2005 09:17:04 -1000, Randy Bush wrote:

...

and we once thought 32 bits of address should be enough for ever If this policy discussion continues, and continues, and continues ... ... then 32 bits of address *will be* enough for ever.

To put it in another perspective: If these policies cause 2000::/3 to be exhausted then there are 7 more tries left to do it all over again. And indeed the people in 2000::/3 who where early adopters will have the advantage of getting a huge space easily, just like in IPv4 land. But in IPv4 land there was not much left, in IPv6 there are another 7 tries to go before it is completely filled up... Now folks get over it ;) Greets, Jeroen

On Tue, Apr 05, 2005 at 11:00:11AM +0100, Michael.Dillon@radianz.com wrote:

Now, a set of IPv6 policies in which no globally routable prefixes are longer than /32 allows router manufacturers to optimize memory usage and design router tables to only carry those 32 bits of the IPv6 address.

We don't have those policies. Supposed-to-be-globally-routable /48s do already exist.

This will conserve memory and allow the routers to scale easier.

If we really consider crippling CIDR lookups to less than 128 Bit: I don't think that "64 bit or bit 48" makes much of a difference in terms of router scalability... but I'm guesstimating here with about nothing to back that. Other folks might comment.

Our job is to make a sensible policy that allows the use of IPv6 to scale smoothly so that it meets the needs of humankind for the next generation or two. Let's not be so arrogant that we try to solve all addressing problems forever. That is not necessary.

ACK. And our job is to design something desireable, not something that has serious shortcomings compared to IPv4 (no PI for endusers). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Tue, Apr 05, 2005 at 02:17:21PM +0200, Iljitsch van Beijnum wrote:

...

ACK. And our job is to design something desireable, not something that has serious shortcomings compared to IPv4 (no PI for endusers).

And that's exactly the problem. This forum is more or less a marketing forum, and as such it's the wrong place to decide on these issues, as these are ENGINEERING tradeoffs.

Name the engineering problems of end-user PI. (Un)fortunately nobody was yet able to show convincing prove that there IS a problem. Stop FUDding.

In addition, it makes no sense whatsoever to make these decisions for part of the network, as the results impact everyone around the world.

Agreed.

The IETF has worked long and hard on multihoming without PI. It would be superbly stupid to throw all of that away with the finish line in sight and forever increase the cost of routing just so lazy people can get away with hardcoding IPv6 addresses in their access lists.

IETF is nowhere near any solution. They are as far away from it as they can be. Will probably take another few years to finally realize that. There is no REAL multihoming without PI yet. And the IETF recently narrowed down the road they want to take (solution space) that guarrantees that the result won't fit people's needs. The multi6=>shim6 transition was (for me and quite a few others) the "end of all hope". Don't waste time and energy waiting for shim6. The outcome won't fly. A sensible "separated locator and idenfication" approach would need a complete revamp of the operating model and (and that's the big thing) operating systems L3/L4 stacks. Won't happen, so shim6 will be a crude hack, attacking only part of the requirement space. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On 5-apr-05, at 14:27, Daniel Roesen wrote:

...

And that's exactly the problem. This forum is more or less a marketing forum, and as such it's the wrong place to decide on these issues, as these are ENGINEERING tradeoffs.

Name the engineering problems of end-user PI. (Un)fortunately nobody was yet able to show convincing prove that there IS a problem. Stop FUDding.

The problem is that PI isn't scalable. This is of course fine if you don't feel like scaling, but putting non-scalable aspects in technology that is supposed to be around for decades to come is a very dangerous and expensive game.

IETF is nowhere near any solution. They are as far away from it as they can be.

Believe me, they could have been much farther away from a solution. :-)

There is no REAL multihoming without PI yet. And the IETF recently narrowed down the road they want to take (solution space) that guarrantees that the result won't fit people's needs. The multi6=>shim6 transition was (for me and quite a few others) the "end of all hope".

Why?

A sensible "separated locator and idenfication" approach would need a complete revamp of the operating model and (and that's the big thing) operating systems L3/L4 stacks. Won't happen, so shim6 will be a crude hack, attacking only part of the requirement space.

Shim6 will deliver 80% of the functionality of a loc/id solution with 20% of the effort. There are plenty of hooks to attach the remaining functionality later, but making small steps first makes much more sense.

On 5-apr-05, at 15:37, Daniel Roesen wrote:

...

The problem is that PI isn't scalable.

It's as scalable as PA. There is no inherent difference in scaling how many ISPs there are to the number of end users. Both grow in similar progression. It's not like O(n) vs. O(n^2) or so.

I grant you that there is no difference whether 10000 ISPs inject 10000 PA prefixes or 10000 end-users inject 10000 PI prefixes, but I hardly think the potential number of ISPs is similar to the potential number of end-users. (Or the actual number for both, your pick.)

So now start backing your "isn't scalable" claim (in comparision to PA). And back that by hard numbers showing real problems.

Didn't you read my message about memory bandwidth? If that isn't real enough for you then this discussion is moot because we're obviously operating on different time scales.

...

...

There is no REAL multihoming without PI yet. And the IETF recently narrowed down the road they want to take (solution space) that guarrantees that the result won't fit people's needs. The multi6=>shim6 transition was (for me and quite a few others) the "end of all hope".

...

Why?

Because the outcome won't provide what people do ask for.

And what are people asking for?

Hay, Daniel Roesen wrote: [...]

Again: you are talking about theoretical worst-case absolute numbers. I'm talking about real life.

I guess you would agree with me that it's currently no problem at all to obtain an ASN and IPv4 PI if you want to multihome. Right? This has lead to about 17k active ASN out there. Which translates to 17k-20k (let's give some headroom for special routes for anycast etc) IPv6 PA/PI routes. Where is your problem? I don't see multiple million of end sites doing BGP multihoming. Not now, not in ten years. It's not that we have hundred of thousand of NEW people JUST WAITING for the availability of PI out there.

So, when do you estimate will we see let's say more than 100k active ASNs out there? And even then we're talking about 100k, not 1 million, not 10 million.

once again: FullACK. ...but i certainly get tired having that specific discussion with always the same specific arguments every few months, so no much motivation for writing anything more than "FullACK" ATM. But probably it's better than saying nothing at all on that topic (like most people who might not even care). [...]

...

...

...

...

There is no REAL multihoming without PI yet. And the IETF recently narrowed down the road they want to take (solution space) that guarrantees that the result won't fit people's needs. The multi6=>shim6 transition was (for me and quite a few others) the "end of all hope".

...

...

Why?

...

Because the outcome won't provide what people do ask for.

And what are people asking for?

At least the same set of features as IPv4 PI BGP multihoming with no new added significant downsides.

Perhaps folks should start listening to that instead of sticking the head into the sand.

Time will tell, there either will be PI Space (like in the IPv4 world), or IPv6 won't get any relevance in "the Internet" within the next 20years (IMNSHO). If some folks want to stick their heads in the sand - let them. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================

On Tue, 5 Apr 2005, Daniel Roesen wrote:

I guess you would agree with me that it's currently no problem at all to obtain an ASN and IPv4 PI if you want to multihome. Right?

Umm. The proposed v6 policy seems weaker than that? AFAIR, you'll have to justify half of the v4 address space.. and you don't even need to do that to get a v6 block ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Wednesday 06 April 2005 01:22, Daniel Roesen wrote:

In IPv4, it's enough to have a valid TECHNICAL reason to need an ASN (multihoming), and you get one. Same goes for a PI. You need addresses, you get addresses. All you need is a sponsoring LIR (which you usually pay for that service, directly or indirectly). And now in IPv6 with an address space of 128 bits compared to 32 bits you suddenly say that "needing address space" is not a good enough reason anymore?

erm, no. Feel free to correct me if I'm wrong, but you cannot use multihoming as a sole technical reason for PI space in the RIPE region - you've still to justify a /24. I agree with most of what you are saying Daniel. My personal opinion (after far too much wine) is that the routers will probably be able to cope with anything that is thrown at them (again, I don't have the facts to back this statement up nor the knowledge to work it out - so don't ask for them Randy, other people know far more about what's on the horizon that I could ever hope to). Iljitsch, if you choose to take full routes then the cost of memory etc is you're burden - that after all is the perk of being a provider - whether you pass it on is entirely up to you. What I think we're talking about is: 1) free for all - not a good idea, which I think everyone agrees on. 2) a compromise between routing table growth and 1), which needs policies, which in turn must be set by the RIR's. I still think policy shouldn't be made until we know for certain exactly what multi6 are proposing (shim6 or whatever) and we need to see it in writing so to speak (ie they produce the actual docs) - the routers will cope I've already said, but that doesn't mean I believe in a free for all. Throwing out conservation just because the v6 address range is so vast is plain stupidity - the past, in my mind, exists for one reason, so that we can learn from it (I might not, but that's a personal problem or at least SWMBO tells me so). ISP's might need a /32 (doubtful in most cases) but enterprises DO NOT. Yes, enterprises need to multihome (same as ISP's do) but they do not need nor will they ever need a /32 (or even a /48 for that matter). How many enterprises currently use a class 'A' in current v4 space - and I mean really use - I think that question answers itself. If the routing table grows, then surely that's part of being a provider. Iljisch, who pays for it ? - you do. And ultimately, your customers. So that's unfair to customers, so what that's life. Should we open up RIPE address space to anyone who can afford to pay and can justify the address usage - erm, sorry but, that's already the situation. You want PA space and can afford it, then you can afford to pay someone who can get it - EOS - it's not hard to justify space, a lot of hassle and creative thinking maybees but not hard. I've had far too much to drink and I don't see a need to waste address space a second time. IMHO the routers will be able to handle the growth. The providers will pass the cost of routing on (so what if that leads to a consolidation of the ISP market - it's going to happen anyway) and the world will go on, but at the end of the day v6 must happen and for that to occur we need a multi-homing solution which when it boils down to it, is what this is all about. Jon

Hi, On Wed, Apr 06, 2005 at 01:40:24AM +0300, Pekka Savola wrote:

On Tue, 5 Apr 2005, Daniel Roesen wrote:

...

I guess you would agree with me that it's currently no problem at all to obtain an ASN and IPv4 PI if you want to multihome. Right?

Umm. The proposed v6 policy seems weaker than that? AFAIR, you'll have to justify half of the v4 address space.. and you don't even need to do that to get a v6 block ?

Actually, as of today, IPv4 PI is much more convenient than the proposed IPv6 policy: there is *no cost* attached to IPv4 PI. (And the need to justify the address space is obviously something that can be done - how hard is it for a not-so-small company to claim usage of 120 IPs? - and those they really don't have that many machines, just think something up, to get a "routeable" chunk) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

Hi, On Wed, Apr 06, 2005 at 11:55:31AM +0200, Daniel Roesen wrote:

On Wed, Apr 06, 2005 at 11:35:11AM +0200, Gert Doering wrote:

...

Actually, as of today, IPv4 PI is much more convenient than the proposed IPv6 policy: there is *no cost* attached to IPv4 PI.

This isn't really correct. The sponsoring LIR pays for it, and usually will charge the customer for that one way or another. Some attach a price tag for it, others see it as added customer service.

Yes, you're right here. I remembered "PI is special" but forgot in which way (only charged in the first year, not in the following years, same as for AS numbers). Still different from "becoming a LIR and paying yearly recurring fees" (which the point I wanted to make). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

On 5-apr-05, at 16:14, Daniel Roesen wrote:

Again: you are talking about theoretical worst-case absolute numbers. I'm talking about real life.

Real life has a tendency to reflect theoretical worst-case absolute numbers, given enough time.

I guess you would agree with me that it's currently no problem at all to obtain an ASN and IPv4 PI if you want to multihome. Right?

For me or for the IPv4 BGP table?

This has lead to about 17k active ASN out there. Which translates to 17k-20k (let's give some headroom for special routes for anycast etc) IPv6 PA/PI routes.

Nonsense. The number of active ASes in the IPv6 table is around 500, and the number of active prefixes around 700. However, none of the 100 largest web sites is reachable over IPv6, so this is all meaningless. The only thing we know from experience with IPv4 is that there are way too many people who don't care about the routing table, so if it's POSSIBLE to do bad things, there will be someone who DOES bad things.

Where is your problem? I don't see multiple million of end sites doing BGP multihoming. Not now, not in ten years. It's not that we have hundred of thousand of NEW people JUST WAITING for the availability of PI out there.

Then why do we need it? I see no natural limit on the number of potential multihomers. What if Linksys puts BGP in their home gateways, with a nice wizzard to take care of setting everything up? You may very well be right that the number of multihomers will grow slower than the capacity of the routers, but without knowing this for sure making this possible is irresponsible. ISPs have a very bad reputation for reliability and more and more business critical stuff happens over the internet. I think it's only a matter of time before multihoming will be all the rage, especially if it's easy to do.

...

And what are people asking for?

At least the same set of features as IPv4 PI BGP multihoming with no new added significant downsides.

Perhaps folks should start listening to that instead of sticking the head into the sand.

Read the multi6 documents. This stuff has been discussed to death. Giving some people PI until the routers almost break isn't the solution.

On Tue, 5 Apr 2005 16:58:10 +0300 (EEST), Pekka Savola wrote:

I for one don't want to see the routers CPUs' screaming red when a random brazilian ISP experiences a fiber cut and I see 5,000 v6 prefixes churning in most routers in the world because of that. You won't see it screaming red.

Because the job is done in about <50ms and this is standard business *today*. A 5000 prefix update is what happens quite often e.g. if an exchange router is restarted. What happens: *Nothing*. *No impact at all*. Question: Do you intend to implement IPv6 and BGP on a 8080 CPU ?

PI to end-users => lots of processing on routers when those sites, their ISPs, transits, ..., experience failures. Pi works today.

Pleas stop FUDing. Best regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0

Hi, On Tue, Apr 05, 2005 at 02:17:21PM +0200, Iljitsch van Beijnum wrote:

The IETF has worked long and hard on multihoming without PI. It would be superbly stupid to throw all of that away with the finish line in sight and forever increase the cost of routing just so lazy people can get away with hardcoding IPv6 addresses in their access lists.

I'm not sure how this ongoing discussion relates to *access lists*? We're talking about networks like: - large-scale networks that have only BGP customers that already have their own address space (so "no 200 /48 given to customers") - 3GPP networks that assign /64s (so it's no "/48s" given to customers) - smallish ISPs that could be a good driver for new IPv6 products (because they are not old, rusty, and refusing anything new) but do not yet have 200 customers, but maybe 30 very large ones... etc. None of these can be helped with the end-user-multihoming solutions developed by the IETF (which are important, of course). (In case you haven't noticed: there are a number of different policy proposals being discussed in parallel. Please put your attacks regarding "access-list lazyness" into the correct discussion, wherever that might be) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

On Tue, 5 Apr 2005 14:17:21 +0200, Iljitsch van Beijnum wrote:

The IETF has worked long and hard on multihoming without PI. ... and still has no solution since years and there won't be a solution.

At the end there is always an address and packets which require routing to said address. And this can't be done by papers, policies and oposition against everything. But it can be done by installing such little boxes called routers. Please explain: What do *you* *today* propose as a *complete* technical solution to handle the customer demand called PI ? Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0

On Tue, Apr 05, 2005 at 11:00:11AM +0100, Michael.Dillon@radianz.com wrote:

...

Now, a set of IPv6 policies in which no globally routable prefixes are longer than /32 allows router manufacturers to optimize memory usage and design router tables to only carry those 32 bits of the IPv6 address. We don't have those policies. Supposed-to-be-globally-routable /48s do already exist.

heck, the fatal flaw with this clueles idiocy is that we don't want vendors hard coding anything like this. remember when a/b/c were hard coded in routers and in rip? of the stupid ideas we seem bent on repeating, this seems one of the worst. randy

It's one thing to have a fall back plan to deal with unforeseen problems. It's quite another to recklessly move in a direction with significant long-term implications just because "we can always try again later".

I believe that the long term implications of growing the routing table to avoid minor waste of IPv6 address space, are much more significant and worrying that the other way around. Or, to restate it the other way around, if conserving IPv6 address space causes the global routing table to grow bigger (either in entries or bits) then we risk creating problems that we do not know how to solve. However, we do know how to solve the problem of wasting too much IPv6 address space. We either extend 2000::/3 by one more bit, or we transition to a different IPv6 addressing plan.

...

This means that we should not be excessively concerned with conserving address space or wasting addresses. It is entirely appropriate to give a /32 to anyone who might be some sort of an ISP, either traditional or some new type, like Google or BMW or Cadburys.

And, do you have an estimate of how many such "ISPs" exist today, or will exist in 10-20 years? E.g., are we talking about 10,000 entities (not scary), or 1 million (scary to me).

The point that I am making is that the ISPs of today (and the future) do not necessarily follow the same business model as the ISPs of yesterday. In the 1990's it was reasonable to define an ISP as an organization that connects 200 or more customers. That is no longer reasonable and it should be removed. If people are concerned about exponential demand for /32s then the policy change can incorporate a limit and a review period, i.e. no more than 3000 new /32's without reviewing this policy. However, all of the "ISPs" that don't fit in the current model, have something in common. They provide a service to many different physical locations or to large numbers of users. Because of this, the number of such "ISPs" will tend to be closer to 10,000 entities than to 1 million. The 200 new customer limit was meant to be a measure of largeness and seriousness. I think that in today's world, that measure fails to do the job. However, the recurring RIPE fees, do continue to serve as a measurement of size and seriousness. Assuming that we have a process for recovering IPv6 addresses from customers who cease to pay the recurring fees, I don't see that there is a problem with simplifying the policy. --Michael Dillon

On Tue, 5 Apr 2005 23:13:59 +0300 (EEST), Pekka Savola wrote:

Could you clarify, why do you think "200 customers" fails as a meter for largeness ? Pekka, just one question:

Do you really think big is good, small is bad, and just the big ISP's will promote IPv6 ? There is one point I don't understand in the whole discussion: If every RIPE member get's an IPv6 prefix, which is true for IPv4, we are talking about plus 10K prefixes in the table. This is *nothing* compared to a single de-aggregation action of clueless over-the-ocean ISP's which indeed happend and is *proven* to be managable by the existing routers. Thus *there is no technical reason at all* to keep the rule and force smaller ISP's to promise "plans" that won't get reality or put them as "second class" RIPE members into some sort of dependency of an larger RIPE member. There is also *enough* IPv6 address space, the IPv6 was designed that way. * I like clear words: If there is no technical reason at all, could one of the promoters of the 200 customers pseudo rule please explain the *true* reasons for this "we simply don't like this" opposition. I can't withhold my impression and disapointment that some behind-the-wall "arguments" for this rule are just of anti-competitive nature and that large ISP's simply think they can force smaller ISP's into some sort of dependency to keep the market clean in their sense ?!? Do people *really* think this approach works and do they really think that such an anti-competitive 200 customer policy - does neither hit IPv6 and the idea behind it - does not hit community - will not be forced down by EU commission authorities ?!? Sorry for this clear and open words. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0

On Tue, 5 Apr 2005 12:11:26 -1000, Randy Bush wrote:

go to the ipv6 forum or whatever to discuss promoting ipv6. here, we're trying to figure out how to do prudent and responsible engineering so that this thing will scale for 50+ years if anyone decides to use it. Aha.

Do I see this right that we have list members here who are clever enough to *exactly* know what will happen with network technology in the next 50 years propably because of some intuition given personally by Him to them ? And from the discussion it sounds like He told them to pray that every household should become a RIPE NCC member and thus IPv6 address space is in great danger. No math please, no facts, just *believe and pray* :-( Btw.: I estimate about <<1 Mio. households within the RIPE NCC region. Even if there is a /32 for each household, still <1/1000 part of the IPv6 address space is given up. And when using advanced routers of today, even a routing table with 1 Mio. entries would be *possible*. It would have some economical impact, yes, of course. But it is *possible*. Clearly within a 50 years range from now ;-) But I can tell you for sure that neither my parents nor my neighbour (pet doc.) will not open an ISP as home business and thus won't apply for RIPE NCC membership, thus 999998 table entries will be sufficient with the new gamma policy proposal. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0

On Wed, 6 Apr 2005 10:50:42 +0300 (EEST), Pekka Savola wrote:

Please re-do your math. Germany also has, what 80 or 100 million people? Would it be safe to say that equates, to, at least 30 Mio households. This is correct, I estimated the number of companies and it was early in the morning.

Do the math globally and we're maybe at 2 billion households. We are talking about RIPE.

Nevertheless: It is useless, stay with your China comes to Europe theory, keep your 200 customers pseudo rule, we will clearly not invest a single cent into IPv6 and I won't bet a penny that this protocol under the current concrete head policy conditions will ever gain a anyhow usable distribution in our world. Propably it takes another ten years, then propably there has some significantly better protocol (think e.g. of embedded search queries processed by routers) been defined and the whole IPv6 effort is for this animal, which receives so much care by managers and developers with useless designs: The cat. For me this is now end of discussion, Congratulations to the concrete heads for putting IPv6 successfully to grave. Best regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0

On Tue, 5 Apr 2005, Oliver Bartels wrote:

On Tue, 5 Apr 2005 23:13:59 +0300 (EEST), Pekka Savola wrote:

...

Could you clarify, why do you think "200 customers" fails as a meter for largeness ?

Do you really think big is good, small is bad, and just the big ISP's will promote IPv6 ? [...]

Why do you think you require a /32 to "promote IPv6". Don't answer.. it was a rhetoric question :) My own, small consulting company (with dozens of customers) can certainly promote v6, but I have no delusions of grandeour that it would be best from the global perspective to allow such or even larger companies, whether calling themselves ISPs or not, to obtain a /32. Is a bit of unselfishness too much to ask ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On 6-apr-05, at 8:30, Oliver Bartels wrote:

For our company we require a *unique* *globally* and under our AS with definition of an AS ("own policy") routable address space. I don't care about the exact size.

No you don't. That's just the easiest way to get what you really need (stability, independence, failover, whatever).

Thus I can clearly tell you that without independently routable address space we will not introduce IPv6 within our network. Period.

See you in IPv7 then. Bye.

On Wed, 6 Apr 2005, Elmar K. Bins wrote:

...

My own, small consulting company (with dozens of customers) can certainly promote v6, but I have no delusions of grandeour that it would be best from the global perspective to allow such or even larger companies, whether calling themselves ISPs or not, to obtain a /32.

Would you - if I may ask - believe "such or even larger companies" to be eligible for an independently routable prefix at all, or, more clearly spoken, eligible for a slot int the global routing table?

They should never be in the global routing table.

Under what circumstances would your idea of eligibility change?

That can be debated, but hopefully not in this thread or list. I'm asking you guys :) Getting 200 real customers is one acceptable circumtance. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

* Elmar K. Bins:

...

Getting 200 real customers is one acceptable circumtance.

I believe the "200" poses a problem for most of the typical early adopters, who are not among the Tier 1 folks, but in Tiers 2 and 3 (if you think in tiered terms).

Well, if the "200" is a problem, just go ahead and open a bot shell provider (or some kind of reselling service for the actual BSPs). Using address space for the sole purpose of vanity host names is completely legit. 8-)

On 6-apr-05, at 1:37, Jørgen Hovland wrote:

There is no such thing as technical limitations/reasons, only economical.

Nobody can transport an IP packet faster than 300000 km/s (well, more like 200000 km/s in practice) no matter how much money they have.

I don't see an economical reason for why normal network providers shouldn't be able to handle 500,000 IPv6 routes.

It's too expensive. Don't forget that a typical router takes a bunch of full feeds (or equivalent in partial feeds) from different peers, so 0.5M routes probably means your router needs to support 2 - 5 M BGP routes. And of course you need a FIB that's large enough and can be searched fast enough.

Existing operators may need to upgrade something or they have to downgrade to singlehoming if they do not wish to upgrade.

It's not just the multihomers that need a router that supports a full BGP table. Medium-sized and larger ISPs need to have routers that hold full tables too, they don't have a choice.

With that in mind, isn't this what you are looking for: A natural way to limit the amount of multihomed autonomous systems/amount of prefixes without enforcing unreasonable policies?

That's why I proposed "provider-internal aggregation based on geography" but this fell on deaf ears. Go for the quick fix PI block and let someone else clean up the mess seems to be the prevailing attitude.

IPv6 won't survive if you keep having silly policies (and I still think that includes the fixed size /48 customer assignment policy).

What's silly about that? A fixed prefix length is very useful because that way you only have to renumber the top 48 bits when you switch ISPs. This makes life much easier.

(sidenote: the speed of light is not relevant to how fast you can transport IP packets) It breaks down to time and money and how much you want to spend of it.

i am sure i can get you a USD 1,000,000 award for transporting at faster than the speed of light. is that enough money? heck it's probably worth a nobel. can we cut the hyperbole and try to seal with engineering reality. that's hard enough without the bs. randy

-----Opprinnelig melding----- Fra: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] På vegne av Iljitsch van Beijnum

No matter how much money you have, you're not going to get a packet from London to New York in (say) 10 ms. Sure, if you spend more money you can get MORE packets from London to New York in 100 ms, but that's not what I call "faster".

I think Randy said it all. I'll buy you a beer when I get my $1 mil then.

...

Renumbering will be just as easy with any number between 0 and 127 as long as the new prefix is equal or larger to the previous.

So how would that happen if everyone would have their own policy for this?

As long as you get one billion times more addresses than you need, the size of your new allocation will depend on the current address policy which will change over time as the amount of free IPv6 addresses gets reduced. This is (mostly) why the early birds on the Internet got a class /8 IPv4 block, and I bet some of them don't even use close to all of it. How long do you think this /48 policy will last? I was hoping for at least 60 years++ so I don't need to have the same discussion again with IPv8.

...

With dhcp it doesn't matter.

Most people aren't going to use DHCP in IPv6.

Which is another discussion.

...

I am aware of rfc3177 saying "a company with several nets gets a /48 and allocate /64s for each of their subnets". But let's not mix the word recommendation with must. Why we allocate a /124 on our lan instead of /64 is not of anyones concern but us From RFC 3513:

For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format.

In theory I agree with you as IPv6 is supposed to be classless, but in practice the above makes sense as it would probably be too difficult to support address autoconfiguration with variable subnet sizes.

...

and therefore the enforced 48 number is unreasonable.

I don't see why it's unreasonable. At least this way everyone gets the same, regardless of which ISP they use. (It's always possible to request a bigger block for those who need it.)

So you are saying that documenting your need of a /48 will be rejected by future LIRs due to their own address policy and they will give you a /56 instead because that’s what their policy says? I don't believe that will happen as long as the RIRs have somewhat loose policies. ARIN allocates you a netblock and you do whatever you want with it. With RIPE you need to apply for allocations within your assigned netblock. I can see that this might impact on the different policies in the US. But what about you document the need of a /40 but will only get a /48 (/47)?

...

A more specific problem with this allocation policy: You would expect that if a /64 is the standard allocation size of a lan, then we can all start filtering on /64s instead of /128s if we want to do per-ipv6 filtering, right?

I don't understand what you're getting at...

I see I was a bit unclear. Limitation of 1 ftp connection per user, 1 registration per user on our website and so on.. Simple techniques to reduce abuse++ often take advantage of the one machine to one IP address ratio with IPv4 today. With IPv6 you get one address, or you get a billion. You can't tell anymore cause you can grab thousand extra ips on the /64 lan and use it for whatever you like. We are sure going to miss this feature. Joergen Hovland ENK

Hi, On Thu, Apr 07, 2005 at 12:21:06AM +0200, Jørgen Hovland wrote:

How long do you think this /48 policy will last? I was hoping for at least 60 years++ so I don't need to have the same discussion again with IPv8.

While I personally dislike /64s and /48s (for some other reasons that do not need discussion here, as there are good reasons for /64 and /48, and I can accept these), your argumentation is still flawed. Everybody that tells me "we will run out of IPv6 address space!!!!" has pretty obviously not done the math - just count how many /48s are there, and then do some estimation on how many people earth can suffice, and how many /48s per person for each of those we have. Out of 2000::/3. *Then* come back and tell me (with a straight face) "we will run out of IPv6 addresses because /48s are such a great waste". [..]

So you are saying that documenting your need of a /48 will be rejected by future LIRs due to their own address policy and they will give you a /56 instead because that???s what their policy says?

The whole point of the /48s is that you do NOT need to argue with your LIR. You'll *always* get a /48 when changing ISPs, and that's big enough for all but the largest customers. This is why /48s are *good*. (Unless, of course, your network is too large for a /48 - provisions for that case exist).

I don't believe that will happen as long as the RIRs have somewhat loose policies. ARIN allocates you a netblock and you do whatever you want with it. With RIPE you need to apply for allocations within your assigned netblock.

You're seriously confused about terminology and about RIPE IPv6 policy. [..]

But what about you document the need of a /40 but will only get a /48 (/47)?

Show me the network plan that documents the need for a /40. 16 million independent multiaccess networks ("LAN")??? (There are some, but it's going to be "few"). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

...

While I understand and accept your argument here, whether we'd ever run out of address space imho has nothing to do with /48's. How many /32's have we got to play with ( 536870912 per /3 by my calculations) OK, that's still a big number. But if we allow everyone who wants to multihome a /32, there is the possibility that we could run out - not in the near future that's for sure.

Many companies are still discovering how/if they can use the internet. As more and more uses for the 'net are thought up, companies are going to become more and more reliant on the 'net to the point where they will/may struggle to function without it - somewhere around that point, all companies will need to have a permanent connection and in my mind a permanent connection means multihoming.

How many companies are there in this world ? Thus how many potential multihomers have we got ? - more than the number of /32's available, I doubt it (I don't think there are 4 billion companies). We're a along way off home users multihoming, so perhaps we'll never run out of /32's. But I for one would not like to bet on it.

Shared reluctancy to bet on it, as a basis of building policy at least. Cheers, mh (as6453)

Jon

-----Opprinnelig melding----- Fra: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] På vegne av Gert Doering Sendt: 7. april 2005 21:01

Everybody that tells me "we will run out of IPv6 address space!!!!" has pretty obviously not done the math - just count how many /48s are there, and then do some estimation on how many people earth can suffice, and how many /48s per person for each of those we have. Out of 2000::/3.

*Then* come back and tell me (with a straight face) "we will run out of IPv6 addresses because /48s are such a great waste".

I will have no problem telling you that. I agree with Randy (every size limit that has ever been done in computing has proved to be too small in the long run). I am not implying that we will run out of addresses tomorrow, only that we will run out.

Show me the network plan that documents the need for a /40. 16 million independent multiaccess networks ("LAN")??? (There are some, but it's going to be "few").

Well then I can show you a plan that doesn't work: The 200 /48 customer assignment policy plan (which was what I argued about in the first place) LIRs need IPv6 prefixes in order to use IPv6. What are you waiting for, RIPE? A better IP protocol? Since it is not due to the infinite, as you say it, resource of IPv6 addresses the reason for this policy must be due to the problem with a large, global routing table. The economical side of an enormous routing table will affect anyone. I am sure we can agree on that this won't kill the entire Internet. If you truly need multihoming, you can afford it whatever it cost. The whole multihoming issue is one big economical reason anyway. Therefore I can't see the problem with my open policy suggestion. I believe it to be better than the existing one although perhaps not 110% perfect. You will simply charge the customer more if it really comes to it in 100 years, but by then I, and you should too, expect better cost-effective routing hardware. The customer will pay, they always do. Joergen Hovland ENK

Could you clarify, why do you think "200 customers" fails as a meter for largeness ?

Because it assumes that the LIRs applying for address space are following a traditional ISP model in which the customers of the LIR are being connected by the network. In the case of BMW it may be the factories, or it may be the repair centres. In the case of Google it may be some set of replicated server farms in many locations.

What do you think would be a reasonable bar then?

First, I think that it would be more reasonable to have no bar but to have a number of /32 allocations which triggers a policy review. But if there has to be a bar, then perhaps it could be restated as: "the LIR intends to allocate at least 200 /48 blocks within the next two years". On a commercial level, that still allows a new startup ISP who intends to offer IPv6-only network access, to get the addresses that they need for their business plan. But it also allows for all the existing IPv4 network operators, many of whom are not ISPs, to get IPv6 addresses to transition their networks. We don't really know who is going to adopt IPv6 or how they are going to use it so the policy has to avoid making assumptions and avoid unecessary barriers to entry. --Michael Dillon

* Pekka Savola:

Do you consider BMW and Google ISPs? Do you think they should be?

Both BMW and Google need stable internal adressing, independent of the ISPs they use because their life expectancy exceeds that of your average (large) ISP. If they can't get stable public addresses (globally routeable or not), they'll just use private ones (or even a completely different address allocation scheme), and NAT as necessary. This is not an ideal solution, especially if BMW and Google should ever merge, but it's better than complete dependence on an external entity which might turn into a competitor or go out of business. If you don't give real addresses to end sites, you cannot compete with NAT in most areas. This is sad because NAT does have its problems. If another IPv6 killer application surfaces (besides the large address spaces), both BMW and Google will be able to jump through almost any hoop to qualify as an ISP. That's why it's so strange not to give them real addresses in the first place.

Do you consider BMW and Google ISPs? Do you think they should be?

No and no. I also don't think that this is relevant to RIPE policies. There was a time when virtually all IP network operators were ISPs and ISPs were distinct and separate from telecoms companies. Now, most ISPs are telecoms companies, but virtually all companies in Europe operate an IP network of some sort. RIPE should be concerned with all operators of large IP networks, whether or not their business model is that of an ISP or something else. The technology of IP networking requires IP addresses. Once a company has the need to interconnect IP networks, they also have a legitimate need for globally unique IP addresses. That is where RIPE comes in. It doesn't matter whether this is a company, like mine, which operates a parallel internetwork separate from the Internet, or whether it is a company which operates their own IP extranet infrastructure, or whether it is a large multi-location company operating their own IP intranet. If they need globally unique IP addresses, they come to RIPE and RIPE policies must be fair to all of them. RIPE must not be seen to be a cabal of ISPs trying to impose a certain business model through anti-competitive policies. This is all the more important with IPv6 because real-world political organizations are taking notice and talking about becoming involved. As long as RIPE stays current with the realities of today, not the dreams of yesterday, then there will be no problems. I believe that RIPE can evolve its policies so that there is no need for the EU or ITU to become involved in IPv6 addressing. But evolution is required.

Note that at least according to some enterprises, folks also want to advertise more specifics from each of the network demarcation points they attack to -- not wanting to backhaul internal traffic through their internal network. Giving such enteprises /32 furthers bloats the routing table with TE-induced more specifics. For those enteprises, it might be better to have local-provider aggegatable addresses, which don't need these traffic engineering properties.

If an enterprise desires that type of traffic flow then it would be a mistake for them to get a PI allocation. If there is a real danger that people will make this mistake, then RIPE could publish educational material about how different addressing scenarios affect traffic engineering, failover, etc.

c) plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation; and

d) have a plan for making at least 200 /48 assignments to other organisations within two years.

What you said, "the LIR intends to allocate at least 200 /48 blocks within the next two years" seems to be roughly equal to the above, except by removing the "other organizations" rule.

Was this the intent -- because the current policy already allows a /32 to (if the other conditions are met) new ISPs which don't _yet_ have 200 customers ?

If you remove "to other organisations" from d) and also reword c) so that it refers to something other than organisations (sites?) then I think the policy will be much fairer. However, I still think that the plan for 200 sites within 2 years is not necessary at this point in time. If only we had a clearer definition of a network and an internetwork. I would probably say something like: "Any organization planning to operate an IPv6 internetwork connecting two or more physically discontiguous locations...". --Michael Dillon

If these policies cause 2000::/3 to be exhausted then there are 7 more tries left to do it all over again.

No. If we find that 2000::/3 is not enough, we've botched things badly through poor choices made today. Using the remaining space a long ways from now (e.g, in 30? 50 years?) would perhaps be OK. Needing to use it anytime in the next 10-20 years means we've botched it. Thomas

Hi, On Mon, Apr 04, 2005 at 09:17:04AM -1000, Randy Bush wrote:

and we once thought 32 bits of address should be enough for ever

*I* wasn't part of that "we" - and the math is a *little* bit different here. To answer Jon Lawrence on his "address space depletion worries": please *do* the math, just once, and then stop this often repeated but invalid argument. There are 4 *billion* /32 prefixes. Handing out (globally visible) /32s will not be a mistake because the *addresses* run out - the problem space is "number of AS numbers" and "number of routing table entries". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

On Mon, 4 Apr 2005 13:38:10 -1000, Randy Bush wrote:
>gert, i am too busy to find the quote for you right now, but
>the essence is that EVERY size limit that has EVER been done
>in computing has proved to be to small in the long run.
*Please* do math. The limit is the number of atoms on earth,
however we should consider the aliens ...

It has also been proven that EVERY memory size problem
has been solved so far.

>so perhape prudence in the presence of finite resource is not
>stupid.  

>if v6's only feature is that you can be wasteful of
>the space, that is still not going to sell it.
To some degree I agree:
- If IPv6 only feature is that you have a large address space,
*which can't be routed*, it won't sell.

The equivalent would be a 20 digit postal zip code
with just 5 digits used by the postman, but the other
15 validated by an address controller just to check
that post office customers have fully read and understood
the zip code rules book with it's 1000 pages ;-/

We don't need a protocol with 128 Bit address space
(a decimal number with *38* decimal digits) nor 64 Bit
(a decimal number with *19* decimal digits) global
addresses *if we can't route this space globally* and thus
*again* have all the renumbering pain which we have
with IPv4 in the case of a technical or ISP change.

*Either* we are sure that engineers and vendors will
be able to provide at least the routing performance of
IPv4 for IPv6 and hopefully *significantly better*, then we
should stop this "let us restrict everything" discussion.

We can sell products, but we can't sell restrictions.

Or we don't believe this, then we should stop considering
IPv6 as new protocol for the global internet.

Best Regards
Oliver

P.s.: And no, there are not enough *intranet* VPN's to
justify switching to a new *internet* protocol. In such
cases IPv6 may be used internally up to the gateway.



Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany
oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0

On Mon, 4 Apr 2005 19:46:32 -1000, Randy Bush wrote:

by changing the addressing. and that is exactly where we got into trouble last time. and our grandchildren will have the same problem again. What trouble ?

The IPv4 is a *success story*, there are *few* products with more success. The whole world adoped this protocol and addressing and it is and still will be *functional* for a long time. Compared to this success the few "we need CIDR and some address assignment policy" issues are *minor* and can be seen as small corrections implied with every success story. Even the FA board does apply minor changes to the >100 years old football rule after regulary scheduled meetings ... Compared with these IPv6 is currently *not* a success story, it is over ten years old and still experimental. For the technology of the '90s it makes indeed sense to use a 32 bit address space with 24 bit international routing: - The address can be handled in one step by standard processors designed for 32 bit - 32 bit as a reasonable 2^n multiple of an 8 bit byte (character unit and again 2^k) is => large enough to provide at least one IP adddress per stationary end user site on this world => small enough for efficiently wirable bus widths and *fast* handling by ALU's (carry lock ahead etc.) ( remember the market failure of the Itanium, a pure/mainly 64 bit engine has no market, as 32 bit is a reasonable integer and pointer width in *most* cases, 16 bit is too small for pointers, on the other side more than 4GB address space per task is required just by very few programming tasks ) - 24 bit can be completely internationally forwarded by a very fast radix tree structure: - Take the first byte, look up in a table, either find a next hop or a pointer to the next second level table. If there is a next hop, you are done. - Repeat this for the second, third byte and the second and third level table. This requires 3 table accesses, an easy job for even a small microprocessor. An access list is much more complicated. This means: Worst case is 1 + 256 + 256*256 tables with e.g. four bytes per entry (ptr.) and 256 entries each, this means *worst case* 65793 tables or appx. 67MByte RAM, typical case about one third due to many /16's, unused /8s, multicast space etc. and hopefully a good next hop aggregation algorithm for /16's splitted into same destination /24's by clueless operators. Which means: This lookup can even be done in SRAM or by microcode compiled from the BGP info in real time, a static RAM area with 8...16 MWords (32 Bit/word) is affordable today, the same with DRAM is *really cheap* and even was cheap in the last century ... The 32 bit address makes absolutely sense from a technical and economical point of view and you need *very good reasons* and a *much* better performance to sell something else. At the end the customers decides, not the address-policy-wg, and if we can't provide an interesting IPv6, the customer will stay with IPv4 for the next 20 years. After that, the chance is high that there will be some completly new (intelligent, on the fly search, combined-multi-any-whatever-cast) IPv_new. If you want make IPv6 an success, it must be *better* than IPv4, not worse and more restricted. Arguments could be (Ceterum Censeo ;-) - no renumbering pain due to get-once-stay-with-them addresses *regardless* which ISP doing the service - easy multihoming - easy VPN's - a *globally* unique *constant* address for each mobile (which again means global routing, *not* dynamic assignment, this and NAT is what we have today) and not - total dependency on your ISP or upstream due to an restrictive and pseudo-geographical addressing Think of: IPv6 was created with nearly *unlimited* address space in mind, either it can keep this promise (which means usable, thus *routable* address space) or it is dead. Greets Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0

...

...

...

gert, i am too busy to find the quote for you right now, but the essence is that EVERY size limit that has EVER been done in computing has proved to be to small in the long run. It has also been proven that EVERY memory size problem has been solved so far. by changing the addressing. and that is exactly where we got into trouble last time. and our grandchildren will have the same problem again. So what do *you* propose to do now?

go back to paying work. if we need to give away large blocks to get folk to even ask for something that they don't seem to actually use anyway, then i think ipv6 has other issues that are a lot more pressing.

(On the math thing: you conveniently ignored my argument that we'll run into other limits *far* earlier than into the depletion of /32s - and unless *those* are solved, address depletion by handing out routable /32s really is a non-issue)

in ipv4, we have fixed routing many times. this is why the ivtf politicians allowed v6 to be decided independent of routing. they really believe these other issues can be fixed as we go along. as we're not really going along, we really don't know how true this is. randy

Hi, On Tue, Apr 05, 2005 at 10:00:22AM +0100, Jon Lawrence wrote:

So that only question is where do we draw the line on who gets routable address space: 1) companies who provide addresses to clients (ie ISP's).

This is what the policy proposal talks about. Just without the silly need to claim a *plan* for fulfillment of an arbitrary number. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

Oliver, Would you please invest some time into discovering how grownups use email? The excessive funny interpunction hurts my eyes. On 4-apr-05, at 21:10, Oliver Bartels wrote:

...

I'd rather see large routing tables rather than in 10 years time find we're running out of v6 space.

Whatever we do, we're not going to run out of IPv6 space. Worst case, we have to start subdividing /64s and kill autoconfiguration, but that way we still have four billion times as many addresses in a single /64 as in the whole IPv4 internet. That said, the HD ratio and strange new ways to distribute from IANA to RIRs may eat up the bits from 3 - 47 much faster than we could have imagined at the time that IPv6 was designed, so we shouldn't waste v6 space like there is no tomorrow. Still, the routing table size problem is much more pressing than the depletion problem in IPv6 because even if the table size isn't fatal, it can get expensive easily, and when it gets fatal there is no way to fix it (even if we give up autoconfiguration).

Well, we will also see routers beeing capable to route more than 150K prefixes. We can even see them today.

Well, we're never going to run out of oil either, but at some point it's going to be so expensive to get it out of the ground that it's easier to leave it there and walk to work. I'm not sure what the cheapest router is that can handle a full table today, but I'm pretty sure it's more expensive than what one that could 10 years ago cost then (ie a Cisco 2501).

At these old days when these 64MB routers were designed, RAM chips had 4 to 16 MBits of RAM. Today we are talking about min. 256MBit SDRAM dies, smaller SDRAM's will have their "call for last order" very soon now.

Ah, but if you have N * 2 routing table entries, not only do you need 2 times the memory, but all else being equal you're going to see 2 times as many updates, so assuming you need to search N * 2 entries before you can update one (which fortunately isn't the case, the exact math is left as an excercise to the reader) you need 2 * 2 = 4 times as much memory bandwidth. It's not just a factor of more memory.

Again for multiv6: *There won't be a *full* and *unrestricted* solution, the we_want_multiv6_but_keep_BGP4 approach has fundamental laws of math and computer science against it:

An *address* is an *address* and is spoken *address*, because it addresses something, which means it guides something to a destination, which does not mean that it just references something and let's some unknown big wonder do the job ;-/

I have no idea what you're talking about here.

But it is possible, BGP4 is proven with existing products for appx. 500K prefixes, if more is needed, I would suggest thinking of an protocol update.

And what exactly would that update entail? The problem isn't BGP (although BGP has problems for sure) but the fundamental problem that if you can't derive the answer you're looking for from the information you already have, you'll have to go to the place where the information is kept. I.e., you need to search the routing table.

I do fully agree with Gert: "because if IPv6 isn't going to take up soon, it's dead."

I'm not sure how having a new techology available before the old technology implodes is a problem.

On 5-apr-05, at 15:19, Daniel Roesen wrote:

...

I'm not sure what the cheapest router is that can handle a full table today, but I'm pretty sure it's more expensive than what one that could 10 years ago cost then (ie a Cisco 2501).

A 50-EUR-off-Ebay PC can do that easily.

As Randy is fond of saying: I invite my competitors to do this. My experience with PC hardware routers is that they're fast and powerful, and fail 10 times as often as "real" routers so all the money you save on hardware is eaten up by operational expenses.

And even if you go to the "off-the-shelf-real-routers" (actually not "routers", but "optimized forwarders with routing component") then you can have them quite cheaply... looking at JNPR J-Series and Cisco 1800 series that should be doable well below 2000 EUR.

I doubt that the 2501 was much less expensive back then. :-)

It was around that price. Ok I wasn't aware of the 1800 but this looks like a nice entry level BGP box.

Dear Iljitsch, On Tue, 5 Apr 2005 15:10:29 +0200, Iljitsch van Beijnum wrote:

Would you please invest some time into discovering how grownups use email? The excessive funny interpunction hurts my eyes. I would appreciate if you could stay with the subject and don't put things on the personal level.

Doing so if arguments are missing is not a good idea. And please keep in mind that at least I am not a native English speaker.

Whatever we do, we're not going to run out of IPv6 space. Exact.

Still, the routing table size problem is much more pressing than the depletion problem in IPv6 because even if the table size isn't fatal, it can get expensive easily, and when it gets fatal there is no way to fix it (even if we give up autoconfiguration). Stay with math: There are about 20K AS'es and much less RIPE members.

Thus : How many prefixes will be out caused by the new policy ? ;-)

I'm not sure what the cheapest router is that can handle a full table today, but I'm pretty sure it's more expensive than what one that could 10 years ago cost then (ie a Cisco 2501). The 2501 is for the museum.

Any 50$ EBay PC is capable of handling >>200K routes.

Ah, but if you have N * 2 routing table entries, not only do you need 2 times the memory, but all else being equal you're going to see 2 times as many updates, so assuming you need to search N * 2 entries before you can update one (which fortunately isn't the case, the exact math is left as an excercise to the reader) you need 2 * 2 = 4 times as much memory bandwidth.

I have no idea what you're talking about here. At the end we are talking about a complex (NP) shortest

Believe me (we *developed our own BGP4 route server* down to the BGP packet level): Updates are not the problem on the memory bandwidth, a typical DRAM doesn't care about 100K memory accesses. We are talking of >>multiple GBit memory bandwidths. A significant load on the CPU arises if the *whole table* is dropped or rebuild due to some line going down or up. Most of the CPU power is required for policy calculations. However: At least our route server handles a complete 150K table in less than 1 second with complex policies. path problem which can't be solved by policies. *There is no way* to avoid the any-network-structure shortest-path calculation in a complex network. Not by multiv6 and *not by any other approach*. Routers can only be replaced by routers.

I'm not sure how having a new techology available before the old technology implodes is a problem. If old technolgy means 10 year old 2501, then it is good when it implodes and providers are forced to invest into state-of-the-art hardware if they want to offer state-of-the-art services.

Noone is forced to offer IPv6 services and there will be a very long transition period. But we can't make the rules for the system of tommorow based on limits imposed by technology of the day before yesterday, Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0

On Wed, 6 Apr 2005 17:52:30 +0200, Iljitsch van Beijnum wrote:

So what? Most of us aren't. Does your native language use asterisks and smileys for punctuation? If you don't like them, ignore them.

Well, worst case a 10 Gbps router has 67.2 nanoseconds to forward a packet before the next one comes in. At these speeds every single memory cycle is relevant. This is simply wrong.

In know this for sure because we are designing such boxes. The key point is that packet forwarding is a process which can (and is in current designs) perfectly pipelined and parallelized. What you do is e.g.: - Convert the table to a radix tree or to microcode representing a radix tree - Wait until the packet header is complete - Extract the destination of packet 1, add some cyclic local id., to address and packet buffer (or take the buffer id. as local id.) put both in the pipeline for checking the first tree level - In the meantime do the same for packet 2, 3 etc. - With the first level decision done, re-schedule the address of the packets for level 2, 3 etc. - At the end there is a decision for the packet referenced by the local id. Flush the packet buffer to the next hop and release it for new packets. Typically one would implement an online compiler to translate the table into microcode and would have multiple "threads" running on the same engine. The response time is not critical, just the throughput, which can be easily increased by adding additional processing units. Another approach is using multiple network CPU's on a single chip. But if you like, you may also do a forwarding decision on a 256K table in one TCAM cycle. IDT delivers such devices and they are happy to sell them.

However, I must admit that I was a bit careless with updating the table and forwarding, things will have to get pretty bad before updating will run into memory bandwidth problems. But if and when that happens, we're in a deep pile of brown stuff as read random access memory bandwidth for large memories hasn't been able to keep up with progress in other areas in the past and it's unlikely that this will happen in the future. I can give you numbers: Standard PC, 1,5GHz, nothing really fast, full table, full policy test of our implementation :

Can you please point me to the part in the BGP spec that explains where in BGP the SPF calculations are done? It is a shortest inter-AS path calculation which is applied if

Full table (150K) read and processed in less than 1 second if the other side can deliver it as fast as we read it. there is no policy which enforces other rules. The selection rules are outside the scope of RFC1771 (see para 9.3) but they are implemented by all vendors in a similar way: If no other policy enforces other selections, the path list provided is evaluated and the shortest list is taken. As this (hopefully, if there are no politics and thus specific policies active) happens within other AS's too, typically a shortest inter AS path is determinated. Please keep in mind that local policies (e.g. localpref) are active, they are prefered, because of this and of the missing AS internal knowledge the route determination does not have the same quality as e.g. intra-area OSPF.

Yes, if you sell hardware. Not so much if you're the person who has to foot the bill. Obvously I'm not saying we should be able to run core networks on 15 year old hardware. The 2501 is of the 10 to 15 years class ...

Take *any* PC from Ebay, put a Zebra/Quagga on it and you will have a *much* better routing performance and all your problems with the "large" table are solved. A table with 100K to 200K entries is not large for actual hardware. If we talk about >>1 Mio. Prefixes and PI for everyone, then we should consider an update of the BGP. Greetings Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0

This doesn't have much to do with policy anymore, so address-policy-wg is bcc:ed. On Mon, 4 Apr 2005, Gert Doering wrote: [...]

if that means "we'll start making progress" - because if IPv6 isn't going to take up soon, it's dead.

Well.. these policy proposals seem mainly set to enable v6 to enterprises, not to ISPs (because ISPs can basically qualify as it is). As is it, enterprises have very little incentive to deploy v6 in any case. It brings them few benefits and a lot of (bleeding edge) trouble. While enterprises may be good for ISPs to get some revenue to play with v6, and maybe to get pressure on the equipment vendors to ship v6 stuff, we shouldn't be equating enterprises' desires wrt v6 with the success or failure of v6. IPv6 will succeed or fail regardless of whether enterprises get v6 PI or not. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On 4-apr-05, at 15:48, Gert Doering wrote:

...

I don't think I agree here. So, 1-man consulting companies, providing web hosting for one customer could fulfill the criteria for a /32?

If that enterprise is willing to pay RIPE fees for it, it would qualify.

...

Looks like every enterprise out there would also get a /32.

If they are willing to undergo the necessary paperwork, and pay the yearly fees, yes.

Either having very many people get /32s is harmful, or it isn't. How does paying the RIPE fee move this from "harmful" to "non-harmful"?

...

So, I'm opposed to the policy change.

Me too.

On 5-apr-05, at 14:34, Gert Doering wrote:

...

Either having very many people get /32s is harmful, or it isn't. How does paying the RIPE fee move this from "harmful" to "non-harmful"?

It reduces the possible amount of applicants from "anybody out there" (many billions) to "anybody who thinks this is so important to his heart / business that he's willing to shell out serious money for it".

So you agree that an excessive number of prefixes is bad? Then the only thing we disagree about is whether the LIR fee will be enough to make the number non-excessive. It will at first, of course, but it's unlikely to do so in the long term as RIRs are not-for-profit so the more people become a LIR, the lower the fees become.

Hi, On Tue, Apr 05, 2005 at 03:20:45PM +0200, Iljitsch van Beijnum wrote:

On 5-apr-05, at 14:34, Gert Doering wrote:

...

...

Either having very many people get /32s is harmful, or it isn't. How does paying the RIPE fee move this from "harmful" to "non-harmful"?

...

It reduces the possible amount of applicants from "anybody out there" (many billions) to "anybody who thinks this is so important to his heart / business that he's willing to shell out serious money for it".

So you agree that an excessive number of prefixes is bad?

Of course. The question is "how many is excessive" and "is there real danger that the number of LIRs will reach 'excessive' any time soon" (5 years)? I pick "5 years", because I guess that's the time it will need to develop significant changes in the IPv6 protocol stacks, like "shim6" or whatever will come up - and then we certainly need to reconsider the policy.

Then the only thing we disagree about is whether the LIR fee will be enough to make the number non-excessive. It will at first, of course, but it's unlikely to do so in the long term as RIRs are not-for-profit so the more people become a LIR, the lower the fees become.

I'm sure ncc-services will find ways to keep up the fees :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

--On 04 April 2005 14:13 +0200 marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

I guess that it may make sense to define a time frame here... i mean, an organization planning to provide IPv6 connectivity in 20 years would qualify here?

I'd suggest we steer clear of yet more seemingly arbitrary numbers and limitations. It should be an immediate "demonstrable need", which would be in harmony with the initial IPv4 allocation policy. Regards, Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike@linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1"

On Mon, 2005-04-04 at 14:40 +0200, Gert Doering wrote:

Hi,

On Mon, Apr 04, 2005 at 06:57:42AM +0200, Hans Petter Holen wrote:

...

9. Summary of proposal: The proposal is to change the IPv6 Initial Allocation criteria outlined in the "IPv6 Address Allocation and Assignment Policy" (http://www.ripe.net/ripe/docs/ipv6policy.html). The proposed change is to remove "have a plan for making at least 200 /48 assignments to other organisations within two years" and to

I'm all for removing the 200-customer rule, as it's pointless... <SNIP>

So I'd go for a forward reference. Text proposal is below.

/me goes with Gert, his version sounds completely sane IMHO. Greets, Jeroen

Hi, On Mon, Apr 04, 2005 at 02:26:05PM +0100, Andy Furnell wrote:

...

I'd opt for:

c) plan to provide IPv6 connectivity to organisations and customers to which it will make assignments _according to the rules specified in section 5.4.1_, and will advertise that connectivity through its single aggregated address allocation.

just to make it clear that this change doesn't mean "/60s are fine now".

Exactly. 5.4.1 and RFC3177 are important for the sake of maintaining a coherent assignment policy, but the size of the assignments an LIR/ISP is planning on making (which we very much hope will be picked from the /48 /64 or /128 bucket as per that policy) should not impact their ability to obtain an allocation in the first place...

OK, so we're all in violent agreement, are we? :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234