January 1996 - Test - lists.nanog.org

Re: Policy Statement on Address Space Allocations
by Sean Doran 26 Jan '96

26 Jan '96

| > We just have some differences of philosophy -- you think | > that RIPE really can persuade people into having only | > 1024 announements (preferably far fewer) in 195/8, and | > I don't. That's all. | | OK. I call this a challenge but you won't let me try ;-). You and Randy Bush seem to be reading each other's minds. He has proposed this in a way that is very interesting, and which I will think about. There is a bad failure mode to consider that even a badge afterwards won't make any more attractive. Mostly it's "what on earth do we do if we cross the threshold of 1024 prefixes in 195/8?" to which I see no easy answer that doesn't involve inflict enormous pain on people with old, established long prefixes in 195/8. If you could help more there, then yes, you can think of it as a big challenge. The rest of your message is a good start, and has me thinking, as I've just told Randy in private email. The only other detail is that the consequences of making an exception in one piece of unallocated-from address-space because of the involvement of a single particular organization may have some side-effects beyond engineering that will have to be pondered by some other of my colleagues. This is also something you could help think about, as we will need an answer for "well, you gave *RIPE* a break, why not us?". Sean.

1 0

Re: Policy Statement on Address Space Allocations
by Yakov Rekhter 26 Jan '96

26 Jan '96

Daniel, > If you insist on prefix-length filtering I have proposed a soloution > for future address space allocated via the RIPE NCC several times: > > - set your inbound prefix length filter to /19. > > - The RIPE NCC will *guarantee* that we will not make more than > 1024 non-aggregateable allocations from each /8. Would the RIPE NCC provide such non-aggregatable allocations irrespective of how many hosts would be covered by such an allocation ? Yakov.

2 2

MAI Announces Detroit MXP
by Justin W. Newton 26 Jan '96

26 Jan '96

MAI, Network Services announced today that the Detroit MXP (Metropolitan Exchange Point) is ready for operation. Parties interested in connecting to the MXP should contact Justin Newton (justin(a)mai.net) or Vincent Bono (vbono(a)mai.net) at (703) 506-0505. More information can be found on the Detroit MXP web page at: http://www.mai.net/mxp/detroit/mxp.htm. Justin Newton | jnewton(a)hq.mainet.com Internet Administrator # (703) 506-0505 MAI Network Services | Detroit MXP online soon #

1 0

Re: Policy Statement on Address Space Allocations
by Sean Doran 26 Jan '96

26 Jan '96

Dennis said: >>[192 et al] look like swamps that are ripe for the picking. Bill said: >Already underway as part of PIER Yay. I'm looking forward to the updates. I'm even more looking forward to technology that makes renumbering tractable, because that will end this entire line of discussion pretty much forever. Sean.

1 0

Re: Policy Statement on Address Space Allocations
by Ronald Khoo 26 Jan '96

26 Jan '96

You're trying to achieve a perfect policy that will work for all time when what we need is something to eke out IPv4 for the rest of its natural life. By the time enough of your postulated ISPs have grown big enough AND THEN shrunk enough for this to matter in any practical sense, IPv4 will have become mostly static, and all of us here will have retired from active Internet Politics. I hope. On Jan 26, 12:59pm, Daniel Karrenberg wrote: } Subject: Policy Statement on Address Space Allocations } } > Ronald Khoo <ronald(a)office.demon.net> writes: } } > Here's a suggestion for one simple rule. "Where delegating address space } > to a provider registry, a) never delegate a block smaller than any } > existing PA block already delegated, and b) once 3 such blocks are } > delegated, always delegate a block at least 4 times bigger". } } While sounding fine in general, this assumes ever increasing growth } of ISPs. An assumption easily proven invalid by counterexample. } } Daniel }-- End of excerpt from Daniel Karrenberg -- Ronald Khoo <ronald(a)demon.net> +44-181-371-1000 FAX +44-181-371-3750

2 1

Re: Policy Statement on Address Space Allocations
by hwb＠upeksa.sdsc.edu 26 Jan '96

26 Jan '96

>IANA is the *Naming and Addressing* Authority. But to the >best of my knowledge the IANA's authority is not sufficient to >guarantee Internet-wide connectivity. There is no authority any more. May have been in the ARPAnet, *may* be in the NSFNET days. The IANA/InterNIC thing is essentially a coordination function that assumes that everyone plays and in result gives a good probability of global uniqueness in varieties of assignments. If the policies are not being accepted, the non-accepters will weight global interconnectivity against needing to provide services in a perhaps isolated environment. Many will choose global connectivity, some others may not. Example. A few weeks back or so I needed an AS number, but the InterNIC came back, after I filled out their form, with what I considered unreasonable additional requests, and I thought screw it, I don't need this, I just pick a number. The setup was semi-experimenal anyway (some routing research, but connected), and if someone complains I can fix it later, or send them after the InterNIC. So, the coordination function has failed there, and there was certainly no authority involved. I liked Dennis' note about picking reasonable targets, btw, and going for those somehow, may be doing "limits by declaration," so we find out what's reasonable, rather than dwelling in doom or no-doom about address spaces and so. That something that could be done at the NANOG meeting, with some email in advance and after?

1 0

Re: Policy Statement on Address Space Allocations
by Jeff Young 26 Jan '96

26 Jan '96

>It's the other way round: SPRINT should tell his customers he can't >guarantee 100% global Internet connectivity because he disagrees with >the current address allocation policy of the IANA/InterNIC/RIPE NCC/AP-NIC. >They might want to look for a different transit provider... > >Regards, > >Miguel say what you will about this policy, but someone (sean?) thought long and hard about it's implications. i didn't like the abrupt manner in which it was implemented, but it does take guts and it is pretty elegant: it's everyone else's 206 customers who can't reach sprint's customers. even though it's the packets from sprint's customer's that can't make it back to everyone else. that's the beauty of it. sprint announces networks in the 206 space to us and to everyone else. we accept the announcements if they are larger than /24: *> 206.12.94.0 192.41.177.241 128 80 0 1239 3602 ? *> 206.12.187.0 192.41.177.241 128 80 0 1239 1794 ? *> 206.13.159.0 192.41.177.241 128 80 0 1239 1791 3064 i * 206.24.100.0/23 192.41.177.241 128 80 0 1239 1792 3563 i *> 206.40.99.0 192.41.177.241 128 80 0 1239 3663 i *> 206.40.100.0 192.41.177.241 128 80 0 1239 3663 i *> 206.40.101.0 192.41.177.241 128 80 0 1239 3663 i *> 206.40.102.0 192.41.177.241 128 80 0 1239 3663 i *> 206.40.103.0 192.41.177.241 128 80 0 1239 3663 i * 206.40.128.0/19 192.41.177.241 128 80 0 1239 4534 i so if i'm a customer of sprint in a 206+ network that is announced as a /24, i have a route to the world. the real message is if you have a 206+ address, make sure that your provider can put it into an aggregation block for you (or go to sprint). nobody said it would be boring. :-) Jeff Young young(a)mci.net

1 0

Re: Policy Statement on Address Space Allocations
by Scott Bradner 26 Jan '96

26 Jan '96

> I think the hierarchical routeing is one step *worse* than the above. > The address *defines* the route the packets take ? What about the real, > live multi-interconnect, multi-homed Internet we use ? Maybe I have > misunderstood the way IPv6 addressing works. HR sure does sound real bad, just for grins what is your plan to keep the routing table size within the constraints of the routers without it? Scott

1 0

Re: Policy Statement on Address Space Allocations
by Sean Doran 26 Jan '96

26 Jan '96

Jeff Young wrote: | say what you will about this policy, but someone (sean?) thought | long and hard about it's implications. i didn't like the abrupt | manner in which it was implemented, but it does take guts and it | is pretty elegant: Thanks, Jeff. Once again I shall repeat my apologies -- the original intent was to make sure the filters would break things on day one, rather than retroactively apply to the number of people whose route announcements had been leaked in by mistake. Despite the immediate retrospective thought that it was a cute way to avoid accusations of collusion among big providers, I did very much regret the work you folks and others had to do when this got dropped into place. OTOH, well, there had been several months' warning about the details... But still, sorry that it wasn't as smooth as it could have been if there hadn't been a flaw in the filtering that crept in in about April, long before anyone was even really thinking of allocating from 206.0.0.0/8. However, as I think everyone remembers, after a short while, in an effort to assist in getting aggregation of the then-announced bits of 206.0.0.0/8 working OK and giving people some time to get used to the filtering, I did relax the filtering on 206.0.0.0/8 to permit /19s. As you note, this was to the benefit of other peoples' customers. | the real message is if you have a 206+ address, make sure that your | provider can put it into an aggregation block for you (or go to sprint). Right, and we have been warning our customer base for some time that if they announce a 206+ address that is not aggregatable into something reasonably big (like a /18), they run the risk of losing connectivity to other providers if they ever were to impose similar filters for business or technical reasons. Meanwhile, yes, it's a slight competitive advantage. :-) (Frankly though, that was a at first side-effect of not having the ability to do the outbound filtering immediately, but it rapidly seemed like a smart thing to do to make other people think about similar filtering. An interesting thing to wonder about is how different the early days of CIDR deployment would have been if rather than aggregating at the source, people were to have set up some sort of inbound filtering at places like MAE-EAST.) | nobody said it would be boring. :-) Yup. Sean.

1 0

Re: Policy Statement on Address Space Allocations
by Peter Galbavy 26 Jan '96

26 Jan '96

> Despite the weather forecast, I'm sure you'll warm to RIPE, its > members and even its "bureaucracy", and perhaps revise your > opinion in the light of an enjoyable experience. > > Looking forward to meeting you in Amsterdam. Me too. See you all there... -- Peter Galbavy peter(a)demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/

1 0