- Test - lists.nanog.org

Policy Statement on Address Space Allocations
by Daniel Karrenberg 31 Jan '96

31 Jan '96

> Peter Galbavy <peter(a)demon.net> writes: > > Thanks for amitting at least that much ;-). > > Would you care to share your thoughts on less flawed paradigms > > that will work with current or near-future kit ({hard,firm,soft}ware for > > the non-british)? > > I wish I knew. In this I am the worst type of couch potato. .... So stop critising "paradigms" without proposing better ones or at least research the rationales and history behind them. > > Yes, CIDR works if addresses are allocated *somewhat* topologically. > > And in the case of (I am guessing) > 70% of RIPE NCC allocated addresses > are not. First you missed the emphasis on *somewhat*. Second you are guessing wrong. >From both of the above it seems that you only know of and are only concerned with your own particular situation. > This is no ones "fault", just the way the policy is. Therefore > I say the policy is WRONG. What is the better policy? > > The continental component in address space allocation is pure policy and > > has little to do with CIDR. The policy only seems unreasonable when > > considering only the issue you raise. > > But it is the *primary* issue. What else is there that influences how > addresses are allocated in a CIDR or hierarchical way ? More local topology than continental one is *very* important. > We have e-mail for admin - it is timezone orthoganal. The existance > of the RIPE NCC should just be remote, local staff for the InterNIC. Fine with me. Do RIEP and theother contributors agree? We can re-organise starting next week. > If the RIPE NCC applies a "local model" then it is not conforming > to the policies of IANA and the IAB that you keep referring to. The RIPE NCC applies local policies within the boundaries of the global policies. > > Personally I believe that even this issue is irrelevant for providers of > > the size of Demon. It makes no difference where you get a /16 from. > > Except you will not, even with correct justifications, give us one for > our dial up services. > > To wash some dirty laundry here ... I could help you washing in detail but I do not think this is appropriate in all these fora. For the record I will summarise: Demon is statically assigning IP addresses to dialup customers on a large scale. This results in adresses being used per customer and not per dial-in port. Obviously then number of customers is less limited than that of dial in ports. There is concern about the wastefulness of this practise on a large scale and the non-linear effects it could have on address space usage. Hence it is *global*, read IANA, policy to strongly discourage this practise and not to allocate more addresses than three months worth of usage. This is not just an NCC policy! Indeed we have allocated you a /19 to start with in addition to the address space you have been allocated for other purposes than dial up IP. Of course you will receive further allocations within the range of the above policy whenever you need them. Of course we will do our best to make the further allocations aggregateable with previous ones. Assignments of address space by local IRs to customers have to be registered in the RIPE (whois) database. You have raised that your commercial interest of keeping your customer list confidential should outweigh this registration requirement in the case of individuals because of the special characterisitcs of the (consumer) market you operate in. We have recognised that the tradeoff between the benefit of registration and the commercial interests of individual dialup providers is indeed special and consequently have worked with you(!), IANA and the other regional registries to establish a global policy for this special case. This policy has to take into account the need for verification of assignments since the registration requirement has been dropped and the database is not available for verification. We have worked with you in this matter, you have agreed to the result. I think it is *very* inappropriate to publicly abuse those who have worked with you and to throw polemics at compromises some of which you have even suggested and all of which you have agreed to. I will leave the polemics for what they are. > I wish I had the time, but it appears that we will have to make the > time to get more involed. sigh. Yes, it is more appropriate than polemicising publicly. > > What we do *not* do is consider *individual* interests of some over > > the ones of others. If we would do that we would eliminate our > > "raison d'etre". > > Why not. We are not a communist society are we ? Each individual member > of RIPE have their own unique requirements in a commercial and > academically challenging world. We have a USP (Unique Selling Point) of > giving our paying customers there own IP address (OK - it is not > unique, but close enough). We have built propretary technology that > allows our users to use *any* of our dial in points and get the same > service, with the same IP number etc etc, and as one of our primary USPs > we cannot allow the RIPE NCC to try to change that. > ... > The RIPE NCC model probably would work if it took into account that > fact that its members are (on the whole) commercial organisations > that sell differing products and services and have different > requirements of the NCC. This does not appear to be the case. You have received sufficient address space for your present needs and you have been assured that -unless there are policy changes- you will receive enough for your future needs. The same policy is applied to everyone. --- Polemic mode on ---- I have the slight suspicion that for you the only good model is one that does exactly what *you* want, everyone else be damned. --- Polemic mode off ---- Daniel

3 3

Re: Policy Statement on Address Space Allocations
by asp＠uunet.uu.net 31 Jan '96

31 Jan '96

> I think that we solved that problem by providing full information for > all of the routes to routers within the area, and none outside. > If you wish to correct me, feel free. So everyone w/in the area can get to all of these sites (& since they have to carry full routes, they don't save any routing table space), and everyone outside of this area has no routes to any part of the area and thus can't get to any of these sites at all? Humm; if I understand you corretly, this seems to be a loose all around. --asp(a)uunet.uu.net (Andrew Partan)

6 10

RE: MCI to market MSN
by Hank Nussbacher 31 Jan '96

31 Jan '96

On Tue, 30 Jan 1996 20:01:36 -0800 (PST) alexy(a)alpha.c2.org wrote: >MCI and Microsoft will now be building networks together, MCI ditching >Netscape and starting to sell Microsoft network access tools & pushing >MSN... > >>From the local rag news paper: > >"MCI, Microsoft to jointly market on-line services > > WASHINGTON -- MCI Communications Corp., switching its Internet Strategy, >said it will team up with Microsoft Corp. to jointly market and develop >services for the burgeoning on-line industry" > >The story later goes on to say: > >"MCI will promote Microsoft Network, the No. 4 U.S. on-line service, and >sell Microsoft's Internet software through its SHL Systemhouse unit" > >Interesting, No? How does this affect UUnet (who provides Internet infrastructure for MSN) and MCI? > >-alex > ---------------------------------------------------------------------- Hank Nussbacher Manager, Internet Technology Programs Telephone: +972 3 6978852 Vnet: HANK at TELVM1 Fax: +972 3 6978115 Internet: hank(a)ibm.net.il ---------------------------------------------------------------------- IBM Israel 2, Weizmann St. Tel Aviv 61336 ====== ======= === === http://www.ibm.net.il/ ====== ======== ==== ==== Dialup registration: 177-022-3993 == == == ==== ==== Company services: 03-6978663 == ====== == === == Internet sales fax: 03-6978115 == == === == = == Enquiries: info(a)ibm.net.il ====== ======== === === Technical support: noc(a)ibm.net.il ====== ======= === === ----------------------------------------------------------------------

1 0

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 31 Jan '96

31 Jan '96

At 5:48 1/30/96, Alex.Bligh wrote: >Thankyou for the first constructive workable suggestion had so far. However, >this has two problems. You're welcome. > >a) RIPE fidn't give me the first /19 in a shorted prefix block > ( its x.x.160.x and .192.x is used), but no matter, I'll renumber > if necessary :-( or persuade them to give me a /18 as well so I > can do the above (hopefully). My convert the /19 to an /18 was a way to get minimal extra announcements. Getting a new /19 and keeping the first 3 /21s for your own use and giving them the 4th, still adds only one EXTRA announcement (over the need to announce the [new] /19 itself). >b) The /21 advert may be inbound filtered by a.n.other, which will be > fine if it has an AS-Path through me (as the less specific route > will work the same way) but won't when that path goes through the > other provider with whom they are multi-homed, as the /21 will disappear > entirely (3rd parties, i.e. a.n.other's customers will see neither), > the /19 will be the only thing that is visible, and I'll just black > hole their packets. As a Multi-Home (as opposed to a Private) /21 it should (theoretically) be entitled to being added to the filter lists as valid - Getting this done is a political problem. You should not be black holing the packets since your receipt of them is VALID (since they are Multi-Homed as opposed to having walked with the block).

1 0

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 31 Jan '96

31 Jan '96

At 11:39 1/30/96, Iljitsch van Beijnum wrote: >> At 6:09 1/29/96, Alex.Bligh wrote: > >> > Currently I have 2 choices as >> >far as I can make out, give them a bit of my /19, break up my >> >nice aggregate and ensure loads of extra announcements (and that >> >probably none of them get routed by anyone applying prefix based >> >filtering), or give them a new /19 all of their own (you've > >Suppose you have a customer that needs a /22 and they want to go >multi-homed. Suppose you give them that /22 out of your /19 or /16 you >got from the RIPE NCC. So they announce their /22 to you and to their >other provider. But you keep announcing your /19 or /16. So if anybody >were to filter the /22 announcement, your customer only suffers partial >loss of connectivity, since you are still announcing an aggregate of >their announcemnt (your original /19 or /16). > >Problem fixed. Anything else? ;-) Unless you announce both the /16 (or 19) AND the /22, they are not multi-homed but only single routed (with some fallback for those who see the /22 announcement). Anyone who gets the unfiltered /22 announcement will used the other provider (so long as that provider is up) while you get used only by those who get a filter routing (and as fallback when the other provider goes down).

1 0

Re: misinformation and rumors from MCI
by matthew＠scruz.net 31 Jan '96

31 Jan '96

Original message <199601310545.XAA14185(a)westie.gi.net> From: Alan Hannan <alan(a)gi.net> Date: Jan 30, 23:45 Subject: Re: misinformation and rumors from MCI > > > Matthem, > > I read your letter with a bit of a frown. ... > Please, in the future, send this mail to the person's manager, not > to the NANOG mail list. People make mistakes, obviously he made > one, and I don't see any reason to drag them/him through the > coals. We've seen this same sort of misinformation propogated by people at the major NSPs for some time now,... the people who know what interconnects really are and what routing policy really is read this list, and their understanding of the technology is presumably well-respected in their organization. If the major NSPs really want small providers to stay around to handle the end-user sales, they're going to have to adopt that attitude comapny-wide, and perhaps the technical people could write up an FAQ or two for their sales staff so that misinformation like this doesn't repeatedly end up in my mailbox, coming from customers who think that WE'RE the ones who lied. This was just yet another "I heard this about you from MCI and they must know what they're talking about" and I thought it might be informative for the readers of this list to see what's being said out there. There's a difference between a mistake and a corporate attitude of "drag all the small guys through the mud by claiming that their connectivity sucks by waving around technical terms". And sure, if nobody else thought this was interesting, I'll be sure to not mention this sort of thing on this list again... no need to waste everyone's valuable mail reading time :) -matthew kaufman matthew(a)scruz.net

1 0

Subscribe
by R. S. Ashton 31 Jan '96

31 Jan '96

subscribe tac(a)acnet.net

2 1

Re: Policy Statement on Address Space Allocations
by Vadim Antonov 31 Jan '96

31 Jan '96

The zero-settlement scheme works ok as long as interconnected parties are of about the same size. That makes them suffer equally from routing bloat. Incidentally, that was part of the reasoning after Sprint's IXP peering policy. In any case having zillions of small ISPs to be at top-level IXPs is economical and technical insanity, and it seems that it can only be fixed by rather steep settlements at IXPs to make it a very expensive prestige shopping. BTW, "settlements for routes" is a rather interesting thing. Imagine, say, Sprint peering with Joe Blow Internet-And-Burgers. Let's assume that route costs $100/yr, so Sprint pays $1M/yr to JBIB and JBIB pays back $300/yr. Sounds like a good business for JBIB :) The better idea is auctioning and trading the routing slots, though it is unclear where the proceeds from the initial auction should go. Probably to fund the Network Police which would chase the bootleg route injectors. I don't know what you make of it, but i think that sucks a lot more than the zero-sum model we have now. --vadim Not speaking for Sprint. PS Given the choice between fixing the technology and fixing the society it is always more prudent to go after technology. >From list-admin(a)merit.edu Tue Jan 30 20:56:10 1996 Received: from merit.edu (merit.edu [35.1.1.42]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id UAA11534 for <avg(a)titan.sprintlink.net>; Tue, 30 Jan 1996 20:56:08 -0500 Received: from nico.aarnet.edu.au (nico.aarnet.edu.au [139.130.204.16]) by merit.edu (8.7.3/merit-2.0) with SMTP id TAA25560 for <nanog(a)merit.edu>; Tue, 30 Jan 1996 19:59:35 -0500 (EST) Received: (from gih@localhost) by nico.aarnet.edu.au (8.6.10/8.6.10) id LAA25214; Wed, 31 Jan 1996 11:56:53 +1100 From: Geoff Huston <G.Huston(a)aarnet.edu.au> Message-Id: <199601310056.LAA25214(a)nico.aarnet.edu.au> Subject: Re: Policy Statement on Address Space Allocations To: huddle(a)mci.net (Scott Huddle) Date: Wed, 31 Jan 1996 11:56:53 +1100 (EST) Cc: asp(a)uunet.uu.net, G.Huston(a)aarnet.edu.au, cidrd(a)iepg.org, nanog(a)merit.edu In-Reply-To: <199601310009.TAA06568(a)new6.Reston.mci.net> from "Scott Huddle" at Jan 30, 96 07:09:12 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R Yes this inevitably leads to another instantiation of the Grande Olde Religious War on Settlements. However now the folk who are religiously tainted towards supporting the continued viability (or even absolute necessity in some versions of the War) of zero dollar interconnection now have the added hurdle of demonstrating how they can also solve the routing table scaling issues as a basic precursor of demonstrating that Zero Dollar settlements (aka free transit) is a Good Thing. Good luck and may the force be with them. And the forum in which this will happen? Personally I'm of the view this is not an area which naturally lends itself to the open processes of NANOG and the IETF. The most likely scenario is that the forum will either be smoke-filled back rooms or elevated views on the 150th floor, or both. And no, this is not a completely comforting answer for many. thanks, Geoff > > In the same way that giving away IP addresses and giving away IP > > routing can only be described as a very bad case of irrational > > behaviour, especially when the underlying resource is under stress as > > it is at present, then I'd also note that giving away transit is > > similarly a case completely irrational behaviour! > > Agreed, but doesn't this lead to the religious War On Settlements. Yakov's > push/pull paper on route announcements coupled with traffic levies > would seem to to address your point. Do you agree? > > > All this points to a desperate need for a more realistic economic > > structure to be used within a number of key aspects of Internet > > infrastructure. > > Agreed, what are the forums, though? There are both techie questions to > be answered as well as hard business case scenarios. NANOG seem > unlikely to address the former, where the IETF seems ill equipped to > answer the latter. > > -scott > > [...] > > Andrew's comments: > > > > > > > > > Half correct. Everyone in the area carries full routes for the block. > > > > Everyone outside the area can listen to only the /8 advertisement. > > > > > > So these providers are providing the free transit to their > > > non-customers? > > > > > > This does not make any business sense; it will not happen. > > > --asp(a)uunet.uu.net (Andrew Partan) > > > > > > > > > > > >

1 0

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 31 Jan '96

31 Jan '96

At 6:09 1/29/96, Alex.Bligh wrote: > Currently I have 2 choices as >far as I can make out, give them a bit of my /19, break up my >nice aggregate and ensure loads of extra announcements (and that >probably none of them get routed by anyone applying prefix based >filtering), or give them a new /19 all of their own (you've >said it, that's the minimum size allocation) which actually >solves their problem and mine, but this isn't an option >currently available because currently it's one window per local-IR. >So they have to go and become a local IR. If the high /21 of your /19 is not Allocated, you just assign it to them and add ONE announcement of the /21 to supersede with the current /19. If it is not free but is sparsely populated you can move the stuff out to free it up or go to RIPE to get your /19 turned into an /18 (ie: get the /19 right after your current /19 [RIPE did give you the first /19 in a shorter prefix block didn't they?]) in exchange for returning the /21 worth of space [giving you 3 extra /21s worth of space], and divide that 2nd /19 into a /20, and 2 /21s giving them the 2nd /21 (still doing the same 2 announcements as you would if allocated out of your current /19).

5 4

Re: Policy Statement on Address Space Allocations
by Scott Huddle 31 Jan '96

31 Jan '96

Geoff Huston <G.Huston(a)aarnet.edu.au> writes > If you manage to provide a better model for interconnection which > includes a rational economic model of interaction then, strangely > enough, you then have a powerful tool you can use to address teh > technical issue of scaling the routing domain. > > i.e. > > "free transit" is stupid, as Andrew indicates. > > "transit" is possible given a rational economic model of the > transit interaction. > > In the same way that giving away IP addresses and giving away IP > routing can only be described as a very bad case of irrational > behaviour, especially when the underlying resource is under stress as > it is at present, then I'd also note that giving away transit is > similarly a case completely irrational behaviour! Agreed, but doesn't this lead to the religious War On Settlements. Yakov's push/pull paper on route announcements coupled with traffic levies would seem to to address your point. Do you agree? > All this points to a desperate need for a more realistic economic > structure to be used within a number of key aspects of Internet > infrastructure. Agreed, what are the forums, though? There are both techie questions to be answered as well as hard business case scenarios. NANOG seem unlikely to address the former, where the IETF seems ill equipped to answer the latter. -scott [...] > Andrew's comments: > > > > > > Half correct. Everyone in the area carries full routes for the block. > > > Everyone outside the area can listen to only the /8 advertisement. > > > > So these providers are providing the free transit to their > > non-customers? > > > > This does not make any business sense; it will not happen. > > --asp(a)uunet.uu.net (Andrew Partan) > > > > > >

2 1