Stephen Griffin wrote:
==>Returning a /16 which the organization is not entirely using for a smaller
==>block seems to be anything other than depletion. Perhaps I've misread
==>Dani's original message, but it appeared that the /16 is not being
The original poster didn't entirely make it clear whether the other
remaining /18's would be used by other sections of the parent company,
but that's not the point. If the space had been allocated from
206+ or 62/63/64, his announcements would have been accepted.
Just because their parent company has been around for a while means that
some ISP's penalize them. One could guess from his e-mail address that
the parent company is one of the larger global enterprises in the world.
When I refer to the depletion of immediately available address space,
I refer to a company returning /16's, leaving an unallocated hole in the
middle of 181/8 or 174/8 or 171/8 or whatever. The unallocated hole
isn't as easily handed out by ARIN, because it's not a matter of serially
handing out address space from a very large block; the process to hand
out these "holes" would have to be considerably more costly to the
In fact, if you were a global enterprise today, and you asked ARIN for
address space (because you were multi-homed), and they offered you the
choice: 64/8 or 174/8 space, which would you take?
Be careful with that answer if you haven't worked in or run a network
for a global enterprise that has multiple Internet access locations.
Global enterprises pay ISP's to deliver Internet traffic LOCALLY; they
don't run Internet backbones, and they have no intention to. Therefore,
they want to assign different addressing to different areas in order to
have the ISP's bring traffic to the region with that addressing. This
differs from the ISP model where traffic arrives at the closest possible
entrypoint into the network, then follows a backbone to its destination.
(We're talking about standard hot-potato, so try not to be too critical
on semantics with content providers, cold potato, and that ball of wax.)
==>> Why not adopt a reasonable policy to accept up to /20's or up to /19's in
==>> the old B space so that organizations who already have these blocks can
==>> use them?
==>Most people who filter feel that filtering on registry boundaries is
==>reasonable. There are people who feel that their version of reasonable
==>is more reasonable. What makes /32 less reasonable than /20? If one
==>filters on registry boundaries, the only time you don't have access to
==>an entity is when they are not announcing the allocation they have been
I feel that filtering on registry boundaries is reasonable; but that
of course it depends on what you believe the registries' intentions are.
If a registry is currently handing out blocks with a minimum size of
/20, is it reasonable to filter all space other than the dump and swamp
to /20? No problems here. I don't want the UUnet deaggregation disaster
of the past to happen in 128/2. And chances are, if someone's announcing
256 /24's in their class B block, they're misconfigured. Fine. Protect
But is there a good reason that a block size of /19 shouldn't be accepted
in this space? Is it not reasonable for an older global enterprise to
want more Internet access locations for their enterprise, and therefore
divide their address space up a bit more?
Some ISP's believe that when the registries allocated address space in the
B space prior to CIDR times, that they intended for those companies only
to announce that space as /16's. Okay, I can accept that, given the
landscape at the time. However, the flaw that these ISP's are making in
policy is the belief that all the organizations who received this space in
the past won't use VLSM, and can't be responsible with addressing.
Note that most ISP's are accepting the /19's or /20's. There are only a
small handful who are not accepting them. Of them, there are a few more
who are willing to make exceptions if you ask nicely and provide a good
reason. Others are not, and eventually the topic will come to a head as
it did with content vs access wars.