From bmanning at vacation.karoshi.com  Sat Feb 12 13:44:38 2005
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sat, 12 Feb 2005 18:44:38 +0000
Subject: [ppml] wgig webcast
Message-ID: <20050212184438.GB969@vacation.karoshi.com.>


for those tangentially interested in WGIG/WSIS. The next mtg
in Geneva is next week.  Parts will be 'cast.  Pointers here:

http://streaming.polito.it/wgig-meeting

--bill


From william at elan.net  Sat Feb 12 14:09:40 2005
From: william at elan.net (william(at)elan.net)
Date: Sat, 12 Feb 2005 11:09:40 -0800 (PST)
Subject: [ppml] wgig webcast
In-Reply-To: <20050212184438.GB969@vacation.karoshi.com.>
Message-ID: <Pine.LNX.4.44.0502121108400.3084-100000@sokol.elan.net>


People from ARIN are there and will give summary at the meeting, right?

On Sat, 12 Feb 2005 bmanning at vacation.karoshi.com wrote:
 
> for those tangentially interested in WGIG/WSIS. The next mtg
> in Geneva is next week.  Parts will be 'cast.  Pointers here:
> 
> http://streaming.polito.it/wgig-meeting
> 
> --bill



From bmanning at vacation.karoshi.com  Sat Feb 12 14:16:23 2005
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sat, 12 Feb 2005 19:16:23 +0000
Subject: [ppml] wgig webcast
In-Reply-To: <Pine.LNX.4.44.0502121108400.3084-100000@sokol.elan.net>
References: <20050212184438.GB969@vacation.karoshi.com.> <Pine.LNX.4.44.0502121108400.3084-100000@sokol.elan.net>
Message-ID: <20050212191623.GD969@vacation.karoshi.com.>

On Sat, Feb 12, 2005 at 11:09:40AM -0800, william(at)elan.net wrote:
> 
> People from ARIN are there and will give summary at the meeting, right?

	not that i am aware of.
	
> 
> On Sat, 12 Feb 2005 bmanning at vacation.karoshi.com wrote:
>  
> > for those tangentially interested in WGIG/WSIS. The next mtg
> > in Geneva is next week.  Parts will be 'cast.  Pointers here:
> > 
> > http://streaming.polito.it/wgig-meeting
> > 
> > --bill


From stacy at hilander.com  Sat Feb 12 15:55:01 2005
From: stacy at hilander.com (stacy at hilander.com)
Date: Sat, 12 Feb 2005 13:55:01 -0700
Subject: [ppml] wgig webcast
In-Reply-To: <20050212184438.GB969@vacation.karoshi.com.>
References: <20050212184438.GB969@vacation.karoshi.com.>
Message-ID: <1108241701.420e6d2503fc0@www.hilander.com>

Thanks so much, Bill!
We all need to be paying attention to this, you guys!!
:)
/Stacy

Quoting bmanning at vacation.karoshi.com:

>
> for those tangentially interested in WGIG/WSIS. The next mtg
> in Geneva is next week.  Parts will be 'cast.  Pointers here:
>
> http://streaming.polito.it/wgig-meeting
>
> --bill
>





From andrew.dul at quark.net  Sun Feb 13 12:41:28 2005
From: andrew.dul at quark.net (Andrew Dul)
Date: Sun, 13 Feb 2005 09:41:28 -0800
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Cidr Report
Message-ID: <20050213174247.DFDDC1445C6@smtp2.arin.net>

I was wondering if people in the ARIN region agreed with these statements
about the ARIN region not doing enough to educate the membership about
deaggregation, BGP annoucements etc...

If ARIN were to do more what would you suggest?  

1. More/Better online training
2. Regional Training session (similar to RIPE?)
3  Other???

Andrew

>From: Hank Nussbacher <hank at mail.iucc.ac.il>
>To: Philip Smith <pfs at cisco.com>
>Cc: nanog at merit.edu
>Subject: Re: The Cidr Report
>Sender: owner-nanog at merit.edu
>X-Loop: nanog
>
>
>On Sat, 12 Feb 2005, Philip Smith wrote:
>
>>  From my own Routing Report (due out in a couple of hours), a quick
>> glance shows that the vast majority of the increase comes from ASNs
>> assigned by ARIN (the ASNs from the other three registry regions show
>> minimal increase in announcements).
>
>Duh!  No suprise there.  ARIN just gives IP space and only offers some
>measly online training:
>http://www.arin.net/library/training/index.html
>
>RIPE on the other hand, has 3-6 course a month, throughout Europe:
>http://www.ripe.net/training/lir/index.html
>http://www.ripe.net/cgi-bin/courselist.pl.cgi
>
>APNIC also has a number of courses and goes out to where it is needed:
>http://www.apnic.net/training/schedule.html
>
>As long as ARIN just doles out IP space with no education, the routing
>table will continue to grow.
>
>-Hank
>
>>
>> Most seem to come from AS4323. Today they are announcing 2606 prefixes,
>> a week ago they were announcing 844 prefixes.
>>
>> philip
> 



From randy at psg.com  Sun Feb 13 12:59:42 2005
From: randy at psg.com (Randy Bush)
Date: Sun, 13 Feb 2005 07:59:42 -1000
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Cidr Report
References: <20050213174247.DFDDC1445C6@smtp2.arin.net>
Message-ID: <16911.38286.172767.148512@roam.psg.com>

> I was wondering if people in the ARIN region agreed with these statements
> about the ARIN region not doing enough to educate the membership about
> deaggregation, BGP annoucements etc...

the vast majority of de-aggregation in the arin region is very
intentional by a few isps who think their own mis-perceived
needs are more important than the public good.  you can see
their names at the top of the cidr report.  they are very aware
of the issues, yet persist.

> If ARIN were to do more what would you suggest?

the only things arin could do would be sufficiently draconian
as to be inappropriate.

the other isps need to act.  we are hoping that the router
vendors will provide a few knobs as have been discussed on
cisco-nsp.  this will allow us to ignore, not see and not
propagate, de-aggregated prefixes.

randy



From jlewis at lewis.org  Sun Feb 13 13:12:05 2005
From: jlewis at lewis.org (Jon Lewis)
Date: Sun, 13 Feb 2005 13:12:05 -0500 (EST)
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Cidr
 Report
In-Reply-To: <20050213174247.DFDDC1445C6@smtp2.arin.net>
References: <20050213174247.DFDDC1445C6@smtp2.arin.net>
Message-ID: <Pine.LNX.4.58.0502131252380.8534@web1.mmaero.com>

On Sun, 13 Feb 2005, Andrew Dul wrote:

> I was wondering if people in the ARIN region agreed with these statements
> about the ARIN region not doing enough to educate the membership about
> deaggregation, BGP annoucements etc...
>
> If ARIN were to do more what would you suggest?
>
> 1. More/Better online training
> 2. Regional Training session (similar to RIPE?)

Whether or not ARIN actually did any training courses, it would be nice to
see some info on BCPs for BGP routing in the training section of the ARIN
web site rather than just "how to use whois" and "how to jump through the
hoops to get IP space".

Too many networks deaggregate their announcements for no reason simply
because they don't realize there's any reason they shouldn't.

Covering things like route filtering (i.e. not leaking provider A's routes
to provider B) would be nice.  Might even mention the use of routing
registries (radb, altdb, ARIN's own one, etc.).

To make a bad analogy, right now, ARIN's like a gun shop selling guns with
no manuals and no safety literature.  Not everyone who's buying knows how
to use them safely.

----------------------------------------------------------------------
 Jon Lewis                   |  I route
 Senior Network Engineer     |  therefore you are
 Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From hannigan at verisign.com  Sun Feb 13 18:31:01 2005
From: hannigan at verisign.com (Hannigan, Martin)
Date: Sun, 13 Feb 2005 18:31:01 -0500
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Ci
	dr Report
Message-ID: <A206819EF47CBE4F84B5CB4A303CEB7A242300@dul1wnexmb01.vcorp.ad.vrsn.com>

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Jon
> Lewis
> Sent: Sunday, February 13, 2005 1:12 PM
> To: Andrew Dul
> Cc: ppml at arin.net
> Subject: Re: [ppml] Deaggregation in the ARIN region Was: [nanog] The
> Cidr Report
> 
> 
> On Sun, 13 Feb 2005, Andrew Dul wrote:
> 
> > I was wondering if people in the ARIN region agreed with 
> these statements
> > about the ARIN region not doing enough to educate the 
> membership about
> > deaggregation, BGP annoucements etc...
> >
> > If ARIN were to do more what would you suggest?
> >
> > 1. More/Better online training
> > 2. Regional Training session (similar to RIPE?)
> 
> Whether or not ARIN actually did any training courses, it 
> would be nice to
> see some info on BCPs for BGP routing in the training section 
> of the ARIN
> web site rather than just "how to use whois" and "how to jump 
> through the
> hoops to get IP space".

Not a bad idea, but don't confuse apathy with responsibility. 
Aggregation isn't a new concept.

> 
> Too many networks deaggregate their announcements for no reason simply
> because they don't realize there's any reason they shouldn't.
>
> Covering things like route filtering (i.e. not leaking 
> provider A's routes
> to provider B) would be nice.  Might even mention the use of routing
> registries (radb, altdb, ARIN's own one, etc.).
> 
> To make a bad analogy, right now, ARIN's like a gun shop 
> selling guns with
> no manuals and no safety literature.  Not everyone who's 
> buying knows how
> to use them safely.

I would be a good idea to ask the operators/NANOG to get this into 
their BGP BoF curriculum and have it stay there.

http://www.nanog.org/mtg-0501/smith.html

About ARIN says:

"and supports efforts to keep the global routing tables to a manageable 
size to ensure information can be routed over the Internet."

What more could ARIN do other than send in the leg breakers?

-M<



From billd at cait.wustl.edu  Sun Feb 13 18:50:23 2005
From: billd at cait.wustl.edu (Bill Darte)
Date: Sun, 13 Feb 2005 17:50:23 -0600
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Ci
	dr Report
Message-ID: <50C9C45A7E8DCE41A19F7A94715BABFD02A75B@kronos.cait.wustl.edu>

Jon,

BCPs for BGP appearing on ARIN's website, you say. Well, it is possible that
if you forwarded some they might be posted....but then again who would
maintain them? Perhaps you know of a link to such?

I'm thinking that BCPs for the routing infrastructure sounds more like an
operational issue.  Is the educational effort you suggest not more
appropriate to NANOG than to ARIN?

Don't get me wrong.  I think that whenever ARIN can support educational
objectives that improve the Internet it would be great.  In fact, ARIN has
sponsored fundamental education with tutorials associated with BGP at its
twice yearly Public Policy and Membership Meetings.

Also, there was significant outreach from ARIN to identify education that
its stakeholders wanted and it was met with deafening silence...even when it
was quite widely know what effort was underway in other regions.  Should
ARIN allocate resources to such effort when there is no evidence that such
an investment would be valued by those that pay the bills?

Bill Darte
ARIN Advisory Council



On Sun, 13 Feb 2005, Andrew Dul wrote:

> I was wondering if people in the ARIN region agreed with these
statements
> about the ARIN region not doing enough to educate the membership about
> deaggregation, BGP annoucements etc...
>
> If ARIN were to do more what would you suggest?
>
> 1. More/Better online training
> 2. Regional Training session (similar to RIPE?)

Whether or not ARIN actually did any training courses, it would be nice
to
see some info on BCPs for BGP routing in the training section of the
ARIN
web site rather than just "how to use whois" and "how to jump through
the
hoops to get IP space".

Too many networks deaggregate their announcements for no reason simply
because they don't realize there's any reason they shouldn't.

Covering things like route filtering (i.e. not leaking provider A's
routes
to provider B) would be nice.  Might even mention the use of routing
registries (radb, altdb, ARIN's own one, etc.).

To make a bad analogy, right now, ARIN's like a gun shop selling guns
with
no manuals and no safety literature.  Not everyone who's buying knows
how
to use them safely.

----------------------------------------------------------------------
 Jon Lewis                   |  I route
 Senior Network Engineer     |  therefore you are
 Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From jlewis at lewis.org  Mon Feb 14 12:04:08 2005
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 14 Feb 2005 12:04:08 -0500 (EST)
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Ci
 dr Report
In-Reply-To: <50C9C45A7E8DCE41A19F7A94715BABFD02A75B@kronos.cait.wustl.edu>
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A75B@kronos.cait.wustl.edu>
Message-ID: <Pine.LNX.4.58.0502141152340.8534@web1.mmaero.com>

On Sun, 13 Feb 2005, Bill Darte wrote:

> BCPs for BGP appearing on ARIN's website, you say. Well, it is possible that
> if you forwarded some they might be posted....but then again who would
> maintain them? Perhaps you know of a link to such?
>
> I'm thinking that BCPs for the routing infrastructure sounds more like an
> operational issue.  Is the educational effort you suggest not more
> appropriate to NANOG than to ARIN?

It probably is, but I'd wager a large percentage of ARIN "members"
(assuming everyone with an ASN assigned by ARIN is a "member", even
though they don't appear to be based on
http://www.arin.net/membership/index.html) have never been to a NANOG
meeting or heard of the mailing list.

It seems to me there are at least 2 classes of deaggregators...the big NSP
types who certainly should have engineering staff who know better but for
whatever reasons choose to deaggregate, and the small network/ISP who may
not even have PI space, but deaggregates whatever they do have into /24s
because that's how someone set it up for them, and it's not broken as far
as they can tell.

You probably can't help the first class without waving a stick at them.
The second class just needs a little education that could be provided in
the form of some "helpful URLs" on "BGP and the internet community" when
they receive their ASN.

> Also, there was significant outreach from ARIN to identify education that
> its stakeholders wanted and it was met with deafening silence...even when it
> was quite widely know what effort was underway in other regions.  Should
> ARIN allocate resources to such effort when there is no evidence that such
> an investment would be valued by those that pay the bills?

I'm not suggesting a training program that would require
"resources"...just a few links and/or short paragraphs on BGP, and how to
be a good netizen with it.  The sort of thing that could be thrown
together by one person in an afternoon or less.

----------------------------------------------------------------------
 Jon Lewis                   |  I route
 Senior Network Engineer     |  therefore you are
 Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From owen at delong.com  Mon Feb 14 16:21:27 2005
From: owen at delong.com (Owen DeLong)
Date: Mon, 14 Feb 2005 13:21:27 -0800
Subject: [ppml] Deaggregation in the ARIN region Was: [nanog] The Ci dr
 Report
In-Reply-To: <Pine.LNX.4.58.0502141152340.8534@web1.mmaero.com>
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A75B@kronos.cait.wustl.edu>
 <Pine.LNX.4.58.0502141152340.8534@web1.mmaero.com>
Message-ID: <2147483647.1108387287@imac-en0.delong.sj.ca.us>

> It probably is, but I'd wager a large percentage of ARIN "members"
> (assuming everyone with an ASN assigned by ARIN is a "member", even
> though they don't appear to be based on
> http://www.arin.net/membership/index.html) have never been to a NANOG
> meeting or heard of the mailing list.
>
A large percentage of ARIN "members" have been to NANOG.  A decent 
percentage
of ARIN members don't have ASNs.  A decent percentage of entities with
ASNs are NOT ARIN members.  Generally, I'd take your bet on multiple levels.

> It seems to me there are at least 2 classes of deaggregators...the big NSP
> types who certainly should have engineering staff who know better but for
> whatever reasons choose to deaggregate, and the small network/ISP who may
> not even have PI space, but deaggregates whatever they do have into /24s
> because that's how someone set it up for them, and it's not broken as far
> as they can tell.
>
Yep.  And the big NSPs have mostly been to NANOG at least once or twice.

> You probably can't help the first class without waving a stick at them.
> The second class just needs a little education that could be provided in
> the form of some "helpful URLs" on "BGP and the internet community" when
> they receive their ASN.
>
Perhaps, but, how many of the orgs in this class are recently issued
(>35000) ASNs?  I tend to suspect it is a small percentage of the group.

I agree that throwing up the links and such wouldn't be a bad idea for
ARIN to do, but, it's not quite as simple as you suggest.  Someone
needs to periodically check those links and find new ones when the old
ones become invalid.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050214/6bee8baf/attachment.sig>

From bruce.eastman at adelphia.com  Mon Feb 14 16:45:20 2005
From: bruce.eastman at adelphia.com (Bruce Eastman)
Date: Mon, 14 Feb 2005 16:45:20 -0500
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Cidr Report
References: <20050213174247.DFDDC1445C6@smtp2.arin.net> <Pine.LNX.4.58.0502131252380.8534@web1.mmaero.com>
Message-ID: <00cf01c512de$7af25a30$5e2012d1@deipadmin>

> To make a bad analogy, right now, ARIN's like a gun shop selling guns with
> no manuals and no safety literature.  Not everyone who's buying knows how
> to use them safely.



Maybe ARIN should add a Warning label. :)





WARNING - DANGER - READ THIS & HEED THIS!



WARNING: THIS IS NOT A TOY. THIS IP IS DESIGNED FOR USE BY EXPERIENCED
NETWORKING PERSONNEL AND IS INTENDED

 FOR USE BY AN EXPERT IN ROUTING. THESE IP'S ARE INTENDED FOR USE SOLELY BY
SENIOR NETWORK ENGINEER TYPES

( WITH NECESSARY SAFETY EQUIPMENT ). NO OTHER USE IS INTENDED OR
RECOMMENDED. ILLEGAL TO OWN, PURCHASE OR

TRANSFER BY ANYONE OTHER THAN ARIN OR OUTSIDE THE TERMS AFOREMENTIONED.
MISUSE OR CARELESS USE MAY CAUSE

SERIOUS ROUTING DEAGGREGATION. READ OWNERS MANUAL BEFORE USING.





Bruce Eastman
Senior IP Analyst
Adelphia Communications




----- Original Message ----- 
From: "Jon Lewis" <jlewis at lewis.org>
To: "Andrew Dul" <andrew.dul at quark.net>
Cc: <ppml at arin.net>
Sent: Sunday, February 13, 2005 1:12 PM
Subject: Re: [ppml] Deaggregation in the ARIN region Was: [nanog] The Cidr
Report


> On Sun, 13 Feb 2005, Andrew Dul wrote:
>
> > I was wondering if people in the ARIN region agreed with these
statements
> > about the ARIN region not doing enough to educate the membership about
> > deaggregation, BGP annoucements etc...
> >
> > If ARIN were to do more what would you suggest?
> >
> > 1. More/Better online training
> > 2. Regional Training session (similar to RIPE?)
>
> Whether or not ARIN actually did any training courses, it would be nice to
> see some info on BCPs for BGP routing in the training section of the ARIN
> web site rather than just "how to use whois" and "how to jump through the
> hoops to get IP space".
>
> Too many networks deaggregate their announcements for no reason simply
> because they don't realize there's any reason they shouldn't.
>
> Covering things like route filtering (i.e. not leaking provider A's routes
> to provider B) would be nice.  Might even mention the use of routing
> registries (radb, altdb, ARIN's own one, etc.).
>
> To make a bad analogy, right now, ARIN's like a gun shop selling guns with
> no manuals and no safety literature.  Not everyone who's buying knows how
> to use them safely.
>
> ----------------------------------------------------------------------
>  Jon Lewis                   |  I route
>  Senior Network Engineer     |  therefore you are
>  Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From jlewis at lewis.org  Mon Feb 14 18:03:57 2005
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 14 Feb 2005 18:03:57 -0500 (EST)
Subject: [ppml] Deaggregation in the ARIN region Was: [nanog] The Ci dr
 Report
In-Reply-To: <2147483647.1108387287@imac-en0.delong.sj.ca.us>
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A75B@kronos.cait.wustl.edu>
 <Pine.LNX.4.58.0502141152340.8534@web1.mmaero.com>
 <2147483647.1108387287@imac-en0.delong.sj.ca.us>
Message-ID: <Pine.LNX.4.58.0502141743140.8534@web1.mmaero.com>

On Mon, 14 Feb 2005, Owen DeLong wrote:

> A large percentage of ARIN "members" have been to NANOG.

How sure are you about that?...especially using my loose definition of
ARIN "members" as any network with an ASN from ARIN?  There are lots of
companies that have multihomed (and therefore gotten at least an ASN so
they can do BGP) who have no interest in going to NANOG meetings...or
aren't even aware of them.  To my knowledge, of the 2 ISPs I've worked
for, only the current one has ever sent anyone to a NANOG meeting...and
that was me at my request a few meetings ago when it was nearby in Miami.
Of the BGP customers I've had, I'm confident none of them have been to a
meeting...and I'd bet at least some of them don't know what NANOG is.

If nanog.org had a list of attendees by ASN, that would be nice to look at
to see how many unique ASNs have been represented at a NANOG, but all I
could find was names/companies for each meeting in really terrible looking
HTML.  And just sending someone to a meeting is no guarantee they'll pick
up any BGP clue.

> A decent percentage of ARIN members don't have ASNs.

What sort of members are they then?

> A decent percentage of entities with ASNs are NOT ARIN members.

Yeah...I realized that before my last message when I checked and saw that
just having an ASN does not make you a member...thus my use of "members".

> Yep.  And the big NSPs have mostly been to NANOG at least once or twice.

Not debating that...the big ones obviously know better, but have their
reasons, perhaps technical, perhaps legacy and not enough clueful spare
man hours to get it cleaned up, or just no motivation to.

> Perhaps, but, how many of the orgs in this class are recently issued
> (>35000) ASNs?  I tend to suspect it is a small percentage of the group.

What does recently issued have to do with it, and what's the reference to
>35000?  AFAICT, ARIN appears to be up to about AS33642 (issued last
Friday).  There are ARIN-nonmembers who've had ASNs for years and could
have used some BGP tips years ago.

> I agree that throwing up the links and such wouldn't be a bad idea for
> ARIN to do, but, it's not quite as simple as you suggest.  Someone
> needs to periodically check those links and find new ones when the old
> ones become invalid.

So put up locally "cached" copies with links to the originals...if the
original links go stale, nothing's really lost.  Or just make up original
content based on info gathered from things like some of Avi's BGP howtos.

----------------------------------------------------------------------
 Jon Lewis                   |  I route
 Senior Network Engineer     |  therefore you are
 Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From billd at cait.wustl.edu  Mon Feb 14 18:32:46 2005
From: billd at cait.wustl.edu (Bill Darte)
Date: Mon, 14 Feb 2005 17:32:46 -0600
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Ci
	dr Report
Message-ID: <50C9C45A7E8DCE41A19F7A94715BABFD02A76F@kronos.cait.wustl.edu>

Jon is right.  Deaggregation is not a laughing matter. Its poor management
at least from a netizens point of view....

Still, you advisory below is a hoot!  I like it.

Bill Darte


Bruce Eastman said:


Maybe ARIN should add a Warning label. :)





WARNING - DANGER - READ THIS & HEED THIS!



WARNING: THIS IS NOT A TOY. THIS IP IS DESIGNED FOR USE BY EXPERIENCED
NETWORKING PERSONNEL AND IS INTENDED

 FOR USE BY AN EXPERT IN ROUTING. THESE IP'S ARE INTENDED FOR USE SOLELY
BY
SENIOR NETWORK ENGINEER TYPES

( WITH NECESSARY SAFETY EQUIPMENT ). NO OTHER USE IS INTENDED OR
RECOMMENDED. ILLEGAL TO OWN, PURCHASE OR

TRANSFER BY ANYONE OTHER THAN ARIN OR OUTSIDE THE TERMS AFOREMENTIONED.
MISUSE OR CARELESS USE MAY CAUSE

SERIOUS ROUTING DEAGGREGATION. READ OWNERS MANUAL BEFORE USING.





Bruce Eastman
Senior IP Analyst
Adelphia Communications




----- Original Message ----- 
From: "Jon Lewis" <jlewis at lewis.org>
To: "Andrew Dul" <andrew.dul at quark.net>
Cc: <ppml at arin.net>
Sent: Sunday, February 13, 2005 1:12 PM
Subject: Re: [ppml] Deaggregation in the ARIN region Was: [nanog] The
Cidr
Report


> On Sun, 13 Feb 2005, Andrew Dul wrote:
>
> > I was wondering if people in the ARIN region agreed with these
statements
> > about the ARIN region not doing enough to educate the membership
about
> > deaggregation, BGP annoucements etc...
> >
> > If ARIN were to do more what would you suggest?
> >
> > 1. More/Better online training
> > 2. Regional Training session (similar to RIPE?)
>
> Whether or not ARIN actually did any training courses, it would be
nice to
> see some info on BCPs for BGP routing in the training section of the
ARIN
> web site rather than just "how to use whois" and "how to jump through
the
> hoops to get IP space".
>
> Too many networks deaggregate their announcements for no reason simply
> because they don't realize there's any reason they shouldn't.
>
> Covering things like route filtering (i.e. not leaking provider A's
routes
> to provider B) would be nice.  Might even mention the use of routing
> registries (radb, altdb, ARIN's own one, etc.).
>
> To make a bad analogy, right now, ARIN's like a gun shop selling guns
with
> no manuals and no safety literature.  Not everyone who's buying knows
how
> to use them safely.
>
> ----------------------------------------------------------------------
>  Jon Lewis                   |  I route
>  Senior Network Engineer     |  therefore you are
>  Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From hannigan at verisign.com  Mon Feb 14 18:54:34 2005
From: hannigan at verisign.com (Hannigan, Martin)
Date: Mon, 14 Feb 2005 18:54:34 -0500
Subject: [ppml] Deaggregation in the ARIN region Was: [nanog] The Ci d
	r Report
Message-ID: <A206819EF47CBE4F84B5CB4A303CEB7A242335@dul1wnexmb01.vcorp.ad.vrsn.com>

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Jon
> Lewis
> Sent: Monday, February 14, 2005 6:04 PM
> To: Owen DeLong
> Cc: ppml at arin.net
> Subject: RE: [ppml] Deaggregation in the ARIN region Was: 
> [nanog] The Ci
> dr Report
> 
> 
> On Mon, 14 Feb 2005, Owen DeLong wrote:
> 
> > A large percentage of ARIN "members" have been to NANOG.
> 
> How sure are you about that?...especially using my loose definition of
> ARIN "members" as any network with an ASN from ARIN?  There 
> are lots of
> companies that have multihomed (and therefore gotten at least 
> an ASN so
> they can do BGP) who have no interest in going to NANOG meetings...or
> aren't even aware of them.  To my knowledge, of the 2 ISPs I've worked
> for, only the current one has ever sent anyone to a NANOG 
> meeting...and
> that was me at my request a few meetings ago when it was 
> nearby in Miami.
> Of the BGP customers I've had, I'm confident none of them 
> have been to a
> meeting...and I'd bet at least some of them don't know what NANOG is.

Almost every ISP on the CIDR report(most of the continuing problem) has been

to one or more NANOGs. Most can be found "usually" there.

>From my operator experience, this is why it seems pretty clear to me
that it's an operators responsibility to apply their routing policies 
to their customers. Extended education sessions across the country
will address 1% of the problem and I would consider it a waste of
ARIN's resources - to be honest. The web page idea is the way to
go.

[ SNIP ]






From bicknell at ufp.org  Mon Feb 14 20:04:24 2005
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 14 Feb 2005 20:04:24 -0500
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Cidr Report
In-Reply-To: <20050213174247.DFDDC1445C6@smtp2.arin.net>
References: <20050213174247.DFDDC1445C6@smtp2.arin.net>
Message-ID: <20050215010424.GA89128@ussenterprise.ufp.org>

In a message written on Sun, Feb 13, 2005 at 09:41:28AM -0800, Andrew Dul wrote:
> I was wondering if people in the ARIN region agreed with these statements
> about the ARIN region not doing enough to educate the membership about
> deaggregation, BGP annoucements etc...

I guess I question if there is an education problem.  For all the
complaining on the NANOG mailing list I've never seen something
more than, well complaining.

You can split the issues into several categories, and I don't know
how ARIN can help with any of them.  First, in many cases no one
can bother to contact the offending party.  Obviously their own
upstream is a prime candidate to notice and contact the person in
question.  If we can't get the major ISP's who have a clue, and
have staff, and know the issues to make it a priority to contact
the smaller players and help them along then I don't know what hope
we have for some outside influence to make a difference.

Second, when contacted, one of two things happen.  The parties often
clean up their act simply by someone asking (the, "oops, I didn't
know I was doing that" situation).  In the other cases, the response
is often "I have a reason to do this and I'm not explaining it to
you."  I suppose ARIN might be able to do something in the former
case although I question if it is appropriate.  In the latter case,
unless the industry as a whole takes a much stronger stance and
imposes sanctions (eg, route filtering) then no one complaining
will make a difference.

Third, and most important, does anyone care?  We're not at a stage
anymore where the routers are on the verge of falling over.  Other
than a few complainers, it's not clear this issue impacts the day
to day operation of anyone's network in a significant way.  Obviously
there is the potential, if it gets worse it could get real bad real
quick.  There seems to be a level of tolerance for slop in the
system right now, and that's probably a good thing.

So, I too question if ARIN is the right place.  However, if anyone
is going to take action on this I think it needs to be documented
not only that this is occurring (which is easy, from the CIDR report)
but that the existing mechanisms don't work (contacting the party,
contacting their upstream), and that as a result of them not working
there is a danger to the system.

While minizing the table is a good engineering practice, there are
reasons to de-aggregate.  Several providers have been forced to do
it during the past few years merger sprees on a temporary basis to
aid in transition.  We don't want to be so rigid that they would
be precluded from de-aggregating for a few months to make for a
smoother transition when there are resources available.  Forcing
more complicated transitions may actually lead to greater Internet
instability.

There are obviously people simply ignorant of the issue and de-aggregating
for no reason, but those are also people unlikely to reach out for
any help out of ignorance or apathy.  To reach those people will
require a proactive effort.  Since ARIN does not actively manage
the routing table, it seems likely they are best to be proactive
about what is in the routing table.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050214/8725e71c/attachment.sig>

From Michael.Dillon at radianz.com  Tue Feb 15 04:46:10 2005
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Tue, 15 Feb 2005 09:46:10 +0000
Subject: [ppml] Deaggregation in the ARIN region Was: [nanog] The Ci d	r Report
In-Reply-To: <A206819EF47CBE4F84B5CB4A303CEB7A242335@dul1wnexmb01.vcorp.ad.vrsn.com>
Message-ID: <OF612065EB.EF15C798-ON80256FA9.003544CF-80256FA9.0035AA68@radianz.com>

> Almost every ISP on the CIDR report(most of the continuing problem) has 
been
> to one or more NANOGs. Most can be found "usually" there.

I disagree. I have been to several NANOG meetings and
I have never seen an ISP or NSP at any of them. All
attendees that I saw were PEOPLE. Yes, many of them
worked for one ISP or another in various different
job capacities, but this is hardly relevant.

The problem is that we want CORPORATE entities
to take a certain action, namely aggregating their
BGP announcements. In order for this to happen we
somehow need to communicate the need for such action
with the decision makers in those corporate entities
and provide a justification for what we say.

Nothing that I have seen indicates that ISP
decision makers are even aware of the problem.
I have no idea how many ISP decision makers are
on the NANOG and ARIN lists nor do I know
how many of the list members have the ear
of the decision makers in their organizations.

Talk is cheap.

--Michael Dillon



From Michael.Dillon at radianz.com  Tue Feb 15 04:50:47 2005
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Tue, 15 Feb 2005 09:50:47 +0000
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Cidr Report
In-Reply-To: <20050215010424.GA89128@ussenterprise.ufp.org>
Message-ID: <OF8EF6CD1A.D2BBB154-ON80256FA9.0035ACF8-80256FA9.003616A3@radianz.com>

> Third, and most important, does anyone care?  We're not at a stage
> anymore where the routers are on the verge of falling over.  Other
> than a few complainers, it's not clear this issue impacts the day
> to day operation of anyone's network in a significant way.

Exactly.

There is no agreed problem to solve. I have no idea
what these people are complaining about. The nearest
I can tell is that they don't like the top ten organizations
on the list at the CIDR report. I'd like to point out
that any list of networks will always have a top ten.
There is nothing wrong with being on the top of a list.

Before ARIN takes any action at all, education or
otherwise, the people calling for action need to
present a clear statement of the problem and the
actions that they desire from network operators. 
If there really is a "best practice" here that is
not practiced by enough networks, then we need an
authoritative document that defines this "best practice"
before we can do anything.

It is not ARIN's job to create a "best practice"
document for Internet operations.

--Michael Dillon



From cpm at well.com  Tue Feb 15 07:50:10 2005
From: cpm at well.com (Chip Mefford)
Date: Tue, 15 Feb 2005 07:50:10 -0500
Subject: [ppml] Deaggregation in the ARIN region (typical gallery noise)
In-Reply-To: <20050215010424.GA89128@ussenterprise.ufp.org>
References: <20050213174247.DFDDC1445C6@smtp2.arin.net> <20050215010424.GA89128@ussenterprise.ufp.org>
Message-ID: <4211F002.7040101@well.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leo Bicknell wrote:
| In a message written on Sun, Feb 13, 2005 at 09:41:28AM -0800, Andrew
Dul wrote:
|
|>I was wondering if people in the ARIN region agreed with these statements
|>about the ARIN region not doing enough to educate the membership about
|>deaggregation, BGP annoucements etc...
|> snipped in original;

| You can split the issues into several categories, and I don't know
| how ARIN can help with any of them.  First, in many cases no one
| can bother to contact the offending party.  Obviously their own
| upstream is a prime candidate to notice and contact the person in
| question.  If we can't get the major ISP's who have a clue, and
| have staff, and know the issues to make it a priority to contact
| the smaller players and help them along then I don't know what hope
| we have for some outside influence to make a difference.

I'm just being a typical punter here, however, I feel that issues
happening upstream should be reported or commented on upstream.
Folks in general should have a working relationship with their
next-hop up. I know this is often hearache and pain, but
it is rational. Top down enforcement is pretty much always
resented in pretty much all things.

| Second, when contacted, one of two things happen.  The parties often
| clean up their act simply by someone asking (the, "oops, I didn't
| know I was doing that" situation).

I'm pretty much a bottom feeder, I run a few small networks,
and when I do something that my users don't like, they let me
know and I often say "Oops". I think this scales.

|In the other cases, the response
| is often "I have a reason to do this and I'm not explaining it to
| you."  I suppose ARIN might be able to do something in the former
| case although I question if it is appropriate.  In the latter case,
| unless the industry as a whole takes a much stronger stance and
| imposes sanctions (eg, route filtering) then no one complaining
| will make a difference.

route filtering gets into some very dodgy ground pretty fast.
route filtering is tantamount to broad stroke censorship.

| Third, and most important, does anyone care?  We're not at a stage
| anymore where the routers are on the verge of falling over.  Other
| than a few complainers, it's not clear this issue impacts the day
| to day operation of anyone's network in a significant way.  Obviously
| there is the potential, if it gets worse it could get real bad real
| quick.  There seems to be a level of tolerance for slop in the
| system right now, and that's probably a good thing.
|
| So, I too question if ARIN is the right place.

Not so long ago, I was blaming ARIN for all the sins in the
world, 'till a college brought me up short and told me to
go to ARIN meetings and shutup and pay attention. ARIN is
"Us" in many ways, Having spent some time talking to those
who know better than I do about a lot of stuff, ARIN stuff
included, I realised that "we" bring a lot of this on ourselves
by thinking that our networks are somehow autonomous and don't
really exist as part of a whole. Our peering providers, immho,
should be the first place to address issues, and often many issues
can be resolved, or at least better comprehended by addressing
concernings straight upstream.

In short, if you are trying to fix things globally, get them
fixed locally, and the global issues will get resolved.

And, btw, where is the current best practice on this issue documented?

- --chipper

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCEfAC0STXFHxUucwRAv7gAJ0eTgEHYHm1ieI7cV8YYwEAc2SY0QCeOFl3
6jphhnl1rkBz3vpiw9rZ7d4=
=tBgF
-----END PGP SIGNATURE-----


From bruce.eastman at adelphia.com  Tue Feb 15 08:21:52 2005
From: bruce.eastman at adelphia.com (Bruce Eastman)
Date: Tue, 15 Feb 2005 08:21:52 -0500
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Cidr Report
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A76F@kronos.cait.wustl.edu>
Message-ID: <002c01c51361$4ffa0cf0$5e2012d1@deipadmin>

> Jon is right.  Deaggregation is not a laughing matter. Its poor management
> at least from a netizens point of view....


Well, the warning advisory in and of itself was meant to interject a little
humor, but the idea
was serious. ARIN submits an e-mail message to the customer, with each
allocation.
I think John's idea of adding a short paragraph and direction to a few links
was a very good
idea. I believe the message sent out with each allocation would be a good
place to add said
links and paragraph.

Bruce Eastman



----- Original Message ----- 
From: "Bill Darte" <billd at cait.wustl.edu>
To: "'Bruce Eastman '" <bruce.eastman at adelphia.com>; <owner-ppml at arin.net>;
<ppml at arin.net>
Sent: Monday, February 14, 2005 6:32 PM
Subject: RE: [ppml] Deaggregation in the ARIN region Was: [nanog] The Cidr
Report


> Jon is right.  Deaggregation is not a laughing matter. Its poor management
> at least from a netizens point of view....
>
> Still, you advisory below is a hoot!  I like it.
>
> Bill Darte
>
>
> Bruce Eastman said:
>
>
> Maybe ARIN should add a Warning label. :)
>
>
>
>
>
> WARNING - DANGER - READ THIS & HEED THIS!
>
>
>
> WARNING: THIS IS NOT A TOY. THIS IP IS DESIGNED FOR USE BY EXPERIENCED
> NETWORKING PERSONNEL AND IS INTENDED
>
>  FOR USE BY AN EXPERT IN ROUTING. THESE IP'S ARE INTENDED FOR USE SOLELY
> BY
> SENIOR NETWORK ENGINEER TYPES
>
> ( WITH NECESSARY SAFETY EQUIPMENT ). NO OTHER USE IS INTENDED OR
> RECOMMENDED. ILLEGAL TO OWN, PURCHASE OR
>
> TRANSFER BY ANYONE OTHER THAN ARIN OR OUTSIDE THE TERMS AFOREMENTIONED.
> MISUSE OR CARELESS USE MAY CAUSE
>
> SERIOUS ROUTING DEAGGREGATION. READ OWNERS MANUAL BEFORE USING.
>
>
>
>
>
> Bruce Eastman
> Senior IP Analyst
> Adelphia Communications
>
>
>
>
> ----- Original Message ----- 
> From: "Jon Lewis" <jlewis at lewis.org>
> To: "Andrew Dul" <andrew.dul at quark.net>
> Cc: <ppml at arin.net>
> Sent: Sunday, February 13, 2005 1:12 PM
> Subject: Re: [ppml] Deaggregation in the ARIN region Was: [nanog] The
> Cidr
> Report
>
>
> > On Sun, 13 Feb 2005, Andrew Dul wrote:
> >
> > > I was wondering if people in the ARIN region agreed with these
> statements
> > > about the ARIN region not doing enough to educate the membership
> about
> > > deaggregation, BGP annoucements etc...
> > >
> > > If ARIN were to do more what would you suggest?
> > >
> > > 1. More/Better online training
> > > 2. Regional Training session (similar to RIPE?)
> >
> > Whether or not ARIN actually did any training courses, it would be
> nice to
> > see some info on BCPs for BGP routing in the training section of the
> ARIN
> > web site rather than just "how to use whois" and "how to jump through
> the
> > hoops to get IP space".
> >
> > Too many networks deaggregate their announcements for no reason simply
> > because they don't realize there's any reason they shouldn't.
> >
> > Covering things like route filtering (i.e. not leaking provider A's
> routes
> > to provider B) would be nice.  Might even mention the use of routing
> > registries (radb, altdb, ARIN's own one, etc.).
> >
> > To make a bad analogy, right now, ARIN's like a gun shop selling guns
> with
> > no manuals and no safety literature.  Not everyone who's buying knows
> how
> > to use them safely.
> >
> > ----------------------------------------------------------------------
> >  Jon Lewis                   |  I route
> >  Senior Network Engineer     |  therefore you are
> >  Atlantic Net                |
> > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From paul.bradford at adelphiacom.net  Tue Feb 15 08:55:22 2005
From: paul.bradford at adelphiacom.net (Paul Bradford)
Date: Tue, 15 Feb 2005 08:55:22 -0500
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Cidr Report
Message-ID: <1108475722.27259.25.camel@agape.adelphiacom.net>


Maybe this all is just a result of different inefficient (IP Wise not $$
wise) network designs... like those that rely on upstream providers to
provide a "virtual" backbone for a company because they design thier
network to be discontiguous...  

Thanks,
Paul

On Tue, 2005-02-15 at 08:21 -0500, Bruce Eastman wrote:
> > Jon is right.  Deaggregation is not a laughing matter. Its poor management
> > at least from a netizens point of view....
> 
> 
> Well, the warning advisory in and of itself was meant to interject a little
> humor, but the idea
> was serious. ARIN submits an e-mail message to the customer, with each
> allocation.
> I think John's idea of adding a short paragraph and direction to a few links
> was a very good
> idea. I believe the message sent out with each allocation would be a good
> place to add said
> links and paragraph.
> 
> Bruce Eastman
> 
> 
> 
> ----- Original Message ----- 
> From: "Bill Darte" <billd at cait.wustl.edu>
> To: "'Bruce Eastman '" <bruce.eastman at adelphia.com>; <owner-ppml at arin.net>;
> <ppml at arin.net>
> Sent: Monday, February 14, 2005 6:32 PM
> Subject: RE: [ppml] Deaggregation in the ARIN region Was: [nanog] The Cidr
> Report
> 
> 
> > Jon is right.  Deaggregation is not a laughing matter. Its poor management
> > at least from a netizens point of view....
> >
> > Still, you advisory below is a hoot!  I like it.
> >
> > Bill Darte
> >
> >
> > Bruce Eastman said:
> >
> >
> > Maybe ARIN should add a Warning label. :)
> >
> >
> >
> >
> >
> > WARNING - DANGER - READ THIS & HEED THIS!
> >
> >
> >
> > WARNING: THIS IS NOT A TOY. THIS IP IS DESIGNED FOR USE BY EXPERIENCED
> > NETWORKING PERSONNEL AND IS INTENDED
> >
> >  FOR USE BY AN EXPERT IN ROUTING. THESE IP'S ARE INTENDED FOR USE SOLELY
> > BY
> > SENIOR NETWORK ENGINEER TYPES
> >
> > ( WITH NECESSARY SAFETY EQUIPMENT ). NO OTHER USE IS INTENDED OR
> > RECOMMENDED. ILLEGAL TO OWN, PURCHASE OR
> >
> > TRANSFER BY ANYONE OTHER THAN ARIN OR OUTSIDE THE TERMS AFOREMENTIONED.
> > MISUSE OR CARELESS USE MAY CAUSE
> >
> > SERIOUS ROUTING DEAGGREGATION. READ OWNERS MANUAL BEFORE USING.
> >
> >
> >
> >
> >
> > Bruce Eastman
> > Senior IP Analyst
> > Adelphia Communications
> >
> >
> >
> >
> > ----- Original Message ----- 
> > From: "Jon Lewis" <jlewis at lewis.org>
> > To: "Andrew Dul" <andrew.dul at quark.net>
> > Cc: <ppml at arin.net>
> > Sent: Sunday, February 13, 2005 1:12 PM
> > Subject: Re: [ppml] Deaggregation in the ARIN region Was: [nanog] The
> > Cidr
> > Report
> >
> >
> > > On Sun, 13 Feb 2005, Andrew Dul wrote:
> > >
> > > > I was wondering if people in the ARIN region agreed with these
> > statements
> > > > about the ARIN region not doing enough to educate the membership
> > about
> > > > deaggregation, BGP annoucements etc...
> > > >
> > > > If ARIN were to do more what would you suggest?
> > > >
> > > > 1. More/Better online training
> > > > 2. Regional Training session (similar to RIPE?)
> > >
> > > Whether or not ARIN actually did any training courses, it would be
> > nice to
> > > see some info on BCPs for BGP routing in the training section of the
> > ARIN
> > > web site rather than just "how to use whois" and "how to jump through
> > the
> > > hoops to get IP space".
> > >
> > > Too many networks deaggregate their announcements for no reason simply
> > > because they don't realize there's any reason they shouldn't.
> > >
> > > Covering things like route filtering (i.e. not leaking provider A's
> > routes
> > > to provider B) would be nice.  Might even mention the use of routing
> > > registries (radb, altdb, ARIN's own one, etc.).
> > >
> > > To make a bad analogy, right now, ARIN's like a gun shop selling guns
> > with
> > > no manuals and no safety literature.  Not everyone who's buying knows
> > how
> > > to use them safely.
> > >
> > > ----------------------------------------------------------------------
> > >  Jon Lewis                   |  I route
> > >  Senior Network Engineer     |  therefore you are
> > >  Atlantic Net                |
> > > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> 
> 





From memsvcs at arin.net  Tue Feb 15 12:06:03 2005
From: memsvcs at arin.net (Member Services)
Date: Tue, 15 Feb 2005 12:06:03 -0500 (EST)
Subject: [ppml] Policy Proposal 2005-1: Provider Independent IPv6 Assignments for
 End-sites
Message-ID: <Pine.GSO.4.51.0502151205140.10977@ops.arin.net>

ARIN welcomes feedback and discussion about the following policy
proposal in the weeks leading to the ARIN Public Policy Meeting
in Orlando scheduled for April 18-20, 2005.

According to the ARIN Internet Resource Policy Evaluation Process
the Advisory Council will evaluate policy proposals after the Public
Policy Meeting. The feedback and discussion of policy proposals
on the Public Policy Mailing List will be included in the AC's
evaluation.

The policy proposal text is below and can be found at:
http://www.arin.net/policy/2005_1.html

Subscription information for the ARIN Public Policy Mailing List can be
found at:
http://www.arin.net/mailing_lists/index.html

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/ipep.html

ARIN's Policy Proposal Archive can be found at:
http://www.arin.net/policy/proposal_archive.html

Regards,
Member Services Department
American Registry for Internet Numbers

===================================================================
Register for ARIN XV and NAv6TF Summit, April 17-21, 2005, Orlando, FL

                   http://www.arin.net/ARIN-XV/

   E-mail                             memsvcs at arin.net
   FTP                                ftp.arin.net
   WHOIS                              whois.arin.net
   Website                            http://www.arin.net
===================================================================

### * ###

Policy Proposal Name: Provider Independent IPv6 Assignments for End-sites

Author: Owen DeLong

Policy statement: to be added to NRPM Section 6, IPv6, a new sub-section:

6.11 Assignments to End-Sites with Autonomous System Numbers

Any end-site which meets the current criteria for assignment of an
autonomous system number (ASN) shall also qualify for one IPv6 prefix
assignment of the minimum size justified under the ARIN guidelines for
assignment by an LIR. If the organization grows to require more space, it
will not be entitled to an additional block, but rather may obtain a new,
replacement block of sufficient size to meet its needs in exchange for
making the commitment to return its existing block within 24 months, so
that it may be reassigned.

Rationale:

There is a legitimate and growing need for provider independent addressing
for end-site organizations. While there were and are technical reasons for
limiting this in the IPv4 world, they need to be solved in the IPv6 world,
or, we will not see widespread adoption of IPv6.

This policy does not promote extreme growth in the routing table, as it
would provide support for fewer than 70,000 IPv6 prefixes if every
organization that currently has an ASN were to get an assignment, grow,
and, be in the 24 month renumbering period. Realistically, it is
unreasonable to think that this policy would contribute even 10,000 routes
to the IPv6 table in the near term future.

This policy provides for reasonable IPv6 provider independent assignments
without creating a land-grab, explosive routing table growth, or a IPv6
swamp.

All such assignments under this policy shall be subject to the same
renewal criteria as IPv4 end-user assignments with a fee structure to be
set by ARIN in the usual and customary way.

Concerns were expressed about being able to reclaim this space and about a
land rush. Should an IPv6 land rush occur under this policy (an ASN land
rush would be required first), the ARIN BOT has emergency authority to
suspend this or any other policy in the interests of the internet with
appropriate review at the next public policy meeting. As to reclamation,
it is quite clear in the Registration Services Agreement:

4. Conditions of service ...
(d) Changes to Services. Applicant acknowledges and agrees that ARIN
fulfills a critical role in the continued evolution of the Internet and,
accordingly, ARIN may, in its sole and absolute discretion, change,
modify, suspend, or make improvements to any aspect of the Services,
temporarily or permanently, at any time without specific notice to
Applicant, and ARIN will not be liable for doing so. ARIN will have the
right from time to time to change the amount of the fees or institute new
fees relating to the Services, as set forth in Section 6, but such changes
to fees will only take effect upon the renewal of the Services.

Also, according to subsequent sections of the agreement, ARIN may simply
choose not to renew the agreement with 30 days notice to the applicant.
Either of these actions makes reclamation quite possible.



From billd at cait.wustl.edu  Tue Feb 15 14:55:21 2005
From: billd at cait.wustl.edu (Bill Darte)
Date: Tue, 15 Feb 2005 13:55:21 -0600
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Network Inter
	-Connectivity
Message-ID: <50C9C45A7E8DCE41A19F7A94715BABFD02A77B@kronos.cait.wustl.edu>

Hello,
Just a heads up prior to the April Public Policy and Member's Meetings
http://www.arin.net/ARIN-XV/agenda.html
<http://www.arin.net/ARIN-XV/agenda.html> 
There was quite a lot of discussion about Policy Proposal 2004-3 at the
prior meetings in Reston, Oct. 2004.
Much of that discussion revolved around the proposal being 'new' policy when
actually it was a clarification to existing policy and ARIN practice.  As
such, the following is available for your consideration.  Note that the new
wording of the proposal intends to supercede existing wording in the ARIN
Number Resource Policy Manual in sections identified below, but is
consistent with current ARIN practice.
Bill Darte
ARIN AC

Policy Proposal 2004-3: Global Addresses for Private Network
Inter-Connectivity
Policy statement: 
End-users not currently connected to an ISP and/or not planning to be
connected to the Internet are encouraged to use private IP address numbers
reserved for non-connected networks (see RFC 1918). When private,
non-connected networks require interconnectivity and the private IP address
numbers are ineffective, globally unique addresses may be requested and used
to provide this interconnectivity.

This text supersedes section 4.3.5 Non-connected Networks.
Rationale:

In order to provide clarification for current ARIN practice concerning the
use of Global Addresses for private network interconnectivity, the change
above to the ARIN Number Resource Policy Manual is proposed.

Current wording of Section 4.3.5 Non-connected Networks:
End-users not currently connected to an ISP and/or plan not to be connected
to the Internet are encouraged to use private IP numbers reserved for
non-connected networks (see RFC 1918 </library/rfc/rfc1918.txt>). 



From randy at psg.com  Tue Feb 15 16:31:00 2005
From: randy at psg.com (Randy Bush)
Date: Tue, 15 Feb 2005 11:31:00 -1000
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Network Inter
	-Connectivity
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77B@kronos.cait.wustl.edu>
Message-ID: <16914.27156.831857.425932@roam.psg.com>

> encouraged to use private IP address numbers

i do not believe the above phrase, in particular the word "encouraged,"
should occur anywhere

randy



From owen at delong.com  Tue Feb 15 17:01:38 2005
From: owen at delong.com (Owen DeLong)
Date: Tue, 15 Feb 2005 14:01:38 -0800
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private
 Network Inter	-Connectivity
In-Reply-To: <16914.27156.831857.425932@roam.psg.com>
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77B@kronos.cait.wustl.edu>
 <16914.27156.831857.425932@roam.psg.com>
Message-ID: <2147483647.1108476098@imac-en0.delong.sj.ca.us>

Why?


--On Tuesday, February 15, 2005 11:31 AM -1000 Randy Bush <randy at psg.com> 
wrote:

>> encouraged to use private IP address numbers
>
> i do not believe the above phrase, in particular the word "encouraged,"
> should occur anywhere
>
> randy
>



-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050215/68ccf560/attachment.sig>

From kc at caida.org  Tue Feb 15 18:14:55 2005
From: kc at caida.org (k claffy)
Date: Tue, 15 Feb 2005 15:14:55 -0800
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Cidr Report
In-Reply-To: <OF8EF6CD1A.D2BBB154-ON80256FA9.0035ACF8-80256FA9.003616A3@radianz.com>
References: <20050215010424.GA89128@ussenterprise.ufp.org> <OF8EF6CD1A.D2BBB154-ON80256FA9.0035ACF8-80256FA9.003616A3@radianz.com>
Message-ID: <20050215231455.GB74179@caida.org>

On Tue, Feb 15, 2005 at 09:50:47AM +0000, Michael.Dillon at radianz.com wrote:
  
  It is not ARIN's job to create a "best practice"
  document for Internet operations.

[naive but serious question from the academy:]
  
whose job is it?

[you guys know the fcc has heard about us now, right?]
k


From dgolding at burtongroup.com  Tue Feb 15 19:14:48 2005
From: dgolding at burtongroup.com (Daniel Golding)
Date: Tue, 15 Feb 2005 19:14:48 -0500
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The
 Cidr Report
In-Reply-To: <20050215231455.GB74179@caida.org>
Message-ID: <BE37FAA8.7EAA%dgolding@burtongroup.com>


Well, one possibility is the IETF through something like GROW.

In all seriousness, though, who is better qualified than ARIN to suggest
addressing best practices?

- Dan

On 2/15/05 6:14 PM, "k claffy" <kc at caida.org> wrote:

> On Tue, Feb 15, 2005 at 09:50:47AM +0000, Michael.Dillon at radianz.com wrote:
>   
>   It is not ARIN's job to create a "best practice"
>   document for Internet operations.
> 
> [naive but serious question from the academy:]
>   
> whose job is it?
> 
> [you guys know the fcc has heard about us now, right?]
> k



From randy at psg.com  Tue Feb 15 19:54:49 2005
From: randy at psg.com (Randy Bush)
Date: Tue, 15 Feb 2005 14:54:49 -1000
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Ne
	 twork Inter	-Connectivity
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77E@kronos.cait.wustl.edu>
Message-ID: <16914.39385.362506.334832@roam.psg.com>

> Randy, do you object to the term or the encouragement?

the encouragement.  private address space is a disease that
should not be officially encouraged in any way.

randy



From andrew.dul at quark.net  Tue Feb 15 21:58:23 2005
From: andrew.dul at quark.net (Andrew Dul)
Date: Tue, 15 Feb 2005 18:58:23 -0800
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private
  Network Inter-Connectivity
In-Reply-To: <16914.27156.831857.425932@roam.psg.com>
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77B@kronos.cait.wustl.edu>
Message-ID: <20050216030000.DDF3E1442D1@smtp2.arin.net>

At 11:31 AM 2/15/2005 -1000, Randy Bush wrote:
>> encouraged to use private IP address numbers
>
>i do not believe the above phrase, in particular the word "encouraged,"
>should occur anywhere
>

Maybe we should encourage people to use IPv6 in the policy    :)


From ahp at hilander.com  Tue Feb 15 22:48:01 2005
From: ahp at hilander.com (Alec H. Peterson)
Date: Tue, 15 Feb 2005 20:48:01 -0700
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Ne	
 twork Inter	-Connectivity
In-Reply-To: <16914.39385.362506.334832@roam.psg.com>
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77E@kronos.cait.wustl.edu>
 <16914.39385.362506.334832@roam.psg.com>
Message-ID: <6ED624BADE09BE78ABDCB817@Alec-Petersons-Computer.local>

--On February 15, 2005 14:54:49 -1000 Randy Bush <randy at psg.com> wrote:

>
> the encouragement.  private address space is a disease that
> should not be officially encouraged in any way.

I see.  Well, without trying to start up a good old fashioned flame war, 
could you elaborate on the rationale behind your opinion?  I'm quite 
certain there are people out there who don't want to question you for fear 
of a 'plonk'.  Fortunately, I've already been there and done that so I have 
no fear.

Thanks,

Alec, wearing his 'plonk me, oh please plonk me' t-shirt this evening



From ppml at rs.seastrom.com  Tue Feb 15 23:12:41 2005
From: ppml at rs.seastrom.com (Robert E.Seastrom)
Date: Tue, 15 Feb 2005 23:12:41 -0500
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private
 Network Inter-Connectivity
In-Reply-To: <20050216030000.DDF3E1442D1@smtp2.arin.net> (Andrew Dul's
 message of "Tue, 15 Feb 2005 18:58:23 -0800")
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77B@kronos.cait.wustl.edu>
	<20050216030000.DDF3E1442D1@smtp2.arin.net>
Message-ID: <87fyzxnnwm.fsf@valhalla.seastrom.com>


Andrew Dul <andrew.dul at quark.net> writes:

> At 11:31 AM 2/15/2005 -1000, Randy Bush wrote:
>>> encouraged to use private IP address numbers
>>
>>i do not believe the above phrase, in particular the word "encouraged,"
>>should occur anywhere
>>
>
> Maybe we should encourage people to use IPv6 in the policy    :)

While understanding that there are technical hurdles (particularly
certain network vendors who remain wishy-washy in their v6 support)
which stand in the way of implementation _today_, such barriers can be
expected to become slowly lower over time, and proposals should be
considered with an eye towards conditions next year and three years
from now as well as conditions next month..

I believe that we would be remiss in our stewardship duties if we did
not include language along the lines of "Applicants are reminded of
the comparatively finite nature of IPv4 address space and are
encouraged to consider substituting IPv6 in private networks to the
extent practicable" in any proposal that addresses globally unique
addresses for private networks.

We then need to put our money where our mouths are by vigorously
supporting private v6 space, but that's an argument for another
thread...

                                        ---Rob




From randy at psg.com  Tue Feb 15 23:19:43 2005
From: randy at psg.com (Randy Bush)
Date: Tue, 15 Feb 2005 18:19:43 -1000
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Network Inter	-Connectivity
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77E@kronos.cait.wustl.edu>
	<16914.39385.362506.334832@roam.psg.com>
	<6ED624BADE09BE78ABDCB817@Alec-Petersons-Computer.local>
Message-ID: <16914.51679.395846.958726@roam.psg.com>

this is arin, not some advice to the hacker group.  use of 1918
space is dangerous and can cause nasty surprises to pop up
years later.  see

    <http://rip.psg.com/~randy/040226.apnic-nats.pdf>.

folk who understand what they're getting into may choose to use
it.  heck, i do for part of my home networks, as my dsl isps are
stingy with address space.  and it causes pain via a number of
applications is breaks, e.g. sip/rtp.

but the rir's members are of all flavors, wise, newbies, ...  we
should not be directly *encouraging* use of a technique known to
be dangerous.  and lirs (kinda isps in the rest of the world)
have been known to seriously abuse this, e.g. a colonial ptt
forcing an in-country isp to use nat and a /27 for their entire
operation.  and the ptt will point to your *encourage* and
stonewall.

you can look at how apnic and ripe now phrase it.  i think it is
more "you may want to look at" or something.

randy



From owen at delong.com  Wed Feb 16 04:55:23 2005
From: owen at delong.com (Owen DeLong)
Date: Wed, 16 Feb 2005 01:55:23 -0800
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private
 Network Inter-Connectivity
In-Reply-To: <87fyzxnnwm.fsf@valhalla.seastrom.com>
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77B@kronos.cait.wustl.edu>
 	<20050216030000.DDF3E1442D1@smtp2.arin.net>
 <87fyzxnnwm.fsf@valhalla.seastrom.com>
Message-ID: <2147483647.1108518919@[172.17.1.152]>

Which of the myriad forms of private V6 space did you have in mind?
(I realize you say an argument for a different thread, but, since I think
that the current IETF proposal for theoretically private V6 space is
simply an end-run on registered address assignments, I think it is
important to settle the latter prior to encouraging the former.)

Owen


--On Tuesday, February 15, 2005 23:12 -0500 "Robert E.Seastrom" 
<ppml at rs.seastrom.com> wrote:

>
> Andrew Dul <andrew.dul at quark.net> writes:
>
>> At 11:31 AM 2/15/2005 -1000, Randy Bush wrote:
>>>> encouraged to use private IP address numbers
>>>
>>> i do not believe the above phrase, in particular the word "encouraged,"
>>> should occur anywhere
>>>
>>
>> Maybe we should encourage people to use IPv6 in the policy    :)
>
> While understanding that there are technical hurdles (particularly
> certain network vendors who remain wishy-washy in their v6 support)
> which stand in the way of implementation _today_, such barriers can be
> expected to become slowly lower over time, and proposals should be
> considered with an eye towards conditions next year and three years
> from now as well as conditions next month..
>
> I believe that we would be remiss in our stewardship duties if we did
> not include language along the lines of "Applicants are reminded of
> the comparatively finite nature of IPv4 address space and are
> encouraged to consider substituting IPv6 in private networks to the
> extent practicable" in any proposal that addresses globally unique
> addresses for private networks.
>
> We then need to put our money where our mouths are by vigorously
> supporting private v6 space, but that's an argument for another
> thread...
>
>                                         ---Rob
>
>



-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050216/f66c1000/attachment.sig>

From Michael.Dillon at radianz.com  Wed Feb 16 05:25:41 2005
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Wed, 16 Feb 2005 10:25:41 +0000
Subject: [ppml] Deaggregation in the ARIN region   Was: [nanog] The Cidr Report
In-Reply-To: <20050215231455.GB74179@caida.org>
Message-ID: <OF53EBBCAE.5CE34F36-ON80256FAA.00384856-80256FAA.0039488A@radianz.com>

> On Tue, Feb 15, 2005 at 09:50:47AM +0000, Michael.Dillon at radianz.com 
wrote:
> 
>   It is not ARIN's job to create a "best practice"
>   document for Internet operations.
> 
> [naive but serious question from the academy:]
> 
> whose job is it?
> 
> [you guys know the fcc has heard about us now, right?]

I would say that it's the IETF's job to PUBLISH a best practice
document but I'm not sure whether it is their job to create the
document. If NANOG were a real organization, I would place the
responsibility there, but since NANOG is not a real operators
organization, I think that the United States Telephone
Association is the closest thing that we have to a network
operators organization. In know for a fact that the FCC has heard
of the USTA. 

And then there is the ISP/C which merged with the CIX and ended
up somehow as the US ISPA http://www.cix.org/ but I have no idea
what, if anything, they do.

On second thought, now that NANOG is going to become some sort
of corporate entity with a board, perhaps we should have an
agenda item to discuss whether or not ARIN should urge NANOG to
publish an aggregation BCP via the IETF's RFC process.

NANOG has always been the meeting place for the network research
community, the network operations community and the network vendor
community (hardware and software). This formula has worked extremely
well in deploying the Internet over the last decade or so and I
think ARIN should support NANOG but not try to usurp any of the 
activities which rightly belong to the NANOG umbrella.

--Michael Dillon




From paul at vix.com  Wed Feb 16 09:44:18 2005
From: paul at vix.com (Paul Vixie)
Date: Wed, 16 Feb 2005 14:44:18 +0000
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Ne twork Inter -Connectivity 
In-Reply-To: Message from "Alec H. Peterson" <ahp@hilander.com> 
	of "Tue, 15 Feb 2005 20:48:01 MST."
	<6ED624BADE09BE78ABDCB817@Alec-Petersons-Computer.local> 
Message-ID: <20050216144418.CAC4513951@sa.vix.com>

i saw randy's comment...

> ...  private address space is a disease that
> should not be officially encouraged in any way.

...and i think i disagree.  the internet is a network of networks, and
if some of those networks prefer nonuniversal EIDs then that's autonomy
in action.  speaking as a rootop, i know that private/nonuniversal
address space is responsible for a huge share of my unanswerable queries,
and i wish we had better fences so that better fences could make better
neighbors.  but aside from the toxics leaching over the property line,
"private" address space is a strictly local, strictly autonomous issue,
and not a "disease" at all.

the second part of what randy said strikes me as right, though.  "private"
(to whom?) addresses ought not be officially encouraged.  i'm only saying,
these nonuniversal addresses should not be officiall discouraged, either.

background:

universality of EID's is quite expensive, both in overall internet
maintainability and by "encouraging" an economic model that favours
older and larger entities at the expense of newer and smaller ones.  we
cannot be seen kicking the crutches out from under enterprises who want
to limit their tithe, and avoid long term contracts with "the tiers",
and build their corner of "the internet" as a grid rather than pyramid.

even though i think it's insane that we use /48's for campuses and /64's
for LANs and that V6 will still have to reach swamp-equilibrium as part
of its success (if it succeeds), i have to say, i can imagine worse things.


From cpm at well.com  Wed Feb 16 10:29:04 2005
From: cpm at well.com (Chip Mefford)
Date: Wed, 16 Feb 2005 10:29:04 -0500
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Network
 Inter	-Connectivity
In-Reply-To: <16914.51679.395846.958726@roam.psg.com>
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77E@kronos.cait.wustl.edu>	<16914.39385.362506.334832@roam.psg.com>	<6ED624BADE09BE78ABDCB817@Alec-Petersons-Computer.local> <16914.51679.395846.958726@roam.psg.com>
Message-ID: <421366C0.4060709@well.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Randy Bush wrote:
| this is arin, not some advice to the hacker group.  use of 1918
| space is dangerous and can cause nasty surprises to pop up
| years later.  see
|
|     <http://rip.psg.com/~randy/040226.apnic-nats.pdf>.

Agreed in principal.

But the core issue remains. There are some of us out here
who are tiny, and must get by with (-also, another generally bad
idea, CIDRs- of) /26 or /28s or less.

What choice have we?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCE2a/0STXFHxUucwRApKGAKCAukhhtugUJVO/tBlQUDlUrCus0QCfeNaU
dsd66KGNwdZuINoRKRYsdVQ=
=S0vm
-----END PGP SIGNATURE-----


From memsvcs at arin.net  Wed Feb 16 11:29:42 2005
From: memsvcs at arin.net (Member Services)
Date: Wed, 16 Feb 2005 11:29:42 -0500 (EST)
Subject: [ppml] Proposed Policy: Directory Services Overhaul
Message-ID: <Pine.GSO.4.51.0502161128590.27208@ops.arin.net>

ARIN received the following proposed policy.  In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being posted
to the ARIN Public Policy Mailing List and being placed on ARIN's website.

The ARIN Advisory Council will review the proposal and within ten working
days may decide to:
1)  support the proposal as is,
2)  work with the author to clarify, divide or combine one or more policy
proposals, or
3)  not support the policy proposal.

If the AC supports the proposal or reaches an agreement to work with the
author, then the proposal will be posted as a formal policy proposal to
the Public Policy Mailing List and it will be presented at the Public
Policy Meeting.  If the AC does not support the proposal, then the author
may elect to use the petition process to advance the proposal. If the
author elects not to petition or the petition fails, then the proposed
policy will be considered closed.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/ipep.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/index.html

Regards,
Member Services Department
American Registry for Internet Numbers

===================================================================
Register for ARIN XV and NAv6TF Summit, April 17-21, 2005, Orlando, FL

                   http://www.arin.net/ARIN-XV/

   E-mail                             memsvcs at arin.net
   FTP                                ftp.arin.net
   WHOIS                              whois.arin.net
   Website                            http://www.arin.net
===================================================================

### * ###

Policy Proposal Name: Directory Services Overhaul

Author: Leo Bicknell

Policy term: permanent

Policy statement:

Replace all of section three with the following rewrite.

3 Directory Services

  3.1 ARIN Directory Services Databases

     The ARIN Public Information Database (APID) is a collection
     of information created and collected by ARIN during the due
     course of business which the ARIN membership has deemed public
     information and decided to publish.

     The ARIN Confidential Information Database (ACID) is a collection
     of information created and collected by ARIN during the due course
     of business which the ARIN membership has deemed is confidential
     information that should be kept under a strict privacy policy.

  3.2 Directory Information Made Public

     ARIN shall publish verified contact information and the
     resource(s) allocated (including identification for that
     allocation, like date of allocation or other information
     identified by ARIN) in the APID in the following cases:

         - All resources delegated by ARIN.
	 - If allowed by the parent delegation, and requested by
	   the contact listed with the parent, a subdelegation of a
	   resource.

     ARIN shall insure all contact information in the APID is
     verified from time to time and is correct to the best of ARIN's
     ability.  ARIN staff shall maintain verification criteria and
     post it on the ARIN web site.

     3.2.1 Non-Responsive Contacts

       If ARIN is unable to verify contact information via the normal
       verification procedure ARIN shall attempt to notify the parent
       of the resource to have the information updated.  If there is
       no parent, or if the data is not corrected in a reasonable
       amount of time the resource shall be SUSPENDED.

       Once the resource is suspended ARIN shall make one more request
       of all contacts listed with the resource and the parent resource
       (if available), and if no response is received in a reasonable
       amount of time the resource shall be reclaimed.

       Third parties may report the inability to make contact with a
       party via information in the APID.  In this case ARIN shall
       attempt the contact verification procedure for that contact
       immediately.  If a response is received, ARIN should document
       that a problem occurred, and the response from the resource
       holder.  Offenders who fail to respond to third parties more
       than 4 times per month for three months may have their resources
       reclaimed at the discretion of ARIN staff.

       If a third party submits reports of the inability to make contact
       that are subsequently disproven, ARIN may choose to ignore reports
       from specific companies, people, e-mail addresses, or any other
       classification means as appropriate.

       The ARIN staff shall publish the time thresholds and procedural
       details to implement this policy on the ARIN web site.

       If a resource is reclaimed under no circumstances shall the
       holder of that resource be entitled to a refund of any fees.

  3.3 Data Distribution

     3.3.1 Methods of Access

       ARIN shall publish the APID in the following methods using
       industry standard practices:

           - Via the WHOIS protocol.
           - Via a query form accessible via the HTTP protocol.
           - Via FTP to users who complete the bulk data form.
           - Via CDROM to users who complete the bulk data form.
           - Via the RWHOIS protocol.

     3.3.1.1 Outside Sources

       ARIN may refer a query to a outside source (for instance via
       RWHOIS or HTTP redirect).  Outside sources must:

       1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff.
       2 Meet the requirements in section 3.3.3.
       3 Support the applications in section 3.3.1.
       4 Prohibit the applications in section 3.3.2.

     3.3.2 Acceptable Usage Policy

       All data provided shall be subject to an AUP.  The AUP shall
       be written by ARIN staff and legal and posted on the ARIN website.
       ARIN may require a signed copy of the AUP before providing
       bulk data.

     3.3.3 Requirements for Internet Accessible Services

       For any method of access which is provided in real time via the
       Internet the following requirements must be met:

	 * The distributed information service must be operational
	   24 hours a day, 7 days a week to both the general public
	   and ARIN staff.  The service is allowed reasonable
	   downtime for server maintenance according to generally
	   accepted community standards.

	 * The distributed information service must allow public
	   access to reassignment information. The service may
	   restrict the number of queries allowed per time interval
	   from a host or subnet to defend against DDOS attacks,
	   remote mirroring attempts, and other nefarious acts.

         * The distributed information service must return current
           information.

  3.4 Distribution of the ARIN Public Information Database

      3.4.1 Supported Uses

        ARIN shall make the APID available for the following uses
        (supported uses):

          1 ARIN's use in implementing ARIN policies and other
            business.
          2 Community verification, allowing members of the community
            to confirm the proper users of the various resources ARIN
            controls.
          3 Statistic gathering by ARIN and third parties on resource
            utilization.
          4 As a contact database to facilitate communication with the
            person or entity responsible for a particular resource.

      3.4.2 Prohibited Uses

        ARIN prohibits the use of the APID for the following uses:

          1 Sending any unsolicited commercial correspondence advertising
            a product or service to any address (physical or electronic)
            listed in the APID.
          2 Using data in the APID to facilitate violating any state,
            federal, or local law.

      3.4.3 Other Uses

        ARIN shall allow all non-prohibited uses of the APID, however
        unless those uses are listed as a supported use the data set
        may be changed in such a way as to render them ineffective,
        or they may be blocked outright as deemed necessary by ARIN
        staff.  Users of applications not listed who are concerned
        that they are supported should introduce a proposal to add
        their application to the supported list.

  3.5 Distribution of the ARIN Confidential Information Database

    ARIN Staff shall use industry standard procedures to prevent
    the distribution of any data in the ARIN Confidential Information
    Database.

  3.6 Implementation Details

    ARIN Staff shall document all implementation specific details for
    directory services in a single document available on the web site.
    The document must contain, but is not limited to:

      - Database field definitions.
      - Update procedures.
      - Templates.
      - Points of contact.
      - Copies of the AUP.
      - Verification procedures.

  3.7 [Routing Registry] Copy Verbatim from the existing 3.4.

Section 4.2.3.7.4: Replace with:

  All reassignment information for current blocks shall be submitted to
  ARIN prior to submitting a request for a new allocation.

Section 4.2.3.7.6: Strike.

   8. Rationale:

Various proposals affecting directory services have come and gone in the
last 5 years leaving the policy affecting directory services fragemented.
Also during that time deployments and laws have changed.  Several large
DSL and cable providers now offer subnets to residential customers that
may require them to be registered with ARIN.  Several laws have been
passed that may restrict the personal information that can be published.
This proposal attempts to provide a unified policy that is easier to
understand, and is updated to deal with these new issues.

Timetable for implementation: 6-18 months, depending on staff
impact.


From andrew.dul at quark.net  Wed Feb 16 11:31:08 2005
From: andrew.dul at quark.net (Andrew Dul)
Date: Wed, 16 Feb 2005 16:31:08 +0000
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Network Inter -Connectivity
Message-ID: <20050216163108.12473.qmail@hoster908.com>

Chip Mefford <cpm at well.com> wrote: 
> Randy Bush wrote:
> | this is arin, not some advice to the hacker group.  use of 1918
> | space is dangerous and can cause nasty surprises to pop up
> | years later.  see
> |
> |     <http://rip.psg.com/~randy/040226.apnic-nats.pdf>.
> 
> Agreed in principal.
> 
> But the core issue remains. There are some of us out here
> who are tiny, and must get by with (-also, another generally bad
> idea, CIDRs- of) /26 or /28s or less.
> 
> What choice have we?

So what is preventing you from requesting a larger block from your upstream (or ARIN if you have a large enough network) to include the addresses that you currently NAT?  Is it economic?  ie. the recurring cost your current upstream "charges" for additional address space?  or  the cost of readdressing?  Something else?

Andrew   


From randy at psg.com  Wed Feb 16 12:24:17 2005
From: randy at psg.com (Randy Bush)
Date: Wed, 16 Feb 2005 07:24:17 -1000
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Network
 Inter	-Connectivity
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77E@kronos.cait.wustl.edu>
	<16914.39385.362506.334832@roam.psg.com>
	<6ED624BADE09BE78ABDCB817@Alec-Petersons-Computer.local>
	<16914.51679.395846.958726@roam.psg.com>
	<421366C0.4060709@well.com>
Message-ID: <16915.33217.741349.833598@roam.psg.com>

>> this is arin, not some advice to the hacker group.  use of 1918
>> space is dangerous and can cause nasty surprises to pop up
>> years later.  see
>>
>>     <http://rip.psg.com/~randy/040226.apnic-nats.pdf>.
> 
> Agreed in principal.
> 
> But the core issue remains. There are some of us out here
> who are tiny, and must get by with (-also, another generally bad
> idea, CIDRs- of) /26 or /28s or less.
> 
> What choice have we?

somehow you seem to only receive or read the top ten lines of
messages.  check your mta and mua.

i did not propose to remove rfc 1918, forbid use of 1918 address
space, ...  i even admitted that i do so in the privacy of my own
homes.

what i said was that we, arin, should not "encourage" it.

randy



From L.Howard at stanleyassociates.com  Wed Feb 16 12:45:13 2005
From: L.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Wed, 16 Feb 2005 12:45:13 -0500
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Ne
	twork Inter	-Connectivity
Message-ID: <DA3C0F2741E221419875800F2BC52DDB0488DF1A@SANT2>

>From Bill's original message:
End-users not currently connected to an ISP and/or not planning to be
connected to the Internet 
are encouraged to use private IP address numbers reserved for non-connected
networks (see RFC 1918).


>From your notes, it looks like you object to NAT, not a specific set of
integers.  Using 
private addresses on private networks does not imply NAT.

Bill's message included an excerpt of current policy, which says:
End-users not currently connected to an ISP and/or plan not to be connected
to the Internet 
are encouraged to use private IP numbers reserved for non-connected networks
(see RFC 1918 
</library/rfc/rfc1918.txt>). 

Do you object to current policy, proposed policy, or everything?

Lee

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> Behalf Of Randy Bush
> Sent: Tuesday, February 15, 2005 11:20 PM
> To: Alec H. Peterson
> Cc: ppml at arin.net
> Subject: RE: [ppml] Policy Proposal 2004-3 Global Addresses 
> for Private Network Inter -Connectivity
> 
> 
> this is arin, not some advice to the hacker group.  use of 
> 1918 space is dangerous and can cause nasty surprises to pop 
> up years later.  see
> 
    <http://rip.psg.com/~randy/040226.apnic-nats.pdf>.

folk who understand what they're getting into may choose to use it.  heck, i
do for part of my home networks, as my dsl isps are stingy with address
space.  and it causes pain via a number of applications is breaks, e.g.
sip/rtp.

but the rir's members are of all flavors, wise, newbies, ...  we should not
be directly *encouraging* use of a technique known to be dangerous.  and
lirs (kinda isps in the rest of the world) have been known to seriously
abuse this, e.g. a colonial ptt forcing an in-country isp to use nat and a
/27 for their entire operation.  and the ptt will point to your *encourage*
and stonewall.

you can look at how apnic and ripe now phrase it.  i think it is more "you
may want to look at" or something.

randy


From randy at psg.com  Wed Feb 16 12:51:19 2005
From: randy at psg.com (Randy Bush)
Date: Wed, 16 Feb 2005 07:51:19 -1000
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Ne
	twork Inter	-Connectivity
References: <DA3C0F2741E221419875800F2BC52DDB0488DF1A@SANT2>
Message-ID: <16915.34839.931902.628889@roam.psg.com>

in the long run, many networks which did not plan to be connected
to the internet become so.  and the resulting mess is not pretty.
which is why 1918 was written.  otherwise, why should they not use
any arbitrary address space?

randy



From cpm at well.com  Wed Feb 16 14:06:52 2005
From: cpm at well.com (Chip Mefford)
Date: Wed, 16 Feb 2005 14:06:52 -0500
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Network
 Inter -Connectivity
In-Reply-To: <20050216163108.12473.qmail@hoster908.com>
References: <20050216163108.12473.qmail@hoster908.com>
Message-ID: <421399CC.70201@well.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andrew: (all)

Andrew Dul wrote:
| Chip Mefford <cpm at well.com> wrote:
|
|>Randy Bush wrote:
|>| this is arin, not some advice to the hacker group.  use of 1918
|>| space is dangerous and can cause nasty surprises to pop up
|>| years later.  see
|>|
|>|     <http://rip.psg.com/~randy/040226.apnic-nats.pdf>.
|>snip
|>who are tiny, and must get by with (-also, another generally bad
|>idea, CIDRs- of) /26 or /28s or less.
|>
|>What choice have we?
|
| So what is preventing you from requesting a larger block from your
| upstream (or ARIN if you have a large enough network) to include the
addresses that
| you currently NAT?  Is it economic?  ie. the recurring cost your
current upstream
|"charges" for additional address space?  or  the cost of readdressing?
  Something else?

Principally economic. I'm a small guy, and I know it, and so does my
upstream (at&t).
I could do pretty well on a /24, but had to cry to get a /26. They only
want to hand out /28s and have folks use NAT. Further, they don't want
to see virtual IP hosts, (which makes ssl hosting kinda tricky).
Were I large enough for /20, I could probably afford it. But I'm a "Free
Community Wireless ISP" and as such, don't have a lot of clout, and my
cash flow is primarily derived from other kind community members, and
my day job.

Now, I could take this opportunity to whine about certain commercial
organizations squatting on /8s for no good reason other than being
around for a while, but that wouldn't really be constructive.

Nor would stating that despite media frenzy and panic to the contrary,
there is plenty of ip address space, a great deal of which is completely
wasted.

But I did it anyway.

I started doing nat/masq at my day job 9 years ago, when economic
reality and growth forced me to move from a 28.8 dial-up with a /24 from
uunet, to a 56k frame from psi (heh) with a /28 because it was
cost-equivalent. And a /28 was all psi was willing to give up without a
huge (and recurring) surcharge.

So, that's life.
It's not what I would choose, but there are a lot of us out
here and this is how we deal with it. But you know that.

| Andrew

- --chipper
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCE5nM0STXFHxUucwRAg6HAJ9xM/iZ/y1QddnPMy4da3nz+0oBfgCfdMaP
FmrbAKlBFBPUJSAu2ypAmdA=
=L2Nx
-----END PGP SIGNATURE-----


From cpm at well.com  Wed Feb 16 14:45:18 2005
From: cpm at well.com (Chip Mefford)
Date: Wed, 16 Feb 2005 14:45:18 -0500
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Network
 Inter	-Connectivity
In-Reply-To: <16915.33217.741349.833598@roam.psg.com>
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77E@kronos.cait.wustl.edu>	<16914.39385.362506.334832@roam.psg.com>	<6ED624BADE09BE78ABDCB817@Alec-Petersons-Computer.local>	<16914.51679.395846.958726@roam.psg.com>	<421366C0.4060709@well.com> <16915.33217.741349.833598@roam.psg.com>
Message-ID: <4213A2CE.7010002@well.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Randy;

Randy Bush wrote:
|>>this is arin, not some advice to the hacker group.  use of 1918
|>>space is dangerous and can cause nasty surprises to pop up
|>>years later.  see
|>>
|>>    <http://rip.psg.com/~randy/040226.apnic-nats.pdf>.
|>
|>Agreed in principal.
|>
|>But the core issue remains. There are some of us out here
|>who are tiny, and must get by with (-also, another generally bad
|>idea, CIDRs- of) /26 or /28s or less.
|>
|>What choice have we?
|
| somehow you seem to only receive or read the top ten lines of
| messages.  check your mta and mua.

No, believe it or not, I actually do read the whole thing.
But I only reply to the bits I have some issue with, be
that comment, controversy, or whatever.

| i did not propose to remove rfc 1918, forbid use of 1918 address
| space, ...

No, of course not. I'm sorry if I somehow implied that you did.
Wasn't my intention.

| what i said was that we, arin, should not "encourage" it.

It's a bit funny for me to say "we, arin" but I suppose
in some sense, I am too. I have been to meetings, and
I did pay attention.

That said, non rfc-1918 address space (hows that for backwards
thinking?) isn't the easiest thing for us small guys to have allocated
to us. We are dependent on our upstreams, who often in turn are
dependent on their upstreams who love to consider their allocations
as inventory that is saleable. I don't really blame them.

We, ARIN, are completely cool about direct allocation. But I don't
need a /20, and certainly cannot afford one. And even if I could,
it would be a waste. (like a lot of the /8s, and for that matter
a number of the /16s as well).
We, ARIN (I'm starting to like that) may feel that we shouldn't
encourage the use of rfc-1918 for internet-worked networks, but
it is a fact of life, and will remain so.
We, ARIN, already encourage ISPs to use netblocks as
small as /29, (and smaller) and do encourge SWIPing those blocks, all of
which makes sense. However, by recognising netblocks above /24, we are
almost implying those downstream are going to be using rfc-1918
addresses, and as such, perhaps we should be suggesting or at least
actively participating in how those networks can be best utilized
for the good of all.

I'm rambling, and I apologize for that.
I'll go back to lurking now.

Thanks for your time/input.

| randy
|
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCE6LO0STXFHxUucwRArtVAJ9fhNg36oOnBA/IyCZxhTXQkLaS8wCfcH8a
noZytZ9VlsnYaCqqp+6P2is=
=XGlk
-----END PGP SIGNATURE-----


From kurtis at kurtis.pp.se  Thu Feb 17 02:51:21 2005
From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist)
Date: Thu, 17 Feb 2005 08:51:21 +0100
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Network Inter	-Connectivity
In-Reply-To: <16914.51679.395846.958726@roam.psg.com>
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77E@kronos.cait.wustl.edu> <16914.39385.362506.334832@roam.psg.com> <6ED624BADE09BE78ABDCB817@Alec-Petersons-Computer.local> <16914.51679.395846.958726@roam.psg.com>
Message-ID: <B6B44BAE-80B8-11D9-B8A2-000A95928574@kurtis.pp.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 2005-02-16, at 05.19, Randy Bush wrote:

> you can look at how apnic and ripe now phrase it.  i think it is
> more "you may want to look at" or something.

I think it is even just a question "Have you considered?", which I 
think is more fair. I tend to agree with Randy. Being a non-native to 
the language, "encourage" to me reads as if we know that one technology 
is more superior to the other, while in reality the other way around 
holds.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBQhRNAKarNKXTPFCVEQLeeACg111RAY5zwMvl+PyEa38mWkZ02QkAn0Lq
agEBmbBBAtk8l3WUdu0K9cnd
=v8rq
-----END PGP SIGNATURE-----



From leo at ripe.net  Thu Feb 17 03:16:55 2005
From: leo at ripe.net (leo vegoda)
Date: Thu, 17 Feb 2005 09:16:55 +0100
Subject: [ppml] Policy Proposal 2004-3 Global Addresses for Private Network
 Inter	-Connectivity
In-Reply-To: <B6B44BAE-80B8-11D9-B8A2-000A95928574@kurtis.pp.se>
References: <50C9C45A7E8DCE41A19F7A94715BABFD02A77E@kronos.cait.wustl.edu> <16914.39385.362506.334832@roam.psg.com> <6ED624BADE09BE78ABDCB817@Alec-Petersons-Computer.local> <16914.51679.395846.958726@roam.psg.com> <B6B44BAE-80B8-11D9-B8A2-000A95928574@kurtis.pp.se>
Message-ID: <421452F7.1070907@ripe.net>

Hi,

Kurt Erik Lindqvist wrote:

[...]

>>you can look at how apnic and ripe now phrase it.  i think it is
>>more "you may want to look at" or something.
> 
> I think it is even just a question "Have you considered?", which I 
> think is more fair. I tend to agree with Randy. Being a non-native to 
> the language, "encourage" to me reads as if we know that one technology 
> is more superior to the other, while in reality the other way around 
> holds.

The RIPE IPv4 policy document has the following text on private address
space and NATs:

    Some address ranges are set aside for the operation of private IP
    networks. Anyone may use these addresses in their private networks
    without registration or co-ordination. Hosts using these addresses
    cannot directly be reached from the Internet. Such connectivity is
    enabled by using the technique known as Network Address Translation
    (NAT). Private addresses restrict a network so that its hosts only
    have partial Internet connectivity. Where full Internet connectivity
    is needed, unique, public addresses should be used.

    For a detailed description of ?Address Allocation for Private
    Internets? and the actual ranges of addresses set aside for that
    purpose, please refer to RFC 1918 found at:
    ftp://ftp.ripe.net/rfc/rfc1918.txt

    For information on the ?Architectural Implications of NAT?, please
    refer to RFC 2993, found at:
    ftp://ftp.ripe.net/rfc/rfc2993.txt

It's possible that improvements to the RIPE text could also be made.

Regards,

-- 
leo vegoda
RIPE NCC
Registration Services Manager



From memsvcs at arin.net  Thu Feb 17 13:04:19 2005
From: memsvcs at arin.net (Member Services)
Date: Thu, 17 Feb 2005 13:04:19 -0500 (EST)
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4 allocations
Message-ID: <Pine.GSO.4.51.0502171301420.29210@ops.arin.net>

ARIN received the following proposed policy.  In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being posted
to the ARIN Public Policy Mailing List and being placed on ARIN's website.

The ARIN Advisory Council will review the proposal and within ten working
days may decide to:
1)  support the proposal as is,
2)  work with the author to clarify, divide or combine one or more policy
proposals, or
3)  not support the policy proposal.

If the AC supports the proposal or reaches an agreement to work with the
author, then the proposal will be posted as a formal policy proposal to
the Public Policy Mailing List and it will be presented at the Public
Policy Meeting.  If the AC does not support the proposal, then the author
may elect to use the petition process to advance the proposal. If the
author elects not to petition or the petition fails, then the proposed
policy will be considered closed.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/ipep.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/index.html

Regards,
Member Services Department
American Registry for Internet Numbers

===================================================================
Register for ARIN XV and NAv6TF Summit, April 17-21, 2005, Orlando, FL

                   http://www.arin.net/ARIN-XV/

   E-mail                             memsvcs at arin.net
   FTP                                ftp.arin.net
   WHOIS                              whois.arin.net
   Website                            http://www.arin.net
===================================================================

### * ###

Policy Proposal Name: Adding an HD ratio choice for new IPv4 allocations

Author: Michael Dillon

Policy term: permanent

Policy statement:
That section 4.2.4.1 of the NPRM (Number Policy Resource Manual) be
replaced with the following text:

4.2.4.1. Utilization Efficiency

ISPs must have efficiently utilized all previous allocations in order to
receive additional space. This includes all space reassigned to their
customers. The reassignment information section of the ARIN ISP Network
Request Template should be completed for all address blocks that have been
allocated to your organization. In the template, line 1b. Assigned:
information will be verified via SWIP/RWHOIS and 1c. Reserved: should be
used to indicate internal network information. Please note that until your
prior utilization is verified to meet the requirements of section 4.2.4.1
and its subsections, ARIN can neither process nor approve a request for
additional addresses.

4.2.4.1.1. Capping the Utilization Percentage - In no case will an
organization be required to show greater than 80% utilization of their
most recent allocation.

4.2.4.1.2.  Electing the use of HD Ratio - Any organization whose total
IPv4 allocation is equivalent to a /20 or more may choose to have
additional requests for IPv4 addresses evaluated using an HD (Host
Density) Ratio calculation to determine sufficient utilization instead of
a fixed percentage threshold.

4.2.4.1.3. Simplified HD Ratio table - When electing to use the HD ratio
calculation, the applicant may elect to use these simplified tables rather
than calculating the actual ratios:

Total Alloc.    Total Perc.
<  /20               80%
>= /20 and < /18     75%
>= /18 and < /16     70%
>= /16 and < /14     66%
>= /14 and < /12     62%
>= /12 and < /10     59%
>= /10               55%

Recent Alloc.   Recent Perc.
<  /19               56%
>= /19 and < /18     51%
>= /18 and < /17     49%
>= /17 and < /16     46%
>= /16 and < /15     44%
>= /15 and < /14     42%
>= /14               40%

In these tables the percentage columns refer to the percentage utilization
of the address block represented by the first column.

4.2.4.1.3. HD ratio threshold for all previous allocations - All requests
for additional IPv4 address space subject to the HD Ratio shall require
the efficient utilization of the sum total of all existing IPv4
allocations. The HD Ratio on the sum total of all existing IPv4
allocations must be greater than or equal to .966.

4.2.4.1.4. HD ratio threshold for the most recent allocation - In
addition, the HD ratio of the most recent IPv4 allocation must be greater
than or equal to .930.

4.2.4.1.5. HD ratio calculation defined - The HD ratio is calculated as
log(utilized IPv4 addresses) divided by log(total addresses in all
previous IPv4 allocations). In this formula, log refers to the natural
logarithm.

Rationale:

The existing fixed 80% threshold does not recognize that address
management efficiency decreases for large address blocks and imposes an
unreasonable management overhead on larger organizations. The HD ratio
floating threshold makes allowance for hierarchical management. As
hierarchy increases in a network, the need for maintaining spare addresses
in a larger number of address blocks requires an ISP to have a lower
overall utilization rate for addresses. This effect is caused by both
increasing depth in addressing hierarchy and the increased breadth enabled
by the deeper hierarchy, e.g. larger number of PoPs. We cannot measure
depth and breadth of hierarchy directly so we approximate this by
measuring the total quantity of IP addresses allocated to the ISP.

The existing fixed threshold imposes a limited growth rate on larger ISPs
which is inconsistent with restraint of trade legislation in USA, Canada
and other countries. This growth rate limit has been masked in previous
years by two factors. One is that many, many new ISPs were starting up and
therefore the growth of the Internet was not limited by the growth rate of
a single company. The second factor is that in the recent past, many
companies experienced shrinkage and churn. When the growth of new business
required new IP addresses, they could either apply to ARIN or mine the
required addresses from these churned customers. Today we have a situation
where many companies have cleaned up their internal inefficiencies and the
Internet is growing once again, but the number of independent network
operators is much reduced. There is a real danger that the fixed threshold
imposed by ARIN will, in fact, limit the ability of one or more network
operators to grow their Internet services.

This limiting effect kicks in when an organization's rate of growth
exceeds their 6 month predictions and the time required to run internal
network change management processes is longer than the time required to
use up the last 20% of their most recent allocation. The Internet has
become a critical infrastructure in the world economy and prudent network
management practices require that any change to a network should be
checked, tested and carefully rolled out during narrow change windows
which may be as little as 20 hours per week. Many smaller networks who do
not provide mission critical network services can accommodate the fixed
threshold with little problems. However, ARIN's policies apply to all
organizations in the region regardless of business model, it is important
for these policies to allow a variety of business models to compete on a
level playing field.

Because this requires ISP to make fundamental changes in their addressing
process it is made entirely optional. There are three possibilities. An
ISP can do everything in the same way as they always have and 4.2.4.1.1
ensures that they continue to adhere to ARIN's policies. An ISP can elect
to apply the HD ratio to their address management systems by using the
percentage tables from 4.2.4.1.3. At any point in time an ISP needs to be
concerned with only two table entries, and this should be easy to
incorporate into percentage-based management systems. Or, an ISP can elect
to implement the HD ratio formula into their management systems and use
the same framework for both IPv6 and IPv4 allocations.

RIPE will be discussing a similar proposal from Alain Bidron of France
Telecom at their meeting in Stockholm May 2 - 6, 2005. In Europe, the
largest ISPs are telecom companies and are members of the ETNO (European
Telecom Network Operators Association). The ETNO has recently published an
expert opinion document in which they strongly support applying the HD
ratio to IPv4 addresses. This document is available in PDF format at this
URL
<http://www.etno.be/pp/EC064%20-%20NANI%20EC%20on%20IPv4%20AD%20ratio.pdf>.

The HD ratio was proposed as a way to determine allocation usage
thresholds for IPv6 address allocations. For more details on this, please
refer to RFC 3194 <http://www.faqs.org/rfcs/rfc3194.html>. There is some
detailed background discussion about applying the HD ratio to IPv4
allocations in a proposal by Paul Wilson posted to the APNIC mailing list
on Aug 7, 2003
http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/msg00000.html
and he made a presentation of this to last year's RIPE 48 meeting in
Amsterdam. PDF slides of his presentation are here
<http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-hd-ratio.pdf>.
Paul and some others use the term 'AD ratio' to refer to the HD ratio when
it is applied to IPv4 addresses. I have kept the original term used in
ARIN's IPv6 policy for the sake of simplicity.

Timetable for implementation: 30 days after ratification by the board


From memsvcs at arin.net  Thu Feb 17 13:10:41 2005
From: memsvcs at arin.net (Member Services)
Date: Thu, 17 Feb 2005 13:10:41 -0500 (EST)
Subject: [ppml] Proposed Policy: Lame Delegations in IN-ADDR.ARPA
Message-ID: <Pine.GSO.4.51.0502171309280.29210@ops.arin.net>

ARIN received the following proposed policy.  In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being posted
to the ARIN Public Policy Mailing List and being placed on ARIN's website.

The ARIN Advisory Council will review the proposal and within ten working
days may decide to:
1)  support the proposal as is,
2)  work with the author to clarify, divide or combine one or more policy
proposals, or
3)  not support the policy proposal.

If the AC supports the proposal or reaches an agreement to work with the
author, then the proposal will be posted as a formal policy proposal to
the Public Policy Mailing List and it will be presented at the Public
Policy Meeting.  If the AC does not support the proposal, then the author
may elect to use the petition process to advance the proposal. If the
author elects not to petition or the petition fails, then the proposed
policy will be considered closed.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/ipep.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/index.html

Regards,
Member Services Department
American Registry for Internet Numbers

===================================================================
Register for ARIN XV and NAv6TF Summit, April 17-21, 2005, Orlando, FL

                   http://www.arin.net/ARIN-XV/

   E-mail                             memsvcs at arin.net
   FTP                                ftp.arin.net
   WHOIS                              whois.arin.net
   Website                            http://www.arin.net
===================================================================

### * ###

Policy Proposal Name: Lame Delegations in IN-ADDR.ARPA

Author: Paul Andersen on behalf of the ARIN AC

Policy Term: Permanent

Policy statement: This policy proposal replaces section 7.2 of the ARIN
NRPM.

ARIN will actively identify lame DNS name server(s) for in-addr.arpa
delegations associated with address blocks allocated, assigned or
administered by ARIN. Upon identification of a lame delegation, ARIN shall
attempt to contact the POC for that resource and resolve the issue.  If,
following due diligence, ARIN is unable to resolve the lame delegation,
ARIN will update the WHOIS database records resulting in the removal of
lame servers.

Rationale:  The policy as stated could not be implemented without placing
an undue burden on ARIN staff resources.  The procedures mandated in the
policy require a shifting of registration service resources from such
activities as IP Analyst support for on-going registration actions as well
as the telephonic and email help desks.  Removing the procedures from the
policy allows the Director of Registration Services the flexibility of
meeting all registration services needs and managing the identification,
notification, and removal of lame delegations.

Timetable for implementation:  90 days after adoption


From Ed.Lewis at neustar.biz  Thu Feb 17 21:52:56 2005
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Fri, 18 Feb 2005 11:52:56 +0900
Subject: [ppml] Proposed Policy: Lame Delegations in IN-ADDR.ARPA
In-Reply-To: <Pine.GSO.4.51.0502171309280.29210@ops.arin.net>
References: <Pine.GSO.4.51.0502171309280.29210@ops.arin.net>
Message-ID: <a0620070abe3b03f11528@[172.16.0.87]>

At 13:10 -0500 2/17/05, Member Services wrote:

>Policy Proposal Name: Lame Delegations in IN-ADDR.ARPA
>
...

>Rationale:  The policy as stated could not be implemented without placing
>an undue burden on ARIN staff resources.  The procedures mandated in the

I think this responds well to the workload problem of the current 
lame delegation policy statement.

Now, to get tangential on this, here is question for the community.

Let's say there is a /20 network with name servers registered.  To 
the DNS this means there will be 16 (2 to the 24-20th) /24 zones.  In 
WhoIs, you would see one record for the network and one listing of 
the name servers.  In DNS you would see 16 NS RRsets.

What if the administrator has put up 15 of the 16 zones?

If, by rule, you de-list the name servers because of the one lame 
zone, the result hurts the 15 working zones.  One DNS implementation 
will drop all queries to the 16th zone, most will reply with a 
referral to "somewhere else."

(The best of all worlds would be to explain to the admin to configure 
and server the 16th zone, even with no data in it.)

This isn't a make or break problem.  The question is - does the 
community care to dive to this level of detail?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Achieving total enlightenment has taught me that ignorance in bliss.


From stacy at hilander.com  Fri Feb 18 12:22:50 2005
From: stacy at hilander.com (stacy at hilander.com)
Date: Fri, 18 Feb 2005 10:22:50 -0700
Subject: [ppml] Proposed Policy: Lame Delegations in IN-ADDR.ARPA
In-Reply-To: <Pine.GSO.4.51.0502171309280.29210@ops.arin.net>
References: <Pine.GSO.4.51.0502171309280.29210@ops.arin.net>
Message-ID: <1108747370.4216246a41f41@www.hilander.com>

I support this proposal.
/Stacy

Quoting Member Services <memsvcs at arin.net>:

> ARIN received the following proposed policy.  In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being posted
> to the ARIN Public Policy Mailing List and being placed on ARIN's website.
>
> The ARIN Advisory Council will review the proposal and within ten working
> days may decide to:
> 1)  support the proposal as is,
> 2)  work with the author to clarify, divide or combine one or more policy
> proposals, or
> 3)  not support the policy proposal.
>
> If the AC supports the proposal or reaches an agreement to work with the
> author, then the proposal will be posted as a formal policy proposal to
> the Public Policy Mailing List and it will be presented at the Public
> Policy Meeting.  If the AC does not support the proposal, then the author
> may elect to use the petition process to advance the proposal. If the
> author elects not to petition or the petition fails, then the proposed
> policy will be considered closed.
>
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/ipep.html
>
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/index.html
>
> Regards,
> Member Services Department
> American Registry for Internet Numbers
>
> ===================================================================
> Register for ARIN XV and NAv6TF Summit, April 17-21, 2005, Orlando, FL
>
>                    http://www.arin.net/ARIN-XV/
>
>    E-mail                             memsvcs at arin.net
>    FTP                                ftp.arin.net
>    WHOIS                              whois.arin.net
>    Website                            http://www.arin.net
> ===================================================================
>
> ### * ###
>
> Policy Proposal Name: Lame Delegations in IN-ADDR.ARPA
>
> Author: Paul Andersen on behalf of the ARIN AC
>
> Policy Term: Permanent
>
> Policy statement: This policy proposal replaces section 7.2 of the ARIN
> NRPM.
>
> ARIN will actively identify lame DNS name server(s) for in-addr.arpa
> delegations associated with address blocks allocated, assigned or
> administered by ARIN. Upon identification of a lame delegation, ARIN shall
> attempt to contact the POC for that resource and resolve the issue.  If,
> following due diligence, ARIN is unable to resolve the lame delegation,
> ARIN will update the WHOIS database records resulting in the removal of
> lame servers.
>
> Rationale:  The policy as stated could not be implemented without placing
> an undue burden on ARIN staff resources.  The procedures mandated in the
> policy require a shifting of registration service resources from such
> activities as IP Analyst support for on-going registration actions as well
> as the telephonic and email help desks.  Removing the procedures from the
> policy allows the Director of Registration Services the flexibility of
> meeting all registration services needs and managing the identification,
> notification, and removal of lame delegations.
>
> Timetable for implementation:  90 days after adoption
>





From tvest at pch.net  Mon Feb 21 23:43:25 2005
From: tvest at pch.net (Tom Vest)
Date: Tue, 22 Feb 2005 13:43:25 +0900
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4 allocations
In-Reply-To: <Pine.GSO.4.51.0502171301420.29210@ops.arin.net>
References: <Pine.GSO.4.51.0502171301420.29210@ops.arin.net>
Message-ID: <19f4c66a5f618b4e3108e90895938569@pch.net>

The proposed language for 4.2.4.1 uses the terms "ISP" and "all  
previous allocations" to suggest how the denominator for the HD ratio  
should be calculated. However, "ISP" is not defined in the NPRM. This  
is not especially problematic for the current  4.2.4.1 language, which  
applies the HD ratio only to an institution's most recent allocation.  
However, does ARIN possess the means to make such calculations for  
established ISPs that have grown/changed through M&A, selective  
divestiture, implementation of new autonomous systems, etc.?

Tom

On Feb 18, 2005, at 3:04 AM, Member Services wrote:

> Policy Proposal Name: Adding an HD ratio choice for new IPv4  
> allocations
>
> Author: Michael Dillon
>
> Policy term: permanent
>
> Policy statement:
> That section 4.2.4.1 of the NPRM (Number Policy Resource Manual) be
> replaced with the following text:
>
> 4.2.4.1. Utilization Efficiency
>
> ISPs must have efficiently utilized all previous allocations in order  
> to
> receive additional space. This includes all space reassigned to their
> customers. The reassignment information section of the ARIN ISP Network
> Request Template should be completed for all address blocks that have  
> been
> allocated to your organization. In the template, line 1b. Assigned:
> information will be verified via SWIP/RWHOIS and 1c. Reserved: should  
> be
> used to indicate internal network information. Please note that until  
> your
> prior utilization is verified to meet the requirements of section  
> 4.2.4.1
> and its subsections, ARIN can neither process nor approve a request for
> additional addresses.
>
> 4.2.4.1.1. Capping the Utilization Percentage - In no case will an
> organization be required to show greater than 80% utilization of their
> most recent allocation.
>
> 4.2.4.1.2.  Electing the use of HD Ratio - Any organization whose total
> IPv4 allocation is equivalent to a /20 or more may choose to have
> additional requests for IPv4 addresses evaluated using an HD (Host
> Density) Ratio calculation to determine sufficient utilization instead  
> of
> a fixed percentage threshold.
>
> 4.2.4.1.3. Simplified HD Ratio table - When electing to use the HD  
> ratio
> calculation, the applicant may elect to use these simplified tables  
> rather
> than calculating the actual ratios:
>
> Total Alloc.    Total Perc.
> <  /20               80%
>> = /20 and < /18     75%
>> = /18 and < /16     70%
>> = /16 and < /14     66%
>> = /14 and < /12     62%
>> = /12 and < /10     59%
>> = /10               55%
>
> Recent Alloc.   Recent Perc.
> <  /19               56%
>> = /19 and < /18     51%
>> = /18 and < /17     49%
>> = /17 and < /16     46%
>> = /16 and < /15     44%
>> = /15 and < /14     42%
>> = /14               40%
>
> In these tables the percentage columns refer to the percentage  
> utilization
> of the address block represented by the first column.
>
> 4.2.4.1.3. HD ratio threshold for all previous allocations - All  
> requests
> for additional IPv4 address space subject to the HD Ratio shall require
> the efficient utilization of the sum total of all existing IPv4
> allocations. The HD Ratio on the sum total of all existing IPv4
> allocations must be greater than or equal to .966.
>
> 4.2.4.1.4. HD ratio threshold for the most recent allocation - In
> addition, the HD ratio of the most recent IPv4 allocation must be  
> greater
> than or equal to .930.
>
> 4.2.4.1.5. HD ratio calculation defined - The HD ratio is calculated as
> log(utilized IPv4 addresses) divided by log(total addresses in all
> previous IPv4 allocations). In this formula, log refers to the natural
> logarithm.
>
> Rationale:
>
> The existing fixed 80% threshold does not recognize that address
> management efficiency decreases for large address blocks and imposes an
> unreasonable management overhead on larger organizations. The HD ratio
> floating threshold makes allowance for hierarchical management. As
> hierarchy increases in a network, the need for maintaining spare  
> addresses
> in a larger number of address blocks requires an ISP to have a lower
> overall utilization rate for addresses. This effect is caused by both
> increasing depth in addressing hierarchy and the increased breadth  
> enabled
> by the deeper hierarchy, e.g. larger number of PoPs. We cannot measure
> depth and breadth of hierarchy directly so we approximate this by
> measuring the total quantity of IP addresses allocated to the ISP.
>
> The existing fixed threshold imposes a limited growth rate on larger  
> ISPs
> which is inconsistent with restraint of trade legislation in USA,  
> Canada
> and other countries. This growth rate limit has been masked in previous
> years by two factors. One is that many, many new ISPs were starting up  
> and
> therefore the growth of the Internet was not limited by the growth  
> rate of
> a single company. The second factor is that in the recent past, many
> companies experienced shrinkage and churn. When the growth of new  
> business
> required new IP addresses, they could either apply to ARIN or mine the
> required addresses from these churned customers. Today we have a  
> situation
> where many companies have cleaned up their internal inefficiencies and  
> the
> Internet is growing once again, but the number of independent network
> operators is much reduced. There is a real danger that the fixed  
> threshold
> imposed by ARIN will, in fact, limit the ability of one or more network
> operators to grow their Internet services.
>
> This limiting effect kicks in when an organization's rate of growth
> exceeds their 6 month predictions and the time required to run internal
> network change management processes is longer than the time required to
> use up the last 20% of their most recent allocation. The Internet has
> become a critical infrastructure in the world economy and prudent  
> network
> management practices require that any change to a network should be
> checked, tested and carefully rolled out during narrow change windows
> which may be as little as 20 hours per week. Many smaller networks who  
> do
> not provide mission critical network services can accommodate the fixed
> threshold with little problems. However, ARIN's policies apply to all
> organizations in the region regardless of business model, it is  
> important
> for these policies to allow a variety of business models to compete on  
> a
> level playing field.
>
> Because this requires ISP to make fundamental changes in their  
> addressing
> process it is made entirely optional. There are three possibilities. An
> ISP can do everything in the same way as they always have and 4.2.4.1.1
> ensures that they continue to adhere to ARIN's policies. An ISP can  
> elect
> to apply the HD ratio to their address management systems by using the
> percentage tables from 4.2.4.1.3. At any point in time an ISP needs to  
> be
> concerned with only two table entries, and this should be easy to
> incorporate into percentage-based management systems. Or, an ISP can  
> elect
> to implement the HD ratio formula into their management systems and use
> the same framework for both IPv6 and IPv4 allocations.
>
> RIPE will be discussing a similar proposal from Alain Bidron of France
> Telecom at their meeting in Stockholm May 2 - 6, 2005. In Europe, the
> largest ISPs are telecom companies and are members of the ETNO  
> (European
> Telecom Network Operators Association). The ETNO has recently  
> published an
> expert opinion document in which they strongly support applying the HD
> ratio to IPv4 addresses. This document is available in PDF format at  
> this
> URL
> <http://www.etno.be/pp/EC064%20- 
> %20NANI%20EC%20on%20IPv4%20AD%20ratio.pdf>.
>
> The HD ratio was proposed as a way to determine allocation usage
> thresholds for IPv6 address allocations. For more details on this,  
> please
> refer to RFC 3194 <http://www.faqs.org/rfcs/rfc3194.html>. There is  
> some
> detailed background discussion about applying the HD ratio to IPv4
> allocations in a proposal by Paul Wilson posted to the APNIC mailing  
> list
> on Aug 7, 2003
> http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/ 
> msg00000.html
> and he made a presentation of this to last year's RIPE 48 meeting in
> Amsterdam. PDF slides of his presentation are here
> <http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-hd- 
> ratio.pdf>.
> Paul and some others use the term 'AD ratio' to refer to the HD ratio  
> when
> it is applied to IPv4 addresses. I have kept the original term used in
> ARIN's IPv6 policy for the sake of simplicity.
>
> Timetable for implementation: 30 days after ratification by the board



From owen at delong.com  Tue Feb 22 05:23:26 2005
From: owen at delong.com (Owen DeLong)
Date: Tue, 22 Feb 2005 02:23:26 -0800
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4
 allocations
In-Reply-To: <19f4c66a5f618b4e3108e90895938569@pch.net>
References: <Pine.GSO.4.51.0502171301420.29210@ops.arin.net>
 <19f4c66a5f618b4e3108e90895938569@pch.net>
Message-ID: <2147483647.1109039006@[172.17.1.152]>

The correct solution is to replace the term ISP with the term LIR for
allocations and the term Organization for asignments.

Owen


--On Tuesday, February 22, 2005 13:43 +0900 Tom Vest <tvest at pch.net> wrote:

> The proposed language for 4.2.4.1 uses the terms "ISP" and "all  previous
> allocations" to suggest how the denominator for the HD ratio  should be
> calculated. However, "ISP" is not defined in the NPRM. This  is not
> especially problematic for the current  4.2.4.1 language, which  applies
> the HD ratio only to an institution's most recent allocation.  However,
> does ARIN possess the means to make such calculations for  established
> ISPs that have grown/changed through M&A, selective  divestiture,
> implementation of new autonomous systems, etc.?
>
> Tom
>
> On Feb 18, 2005, at 3:04 AM, Member Services wrote:
>
>> Policy Proposal Name: Adding an HD ratio choice for new IPv4
>> allocations
>>
>> Author: Michael Dillon
>>
>> Policy term: permanent
>>
>> Policy statement:
>> That section 4.2.4.1 of the NPRM (Number Policy Resource Manual) be
>> replaced with the following text:
>>
>> 4.2.4.1. Utilization Efficiency
>>
>> ISPs must have efficiently utilized all previous allocations in order
>> to
>> receive additional space. This includes all space reassigned to their
>> customers. The reassignment information section of the ARIN ISP Network
>> Request Template should be completed for all address blocks that have
>> been
>> allocated to your organization. In the template, line 1b. Assigned:
>> information will be verified via SWIP/RWHOIS and 1c. Reserved: should
>> be
>> used to indicate internal network information. Please note that until
>> your
>> prior utilization is verified to meet the requirements of section
>> 4.2.4.1
>> and its subsections, ARIN can neither process nor approve a request for
>> additional addresses.
>>
>> 4.2.4.1.1. Capping the Utilization Percentage - In no case will an
>> organization be required to show greater than 80% utilization of their
>> most recent allocation.
>>
>> 4.2.4.1.2.  Electing the use of HD Ratio - Any organization whose total
>> IPv4 allocation is equivalent to a /20 or more may choose to have
>> additional requests for IPv4 addresses evaluated using an HD (Host
>> Density) Ratio calculation to determine sufficient utilization instead
>> of
>> a fixed percentage threshold.
>>
>> 4.2.4.1.3. Simplified HD Ratio table - When electing to use the HD
>> ratio
>> calculation, the applicant may elect to use these simplified tables
>> rather
>> than calculating the actual ratios:
>>
>> Total Alloc.    Total Perc.
>> <  /20               80%
>>> = /20 and < /18     75%
>>> = /18 and < /16     70%
>>> = /16 and < /14     66%
>>> = /14 and < /12     62%
>>> = /12 and < /10     59%
>>> = /10               55%
>>
>> Recent Alloc.   Recent Perc.
>> <  /19               56%
>>> = /19 and < /18     51%
>>> = /18 and < /17     49%
>>> = /17 and < /16     46%
>>> = /16 and < /15     44%
>>> = /15 and < /14     42%
>>> = /14               40%
>>
>> In these tables the percentage columns refer to the percentage
>> utilization
>> of the address block represented by the first column.
>>
>> 4.2.4.1.3. HD ratio threshold for all previous allocations - All
>> requests
>> for additional IPv4 address space subject to the HD Ratio shall require
>> the efficient utilization of the sum total of all existing IPv4
>> allocations. The HD Ratio on the sum total of all existing IPv4
>> allocations must be greater than or equal to .966.
>>
>> 4.2.4.1.4. HD ratio threshold for the most recent allocation - In
>> addition, the HD ratio of the most recent IPv4 allocation must be
>> greater
>> than or equal to .930.
>>
>> 4.2.4.1.5. HD ratio calculation defined - The HD ratio is calculated as
>> log(utilized IPv4 addresses) divided by log(total addresses in all
>> previous IPv4 allocations). In this formula, log refers to the natural
>> logarithm.
>>
>> Rationale:
>>
>> The existing fixed 80% threshold does not recognize that address
>> management efficiency decreases for large address blocks and imposes an
>> unreasonable management overhead on larger organizations. The HD ratio
>> floating threshold makes allowance for hierarchical management. As
>> hierarchy increases in a network, the need for maintaining spare
>> addresses
>> in a larger number of address blocks requires an ISP to have a lower
>> overall utilization rate for addresses. This effect is caused by both
>> increasing depth in addressing hierarchy and the increased breadth
>> enabled
>> by the deeper hierarchy, e.g. larger number of PoPs. We cannot measure
>> depth and breadth of hierarchy directly so we approximate this by
>> measuring the total quantity of IP addresses allocated to the ISP.
>>
>> The existing fixed threshold imposes a limited growth rate on larger
>> ISPs
>> which is inconsistent with restraint of trade legislation in USA,
>> Canada
>> and other countries. This growth rate limit has been masked in previous
>> years by two factors. One is that many, many new ISPs were starting up
>> and
>> therefore the growth of the Internet was not limited by the growth
>> rate of
>> a single company. The second factor is that in the recent past, many
>> companies experienced shrinkage and churn. When the growth of new
>> business
>> required new IP addresses, they could either apply to ARIN or mine the
>> required addresses from these churned customers. Today we have a
>> situation
>> where many companies have cleaned up their internal inefficiencies and
>> the
>> Internet is growing once again, but the number of independent network
>> operators is much reduced. There is a real danger that the fixed
>> threshold
>> imposed by ARIN will, in fact, limit the ability of one or more network
>> operators to grow their Internet services.
>>
>> This limiting effect kicks in when an organization's rate of growth
>> exceeds their 6 month predictions and the time required to run internal
>> network change management processes is longer than the time required to
>> use up the last 20% of their most recent allocation. The Internet has
>> become a critical infrastructure in the world economy and prudent
>> network
>> management practices require that any change to a network should be
>> checked, tested and carefully rolled out during narrow change windows
>> which may be as little as 20 hours per week. Many smaller networks who
>> do
>> not provide mission critical network services can accommodate the fixed
>> threshold with little problems. However, ARIN's policies apply to all
>> organizations in the region regardless of business model, it is
>> important
>> for these policies to allow a variety of business models to compete on
>> a
>> level playing field.
>>
>> Because this requires ISP to make fundamental changes in their
>> addressing
>> process it is made entirely optional. There are three possibilities. An
>> ISP can do everything in the same way as they always have and 4.2.4.1.1
>> ensures that they continue to adhere to ARIN's policies. An ISP can
>> elect
>> to apply the HD ratio to their address management systems by using the
>> percentage tables from 4.2.4.1.3. At any point in time an ISP needs to
>> be
>> concerned with only two table entries, and this should be easy to
>> incorporate into percentage-based management systems. Or, an ISP can
>> elect
>> to implement the HD ratio formula into their management systems and use
>> the same framework for both IPv6 and IPv4 allocations.
>>
>> RIPE will be discussing a similar proposal from Alain Bidron of France
>> Telecom at their meeting in Stockholm May 2 - 6, 2005. In Europe, the
>> largest ISPs are telecom companies and are members of the ETNO
>> (European
>> Telecom Network Operators Association). The ETNO has recently
>> published an
>> expert opinion document in which they strongly support applying the HD
>> ratio to IPv4 addresses. This document is available in PDF format at
>> this
>> URL
>> <http://www.etno.be/pp/EC064%20-
>> %20NANI%20EC%20on%20IPv4%20AD%20ratio.pdf>.
>>
>> The HD ratio was proposed as a way to determine allocation usage
>> thresholds for IPv6 address allocations. For more details on this,
>> please
>> refer to RFC 3194 <http://www.faqs.org/rfcs/rfc3194.html>. There is
>> some
>> detailed background discussion about applying the HD ratio to IPv4
>> allocations in a proposal by Paul Wilson posted to the APNIC mailing
>> list
>> on Aug 7, 2003
>> http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/
>> msg00000.html
>> and he made a presentation of this to last year's RIPE 48 meeting in
>> Amsterdam. PDF slides of his presentation are here
>> <http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-hd-
>> ratio.pdf>.
>> Paul and some others use the term 'AD ratio' to refer to the HD ratio
>> when
>> it is applied to IPv4 addresses. I have kept the original term used in
>> ARIN's IPv6 policy for the sake of simplicity.
>>
>> Timetable for implementation: 30 days after ratification by the board
>



-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050222/a0392149/attachment.sig>

From Michael.Dillon at radianz.com  Tue Feb 22 08:15:30 2005
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Tue, 22 Feb 2005 13:15:30 +0000
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4
 allocations
In-Reply-To: <2147483647.1109039006@[172.17.1.152]>
Message-ID: <OF6A56179C.C7CF45A7-ON80256FB0.0047F36C-80256FB0.0048D2E0@radianz.com>

> The correct solution is to replace the term ISP with the term LIR for
> allocations and the term Organization for asignments.

In my proposal I used the term "organization" because
the context was already set by the section title,
4.2.  Allocations to ISPs

However, the existing section 4.2.4.1 did use the
term ISP and I kept this in the interest of making 
minimal changes to the current wording of this 
section. I only changed the words needed to accomodate
the HD ratio and left the rest, including the term
ISP, unchanged. This leaves open the possibility 
that at some later date, we could insert a clause
elsewhere in the NPRM that says

    "Organizations classed as ???? must meet
     the requirements of sections 4.2.4.1.1
     through 4.2.4.1.5 inclusive, when applying
     for additional address space."

I do agree that it would be a good idea to 
have a definition of the term ISP in the NPRM.
My sense is that ISP refers to any organization
that receives an allocation from ARIN and it is
therefore identical to the RIPE term LIR.

However, this should be done elsewhere in the
NPRM, not in the Allocation to ISP's section.

--Michael Dillon



From cscott at gaslightmedia.com  Tue Feb 22 09:14:44 2005
From: cscott at gaslightmedia.com (Charles Scott)
Date: Tue, 22 Feb 2005 09:14:44 -0500 (EST)
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4
 allocations
In-Reply-To: <19f4c66a5f618b4e3108e90895938569@pch.net>
Message-ID: <Pine.LNX.4.44.0502220904330.16091-100000@harbor.gaslightmedia.com>


PPML:
  As this has been introduced before I would like to copy a message I
posted a little more than 1 year ago regarding the validity of HD ratio
with respect to ISP allocation/re-allocation. I don't believe that these
specific questions were addressed the last time HD ratio came up. I am
still not convinced that there is sufficient reason to introduce HD ratio
as it appears to address a problem that is questionably applicable to
end-user utilization and apparently not applicable to ISP
allocation/re-allocation. As the rational for HD ratio is being applied to
the needs of ISP's, I would appreciate an explanation as to how and why HD
ratio would be applicable.

Chuck Scott
cscott at gaslightmedia.com


>Date: Tue, 10 Feb 2004 08:38:01 -0500 (EST)
>From: Charles Scott <cscott at gaslightmedia.com>
>To: Michael.Dillon at radianz.com
>Cc: ppml at arin.net
>Subject: Re: [ppml] HD Ratio changes
>
>
>
>Michael:
>  When this last came up I questioned why HD Ratio should be applied to
>ISP allocations/assignments and received no responses. In fact, I even
>challenged the application of HD Ratio to end-user address space on the
>premise that the argument for HD Radio is based on the need to implement
>a strict hierarchical numbering scheme. With dynamic routing protocols it
>is not necessary to have a network hierarchically arranged strictly by
>numeric address--subnets can appear in networks to which they are not
>numerically related. The arguments for HD Ratio have used telephone
>number distribution as an example, but that is not a comparative model
>today (although number portability may convolute that).
>  Frankly I see this as being parallel to encouraging end-users to use
>NAT in that the more they use it, the more they conserve address space.
>In that respect, the more people rely on dynamic routing to permit more
>flexible distribution of address space, the easier it is to manage
>address space and the more they can conserve (and the more they avoid the
>concerns driving HD Ratio).
>  Regardless of the above, all of the references about the need for HD
>Ratio relate to end-user address assignment issues and don't seem to be
>relevant to allocating, or re-allocating (here we go with terminology
>again) blocks of addresses by ISP's. Frankly, I can't see how it would be
>relevant to that. I might be inclined to agree with the use of HD Ratio
>if it only applies to end user implementation of address space and not to
>address block assignment/allocation, and if I was convinced that the
>mitigating issues addressed above do not relieve the concerns. Otherwise,
>I'm, once again, concerned that this approach unnecessarily increases
>waste and complexity and in doing so provides questionable relief.
>
>Chuck Scott
>cscott at gaslightmedia.com





From Michael.Dillon at radianz.com  Tue Feb 22 09:36:44 2005
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Tue, 22 Feb 2005 14:36:44 +0000
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4
 allocations
In-Reply-To: <Pine.LNX.4.44.0502220904330.16091-100000@harbor.gaslightmedia.com>
Message-ID: <OFBECA4ACA.7F323CFE-ON80256FB0.004F2CB6-80256FB0.005042FC@radianz.com>

> >  When this last came up I questioned why HD Ratio should be applied to
> >ISP allocations/assignments and received no responses. In fact, I even
> >challenged the application of HD Ratio to end-user address space on the
> >premise that the argument for HD Radio is based on the need to 
implement
> >a strict hierarchical numbering scheme. With dynamic routing protocols 
it
> >is not necessary to have a network hierarchically arranged strictly by
> >numeric address--subnets can appear in networks to which they are not
> >numerically related. 

To begin with, it's not hierarchy alone that creates the
problem. Hierarchy interacts with the bit-mask operations
used to divide network addresses and host addresses. These
bit-mask operations impose a power-of-2 structure on network
sizes and aggregate sizes. The hierarchy exacerbates the
problem because the power-of-2 rule applies at each level.

Suppose that I have a special product that requires 5
IP addresses per customer. I have 5 PoPs with 25 customers
at each PoP. Therefore, at each PoP I need 125 addresses for
a sum total of 625 addresses to cover the needs of all 
5 cities.

But IPv4 doesn't work that way. In fact, I have to give each
customer 8 addresses for a total of 200 addresses at a PoP.
That makes 1000 addresses in total, right? Wrong. I have to 
give each PoP 256 addresses, not 200. That makes for a total
of 1280 addresses. This is how hierarchy increases inefficiency
by compounding the "overhead" associated with the power-of-2
rule.

In a real network, each of the subnets will also have extra
addresses to accomodate growth because no network operator
can function by only growing their subnets by one customer
requirement at a time. The larger the network, the more this
overhead eats up addresses especially when you are trying 
to make sure that routes can be aggregated to keep the number
of individual routes low. In a small network you can ignore 
aggregation, give every customer a random block of addresses
and let dynamic routing sort out the mess. This will not
scale.

--Michael Dillon




From cscott at gaslightmedia.com  Tue Feb 22 12:24:47 2005
From: cscott at gaslightmedia.com (Charles Scott)
Date: Tue, 22 Feb 2005 12:24:47 -0500 (EST)
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4
 allocations
In-Reply-To: <OFBECA4ACA.7F323CFE-ON80256FB0.004F2CB6-80256FB0.005042FC@radianz.com>
Message-ID: <Pine.LNX.4.44.0502221213550.16091-100000@harbor.gaslightmedia.com>


Michael:
  You seem to be supporting my point, that, if anything, HD ratio applies 
to end-user address utilization, for which there is already significant 
accommodation for these issues as your examples would easily be 
accommodated by the 25%/50% policy for end-user address utilization. 
  Is there something else I'm missing?

Chuck Scott
cscott at gaslightmedia.com



On Tue, 22 Feb 2005 Michael.Dillon at radianz.com wrote:

> > >  When this last came up I questioned why HD Ratio should be applied to
> > >ISP allocations/assignments and received no responses. In fact, I even
> > >challenged the application of HD Ratio to end-user address space on the
> > >premise that the argument for HD Radio is based on the need to 
> implement
> > >a strict hierarchical numbering scheme. With dynamic routing protocols 
> it
> > >is not necessary to have a network hierarchically arranged strictly by
> > >numeric address--subnets can appear in networks to which they are not
> > >numerically related. 
> 
> To begin with, it's not hierarchy alone that creates the
> problem. Hierarchy interacts with the bit-mask operations
> used to divide network addresses and host addresses. These
> bit-mask operations impose a power-of-2 structure on network
> sizes and aggregate sizes. The hierarchy exacerbates the
> problem because the power-of-2 rule applies at each level.
> 
> Suppose that I have a special product that requires 5
> IP addresses per customer. I have 5 PoPs with 25 customers
> at each PoP. Therefore, at each PoP I need 125 addresses for
> a sum total of 625 addresses to cover the needs of all 
> 5 cities.
> 
> But IPv4 doesn't work that way. In fact, I have to give each
> customer 8 addresses for a total of 200 addresses at a PoP.
> That makes 1000 addresses in total, right? Wrong. I have to 
> give each PoP 256 addresses, not 200. That makes for a total
> of 1280 addresses. This is how hierarchy increases inefficiency
> by compounding the "overhead" associated with the power-of-2
> rule.
> 
> In a real network, each of the subnets will also have extra
> addresses to accomodate growth because no network operator
> can function by only growing their subnets by one customer
> requirement at a time. The larger the network, the more this
> overhead eats up addresses especially when you are trying 
> to make sure that routes can be aggregated to keep the number
> of individual routes low. In a small network you can ignore 
> aggregation, give every customer a random block of addresses
> and let dynamic routing sort out the mess. This will not
> scale.
> 
> --Michael Dillon
> 
> 



From owen at delong.com  Tue Feb 22 13:52:09 2005
From: owen at delong.com (Owen DeLong)
Date: Tue, 22 Feb 2005 10:52:09 -0800
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4
 allocations
In-Reply-To: <OF6A56179C.C7CF45A7-ON80256FB0.0047F36C-80256FB0.0048D2E0@radianz.com>
References: <OF6A56179C.C7CF45A7-ON80256FB0.0047F36C-80256FB0.0048D2E0@radia
 nz.com>
Message-ID: <2147483647.1109069529@imac-en0.delong.sj.ca.us>

Actually, the Allocation section should be rewritten to replace
the ambiguous and meaningless term ISP with the defined and registry-
relevant term LIR, in my opinion.

I do not believe the term LIR is RIPE specific, as it is included
in RFCs and other IETF working group documents, and, in fact is
defined in the NRPM (note: not NPRM) at section 2.4.

Since the NRPM defines LIR and does not define ISP, I believe that
it is a clerical correction to s/ISP/LIR/g in the NRPM, but, I will
leave that to the judgment of Einar, the AC, and the BOT.

Again, assignments are, by definition to Organizations, and, allocations
are, by definition to LIRs or NIRs.  I don't believe there are currently
any NIRs within ARIN, but, even if there are, ISP would not encompass
them correctly, anyway.

Owen


--On Tuesday, February 22, 2005 1:15 PM +0000 Michael.Dillon at radianz.com 
wrote:

>> The correct solution is to replace the term ISP with the term LIR for
>> allocations and the term Organization for asignments.
>
> In my proposal I used the term "organization" because
> the context was already set by the section title,
> 4.2.  Allocations to ISPs
>
> However, the existing section 4.2.4.1 did use the
> term ISP and I kept this in the interest of making
> minimal changes to the current wording of this
> section. I only changed the words needed to accomodate
> the HD ratio and left the rest, including the term
> ISP, unchanged. This leaves open the possibility
> that at some later date, we could insert a clause
> elsewhere in the NPRM that says
>
>     "Organizations classed as ???? must meet
>      the requirements of sections 4.2.4.1.1
>      through 4.2.4.1.5 inclusive, when applying
>      for additional address space."
>
> I do agree that it would be a good idea to
> have a definition of the term ISP in the NPRM.
> My sense is that ISP refers to any organization
> that receives an allocation from ARIN and it is
> therefore identical to the RIPE term LIR.
>
> However, this should be done elsewhere in the
> NPRM, not in the Allocation to ISP's section.
>
> --Michael Dillon
>



-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050222/a6bf68fb/attachment.sig>

From owen at delong.com  Tue Feb 22 14:10:20 2005
From: owen at delong.com (Owen DeLong)
Date: Tue, 22 Feb 2005 11:10:20 -0800
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4
 allocations
In-Reply-To: <OFBECA4ACA.7F323CFE-ON80256FB0.004F2CB6-80256FB0.005042FC@radianz.com>
References: <OFBECA4ACA.7F323CFE-ON80256FB0.004F2CB6-80256FB0.005042FC@radia
 nz.com>
Message-ID: <2147483647.1109070620@imac-en0.delong.sj.ca.us>

> To begin with, it's not hierarchy alone that creates the
> problem. Hierarchy interacts with the bit-mask operations
> used to divide network addresses and host addresses. These
> bit-mask operations impose a power-of-2 structure on network
> sizes and aggregate sizes. The hierarchy exacerbates the
> problem because the power-of-2 rule applies at each level.
>
> Suppose that I have a special product that requires 5
> IP addresses per customer. I have 5 PoPs with 25 customers
> at each PoP. Therefore, at each PoP I need 125 addresses for
> a sum total of 625 addresses to cover the needs of all
> 5 cities.
>
A rather pathological example, but, OK... Let's run with that...

> But IPv4 doesn't work that way. In fact, I have to give each
> customer 8 addresses for a total of 200 addresses at a PoP.
> That makes 1000 addresses in total, right? Wrong. I have to
> give each PoP 256 addresses, not 200. That makes for a total
> of 1280 addresses. This is how hierarchy increases inefficiency
> by compounding the "overhead" associated with the power-of-2
> rule.
>
Why?  Why does each POP have to aggregate to a /24?  Why can't
each POP simply advertise the individual /29s into your backbone?
You only need to aggregate at your borders to other ASs, and, if
you're getting allocation/assignment direct from ARIN (where this
would matter), you've got at least a /22, so, having the /29s
inside your AS and the /22 or more outside should not be an
issue.  Sure, aggregating at the POP level may be desirable in
cases where it makes sense, but, this seems to identify a
situation where it does not.

Further, if you have, in fact, issued /29s to the customers,
then you have "utilized" for the ARIN term, 200 addresses
per POP, not the 125 you claim.  200/256 is 0.78125, so,
if you've done your entire network in this manner and you
don't have any other small assignments in your POPs to take
up the remaining (1 /29, 1 /28, 1 /27) prefixes aggregated
to that POP (and for some reason, you can't put them elsewhere
in your network as more specifics (?), then, I suppose that
you might have some difficulty with the 80% rule.
However, if you had 26 customers per POP, or, managed to
find a need for that /27 (say the POP infrastructure), then,
you'd have no problem with the current 80% rule.

My general position on the HD thing has been "It's optional,
some may find it useful, who cares... It's not a big deal."
However, your example has now convinced me that it is actually
a way to reward inefficient network topology with more address
space.  As such, I withdraw my neutrality and oppose the
current proposal.

> In a real network, each of the subnets will also have extra
> addresses to accomodate growth because no network operator
> can function by only growing their subnets by one customer
> requirement at a time. The larger the network, the more this
> overhead eats up addresses especially when you are trying
> to make sure that routes can be aggregated to keep the number
> of individual routes low. In a small network you can ignore
> aggregation, give every customer a random block of addresses
> and let dynamic routing sort out the mess. This will not
> scale.
>
That's true, but, I'm not at this point convinced that HD ratio
is a meaningful solution to that problem.  I have long advocated
that there are cases in which an LIR should be able to treat
nodes as if they were individual sub-LIRs and justify space to
ARIN on that basis.  When I was at Exodus, this was bad enough
that we finally succumbed and paid multiple fees to ARIN to make
each of our regions a separate LIR instead of being a single
organization with a single allocation criteria.  However, I
don't believe HD really addresses this issue.  I do believe
that it rewards pathological inefficiencies as the one you describe
above.

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050222/ed3e31de/attachment.sig>

From cscott at gaslightmedia.com  Tue Feb 22 15:03:36 2005
From: cscott at gaslightmedia.com (Charles Scott)
Date: Tue, 22 Feb 2005 15:03:36 -0500 (EST)
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4
 allocations
In-Reply-To: <2147483647.1109070620@imac-en0.delong.sj.ca.us>
Message-ID: <Pine.LNX.4.44.0502221447500.2982-100000@harbor.gaslightmedia.com>





On Tue, 22 Feb 2005, Owen DeLong wrote:
>
> Further, if you have, in fact, issued /29s to the customers,
> then you have "utilized" for the ARIN term, 200 addresses
> per POP, not the 125 you claim.  200/256 is 0.78125, so,
> if you've done your entire network in this manner and you
> don't have any other small assignments in your POPs to take
> up the remaining (1 /29, 1 /28, 1 /27) prefixes aggregated
> to that POP (and for some reason, you can't put them elsewhere
> in your network as more specifics (?), then, I suppose that
> you might have some difficulty with the 80% rule.
> However, if you had 26 customers per POP, or, managed to
> find a need for that /27 (say the POP infrastructure), then,
> you'd have no problem with the current 80% rule.

Owen:
  I'm not sure about your comments above, It's been my understanding, that
address space assigned to an ISP's customers is considered 100% utilized
as far as the ISP's address reassignment pool is concerned--provided of
course that there was adequate justification for the assignment to the
customer (re: 25%/50% rule) in the first place. It's also been my
understanding that an ISP effectively assigns address space to itself from
their reassignment pool when it is to be the end user of the space and
that space needs to be justified under the 25%/50% rule. If there's no
argument about that, then there is a clear separation in the how the
justification is assessed for an ISP's reassignment pool vs end user
address space. Therefore my point on HD ratio not being necessary for
end-user utilization and not being relevant to a reassignment pool.

Chuck Scott
cscott at gaslightmedia.com





From owen at delong.com  Tue Feb 22 15:59:42 2005
From: owen at delong.com (Owen DeLong)
Date: Tue, 22 Feb 2005 12:59:42 -0800
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4
 allocations
In-Reply-To: <Pine.LNX.4.44.0502221447500.2982-100000@harbor.gaslightmedia.com>
References: <Pine.LNX.4.44.0502221447500.2982-100000@harbor.gaslightmedia.co
 m>
Message-ID: <2147483647.1109077182@imac-en0.delong.sj.ca.us>



--On Tuesday, February 22, 2005 3:03 PM -0500 Charles Scott 
<cscott at gaslightmedia.com> wrote:

>
>
>
>
> On Tue, 22 Feb 2005, Owen DeLong wrote:
>>
>> Further, if you have, in fact, issued /29s to the customers,
>> then you have "utilized" for the ARIN term, 200 addresses
>> per POP, not the 125 you claim.  200/256 is 0.78125, so,
>> if you've done your entire network in this manner and you
>> don't have any other small assignments in your POPs to take
>> up the remaining (1 /29, 1 /28, 1 /27) prefixes aggregated
>> to that POP (and for some reason, you can't put them elsewhere
>> in your network as more specifics (?), then, I suppose that
>> you might have some difficulty with the 80% rule.
>> However, if you had 26 customers per POP, or, managed to
>> find a need for that /27 (say the POP infrastructure), then,
>> you'd have no problem with the current 80% rule.
>
> Owen:
>   I'm not sure about your comments above, It's been my understanding, that
> address space assigned to an ISP's customers is considered 100% utilized
> as far as the ISP's address reassignment pool is concerned--provided of
> course that there was adequate justification for the assignment to the
> customer (re: 25%/50% rule) in the first place. It's also been my
> understanding that an ISP effectively assigns address space to itself from
> their reassignment pool when it is to be the end user of the space and
> that space needs to be justified under the 25%/50% rule. If there's no
> argument about that, then there is a clear separation in the how the
> justification is assessed for an ISP's reassignment pool vs end user
> address space. Therefore my point on HD ratio not being necessary for
> end-user utilization and not being relevant to a reassignment pool.
>
> Chuck Scott
> cscott at gaslightmedia.com
>
>
>

Only problem is that you are not correct about the 25/50% rule.  That only
applies to the INITIAL allocation to an end-user organization and does
NOT apply to additional assignments.  Additional assignments are still
subject to the 80% of all existing space and 50% of most recent allocation
rule.

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050222/eaaf7508/attachment.sig>

From cscott at gaslightmedia.com  Tue Feb 22 17:18:30 2005
From: cscott at gaslightmedia.com (Charles Scott)
Date: Tue, 22 Feb 2005 17:18:30 -0500 (EST)
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4
 allocations
In-Reply-To: <2147483647.1109077182@imac-en0.delong.sj.ca.us>
Message-ID: <Pine.LNX.4.44.0502221647230.2982-100000@harbor.gaslightmedia.com>



On Tue, 22 Feb 2005, Owen DeLong wrote:

> 
> Only problem is that you are not correct about the 25/50% rule.  That only
> applies to the INITIAL allocation to an end-user organization and does
> NOT apply to additional assignments.  Additional assignments are still
> subject to the 80% of all existing space and 50% of most recent allocation
> rule.
> 
> Owen

Owen:
  Sorry, my perpetual confusion regarding what the meaning of
"utilization" is.
  This situation, however, indicates how inane the popular concept of
utilization (hosts/addresses) really is when applied universally to
everything from a single subnet to a large reassignment pool. I would
argue that this very narrow definition of utilization is only applicable
to the use of an individual subnet. At higher levels, it would seem that
if subnets are rationally and efficiently used, that they should be
considered consumed in their entirety for the purpose of evaluating the
pool from which they were drawn. If one takes that approach then there is
no more confusion, each level of assignment can be evaluated on it's own
merit, and there is no relevance to HD ratio. To do otherwise seems to be
the tail wagging the dog as each level in the hierarchy dynamically
complicates all levels above to point of absurdity.
  Having written the above, I would agree that in the absence of the above
logic, and where a strict composite hosts/addresses evaluation is used at
all levels, that an HD ratio bandaid could be argued--but not easily for
the reasons given.

Chuck




From owen at delong.com  Wed Feb 23 02:06:50 2005
From: owen at delong.com (Owen DeLong)
Date: Tue, 22 Feb 2005 23:06:50 -0800
Subject: [ppml] Proposed Policy: Adding an HD ratio choice for new IPv4
 allocations
In-Reply-To: <Pine.LNX.4.44.0502221647230.2982-100000@harbor.gaslightmedia.com>
References: <Pine.LNX.4.44.0502221647230.2982-100000@harbor.gaslightmedia.co
 m>
Message-ID: <2147483647.1109113608@[172.17.1.152]>

At a higher level, if 80% of the address space is assigned (i.e. carved
up into subnets) and each subnet is 80% utilized (i.e. efficiently
utilized), things tend to work out rather well.  There are a few
pathological cases where efficient subnet utilization is closer to
50% than 80%, but, in most large address pools, these do not tend to
represent a significant portion of the address space and do not
create a statistically meaningful drop in utilization.  In general,
when ARIN is reviewing allocations, they look for 80% assignment to
count utilization.  When reviewing assignments, they look for 80%
host usage with some fudge factor allowed in justifiable cases.

Owen


--On Tuesday, February 22, 2005 17:18 -0500 Charles Scott 
<cscott at gaslightmedia.com> wrote:

>
>
> On Tue, 22 Feb 2005, Owen DeLong wrote:
>
>>
>> Only problem is that you are not correct about the 25/50% rule.  That
>> only applies to the INITIAL allocation to an end-user organization and
>> does NOT apply to additional assignments.  Additional assignments are
>> still subject to the 80% of all existing space and 50% of most recent
>> allocation rule.
>>
>> Owen
>
> Owen:
>   Sorry, my perpetual confusion regarding what the meaning of
> "utilization" is.
>   This situation, however, indicates how inane the popular concept of
> utilization (hosts/addresses) really is when applied universally to
> everything from a single subnet to a large reassignment pool. I would
> argue that this very narrow definition of utilization is only applicable
> to the use of an individual subnet. At higher levels, it would seem that
> if subnets are rationally and efficiently used, that they should be
> considered consumed in their entirety for the purpose of evaluating the
> pool from which they were drawn. If one takes that approach then there is
> no more confusion, each level of assignment can be evaluated on it's own
> merit, and there is no relevance to HD ratio. To do otherwise seems to be
> the tail wagging the dog as each level in the hierarchy dynamically
> complicates all levels above to point of absurdity.
>   Having written the above, I would agree that in the absence of the above
> logic, and where a strict composite hosts/addresses evaluation is used at
> all levels, that an HD ratio bandaid could be argued--but not easily for
> the reasons given.
>
> Chuck
>
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050222/40caac4a/attachment.sig>

From Michael.Dillon at radianz.com  Wed Feb 23 04:49:43 2005
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Wed, 23 Feb 2005 09:49:43 +0000
Subject: [ppml] HD Ratio and scaling issues (was Re: Proposed Policy...)
In-Reply-To: <2147483647.1109070620@imac-en0.delong.sj.ca.us>
Message-ID: <OFEC6E5E2A.2898A625-ON80256FB1.00355C62-80256FB1.0035FBAF@radianz.com>

> That's true, but, I'm not at this point convinced that HD ratio
> is a meaningful solution to that problem.  I have long advocated
> that there are cases in which an LIR should be able to treat
> nodes as if they were individual sub-LIRs and justify space to
> ARIN on that basis.  When I was at Exodus, this was bad enough
> that we finally succumbed and paid multiple fees to ARIN to make
> each of our regions a separate LIR instead of being a single
> organization with a single allocation criteria.  However, I
> don't believe HD really addresses this issue.  I do believe
> that it rewards pathological inefficiencies as the one you describe
> above.

First, my comments were not intended to be an explanation
of why we need HD ratio for IPv4. I mainly tried to address
one question from Charles to illustrate the effects of
hierarchy. You seem to think that this illustrates pathological
inefficiency and prefer to see large numbers of routes
instead. But since we are talking about scaling issues here,
having a large number of internal routes is not necessarily
prudent or efficient in a large network.

I would really like to see you describe in more
detail your definition of pathological inefficiency
contrasted with ordinary inefficiency.

Also, I'd like to understand what were the issues that
you ran into at Exodus. Were they also scaling issues
in which the ARIN policies simply don't work for larger
networks?

--Michael Dillon



From owen at delong.com  Wed Feb 23 06:06:04 2005
From: owen at delong.com (Owen DeLong)
Date: Wed, 23 Feb 2005 03:06:04 -0800
Subject: [ppml] HD Ratio and scaling issues (was Re: Proposed Policy...)
In-Reply-To: <OFEC6E5E2A.2898A625-ON80256FB1.00355C62-80256FB1.0035FBAF@radianz.com>
References: <OFEC6E5E2A.2898A625-ON80256FB1.00355C62-80256FB1.0035FBAF@radia
 nz.com>
Message-ID: <2147483647.1109127962@[172.17.1.152]>



--On Wednesday, February 23, 2005 9:49 +0000 Michael.Dillon at radianz.com 
wrote:

>> That's true, but, I'm not at this point convinced that HD ratio
>> is a meaningful solution to that problem.  I have long advocated
>> that there are cases in which an LIR should be able to treat
>> nodes as if they were individual sub-LIRs and justify space to
>> ARIN on that basis.  When I was at Exodus, this was bad enough
>> that we finally succumbed and paid multiple fees to ARIN to make
>> each of our regions a separate LIR instead of being a single
>> organization with a single allocation criteria.  However, I
>> don't believe HD really addresses this issue.  I do believe
>> that it rewards pathological inefficiencies as the one you describe
>> above.
>
> First, my comments were not intended to be an explanation
> of why we need HD ratio for IPv4. I mainly tried to address
> one question from Charles to illustrate the effects of
> hierarchy. You seem to think that this illustrates pathological
> inefficiency and prefer to see large numbers of routes
> instead. But since we are talking about scaling issues here,
> having a large number of internal routes is not necessarily
> prudent or efficient in a large network.
>
OK... Well, since his question was related to your HD ratio proposal,
I assumed your answer was similarly related.  My mistake.
I proposed large numbers of IGP routes (625 is a large number
of routes?) as one easy alternative at the scale described.
Realistically, if you scale this much larger than what you
described, most of the described inefficiencies start to drop
into the noise threshold, so, that is why I considered it
a pathological example.  Address consumption vs. <1K route
delta in an IGP does not seem like a wise tradeoff to me.
Below, I propose a way to do this without significant (if any)
routing table growth.

> I would really like to see you describe in more
> detail your definition of pathological inefficiency
> contrasted with ordinary inefficiency.
>
In my experience, running several large networks, allocating /29s
to lots of networks with exactly 5 hosts (pretty close to the worst-
case you can justify, 3 is about as bad a scenario as you can concoct,
but, 5 is pretty bad) is pretty unusual.  In the ordinary world,
these would be simply /29s assigned to each customer, and, therefore,
as long as the customer had need of at least 3 host addresses, you
would achieve 100% utilization credit for each /29 is far more
normal.  Sure, if you want to aggregate at the POP level, you still
have (as I pointed out), 3 more-specific prefixes per POP that you
are not using, but, as I also pointed out, with a minimal penalty
in number of routes (with 25 pops as in your example, a maximum of
75 additional prefixes... hardly a scaling issue for any modern IGP
unless you are really determined to run RIP), I just don't see it
as a likely normal scenario.  Plus, if you are only running one product
in your POP and it's this particularly inefficient one (from an
address consumption perspective), I'd be surprised in a real-world
scenario.  What is far less pathological is that you could probably
find some other use within that POP for at least one of those
other prefixes (which is enough to solve the problem if you can
use the /28 or /27).

However, even if your true case is actually as pathological as you state,
I would propose that you should aggregate your POPs in topological
groups of approximately 4+ POPs per group.  That way, you could make
much more efficient use of allocations to those POPS and still come
out with fewer prefixes in your routing tables outside of each POP group.

Point is, the case you described was relatively worst case and there are
alternatives even in that case.

> Also, I'd like to understand what were the issues that
> you ran into at Exodus. Were they also scaling issues
> in which the ARIN policies simply don't work for larger
> networks?
>
Not exactly.  The problems at Exodus were also somewhat pathological,
but, basically, each Exodus IDC had lots of direct external peering.
As such, each IDC was practically its own standalone ISP separate from
the rest of Exodus.  Sure, we had peering between our IDCs as well,
and a backbone, but most traffic was IDC<-->External direct.

For a variety of efficiencies, we liked to allocate at least a
/20 (and usually a /18) to each new IDC as it was coming on line.
Due to a variety of issues, we'd have circumstances where we had
to provide customer assignments for a new IDC 3-6 months before
most of the tenants were able to move into the IDC, or, even
general sales of IDC space in the facility began.  As a result,
we often found ourselves with 3-month allocations where we had
sub-allocated all of our available space, but, only assigned
5-10% of some of our sub-allocations.  We knew that in a month
or two, we'd have 80% utilization in those spaces, but, they
were enough to drag our overall numbers down to where ARIN didn't
want to give us new space for other new IDCs coming on line.

I believe that the current 6 month rule would compensate for
a majority of these issues.  I'm not convinced that the HD
ratio would help at all.

Owen


-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050223/22489886/attachment.sig>