Why does Sprint have address filters again?

For some unknown reason, although IHETS has been allocated the entire
traditional class B 165.138.0.0, they are announcing it as a partial
165.138.0.0/20. They could announce the entire /16. But they've chosen
not too. If IHETS wants to ensure they can reach as much as the Internet
as possible, they could follow Sprint's filtering policy, and announce
their network as a 165.138.0.0/16. IHET could check
http://www.sprint.net/filter.htm for a description of the policy.

Since IHETS seems to be a SPRINT customer, I sure would appreciate it
if the SPRINT NOC could explain to IHETS why such address filters exist,
and if Sprint thinks its a good idea to apply them to other ISPs, why
the reciprocal argument would also be true.

For some unknown reason, although IHETS has been allocated the entire
traditional class B 165.138.0.0, they are announcing it as a partial
165.138.0.0/20. They could announce the entire /16. But they've chosen
not too. If IHETS wants to ensure they can reach as much as the Internet
as possible, they could follow Sprint's filtering policy, and announce
their network as a 165.138.0.0/16. IHET could check
Sprint Portal for a description of the policy.

Since IHETS seems to be a SPRINT customer, I sure would appreciate it
if the SPRINT NOC could explain to IHETS why such address filters exist,
and if Sprint thinks its a good idea to apply them to other ISPs, why
the reciprocal argument would also be true.
--
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
  Affiliation given for identification not representation

It is also fascinating that Sprint's argument for their filtering (per their
web page) is that ARIN has espoused this as a "proper" thing to do. They
even provide a web reference to ARIN's statements in this matter.

I have to ask what in the dickens ARIN thinks it is doing advocating *policy*
on address filtering for ISPs, how this squares with ARIN's 501c(6) status,
and how this can be justified, particularly when it shows up referenced like
this as a "business justification".

This polciy CERTAINLY has nothing to do with route table size, and wouldn't
if it was enforced at the /19 level across the board.

So just what is Sprint's, and ARIN's, justification for those *policy*
statements?

And does anyone on NANOG have other references to ISPs who *also* have
picked up on this "suggestion" and have implemented something similar?

[This is a request as an ARIN AC member, who has tried to get a lot of
these kinds of questions answered from officers and trustees of ARIN]

It is also fascinating that Sprint's argument for their filtering (per their
web page) is that ARIN has espoused this as a "proper" thing to do. They
even provide a web reference to ARIN's statements in this matter.

As an ARIN AC member I'd like to see ARIN send them a note requesting that
they remove this historical revisionism from their website.

I have to ask what in the dickens ARIN thinks it is doing advocating *policy*
on address filtering for ISPs,

As far as I know, ARIN is doing no such thing. Seems to me we have here a
document that could have been worded better and probably would have been
worded better if anyone had cared to comment on it.

[This is a request as an ARIN AC member, who has tried to get a lot of
these kinds of questions answered from officers and trustees of ARIN]

Seems to me that you are an AC member that has demanded ARIN provide a lot
more public documentation of its policies and are, no doubt, a prime
motivator for the production of the document in question.

Personally, I think this could have been better handled by sending some
suggestions on wording directly to the author of the document rather than
raising a big public fuss about it. I would suggest that the section in
question be replaced with this:

     In the past, major transit providers have claimed that technical and
     implementation constraints on the Internet routing system cause them
     to enforce various policies in order to reduce the number of globally
     advertised routes and preven the possibility of routing overload.
     Typically we see these providers setting limits on the size of
     Classless Inter-Domain Routing (CIDR) prefixes added to the routing
     tables or filtering of non-aggregated routes.

     To aid in the efficient deployment of CIDR, ISPs are encouraged to
     request address space from their upstream provider. The upstream
     provider is to maintain control of the allocated block unless
     explicitly and contractually stated otherwise.

     In an effort to ensure that CIDR is implemented and utilized as
     efficiently as possible, ARIN issues blocks of addresses
     on appropriate "CIDR-supported" bit boundaries. Determination of IP
     address space allocation size is the responsibility of ARIN.

I haven't taken the time to review the rest of the document so if anyone
else has suggestions on revising the wording, I would appreciate it if you
would contact the author directly.

And I think some thanks are in order for the ARIN staff who are
undertaking this thankless task of getting the whole IP allocation
function better documented for all of us. I can't think of a worse
attitude to take than telling them that they are damned if they do and
damned if they don't.

For some unknown reason, although IHETS has been allocated the entire
traditional class B 165.138.0.0, they are announcing it as a partial
165.138.0.0/20. They could announce the entire /16. But they've chosen
not too.

They are quite entitled to that choice. And we are entitled not to accept
the route.

randy

[ Karl asks a bunch of cogent questions and then scares the shit out of
  me by following up with: ]

[This is a request as an ARIN AC member, who has tried to get a lot of
these kinds of questions answered from officers and trustees of ARIN]

Would it be out of line for me to ask why you are having so much
difficulty _getting_ answers to these questions that you need to ask
them here? This whole ARIN thing is starting to smell somewhat like the
InterNIC does...

Cheers,
-- jra

Dont forget were being charged $500 initially for AS numbers now.

ARIN has asserted that individual members (and in fact individual AC members)
don't have a right to have these types of questions answered.

It is my counter-assertion that IF ARIN is going to act as a custodian of
an essential facility (which it is), in the public interest (which is
currently open and in debate), that not only do the AC and membership have
these rights, but the general public has the right to full transparency
within ARIN's operation.

IMHO the network operators within ARIN's "sphere of influence" should
consider "waking up" and making their opinions known about this and related
sets of issues having to do with IPv4 allocation.

If there is a set of "affected organizations" which should be fully aware
of and involved in this, its the NANOG group.

Two places to do so are "arin-members@arin.net", and "arin-council@arin.net",
which are the mailing lists for the membership and AC, respectively.

Those who find themselves embargoed from posting to either are welcome to
ask me to forward material for them; as both an AC member, and an ARIN
member, I have the right to post to both.

The only way the questions will be resolved is if the debate is deemed
important by those who are impacted by ARIN - which is, virtually without
exception, an intersecting set within the NANOG community.

It would also be a good idea to read the ARIN bylaws (available on their web
site) and note carefully the lack of any real, functional oversight by the
membership (ie: the membership cannot recall an AC member, a board member,
or a corporate officer, either directly or indirectly).

Then surf over to the CIX web site and read THEIR bylaws. Compare the two,
and draw your own conclusions.

Both are, by the way, 501c(6) organizations.

I must agree with you in principle. If YOU, of all people, are not
permitted answers to these questions, who in the world is? And...what do
you get for your $1000 membership fee?

Spam(tm) is pressed meat. Spammers should be too.

Dean Robb
PC-Easy
On-site computer services
(757) 495-EASY [3279]

According to the bylaws (which provide me no ability to remove a BoT member
or officer, even if every other member agrees with me, and they're the only
ones who can make or implement policy; ergo, if there's folks members should
be able to fire, that's the short list) - the right to show up and stand
(or sit) in a room with others once a year.

And a cancelled check.

Yes, and that's for the entirely time-consuming entering your name and a
number in a database (can you say "default nextval()").

One has to wonder just where the authority for THAT one comes from.

ARIN has asserted that individual members (and in fact individual AC members)
don't have a right to have these types of questions answered.

It is my counter-assertion that IF ARIN is going to act as a custodian of
an essential facility (which it is), in the public interest (which is
currently open and in debate), that not only do the AC and membership have
these rights, but the general public has the right to full transparency
within ARIN's operation.

Right. And that requires that ARIN make such decisions with due process.
It does not allow an individual to browbeat the information out of an ARIN
employee. And it does not allow an ARIN employee to make the decision to
release this information without any consultation with at least the ARIN
Board of Trustees. It is especially important that ARIN employees don't
make special exceptions to the existing policies for you since you appear
to be attempting to entrap them by simultaneously demanding that ARIN act
like a public interest organization and demanding that ARIN employees do
special things for you right now that are outside of the current ARIN
policies.

IMHO the network operators within ARIN's "sphere of influence" should
consider "waking up" and making their opinions known about this and related
sets of issues having to do with IPv4 allocation.

I agree wholeheartedly. But I intensely dislike seeing your attempts to
subvert due process by demanding that ARIN employees work for you merely
because of some airy-fairy title like "Advisory Council Member". I don't
see why ARIN employees should need to jump when you say jump.

Those who find themselves embargoed from posting to either are welcome to
ask me to forward material for them; as both an AC member, and an ARIN
member, I have the right to post to both.

That's just plain silly. There are ARIN people on this list and if it's an
issue of importance to the NANOG community then there is no need to hide
the discussion off in a closed list somewhere. I see no good reason not to
have such a discussion here.

Then surf over to the CIX web site and read THEIR bylaws. Compare the two,
and draw your own conclusions.

No, please don't draw your own conclusions. The last thing we need are
more conspiracy theorists. But it would be decidedly useful if we had a
few more people willing to put some real effort into rewriting the bylaws
or at least digging up some more examples of bylaws from similar
organizations. Karl seems to think that the CIX is similar enough to ARIN
that we can copy parts of their bylaws wholesale. I happen to believe that
the CIX is rather unlike ARIN and would like to see some more examples.

In the Detroit area alot of smaller ISPs are looking to create a
peering between each other to create shorter router for wherever
traffic needs to go (ie. transit routing).

This plan has been placed on hold and almost officially shelved
because alot of the smaller ISPs dont see the need for an AS number.

It is like trying to get your budget increased. If the fee for AS
numbers was removed this peering would probably be already completed.

I think either I am missing the point or others are. We plan on
sending traffic through each others backbones. In essence we will be
one huge network. Sharing traffic. I can do this with private as
numbers?

Sure, as long as none of the AS numbers end up being "globally visible".
For example, you couldn't use the private AS number to announce routes to
your transit provider(s).

Bradley