[arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments (Michael K. Smith - Adhost)

Rudi Daniel rudi.daniel at gmail.com
Fri May 8 00:23:44 EDT 2009 

I oppose this policy proposal as written.
There has been a steady consumption rate since 2002 or thereabouts and
entire depletion suggested as middle 2011. Therefore I think this
policy proposal as written would have a negative effect on the
transition to 4byte ASNs. Anyway I would question that the
reachability issues are so significant as to demand such a change...I
also concur in general with Aaron argument also seems realistic.

Rudi


>
> I support this policy as written.  I think that forcing new ARIN members to use a resource that may cause them reachability issues on the
> Internet is a bad idea and this policy recognizes that problem and seeks to remedy it within a specific window of time.
>
> Regards,
>
> Mike
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
>> Behalf Of Member Services
>> Sent: Thursday, May 07, 2009 3:28 AM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments
>>
>> ARIN received the following policy proposal and is posting it to the
>> Public Policy Mailing List (PPML) in accordance with Policy
> Development
>> Process.
>>
>> This proposal is in the first stage of the Policy Development Process.
>> ARIN staff will perform the Clarity and Understanding step. Staff does
>> not evaluate the proposal at this time, their goal is to make sure
> that
>> they understand the proposal and believe the community will as well.
>> Staff will report their results to the ARIN Advisory Council (AC)
>> within
>> 10 days.
>>
>> The AC will review the proposal at their next regularly scheduled
>> meeting (if the period before the next regularly scheduled meeting is
>> less than 10 days, then the period may be extended to the subsequent
>> regularly scheduled meeting). The AC will decide how to utilize the
>> proposal and announce the decision to the PPML.
>>
>> In the meantime, the AC invites everyone to comment on the proposal on
>> the PPML, particularly their support or non-support and the reasoning
>> behind their opinion. Such participation contributes to a thorough
>> vetting and provides important guidance to the AC in their
>> deliberations.
>>
>> The ARIN Policy Development Process can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Mailing list subscription information can be found
>> at:https://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: Extend 16 bit ASN Assignments
>>
>> Proposal Originator: Marla Azinger
>>
>> Proposal Version: 1
>>
>> Submission Date: 6 May 2009
>>
>> Proposal type: Modify
>>
>> Policy term: Permanent
>>
>> Policy statement: This proposal is to modify section 5.1 in the NRPM
> to
>> extend the 16-bit ASN assignment timeframe for one more year further
>> than the current text. The expiration requiring removal of section 5.1
>> is also being removed.
>>
>> Rationale:
>>
>> Currently users of 32-bit ASN's are encountering technical issues that
>> they can't immediately overcome and therefore require 16-bit ASN's to
>> operate. As a result in the ARIN region to date, 204 of the 216 32-bit
>> ASN's that have been assigned have been returned and exchanged for a
> 16
>> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between
>> 32-bit and 16-bit ASN's. This proposal is to change the date on the
>> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN's to be
>> assigned. If these changes are made then ARIN RIR ASN policy will read
>> clearly and remove any misconceptions of 16-bit cutoff post run out
> and
>> enable technology to catch up to the ASN bit change. The expiration
>> date
>> that requires removal of section 5.1 after zero distinction occurs is
>> to
>> be removed. Instead section 5.1 will be left in place in the NRPM for
>> value added historical purposes.
>>
>> The revision of 5.1 would read as follows:
>>
>> 5.1 16-bit and 32-bit AS Numbers
>>
>> * Commencing 1 January 2007, ARIN will process applications that
>> specifically request 32-bit only AS Numbers and assign such AS numbers
>> as requested by the applicant. In the absence of any specific request
>> for a 32-bit only AS Number, a 16-bit only AS Number will be assigned.
>>
>> * Commencing 1 January 2009, ARIN will process applications that
>> specifically request 16-bit only AS Numbers and assign such AS Numbers
>> as requested by the applicant. In the absence of any specific request
>> for a 16-bit only AS Number, a 32-bit only AS Number will be assigned.
>>
>> * Commencing 1 January 2011, ARIN will cease to make any distinction
>> between 16-bit only AS Numbers and 32-bit only AS Numbers, and will
>> operate AS number assignments from an undifferentiated 32-bit AS
> Number
>> pool.
>>
>> Terminology
>>
>> * "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535
>>
>> * "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 -
>> 4,294,967,295
>>
>> * "32-bit AS Numbers" refers to AS Numbers in the range 0 -
>> 4,294,967,295
>>
>> Timetable for implementation: Immediate
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 07 May 2009 21:11:26 +0000
> From: Paul Vixie <vixie at isc.org>
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy -
>        comments as     requested
> To: ppml at arin.net
> Message-ID: <g34ovwlitd.fsf at nsa.vix.com>
> Content-Type: text/plain; charset=us-ascii
>
> kkargel at polartel.com ("Kevin Kargel") writes:
>
>>...
>> I realize that ARIN is not a democracy.  This was appropriately driven home
>> by Mr. Vixie at the Public Policy meeting.  ...
>
> to be clear, i said that ARIN is not a *direct* democracy.  i say this when
> polling for support/opposition to make clear to those in the room that we're
> not voting on a policy proposal, but rather gathering community input for use
> by the ARIN Advisory Committee (who are, BTW, elected) in their deliberations.
> --
> Paul Vixie
> Chair, ARIN BoT
> KI6YSY
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 7 May 2009 17:14:31 -0400
> From: Leo Bicknell <bicknell at ufp.org>
> Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN
>        Assignments
> To: arin-ppml at arin.net
> Message-ID: <20090507211431.GB80472 at ussenterprise.ufp.org>
> Content-Type: text/plain; charset="us-ascii"
>
> In a message written on Thu, May 07, 2009 at 03:57:03PM -0500, Kevin Kargel wrote:
>> My understanding of the current Cisco code we are using {12.2(33)} is that
>> it will route with 32bit ASN's it gets from BGP with no issue, but that I
>> can only enter a 16 bit ASN in to my config.  I haven't quite figured out
>> why this disparity exists.
>
> The answer is, "it's complicated."
>
> Google for "ASN 23456" to get some of the information.  The short
> form is that a 32 bit ASN can pass through a 16 bit ASN only network
> by using ASN 23456 and some transitional magic.
>
> Lots of people who think they need /all/ of their devices to support
> 32 bit ASN's do not, although depending on how you use these
> transition mechanisms it may complicate your path to move to 32 bit
> clean code.
>
> --
>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 825 bytes
> Desc: not available
> Url : http://lists.arin.net/pipermail/arin-ppml/attachments/20090507/8de16302/attachment-0001.bin
>
> ------------------------------
>
> Message: 4
> Date: Thu, 7 May 2009 14:36:15 -0700
> From: Aaron Hughes <aaronh at bind.com>
> Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN
>        Assignments
> To: Scott Leibrand <scottleibrand at gmail.com>
> Cc: arin-ppml at arin.net
> Message-ID: <20090507213615.GF67888 at trace.bind.com>
> Content-Type: text/plain; charset=us-ascii
>
> Fellow PPML participates,
>
> Just to make sure this is 100% clear.  RIPE is very likely to run out of 16bit ASNs next year as they appear to have no reclamation process (based on the 8 blocks of 1,024 ASNs recently assigned by IANA to the RIPE region). This means, operator support will happen.
>
> ARIN, on the other hand, will have 16 bit ASNs to give out until ~2013.  If we simply let ARIN give out 16it until they run out and they start issuing 32bit, we will get BOTH the benefit of continuing to hand out 16bit ASNs AND push for operational support.
>
> Global proliferation of 4-byte ASNs in 2010-2011 is a foregone conclusion.  More to the point, ARIN has ~3.5 years of 2-byte inventory because of their efficiency. So the proposal to stop ARIN from unifying the two pools is unnecessary.
>
> Cheers,
> Aaron
>
> On Thu, May 07, 2009 at 01:51:51PM -0700, Aaron Hughes wrote:
>>
>> I oppose this policy as written.
>>
>> Looking at ARIN's historical statistics, it appears as though ARIN issues 1,600 to 1,700 ASNs each year.
>>
>> Looking at IANA's stats:
>> 35840-36863 Assigned by ARIN 2005-02
>> 39936-40959 Assigned by ARIN 2006-03-29
>> 46080-47103 Assigned by ARIN 2008-03-27
>> 53248-54271 Assigned by ARIN 2009-04-21
>> 54272-55295 Assigned by ARIN 2009-04-21
>> Excluding April 2009, ARIN has only requested 3,072 ASNs since February 2005.
>>
>> Looking again at ARIN's historical statistics, they have issued 6,550 ASNs from 2005 through 2008, but have only gotten 3,072 ASNs from the IANA.
>>
>> Where's the difference?
>> In San Antonio, Leslie gave a presentation that included information about returned and revoked ASNs. Slide 10 of the presentation indicates 4,357 ASNs have been returned to ARIN since January 2005.
>>
>> So it looks like ARIN is recycling unused ASNs, prolonging the lifespan of the free 16-bit ASN pool.
>> Projecting this forward, at current consumption rates it should take approximately 32 months for ARIN to use up the 2,048 ASNs issued on 2009-04-21 by IANA, which puts us somewhere near December 2012.
>>
>> ARIN's historical statistics:
>> https://www.arin.net/knowledge/statistics/historical.html
>> IANA's stats:
>> http://www.iana.org/assignments/as-numbers/
>> Presentation foils:
>> https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesday/rsd.ppt
>>
>> Cheers,
>> Aaron
>>
>>
>> On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote:
>> > I disagree.  We are still waiting to get a release of the code train we
>> > use on the Cisco 7600 platform that supports 32-bit ASNs.  It sounds
>> > like they're finally getting close, but I think a further extension
>> > probably would be helpful.
>> >
>> > We'll have a much better view of what's required by the fall meeting,
>> > when this is up for discussion.  Since that will be our last chance to
>> > change policy before the current 1 Jan 2010 deadline, I definitely think
>> > this needs to be on the agenda.
>> >
>> > -Scott
>> >
>> > Owen DeLong wrote:
>> > > NIT:  The revised text of 5.1 (or at least specific amendments to it)
>> > > should be
>> > > stated as part of the Policy statement. The rationale section is not a
>> > > binding
>> > > part of the policy.
>> > >
>> > > Substance: This policy simply isn't needed. Current software for most
>> > > routers supports 32 bit ASNs. There's been ample warning for providers
>> > > and other organizations to update their management systems, scripts,
>> > > etc. If they haven't done it by now, they are only going to do it in
>> > > response
>> > > to the change actually happening.  Putting it off further does not really
>> > > benefit the community.
>> > >
>> > > I am opposed to this policy as written.
>> > >
>> > >> ## * ##
>> > >>
>> > >>
>> > >> Policy Proposal Name: Extend 16 bit ASN Assignments
>> > >>
>> > >> Proposal Originator: Marla Azinger
>> > >>
>> > >> Proposal Version: 1
>> > >>
>> > >> Submission Date: 6 May 2009
>> > >>
>> > >> Proposal type: Modify
>> > >>
>> > >> Policy term: Permanent
>> > >>
>> > >> Policy statement: This proposal is to modify section 5.1 in the NRPM to
>> > >> extend the 16-bit ASN assignment timeframe for one more year further
>> > >> than the current text. The expiration requiring removal of section 5.1
>> > >> is also being removed.
>> > >>
>> > >> Rationale:
>> > >>
>> > >> Currently users of 32-bit ASN?s are encountering technical issues that
>> > >> they can?t immediately overcome and therefore require 16-bit ASN?s to
>> > >> operate. As a result in the ARIN region to date, 204 of the 216 32-bit
>> > >> ASN?s that have been assigned have been returned and exchanged for a 16
>> > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction between
>> > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on the
>> > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s to be
>> > >> assigned. If these changes are made then ARIN RIR ASN policy will read
>> > >> clearly and remove any misconceptions of 16-bit cutoff post run out and
>> > >> enable technology to catch up to the ASN bit change. The expiration date
>> > >> that requires removal of section 5.1 after zero distinction occurs is to
>> > >> be removed. Instead section 5.1 will be left in place in the NRPM for
>> > >> value added historical purposes.
>> > >>
>> > >> The revision of 5.1 would read as follows:
>> > >>
>> > >> 5.1 16-bit and 32-bit AS Numbers
>> > >>
>> > >> ? Commencing 1 January 2007, ARIN will process applications that
>> > >> specifically request 32-bit only AS Numbers and assign such AS numbers
>> > >> as requested by the applicant. In the absence of any specific request
>> > >> for a 32-bit only AS Number, a 16-bit only AS Number will be assigned.
>> > >>
>> > >> ? Commencing 1 January 2009, ARIN will process applications that
>> > >> specifically request 16-bit only AS Numbers and assign such AS Numbers
>> > >> as requested by the applicant. In the absence of any specific request
>> > >> for a 16-bit only AS Number, a 32-bit only AS Number will be assigned.
>> > >>
>> > >> ? Commencing 1 January 2011, ARIN will cease to make any distinction
>> > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and will
>> > >> operate AS number assignments from an undifferentiated 32-bit AS Number
>> > >> pool.
>> > >>
>> > >> Terminology
>> > >>
>> > >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 - 65535
>> > >>
>> > >> ? "32-bit only AS Numbers" refers to AS Numbers in the range 65,536 -
>> > >> 4,294,967,295
>> > >>
>> > >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 -
>> > >> 4,294,967,295
>> > >>
>> > >> Timetable for implementation: Immediate
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> PPML
>> > >> You are receiving this message because you are subscribed to
>> > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> > >> Unsubscribe or manage your mailing list subscription at:
>> > >> http://lists.arin.net/mailman/listinfo/arin-ppml
>> > >> Please contact info at arin.net if you experience any issues.
>> > >
>> > > ------------------------------------------------------------------------
>> > >
>> > > _______________________________________________
>> > > PPML
>> > > You are receiving this message because you are subscribed to
>> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> > > Unsubscribe or manage your mailing list subscription at:
>> > > http://lists.arin.net/mailman/listinfo/arin-ppml
>> > > Please contact info at arin.net if you experience any issues.
>> > --
>> > PPML
>> > You are receiving this message because you are subscribed to
>> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> > Unsubscribe or manage your mailing list subscription at:
>> > http://lists.arin.net/mailman/listinfo/arin-ppml
>> > Please contact info at arin.net if you experience any issues.
>>
>> --
>>
>> Aaron Hughes
>> aaronh at bind.com
>> (703) 244-0427
>> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
>> http://www.bind.com/
>> --
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
> --
>
> Aaron Hughes
> aaronh at bind.com
> (703) 244-0427
> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
> http://www.bind.com/
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 7 May 2009 17:45:04 -0400
> From: "Chris Malayter" <cmalayter at switchanddata.com>
> Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN
>        Assignments
> To: "Aaron Hughes" <aaronh at bind.com>
> Cc: arin-ppml at arin.net
> Message-ID:
>        <6394AFBFA9558A4AACC7B19F5FD3057901AEC41D at SDCORPMAIL01.northamerica.switchanddata.org>
>
> Content-Type: text/plain;       charset="us-ascii"
>
> Just to give a little background, there's a lot of information out there
> on this issue.  It's likely that other RIR's will run out of 16bit ASN's
> before ARIN does if they do not create a re-allocation policy to help
> their 16bit pools last after their block allocations come to an end.
> Vendor support is VERY scattered depending on vendor and platform.  Greg
> Henkins at F10 and I have done several presentations on this very topic at
> past NANOGs/GPF's/APRICOT's.  The bottom line is that AS23456 is not a
> very scalable nor workable solution for many people.  I think inevitably
> we are going to have to extend the 32 bit deadline to accommodate
> vendors integration into mainline builds for legacy equipment that is
> still being supported.  From the data I've been looking at July of 2011
> appears to be the exhaust for the first RIR.  As such, I am fine with
> the way that this policy is written, though I think some flexibility put
> into the policy for the cutoff for 32bit only asns might be the best
> bet.
>
> -Chris
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Aaron Hughes
> Sent: Thursday, May 07, 2009 5:36 PM
> To: Scott Leibrand
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments
>
> Fellow PPML participates,
>
> Just to make sure this is 100% clear.  RIPE is very likely to run out of
> 16bit ASNs next year as they appear to have no reclamation process
> (based on the 8 blocks of 1,024 ASNs recently assigned by IANA to the
> RIPE region). This means, operator support will happen.
>
> ARIN, on the other hand, will have 16 bit ASNs to give out until ~2013.
> If we simply let ARIN give out 16it until they run out and they start
> issuing 32bit, we will get BOTH the benefit of continuing to hand out
> 16bit ASNs AND push for operational support.
>
> Global proliferation of 4-byte ASNs in 2010-2011 is a foregone
> conclusion.  More to the point, ARIN has ~3.5 years of 2-byte inventory
> because of their efficiency. So the proposal to stop ARIN from unifying
> the two pools is unnecessary.
>
> Cheers,
> Aaron
>
> On Thu, May 07, 2009 at 01:51:51PM -0700, Aaron Hughes wrote:
>>
>> I oppose this policy as written.
>>
>> Looking at ARIN's historical statistics, it appears as though ARIN
> issues 1,600 to 1,700 ASNs each year.
>>
>> Looking at IANA's stats:
>> 35840-36863 Assigned by ARIN 2005-02
>> 39936-40959 Assigned by ARIN 2006-03-29
>> 46080-47103 Assigned by ARIN 2008-03-27
>> 53248-54271 Assigned by ARIN 2009-04-21
>> 54272-55295 Assigned by ARIN 2009-04-21
>> Excluding April 2009, ARIN has only requested 3,072 ASNs since
> February 2005.
>>
>> Looking again at ARIN's historical statistics, they have issued 6,550
> ASNs from 2005 through 2008, but have only gotten 3,072 ASNs from the
> IANA.
>>
>> Where's the difference?
>> In San Antonio, Leslie gave a presentation that included information
> about returned and revoked ASNs. Slide 10 of the presentation indicates
> 4,357 ASNs have been returned to ARIN since January 2005.
>>
>> So it looks like ARIN is recycling unused ASNs, prolonging the
> lifespan of the free 16-bit ASN pool.
>> Projecting this forward, at current consumption rates it should take
> approximately 32 months for ARIN to use up the 2,048 ASNs issued on
> 2009-04-21 by IANA, which puts us somewhere near December 2012.
>>
>> ARIN's historical statistics:
>> https://www.arin.net/knowledge/statistics/historical.html
>> IANA's stats:
>> http://www.iana.org/assignments/as-numbers/
>> Presentation foils:
>>
> https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesd
> ay/rsd.ppt
>>
>> Cheers,
>> Aaron
>>
>>
>> On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote:
>> > I disagree.  We are still waiting to get a release of the code train
> we
>> > use on the Cisco 7600 platform that supports 32-bit ASNs.  It sounds
>
>> > like they're finally getting close, but I think a further extension
>> > probably would be helpful.
>> >
>> > We'll have a much better view of what's required by the fall
> meeting,
>> > when this is up for discussion.  Since that will be our last chance
> to
>> > change policy before the current 1 Jan 2010 deadline, I definitely
> think
>> > this needs to be on the agenda.
>> >
>> > -Scott
>> >
>> > Owen DeLong wrote:
>> > > NIT:  The revised text of 5.1 (or at least specific amendments to
> it)
>> > > should be
>> > > stated as part of the Policy statement. The rationale section is
> not a
>> > > binding
>> > > part of the policy.
>> > >
>> > > Substance: This policy simply isn't needed. Current software for
> most
>> > > routers supports 32 bit ASNs. There's been ample warning for
> providers
>> > > and other organizations to update their management systems,
> scripts,
>> > > etc. If they haven't done it by now, they are only going to do it
> in
>> > > response
>> > > to the change actually happening.  Putting it off further does not
> really
>> > > benefit the community.
>> > >
>> > > I am opposed to this policy as written.
>> > >
>> > >> ## * ##
>> > >>
>> > >>
>> > >> Policy Proposal Name: Extend 16 bit ASN Assignments
>> > >>
>> > >> Proposal Originator: Marla Azinger
>> > >>
>> > >> Proposal Version: 1
>> > >>
>> > >> Submission Date: 6 May 2009
>> > >>
>> > >> Proposal type: Modify
>> > >>
>> > >> Policy term: Permanent
>> > >>
>> > >> Policy statement: This proposal is to modify section 5.1 in the
> NRPM to
>> > >> extend the 16-bit ASN assignment timeframe for one more year
> further
>> > >> than the current text. The expiration requiring removal of
> section 5.1
>> > >> is also being removed.
>> > >>
>> > >> Rationale:
>> > >>
>> > >> Currently users of 32-bit ASN?s are encountering technical issues
> that
>> > >> they can?t immediately overcome and therefore require 16-bit
> ASN?s to
>> > >> operate. As a result in the ARIN region to date, 204 of the 216
> 32-bit
>> > >> ASN?s that have been assigned have been returned and exchanged
> for a 16
>> > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction
> between
>> > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on
> the
>> > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s
> to be
>> > >> assigned. If these changes are made then ARIN RIR ASN policy will
> read
>> > >> clearly and remove any misconceptions of 16-bit cutoff post run
> out and
>> > >> enable technology to catch up to the ASN bit change. The
> expiration date
>> > >> that requires removal of section 5.1 after zero distinction
> occurs is to
>> > >> be removed. Instead section 5.1 will be left in place in the NRPM
> for
>> > >> value added historical purposes.
>> > >>
>> > >> The revision of 5.1 would read as follows:
>> > >>
>> > >> 5.1 16-bit and 32-bit AS Numbers
>> > >>
>> > >> ? Commencing 1 January 2007, ARIN will process applications that
>> > >> specifically request 32-bit only AS Numbers and assign such AS
> numbers
>> > >> as requested by the applicant. In the absence of any specific
> request
>> > >> for a 32-bit only AS Number, a 16-bit only AS Number will be
> assigned.
>> > >>
>> > >> ? Commencing 1 January 2009, ARIN will process applications that
>> > >> specifically request 16-bit only AS Numbers and assign such AS
> Numbers
>> > >> as requested by the applicant. In the absence of any specific
> request
>> > >> for a 16-bit only AS Number, a 32-bit only AS Number will be
> assigned.
>> > >>
>> > >> ? Commencing 1 January 2011, ARIN will cease to make any
> distinction
>> > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and
> will
>> > >> operate AS number assignments from an undifferentiated 32-bit AS
> Number
>> > >> pool.
>> > >>
>> > >> Terminology
>> > >>
>> > >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 -
> 65535
>> > >>
>> > >> ? "32-bit only AS Numbers" refers to AS Numbers in the range
> 65,536 -
>> > >> 4,294,967,295
>> > >>
>> > >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 -
>> > >> 4,294,967,295
>> > >>
>> > >> Timetable for implementation: Immediate
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> PPML
>> > >> You are receiving this message because you are subscribed to
>> > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> > >> Unsubscribe or manage your mailing list subscription at:
>> > >> http://lists.arin.net/mailman/listinfo/arin-ppml
>> > >> Please contact info at arin.net if you experience any issues.
>> > >
>> > >
> ------------------------------------------------------------------------
>> > >
>> > > _______________________________________________
>> > > PPML
>> > > You are receiving this message because you are subscribed to
>> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> > > Unsubscribe or manage your mailing list subscription at:
>> > > http://lists.arin.net/mailman/listinfo/arin-ppml
>> > > Please contact info at arin.net if you experience any issues.
>> > --
>> > PPML
>> > You are receiving this message because you are subscribed to
>> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> > Unsubscribe or manage your mailing list subscription at:
>> > http://lists.arin.net/mailman/listinfo/arin-ppml
>> > Please contact info at arin.net if you experience any issues.
>>
>> --
>>
>> Aaron Hughes
>> aaronh at bind.com
>> (703) 244-0427
>> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
>> http://www.bind.com/
>> --
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
> --
>
> Aaron Hughes
> aaronh at bind.com
> (703) 244-0427
> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
> http://www.bind.com/
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 47, Issue 32
> *****************************************
>



-- 
Rudi Daniel
Independent Consultant
e Business
www.svgpso.org
1 784 533 7321

More information about the ARIN-PPML mailing list