On Tue, 29 Aug 2006, Sascha Lenz wrote:

Although one should think about what happens if /24 gets "not routable" due to the upcoming next round of memory restrains in BGP routers. Is it /23 then as next minimum?

Well, the larger ISPs use routers that can handle more than 240k routes, and as long as they carry the routes, if smaller ISPs filter they will soon see a loss of customers due to this. I also forsee these smaller ISPs getting a default-route as well from their upstreams to handle their inability to handle all routes.

I didn't really get any comments on this a week ago on the discussion leading to this proposal, so i assume, it's not an issue to think about right now for most people?

Well, IPv6 solves the addressing issue but it does nothing for the routing issue. Multihoming in IPv6 is still an issue being debated due to exact same reasons you mention.

. o O(and i really wonder why there's still no rant about global routing table size increase by allowing routing issues to be PI-assignment relevant..)

Probably because the solution is a radical change from how things are done today and people are quite hesitant to commit to a paradigm shift, especially since the "throw faster hardware at the problem" has worked so far? It would of course be interesting to send the proposal to groups like NANOG and see their reaction, as there are quite a lot of more routing people there that cares less for addressing. -- Mikael Abrahamsson email: swmike@swm.pp.se

Hi, On Tue, Aug 29, 2006 at 10:58:38AM +0200, Sascha Lenz wrote:

. o O(and i really wonder why there's still no rant about global routing table size increase by allowing routing issues to be PI-assignment relevant..)

Because it doesn't make a difference. It just means "people will no longer lie to the RIPE hostmasters". What I am really worried about is people getting "lots and lots" of PI, and using multiple routing table slots, instead of getting a reasonable chunk of addresses (however named), and announcing only *one* route. (I'm not talking about TE - this is a can of worms in itself - but about "poor address planning" or "using PI as a substitute for becoming a LIR") Gert Doering -- APWG Co-Chair -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

On 15 Sep 2006, at 20:01, Gert Doering wrote:

On Tue, Aug 29, 2006 at 10:58:38AM +0200, Sascha Lenz wrote:

...

. o O(and i really wonder why there's still no rant about global routing table size increase by allowing routing issues to be PI-assignment relevant..) Because it doesn't make a difference. It just means "people will no longer lie to the RIPE hostmasters". What I am really worried about is people getting "lots and lots" of PI, and using multiple routing table slots, instead of getting a reasonable chunk of addresses (however named), and announcing only *one* route.

There is a real risk that networks due to router resource constraints, who already filter on shorter-than-/24 prefixes will have to cope with any routing table growth by filtering on /23, /22, etc. If we accept argument that we should, as a community, advocate no smaller PI assignments smaller than a /24 because of table filtration, what happens when the table grows to the size that operators start to filter on longer masks ? Andy

Hi

...

http://www.ripe.net/ripe/policies/proposals/2006-05.html

We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 26 September 2006.

The proposal make sense but we have to look deeper into the problem of increase the prefixes. If someone ask for multihoming with PI Space, it makes sense that we assign a size which will work with the current filtering policies. But maybe we have to change the policy about PI Space in general ? The question is, which "problems" do we rate as a higher risk; waste of ip space, amount of prefixes, reach ability of a subnet. What do you think ? Regards Erich -- * Erich Hohermuth IP Engineer - SolNet (AS 9044) PGPKEY-46A08FCB * * phone: +41 32 686 8220 / sip:9044*463@inoc-dba.pch.net *

I also support this proposal. Being at the "receiving end" of an ISP, we've seen customer requirements often enough - many times we have been able to redirect the customer wishes towards regular PA space (which of course we'd rather assign, as it keeps customer "in line" more than PI), but larger places often have gone through IP renumbering before (sometimes when switching to us), so they know the cost involved. The prospect of e.g. shelling out the time & money for renumbering again is not very appealing. Of course, those bigger places often require more than a /24, so the issue of non-routable PIs doesn't necessarily apply. Anyway, there are situations where the number of IPs involved is smaller, but the implications are a lot bigger - best example is the current PI I had been asked to request - while the usage is somewhere in the 90 area (totalling in at or around /25+/26 given the network structure and organization), RIPE proposed assigning a /26+/27 which is (of course) useless. While the number of currently used IPs would not necessarily warant a /24 due to rather low work changing THOSE IPs, they are currently in the first roll-out phase of POS terminals - boxes, which have the destination for their communication hard-coded in Flash. Of course chaging one is possible, but imagine doing that on several tenthousands of the boxes at some point ... you will understand that the cost involved is not paid from pocket change ... my mistake was not artificially blowing up the requirements in order to end up in the 230-250 IPs range but attaching a correct, real IP plan ... :( Dmitry Kiselev wrote:

On my practice multihoming PI users ask one more prefix each time the previous one exhausted. Its coused by difficults while receiving one large enough PI subnet. Instead of becoming LIR and have no problems with PA, such users save money and got a couple of small PIs for a space solution... Yeah, here, in xUSSR, it is common practice. :(

What's the point in making end users (as in Companies, etc.) register as an LIR just because they want (or need) a network of their own? The main reason is not being dependent of a single provider, being able to switch providers when technically necessary without a sh@tload of problems and quite non-trivial cost issues afterwards due to changes in IP addresses ... being an LIR is pointless for non-ISPs or SMBs (and most likely for large ones, too). Erich Hohermuth wrote:

increase the prefixes. If someone ask for multihoming with PI Space, it makes sense that we assign a size which will work with the current filtering policies. But maybe we have to change the policy about PI Space in general ? The question is, which "problems" do we rate as a higher risk; waste of ip space, amount of prefixes, reach ability of a subnet. What do you think ?

Multihoming as such I don't see as the core reason for PI space - assigning PA space by two providers isn't a problem, less so than announcing the same size PI prefix, as there should always be a less-specific /19 or bigger to fall back to ... If the amount of prefixes were a reason, shouldn't ISPs be (en)forced to aggregate their announcements? Looking at e.g. the peering tables I get at DECIX or via our uplinks, I see hundreds and thousands of subnets announced by providers from their own PA space, broken down into _many_ subnets, additionally to the aggregated prefix. And I don't think all (or even a mentionable percentage of) those customers are multi-homed and therefore require the smaller announcement be made due to more-specific routing ... at that point, possibly 25% of the routing tables could be saved ... Rather, in order to discourage PI usage by endusers who don't actually need a PI network from a technical standpoint, why not charge an appropriate amount for assigning PI networks? Please correct me if I got this wrong, but at the moment, PI networks count towards the LIR's rating. Which can end up - in a way - to be unfair, as PI networks are requested for end customer, which may at some point in the future switch providers. The points are still counted, even though the provider does not have any revenue to count against it. By defining a rate of €X per /24 would one on hand reduce the requested size of the requests, and also make users think twice about requesting technically unnecessary PI space ... Michael.Dillon@btradianz.com wrote:

If the organization is simultaneously applying for an AS number or the organization already has an AS number, then we should consider routing to be a major issue if the organization says that it is. After all, the only purpose of having an AS number is to do routing.

Indeed. Still, an AS should not be a prerequisite though, as using an PI could be the first part of setting up "advanced routing". Regards, -garry

--On 18 September 2006 17:58 +0200 Gert Doering <gert@space.net> wrote:

The problem with the current scheme is that it's a one-time fee, payable only in the year of PI assignment (!), and after that, the PI is free.

This is important given that there *is* an ongoing cost of PI space (e.g. operating the databases which say who's been allocated what), and this is set to increase if anything, with the plans to digitally sign allocations/assignments in order to increase the security of the routing system (e.g. sBGP). I find myself more in favour of having to "lease" number resources, as long as the cost is reasonable (and we can see to that because of the "bottom-up" process that exists), rather than "buy" them. This will, if anything, help with resource reclamation and re-cycling in the longer term. Regards, Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike@linx.net http://www.linx.net/

Hi Jeroen, On Mon, 18 Sep 2006 18:33:54 +0200, Jeroen Massar wrote:

(who indeed would like to see a scheme like sBGP deployed :)

The sBGP will consume _significantly_ more resources in the network for even a small amount of sBGP prefixes than PI will consume ever. Crypto Algos require a lot of computational power on conventional CPU's, the very huge majority of backbone routers has no special crypto hardware on board. _If_ sBGB should be implemented, I do sugest to make the BGP PI-friendly (e.g. separation of prefix and AS attributes) in the same step, as sBGB will require an router hardware and software update anyway. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0

Hi Gert, On Mon, 18 Sep 2006 17:58:22 +0200, Gert Doering wrote:

I strongly think that the latter kind should not be able to get PI space easily, for a one-time-fee, and burden the *recurring cost* for their convenience on everybody else.

Your approach sounds like "Planwirtschaft" and generating jobs for buerocrates ("right-to-use PI certification agency auditing office supervisor" ;-/ How about taking the potential money received for PI to finance a better BGP / routing technology or at least memory for poor ISP's ? If we would handle other network technological issues like the "PI is impossible - large tables are impossible" one, we probably would have a "right-to-use-a-9600-baud-modem certification agency" instead of DSL, just because someone would argument that it is impossible to have more than 10 high speed channels on a standard 1000 phone lines copper cable ... Do you remember the old "private modems are bad and will destroy the phone network" arguments from former Bundespost ? The PI routing issue is a technical challenge which cries for an technical solution (yes, large distributed databases do exist) and not for an additional administration. 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 Gert, On Mon, 18 Sep 2006 21:59:35 +0200, Gert Doering wrote:

Of course I hope for a technical solution that will solve everything.

Until then, I do my best to make sure the network will continue running - and part of that effort is to make sure that costs are at least partially paid by those that have the benefits.

This is a nice try, however I doubt you will be able to charge those who de-aggregate prefixes and thus cause the vast majority of the table growth. At the end of the day a lot of these de-aggregation results from "security concerns" since 9-11. You may try to charge Mr. Bin Laden, however there are other ones in the queue, too. To keep your network running, you may either: 1. invest or 2. filter those redundant de-agregated announcements (e.g. don't take a /24 with the same AS-path as the /16 it is contained in) However, I know the second (filter) approach _will_ cause your company which pays your salary loosing business, as your company is an transit ISP and thus your customers router will prefer the more specific of your competitor supplying the full table. This should answer the question: # If we accept argument that we should, as a community, advocate no # smaller PI assignments smaller than a /24 because of table # filtration, what happens when the table grows to the size that # operators start to filter on longer masks ? This won't happen, as doing so will cause loss of business for those transit networks which do so. Sadly enough, you should also face that there is nothing, really nothing, that the RIPE can do to stop the table growth influenced by other regions in this world. If the buzzword "security" comes up with large US telcos, this is the end of all discussions in these days. The only thing restrictive policies limited to the RIPE region, as the PI /24 issue and the v6 200 customer rules cause is: - Local ISP's homed in the RIPE region only will be less competitive compared to international ISP's. - People will ly to the hostmasters :-( We should not make policies which cause said disadvantages without having any significant advantage. 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

Oliver Bartels wrote:

2. filter those redundant de-agregated announcements (e.g. don't take a /24 with the same AS-path as the /16 it is contained in)

However, I know the second (filter) approach _will_ cause your company which pays your salary loosing business,

It is a good idea to set up the default route to one of upstreams when you set up filtering. This saves routers' memory, but leaves your connectivity fine. You can even accept 0.0.0.0/0 from several upstreams with different localprefs to keep channels back-up working. P.S. I don't believe backbone carriers who don't have upstreams at all need to conserve some extra kilobytes of memory ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

How about taking the potential money received for PI to finance a better BGP / routing technology or at least memory for poor ISP's ?

Can we please kill this "let's get RIPE/NCC to charge more money for X so that we can give it to Y" idea for once and for all? The RIPE NCC is not a taxation agency. Let's not waste time proposing to turn it into one.

Do you remember the old "private modems are bad and will destroy the phone network" arguments from former Bundespost ?

Yes, we all remember that. Just as we remember the times when - due to routing table growth - a whole pile of different types of equipment were rendered defunct due to their inability to deal with a full routing table, whether through RIB or FIB memory deficiency. At each stage, this cost ISPs a lot of money to rectify. The Bundespost argument (repeated by pretty much all telcos worldwide, as far as I can tell) was to a large extent FUD based on presumption and fear of the unknown. Routing table growth is a well defined phenomenon which costs real money to deal with. [Incidentally, we also remember the NFSnet $15 domain tax and the way that it was declared illegal.]

The PI routing issue is a technical challenge which cries for an technical solution (yes, large distributed databases do exist) and not for an additional administration.

The "PI routing issue" does not exist, at least in the terms that you're using here. What exists is a large growth in routing table size, due to - inter-alia - PI announcements, PA subnet announcements and the fast organic growth of full PA netblocks. Also, large distributed databases are of no real relevance to switching IP packets at 10G speeds. However, this is not particularly relevant to proposal 2006-05. The proposal may - slightly - increase the rate of uptake of PI assignments in the RIPE catchment area, and this may proportionally increase the number of prefixes in the routing tables. But the only thing that's stopping people from registering /24's at the moment where they really need less than this amount of space, is their inclination not to lie to RIPE. Removing this (almost) requirement to lie to get a /24 is not going to open up the flood gates and cause the internet to collapse. Nick

Gert Doering wrote:

If we make PI cost a "reasonable" price (like "extra-small LIR") per year, this will not hinder networks that "must have" PI very much - and those that find PI a nice and cheap convenience might reconsider.

In this case, at first you are going to kill a small and extra-small business (I believe, it is *only* real target for those who speaks againist PI - to simplify competition for themselves) as well as non-commertial and educational requesters. Second, "PI vs LIR" deal. If one real wants own IP/AS, and ready to pay for it, this one WILL add a prefix to the global routing table, either he become a LIR or only get PI. BUT. If costs are equal, EVERY manager (who make final decision for what to pay) will take MORE "something" (IP addresses in this case) for same (or near) price. And no technician can argue with that. So instead of PI /24 they really need, they get a LIR with at least /21 they really don't need in any case. And we loose in conservation of address space in 8 times (not winning in aggregation any percent)!!! -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

Nobody is aiming to exclude people from participating in the Internet, but PI isn't the *only* way.

IP addresses (PA and PI) are not just used for the Internet. Many IP address blocks are only used on IP internetworks that are not part of the public Internet. Some of these internetworks allow limited traffic exchange with the public Internet through NAT gateways. Others allow no traffic interchange at all and enforce this with firewalls in case participants fail to maintain the air gap between their Internet connections and the other internetwork. Most of these IP address blocks, PI and PA, are not used by a military organization. They tend to be used by business federations and by companies providing a business service to customers over a non-public internetwork. RFC 2050 paragraph 3(a) specifically allows for IP address allocations/assignments to these non-Internet uses. When RIPE is making policy about IP address use, we should be careful to not be Internet-centric because that could be interpreted as anti-competition. Companies can justify PI assignments or PA allocations/assignments independently of whether they intend to connect to the public Internet. As far as participating in the Internet, not all organizations necessarily want 100% global connectivity. In particular, organizations in countries with a non-colonial language may only want connectivity to a few countries which they consider to be their "community" or their "market". For the record, colonial languages are those like English, French, Spanish, and Russian which are widely used outside of their area of origin due to a previous history as the language of empire. You can understand that a business who markets services in Hungarian might only want connectivity to Hungary, Rumania, Austria, Slovakia, and Ukraine where there is a population of Hungarian native speakers. They might do this by buying connectivity to multiple local ISPs in this region and asking those ISPs to not forward their announced route(s). That is a valid use of a PI assignment for multihoming that does not result in the use of a slot in the global routing table. --Michael Dillon P.S. my choice of Hungarian was entirely random. The same thing applies for languages like Catalan, Italian, Albanian, German, etc.

Gert Doering wrote:

(Besides this, nobody said that the price would have to be the *same* - I specifically mentioned the "extra small" LIR category)

Yep, it is certainly minimum /21 PA I said ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

Dmitry Kiselev wrote:

Max, how say that fees will be equal? As for me, PI/24+ASN should have yearly fee acceptable for most small companies. If they really need it, they will pay for it. Once payments stoped - resources returned and ready to reassignment.

Seems to be very reasonable. For example, as it was a long before. But there should be a schema how I can pass mntner to client, and therefore "block" (or remove) objects in case of payment stops. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

Hi Hank! This story is about PA/LIR, where (again, in the theory) all is quite simply. No money -> closing contarct (as in terms of it) -> getting back IPs. But. If there is PI space (and ASes not associated with LIR company) - there is also third party: end-user. He shouldn't have any troubles if LIR goes out of business or became unlucky in it. I have a large experience in providing PI/AS (even own a LIR with primary service is PI assignment i ex-USSR). My opinion is: 1. PI is a GOOD thing. 1a. It stimulates small and medium business, providing Internet in regions with a lack of money. Yes, EUR2000 really can be a yearly turnover of small Internet company here. 1b. It conserves IP space (people do request as many space as they really need, not /21 "because it is given at LIR startup") 2. PI and AS SHOULD be billed in the regular basis (yearly, quarterly or so). This pervents dead IP space beeing locked. 3. There shoud be an mechanism (NOT mntner as it is now) to suspend and remove address space if there is no payments. Again, _not_ LIR's mntner in object. 4. There should be clear and simply mechanism ("what-to-do, step-by-step") how PI end-user can change LIR if something goes wrong (LIR is out of business, and even LIR goes mad). 4a. This mechanism should be quite easy and clear so anyone can get rid in it in ten minutes, therefore there should be something to stop user switching between LIRs looking where is cheaper (and in practice, killing the market by some inadequate players will do demping). 5. Of course, RIPE (LIR?) should check actuality of contact information of that kind of objects. Or if not really check - have an ability to suspend objects if this information is invalid (i.e. RIPE can't contact user with that information). Yes, I think there should be "suspended" objects: not visible in the database (or visible with some flag, but not routeable - without route objects or so). These objects can be returned to life in some cases (user at least payed a bill, provided actual contacts or so) or wiped in some other cases. Maybe, we should learn things from domain name registering systems. If it is interesting, I can do something like presentation or policy draft? So it is a good topic to talk at the RIPE meeting anyway ;) Hank Nussbacher wrote:

On Tue, 19 Sep 2006, Max Tulyev wrote:

...

Dmitry Kiselev wrote:

...

Max, how say that fees will be equal? As for me, PI/24+ASN should have yearly fee acceptable for most small companies. If they really need it, they will pay for it. Once payments stoped - resources returned and ready to reassignment.

Seems to be very reasonable. For example, as it was a long before.

Once payment stops resources are not returned (as far as my example shows below). See: http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.ht...

for an example I've been tracking for 5 years now (company bankrupt).

ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt shows the following still: il.doarnet DoarNet Ltd.

19981211 212.77.128/19 ALLOCATED PA

So in theory your idea sounds nice. In practice it doesn't work.

Regards, -Hank Nussbacher http://www.interall.co.il

-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

On Wed, Sep 20, 2006 at 11:51:59AM +0300, Dmitry Kiselev wrote:

...

This story is about PA/LIR, where (again, in the theory) all is quite simply. No money -> closing contarct (as in terms of it) -> getting back IPs.

According to current IPv4 Address Policy PI address space should be ASSIGNED to END USERS ONLY. ISP usually provide service for some (or many) organizations, i.e. contact info for some ranges may be very different. Although ISP is close to its customers they are different companies - end-users in Policy terms. ISP with PI can't create separate DB records and it is violate section 4.0 of Policy. It is violate item 5 from Your opinion quoted above too. ;)

Since PA have no such disadvantages and have a good scale capability it should be used by ISPs. PI is still good for small/medium *enterprises* which large enough to do multihoming. And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it). The only advantage of PI's is that customer doesn't needs to be renumbered if he leaves his primary ISP.

...

...

On Tue, 19 Sep 2006, Max Tulyev wrote:

...

Dmitry Kiselev wrote:

...

Max, how say that fees will be equal? As for me, PI/24+ASN should have yearly fee acceptable for most small companies. If they really need it, they will pay for it. Once payments stoped - resources returned and ready to reassignment.

Seems to be very reasonable. For example, as it was a long before.

Once payment stops resources are not returned (as far as my example shows below). See: http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.ht...

for an example I've been tracking for 5 years now (company bankrupt).

ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt shows the following still: il.doarnet DoarNet Ltd.

19981211 212.77.128/19 ALLOCATED PA

So in theory your idea sounds nice. In practice it doesn't work.

-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

-- Dmitry Kiselev

-- Regards, Gennady Abramov, CCNP, AGV77-RIPE Demos-Internet NOC Phone: +7 (495) 737-0436 http://www.demos.ru/address

On Wed, Sep 20, 2006 at 02:54:09PM +0100, Nick Hilliard wrote:

...

And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it).

It's nothing to do with your LIR. You can only do this if your secondary upstream agrees to it. Your LIR can shout and jump up and down and tell you not to do this, but they can't stop their competitor from leaking a prefix which they really shouldn't. Mm... In most cases, LIR protects (Or at least, should protect, I think) PA assigments by his own mntner. Secondary upstream can't create route object on this specific PA assigment from first LIR without agreement, and this prefix wouldn't be routed in Internet normally.

Fortunately, most ISPs won't do this sort of thing.

Nick

-- Regards, Gennady Abramov, CCNP, AGV77-RIPE Demos-Internet NOC Phone: +7 (495) 737-0436 http://www.demos.ru/address

Which is unfortunate. Because if scaling of the global routing table is really as big of an issue as some people claim,

It's just an issue which crops up again and again, and costs money to solve each time. I've got a bunch of dual stacked sup720 pfc3b's. These no longer take a full v4 routing table in their default configuration, and shortly, I expect them not to be able to take a full v4 routing table using any soft configuration, except by filtering out routes. Yes, I can upgrade them. But it's an issue. It means downtime and lots of €€€.

then the above scenario defines a BEST PRACTICE for multihoming without global impact.

Let's be fair here - it's half-baked multihoming. If your connection to your LIR network goes down, you're going to be left with patchy connectivity at best. Half baked != best practice.

But, as I said in my last message, without a globally agreed definition of the problem and a globally agreed way forward to solving it, any action that RIPE takes to limit growth of the global routing table is just penalizing European businesses for no net benefit.

But, but, but, but.... in this proposal, RIPE is not taking action to limit the growth of the global routing table. Under the terms of 2006-05, the intent is to make RIPE PI assignments more useful in the Internet, which makes PI a more attractive option, which helps European businesses.

PI assignments are a good thing because they help get organizations online. When an organization needs this kind of address range, RIPE should be ready to give it to them. In the end, all assignments and allocations are subject to technical justifications based on RFC 2050.

Exactly - this is what this proposal is about. Separate to this proposal are the following items of note: 1. 2006-05 affects address assignment policy, and address assignment policy indirectly affects routing table growth, 2. we have no garbage collection mechanism for stale PI assignments, 3. readily available PI is good for business, 4. lots of people believe - with good reason - that readily available PI is bad news from a network scalability point of view, and therefore: 5. one of the reasons that people might be unhappy about this proposal is because it may increase the amount of PI space assigned by RIPE. Nick

Hi! On Wed, Sep 20, 2006 at 04:21:27PM +0400, Gennady Abramov wrote:

...

...

This story is about PA/LIR, where (again, in the theory) all is quite simply. No money -> closing contarct (as in terms of it) -> getting back IPs.

According to current IPv4 Address Policy PI address space should be ASSIGNED to END USERS ONLY. ISP usually provide service for some (or many) organizations, i.e. contact info for some ranges may be very different. Although ISP is close to its customers they are different companies - end-users in Policy terms. ISP with PI can't create separate DB records and it is violate section 4.0 of Policy. It is violate item 5 from Your opinion quoted above too. ;)

Since PA have no such disadvantages and have a good scale capability it should be used by ISPs. PI is still good for small/medium *enterprises* which large enough to do multihoming. And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it). The only advantage of PI's is that customer doesn't needs to be renumbered if he leaves his primary ISP.

...and does not pay any money! ;) It is major argument for most of PI holders.

...

...

...

...

...

Max, how say that fees will be equal? As for me, PI/24+ASN should have yearly fee acceptable for most small companies. If they really need it, they will pay for it. Once payments stoped - resources returned and ready to reassignment.

Seems to be very reasonable. For example, as it was a long before.

Once payment stops resources are not returned (as far as my example shows below). See: http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.ht...

for an example I've been tracking for 5 years now (company bankrupt).

ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt shows the following still: il.doarnet DoarNet Ltd.

19981211 212.77.128/19 ALLOCATED PA

So in theory your idea sounds nice. In practice it doesn't work.

-- Dmitry Kiselev

Gennady Abramov wrote:

And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it).

Multihoming, but not backups. Because of some traffic will flow through [aggregated] LIR route if even link with LIR will be damaged. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

Gennady Abramov wrote:

...

Gennady Abramov wrote:

...

And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it). Multihoming, but not backups. Because of some traffic will flow through [aggregated] LIR route if even link with LIR will be damaged. It is very some traffic. Some traffic flows on default gateway, even if you have BGP full view on

On Wed, Sep 20, 2006 at 06:03:09PM +0000, Max Tulyev wrote: the router... :) Normally, longest prefix has highest priority. If your multihomed prefix doesn't exist in some part of Internet, you may have troubles with connectivity with this part of Internet, don't looking PA or PI addresses you uses. In the case of PA specific, traffic from this part of Internet will flow to aggregated route, and, if specific route would be found on next hops, will go to specific route from this next hops. In the case of PI, traffic will flow to default or will be dropped. Anyway, if your prefix doesn't routed anywhere, it isn't normal situation, don't depend of addresses u use.

Good only in the theory ;) IRL some "wise" admins filters out more specific if there is less specific (? - as I can understand this). This means some part of Internet will be not accessible if there is no link between you and your LIR. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

On Thu, 2006-09-21 at 02:00 +0100, Andy Davidson wrote:

Max Tulyev wrote:

...

This story is about PA/LIR, where (again, in the theory) all is quite simply. No money -> closing contarct (as in terms of it) -> getting back IPs.

You're opening up a huge can of worms here. 'Getting back IPs' means contacting peers and upstreams and telling these parties to stop accepting the announcement from the non-paying company. If the company is still paying bills to their upstreams, do you think upstreams will take kindly to this action ?

What the immediate upstream may think would be irrelevant. *If* there is *ever* consensus within the RIPE community to have the NCC reclaim blocks, there would have to be mechanisms in place to enforce the decision. That would most probably involve a quarantine period for reclaimed prefixes during which transit providers in the region would be asked to black-hole the space.

The RIPE NCC deleting the inetnum object doesn't mean the addresses stop routing ...

It only takes a handful of large transit providers to black-hole a prefix to render that address-block useless.

RIPE NCC possibly have no contract with the companies that would need to stop accepting the prefixes from the debting party.

There are more than enough transit-providers on contract. The immediate upstream of the reclaimed block alone makes no difference. The question isn't if it can be done or not, but whether the RIPE community as a whole really wants such a scheme to be implemented. -- Per Heldal - http://heldal.eml.cc/

leo vegoda wrote:

We always 'quarantine' address space when it is returned to us. Allocations from about 65 LIRs have been returned so far this year.

And what will be if some totally mad person will announce that space and will say "It's mine, not your!!!"? Can RIPE use some (which?) force in this case? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

On 21 Sep, 2006, at 15:50, leo vegoda wrote:

Hi Max,

On 21 Sep 2006, at 7:41GMT+02:00, Max Tulyev wrote:

...

...

We always 'quarantine' address space when it is returned to us. Allocations from about 65 LIRs have been returned so far this year.

And what will be if some totally mad person will announce that space and will say "It's mine, not your!!!"? Can RIPE use some (which?) force in this case?

The RIPE NCC has no authority over routing decisions taken by network operators.

Though hopefully it will have public records for ISPs to see who has been assigned the IP block through the established process, right? Joao

But this is nothing special imho, the very same statement holds true for any space that as yet hadn't been "in use" at all. Bottom line: if there isn't a record to properly docment assignment to an end site, then the use or routing of that address space is at least vey, very, questionable(1). But if you don't double-check - you'll never know ;-) Wilfried. (1) announcement of a full PA allocation as one route, covering as yet unassigned space, is an exception to this rule. leo vegoda wrote:

Hi Joao,

On 22 Sep 2006, at 10:19GMT+02:00, Joao Damas wrote:

[...]

...

...

...

...

We always 'quarantine' address space when it is returned to us. Allocations from about 65 LIRs have been returned so far this year.

And what will be if some totally mad person will announce that space and will say "It's mine, not your!!!"? Can RIPE use some (which?) force in this case?

The RIPE NCC has no authority over routing decisions taken by network operators.

Though hopefully it will have public records for ISPs to see who has been assigned the IP block through the established process, right?

If a network is announcing address space that has been returned to us there will not be a registration for the specific prefix being announced, just a registration for the allocation from which it is 'taken'.

Regards,

Randy Bush wrote:

...

Though hopefully it will have public records for ISPs to see who has been assigned the IP block through the established process, right?

if we are lucky, this time next year, you will be able to verify an X.509 certificate chain with rfc 3779 resource extensions, and have significant confidence in rights to address and asn resources.

As I can understand, I can verify origin of prefix, prefix itself, but it can't authorize is that certain as-path legitimate or not. Like I can figure it out from routing registry DB. Isn't it? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

On Mon, Sep 25, 2006 at 06:43:40AM -1000, Randy Bush wrote:

...

...

if we are lucky, this time next year, you will be able to verify an X.509 certificate chain with rfc 3779 resource extensions, and have significant confidence in rights to address and asn resources.

As I can understand, I can verify origin of prefix, prefix itself, but it can't authorize is that certain as-path legitimate or not. Like I can figure it out from routing registry DB. Isn't it?

the current work will provide a formally verifiable demonstration of ownership of address space.

wow... address ownership. thats kind of a new concept. last i checked, most RIRs deal with the concept of address stewardship. does that mean i can assert ownership of integers and the RIR system will back me up?

one first useful step for an isp is to use the x.509 data to verify ownership assertions in the irr when building filter lists, for example. randy

--bill

On Mon, Sep 25, 2006 at 08:40:18AM -1000, Randy Bush wrote:

...

wow... address ownership. thats kind of a new concept. last i checked, most RIRs deal with the concept of address stewardship. does that mean i can assert ownership of integers and the RIR system will back me up?

thanks for very educational contribution.

randy

your welcome. and unless you have verifiable information to the contrary, i (for one) would appreciate it if you would be more precise regarding address allocation/delegation and stewardship. To my understanding, addresses are NOT property and can not be owned. I will be pleased to be reliably informed otherwise. Please educate me here. --bill

Randy Bush wrote:

...

...

if we are lucky, this time next year, you will be able to verify an X.509 certificate chain with rfc 3779 resource extensions, and have significant confidence in rights to address and asn resources. As I can understand, I can verify origin of prefix, prefix itself, but it can't authorize is that certain as-path legitimate or not. Like I can figure it out from routing registry DB. Isn't it?

the current work will provide a formally verifiable demonstration of ownership of address space.

to achieve your goal _formally_ will require something like sbgp.

the irr is an informal way to kinda achieve what you want. and we use it today.

one first useful step for an isp is to use the x.509 data to verify ownership assertions in the irr when building filter lists, for example.

I just think (if I correct understood that, sorry but this RFC is not easy reading) small enhancement of this will give us the large improvement: we can do filtering of unauthorized announcements (announcements of right prefix originated with right AS but from wrong place)! -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

On Mon, 25 Sep 2006, Randy Bush wrote: <snip>

will need one more thing to verify origin, what is called a Routing Origination Authority, which looks a lot like a cert and is stored in the infrastructure, but which binds a cert of address ownership to the as number which is authorized to announce it. this would be verifiably signed by the formal owner of the address space.

Hope you don't mean ownership as in really own it forever, but more like right to use it if you've payed your fee etc ? -- ------------------------------ Roger Jorgensen | roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------

On Tue, 26 Sep 2006, Roger Jorgensen wrote: Why not just replace the word "owner" with "leaser"? I always assumed that I was leasing IP address space from the RIRs and not owning it. -Hank

On Mon, 25 Sep 2006, Randy Bush wrote: <snip>

...

will need one more thing to verify origin, what is called a Routing Origination Authority, which looks a lot like a cert and is stored in the infrastructure, but which binds a cert of address ownership to the as number which is authorized to announce it. this would be verifiably signed by the formal owner of the address space.

Hope you don't mean ownership as in really own it forever, but more like right to use it if you've payed your fee etc ?

--

------------------------------ Roger Jorgensen | roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------

+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.

Per Heldal wrote:

What the immediate upstream may think would be irrelevant. *If* there is *ever* consensus within the RIPE community to have the NCC reclaim blocks, there would have to be mechanisms in place to enforce the decision. That would most probably involve a quarantine period for reclaimed prefixes during which transit providers in the region would be asked to black-hole the space.

No, not black-hole! Just don't accept! Because of there will be another period of "de-black-holing" ;) and so on...

It only takes a handful of large transit providers to black-hole a prefix to render that address-block useless.

Again, if there is no inetnum/as/roure objects, "large transit providers" just drop this because of RR DB filters. This also true for those who "transmit pirate signal into the Matrix" ;) using fake IPs and ASes.

The question isn't if it can be done or not, but whether the RIPE community as a whole really wants such a scheme to be implemented.

I think it must be done. Not only because of this case, but also for blocking unauthorized announces. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

You're opening up a huge can of worms here. 'Getting back IPs' means contacting peers and upstreams and telling these parties to stop accepting the announcement from the non-paying company. If the company is still paying bills to their upstreams, do you think upstreams will take kindly to this action ?

The RIPE NCC deleting the inetnum object doesn't mean the addresses stop routing ...

RIPE NCC possibly have no contract with the companies that would need to stop accepting the prefixes from the debting party. The deletion of "route:" object means troubles with routing of the

On Thu, Sep 21, 2006 at 02:00:20AM +0100, Andy Davidson wrote: prefix. Of course, it is possible to route prefix without corresponding "route:", but it isn't very easy. And, of course, forget of any routing policy with this prefix, you may just to place this prefix to the Internet somehow. Of course, if you can (Talk with your upstreams to configure "hand-made" filters, or get an upstream who will accept "any" from you and have such peers and upstreams, etc). -- С уважением, Абрамов Геннадий, CCNP Отдел сетевого управления (NOC) ЗАО "Демос-Интернет" Тел.: (495) 737-0436 http://www.demos.ru/address

(I believe, it is *only* real target for those who speaks againist PI - to simplify competition for themselves)

Um. No. It is also people who have experienced the "joys" of watching routers falls over (and the subsequent cascading failures) because of too much routing information and who wish to avoid similar happy experiences in the future. Simply, PI to network topological leaves doesn't scale. Rgds, -drc "Those who cannot remember the past are condemned to repeat it." -- George Santayana

Max, On Sep 19, 2006, at 11:37 AM, Max Tulyev wrote:

David Conrad wrote:

...

Simply, PI to network topological leaves doesn't scale. I think it is not an argument for PI.

Right. It is an argument against PI.

You also can't scale PA when it ends. You only can allocate new one.

The difference, of course, is that PA (by definition) can be aggregated into a single announcement, thereby reducing the amount of information sloshing around the routing system. It is true that if an ISP runs out of PA prefixes to assign to their customers that they'll need to get another one and that additional prefix will need to be PI, but that is a single prefix that aggregates all the customers numbered out of that prefix. This is Routing Scalability 101.

It is an argument for thinking before doing. Best way is to set up period of requesting, i.e. one company can do same kind of requests for example once in two years. It makes a company think twice about scaling ("do we requesting enough space for our grow?") and about conserving

Even if you can have a crystal ball that predicts your future addressing requirements for arbitrary amounts of time into the future, this still has a 1:1 ratio of end user organization to routing prefix and every flap of that prefix has to get propagated globally. This simply doesn't scale. Rgds, -drc

David Conrad wrote:

...

You also can't scale PA when it ends. You only can allocate new one.

The difference, of course, is that PA (by definition) can be aggregated into a single announcement, thereby reducing the amount of information sloshing around the routing system. It is true that if an ISP runs out of PA prefixes to assign to their customers that they'll need to get another one and that additional prefix will need to be PI, but that is a single prefix that aggregates all the customers numbered out of that prefix. This is Routing Scalability 101.

Please, see the difference of just customers (who don't know anything about PI vs PA at all, using their ADSL connection and be happy) and those who need own routing policy and own IP space. You can't aggregate second one into single prefix by definition. Again, I don't even think about "portable IPs to any customer" at this stage of Internet evolution. May be a bit later? But not now. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

David Conrad wrote:

Max,

On Sep 20, 2006, at 4:40 AM, Max Tulyev wrote:

...

Again, I don't even think about "portable IPs to any customer" at this stage of Internet evolution. May be a bit later? But not now.

So what is the criteria between customers who should get PI and who shouldn't?

Multihoming. In some other rare cases - really large problems with renumbering (hosting provider with 10000 domains). -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

Hi, On Wed, Sep 20, 2006 at 10:17:32AM +0100, Michael.Dillon@btradianz.com wrote:

But since this hypothetical consortium does not currently exist, RIPE can find nobody to take responsibility for global routing table impact and therefore cannot include global routing table size in its policies.

Invalid conclusion. *We* are RIPE. *You* are part of RIPE. So of course the RIPE policies can consider routing table impact. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

On Wed, 2006-09-20 at 11:51 +0100, Michael.Dillon@btradianz.com wrote:

RIPE represents network operators from one of the 5 regions of the world which share the global routing table. How can RIPE reasonably deal with such a global issue unilaterally?

RIPE is not an island and no matter how much we'd like to pretend otherwise, RIPE addressing policies cannot be meaningfully divorced from the population of routing table slots. You're free to agree or disagree with this, but the bottom line is that if RIPE changes its policies on PI assignment, this is likely to impact the number of announced PI prefixes, regardless of whether the announcements are accepted or not. Also, RIPE is not dealing with this unilaterally. It's dealing with the issue in its own area, which is what it's mandated to do by its members and charged to do by ICANN. If it makes policies in one particular area, these policies are not directly relevant in other parts of the world, unless other RIR areas in the world decide that they want to adopt similar policies. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie

* Max Tulyev:

Second, "PI vs LIR" deal. If one real wants own IP/AS, and ready to pay for it, this one WILL add a prefix to the global routing table, either he become a LIR or only get PI. BUT. If costs are equal, EVERY manager (who make final decision for what to pay) will take MORE "something" (IP addresses in this case) for same (or near) price.

Reality check, please. Market prices for PI space (excluding router setup etc.) are quite close to LIR setup fees.

I have a question though, the proposal includes the notion of "major issue", perhaps this could be specified a bit more? Or is it clear how this would be interpreted by a hostmaster processing an application, that if the customer adds "I need to advertise this on the public internet" it will automatically be known that a at least a /24 is needed?

If the organization is simultaneously applying for an AS number or the organization already has an AS number, then we should consider routing to be a major issue if the organization says that it is. After all, the only purpose of having an AS number is to do routing. --Michael Dillon

Per Heldal wrote:

On Tue, 2006-08-29 at 10:25 +0200, Filiz Yilmaz wrote:

...

PDP Number: 2006-05 PI Assignment Size

Dear Colleagues,

A new RIPE Policy has been proposed and is now available for discussion.

This proposal suggests to have the minimum assignment size for PI assignments to be a /24 when routing is a major issue for a multihoming End User.

I still think that proposal is a completely inappropriate approach to take volatile(1) routing configuration criteria as (major) input for manufacturing address assignment policies. (1) volatile in the sense that a) (change in) filtering behaviour of ISPs is not consistent, nor under the control of the body having to agree on addressing policy, and b) as has been pointed out already, this behaviour might change "any time", rendering the policy broken again.

When should RIRs allocate v4 PI-blocks so small they won't be globally accepted? Such would in reality become small "private" blocks. For v6 the discussion is still open wrt the allocation of private (unannuced) addresses, but for v4 we should stick to rfc1918 and ask those who don't qualify for an allocation big enough to pursue de-aggregated PA-space which at least will be routed through its wider aggregate.

The wording in the policy should instead reflect the need for consistence between the minimum size of allocated blocks and common filtering recommendations for the related IANA container-block (/8).

//per

Another aspect of this proposal is that it would brake the equal opportunity approch opposite PA-Space - unless we raise the minimum block size for PA- assignments to /24 or whatever, too. Wilfried.