Last Call for Comment: Policy Proposal 2001-2

Thu Nov 15 12:48:46 EST 2001

I would like to echo Daniel & Anita recommendation, in order to satisfy
today's small, 
medium and large business requirements, being able to provide a multi-home
solution 
and enjoy the diversity and a more reliable solution for their critical
Internet business needs. 

Regards,  Greg

-----Original Message-----
From: Anita Shah [mailto:asoni at sprint.net]
Sent: Thursday, November 15, 2001 11:00 AM
To: Daniel Golding
Cc: Trevor Paquette; ppml at arin.net
Subject: RE: Last Call for Comment: Policy Proposal 2001-2

I haven't been an active participant in these discussions, but I
completely agree with your points.  I work for an ISP that scrutinizes
customer network justifications in order to allocate IP address space
responsibly.  Our customers have resorted to lying in order to obtain a
/24 only because they are multihomed.  If they can falsify the
justification, they will be receiving the addresses anyway.  I would much
rather see this proposal pass.

Sincerely,
Anita Shah

On Tue, 13 Nov 2001, Daniel Golding wrote:

> to address the issues raised by Trevor Paquette...
>
> 	In regard to your first point, I strongly disagree that this policy
will
> cause an increase in wasted IP space. Currently, it is common knowledge
that
> a /24 is, more or less, globally routable. Thus, customers generally
demand,
> and generally receive /24s upon requests, for the purpose of multihoming.
In
> those circumstances where ISPs demand additional justification for the /24
> allocation, the customer will either provide it (if they have it), or lie
in
> order to receive it. As there are numerous legitimate multihomed
enterprises
> that can not justify a /24 via current standard, we have a significant
> amount of false justification. This isn't because people are dishonest -
> it's because there is a business requirement in many cases to multihome,
and
> an exaggerated justification is the only way to do it. Any policy that
> encourages normally honest people to deceive ARIN or an upstream ISP in
> order to achieve a legitimate purpose is, ipso facto, contrary to the good
> of the internet community, as open and honest communications between
issuer
> and issue is essential.
>
> Therefore, IPv4 exhaustion will not occur any sooner - it will occur at
the
> same rate. However, the general level of honesty and open communication
will
> rise, which is a worthy goal.
>
> 	In regard to your second point, I disagree that customers will take
> advantage of this policy to illegitimately secure IP space. There is
almost
> no reason for a customer to request a /24 unless they intend to multihome.
> Even if they feel they need it, checking for the issuance of an AS, and
> receiving the customer's assurance that they will multihome should be
> sufficient. I don't think anyone will be going back to police their
> customers - however, it will be appropriate to ensure compliance with
> previous allocations at the time of a request for new allocation. If
> additional allocations are made for internal political reasons by an ISP,
> they will need to be able to justify them to ARIN. If an organization is
so
> shortsighted that it would issue space to customers irresponsibly, this
> policy proposal will neither accentuate nor ameliorate that
> irresponsibility. In the end, such practices tend to "catch up" to ISPs -
> usually when they are trying to get additional space from ARIN.
>
> 	In regard to your third point, I'm confused. Is your assertion that
making
> it easier to get globally routable blocks will promote multihoming? If so,
> you are correct in that assertion. However, ARIN is meeting the demands of
> it's membership in promoting multihoming. Your concerns in regard to AS
> number depletion are currently being addressed in the IETF IDR working
> group's draft: BGP support for four-octet AS number space,
> draft-ietf-idr-as4bytes-04.txt. At the current rate of AS depletion, there
> should be sufficient AS numbers for 4 to 6 years into the future. This
draft
> should be implemented will before then.
>
> 	Your forth point is only tangentially related to this policy
proposal.
> Ensuring that customers meet, and then continue to meet, requirements for
> the allocation of IP space has long been the responsibility of their
> upstream provider. Although this can be a difficult issue, service
providers
> should continue their current policies in this regard, which generally
> adhere to the idea of requiring justification at time of issuance, and
then
> requiring additional justification (As well as confirmation of previous
> justification) upon additional address request. This is the general model
> upon which ARIN related to it's member-customers, and is a good model for
> it's members to use in relation to their own customers. No one is being
> required to be an "IP Address Cop" to the detriment of their business.
> However, everyone is required to act responsibly to safeguard a public
> resource. This policy proposal does not alter that axiom.
>
> Needless to say, I support Policy Proposal 2001-2, and urge the ARIN BoD
to
> adopt it at their earliest convenience.
>
> Sincerely,
>
> Daniel Golding
>
> > -----Original Message-----
> > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of
> > Trevor Paquette
> > Sent: Tuesday, November 13, 2001 1:48 PM
> > To: ppml at arin.net
> > Subject: RE: Last Call for Comment: Policy Proposal 2001-2
> >
> >
> >
> > By adopting this policy I think the following points should be made:
> >
> > 1) IPv4 exhaustion
> >    v4 space will be used at a higher rate, with an increase of
> > wasted space.
> >    More and more companies are beginning to rely on the internet
> > to conduct
> >    their day to day business operations (Raise your hand if you've heard
> >    complaints from customers when email is not delivered within 5
minutes
> >    after they hit 'send'). As such, these companies will begin to look
at
> >    providing their own redundant links to the Internet (via
multi-homing)
> >    and not depend on the redundancy of their upstream provider.
> > This 'always
> >    connected' (vs 'always on') requirement will increase IP requests to
> >    upstream providers.
> >
> > 2) Potential for abuse of the policy to secure IP space.
> >    I can see companies begin to abuse Policy 2001-2 to secure a /24
> >    and use very little address space out of that block. Some
> > companies will
> >    lie about being or becoming multi-homed in order to secure
> > more IP space
> >    then they really need.
> >
> >    In today's world, revenue is king. If I have to tell a customer
because
> >    they are no longer multi-homed (or they lied about it), that I have
to
> >    pull their IP space; and they threaten to terminate their service
with
> >    us; guess who is going to win. The customer. Very few Senior
Executives
> >    understand or care about IP Policy; their job is to make the company
> >    money, keep the revenues flowing. If that means the customer gets to
> >    keep their /24; so be it.
> >
> > 3) The current AS limit.
> >    As a few folks have mentioned before that AS numbers are a much
scarcer
> >    commodity then IP space. I agree with that statement. Policy
> > 2001-2 will
> >    make the AS space run out faster. (Do we need to propose an new
policy
> >    or an RFC on increasing AS size?)
> >
> > 4) Reclaimation
> >    How does an ISP reclaim the IP space (here comes the key
> > phrase) "without
> >    losing that customer", should the customer decide one day that they
no
> >    longer want to be multi-homed? Is it up to the ISP that gave
> > the IP space
> >    in the first place to periodically check to make sure that the
> > customer is
> >    in fact still multi-homed? (which brings up point 2 again)
> >
> > Remember, I'm not saying that these points will happen. I'm
> > saying that these
> > are very possible scenarios.
> >
> > My apologies if this has been discussed before; I was in Nassau during
the
> > hurricane (very little Internet access in Nassau, even more so during
the
> > storm and the days following it) and I just got home to start
> > catching up on
> > things.
> >
> > Trev
> > --
> >
> > Trevor Paquette          |TeraGo Networks Inc.  |Work:(403)668-5321
> > Trevor.Paquette at TeraGo.ca|300, 300 Manning Rd NE|Cell:(403)703-8738
> > Lead Systems Architect   |Calgary, AB, Canada   |Main:(403)668-5300
> > http://www.terago.ca     |       T2E 4K8        | Fax:(403)668-5344
> >
>

Thanks,
Anita J. Shah
Sprint E|Solutions
Service Delivery
703-689-5076
anita.j.shah at mail.sprint.com
asoni at sprint.net