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).
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.
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 
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.
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.
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.
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
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).
Aggregation buys time, that's it. Aggregation does not make the
current routing methods any more scalable.
--msa
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
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.
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.
Please let me know when your Linux box is capable of doing
line rate forwarding on an OC-192.
Thanks!
--msa
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
Well, I did say up to a 7200, and a 7200 won't exactly forward an OC-192
line rate. No interface cards either.
Precisely my point...no interface cards. Yes, you can route
ethernet, and maybe even a T1 or two...you can't do serious T1 or DS3
aggregation or anything larger than an OC-3 or so with that PC.
It's fine for people in colo or with a couple of LANs to route
about but it isn't a practical solution for those of us with real
networks to run. So, will you and everyone else who brings this up,
please stop. If it were as practical as you claim, a lot more people
would be doing it.
Of course, a GSR won't forward it at line rate either, AFAIK. It pretends
to nicely, though...
I think you'll need to be more specific than GSR when making
this statement.
--msa
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,
> 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
> Memory and CPUs are not really that expensive, it just depends on how
> much certain router manufacturers think they can milk out of you for
> overpriced hardware. Considering that you can build a router with a
> PC and Linux for better performance, better stability, and better
> scalability than a 7200 for about a tenth the price, I fail to see why
> any of those boxes continue to be sold... It just requires actual
> quality PC hardware.Please let me know when your Linux box is capable of doing
line rate forwarding on an OC-192.
Please let me know when a 7200 will do line rate forwarding on an
OC-192. Sorry... I had to....I do not think that Linux is exactly cut
out for the job, but he DID say a 7200.