RE: Getting a "portable" /19 or /20
Actually, the last I heard is that they will sell down to a /24. They just warn you that it may not be very usable. The interesting thing is that, last I looked, they had the same price-tag as a /20 or /19. The price isn't the issue, though ... routing *is*. Qualifying for a /20, when you only really need a /24, is a PITA (not to mention, leaving you feeling a bit sleazy).
-----Original Message----- From: Aaron Dewell [mailto:acd@woods.net] Sent: Monday, April 09, 2001 2:50 PM To: Jade E. Deane Cc: 'Roeland Meyer'; 'James Thomason'; 'mike harrison'; nanog@merit.edu Subject: RE: Getting a "portable" /19 or /20
But also if you want just slightly over a /21, but not enough to make a /20, then they still don't want to talk to you. That's the project I'm currently working on.
Last word I got is "if you only need a /21, please contact your provider". Unfortunately, most providers don't have a /21 just lying around doing nothing, and the current folks say "call ARIN, they can give you addresses."
On Mon, 9 Apr 2001, Jade E. Deane wrote:
Two points for hitting the nail on the head.
Jade
-----Original Message----- From: Roeland Meyer [mailto:rmeyer@mhsc.com] Sent: Monday, April 09, 2001 1:13 PM To: 'James Thomason'; Jade E. Deane Cc: 'mike harrison'; nanog@merit.edu Subject: RE: Getting a "portable" /19 or /20
The problem comes from when you only need a /24 and it has to be portable and multi-homed.
-----Original Message----- From: James Thomason [mailto:james@divide.org] Sent: Monday, April 09, 2001 1:55 PM To: Jade E. Deane Cc: 'mike harrison'; nanog@merit.edu Subject: RE: Getting a "portable" /19 or /20
Gee, I followed the guidelines and procedures outlined by ARIN - and what do you know!?
We got address space! Try it! You might like it!
On Mon, 9 Apr 2001, Jade E. Deane wrote:
Sure... knee pads and a copy of the communist manifesto, to
put you in the
proper ARIN mindset.
Jade
-----Original Message----- From: mike harrison [mailto:meuon@highertech.net] Sent: Monday, April 09, 2001 12:40 PM To: nanog@merit.edu Subject: Getting a "portable" /19 or /20
With the demise of Winstar/good.net locally, and us having to renumber anyway, I am getting started on the idea of getting a 'portable' /19 from Arin. We are currently using a non-portable /20 and a couple of /24's.
Any words of advice as we start this process? I'd like to do this right the first time and could use an experienced viewpoint.
Mike Harrison -- ASN 3901
I looked, they had the same price-tag as a /20 or /19. The price isn't the issue, though ... routing *is*. Qualifying for a /20, when you only really need a /24, is a PITA (not to mention, leaving you feeling a bit sleazy).
I understand the issue of "it costs just as much administration overhead as a /24 as a /20", and there is probably some more overhead for more addresses. It also raises the bar.. do they REALLY need it? It's #1 on tomorrows (and the next several weeks) agenda - Thanks --Mike--
Actually, the last I heard is that they will sell down to a /24.
No. See http://www.arin.net/regserv/feeschedule.html "The minimum block of IP address space assigned by ARIN is a /20." Also, they don't have any special-case handling that I am aware of. I tried to get a private /24 to use for the topology examples in my books and couldn't get one. ARIN outright refused the request even though I could prove the need for it, and even though I didn't care about global routing or reachability. I was also told that any /24 that I might manage to acquire would be revoked instead of transferred to me. I honestly believe that ARIN is funded by stock ownership in NAT provder technologies. They are the primary reason that we have NAT and RFC 1918 problems on the net everyday. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Mon, 9 Apr 2001, Eric A. Hall wrote:
Actually, the last I heard is that they will sell down to a /24.
No. See http://www.arin.net/regserv/feeschedule.html
"The minimum block of IP address space assigned by ARIN is a /20."
Also, they don't have any special-case handling that I am aware of. I tried to get a private /24 to use for the topology examples in my books and couldn't get one. ARIN outright refused the request even though I could prove the need for it, and even though I didn't care about global routing or reachability.
I was also told that any /24 that I might manage to acquire would be revoked instead of transferred to me.
I honestly believe that ARIN is funded by stock ownership in NAT provder technologies. They are the primary reason that we have NAT and RFC 1918 problems on the net everyday.
Well, to me it sounds like you wanted your own /24, came up with an excuse, and they saw right through it. I mean, if you need IP space for your book, 192.168/16 and 10/8 are popular choices. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
Also, they don't have any special-case handling that I am aware of. I tried to get a private /24 to use for the topology examples in my books and couldn't get one. ARIN outright refused the request even though I could prove the need for it, and even though I didn't care about global routing or reachability.
Well, to me it sounds like you wanted your own /24, came up with an excuse, and they saw right through it. I mean, if you need IP space for your book, 192.168/16 and 10/8 are popular choices.
Well - a bit off to the side of this topic, but when has that stopped anyone on this list... I seem to recall that 192.0.2.0/24 was reserved for just this type of use. I can't find an RFC that explicitly says "192.0.2.0/24 is reserved for documentation and example code" though the block has been reserved by ARIN and Bill Manning's got an Internet Draft saying as much (http://www.isi.edu/~bmanning/dsua.html). Anyone have a reference to the official word on this? Eric :)
I seem to recall that 192.0.2.0/24 was reserved for just this type of use.
Useless for fully-connected example purposes since you won't get any packets back. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
I seem to recall that 192.0.2.0/24 was reserved for just this type of use.
Useless for fully-connected example purposes since you won't get any packets back.
-- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
192.0.2.0/24 was earmarked by Jon Postel for use in documentation. Not all (in fact few) protocols are routing oriented so you don't have to show "fully-connected" state. Of course, with VLSM in play, its pretty easy to carve up a /24 into lots of subnets. It was never to show up in a routing table as a prefix that would be forwarded. This was back in the day when oen didn't need and RFC to wipe ones nose. The DSUA draft is prolly the closest document that will exist on this particular prefix. --bill
192.0.2.0/24 was earmarked by Jon Postel for use in documentation.
It was never to show up in a routing table as a prefix that would be forwarded.
It's useful for pictures showing "Host A sends packets to Host B" when they're both on the same network. It's not useful for illustrating how things really happen out on the Internet, particularly when errors which must be returned to the sender are involved. It's like the example.com domain, which is also set aside for document purposes. example.com is useful for illustrating high-level concepts in white papers ("your SMTP client connects to the server..."), but it is not useful for describing in detail the dozen DNS transactions that happen when sendmail delivers a message to a remote site. That requires a real domain with MX backups and real addresses and everything. The example blocks/domains are useful for what they are, but their scope of usefulness is much smaller than real blocks/domains when it comes to documenting the detailed interactions between hosts and networks on the public Internet. This thread is way OT. Private queries preferred. Thanks. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Actually, the last I heard is that they will sell down to a /24.
"The minimum block of IP address space assigned by ARIN is a /20."
Also, they don't have any special-case handling that I am aware of.
That was the point. It's against their policy and they don't have any mechs in place for reasonable requests within their policy framework. My specific needs are irrelevant to the point and were only provided for illustration purposes. If you can sweet talk a /24 out of them, more power to you.
Well, to me it sounds like you wanted your own /24, came up with an excuse, and they saw right through it.
I have more addrs than I need. Your second guessing proves nothing.
I mean, if you need IP space for your book, 192.168/16 and 10/8 are popular choices.
There are a bunch of protocols and services that need fully-connected addresses. But that's all beside the point. You can't get /24 from ARIN, and that's the point. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
In the referenced message, Eric A. Hall said:
Also, they don't have any special-case handling that I am aware of. I tried to get a private /24 to use for the topology examples in my books and couldn't get one. ARIN outright refused the request even though I could prove the need for it, and even though I didn't care about global routing or reachability.
Internet Assigned Numbers Authority (NET-TEST) IANA 192.0.2.0 - 192.0.2.255 The above, iirc, is the appropriate netblock to use in documentation examples. So, they have already assigned you and every other author in the world a /24 to use.
On Mon, Apr 09, 2001 at 10:54:24PM -0400, Stephen Griffin wrote:
The above, iirc, is the appropriate netblock to use in documentation examples. So, they have already assigned you and every other author in the world a /24 to use.
To be pedantic, IANA has, ARIN didn't. --msa
On Mon, 9 Apr 2001, Eric A. Hall wrote:
Actually, the last I heard is that they will sell down to a /24.
No. See http://www.arin.net/regserv/feeschedule.html
"The minimum block of IP address space assigned by ARIN is a /20."
Also, they don't have any special-case handling that I am aware of. I tried to get a private /24 to use for the topology examples in my books and couldn't get one. ARIN outright refused the request even though I could prove the need for it, and even though I didn't care about global routing or reachability.
I was also told that any /24 that I might manage to acquire would be revoked instead of transferred to me.
I honestly believe that ARIN is funded by stock ownership in NAT provder technologies. They are the primary reason that we have NAT and RFC 1918 problems on the net everyday.
No, thats really not fair. I'm probably more of a NAT hater then most people here, but I can't agree with that. The reason they don't allocate /24's is because without aggregation the Internet is not scalable. Perhaps they are being too agressive, but the reasoning is sound.
On Tue, Apr 10, 2001, Greg Maxwell wrote:
The reason they don't allocate /24's is because without aggregation the Internet is not scalable. Perhaps they are being too agressive, but the reasoning is sound.
s/not/less/
Adrian -- Adrian Chadd "Two hundred and thirty-three thousand <adrian@creative.net.au> times the speed of light. Dear holy fucking shit."
On Tue, 10 Apr 2001, Adrian Chadd wrote:
On Tue, Apr 10, 2001, Greg Maxwell wrote:
The reason they don't allocate /24's is because without aggregation the Internet is not scalable. Perhaps they are being too agressive, but the reasoning is sound.
s/not/less/
No. s/less/not/. Aggregation is a core requirement. Without *any* aggregation we would have a global route for every single host, this would obviously not work. Aggregation is a requirement, beyond that all that differs is where you draw the line. /24 minimum aggregation was acceptable 20 years ago. It is not acceptable today, as made obvious by the routing policies of many networks. There really isn't a solution to this struggle between the desire to multihome and the need to aggregate on today's IPv4 Internet. Which is why I've been participating on the multi6 working group to ensure that IPv6 offers a better solution (and perhaps, finally, a compelling reason for the people here to drive the transition to IPv6).
On Tue, Apr 10, 2001 at 08:27:54AM -0400, Greg Maxwell wrote:
The reason they don't allocate /24's is because without aggregation the Internet is not scalable. Perhaps they are being too agressive, but the reasoning is sound.
Aggregation buys time, that's it. Aggregation does not make the current routing methods any more scalable. --msa
On Tue, 10 Apr 2001, Majdi S. Abbas wrote:
On Tue, Apr 10, 2001 at 08:27:54AM -0400, Greg Maxwell wrote:
The reason they don't allocate /24's is because without aggregation the Internet is not scalable. Perhaps they are being too agressive, but the reasoning is sound.
Aggregation buys time, that's it. Aggregation does not make the current routing methods any more scalable.
I'd be inclined to think that anything which allows a system to stretch further without fundamental change implies increased scalability. That's not to say that it makes it infinitely scaleable, but is anything? Incidentally, how do people feel about the use of default routes to work around the problem of routing table size on tier-2 (!) networks and below? If all "small" edge networks pointed their default at one or more of their upstreams, and filtered their outbound traffic to remove things they wouldn't want to be able to get out anyway, it would be down to the larger NSPs to deal with the issue of routing table size for prefixes beyond a certain length. Doesn't really fix anything, as it reduces control over which path your outbound traffic takes, but I suppose at least it makes sure it'll go -somewhere-? On the flipside, who is actually less concerned about routing table size? The multihomed networks on the edges who can use a default if they want to, and are likely to be carrying less traffic and so have more resources to deal with routing, or the core networks who have capacity problems of their own? Curious (and thinking aloud), Patrick -- Patrick Evans - Net bloke, indie kid and lemonade drinker pre at pre dot org tompaulin dot pre dot org
On Tue, 10 Apr 2001, Patrick Evans wrote:
Incidentally, how do people feel about the use of default routes to work around the problem of routing table size on tier-2 (!) networks and below? If all "small" edge networks pointed their default at one or more of their upstreams, and filtered their outbound traffic to remove things they wouldn't want to be able to get out anyway, it would be down to the larger NSPs to deal with the issue of routing table size for prefixes beyond a certain length. Doesn't really fix anything, as it reduces control over which path your outbound traffic takes, but I suppose at least it makes sure it'll go -somewhere-?
Pointing default is a stop-gap measure at best for the multi-homed entity on the edge. It does not reduce the size of the global table at all. It simply allows the edge entity to get by with using a less powerful router because they don't have to hold full views in their RIB.
On the flipside, who is actually less concerned about routing table size? The multihomed networks on the edges who can use a default if they want to, and are likely to be carrying less traffic and so have more resources to deal with routing, or the core networks who have capacity problems of their own?
Everyone _should_ be concerned about table size unless they just have money to throw at their routers for grins and giggles. --- John Fraizer EnterZone, Inc
On Tue, 10 Apr 2001, Majdi S. Abbas wrote:
On Tue, Apr 10, 2001 at 08:27:54AM -0400, Greg Maxwell wrote:
The reason they don't allocate /24's is because without aggregation the Internet is not scalable. Perhaps they are being too agressive, but the reasoning is sound.
Aggregation buys time, that's it. Aggregation does not make the current routing methods any more scalable.
In IPv4 yes, because you can't have perfect aggregation, too much network multihoming and old prefixes and it's to painful to change address blocks. In IPv6, if implimented right aggregation provides for virtually limitless scalability for unicast traffic.
On Tue, Apr 10, 2001 at 03:45:10PM -0400, Greg Maxwell wrote:
On Tue, 10 Apr 2001, Majdi S. Abbas wrote:
On Tue, Apr 10, 2001 at 08:27:54AM -0400, Greg Maxwell wrote:
The reason they don't allocate /24's is because without aggregation the Internet is not scalable. Perhaps they are being too agressive, but the reasoning is sound.
Aggregation buys time, that's it. Aggregation does not make the current routing methods any more scalable.
In IPv4 yes, because you can't have perfect aggregation, too much network multihoming and old prefixes and it's to painful to change address blocks.
In IPv6, if implimented right aggregation provides for virtually limitless scalability for unicast traffic.
So long as "implemented right" means "edge sites are no longer permitted to multi-home at the IP layer". If those are the constraints of your routing policy, IPv4 will scale too. Very nicely. Joe
On Tue, 10 Apr 2001, Joe Abley wrote:
On Tue, Apr 10, 2001 at 03:45:10PM -0400, Greg Maxwell wrote:
On Tue, 10 Apr 2001, Majdi S. Abbas wrote:
On Tue, Apr 10, 2001 at 08:27:54AM -0400, Greg Maxwell wrote:
The reason they don't allocate /24's is because without aggregation the Internet is not scalable. Perhaps they are being too agressive, but the reasoning is sound.
Aggregation buys time, that's it. Aggregation does not make the current routing methods any more scalable.
In IPv4 yes, because you can't have perfect aggregation, too much network multihoming and old prefixes and it's to painful to change address blocks.
In IPv6, if implimented right aggregation provides for virtually limitless scalability for unicast traffic.
So long as "implemented right" means "edge sites are no longer permitted to multi-home at the IP layer". If those are the constraints of your routing policy, IPv4 will scale too. Very nicely.
Well, thats close to what I ment. My proposal is that any networking level multihoming for IPv6 not be globally advertised (I.e. two tier-2's could fast path their networks to each other, and they both fully carry the routing burden of that choice without impact to other networks). It should be clairfied in the end-to-end multihoming draft soon.
Hi, At 03:45 PM 4/10/2001 -0400, Greg Maxwell wrote:
Aggregation buys time, that's it. Aggregation does not make the current routing methods any more scalable.
No. Aggregation hides information. Information hiding promotes scalability. Current routing methods can theoretically be as scalable as anyone could ever want if you place well known constraints, namely single homing and pure provider based addressing, on entrants into the routing system. Of course, as neither of those constraints are particularly appealing to anyone but top-tier service providers and the incremental cost of violating those constraints are so small that you quickly get into a "tragedy of the commons" scenario.
In IPv4 yes, because you can't have perfect aggregation, too much network multihoming and old prefixes and it's to painful to change address blocks.
In IPv6, if implimented right aggregation provides for virtually limitless scalability for unicast traffic.
IPv6 is not magic. IPv4 and IPv6 use the same routing paradigm, so if you can have virtually limitless scalability with v6, you can have virtually limitless scalability with v4. Problem is: a) multi-homing is demanded by the market and for multi-homing to make sense, you must stop hiding information. I don't see the market demand changing with the deployment of IPv6. b) CIDR requires renumbering. If people want to change providers, they must renumber into their new provider's block, even with IPv6. IPv6 is supposed to make renumbering easier, however I personally don't believe the current addressing model used for IPv6 makes it that much easier than IPv4, so there will still be resistance to renumbering in IPv6. Rgds, -drc
participants (14)
-
Adrian Chadd -
Andy Dills -
bmanning＠vacation.karoshi.com -
David R. Conrad -
Eric A. Hall -
Eric Gauthier -
Greg Maxwell -
Joe Abley -
John Fraizer -
Majdi S. Abbas -
mike harrison -
Patrick Evans -
Roeland Meyer -
Stephen Griffin