From Keith at jcc.com  Sat Sep  1 00:23:50 2007
From: Keith at jcc.com (Keith W. Hare)
Date: Sat, 1 Sep 2007 00:23:50 -0400
Subject: [ppml] Policy Proposal 2007-15: Authentication of
	Legacy	Resources - version 1.1
Message-ID: <933be923a2dcb358a88b584c6b12359f46d8e956@jcc.com>

 

> -----Original Message-----
> From: Scott Leibrand [mailto:sleibrand at internap.com] 
> 
> The policy states that the RSA should be ready on January 1, 
> 2008.  If that doesn't happen until December, then the 
> following section of the policy proposal will apply:
> 
> > If this policy is
> > implemented after December 31, 2007, the trigger dates in 
> the policy 
> > should be adjusted appropriately.
> 
> The intent of the policy proposal is to provide 1 year from 
> the date the RSA becomes available and the date that it 
> becomes required for all updates to legacy registrations.

That's not what the policy says.  It says "No changes shall be made to
legacy resource records which are not covered by a registration services
agreement after December 31, 2007."

So, the RSA is ready on January 1, 2008, but legacy resource holders
can't update stuff that is not covered by the RSA after December 31,
2007?  There is not a year there.

I would be happier if the year you claim is the intent were actually in
the proposed policy. I would be even happier to leave the sentence out
entirely.

Why do we need a stick today for the legacy address holders who have not
responded to the invitation that has not yet been issued?

Keith




From jr at jrw.org  Sat Sep  1 07:54:49 2007
From: jr at jrw.org (J. R. Westmoreland)
Date: Sat, 1 Sep 2007 05:54:49 -0600
Subject: [ppml] Legacy /24s
References: <mailman.4174.1188583766.29428.ppml@arin.net>	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<46D8D83A.7020306@Dilkie.com> 
Message-ID: <000101c7ec8e$e9489df0$bbd9d9d0$@org>

Let's try this again and send it to the whole list this time.
Sorry, Lee, for causing you to get a double copy.

----------------------------------------
J. R. Westmoreland
Custom Computers & Consulting
Email: jr at jrw.org
 

> -----Original Message-----
> From: J. R. Westmoreland [mailto:jr at jrw.org]
> Sent: Saturday, September 01, 2007 5:48 AM
> To: 'Lee Dilkie'
> Subject: RE: [ppml] Legacy /24s
> 
> Mack,
> 
> I, sinceI fall into your category, being a very small consulting
> company, would support your proposal whole heartedly.
> 
> Maybe I'll go find the form, and using some of your good wording, see
> about making a proposal. I figure that it wouldn't start much more fuss
> than there already is. <grin>
> 
> J. R.
> 
> ----------------------------------------
> J. R. Westmoreland
> Email: jr at jrw.org
> 
> > -----Original Message-----
> > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf
> Of
> > Lee Dilkie
> > Sent: Friday, August 31, 2007 9:11 PM
> > To: mack
> > Cc: ppml at arin.net
> > Subject: Re: [ppml] Legacy /24s
> >
> > What?
> >
> > no restrictive RSA?
> >
> > no outrageous $100/yr scalper fee?
> >
> > no justification of usage?
> >
> > You're daft man!
> >
> > A common sense proposal like this has no place on ppml.
> >
> > {pardon my sarcasm, been here too long I guess. But being a /24
> legacy
> > holder in the same shoes as probably many, this would fit the bill
> but
> > I
> > wouldn't hold my breath}
> >
> > -lee
> >
> > mack wrote:
> > > I don't have the time to write it but I would support a
> > > proposal that gives legacy /24 holders a permanent IPv4 fee waiver,
> > > an efficient usage waiver so that they don't have to worry about
> > reclamation,
> > > and allows assignment of an appropriate sized block of IPv6 if they
> > > start paying a fee after some specified date (ie. Jan 1, 2010) or
> > whenever
> > > the regular IPv6 waiver expires if it is extended beyond this date.
> > > With the only contingency that the space be actively used in the
> DFZ
> > > or showing that the space is in use in a manner that cannot be
> > readily
> > > replaced by 1918 space.
> > >
> > > I personally feel that the /24 space needs to be handled
> differently
> > than
> > > the /16 and /8 space.
> > >
> > > 1) Because there are more of these than the others numerically.
> > > 2) Because there is no significant reclamation benefit if they are
> > being used.
> > > 3) Most of these are individuals or small companies that don't have
> > significant resources.
> > >
> > > The use contingency allows for private use in organizations that
> may
> > find
> > > it difficult to convert to 1918 space.
> > >
> > > This would be neutral in overall effect.  It cost them nothing
> unless
> > they want IPv6 space.
> > > It will encourage adoption of IPv6 by these users.  It will move a
> > significant number of
> > > legacy blocks under a policy umbrella.
> > >
> > > This obviously would be for the 2008 timeframe.
> > >
> > >
> > > LR Mack McBride
> > > Network Administrator
> > > Alpha Red, Inc.
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed to the
> ARIN
> > Public Policy
> > > Mailing List (PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
> > Member Services
> > > Help Desk at 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 (PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
> > Member Services
> > Help Desk at info at arin.net if you experience any issues.




From Lee at Dilkie.com  Sat Sep  1 08:36:53 2007
From: Lee at Dilkie.com (Lee Dilkie)
Date: Sat, 01 Sep 2007 08:36:53 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <000101c7ec8e$e9489df0$bbd9d9d0$@org>
References: <mailman.4174.1188583766.29428.ppml@arin.net>	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>	<46D8D83A.7020306@Dilkie.com>
	<000101c7ec8e$e9489df0$bbd9d9d0$@org>
Message-ID: <46D95CE5.5020807@Dilkie.com>

The list might as well see my reply back...

Hey Mack,

I agree with you. I think I even proposed a very minor fee as well ($5
is reasonable considering that all a legacy holder gets is an entry in a
DB).

I proposed something similar a few months ago, well, I "argued" that a
number of the legacy holders are interested in ipv6 and perhaps should
be given PI space to aid in general adoption. The argument being that
these folks were early adopters of the original network and created the
demand that we have today. We definitely need something like this for
ipv6, something beyond just being a network infrastructure replacement
or it'll be a very slow adoption rate.

Anyway, your "proposal" is spot on, for me anyway. I'm currently playing
with ipv6 (I am a s/w programmer) and I have two ipv6 networks via
tunnel brokers but I would like to have a small bit (/48) of PI space.
The tunnels are okay for connectivity but they have high latency
(>200ms) and unsuitable for a number of things (I'm a VoIP programmer...
having a chat with 200ms+ is not very pleasant). My ISP has no IPv6 yet
but they've not seen any demand. I think if I, a current business
customer they are routing for, asks to route my IPv6 PI block, it might
make them think harder about their own deployment. (faced with losing
existing business, if I should move my network to another ISP that
offers v6).

Are you going to write this up as a formal proposal?

-lee



J. R. Westmoreland wrote:
> Let's try this again and send it to the whole list this time.
> Sorry, Lee, for causing you to get a double copy.
>
> ----------------------------------------
> J. R. Westmoreland
> Custom Computers & Consulting
> Email: jr at jrw.org
>  
>
>   
>> -----Original Message-----
>> From: J. R. Westmoreland [mailto:jr at jrw.org]
>> Sent: Saturday, September 01, 2007 5:48 AM
>> To: 'Lee Dilkie'
>> Subject: RE: [ppml] Legacy /24s
>>
>> Mack,
>>
>> I, sinceI fall into your category, being a very small consulting
>> company, would support your proposal whole heartedly.
>>
>> Maybe I'll go find the form, and using some of your good wording, see
>> about making a proposal. I figure that it wouldn't start much more fuss
>> than there already is. <grin>
>>
>> J. R.
>>
>> ----------------------------------------
>> J. R. Westmoreland
>> Email: jr at jrw.org
>>
>>     
>>> -----Original Message-----
>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf
>>>       
>> Of
>>     
>>> Lee Dilkie
>>> Sent: Friday, August 31, 2007 9:11 PM
>>> To: mack
>>> Cc: ppml at arin.net
>>> Subject: Re: [ppml] Legacy /24s
>>>
>>> What?
>>>
>>> no restrictive RSA?
>>>
>>> no outrageous $100/yr scalper fee?
>>>
>>> no justification of usage?
>>>
>>> You're daft man!
>>>
>>> A common sense proposal like this has no place on ppml.
>>>
>>> {pardon my sarcasm, been here too long I guess. But being a /24
>>>       
>> legacy
>>     
>>> holder in the same shoes as probably many, this would fit the bill
>>>       
>> but
>>     
>>> I
>>> wouldn't hold my breath}
>>>
>>> -lee
>>>
>>> mack wrote:
>>>       
>>>> I don't have the time to write it but I would support a
>>>> proposal that gives legacy /24 holders a permanent IPv4 fee waiver,
>>>> an efficient usage waiver so that they don't have to worry about
>>>>         
>>> reclamation,
>>>       
>>>> and allows assignment of an appropriate sized block of IPv6 if they
>>>> start paying a fee after some specified date (ie. Jan 1, 2010) or
>>>>         
>>> whenever
>>>       
>>>> the regular IPv6 waiver expires if it is extended beyond this date.
>>>> With the only contingency that the space be actively used in the
>>>>         
>> DFZ
>>     
>>>> or showing that the space is in use in a manner that cannot be
>>>>         
>>> readily
>>>       
>>>> replaced by 1918 space.
>>>>
>>>> I personally feel that the /24 space needs to be handled
>>>>         
>> differently
>>     
>>> than
>>>       
>>>> the /16 and /8 space.
>>>>
>>>> 1) Because there are more of these than the others numerically.
>>>> 2) Because there is no significant reclamation benefit if they are
>>>>         
>>> being used.
>>>       
>>>> 3) Most of these are individuals or small companies that don't have
>>>>         
>>> significant resources.
>>>       
>>>> The use contingency allows for private use in organizations that
>>>>         
>> may
>>     
>>> find
>>>       
>>>> it difficult to convert to 1918 space.
>>>>
>>>> This would be neutral in overall effect.  It cost them nothing
>>>>         
>> unless
>>     
>>> they want IPv6 space.
>>>       
>>>> It will encourage adoption of IPv6 by these users.  It will move a
>>>>         
>>> significant number of
>>>       
>>>> legacy blocks under a policy umbrella.
>>>>
>>>> This obviously would be for the 2008 timeframe.
>>>>
>>>>
>>>> LR Mack McBride
>>>> Network Administrator
>>>> Alpha Red, Inc.
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to the
>>>>         
>> ARIN
>>     
>>> Public Policy
>>>       
>>>> Mailing List (PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
>>>>         
>>> Member Services
>>>       
>>>> Help Desk at 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 (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
>>> Member Services
>>> Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>   


From jr at jrw.org  Sat Sep  1 08:48:28 2007
From: jr at jrw.org (J. R. Westmoreland)
Date: Sat, 1 Sep 2007 06:48:28 -0600
Subject: [ppml] Legacy /24s
In-Reply-To: <46D95CE5.5020807@Dilkie.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>	<46D8D83A.7020306@Dilkie.com>	<000101c7ec8e$e9489df0$bbd9d9d0$@org>
	<46D95CE5.5020807@Dilkie.com>
Message-ID: <000001c7ec96$67dfacb0$379f0610$@org>

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
> Lee Dilkie
> Sent: Saturday, September 01, 2007 6:37 AM
> To: 'ARIN Address Policy'
> Subject: Re: [ppml] Legacy /24s
> 
> The list might as well see my reply back...
> 
> Hey Mack,
> 
> I agree with you. I think I even proposed a very minor fee as well ($5
> is reasonable considering that all a legacy holder gets is an entry in
> a
> DB).
> 

I'd even be willing to make that $10/year with the ability to purchase
multiple years at one time.

> I proposed something similar a few months ago, well, I "argued" that a
> number of the legacy holders are interested in ipv6 and perhaps should
> be given PI space to aid in general adoption. The argument being that
> these folks were early adopters of the original network and created the
> demand that we have today. We definitely need something like this for
> ipv6, something beyond just being a network infrastructure replacement
> or it'll be a very slow adoption rate.

Agreed.

> 
> Anyway, your "proposal" is spot on, for me anyway. I'm currently
> playing
> with ipv6 (I am a s/w programmer) and I have two ipv6 networks via
> tunnel brokers but I would like to have a small bit (/48) of PI space.
> The tunnels are okay for connectivity but they have high latency
> (>200ms) and unsuitable for a number of things (I'm a VoIP
> programmer...
> having a chat with 200ms+ is not very pleasant). My ISP has no IPv6 yet
> but they've not seen any demand. I think if I, a current business
> customer they are routing for, asks to route my IPv6 PI block, it might
> make them think harder about their own deployment. (faced with losing
> existing business, if I should move my network to another ISP that
> offers v6).
> 
> Are you going to write this up as a formal proposal?

I'm interested and would be willing to help or do the writing with some
suggestions from both of you.

> 
> -lee
> 
> 
> 
> J. R. Westmoreland wrote:
> > Let's try this again and send it to the whole list this time.
> > Sorry, Lee, for causing you to get a double copy.
> >
> > ----------------------------------------
> > J. R. Westmoreland
> > Custom Computers & Consulting
> > Email: jr at jrw.org
> >
> >
> >
> >> -----Original Message-----
> >> From: J. R. Westmoreland [mailto:jr at jrw.org]
> >> Sent: Saturday, September 01, 2007 5:48 AM
> >> To: 'Lee Dilkie'
> >> Subject: RE: [ppml] Legacy /24s
> >>
> >> Mack,
> >>
> >> I, sinceI fall into your category, being a very small consulting
> >> company, would support your proposal whole heartedly.
> >>
> >> Maybe I'll go find the form, and using some of your good wording,
> see
> >> about making a proposal. I figure that it wouldn't start much more
> fuss
> >> than there already is. <grin>
> >>
> >> J. R.
> >>
> >> ----------------------------------------
> >> J. R. Westmoreland
> >> Email: jr at jrw.org
> >>
> >>
> >>> -----Original Message-----
> >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On
> Behalf
> >>>
> >> Of
> >>
> >>> Lee Dilkie
> >>> Sent: Friday, August 31, 2007 9:11 PM
> >>> To: mack
> >>> Cc: ppml at arin.net
> >>> Subject: Re: [ppml] Legacy /24s
> >>>
> >>> What?
> >>>
> >>> no restrictive RSA?
> >>>
> >>> no outrageous $100/yr scalper fee?
> >>>
> >>> no justification of usage?
> >>>
> >>> You're daft man!
> >>>
> >>> A common sense proposal like this has no place on ppml.
> >>>
> >>> {pardon my sarcasm, been here too long I guess. But being a /24
> >>>
> >> legacy
> >>
> >>> holder in the same shoes as probably many, this would fit the bill
> >>>
> >> but
> >>
> >>> I
> >>> wouldn't hold my breath}
> >>>
> >>> -lee
> >>>
> >>> mack wrote:
> >>>
> >>>> I don't have the time to write it but I would support a
> >>>> proposal that gives legacy /24 holders a permanent IPv4 fee
> waiver,
> >>>> an efficient usage waiver so that they don't have to worry about
> >>>>
> >>> reclamation,
> >>>
> >>>> and allows assignment of an appropriate sized block of IPv6 if
> they
> >>>> start paying a fee after some specified date (ie. Jan 1, 2010) or
> >>>>
> >>> whenever
> >>>
> >>>> the regular IPv6 waiver expires if it is extended beyond this
> date.
> >>>> With the only contingency that the space be actively used in the
> >>>>
> >> DFZ
> >>
> >>>> or showing that the space is in use in a manner that cannot be
> >>>>
> >>> readily
> >>>
> >>>> replaced by 1918 space.
> >>>>
> >>>> I personally feel that the /24 space needs to be handled
> >>>>
> >> differently
> >>
> >>> than
> >>>
> >>>> the /16 and /8 space.
> >>>>
> >>>> 1) Because there are more of these than the others numerically.
> >>>> 2) Because there is no significant reclamation benefit if they are
> >>>>
> >>> being used.
> >>>
> >>>> 3) Most of these are individuals or small companies that don't
> have
> >>>>
> >>> significant resources.
> >>>
> >>>> The use contingency allows for private use in organizations that
> >>>>
> >> may
> >>
> >>> find
> >>>
> >>>> it difficult to convert to 1918 space.
> >>>>
> >>>> This would be neutral in overall effect.  It cost them nothing
> >>>>
> >> unless
> >>
> >>> they want IPv6 space.
> >>>
> >>>> It will encourage adoption of IPv6 by these users.  It will move a
> >>>>
> >>> significant number of
> >>>
> >>>> legacy blocks under a policy umbrella.
> >>>>
> >>>> This obviously would be for the 2008 timeframe.
> >>>>
> >>>>
> >>>> LR Mack McBride
> >>>> Network Administrator
> >>>> Alpha Red, Inc.
> >>>> _______________________________________________
> >>>> PPML
> >>>> You are receiving this message because you are subscribed to the
> >>>>
> >> ARIN
> >>
> >>> Public Policy
> >>>
> >>>> Mailing List (PPML at arin.net).
> >>>> Unsubscribe or manage your mailing list subscription at:
> >>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the
> ARIN
> >>>>
> >>> Member Services
> >>>
> >>>> Help Desk at 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 (PPML at arin.net).
> >>> Unsubscribe or manage your mailing list subscription at:
> >>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
> >>> Member Services
> >>> Help Desk at 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 (PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
> Member Services
> > Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
> Member Services
> Help Desk at info at arin.net if you experience any issues.




From paul at vix.com  Sat Sep  1 10:36:46 2007
From: paul at vix.com (Paul Vixie)
Date: Sat, 01 Sep 2007 14:36:46 +0000
Subject: [ppml] Legacy /24s
In-Reply-To: Your message of "Sat, 01 Sep 2007 05:54:49 CST."
	<000101c7ec8e$e9489df0$bbd9d9d0$@org> 
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<46D8D83A.7020306@Dilkie.com>
	<000101c7ec8e$e9489df0$bbd9d9d0$@org> 
Message-ID: <8582.1188657406@sa.vix.com>

> > I, since I fall into your category, being a very small consulting
> > company, would support your proposal whole heartedly.
> > ...
> > J. R.

192.5.5.0/24 was once held by a small consulting company.  if that were
still the case, i would not feel that that consulting company's ability
to multihome was worth a slot in every routing table on every router on
the internet, given how globally expensive that has turned out to be.

(the block was later used for a root name server, and then, later, given
into the control of a 501(c)(3) nonprofit who operates that server, and
for that, i think the community of router owners would say it's worth a
routing slot... i'm just saying if that hadn't happened, i'd've stopped
using the space by now, on a "think globally, act locally" basis.)


From bicknell at ufp.org  Sat Sep  1 10:45:53 2007
From: bicknell at ufp.org (Leo Bicknell)
Date: Sat, 1 Sep 2007 10:45:53 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
Message-ID: <20070901144553.GA494@ussenterprise.ufp.org>

In a message written on Fri, Aug 31, 2007 at 03:03:08PM -0500, mack wrote:
> 3) Most of these are individuals or small companies that don't have significant resources.

So individuals and small businesses should be allowed to eat up
routing slots in tens of thousands of routers worldwide collectively
costing ISP's millions of dollars in capital, if and only if they
were smart enough to get an "early" IPv4 allocation?

What about the billions of other individuals and millions of other
businesses in the world?  Why do they not qualify for such special
treatment?

-- 
       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/20070901/40df54dd/attachment.sig>

From andrew.dul at quark.net  Sat Sep  1 12:32:46 2007
From: andrew.dul at quark.net (Andrew Dul)
Date: Sat, 01 Sep 2007 09:32:46 -0700
Subject: [ppml] Policy Proposal 2007-15: Authentication
 ofLegacyResources - version 1.1
In-Reply-To: <59bca099a787ac5b0479b5655fda49b446d88cd4@jcc.com>
Message-ID: <20070901163246.CB53B1446B8@smtp2.arin.net>

At 05:47 PM 8/31/2007 -0400, Keith W. Hare wrote:
> 
>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
>> Behalf Of Scott Leibrand
>> Sent: Friday, August 31, 2007 4:54 PM
>> To: David Conrad
>> Cc: Public Policy Mailing List
>> Subject: Re: [ppml] Policy Proposal 2007-15: Authentication 
>> of Legacy Resources - version 1.1
>> 
>> David Conrad wrote:
>> > On Aug 31, 2007, at 10:20 AM, Member Services wrote:
>> >   
>> >> 1.      Policy Proposal Name: Authentication of Legacy Resources
>> >> No changes shall be made to legacy resource records which are not
>> >> covered by a registration services agreement after 
>> December 31, 2007.
>> >>     
>> >
>> > I suspect that refusal to update registration information 
>> will likely  
>> > not be very popular with folks trying to fight spam, 
>> phishing, fraud,  
>> > etc. It could also have the effect of spurring the 
>> establishment of  
>> > alternative registries that maintain "accurate" information.
>> 
>> Is requiring registrants to sign a contract that codifies 
>> their rights 
>> and responsibilities "refusal"?  I don't see the requirements 
>> here as at 
>> all onerous, and wouldn't see alternate registries as viable.  As an 
>> ISP, if a customer asked me to route space based on the 
>> information in 
>> some alternate registry because they were unwilling to sign 
>> an RSA and 
>> pay ARIN $100/year, I would consider that suspicious enough to have 
>> another abuse scrub run on the customer, and refuse to route 
>> the space.
>
>By the time the RSA for legacy resource holders is available, and ARIN
>starts an outreach to legacy resoure holders, it is going to be
>December, 2007.
>
>How about saying "No changes shall be made to legacy resource records
>which are not covered by a registration services agreement after
>December 31, 2008."

If the date of implementation is a stumbling block, then it certainly can
be changed to accomodate the consensus of the community.

Andrew




From jr at jrw.org  Sat Sep  1 12:35:30 2007
From: jr at jrw.org (J. R. Westmoreland)
Date: Sat, 1 Sep 2007 10:35:30 -0600
Subject: [ppml] FW:  Legacy /24s
Message-ID: <000d01c7ecb6$1f547460$5dfd5d20$@org>



----------------------------------------
J. R. Westmoreland
Email: jr at jrw.org
 

> -----Original Message-----
> From: J. R. Westmoreland [mailto:jr at jrw.org]
> Sent: Saturday, September 01, 2007 10:32 AM
> To: 'Leo Bicknell'
> Subject: RE: [ppml] Legacy /24s
> 
> So, this is not for the users but only for the ISPs and their money
> investments?
> If we want to go back to it maybe small people should band together
> with the BIG legacy holders and really have a good time.
> 
> ----------------------------------------
> J. R. Westmoreland
> Email: jr at jrw.org
> 
> 
> > -----Original Message-----
> > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf
> Of
> > Leo Bicknell
> > Sent: Saturday, September 01, 2007 8:46 AM
> > To: ppml at arin.net
> > Subject: Re: [ppml] Legacy /24s
> >
> > In a message written on Fri, Aug 31, 2007 at 03:03:08PM -0500, mack
> > wrote:
> > > 3) Most of these are individuals or small companies that don't have
> > significant resources.
> >
> > So individuals and small businesses should be allowed to eat up
> routing
> > slots in tens of thousands of routers worldwide collectively costing
> > ISP's millions of dollars in capital, if and only if they were smart
> > enough to get an "early" IPv4 allocation?
> >
> > What about the billions of other individuals and millions of other
> > businesses in the world?  Why do they not qualify for such special
> > treatment?
> >
> > --
> >        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




From jr at jrw.org  Sat Sep  1 12:35:39 2007
From: jr at jrw.org (J. R. Westmoreland)
Date: Sat, 1 Sep 2007 10:35:39 -0600
Subject: [ppml] FW:  Legacy /24s
Message-ID: <000e01c7ecb6$24d7e480$6e87ad80$@org>



----------------------------------------
J. R. Westmoreland
Email: jr at jrw.org
 

> -----Original Message-----
> From: J. R. Westmoreland [mailto:jr at jrw.org]
> Sent: Saturday, September 01, 2007 10:33 AM
> To: 'Paul Vixie'
> Subject: RE: [ppml] Legacy /24s
> 
> That is silly. We are talking about ONE group and not MANY. The item is
> not even close to being the same.
> 
> ----------------------------------------
> J. R. Westmoreland
> Email: jr at jrw.org
> 
> 
> > -----Original Message-----
> > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf
> Of
> > Paul Vixie
> > Sent: Saturday, September 01, 2007 8:37 AM
> > To: 'ARIN Address Policy'
> > Subject: Re: [ppml] Legacy /24s
> >
> > > > I, since I fall into your category, being a very small consulting
> > > > company, would support your proposal whole heartedly.
> > > > ...
> > > > J. R.
> >
> > 192.5.5.0/24 was once held by a small consulting company.  if that
> were
> > still the case, i would not feel that that consulting company's
> ability
> > to multihome was worth a slot in every routing table on every router
> on
> > the internet, given how globally expensive that has turned out to be.
> >
> > (the block was later used for a root name server, and then, later,
> > given
> > into the control of a 501(c)(3) nonprofit who operates that server,
> and
> > for that, i think the community of router owners would say it's worth
> a
> > routing slot... i'm just saying if that hadn't happened, i'd've
> stopped
> > using the space by now, on a "think globally, act locally" basis.)
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the ARIN
> > Public Policy
> > Mailing List (PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
> > Member Services
> > Help Desk at info at arin.net if you experience any issues.




From briand at ca.afilias.info  Sat Sep  1 13:26:42 2007
From: briand at ca.afilias.info (briand at ca.afilias.info)
Date: Sat, 1 Sep 2007 13:26:42 -0400 (EDT)
Subject: [ppml] Legacy /24s
In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphare
	d.local>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
Message-ID: <63408.74.122.168.81.1188667602.squirrel@look.libertyrms.com>

> I don't have the time to write it but I would support a
> proposal that gives legacy /24 holders a permanent IPv4 fee waiver,
> an efficient usage waiver so that they don't have to worry about
> reclamation,

I agree that reclamation on IPv4 is truly orthogonal to the deployment
of IPv6.

IPv6 will be necessary to support new allocations beyond 2010, and we
need to remove as many barriers to IPv6 deployment as we can.

There is little or no benefit to reclamation of IPv4 swamp space.

Much more benefit could be achieved by placing pressure on operators
who deaggregate, to stop doing so - and I would encourage adoption of
any such policy, e.g. requiring fees per globally announced prefix,
regardless of whether it is covered by another prefix.

> With the only contingency that the space be actively used in the DFZ
> or showing that the space is in use in a manner that cannot be readily
> replaced by 1918 space.

The ideas being circulated relating to the DFZ, that have widespread
support, are those that avoid polluting it with large numbers of prefixes,
where the prefixes in question could/should be aggregated.

To wit: if any current IPv4 prefix is single-homed, but not aggregateable,
the most likely reason is that it was assigned pre-CIDR.

Post-CIDR, the assignment would/should have been made from an LIR/ISP,
from a PA block.

We want to drain the swamp, not move it whole-hog (us who like the idea
of an IPv6 DFZ that scales to global use and lasts more than a year.)

So, if we change the wording to:
"... cannot be readily replaced by PA space.".

This would need to be emphasized by adding the additional requirement that
the policy would apply only to prefixes, where the requester operates an
active AS in IPv4 or IPv6, originating one or more prefixes registered to
them (or assigned to them via legacy assignment(s)).

This keeps the number of PI prefixes in par with the number of ASNs,
while bringing legacy /24's into the RSA fold.

>
> I personally feel that the /24 space needs to be handled differently than
> the /16 and /8 space.

Agreed.

> This obviously would be for the 2008 timeframe.

I think that it would be suitable for immediate implementation, actually.

Brian Dickson




From arin-contact at dirtside.com  Sat Sep  1 14:40:25 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Sat, 1 Sep 2007 14:40:25 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <20070901144553.GA494@ussenterprise.ufp.org>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
Message-ID: <3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>

On 9/1/07, Leo Bicknell <bicknell at ufp.org> wrote:
> So individuals and small businesses should be allowed to eat up
> routing slots in tens of thousands of routers worldwide collectively
> costing ISP's millions of dollars in capital, if and only if they
> were smart enough to get an "early" IPv4 allocation?

Leo,

Lets put some numbers to this so that we're arguing facts rather than opinions.

There are 233,000 IPv4 routes and a little under 1000 IPv6 routes in
the default-free zone (DFZ) today.

10%-30% of the routers in the DFZ today have a hard limit between
244,000 and 260,000 IPv4 routes or half that number of IPv6 routes.
When the limit is reached within the next few months, those routers
will experience various degrees of falling over dead. Upgrading these
routers to accomodate 1M IPv4 or 500k IPv6 routes will cost
$30,000-$150,000 each.

In the more general case, these routers have to be upgraded every 3-5 years.

The number of routes and ASes in the DFZ implies that there are
somewhere between 200,000 and 300,000 routers in the DFZ.

Lets start with the low numbers. If its $30k to put 233k routes in the
DFZ then each route in each router costs around 13 cents. Times 200k
routers offers an aggregate worldwide cost of $26,000 to announce an
IPv4 route. The IPv6 routes consume twice the capacity in the router,
so that means the worldwide cost of announcing an IPv6 prefix is
$52,000. On a 3-year upgrade cycle that's an annual attributable cost
of $17,300 per prefix.

Lets try the high numbers. $150k to handle 500,000 IPv6 routes = 30
cents per route. Times 300k routers = $90l. Divide by a 5 year upgrade
cycle = an annual attributable cost of $18,000 per prefix.

While this is not a thorough cost analysis, its reasonable for
ballparking. I can say with an acceptable degree of confidence that
the worldwide attributable cost of announcing one IPv6 prefix is
between $17k and $18k per year.


So, with any proposal to expand the availability of IPv6 PI, the
question that should be asked is: "Does the proposed use in the
expansion justify asking the rest of the world to pay $17k?"


My opinion is that in the case of a multihomed content provider, the
answer is yes. Why should he receive poor treatment in IPv6 merely
because his mechanism for providing content was efficient enough to
require only a few IP addresses? If you're willing to pay the prices
that the network operators require to be mulithomed (whatever that
happens to be) then you should be eligible for the necessary IPv6 PI
assignment. That's just how the Internet functions and the $17k is a
cost of doing business.

In the case of single-homed folks who just want to avoid renumbering
hassles, I think you'd need an awfully large number of computers
before the renumbering hassle adds up to $17k/yr. Many many computers.

As for the folks who want to weasel out of the $100/yr annual
maintenance fee for an IPv6 PI assignment, I would ask why anyone
should take your request seriously when you're simultaneously asking
the rest of the world to spend $17,000/yr on your behalf.

Regards,
Bill Herrin

-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From JOHN at egh.com  Sat Sep  1 16:56:02 2007
From: JOHN at egh.com (John Santos)
Date: Sat, 1 Sep 2007 16:56:02 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <20070901144553.GA494@ussenterprise.ufp.org>
Message-ID: <1070901165207.964D-100000@Ives.egh.com>


I would like to point out for the millionth time that having PI
space and taking up a routing slot are *NOT* the same thing.

There are many legitimate uses of globally unique address space
that don't require routing in the DFZ.  (For example private
internets either on leased circuits or via VPN tunnels over
the public Internet.)


-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

From paul at vix.com  Sat Sep  1 17:05:29 2007
From: paul at vix.com (Paul Vixie)
Date: Sat, 01 Sep 2007 21:05:29 +0000
Subject: [ppml] Legacy /24s
In-Reply-To: Your message of "Sat, 01 Sep 2007 13:26:42 -0400."
	<63408.74.122.168.81.1188667602.squirrel@look.libertyrms.com> 
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<63408.74.122.168.81.1188667602.squirrel@look.libertyrms.com> 
Message-ID: <93195.1188680729@sa.vix.com>

> There is little or no benefit to reclamation of IPv4 swamp space.

well, the space itself has no reassignment value, so this is mostly true.
but every reclaimation that removes a swamp route from the DFZ has "some
benefit".


From paul at vix.com  Sat Sep  1 17:10:03 2007
From: paul at vix.com (Paul Vixie)
Date: Sat, 01 Sep 2007 21:10:03 +0000
Subject: [ppml] Legacy /24s
In-Reply-To: Your message of "Sat, 01 Sep 2007 16:56:02 -0400."
	<1070901165207.964D-100000@Ives.egh.com> 
References: <1070901165207.964D-100000@Ives.egh.com> 
Message-ID: <93792.1188681003@sa.vix.com>

> I would like to point out for the millionth time that having PI
> space and taking up a routing slot are *NOT* the same thing.
> 
> There are many legitimate uses of globally unique address space
> that don't require routing in the DFZ.  (For example private
> internets either on leased circuits or via VPN tunnels over
> the public Internet.)

while i agree with this, the cause it represents is hopeless.  the IETF
intelligensia has killed, at least for now and probably forever, any hope of
globally unrouteable unique address space.  if ARIN or the RIR community want
to add this feature, it'll have to be done regionally and bottomly-uply.  if
we get an RPKI then perhaps routability could be a routing object attribute,
or something like that.

"unroutable PI" could be a huge relief to a lot of people.  but right now,
with no way to enforce it, the policy development process has to assume that
all PI will be routed, and so, the policies disfavour PI.  i called this "the
tyranny of the DFZ" in one particularly-harshly-worded missive on the topic.


From Lee at Dilkie.com  Sat Sep  1 17:34:58 2007
From: Lee at Dilkie.com (Lee Dilkie)
Date: Sat, 01 Sep 2007 17:34:58 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
Message-ID: <46D9DB02.7070509@Dilkie.com>



William Herrin wrote:
> ...
> As for the folks who want to weasel out of the $100/yr annual
> maintenance fee for an IPv6 PI assignment, I would ask why anyone
> should take your request seriously when you're simultaneously asking
> the rest of the world to spend $17,000/yr on your behalf.
>   
Interesting argument. However, the cost isn't borne by the network
operators, it's passed down to the end users (like me) and we all pay
our share to cover that.

But thank you Bill, for again for reinforcing the need for me to keep my
mouth shut. I really did see this coming.


From jcurran at istaff.org  Sat Sep  1 18:58:07 2007
From: jcurran at istaff.org (John Curran)
Date: Sat, 1 Sep 2007 18:58:07 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.lo
	cal>	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
Message-ID: <p06240800c2ff9d551e97@[192.168.3.65]>

At 2:40 PM -0400 9/1/07, William Herrin wrote:
>Lets put some numbers to this so that we're arguing facts rather than opinions.

Nice analysis, by the way...  One comment, see below.

>...
>The number of routes and ASes in the DFZ implies that there are
>somewhere between 200,000 and 300,000 routers in the DFZ.

Hmm.  Could you expand on this part of the calculation?   I know
lots of backbones operating in the default-free zone, and can take
an estimate at number of routers each, but I'm not certain that
the product gets us to 200000 routers.  Also, there are often IGP
routers which don't participate in global routing but have the entry
purely for internal traffic engineering...  Is it fair to reflect the cost
of upgrading such routers onto the cost for a global routing entry?

/John


From sleibrand at internap.com  Sat Sep  1 19:18:53 2007
From: sleibrand at internap.com (Scott Leibrand)
Date: Sat, 01 Sep 2007 16:18:53 -0700
Subject: [ppml] Policy Proposal 2007-15: Authentication of
 Legacy	Resources - version 1.1
In-Reply-To: <933be923a2dcb358a88b584c6b12359f46d8e956@jcc.com>
References: <933be923a2dcb358a88b584c6b12359f46d8e956@jcc.com>
Message-ID: <46D9F35D.6030802@internap.com>

Keith W. Hare wrote:
>
> That's not what the policy says.  It says "No changes shall be made to
> legacy resource records which are not covered by a registration services
> agreement after December 31, 2007."
>
> So, the RSA is ready on January 1, 2008, but legacy resource holders
> can't update stuff that is not covered by the RSA after December 31,
> 2007?  There is not a year there.
>   

My apologies, you're correct.  I misread the policy to read the way I 
thought it should, not the way it's written.

> I would be happier if the year you claim is the intent were actually in
> the proposed policy.

I would support a further revision to 2007-15 to provide a grace period 
(such as 1 year) between availability of a Legacy Resource Record Holder 
RSA and the requirement of being covered by such an RSA before making 
changes to records.

> I would be even happier to leave the sentence out
> entirely.
>   
And I wouldn't oppose that.

> Why do we need a stick today for the legacy address holders who have not
> responded to the invitation that has not yet been issued?
>   

I don't think we need to invoke the stick before putting out the formal 
invitation.  I suspect we'll need the stick eventually.  If we choose 
not to require the RSA initially, I think we need to get a report from 
ARIN staff after a certain amount of time (6 months or so maybe) on the 
adoption rate of the new RSA, and discuss requirements at that point.

-Scott



From arin-contact at dirtside.com  Sat Sep  1 21:01:08 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Sat, 1 Sep 2007 21:01:08 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <p06240800c2ff9d551e97@192.168.3.65>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<p06240800c2ff9d551e97@192.168.3.65>
Message-ID: <3c3e3fca0709011801oc9c7acbm5518e4f81cd89ead@mail.gmail.com>

On 9/1/07, John Curran <jcurran at istaff.org> wrote:
> At 2:40 PM -0400 9/1/07, William Herrin wrote:
> >The number of routes and ASes in the DFZ implies that there are
> >somewhere between 200,000 and 300,000 routers in the DFZ.
>
> Hmm.  Could you expand on this part of the calculation?

John,

Its purely a SWAG. There are a little under 30k AS's announcing around
233k IPv4 routes. In the operations I've been involved in, the
organization usually originated about as many DFZ routes as it had
routers that took a full BGP feed. Sometimes a little more, sometimes
a little less.

If you have a more solid estimate, lets roll with it and re-run the
numbers. I'd be very surprised if it got us below 100k routers or
changed the point that its wildly expensive to announce a prefix into
the DFZ.

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From arin-contact at dirtside.com  Sat Sep  1 21:20:37 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Sat, 1 Sep 2007 21:20:37 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <1070901165207.964D-100000@Ives.egh.com>
References: <20070901144553.GA494@ussenterprise.ufp.org>
	<1070901165207.964D-100000@Ives.egh.com>
Message-ID: <3c3e3fca0709011820m736ab56ata444f2368294735d@mail.gmail.com>

On 9/1/07, John Santos <JOHN at egh.com> wrote:
> I would like to point out for the millionth time that having PI
> space and taking up a routing slot are *NOT* the same thing.
>
> There are many legitimate uses of globally unique address space
> that don't require routing in the DFZ.  (For example private
> internets either on leased circuits or via VPN tunnels over
> the public Internet.)

John,

The solution to this is staring you in the face. We have great gobs of
unroutable / semi-routable IPv6 space within the 6to4 spec. If you
already have unrouted IPv4 space, why not use the corresponding
unrouted 6to4 space for your non-DFZ tasks? Each /24 of IPv4 space
maps to a /40 of IPv6 space or 24M subnets.

Regards,
Bill Herrin

-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bicknell at ufp.org  Sat Sep  1 21:23:34 2007
From: bicknell at ufp.org (Leo Bicknell)
Date: Sat, 1 Sep 2007 21:23:34 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <1070901165207.964D-100000@Ives.egh.com>
References: <20070901144553.GA494@ussenterprise.ufp.org>
	<1070901165207.964D-100000@Ives.egh.com>
Message-ID: <20070902012334.GA31369@ussenterprise.ufp.org>

In a message written on Sat, Sep 01, 2007 at 04:56:02PM -0400, John Santos wrote:
> I would like to point out for the millionth time that having PI
> space and taking up a routing slot are *NOT* the same thing.
> 
> There are many legitimate uses of globally unique address space
> that don't require routing in the DFZ.  (For example private
> internets either on leased circuits or via VPN tunnels over
> the public Internet.)

I agree, however from the post that started this thread:

> With the only contingency that the space be actively used in the DFZ
> or showing that the space is in use in a manner that cannot be readily
> replaced by 1918 space.

So this proposal explicitly excluded the case you're referring to
from the start.

-- 
       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/20070901/0efd91c5/attachment.sig>

From bicknell at ufp.org  Sat Sep  1 21:40:03 2007
From: bicknell at ufp.org (Leo Bicknell)
Date: Sat, 1 Sep 2007 21:40:03 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
Message-ID: <20070902014003.GB31369@ussenterprise.ufp.org>

In a message written on Sat, Sep 01, 2007 at 02:40:25PM -0400, William Herrin wrote:
> 10%-30% of the routers in the DFZ today have a hard limit between
> 244,000 and 260,000 IPv4 routes or half that number of IPv6 routes.
> When the limit is reached within the next few months, those routers
> will experience various degrees of falling over dead. Upgrading these
> routers to accomodate 1M IPv4 or 500k IPv6 routes will cost
> $30,000-$150,000 each.

You've nicely bounded the problem of upgrading Sup2+MSFC boxes to
Sup720 boxes.  (I'm guessing, because I've seen you talking about
the problem on the nanog mailing list and all the numbers fit.)

On the flip side, there are a lot of M40, 7513, 12008 and the list
goes on boxes that either have no direct upgrade path, or the upgrade
path is so costly and painful that replacing the box in total is
the only option.  In many cases the replacement cost includes
upgrades (some of which you want, some of which you don't), and can
easily be in the range of $500,000-$2,000,000 per box.

Your numbers also only account for the hardware cost.  Particularly
in the case of a forklift upgrade you're talking about a significant
amount of engineer time, and on-site time at what may not be manned
pops.  You also do not account for customer credits and/or losses
attributed to the down time of upgrading.

In short, I'm afraid your estimate is WAY low on cost per device.

> The number of routes and ASes in the DFZ implies that there are
> somewhere between 200,000 and 300,000 routers in the DFZ.

I can't come up with anyway to estimate, but my gut tells me this is a
little high.

> Lets try the high numbers. $150k to handle 500,000 IPv6 routes = 30
> cents per route. Times 300k routers = $90l. Divide by a 5 year upgrade
> cycle = an annual attributable cost of $18,000 per prefix.

Ok, so, we keep talking about a 50-100 year lifetime for IPv6.
Using your numbers, assuming it's a one time cost, and there's no
inflation means if ARIN makes an allocation it will cost $900,000
to $5,000,000.

If there are 10,000 swamp routes that would qualify we're talking
about $9,000,000,000 to $50,000,000,000.  That's 9 billion to 50
billion dollars, over the lifetime of IPv6.

So individuals and small businesses who jumped on IPv4 early can
continue to reap the same benefits.

IPv6 was supposed to be different.  The concept is rooted in really
good principals.  Unfortunately the execution has been lacking.

> As for the folks who want to weasel out of the $100/yr annual
> maintenance fee for an IPv6 PI assignment, I would ask why anyone
> should take your request seriously when you're simultaneously asking
> the rest of the world to spend $17,000/yr on your behalf.

Excellent point.  I personally believe if $100 a year is an issue
for you that's a sign you should not have your own block, for the
economic reasons above.

-- 
       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/20070901/4a8c3619/attachment.sig>

From Keith at jcc.com  Sat Sep  1 23:36:35 2007
From: Keith at jcc.com (Keith W. Hare)
Date: Sat, 1 Sep 2007 23:36:35 -0400
Subject: [ppml] Legacy /24s
Message-ID: <49acf4a61c88ad505f77404265e260e546da2fc6@jcc.com>

 

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of William Herrin
> Sent: Saturday, September 01, 2007 2:40 PM
> To: ppml at arin.net
> Subject: Re: [ppml] Legacy /24s
> 
>... 
> In the case of single-homed folks who just want to avoid 
> renumbering hassles, I think you'd need an awfully large 
> number of computers before the renumbering hassle adds up to 
> $17k/yr. Many many computers.
> 

Nope.  All you really need is a small number of computers, several
firewalls, and a requirement that you have to comply with a security and
security auditing specification, such as the payment card industry (PCI)
specification.  Part of the cost would be renumbering, part would be
revising the rules in the firewalls, intrusion detection system, etc.  A
big part would be in re-auditing the information security configuration.

And the cost of making a mistake on the security configurations is about
$10 per exposed credit card number for a year's subscription to a credit
report watch service, not to mention the cost of making the front page
of the newspapers and computer trade press.

Keith

______________________________________________________________
 
Keith W. Hare                     JCC Consulting, Inc.
keith at jcc.com                     600 Newark Road
Phone: 740-587-0157               P.O. Box 381
Fax: 740-587-0163                 Granville, Ohio 43023
http://www.jcc.com                USA
______________________________________________________________
 
 





From michel at arneill-py.sacramento.ca.us  Sun Sep  2 00:08:29 2007
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Sat, 1 Sep 2007 21:08:29 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org>
	<D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
Message-ID: <DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>

> David Conrad wrote:
> I'm beginning to believe that IPv6 as it exists is so flawed and
> the business/economic/political factors are such that in the end,
> [...]

Please do not confuse IPv6 with the business/economic/political factors.
The protocol suite itself, while certainly not perfect, is not what I
call flawed. Yes, there are many things associated with it that are
indeed flawed, but not IPv6 itself. There are several technical aspects
that I do not agree with, or would not have designed the same way
though.

The main issues associated with IPv6 are:

- It was designed as a protocol (with heavy input from protocol purity
zealots), not as a product. Very large numbers within the IETF crowd is
outright stupid about economic issues. They still live in an ivory tower
where (for example) Unix and MacIntosh are the only acceptable ways,
while the rest of the world is running windblows from the evil empire.

- It never delivered initial promises, such as aggregation (the "8K
DFZ"). In their great wisdom, the IETF pushed the protocol out with the
promise that they will deliver the missing features (such as multihoming
and effortless renumbering) later. Problem, nobody figured it out.

- As it turned out down the road, the multiple-addresses-per-host are
too much of an administrative overhead.


So we're in a situation where the only remaining real reason to upgrade
to IPv6 is IPv4 address space exhaustion, while IPv6 still does not have
hugely popular features such as NAT and no equivalent either.

Technically, I consider NAT more flawed than IPv6. Nevertheless, NAT has
addressed market needs, while IPv6 is a solution without a market.

Michel.



From arin-contact at dirtside.com  Sun Sep  2 00:29:31 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Sun, 2 Sep 2007 00:29:31 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <20070902014003.GB31369@ussenterprise.ufp.org>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
Message-ID: <3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>

On 9/1/07, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Sat, Sep 01, 2007 at 02:40:25PM -0400, William Herrin wrote:
> > 10%-30% of the routers in the DFZ today have a hard limit between
> > 244,000 and 260,000 IPv4 routes or half that number of IPv6 routes.
>
> You've nicely bounded the problem of upgrading Sup2+MSFC boxes to
> Sup720 boxes.  (I'm guessing, because I've seen you talking about
> the problem on the nanog mailing list and all the numbers fit.)

That includes most of the Sup720 boxes too; they're bounded at 260k.
In the 6500/7600 product line, only the Sup720-3BXL and RSP720-3CXL
accommodate more than 260k routes. And as you point out there are no
in-place upgrades for the remaining 7200 and 7500 routers.


> upgrades (some of which you want, some of which you don't), and can
> easily be in the range of $500,000-$2,000,000 per box.

Relatively speaking, there are few routers in the DFZ whose street
price exceeds $150k. More, once you're past $150k the major cost
driver is traffic capacity rather than route capacity.


> Your numbers also only account for the hardware cost. [...]
> In short, I'm afraid your estimate is WAY low on cost per device.

They don't account for the electricity cost for running the
power-hungry TCAMs and the required air conditioning capacity either.
Nor do they exclude the cost attribution associated with the routers'
traffic capacity and age-related upgrades rather than route capacity.

Like I said, its not a thorough analysis. I selected only the most
significant factors in order to produce a ballpark figure.


> > The number of routes and ASes in the DFZ implies that there are
> > somewhere between 200,000 and 300,000 routers in the DFZ.
>
> I can't come up with anyway to estimate, but my gut tells me this is a
> little high.

Could be. I'm open to better grounded numbers than the ones I offered.



> Ok, so, we keep talking about a 50-100 year lifetime for IPv6.
> Using your numbers, assuming it's a one time cost, and there's no
> inflation means if ARIN makes an allocation it will cost $900,000
> to $5,000,000.

You really can't project a lifetime cost that way. For one thing, the
cost of one route in one router is falling faster than the number of
routers in the DFZ is growing. For another, there are a variety of
proposals on RRG which on a 5-year horizon would adjust routing
technology in a way that radically alters the cost structure
associated with PI space. The more PI space there is, the higher the
probability of one of these technologies being adopted.

You can only really project the annual cost for the next few years
with any degree of accuracy.


> IPv6 was supposed to be different.  The concept is rooted in really
> good principals.  Unfortunately the execution has been lacking.

I pulled out and leafed through my old "Internet Protocol Next
Generation" book from 1997. Do you realize just how few of the design
goals have panned out operationally? Its appalling.

Regards,
Bill Herrin



-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From paul at vix.com  Sun Sep  2 00:37:12 2007
From: paul at vix.com (Paul Vixie)
Date: Sun, 02 Sep 2007 04:37:12 +0000
Subject: [ppml] IPv6 flawed?
In-Reply-To: Your message of "Sat, 01 Sep 2007 21:08:29 MST."
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org>
	<D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
Message-ID: <1712.1188707832@sa.vix.com>

> - It never delivered initial promises, such as aggregation (the "8K
> DFZ"). In their great wisdom, the IETF pushed the protocol out with the
> promise that they will deliver the missing features (such as multihoming
> and effortless renumbering) later.

agreed.

> Problem, nobody figured it out.

disagreed.  see A6, DNAME, bitstring labels, and 8+8.  i've learned a lot
about the ietf intelligensia over the years, starting with those losses.
we would actually be in a comparatively good position if only our tools
could be made by the lowest bidders.  what you said (not quoted here) about
purity, could be said louder.

> - As it turned out down the road, the multiple-addresses-per-host are
> too much of an administrative overhead.

the thing i keep asking is, where was the per-address default route for
inbound, and where was the LCR hook for outbound?  without those, simply
adding multiple subnets to a LAN and hoping hosts would figure it out
was just vaporware.  (note well: A6/DNAME/bitstrings didn't have solutions
to those problems, either.)

> So we're in a situation where the only remaining real reason to upgrade
> to IPv6 is IPv4 address space exhaustion, while IPv6 still does not have
> hugely popular features such as NAT and no equivalent either.
> 
> Technically, I consider NAT more flawed than IPv6. Nevertheless, NAT has
> addressed market needs, while IPv6 is a solution without a market.

with respect to the oft-quoted axiom that if pigs had wings they could fly,
i remember telling a lot of people (who reported to me inside an ISP) in Y2K
or so is that "the rocket boosters have been attached to the pig called IPv6".
what i meant by this is anybody's guess, really, but i think i was trying to
say that even though it was useless and solved the wrong problem, it was also
inevitable.  nothing's changed: ipv6 fails to solve the problems ipv4 had,
and makes the problems ipv4 had even worse, but nevertheless it's what we'll
have to use while awaiting real innovation, to come, presumably or hopefully,
some time later.

note: i'm not speaking as an arin trustee here.


From arin-contact at dirtside.com  Sun Sep  2 00:41:40 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Sun, 2 Sep 2007 00:41:40 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <49acf4a61c88ad505f77404265e260e546da2fc5@jcc.com>
References: <49acf4a61c88ad505f77404265e260e546da2fc5@jcc.com>
Message-ID: <3c3e3fca0709012141h14012e77hb0ed9a85cad99477@mail.gmail.com>

On 9/1/07, Keith W. Hare <Keith at jcc.com> wrote:
> requirement that you have to comply with a security and
> security auditing specification, such as the payment card industry (PCI)
> specification.  Part of the cost would be renumbering, part would be
> revising the rules in the firewalls, intrusion detection system, etc.  A
> big part would be in re-auditing the information security configuration.

Keith,

That's an interesting argument. Having been through the PCI auditing
process I don't buy that it increases the renumbering cost enough to
merit requiring everybody else to pay $17k per year but its an
interesting argument.

Here's another interesting argument: For better or for worse, spam
filtering is heavily biased towards the IP address. Current software
is extremely suspicious of IP addresses which suddenly begin emiting
large amounts of mail. Getting the new IP address back on everybody's
whitelist is very manpower-expensive. If you're a large non-profit
organization who uses email to solicit donations from constituents,
the lost opportunity cost while correcting those filtering problems
very rapidly runs to hundreds of thousands of dollars.

If you make PI addresses available on those criteria, how would you
measure? How much credit card activity justifies PI addresses? How
much email?

Regards,
Bill Herrin



-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From paul at vix.com  Sun Sep  2 00:43:07 2007
From: paul at vix.com (Paul Vixie)
Date: Sun, 02 Sep 2007 04:43:07 +0000
Subject: [ppml] Legacy /24s
In-Reply-To: Your message of "Sun, 02 Sep 2007 00:29:31 -0400."
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com> 
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com> 
Message-ID: <2994.1188708187@sa.vix.com>

> > Your numbers also only account for the hardware cost. [...]
> > In short, I'm afraid your estimate is WAY low on cost per device.
> 
> They don't account for the electricity cost for running the
> power-hungry TCAMs and the required air conditioning capacity either.
> Nor do they exclude the cost attribution associated with the routers'
> traffic capacity and age-related upgrades rather than route capacity.

i think that as with dotcomenomics, we're expected to grow our way outta this.

> I pulled out and leafed through my old "Internet Protocol Next Generation"
> book from 1997. Do you realize just how few of the design goals have panned
> out operationally? Its appalling.

yes, it is.  but from a policy standpoint, that doesn't matter.  we're going
to run out of new ipv4 soon, and there are three ways to jump:

	1. stop growing the network
	2. dramatically increase NATism
	3. use IPv6

of the three, i like #4.  of the three we actually have, though, i pick #3.


From arin-contact at dirtside.com  Sun Sep  2 01:31:28 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Sun, 2 Sep 2007 01:31:28 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <2994.1188708187@sa.vix.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
	<2994.1188708187@sa.vix.com>
Message-ID: <3c3e3fca0709012231w69e35815y30612954bab767c2@mail.gmail.com>

On 9/2/07, Paul Vixie <paul at vix.com> wrote:
> > I pulled out and leafed through my old "Internet Protocol Next Generation"
> > book from 1997. Do you realize just how few of the design goals have panned
> > out operationally? Its appalling.
>
> yes, it is.  but from a policy standpoint, that doesn't matter.  we're going
> to run out of new ipv4 soon, and there are three ways to jump:
>
>         1. stop growing the network
>         2. dramatically increase NATism
>         3. use IPv6
>
> of the three, i like #4.

Paul,

I like option #29: IP extra large. If IP option header #29 is present
starting at the sixth word in the IPv4 header then the "source" part
of the IP header actually contains the four high-order bytes of the
64-bit IP destination address while the seventh and eighth words
contain the 64-bit source address.

I guess it would have been too easy to let us grow incrementally with
only changes on the software side of the house.

>  of the three we actually have, though, i pick #3.

Yeah, I can live with that. But I will gripe about it now and then.

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From stephen at sprunk.org  Sun Sep  2 01:43:00 2007
From: stephen at sprunk.org (Stephen Sprunk)
Date: Sun, 2 Sep 2007 00:43:00 -0500
Subject: [ppml] Legacy /24s
References: <49acf4a61c88ad505f77404265e260e546da2fc6@jcc.com>
Message-ID: <07fd01c7ed27$db607e30$5c3816ac@atlanta.polycom.com>

Thus spake "Keith W. Hare" <Keith at jcc.com>
> And the cost of making a mistake on the security configurations is
> about $10 per exposed credit card number for a year's subscription
> to a credit report watch service, not to mention the cost of making
> the front page of the newspapers and computer trade press.

It was a PR cost when laws were first passed requiring notification.  Now, 
security breach notices are so common that the media doesn't even bother 
reporting them anymore except for the most extreme cases.  Until we get laws 
requiring companies to pay non-trivial fines and/or restitution for each 
record compromised, it'll remain a non-event.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 




From woody at pch.net  Sun Sep  2 02:16:59 2007
From: woody at pch.net (=?utf-8?B?QmlsbCBXb29kY29jaw==?=)
Date: Sun, 2 Sep 2007 06:16:59 +0000
Subject: [ppml] Legacy /24s
In-Reply-To: <p06240800c2ff9d551e97@[192.168.3.65]>
References: <mailman.4174.1188583766.29428.ppml@arin.net><859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>	<20070901144553.GA494@ussenterprise.ufp.org><3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com><p06240800c2ff9d551e97@[192.168.3.65]>
Message-ID: <1449649690-1188714008-cardhu_decombobulator_blackberry.rim.net-1144185577-@bxe102.bisx.prod.on.blackberry>

If it's helpful, we (PCH) believed there to be about 8,400 ASNs in the world which were providing transit services, last I checked. From experience, I can tell you that the long tail of the curve of how-many-full-table-routers-per-ISP-of-that-type is between one and three. So, really roughly, the 8,300 smaller of those 8,400 might be contributing 20,000 routers to the total.  It's still quite plausible, however, that the top hundred are contributing another 180,000, so I don't dispute 200,000 as a possible total.  I think if I were to guess, I'd guess somewhere between 120,000 and 250,000.

But that's just a guess, supported only by what you see above, and no more detailed analysis. And this is my first email of the morning, which should always be viwed with some additional degree of scepticism.  :-)


                         -Bill

Please excuse the brevity of this message; I typed it on my pager. I could be more loquacious, but then I'd crash my car.    

-----Original Message-----
From: John Curran <jcurran at istaff.org>

Date: Sat, 1 Sep 2007 18:58:07 
To:"William Herrin" <arin-contact at dirtside.com>
Cc:"ppml at arin.net" <ppml at arin.net>
Subject: Re: [ppml] Legacy /24s


At 2:40 PM -0400 9/1/07, William Herrin wrote:
>Lets put some numbers to this so that we're arguing facts rather than opinions.

Nice analysis, by the way...  One comment, see below.

>...
>The number of routes and ASes in the DFZ implies that there are
>somewhere between 200,000 and 300,000 routers in the DFZ.

Hmm.  Could you expand on this part of the calculation?   I know
lots of backbones operating in the default-free zone, and can take
an estimate at number of routers each, but I'm not certain that
the product gets us to 200000 routers.  Also, there are often IGP
routers which don't participate in global routing but have the entry
purely for internal traffic engineering...  Is it fair to reflect the cost
of upgrading such routers onto the cost for a global routing entry?

/John
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.

From paul at vix.com  Sun Sep  2 04:11:20 2007
From: paul at vix.com (Paul Vixie)
Date: Sun, 02 Sep 2007 08:11:20 +0000
Subject: [ppml] FW: Legacy /24s
In-Reply-To: Your message of "Sat, 01 Sep 2007 10:35:39 CST."
	<000e01c7ecb6$24d7e480$6e87ad80$@org> 
References: <000e01c7ecb6$24d7e480$6e87ad80$@org> 
Message-ID: <47015.1188720680@sa.vix.com>

> > (the block was later used for a root name server, and then, later, given
> > into the control of a 501(c)(3) nonprofit who operates that server, and
> > for that, i think the community of router owners would say it's worth a
> > routing slot... i'm just saying if that hadn't happened, i'd've stopped
> > using the space by now, on a "think globally, act locally" basis.)

> That is silly. We are talking about ONE group and not MANY. The item is not
> even close to being the same.

the aphorism "thing globally, act locally" means trying to deduce the impact
of global behaviour that'd be reflective of local behaviour.  for example,
think of tossing a used styrofoam cup out of a car window.  if you're the only
one who acts this way, it would have no global impact.  but if you consider
what might happen to the world "if everybody behaved this way" -- all of us
waist deep in used styrofoam cups, etc -- then it becomes possible to respond
from principle: "somebody's got to be the first person to do the right thing,
if i want doing the right thing ought to become common, so, it might as well
be me."

or think of it another way.  right now about 30000 people have swamp /24's
who would likely not qualify for them under current rules.  from a policy
development standpoint, we can do only one of exactly two things:

	1. treat them as an exception, merely an early deployment necessity
	2. treat them as the rule, something to emulate in new policy

i choose #1.  so if you have activity that can't operate in PA space, like
an anycasted root name server, then you'd better make sure that it's an
activity that the global community of "router operators" think is worth their
expense in carrying a route for you.  most of the time, these days, the "value
proposition" is in terms of compelling content or massive numbers of eyeballs,
and so RIR policy tends to favour large blocks occuping routing table slots
vs. small blocks, unless the small block has compelling content that wouldn't
be as economically viable in PA space as in PI space.

so, we really are talking about many groups, not one.  or at least i am.

note: i'm not speaking as an ARIN trustee in this message.


From paul at vix.com  Sun Sep  2 04:26:37 2007
From: paul at vix.com (Paul Vixie)
Date: Sun, 02 Sep 2007 08:26:37 +0000
Subject: [ppml] Legacy /24s
In-Reply-To: Your message of "Sun, 02 Sep 2007 01:31:28 -0400."
	<3c3e3fca0709012231w69e35815y30612954bab767c2@mail.gmail.com> 
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
	<2994.1188708187@sa.vix.com>
	<3c3e3fca0709012231w69e35815y30612954bab767c2@mail.gmail.com> 
Message-ID: <51731.1188721597@sa.vix.com>

> > of the three, i like #4.
> 
> I like option #29: IP extra large. If IP option header #29 is present
> starting at the sixth word in the IPv4 header then the "source" part of the
> IP header actually contains the four high-order bytes of the 64-bit IP
> destination address while the seventh and eighth words contain the 64-bit
> source address.

that wouldn't've been unambiguous.  what several of us were hoping for was
where the IP version number went to 6 and the addresses got larger and that
was all.  but because this would not have enabled all of the many things
promised for IPng in the document you referenced earlier (most of which
weren't delivered and are now undeliverable), the IETF intelligensia ruled
against this approach.  note that with either your option-29 approach or my
described IPVx approach, the ethertype would still be 0800.  that in itself
explains that IPv6 is really a "new internet" not an "internet extension".
(and it leads to IPv6's lack of backward compatibility with IPv4, which is
one of the now-undeliverable promises made in the document you cited before.)

> I guess it would have been too easy to let us grow incrementally with
> only changes on the software side of the house.

IPv6 has made more than a few careers.  someone early on called it the "full
employment act for programmers", and so it's been.  but nobody i know has
said that it was made difficult just to build careers or employ programmers.
more like, it is the product of an extensive committee process.

> >  of the three we actually have, though, i pick #3.
> 
> Yeah, I can live with that. But I will gripe about it now and then.

and i don't mind griping, either, even though at the end of the day we're all
going to have to deploy it, no matter how we feel, warts and all.  perhaps
DRC would choose "vastly increased NATism" now that IPv6's warts are really
showing, but from an industry standpoint, that's just sooooo not an option.

note: i am not speaking as an ARIN trustee in this message.


From michael.dillon at bt.com  Sun Sep  2 12:00:58 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sun, 2 Sep 2007 17:00:58 +0100
Subject: [ppml] Policy Proposal: Decreasing Exponential Rationingof	IPv4
	IP Addresses
In-Reply-To: <8CC5B9B8-FB3D-4C7F-BD6B-089E31979FAD@muada.com>
References: <Pine.LNX.4.44.0708301647210.15082-100000@citation2.av8.net>
	<85975A4A-0077-4B71-B303-FD9FE27615F6@muada.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0F27485@E03MVC4-UKBR.domain1.systemhost.net>
	<8CC5B9B8-FB3D-4C7F-BD6B-089E31979FAD@muada.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B0F275B3@E03MVC4-UKBR.domain1.systemhost.net>

> A few = generally 2 or 3 years. Is that enough to call a trend?

If your data is monthly or weekly, then yes.

> > And the
> > changes have been explained due to macro events (CIDR introduction, 
> > telecoms collapse) so even though the trends go through 
> step changes, 
> > they are still trends.
> 
> If you can tell the trends from the macro events, please do 
> so because as far as I know, nobody else has been able to.

I said changes were explained by macro events. In other words, pre-CIDR
there was a trend, then CIDR was introduced and the trend changed.

> > One could still do a worst-case scenario based on the pre telecoms 
> > collapse trend
> 
> I guess that would be going from 86 million in 2001 to 69 
> million in 2002.

Pre telecoms collapse means *BEFORE* the telecoms collaps. Therefore I
was referring to the trend which existed *BEFORE* the drop in 2001-2002.

> > and then estimate the probability that macroeconomic events 
> will lead 
> > to that scenario. You then have an estimated runout date, and a 
> > probability that it will occur.

> You can arrive at pretty much any outcome by just selecting 
> the right start date.

But can you find macroeconomic explanations to reinforce your choice of
a starting date, and your choice of a trend? Unless you can tie your
numbers to macroeconomic triggers, they are just meaningless numbers.

> But 1995 was the first year with growth 
> after the introduction of CIDR so we only have 12 years.  
> It's just not enough to come up with something better than 5 
> - 25 % growth per year = running out between Q3 2011 and Q3 2013.

Instead of playing amateur statistician, I suggest that you give the
data to a professional and see what they say. 

> However, you can't predict a run on the bank, hoarding and 
> all kinds of other interesting end games by looking at the past.

Of course not. You need to look at the macroeconomic factors. In the
case of a run on real banks, you need to look at the contracts that
banks have with their customers. They are not the same terms as
contracts in the 1920's and 30's. Then you need to look are reserve bank
systems and financial regulations in effect. All of these things allow
you to predict that there cannot be a run on the bank.

In the case of the RIRs, the fact that people must present technical
justification for IPv4 address requests pretty well prevents a run on
the RIR banks.

> Let me put it this way: would either of them care to publish 
> an error margin to go along with their prediction? Or run the 
> numbers on historical data and see how well the predictions 
> fit what actually happened?

While this may be interesting, it does not change the fact that both
Tony and Geoff are using substantially the same data sources and
substantially the same methodology.

> I don't think there's another source of data. 

IPv4 is used to address hosts. Hosts are computers. Computers are
purchased. Governments collect and publish statistics on purchases of
various types of things.

Companies consume IP addresses when they grow their network. It costs a
lot of money to grow a network. You need to have income to justify any
growth. Income is something that publicly traded companies must
regularly report.

And then there is RIR membership stats which might be used in
conjunction with corporate income reporting.

Router manufacturers tend to sell specialized routers for CPE. They
might be convinced to give a researcher access to statistics on CPE
devices sold.

Statistics and forecasting are disciplines which are taught at the
graduate level. Graduates are often given real-world problems to work
on. Professors of any given discipline tend to be chronically short of
ideas for such real-world statistical/forecasting problems. Etc.

--Michael Dillon


From jonathan at qx.net  Sun Sep  2 12:17:55 2007
From: jonathan at qx.net (Jonathan Barker)
Date: Sun, 02 Sep 2007 12:17:55 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>	<20070901144553.GA494@ussenterprise.ufp.org>	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
Message-ID: <46DAE233.9010004@qx.net>


>> You've nicely bounded the problem of upgrading Sup2+MSFC boxes to
>> Sup720 boxes.  (I'm guessing, because I've seen you talking about
>> the problem on the nanog mailing list and all the numbers fit.)
>>     
>
> That includes most of the Sup720 boxes too; they're bounded at 260k.
> In the 6500/7600 product line, only the Sup720-3BXL and RSP720-3CXL
> accommodate more than 260k routes. And as you point out there are no
> in-place upgrades for the remaining 7200 and 7500 routers.
>
>   
We upgraded to the 7613, 3BXL a few years ago from a 7513, RSP8. It was 
one of the best upgrades we ever made for our network. The 7513's 
backplane is nowhere near as capable as the 7613, and quite a few of the 
backplane performance bottlenecks we saw before evaporated with the new 
hardware. Similarly the problem of DoS attacks evaporated for us, as 
we've been fortunate enough to not see one over 180,000 pps, and at that 
it just increased the router's CPU a couple percent.

Despite the fact we have 2, 4000 watt power supplies, the chassis and 
cards only use 1537.62 Watts, with the requisite air conditioning 
requirements - so it's actually about the same as our old 7513 on power 
and cooling load. I just hope they come up with something better than 
the RSP720-3CXL for our next upgrade cycle. It really doesn't offer much 
more than we already have with the 3BXL, and we've had it for nearly 2 
and a half years.

If you are lucky enough to have a 7200VXR chassis - there is a NPE-G2 
available (we just ordered a couple to serve as agg  / VPN routers.) I 
know the G-2 comes default with 1 Gig RAM, and can be upgraded to 2 
Gigs. Surely that router will be able to take more than 256k routes - 
and the upgrade for the VXR chassis is only 15k or so.... I can't find 
the statistic on Cisco's site - but having the capability of more ram 
than the 3BXL, I don't see why it would choke with the increased routes. 
The only thing the Cisco docs state is that the NPE-G2 "Supports more 
routes, and routing tables"

Of course... I have to say I don't like running BGP on 7200s. With the 
way Cisco prioritizes the BGP scan process, it spikes the single CPU 
each time it runs, and it 'can' in some configurations with large route 
tables, cause a little lag for a second or two every minute. With the 
distributed processing on the 7600 series, that's not an issue.

Jonathan




From drc at virtualized.org  Sun Sep  2 12:24:04 2007
From: drc at virtualized.org (David Conrad)
Date: Sun, 2 Sep 2007 09:24:04 -0700
Subject: [ppml] Legacy /24s
In-Reply-To: <51731.1188721597@sa.vix.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
	<2994.1188708187@sa.vix.com>
	<3c3e3fca0709012231w69e35815y30612954bab767c2@mail.gmail.com>
	<51731.1188721597@sa.vix.com>
Message-ID: <36F46686-972E-4A99-B0C0-4D541895847E@virtualized.org>

On Sep 2, 2007, at 1:26 AM, Paul Vixie wrote:
> and i don't mind griping, either, even though at the end of the day  
> we're all
> going to have to deploy it, no matter how we feel, warts and all.   
> perhaps
> DRC would choose "vastly increased NATism" now that IPv6's warts  
> are really
> showing,

Not sure why you think these are either/or.  I suspect the answer  
will be vastly increased NATism _and_ IPv6 deployment.  ISPs will  
likely migrate their infrastructure to IPv6 without too much pain  
(reusing the IPv4 addresses for customer assignments and using IPv4  
tunneling).  The vast majority of end users will continue to use IPv4  
+ NAT.  The real challenge I see is figuring out how to convince  
content providers that they need to spend the money to add IPv6  
support along side their IPv4-based content.

> but from an industry standpoint, that's just sooooo not an option.

Sorry, which industry is that?

Regards,
-drc



From Keith at jcc.com  Sun Sep  2 15:48:59 2007
From: Keith at jcc.com (Keith W. Hare)
Date: Sun, 2 Sep 2007 15:48:59 -0400
Subject: [ppml] Legacy /24s
Message-ID: <9c74501455b027cd51685a2e6c1e864546db13ac@jcc.com>

 

> -----Original Message-----
> From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf 
> Of William Herrin
> Sent: Sunday, September 02, 2007 12:42 AM
> To: Keith W. Hare
> Cc: ppml at arin.net
> Subject: Re: [ppml] Legacy /24s
> 
> On 9/1/07, Keith W. Hare <Keith at jcc.com> wrote:
> > requirement that you have to comply with a security and security 
> > auditing specification, such as the payment card industry (PCI) 
> > specification.  Part of the cost would be renumbering, part 
> would be 
> > revising the rules in the firewalls, intrusion detection 
> system, etc.  
> > A big part would be in re-auditing the information security 
> configuration.
> 
> Keith,
> 
> That's an interesting argument. Having been through the PCI 
> auditing process I don't buy that it increases the 
> renumbering cost enough to merit requiring everybody else to 
> pay $17k per year but its an interesting argument.
> 

I do not have anywhere close to enough knowledge about now all of this
works to evaluate your $17k per year number.

What I'm claiming is that the cost implementing IPv6 is significantly
higher than the cost of the hardware, and it is the difficult to
quantify costs, such as tying one's IP addresses to a single ISP, that
are going to impede IPv6 adoption.

You claim that letting too many organizations have Provider Independent
address space adds cost to everyone.  

I claim that without PI space, there are a lot of small to medium size
business that are going to be more reluctant to adopt IPv6.

We could both be correct, in which case the ARIN policy question is what
set of policies promote IPv6 sufficiently without overwhelming the
infrastructure?

Keith

______________________________________________________________
 
Keith W. Hare                     JCC Consulting, Inc.
keith at jcc.com                     600 Newark Road
Phone: 740-587-0157               P.O. Box 381
Fax: 740-587-0163                 Granville, Ohio 43023
http://www.jcc.com                USA
______________________________________________________________
 
 



From iljitsch at muada.com  Sun Sep  2 16:21:13 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Sun, 2 Sep 2007 22:21:13 +0200
Subject: [ppml] IPv6 flawed?
In-Reply-To: <1712.1188707832@sa.vix.com>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org>
	<D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
Message-ID: <11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>

On 2-sep-2007, at 6:37, Paul Vixie wrote:

>> - It never delivered initial promises, such as aggregation (the "8K
>> DFZ"). In their great wisdom, the IETF pushed the protocol out  
>> with the
>> promise that they will deliver the missing features (such as  
>> multihoming
>> and effortless renumbering) later.

> agreed.

IETF is still working... And it's not like adopting PI in the mean  
time helps.

>> Problem, nobody figured it out.

> disagreed.  see A6, DNAME, bitstring labels,

What's the deal here? This was removed very quickly from BIND.  
Wouldn't it have made more sense to keep it in there to allow further  
experimentation at least?

Although I can understand the problems with A6, it's a shame that the  
IETF abandoned efforts to make renumbering easier.

> and 8+8.

That's only half a solution, the way it was written down 10 years ago  
doesn't do anything useful. If you fix the problems, you end up with  
something like shim6.

>> - As it turned out down the road, the multiple-addresses-per-host are
>> too much of an administrative overhead.

> the thing i keep asking is, where was the per-address default route  
> for
> inbound, and where was the LCR hook for outbound?  without those,  
> simply
> adding multiple subnets to a LAN and hoping hosts would figure it out
> was just vaporware.  (note well: A6/DNAME/bitstrings didn't have  
> solutions
> to those problems, either.)

I think it was Itojun who told me that they looked at tying the  
default route to the source address but there were problems with  
that. No answers to my questions about what those problems are.

The implementers need to do something here.

> nothing's changed: ipv6 fails to solve the problems ipv4 had,
> and makes the problems ipv4 had even worse, but nevertheless it's  
> what we'll
> have to use while awaiting real innovation, to come, presumably or  
> hopefully,
> some time later.

The problem isn't that we don't know how to fix the problems: we do,  
and often the protocols exist. It's living with the tradeoffs that we  
as a community have a problem with. We want small routing tables, but  
we also want PI. We want stable addresses for applications so the  
network must figure out reachability, but we also want to connect to  
a remote host without delay. We want security and encryption, but not  
a PKI.

IPv6 has some innovation on the link, such as autoconfiguration,  
which many people don't like, by the way, but other than that, it's  
just IP that we know and love with larger addresses. So it has all  
the downsides of IPv4, only now we get to build a bigger network so  
the downsides are all the more troublesome.

> note: i'm not speaking as an arin trustee here.

Really?  :-)


From iljitsch at muada.com  Sun Sep  2 16:22:46 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Sun, 2 Sep 2007 22:22:46 +0200
Subject: [ppml] Legacy /24s
In-Reply-To: <1070901165207.964D-100000@Ives.egh.com>
References: <1070901165207.964D-100000@Ives.egh.com>
Message-ID: <28888CC0-AAFC-44F5-99A7-AB3E7B52DF34@muada.com>

On 1-sep-2007, at 22:56, John Santos wrote:

> I would like to point out for the millionth time that having PI
> space and taking up a routing slot are *NOT* the same thing.

> There are many legitimate uses of globally unique address space
> that don't require routing in the DFZ.  (For example private
> internets either on leased circuits or via VPN tunnels over
> the public Internet.)

So maybe we should set aside a specific block of PI prefixes for  
purposes that don't require them to be injected in the DFZ?


From iljitsch at muada.com  Sun Sep  2 16:36:35 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Sun, 2 Sep 2007 22:36:35 +0200
Subject: [ppml] Policy Proposal: Decreasing Exponential Rationingof	IPv4
	IP Addresses
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B0F275B3@E03MVC4-UKBR.domain1.systemhost.net>
References: <Pine.LNX.4.44.0708301647210.15082-100000@citation2.av8.net>
	<85975A4A-0077-4B71-B303-FD9FE27615F6@muada.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0F27485@E03MVC4-UKBR.domain1.systemhost.net>
	<8CC5B9B8-FB3D-4C7F-BD6B-089E31979FAD@muada.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0F275B3@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <F2328165-23C5-4207-9840-DF2E2D938817@muada.com>

On 2-sep-2007, at 18:00, <michael.dillon at bt.com>  
<michael.dillon at bt.com> wrote:

>> A few = generally 2 or 3 years. Is that enough to call a trend?

> If your data is monthly or weekly, then yes.

Have a look at the monthly data since 2006 and tell me if you can  
spot a trend:

                     14.05 M  2006-01
                     15.46 M  2006-02
                     19.02 M  2006-03
                     11.68 M  2006-04
                     15.01 M  2006-05
                      9.54 M  2006-06
                     21.43 M  2006-07
                     10.61 M  2006-08
                     15.29 M  2006-09
                     10.27 M  2006-10
                     20.30 M  2006-11
                     10.14 M  2006-12
                     16.59 M  2007-01
                     16.92 M  2007-02
                     20.75 M  2007-03
                      8.52 M  2007-04
                     20.08 M  2007-05
                     19.03 M  2007-06
                     21.12 M  2007-07
                     16.92 M  2007-08

>> You can arrive at pretty much any outcome by just selecting
>> the right start date.

> But can you find macroeconomic explanations to reinforce your  
> choice of
> a starting date, and your choice of a trend? Unless you can tie your
> numbers to macroeconomic triggers, they are just meaningless numbers.

Well, you wouldn't want to jump in at either the height of the boom  
or the depth of the bust, so you need to start in 2002 or so or  
before 1999...

>> But 1995 was the first year with growth
>> after the introduction of CIDR so we only have 12 years.
>> It's just not enough to come up with something better than 5
>> - 25 % growth per year = running out between Q3 2011 and Q3 2013.

> Instead of playing amateur statistician, I suggest that you give the
> data to a professional and see what they say.

The data is there for everyone to download, so professionals: have at  
it.

But my "amateur" take is that the data is simply to volatile and  
there have been too many fundamental changes (CIDR, broadband, .com  
boom, telecom bust) in too short a time to arrive at a real prediction.

But in another couple of years it doesn't matter anymore because  
we'll be so close that we know for sure we'll run out soon.


From colin at thusa.co.za  Sun Sep  2 17:55:59 2007
From: colin at thusa.co.za (Colin Alston)
Date: Sun, 02 Sep 2007 23:55:59 +0200
Subject: [ppml] IPv6 flawed?
In-Reply-To: <DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org>	<D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
Message-ID: <46DB316F.5050009@thusa.co.za>

On 02/09/2007 06:08 Michel Py wrote:
> - As it turned out down the road, the multiple-addresses-per-host are
> too much of an administrative overhead.
> 
> So we're in a situation where the only remaining real reason to upgrade
> to IPv6 is IPv4 address space exhaustion, while IPv6 still does not have
> hugely popular features such as NAT and no equivalent either.
> 
> Technically, I consider NAT more flawed than IPv6. Nevertheless, NAT has
> addressed market needs, while IPv6 is a solution without a market.

While I agree with a number of areas lacking in IPv6 implementation 
(DHCPv6 for example which is a bit broken on every implementation I've 
touched), I don't quite grok how that is a flaw in the protocol itself 
or how it influences adoption (aside from the argument that it has no 
market yet).

Mostly though, I don't understand the idea that peoples hardware 
hardware capabilities (router memory) and software implementations 
(NAT etc) are a fixed constraint that policy should work around.

-- 
Colin Alston <colin at thusa.co.za>


From bicknell at ufp.org  Sun Sep  2 18:41:27 2007
From: bicknell at ufp.org (Leo Bicknell)
Date: Sun, 2 Sep 2007 18:41:27 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
Message-ID: <20070902224127.GA93562@ussenterprise.ufp.org>

In a message written on Sun, Sep 02, 2007 at 12:29:31AM -0400, William Herrin wrote:
> Relatively speaking, there are few routers in the DFZ whose street
> price exceeds $150k. More, once you're past $150k the major cost
> driver is traffic capacity rather than route capacity.

*blink*

I have to say you're way off.  Many routers in the DFZ don't have
linecards that cost less than $150k.  Priced out an OC-192 card for
a T640 lately?  I've helped bring up many routers that cost well
over $2M when you consider the cost of all the cards in them.

A T640, 12416, or CSR-1 are all well over 150k to get the empty
chassis, and have linecards that run $100-$300k each.

> I pulled out and leafed through my old "Internet Protocol Next
> Generation" book from 1997. Do you realize just how few of the design
> goals have panned out operationally? Its appalling.

I believe the number that panned out would be zero so far, right?

-- 
       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/20070902/e407a59e/attachment.sig>

From paul at vix.com  Sun Sep  2 19:32:29 2007
From: paul at vix.com (Paul Vixie)
Date: Sun, 02 Sep 2007 23:32:29 +0000
Subject: [ppml] Legacy /24s
In-Reply-To: Your message of "Sun, 02 Sep 2007 18:41:27 -0400."
	<20070902224127.GA93562@ussenterprise.ufp.org> 
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
	<20070902224127.GA93562@ussenterprise.ufp.org> 
Message-ID: <17006.1188775949@sa.vix.com>

> > I pulled out and leafed through my old "Internet Protocol Next
> > Generation" book from 1997. Do you realize just how few of the design
> > goals have panned out operationally? Its appalling.
> 
> I believe the number that panned out would be zero so far, right?

judge for yourself at <http://playground.sun.com/ipv6/INET-IPng-Paper.html>.
i especially like section 11, "IPng Transition Mechanisms", which gets 
funnier every year, even without considering RFC 4966.  consider this gem:

	The IPng transition mechanisms ensures that IPv6 hosts can
	interoperate with IPv4 hosts anywhere in the Internet up until the
	time when IPv4 addresses run out, and allows IPv6 and IPv4 hosts
	within a limited scope to interoperate indefinitely after that. This
	feature protects the huge investment users have made in IPv4 and
	ensures that IPv6 does not render IPv4 obsolete. Hosts that need only
	a limited connectivity range (e.g., printers) need never be upgraded
	to IPv6.

that was the face that launched a thousand ships, yes.


From arin-contact at dirtside.com  Sun Sep  2 19:33:21 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Sun, 2 Sep 2007 19:33:21 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <20070902224127.GA93562@ussenterprise.ufp.org>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
	<20070902224127.GA93562@ussenterprise.ufp.org>
Message-ID: <3c3e3fca0709021633g5a02d19u3b7ab8e27ce48f56@mail.gmail.com>

On 9/2/07, Leo Bicknell <bicknell at ufp.org> wrote:
> A T640, 12416, or CSR-1 are all well over 150k to get the empty
> chassis, and have linecards that run $100-$300k each.

Leo,

Well, the 12416 fully loaded is running in the $10k to $80k range on
the second hand market right now. The T640 is running moderately
higher. I don't know about the CSR-1.

Anyway how many of these have been sold? 10k? 20k? And of the number
sold, how many have been deployed to Internet DFZ functions as opposed
to interior functions or enterprise functions? And where they were
deployed, was it because the prior router couldn't expand to meet the
traffic demand or was it because the prior router couldn't handle the
number of routes?

If you're telling me that 50% of the DFZ routers are these biggest of
the big iron and they face the same FIB issues as my poor Sup2 then my
estimate of a PI route's cost needs some revision. If you're talking
10% and and traffic capacity as the main driver then the impact on the
final numbers won't be enough to waste time on the analysis.


> > I pulled out and leafed through my old "Internet Protocol Next
> > Generation" book from 1997. Do you realize just how few of the design
> > goals have panned out operationally? Its appalling.
>
> I believe the number that panned out would be zero so far, right?

I didn't want to be the one to say it for fear that someone would
point out some clever function I overlooked.

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From randy at psg.com  Sun Sep  2 20:51:04 2007
From: randy at psg.com (Randy Bush)
Date: Mon, 03 Sep 2007 09:51:04 +0900
Subject: [ppml] Legacy /24s
In-Reply-To: <3c3e3fca0709021633g5a02d19u3b7ab8e27ce48f56@mail.gmail.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>	<20070901144553.GA494@ussenterprise.ufp.org>	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>	<20070902014003.GB31369@ussenterprise.ufp.org>	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>	<20070902224127.GA93562@ussenterprise.ufp.org>
	<3c3e3fca0709021633g5a02d19u3b7ab8e27ce48f56@mail.gmail.com>
Message-ID: <46DB5A78.5010807@psg.com>

William Herrin wrote:
> On 9/2/07, Leo Bicknell <bicknell at ufp.org> wrote:
>> A T640, 12416, or CSR-1 are all well over 150k to get the empty
>> chassis, and have linecards that run $100-$300k each.
> Well, the 12416 fully loaded is running in the $10k to $80k range on
> the second hand market right now. The T640 is running moderately
> higher. I don't know about the CSR-1.

so, to be a multi-homed enterprise on tomorrow's internet i need to run
one of these which i buy on the used market?

> Anyway how many of these have been sold? 10k? 20k?

hmmmmm

randy


From owen at delong.com  Mon Sep  3 03:14:22 2007
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Sep 2007 00:14:22 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org>
	<D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
	<11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>
Message-ID: <7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>


On Sep 2, 2007, at 1:21 PM, Iljitsch van Beijnum wrote:

> On 2-sep-2007, at 6:37, Paul Vixie wrote:
>
>>> - It never delivered initial promises, such as aggregation (the "8K
>>> DFZ"). In their great wisdom, the IETF pushed the protocol out
>>> with the
>>> promise that they will deliver the missing features (such as
>>> multihoming
>>> and effortless renumbering) later.
>
>> agreed.
>
> IETF is still working... And it's not like adopting PI in the mean
> time helps.
>
I strongly disagree.  Adopting PI in the mean time can serve as very
useful input to express to IETF that they _MUST_ solve the routing
problem in a scalable way.  And ID-Locator split is long overdue.
>
> That's only half a solution, the way it was written down 10 years ago
> doesn't do anything useful. If you fix the problems, you end up with
> something like shim6.
>
Shim6 is far too complicated to actually see reliable implementation
in the average enterprise and it does nothing to help with easy
renumbering.

> The problem isn't that we don't know how to fix the problems: we do,
> and often the protocols exist. It's living with the tradeoffs that we
> as a community have a problem with. We want small routing tables, but
> we also want PI. We want stable addresses for applications so the
> network must figure out reachability, but we also want to connect to
> a remote host without delay. We want security and encryption, but not
> a PKI.
>
We don't want small routing tables.  We want routing tables that fit
in existing hardware and a churn-rate which can be handled by the
hardware.  I don't think anyone actually cares if the routing table
is 10,000, 150,000, or 230,000 routes.  Sure, they worry if it's
500,000 routes or more, but, wanting to avoid an excruciatingly
large routing table is different from wanting a small one.

PI is a necessity.  CIDR and PA were horrible hacks put in
place as a band-aid until IPv6 could be engineered to truly
solve the routing problem in a scalable fashion.  I have no
idea why an ID/Locator split was not made a built-in part
of IPv6, but, I believe it can be added without reworking the
protocol, so, there is still a way forward.

> IPv6 has some innovation on the link, such as autoconfiguration,
> which many people don't like, by the way, but other than that, it's
> just IP that we know and love with larger addresses. So it has all
> the downsides of IPv4, only now we get to build a bigger network so
> the downsides are all the more troublesome.
>
IPv6 has worse downsides than IPv4.  I can see a few rare instances
where autoconfiguraiton could be considered a useful feature, but,
even in those cases, I don't see where it is significantly better than
DHCPv4.  Hopefully, eventually, DHCPv6 will be full featured, too,
and, stateless autoconf will take it's rightful place next to RARP as
something which works but is rarely used any more.

Owen



From owen at delong.com  Mon Sep  3 03:30:55 2007
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Sep 2007 00:30:55 -0700
Subject: [ppml] Legacy /24s
In-Reply-To: <3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
Message-ID: <D7946E90-A5FF-4D87-88F0-CAD86E6F9128@delong.com>

> Leo,
>
> Lets put some numbers to this so that we're arguing facts rather  
> than opinions.
>
> There are 233,000 IPv4 routes and a little under 1000 IPv6 routes in
> the default-free zone (DFZ) today.
>
Agreed...
> 10%-30% of the routers in the DFZ today have a hard limit between
> 244,000 and 260,000 IPv4 routes or half that number of IPv6 routes.
> When the limit is reached within the next few months, those routers
> will experience various degrees of falling over dead. Upgrading these
> routers to accomodate 1M IPv4 or 500k IPv6 routes will cost
> $30,000-$150,000 each.
>
I'm not so sure about your estimate of the number of routers in the DFZ
that would need to be upgraded or where you came up with that number,
but, for the moment, I can go with it.
> In the more general case, these routers have to be upgraded every  
> 3-5 years.
>
Most internet-oriented technology needs to be refreshed on a 2-4 year
life-cycle, actually.
> The number of routes and ASes in the DFZ implies that there are
> somewhere between 200,000 and 300,000 routers in the DFZ.
>
Here, I think you go off the rails with a big hand-wave.  How, exactly
do you think you can correlate the routes+ASs in the DFZ to the
number of routers participating in the DFZ?
> Lets start with the low numbers. If its $30k to put 233k routes in the
> DFZ then each route in each router costs around 13 cents. Times 200k
> routers offers an aggregate worldwide cost of $26,000 to announce an
> IPv4 route. The IPv6 routes consume twice the capacity in the router,
> so that means the worldwide cost of announcing an IPv6 prefix is
> $52,000. On a 3-year upgrade cycle that's an annual attributable cost
> of $17,300 per prefix.
>
Why is an IPv6 prefix 2x an IPv4 prefix?  It's 4x the prefix size,  
but, given
all the other path attributes and such, I still don't see that  
doubling the
storage requirements.

> Lets try the high numbers. $150k to handle 500,000 IPv6 routes = 30
> cents per route. Times 300k routers = $90l. Divide by a 5 year upgrade
> cycle = an annual attributable cost of $18,000 per prefix.
>
While I can potentially accept your price per route per router, I am not
sure I accept your computation of the number of routers it is multiplied
by.  This means that your $17-$18k per prefix per anum number is
very suspect since the 200k routers is a much bigger component
of the end number than the price per route.
> While this is not a thorough cost analysis, its reasonable for
> ballparking. I can say with an acceptable degree of confidence that
> the worldwide attributable cost of announcing one IPv6 prefix is
> between $17k and $18k per year.
>
I have less confidence in the number than you do.
>
> So, with any proposal to expand the availability of IPv6 PI, the
> question that should be asked is: "Does the proposed use in the
> expansion justify asking the rest of the world to pay $17k?"
>
Since that's 17k divided amongst 30k or so organizations, you're
really asking each other org. to foot a $0.50 bill per prefix.
>
> My opinion is that in the case of a multihomed content provider, the
> answer is yes. Why should he receive poor treatment in IPv6 merely
> because his mechanism for providing content was efficient enough to
> require only a few IP addresses? If you're willing to pay the prices
> that the network operators require to be mulithomed (whatever that
> happens to be) then you should be eligible for the necessary IPv6 PI
> assignment. That's just how the Internet functions and the $17k is a
> cost of doing business.
>
What about a multihomed content consumer?  Why should they
be treated any worse than a multihomed content provider?
> In the case of single-homed folks who just want to avoid renumbering
> hassles, I think you'd need an awfully large number of computers
> before the renumbering hassle adds up to $17k/yr. Many many computers.
>
You are missing a fundamental factor here.  The pain/cost of renumbering
is only marginally proportional to the number of hosts you own.  It  
is much
more affected by the number of hosts with your IPs in their  
configuration
files that you do not control.
> As for the folks who want to weasel out of the $100/yr annual
> maintenance fee for an IPv6 PI assignment, I would ask why anyone
> should take your request seriously when you're simultaneously asking
> the rest of the world to spend $17,000/yr on your behalf.
>
Nobody really cares about the $100/yr.  Proposals to waive that
have been targeted at providing what little incentive we can towards
other behaviors for the common good.

Owen



From michael.dillon at bt.com  Mon Sep  3 04:32:54 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 3 Sep 2007 09:32:54 +0100
Subject: [ppml] Policy Proposal: Decreasing Exponential Rationingof	IPv4
	IP Addresses
In-Reply-To: <F2328165-23C5-4207-9840-DF2E2D938817@muada.com>
References: <Pine.LNX.4.44.0708301647210.15082-100000@citation2.av8.net>
	<85975A4A-0077-4B71-B303-FD9FE27615F6@muada.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0F27485@E03MVC4-UKBR.domain1.systemhost.net>
	<8CC5B9B8-FB3D-4C7F-BD6B-089E31979FAD@muada.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0F275B3@E03MVC4-UKBR.domain1.systemhost.net>
	<F2328165-23C5-4207-9840-DF2E2D938817@muada.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B0F276C5@E03MVC4-UKBR.domain1.systemhost.net>


> >> A few = generally 2 or 3 years. Is that enough to call a trend?
> 
> > If your data is monthly or weekly, then yes.
> 
> Have a look at the monthly data since 2006 and tell me if you 
> can spot a trend:

Why? Geoff Huston has already done this at
http://www.potaroo.net/presentations/2007-07-23-ietf69-intarea-v4.pdf
If you look at slide 14, it seems pretty close to a linear trend. Of
course, the early stages of an exponential trend, also look pretty much
linear. In any case, that time period does not show any step changes in
the trend. The steps in the chart are the result of pent up demand being
satisfied, i.e. the short term trend appears to decrease but then
sharply rises. Over the longer term shown in slide 14, those steps
converge on a smooth trend that has show no inflection points, just a
slight uplift.

> But in another couple of years it doesn't matter anymore 
> because we'll be so close that we know for sure we'll run out soon.

And there you have a compelling business case for IPv6 deployment. 

--Michael Dillon


From iljitsch at muada.com  Mon Sep  3 04:39:49 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Mon, 3 Sep 2007 10:39:49 +0200
Subject: [ppml] The myth of IPv6-IPv4 interoperation, was: Re:  Legacy /24s
In-Reply-To: <17006.1188775949@sa.vix.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
	<20070902224127.GA93562@ussenterprise.ufp.org>
	<17006.1188775949@sa.vix.com>
Message-ID: <4CBA7EA2-DF77-4587-8063-9B7E1270F0C2@muada.com>

On 3-sep-2007, at 1:32, Paul Vixie wrote:

> <http://playground.sun.com/ipv6/INET-IPng-Paper.html>.
> i especially like section 11, "IPng Transition Mechanisms", which gets
> funnier every year, even without considering RFC 4966.  consider  
> this gem:

> 	The IPng transition mechanisms ensures that IPv6 hosts can
> 	interoperate with IPv4 hosts anywhere in the Internet up until the
> 	time when IPv4 addresses run out, and allows IPv6 and IPv4 hosts
> 	within a limited scope to interoperate indefinitely after that. This
> 	feature protects the huge investment users have made in IPv4 and
> 	ensures that IPv6 does not render IPv4 obsolete. Hosts that need only
> 	a limited connectivity range (e.g., printers) need never be upgraded
> 	to IPv6.

> that was the face that launched a thousand ships, yes.

It looks like you suffer from the (fairly common) misconception that  
goes along these lines:

     "If only the IETF had made IPv6 interoperable with IPv4,
     we wouldn't have any transition issues."

(See http://cr.yp.to/djbdns/ipv6mess.html )

The assumption here of course is that it would have been POSSIBLE to  
build IPv6 in such a way that an IPv6 host can talk to an IPv4 host.  
Unfortunately, it isn't. Or rather, the only way to do that is for  
the IPv6 host to stick to 32-bit addresses (by setting the other 96  
bits to 0 or some such and having something in the middle do the IPv6- 
IPv4 translation), because that's the only thing an IPv4 host  
understands.

This would work well as long as IPv6 hosts only use 32-bit addresses,  
but obviously, the idea behind IPv6 is that at some point, someone  
starts using an address that uses more than 32 bits. But this would  
be impossible, as there is no way to know whether a destination is a  
real IPv6 host that can handle the extra bits, or a fake IPv6 host  
that really does IPv4 behind the scenes which won't handle the longer  
addresses.

Today, the situation is much cleaner: do IPv4 and be limited to all  
that that entails, do IPv6 and the IPv4 limits go away. The presence  
or absense of AAAA records in the DNS tell you if someone you want to  
talk to can do IPv6 or not.

That is not to say that things couldn't have been better: rather than  
revisit all protocols that touch addresses and replace all the  
instances of 32-bit addresses with 128-bit ones, the IETF could have  
gone from 32-bit addresses to variable length, higher level  
identifiers, i.e., FQDNs, so the protocols became address length  
agnostic.


From iljitsch at muada.com  Mon Sep  3 04:57:21 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Mon, 3 Sep 2007 10:57:21 +0200
Subject: [ppml] IPv6 flawed?
In-Reply-To: <7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org>
	<D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
	<11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>
	<7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>
Message-ID: <647B3B9C-575A-44EE-B266-3AD5A40D1496@muada.com>

On 3-sep-2007, at 9:14, Owen DeLong wrote:

>> IETF is still working... And it's not like adopting PI in the mean
>> time helps.

> I strongly disagree.  Adopting PI in the mean time can serve as very
> useful input to express to IETF that they _MUST_ solve the routing
> problem in a scalable way.  And ID-Locator split is long overdue.

That's like everyone buying SUVs to signal that this global warming  
issue _MUST_ be solved.

My interpretation of the adoption of IPv6 PI was "the operational  
community doesn't consider routing table size an important issue".

> Shim6 is far too complicated to actually see reliable implementation
> in the average enterprise

Did you ever read the IPsec or SNMP RFCs? Those are at least an order  
of magnitude more complex, and enterprises managed to implement/ 
deploy them just fine.

> and it does nothing to help with easy renumbering.

My wireless keyboard doesn't help with easy renumbering either. I  
guess this means it's not a good keyboard.

> PI is a necessity.  CIDR and PA were horrible hacks

Without aggregation, routing only works by coincidence. Even WITH PA  
30k ASes results in a 230k routing table...

> put in
> place as a band-aid until IPv6 could be engineered to truly
> solve the routing problem in a scalable fashion.

Engineering scalable routing is not hard: create a big, fat  
hierarchy. It's getting scalable routing deployed and breaking pretty  
much all ISP business models in the process that is a challenge.

> I have no
> idea why an ID/Locator split was not made a built-in part
> of IPv6, but, I believe it can be added without reworking the
> protocol, so, there is still a way forward.

An id/loc split is certainly interesting, but what it basically does  
is say "having stable FQDNs and renumbering IP addresses is too hard,  
so now we're going to have stable FQDNs that map to stable id  
addresses which map to loc addresses which we WILL be able to  
renumber". It would be helpful to see evidence of that last part  
before we go down this road.

> IPv6 has worse downsides than IPv4.  I can see a few rare instances
> where autoconfiguraiton could be considered a useful feature, but,
> even in those cases, I don't see where it is significantly better than
> DHCPv4.

At the last IETF meeting, the DHCP server flaked out several times.  
IPv6 stateless autoconfig was solid as a rock. Same thing at a RIPE  
meeting a few years ago, unless I misremember. DHCP is actually not  
that easy to get right in the presence of failing hard- and software.  
With stateless autoconfig you can boot up a new router and take the  
old one down a few minutes later with no real service interruption.


From iljitsch at muada.com  Mon Sep  3 05:28:41 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Mon, 3 Sep 2007 11:28:41 +0200
Subject: [ppml] Policy Proposal: Decreasing Exponential Rationingof	IPv4
	IP Addresses
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B0F276C5@E03MVC4-UKBR.domain1.systemhost.net>
References: <Pine.LNX.4.44.0708301647210.15082-100000@citation2.av8.net>
	<85975A4A-0077-4B71-B303-FD9FE27615F6@muada.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0F27485@E03MVC4-UKBR.domain1.systemhost.net>
	<8CC5B9B8-FB3D-4C7F-BD6B-089E31979FAD@muada.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0F275B3@E03MVC4-UKBR.domain1.systemhost.net>
	<F2328165-23C5-4207-9840-DF2E2D938817@muada.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0F276C5@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <C9E9585A-A94E-46D4-B295-9E9906B1FFD6@muada.com>

On 3-sep-2007, at 10:32, <michael.dillon at bt.com>  
<michael.dillon at bt.com> wrote:

>> Have a look at the monthly data since 2006 and tell me if you
>> can spot a trend:

> Why? Geoff Huston has already done this at
> http://www.potaroo.net/presentations/2007-07-23-ietf69-intarea-v4.pdf

Ok. This looks fairly smooth: whether any given month sees 10 or 20  
million new addresses doesn't mean much relative to the ~ 2.5 billion  
already given out.

> If you look at slide 14, it seems pretty close to a linear trend.

You have to remember that in 2005 and 2006, almost exactly the same  
number of addresses was given out, hence the linearity. However, 2007  
so far is noticeably higher, which doesn't show up. If you go back to  
before 2005, things look very different.

I'm not sure what the number on the Y axis are, by the way.  
Apparently, on january first this year, we were at about "163".  
However, the total amount of address space given out to end-users/ 
LIRs/ISPs at that time, excluding the IANA free space and the RIR  
space that wasn't further delegated, was 2407 million addresses,  
143.5 /8s. There are 3707 million usable IPv4 addresses = 221 /8s, so  
the projection on this slide would indicate complete IPv4 depletion  
somewhere in 2013.

> The steps in the chart are the result of pent up demand being
> satisfied,

How can you have pent-up demand for IP addresses??


From colin at thusa.co.za  Mon Sep  3 06:01:57 2007
From: colin at thusa.co.za (Colin Alston)
Date: Mon, 03 Sep 2007 12:01:57 +0200
Subject: [ppml] IPv6 flawed?
In-Reply-To: <647B3B9C-575A-44EE-B266-3AD5A40D1496@muada.com>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org>	<D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>	<1712.1188707832@sa.vix.com>	<11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>	<7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>
	<647B3B9C-575A-44EE-B266-3AD5A40D1496@muada.com>
Message-ID: <46DBDB95.6010408@thusa.co.za>

On 03/09/2007 10:57 Iljitsch van Beijnum wrote:
> At the last IETF meeting, the DHCP server flaked out several times.  
> IPv6 stateless autoconfig was solid as a rock. Same thing at a RIPE  
> meeting a few years ago, unless I misremember. DHCP is actually not  
> that easy to get right in the presence of failing hard- and software.  
> With stateless autoconfig you can boot up a new router and take the  
> old one down a few minutes later with no real service interruption.

Off-topic, but RADV can't provide autoconfiguration of DNS [1], WINS, 
TFTP, dynamic DNS updates and NTP servers etc - something critical to 
most operations especially in the VoIP world with PnP SIP phones.

I think the volume of current DHCPv4 capabilities would be easiest to 
(and, well, already have been) implement in DHCPv6 rather than hacks 
to stateless autoconfiguration as part of the IPv6 standard.

[1] - There is this draft RFC.. 
http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-jeong-ipv6-ra-dns-autoconf-00.txt

-- 
Colin Alston <colin at thusa.co.za>     ______
Linux & Internet Services           /\_\_\_\
Thusa Business Support (Pty) Ltd   /\/\_\_\_\
http://www.thusa.co.za/           /\/\/\_\_\_\
Tel:  (+27) 031 277 1257          \/\/\/_/_/_/
Fax:  (+27) 031 277 1269           \/\/_/_/_/
                                     \/_/_/_/
"To the world you may be one person, to one person you may be the 
world" ~ Rachel Ann Nunes.


From arin-contact at dirtside.com  Mon Sep  3 10:27:14 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Mon, 3 Sep 2007 10:27:14 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <D7946E90-A5FF-4D87-88F0-CAD86E6F9128@delong.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<D7946E90-A5FF-4D87-88F0-CAD86E6F9128@delong.com>
Message-ID: <3c3e3fca0709030727v6caddbccsea573ddd3b288c76@mail.gmail.com>

On 9/3/07, Owen DeLong <owen at delong.com> wrote:
> Most internet-oriented technology needs to be refreshed on a 2-4 year
> life-cycle, actually.

I generally get better results from my equipment buy YMMV.


> > The number of routes and ASes in the DFZ implies that there are
> > somewhere between 200,000 and 300,000 routers in the DFZ.
> >
> Here, I think you go off the rails with a big hand-wave.  How, exactly
> do you think you can correlate the routes+ASs in the DFZ to the
> number of routers participating in the DFZ?

As I said before, its a SWAG. Some of the better educated responders
suggest that I'm around 50k too high here with the actual number in
the 150k-250k range.


> Why is an IPv6 prefix 2x an IPv4 prefix?

That's what Cisco is claiming in their documentation. 1M IPv4 routes
or 500k IPv6 routes. I assume this probably means they're stashing the
first 64 bits into the TCAM and bouncing it up to the software if you
need a route more specific than /64. Sounds sloppy to me but I'm not
Cisco.


> > So, with any proposal to expand the availability of IPv6 PI, the
> > question that should be asked is: "Does the proposed use in the
> > expansion justify asking the rest of the world to pay $17k?"
>
> Since that's 17k divided amongst 30k or so organizations, you're
> really asking each other org. to foot a $0.50 bill per prefix.

26109 AS's according to the latest routing table report yielding
closer to $0.65. But that's a false way of looking at problem. Some
AS's have one DFZ router. Some have many. None interact with the
problem in terms of individual routes; they have to deal with the
whole route count.

Looking at the cost of an individual route is useful in terms of the
whole systemic cost accross the entire DFZ.


> > My opinion is that in the case of a multihomed content provider, the
> > answer is yes. Why should he receive poor treatment in IPv6 merely
>
> What about a multihomed content consumer?  Why should they
> be treated any worse than a multihomed content provider?

Because non-PI multihoming solutions for the NATed content consumer
are relatively trivial to build.


> Nobody really cares about the $100/yr.  Proposals to waive that
> have been targeted at providing what little incentive we can towards
> other behaviors for the common good.

Yet the original posters in this thread brought it up as a complaint.

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From paul at vix.com  Mon Sep  3 11:11:43 2007
From: paul at vix.com (Paul Vixie)
Date: Mon, 03 Sep 2007 15:11:43 +0000
Subject: [ppml] The myth of IPv6-IPv4 interoperation,
	was: Re: Legacy /24s
In-Reply-To: Your message of "Mon, 03 Sep 2007 10:39:49 +0200."
	<4CBA7EA2-DF77-4587-8063-9B7E1270F0C2@muada.com> 
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
	<20070902224127.GA93562@ussenterprise.ufp.org>
	<17006.1188775949@sa.vix.com>
	<4CBA7EA2-DF77-4587-8063-9B7E1270F0C2@muada.com> 
Message-ID: <53709.1188832303@sa.vix.com>

> It looks like you suffer from the (fairly common) misconception

what an unnecessarily harsh way to phrase your difference of opinion.  "ouch."

> that goes along these lines:
> 
>      "If only the IETF had made IPv6 interoperable with IPv4,
>      we wouldn't have any transition issues."
> 
> (See http://cr.yp.to/djbdns/ipv6mess.html )

no.  we would still have transition issues.  just not this one.

> The assumption here of course is that it would have been POSSIBLE to  
> build IPv6 in such a way that an IPv6 host can talk to an IPv4 host.  

that was a design goal.  of the IPng candidates being proferred, the one we've
got now was chosen to become IPv6 on the basis of the features it offered.  if
it wasn't possible to deliver this, then it's possible a different choice
might have been made.  but more to the point, if the paragraph i quoted had
been true then IPv6 would be in wide deployment today and the IPv4 runout
would be a yawner.

> 	The IPng transition mechanisms ensures that IPv6 hosts can
> 	interoperate with IPv4 hosts anywhere in the Internet up until the
> 	time when IPv4 addresses run out, and allows IPv6 and IPv4 hosts
> 	within a limited scope to interoperate indefinitely after that.  This
> 	feature protects the huge investment users have made in IPv4 and
> 	ensures that IPv6 does not render IPv4 obsolete. Hosts that need only
> 	a limited connectivity range (e.g., printers) need never be upgraded
> 	to IPv6.
>
>	(From <http://playground.sun.com/ipv6/INET-IPng-Paper.html>.)


From arin-contact at dirtside.com  Mon Sep  3 11:15:45 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Mon, 3 Sep 2007 11:15:45 -0400
Subject: [ppml] The myth of IPv6-IPv4 interoperation,
	was: Re: Legacy /24s
In-Reply-To: <4CBA7EA2-DF77-4587-8063-9B7E1270F0C2@muada.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
	<20070902224127.GA93562@ussenterprise.ufp.org>
	<17006.1188775949@sa.vix.com>
	<4CBA7EA2-DF77-4587-8063-9B7E1270F0C2@muada.com>
Message-ID: <3c3e3fca0709030815s35f15bb1m8bdcf4125057b4e8@mail.gmail.com>

On 9/3/07, Iljitsch van Beijnum <iljitsch at muada.com> wrote:
> It looks like you suffer from the (fairly common) misconception that
> goes along these lines:
>
>      "If only the IETF had made IPv6 interoperable with IPv4,
>      we wouldn't have any transition issues."
>
> The assumption here of course is that it would have been POSSIBLE to
> build IPv6 in such a way that an IPv6 host can talk to an IPv4 host.

Iljitsch,

That's nonsense. Perhaps you misunderstand the character of backwards
compatibility. Its not a deep technical concept. It has much more to
do with technical and administrative policy decisions and it could
have been implemented with the IPv6 protocol that we actually created.

Consider the following theoretical ruleset:

1. IPv4 addresses map to the IPv6 address space by placing zeros at the front.

2. Any router which receives an IPv4 packet for a destination that is
only served through an IPv6-only trunk must translate the IPv4 packet
to a corresponding IPv6 packet.

3. Any router which receives an IPv6 packet for a destination that is
only served through an IPv4-only trunk must translate the IPv6 packet
to a corresponding IPv4 packet.

4. Any host which implements both IPv4 and IPv6 must consider a return
packet of the other type than the originated packet to be a valid part
of the same communication and should attempt to synchronize with the
same IP version as the remote host.

What are the compatibility consequences of such a ruleset?

A. Once I upgrade the IOS on my Cisco and install the patch from
Microsoft, all of my equipment automatically operates with the new
protocol. There are no new IP addresses to obtain and no configuration
changes to make.

B. The old sockets API works until you want to initiate a connection
to an address that's beyond the scope of the IPv4 addresses. It can
even originate IPv6 packets and accept connections from high-order
addresses, albeit with faulty logging.

C. You can't accomplish most of the subsidiary goals that IPv6 was
intended to accomplish. But then, none of them actually panned out
opertionally anyway.


That's a pretty high level of compatibility. And that's just with the
IPv6 protocol we have. Even greater compatibility gains are possible
with something like http://bill.herrin.us/network/ipxl.html

Regards,
Bill Herrin



-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From iljitsch at muada.com  Mon Sep  3 11:33:38 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Mon, 3 Sep 2007 17:33:38 +0200
Subject: [ppml] The myth of IPv6-IPv4 interoperation,
	was: Re: Legacy /24s
In-Reply-To: <53709.1188832303@sa.vix.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
	<20070902224127.GA93562@ussenterprise.ufp.org>
	<17006.1188775949@sa.vix.com>
	<4CBA7EA2-DF77-4587-8063-9B7E1270F0C2@muada.com>
	<53709.1188832303@sa.vix.com>
Message-ID: <2DA9EA61-683C-437C-BE47-BA8FB44097AC@muada.com>

On 3-sep-2007, at 17:11, Paul Vixie wrote:

>> It looks like you suffer from the (fairly common) misconception

> what an unnecessarily harsh way to phrase your difference of  
> opinion.  "ouch."

Sorry about that, but I figured you'd set me straight if you  
didn't.  :-)

>> The assumption here of course is that it would have been POSSIBLE to
>> build IPv6 in such a way that an IPv6 host can talk to an IPv4 host.

> that was a design goal.

A few years in the multi6 trenches taught me a thing or two about  
design goals...

> of the IPng candidates being proferred, the one we've
> got now was chosen to become IPv6 on the basis of the features it  
> offered.  if
> it wasn't possible to deliver this, then it's possible a different  
> choice
> might have been made.  but more to the point, if the paragraph i  
> quoted had
> been true then IPv6 would be in wide deployment today and the IPv4  
> runout
> would be a yawner.

The point is that the transition to another address length inherently  
means that hosts only implementing the shorter length can't talk to  
ones only implementing the larger length if those actually get to use  
that length as opposed to the old length and a bunch of 0 bits.


From michael.dillon at bt.com  Mon Sep  3 12:38:17 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 3 Sep 2007 17:38:17 +0100
Subject: [ppml] The myth of IPv6-IPv4 interoperation,
	was: Re: Legacy /24s
In-Reply-To: <2DA9EA61-683C-437C-BE47-BA8FB44097AC@muada.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net><859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local><20070901144553.GA494@ussenterprise.ufp.org><3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com><20070902014003.GB31369@ussenterprise.ufp.org><3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com><20070902224127.GA93562@ussenterprise.ufp.org><17006.1188775949@sa.vix.com><4CBA7EA2-DF77-4587-8063-9B7E1270F0C2@muada.com><53709.1188832303@sa.vix.com>
	<2DA9EA61-683C-437C-BE47-BA8FB44097AC@muada.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B0F27B32@E03MVC4-UKBR.domain1.systemhost.net>

> The point is that the transition to another address length 
> inherently means that hosts only implementing the shorter 
> length can't talk to ones only implementing the larger length 
> if those actually get to use that length as opposed to the 
> old length and a bunch of 0 bits.

Hmmm... Hosts implementing globally unique IPv4 addresses can't talk to
ones only implementing non-unique addresses.

True on the surface of it, but in practice people use NAT proxies and a
significant percentage of Internet traffic is between such incompatible
IPv4 hosts. 

Given that IPv4-IPv6 proxying is as simple to implement as PNAT, one
wonders why people are making such a fuss.

--Michael Dillon


From cliffb at cjbsys.bdb.com  Mon Sep  3 13:09:47 2007
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Mon, 3 Sep 2007 13:09:47 -0400 (EDT)
Subject: [ppml] Legacy /24s (fwd)
Message-ID: <200709031709.l83H9lW9023907@cjbsys.bdb.com>

I forgot to CC PPML for this

 
 Stuff deleted
 > 
 > 
 > > Nobody really cares about the $100/yr.  Proposals to waive that
 > > have been targeted at providing what little incentive we can towards
 > > other behaviors for the common good.
 > 
 > Yet the original posters in this thread brought it up as a complaint.
 
 I don't know if I was one of the original posters but I think I mentioned the
 fee as one more thing that takes away from enthusiasm to go to ipv6.  No
 legacy user who is paying for a /24 connection has any right to complain about 
 the $100.00.  I assume most are far more concerned about having the /24 
 reclaimed or in some way restricted if they sign an RSA and become an
 "official" part of ARIN.  I think many believe that since ARIN has taken no
 action to bring them into the fold for 10 years, they are "common law"
 grandfathered into the internet and any actions they take to acknowledge ARIN
 oversight would jeopardize that.  I tend to be suspicious of anybody who says
 "We're from the government/ARIN/... and we're here to help you". :-)  Put
 another way, "Just because I'm paranoid doesn't mean they're not out to get
 me"  Policy Proposal 2007-15 to stop allowing changes to our resource records 
 to force us to join ARIN does not give me a warm and fuzzy feeling about
 ARIN's intentions. Paranoid? maybe but see above. :-)
 
 Cliff
 
 > 
 > Regards,
 > Bill Herrin
 > 
 > 
 > -- 
 > William D. Herrin                  herrin at dirtside.com  bill at herrin.us
 > 3005 Crane Dr.                        Web: <http://bill.herrin.us/>
 > Falls Church, VA 22042-3004
 > _______________________________________________
 > PPML
 > You are receiving this message because you are subscribed to the ARIN Public Policy
 > Mailing List (PPML at arin.net).
 > Unsubscribe or manage your mailing list subscription at:
 > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
 > Help Desk at info at arin.net if you experience any issues.
 > 
 
 
-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20740
cliffb at cjbsys.bdb.com http://www.bdb.com
Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/


From colin at thusa.co.za  Mon Sep  3 13:09:51 2007
From: colin at thusa.co.za (Colin Alston)
Date: Mon, 03 Sep 2007 19:09:51 +0200
Subject: [ppml] The myth of IPv6-IPv4 interoperation,
 was: Re: Legacy /24s
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B0F27B32@E03MVC4-UKBR.domain1.systemhost.net>
References: <mailman.4174.1188583766.29428.ppml@arin.net><859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local><20070901144553.GA494@ussenterprise.ufp.org><3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com><20070902014003.GB31369@ussenterprise.ufp.org><3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com><20070902224127.GA93562@ussenterprise.ufp.org><17006.1188775949@sa.vix.com><4CBA7EA2-DF77-4587-8063-9B7E1270F0C2@muada.com><53709.1188832303@sa.vix.com>	<2DA9EA61-683C-437C-BE47-BA8FB44097AC@muada.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0F27B32@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <46DC3FDF.80203@thusa.co.za>

On 03/09/2007 18:38 michael.dillon at bt.com wrote:
> Given that IPv4-IPv6 proxying is as simple to implement as PNAT, one
> wonders why people are making such a fuss.

I think you mean IPv6 to IPv4 proxying? Letting IPv4-only hosts talk 
to IPv6 is an impossibility. Unless CERN finish the LHC and find the 
"answers to the universe" soon or something that is ;-)

-- 
Colin Alston <colin at thusa.co.za>     ______
Linux & Internet Services           /\_\_\_\
Thusa Business Support (Pty) Ltd   /\/\_\_\_\
http://www.thusa.co.za/           /\/\/\_\_\_\
Tel:  (+27) 031 277 1257          \/\/\/_/_/_/
Fax:  (+27) 031 277 1269           \/\/_/_/_/
                                     \/_/_/_/
"To the world you may be one person, to one person you may be the 
world" ~ Rachel Ann Nunes.


From michael.dillon at bt.com  Mon Sep  3 14:42:56 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 3 Sep 2007 19:42:56 +0100
Subject: [ppml] The myth of IPv6-IPv4 interoperation,
	was: Re: Legacy /24s
In-Reply-To: <46DC3FDF.80203@thusa.co.za>
References: <mailman.4174.1188583766.29428.ppml@arin.net><859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local><20070901144553.GA494@ussenterprise.ufp.org><3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com><20070902014003.GB31369@ussenterprise.ufp.org><3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com><20070902224127.GA93562@ussenterprise.ufp.org><17006.1188775949@sa.vix.com><4CBA7EA2-DF77-4587-8063-9B7E1270F0C2@muada.com><53709.1188832303@sa.vix.com>	<2DA9EA61-683C-437C-BE47-BA8FB44097AC@muada.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0F27B32@E03MVC4-UKBR.domain1.systemhost.net>
	<46DC3FDF.80203@thusa.co.za>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B0F7DE89@E03MVC4-UKBR.domain1.systemhost.net>

> > Given that IPv4-IPv6 proxying is as simple to implement as 
> PNAT, one 
> > wonders why people are making such a fuss.
> 
> I think you mean IPv6 to IPv4 proxying? Letting IPv4-only 
> hosts talk to IPv6 is an impossibility. Unless CERN finish 
> the LHC and find the "answers to the universe" soon or 
> something that is ;-)

Proxying is always possible. Sometimes it mixes layers, but it is always
possible.

Let's give a concrete example. Joe's ISP in Lower Podunk has 80% of the
households on his dial-up IPv4 service. There is no broadband in Lower
Podunk and likely never will be due to the limited population, lack of
growth in the county, and generally rural spread of households. So Joe's
ISP has no plans to switch to IPv6 for at least the next 5 - 10 years.

Google acquires Facebook, launches the new GoogleBook service on the
IPv6 Internet only, and the state department of education announces that
all universities will be closed and higher education will only be
available on GoogleBook. Does Joe have a problem?

No, of course not. He puts A records for GoogleBook into his DNS servers
pointing at his V6 proxy. The proxy is actually hosted in the state
capital where IPv6 service is readly available. Joe's customers can now
use GoogleBook's IPv6 services via Joe's proxy server. Since GoogleBook
is implemented using the standard HTTP protocol, it doesn't much matter
whether there is IPv6 or v4 underneath. In fact, Joe's proxy functions
much like an IPv4 NAT box except that it uses unique IPv6 addresses for
each customer session rather than an address/port pair as in IPv4 NAT.

Operationally, you can expect people to just fix problems and make it
work, not agonize over whether or not the IETF could have documented
that solution 10 years ago.

--Michael Dillon


From bicknell at ufp.org  Mon Sep  3 15:12:27 2007
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 3 Sep 2007 15:12:27 -0400
Subject: [ppml] Legacy /24s
In-Reply-To: <3c3e3fca0709021633g5a02d19u3b7ab8e27ce48f56@mail.gmail.com>
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
	<20070902224127.GA93562@ussenterprise.ufp.org>
	<3c3e3fca0709021633g5a02d19u3b7ab8e27ce48f56@mail.gmail.com>
Message-ID: <20070903191227.GB61706@ussenterprise.ufp.org>

In a message written on Sun, Sep 02, 2007 at 07:33:21PM -0400, William Herrin wrote:
> Well, the 12416 fully loaded is running in the $10k to $80k range on
> the second hand market right now. The T640 is running moderately
> higher. I don't know about the CSR-1.

And the second hand market generally provids them at around $0.10
on the dollar, so there's an idea of what the companies paid for
them brand new.

> If you're telling me that 50% of the DFZ routers are these biggest of
> the big iron and they face the same FIB issues as my poor Sup2 then my
> estimate of a PI route's cost needs some revision. If you're talking
> 10% and and traffic capacity as the main driver then the impact on the
> final numbers won't be enough to waste time on the analysis.

No, that's not what I'm telling you.  I'm telling you that if I'm
a large ISP, and I have a POP with 20 Cisco 7513's still aggregating
DS-3 customers that my upgrade is not going to be 20 new whatevers.
It's going to be 5 new 12416's or T640's, perhaps not with DS-3
cards but with channelized OC-48 cards, which require upgrades to
my telco infrastructure as well.

Now, that's not all for IPv6.  If you were trying to divide up cost,
some is convenience, some is what is supported, some is where you
think your business is going.

Even if you can pull out a Sup720-3B and replace it with a Sup720-3BLX
(which is a relatively cheap upgrade as box upgrades go) that still
may not be a smart move.  If you're running all older linecards and
about to hit the traffic wall that requires all distributed linecards
in less than a year you may look at swapping out the entire chassis
anyway.

At the end of the day, there's two costs to consider.  The cost
directly attributable to IPv6, and the additional cost of "if we're
going to do these upgrades now, we might as well do these other
things because it makes sense."

However, I think we are running fairly far afield here, point is, adding
routes to the global table is "expensive", which is why the community
likes to avoid it, where possible.

-- 
       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/20070903/6a520168/attachment.sig>

From paul at vix.com  Mon Sep  3 16:48:54 2007
From: paul at vix.com (Paul Vixie)
Date: Mon, 03 Sep 2007 20:48:54 +0000
Subject: [ppml] Legacy /24s
In-Reply-To: Your message of "Mon, 03 Sep 2007 15:12:27 -0400."
	<20070903191227.GB61706@ussenterprise.ufp.org> 
References: <mailman.4174.1188583766.29428.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
	<3c3e3fca0709011140h3cf98b99teed4982f4d01be3b@mail.gmail.com>
	<20070902014003.GB31369@ussenterprise.ufp.org>
	<3c3e3fca0709012129j2488d83fv9895236f75284deb@mail.gmail.com>
	<20070902224127.GA93562@ussenterprise.ufp.org>
	<3c3e3fca0709021633g5a02d19u3b7ab8e27ce48f56@mail.gmail.com>
	<20070903191227.GB61706@ussenterprise.ufp.org> 
Message-ID: <32810.1188852534@sa.vix.com>

i was with you right up to this:

> However, I think we are running fairly far afield here, point is, adding
> routes to the global table is "expensive", which is why the community likes
> to avoid it, where possible.

all human actions, according to von mises and others, have costs and benefits.
for the action of "add one more route to the global table" the cost is borne
by the community and the principle benefit comes to the actor.

what the community is looking for isn't growth avoidance per se, but rather,
cost:benefit symmetry.  if someone's bringing in compelling content or large
populations of new eyeballs, then global table growth has a community benefit
that offsets its community cost.  if myspace wants to multihome a /24 for a
web service that makes 3G cell phones sell like hotcakes, then the community
would be ready to say "sure, take a slot for that."  if vixie enterprises
wants to multihome a /24 so as to avoid a renumbering penalty when we change
providers, the community would be ready to say, "why don't you go pound sand?"

again, table growth isn't by itself a leading indicator of goodness/badness.
it's cost:benefit symmetry at the community level that gets people out of bed
and has them flaming on PPML in their bathrobes in the middle of sunday night.


From peter at boku.net  Mon Sep  3 17:39:18 2007
From: peter at boku.net (Peter Eisch)
Date: Mon, 03 Sep 2007 16:39:18 -0500
Subject: [ppml] Legacy /24s
In-Reply-To: <32810.1188852534@sa.vix.com>
Message-ID: <C301E936.8C647%peter@boku.net>

On 9/3/07 3:48 PM, "Paul Vixie" <paul at vix.com> wrote:

>> However, I think we are running fairly far afield here, point is, adding
>> routes to the global table is "expensive", which is why the community likes
>> to avoid it, where possible.
> 
> all human actions, according to von mises and others, have costs and benefits.
> for the action of "add one more route to the global table" the cost is borne
> by the community and the principle benefit comes to the actor.

Let's roll back the clock, I want to run full routes on my c1750!

I need all the "big ISPs" with their non-aggregated advertisements to
renumber into a single network that they announce in their single AS (not
multiple ASes, but SINGLE AS).  One route per slot and slot per org, no more
for all traffic they originate!

Bless the multi-homed nets.  If small-time vixienet is multi-homed, we have
to pay for the slot regardless if it's a /24 or a /20 and nobody needs to be
pounding sand.  If vixienet or myspace isn't multi-homed, then, I agree,
that it is an exception that needs to be eliminated for the purposes of "the
community."

Why is the elephant in the room, er this list, that while costs need to be
managed on all sides that there is a specific cost of doing business.  If
you want to be a carrier, then be a carrier.  If you can only afford to do
aggregation to a carrier, then be an aggregator.  As the requirements for
the routing hardware increase, the number of organizations able to carry
full routes will decrease.  (Notably if they're not able to budget and plan
for the growth.)  Where's the problem?

peter



From michael.dillon at bt.com  Tue Sep  4 08:15:34 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 4 Sep 2007 13:15:34 +0100
Subject: [ppml] IPv6 addressing plans
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B0F7E1F0@E03MVC4-UKBR.domain1.systemhost.net>

Does anyone have any reasoning why a network spanning two or more of the
RIR regions, should or should not get separate ISP allocations from each
region?

I'm not just interested in opinions, but also the reasoning behind them,
especially any technical pros and cons.

In addition, are there any characteristics that define a good IPv6
addressing plan for a network operator?

We've just received an IPv6 /22 from RIPE based solely on projections in
our European network infrastructure. Fairly soon we will have to decide
whether to internally assign chunks of that space to our North American
network or to go to ARIN for a separate IPv6 allocation based on North
American needs only.

I imagine that a number of other companies are in this position and if
there is actually a best practice for IPv6 addressing, it would be good
to document it and follow it before deployment gets much further ahead.
On the other hand, if it is a coin-toss scenario from a technical point
of view, it would be nice to see general acknowledgement of that fact.

--Michael Dillon


From kkargel at polartel.com  Tue Sep  4 10:13:31 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 4 Sep 2007 09:13:31 -0500
Subject: [ppml] Legacy /24s
In-Reply-To: <20070901144553.GA494@ussenterprise.ufp.org>
References: <mailman.4174.1188583766.29428.ppml@arin.net><859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local>
	<20070901144553.GA494@ussenterprise.ufp.org>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667073CB@mail>

 As for the untold billions out there, "a day late or a dollar short"
applies to everything else in business..  why should this be any
different?



> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Leo Bicknell
> Sent: Saturday, September 01, 2007 9:46 AM
> To: ppml at arin.net
> Subject: Re: [ppml] Legacy /24s
> 
> In a message written on Fri, Aug 31, 2007 at 03:03:08PM 
> -0500, mack wrote:
> > 3) Most of these are individuals or small companies that 
> don't have significant resources.
> 
> So individuals and small businesses should be allowed to eat 
> up routing slots in tens of thousands of routers worldwide 
> collectively costing ISP's millions of dollars in capital, if 
> and only if they were smart enough to get an "early" IPv4 allocation?
> 
> What about the billions of other individuals and millions of 
> other businesses in the world?  Why do they not qualify for 
> such special treatment?
> 
> -- 
>        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
> 


From owen at delong.com  Tue Sep  4 10:45:29 2007
From: owen at delong.com (Owen DeLong)
Date: Tue, 4 Sep 2007 07:45:29 -0700
Subject: [ppml] IPv6 addressing plans
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B0F7E1F0@E03MVC4-UKBR.domain1.systemhost.net>
References: <D03E4899F2FB3D4C8464E8C76B3B68B0F7E1F0@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <B9023006-C67E-483C-BBC2-1FCA24B133CB@delong.com>

I would tend to think that the correct answer would depend a lot on  
your internal
topology and how those segments connect to the internet.

If they are a single contiguous autonomous system with a consistent  
routing
policy, then, it makes sense to advertise an aggregate and accept  
traffic wherever
it is presented.  OTOH, if you need to manage the arrival location of  
traffic
on a continental or other topological basis, then, it probably makes  
more
sense to get separate assignments accordingly.

I don't think there is a good one-size-fits all BCP answer to your  
question.

Owen

On Sep 4, 2007, at 5:15 AM, <michael.dillon at bt.com>  
<michael.dillon at bt.com> wrote:

> Does anyone have any reasoning why a network spanning two or more  
> of the
> RIR regions, should or should not get separate ISP allocations from  
> each
> region?
>
> I'm not just interested in opinions, but also the reasoning behind  
> them,
> especially any technical pros and cons.
>
> In addition, are there any characteristics that define a good IPv6
> addressing plan for a network operator?
>
> We've just received an IPv6 /22 from RIPE based solely on  
> projections in
> our European network infrastructure. Fairly soon we will have to  
> decide
> whether to internally assign chunks of that space to our North  
> American
> network or to go to ARIN for a separate IPv6 allocation based on North
> American needs only.
>
> I imagine that a number of other companies are in this position and if
> there is actually a best practice for IPv6 addressing, it would be  
> good
> to document it and follow it before deployment gets much further  
> ahead.
> On the other hand, if it is a coin-toss scenario from a technical  
> point
> of view, it would be nice to see general acknowledgement of that fact.
>
> --Michael Dillon
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.



From stephen at sprunk.org  Tue Sep  4 12:00:37 2007
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 4 Sep 2007 11:00:37 -0500
Subject: [ppml] IPv6 addressing plans
References: <D03E4899F2FB3D4C8464E8C76B3B68B0F7E1F0@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <010501c7ef0f$2bdcb160$533816ac@atlanta.polycom.com>

Thus spake <michael.dillon at bt.com>
> Does anyone have any reasoning why a network spanning two or
> more of the RIR regions, should or should not get separate ISP
> allocations from each region?
>
> I'm not just interested in opinions, but also the reasoning behind
> them, especially any technical pros and cons.
>
> In addition, are there any characteristics that define a good IPv6
> addressing plan for a network operator?
>
> We've just received an IPv6 /22 from RIPE based solely on
> projections in our European network infrastructure. Fairly soon
> we will have to decide whether to internally assign chunks of that
> space to our North American network or to go to ARIN for a
> separate IPv6 allocation based on North American needs only.

It is generally assumed, if not stated explicitly in policy, that addresses 
issued by an RIR are for use within that region only.  If the use outside 
the region is a negligible part of address use, nobody's going to complain, 
but you shouldn't be assigning space _to customers_ in the US from a RIPE 
block, and vice versa.

Also, if your network in the US is of non-negligible size, it's assumed that 
the topology is going to be mostly independent and will be a separate AS 
speaking BGP to your AS in Europe.  In that case, your US network would be a 
separate "organization", and would be no different in the RIRs' eyes than if 
your networks were two independent companies.  You probably have separate 
legal entities in such a case anyways, though that's not technically 
required for you to claim multi-organization status.  Multiple organizations 
should not "share" blocks between them, because that makes paperwork -- and 
routing -- a mess.

Another thought is that using the same block in multiple regions would 
defeat RIR-level aggregation; if RIPE-issued blocks are all exclusively used 
in the RIPE region, smaller (i.e. non-global) players in other regions can 
filter them from their routers and just point a static route for all of 
RIPE's address space "that way", i.e. towards Europe.  If, in contrast, you 
use your RIPE block in the US, people can't do that and we're doomed to 
every DFZ player having to carry redundant routes for other regions (or 
implement difficult-to-maintain filter lists) just to handle the few 
exceptions.

The main justification I see for using a block outside the region that 
issued it is if your use in the other region is not sufficient to get a 
block from the appropriate RIR.  This might be the case for a European ISP 
that buys a pipe to show up at a US IXP, or vice versa; addressing a couple 
routers is not enough to get a block from the "correct" RIR, but it makes 
sense to use addresses from the "wrong" RIR in such a case.  Likewise, if an 
end-user org has a PI assignment from a certain region, it makes sense that 
all their sites worldwide would use addresses from that block _if they did 
not have connectivity to the outside world except through the issuing 
region_.  For instance, if a office in Moscow has to go through HQ in the US 
to reach the Internet (which is not unusual), they should be addressed from 
that company's ARIN block; if they got a second connection in Europe, the 
sites behind that connection should be renumbered to RIPE space.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 




From packetgrrl at gmail.com  Tue Sep  4 12:27:58 2007
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Tue, 4 Sep 2007 10:27:58 -0600
Subject: [ppml] IPv6 addressing plans
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B0F7E1F0@E03MVC4-UKBR.domain1.systemhost.net>
References: <D03E4899F2FB3D4C8464E8C76B3B68B0F7E1F0@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <c3227e9e0709040927t629124fdpf5b5f81b00c23395@mail.gmail.com>

Michael,

I used to run a network that had allocations from the (at the time) 3 RIRs.
I did that on purpose for a couple of reasons.

- The networks were connected in a way that it made sense to have RIR based
allocations
-  I wanted our networks and the people who ran them to be active in the
appropriate communities.
-  The deployment schedules and address space utilization rates were
significantly different from region to region. If we had it all from ARIN we
probably would have had to have three separate allocations with different
maintainer IDs anyway.

I can tell you this.  And I know you're not going to believe me but it was
much much easier to deal with ARIN's policies than the policies of the other
RIRs.   We had a very small allocation window size from RIPE and so if we
wanted to assign a subnet greater than a /29 to a customer we had to ask
permission.  Even when it was raised to a /24 it was a total pain.  Further
there were some really interesting requirements of cable providers in RIPE
and APNIC that we had to work with the communities to fix.  That actually
went very smoothly.

We were certainly told that we could have all of our allocations from ARIN
because our company headquarters was in the US.  There were days that I
wished I had done just that.  I think we did greatly benefit from being
active in all the regions and knowing the regional ISP communities was also
a great benefit.

I hope this helps.
----Cathy


On 9/4/07, michael.dillon at bt.com <michael.dillon at bt.com> wrote:
>
> Does anyone have any reasoning why a network spanning two or more of the
> RIR regions, should or should not get separate ISP allocations from each
> region?
>
> I'm not just interested in opinions, but also the reasoning behind them,
> especially any technical pros and cons.
>
> In addition, are there any characteristics that define a good IPv6
> addressing plan for a network operator?
>
> We've just received an IPv6 /22 from RIPE based solely on projections in
> our European network infrastructure. Fairly soon we will have to decide
> whether to internally assign chunks of that space to our North American
> network or to go to ARIN for a separate IPv6 allocation based on North
> American needs only.
>
> I imagine that a number of other companies are in this position and if
> there is actually a best practice for IPv6 addressing, it would be good
> to document it and follow it before deployment gets much further ahead.
> On the other hand, if it is a coin-toss scenario from a technical point
> of view, it would be nice to see general acknowledgement of that fact.
>
> --Michael Dillon
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member
> Services
> Help Desk at info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070904/6ca3d38c/attachment.htm>

From marla.azinger at frontiercorp.com  Tue Sep  4 12:57:07 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Tue, 4 Sep 2007 12:57:07 -0400
Subject: [ppml] IPv6 addressing plans
Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272FA02@nyrofcs2ke2k01.corp.pvt>

You might find the following document that is working its way through IETF right now useful.  http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addcon-05.txt
 
Also, I would stick to getting IPv6 Allocations from the respective RIR.  All the same routing reasons still apply to IPv6 at this time as they do for IPv4.  Maybe architectural changes could occur in the future...but we are not there yet.
 
Another one to read: ftp://ftp.isi.edu/in-notes/rfc1519.txt and http://www.ietf.org/rfc/rfc3177.txt.  I thought there was another document for guidance to ISP's...but I cant seem to find it.
 
Cheers!
Marla

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of cja at daydream.com
Sent: Tuesday, September 04, 2007 9:28 AM
To: michael.dillon at bt.com
Cc: ppml at arin.net
Subject: Re: [ppml] IPv6 addressing plans


Michael,

I used to run a network that had allocations from the (at the time) 3 RIRs.  I did that on purpose for a couple of reasons.

- The networks were connected in a way that it made sense to have RIR based allocations 
-  I wanted our networks and the people who ran them to be active in the appropriate communities.  
-  The deployment schedules and address space utilization rates were significantly different from region to region. If we had it all from ARIN we probably would have had to have three separate allocations with different maintainer IDs anyway.  

I can tell you this.  And I know you're not going to believe me but it was much much easier to deal with ARIN's policies than the policies of the other RIRs.   We had a very small allocation window size from RIPE and so if we wanted to assign a subnet greater than a /29 to a customer we had to ask permission.  Even when it was raised to a /24 it was a total pain.  Further there were some really interesting requirements of cable providers in RIPE and APNIC that we had to work with the communities to fix.  That actually went very smoothly.  

We were certainly told that we could have all of our allocations from ARIN because our company headquarters was in the US.  There were days that I wished I had done just that.  I think we did greatly benefit from being active in all the regions and knowing the regional ISP communities was also a great benefit.  

I hope this helps.  
----Cathy



On 9/4/07, michael.dillon at bt.com <  <mailto:michael.dillon at bt.com> michael.dillon at bt.com> wrote: 

Does anyone have any reasoning why a network spanning two or more of the 
RIR regions, should or should not get separate ISP allocations from each
region?

I'm not just interested in opinions, but also the reasoning behind them,
especially any technical pros and cons.

In addition, are there any characteristics that define a good IPv6
addressing plan for a network operator?

We've just received an IPv6 /22 from RIPE based solely on projections in
our European network infrastructure. Fairly soon we will have to decide 
whether to internally assign chunks of that space to our North American
network or to go to ARIN for a separate IPv6 allocation based on North
American needs only.

I imagine that a number of other companies are in this position and if 
there is actually a best practice for IPv6 addressing, it would be good
to document it and follow it before deployment gets much further ahead.
On the other hand, if it is a coin-toss scenario from a technical point 
of view, it would be nice to see general acknowledgement of that fact.

--Michael Dillon
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy 
Mailing List ( PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml  <http://lists.arin.net/mailman/listinfo/ppml> Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070904/fbd95713/attachment.htm>

From iljitsch at muada.com  Tue Sep  4 14:09:21 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Tue, 4 Sep 2007 20:09:21 +0200
Subject: [ppml] IPv6 addressing plans
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B0F7E1F0@E03MVC4-UKBR.domain1.systemhost.net>
References: <D03E4899F2FB3D4C8464E8C76B3B68B0F7E1F0@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <689E3E7C-82E0-4470-ACD4-11A6FEB4F0B7@muada.com>

On 4-sep-2007, at 14:15, <michael.dillon at bt.com>  
<michael.dillon at bt.com> wrote:

> Does anyone have any reasoning why a network spanning two or more  
> of the
> RIR regions, should or should not get separate ISP allocations from  
> each
> region?

Well obviously arbitrary administrativia trumps using up routing  
table slots.

</sarcasm>

Although in your case it doesn't matter much because by the time all  
the IPv6 space is sliced in /22s (or /23s) we can route a million of  
them without any trouble.

> We've just received an IPv6 /22 from RIPE

Yeah, they should stop doing that.

> based solely on projections in our European network infrastructure.

Especially based on projections that may or may not pan out.


From briand at ca.afilias.info  Tue Sep  4 14:13:53 2007
From: briand at ca.afilias.info (briand at ca.afilias.info)
Date: Tue, 4 Sep 2007 14:13:53 -0400 (EDT)
Subject: [ppml] IPv6 flawed?
In-Reply-To: <7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org>
	<D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
	<11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>
	<7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>
Message-ID: <60037.74.122.168.81.1188929633.squirrel@look.libertyrms.com>

Owen DeLong wrote:
> On Sep 2, 2007, at 1:21 PM, Iljitsch van Beijnum wrote:
>>
>> IETF is still working... And it's not like adopting PI in the mean
>> time helps.
>>
> I strongly disagree.  Adopting PI in the mean time can serve as very
> useful input to express to IETF that they _MUST_ solve the routing
> problem in a scalable way.  And ID-Locator split is long overdue.

> We don't want small routing tables.  We want routing tables that fit
> in existing hardware and a churn-rate which can be handled by the
> hardware.  I don't think anyone actually cares if the routing table
> is 10,000, 150,000, or 230,000 routes.  Sure, they worry if it's
> 500,000 routes or more, but, wanting to avoid an excruciatingly
> large routing table is different from wanting a small one.

There are a number of considerations we need, as a community, to address:
- in the short-term, much/most of the DFZ will be dual-stack
- the DFZ routers will carry both IPv4 and IPv6
- collectively, the short-term needs of DFZ networks cannot be ignored
- this specifically includes hard limits on DFZ prefix counts
- breaking the hard limit will most likely result in IPv6 getting tossed
- IPv6 needs to not be tossed to avoid a "big crunch" around 2010

So, the short term need, to avoid a "tragedy of the commons" effect,
where short term is likely 3-5 years, is that O(IPv6 PI) == O(ASNs).
Meaning, we need to keep PI space down to about 1 per ASN.

And after 3-5 years, with widespread adoption, there may not be any
(compelling) reason to change that policy.

So, as long as you mean "routing table" to be "IPv4 + IPv6" routing table
aggregate, then yes, 10k vs 150k vs 250k is mostly unimportant.
Which translates into "very few IPv6 routes".

Brian Dickson



From info at arin.net  Wed Sep  5 08:44:04 2007
From: info at arin.net (Member Services)
Date: Wed, 05 Sep 2007 08:44:04 -0400
Subject: [ppml] Policy Proposal 2007-24: IPv6 Assignment Guidelines
Message-ID: <46DEA494.9040001@arin.net>

On 30 August 2007, the ARIN Advisory Council (AC) concluded their
initial review of "IPv6 Assignment Guidelines" and accepted it as a 
formal policy proposal for discussion by the community.

The proposal is designated Policy Proposal 2007-24: IPv6 Assignment
Guidelines. The proposal text is below and can be found at:
http://www.arin.net/policy/proposals/2007_24.html

All persons in the community are encouraged to discuss Policy Proposal
2007-24 prior to it being presented at the ARIN Public Policy Meeting in
Albuquerque, New Mexico, 17-18 October 2007. Both the discussion on the
Public Policy Mailing List and at the Public Policy Meeting will be used
to determine the community consensus regarding this policy proposal.

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Proposal 2007-24
IPv6 Assignment Guidelines

Author: Leo Bicknell and Ed Lewis

Proposal type: new

Policy term: permanent

Policy statement:

Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 with
the following text:

Assignments by LIRs /48 or smaller will not be reviewed by ARIN.
Assignments greater than /48 will be reviewed to see if the additional
space is warranted according to the 0.94 HD ratio policy. If the space
is not warranted, ARIN will consider the excess space to be available
for a different assignment, lowering the overall utilization score of
the LIR.

Rationale:

The existing section 6.5.4.1 does not provide clear guidance on how ARIN
should treat prefixes allocated to a site should an ISP come back for
additional space in the future. This makes it difficult for LIR's to
know if they are allocating in accordance with the rules under which
they will be judged in the future. The existing section also provides no
guidence on what the LIR or ARIN should do in the case a larger prefix
is necessary.

Timetable for implementation: immediate






From info at arin.net  Wed Sep  5 08:45:06 2007
From: info at arin.net (Member Services)
Date: Wed, 05 Sep 2007 08:45:06 -0400
Subject: [ppml] Policy Proposal 2007-25: IPv6 Policy Housekeeping
Message-ID: <46DEA4D2.3070409@arin.net>

On 30 August 2007, the ARIN Advisory Council (AC) concluded their
initial review of "IPv6 Policy Housekeeping" and accepted it as a formal 
policy proposal for discussion by the community.

The proposal is designated Policy Proposal 2007-25: IPv6 Policy
Housekeeping. The proposal text is below and can be found at:
http://www.arin.net/policy/proposals/2007_25.html

All persons in the community are encouraged to discuss Policy Proposal
2007-25 prior to it being presented at the ARIN Public Policy Meeting in
Albuquerque, New Mexico, 17-18 October 2007. Both the discussion on the
Public Policy Mailing List and at the Public Policy Meeting will be used
to determine the community consensus regarding this policy proposal.

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 2007-25
IPv6 Policy Housekeeping

Author: Leo Bicknell

Proposal type: modify

Policy term: permanent

Policy statement:

Change I:

In section 6.5.1.1.d, replace the existing statement with the new statement:

"be an existing, known ISP in the ARIN region or have a plan for making
at least 200 end-site assignments to other organizations within 5 years."

Change J:

Remove section 6.5.3 entirely. Update all subsequent sections to have
new section numbers (6.5.[n-1]).

Replace part of the text as (new) section 6.5.4.4:

"All /56 and larger assignments to end sites are required to be
registered either by the LIR or its subordinate ISPs in such a way that
the RIR/NIR can properly evaluate the HD-Ratio when a subsequent
allocation becomes necessary."

Change K:

Section 6.5.8.2, add the following sentence to the end of the first
paragraph:

"An HD-Ratio of .94 must be met for all assignments larger than a /48."

Add to the end of the second paragraph:

"This reservation may be assigned to other organizations later, at
ARIN's discretion."

Change L:

Section 6.5.8.3, add a sentence between the two existing sentences:

"Justification will be determined based on the .94 HD-Ratio metric."


Rationale:

When the IPv6 policy was passed, it was considered to be an "interim"
policy, and it was intended to be similar in all 5 RIR's. Since that
time it has become clear the policy is no longer interim (and proposal
2007-4 was passed to change just that) and it has also been modified
separately in the different RIR's.

It was brought to the ARIN AC's attention that there were a number of
problems with "Section 6" of the NRPM as a result of this legacy:

* The policy contained a large number of items that were not policy. *
The policy contained a few items that were self contradictory. * The
added text was redundant in some cases with existing text. * The policy
was overly vague in a few areas, leaving ARIN staff to have to make
interpretations of what the policy intended. * Policy changes made since
the initial IPv6 policy was adopted have not always updated all of the
relevant sections due to the complexity of section 6.

The intent of these changes is not to change any existing policy, but
rather to remove all non-policy items, and update any ambiguous items
with the way that ARIN staff is currently interprets the policy.

Change I:

Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64
allocations, but section 6.5.1.1.d was never updated to match the
change. It is believed the intent of the policy, and ARIN staff's
current interpretation of the policy match the updated text.

Change J:

The first part is not policy, and incorrectly states there is no policy
as section 6.5.4 has the policy in it. Take the one useful part and make
it part of the 6.5.4 criteria.

Change K:

No metric is currently listed to justify a larger initial assignment. It
is believed ARIN staff is currently applying the HD-Ratio similar to the
ISP policy, this puts that in writing.

Make it clear that the reservation may not exist in perpetuity.

Change L:

No metric is given to justify additional assignments. It is believed
that ARIN staff is currently applying the HD_Ratio similar to the ISP
policy, this puts that in writing.

Timetable for implementation: Immediate







From briand at ca.afilias.info  Wed Sep  5 10:36:02 2007
From: briand at ca.afilias.info (briand at ca.afilias.info)
Date: Wed, 5 Sep 2007 10:36:02 -0400 (EDT)
Subject: [ppml] Policy Proposal: Decreasing Exponential Rationingof	IPv4
 IP Addresses
In-Reply-To: <F2328165-23C5-4207-9840-DF2E2D938817@muada.com>
References: <Pine.LNX.4.44.0708301647210.15082-100000@citation2.av8.net>
	<85975A4A-0077-4B71-B303-FD9FE27615F6@muada.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0F27485@E03MVC4-UKBR.domain1.systemhost.net>
	<8CC5B9B8-FB3D-4C7F-BD6B-089E31979FAD@muada.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0F275B3@E03MVC4-UKBR.domain1.systemhost.net>
	<F2328165-23C5-4207-9840-DF2E2D938817@muada.com>
Message-ID: <64004.74.122.168.81.1189002962.squirrel@look.libertyrms.com>

Iljitch wrote:

> Have a look at the monthly data since 2006 and tell me if you can
> spot a trend:

[monthly data snipped]

Taking the monthly data, and doing sliding window averages, trends
show up pretty quickly. There's annual cyclical variances, but year
over year, each month should show the same trend.

Sliding average data on 4-month window:
4 month sliding window average ending 2006-04 is 15.05
4 month sliding window average ending 2006-05 is 15.29
4 month sliding window average ending 2006-06 is 13.81
4 month sliding window average ending 2006-07 is 14.41
4 month sliding window average ending 2006-08 is 14.15
4 month sliding window average ending 2006-09 is 14.22
4 month sliding window average ending 2006-10 is 14.40
4 month sliding window average ending 2006-11 is 14.12
4 month sliding window average ending 2006-12 is 14.00
4 month sliding window average ending 2007-01 is 14.32
4 month sliding window average ending 2007-02 is 15.99
4 month sliding window average ending 2007-03 is 16.10
4 month sliding window average ending 2007-04 is 15.70
4 month sliding window average ending 2007-05 is 16.57
4 month sliding window average ending 2007-06 is 17.09
4 month sliding window average ending 2007-07 is 17.19
4 month sliding window average ending 2007-08 is 19.29

Two observations:
- monthly averages > 14M/month
- trending upwards (however slightly)

> But in another couple of years it doesn't matter anymore because
> we'll be so close that we know for sure we'll run out soon.

Bingo. Monotonically increasing usage, and increasing rate of usage.
We will run out, and reasonably soon. Even if the rate flattens, e.g at
20M/month, we will still exhaust the pool in << 5 years. Whether it is
3, 4, or 5 years, that's still a very short time to be fully IPv6+IPv4,
for those who want to be around after IPv4 addresses are very hard to get.

Brian



From sleibrand at internap.com  Wed Sep  5 14:08:15 2007
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 05 Sep 2007 11:08:15 -0700
Subject: [ppml] Policy Proposal 2007-24: IPv6 Assignment Guidelines
In-Reply-To: <46DEA494.9040001@arin.net>
References: <46DEA494.9040001@arin.net>
Message-ID: <46DEF08F.8080209@internap.com>

I support this policy, as it seems to be a reasonable clarification of 
ARIN policy on the subject, without any onerous restrictions on LIR 
decision making.

I would hope that ARIN staff would interpret "Assignments greater than 
/48 will be reviewed" to mean that they would review the assignments 
only if/when the LIR asks for additional IPv6 address space.  (That's my 
interpretation of the intent of the proposal.  If the Author's intent 
differs, please speak up.)

-Scott

Member Services wrote:
> On 30 August 2007, the ARIN Advisory Council (AC) concluded their
> initial review of "IPv6 Assignment Guidelines" and accepted it as a 
> formal policy proposal for discussion by the community.
>
> The proposal is designated Policy Proposal 2007-24: IPv6 Assignment
> Guidelines. The proposal text is below and can be found at:
> http://www.arin.net/policy/proposals/2007_24.html
>
> All persons in the community are encouraged to discuss Policy Proposal
> 2007-24 prior to it being presented at the ARIN Public Policy Meeting in
> Albuquerque, New Mexico, 17-18 October 2007. Both the discussion on the
> Public Policy Mailing List and at the Public Policy Meeting will be used
> to determine the community consensus regarding this policy proposal.
>
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
>
> ARIN's Policy Proposal Archive can be found at:
> http://www.arin.net/policy/proposals/proposal_archive.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Proposal 2007-24
> IPv6 Assignment Guidelines
>
> Author: Leo Bicknell and Ed Lewis
>
> Proposal type: new
>
> Policy term: permanent
>
> Policy statement:
>
> Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 with
> the following text:
>
> Assignments by LIRs /48 or smaller will not be reviewed by ARIN.
> Assignments greater than /48 will be reviewed to see if the additional
> space is warranted according to the 0.94 HD ratio policy. If the space
> is not warranted, ARIN will consider the excess space to be available
> for a different assignment, lowering the overall utilization score of
> the LIR.
>
> Rationale:
>
> The existing section 6.5.4.1 does not provide clear guidance on how ARIN
> should treat prefixes allocated to a site should an ISP come back for
> additional space in the future. This makes it difficult for LIR's to
> know if they are allocating in accordance with the rules under which
> they will be judged in the future. The existing section also provides no
> guidence on what the LIR or ARIN should do in the case a larger prefix
> is necessary.
>
> Timetable for implementation: immediate
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>   


From bicknell at ufp.org  Wed Sep  5 20:18:26 2007
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 5 Sep 2007 20:18:26 -0400
Subject: [ppml] Policy Proposal 2007-24: IPv6 Assignment Guidelines
In-Reply-To: <46DEF08F.8080209@internap.com>
References: <46DEA494.9040001@arin.net> <46DEF08F.8080209@internap.com>
Message-ID: <20070906001826.GA84006@ussenterprise.ufp.org>

In a message written on Wed, Sep 05, 2007 at 11:08:15AM -0700, Scott Leibrand wrote:
> I would hope that ARIN staff would interpret "Assignments greater than 
> /48 will be reviewed" to mean that they would review the assignments 
> only if/when the LIR asks for additional IPv6 address space.  (That's my 
> interpretation of the intent of the proposal.  If the Author's intent 
> differs, please speak up.)

It's probably not wrong to think about it that way, but that's not
exactly my intent.  ARIN today does sometimes do reviews outside
of a renewal request.  I don't know when those occur today, but
they would also be an appropriate time.

I don't think this language would increase (or decrease) the number
of times ARIN would ask for the information, it just clarifies what
they will ask for when they do ask.  I'm not interested in changing
the frequency of review, just clarifing what happens when there is
a review.

-- 
       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/20070905/a0469a84/attachment.sig>

From sleibrand at internap.com  Wed Sep  5 21:01:05 2007
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 05 Sep 2007 18:01:05 -0700
Subject: [ppml] Policy Proposal 2007-24: IPv6 Assignment Guidelines
In-Reply-To: <20070906001826.GA84006@ussenterprise.ufp.org>
References: <46DEA494.9040001@arin.net> <46DEF08F.8080209@internap.com>
	<20070906001826.GA84006@ussenterprise.ufp.org>
Message-ID: <46DF5151.70906@internap.com>

Leo Bicknell wrote:
>
> ARIN today does sometimes do reviews outside
> of a renewal request.  I don't know when those occur today, but
> they would also be an appropriate time.
>
> I don't think this language would increase (or decrease) the number
> of times ARIN would ask for the information, it just clarifies what
> they will ask for when they do ask.  I'm not interested in changing
> the frequency of review, just clarifing what happens when there is
> a review.
>   
Fair enough: as long as it doesn't require ARIN to review more than they 
otherwise would that's fine with me.

-Scott


From drc at virtualized.org  Wed Sep  5 21:30:22 2007
From: drc at virtualized.org (David Conrad)
Date: Wed, 5 Sep 2007 18:30:22 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <60037.74.122.168.81.1188929633.squirrel@look.libertyrms.com>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org>
	<D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
	<11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>
	<7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>
	<60037.74.122.168.81.1188929633.squirrel@look.libertyrms.com>
Message-ID: <AF699AB3-F131-4174-B881-F602A5D93140@virtualized.org>

Brian,

On Sep 4, 2007, at 11:13 AM, briand at ca.afilias.info wrote:
> - breaking the hard limit will most likely result in IPv6 getting  
> tossed

Very true.  An interesting point I hadn't really considered.

> So, the short term need, to avoid a "tragedy of the commons" effect,
> where short term is likely 3-5 years, is that O(IPv6 PI) == O(ASNs).
> Meaning, we need to keep PI space down to about 1 per ASN.

According to <http://www.conference.sanog.org/slides/conference/ 
sanog10-pfs-deaggregation-report.pdf>, we're seeing the  
"deaggregation factor" increase "slowly and steadily since 'records  
began'", with the fastest growth occurring in the "new" Internet (the  
graph on page 15 is very interesting).  Since IPv6 uses the same  
routing and traffic engineering technology as IPv4, I am curious what  
constraints could be put in place to keep PI space down to about 1  
per ASN.  Particularly given PI allocation policies either have been  
or are being liberalized in all the RIRs (for sound economic and  
business reasons, at least from the perspective of the Internet end  
users).

Perhaps more distressingly, if you believe the post IPv4 run out  
world is going to be awash with long prefixes taken from holders of  
legacy space as IPv4 address space is used more efficiently after  
free pool run out, the deaggregation factor of the "old" Internet is  
likely going to ramp up quite quickly.  This would seem to imply IPv6  
could get strangled long before it could take off, regardless of RIR  
allocation policies.

Regards,
-drc



From dlw+arin at tellme.com  Thu Sep  6 12:30:42 2007
From: dlw+arin at tellme.com (David Williamson)
Date: Thu, 6 Sep 2007 09:30:42 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <AF699AB3-F131-4174-B881-F602A5D93140@virtualized.org>
References: <D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
	<11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>
	<7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>
	<60037.74.122.168.81.1188929633.squirrel@look.libertyrms.com>
	<AF699AB3-F131-4174-B881-F602A5D93140@virtualized.org>
Message-ID: <20070906163042.GE23217@shell01.cell.sv2.tellme.com>

On Wed, Sep 05, 2007 at 06:30:22PM -0700, David Conrad wrote:
> Since IPv6 uses the same  
> routing and traffic engineering technology as IPv4, I am curious what  
> constraints could be put in place to keep PI space down to about 1  
> per ASN.  Particularly given PI allocation policies either have been  
> or are being liberalized in all the RIRs (for sound economic and  
> business reasons, at least from the perspective of the Internet end  
> users).

I don't understand why you single out PI holders in this.  I'm
wondering how many ASNs now advertise more than 2 PI prefixes...I know
that the six ASNs I have some control over have single PI chunks
assigned to them.  I have an association with another org that has two
PI announcements from a single AS, primarily because one of them is
from the class C swamp.

I suspect that PA holders are just as guilty of deaggregation.  Outside
of TE or simple sloppiness, there's been a lot of business activity
that leads to a lot of mergers and associated extra announcements.

Finally, there's all of the PA space that's getting used for
multi-homing.  From a routing point of view, that's exactly the same as
PI space - it's some smallish chunk in the middle of some other block
that's still attached to a single ASN (and different from the parent
chunk).

I'm sorry, but I don't see how PI space (when used responsibly) is a
culprit in the growth of the routing table any more than PA space.  The
real culprit is multi-homing and TE.  Clearly, we should just forbid
that.  (Yeah, right.)

As a network operator, I entirely agree that the problem is going to
come to a head at some point, and things are going to break.  What
things break and how remains to be seen...but something has got to
change.

Personally, I suspect we're going to see more and more long IPv4
prefixes in the DFZ.  I don't think it's up to ARIN or the other RIRs
to figure out how that will work.  I do think it's up to ARIN to hand
out space in a sensible manner, possibly including longer prefix PI and
PA space.  The routing community is going to have to figure out how to
either:

a) scale the routing system appropriately, or

b) figure out how to value a specific prefix.

For the latter, consider if windowsupdate.microsoft.com was a single
VIP or set of VIPs that resides in a /29.  As an ISP, would you route
that /29?  You bet you would...or you'd lose customers to the guy that
is.  How do you differentiate the value of that /29 versus some random
/29 that appears in the routing system for something of much lesser
value?  I haven't the faintest idea on that.  If I did, I'd quit may
day job and start consulting full-time.

Anyway, now that I've ranted on this topic space a bit, I'm hoping
someone can provide some numbers to show that PI space is more
responsible than PA space for the deaggregation noted in the posts in
this thread.  I really don't see it as any different.

-David


From marla.azinger at frontiercorp.com  Thu Sep  6 12:42:40 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Thu, 6 Sep 2007 12:42:40 -0400
Subject: [ppml] IPv6 flawed?
Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272FA07@nyrofcs2ke2k01.corp.pvt>

ok.  you got me wondering...

Do you have any stats you can provide that show PA IPv6 being subnetted down more specific than a /32 and actually getting through routers that way?  And if yes, how many?  I would love to see the actual numbers.  I dont mean to be snarky, I just really want to know if this is really happening with PA space on large, medium or small scale.

And whether its perception or reality, I dont know.  I would love to see the stats on PI space being routed and successfully making its way through filters in anything more specific than the original allocation from its RIR.  I believe just based on the nature of how current policy is written in ARIN RIR for PI, it naturally lends itself to being used for multihoming and TE.

And just for the record.  Long live multihoming and TE!  ;o)

Cheers!
Marla Azinger
Frontier Communications

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
David Williamson
Sent: Thursday, September 06, 2007 9:31 AM
To: David Conrad
Cc: Public Policy Mailing List
Subject: Re: [ppml] IPv6 flawed?


On Wed, Sep 05, 2007 at 06:30:22PM -0700, David Conrad wrote:
> Since IPv6 uses the same  
> routing and traffic engineering technology as IPv4, I am curious what  
> constraints could be put in place to keep PI space down to about 1  
> per ASN.  Particularly given PI allocation policies either have been  
> or are being liberalized in all the RIRs (for sound economic and  
> business reasons, at least from the perspective of the Internet end  
> users).

I don't understand why you single out PI holders in this.  I'm
wondering how many ASNs now advertise more than 2 PI prefixes...I know
that the six ASNs I have some control over have single PI chunks
assigned to them.  I have an association with another org that has two
PI announcements from a single AS, primarily because one of them is
from the class C swamp.

I suspect that PA holders are just as guilty of deaggregation.  Outside
of TE or simple sloppiness, there's been a lot of business activity
that leads to a lot of mergers and associated extra announcements.

Finally, there's all of the PA space that's getting used for
multi-homing.  From a routing point of view, that's exactly the same as
PI space - it's some smallish chunk in the middle of some other block
that's still attached to a single ASN (and different from the parent
chunk).

I'm sorry, but I don't see how PI space (when used responsibly) is a
culprit in the growth of the routing table any more than PA space.  The
real culprit is multi-homing and TE.  Clearly, we should just forbid
that.  (Yeah, right.)

As a network operator, I entirely agree that the problem is going to
come to a head at some point, and things are going to break.  What
things break and how remains to be seen...but something has got to
change.

Personally, I suspect we're going to see more and more long IPv4
prefixes in the DFZ.  I don't think it's up to ARIN or the other RIRs
to figure out how that will work.  I do think it's up to ARIN to hand
out space in a sensible manner, possibly including longer prefix PI and
PA space.  The routing community is going to have to figure out how to
either:

a) scale the routing system appropriately, or

b) figure out how to value a specific prefix.

For the latter, consider if windowsupdate.microsoft.com was a single
VIP or set of VIPs that resides in a /29.  As an ISP, would you route
that /29?  You bet you would...or you'd lose customers to the guy that
is.  How do you differentiate the value of that /29 versus some random
/29 that appears in the routing system for something of much lesser
value?  I haven't the faintest idea on that.  If I did, I'd quit may
day job and start consulting full-time.

Anyway, now that I've ranted on this topic space a bit, I'm hoping
someone can provide some numbers to show that PI space is more
responsible than PA space for the deaggregation noted in the posts in
this thread.  I really don't see it as any different.

-David
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.


From sethm at rollernet.us  Thu Sep  6 12:44:59 2007
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 06 Sep 2007 09:44:59 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <20070906163042.GE23217@shell01.cell.sv2.tellme.com>
References: <D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
	<11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>
	<7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>
	<60037.74.122.168.81.1188929633.squirrel@look.libertyrms.com>
	<AF699AB3-F131-4174-B881-F602A5D93140@virtualized.org>
	<20070906163042.GE23217@shell01.cell.sv2.tellme.com>
Message-ID: <46E02E8B.3080204@rollernet.us>

David Williamson wrote:
> On Wed, Sep 05, 2007 at 06:30:22PM -0700, David Conrad wrote:
>> Since IPv6 uses the same  
>> routing and traffic engineering technology as IPv4, I am curious what  
>> constraints could be put in place to keep PI space down to about 1  
>> per ASN.  Particularly given PI allocation policies either have been  
>> or are being liberalized in all the RIRs (for sound economic and  
>> business reasons, at least from the perspective of the Internet end  
>> users).
> 
> I don't understand why you single out PI holders in this.  I'm
> wondering how many ASNs now advertise more than 2 PI prefixes...I know
> that the six ASNs I have some control over have single PI chunks
> assigned to them.  I have an association with another org that has two
> PI announcements from a single AS, primarily because one of them is
> from the class C swamp.
> 
> I suspect that PA holders are just as guilty of deaggregation.  Outside
> of TE or simple sloppiness, there's been a lot of business activity
> that leads to a lot of mergers and associated extra announcements.
> 

When I was forced to use PA space (because I didn't qualify for PI space 
at the time) I didn't have any choice but to announce all my /24's 
individually. Now that I finally have PI space I have the ability to 
announce one prefix once I finish renumbering. It's not my fault, the 
rules made me announce extra cruft into the routing table even though I 
knew better.

I'd say multihoming PA holders are more likely to deaggregate because 
they're forced to pick up and announce random /24's here and there until 
they can get PI space.

~Seth


From iljitsch at muada.com  Thu Sep  6 13:30:19 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Thu, 6 Sep 2007 19:30:19 +0200
Subject: [ppml] IPv6 flawed?
In-Reply-To: <AF699AB3-F131-4174-B881-F602A5D93140@virtualized.org>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org>
	<D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
	<11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>
	<7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>
	<60037.74.122.168.81.1188929633.squirrel@look.libertyrms.com>
	<AF699AB3-F131-4174-B881-F602A5D93140@virtualized.org>
Message-ID: <6724492E-7A08-4B58-827F-96CDB5A9D23F@muada.com>

On 6-sep-2007, at 3:30, David Conrad wrote:

> According to <http://www.conference.sanog.org/slides/conference/
> sanog10-pfs-deaggregation-report.pdf>, we're seeing the
> "deaggregation factor" increase "slowly and steadily since 'records
> began'", with the fastest growth occurring in the "new" Internet (the
> graph on page 15 is very interesting).

Note that this is "prefixes with maximum achievable aggregation" vs  
"currently seen prefixes". If you count the number of prefixes per  
AS, you'll be getting the same number for a good number of years: 8.

> Since IPv6 uses the same
> routing and traffic engineering technology as IPv4, I am curious what
> constraints could be put in place to keep PI space down to about 1
> per ASN.

Prefixes per AS aren't limited by routing technology (if only it  
could...) so this is irrelevant. Traffic engineering also seems to be  
largely irrelevant as inspection of the routing table (without tools,  
so I might be overlooking SOME stuff but believe me, this is obvious)  
shows multiple prefixes sourced from the same AS to have the same  
attributes almost all the time.

> Perhaps more distressingly, if you believe the post IPv4 run out
> world is going to be awash with long prefixes taken from holders of
> legacy space as IPv4 address space is used more efficiently after
> free pool run out, the deaggregation factor of the "old" Internet is
> likely going to ramp up quite quickly.  This would seem to imply IPv6
> could get strangled long before it could take off, regardless of RIR
> allocation policies.

I don't see how those IPv4 issues carry over into IPv6, but to get  
back to the main point: in IPv6, you'll be either getting a /32 or a / 
48 as a PI block. So unless you manage to get multiple PI blocks, any  
efforts to inject more than a single prefix will easily be thwarted  
by prefix length filters.

That is, of course, until the people who have been pushing for PI in  
IPv6 notice that having a single, undeaggregatable IPv6 prefix means  
that they have to carry traffic between their different offices on  
their own dime, and there will be a push for multiple PI blocks per  
AS or multiple ASes per organization. Estimating the impact of that  
on routing scalability is left as an exercise for the reader.


From mack at exchange.alphared.com  Thu Sep  6 13:41:15 2007
From: mack at exchange.alphared.com (mack)
Date: Thu, 6 Sep 2007 12:41:15 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <mailman.5.1189094400.12832.ppml@arin.net>
References: <mailman.5.1189094400.12832.ppml@arin.net>
Message-ID: <859D2283FD04CA44986CC058E06598F84B1D9AA8FB@exchange4.exchange.alphared.local>

> Message: 4
> Date: Wed, 5 Sep 2007 18:30:22 -0700
> From: David Conrad <drc at virtualized.org>
> Subject: Re: [ppml] IPv6 flawed?
> To: briand at ca.afilias.info
> Cc: Public Policy Mailing List <ppml at arin.net>
> Message-ID: <AF699AB3-F131-4174-B881-F602A5D93140 at virtualized.org>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Brian,
>
> On Sep 4, 2007, at 11:13 AM, briand at ca.afilias.info wrote:
> > - breaking the hard limit will most likely result in IPv6 getting
> > tossed
>
> Very true.  An interesting point I hadn't really considered.
>

In the most relevant products from Cisco (sup32 and sup720) the IPv6 is stored in a TCAM with a different architecture from the IPv4 TCAM.  Specifically the Sup32 and Sup720-3B both have 256000 IPv4 slots and 128000 IPv6 slots.
The IPv4 TCAM on these models will either break or require de-aggregation pruning within the next 6 months.  This de-aggregation pruning could be done in software as part of BGP but is not in the current software (to my knowledge).  The Sup720-3BXL and RSP720-3CXL both have 1000000 IPv4 slots and 512000 IPv6 slots.

This does not cover software based routers or other manufacturers.  Also a large number of models of hardware do not support IPv6 at all.

An argument can be made that it will be cheaper for some organizations to switch to IPv6 shortly due to the impending limit of the FIB TCAM on their routers.

In any case the most relevant Cisco products are going to run out of IPv4 TCAM space before IPv6 even makes a dent.

Someone familiar with the architecture of Juniper and other products should be able to shed light on the capabilities of those products.

LR Mack McBride
Network Administrator
Alpha Red, Inc.


From briand at ca.afilias.info  Thu Sep  6 13:51:58 2007
From: briand at ca.afilias.info (briand at ca.afilias.info)
Date: Thu, 6 Sep 2007 13:51:58 -0400 (EDT)
Subject: [ppml] IPv6 flawed?
In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1D9AA8FB@exchange4.exchange.alphare
	d.local>
References: <mailman.5.1189094400.12832.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA8FB@exchange4.exchange.alphared.local>
Message-ID: <62965.74.122.168.81.1189101118.squirrel@look.libertyrms.com>

"Mack" wrote:
> In the most relevant products from Cisco (sup32 and sup720) the IPv6 is
> stored in a TCAM with a different architecture from the IPv4 TCAM.
> Specifically the Sup32 and Sup720-3B both have 256000 IPv4 slots and
> 128000 IPv6 slots.

Wrong.

A closer inspection of the literature, you will find, says *or*, not *and*.

Meaning, 256k IPv4 *only*, or 128k IPv6 *only*.

And the default set-up is a mix of 192k IPv4 and 32k combined
IPv6-and-multicast.

> An argument can be made that it will be cheaper for some organizations to
> switch to IPv6 shortly due to the impending limit of the FIB TCAM on their
> routers.

Organizations at the edge, maybe, who don't do content or services.
Who can deploy IPv6 to IPv4 NAT gateways at their upstream edges.

Not content players, and not DFZ players, for sure.

> In any case the most relevant Cisco products are going to run out of IPv4
> TCAM space before IPv6 even makes a dent.

... which is all the *more* reason why paying close attention to IPv6
allocation, aggregation, and usage, is so important.

Brian



From mack at exchange.alphared.com  Thu Sep  6 14:52:12 2007
From: mack at exchange.alphared.com (mack)
Date: Thu, 6 Sep 2007 13:52:12 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <62965.74.122.168.81.1189101118.squirrel@look.libertyrms.com>
References: <mailman.5.1189094400.12832.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA8FB@exchange4.exchange.alphared.local>
	<62965.74.122.168.81.1189101118.squirrel@look.libertyrms.com>
Message-ID: <859D2283FD04CA44986CC058E06598F84B1D9AA917@exchange4.exchange.alphared.local>

> -----Original Message-----
> From: briand at ca.afilias.info [mailto:briand at ca.afilias.info]
> Sent: Thursday, September 06, 2007 12:52 PM
> To: mack
> Cc: ppml at arin.net
> Subject: Re: [ppml] IPv6 flawed?
>
> "Mack" wrote:
> > In the most relevant products from Cisco (sup32 and sup720) the IPv6
> is
> > stored in a TCAM with a different architecture from the IPv4 TCAM.
> > Specifically the Sup32 and Sup720-3B both have 256000 IPv4 slots and
> > 128000 IPv6 slots.
>
> Wrong.
>
> A closer inspection of the literature, you will find, says *or*, not
> *and*.
>
> Meaning, 256k IPv4 *only*, or 128k IPv6 *only*.
>
> And the default set-up is a mix of 192k IPv4 and 32k combined
> IPv6-and-multicast.

I stand corrected. Is there a command to modify this?
I was unable to find a documented command to do this.
The Sup32 and Sup720-3B are basically dead as far as the DFZ are concerned.
They will continue to work at the edge where routes can be pruned but not at the core.
If there is not easy way to modify the FIB ratios then these units can't take a full
set of routes now.  And have not been able to for a substantial amount of time.

>
> > An argument can be made that it will be cheaper for some
> organizations to
> > switch to IPv6 shortly due to the impending limit of the FIB TCAM on
> their
> > routers.
>
> Organizations at the edge, maybe, who don't do content or services.
> Who can deploy IPv6 to IPv4 NAT gateways at their upstream edges.
>
> Not content players, and not DFZ players, for sure.

The DFZ core has already upgraded (at least the networks I deal with).
256K was insufficient for the routing table plus internal routes months ago.

>
> > In any case the most relevant Cisco products are going to run out of
> IPv4
> > TCAM space before IPv6 even makes a dent.
>
> ... which is all the *more* reason why paying close attention to IPv6
> allocation, aggregation, and usage, is so important.
>
> Brian


If the TCAM distribution is not modifiable this is not as relevant.

Mack


From dsinn at dsinn.com  Thu Sep  6 16:01:30 2007
From: dsinn at dsinn.com (David Sinn)
Date: Thu, 6 Sep 2007 13:01:30 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1D9AA917@exchange4.exchange.alphared.local>
References: <mailman.5.1189094400.12832.ppml@arin.net>
	<859D2283FD04CA44986CC058E06598F84B1D9AA8FB@exchange4.exchange.alphared.local>
	<62965.74.122.168.81.1189101118.squirrel@look.libertyrms.com>
	<859D2283FD04CA44986CC058E06598F84B1D9AA917@exchange4.exchange.alphared.local>
Message-ID: <CF28C577-DD14-46DA-B780-D851A7DCC8FA@dsinn.com>

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



On Sep 6, 2007, at 11:52 AM, mack wrote:

>> -----Original Message-----
>> From: briand at ca.afilias.info [mailto:briand at ca.afilias.info]
>> Sent: Thursday, September 06, 2007 12:52 PM
>> To: mack
>> Cc: ppml at arin.net
>> Subject: Re: [ppml] IPv6 flawed?
>>
>> "Mack" wrote:
>>> In the most relevant products from Cisco (sup32 and sup720) the IPv6
>> is
>>> stored in a TCAM with a different architecture from the IPv4 TCAM.
>>> Specifically the Sup32 and Sup720-3B both have 256000 IPv4 slots and
>>> 128000 IPv6 slots.
>>
>> Wrong.
>>
>> A closer inspection of the literature, you will find, says *or*, not
>> *and*.
>>
>> Meaning, 256k IPv4 *only*, or 128k IPv6 *only*.
>>
>> And the default set-up is a mix of 192k IPv4 and 32k combined
>> IPv6-and-multicast.
>
> I stand corrected. Is there a command to modify this?
> I was unable to find a documented command to do this.
> The Sup32 and Sup720-3B are basically dead as far as the DFZ are  
> concerned.
> They will continue to work at the edge where routes can be pruned  
> but not at the core.
> If there is not easy way to modify the FIB ratios then these units  
> can't take a full
> set of routes now.  And have not been able to for a substantial  
> amount of time.

Modifying the TCAM division (though potentially more apropos for  
cisco-nsp) can be done by:

(config)#mls cef max ?
   ip            number of ip routes
   ip-multicast  number of multicast routes
   ipv6          number of ipv6 routes
   mpls          number of MPLS labels

Reboot is required and I believe 1000 is the minimum for any one  
category.  Just to make things even more interesting if you modify  
one of these you no longer get the shared nature resource of the  
default config as is shown in:

#sho mls cef max
FIB TCAM maximum routes :
=======================
Current :-
- -------
IPv4 + MPLS         - 192k (default)
IPv6 + IP Multicast - 32k (default)

David

>
>>
>>> An argument can be made that it will be cheaper for some
>> organizations to
>>> switch to IPv6 shortly due to the impending limit of the FIB TCAM on
>> their
>>> routers.
>>
>> Organizations at the edge, maybe, who don't do content or services.
>> Who can deploy IPv6 to IPv4 NAT gateways at their upstream edges.
>>
>> Not content players, and not DFZ players, for sure.
>
> The DFZ core has already upgraded (at least the networks I deal with).
> 256K was insufficient for the routing table plus internal routes  
> months ago.
>
>>
>>> In any case the most relevant Cisco products are going to run out of
>> IPv4
>>> TCAM space before IPv6 even makes a dent.
>>
>> ... which is all the *more* reason why paying close attention to IPv6
>> allocation, aggregation, and usage, is so important.
>>
>> Brian
>
>
> If the TCAM distribution is not modifiable this is not as relevant.
> Mack
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFG4FyaLa9jIE3ZamMRApPlAKCRhmg9G6wzegHPM/RDNHzOiSIeQgCfWmff
8GQB8qMz/VUpb7Wc4M+tcy8=
=PzLw
-----END PGP SIGNATURE-----


From dean at av8.com  Fri Sep  7 21:08:04 2007
From: dean at av8.com (Dean Anderson)
Date: Fri, 7 Sep 2007 21:08:04 -0400 (EDT)
Subject: [ppml] Policy Proposal: Decreasing Exponential Rationingof	IPv4
 IP Addresses
In-Reply-To: <64004.74.122.168.81.1189002962.squirrel@look.libertyrms.com>
Message-ID: <Pine.LNX.4.44.0709072037460.12609-100000@citation2.av8.net>

On Wed, 5 Sep 2007 briand at ca.afilias.info wrote:

> Taking the monthly data, and doing sliding window averages, trends
> show up pretty quickly. There's annual cyclical variances, but year
> over year, each month should show the same trend.
> 
> Sliding average data on 4-month window:
> [...] 
> Two observations:
> - monthly averages > 14M/month
> - trending upwards (however slightly)

There are some other ways to analyze the data: Compare the
month-to-month and quarter-to-quarter amounts;  Keep a running sum of
the differences, and I think you'll also see that usage rate is
increasing.  But, the point is: you do see the trend--there is a trend.

> Bingo. Monotonically increasing usage, and increasing rate of usage.
> We will run out, and reasonably soon. Even if the rate flattens, e.g
> at 20M/month, we will still exhaust the pool in << 5 years. Whether it
> is 3, 4, or 5 years, that's still a very short time to be fully
> IPv6+IPv4, for those who want to be around after IPv4 addresses are
> very hard to get.

I've been looking at a few old books that mentioned Address Depletion,
and IPv6.  "Routing in the Internet", by Christian Huitema, Prentice
Hall 1995, and "IPng Internet Protocol Next Generation" by Bradner and
Mankin, Addison-Wesley 1996.  Both books give some predictions for
depletion between 2008 and 2018.  With 2007 hindsight, it looks like
Frank Solensky's use of the logistical distribution was best. In 1995,
Solensky predicted depletion in 2008. The logistic distribution, had
been used to predict growth of the telephone network in the 1960s.  
Also, Solensky's prediction was based on mostly pre-CIDR data (CIDR was
introduced in 1994--RFC 1519 date is November 1993)

I'll try to resubmit my proposal on rationing again by Monday, as a
modification to the policy manual.

		--Dean





-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




From ppml at rsuc.gweep.net  Sun Sep  9 15:25:27 2007
From: ppml at rsuc.gweep.net (Joe Provo)
Date: Sun, 9 Sep 2007 15:25:27 -0400
Subject: [ppml] IPv6 flawed?
In-Reply-To: <20070906163042.GE23217@shell01.cell.sv2.tellme.com>
References: <D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
	<11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>
	<7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>
	<60037.74.122.168.81.1188929633.squirrel@look.libertyrms.com>
	<AF699AB3-F131-4174-B881-F602A5D93140@virtualized.org>
	<20070906163042.GE23217@shell01.cell.sv2.tellme.com>
Message-ID: <20070909192527.GA11504@gweep.net>

On Thu, Sep 06, 2007 at 09:30:42AM -0700, David Williamson wrote:
[snip]
> I'm sorry, but I don't see how PI space (when used responsibly) is a
> culprit in the growth of the routing table any more than PA space.  The
> real culprit is multi-homing and TE.  Clearly, we should just forbid
> that.  (Yeah, right.)

Assuming global-scope 'TE' by abusing longest-match is the single 
most common instance I've run across when discussing fixing the 
announcements with the culprit deaggregators over the last decade.  
Out of the stack of offered solutions in many fora, providing a set 
of well-known communities to allow the standardization of provider-
by-provider often-implemented redistribution communities was the best
I had seen at addressing real operator desires (deaggregation based
TE) and problems (easily limiting the scope of the announcements).
ISTR more generalized approach being discussed in ptomaine/grow, 
but rfc3765 seems to be the only result.  However, allowing customers 
to tell you how to manage your capacity or finances isn't the same 
as "this route doesn't need to be seen N ASNs away".

Cheers,

Joe

-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE


From dean at av8.com  Mon Sep 10 18:15:36 2007
From: dean at av8.com (Dean Anderson)
Date: Mon, 10 Sep 2007 18:15:36 -0400 (EDT)
Subject: [ppml] IPv6 flawed?
In-Reply-To: <AF699AB3-F131-4174-B881-F602A5D93140@virtualized.org>
Message-ID: <Pine.LNX.4.44.0709072109320.12609-100000@citation2.av8.net>

On Wed, 5 Sep 2007, David Conrad wrote:

> On Sep 4, 2007, at 11:13 AM, briand at ca.afilias.info wrote:
> > - breaking the hard limit will most likely result in IPv6 getting  
> > tossed
> 
> Very true.  An interesting point I hadn't really considered.

Of course, one might use separate hardware for IPv4 and IPv6 as a
solution to such problems.

There seems to be way too much emphasis on trying to load IPv6 onto
IPv4.  While I can see that you might want to send IPv4 and IPv6 packets
over the same WAN connections, and over the same LAN hardware, there is
no reason to mix them further. Indeed, probably there are more good
reasons not to mix them.  Indeed, embedded systems builders have to
replace some IPv4/IPv6-muddled programs when they turn off IPv6, or 
suffer build problems.

> This would seem to imply IPv6 could get strangled long before it could
> take off, regardless of RIR allocation policies.

Its sort of ironic that the motivation for creating IPv6 was address
depletion, when address depletion will kill IPv6.

IPv6 was supposed to "take off" between 1995 and 2005.  Seems we are
behind schedule by a lot. Maybe IPv6 is already dead, suffocated by a
variety of things, but most notably by market rejection and government
refusal.

The IPng book is a useful roadmap to what's wrong with IPv6:  (just a
few quotes)

"It should be explicitly noted that the reasons which are compelling the
Internet Community to create IPng [...] are not themselves adequate
motivations for users to deploy IPng within their own private networks"

"The IETF firmly believed that it must "own" the standards" pg 199

"Therefore, for a number of reasons, unfortunately including prejudice 
in a few cases..." pg 199

So, here it is: 'the users won't want it, and unsavory politics drives
the process.' Hmm... Let me think... No, not something I want to buy
into, I think.  Unsavory politics has since turned into bad science.  
(e.g. Stateful Anycast fraud, Patent fraud, see
http://www.av8.net/IETF-watch/)  

I bought the IPng book in 1996. I haven't looked at it in years.  In
retrospect, this book contains just exactly the things one hopes not to
hear. So, I think it means more now than it did then.  Its no wonder
things are not working out...

The important question is whether there is an alternative.  

Indeed, there might still be a viable alternative. I think if we have to
pull together an alternative in the next few years, it has to be
ISO/CLNP TUBA (TCP/UDP over CLNP, RFC1347, RFC1561, et al). This was an
early contentious proposal for IPng.  In retrospect, maybe that would be
better. The reason it is still viable is that CLNP is already (still)
supported by router vendors, and still used for IS-IS.  To entirely
replace IPv6 with CLNP/TUBA requires:

 CLNP stacks for host computers
 setting up a Nameservice 
 Allocating global address space
 setting up IDRP (basically BGP for OSI)
 porting/deploying applications

Basically, this is about the same as what remains to do with IPv6. [hmm.  
after 14+ years work on IPv6, we are still where we were in 1993...sigh] 
There are some advantages, though:

An advantage is that CLNP interoperability between vendors is already
guaranteed, and developers of host implmentations can test with existing
working implementations, rather than trying to read unimplemented
specifications and hoping they do what everyone else will do. No such
problems plague CLNP, so, we have none of the interoperability problems
that continue to plague IPv6.

Large private networks could keep their IPv4 infrastructure, and connect
via IPv4 gateways and proxies and upgrade to CLNP/TUBA as necessary.  
Doing 'gateway/proxy of IPv4' is probably same as they would otherwise
do with IPv6, so this will be pretty transparent to most users. Private
networks that need CLNS features directly could upgrade all or part of
their network as necessary.

The situation is even better for ISPs: Dual stack (IPv4/CLNP) network
operation is _already_ implemented, so ISPs don't need to upgrade very
much, or make very much change at all--basically just

  configure/upgrade for IDRP (the OSI BGP), 
  perform address assignment to customers,
  configure ISIS for CLNP routing

The big one: Customers continue to run IPv4 until they choose to
upgrade.

Bringing up CLNP stack on hosts is easier than IPv6 because the protocol
is stable and well-defined, and already implemented by multiple vendors
who solved interoperation problems long ago.

Another advantage is that we all can completely bypass the IPv6
profiteers and their baggage, including Root DNS mismanagement.

Cisco and other vendors support CLNP now.  Here's a Cisco page on CLNP:
http://www.cisco.com/warp/public/535/2.html

Maybe we can still get IPv6 to work; the saying goes that one can't
polish a t*rd; I think one can get just about anything to run, though
maybe not well.



		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   







From drc at virtualized.org  Mon Sep 10 21:12:09 2007
From: drc at virtualized.org (David Conrad)
Date: Mon, 10 Sep 2007 18:12:09 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <6724492E-7A08-4B58-827F-96CDB5A9D23F@muada.com>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org>
	<D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
	<11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>
	<7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>
	<60037.74.122.168.81.1188929633.squirrel@look.libertyrms.com>
	<AF699AB3-F131-4174-B881-F602A5D93140@virtualized.org>
	<6724492E-7A08-4B58-827F-96CDB5A9D23F@muada.com>
Message-ID: <BE3F6B0D-AE14-487C-8A65-EB9D06164484@virtualized.org>

Iljitsch,

On Sep 6, 2007, at 10:30 AM, Iljitsch van Beijnum wrote:
>> According to <http://www.conference.sanog.org/slides/conference/
>> sanog10-pfs-deaggregation-report.pdf>, we're seeing the
>> "deaggregation factor" increase "slowly and steadily since 'records
>> began'", with the fastest growth occurring in the "new" Internet (the
>> graph on page 15 is very interesting).
>
> Note that this is "prefixes with maximum achievable aggregation" vs  
> "currently seen prefixes". If you count the number of prefixes per  
> AS, you'll be getting the same number for a good number of years: 8.

Well, yes.  And if you truncate the deaggregation factor, you get 1  
since data collection started.  Looking at the historic data from the  
published routing analysis of prefixes per AS, you'll see a fairly  
rapid decent from 12.13 in Feb 1999 to 7.97 in Jan 2004 after which  
it has been increasing "slowly and steadily" ever since (we're at  
8.81 now).

Interestingly, if you look at the ratio of ASes that are announcing a  
single prefix to all ASes, it has consistently gone up (from 27% in  
1999 to 42% today).

I suspect both of these are causes for worry.  The first is likely  
driven primarily by people breaking up aggregates for good or bad  
reasons.  The second is likely due to multihoming.  Fortunately, the  
growth isn't that great right now.  The big question is how these  
trends will change in the future.

>> Since IPv6 uses the same
>> routing and traffic engineering technology as IPv4, I am curious what
>> constraints could be put in place to keep PI space down to about 1
>> per ASN.
>
> Prefixes per AS aren't limited by routing technology (if only it  
> could...) so this is irrelevant.

Yet you go ahead and address this irrelevancy:

> in IPv6, you'll be either getting a /32 or a /48 as a PI block. So  
> unless you manage to get multiple PI blocks, any efforts to inject  
> more than a single prefix will easily be thwarted by prefix length  
> filters.

Of course, this assumes people will implement and maintain prefix  
length filters.  I'm told by some in the ISP business that the  
economic pressure to remove such filters is sufficiently high that  
they don't believe prefix length filters are viable in the long term  
(I'm paraphrasing a bit).

Regards,
-drc



From john at quonix.net  Mon Sep 10 22:14:19 2007
From: john at quonix.net (John Von Essen)
Date: Mon, 10 Sep 2007 22:14:19 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
Message-ID: <D7E6A943-C613-479F-831A-31CE498FE2BB@quonix.net>

Disclaimer: This is my first post, so be kind!

A run-in with a local ISP in my area was a cause for concern. That  
lead me to a closer understanding of ARINs reverse DNS policy, then  
an email to ARINs hostmaster, and now an email to this list.

First, let me describe the scenario that spawned all of this.

1. I signup for DSL and receive an account with an IP address that  
does not resolve.
2. Upon review, its more then a missing PTR, the IP I was given  
belongs to an in-addr.arpa zone which is not mapped at all in the  
ISP's DNS servers - the servers indicated in their IP assignments  
from ARIN. It is not site-wide however, some in-addr.arpa's they map,  
others they do not.
3. Several functions on my PC incur long reverse DNS timeouts (up to  
30 seconds) as a result. i.e. sending mail through smtp, telnet and  
ssh connections, and any other protocol which natively has built in  
reverse DNS checks.
4. Contact ISP to resolve, no luck.
5. Contacted ISPs ARIN Tech/Abuse/NOC POCs, still no luck.

After contacting the ARIN hostmaster, it is my understanding that  
under the current policy the ISP in question is not violating  
anything. Since at least one in-addr.arpa prefix in their range is  
properly mapped, their reverse DNS servers are not considered Lame.

I do not agree with this. I feel that every prefix advertised from an  
AS should have all of its in-addr.arpa zones mapped, that is 100%  
compliancy for reverse DNS.

I feel that the scenario of these dns timeouts is significant and  
should be avoided. Theoretically, it is causing an environment that  
wastes UDP connections. Consider GoDaddy's public SMTP server for  
email customers. Every user that hits that smtp server causes a  
reverse dns check - so a UDP connection is needed, but quickly  
recycled because it finishes within a few milliseconds. But users who  
come from ISPs who do not map their in-addr.arpa cause GoDaddy's  
resolvers to open a UDP connection and wait for a timeout, then  
retry, wait, then try secondary, server, etc.,. Thereby wasting  
resources on GoDaddy's internal resolving DNS servers.

What are other peoples thoughts on this? Could the policy be updated  
requiring full mapping of ALL in-addr.arpa zones that an AS advertises?

ARIN wont have to police behavior of ISPs, just have the policy in  
place so the community can say to a rogue ISP, "Hey, you violate  
policy". Down the road automated systems would be nice to  
automatically find AS's who violate.



Thanks,
John Von Essen
(800) 248-1736 ext 100
President, Quonix Networks, Inc.
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070910/8c5013fa/attachment.htm>

From HRyu at norlight.com  Mon Sep 10 22:26:05 2007
From: HRyu at norlight.com (Hyunseog Ryu)
Date: Mon, 10 Sep 2007 21:26:05 -0500
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
Message-ID: <OF17C207B5.B393C6EA-ON86257353.000D5FEE@norlight.com>


I don't think this should be considered as policy discussion.
It's their way to manage reverse zone data.
it seems to me that they have inverse dns setup for allocated ip block, but they don't maintain the data as up-to-dated.
It should be dealt between you and your ISP, and there is not much ARIN can do.
If your ISP doesn't update reverse DNS data for your IP, it's their customer case handling problem.
You can escalate the case with your ISP, or find somebody else.
This is my humble opinion. 

Hyun
Sent from blackberry on the road


----- Original Message -----
From: John Von Essen [john at quonix.net]
Sent: 09/10/2007 10:14 PM AST
To: Public Policy Mailing List <ppml at arin.net>
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy



Disclaimer: This is my first post, so be kind!

A run-in with a local ISP in my area was a cause for concern. That  
lead me to a closer understanding of ARINs reverse DNS policy, then  
an email to ARINs hostmaster, and now an email to this list.

First, let me describe the scenario that spawned all of this.

1. I signup for DSL and receive an account with an IP address that  
does not resolve.
2. Upon review, its more then a missing PTR, the IP I was given  
belongs to an in-addr.arpa zone which is not mapped at all in the  
ISP's DNS servers - the servers indicated in their IP assignments  
from ARIN. It is not site-wide however, some in-addr.arpa's they map,  
others they do not.
3. Several functions on my PC incur long reverse DNS timeouts (up to  
30 seconds) as a result. i.e. sending mail through smtp, telnet and  
ssh connections, and any other protocol which natively has built in  
reverse DNS checks.
4. Contact ISP to resolve, no luck.
5. Contacted ISPs ARIN Tech/Abuse/NOC POCs, still no luck.

After contacting the ARIN hostmaster, it is my understanding that  
under the current policy the ISP in question is not violating  
anything. Since at least one in-addr.arpa prefix in their range is  
properly mapped, their reverse DNS servers are not considered Lame.

I do not agree with this. I feel that every prefix advertised from an  
AS should have all of its in-addr.arpa zones mapped, that is 100%  
compliancy for reverse DNS.

I feel that the scenario of these dns timeouts is significant and  
should be avoided. Theoretically, it is causing an environment that  
wastes UDP connections. Consider GoDaddy's public SMTP server for  
email customers. Every user that hits that smtp server causes a  
reverse dns check - so a UDP connection is needed, but quickly  
recycled because it finishes within a few milliseconds. But users who  
come from ISPs who do not map their in-addr.arpa cause GoDaddy's  
resolvers to open a UDP connection and wait for a timeout, then  
retry, wait, then try secondary, server, etc.,. Thereby wasting  
resources on GoDaddy's internal resolving DNS servers.

What are other peoples thoughts on this? Could the policy be updated  
requiring full mapping of ALL in-addr.arpa zones that an AS advertises?

ARIN wont have to police behavior of ISPs, just have the policy in  
place so the community can say to a rogue ISP, "Hey, you violate  
policy". Down the road automated systems would be nice to  
automatically find AS's who violate.



Thanks,
John Von Essen
(800) 248-1736 ext 100
President, Quonix Networks, Inc.
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070910/fbbd1a57/attachment.htm>
-------------- next part --------------
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.

From john at quonix.net  Mon Sep 10 22:44:18 2007
From: john at quonix.net (John Von Essen)
Date: Mon, 10 Sep 2007 22:44:18 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <OF17C207B5.B393C6EA-ON86257353.000D5FEE@norlight.com>
References: <OF17C207B5.B393C6EA-ON86257353.000D5FEE@norlight.com>
Message-ID: <500EA4D6-1C28-46C9-89CE-103B4B6E3DF7@quonix.net>

Couple of quick points.

I have spent three weeks with the ISP, and they are either  
incompetent or unwilling to resolve, or both.

And it is definitely not a case of them rolling out a new /24 and  
simply forgetting to add it to their DNS server. I have done some  
digging around, and they have massive amounts of IPs ranges that have  
no in-addr.arpa mappings.

I understand some people think that this is an ISP-and-customer  
issue, but when an ISP who has a /16 or larger assignment and they  
engage in activity that literally slows down external resolvers  
throughout the internet by causing tons of excessive reverse DNS  
timeouts, I do feel it is ARIN's responsibility to have a policy that  
will official denounce this practice

-John


On Sep 10, 2007, at 10:26 PM, Hyunseog Ryu wrote:

>
> I don't think this should be considered as policy discussion.
> It's their way to manage reverse zone data.
> it seems to me that they have inverse dns setup for allocated ip  
> block, but they don't maintain the data as up-to-dated.
> It should be dealt between you and your ISP, and there is not much  
> ARIN can do.
> If your ISP doesn't update reverse DNS data for your IP, it's their  
> customer case handling problem.
> You can escalate the case with your ISP, or find somebody else.
> This is my humble opinion.
>
> Hyun
> Sent from blackberry on the road
>
>  ----- Original Message -----
>   From: John Von Essen [john at quonix.net]
>   Sent: 09/10/2007 10:14 PM AST
>   To: Public Policy Mailing List <ppml at arin.net>
>   Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
>
>
> Disclaimer: This is my first post, so be kind!
>
> A run-in with a local ISP in my area was a cause for concern. That  
> lead me to a closer understanding of ARINs reverse DNS policy, then  
> an email to ARINs hostmaster, and now an email to this list.
>
> First, let me describe the scenario that spawned all of this.
>
> 1. I signup for DSL and receive an account with an IP address that  
> does not resolve.
> 2. Upon review, its more then a missing PTR, the IP I was given  
> belongs to an in-addr.arpa zone which is not mapped at all in the  
> ISP's DNS servers - the servers indicated in their IP assignments  
> from ARIN. It is not site-wide however, some in-addr.arpa's they  
> map, others they do not.
> 3. Several functions on my PC incur long reverse DNS timeouts (up  
> to 30 seconds) as a result. i.e. sending mail through smtp, telnet  
> and ssh connections, and any other protocol which natively has  
> built in reverse DNS checks.
> 4. Contact ISP to resolve, no luck.
> 5. Contacted ISPs ARIN Tech/Abuse/NOC POCs, still no luck.
>
> After contacting the ARIN hostmaster, it is my understanding that  
> under the current policy the ISP in question is not violating  
> anything. Since at least one in-addr.arpa prefix in their range is  
> properly mapped, their reverse DNS servers are not considered Lame.
>
> I do not agree with this. I feel that every prefix advertised from  
> an AS should have all of its in-addr.arpa zones mapped, that is  
> 100% compliancy for reverse DNS.
>
> I feel that the scenario of these dns timeouts is significant and  
> should be avoided. Theoretically, it is causing an environment that  
> wastes UDP connections. Consider GoDaddy's public SMTP server for  
> email customers. Every user that hits that smtp server causes a  
> reverse dns check - so a UDP connection is needed, but quickly  
> recycled because it finishes within a few milliseconds. But users  
> who come from ISPs who do not map their in-addr.arpa cause  
> GoDaddy's resolvers to open a UDP connection and wait for a  
> timeout, then retry, wait, then try secondary, server, etc.,.  
> Thereby wasting resources on GoDaddy's internal resolving DNS servers.
>
> What are other peoples thoughts on this? Could the policy be  
> updated requiring full mapping of ALL in-addr.arpa zones that an AS  
> advertises?
>
> ARIN wont have to police behavior of ISPs, just have the policy in  
> place so the community can say to a rogue ISP, "Hey, you violate  
> policy". Down the road automated systems would be nice to  
> automatically find AS's who violate.
>
>
>
> Thanks,
> John Von Essen
> (800) 248-1736 ext 100
> President, Quonix Networks, Inc.
> john at quonix.net
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070910/698a0c97/attachment.htm>

From BehmJL at bv.com  Mon Sep 10 23:21:10 2007
From: BehmJL at bv.com (Behm, Jeffrey L.)
Date: Mon, 10 Sep 2007 22:21:10 -0500
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
References: <OF17C207B5.B393C6EA-ON86257353.000D5FEE@norlight.com>
	<500EA4D6-1C28-46C9-89CE-103B4B6E3DF7@quonix.net>
Message-ID: <0C3670BC9169B244AA6E7B2E436180D1F9BC7D@TSMC-MAIL-04.na.bvcorp.net>

I would say it's time to find a new ISP.

On Mon 9/10/2007 9:44 PM, John Von Essen said:
 
>I understand some people think that this is an ISP-and-customer issue, but when an ISP who
>has a /16 or larger assignment and they engage in activity that literally slows down external
>resolvers throughout the internet by causing tons of excessive reverse DNS timeouts, I do
>feel it is ARIN's responsibility to have a policy that will official denounce this practice


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070910/726cd553/attachment.htm>

From marla.azinger at frontiercorp.com  Mon Sep 10 23:44:57 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Mon, 10 Sep 2007 23:44:57 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>

Hi John-
 
Thank you for posting for the first time.  
 
I understand your desire to make this an ARIN policy.  However, it has long been a position of the ARIN Community (for the most part) that ARIN policy is not to dictate or guarantee routing.  Thus, the majority of the responses you will get here will have people telling you to go find a new ISP that has a clue.  I hate to say it, but that is what I would suggest too.  Hopefully you are in a location that provides you the opportunity to shop around for a clueful ISP.
 
If you really think policy of some kind may help, your best bet is collecting up RFC and BCP's written within the IETF that address cluefull mapping of in-addr.  
 
Cheers!
Marla Azinger
Frontier Communications

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of John Von Essen
Sent: Monday, September 10, 2007 7:14 PM
To: Public Policy Mailing List
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy


Disclaimer: This is my first post, so be kind! 

A run-in with a local ISP in my area was a cause for concern. That lead me to a closer understanding of ARINs reverse DNS policy, then an email to ARINs hostmaster, and now an email to this list.

First, let me describe the scenario that spawned all of this.

1. I signup for DSL and receive an account with an IP address that does not resolve.
2. Upon review, its more then a missing PTR, the IP I was given belongs to an in-addr.arpa zone which is not mapped at all in the ISP's DNS servers - the servers indicated in their IP assignments from ARIN. It is not site-wide however, some in-addr.arpa's they map, others they do not.
3. Several functions on my PC incur long reverse DNS timeouts (up to 30 seconds) as a result. i.e. sending mail through smtp, telnet and ssh connections, and any other protocol which natively has built in reverse DNS checks.
4. Contact ISP to resolve, no luck.
5. Contacted ISPs ARIN Tech/Abuse/NOC POCs, still no luck.

After contacting the ARIN hostmaster, it is my understanding that under the current policy the ISP in question is not violating anything. Since at least one in-addr.arpa prefix in their range is properly mapped, their reverse DNS servers are not considered Lame.

I do not agree with this. I feel that every prefix advertised from an AS should have all of its in-addr.arpa zones mapped, that is 100% compliancy for reverse DNS.

I feel that the scenario of these dns timeouts is significant and should be avoided. Theoretically, it is causing an environment that wastes UDP connections. Consider GoDaddy's public SMTP server for email customers. Every user that hits that smtp server causes a reverse dns check - so a UDP connection is needed, but quickly recycled because it finishes within a few milliseconds. But users who come from ISPs who do not map their in-addr.arpa cause GoDaddy's resolvers to open a UDP connection and wait for a timeout, then retry, wait, then try secondary, server, etc.,. Thereby wasting resources on GoDaddy's internal resolving DNS servers.

What are other peoples thoughts on this? Could the policy be updated requiring full mapping of ALL in-addr.arpa zones that an AS advertises? 

ARIN wont have to police behavior of ISPs, just have the policy in place so the community can say to a rogue ISP, "Hey, you violate policy". Down the road automated systems would be nice to automatically find AS's who violate.




Thanks, 
John Von Essen
(800) 248-1736 ext 100
President, Quonix Networks, Inc.
john at quonix.net



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070910/38a4425b/attachment.htm>

From randy at psg.com  Tue Sep 11 00:05:28 2007
From: randy at psg.com (Randy Bush)
Date: Mon, 10 Sep 2007 18:05:28 -1000
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>
Message-ID: <46E61408.5000100@psg.com>

> I understand your desire to make this an ARIN policy.  However, it
> has long been a position of the ARIN Community (for the most part)
> that ARIN policy is not to dictate or guarantee routing.

perhaps re-reading the OP's post would reveal that nothing about routing
is mentioned.

my guess is that you are making an inference from routing to reverse
dns.  but such a leap may not be completely defensible, as reverse dns
is something about which arin does have policy, just not the policy
which i think the OP wants.

many fora have looked at reverse mapping policy and not made much
progress.  this is mostly due to a large and loud contingent of "who
cares?  it does not matter.  those who check are <bleep>s.  etc."

the problem is that it is the user (that silly person who pays all our
salaries) who gets screwed, as you can see from the whining of this
particular screwee.  most do not know why they get long hangs when doing
simple things, they think crap is normal.  perhaps it should not be.

randy


From john at quonix.net  Tue Sep 11 00:37:49 2007
From: john at quonix.net (John Von Essen)
Date: Tue, 11 Sep 2007 00:37:49 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <46E61408.5000100@psg.com>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>
	<46E61408.5000100@psg.com>
Message-ID: <091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net>

Randy - Thanks, you are the first person to not write this off as a  
"find another ISP" comment.

Maria, I understand your comments, but consider this... The current  
policy on reverse dns mapping "almost" does the job - it just needs  
to go a tiny bit further.

Current policy dictates that you have to map an in-addr.arpa zone for  
your prefix in order for your nameservers to not be considered lame.

Problem is, an AS only has to properly map a single in-addr.arpa to  
satisfy that requirement. What I am saying is just go a bit further,  
and have policy dictate that the AS must properly map ALL in- 
addr.arpa's for advertised prefixes in order for their nameservers to  
not be considered lame. Seems simple enough.

The problem goes beyond the ISP-to-customer scenario. Take Verizon  
DSL, what if they didn't map the in-addr.arpa's for all their DSL  
IP's - thats probably 10 or so /16's easily. That would cause tons of  
problems for various 3rd party organizations all throughout the  
internet; people like vonage (sip traffic), gmail, postini, or any  
large smtp environment or protocol dependent on reverse DNS.

But the current policy would not consider Verizon's reverse DNS  
servers as being lame. Because even though there are 1000's of in- 
addr.arpa zones not mapped (thereby causing excessive timeout on  
resolvers throughout the world), they do have one mapped to meet the  
minimum ARIN requirement for non-lameness. That simply doesn't make  
sense.

The threat of one's reverse DNS server being declared lame is the  
only way to ensure proper reverse DNS mapping. I dont see why 100%  
enforcement across all advertised prefixes for a given AS is a problem.

Lets not forget that reverse DNS plays an important role in the  
proper operation of many protocols throughout the internet, and one  
of ARINs most important jobs is delegation of reverse dns authority.   
ARIN has a responsibility to make sure that the DNS server they are  
delegating reverse authority too is maintained to at least a minimum  
level of efficiency.

-John


On Sep 11, 2007, at 12:05 AM, Randy Bush wrote:

>> I understand your desire to make this an ARIN policy.  However, it
>> has long been a position of the ARIN Community (for the most part)
>> that ARIN policy is not to dictate or guarantee routing.
>
> perhaps re-reading the OP's post would reveal that nothing about  
> routing
> is mentioned.
>
> my guess is that you are making an inference from routing to reverse
> dns.  but such a leap may not be completely defensible, as reverse dns
> is something about which arin does have policy, just not the policy
> which i think the OP wants.
>
> many fora have looked at reverse mapping policy and not made much
> progress.  this is mostly due to a large and loud contingent of "who
> cares?  it does not matter.  those who check are <bleep>s.  etc."
>
> the problem is that it is the user (that silly person who pays all our
> salaries) who gets screwed, as you can see from the whining of this
> particular screwee.  most do not know why they get long hangs when  
> doing
> simple things, they think crap is normal.  perhaps it should not be.
>
> randy

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/3dabe84b/attachment.htm>

From marla.azinger at frontiercorp.com  Tue Sep 11 01:12:35 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Tue, 11 Sep 2007 01:12:35 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272FA0E@nyrofcs2ke2k01.corp.pvt>

Well, as Randy pointed out ...maybe I am leaping a bit.  But I have had circular conversations where that wasnt viewed as such a leap.  Be it strictly routing or dns success/failures, they both have fallen into the  "it shouldnt be dictated by ARIN" conversations.  And I guess pointing out in an obviouse way that they shouldnt be in the same conversation is needed.  So...thanks Randy for getting me thinking straight again.
 
So to your point John, I would say its worth writing up and submitting it.  Clearly you have good rational and a need.  I would be interested to see how many people would support it and what type of Con's would be pointed out.  
 
Cheers!
Marla

[Azinger, Marla]  -----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of John Von Essen
Sent: Monday, September 10, 2007 9:38 PM
To: Public Policy Mailing List
Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy



Randy - Thanks, you are the first person to not write this off as a "find another ISP" comment. 

Maria, I understand your comments, but consider this... The current policy on reverse dns mapping "almost" does the job - it just needs to go a tiny bit further. 

Current policy dictates that you have to map an in-addr.arpa zone for your prefix in order for your nameservers to not be considered lame.

Problem is, an AS only has to properly map a single in-addr.arpa to satisfy that requirement. What I am saying is just go a bit further, and have policy dictate that the AS must properly map ALL in-addr.arpa's for advertised prefixes in order for their nameservers to not be considered lame. Seems simple enough.

The problem goes beyond the ISP-to-customer scenario. Take Verizon DSL, what if they didn't map the in-addr.arpa's for all their DSL IP's - thats probably 10 or so /16's easily. That would cause tons of problems for various 3rd party organizations all throughout the internet; people like vonage (sip traffic), gmail, postini, or any large smtp environment or protocol dependent on reverse DNS.

But the current policy would not consider Verizon's reverse DNS servers as being lame. Because even though there are 1000's of in-addr.arpa zones not mapped (thereby causing excessive timeout on resolvers throughout the world), they do have one mapped to meet the minimum ARIN requirement for non-lameness. That simply doesn't make sense.

The threat of one's reverse DNS server being declared lame is the only way to ensure proper reverse DNS mapping. I dont see why 100% enforcement across all advertised prefixes for a given AS is a problem.

Lets not forget that reverse DNS plays an important role in the proper operation of many protocols throughout the internet, and one of ARINs most important jobs is delegation of reverse dns authority.  ARIN has a responsibility to make sure that the DNS server they are delegating reverse authority too is maintained to at least a minimum level of efficiency.

-John


On Sep 11, 2007, at 12:05 AM, Randy Bush wrote:


I understand your desire to make this an ARIN policy.  However, it
has long been a position of the ARIN Community (for the most part)
that ARIN policy is not to dictate or guarantee routing.


perhaps re-reading the OP's post would reveal that nothing about routing
is mentioned.

my guess is that you are making an inference from routing to reverse
dns.  but such a leap may not be completely defensible, as reverse dns
is something about which arin does have policy, just not the policy
which i think the OP wants.

many fora have looked at reverse mapping policy and not made much
progress.  this is mostly due to a large and loud contingent of "who
cares?  it does not matter.  those who check are <bleep>s.  etc."

the problem is that it is the user (that silly person who pays all our
salaries) who gets screwed, as you can see from the whining of this
particular screwee.  most do not know why they get long hangs when doing
simple things, they think crap is normal.  perhaps it should not be.

randy



Thanks, 
John Von Essen
(800) 248-1736 ext 100
john at quonix.net



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/b15ef28c/attachment.htm>

From randy at psg.com  Tue Sep 11 01:14:00 2007
From: randy at psg.com (Randy Bush)
Date: Mon, 10 Sep 2007 19:14:00 -1000
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>	<46E61408.5000100@psg.com>
	<091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net>
Message-ID: <46E62418.7030603@psg.com>

> Problem is, an AS only has to properly map a single in-addr.arpa to
> satisfy that requirement. What I am saying is just go a bit further, and
> have policy dictate that the AS must properly map ALL in-addr.arpa's for
> advertised prefixes in order for their nameservers to not be considered
> lame.

well, one technicality is that is not what 'lame' means.  lame means
that the servers are not authoritative for the named zone, i.e. do not
return an SOA with the authoritative bit set.  it says nothing about
having reasonable content within the zone.

but that is a technicality.  we know what you mean.

as i said, attempts to address the actual operational problem have
foundered.  the nay-sayers might be dealt with if there was not a
problem of specifying what actually is 'correct' operation.  remember,
your particular case is one of a wide range of incorrect in-addr.arpa
behavior.  a memorable failure to fix silliness was an ivtf effort to
label as broken dns servers which return 1918 A RRs for public look-ups.
 so it is rather a wide subject.

but maybe, when all the arin policy experts wake up in the us mainland
morning, someone can make a succinct prescription of how arin might help
with your problem.  and maybe cash will fall from the sky.

fwiw, i buy dsl bearer from the local telcos because i am forced to, but
use local isps (lavanet and infinity) for layer three so i can talk to
someone with clue.

randy


From marla.azinger at frontiercorp.com  Tue Sep 11 01:18:33 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Tue, 11 Sep 2007 01:18:33 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C9B1@nyrofcs2ke2k01.corp.pvt>

>but maybe, when all the arin policy experts wake up in the us mainland
morning, someone can make a succinct prescription of how arin might help
with your problem.  and maybe cash will fall from the sky.<

Experts.  LOL.  We are legends in our own minds.

I would like the cash to fall from the sky... 

...but I would still help John if he wants to pursue this.  ;o)

Marla

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Randy Bush
Sent: Monday, September 10, 2007 10:14 PM
To: John Von Essen
Cc: Public Policy Mailing List
Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy


> Problem is, an AS only has to properly map a single in-addr.arpa to
> satisfy that requirement. What I am saying is just go a bit further, and
> have policy dictate that the AS must properly map ALL in-addr.arpa's for
> advertised prefixes in order for their nameservers to not be considered
> lame.

well, one technicality is that is not what 'lame' means.  lame means
that the servers are not authoritative for the named zone, i.e. do not
return an SOA with the authoritative bit set.  it says nothing about
having reasonable content within the zone.

but that is a technicality.  we know what you mean.

as i said, attempts to address the actual operational problem have
foundered.  the nay-sayers might be dealt with if there was not a
problem of specifying what actually is 'correct' operation.  remember,
your particular case is one of a wide range of incorrect in-addr.arpa
behavior.  a memorable failure to fix silliness was an ivtf effort to
label as broken dns servers which return 1918 A RRs for public look-ups.
 so it is rather a wide subject.

but maybe, when all the arin policy experts wake up in the us mainland
morning, someone can make a succinct prescription of how arin might help
with your problem.  and maybe cash will fall from the sky.

fwiw, i buy dsl bearer from the local telcos because i am forced to, but
use local isps (lavanet and infinity) for layer three so i can talk to
someone with clue.

randy
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.


From bmanning at vacation.karoshi.com  Tue Sep 11 02:17:09 2007
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 11 Sep 2007 06:17:09 +0000
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>
	<46E61408.5000100@psg.com>
	<091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net>
Message-ID: <20070911061709.GA8969@vacation.karoshi.com.>

On Tue, Sep 11, 2007 at 12:37:49AM -0400, John Von Essen wrote:
> 
> Problem is, an AS only has to properly map a single in-addr.arpa to  
> satisfy that requirement. What I am saying is just go a bit further,  
> and have policy dictate that the AS must properly map ALL in- 
> addr.arpa's for advertised prefixes in order for their nameservers to  
> not be considered lame. Seems simple enough.
...
> 
> The threat of one's reverse DNS server being declared lame is the  
> only way to ensure proper reverse DNS mapping. I dont see why 100%  
> enforcement across all advertised prefixes for a given AS is a problem.
> 
> Lets not forget that reverse DNS plays an important role in the  
> proper operation of many protocols throughout the internet, and one  
> of ARINs most important jobs is delegation of reverse dns authority.   
> ARIN has a responsibility to make sure that the DNS server they are  
> delegating reverse authority too is maintained to at least a minimum  
> level of efficiency.
> 
> -John
> 

    John, 
        you point out an interesting conundrum in the administration of
        DNS...  your forward map is usually owned by you (via a registrar
        or in some cases a registry) while the reverse map is owned by 
        your ISP (in most cases) ...  

        the use of secure dynamic update allows you to maintain your DNS
        entries in a secure fashion, however your ISP is refusing to 
        update the information (at all, let alone what you want it to be)
	
	one might observe that since address space is not "owned" - that
	a stewardship obligation be applied to delegations - and that
 	ARIN *might* pre-populate the reverse maps before delegation.

	for some DNSSEC usage models, having teh forward and reverse
	maps converge is highly desirable...  e.g.

		foo.bar.	a	127.0.0.1
		1.0.0.127.in-addr.arpa.  ptr foo.bar.

	which will require the ISP to rethink who it will allow its clients
	to update the reverse maps themselves, in a secure fashion.

	thoughts for your consideration.

--bill


From weiler at tislabs.com  Tue Sep 11 02:19:40 2007
From: weiler at tislabs.com (Sam Weiler)
Date: Tue, 11 Sep 2007 02:19:40 -0400 (EDT)
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
Message-ID: <Pine.LNX.4.64.0709110200480.14644@mint.samweiler.com>

> 3. Several functions on my PC incur long reverse DNS timeouts (up to 
> 30 seconds) as a result. i.e. sending mail through smtp, telnet and 
> ssh connections, and any other protocol which natively has built in 
> reverse DNS checks. 4. Contact ISP to resolve, no luck. 5. Contacted 
> ISPs ARIN Tech/Abuse/NOC POCs, still no luck.

I'm wondering if it would be sufficient to have ARIN act _far_ more
swiftly to remove the lame delegations.  While that wouldn't get good
PTR records published, it should cure the long timeout problem.

We already require ARIN to do that removal, but, in my experience, it
can take ARIN months to do so.  Might it be more reasonable to ask
ARIN to act faster, perhaps within a week or two?  To be clear, I'm
only talking about removing the DNS delegations (NS records) for the
address blocks, not revoking the IP assignment/allocation.

Section 7.2 of the NRPM (from policy proposal 2005-3) says:

"ARIN will actively identify lame DNS name server(s) for reverse
address 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."  [Note that this just changed on
August 22nd; before that, the NRPM had the text from policy proposal
2002-1, which required flagging of lame records.  The replacement
policy was adopted in June 2005 but just made it into the NRPM in the
last month.]

Perhaps the AC will work with you on a modification of this policy
that requires a faster response time from ARIN.

-- Sam


From randy at psg.com  Tue Sep 11 02:36:29 2007
From: randy at psg.com (Randy Bush)
Date: Mon, 10 Sep 2007 20:36:29 -1000
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <20070911061709.GA8969@vacation.karoshi.com.>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>	<46E61408.5000100@psg.com>	<091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net>
	<20070911061709.GA8969@vacation.karoshi.com.>
Message-ID: <46E6376D.1030302@psg.com>

> one might observe that since address space is not "owned" - that a
> stewardship obligation be applied to delegations - and that ARIN
> *might* pre-populate the reverse maps before delegation.

a - this is orthogonal to the religious discussions of address space
ownership.

b - when arin *delegates* the pre-populated zone file, the population
stays home at arin, and would not magically appear in the delegatee's zone.

randy


From bonomi at mail.r-bonomi.com  Tue Sep 11 02:49:46 2007
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Tue, 11 Sep 2007 01:49:46 -0500 (CDT)
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
Message-ID: <200709110649.l8B6nkUp021038@mail.r-bonomi.com>

> Date: Tue, 11 Sep 2007 02:19:40 -0400 (EDT)

> From: Sam Weiler <weiler at tislabs.com>
> Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy
>
> I'm wondering if it would be sufficient to have ARIN act _far_ more
> swiftly to remove the lame delegations.  While that wouldn't get good
> PTR records published, it should cure the long timeout problem.

Does an inompletely populated zone constitute a 'lame' server?

Does a zone with _no_ data other  than a SOA  constitute a 'lame' server?

Is a server that fails to return  NXDOMAIN in a _timely_ manner for
something it doesn't know about a 'lame' server?

It's not at all clear to me that requiring faser action for 7.2  addresses
any of those situations.

My understading of a lame server is one that is listed (elsewhere) as 
'authoritative' for a zone, but does NOT report itself as athoritative
when queried.

Policy is that the zone has to 'be there'. I haven't found anything that
says abot 'if' or 'what' has to be in the zone -- beyond the SOA that makes
it 'authoritative', that is.



From randy at psg.com  Tue Sep 11 02:51:28 2007
From: randy at psg.com (Randy Bush)
Date: Mon, 10 Sep 2007 20:51:28 -1000
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <200709110649.l8B6nkUp021038@mail.r-bonomi.com>
References: <200709110649.l8B6nkUp021038@mail.r-bonomi.com>
Message-ID: <46E63AF0.60302@psg.com>

> Does an inompletely populated zone constitute a 'lame' server?

rat-hole.  we know what the op meant.

> Does a zone with _no_ data other  than a SOA  constitute a 'lame' server?

no, a broken one.  needs ns rrs.

randy


From bmanning at vacation.karoshi.com  Tue Sep 11 04:08:30 2007
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 11 Sep 2007 08:08:30 +0000
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <46E6376D.1030302@psg.com>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>
	<46E61408.5000100@psg.com>
	<091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net>
	<20070911061709.GA8969@vacation.karoshi.com.>
	<46E6376D.1030302@psg.com>
Message-ID: <20070911080830.GA9719@vacation.karoshi.com.>

On Mon, Sep 10, 2007 at 08:36:29PM -1000, Randy Bush wrote:
> > one might observe that since address space is not "owned" - that a
> > stewardship obligation be applied to delegations - and that ARIN
> > *might* pre-populate the reverse maps before delegation.
> 
> a - this is orthogonal to the religious discussions of address space
> ownership.
> 
> b - when arin *delegates* the pre-populated zone file, the population
> stays home at arin, and would not magically appear in the delegatee's zone.
> 
> randy


	a) the point was a "proper" steward might be expected to 
	   perform certain functions as a measure of their stewardship

	b) true enough... but it would set a useful example to the new
	   steward as to the expected behaviour.

--bill


From michael.dillon at bt.com  Tue Sep 11 05:16:50 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 11 Sep 2007 10:16:50 +0100
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <500EA4D6-1C28-46C9-89CE-103B4B6E3DF7@quonix.net>
References: <OF17C207B5.B393C6EA-ON86257353.000D5FEE@norlight.com>
	<500EA4D6-1C28-46C9-89CE-103B4B6E3DF7@quonix.net>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00102F5D6@E03MVC4-UKBR.domain1.systemhost.net>

 

	I have spent three weeks with the ISP, and they are either
incompetent or unwilling to resolve, or both.
	
	
	And it is definitely not a case of them rolling out a new /24
and simply forgetting to add it to their DNS server. I have done some
digging around, and they have massive amounts of IPs ranges that have no
in-addr.arpa mappings. 
	
	
	I understand some people think that this is an ISP-and-customer
issue, but when an ISP who has a /16 or larger assignment and they
engage in activity that literally slows down external resolvers
throughout the internet by causing tons of excessive reverse DNS
timeouts, I do feel it is ARIN's responsibility to have a policy that
will official denounce this practice 
	 

Wrong!
 
It is not ARIN's responsibility to police the Internet. And ARIN policy
should not get involved in such things. And, in fact, it is not an error
to have missing in-addr.arpa delegations. My company has several such
missing delegations on purpose. And I know of at least one company whose
multibillion dollar per year business depends on a lame delegation for a
.com domain name. Reality is much stranger than you can imagine. 
 
If you want to make a formal suggestion to ARIN that it contact ISPs who
have not registered in-addr.arpa nameservers to suggest that it is a
good idea, if the address range is in use on the public Internet, then I
would support that. The formal suggestion box is here:
http://www.arin.net/acsp/index.html
 
ARIN offers in-addr.arpa service to all holders of IP allocations. It
seems reasonable to contact organization who are not using this service
to inform them that the service is available and how to get their
nameservers properly registered. Further, it wouldn't hurt to point them
to some Internet DNS best practices documents so they have a guide that
covers things like putting some zone files into the registered
nameservers as well.
 
--Michael Dillon
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/57df8aa7/attachment.htm>

From michael.dillon at bt.com  Tue Sep 11 05:22:40 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 11 Sep 2007 10:22:40 +0100
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272FA0E@nyrofcs2ke2k01.corp.pvt>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0E@nyrofcs2ke2k01.corp.pvt>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00102F5E3@E03MVC4-UKBR.domain1.systemhost.net>

>  So to your point John, I would say its worth writing up and
submitting it.   
> Clearly you have good rational and a need.  I would be interested to
see  
>  how many people would support it and what type of Con's would be
pointed out.   
 
I personally think that it is inappropriate for an ARIN AC member to be
encouraging people to submit policy proposals that are clearly out of
the scope of ARIN's charter.
 
It is most UNhelpful to encourage such pollution of the policymaking
process. We already have more than enough volume of proposals to deal
with.
 
--Michael Dillon
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/41c3372d/attachment.htm>

From michael.dillon at bt.com  Tue Sep 11 05:30:05 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 11 Sep 2007 10:30:05 +0100
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <46E62418.7030603@psg.com>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>	<46E61408.5000100@psg.com><091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net>
	<46E62418.7030603@psg.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00102F5FA@E03MVC4-UKBR.domain1.systemhost.net>

> but maybe, when all the arin policy experts wake up in the us 
> mainland morning, someone can make a succinct prescription of 
> how arin might help with your problem.  and maybe cash will 
> fall from the sky.

Education!

No need to run around beating people with a stick when they don't even
know what they are doing wrong. That's just plain sadism and is
economically harmful to your enterprise.

ARIN offers in-addr.arpa service for a reason; because it makes the
Internet run better. ARIN knows who is not using this service. ARIN
could have a program of identifying appropriate contacts within
organizations who do not have non-lame servers registered for each
block. ARIN could then contact these people with educational material to
explain the benefits of ARIN's free service and what needs to be done to
make use of it.

Just sending email to POCs offering in-addr.arpa is not enough. An email
message to POCs should ask for DNS server administrator contacts. Then
these people, who can be expected to have a better understanding of the
technical issues as well as the ability to act and put in-addr.arpa
zones in nameservers, could be offered the service. It wouldn't be a bad
idea to also send some material by postal mail to Domain Name Service
Administrator c/o Network Operator, in cases where the POC request fails
to elicit a viable response.

This type of educational outreach *IS* within the scope of ARIN's
charter, but still outside the scope of ARIN policy.

--Michael Dillon


From jcurran at istaff.org  Tue Sep 11 06:59:27 2007
From: jcurran at istaff.org (John Curran)
Date: Tue, 11 Sep 2007 06:59:27 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B00102F5FA@E03MVC4-UKBR.domain1.systemhost.
	net>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>
	<46E61408.5000100@psg.com><091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net
	>	<46E62418.7030603@psg.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B00102F5FA@E03MVC4-UKBR.domain1.systemhost.
	net>
Message-ID: <p06240802c30c255442d0@[192.168.4.126]>

At 10:30 AM +0100 9/11/07, <michael.dillon at bt.com> wrote:
>
>Just sending email to POCs offering in-addr.arpa is not enough. An email
>message to POCs should ask for DNS server administrator contacts. Then
>these people, who can be expected to have a better understanding of the
>technical issues as well as the ability to act and put in-addr.arpa
>zones in nameservers, could be offered the service. It wouldn't be a bad
>idea to also send some material by postal mail to Domain Name Service
>Administrator c/o Network Operator, in cases where the POC request fails
>to elicit a viable response.

Does anyone know how this issue is handled in other regions?
/John


From dogwallah at gmail.com  Tue Sep 11 07:18:29 2007
From: dogwallah at gmail.com (McTim)
Date: Tue, 11 Sep 2007 14:18:29 +0300
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <p06240802c30c255442d0@192.168.4.126>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>
	<46E61408.5000100@psg.com> <46E62418.7030603@psg.com>
	<p06240802c30c255442d0@192.168.4.126>
Message-ID: <f65fb55e0709110418k950af51xe1b5f0b1f4fe8cf1@mail.gmail.com>

On 9/11/07, John Curran <jcurran at istaff.org> wrote:
> At 10:30 AM +0100 9/11/07, <michael.dillon at bt.com> wrote:
> >
> >Just sending email to POCs offering in-addr.arpa is not enough. An email
> >message to POCs should ask for DNS server administrator contacts. Then
> >these people, who can be expected to have a better understanding of the
> >technical issues as well as the ability to act and put in-addr.arpa
> >zones in nameservers, could be offered the service. It wouldn't be a bad
> >idea to also send some material by postal mail to Domain Name Service
> >Administrator c/o Network Operator, in cases where the POC request fails
> >to elicit a viable response.
>
> Does anyone know how this issue is handled in other regions?

In RIPEland there is a rev-srv: attribute whose value is meant to be the email
address of the person handling reverse.  This is being deprecated however,
since it has only been used sparingly by only a very few folk.

Mr. Van Essen has hinted that the block in question may be a /16, in
which case it seems that perhaps his upstream might not know they can
do reverse on the whole /16 in one go, and not need to reverse
individual /24s.

-- 
Cheers,

McTim
$ whois -h whois.afrinic.net mctim


From arno at ripe.net  Tue Sep 11 07:41:20 2007
From: arno at ripe.net (arno meulenkamp)
Date: Tue, 11 Sep 2007 13:41:20 +0200
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <f65fb55e0709110418k950af51xe1b5f0b1f4fe8cf1@mail.gmail.com>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>
	<46E61408.5000100@psg.com> <46E62418.7030603@psg.com>
	<p06240802c30c255442d0@192.168.4.126>
	<f65fb55e0709110418k950af51xe1b5f0b1f4fe8cf1@mail.gmail.com>
Message-ID: <F376BF2A-C485-4FA5-AC68-1D3A38A6F46B@ripe.net>


On Sep 11, 2007, at 1:18 PM, McTim wrote:

> On 9/11/07, John Curran <jcurran at istaff.org> wrote:
>> At 10:30 AM +0100 9/11/07, <michael.dillon at bt.com> wrote:
>>>
>>> Just sending email to POCs offering in-addr.arpa is not enough.  
>>> An email
>>> message to POCs should ask for DNS server administrator contacts.  
>>> Then
>>> these people, who can be expected to have a better understanding  
>>> of the
>>> technical issues as well as the ability to act and put in-addr.arpa
>>> zones in nameservers, could be offered the service. It wouldn't  
>>> be a bad
>>> idea to also send some material by postal mail to Domain Name  
>>> Service
>>> Administrator c/o Network Operator, in cases where the POC  
>>> request fails
>>> to elicit a viable response.
>>
>> Does anyone know how this issue is handled in other regions?
>
> In RIPEland there is a rev-srv: attribute whose value is meant to  
> be the email
> address of the person handling reverse.  This is being deprecated  
> however,
> since it has only been used sparingly by only a very few folk.
>
> Mr. Van Essen has hinted that the block in question may be a /16, in
> which case it seems that perhaps his upstream might not know they can
> do reverse on the whole /16 in one go, and not need to reverse
> individual /24s.

Actually, for address space obtained in the RIPE region, the reverse  
DNS is handled through domain objects in the RIPE database. The rev- 
srv attribute in the inetnum objects is legacy and pointed to the DNS  
servers that were supposed to handle reverse DNS for that address space.

On another note.. I don't see an issue with the lack of PTR records  
for a given rDNS name. An NXDOMAIN answer is just as fast as an  
answer with a PTR record. I have no opinion on wether the RIRs should  
or should not police lameness in the reverse zones though. :)

regards,

Arno



From Ed.Lewis at neustar.biz  Tue Sep 11 08:47:34 2007
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Tue, 11 Sep 2007 08:47:34 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <D7E6A943-C613-479F-831A-31CE498FE2BB@quonix.net>
References: <D7E6A943-C613-479F-831A-31CE498FE2BB@quonix.net>
Message-ID: <a06240800c30c185616d8@[192.168.1.100]>

As an "arin mainland policy expert" with a lot of experience in 
lameness and DNS...

ARIN lame delegation proposals: 2002-1 and 2005-3.  2002-1 was 
ratified by the BoT on 17 November 2002 and 2005-3 was ratified on 16 
June 2005 and has an implementation date of 22 August 2007.  (From 
the ARIN web site.  BTW, the link from 2002-1's archive to the ARIN 
IX minuted is broken [404].)  In 2003 an update on this was presented 
to NANOG (http://www.nanog.org/mtg-0306/lewis.html).

The term "lame" in the context of DNS is defined by the IETF in RFC 
1612, 1713, 1912, and 3658.  The word lame is defined more narrowly 
than is used in practice.  Lameness is in the eye of the client and 
applies only when the client *receives a response* indicating that 
the server does not *know* the answer.  In practice, situations when 
a response does not arrive at the client has been called lame, even 
if the reason for the failure is due to an underlying network layer 
event (like packets being filtered at a firewall).

Why did ARIN pass 2002-1?  Because a widely popular implementation of 
DNS (back in the day) would be sent into a loop when it received a 
DNS referral message pointing back "up" the tree.  This made the 
presence of lame delegations an operational issue.  This 
implementation has apparently faded from general use, the operational 
impact diminished, and the topic of correcting lame delegations has 
taken a back seat to other work.

As far as general DNS reverse mapping policy, there has been an 
ongoing discussion within the IETF to produce a document on this. 
Here is the URL for a DNS Operations Working Group document in 
progress:
http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reverse-mapping-considerations/

To give an idea of how much trouble specifying operational 
requirements for reverse mapping is, the topic first appears in the 
IETF Meeting archives at
http://www3.ietf.org/proceedings/00dec/I-D/draft-ietf-dnsop-inaddr-required-00.txt 
in the report of the December 2000 meeting of the DNSOP WG.  (I have 
a personal recollection of the topic being raised at the meeting a 
few months earlier, in August 2000.)  Given the date of the cited 
document, it's been over seven years for the IETF to generate any 
statement on the topic.

What would happen if a policy were to be introduced into ARIN on this?

First an argument over the nature of reverse mapping would happen. 
As you could imagine, if the IETF takes seven plus years to come to 
consensus on this, it'll take ARIN about as long.  (Neither 
organization is smarter than the other.)  Even is there is an IETF 
RFC, I would bet that there will still be at least a small debate 
held here.

Second, the policy would really have to make a statement on what ARIN 
does regarding reverse mapping.  ARIN already offers to make 
delegations.  If the delegations are lame ARIN will cull them (per 
2005-3).  There has been talk of using the threat of culling 
delegations as a carrot/stick to make legacy holders sign agreements 
with ARIN - I say this only as an example of ARIN's action be to stop 
delegations, not because I agree with that.

I could imagine a policy proposal that says "operate reverse mapping 
DNS or lose your allocation" as being the one way to force reverse 
mapping to happen.  But I  also imagine that any such proposal would 
"go down in flames."

I'll conclude by saying that the anal-retentive DNS-wonk engineer in 
me really wants to see a fully populated reverse map zone.  But 
observing the behavior of humans who make decisions, reverse mapping 
is something that isn't going to become mandatory.  I would be 
willing to help any policy that encourages population of the reverse 
map, but given what I've witnessed I think the effort is Quixotic.

ARIN could institute a service of offering free slave service to all 
allocations to encourage reverse map population.  However there are 
problems with this.  One, such an offering is not a topic for a 
policy proposal (see proposals 2007-1,2,3 for what I mean).  Two, 
this would conflict with commercial efforts to provide slave service. 
(A unit of my employer is in that market.)  I raise this because RIPE 
has historically provided slave service but requests have been made 
to cease the free service.

(See: http://ripe.net/ripe/maillists/archives/dns-wg/2006/msg00173.html
    51.3 Lars-Johan Liman -- NCC Secondary Service Policy
         Lars commented that the RIPE NCC has announced it will limit
         involvement in provision of slave servers for TLDs. Lars suggested
         this be closed for now and marked as overtaken by events.
         The working group agreed.
         [[Done, pending mailing list approval]]
)

PS - In digging up references I came across these other links to 
related topics:

These refer to 2003 discussions about lame delegations within RIPE:
http://ripe.net/ripe/maillists/archives/dns-wg/2003/msg00069.html
http://ripe.net/ripe/maillists/archives/dns-wg/2003/msg00088.html

This is an APNIC meeting that covered lame delegations and a general 
reverse map tool, as well as a report of an operational failure 
incident:
http://www.apnic.net/meetings/21/programme/sigs/dns.html

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/fb05dea4/attachment.htm>

From owen at delong.com  Tue Sep 11 09:04:11 2007
From: owen at delong.com (Owen DeLong)
Date: Tue, 11 Sep 2007 06:04:11 -0700
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272FA0E@nyrofcs2ke2k01.corp.pvt>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0E@nyrofcs2ke2k01.corp.pvt>
Message-ID: <13110A43-314E-44F4-855D-2C379CE1E96E@delong.com>


On Sep 10, 2007, at 10:12 PM, Azinger, Marla wrote:

> Well, as Randy pointed out ...maybe I am leaping a bit.  But I have  
> had circular conversations where that wasnt viewed as such a leap.   
> Be it strictly routing or dns success/failures, they both have  
> fallen into the  "it shouldnt be dictated by ARIN" conversations.   
> And I guess pointing out in an obviouse way that they shouldnt be  
> in the same conversation is needed.  So...thanks Randy for getting  
> me thinking straight again.
>
> So to your point John, I would say its worth writing up and  
> submitting it.  Clearly you have good rational and a need.  I would  
> be interested to see how many people would support it and what type  
> of Con's would be pointed out.
>
1.	This is not about lame server delegations. It's about  
operationally incomplete
	DNS data.
2.	DNS is not routing, but, DNS Operations, like routing, are outside  
of ARIN's scope.
3.	It still doesn't have anything to do with stewardship over the  
address space
	or address assignment policy.
4.	This is an operational issue.
5.	ARIN is an address policy forum and not an operational forum.

If you want a policy body, I'd say this belongs to IETF more than any  
other
policy body I can think of.  It is clearly out of scope for ARIN in  
my opinion.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/ac5aea87/attachment.htm>

From arin-contact at dirtside.com  Tue Sep 11 09:33:23 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Tue, 11 Sep 2007 09:33:23 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <D7E6A943-C613-479F-831A-31CE498FE2BB@quonix.net>
References: <D7E6A943-C613-479F-831A-31CE498FE2BB@quonix.net>
Message-ID: <3c3e3fca0709110633x1b6e2a70w4cdcbc0d5ec988f6@mail.gmail.com>

On 9/10/07, John Von Essen <john at quonix.net> wrote:
> What are other peoples thoughts on this? Could the policy be updated
> requiring full mapping of ALL in-addr.arpa zones that an AS advertises?

John,

The posters so far are essentially correct: no policy has been broken
here. Its entirely up to the ISP to decide how (or even if) they
manage or delegate RDNS. If you can, you should fine another provider.
If your provider is a monopoly like the Bells or cable companies,
there may be a local venue in which you can file an actionable
complaint. At the very least you can try a complaint at the better
business bureau.

Two additional thoughts:

ARIN's preference to refer to the ISP as a "Local Internet Registry"
is a problem here. It implies that the ISP has a duty to competently
manage all of the delegated resources but at least for the RDNS that's
simply not true. If we're not going to require reasonable management
of the resources, we shouldn't be referring to them as LIRs.

Who's the ISP? I'd like to call up their marketing manager and suggest
that their customers have been hurt and reputation damaged by their
mismanagement of the RDNS. A little ridicule placed in the right ear
can go a long way towards correcting undesirable behavior.

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From stephen at sprunk.org  Tue Sep 11 09:31:05 2007
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 11 Sep 2007 08:31:05 -0500
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt><46E61408.5000100@psg.com>
	<091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net>
Message-ID: <00ec01c7f47c$b407a370$393816ac@atlanta.polycom.com>

Thus spake John Von Essen
> Maria, I understand your comments, but consider this... The
> current policy on reverse dns mapping "almost" does the job
> - it just needs to go a tiny bit further.
>
> Current policy dictates that you have to map an in-addr.arpa
> zone for your prefix in order for your nameservers to not be
> considered lame.
...
> Lets not forget that reverse DNS plays an important role in the
> proper operation of many protocols throughout the internet, and
> one of ARINs most important jobs is delegation of reverse dns
> authority.  ARIN has a responsibility to make sure that the DNS
> server they are delegating reverse authority too is maintained
> to at least a minimum level of efficiency.

I'm tempted to say "your ISP should be free to sell you bad service if 
you're willing to buy it", but that's not terribly helpful to you.

Instead, what I'll say is that you are welcome to submit a proposal to 
modify the policy "a tiny bit" in the way you wish.  Unfortunately you've 
missed the cut-off for the current cycle, but that means you have about five 
months to get the details worked out for the next cycle.  If you're looking 
for someone to help you with the wording or process for such a proposal, 
please make a more explicit request for that so we know how to help.

I'm personally neutral on the topic until we have a proposal to debate 
(preferably after Albuquerque).

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking




From john at quonix.net  Tue Sep 11 10:34:49 2007
From: john at quonix.net (John Von Essen)
Date: Tue, 11 Sep 2007 10:34:49 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <7989754C-C7A0-4E4B-8095-A4FE8E785F89@delong.com>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>
	<46E61408.5000100@psg.com>
	<091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net>
	<7989754C-C7A0-4E4B-8095-A4FE8E785F89@delong.com>
Message-ID: <995886AB-001D-4C91-A787-4572BFB0ED1E@quonix.net>

Wrong, wrong, wrong.

I appreciate the comments, but I think some people still are  
misunderstanding the issues.

Let me clarify, my post has nothing to do with Org's reversing IPs  
with valid PTRs. If an Org doesn't want to reverse an an IP thats  
fine, and like Owen said, with no PTR, and instantaneous NX Domain  
error comes back, no timeout.

But that is not that scenario I am describing. Consider the following  
real-world example:

# nslookup 208.72.239.200
Server:         4.2.2.2
Address:        4.2.2.2#53
** server can't find 200.239.72.208.in-addr.arpa: NXDOMAIN

Thats good. The AS who advertises 208.72.239.0/24 has the  
239.72.208.in-addr.arpa zone configured in their name server, an SOA  
an NS record exists, but there is no PTR data. And that is perfectly  
fine.

Now consider this...

# nslookup 76.161.191.192
;; connection timed out; no servers could be reached

And the above took about 20 seconds to return. The AS who advertises  
76.161.192.0/24 (and many other /24's) does not have the  
192.161.76.in-addr.arpa zone configured at all on their DNS server.  
This is a problem for the user of that IP, and any person on the  
internet that has to talk to that IP since it will create a  
burdensome dns timeouts.

I'm sorry, but that second example is simply unacceptable. This may  
sound rude, but the amount of money ARIN brings in for ASN  
registrations, membership, and IP range allocations - the buck has to  
stop with ARIN when it comes to AS's who completely misconfigure  
massive in-addr.arpa zones and potentially create the environment to  
slow down dns traffic throughout the internet.

When ARIN delegates reverse authority to the DNS servers of an AS  
that does not have in-addr.arpa zone configured at all (for IP's in  
use), ARIN is openly supporting a practice that hurts the internet by  
allowing these dns timeouts to propagate. ARIN should take  
responsibility.

All I am saying is simply state in policy, that if an AS advertises a  
prefix and uses an IP range, that in-addr.arpa zone for those IPs has  
to be at least be configured to return an SOA and avoid this problem  
of timeouts. If they dont, that AS is violating policy, and if they  
dont resolve it, the dns delegation would be removed all together -  
with a specified time table (say within 30 days).

-John



On Sep 11, 2007, at 8:34 AM, Owen DeLong wrote:

> Also, such a server should _NOT_ cause delays.  It should  
> instantaneously
> return an NXDOMAIN result.
>
> Your issue isn't lame servers.  Your issue is servers with  
> incomplete data,
> which is an operational issue well outside of the scope of Address  
> Assignment
> policy.

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/0b770766/attachment.htm>

From marla.azinger at frontiercorp.com  Tue Sep 11 11:02:44 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Tue, 11 Sep 2007 11:02:44 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272FA0F@nyrofcs2ke2k01.corp.pvt>

Michael-  
 
One, If you look at my posting I posted as a member and an employee from Frontier.  I may be on AC but I did not post as "AC".
 
Two, I believe John has a valid point.  I believe it should be discussed and I believe that draft proposals tend to help further discussion.  And as someone else pointed out, this potential proposal would be inserted into the next conference cycle not this one.  But yet, had it been brought up in time, it is no less valid than other topics.
 
Three, as you point out in another email education is needed.  Like it or not, the whole proposal discussion realm is a large classroom.  You can debate the correctness of this reality, but its still reality.
 
Cheers!
Marla

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of michael.dillon at bt.com
Sent: Tuesday, September 11, 2007 2:23 AM
To: ppml at arin.net
Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy


>  So to your point John, I would say its worth writing up and submitting it.   
> Clearly you have good rational and a need.  I would be interested to see  
>  how many people would support it and what type of Con's would be pointed out.   
 
I personally think that it is inappropriate for an ARIN AC member to be encouraging people to submit policy proposals that are clearly out of the scope of ARIN's charter.
 
It is most UNhelpful to encourage such pollution of the policymaking process. We already have more than enough volume of proposals to deal with.
 
--Michael Dillon
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/de7ca286/attachment.htm>

From stephen at sprunk.org  Tue Sep 11 11:28:47 2007
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 11 Sep 2007 10:28:47 -0500
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0E@nyrofcs2ke2k01.corp.pvt>
	<D03E4899F2FB3D4C8464E8C76B3B68B00102F5E3@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <01ff01c7f489$b5b1be10$393816ac@atlanta.polycom.com>

Thus spake michael.dillon at bt.com
>>  So to your point John, I would say its worth writing up and
>> submitting it.   Clearly you have good rational and a need.  I
>> would be interested to see how many people would support it
>> and what type of Con's would be pointed out.
>
> I personally think that it is inappropriate for an ARIN AC member
> to be encouraging people to ...

We're supposed to be electing people to the AC because they have Clue(tm) on 
numbering resource matters, so it is counter-productive to attempt to muzzle 
them.

I am happy with the recent trend by BoT members to indicate whether they're 
speaking with their BoT "hats" on or not; perhaps it would be appropriate 
for AC members to do so as well to avoid the appearance of them trying to 
unduly influence the process.  Personally, I think it should not be 
necessary, since any official statements from the BoT or AC come in an 
easily-recognized form, but it's a friendly, voluntary process that helps 
remind people.

> ... submit policy proposals that are clearly out of the scope of
> ARIN's charter.

I disagree that such a proposal is "clearly" out of scope.  We have existing 
policy (7.2) against lame delegations.  It is not much of a stretch to 
extend that policy to include lame subdelegations.  At most, the point is 
debatable, which means it's not "clear".

If such a proposal were accepted by the community, it would be up to counsel 
to determine whether it was within the charter.  We have been told to make 
the policy we feel is best for the community without regard to legal 
complications until told otherwise.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 




From weiler at tislabs.com  Tue Sep 11 12:08:49 2007
From: weiler at tislabs.com (Sam Weiler)
Date: Tue, 11 Sep 2007 12:08:49 -0400 (EDT)
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
Message-ID: <Pine.LNX.4.64.0709111142110.15772@mint.samweiler.com>

On Tue, 11 Sep 2007, William Herrin wrote:

> The posters so far are essentially correct: no policy has been 
> broken here.

I disagree.  Current policy requires ARIN to remove lame delegations 
from the reverse DNS zones it manages.  I've seen evidence that ARIN 
isn't doing that, and I think ARIN is in violation of NRPM Section 
7.2.

In this case, I'm using a broad definition of "lame" that includes 
"all nameservers listed in the NS RRset are unreachable".

Here's another example that was reported to ARIN on May 11th, four 
months ago to the day:
'dig +trace 79.114.208.in-addr.arpa.'

Perhaps some guidance from the staff would be useful here.  Is the 
current policy sufficient for you to clean these up?  Are you reading 
"lame" broadly enough to cover the cases raised by Mr. Von Essen and 
myself?  Absent instructions from the community specifying a 
timetable[1], how long will it take between these being reported and 
them being cleaned up?  (FWIW, I'd prefer to see a short timetable, on 
the order of two weeks.)

-- Sam

[1] Not that I'm optimistic about the chances of ARIN listening to the 
community: 2005-3 included an implementation timetable of 90 days 
after adoption.  It appears to have taken 797 days.


From Ed.Lewis at neustar.biz  Tue Sep 11 12:13:28 2007
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Tue, 11 Sep 2007 12:13:28 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <995886AB-001D-4C91-A787-4572BFB0ED1E@quonix.net>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>
	<46E61408.5000100@psg.com>
	<091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net>
	<7989754C-C7A0-4E4B-8095-A4FE8E785F89@delong.com>
	<995886AB-001D-4C91-A787-4572BFB0ED1E@quonix.net>
Message-ID: <a06240804c30c6c8970c5@[10.31.32.75]>

At 10:34 -0400 9/11/07, John Von Essen wrote:

>All I am saying is simply state in policy, that if an AS advertises a
>prefix and uses an IP range, that in-addr.arpa zone for those IPs has to
>be at least be configured to return an SOA and avoid this problem of
>timeouts. If they dont, that AS is violating policy, and if they dont
>resolve it, the dns delegation would be removed all together - with a
>specified time table (say within 30 days).

2005-3 kind of already answers this, but it does say "lame" 
delegations.  If we expand the scope to include all name servers that 
fail to respond we have to define what fail to respond means.  "Fail 
to respond over an X day window, tested a few times daily."  "Fail to 
respond to queries issued from set point/s in the public Internet." 
(UDP is pain when it comes to specifying what constitutes a failure 
case because the protocol is inherently unreliable.)

The irritation is where to draw the line between policy and specifics 
of the implementation.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.


From MOHLER at graceland.edu  Tue Sep 11 12:26:27 2007
From: MOHLER at graceland.edu (Dave Mohler)
Date: Tue, 11 Sep 2007 11:26:27 -0500
Subject: [ppml] AC Members' participation in ppml discussions -- was
	Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <01ff01c7f489$b5b1be10$393816ac@atlanta.polycom.com>
Message-ID: <EA9B1801BA3A584887D7D4AB70DC30B008B93437@athena.graceland.edu>

I have also found AC (and BoT) members' contributions to the policy
discussion here on this list helpful.  I have _not_ felt that their
contributions included a tone suggesting that their AC membership added
any weight to the thoughts they expressed beyond that of any other
contributors' thoughts.

To the contrary, I would feel that it was a less open process if AC
members withheld their views until the meeting at which a vote was to be
taken.  Having AC members' views shared on the list allows list
participants with opposing (or even slightly varying) views more time to
thoughtfully challenge those positions.  Issues withheld until the
meeting could leave those with opposing views with the feeling of having
been blindsided.

-- Just my "two cents"(tm)
-- dave

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf
Of
> Stephen Sprunk
> Sent: Tuesday, September 11, 2007 10:29 AM
> To: michael.dillon at bt.com
> Cc: ARIN PPML
> Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy
> 
> Thus spake michael.dillon at bt.com
> >>  So to your point John, I would say its worth writing up and
> >> submitting it.   Clearly you have good rational and a need.  I
> >> would be interested to see how many people would support it
> >> and what type of Con's would be pointed out.
> >
> > I personally think that it is inappropriate for an ARIN AC member
> > to be encouraging people to ...
> 
> We're supposed to be electing people to the AC because they have
Clue(tm)
> on
> numbering resource matters, so it is counter-productive to attempt to
> muzzle
> them.
> 
> I am happy with the recent trend by BoT members to indicate whether
> they're
> speaking with their BoT "hats" on or not; perhaps it would be
appropriate
> for AC members to do so as well to avoid the appearance of them trying
to
> unduly influence the process.  Personally, I think it should not be
> necessary, since any official statements from the BoT or AC come in an
> easily-recognized form, but it's a friendly, voluntary process that
helps
> remind people.
> ...


From john at quonix.net  Tue Sep 11 12:29:07 2007
From: john at quonix.net (John Von Essen)
Date: Tue, 11 Sep 2007 12:29:07 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <Pine.LNX.4.64.0709111142110.15772@mint.samweiler.com>
References: <Pine.LNX.4.64.0709111142110.15772@mint.samweiler.com>
Message-ID: <81245675-0736-467F-9EF2-A20A0FC0E904@quonix.net>

Identical issues to what I am experiencing. If people look deeply  
enough, I am confident there are many Org's who operate AS's with no  
in-addr.arpa SOA on there DNS servers.

If anything, can we agree on the fact the current policy is too  
vague. I had to email ARIN's hostmaster 2 or 3 times to understand it  
- it can be read many ways. And the explanation I got from hostmaster  
was if an AS properly configures at least one in-addr.arpa zone, then  
Arin will bless the entire delegation and not consider the dns server  
as lame. To be honest, I have no idea how one draws that conclusion  
from the wording on the policy.

DNS is a standard protocol. The policy should specifically state the  
dns servers must return a valid SOA for each in-addr.arpa in their IP  
prefix that they advertise from their AS (i.e. they dont have to do  
it for IPs they dont use). If any in-addr.arpa does not return an  
SOA, then that AS is in violation, and their nameserver will be  
considered lame and suspect for removal from reverse delegation.

I dont think it is a requirement that ARIN proactively seek and find  
AS's that are in violation, but it should be in the policy.

Those 2 or 3 sentences are all that is needed.


On Sep 11, 2007, at 12:08 PM, Sam Weiler wrote:

> dig +trace 79.114.208.in-addr.arpa.

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/3e53db74/attachment.htm>

From packetgrrl at gmail.com  Tue Sep 11 14:15:20 2007
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Tue, 11 Sep 2007 12:15:20 -0600
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <81245675-0736-467F-9EF2-A20A0FC0E904@quonix.net>
References: <Pine.LNX.4.64.0709111142110.15772@mint.samweiler.com>
	<81245675-0736-467F-9EF2-A20A0FC0E904@quonix.net>
Message-ID: <c3227e9e0709111115s3343813bt49ac9a0d6e8c9eaf@mail.gmail.com>

If the policy needs updating I really hope one of you will take on the
project and submit suggested changes in the form of a policy proposal.
There are a number of us on the AC who are more than willing to help and
shepherd it through the process.  The great thing about the policy process
is that if you don't like a policy you can take action and fix/change it.

Thanks!
----Cathy

On 9/11/07, John Von Essen <john at quonix.net> wrote:
>
> Identical issues to what I am experiencing. If people look deeply enough,
> I am confident there are many Org's who operate AS's with no in-addr.arpaSOA on there DNS servers.
> If anything, can we agree on the fact the current policy is too vague. I
> had to email ARIN's hostmaster 2 or 3 times to understand it - it can be
> read many ways. And the explanation I got from hostmaster was if an AS
> properly configures at least one in-addr.arpa zone, then Arin will bless
> the entire delegation and not consider the dns server as lame. To be honest,
> I have no idea how one draws that conclusion from the wording on the policy.
>
> DNS is a standard protocol. The policy should specifically state the dns
> servers must return a valid SOA for each in-addr.arpa in their IP prefix
> that they advertise from their AS (i.e. they dont have to do it for IPs
> they dont use). If any in-addr.arpa does not return an SOA, then that AS
> is in violation, and their nameserver will be considered lame and suspect
> for removal from reverse delegation.
>
> I dont think it is a requirement that ARIN proactively seek and find AS's
> that are in violation, but it should be in the policy.
>
> Those 2 or 3 sentences are all that is needed.
>
>
> On Sep 11, 2007, at 12:08 PM, Sam Weiler wrote:
>
> dig +trace 79.114.208.in-addr.arpa.
>
>
> Thanks,
> John Von Essen
> (800) 248-1736 ext 100
> john at quonix.net
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member
> Services
> Help Desk at info at arin.net if you experience any issues.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/2de7b013/attachment.htm>

From john at quonix.net  Tue Sep 11 14:30:44 2007
From: john at quonix.net (John Von Essen)
Date: Tue, 11 Sep 2007 14:30:44 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <c3227e9e0709111115s3343813bt49ac9a0d6e8c9eaf@mail.gmail.com>
References: <Pine.LNX.4.64.0709111142110.15772@mint.samweiler.com>
	<81245675-0736-467F-9EF2-A20A0FC0E904@quonix.net>
	<c3227e9e0709111115s3343813bt49ac9a0d6e8c9eaf@mail.gmail.com>
Message-ID: <01422249-3F8A-466D-B309-DABA555D92F3@quonix.net>

Well, I for one would like to take on this project. How does one  
begin to submit a policy proposal?

-John

On Sep 11, 2007, at 2:15 PM, cja at daydream.com wrote:

> If the policy needs updating I really hope one of you will take on  
> the project and submit suggested changes in the form of a policy  
> proposal.  There are a number of us on the AC who are more than  
> willing to help and shepherd it through the process.  The great  
> thing about the policy process is that if you don't like a policy  
> you can take action and fix/change it.
>
> Thanks!
> ----Cathy
>
> On 9/11/07, John Von Essen <john at quonix.net> wrote:
> Identical issues to what I am experiencing. If people look deeply  
> enough, I am confident there are many Org's who operate AS's with  
> no in-addr.arpa SOA on there DNS servers.
>
> If anything, can we agree on the fact the current policy is too  
> vague. I had to email ARIN's hostmaster 2 or 3 times to understand  
> it - it can be read many ways. And the explanation I got from  
> hostmaster was if an AS properly configures at least one in- 
> addr.arpa zone, then Arin will bless the entire delegation and not  
> consider the dns server as lame. To be honest, I have no idea how  
> one draws that conclusion from the wording on the policy.
>
> DNS is a standard protocol. The policy should specifically state  
> the dns servers must return a valid SOA for each in-addr.arpa in  
> their IP prefix that they advertise from their AS (i.e. they dont  
> have to do it for IPs they dont use). If any in-addr.arpa does not  
> return an SOA, then that AS is in violation, and their nameserver  
> will be considered lame and suspect for removal from reverse  
> delegation.
>
> I dont think it is a requirement that ARIN proactively seek and  
> find AS's that are in violation, but it should be in the policy.
>
> Those 2 or 3 sentences are all that is needed.
>
>
> On Sep 11, 2007, at 12:08 PM, Sam Weiler wrote:
>
>> dig +trace 79.114.208.in-addr.arpa.
>
> Thanks,
> John Von Essen
> (800) 248-1736 ext 100
> john at quonix.net
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List ( PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.
>
>

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/37277e44/attachment.htm>

From packetgrrl at gmail.com  Tue Sep 11 14:34:21 2007
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Tue, 11 Sep 2007 12:34:21 -0600
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <01422249-3F8A-466D-B309-DABA555D92F3@quonix.net>
References: <Pine.LNX.4.64.0709111142110.15772@mint.samweiler.com>
	<81245675-0736-467F-9EF2-A20A0FC0E904@quonix.net>
	<c3227e9e0709111115s3343813bt49ac9a0d6e8c9eaf@mail.gmail.com>
	<01422249-3F8A-466D-B309-DABA555D92F3@quonix.net>
Message-ID: <c3227e9e0709111134i44e5fc7fhdf6f7f07af54c7cc@mail.gmail.com>

All the info you need is here

http://www.arin.net/policy/irpep.html

----Cathy

On 9/11/07, John Von Essen <john at quonix.net> wrote:
>
> Well, I for one would like to take on this project. How does one begin to
> submit a policy proposal?
> -John
>
> On Sep 11, 2007, at 2:15 PM, cja at daydream.com wrote:
>
> If the policy needs updating I really hope one of you will take on the
> project and submit suggested changes in the form of a policy proposal.
> There are a number of us on the AC who are more than willing to help and
> shepherd it through the process.  The great thing about the policy process
> is that if you don't like a policy you can take action and fix/change it.
>
> Thanks!
> ----Cathy
>
> On 9/11/07, John Von Essen <john at quonix.net> wrote:
> >
> > Identical issues to what I am experiencing. If people look deeply
> > enough, I am confident there are many Org's who operate AS's with no
> > in-addr.arpa SOA on there DNS servers.
> > If anything, can we agree on the fact the current policy is too vague. I
> > had to email ARIN's hostmaster 2 or 3 times to understand it - it can be
> > read many ways. And the explanation I got from hostmaster was if an AS
> > properly configures at least one in-addr.arpa zone, then Arin will bless
> > the entire delegation and not consider the dns server as lame. To be honest,
> > I have no idea how one draws that conclusion from the wording on the policy.
> >
> > DNS is a standard protocol. The policy should specifically state the dns
> > servers must return a valid SOA for each in-addr.arpa in their IP prefix
> > that they advertise from their AS (i.e. they dont have to do it for IPs
> > they dont use). If any in-addr.arpa does not return an SOA, then that AS
> > is in violation, and their nameserver will be considered lame and suspect
> > for removal from reverse delegation.
> >
> > I dont think it is a requirement that ARIN proactively seek and find
> > AS's that are in violation, but it should be in the policy.
> >
> > Those 2 or 3 sentences are all that is needed.
> >
> >
> > On Sep 11, 2007, at 12:08 PM, Sam Weiler wrote:
> >
> > dig +trace 79.114.208.in-addr.arpa.
> >
> >
> >   Thanks,
> > John Von Essen
> > (800) 248-1736 ext 100
> > john at quonix.net
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the ARIN
> > Public Policy
> > Mailing List ( PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
> > Member Services
> > Help Desk at info at arin.net if you experience any issues.
> >
> >
>
> Thanks,
> John Von Essen
> (800) 248-1736 ext 100
> john at quonix.net
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member
> Services
> Help Desk at info at arin.net if you experience any issues.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/94d0cf4d/attachment.htm>

From tme at multicasttech.com  Tue Sep 11 14:48:08 2007
From: tme at multicasttech.com (Marshall Eubanks)
Date: Tue, 11 Sep 2007 14:48:08 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <01422249-3F8A-466D-B309-DABA555D92F3@quonix.net>
References: <Pine.LNX.4.64.0709111142110.15772@mint.samweiler.com>
	<81245675-0736-467F-9EF2-A20A0FC0E904@quonix.net>
	<c3227e9e0709111115s3343813bt49ac9a0d6e8c9eaf@mail.gmail.com>
	<01422249-3F8A-466D-B309-DABA555D92F3@quonix.net>
Message-ID: <87FE5159-7A05-4F50-B509-0748C715395F@multicasttech.com>


On Sep 11, 2007, at 2:30 PM, John Von Essen wrote:

> Well, I for one would like to take on this project. How does one  
> begin to submit a policy proposal?
>

Go to

http://www.arin.net/policy/index.html

read down, follow directions.

Regards
Marshall


> -John
>
> On Sep 11, 2007, at 2:15 PM, cja at daydream.com wrote:
>
>> If the policy needs updating I really hope one of you will take on  
>> the project and submit suggested changes in the form of a policy  
>> proposal.  There are a number of us on the AC who are more than  
>> willing to help and shepherd it through the process.  The great  
>> thing about the policy process is that if you don't like a policy  
>> you can take action and fix/change it.
>>
>> Thanks!
>> ----Cathy
>>
>> On 9/11/07, John Von Essen <john at quonix.net> wrote:
>> Identical issues to what I am experiencing. If people look deeply  
>> enough, I am confident there are many Org's who operate AS's with  
>> no in-addr.arpa SOA on there DNS servers.
>>
>> If anything, can we agree on the fact the current policy is too  
>> vague. I had to email ARIN's hostmaster 2 or 3 times to understand  
>> it - it can be read many ways. And the explanation I got from  
>> hostmaster was if an AS properly configures at least one in- 
>> addr.arpa zone, then Arin will bless the entire delegation and not  
>> consider the dns server as lame. To be honest, I have no idea how  
>> one draws that conclusion from the wording on the policy.
>>
>> DNS is a standard protocol. The policy should specifically state  
>> the dns servers must return a valid SOA for each in-addr.arpa in  
>> their IP prefix that they advertise from their AS (i.e. they dont  
>> have to do it for IPs they dont use). If any in-addr.arpa does not  
>> return an SOA, then that AS is in violation, and their nameserver  
>> will be considered lame and suspect for removal from reverse  
>> delegation.
>>
>> I dont think it is a requirement that ARIN proactively seek and  
>> find AS's that are in violation, but it should be in the policy.
>>
>> Those 2 or 3 sentences are all that is needed.
>>
>>
>> On Sep 11, 2007, at 12:08 PM, Sam Weiler wrote:
>>
>>> dig +trace 79.114.208.in-addr.arpa.
>>
>> Thanks,
>> John Von Essen
>> (800) 248-1736 ext 100
>> john at quonix.net
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the  
>> ARIN Public Policy
>> Mailing List ( PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the  
>> ARIN Member Services
>> Help Desk at info at arin.net if you experience any issues.
>>
>>
>
> Thanks,
> John Von Essen
> (800) 248-1736 ext 100
> john at quonix.net
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.



From tedm at ipinc.net  Tue Sep 11 17:07:14 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 11 Sep 2007 14:07:14 -0700
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <01422249-3F8A-466D-B309-DABA555D92F3@quonix.net>
Message-ID: <NABBJOELMNGNJNGPKDDOEEINHDAA.tedm@ipinc.net>

John,

  Sorry for the top post but allow me to interject my $0.02 here.

  The purpose of this mailing list is to flesh out proposals.  There have
been enough postings on
this topic for you to get an idea of what would happen to such a proposal -
it would be voted
down as it's not in the RIR's scope of responsibilities.  I therefore think
your wasting your time
filing a proposal.

  Now I have read your ranting and some of the responses.  But there is one
response that I
didn't see and that you obviously didn't consider.  In my opinion, the
network manager at
your ISP is fully aware of the PTR issues and has chosen to DELIBERATELY not
entered
the in-addr.arpa zone for your numbers.

  "Why would those bozos do this" I hear you ask.  Very simple.  I am
assuming from the
background information you have posted that your DSL account is a simple
retail DSL account.
Well, the ISP that your buying it from may not want you running servers on
that account.
Nor may they not want you making direct SMTP connections to other people's
mailservers from
that IP address.  They have their own mailserver - maybe they think if you
want to relay outbound
mail then relay it through their server.

  Most of the gloom-and-doom scenarios you describe about the lack of PTR
records
simply do not apply.  We have NEVER had valid PTR's on our modem dialup IP
pools
for the simple reason that in any given time at least 20% of our modem
customers are
running systems that are infected with SMTP mailer viruses.  If one of our
infected
customers transmits spam to a destination mailserver, it is very simple for
that server
to reject the SMTP handshake on a failure to have either a forward or a
reverse record
in the DNS without having to spend lots of CPU time scanning the message for
spamliness.

And sure, we could block
outbound SMTP - which then is going to cause other complaints, plus there is
the
philosophical argument about blocking.  A dialup user could have a perfectly
legitimate need for
outbound SMTP so why block.  By contrast, chances a user would have a
legitimate
need for in-addr.arpa is far lower, and much easier to accomodate in any
case.

  As for our DSL customers, we do not by default add in PTR records
(although we do
have the in-addr.arpa zones properly setup and referred to the nameserver)
If you were our
customer and you called complaining I would have a very serious and long
discussion with
you to figure out exactly what you were doing and whether you were violating
any of our
AUPs.  Assuming you were in the category of "home user that wants to dink
around with
a personal mailserver" I'd set it up for you.  We have a number of those.
But, if your
trying to scam us, that would be a different story.

  We have had, for example, people in the past who have purchased
RESIDENTIAL
dsl accounts from us then attempted to setup a mailserver using fetchmail or
some
such at a business site.  Not all businesses use commercial buildings or
have business
telephone numbers and it's possible for some of them to slip in a
residential order without
the ISP knowing.  Those customers then find a month into it that a large
percentage of their
outbound mail is spam-blocked by other ISPs for failure to have proper DNS
setup - they
then call us complaining and that flushes them out of the woodwork.  To get
the desired
DNS mapping they have to pay more money for a business account, of course.
(and
usually most of them do, with a comment along the lines of "I guess ya
caught me")

Today with organizations like dydns.org who's sole purpose is to assist
businesses to cheat ISP's, there are not a lot of tools an ISP has at it's
disposal to
catch cheaters that don't have a lot of side effects.  Control of
in-addr.arpa records
is one of the few.  I am not saying it is a great way.  But dydns.org is a
far, far more horrible
hack.  I have seen cheaters setting up DNS records with SOA timers set at
under a minute,
causing virtually EVERY SINGLE dns query for their domain to cause a root
server query -
costing the Internet hundreds of dollars of extra network load a month just
so the cheater
can save $20 a month on a business DSL line.  If you want to start throwing
around
policy proposals to police the Internet well then how about a minimum DNS
expiration
requirement of 6 hours?  Don't start with the stone throwing if your sitting
in a
glass house.

As for your GoDaddy scenario, well the application controls UDP timeout.  If
GoDaddy
is finding - like we have found with our own mailservers - that a 5 minute
retry timeout is
to long for a missing PTR check, then it is trivial to change the sendmail
config to lower
the timeout.  So, people not loading in-addr.arpa isn't going to be a
problem for them any
more than it's a problem for us for other ISP's who also don't load
in-addr.arpa

As for Telnet and SSH yes well that is an annoyance if your setting a SSH or
Telnet server
up on your DSL line and you want to telnet into it.  But the vast majority
of users don't
do this.

Your story sounds like your just being given the usual brush-off by your
ISP, they are pretending they are stupid about this issue, because they
don't want
to engage you in a discussion to explain their reasons for not setting up
in-addr.arpa
I noticed your mail is coming from 76.161.192.192 so you obviously figured
out how
to get a static IP that doesen't have this problem.  I would submit that
your real beef
is that you want to pay residential rates on a dynamic IP not business rates
on a
static IP.  I would also ask you if you would like it if one of your
business customers on
quonix.net were to setup a bunch of mailboxes ostensibly for users in their
business,
when in reality they were doing a fetchmail solution for a bunch of other
companies
and using you merely as a spam filter, and reselling your service (and
making far more
money doing that then your making from them)

Take care!
Ted

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of John
Von Essen
Sent: Tuesday, September 11, 2007 11:31 AM
To: Public Policy Mailing List
Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy


Well, I for one would like to take on this project. How does one begin to
submit a policy proposal?


-John


On Sep 11, 2007, at 2:15 PM, cja at daydream.com wrote:


If the policy needs updating I really hope one of you will take on the
project and submit suggested changes in the form of a policy proposal. There
are a number of us on the AC who are more than willing to help and shepherd
it through the process. The great thing about the policy process is that if
you don't like a policy you can take action and fix/change it.

Thanks!
----Cathy


On 9/11/07, John Von Essen <john at quonix.net> wrote:
Identical issues to what I am experiencing. If people look deeply enough, I
am confident there are many Org's who operate AS's with no in-addr.arpa SOA
on there DNS servers.


If anything, can we agree on the fact the current policy is too vague. I had
to email ARIN's hostmaster 2 or 3 times to understand it - it can be read
many ways. And the explanation I got from hostmaster was if an AS properly
configures at least one in-addr.arpa zone, then Arin will bless the entire
delegation and not consider the dns server as lame. To be honest, I have no
idea how one draws that conclusion from the wording on the policy.


DNS is a standard protocol. The policy should specifically state the dns
servers must return a valid SOA for each in-addr.arpa in their IP prefix
that they advertise from their AS (i.e. they dont have to do it for IPs they
dont use). If any in-addr.arpa does not return an SOA, then that AS is in
violation, and their nameserver will be considered lame and suspect for
removal from reverse delegation.


I dont think it is a requirement that ARIN proactively seek and find AS's
that are in violation, but it should be in the policy.


Those 2 or 3 sentences are all that is needed.




On Sep 11, 2007, at 12:08 PM, Sam Weiler wrote:


dig +trace 79.114.208.in-addr.arpa.


Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net





_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public
Policy
Mailing List ( PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member
Services
Help Desk at info at arin.net if you experience any issues.






Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net



From owen at delong.com  Tue Sep 11 17:10:09 2007
From: owen at delong.com (Owen DeLong)
Date: Tue, 11 Sep 2007 14:10:09 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
Message-ID: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>

Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0

1.	Policy Proposal Name: Deprecate Lame Server Policy
2.	Author
	a.	name: Owen DeLong
	b.	email: owen at delong.com
	c.	telephone: 408-921-6984
	d.	organization: JITTR Networks

3.	Proposal Version: 1.0
4.	Submission Date: 11 September, 2007
5.	Proposal type: delete
	new, modify, or delete.
6.	Policy term: permanent
	temporary, permanent, or renewable.
7.	Policy statement:
		Delete section 7 from the NRPM

8.	Rationale:
		Recent PPML discussion has called attention to the
		fact that lame DNS delegations are more an operational
		issue than one of policy.  As such, the existing lame
		delegation policy should be removed from the NRPM
		to remove the resultant confusion.  This is not meant
		to prevent ARIN staff from taking reasonable action
		WRT DNS operational issues related to resources issued
		by ARIN, but, such action can be covered by staff
		operational guidelines and is not within the scope
		of Address Policy.

9.	Timetable for implementation:
		1 June, 2008
10.	Meeting presenter:
END OF TEMPLATE


From john at quonix.net  Tue Sep 11 17:32:34 2007
From: john at quonix.net (John Von Essen)
Date: Tue, 11 Sep 2007 17:32:34 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <NABBJOELMNGNJNGPKDDOEEINHDAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOEEINHDAA.tedm@ipinc.net>
Message-ID: <B32F460F-9740-40DC-9E2E-6A1DE04ED47F@quonix.net>

Ted,

Your are making the same incorrect judgement over my original post.

Let me repeat, the issue is NOT about ISP's and forcing them to have  
PTRs.

I agree with you, the ISP doesn't need to have a PTR record for DSL  
IPs. It even helps curb spam.

But that is not the issue.

The issue is the ISP is operating a given IP range, say 5.5.5.0/24,  
and the DNS server that ARIN delegates reverse authority to does NOT  
have the 5.5.5.in-addr.arpa zone conigured at all, which means there  
is no SOA or NS record for in-addr.arpa zone. This is all way before  
we get to PTR records.

The problem with this is when you try to reverse the 5.5.5.0/24 IP  
you get a long timeout. (See dig +trace 191.161.76.in-addr.arpa.) If  
they map the in-addr.arpa zone, and decide to NOT enter any PTR's  
(which is okay) a reverse query would immediately return NXDOMAIN  
error, thereby not causing a timeout.

So why is this an issue?

Creation of that timeout extends beyond the ISP's local customer  
base. It effects 3rd party's that the ISP customer talks to. So the  
ISP is purposely creating excessive dns query timeouts on 3rd party  
resolvers because they failed to do a simple, and what I believe to  
be a required task - which is... mapping all in-addr.arpa's with at  
least an SOA and NS record. Last time I checked, causing excessive  
resource utilization on somebody else's system is called a DoS attack.

It is my opinion that if large scale abuse like this were to continue  
and grow, it could develop into a serious issue affecting global DNS  
resolver health. I feel ARIN policy has a responsibility to curb this  
potentional anomaly.

So please, no more posts about... "ISP's dont have to have PTR's". If  
you are making that statement, you are completely missing the point  
of the initial argument.

-John


On Sep 11, 2007, at 5:07 PM, Ted Mittelstaedt wrote:

> John,
>
>   Sorry for the top post but allow me to interject my $0.02 here.
>
>   The purpose of this mailing list is to flesh out proposals.   
> There have
> been enough postings on
> this topic for you to get an idea of what would happen to such a  
> proposal -
> it would be voted
> down as it's not in the RIR's scope of responsibilities.  I  
> therefore think
> your wasting your time
> filing a proposal.
>
>   Now I have read your ranting and some of the responses.  But  
> there is one
> response that I
> didn't see and that you obviously didn't consider.  In my opinion, the
> network manager at
> your ISP is fully aware of the PTR issues and has chosen to  
> DELIBERATELY not
> entered
> the in-addr.arpa zone for your numbers.
>
>   "Why would those bozos do this" I hear you ask.  Very simple.  I am
> assuming from the
> background information you have posted that your DSL account is a  
> simple
> retail DSL account.
> Well, the ISP that your buying it from may not want you running  
> servers on
> that account.
> Nor may they not want you making direct SMTP connections to other  
> people's
> mailservers from
> that IP address.  They have their own mailserver - maybe they think  
> if you
> want to relay outbound
> mail then relay it through their server.
>
>   Most of the gloom-and-doom scenarios you describe about the lack  
> of PTR
> records
> simply do not apply.  We have NEVER had valid PTR's on our modem  
> dialup IP
> pools
> for the simple reason that in any given time at least 20% of our modem
> customers are
> running systems that are infected with SMTP mailer viruses.  If one  
> of our
> infected
> customers transmits spam to a destination mailserver, it is very  
> simple for
> that server
> to reject the SMTP handshake on a failure to have either a forward  
> or a
> reverse record
> in the DNS without having to spend lots of CPU time scanning the  
> message for
> spamliness.
>
> And sure, we could block
> outbound SMTP - which then is going to cause other complaints, plus  
> there is
> the
> philosophical argument about blocking.  A dialup user could have a  
> perfectly
> legitimate need for
> outbound SMTP so why block.  By contrast, chances a user would have a
> legitimate
> need for in-addr.arpa is far lower, and much easier to accomodate  
> in any
> case.
>
>   As for our DSL customers, we do not by default add in PTR records
> (although we do
> have the in-addr.arpa zones properly setup and referred to the  
> nameserver)
> If you were our
> customer and you called complaining I would have a very serious and  
> long
> discussion with
> you to figure out exactly what you were doing and whether you were  
> violating
> any of our
> AUPs.  Assuming you were in the category of "home user that wants  
> to dink
> around with
> a personal mailserver" I'd set it up for you.  We have a number of  
> those.
> But, if your
> trying to scam us, that would be a different story.
>
>   We have had, for example, people in the past who have purchased
> RESIDENTIAL
> dsl accounts from us then attempted to setup a mailserver using  
> fetchmail or
> some
> such at a business site.  Not all businesses use commercial  
> buildings or
> have business
> telephone numbers and it's possible for some of them to slip in a
> residential order without
> the ISP knowing.  Those customers then find a month into it that a  
> large
> percentage of their
> outbound mail is spam-blocked by other ISPs for failure to have  
> proper DNS
> setup - they
> then call us complaining and that flushes them out of the  
> woodwork.  To get
> the desired
> DNS mapping they have to pay more money for a business account, of  
> course.
> (and
> usually most of them do, with a comment along the lines of "I guess ya
> caught me")
>
> Today with organizations like dydns.org who's sole purpose is to  
> assist
> businesses to cheat ISP's, there are not a lot of tools an ISP has  
> at it's
> disposal to
> catch cheaters that don't have a lot of side effects.  Control of
> in-addr.arpa records
> is one of the few.  I am not saying it is a great way.  But  
> dydns.org is a
> far, far more horrible
> hack.  I have seen cheaters setting up DNS records with SOA timers  
> set at
> under a minute,
> causing virtually EVERY SINGLE dns query for their domain to cause  
> a root
> server query -
> costing the Internet hundreds of dollars of extra network load a  
> month just
> so the cheater
> can save $20 a month on a business DSL line.  If you want to start  
> throwing
> around
> policy proposals to police the Internet well then how about a  
> minimum DNS
> expiration
> requirement of 6 hours?  Don't start with the stone throwing if  
> your sitting
> in a
> glass house.
>
> As for your GoDaddy scenario, well the application controls UDP  
> timeout.  If
> GoDaddy
> is finding - like we have found with our own mailservers - that a 5  
> minute
> retry timeout is
> to long for a missing PTR check, then it is trivial to change the  
> sendmail
> config to lower
> the timeout.  So, people not loading in-addr.arpa isn't going to be a
> problem for them any
> more than it's a problem for us for other ISP's who also don't load
> in-addr.arpa
>
> As for Telnet and SSH yes well that is an annoyance if your setting  
> a SSH or
> Telnet server
> up on your DSL line and you want to telnet into it.  But the vast  
> majority
> of users don't
> do this.
>
> Your story sounds like your just being given the usual brush-off by  
> your
> ISP, they are pretending they are stupid about this issue, because  
> they
> don't want
> to engage you in a discussion to explain their reasons for not  
> setting up
> in-addr.arpa
> I noticed your mail is coming from 76.161.192.192 so you obviously  
> figured
> out how
> to get a static IP that doesen't have this problem.  I would submit  
> that
> your real beef
> is that you want to pay residential rates on a dynamic IP not  
> business rates
> on a
> static IP.  I would also ask you if you would like it if one of your
> business customers on
> quonix.net were to setup a bunch of mailboxes ostensibly for users  
> in their
> business,
> when in reality they were doing a fetchmail solution for a bunch of  
> other
> companies
> and using you merely as a spam filter, and reselling your service (and
> making far more
> money doing that then your making from them)
>
> Take care!
> Ted
>
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf  
> Of John
> Von Essen
> Sent: Tuesday, September 11, 2007 11:31 AM
> To: Public Policy Mailing List
> Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy
>
>
> Well, I for one would like to take on this project. How does one  
> begin to
> submit a policy proposal?
>
>
> -John
>
>
> On Sep 11, 2007, at 2:15 PM, cja at daydream.com wrote:
>
>
> If the policy needs updating I really hope one of you will take on the
> project and submit suggested changes in the form of a policy  
> proposal. There
> are a number of us on the AC who are more than willing to help and  
> shepherd
> it through the process. The great thing about the policy process is  
> that if
> you don't like a policy you can take action and fix/change it.
>
> Thanks!
> ----Cathy
>
>
> On 9/11/07, John Von Essen <john at quonix.net> wrote:
> Identical issues to what I am experiencing. If people look deeply  
> enough, I
> am confident there are many Org's who operate AS's with no in- 
> addr.arpa SOA
> on there DNS servers.
>
>
> If anything, can we agree on the fact the current policy is too  
> vague. I had
> to email ARIN's hostmaster 2 or 3 times to understand it - it can  
> be read
> many ways. And the explanation I got from hostmaster was if an AS  
> properly
> configures at least one in-addr.arpa zone, then Arin will bless the  
> entire
> delegation and not consider the dns server as lame. To be honest, I  
> have no
> idea how one draws that conclusion from the wording on the policy.
>
>
> DNS is a standard protocol. The policy should specifically state  
> the dns
> servers must return a valid SOA for each in-addr.arpa in their IP  
> prefix
> that they advertise from their AS (i.e. they dont have to do it for  
> IPs they
> dont use). If any in-addr.arpa does not return an SOA, then that AS  
> is in
> violation, and their nameserver will be considered lame and suspect  
> for
> removal from reverse delegation.
>
>
> I dont think it is a requirement that ARIN proactively seek and  
> find AS's
> that are in violation, but it should be in the policy.
>
>
> Those 2 or 3 sentences are all that is needed.
>
>
>
>
> On Sep 11, 2007, at 12:08 PM, Sam Weiler wrote:
>
>
> dig +trace 79.114.208.in-addr.arpa.
>
>
> Thanks,
> John Von Essen
> (800) 248-1736 ext 100
> john at quonix.net
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public
> Policy
> Mailing List ( PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member
> Services
> Help Desk at info at arin.net if you experience any issues.
>
>
>
>
>
>
> Thanks,
> John Von Essen
> (800) 248-1736 ext 100
> john at quonix.net
>

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/cc993a5a/attachment.htm>

From briand at ca.afilias.info  Tue Sep 11 17:33:27 2007
From: briand at ca.afilias.info (Brian Dickson)
Date: Tue, 11 Sep 2007 17:33:27 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <NABBJOELMNGNJNGPKDDOEEINHDAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOEEINHDAA.tedm@ipinc.net>
Message-ID: <46E709A7.9060105@ca.afilias.info>

Ted Mittelstaedt wrote:
> There have
> been enough postings on
> this topic for you to get an idea of what would happen to such a proposal -
>   
There have been enough people commenting on their misinterpretation of 
John's observation (complaint),
and the underlying technical issue, that the proposal would need to be 
very clearly written to avoid this.

That said, the *actual* issue, if addressed, most certainly would be 
in-scope for RIR policies, and as such
would be suitable for normal discussion, and likely would get support, 
enough to be adopted as policy.
>   Now I have read your ranting and some of the responses.  But there is one
> response that I
> didn't see and that you obviously didn't consider.  In my opinion, the
> network manager at
> your ISP is fully aware of the PTR issues and has chosen to DELIBERATELY not
> entered
> the in-addr.arpa zone for your numbers.
>   
If that is what you think the issue is, then I think you misread the 
original message and several of the follow-ups.

The issue isn't the *content* (present or absent) of the in-addr zone 
that has been delegated, it is that the server to which
the delegation has been made, fails to answer queries for the *specific* 
in-addr zone. It is lame *for that zone*.

[discussion relevant only to non-lame zones with no PTRs in them, 
omitted for brevity.]
> As for your GoDaddy scenario, well the application controls UDP timeout. 
The problem is fundamentally tied to resolvers. Unless the application 
is doing a roll-your-own implementation
of name resolution, it is likely sharing a common fate with all clients 
of resolution service on whatever box is acting as a recursive resolver.

Tweaking timeouts on nameserver lookups is something, to paraphrase 
Randy Bush, I encourage anyone foolish enough to want to, to do so.
> Take care!
> Ted
>   
If you were to "take care" yourself and read and understand what the 
original poster said, IMHO reasonably clearly and with all due emphasis,
you would have been able to avoid making your misunderstanding so 
visible on a public mailing list. No offense intended.

Brian

> with no in-addr.arpa SOA
> on there DNS servers.
P.S. Aside from s/there/their/, the above quote summarizes the problem 
reported in 10 words or less. Less is more, IMHO.


From tedm at ipinc.net  Tue Sep 11 17:43:21 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 11 Sep 2007 14:43:21 -0700
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <B32F460F-9740-40DC-9E2E-6A1DE04ED47F@quonix.net>
Message-ID: <NABBJOELMNGNJNGPKDDOEEIOHDAA.tedm@ipinc.net>

Hi John,

  No, I understood perfectly that is why I took pains to explain that while
we don't put in
PTR records we do have the in-addr.arpa stuff setup for our in-use numbers
in our block.

  What I was trying to make as a point is that your assuming your ISP forgot
to put
them in. I'm saying they may be deliberately not putting them in precisely
to create those
annoying long timeouts.

Note this doesen't qualify as a DDoS attack because the delays don't happen
if the
recipeint TCP host doesen't do a PTR query.  There's no requirement in the
standard
that requires a host like a mailserver or suchlike to do a reverse record
lookup.

  I didn't say this was optimal.

Ted
  -----Original Message-----
  From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
John Von Essen
  Sent: Tuesday, September 11, 2007 2:33 PM
  To: Public Policy Mailing List
  Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy


  Ted,


  Your are making the same incorrect judgement over my original post.


  Let me repeat, the issue is NOT about ISP's and forcing them to have PTRs.


  I agree with you, the ISP doesn't need to have a PTR record for DSL IPs.
It even helps curb spam.


  But that is not the issue.


  The issue is the ISP is operating a given IP range, say 5.5.5.0/24, and
the DNS server that ARIN delegates reverse authority to does NOT have the
5.5.5.in-addr.arpa zone conigured at all, which means there is no SOA or NS
record for in-addr.arpa zone. This is all way before we get to PTR records.


  The problem with this is when you try to reverse the 5.5.5.0/24 IP you get
a long timeout. (See dig +trace 191.161.76.in-addr.arpa.) If they map the
in-addr.arpa zone, and decide to NOT enter any PTR's (which is okay) a
reverse query would immediately return NXDOMAIN error, thereby not causing a
timeout.


  So why is this an issue?


  Creation of that timeout extends beyond the ISP's local customer base. It
effects 3rd party's that the ISP customer talks to. So the ISP is purposely
creating excessive dns query timeouts on 3rd party resolvers because they
failed to do a simple, and what I believe to be a required task - which
is... mapping all in-addr.arpa's with at least an SOA and NS record. Last
time I checked, causing excessive resource utilization on somebody else's
system is called a DoS attack.


  It is my opinion that if large scale abuse like this were to continue and
grow, it could develop into a serious issue affecting global DNS resolver
health. I feel ARIN policy has a responsibility to curb this potentional
anomaly.


  So please, no more posts about... "ISP's dont have to have PTR's". If you
are making that statement, you are completely missing the point of the
initial argument.


  -John




  On Sep 11, 2007, at 5:07 PM, Ted Mittelstaedt wrote:


    John,


    Sorry for the top post but allow me to interject my $0.02 here.


    The purpose of this mailing list is to flesh out proposals. There have
    been enough postings on
    this topic for you to get an idea of what would happen to such a
proposal -
    it would be voted
    down as it's not in the RIR's scope of responsibilities. I therefore
think
    your wasting your time
    filing a proposal.


    Now I have read your ranting and some of the responses. But there is one
    response that I
    didn't see and that you obviously didn't consider. In my opinion, the
    network manager at
    your ISP is fully aware of the PTR issues and has chosen to DELIBERATELY
not
    entered
    the in-addr.arpa zone for your numbers.


    "Why would those bozos do this" I hear you ask. Very simple. I am
    assuming from the
    background information you have posted that your DSL account is a simple
    retail DSL account.
    Well, the ISP that your buying it from may not want you running servers
on
    that account.
    Nor may they not want you making direct SMTP connections to other
people's
    mailservers from
    that IP address. They have their own mailserver - maybe they think if
you
    want to relay outbound
    mail then relay it through their server.


    Most of the gloom-and-doom scenarios you describe about the lack of PTR
    records
    simply do not apply. We have NEVER had valid PTR's on our modem dialup
IP
    pools
    for the simple reason that in any given time at least 20% of our modem
    customers are
    running systems that are infected with SMTP mailer viruses. If one of
our
    infected
    customers transmits spam to a destination mailserver, it is very simple
for
    that server
    to reject the SMTP handshake on a failure to have either a forward or a
    reverse record
    in the DNS without having to spend lots of CPU time scanning the message
for
    spamliness.


    And sure, we could block
    outbound SMTP - which then is going to cause other complaints, plus
there is
    the
    philosophical argument about blocking. A dialup user could have a
perfectly
    legitimate need for
    outbound SMTP so why block. By contrast, chances a user would have a
    legitimate
    need for in-addr.arpa is far lower, and much easier to accomodate in any
    case.


    As for our DSL customers, we do not by default add in PTR records
    (although we do
    have the in-addr.arpa zones properly setup and referred to the
nameserver)
    If you were our
    customer and you called complaining I would have a very serious and long
    discussion with
    you to figure out exactly what you were doing and whether you were
violating
    any of our
    AUPs. Assuming you were in the category of "home user that wants to dink
    around with
    a personal mailserver" I'd set it up for you. We have a number of those.
    But, if your
    trying to scam us, that would be a different story.


    We have had, for example, people in the past who have purchased
    RESIDENTIAL
    dsl accounts from us then attempted to setup a mailserver using
fetchmail or
    some
    such at a business site. Not all businesses use commercial buildings or
    have business
    telephone numbers and it's possible for some of them to slip in a
    residential order without
    the ISP knowing. Those customers then find a month into it that a large
    percentage of their
    outbound mail is spam-blocked by other ISPs for failure to have proper
DNS
    setup - they
    then call us complaining and that flushes them out of the woodwork. To
get
    the desired
    DNS mapping they have to pay more money for a business account, of
course.
    (and
    usually most of them do, with a comment along the lines of "I guess ya
    caught me")


    Today with organizations like dydns.org who's sole purpose is to assist
    businesses to cheat ISP's, there are not a lot of tools an ISP has at
it's
    disposal to
    catch cheaters that don't have a lot of side effects. Control of
    in-addr.arpa records
    is one of the few. I am not saying it is a great way. But dydns.org is a
    far, far more horrible
    hack. I have seen cheaters setting up DNS records with SOA timers set at
    under a minute,
    causing virtually EVERY SINGLE dns query for their domain to cause a
root
    server query -
    costing the Internet hundreds of dollars of extra network load a month
just
    so the cheater
    can save $20 a month on a business DSL line. If you want to start
throwing
    around
    policy proposals to police the Internet well then how about a minimum
DNS
    expiration
    requirement of 6 hours? Don't start with the stone throwing if your
sitting
    in a
    glass house.


    As for your GoDaddy scenario, well the application controls UDP timeout.
If
    GoDaddy
    is finding - like we have found with our own mailservers - that a 5
minute
    retry timeout is
    to long for a missing PTR check, then it is trivial to change the
sendmail
    config to lower
    the timeout. So, people not loading in-addr.arpa isn't going to be a
    problem for them any
    more than it's a problem for us for other ISP's who also don't load
    in-addr.arpa


    As for Telnet and SSH yes well that is an annoyance if your setting a
SSH or
    Telnet server
    up on your DSL line and you want to telnet into it. But the vast
majority
    of users don't
    do this.


    Your story sounds like your just being given the usual brush-off by your
    ISP, they are pretending they are stupid about this issue, because they
    don't want
    to engage you in a discussion to explain their reasons for not setting
up
    in-addr.arpa
    I noticed your mail is coming from 76.161.192.192 so you obviously
figured
    out how
    to get a static IP that doesen't have this problem. I would submit that
    your real beef
    is that you want to pay residential rates on a dynamic IP not business
rates
    on a
    static IP. I would also ask you if you would like it if one of your
    business customers on
    quonix.net were to setup a bunch of mailboxes ostensibly for users in
their
    business,
    when in reality they were doing a fetchmail solution for a bunch of
other
    companies
    and using you merely as a spam filter, and reselling your service (and
    making far more
    money doing that then your making from them)


    Take care!
    Ted


    -----Original Message-----
    From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
John
    Von Essen
    Sent: Tuesday, September 11, 2007 11:31 AM
    To: Public Policy Mailing List
    Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy




    Well, I for one would like to take on this project. How does one begin
to
    submit a policy proposal?




    -John




    On Sep 11, 2007, at 2:15 PM, cja at daydream.com wrote:




    If the policy needs updating I really hope one of you will take on the
    project and submit suggested changes in the form of a policy proposal.
There
    are a number of us on the AC who are more than willing to help and
shepherd
    it through the process. The great thing about the policy process is that
if
    you don't like a policy you can take action and fix/change it.


    Thanks!
    ----Cathy




    On 9/11/07, John Von Essen <john at quonix.net> wrote:
    Identical issues to what I am experiencing. If people look deeply
enough, I
    am confident there are many Org's who operate AS's with no in-addr.arpa
SOA
    on there DNS servers.




    If anything, can we agree on the fact the current policy is too vague. I
had
    to email ARIN's hostmaster 2 or 3 times to understand it - it can be
read
    many ways. And the explanation I got from hostmaster was if an AS
properly
    configures at least one in-addr.arpa zone, then Arin will bless the
entire
    delegation and not consider the dns server as lame. To be honest, I have
no
    idea how one draws that conclusion from the wording on the policy.




    DNS is a standard protocol. The policy should specifically state the dns
    servers must return a valid SOA for each in-addr.arpa in their IP prefix
    that they advertise from their AS (i.e. they dont have to do it for IPs
they
    dont use). If any in-addr.arpa does not return an SOA, then that AS is
in
    violation, and their nameserver will be considered lame and suspect for
    removal from reverse delegation.




    I dont think it is a requirement that ARIN proactively seek and find
AS's
    that are in violation, but it should be in the policy.




    Those 2 or 3 sentences are all that is needed.








    On Sep 11, 2007, at 12:08 PM, Sam Weiler wrote:




    dig +trace 79.114.208.in-addr.arpa.




    Thanks,
    John Von Essen
    (800) 248-1736 ext 100
    john at quonix.net










    _______________________________________________
    PPML
    You are receiving this message because you are subscribed to the ARIN
Public
    Policy
    Mailing List ( PPML at arin.net).
    Unsubscribe or manage your mailing list subscription at:
    http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
Member
    Services
    Help Desk at info at arin.net if you experience any issues.












    Thanks,
    John Von Essen
    (800) 248-1736 ext 100
    john at quonix.net




  Thanks,
  John Von Essen
  (800) 248-1736 ext 100
  john at quonix.net



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/cffd25cc/attachment.htm>

From Ed.Lewis at neustar.biz  Tue Sep 11 18:22:55 2007
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Tue, 11 Sep 2007 18:22:55 -0400
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
Message-ID: <a0624080bc30cbf4800d0@[10.31.32.75]>

At 14:10 -0700 9/11/07, Owen DeLong wrote:

>8.	Rationale:
>		Recent PPML discussion has called attention to the
>		fact that lame DNS delegations are more an operational
>		issue than one of policy.  As such, the existing lame
>		delegation policy should be removed from the NRPM
>		to remove the resultant confusion.  This is not meant
>		to prevent ARIN staff from taking reasonable action
>		WRT DNS operational issues related to resources issued
>		by ARIN, but, such action can be covered by staff
>		operational guidelines and is not within the scope
>		of Address Policy.

Hmmmm. Mmmmmmmmm.

First I want to ask for a definition of the "scope of Address 
Policy."  I have a vague idea, I gather it refers to IPv4 address 
ranges, IPv6 address ranges, and Autonomous System number(s).  (It's 
that I don't think of AS numbers as addresses; I usually refer to the 
triad of parameters as IP numbering resources.  Okay, okay, splitting 
terminology hairs here, what I'm asking for is a pointer or statement 
about the scope.)

I may or may not agree that the lame delegation "policy" should be 
excluded from the NRPM.  I am unsure about that.

What I would be against is dropping any membership requirement on the 
staff to enforce clean health (lexically stretching "lameness") on 
the DNS systems operated by ARIN.  I think it is incumbent upon ARIN 
not to refer DNS traffic to servers which answer "incorrectly."

I could argue that (all?) IP address allocation policy is an 
operational consideration.  Poor address allocation policy would 
cause an undue burden on the routing system.  E.g., what if we only 
gave a (IPv6) /48 to LIRs each time the asked regardless of need and 
wound up with highly fragmented allocations?  I'm being silly here, 
to stress the point that I disagree that with the criteria of being 
an operational issue means removal from the NRPM.

Still, I am not necessarily against what is proposed here.  I'm just 
saying I have questions for now, but I don't want to see this lost.

I don't want sloppy servers.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.


From michael at rancid.berkeley.edu  Tue Sep 11 18:29:32 2007
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Tue, 11 Sep 2007 15:29:32 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
Message-ID: <46E716CC.6050900@rancid.berkeley.edu>

Owen DeLong wrote:

> 8.	Rationale:
> 		Recent PPML discussion has called attention to the
> 		fact that lame DNS delegations are more an operational
> 		issue than one of policy.  As such, the existing lame
> 		delegation policy should be removed from the NRPM
> 		to remove the resultant confusion.  This is not meant
> 		to prevent ARIN staff from taking reasonable action
> 		WRT DNS operational issues related to resources issued
> 		by ARIN, but, such action can be covered by staff
> 		operational guidelines and is not within the scope
> 		of Address Policy.

There are actually three issues in this discussion:

1. in-addr.arpa zones that are not populated with PTR records that match 
A records in forward zones.  There seems to be consensus that this is 
not under ARIN's purview.  As has already been pointed out is NOT the 
issue that the OP raised.

2. in-addr.arpa zones with lame delegations.  I define "lame delegation" 
here as a server that returns SERVFAIL, upward referral, REFUSED, or 
simply times out for queries in a particular zone.  The OP appeared to 
be concerned about the delays involved in the time-out issue, but as I 
mention below, there is a difference in my mind as to whether the lame 
delegation comes directly from ARIN or is the result of a further 
(re-)delegation within the ISP's DNS configuration.

2a. A subset of the lame delegation is what RFC 1912 states is "an even 
worse form of lame delegation," which is listing someone else's 
nameserver without their permission because a) that was the example in 
the book; b) you needed two nameservers and heck, this one seems to work 
for some other zone, and you really don't have time to contact the owner 
of that DNS server and set up the zone, but they won't mind; or c) some 
other reason too baroque for anyone clueful to even understand.

I had a case of 2a that went on for years, where a major financial 
services company selected ns{1,2}.berkeley.edu as in-addr.arpa 
nameservers for the /16 it had.  We had no relationship with this 
company and had never agreed to provide nameservice for their /16's 
in-addr.arpa.  But it was our nameservers that received the traffic, our 
logs that had numerous entries in it for the lame zone, and in some 
cases, *we* had to answer complaints that our name server were lame for 
this zone.

I contacted the POC for the /16.  No answer.  Contacted again.  No 
answer.  I contacted the ARIN hostmaster.  They told me to contact the 
POC.  I told them I had.  Contacted the POC and the ARIN hostmaster. 
This actually went on for years until, after the lame server policy was 
passed, I escalated the issue to someone fairly high in the organization 
and our records were removed from the /16 that wasn't ours and for which 
we had not agreed to provide in-addr.arpa service.

It occurred to me that before the lame delegation policy, there was 
really no way for the ARIN hostmaster to know what to do in a situation 
like 2a.  I am not sure how they dealt with it in the past, but I 
certainly had a hard time getting anything to happen until such a time 
as there was a guideline to deal with it.

In general, I do not think there is consensus in the PPML thread that 2 
and 2a are not within ARIN's purview, where the delegations come 
directly from ARIN.  As operators of the parent DNS zone in which this 
lame delegation was made, ARIN did have a role to play when the POC 
refused to respond to repeated requests over a period of years.

I think the policy regarding lame delegations that are made directly 
from ARIN (in whois and in the zones served by the ARIN.NET nameservers) 
is appropriate.  If people who receive delegations from ARIN either a) 
do not populate their zones with PTR records; or b) re-delegate within 
their zones (say a /16 with delegated zones representing /24-sized 
blocks) and some of those re-delegations are lame, then I agree that 
this is not under ARIN's purview.  (It is not clear to me from the OP 
whether the lame delegation comes from ARIN or whether it is a lame 
re-delegation from the ISP's nameservers, but it sounds like the 
latter.)  Since the policy only covers the former case, I do not believe 
it needs to be deprecated.

Moreover, as my experience shows, I believe that the policy needs to be 
explicitly stated in order to convince POCs that they need to take 
action, and to provide a written rationale, procedure, and escalation 
path where situations like 2a exist.  Staff operational guidelines would 
work, if they were appropriately publicized, but this did not appear to 
be the case before the lame delegation policy was in place.

I also have a hard time thinking about how an expanded policy would 
actually be within ARIN's purview, but without seeing such a policy, I 
can't really comment much more on that.

michael


From arin-contact at dirtside.com  Tue Sep 11 18:31:58 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Tue, 11 Sep 2007 18:31:58 -0400
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
Message-ID: <3c3e3fca0709111531u656b79fv8f9b1155b34a2402@mail.gmail.com>

On 9/11/07, Owen DeLong <owen at delong.com> wrote:
> 1.      Policy Proposal Name: Deprecate Lame Server Policy
> 7.      Policy statement:
>                 Delete section 7 from the NRPM

Owen,

Are you sure this is the right way to move on this? If we're going to
call ISPs "Local Internet Registries," shouldn't we expect them to
behave as internet registries and do the things that internet
registries do, including reallocation and assignment of the RDNS
attached to every IP address?

Regards,
Bill Herrin

-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From owen at delong.com  Tue Sep 11 18:39:45 2007
From: owen at delong.com (Owen DeLong)
Date: Tue, 11 Sep 2007 15:39:45 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <a0624080bc30cbf4800d0@[10.31.32.75]>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<a0624080bc30cbf4800d0@[10.31.32.75]>
Message-ID: <CD197A05-06DB-4AEE-A34A-6AE2AE0969E4@delong.com>


On Sep 11, 2007, at 3:22 PM, Edward Lewis wrote:

> At 14:10 -0700 9/11/07, Owen DeLong wrote:
>
>> 8.	Rationale:
>> 		Recent PPML discussion has called attention to the
>> 		fact that lame DNS delegations are more an operational
>> 		issue than one of policy.  As such, the existing lame
>> 		delegation policy should be removed from the NRPM
>> 		to remove the resultant confusion.  This is not meant
>> 		to prevent ARIN staff from taking reasonable action
>> 		WRT DNS operational issues related to resources issued
>> 		by ARIN, but, such action can be covered by staff
>> 		operational guidelines and is not within the scope
>> 		of Address Policy.
>
> Hmmmm. Mmmmmmmmm.
>
> First I want to ask for a definition of the "scope of Address  
> Policy."  I have a vague idea, I gather it refers to IPv4 address  
> ranges, IPv6 address ranges, and Autonomous System number(s).   
> (It's that I don't think of AS numbers as addresses; I usually  
> refer to the triad of parameters as IP numbering resources.  Okay,  
> okay, splitting terminology hairs here, what I'm asking for is a  
> pointer or statement about the scope.)
>
I suppose I should have said "Number Resource Policy".  I suppose  
there isn't really
much in the way of a pointer about scope that I can give you.   
However, it is my
opinion that the responsibility and scope of ARIN policy should be  
limited to
the assignment and delegation of number resources.  Operational  
concerns about
routing and DNS are, in my opinion outside of that scope and only  
serve to muddy
the waters of good number resource policy.

> I may or may not agree that the lame delegation "policy" should be  
> excluded from the NRPM.  I am unsure about that.
>
Understood.
> What I would be against is dropping any membership requirement on  
> the staff to enforce clean health (lexically stretching "lameness")  
> on the DNS systems operated by ARIN.  I think it is incumbent upon  
> ARIN not to refer DNS traffic to servers which answer "incorrectly."
>
I have no problem with that as a general procedure, but, that's a  
procedural
and operational question and not what I would consider to be number  
resource
policy.  Certainly such a consideration could go well through the  
ACSP and
I would even support such a suggestion.

> I could argue that (all?) IP address allocation policy is an  
> operational consideration.  Poor address allocation policy would  
> cause an undue burden on the routing system.  E.g., what if we only  
> gave a (IPv6) /48 to LIRs each time the asked regardless of need  
> and wound up with highly fragmented allocations?  I'm being silly  
> here, to stress the point that I disagree that with the criteria of  
> being an operational issue means removal from the NRPM.
>
Sure, but, not all operational considerations are IP address  
allocation policy.
Operational considerations are a superset of IP address allocation  
policy.
Actual operations, operational tactics, and operational requirements and
standards are not, however, number resource policy.

As to fragmented allocations, I'm not 100% convinced that's a bad thing.
While I agree that we should do what we can to reduce the degree to  
which
we fragment things in order to accommodate limitations of today's  
routing
system, I firmly believe that our rather high degree of success in  
doing so
has been one of the factors in our failure to develop a workable and
scalable routing system.

So... I don't advocate going out and fragmenting for the sake of  
fragmenting,
but, I do think that we should stop basing policy on concerns over  
routing
table growth, and, instead manage policy based on rational allocation
and assignment concerns.  ISPs who run routers should take the  
responsibility
for the operational concerns of routing table size.

> Still, I am not necessarily against what is proposed here.  I'm  
> just saying I have questions for now, but I don't want to see this  
> lost.
>
Yep... Understood.

> I don't want sloppy servers.
>
Neither do I, but, I am not convinced that it is ARINs place to  
attempt to
force or even pressure others to clean up their sloppy servers.

Owen



From randy at psg.com  Tue Sep 11 18:58:43 2007
From: randy at psg.com (Randy Bush)
Date: Tue, 11 Sep 2007 12:58:43 -1000
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <46E709A7.9060105@ca.afilias.info>
References: <NABBJOELMNGNJNGPKDDOEEINHDAA.tedm@ipinc.net>
	<46E709A7.9060105@ca.afilias.info>
Message-ID: <46E71DA3.40005@psg.com>

Brian Dickson wrote:
> Ted Mittelstaedt wrote:
procmail is your friend

arin delegates 42.666.in-addr.arpa to the member isp.  the servers
properly respond for that delegation.  this seems to be about as far as
current policy goes; though there are reported gaps in implementation.

the op wants us to say that, if the delegatee further delegates
sub-zones, then the service for those sub-zones must not be lame.

aside from issues of whether the community has the right to descend into
the delegation, how would we text the sub-delegations?  if they are on
byte boundaries, we can probe for them.  but goddesses help us if they
use rfc 2317.  and is it our prerogative to probe 256 sub-delegations of
a /16?  64k of a /8?  and how many of a /32 in ipv6 space?

randy



From michael at rancid.berkeley.edu  Tue Sep 11 19:06:09 2007
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Tue, 11 Sep 2007 16:06:09 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <CD197A05-06DB-4AEE-A34A-6AE2AE0969E4@delong.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>	<a0624080bc30cbf4800d0@[10.31.32.75]>
	<CD197A05-06DB-4AEE-A34A-6AE2AE0969E4@delong.com>
Message-ID: <46E71F61.9080500@rancid.berkeley.edu>

Owen DeLong wrote:

> I suppose I should have said "Number Resource Policy".  I suppose  
> there isn't really
> much in the way of a pointer about scope that I can give you.   
> However, it is my
> opinion that the responsibility and scope of ARIN policy should be  
> limited to
> the assignment and delegation of number resources.  Operational  
> concerns about
> routing and DNS are, in my opinion outside of that scope and only  
> serve to muddy
> the waters of good number resource policy.
[snip]
>> I don't want sloppy servers.
>>
> Neither do I, but, I am not convinced that it is ARINs place to  
> attempt to
> force or even pressure others to clean up their sloppy servers.

Okay, I see the point that it shouldn't be part of the NRPM, and I'd be 
willing to accept that if there were somehow able to be some explicit, 
public policy regarding lame delegations that come directly from ARIN.

Basically, there should be some way for ARIN staff to deal with 
inappropriate delegations where the POC is unresponsive, and that method 
should be public.

Thanks for the proposal.
michael


From marla.azinger at frontiercorp.com  Tue Sep 11 19:21:05 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Tue, 11 Sep 2007 19:21:05 -0400
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C9D6@nyrofcs2ke2k01.corp.pvt>

I would like to see a proposal that is along the lines of clarifying in addition to Owens proposal to just take it away.  Hopefully we havnt scared John off and he will give a wack at it.

Cheers!
Marla

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
William Herrin
Sent: Tuesday, September 11, 2007 3:32 PM
To: Owen DeLong
Cc: Public Policy Mailing List
Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy


On 9/11/07, Owen DeLong <owen at delong.com> wrote:
> 1.      Policy Proposal Name: Deprecate Lame Server Policy
> 7.      Policy statement:
>                 Delete section 7 from the NRPM

Owen,

Are you sure this is the right way to move on this? If we're going to
call ISPs "Local Internet Registries," shouldn't we expect them to
behave as internet registries and do the things that internet
registries do, including reallocation and assignment of the RDNS
attached to every IP address?

Regards,
Bill Herrin

-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.


From tedm at ipinc.net  Tue Sep 11 19:47:13 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 11 Sep 2007 16:47:13 -0700
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <46E709A7.9060105@ca.afilias.info>
Message-ID: <NABBJOELMNGNJNGPKDDOMEIOHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: Brian Dickson [mailto:briand at ca.afilias.info]
>Sent: Tuesday, September 11, 2007 2:33 PM
>To: Ted Mittelstaedt
>Cc: John Von Essen; Public Policy Mailing List
>Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy
>
>
>Ted Mittelstaedt wrote:
>> There have
>> been enough postings on
>> this topic for you to get an idea of what would happen to such a
>proposal -
>>
>There have been enough people commenting on their misinterpretation of
>John's observation (complaint),
>and the underlying technical issue, that the proposal would need to be
>very clearly written to avoid this.
>
>That said, the *actual* issue, if addressed, most certainly would be
>in-scope for RIR policies, and as such
>would be suitable for normal discussion, and likely would get support,
>enough to be adopted as policy.

Go for it, man.  I still don't think it will pass.  I have seen many
reasonable proposals get shot down already.  Such as ones requiring
legacy holders to return unused IPv4 addressing.

>>   Now I have read your ranting and some of the responses.  But
>there is one
>> response that I
>> didn't see and that you obviously didn't consider.  In my opinion, the
>> network manager at
>> your ISP is fully aware of the PTR issues and has chosen to
>DELIBERATELY not
>> entered
>> the in-addr.arpa zone for your numbers.
>>
>If that is what you think the issue is, then I think you misread the
>original message and several of the follow-ups.
>
>The issue isn't the *content* (present or absent) of the in-addr zone
>that has been delegated, it is that the server to which
>the delegation has been made, fails to answer queries for the *specific*
>in-addr zone. It is lame *for that zone*.
>

I understand that, no that wasn't the issue I was bringing up.   What I
was pointing out is John's original assumption insofar that he was taking
the ISPs excuses at face value.

>[discussion relevant only to non-lame zones with no PTRs in them,
>omitted for brevity.]
>> As for your GoDaddy scenario, well the application controls UDP timeout.
>The problem is fundamentally tied to resolvers. Unless the application
>is doing a roll-your-own implementation
>of name resolution, it is likely sharing a common fate with all clients
>of resolution service on whatever box is acting as a recursive resolver.
>
>Tweaking timeouts on nameserver lookups is something, to paraphrase
>Randy Bush, I encourage anyone foolish enough to want to, to do so.

I disagree the problem is tied to resolvers.  The original Godaddy scenario
is that if godaddy does a PTR query that fails that it ties up resources.
This is true - but the resources it ties up are -not- resolver or
network resources.  They are server resources.  If "everyone on the Internet
did this" then assuming Godaddy's mailservers started a process for each
incoming SMTP and waited around for 5 minutes for a response, you have 5
minutes that a very significant large memory consumptive SMTP process is
sitting in core ram waiting.  You get hundreds of these doing that and
for sure your going to seriously impact your SMTP receiver.  That is why
I said to fix that they can adjust their application timeout timers
for the SMTP application accepting the incoming mail.  Not to adjust
timeouts
in the resolver.

>From the resolvers POV it's going to get a PTR query for every incoming
mail anyway no matter if a in-addr.arpa exists or not.

Or perhaps there is some other aspect of the example I'm missing?

>> Take care!
>> Ted
>>
>If you were to "take care" yourself and read and understand what the
>original poster said, IMHO reasonably clearly and with all due emphasis,
>you would have been able to avoid making your misunderstanding so
>visible on a public mailing list. No offense intended.
>

None taken since I don't think you got the point of my response.  Since you
like things simple I'll summarize:

1) His proposal won't pass.
2) His ISP knows what they are not doing, and is being a lying jerk to him.
3) Even if his proposal does pass unless it has teeth it won't have
any value to compel a jerk ISP to stop being a jerk ISP.
4) If it has teeth it definitely won't pass since people don't support
proposals that have teeth.
5) The problem the proposal purports to solve can be worked around so
people will use that as yet another excuse to not support it.

It would be nice to be proved wrong and see the policy process actually
produce a policy that had some teeth and solved a problem.  God knows
it's failed miserably with the IPv4 pending runout problem.

Ted



From sleibrand at internap.com  Tue Sep 11 19:48:48 2007
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 11 Sep 2007 16:48:48 -0700
Subject: [ppml] Is this Lame or what?
In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A02A4C9D6@nyrofcs2ke2k01.corp.pvt>
References: <454810F09B5AA04E9D78D13A5C39028A02A4C9D6@nyrofcs2ke2k01.corp.pvt>
Message-ID: <46E72960.4030805@internap.com>

After doing some research (which I highly recommend everyone do before 
posting), I'm not sure any policy changes are needed to deal with the 
two specific cases raised so far.

ARIN's Lame Delegations page at 
http://www.arin.net/reference/lame_delegations.html states that "ARIN 
tests a reverse zone by requesting the SOA (Start of Authority) record 
from the name servers registered in WHOIS. ... Any other answer (or an 
inability to reach the nameserver due to a forward lookup failure) 
results in the delegation being deemed lame. If all of zones for a given 
name server of a specific network registration are lame, the delegation 
registration is deemed lame."

The way I read that, the fact that the authoritative servers for 
160.76.in-addr.arpa., 161.76.in-addr.arpa., and 64.114.208.in-addr.arpa. 
through 95.114.208.in-addr.arpa. do not respond to queries qualifies 
them as lame.  Under ARIN's own policy, that further means that "After 
30 consecutive days of lameness, ARIN notifies the points-of-contact of 
record via e-mail." and then if they get no response and it's not fixed, 
"After 90 consecutive days of lameness, ARIN strips the lame delegations 
from the WHOIS registration record and notifies the points-of-contact of 
record of the actions taken."

Can anyone from ARIN comment as to whether they share my interpretation 
that a non-responsive name server is deemed lame, and subject to removal 
under the procedure outlined above?

Thanks,
Scott

Azinger, Marla wrote:
> I would like to see a proposal that is along the lines of clarifying in addition to Owens proposal to just take it away.  Hopefully we havnt scared John off and he will give a wack at it.
>
> Cheers!
> Marla
>
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
> William Herrin
> Sent: Tuesday, September 11, 2007 3:32 PM
> To: Owen DeLong
> Cc: Public Policy Mailing List
> Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy
>
>
> On 9/11/07, Owen DeLong <owen at delong.com> wrote:
>   
>> 1.      Policy Proposal Name: Deprecate Lame Server Policy
>> 7.      Policy statement:
>>                 Delete section 7 from the NRPM
>>     
>
> Owen,
>
> Are you sure this is the right way to move on this? If we're going to
> call ISPs "Local Internet Registries," shouldn't we expect them to
> behave as internet registries and do the things that internet
> registries do, including reallocation and assignment of the RDNS
> attached to every IP address?
>
> Regards,
> Bill Herrin
>
>   


From john at quonix.net  Tue Sep 11 19:54:42 2007
From: john at quonix.net (John Von Essen)
Date: Tue, 11 Sep 2007 19:54:42 -0400
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A02A4C9D6@nyrofcs2ke2k01.corp.pvt>
References: <454810F09B5AA04E9D78D13A5C39028A02A4C9D6@nyrofcs2ke2k01.corp.pvt>
Message-ID: <24EB9466-293D-409F-A3BD-2A9FDAFABC5D@quonix.net>

I do plan to submit my proposal. My final comment on all of this is  
with regards to ARIN's stance on operational issues.

I agree ARIN should be careful, but keep in mind ARIN does provide an  
operational function of reverse DNS authority delegation. Because  
ARIN engages in this very-real activity, policy must exist to cover  
its implementation, design, and overall operational health.

If ARIN just did AS numbers and IP allocation, and another  
organization did reverse delegation, say Network Solutions, then YES  
- ARIN should not get involved with operational issues of reverse  
DNS. But that fact is ARIN does do reverse DNS delegation. When I do  
a dig on an IP, I see alot of ARIN servers in the output!

-John

On Sep 11, 2007, at 7:21 PM, Azinger, Marla wrote:

> I would like to see a proposal that is along the lines of  
> clarifying in addition to Owens proposal to just take it away.   
> Hopefully we havnt scared John off and he will give a wack at it.
>
> Cheers!
> Marla
>
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
> William Herrin
> Sent: Tuesday, September 11, 2007 3:32 PM
> To: Owen DeLong
> Cc: Public Policy Mailing List
> Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy
>
>
> On 9/11/07, Owen DeLong <owen at delong.com> wrote:
>> 1.      Policy Proposal Name: Deprecate Lame Server Policy
>> 7.      Policy statement:
>>                 Delete section 7 from the NRPM
>
> Owen,
>
> Are you sure this is the right way to move on this? If we're going to
> call ISPs "Local Internet Registries," shouldn't we expect them to
> behave as internet registries and do the things that internet
> registries do, including reallocation and assignment of the RDNS
> attached to every IP address?
>
> Regards,
> Bill Herrin
>
> -- 
> William D. Herrin                  herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr.                        Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/f1104cae/attachment.htm>

From marla.azinger at frontiercorp.com  Tue Sep 11 20:05:43 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Tue, 11 Sep 2007 20:05:43 -0400
Subject: [ppml] Is this Lame or what?
Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272FA13@nyrofcs2ke2k01.corp.pvt>

LOL.  I understand your point about research...but there is value in the postings.  Eventually it should progress toward clarification to all.  And I do believe from all the confusion the current written text has caused, that some clarification is needed.  Be it policy, definitions clarified or just staff process clarification publicly posted somewhere.  There is clearly some work to be done here in order to minimize confusion and/or resolve something that seems to be not fully baked.  And you might have also noticed how many different views surrounding the whole topic are out there...so the discussion in my view is good. Is daunting and does it add to more ppml to read? yes.  But...that is how we keep the process open and able to change if the community realizes later on down the road that they do or dont like what currently is written as policy or process.

Cheers!
Marla


-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Scott Leibrand
Sent: Tuesday, September 11, 2007 4:49 PM
To: Member Services
Cc: Public Policy Mailing List
Subject: [ppml] Is this Lame or what?


After doing some research (which I highly recommend everyone do before 
posting), I'm not sure any policy changes are needed to deal with the 
two specific cases raised so far.

ARIN's Lame Delegations page at 
http://www.arin.net/reference/lame_delegations.html states that "ARIN 
tests a reverse zone by requesting the SOA (Start of Authority) record 
from the name servers registered in WHOIS. ... Any other answer (or an 
inability to reach the nameserver due to a forward lookup failure) 
results in the delegation being deemed lame. If all of zones for a given 
name server of a specific network registration are lame, the delegation 
registration is deemed lame."

The way I read that, the fact that the authoritative servers for 
160.76.in-addr.arpa., 161.76.in-addr.arpa., and 64.114.208.in-addr.arpa. 
through 95.114.208.in-addr.arpa. do not respond to queries qualifies 
them as lame.  Under ARIN's own policy, that further means that "After 
30 consecutive days of lameness, ARIN notifies the points-of-contact of 
record via e-mail." and then if they get no response and it's not fixed, 
"After 90 consecutive days of lameness, ARIN strips the lame delegations 
from the WHOIS registration record and notifies the points-of-contact of 
record of the actions taken."

Can anyone from ARIN comment as to whether they share my interpretation 
that a non-responsive name server is deemed lame, and subject to removal 
under the procedure outlined above?

Thanks,
Scott

Azinger, Marla wrote:
> I would like to see a proposal that is along the lines of clarifying in addition to Owens proposal to just take it away.  Hopefully we havnt scared John off and he will give a wack at it.
>
> Cheers!
> Marla
>
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
> William Herrin
> Sent: Tuesday, September 11, 2007 3:32 PM
> To: Owen DeLong
> Cc: Public Policy Mailing List
> Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy
>
>
> On 9/11/07, Owen DeLong <owen at delong.com> wrote:
>   
>> 1.      Policy Proposal Name: Deprecate Lame Server Policy
>> 7.      Policy statement:
>>                 Delete section 7 from the NRPM
>>     
>
> Owen,
>
> Are you sure this is the right way to move on this? If we're going to
> call ISPs "Local Internet Registries," shouldn't we expect them to
> behave as internet registries and do the things that internet
> registries do, including reallocation and assignment of the RDNS
> attached to every IP address?
>
> Regards,
> Bill Herrin
>
>   
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.


From arin-contact at dirtside.com  Tue Sep 11 20:11:53 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Tue, 11 Sep 2007 20:11:53 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <46E71DA3.40005@psg.com>
References: <NABBJOELMNGNJNGPKDDOEEINHDAA.tedm@ipinc.net>
	<46E709A7.9060105@ca.afilias.info> <46E71DA3.40005@psg.com>
Message-ID: <3c3e3fca0709111711n3940aa58j5bec0584e1b13567@mail.gmail.com>

On 9/11/07, Randy Bush <randy at psg.com> wrote:
> aside from issues of whether the community has the right to descend into
> the delegation, how would we text the sub-delegations?  if they are on
> byte boundaries, we can probe for them.  but goddesses help us if they
> use rfc 2317.  and is it our prerogative to probe 256 sub-delegations of
> a /16?  64k of a /8?  and how many of a /32 in ipv6 space?

Randy,

That's the easy part: kick off action only after receiving a
complaint. Where no one minds, it doesn't matter and the complaint
will tell us exactly where to look.

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From john at quonix.net  Tue Sep 11 20:15:30 2007
From: john at quonix.net (John Von Essen)
Date: Tue, 11 Sep 2007 20:15:30 -0400
Subject: [ppml] Is this Lame or what?
In-Reply-To: <46E72960.4030805@internap.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4C9D6@nyrofcs2ke2k01.corp.pvt>
	<46E72960.4030805@internap.com>
Message-ID: <ABE34F09-5367-496E-A58E-F38552E281C6@quonix.net>

Scott,

That is a good point, and I had the very same question before  
posting. So I emailed the ARIN hostmaster for a clarification.

Hostmaster confirmed what you state below:

"Only if all of zones for a given name server of a specific network  
registration are lame, is the delegation registration deemed lame"

That is valid, correct, and should stay as-is.

Here is the problem. There is an ISP with a /22 network registration  
(4 /24's). Everything is delegated to a set of DNS servers. Those DNS  
servers correctly answer SOA request for 3 out of 4 of the /24 in- 
addr.arpa's. However, that last /24 was left out, and the ISPs DNS  
server does not answer on the SOA request, even though the ISP uses  
that /24.

So the question is, what do we do? Under current ARIN policy it  
sounds like the above scenario does not deem the ISP's /22 reverse  
dns delegation lame. Its only lame if all 4 /24's were lame, but in  
this case only one is lame. So nothing is done.

Problem is, this is a problem! If any /24 in-addr.arpa is lame, even  
though other /24's in the ISP's network registration are not, the ISP  
should still be considered "partially" lame, and should still be  
contacted by ARIN to remedy the situation.

And the overriding rationale for all of this is that the one lame /24  
is causing issues (like timeouts) for other people on the internet.

Its like sending 4 kids to school. 3 have their books and homework,  
and 1 has nothing. The 1 kid with nothing will cause issues for the  
teacher and the rest of the class. Now is it as bad as sending all 4  
kids to school if all 4 had no books or homework... No. But its still  
bad, and the parents should be called in for a teachers meeting due  
to their irresponsibility!

-John



On Sep 11, 2007, at 7:48 PM, Scott Leibrand wrote:

> After doing some research (which I highly recommend everyone do before
> posting), I'm not sure any policy changes are needed to deal with the
> two specific cases raised so far.
>
> ARIN's Lame Delegations page at
> http://www.arin.net/reference/lame_delegations.html states that "ARIN
> tests a reverse zone by requesting the SOA (Start of Authority) record
> from the name servers registered in WHOIS. ... Any other answer (or an
> inability to reach the nameserver due to a forward lookup failure)
> results in the delegation being deemed lame. If all of zones for a  
> given
> name server of a specific network registration are lame, the  
> delegation
> registration is deemed lame."
>
> The way I read that, the fact that the authoritative servers for
> 160.76.in-addr.arpa., 161.76.in-addr.arpa., and 64.114.208.in- 
> addr.arpa.
> through 95.114.208.in-addr.arpa. do not respond to queries qualifies
> them as lame.  Under ARIN's own policy, that further means that "After
> 30 consecutive days of lameness, ARIN notifies the points-of- 
> contact of
> record via e-mail." and then if they get no response and it's not  
> fixed,
> "After 90 consecutive days of lameness, ARIN strips the lame  
> delegations
> from the WHOIS registration record and notifies the points-of- 
> contact of
> record of the actions taken."
>
> Can anyone from ARIN comment as to whether they share my  
> interpretation
> that a non-responsive name server is deemed lame, and subject to  
> removal
> under the procedure outlined above?
>
> Thanks,
> Scott
>
> Azinger, Marla wrote:
>> I would like to see a proposal that is along the lines of  
>> clarifying in addition to Owens proposal to just take it away.   
>> Hopefully we havnt scared John off and he will give a wack at it.
>>
>> Cheers!
>> Marla
>>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On  
>> Behalf Of
>> William Herrin
>> Sent: Tuesday, September 11, 2007 3:32 PM
>> To: Owen DeLong
>> Cc: Public Policy Mailing List
>> Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy
>>
>>
>> On 9/11/07, Owen DeLong <owen at delong.com> wrote:
>>
>>> 1.      Policy Proposal Name: Deprecate Lame Server Policy
>>> 7.      Policy statement:
>>>                 Delete section 7 from the NRPM
>>>
>>
>> Owen,
>>
>> Are you sure this is the right way to move on this? If we're going to
>> call ISPs "Local Internet Registries," shouldn't we expect them to
>> behave as internet registries and do the things that internet
>> registries do, including reallocation and assignment of the RDNS
>> attached to every IP address?
>>
>> Regards,
>> Bill Herrin
>>
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net




From tedm at ipinc.net  Tue Sep 11 20:26:18 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 11 Sep 2007 17:26:18 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <24EB9466-293D-409F-A3BD-2A9FDAFABC5D@quonix.net>
Message-ID: <NABBJOELMNGNJNGPKDDOMEMGHDAA.tedm@ipinc.net>

Yes John you are correct but the way things often work on this list is
someone like Owen will
submit a policy to remove something that shouldn't obviously be removed, the
result of
which will convert a bunch of fence sitters into proponents of keeping it.

The list membership needs Owens "just kill it" proposal precisely to have
something to
vote down.  A no vote commits the person voting no, to supporting the
policy.

If Owens proposal is voted down, that will destroy all of the "it's not the
RIR's responsibility
to enforce sanctions against bad nameserver operators" arguments, and we can
move the discussion
to something productive of how to actually fix the problem.

Your proposal might be premature - you might find it better to campaign
against Owens
proposal first.

Ted
  -----Original Message-----
  From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
John Von Essen
  Sent: Tuesday, September 11, 2007 4:55 PM
  To: Public Policy Mailing List
  Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy


  I do plan to submit my proposal. My final comment on all of this is with
regards to ARIN's stance on operational issues.


  I agree ARIN should be careful, but keep in mind ARIN does provide an
operational function of reverse DNS authority delegation. Because ARIN
engages in this very-real activity, policy must exist to cover its
implementation, design, and overall operational health.


  If ARIN just did AS numbers and IP allocation, and another organization
did reverse delegation, say Network Solutions, then YES - ARIN should not
get involved with operational issues of reverse DNS. But that fact is ARIN
does do reverse DNS delegation. When I do a dig on an IP, I see alot of ARIN
servers in the output!


  -John


  On Sep 11, 2007, at 7:21 PM, Azinger, Marla wrote:


    I would like to see a proposal that is along the lines of clarifying in
addition to Owens proposal to just take it away. Hopefully we havnt scared
John off and he will give a wack at it.


    Cheers!
    Marla


    -----Original Message-----
    From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
    William Herrin
    Sent: Tuesday, September 11, 2007 3:32 PM
    To: Owen DeLong
    Cc: Public Policy Mailing List
    Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy




    On 9/11/07, Owen DeLong <owen at delong.com> wrote:
      1. Policy Proposal Name: Deprecate Lame Server Policy
      7. Policy statement:
      Delete section 7 from the NRPM


    Owen,


    Are you sure this is the right way to move on this? If we're going to
    call ISPs "Local Internet Registries," shouldn't we expect them to
    behave as internet registries and do the things that internet
    registries do, including reallocation and assignment of the RDNS
    attached to every IP address?


    Regards,
    Bill Herrin


    --
    William D. Herrin herrin at dirtside.com bill at herrin.us
    3005 Crane Dr. Web: <http://bill.herrin.us/>
    Falls Church, VA 22042-3004
    _______________________________________________
    PPML
    You are receiving this message because you are subscribed to the ARIN
Public Policy
    Mailing List (PPML at arin.net).
    Unsubscribe or manage your mailing list subscription at:
    http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
Member Services
    Help Desk at 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 (PPML at arin.net).
    Unsubscribe or manage your mailing list subscription at:
    http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
Member Services
    Help Desk at info at arin.net if you experience any issues.


  Thanks,
  John Von Essen
  (800) 248-1736 ext 100
  john at quonix.net



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/14399389/attachment.htm>

From info at arin.net  Tue Sep 11 20:29:29 2007
From: info at arin.net (Member Services)
Date: Tue, 11 Sep 2007 20:29:29 -0400
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
Message-ID: <46E732E9.5030108@arin.net>

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

The ARIN Advisory Council (AC) will review this proposal at their next
regularly scheduled meeting. The AC may decide to:

    1. Accept the proposal as a formal policy proposal as written. If the
AC accepts the proposal, it will be posted as a formal policy proposal
to PPML and it will be presented at a Public Policy Meeting.

    2. Postpone their decision regarding the proposal until the next
regularly scheduled AC meeting in order to work with the author. The AC
will work with the author to clarify, combine or divide the proposal. At
their following meeting the AC will accept or not accept the proposal.

    3. Not accept the proposal. If the AC does not accept the proposal,
the AC will explain their decision. If a proposal is not accepted, then
the author may elect to use the petition process to advance their
proposal. If the author elects not to petition or the  petition fails,
then the proposal will be closed.

The AC will assign shepherds in the near future. ARIN will provide the
names of the shepherds to the community via the PPML.

In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Owen DeLong wrote:
> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
> 
> 1.	Policy Proposal Name: Deprecate Lame Server Policy
> 2.	Author
> 	a.	name: Owen DeLong
> 	b.	email: owen at delong.com
> 	c.	telephone: 408-921-6984
> 	d.	organization: JITTR Networks
> 
> 3.	Proposal Version: 1.0
> 4.	Submission Date: 11 September, 2007
> 5.	Proposal type: delete
> 	new, modify, or delete.
> 6.	Policy term: permanent
> 	temporary, permanent, or renewable.
> 7.	Policy statement:
> 		Delete section 7 from the NRPM
> 
> 8.	Rationale:
> 		Recent PPML discussion has called attention to the
> 		fact that lame DNS delegations are more an operational
> 		issue than one of policy.  As such, the existing lame
> 		delegation policy should be removed from the NRPM
> 		to remove the resultant confusion.  This is not meant
> 		to prevent ARIN staff from taking reasonable action
> 		WRT DNS operational issues related to resources issued
> 		by ARIN, but, such action can be covered by staff
> 		operational guidelines and is not within the scope
> 		of Address Policy.
> 
> 9.	Timetable for implementation:
> 		1 June, 2008
> 10.	Meeting presenter:
> END OF TEMPLATE
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 



From randy at psg.com  Tue Sep 11 20:38:17 2007
From: randy at psg.com (Randy Bush)
Date: Tue, 11 Sep 2007 14:38:17 -1000
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <3c3e3fca0709111711n3940aa58j5bec0584e1b13567@mail.gmail.com>
References: <NABBJOELMNGNJNGPKDDOEEINHDAA.tedm@ipinc.net>	
	<46E709A7.9060105@ca.afilias.info> <46E71DA3.40005@psg.com>
	<3c3e3fca0709111711n3940aa58j5bec0584e1b13567@mail.gmail.com>
Message-ID: <46E734F9.6020809@psg.com>

>> aside from issues of whether the community has the right to descend into
>> the delegation, how would we text the sub-delegations?  if they are on
>> byte boundaries, we can probe for them.  but goddesses help us if they
>> use rfc 2317.  and is it our prerogative to probe 256 sub-delegations of
>> a /16?  64k of a /8?  and how many of a /32 in ipv6 space?
> That's the easy part: kick off action only after receiving a
> complaint. Where no one minds, it doesn't matter and the complaint
> will tell us exactly where to look.

problem is that, of a thousand users who get screwed, how many will know
they they are screwed, let alone how to diagnose?

randy


From randy at psg.com  Tue Sep 11 20:41:14 2007
From: randy at psg.com (Randy Bush)
Date: Tue, 11 Sep 2007 14:41:14 -1000
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <46E732E9.5030108@arin.net>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<46E732E9.5030108@arin.net>
Message-ID: <46E735AA.901@psg.com>

please reject this silliness.  we're trying to improve the net, not show
that we're <bleep>s.

randy


From tedm at ipinc.net  Tue Sep 11 20:51:31 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 11 Sep 2007 17:51:31 -0700
Subject: [ppml] Is this Lame or what?
In-Reply-To: <ABE34F09-5367-496E-A58E-F38552E281C6@quonix.net>
Message-ID: <NABBJOELMNGNJNGPKDDOCEMHHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>John Von Essen
>Sent: Tuesday, September 11, 2007 5:16 PM
>To: Public Policy Mailing List
>Subject: Re: [ppml] Is this Lame or what?
>
>
>Scott,
>
>That is a good point, and I had the very same question before  
>posting. So I emailed the ARIN hostmaster for a clarification.
>
>Hostmaster confirmed what you state below:
>
>"Only if all of zones for a given name server of a specific network  
>registration are lame, is the delegation registration deemed lame"
>
>That is valid, correct, and should stay as-is.
>
>Here is the problem. There is an ISP with a /22 network registration  
>(4 /24's). Everything is delegated to a set of DNS servers. Those DNS  
>servers correctly answer SOA request for 3 out of 4 of the /24 in- 
>addr.arpa's. However, that last /24 was left out, and the ISPs DNS  
>server does not answer on the SOA request, even though the ISP uses  
>that /24.
>
>So the question is, what do we do? Under current ARIN policy it  
>sounds like the above scenario does not deem the ISP's /22 reverse  
>dns delegation lame. Its only lame if all 4 /24's were lame, but in  
>this case only one is lame. So nothing is done.
>
>Problem is, this is a problem! If any /24 in-addr.arpa is lame, even  
>though other /24's in the ISP's network registration are not, the ISP  
>should still be considered "partially" lame, and should still be  
>contacted by ARIN to remedy the situation.
>

John I disagree - the ISP should only be contacted by ARIN after an
attempt is made to contact the ISP by the complaintant and the ISP
has proven nonresponsive.

>And the overriding rationale for all of this is that the one lame /24  
>is causing issues (like timeouts) for other people on the internet.
>
>Its like sending 4 kids to school. 3 have their books and homework,  
>and 1 has nothing. The 1 kid with nothing will cause issues for the  
>teacher and the rest of the class. Now is it as bad as sending all 4  
>kids to school if all 4 had no books or homework... No. But its still  
>bad, and the parents should be called in for a teachers meeting due  
>to their irresponsibility!
>

No this isn't an exact analogy because the privacy laws basically
prevent other parents from contacting the parent of the kid without his
homework (since the teachers are prohibited from discussing the
kid with other parents) so the school has to be the one to call the
bad parent.

Ted


From tedm at ipinc.net  Tue Sep 11 20:59:31 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 11 Sep 2007 17:59:31 -0700
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <46E734F9.6020809@psg.com>
Message-ID: <NABBJOELMNGNJNGPKDDOGEMHHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Randy Bush
>Sent: Tuesday, September 11, 2007 5:38 PM
>To: William Herrin
>Cc: Public Policy Mailing List
>Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy
>
>
>>> aside from issues of whether the community has the right to descend into
>>> the delegation, how would we text the sub-delegations?  if they are on
>>> byte boundaries, we can probe for them.  but goddesses help us if they
>>> use rfc 2317.  and is it our prerogative to probe 256 sub-delegations of
>>> a /16?  64k of a /8?  and how many of a /32 in ipv6 space?
>> That's the easy part: kick off action only after receiving a
>> complaint. Where no one minds, it doesn't matter and the complaint
>> will tell us exactly where to look.
>
>problem is that, of a thousand users who get screwed, how many will know
>they they are screwed, let alone how to diagnose?
>

There was a big tide one day and on the beach a thousand starfish were
washed up, and lay dying in the hot sun.

A boy walked along the beach picking up starfish and throwing them
back into the water one by one.

A man told the boy: "Give up, there is no way you can save all these
starfish, what you are doing does not matter"

The boy answered:  "It matters to the starfish I threw back"

If even 1 of the thousand screwed users is clueful enough to
use the policy to fix their problem, the policy has done it's
work.

Ted



From kmedcalf at dessus.com  Tue Sep 11 21:09:39 2007
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Tue, 11 Sep 2007 21:09:39 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <81245675-0736-467F-9EF2-A20A0FC0E904@quonix.net>
Message-ID: <e5f3cc6c0abcda4c846c67eaa66e3d9b@mail.dessus.com>


> Identical issues to what I am experiencing. If people look 
> deeply enough, I am confident there are many Org's who 
> operate AS's with no in-addr.arpa SOA on there DNS servers.

You remember that once upon a time in a land far far away the lack of functioning in-addr.arpa. DNS would act to actually prohibit those addresses for being useful for anything other than crawling the dirtpath though CIX and accessing advertizing gophers and the "Commercial internet".

As I recall when I signed the AUP for NSFNet access and transit, working DNS closure was a requirement for access to almost any resource subject those and similar AUP's in common use at that time.

Then along came the clueless johhny-come-lately ISPs (mostly telco's and cableco's) and people stopped checking in-addr.arpa DNS because the sheer volume of the clueless created massive operational issues.

For example, even merit's ftp servers (and uu's also) *required* not only non-lame in-addr.arpa delegations, but also closure of the forward and reverse mapping.

After a while (measured in years) many of the telco/cableco's managed to *buy* a clue.  Many even have proper closure of the forward and reverse zones.

Despite this fact many more recent arrivals (some of them really really big software companies, like Microsoft) still haven't managed to either find or buy a clue.  Perhaps because the clue-store is sold out or all clues are on back-order :)

There is a reason why in-addr.arpa and forward DNS closure is a good thing:  often the operators of each DNS zone are different (or at least those in control of the delegations are different) and therefore proper closure demonstrates that the end-ip is authorized to operate by both the "network" (in-addr.arpa) operator *and* the forward "domain" operator.

If attempting resolution though both domains does not result in closure it is reasonable to assume that the ip/netblock in question is not "authentic" -- and thus any service requiring bare minimum of authenticity verification shoulod be denied to those unable to demonstrate such closure.






From sleibrand at internap.com  Tue Sep 11 21:23:30 2007
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 11 Sep 2007 18:23:30 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <46E732E9.5030108@arin.net>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<46E732E9.5030108@arin.net>
Message-ID: <46E73F92.8080101@internap.com>

I oppose this policy proposal.  I believe that the current policy 
(section 7) defines reasonable policy guidelines for ARIN staff, and 
does not micro-manage operational details.  The fact that ARIN took the 
single paragraph of section 7.2 and expanded it into an entire page of 
procedure for dealing with lame delegations gives me confidence that 
we're striking the right balance here.

It may be worthwhile to use the ACSP to suggest improvements to ARIN's 
lame delegation procedure, and may even be appropriate to refine lame 
delegation policy to require delegated servers to answer authoritatively 
for all delegated subdomains covering an allocation.  However, I don't 
think it's appropriate to remove section 7.

-Scott

Member Services wrote:
> ARIN received the following policy proposal. In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
> ARIN's website.
>
> The ARIN Advisory Council (AC) will review this proposal at their next
> regularly scheduled meeting. The AC may decide to:
>
>     1. Accept the proposal as a formal policy proposal as written. If the
> AC accepts the proposal, it will be posted as a formal policy proposal
> to PPML and it will be presented at a Public Policy Meeting.
>
>     2. Postpone their decision regarding the proposal until the next
> regularly scheduled AC meeting in order to work with the author. The AC
> will work with the author to clarify, combine or divide the proposal. At
> their following meeting the AC will accept or not accept the proposal.
>
>     3. Not accept the proposal. If the AC does not accept the proposal,
> the AC will explain their decision. If a proposal is not accepted, then
> the author may elect to use the petition process to advance their
> proposal. If the author elects not to petition or the  petition fails,
> then the proposal will be closed.
>
> The AC will assign shepherds in the near future. ARIN will provide the
> names of the shepherds to the community via the PPML.
>
> In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
>
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Owen DeLong wrote:
>   
>> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
>>
>> 1.	Policy Proposal Name: Deprecate Lame Server Policy
>> 2.	Author
>> 	a.	name: Owen DeLong
>> 	b.	email: owen at delong.com
>> 	c.	telephone: 408-921-6984
>> 	d.	organization: JITTR Networks
>>
>> 3.	Proposal Version: 1.0
>> 4.	Submission Date: 11 September, 2007
>> 5.	Proposal type: delete
>> 	new, modify, or delete.
>> 6.	Policy term: permanent
>> 	temporary, permanent, or renewable.
>> 7.	Policy statement:
>> 		Delete section 7 from the NRPM
>>
>> 8.	Rationale:
>> 		Recent PPML discussion has called attention to the
>> 		fact that lame DNS delegations are more an operational
>> 		issue than one of policy.  As such, the existing lame
>> 		delegation policy should be removed from the NRPM
>> 		to remove the resultant confusion.  This is not meant
>> 		to prevent ARIN staff from taking reasonable action
>> 		WRT DNS operational issues related to resources issued
>> 		by ARIN, but, such action can be covered by staff
>> 		operational guidelines and is not within the scope
>> 		of Address Policy.
>>
>> 9.	Timetable for implementation:
>> 		1 June, 2008
>> 10.	Meeting presenter:
>> END OF TEMPLATE
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
>> Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>   


From jlewis at lewis.org  Tue Sep 11 21:26:39 2007
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 11 Sep 2007 21:26:39 -0400 (EDT)
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <995886AB-001D-4C91-A787-4572BFB0ED1E@quonix.net>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA0D@nyrofcs2ke2k01.corp.pvt>
	<46E61408.5000100@psg.com>
	<091ECDC1-0112-4FCC-9F2B-E50E0D04158C@quonix.net>
	<7989754C-C7A0-4E4B-8095-A4FE8E785F89@delong.com>
	<995886AB-001D-4C91-A787-4572BFB0ED1E@quonix.net>
Message-ID: <Pine.LNX.4.61.0709112018460.24441@soloth.lewis.org>

On Tue, 11 Sep 2007, John Von Essen wrote:

> Now consider this...
>
> # nslookup 76.161.191.192
> ;; connection timed out; no servers could be reached
>
> And the above took about 20 seconds to return. The AS who advertises 
> 76.161.192.0/24 (and many other /24's) does not have the 
> 192.161.76.in-addr.arpa zone configured at all on their DNS server. This is a 
> problem for the user of that IP, and any person on the internet that has to 
> talk to that IP since it will create a burdensome dns timeouts.
>
> I'm sorry, but that second example is simply unacceptable. This may sound 
> rude, but the amount of money ARIN brings in for ASN registrations, 
> membership, and IP range allocations - the buck has to stop with ARIN when it 
> comes to AS's who completely misconfigure massive in-addr.arpa zones and 
> potentially create the environment to slow down dns traffic throughout the 
> internet.

ARIN hands out IP space and ASNs.  Other than some general rules as to 
what ARIN members can do with their IP space, ARIN doesn't tell them how 
to run their networks.

Annoying as it may be, if you don't like the way your ISP runs _their_ 
network, you have two choices.

1) Leave.
2) Buy them and run the network your way.

If you want ARIN to start imposing rules on how members do things, make it 
something useful and have ARIN forbid BGP deaggregation of allocated / 
assigned CIDRs into subnets having the same as-path.

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


From john at quonix.net  Tue Sep 11 21:35:02 2007
From: john at quonix.net (John Von Essen)
Date: Tue, 11 Sep 2007 21:35:02 -0400
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
Message-ID: <353F859A-78CA-4886-8B29-33D428224158@quonix.net>

Its goes without saying, but I guess I should officially make my  
opinion known now that it is under review.

I do not agree with this policy proposal. It would be a major step  
backwards.

-John

On Sep 11, 2007, at 5:10 PM, Owen DeLong wrote:

> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
>
> 1.	Policy Proposal Name: Deprecate Lame Server Policy
> 2.	Author
> 	a.	name: Owen DeLong
> 	b.	email: owen at delong.com
> 	c.	telephone: 408-921-6984
> 	d.	organization: JITTR Networks
>
> 3.	Proposal Version: 1.0
> 4.	Submission Date: 11 September, 2007
> 5.	Proposal type: delete
> 	new, modify, or delete.
> 6.	Policy term: permanent
> 	temporary, permanent, or renewable.
> 7.	Policy statement:
> 		Delete section 7 from the NRPM
>
> 8.	Rationale:
> 		Recent PPML discussion has called attention to the
> 		fact that lame DNS delegations are more an operational
> 		issue than one of policy.  As such, the existing lame
> 		delegation policy should be removed from the NRPM
> 		to remove the resultant confusion.  This is not meant
> 		to prevent ARIN staff from taking reasonable action
> 		WRT DNS operational issues related to resources issued
> 		by ARIN, but, such action can be covered by staff
> 		operational guidelines and is not within the scope
> 		of Address Policy.
>
> 9.	Timetable for implementation:
> 		1 June, 2008
> 10.	Meeting presenter:
> END OF TEMPLATE
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/03a2634c/attachment.htm>

From mac at pt.com  Tue Sep 11 22:36:16 2007
From: mac at pt.com (Mark A Conrad)
Date: Tue, 11 Sep 2007 22:36:16 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <mailman.7003.1189560907.29428.ppml@arin.net>
Message-ID: <OFC48E07D1.1A6C2368-ON85257354.000DFAC3-85257354.000E4E73@pt.com>

>Annoying as it may be, if you don't like the way your ISP runs _their_ 
>network, you have two choices.
>
>1) Leave.
>2) Buy them and run the network your way.

But I don't like how someone else's ISP is running _their_ network, 
because it's affecting _my_ network by causing timeouts due to missing 
reverse DNS servers.  That is exactly the kind of thing that ARIN policy 
should prevent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/b9a32645/attachment.htm>

From bicknell at ufp.org  Tue Sep 11 22:52:32 2007
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 11 Sep 2007 22:52:32 -0400
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
Message-ID: <20070912025232.GA76366@ussenterprise.ufp.org>

In a message written on Tue, Sep 11, 2007 at 02:10:09PM -0700, Owen DeLong wrote:
> 8.	Rationale:
> 		Recent PPML discussion has called attention to the
> 		fact that lame DNS delegations are more an operational
> 		issue than one of policy.  As such, the existing lame
> 		delegation policy should be removed from the NRPM
> 		to remove the resultant confusion.  This is not meant
> 		to prevent ARIN staff from taking reasonable action
> 		WRT DNS operational issues related to resources issued
> 		by ARIN, but, such action can be covered by staff
> 		operational guidelines and is not within the scope
> 		of Address Policy.

With several recent issues staff has indicated a reluctance to take
action if items were not spelled out in the NRPM.  There is at least
one proposal for the next meeting aimed at giving staff more clarity
in the NRPM so they have backing to take action.

As such I could not support this unless staff issued a strong
statement that they would still feel empowered to take on lame
servers if this policy were to pass, and section 7 were to be
removed.  I am afraid passing this proposal would leave them unwilling
to take any action.

I do think there's a deeper issue here, but for now I'm going to 
just look at the can of worms and not open it.

-- 
       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/20070911/69130e2d/attachment.sig>

From owen at delong.com  Tue Sep 11 23:51:43 2007
From: owen at delong.com (Owen DeLong)
Date: Tue, 11 Sep 2007 20:51:43 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <NABBJOELMNGNJNGPKDDOMEMGHDAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOMEMGHDAA.tedm@ipinc.net>
Message-ID: <288AEB42-E021-4582-82F6-D4FD924EA551@delong.com>

Ted,
	I believe you miss the point of my proposal.  While I do believe that
ARIN has a role to play in applying the clue bat to lame or partially  
lame
ISPs and addressing John's issue, my point is that it belongs in  
operational
guidelines to ARIN staff and not in the NRPM.

	My proposal talks about what I think belongs in the NRPM and is
not a direct expression of how I feel about what ARIN staff should or
should not be doing with respect to this particular issue.  I would  
fully
support an ACSP recommendation that ARIN address all IN-ADDR
lameness whether complete or not on any direct assignment.  This will
potentially require ARIN to examine as many as 255 zones in IPv4 for
a single assignment.

	I would oppose any suggestion requiring ARIN to drill down
to lame delegations made by the ISPs relating to reassignment or
reallocations made by the ISP because of dramatically increasing
workload for dramatically decreasing return on investment and
because there is a limit to the extent to which I believe ARIN should
engage in telling operators how to run their network (let alone their
customers' networks).

	I will also oppose any policy regarding the operational and/or
implementation details of lame delegations because I firmly believe
this is not the role of the NRPM and should be addressed with
operational procedures and recommendations rather than with
number resource policies.

Owen

On Sep 11, 2007, at 5:26 PM, Ted Mittelstaedt wrote:

> Yes John you are correct but the way things often work on this list  
> is someone like Owen will
> submit a policy to remove something that shouldn't obviously be  
> removed, the result of
> which will convert a bunch of fence sitters into proponents of  
> keeping it.
>
> The list membership needs Owens "just kill it" proposal precisely  
> to have something to
> vote down.  A no vote commits the person voting no, to supporting  
> the policy.
>
> If Owens proposal is voted down, that will destroy all of the "it's  
> not the RIR's responsibility
> to enforce sanctions against bad nameserver operators" arguments,  
> and we can move the discussion
> to something productive of how to actually fix the problem.
>
> Your proposal might be premature - you might find it better to  
> campaign against Owens
> proposal first.
>
> Ted
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf  
> Of John Von Essen
> Sent: Tuesday, September 11, 2007 4:55 PM
> To: Public Policy Mailing List
> Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy
>
> I do plan to submit my proposal. My final comment on all of this is  
> with regards to ARIN's stance on operational issues.
>
> I agree ARIN should be careful, but keep in mind ARIN does provide  
> an operational function of reverse DNS authority delegation.  
> Because ARIN engages in this very-real activity, policy must exist  
> to cover its implementation, design, and overall operational health.
>
> If ARIN just did AS numbers and IP allocation, and another  
> organization did reverse delegation, say Network Solutions, then  
> YES - ARIN should not get involved with operational issues of  
> reverse DNS. But that fact is ARIN does do reverse DNS delegation.  
> When I do a dig on an IP, I see alot of ARIN servers in the output!
>
> -John
>
> On Sep 11, 2007, at 7:21 PM, Azinger, Marla wrote:
>
>> I would like to see a proposal that is along the lines of  
>> clarifying in addition to Owens proposal to just take it away.  
>> Hopefully we havnt scared John off and he will give a wack at it.
>>
>> Cheers!
>> Marla
>>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On  
>> Behalf Of
>> William Herrin
>> Sent: Tuesday, September 11, 2007 3:32 PM
>> To: Owen DeLong
>> Cc: Public Policy Mailing List
>> Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy
>>
>>
>> On 9/11/07, Owen DeLong <owen at delong.com> wrote:
>>> 1. Policy Proposal Name: Deprecate Lame Server Policy
>>> 7. Policy statement:
>>> Delete section 7 from the NRPM
>>
>> Owen,
>>
>> Are you sure this is the right way to move on this? If we're going to
>> call ISPs "Local Internet Registries," shouldn't we expect them to
>> behave as internet registries and do the things that internet
>> registries do, including reallocation and assignment of the RDNS
>> attached to every IP address?
>>
>> Regards,
>> Bill Herrin
>>
>> --
>> William D. Herrin herrin at dirtside.com bill at herrin.us
>> 3005 Crane Dr. Web: <http://bill.herrin.us/>
>> Falls Church, VA 22042-3004
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the  
>> ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the  
>> ARIN Member Services
>> Help Desk at 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 (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the  
>> ARIN Member Services
>> Help Desk at info at arin.net if you experience any issues.
>
> Thanks,
> John Von Essen
> (800) 248-1736 ext 100
> john at quonix.net
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/8cc7c879/attachment.htm>

From christopher.morrow at gmail.com  Wed Sep 12 00:18:29 2007
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Wed, 12 Sep 2007 00:18:29 -0400
Subject: [ppml] IPv6 flawed?
In-Reply-To: <BE3F6B0D-AE14-487C-8A65-EB9D06164484@virtualized.org>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com>
	<D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
	<11A63A70-EFD7-49CD-9DCB-78F81B1FB2BC@muada.com>
	<7EF0D548-D8E5-4DC2-A956-21657A8B96F3@delong.com>
	<60037.74.122.168.81.1188929633.squirrel@look.libertyrms.com>
	<AF699AB3-F131-4174-B881-F602A5D93140@virtualized.org>
	<6724492E-7A08-4B58-827F-96CDB5A9D23F@muada.com>
	<BE3F6B0D-AE14-487C-8A65-EB9D06164484@virtualized.org>
Message-ID: <75cb24520709112118p5dd6fad6g636449b7e0eccd3a@mail.gmail.com>

On 9/10/07, David Conrad <drc at virtualized.org> wrote:

> Interestingly, if you look at the ratio of ASes that are announcing a
> single prefix to all ASes, it has consistently gone up (from 27% in
> 1999 to 42% today).
>
> I suspect both of these are causes for worry.  The first is likely
> driven primarily by people breaking up aggregates for good or bad
> reasons.  The second is likely due to multihoming.  Fortunately, the
> growth isn't that great right now.  The big question is how these
> trends will change in the future.

I think, as a few presentations vaf or jason or I have given, that
this trend of more multihoming by customers (many with a single
prefix) is increasing ,  and will continue for the next while to
increase. The drivers we see are regulatory in nature (SOX, GLB, etc).

>
> >> Since IPv6 uses the same
> >> routing and traffic engineering technology as IPv4, I am curious what
> >> constraints could be put in place to keep PI space down to about 1
> >> per ASN.
> >
> > Prefixes per AS aren't limited by routing technology (if only it
> > could...) so this is irrelevant.
>
> Yet you go ahead and address this irrelevancy:
>
> > in IPv6, you'll be either getting a /32 or a /48 as a PI block. So
> > unless you manage to get multiple PI blocks, any efforts to inject
> > more than a single prefix will easily be thwarted by prefix length
> > filters.
>
> Of course, this assumes people will implement and maintain prefix
> length filters.  I'm told by some in the ISP business that the
> economic pressure to remove such filters is sufficiently high that
> they don't believe prefix length filters are viable in the long term
> (I'm paraphrasing a bit).

There will be competing pressures inside each SP, to be sure. Some
will 'lose', some will 'win'. It will likely get very ugly for a time.


From david.kessens at nsn.com  Wed Sep 12 00:29:07 2007
From: david.kessens at nsn.com (David Kessens)
Date: Tue, 11 Sep 2007 21:29:07 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <20070912025232.GA76366@ussenterprise.ufp.org>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<20070912025232.GA76366@ussenterprise.ufp.org>
Message-ID: <20070912042907.GD2901@nsn.com>


Leo,

On Tue, Sep 11, 2007 at 10:52:32PM -0400, Leo Bicknell wrote:
> 
> With several recent issues staff has indicated a reluctance to take
> action if items were not spelled out in the NRPM.  There is at least
> one proposal for the next meeting aimed at giving staff more clarity
> in the NRPM so they have backing to take action.

This is not something you can fix by means of spelling out more and
more operational details in policies. In fact, this would make the
problem worse.

David Kessens
---


From mysidia at gmail.com  Wed Sep 12 02:26:29 2007
From: mysidia at gmail.com (James Hess)
Date: Wed, 12 Sep 2007 01:26:29 -0500
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
Message-ID: <6eb799ab0709112326h528aa57by9e143283dd158c77@mail.gmail.com>

On 9/11/07, Owen DeLong <owen at delong.com> wrote:
> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
>
> 1.      Policy Proposal Name: Deprecate Lame Server Policy

I oppose the proposed deprecation of NRPM section 7. It is important
for policy to assure ISPs have the responsibility to maintain the IN-ADDR
domain records, and to say when ARIN can maintain records through SWIP,
section 7.1 does this.

Removing section 7.1 may cast some doubt as to who is responsible for what.


I would say it is best that ARIN identify servers that are
entirely lame for an allocation; this is trivial to do, since very few DNS
queries are required of each listed reverse DNS server, at the time it
is added, to
verify it is not lame for the allocation.


If a DNS server is truly lame, then either the DNS server does not exist
any longer -- the WHOIS record is wrong, but that's not too bad.

What's worse is if the lame delegation is pointing to someone else's DNS server
who no longer has an agreement to provide DNS records / further delegations for
the reverse zone.


I oppose expanding the policy just about the same as removing it.


Even in the everyday non-lame situation, the reverse IN-ADDR for the whole
allocation is not necessarily always mapped --  some number of blocks of
addresses allocated to an organization may not actually yet have  been assigned
to hosts or networks.

The ultimate destination for reverse DNS requests might not yet
be online (when addresses haven't been assigned yet, especially if
a subdelegated rDNS server will be in the new network, which is
not yet online), or PTR records may not  yet exist for hosts that do
not yet exist, but will eventually -- the whole PA block being
advertised doesn't necessarily mean that every possible IP
address already corresponds to a subnet that is already live
and has been named.


Eliminating lame servers has little to do with preventing the
possibility of slow lookups (awaiting timeout) and user protocols
relying excessively on  Reverse DNS.

Though it can have positive effects there as well as reducing UDP packets,
and these are good effects.


rDNS is for logging and diagnostic purposes.. any protocol relying on it for
anything else already has to be prepared for the possibility that third-party
untrusted DNS servers are misconfigured.

ARIN delegation is no indication that a DNS server is "trustworthy,"
"fast," or "stable".

Forward DNS servers are often slow, lame, or unresponsive too, and some
protocols will take the result of the "reverse DNS map" and attempt a forward
lookup.

Slow reverse lookups, non-existent reverse mappings happen all the time, are
a fact of life, and have to be anticipated, by any robust service --
the responsiveness of third-party DNS servers is not to be trusted.


Slow lookups already often occur, if for some reason   rDNS servers run slowly,
or all of a large ISP's reverse DNS servers happen to be down simultaneously;
this may degrade performance of certain protocols, but robust protocols should
be sufficiently independent of DNS to continue to function.

An outage or slow responsiveness from a DNS server can happen without a
lame delegation situation actually existing.


ARIN's mission isn't to fix slow lookups, or fix problems in the design of
protocols, it's to be a good steward of addresses  -- The delegation of the
request is also  the delegation of the responsibility for the request, once
the delegation is made, the ISPs are responsible for the quality of the
actual data and the responsiveness of their servers.


But I feel it actually is ARIN's responsibility to do their part to
fix the situation,
if the delegation  is being made to third-party hosts that do not consent
to serve DNS for that allocation, good stewardship of the address space, would
dictate wiping out the bogus records on ARIN's rDNS servers.


As for slow lookups, ISPs not fleshing out a full reverse zone, there
are ways  other than ARIN policy to deal with it: like making
a note to the points of contact requesting their attention.


Reverse lookups can generally be turned off on the server side,
especially for Telnet/SSH.


Failing that, caching/manually entering the fact that no response was
received, use of
local /etc/hosts, etc, or blocking access to service from ranges of IPs without
proper reverse, are possibilities.

These last two are of course, suboptimal compared to ISP fixing their
rDNS services.

--
-J


From michael.dillon at bt.com  Wed Sep 12 03:50:44 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 12 Sep 2007 08:50:44 +0100
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <a0624080bc30cbf4800d0@[10.31.32.75]>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<a0624080bc30cbf4800d0@[10.31.32.75]>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00102FB8B@E03MVC4-UKBR.domain1.systemhost.net>

> First I want to ask for a definition of the "scope of Address 
> Policy."

You are asking the wrong person. It is not Owen's definition which
matters, or mine. ARIN is a corporation and therefore it can only act in
accord with its charter and bylaws. Both of these are available to read
here:
http://www.arin.net/reference/index.html

> What I would be against is dropping any membership 
> requirement on the staff to enforce clean health (lexically 
> stretching "lameness") on the DNS systems operated by ARIN.  
> I think it is incumbent upon ARIN not to refer DNS traffic to 
> servers which answer "incorrectly."

Lexical stretching really is not allowed when interpreting policy.

And we have time and time again, pointed out that not all things done by
ARIN are driven by policy. Many things are done by order of the Board of
Trustees who can and do respond to suggestions. We even have an official
suggestion process here: http://www.arin.net/acsp/index.html
It says, among other things, that "The President will evaluate the
proposal, and will within ten (10) business days provide a response to
the submitter.".

--Michael Dillon


From Ed.Lewis at neustar.biz  Wed Sep 12 08:05:03 2007
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Wed, 12 Sep 2007 08:05:03 -0400
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <CD197A05-06DB-4AEE-A34A-6AE2AE0969E4@delong.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<a0624080bc30cbf4800d0@[10.31.32.75]>
	<CD197A05-06DB-4AEE-A34A-6AE2AE0969E4@delong.com>
Message-ID: <a06240800c30d839f8f9c@[10.31.32.75]>

At 15:39 -0700 9/11/07, Owen DeLong wrote:
>Operational concerns about routing and DNS are, in my opinion outside
>of that scope and only serve to muddy the waters of good number
>resource policy.

I've decided that I'm against the proposal because it is a 
bureaucratic step to fix a bureaucratic issue in response to a report 
of an operational issue.  I think operational issues trump 
bureaucratic issues.

The premise of the proposal is sound, there's no argument from me 
that, considered in a vacuum, the proposal cleans up a messy issue in 
the NRPM.  In 2005 I used the existence of 2002-1 and 2003-5 as 
examples why there was a need to have a mechanism to provide 
operational input to ARIN.

However I think trying to make sure we have a clean running process 
for policies is not as important as making sure the Internet benefits 
(operationally) by ARIN's presence.  I'd support a movement of the 
lame delegation directions in to some formal, stable and binding ARIN 
document from where they now reside.  But I won't support removing 
the home they have now until there is a new place for the lame 
delegation directions that membership achieved consensus on in 
response to the operational issue caused.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.


From bicknell at ufp.org  Wed Sep 12 09:34:22 2007
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 12 Sep 2007 09:34:22 -0400
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <20070912042907.GD2901@nsn.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<20070912025232.GA76366@ussenterprise.ufp.org>
	<20070912042907.GD2901@nsn.com>
Message-ID: <20070912133422.GA23451@ussenterprise.ufp.org>

In a message written on Tue, Sep 11, 2007 at 09:29:07PM -0700, David Kessens wrote:
> On Tue, Sep 11, 2007 at 10:52:32PM -0400, Leo Bicknell wrote:
> > With several recent issues staff has indicated a reluctance to take
> > action if items were not spelled out in the NRPM.  There is at least
> > one proposal for the next meeting aimed at giving staff more clarity
> > in the NRPM so they have backing to take action.
> 
> This is not something you can fix by means of spelling out more and
> more operational details in policies. In fact, this would make the
> problem worse.

You misunderstood my statement.

I don't want to add operational details to the NRPM, and I think
the debate about what is a "lame" server only reenforces why that
is a bad idea.  If there are operational details in the NRPM they
should be removed.

However, my fear is that without section 7.2 ARIN staff will feel
they have no authority to police DNS delegations.

-- 
       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/20070912/c3a308c6/attachment.sig>

From michael.dillon at bt.com  Wed Sep 12 09:58:26 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 12 Sep 2007 14:58:26 +0100
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <20070912133422.GA23451@ussenterprise.ufp.org>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com><20070912025232.GA76366@ussenterprise.ufp.org><20070912042907.GD2901@nsn.com>
	<20070912133422.GA23451@ussenterprise.ufp.org>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00102FF01@E03MVC4-UKBR.domain1.systemhost.net>

> However, my fear is that without section 7.2 ARIN staff will 
> feel they have no authority to police DNS delegations.

With section 7.2, my fear is that ARIN staff will feel that they cannot
take any action with regard to in-addr.arpa delegations unless it meets
the letter of the policy. By removing this from policy, staff will be
free to take any reasonable actions under the direction of management
and the board without fear of contravening ARIN policy. This is an ops
issue, not a policy issue.

As for policing, I hope that ARIN staff never police DNS delegations. I
would like to seem them audit such delegations, and maintain contact
with DNS ops people inside the various organizations. I would like to
see them offer free in-addr.arpa services to orgs with ARIN
allocations/assignments and I would like to see them track which orgs
actively refuse the free services so as not to pester them every 6
months or so. But I would not like to see any policing and especially
not any policing which assumes that there is one right way for the
Internet and therefore all IP network users must toe that line.

--Michael Dillon 


From briand at ca.afilias.info  Wed Sep 12 10:07:47 2007
From: briand at ca.afilias.info (Brian Dickson)
Date: Wed, 12 Sep 2007 10:07:47 -0400
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <46E732E9.5030108@arin.net>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<46E732E9.5030108@arin.net>
Message-ID: <46E7F2B3.1070205@ca.afilias.info>

I oppose the proposal. Argument on why follows:
>> 		Recent PPML discussion has called attention to the
>> 		fact that lame DNS delegations are more an operational
>> 		issue than one of policy.  As such, the existing lame
>> 		delegation policy should be removed from the NRPM
>> 		to remove the resultant confusion.  This is not meant
>> 		to prevent ARIN staff from taking reasonable action
>> 		WRT DNS operational issues related to resources issued
>> 		by ARIN, but, such action can be covered by staff
>> 		operational guidelines and is not within the scope
>> 		of Address Policy.
>>     
The point of having policy documents which are public, is not to inform 
ARIN staff what they're
allowed to do, but to inform recipients of ARIN-provided services what 
*they're* allowed to do.

It is important that Section 7 remain part of the policy document for 
this reason, more than anything
else.

Without explicit rules governing expected behaviour, the problem space 
can only be expected
to mushroom. Why this would likely happen, includes scofflaws, lazy 
administrators, as well as
"bad actors", the latter of which are dwarfed in volume by the first two.

Anything which increases the potential workload for enforcement, 
regardless of intent, is a big
step backwards.

And *that* is why I oppose the proposal.

Brian Dickson


From HRyu at norlight.com  Wed Sep 12 10:45:45 2007
From: HRyu at norlight.com (Hyunseog Ryu)
Date: Wed, 12 Sep 2007 09:45:45 -0500
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <46E7F2B3.1070205@ca.afilias.info>
Message-ID: <OF49600A3A.9EF43EFC-ON86257354.0050F37E-86257354.005117B5@norlight.com>

I'm against for this proposal with same reason. 


Hyun

Hyunseog Ryu
Senior Network Engineer
Norlight Telecommunications, Inc./Cinergy Communications. Q-Comm Company
Applications Engineering
13935 Bishops Drive
Brookfield, WI 53005 
Phone. +1-262-792-7965
Fax. +1-262-792-7733
Email. hryu at norlight.com




Brian Dickson <briand at ca.afilias.info> 
Sent by: ppml-bounces at arin.net
09/12/2007 09:07 AM

To
Member Services <info at arin.net>
cc
ppml at arin.net
Fax to

Subject
Re: [ppml] Policy Proposal -- Eliminate Lame Server policy






I oppose the proposal. Argument on why follows:
>>                               Recent PPML discussion has called 
attention to the
>>                               fact that lame DNS delegations are more 
an operational
>>                               issue than one of policy.  As such, the 
existing lame
>>                               delegation policy should be removed from 
the NRPM
>>                               to remove the resultant confusion.  This 
is not meant
>>                               to prevent ARIN staff from taking 
reasonable action
>>                               WRT DNS operational issues related to 
resources issued
>>                               by ARIN, but, such action can be covered 
by staff
>>                               operational guidelines and is not within 
the scope
>>                               of Address Policy.
>> 
The point of having policy documents which are public, is not to inform 
ARIN staff what they're
allowed to do, but to inform recipients of ARIN-provided services what 
*they're* allowed to do.

It is important that Section 7 remain part of the policy document for 
this reason, more than anything
else.

Without explicit rules governing expected behaviour, the problem space 
can only be expected
to mushroom. Why this would likely happen, includes scofflaws, lazy 
administrators, as well as
"bad actors", the latter of which are dwarfed in volume by the first two.

Anything which increases the potential workload for enforcement, 
regardless of intent, is a big
step backwards.

And *that* is why I oppose the proposal.

Brian Dickson
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN 
Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member 
Services
Help Desk at info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070912/7a009f33/attachment.htm>

From Tommy.Perniciaro at thomson.net  Wed Sep 12 10:48:47 2007
From: Tommy.Perniciaro at thomson.net (Perniciaro Tommy)
Date: Wed, 12 Sep 2007 07:48:47 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
Message-ID: <23480D326186CF49819F5EF363276C9002E755DC@BRBKSMAIL04.am.thmulti.com>

I am also against this proposal.

----- Original Message -----
From: ppml-bounces at arin.net <ppml-bounces at arin.net>
To: Brian Dickson <briand at ca.afilias.info>
Cc: ppml at arin.net <ppml at arin.net>; ppml-bounces at arin.net <ppml-bounces at arin.net>
Sent: Wed Sep 12 07:45:45 2007
Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy


I'm against for this proposal with same reason. 


Hyun 

Hyunseog Ryu
Senior Network Engineer
Norlight Telecommunications, Inc./Cinergy Communications. Q-Comm Company
Applications Engineering
13935 Bishops Drive
Brookfield, WI 53005 
Phone. +1-262-792-7965
Fax. +1-262-792-7733
Email. hryu at norlight.com




Brian Dickson <briand at ca.afilias.info> 
Sent by: ppml-bounces at arin.net 

09/12/2007 09:07 AM 	
To
	Member Services <info at arin.net> 
cc
	ppml at arin.net 
Fax to
	
Subject
	Re: [ppml] Policy Proposal -- Eliminate Lame Server policy

	




I oppose the proposal. Argument on why follows:
>>                                   Recent PPML discussion has called attention to the
>>                                   fact that lame DNS delegations are more an operational
>>                                   issue than one of policy.  As such, the existing lame
>>                                   delegation policy should be removed from the NRPM
>>                                   to remove the resultant confusion.  This is not meant
>>                                   to prevent ARIN staff from taking reasonable action
>>                                   WRT DNS operational issues related to resources issued
>>                                   by ARIN, but, such action can be covered by staff
>>                                   operational guidelines and is not within the scope
>>                                   of Address Policy.
>>     
The point of having policy documents which are public, is not to inform 
ARIN staff what they're
allowed to do, but to inform recipients of ARIN-provided services what 
*they're* allowed to do.

It is important that Section 7 remain part of the policy document for 
this reason, more than anything
else.

Without explicit rules governing expected behaviour, the problem space 
can only be expected
to mushroom. Why this would likely happen, includes scofflaws, lazy 
administrators, as well as
"bad actors", the latter of which are dwarfed in volume by the first two.

Anything which increases the potential workload for enforcement, 
regardless of intent, is a big
step backwards.

And *that* is why I oppose the proposal.

Brian Dickson
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.



From briand at ca.afilias.info  Wed Sep 12 10:51:12 2007
From: briand at ca.afilias.info (Brian Dickson)
Date: Wed, 12 Sep 2007 10:51:12 -0400
Subject: [ppml] Is this Lame or what?
In-Reply-To: <ABE34F09-5367-496E-A58E-F38552E281C6@quonix.net>
References: <454810F09B5AA04E9D78D13A5C39028A02A4C9D6@nyrofcs2ke2k01.corp.pvt>	<46E72960.4030805@internap.com>
	<ABE34F09-5367-496E-A58E-F38552E281C6@quonix.net>
Message-ID: <46E7FCE0.2030300@ca.afilias.info>

John Von Essen wrote:
> Scott,
>
>
> Hostmaster confirmed what you state below:
>
> "Only if all of zones for a given name server of a specific network  
> registration are lame, is the delegation registration deemed lame"
>
> That is valid, correct, and should stay as-is.
>
>
>   
Actually, that is, IMHO, incorrect. It is backwards.

It *should* read:

"Only if all name servers for a zone of a specific network registration 
are lame, is the delegation deemed lame."

Meaning:
If 4 /24's are delegated, and all 4 have the same NS sets on their 
in-addr.arpa. delegations, but none of them
in fact serve one of the /24 in-addr.arpa. zones, then the zone 
delegataion for *that* /24 should be deemed lame.

This will fix the /24 problem.

The /16 problem is another kettle of fish.

How do we address this via Public Policy process? Since it directly 
affects the NRPM, should not the
definition itself be part of it, e.g. in an Appendix?

Brian Dickson
> On Sep 11, 2007, at 7:48 PM, Scott Leibrand wrote:
>
>   
>> After doing some research (which I highly recommend everyone do before
>> posting), I'm not sure any policy changes are needed to deal with the
>> two specific cases raised so far.
>>
>> ARIN's Lame Delegations page at
>> http://www.arin.net/reference/lame_delegations.html states that "ARIN
>> tests a reverse zone by requesting the SOA (Start of Authority) record
>> from the name servers registered in WHOIS. ... Any other answer (or an
>> inability to reach the nameserver due to a forward lookup failure)
>> results in the delegation being deemed lame. If all of zones for a  
>> given
>> name server of a specific network registration are lame, the  
>> delegation
>> registration is deemed lame."



From info at arin.net  Wed Sep 12 11:06:36 2007
From: info at arin.net (Member Services)
Date: Wed, 12 Sep 2007 11:06:36 -0400
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
Message-ID: <46E8007C.6010507@arin.net>

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

The ARIN Advisory Council (AC) will review this proposal at their next
regularly scheduled meeting. The AC may decide to:

    1. Accept the proposal as a formal policy proposal as written. If the
AC accepts the proposal, it will be posted as a formal policy proposal
to PPML and it will be presented at a Public Policy Meeting.

    2. Postpone their decision regarding the proposal until the next
regularly scheduled AC meeting in order to work with the author. The AC
will work with the author to clarify, combine or divide the proposal. At
their following meeting the AC will accept or not accept the proposal.

    3. Not accept the proposal. If the AC does not accept the proposal,
the AC will explain their decision. If a proposal is not accepted, then
the author may elect to use the petition process to advance their
proposal. If the author elects not to petition or the  petition fails,
then the proposal will be closed.

The AC will assign shepherds in the near future. ARIN will provide the
names of the shepherds to the community via the PPML.

In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: Modification to Reverse Mapping Policy

Author: John Von Essen

Proposal Version: 1.0

Submission Date: September 11, 2007

Proposal type: modify

Policy term: permanent

Policy statement:

I am proposing a modification to section 7 of the IPv4 policy such that
a more precise definition and overview of lameness is described.
Below is how I think section 7 should be re-written.

START NEW Section

7. Reverse Mapping

7.1. Maintaining IN-ADDRs

All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
from ARIN will be responsible for maintaining all IN- ADDR.ARPA domain
records for their respective customers. For blocks smaller than /16, and
for the segment of larger blocks which start or end with a CIDR prefix
longer than /16, ARIN can maintain IN-ADDRs through the use of the SWIP
(Reallocate and Reassign) templates or the Netmod template for /24 and
shorter prefixes.

7.2 Definitions

7.2.1 Lame Delegation

A delegation is defined as being lame if all of the in-addr.arpa zones
for a given name server of a specific network registration are lame. An
in- addr.arpa zone is defined as lame when ARIN requests the SOA record
from the name server registered in whois, but does not receive an answer.

7.2.2 Partially Lame Delegation

A delegation is defined as being partially lame if at least one in-
addr.arpa zone for a given name server of a specific network
registration is lame. An in- addr.arpa zone is defined as lame when ARIN
requests the SOA record from the name server registered in whois, but
does not receive an answer.

7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA

ARIN will actively identify lame and partially lame DNS name server
(s) for reverse address delegations associated with address blocks
allocated, assigned or administered by ARIN. Upon identification of a
lame or partially 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 or partially lame delegation, ARIN
will update the WHOIS database records resulting in the removal of lame
or partially lame DNS servers. ARIN's actions in resolving lame and
partially lame delegations is governed by the procedures set forth in
(Lame-Ref).

7.4 References

(Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
reference/lame_delegations.html


STOP NEW Section


Rationale:

Current policy only considers an Org's delegation being deemed lame if
all of in-addr.arpa zones for a given name server of a specific network
registration are lame. Lame is defined when ARIN tests an in-addr.arpa
zone by requesting the SOA record from the name server registered in
whois, but does not receive an answer. If deemed lame, ARIN has an
appropriate procedure for contacting the Org and handling the issue as
per "http://www.arin.net/ reference/lame_delegations.html".

Unfortunately, the policy does not cover the situation of a so-called
partially lame delegation. That is, some of the in-addr.arpa zones
belonging to the network registration return a valid SOA upon testing,
and some do not. Even if only one /24 in-addr.arpa reverse tests comes
back as lame, it is my opinion that this still taints the reputation of
entire network registration. IPs belonging to that lame in-addr.arpa
zone will cause query timeouts to 3rd party dns resolvers, both public
and private. These excessive timeouts in my opinion can harm the overall
well-being of reverse dns functionality throughout the internet. The
only way to prevent such harm is for ARIN to not delegate reverse
authority to the so-called partially lame dns server as registered in
whois. That is the purpose of this policy proposal, to consider partial
lameness with the same prejudice as traditionally defined lameness.
Org's who are partially lame should be contacted by ARIN and lame
in-addr.arpa zones should be resolved as the procedures per
"http://www.arin.net/reference/ lame_delegations.html" dictate.

Timetable for implementation: June 1, 2008



From briand at ca.afilias.info  Wed Sep 12 11:24:08 2007
From: briand at ca.afilias.info (Brian Dickson)
Date: Wed, 12 Sep 2007 11:24:08 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <46E71DA3.40005@psg.com>
References: <NABBJOELMNGNJNGPKDDOEEINHDAA.tedm@ipinc.net>
	<46E709A7.9060105@ca.afilias.info> <46E71DA3.40005@psg.com>
Message-ID: <46E80498.3010109@ca.afilias.info>

Randy Bush wrote:
> arin delegates 42.666.in-addr.arpa to the member isp. the servers
> properly respond for that delegation.  this seems to be about as far as
> current policy goes; though there are reported gaps in implementation.
>
> the op wants us to say that, if the delegatee further delegates
> sub-zones, then the service for those sub-zones must not be lame.
>
> aside from issues of whether the community has the right to descend into
> the delegation, how would we text the sub-delegations?  if they are on
> byte boundaries, we can probe for them.  but goddesses help us if they
> use rfc 2317.  and is it our prerogative to probe 256 sub-delegations of
> a /16?  64k of a /8?  and how many of a /32 in ipv6 space?
>   
The "probing" is in fact, an exercise in tree-walking.

Writing a script to handle this should be within the capabilities of 
ARIN, given the scope of other
tools they no doubt need to handle administration of address assignments.

The basic tree-walking should be limited to following delegations of 
expected form (numeric subzones
within the expected ranges, either 0-1 or 0-255). Those are the only 
sub-delegations "of interest",
i.e. which would otherwise have been directly delegated by ARIN.

Optimizations can be done, since the expectation is one of positive 
responses to SOA queries.
Low timeouts may generate false negatives, but no false positives. 
Re-testing false negatives with
longer timeouts, produces the true negatives.

The *main* question is, since in rfc 2317 the distance from ARIN in 
delegations can be >2,
what should be done?

I think the classic "him or you" answer scales best. Arin requests the 
delegatee to fix the subordinate,
or have their delegation pulled, with the recommendation that they use 
the same tactic.

At the leaf, the broken delegatee must either fix the problem or get pruned.
If the delegator does not prune a still-broken leaf, then *his* 
delegator must do the same, or face
being pruned him/herself. Etc.

The responsibility with ARIN rests only in running test scripts, and 
contacting direct delegatees.
All further communication is between third parties, within some set time 
frame.

I *think* this would be able to be codified in the NRPM, as well as 
passing the scaling, sanity,
and legitimacy/legality tests.

Thoughts?

Brian Dickson


From linda at sat-tel.com  Wed Sep 12 11:56:45 2007
From: linda at sat-tel.com (Linda)
Date: Wed, 12 Sep 2007 11:56:45 -0400
Subject: [ppml]  Policy Proposal: Modification to Reverse Mapping Policy
Message-ID: <02cd01c7f555$8556c4f0$966600d0@accountsrec>

Policy Proposal: Modification to Reverse Mapping Policy


I oppose this proposal, this is an operational issue.

Regards,
Linda Werner
Satellite Communication Systems, Inc.

> ----- Original Message ----- 
> From: "Member Services" <info at arin.net>
> To: <ppml at arin.net>
> Sent: Wednesday, September 12, 2007 11:06 AM
> Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
>
>
>> ARIN received the following policy proposal. In accordance with the ARIN
>> Internet Resource Policy Evaluation Process, the proposal is being
>> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
>> ARIN's website.
>>
>> The ARIN Advisory Council (AC) will review this proposal at their next
>> regularly scheduled meeting. The AC may decide to:
>>
>>    1. Accept the proposal as a formal policy proposal as written. If the
>> AC accepts the proposal, it will be posted as a formal policy proposal
>> to PPML and it will be presented at a Public Policy Meeting.
>>
>>    2. Postpone their decision regarding the proposal until the next
>> regularly scheduled AC meeting in order to work with the author. The AC
>> will work with the author to clarify, combine or divide the proposal. At
>> their following meeting the AC will accept or not accept the proposal.
>>
>>    3. Not accept the proposal. If the AC does not accept the proposal,
>> the AC will explain their decision. If a proposal is not accepted, then
>> the author may elect to use the petition process to advance their
>> proposal. If the author elects not to petition or the  petition fails,
>> then the proposal will be closed.
>>
>> The AC will assign shepherds in the near future. ARIN will provide the
>> names of the shepherds to the community via the PPML.
>>
>> In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at:
>> http://www.arin.net/policy/irpep.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: Modification to Reverse Mapping Policy
>>
>> Author: John Von Essen
>>
>> Proposal Version: 1.0
>>
>> Submission Date: September 11, 2007
>>
>> Proposal type: modify
>>
>> Policy term: permanent
>>
>> Policy statement:
>>
>> I am proposing a modification to section 7 of the IPv4 policy such that
>> a more precise definition and overview of lameness is described.
>> Below is how I think section 7 should be re-written.
>>
>> START NEW Section
>>
>> 7. Reverse Mapping
>>
>> 7.1. Maintaining IN-ADDRs
>>
>> All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
>> from ARIN will be responsible for maintaining all IN- ADDR.ARPA domain
>> records for their respective customers. For blocks smaller than /16, and
>> for the segment of larger blocks which start or end with a CIDR prefix
>> longer than /16, ARIN can maintain IN-ADDRs through the use of the SWIP
>> (Reallocate and Reassign) templates or the Netmod template for /24 and
>> shorter prefixes.
>>
>> 7.2 Definitions
>>
>> 7.2.1 Lame Delegation
>>
>> A delegation is defined as being lame if all of the in-addr.arpa zones
>> for a given name server of a specific network registration are lame. An
>> in- addr.arpa zone is defined as lame when ARIN requests the SOA record
>> from the name server registered in whois, but does not receive an answer.
>>
>> 7.2.2 Partially Lame Delegation
>>
>> A delegation is defined as being partially lame if at least one in-
>> addr.arpa zone for a given name server of a specific network
>> registration is lame. An in- addr.arpa zone is defined as lame when ARIN
>> requests the SOA record from the name server registered in whois, but
>> does not receive an answer.
>>
>> 7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA
>>
>> ARIN will actively identify lame and partially lame DNS name server
>> (s) for reverse address delegations associated with address blocks
>> allocated, assigned or administered by ARIN. Upon identification of a
>> lame or partially 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 or partially lame delegation, ARIN
>> will update the WHOIS database records resulting in the removal of lame
>> or partially lame DNS servers. ARIN's actions in resolving lame and
>> partially lame delegations is governed by the procedures set forth in
>> (Lame-Ref).
>>
>> 7.4 References
>>
>> (Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
>> reference/lame_delegations.html
>>
>>
>> STOP NEW Section
>>
>>
>> Rationale:
>>
>> Current policy only considers an Org's delegation being deemed lame if
>> all of in-addr.arpa zones for a given name server of a specific network
>> registration are lame. Lame is defined when ARIN tests an in-addr.arpa
>> zone by requesting the SOA record from the name server registered in
>> whois, but does not receive an answer. If deemed lame, ARIN has an
>> appropriate procedure for contacting the Org and handling the issue as
>> per "http://www.arin.net/ reference/lame_delegations.html".
>>
>> Unfortunately, the policy does not cover the situation of a so-called
>> partially lame delegation. That is, some of the in-addr.arpa zones
>> belonging to the network registration return a valid SOA upon testing,
>> and some do not. Even if only one /24 in-addr.arpa reverse tests comes
>> back as lame, it is my opinion that this still taints the reputation of
>> entire network registration. IPs belonging to that lame in-addr.arpa
>> zone will cause query timeouts to 3rd party dns resolvers, both public
>> and private. These excessive timeouts in my opinion can harm the overall
>> well-being of reverse dns functionality throughout the internet. The
>> only way to prevent such harm is for ARIN to not delegate reverse
>> authority to the so-called partially lame dns server as registered in
>> whois. That is the purpose of this policy proposal, to consider partial
>> lameness with the same prejudice as traditionally defined lameness.
>> Org's who are partially lame should be contacted by ARIN and lame
>> in-addr.arpa zones should be resolved as the procedures per
>> "http://www.arin.net/reference/ lame_delegations.html" dictate.
>>
>> Timetable for implementation: June 1, 2008
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN 
>> Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN 
>> Member Services
>> Help Desk at info at arin.net if you experience any issues.
>>
>>
> 




From john at quonix.net  Wed Sep 12 11:58:32 2007
From: john at quonix.net (John Von Essen)
Date: Wed, 12 Sep 2007 11:58:32 -0400
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <46E80498.3010109@ca.afilias.info>
References: <NABBJOELMNGNJNGPKDDOEEINHDAA.tedm@ipinc.net>
	<46E709A7.9060105@ca.afilias.info> <46E71DA3.40005@psg.com>
	<46E80498.3010109@ca.afilias.info>
Message-ID: <057C2792-D000-4200-81BA-03BC74E97C40@quonix.net>

I agree.

I have no sympathy for the response of "testing all these in- 
addr.arpa zones is too much work". Granted, we are only talking  
about /24 prefixes.

The entire process can be easily automated, and that includes the SOA  
query testing to delegated DNS servers for an Org's address block,  
updating an internal tracking database, and even the process of  
emailing the Org's POC for DNS. The Org's that get emailed the  
warning could even be given a link to click when they have resolved  
the issue. That link would automatically re-check, and if SOA  
response is valid, would automatically remove them from the database  
of "delinquents".

So for the Org's that fix things in a timely fashion following the  
automatic email - ARIN staff will never even have to get involved.  
Staff would only get involved with those Org's that dont respond to  
the initial emails.

-john


On Sep 12, 2007, at 11:24 AM, Brian Dickson wrote:

> Randy Bush wrote:
>> arin delegates 42.666.in-addr.arpa to the member isp. the servers
>> properly respond for that delegation.  this seems to be about as  
>> far as
>> current policy goes; though there are reported gaps in  
>> implementation.
>>
>> the op wants us to say that, if the delegatee further delegates
>> sub-zones, then the service for those sub-zones must not be lame.
>>
>> aside from issues of whether the community has the right to  
>> descend into
>> the delegation, how would we text the sub-delegations?  if they  
>> are on
>> byte boundaries, we can probe for them.  but goddesses help us if  
>> they
>> use rfc 2317.  and is it our prerogative to probe 256 sub- 
>> delegations of
>> a /16?  64k of a /8?  and how many of a /32 in ipv6 space?
>>
> The "probing" is in fact, an exercise in tree-walking.
>
> Writing a script to handle this should be within the capabilities of
> ARIN, given the scope of other
> tools they no doubt need to handle administration of address  
> assignments.
>
> The basic tree-walking should be limited to following delegations of
> expected form (numeric subzones
> within the expected ranges, either 0-1 or 0-255). Those are the only
> sub-delegations "of interest",
> i.e. which would otherwise have been directly delegated by ARIN.
>
> Optimizations can be done, since the expectation is one of positive
> responses to SOA queries.
> Low timeouts may generate false negatives, but no false positives.
> Re-testing false negatives with
> longer timeouts, produces the true negatives.
>
> The *main* question is, since in rfc 2317 the distance from ARIN in
> delegations can be >2,
> what should be done?
>
> I think the classic "him or you" answer scales best. Arin requests the
> delegatee to fix the subordinate,
> or have their delegation pulled, with the recommendation that they use
> the same tactic.
>
> At the leaf, the broken delegatee must either fix the problem or  
> get pruned.
> If the delegator does not prune a still-broken leaf, then *his*
> delegator must do the same, or face
> being pruned him/herself. Etc.
>
> The responsibility with ARIN rests only in running test scripts, and
> contacting direct delegatees.
> All further communication is between third parties, within some set  
> time
> frame.
>
> I *think* this would be able to be codified in the NRPM, as well as
> passing the scaling, sanity,
> and legitimacy/legality tests.
>
> Thoughts?
>
> Brian Dickson
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070912/1f66f847/attachment.htm>

From briand at ca.afilias.info  Wed Sep 12 12:13:51 2007
From: briand at ca.afilias.info (Brian Dickson)
Date: Wed, 12 Sep 2007 12:13:51 -0400
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <46E8007C.6010507@arin.net>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<46E8007C.6010507@arin.net>
Message-ID: <46E8103F.5050002@ca.afilias.info>

I support the proposal, although I would like to see a modification of 
the language proposed,
specifically:

Member Services wrote:
> 7.2.1 Lame Delegation
>
> A delegation is defined as being lame if all of the in-addr.arpa zones
> for a given name server of a specific network registration are lame. An
> in- addr.arpa zone is defined as lame when ARIN requests the SOA record
> from the name server registered in whois, but does not receive an answer.
>
>   
This subsection should be about lame *servers*, not delegations.

A delegation is the delegation of a zone, to *multiple* servers, and is 
only lame if *all* servers are lame
for *that* zone.

s/Delegation/Server/
s/delegation/server/

7.2.1 Lame Server

A server is defined as being lame if all of the in-addr.arpa zones
for the specific name server of a specific network registration are lame.
An in-addr.arpa zone is defined as lame when ARIN requests the SOA record
from the name server registered in whois, but does not receive an answer
(within 30s on 3 successive queries).


> 7.2.2 Partially Lame Delegation
>
> A delegation is defined as being partially lame if at least one in-
> addr.arpa zone for a given name server of a specific network
> registration is lame. An in- addr.arpa zone is defined as lame when ARIN
> requests the SOA record from the name server registered in whois, but
> does not receive an answer.
>   
s/Partially Lame Delegation/Lame Zone Delegation/

7.2.2 Lame Zone Delegation

A zone delegation is defined as being lame if the
in-addr.arpa zone of a specific network registration is
lame, for all listed name servers. An in-addr.arpa zone
is defined as lame when ARIN requests the SOA record
from the name server registered in whois, but does not
receive an answer (within 30s on 3 successive queries).

Brian Dickson


From sleibrand at internap.com  Wed Sep 12 12:36:32 2007
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 12 Sep 2007 09:36:32 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <46E8007C.6010507@arin.net>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<46E8007C.6010507@arin.net>
Message-ID: <46E81590.9040304@internap.com>

John,

Do you have any examples of Partially Lame Delegations (or, to use 
Brian's slightly more precise terminology, Lame Zone Delegations to a 
non-Lame Server)?  I'm not opposed to your policy rewrite, but I'm as 
yet unconvinced that we have a real life non-hypothetical problem that 
can't be fixed by application of current policies and procedures.

Thanks,
Scott

Member Services wrote:
> ARIN received the following policy proposal. In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
> ARIN's website.
>
> The ARIN Advisory Council (AC) will review this proposal at their next
> regularly scheduled meeting. The AC may decide to:
>
>     1. Accept the proposal as a formal policy proposal as written. If the
> AC accepts the proposal, it will be posted as a formal policy proposal
> to PPML and it will be presented at a Public Policy Meeting.
>
>     2. Postpone their decision regarding the proposal until the next
> regularly scheduled AC meeting in order to work with the author. The AC
> will work with the author to clarify, combine or divide the proposal. At
> their following meeting the AC will accept or not accept the proposal.
>
>     3. Not accept the proposal. If the AC does not accept the proposal,
> the AC will explain their decision. If a proposal is not accepted, then
> the author may elect to use the petition process to advance their
> proposal. If the author elects not to petition or the  petition fails,
> then the proposal will be closed.
>
> The AC will assign shepherds in the near future. ARIN will provide the
> names of the shepherds to the community via the PPML.
>
> In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
>
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal Name: Modification to Reverse Mapping Policy
>
> Author: John Von Essen
>
> Proposal Version: 1.0
>
> Submission Date: September 11, 2007
>
> Proposal type: modify
>
> Policy term: permanent
>
> Policy statement:
>
> I am proposing a modification to section 7 of the IPv4 policy such that
> a more precise definition and overview of lameness is described.
> Below is how I think section 7 should be re-written.
>
> START NEW Section
>
> 7. Reverse Mapping
>
> 7.1. Maintaining IN-ADDRs
>
> All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
> from ARIN will be responsible for maintaining all IN- ADDR.ARPA domain
> records for their respective customers. For blocks smaller than /16, and
> for the segment of larger blocks which start or end with a CIDR prefix
> longer than /16, ARIN can maintain IN-ADDRs through the use of the SWIP
> (Reallocate and Reassign) templates or the Netmod template for /24 and
> shorter prefixes.
>
> 7.2 Definitions
>
> 7.2.1 Lame Delegation
>
> A delegation is defined as being lame if all of the in-addr.arpa zones
> for a given name server of a specific network registration are lame. An
> in- addr.arpa zone is defined as lame when ARIN requests the SOA record
> from the name server registered in whois, but does not receive an answer.
>
> 7.2.2 Partially Lame Delegation
>
> A delegation is defined as being partially lame if at least one in-
> addr.arpa zone for a given name server of a specific network
> registration is lame. An in- addr.arpa zone is defined as lame when ARIN
> requests the SOA record from the name server registered in whois, but
> does not receive an answer.
>
> 7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA
>
> ARIN will actively identify lame and partially lame DNS name server
> (s) for reverse address delegations associated with address blocks
> allocated, assigned or administered by ARIN. Upon identification of a
> lame or partially 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 or partially lame delegation, ARIN
> will update the WHOIS database records resulting in the removal of lame
> or partially lame DNS servers. ARIN's actions in resolving lame and
> partially lame delegations is governed by the procedures set forth in
> (Lame-Ref).
>
> 7.4 References
>
> (Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
> reference/lame_delegations.html
>
>
> STOP NEW Section
>
>
> Rationale:
>
> Current policy only considers an Org's delegation being deemed lame if
> all of in-addr.arpa zones for a given name server of a specific network
> registration are lame. Lame is defined when ARIN tests an in-addr.arpa
> zone by requesting the SOA record from the name server registered in
> whois, but does not receive an answer. If deemed lame, ARIN has an
> appropriate procedure for contacting the Org and handling the issue as
> per "http://www.arin.net/ reference/lame_delegations.html".
>
> Unfortunately, the policy does not cover the situation of a so-called
> partially lame delegation. That is, some of the in-addr.arpa zones
> belonging to the network registration return a valid SOA upon testing,
> and some do not. Even if only one /24 in-addr.arpa reverse tests comes
> back as lame, it is my opinion that this still taints the reputation of
> entire network registration. IPs belonging to that lame in-addr.arpa
> zone will cause query timeouts to 3rd party dns resolvers, both public
> and private. These excessive timeouts in my opinion can harm the overall
> well-being of reverse dns functionality throughout the internet. The
> only way to prevent such harm is for ARIN to not delegate reverse
> authority to the so-called partially lame dns server as registered in
> whois. That is the purpose of this policy proposal, to consider partial
> lameness with the same prejudice as traditionally defined lameness.
> Org's who are partially lame should be contacted by ARIN and lame
> in-addr.arpa zones should be resolved as the procedures per
> "http://www.arin.net/reference/ lame_delegations.html" dictate.
>
> Timetable for implementation: June 1, 2008
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>   


From john at quonix.net  Wed Sep 12 13:24:41 2007
From: john at quonix.net (John Von Essen)
Date: Wed, 12 Sep 2007 13:24:41 -0400
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <46E81590.9040304@internap.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<46E8007C.6010507@arin.net> <46E81590.9040304@internap.com>
Message-ID: <01623EDD-5F06-408D-B5BA-32C293A5BD66@quonix.net>

Yes,

I have several examples of what I call partially lame dns servers.  
Let me put together a more in-depth list with prefixes from several  
different providers, and I'll email it to the list later today.

-John

On Sep 12, 2007, at 12:36 PM, Scott Leibrand wrote:

> John,
>
> Do you have any examples of Partially Lame Delegations (or, to use
> Brian's slightly more precise terminology, Lame Zone Delegations to a
> non-Lame Server)?  I'm not opposed to your policy rewrite, but I'm as
> yet unconvinced that we have a real life non-hypothetical problem that
> can't be fixed by application of current policies and procedures.
>
> Thanks,
> Scott
>
> Member Services wrote:
>> ARIN received the following policy proposal. In accordance with  
>> the ARIN
>> Internet Resource Policy Evaluation Process, the proposal is being
>> posted to the ARIN Public Policy Mailing List (PPML) and being  
>> placed on
>> ARIN's website.
>>
>> The ARIN Advisory Council (AC) will review this proposal at their  
>> next
>> regularly scheduled meeting. The AC may decide to:
>>
>>     1. Accept the proposal as a formal policy proposal as written.  
>> If the
>> AC accepts the proposal, it will be posted as a formal policy  
>> proposal
>> to PPML and it will be presented at a Public Policy Meeting.
>>
>>     2. Postpone their decision regarding the proposal until the next
>> regularly scheduled AC meeting in order to work with the author.  
>> The AC
>> will work with the author to clarify, combine or divide the  
>> proposal. At
>> their following meeting the AC will accept or not accept the  
>> proposal.
>>
>>     3. Not accept the proposal. If the AC does not accept the  
>> proposal,
>> the AC will explain their decision. If a proposal is not accepted,  
>> then
>> the author may elect to use the petition process to advance their
>> proposal. If the author elects not to petition or the  petition  
>> fails,
>> then the proposal will be closed.
>>
>> The AC will assign shepherds in the near future. ARIN will provide  
>> the
>> names of the shepherds to the community via the PPML.
>>
>> In the meantime, the AC invites everyone to comment on this  
>> 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 Internet Resource Policy Evaluation Process can be found at:
>> http://www.arin.net/policy/irpep.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: Modification to Reverse Mapping Policy
>>
>> Author: John Von Essen
>>
>> Proposal Version: 1.0
>>
>> Submission Date: September 11, 2007
>>
>> Proposal type: modify
>>
>> Policy term: permanent
>>
>> Policy statement:
>>
>> I am proposing a modification to section 7 of the IPv4 policy such  
>> that
>> a more precise definition and overview of lameness is described.
>> Below is how I think section 7 should be re-written.
>>
>> START NEW Section
>>
>> 7. Reverse Mapping
>>
>> 7.1. Maintaining IN-ADDRs
>>
>> All ISPs receiving one or more distinct /16 CIDR blocks of IP  
>> addresses
>> from ARIN will be responsible for maintaining all IN- ADDR.ARPA  
>> domain
>> records for their respective customers. For blocks smaller than / 
>> 16, and
>> for the segment of larger blocks which start or end with a CIDR  
>> prefix
>> longer than /16, ARIN can maintain IN-ADDRs through the use of the  
>> SWIP
>> (Reallocate and Reassign) templates or the Netmod template for /24  
>> and
>> shorter prefixes.
>>
>> 7.2 Definitions
>>
>> 7.2.1 Lame Delegation
>>
>> A delegation is defined as being lame if all of the in-addr.arpa  
>> zones
>> for a given name server of a specific network registration are  
>> lame. An
>> in- addr.arpa zone is defined as lame when ARIN requests the SOA  
>> record
>> from the name server registered in whois, but does not receive an  
>> answer.
>>
>> 7.2.2 Partially Lame Delegation
>>
>> A delegation is defined as being partially lame if at least one in-
>> addr.arpa zone for a given name server of a specific network
>> registration is lame. An in- addr.arpa zone is defined as lame  
>> when ARIN
>> requests the SOA record from the name server registered in whois, but
>> does not receive an answer.
>>
>> 7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA
>>
>> ARIN will actively identify lame and partially lame DNS name server
>> (s) for reverse address delegations associated with address blocks
>> allocated, assigned or administered by ARIN. Upon identification of a
>> lame or partially 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 or partially lame delegation, ARIN
>> will update the WHOIS database records resulting in the removal of  
>> lame
>> or partially lame DNS servers. ARIN's actions in resolving lame and
>> partially lame delegations is governed by the procedures set forth in
>> (Lame-Ref).
>>
>> 7.4 References
>>
>> (Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
>> reference/lame_delegations.html
>>
>>
>> STOP NEW Section
>>
>>
>> Rationale:
>>
>> Current policy only considers an Org's delegation being deemed  
>> lame if
>> all of in-addr.arpa zones for a given name server of a specific  
>> network
>> registration are lame. Lame is defined when ARIN tests an in- 
>> addr.arpa
>> zone by requesting the SOA record from the name server registered in
>> whois, but does not receive an answer. If deemed lame, ARIN has an
>> appropriate procedure for contacting the Org and handling the  
>> issue as
>> per "http://www.arin.net/ reference/lame_delegations.html".
>>
>> Unfortunately, the policy does not cover the situation of a so-called
>> partially lame delegation. That is, some of the in-addr.arpa zones
>> belonging to the network registration return a valid SOA upon  
>> testing,
>> and some do not. Even if only one /24 in-addr.arpa reverse tests  
>> comes
>> back as lame, it is my opinion that this still taints the  
>> reputation of
>> entire network registration. IPs belonging to that lame in-addr.arpa
>> zone will cause query timeouts to 3rd party dns resolvers, both  
>> public
>> and private. These excessive timeouts in my opinion can harm the  
>> overall
>> well-being of reverse dns functionality throughout the internet. The
>> only way to prevent such harm is for ARIN to not delegate reverse
>> authority to the so-called partially lame dns server as registered in
>> whois. That is the purpose of this policy proposal, to consider  
>> partial
>> lameness with the same prejudice as traditionally defined lameness.
>> Org's who are partially lame should be contacted by ARIN and lame
>> in-addr.arpa zones should be resolved as the procedures per
>> "http://www.arin.net/reference/ lame_delegations.html" dictate.
>>
>> Timetable for implementation: June 1, 2008
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the  
>> ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the  
>> ARIN Member Services
>> Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070912/e5c01afd/attachment.htm>

From tedm at ipinc.net  Wed Sep 12 14:40:53 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 12 Sep 2007 11:40:53 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <288AEB42-E021-4582-82F6-D4FD924EA551@delong.com>
Message-ID: <NABBJOELMNGNJNGPKDDOKEMIHDAA.tedm@ipinc.net>

In cases where a policy must apply uniformly, it has to be official
and not an internal staff guideline.

The big problem with taking this out of the NRPM is that unless
there's sanctions available to enforce correct DNS behavior, the
staff can't do anything because all the non-compliant network
operator has to do is say since it's not spelled out in the NRPM,
you can't do anything to me if I don't do it.

At this point I'm personally not sure any changes need to be made
at all.  But clearly the OP has a problem and the purpose of this
list and the policy process is essentially to present problems to
the community and see what the response is.

Thus I think your proposal is as needed as Johns.  If the membership
really doesen't want the RIR to bother with this, they will vote your
policy in.  If not, they will vote John's policy in (whenever it's
submitted)
So let's see what they want to do.

Ted
  -----Original Message-----
  From: Owen DeLong [mailto:owen at delong.com]
  Sent: Tuesday, September 11, 2007 8:52 PM
  To: Ted Mittelstaedt
  Cc: John Von Essen; Public Policy Mailing List
  Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy


  Ted,
  I believe you miss the point of my proposal. While I do believe that
  ARIN has a role to play in applying the clue bat to lame or partially lame
  ISPs and addressing John's issue, my point is that it belongs in
operational
  guidelines to ARIN staff and not in the NRPM.


  My proposal talks about what I think belongs in the NRPM and is
  not a direct expression of how I feel about what ARIN staff should or
  should not be doing with respect to this particular issue. I would fully
  support an ACSP recommendation that ARIN address all IN-ADDR
  lameness whether complete or not on any direct assignment. This will
  potentially require ARIN to examine as many as 255 zones in IPv4 for
  a single assignment.


  I would oppose any suggestion requiring ARIN to drill down
  to lame delegations made by the ISPs relating to reassignment or
  reallocations made by the ISP because of dramatically increasing
  workload for dramatically decreasing return on investment and
  because there is a limit to the extent to which I believe ARIN should
  engage in telling operators how to run their network (let alone their
  customers' networks).


  I will also oppose any policy regarding the operational and/or
  implementation details of lame delegations because I firmly believe
  this is not the role of the NRPM and should be addressed with
  operational procedures and recommendations rather than with
  number resource policies.


  Owen


  On Sep 11, 2007, at 5:26 PM, Ted Mittelstaedt wrote:


    Yes John you are correct but the way things often work on this list is
someone like Owen will
    submit a policy to remove something that shouldn't obviously be removed,
the result of
    which will convert a bunch of fence sitters into proponents of keeping
it.
    The list membership needs Owens "just kill it" proposal precisely to
have something to
    vote down. A no vote commits the person voting no, to supporting the
policy.
    If Owens proposal is voted down, that will destroy all of the "it's not
the RIR's responsibility
    to enforce sanctions against bad nameserver operators" arguments, and we
can move the discussion
    to something productive of how to actually fix the problem.
    Your proposal might be premature - you might find it better to campaign
against Owens
    proposal first.
    Ted
      -----Original Message-----
      From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
John Von Essen
      Sent: Tuesday, September 11, 2007 4:55 PM
      To: Public Policy Mailing List
      Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy


      I do plan to submit my proposal. My final comment on all of this is
with regards to ARIN's stance on operational issues.


      I agree ARIN should be careful, but keep in mind ARIN does provide an
operational function of reverse DNS authority delegation. Because ARIN
engages in this very-real activity, policy must exist to cover its
implementation, design, and overall operational health.


      If ARIN just did AS numbers and IP allocation, and another
organization did reverse delegation, say Network Solutions, then YES - ARIN
should not get involved with operational issues of reverse DNS. But that
fact is ARIN does do reverse DNS delegation. When I do a dig on an IP, I see
alot of ARIN servers in the output!


      -John


      On Sep 11, 2007, at 7:21 PM, Azinger, Marla wrote:


        I would like to see a proposal that is along the lines of clarifying
in addition to Owens proposal to just take it away. Hopefully we havnt
scared John off and he will give a wack at it.


        Cheers!
        Marla


        -----Original Message-----
        From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf
Of
        William Herrin
        Sent: Tuesday, September 11, 2007 3:32 PM
        To: Owen DeLong
        Cc: Public Policy Mailing List
        Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy




        On 9/11/07, Owen DeLong <owen at delong.com> wrote:
          1. Policy Proposal Name: Deprecate Lame Server Policy
          7. Policy statement:
          Delete section 7 from the NRPM


        Owen,


        Are you sure this is the right way to move on this? If we're going
to
        call ISPs "Local Internet Registries," shouldn't we expect them to
        behave as internet registries and do the things that internet
        registries do, including reallocation and assignment of the RDNS
        attached to every IP address?


        Regards,
        Bill Herrin


        --
        William D. Herrin herrin at dirtside.com bill at herrin.us
        3005 Crane Dr. Web: <http://bill.herrin.us/>
        Falls Church, VA 22042-3004
        _______________________________________________
        PPML
        You are receiving this message because you are subscribed to the
ARIN Public Policy
        Mailing List (PPML at arin.net).
        Unsubscribe or manage your mailing list subscription at:
        http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
Member Services
        Help Desk at 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 (PPML at arin.net).
        Unsubscribe or manage your mailing list subscription at:
        http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
Member Services
        Help Desk at info at arin.net if you experience any issues.


      Thanks,
      John Von Essen
      (800) 248-1736 ext 100
      john at quonix.net




    _______________________________________________
    PPML
    You are receiving this message because you are subscribed to the ARIN
Public Policy
    Mailing List (PPML at arin.net).
    Unsubscribe or manage your mailing list subscription at:
    http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
Member Services
    Help Desk at info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070912/1e34ff35/attachment.htm>

From tedm at ipinc.net  Wed Sep 12 14:52:16 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 12 Sep 2007 11:52:16 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B00102FF01@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <NABBJOELMNGNJNGPKDDOOEMIHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>michael.dillon at bt.com
>Sent: Wednesday, September 12, 2007 6:58 AM
>To: ppml at arin.net
>Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy
>

>But I would not like to see any policing and especially
>not any policing which assumes that there is one right way for the
>Internet and therefore all IP network users must toe that line.
>

This is a rather silly statement.  The entire DNS system depends on
everyone doing things "one right way".  The TCP/IP protocol itself 
won't work if everyone did their own version.  I could point to numerous
examples of everyone on the Internet having to do things "one right way"

If you want to argue that in-addr.arpa handing is not a requirement for
DNS and thus is optional, fine.  But arguing to allow everyone to do
their own thing merely for the sake of being able to do their own thing is
preposterous on a shared network.

One of ARINs jobs is policing.  You may not like the police but they serve
a required function in a community.

Ted


From Ed.Lewis at neustar.biz  Wed Sep 12 14:52:49 2007
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Wed, 12 Sep 2007 14:52:49 -0400
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <46E8007C.6010507@arin.net>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<46E8007C.6010507@arin.net>
Message-ID: <a06240807c30dde26c70f@[192.168.1.100]>

Overall I like the idea, but to give an idea of how much of a pain it 
is to cover this in policy, here is my first pass for nits.  (Keep in 
mind I've written lame delegation test code before and have seen all 
of the "weird" cases.)

I would rather take what we (=community that came to consensus on 
proposals) have, request a review of the tools ARIN (=staff) is using 
to implement 2002-1 and 2003-5 and see where the tools are deemed to 
be insufficient by the community.

>START NEW Section
>
>7. Reverse Mapping
>
>7.1. Maintaining IN-ADDRs
>
>All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
>from ARIN will be responsible for maintaining all IN- ADDR.ARPA domain
>records for their respective customers. For blocks smaller than /16, and
>for the segment of larger blocks which start or end with a CIDR prefix
>longer than /16, ARIN can maintain IN-ADDRs through the use of the SWIP
>(Reallocate and Reassign) templates or the Netmod template for /24 and
>shorter prefixes.

Not all of the delegations from ARIN published zones are to 
"customers" of ARIN.  Because of the Early Registration Transfers 
about 5 years ago, some of the delegations are for registrants of 
APNIC, RIPE, et.al.  We will have to keep this in mind when it comes 
to trying to contact the registrant to report a detected problem.

>7.2 Definitions
>
>7.2.1 Lame Delegation
>
>A delegation is defined as being lame if all of the in-addr.arpa zones
>for a given name server of a specific network registration are lame. An
>in- addr.arpa zone is defined as lame when ARIN requests the SOA record
>from the name server registered in whois, but does not receive an answer.

A delegation in DNS terminology is the subsetting of the name space 
and yielding it to another authority and is indicated by the set of 
name servers where the subsetted name space can be found.  In the 
field of DNS, we have never grouped all of the NS records with common 
"RHS (right hand sides)" to make a set of zones delegated to the RHS, 
and from this declare the "delegation" to be lame.

For a network with 4 zones, using one implementation of DNS, and only 
configuring 3 zones, if you ask the name server in the NS record for 
the SOA of the 3 working zones, you get good answers.  For the fourth 
you will get no response, making it appear that there was a network 
error.  It would not be proper to call the delegation to the name 
server "lame" (sic).

The mapping is "network"->"zone"->"domain name"->"IP address".  A 
network (e.g., a /19) will beget 32 /24 zones.  Each of the 32 zones 
will inherit the, say, 3 name servers registered to the network. 
Those 3 name servers may each have multiple addresses - IPv4 and/or 
IPv6 - so there may be 4 IP addresses to try.  Further, if there is 
anycast there could be many name servers to test for a given network. 
What if the only server for a network is one that is anycasting 
locally to the site from which testing is done?  (I'm pointing this 
out to give a taste of how much you see from the trenches.)

Requesting an SOA and failing to receive and answer is a very 
inaccurate characterization of lameness (sic).  (Please, don't 
redefine terms, in the DNS context, lame already has a, ok a few, 
IETF documented definitions.)  I'll lay aside the call to use a 
different term for "broken."

The following would also be "broken" - non-recursive query for T=SOA 
and getting back anything other than the appropriate SOA alone in the 
Answer Section (ANCOUNT=1) with the Authoritative Answer (aa) bit set 
to 1.  That covers the use of recursive servers to look like they 
slave the zone.

>7.2.2 Partially Lame Delegation
>
>A delegation is defined as being partially lame if at least one in-
>addr.arpa zone for a given name server of a specific network
>registration is lame. An in- addr.arpa zone is defined as lame when ARIN
>requests the SOA record from the name server registered in whois, but
>does not receive an answer.

There will be many cases where for a network, one server will be 
broken at any moment in time.  But this is an inaccurate 
characterization of the problem.

>7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA
>
>ARIN will actively identify lame and partially lame DNS name server
>(s) for reverse address delegations associated with address blocks
>allocated, assigned or administered by ARIN. Upon identification of a
>lame or partially 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 or partially lame delegation, ARIN
>will update the WHOIS database records resulting in the removal of lame
>or partially lame DNS servers. ARIN's actions in resolving lame and
>partially lame delegations is governed by the procedures set forth in
>(Lame-Ref).

I would rephrase this as something like this: ARIN will actively 
monitor DNS delegations from it's DNS servers to ARIN registrants and 
inform registrants of malfunctioning servers .  (Insert time and 
retry parameters here).  If a registered name server for a network 
object is found to be unsuitably operating, it will be removed from 
the network object's definition in the database.

The important point is to make the policy specify an action ARIN can 
easily take - that is the removal of the name server.  (Hey, it 
wasn't working anyway!)  But note "suitably" because it could be the 
case that the name server answers to it's selected population of 
clients and the ARIN tester but to no one else in the Internet, 
thanks to ACLs.

>7.4 References
>
>(Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
>reference/lame_delegations.html


>and some do not. Even if only one /24 in-addr.arpa reverse tests comes
>back as lame, it is my opinion that this still taints the reputation of
>entire network registration. IPs belonging to that lame in-addr.arpa

I don't want ARIN to make judgements about "reputation."

>zone will cause query timeouts to 3rd party dns resolvers, both public
>and private. These excessive timeouts in my opinion can harm the overall
>well-being of reverse dns functionality throughout the internet. The
>only way to prevent such harm is for ARIN to not delegate reverse
>authority to the so-called partially lame dns server as registered in
>whois. That is the purpose of this policy proposal, to consider partial
>lameness with the same prejudice as traditionally defined lameness.
>Org's who are partially lame should be contacted by ARIN and lame
>in-addr.arpa zones should be resolved as the procedures per
>"http://www.arin.net/reference/ lame_delegations.html" dictate.

I have a hard time following the rest of the rationale.  What I can 
buy is asking ARIN to suspend/remove a name server if it's inclusion 
in the DNS causes sustained negative operational consequences.  This 
is limited to the zone involved (not the network), as that is the 
extent of the DNS "damage."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.


From tedm at ipinc.net  Wed Sep 12 14:58:10 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 12 Sep 2007 11:58:10 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <46E81590.9040304@internap.com>
Message-ID: <NABBJOELMNGNJNGPKDDOCEMJHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Scott Leibrand
>Sent: Wednesday, September 12, 2007 9:37 AM
>To: ppml at arin.net
>Subject: Re: [ppml] Policy Proposal: Modification to Reverse Mapping
>Policy
>
>
>John,
>
>Do you have any examples of Partially Lame Delegations (or, to use
>Brian's slightly more precise terminology, Lame Zone Delegations to a
>non-Lame Server)?  I'm not opposed to your policy rewrite, but I'm as
>yet unconvinced that we have a real life non-hypothetical problem that
>can't be fixed by application of current policies and procedures.
>

I absolutely agree completely.  John Von Essen, once you propose a policy
you
must now show the actual networks.  You can no longer hide people behind
terms like "my ISP"

I want a complete posting of your original story with names named, dates,
actual IP numbers and names of who you talked to at ARIN and what exactly
they said.  I want to know how you contacted the ISP and verifyable
names we can check this story out.

If you feel you cannot produce this for "privacy" reasons then withdraw
your policy.

Ted Mittelstaedt



From tedm at ipinc.net  Wed Sep 12 15:00:37 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 12 Sep 2007 12:00:37 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <01623EDD-5F06-408D-B5BA-32C293A5BD66@quonix.net>
Message-ID: <NABBJOELMNGNJNGPKDDOGEMJHDAA.tedm@ipinc.net>

Don't forget to include the examples of how attempting to resolve these
through
normal operational procedures have failed.

Ted
  -----Original Message-----
  From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
John Von Essen
  Sent: Wednesday, September 12, 2007 10:25 AM
  To: Public Policy Mailing List
  Subject: Re: [ppml] Policy Proposal: Modification to Reverse Mapping
Policy


  Yes,


  I have several examples of what I call partially lame dns servers. Let me
put together a more in-depth list with prefixes from several different
providers, and I'll email it to the list later today.


  -John


  On Sep 12, 2007, at 12:36 PM, Scott Leibrand wrote:


    John,


    Do you have any examples of Partially Lame Delegations (or, to use
    Brian's slightly more precise terminology, Lame Zone Delegations to a
    non-Lame Server)? I'm not opposed to your policy rewrite, but I'm as
    yet unconvinced that we have a real life non-hypothetical problem that
    can't be fixed by application of current policies and procedures.


    Thanks,
    Scott


    Member Services wrote:
      ARIN received the following policy proposal. In accordance with the
ARIN
      Internet Resource Policy Evaluation Process, the proposal is being
      posted to the ARIN Public Policy Mailing List (PPML) and being placed
on
      ARIN's website.


      The ARIN Advisory Council (AC) will review this proposal at their next
      regularly scheduled meeting. The AC may decide to:


      1. Accept the proposal as a formal policy proposal as written. If the
      AC accepts the proposal, it will be posted as a formal policy proposal
      to PPML and it will be presented at a Public Policy Meeting.


      2. Postpone their decision regarding the proposal until the next
      regularly scheduled AC meeting in order to work with the author. The
AC
      will work with the author to clarify, combine or divide the proposal.
At
      their following meeting the AC will accept or not accept the proposal.


      3. Not accept the proposal. If the AC does not accept the proposal,
      the AC will explain their decision. If a proposal is not accepted,
then
      the author may elect to use the petition process to advance their
      proposal. If the author elects not to petition or the petition fails,
      then the proposal will be closed.


      The AC will assign shepherds in the near future. ARIN will provide the
      names of the shepherds to the community via the PPML.


      In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at:
      http://www.arin.net/policy/irpep.html


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


      Regards,


      Member Services
      American Registry for Internet Numbers (ARIN)




      ## * ##




      Policy Proposal Name: Modification to Reverse Mapping Policy


      Author: John Von Essen


      Proposal Version: 1.0


      Submission Date: September 11, 2007


      Proposal type: modify


      Policy term: permanent


      Policy statement:


      I am proposing a modification to section 7 of the IPv4 policy such
that
      a more precise definition and overview of lameness is described.
      Below is how I think section 7 should be re-written.


      START NEW Section


      7. Reverse Mapping


      7.1. Maintaining IN-ADDRs


      All ISPs receiving one or more distinct /16 CIDR blocks of IP
addresses
      from ARIN will be responsible for maintaining all IN- ADDR.ARPA domain
      records for their respective customers. For blocks smaller than /16,
and
      for the segment of larger blocks which start or end with a CIDR prefix
      longer than /16, ARIN can maintain IN-ADDRs through the use of the
SWIP
      (Reallocate and Reassign) templates or the Netmod template for /24 and
      shorter prefixes.


      7.2 Definitions


      7.2.1 Lame Delegation


      A delegation is defined as being lame if all of the in-addr.arpa zones
      for a given name server of a specific network registration are lame.
An
      in- addr.arpa zone is defined as lame when ARIN requests the SOA
record
      from the name server registered in whois, but does not receive an
answer.


      7.2.2 Partially Lame Delegation


      A delegation is defined as being partially lame if at least one in-
      addr.arpa zone for a given name server of a specific network
      registration is lame. An in- addr.arpa zone is defined as lame when
ARIN
      requests the SOA record from the name server registered in whois, but
      does not receive an answer.


      7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA


      ARIN will actively identify lame and partially lame DNS name server
      (s) for reverse address delegations associated with address blocks
      allocated, assigned or administered by ARIN. Upon identification of a
      lame or partially 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 or partially lame delegation, ARIN
      will update the WHOIS database records resulting in the removal of
lame
      or partially lame DNS servers. ARIN's actions in resolving lame and
      partially lame delegations is governed by the procedures set forth in
      (Lame-Ref).


      7.4 References


      (Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
      reference/lame_delegations.html




      STOP NEW Section




      Rationale:


      Current policy only considers an Org's delegation being deemed lame if
      all of in-addr.arpa zones for a given name server of a specific
network
      registration are lame. Lame is defined when ARIN tests an in-addr.arpa
      zone by requesting the SOA record from the name server registered in
      whois, but does not receive an answer. If deemed lame, ARIN has an
      appropriate procedure for contacting the Org and handling the issue as
      per "http://www.arin.net/ reference/lame_delegations.html".


      Unfortunately, the policy does not cover the situation of a so-called
      partially lame delegation. That is, some of the in-addr.arpa zones
      belonging to the network registration return a valid SOA upon testing,
      and some do not. Even if only one /24 in-addr.arpa reverse tests comes
      back as lame, it is my opinion that this still taints the reputation
of
      entire network registration. IPs belonging to that lame in-addr.arpa
      zone will cause query timeouts to 3rd party dns resolvers, both public
      and private. These excessive timeouts in my opinion can harm the
overall
      well-being of reverse dns functionality throughout the internet. The
      only way to prevent such harm is for ARIN to not delegate reverse
      authority to the so-called partially lame dns server as registered in
      whois. That is the purpose of this policy proposal, to consider
partial
      lameness with the same prejudice as traditionally defined lameness.
      Org's who are partially lame should be contacted by ARIN and lame
      in-addr.arpa zones should be resolved as the procedures per
      "http://www.arin.net/reference/ lame_delegations.html" dictate.


      Timetable for implementation: June 1, 2008


      _______________________________________________
      PPML
      You are receiving this message because you are subscribed to the ARIN
Public Policy
      Mailing List (PPML at arin.net).
      Unsubscribe or manage your mailing list subscription at:
      http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
Member Services
      Help Desk at 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 (PPML at arin.net).
    Unsubscribe or manage your mailing list subscription at:
    http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
Member Services
    Help Desk at info at arin.net if you experience any issues.


  Thanks,
  John Von Essen
  (800) 248-1736 ext 100
  john at quonix.net



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070912/2bb6b2ba/attachment.htm>

From randy at psg.com  Wed Sep 12 15:04:40 2007
From: randy at psg.com (Randy Bush)
Date: Wed, 12 Sep 2007 09:04:40 -1000
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <a06240807c30dde26c70f@[192.168.1.100]>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>	<46E8007C.6010507@arin.net>
	<a06240807c30dde26c70f@[192.168.1.100]>
Message-ID: <46E83848.1020800@psg.com>

perhaps, instead of trying to specify all the details, which will be
painful, and other negative experiences, go the opposite direction. say
that things should work thusly for the user (e.g. no misconfigs causing
delays), and leave it to staff to work out how/what to do operationally.

randy


From john at quonix.net  Wed Sep 12 15:24:56 2007
From: john at quonix.net (John Von Essen)
Date: Wed, 12 Sep 2007 15:24:56 -0400
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <73394C3E0701EB4F8AAD37FCFF1BDF4C011BD129@email>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com><46E8007C.6010507@arin.net>
	<46E81590.9040304@internap.com>
	<01623EDD-5F06-408D-B5BA-32C293A5BD66@quonix.net>
	<73394C3E0701EB4F8AAD37FCFF1BDF4C011BD129@email>
Message-ID: <C29A97DA-60D6-4FAA-825F-DD80CADA511C@quonix.net>

Huh?

If you have no dns at all, you would be a lame delegation because  
every in-addr.arpa in your assigned net range would be lame (i.e.  
does not return SOA).

If you have a DNS server, but dont have any in-addr.arpa's configured  
for your net range to return SOA, your delegation is lame (i.e.  
again, does not return SOA).

My modification is the scenario where you have DNS servers, their  
alive, and they return SOA for some in-addr.arpa's in your net range,  
but not all. Some in-addr.arpa's in your ARIN assigned range are lame  
and do not return SOA, hence your delegation is considered partially  
lame. Right now, under current policy, this state of being partially  
lame is not addressed, and you as the Org will not be warned in any  
way or requested to resolve the issue in any way. That is what I have  
a problem with. My opinion is a partially lame dns server for an  
assigned IP block is still a bad thing, and ARIN policy should state  
this, and have the same procedure in place to enforce resolution of  
the lameness of those in-addr.arpa zones.

-John

On Sep 12, 2007, at 3:10 PM, Davey, George wrote:

> So No dns is OK?
> Lame DNS is not?
> Is this what you are saying?
>
>
>
>
>
>
>
> George Davey, B.S., M.C.S.E.
> Network Administrator
> 3200 Grand Avenue
> Des Moines, IA  50312
> 515.271.1544
> FAX 515.271.7063
> george.davey at dmu.edu
> www.dmu.edu
>
>
>
>
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On  
> Behalf Of John Von Essen
> Sent: Wednesday, September 12, 2007 12:25 PM
> To: Public Policy Mailing List
> Subject: Re: [ppml] Policy Proposal: Modification to Reverse  
> Mapping Policy
>
> Yes,
>
> I have several examples of what I call partially lame dns servers.  
> Let me put together a more in-depth list with prefixes from several  
> different providers, and I'll email it to the list later today.
>
> -John
>
> On Sep 12, 2007, at 12:36 PM, Scott Leibrand wrote:
>
>> John,
>>
>> Do you have any examples of Partially Lame Delegations (or, to use
>> Brian's slightly more precise terminology, Lame Zone Delegations to a
>> non-Lame Server)?  I'm not opposed to your policy rewrite, but I'm as
>> yet unconvinced that we have a real life non-hypothetical problem  
>> that
>> can't be fixed by application of current policies and procedures.
>>
>> Thanks,
>> Scott
>>
>> Member Services wrote:
>>> ARIN received the following policy proposal. In accordance with  
>>> the ARIN
>>> Internet Resource Policy Evaluation Process, the proposal is being
>>> posted to the ARIN Public Policy Mailing List (PPML) and being  
>>> placed on
>>> ARIN's website.
>>>
>>> The ARIN Advisory Council (AC) will review this proposal at their  
>>> next
>>> regularly scheduled meeting. The AC may decide to:
>>>
>>>     1. Accept the proposal as a formal policy proposal as  
>>> written. If the
>>> AC accepts the proposal, it will be posted as a formal policy  
>>> proposal
>>> to PPML and it will be presented at a Public Policy Meeting.
>>>
>>>     2. Postpone their decision regarding the proposal until the next
>>> regularly scheduled AC meeting in order to work with the author.  
>>> The AC
>>> will work with the author to clarify, combine or divide the  
>>> proposal. At
>>> their following meeting the AC will accept or not accept the  
>>> proposal.
>>>
>>>     3. Not accept the proposal. If the AC does not accept the  
>>> proposal,
>>> the AC will explain their decision. If a proposal is not  
>>> accepted, then
>>> the author may elect to use the petition process to advance their
>>> proposal. If the author elects not to petition or the  petition  
>>> fails,
>>> then the proposal will be closed.
>>>
>>> The AC will assign shepherds in the near future. ARIN will  
>>> provide the
>>> names of the shepherds to the community via the PPML.
>>>
>>> In the meantime, the AC invites everyone to comment on this  
>>> 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 Internet Resource Policy Evaluation Process can be found  
>>> at:
>>> http://www.arin.net/policy/irpep.html
>>>
>>> Mailing list subscription information can be found at:
>>> http://www.arin.net/mailing_lists/
>>>
>>> Regards,
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>> ## * ##
>>>
>>>
>>> Policy Proposal Name: Modification to Reverse Mapping Policy
>>>
>>> Author: John Von Essen
>>>
>>> Proposal Version: 1.0
>>>
>>> Submission Date: September 11, 2007
>>>
>>> Proposal type: modify
>>>
>>> Policy term: permanent
>>>
>>> Policy statement:
>>>
>>> I am proposing a modification to section 7 of the IPv4 policy  
>>> such that
>>> a more precise definition and overview of lameness is described.
>>> Below is how I think section 7 should be re-written.
>>>
>>> START NEW Section
>>>
>>> 7. Reverse Mapping
>>>
>>> 7.1. Maintaining IN-ADDRs
>>>
>>> All ISPs receiving one or more distinct /16 CIDR blocks of IP  
>>> addresses
>>> from ARIN will be responsible for maintaining all IN- ADDR.ARPA  
>>> domain
>>> records for their respective customers. For blocks smaller than / 
>>> 16, and
>>> for the segment of larger blocks which start or end with a CIDR  
>>> prefix
>>> longer than /16, ARIN can maintain IN-ADDRs through the use of  
>>> the SWIP
>>> (Reallocate and Reassign) templates or the Netmod template for / 
>>> 24 and
>>> shorter prefixes.
>>>
>>> 7.2 Definitions
>>>
>>> 7.2.1 Lame Delegation
>>>
>>> A delegation is defined as being lame if all of the in-addr.arpa  
>>> zones
>>> for a given name server of a specific network registration are  
>>> lame. An
>>> in- addr.arpa zone is defined as lame when ARIN requests the SOA  
>>> record
>>> from the name server registered in whois, but does not receive an  
>>> answer.
>>>
>>> 7.2.2 Partially Lame Delegation
>>>
>>> A delegation is defined as being partially lame if at least one in-
>>> addr.arpa zone for a given name server of a specific network
>>> registration is lame. An in- addr.arpa zone is defined as lame  
>>> when ARIN
>>> requests the SOA record from the name server registered in whois,  
>>> but
>>> does not receive an answer.
>>>
>>> 7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA
>>>
>>> ARIN will actively identify lame and partially lame DNS name server
>>> (s) for reverse address delegations associated with address blocks
>>> allocated, assigned or administered by ARIN. Upon identification  
>>> of a
>>> lame or partially 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 or partially lame delegation,  
>>> ARIN
>>> will update the WHOIS database records resulting in the removal  
>>> of lame
>>> or partially lame DNS servers. ARIN's actions in resolving lame and
>>> partially lame delegations is governed by the procedures set  
>>> forth in
>>> (Lame-Ref).
>>>
>>> 7.4 References
>>>
>>> (Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
>>> reference/lame_delegations.html
>>>
>>>
>>> STOP NEW Section
>>>
>>>
>>> Rationale:
>>>
>>> Current policy only considers an Org's delegation being deemed  
>>> lame if
>>> all of in-addr.arpa zones for a given name server of a specific  
>>> network
>>> registration are lame. Lame is defined when ARIN tests an in- 
>>> addr.arpa
>>> zone by requesting the SOA record from the name server registered in
>>> whois, but does not receive an answer. If deemed lame, ARIN has an
>>> appropriate procedure for contacting the Org and handling the  
>>> issue as
>>> per "http://www.arin.net/ reference/lame_delegations.html".
>>>
>>> Unfortunately, the policy does not cover the situation of a so- 
>>> called
>>> partially lame delegation. That is, some of the in-addr.arpa zones
>>> belonging to the network registration return a valid SOA upon  
>>> testing,
>>> and some do not. Even if only one /24 in-addr.arpa reverse tests  
>>> comes
>>> back as lame, it is my opinion that this still taints the  
>>> reputation of
>>> entire network registration. IPs belonging to that lame in-addr.arpa
>>> zone will cause query timeouts to 3rd party dns resolvers, both  
>>> public
>>> and private. These excessive timeouts in my opinion can harm the  
>>> overall
>>> well-being of reverse dns functionality throughout the internet. The
>>> only way to prevent such harm is for ARIN to not delegate reverse
>>> authority to the so-called partially lame dns server as  
>>> registered in
>>> whois. That is the purpose of this policy proposal, to consider  
>>> partial
>>> lameness with the same prejudice as traditionally defined lameness.
>>> Org's who are partially lame should be contacted by ARIN and lame
>>> in-addr.arpa zones should be resolved as the procedures per
>>> "http://www.arin.net/reference/ lame_delegations.html" dictate.
>>>
>>> Timetable for implementation: June 1, 2008
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the  
>>> ARIN Public Policy
>>> Mailing List (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the  
>>> ARIN Member Services
>>> Help Desk at 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 (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the  
>> ARIN Member Services
>> Help Desk at info at arin.net if you experience any issues.
>
> Thanks,
> John Von Essen
> (800) 248-1736 ext 100
> john at quonix.net
>
>

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070912/fafcf1f0/attachment.htm>

From davids at webmaster.com  Wed Sep 12 15:34:56 2007
From: davids at webmaster.com (David Schwartz)
Date: Wed, 12 Sep 2007 12:34:56 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <02cd01c7f555$8556c4f0$966600d0@accountsrec>
Message-ID: <MDEHLPKNGKAHNMBLJOLKGEAPGMAC.davids@webmaster.com>


> I oppose this proposal, this is an operational issue.
>
> Regards,
> Linda Werner
> Satellite Communication Systems, Inc.

I think reverse address delegation is one area where ARIN has to have
operational policies. We avoid operation issues with respect to address
space because we don't care what people use their address space for. But
reverse DNS delegation has a specific operational use and when ARIN refers a
person to a particular server for reverse DNS delegation, it has an
obligation to make sure that delegation works.

To those people who say ARIN has no business policing this, I ask you this:
Suppose some company starting listing your nameservers as secondaries for
all of their blocks. Would you want ARIN to be powerless to do anything when
it's ARIN's delegation to your nameserver's that's hurting you?

This is a case where ARIN does something other than assigning addresses. It
is something that is operational and has the potential to hurt people if not
done right. ARIN should not be required to blindly follow the demands of
those who qualify for address space.

IOW, just because you qualify for address space doesn't mean ARIN should be
required to delegate the corresponding reverse zones anywhere you ask them
to.

DS




From randy at psg.com  Wed Sep 12 15:55:07 2007
From: randy at psg.com (Randy Bush)
Date: Wed, 12 Sep 2007 09:55:07 -1000
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <02cd01c7f555$8556c4f0$966600d0@accountsrec>
References: <02cd01c7f555$8556c4f0$966600d0@accountsrec>
Message-ID: <46E8441B.1090408@psg.com>

> I oppose this proposal, this is an operational issue.

we should stop giving out ip addresses.  they're only operational.  this
will leave us free to focus on internet governance, net politics, and
the digital divide.

randy


From michael at rancid.berkeley.edu  Wed Sep 12 16:04:18 2007
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Wed, 12 Sep 2007 13:04:18 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKGEAPGMAC.davids@webmaster.com>
References: <MDEHLPKNGKAHNMBLJOLKGEAPGMAC.davids@webmaster.com>
Message-ID: <46E84642.8050602@rancid.berkeley.edu>

David Schwartz wrote:

> To those people who say ARIN has no business policing this, I ask you this:
> Suppose some company starting listing your nameservers as secondaries for
> all of their blocks. Would you want ARIN to be powerless to do anything when
> it's ARIN's delegation to your nameserver's that's hurting you?

I believe the current policy deals with this situation.  Once the policy 
went into place, I was able to deal with exactly this issue (with some 
escalation on my part).

michael


From kkargel at polartel.com  Wed Sep 12 16:58:27 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 12 Sep 2007 15:58:27 -0500
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <46E84642.8050602@rancid.berkeley.edu>
References: <MDEHLPKNGKAHNMBLJOLKGEAPGMAC.davids@webmaster.com>
	<46E84642.8050602@rancid.berkeley.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670744D@mail>

 
They could do that now and there policies in place to deal with it.
Isn't this why you have recursion policies in your name servers?

If ARIN (or any other agency)listed a foreign domain or netblock as
authoritative on my name servers effectively that domain would be broken
as my name servers would not provide meaningful responces.  I am sure
the domain owner would get it fixed straight away.


> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Michael Sinatra
> Sent: Wednesday, September 12, 2007 3:04 PM
> To: davids at webmaster.com
> Cc: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal: Modification to Reverse 
> Mapping Policy
> 
> David Schwartz wrote:
> 
> > To those people who say ARIN has no business policing this, 
> I ask you this:
> > Suppose some company starting listing your nameservers as 
> secondaries 
> > for all of their blocks. Would you want ARIN to be powerless to do 
> > anything when it's ARIN's delegation to your nameserver's 
> that's hurting you?
> 
> I believe the current policy deals with this situation.  Once 
> the policy went into place, I was able to deal with exactly 
> this issue (with some escalation on my part).
> 
> michael
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at info at arin.net if you 
> experience any issues.
> 


From dean at av8.com  Wed Sep 12 17:02:26 2007
From: dean at av8.com (Dean Anderson)
Date: Wed, 12 Sep 2007 17:02:26 -0400 (EDT)
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <46E8007C.6010507@arin.net>
Message-ID: <Pine.LNX.4.44.0709121642050.12099-100000@citation2.av8.net>


This proposal is misguided since it decides lameness on a per-nameserver 
basis rather than a per zone basis.

A DNS zone is working if even one nameserver responds to queries for
that zone.

It doesn't matter if a nameserver serves multiple zones, some of which
it actually is configured to serve, and thus is not lame for some zones.  
Nor does it matter if a nameserver serves multiple zones, and does not
respond for any of those zones.

The current policy properly identifies lameness by zone, and removes
delegation records when the _zone_ is lame. A zone is only lame when
_no_ nameservers respond to queries for that zone.  In that case, ARIN
can, after appropriate steps, remove delegation records.  The current
policy is proper so that ARIN nameservers can give out NXDomain
responses (which are also cached) for those zones that won't be
supported anyway.

However, if even one nameserver responds for a zone, there is no reason
for ARIN to take any steps at all: The zone is not lame.  It is not
ARIN's responibility to monitor the uptime of all delegated namesevers,
or otherwise ensure that all nameservers are working for a zone, or for
any group of zones.  There is no harm to ARIN if the zone is not lame,
but some of the nameservers for that zone are not working.

If some other group wants to monitor nameservers and report failures,
that is up to them. But monitoring nameservers isn't a task that belongs
to ARIN, beyond the issue of zone lameness.

Therefore, this policy should not be accepted.


Dean Anderson 
Av8 Internet, Inc 
(a longtime DNSEXT WG and DNSOP WG participant, and discoverer of
various DNS-related scams.)


On Wed, 12 Sep 2007, Member Services wrote:
> 
> Policy Proposal Name: Modification to Reverse Mapping Policy
> 
> Author: John Von Essen
> 
> Proposal Version: 1.0
> 
> Submission Date: September 11, 2007
> 
> Proposal type: modify
> 
> Policy term: permanent
> 
> Policy statement:
> 
> I am proposing a modification to section 7 of the IPv4 policy such that
> a more precise definition and overview of lameness is described.
> Below is how I think section 7 should be re-written.
> 
> START NEW Section
> 
> 7. Reverse Mapping
> 
> 7.1. Maintaining IN-ADDRs
> 
> All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
> from ARIN will be responsible for maintaining all IN- ADDR.ARPA domain
> records for their respective customers. For blocks smaller than /16, and
> for the segment of larger blocks which start or end with a CIDR prefix
> longer than /16, ARIN can maintain IN-ADDRs through the use of the SWIP
> (Reallocate and Reassign) templates or the Netmod template for /24 and
> shorter prefixes.
> 
> 7.2 Definitions
> 
> 7.2.1 Lame Delegation
> 
> A delegation is defined as being lame if all of the in-addr.arpa zones
> for a given name server of a specific network registration are lame. An
> in- addr.arpa zone is defined as lame when ARIN requests the SOA record
> from the name server registered in whois, but does not receive an answer.
> 
> 7.2.2 Partially Lame Delegation
> 
> A delegation is defined as being partially lame if at least one in-
> addr.arpa zone for a given name server of a specific network
> registration is lame. An in- addr.arpa zone is defined as lame when ARIN
> requests the SOA record from the name server registered in whois, but
> does not receive an answer.
> 
> 7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA
> 
> ARIN will actively identify lame and partially lame DNS name server
> (s) for reverse address delegations associated with address blocks
> allocated, assigned or administered by ARIN. Upon identification of a
> lame or partially 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 or partially lame delegation, ARIN
> will update the WHOIS database records resulting in the removal of lame
> or partially lame DNS servers. ARIN's actions in resolving lame and
> partially lame delegations is governed by the procedures set forth in
> (Lame-Ref).
> 
> 7.4 References
> 
> (Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
> reference/lame_delegations.html
> 
> 
> STOP NEW Section
> 
> 
> Rationale:
> 
> Current policy only considers an Org's delegation being deemed lame if
> all of in-addr.arpa zones for a given name server of a specific network
> registration are lame. Lame is defined when ARIN tests an in-addr.arpa
> zone by requesting the SOA record from the name server registered in
> whois, but does not receive an answer. If deemed lame, ARIN has an
> appropriate procedure for contacting the Org and handling the issue as
> per "http://www.arin.net/ reference/lame_delegations.html".
> 
> Unfortunately, the policy does not cover the situation of a so-called
> partially lame delegation. That is, some of the in-addr.arpa zones
> belonging to the network registration return a valid SOA upon testing,
> and some do not. Even if only one /24 in-addr.arpa reverse tests comes
> back as lame, it is my opinion that this still taints the reputation of
> entire network registration. IPs belonging to that lame in-addr.arpa
> zone will cause query timeouts to 3rd party dns resolvers, both public
> and private. These excessive timeouts in my opinion can harm the overall
> well-being of reverse dns functionality throughout the internet. The
> only way to prevent such harm is for ARIN to not delegate reverse
> authority to the so-called partially lame dns server as registered in
> whois. That is the purpose of this policy proposal, to consider partial
> lameness with the same prejudice as traditionally defined lameness.
> Org's who are partially lame should be contacted by ARIN and lame
> in-addr.arpa zones should be resolved as the procedures per
> "http://www.arin.net/reference/ lame_delegations.html" dictate.
> 
> Timetable for implementation: June 1, 2008
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




From sleibrand at internap.com  Wed Sep 12 17:15:19 2007
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 12 Sep 2007 14:15:19 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <Pine.LNX.4.44.0709121642050.12099-100000@citation2.av8.net>
References: <Pine.LNX.4.44.0709121642050.12099-100000@citation2.av8.net>
Message-ID: <46E856E7.2050108@internap.com>

Dean Anderson wrote:
> This proposal is misguided since it decides lameness on a per-nameserver 
> basis rather than a per zone basis.
>
> A DNS zone is working if even one nameserver responds to queries for
> that zone.
>
> It doesn't matter if a nameserver serves multiple zones, some of which
> it actually is configured to serve, and thus is not lame for some zones.  
> Nor does it matter if a nameserver serves multiple zones, and does not
> respond for any of those zones.
>   
True.

> The current policy properly identifies lameness by zone, and removes
> delegation records when the _zone_ is lame. A zone is only lame when
> _no_ nameservers respond to queries for that zone.  In that case, ARIN
> can, after appropriate steps, remove delegation records.

Not quite.  ARIN's current operational policy requires that all zones 
for a given registration be lame before considering the registration 
lame, and triggering the notification and removal process.  If a 
registrant gets a /22, and only sets up reverse DNS for one /24, ARIN 
does not take action against the other three zones (/24's).  This seems 
to be an artifact of the fact that you define a single set of DNS server 
per registration, not per zone (/24, /16, or /8), so ARIN only takes 
action at the level of the registration, not the level of the zone 
(where the problems actually arise).

> The current
> policy is proper so that ARIN nameservers can give out NXDomain
> responses (which are also cached) for those zones that won't be
> supported anyway.
>
> However, if even one nameserver responds for a zone, there is no reason
> for ARIN to take any steps at all: The zone is not lame.  It is not
> ARIN's responibility to monitor the uptime of all delegated namesevers,
> or otherwise ensure that all nameservers are working for a zone, or for
> any group of zones.  There is no harm to ARIN if the zone is not lame,
> but some of the nameservers for that zone are not working.
>   

Agreed.

-Scott


From tedm at ipinc.net  Wed Sep 12 17:48:22 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 12 Sep 2007 14:48:22 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <46E856E7.2050108@internap.com>
Message-ID: <NABBJOELMNGNJNGPKDDOAEMOHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Scott Leibrand
>Sent: Wednesday, September 12, 2007 2:15 PM
>To: Dean Anderson
>Cc: ppml at arin.net
>Subject: Re: [ppml] Policy Proposal: Modification to Reverse Mapping
>Policy
>
>
>
>Not quite.  ARIN's current operational policy requires that all zones 
>for a given registration be lame before considering the registration 
>lame, and triggering the notification and removal process.  

>If a 
>registrant gets a /22, and only sets up reverse DNS for one /24, ARIN 
>does not take action against the other three zones (/24's).  This seems 
>to be an artifact of the fact that you define a single set of DNS server 
>per registration, not per zone (/24, /16, or /8),

No, not at all.  ARIN allows people to request more subnets than their
existing allocation, if they are returning subnets (for purposes of
aggregation)  This implies some of those /24's are going to be unused.

A network that does not have all /24's in use might choose to make the
/24's in their inventory that are not yet deployed, lame.  This would
cause anyone on the Internet who happens to misconfigure
something that sends data to those numbers, to immediately have problems.
Since those subnets are not in use, this would be desired behavior.

Would you rather have them break their /22 into multiple BGP advertisements
and only advertise their in-use subnets instead of an aggregated /22?

Ted


From david.kessens at nsn.com  Wed Sep 12 18:37:36 2007
From: david.kessens at nsn.com (David Kessens)
Date: Wed, 12 Sep 2007 15:37:36 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <20070912133422.GA23451@ussenterprise.ufp.org>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<20070912025232.GA76366@ussenterprise.ufp.org>
	<20070912042907.GD2901@nsn.com>
	<20070912133422.GA23451@ussenterprise.ufp.org>
Message-ID: <20070912223736.GE15069@nsn.com>


Leo,

On Wed, Sep 12, 2007 at 09:34:22AM -0400, Leo Bicknell wrote:
> In a message written on Tue, Sep 11, 2007 at 09:29:07PM -0700, David Kessens wrote:
> > On Tue, Sep 11, 2007 at 10:52:32PM -0400, Leo Bicknell wrote:
> > > With several recent issues staff has indicated a reluctance to take
> > > action if items were not spelled out in the NRPM.  There is at least
> > > one proposal for the next meeting aimed at giving staff more clarity
> > > in the NRPM so they have backing to take action.
> > 
> > This is not something you can fix by means of spelling out more and
> > more operational details in policies. In fact, this would make the
> > problem worse.
> 
> You misunderstood my statement.

I don't think I misunderstood your statement at all (see below).

> I don't want to add operational details to the NRPM, and I think
> the debate about what is a "lame" server only reenforces why that
> is a bad idea.  If there are operational details in the NRPM they
> should be removed.
> 
> However, my fear is that without section 7.2 ARIN staff will feel
> they have no authority to police DNS delegations.

Let's not put things in policies because of fear but because they
actually need to be there. 

ARIN explicitly is entrusted with maintaining the reverse tree for
address blocks that it allocates. I expect them to be capable of doing
the right thing which normally includes not putting in place and/or
removing delegations that don't work etc. Contrary to your fears, not
properly maintaining the tree would mean that they are not doing their
job. The policy process is explicitly not designed to deal with
quality of service issues by ARIN. Let's leave the management of the
reverse tree to professionals instead of the policy makers on this list.

David Kessens
---


From bmanning at vacation.karoshi.com  Wed Sep 12 21:51:51 2007
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 13 Sep 2007 01:51:51 +0000
Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
In-Reply-To: <057C2792-D000-4200-81BA-03BC74E97C40@quonix.net>
References: <NABBJOELMNGNJNGPKDDOEEINHDAA.tedm@ipinc.net>
	<46E709A7.9060105@ca.afilias.info> <46E71DA3.40005@psg.com>
	<46E80498.3010109@ca.afilias.info>
	<057C2792-D000-4200-81BA-03BC74E97C40@quonix.net>
Message-ID: <20070913015151.GA25201@vacation.karoshi.com.>

 there are some people who do this testing already ... we don't do the 
email's any more, since ARIN came into existance...  but we still run the
tests.

--bill


On Wed, Sep 12, 2007 at 11:58:32AM -0400, John Von Essen wrote:
> I agree.
> 
> I have no sympathy for the response of "testing all these in- 
> addr.arpa zones is too much work". Granted, we are only talking  
> about /24 prefixes.
> 
> The entire process can be easily automated, and that includes the SOA  
> query testing to delegated DNS servers for an Org's address block,  
> updating an internal tracking database, and even the process of  
> emailing the Org's POC for DNS. The Org's that get emailed the  
> warning could even be given a link to click when they have resolved  
> the issue. That link would automatically re-check, and if SOA  
> response is valid, would automatically remove them from the database  
> of "delinquents".
> 
> So for the Org's that fix things in a timely fashion following the  
> automatic email - ARIN staff will never even have to get involved.  
> Staff would only get involved with those Org's that dont respond to  
> the initial emails.
> 
> -john
> 
> 
> On Sep 12, 2007, at 11:24 AM, Brian Dickson wrote:
> 
> >Randy Bush wrote:
> >>arin delegates 42.666.in-addr.arpa to the member isp. the servers
> >>properly respond for that delegation.  this seems to be about as  
> >>far as
> >>current policy goes; though there are reported gaps in  
> >>implementation.
> >>
> >>the op wants us to say that, if the delegatee further delegates
> >>sub-zones, then the service for those sub-zones must not be lame.
> >>
> >>aside from issues of whether the community has the right to  
> >>descend into
> >>the delegation, how would we text the sub-delegations?  if they  
> >>are on
> >>byte boundaries, we can probe for them.  but goddesses help us if  
> >>they
> >>use rfc 2317.  and is it our prerogative to probe 256 sub- 
> >>delegations of
> >>a /16?  64k of a /8?  and how many of a /32 in ipv6 space?
> >>
> >The "probing" is in fact, an exercise in tree-walking.
> >
> >Writing a script to handle this should be within the capabilities of
> >ARIN, given the scope of other
> >tools they no doubt need to handle administration of address  
> >assignments.
> >
> >The basic tree-walking should be limited to following delegations of
> >expected form (numeric subzones
> >within the expected ranges, either 0-1 or 0-255). Those are the only
> >sub-delegations "of interest",
> >i.e. which would otherwise have been directly delegated by ARIN.
> >
> >Optimizations can be done, since the expectation is one of positive
> >responses to SOA queries.
> >Low timeouts may generate false negatives, but no false positives.
> >Re-testing false negatives with
> >longer timeouts, produces the true negatives.
> >
> >The *main* question is, since in rfc 2317 the distance from ARIN in
> >delegations can be >2,
> >what should be done?
> >
> >I think the classic "him or you" answer scales best. Arin requests the
> >delegatee to fix the subordinate,
> >or have their delegation pulled, with the recommendation that they use
> >the same tactic.
> >
> >At the leaf, the broken delegatee must either fix the problem or  
> >get pruned.
> >If the delegator does not prune a still-broken leaf, then *his*
> >delegator must do the same, or face
> >being pruned him/herself. Etc.
> >
> >The responsibility with ARIN rests only in running test scripts, and
> >contacting direct delegatees.
> >All further communication is between third parties, within some set  
> >time
> >frame.
> >
> >I *think* this would be able to be codified in the NRPM, as well as
> >passing the scaling, sanity,
> >and legitimacy/legality tests.
> >
> >Thoughts?
> >
> >Brian Dickson
> >_______________________________________________
> >PPML
> >You are receiving this message because you are subscribed to the  
> >ARIN Public Policy
> >Mailing List (PPML at arin.net).
> >Unsubscribe or manage your mailing list subscription at:
> >http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> >Member Services
> >Help Desk at info at arin.net if you experience any issues.
> 
> Thanks,
> John Von Essen
> (800) 248-1736 ext 100
> john at quonix.net
> 
> 

> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.



From owen at delong.com  Wed Sep 12 22:33:01 2007
From: owen at delong.com (Owen DeLong)
Date: Wed, 12 Sep 2007 19:33:01 -0700
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <NABBJOELMNGNJNGPKDDOKEMIHDAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOKEMIHDAA.tedm@ipinc.net>
Message-ID: <4582F64C-85A8-4F8C-91C8-25F5986F1E2D@delong.com>

Actually, staff would, in my opinion, have greater ability to remove
lame or partially lame delegations and still certainly is free to  
contact
lame server operators or resource holders to encourage them to do
the right thing.

Owen

On Sep 12, 2007, at 11:40 AM, Ted Mittelstaedt wrote:

> In cases where a policy must apply uniformly, it has to be official
> and not an internal staff guideline.
>
> The big problem with taking this out of the NRPM is that unless
> there's sanctions available to enforce correct DNS behavior, the
> staff can't do anything because all the non-compliant network
> operator has to do is say since it's not spelled out in the NRPM,
> you can't do anything to me if I don't do it.
>
> At this point I'm personally not sure any changes need to be made
> at all.  But clearly the OP has a problem and the purpose of this
> list and the policy process is essentially to present problems to
> the community and see what the response is.
>
> Thus I think your proposal is as needed as Johns.  If the membership
> really doesen't want the RIR to bother with this, they will vote your
> policy in.  If not, they will vote John's policy in (whenever it's  
> submitted)
> So let's see what they want to do.
>
> Ted
> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Tuesday, September 11, 2007 8:52 PM
> To: Ted Mittelstaedt
> Cc: John Von Essen; Public Policy Mailing List
> Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy
>
> Ted,
> I believe you miss the point of my proposal. While I do believe that
> ARIN has a role to play in applying the clue bat to lame or  
> partially lame
> ISPs and addressing John's issue, my point is that it belongs in  
> operational
> guidelines to ARIN staff and not in the NRPM.
>
> My proposal talks about what I think belongs in the NRPM and is
> not a direct expression of how I feel about what ARIN staff should or
> should not be doing with respect to this particular issue. I would  
> fully
> support an ACSP recommendation that ARIN address all IN-ADDR
> lameness whether complete or not on any direct assignment. This will
> potentially require ARIN to examine as many as 255 zones in IPv4 for
> a single assignment.
>
> I would oppose any suggestion requiring ARIN to drill down
> to lame delegations made by the ISPs relating to reassignment or
> reallocations made by the ISP because of dramatically increasing
> workload for dramatically decreasing return on investment and
> because there is a limit to the extent to which I believe ARIN should
> engage in telling operators how to run their network (let alone their
> customers' networks).
>
> I will also oppose any policy regarding the operational and/or
> implementation details of lame delegations because I firmly believe
> this is not the role of the NRPM and should be addressed with
> operational procedures and recommendations rather than with
> number resource policies.
>
> Owen
>
> On Sep 11, 2007, at 5:26 PM, Ted Mittelstaedt wrote:
>
>> Yes John you are correct but the way things often work on this  
>> list is someone like Owen will
>> submit a policy to remove something that shouldn't obviously be  
>> removed, the result of
>> which will convert a bunch of fence sitters into proponents of  
>> keeping it.
>> The list membership needs Owens "just kill it" proposal precisely  
>> to have something to
>> vote down. A no vote commits the person voting no, to supporting  
>> the policy.
>> If Owens proposal is voted down, that will destroy all of the  
>> "it's not the RIR's responsibility
>> to enforce sanctions against bad nameserver operators" arguments,  
>> and we can move the discussion
>> to something productive of how to actually fix the problem.
>> Your proposal might be premature - you might find it better to  
>> campaign against Owens
>> proposal first.
>> Ted
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On  
>> Behalf Of John Von Essen
>> Sent: Tuesday, September 11, 2007 4:55 PM
>> To: Public Policy Mailing List
>> Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy
>>
>> I do plan to submit my proposal. My final comment on all of this  
>> is with regards to ARIN's stance on operational issues.
>>
>> I agree ARIN should be careful, but keep in mind ARIN does provide  
>> an operational function of reverse DNS authority delegation.  
>> Because ARIN engages in this very-real activity, policy must exist  
>> to cover its implementation, design, and overall operational health.
>>
>> If ARIN just did AS numbers and IP allocation, and another  
>> organization did reverse delegation, say Network Solutions, then  
>> YES - ARIN should not get involved with operational issues of  
>> reverse DNS. But that fact is ARIN does do reverse DNS delegation.  
>> When I do a dig on an IP, I see alot of ARIN servers in the output!
>>
>> -John
>>
>> On Sep 11, 2007, at 7:21 PM, Azinger, Marla wrote:
>>
>>> I would like to see a proposal that is along the lines of  
>>> clarifying in addition to Owens proposal to just take it away.  
>>> Hopefully we havnt scared John off and he will give a wack at it.
>>>
>>> Cheers!
>>> Marla
>>>
>>> -----Original Message-----
>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On  
>>> Behalf Of
>>> William Herrin
>>> Sent: Tuesday, September 11, 2007 3:32 PM
>>> To: Owen DeLong
>>> Cc: Public Policy Mailing List
>>> Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy
>>>
>>>
>>> On 9/11/07, Owen DeLong <owen at delong.com> wrote:
>>>> 1. Policy Proposal Name: Deprecate Lame Server Policy
>>>> 7. Policy statement:
>>>> Delete section 7 from the NRPM
>>>
>>> Owen,
>>>
>>> Are you sure this is the right way to move on this? If we're  
>>> going to
>>> call ISPs "Local Internet Registries," shouldn't we expect them to
>>> behave as internet registries and do the things that internet
>>> registries do, including reallocation and assignment of the RDNS
>>> attached to every IP address?
>>>
>>> Regards,
>>> Bill Herrin
>>>
>>> --
>>> William D. Herrin herrin at dirtside.com bill at herrin.us
>>> 3005 Crane Dr. Web: <http://bill.herrin.us/>
>>> Falls Church, VA 22042-3004
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the  
>>> ARIN Public Policy
>>> Mailing List (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the  
>>> ARIN Member Services
>>> Help Desk at 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 (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the  
>>> ARIN Member Services
>>> Help Desk at info at arin.net if you experience any issues.
>>
>> Thanks,
>> John Von Essen
>> (800) 248-1736 ext 100
>> john at quonix.net
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the  
>> ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the  
>> ARIN Member Services
>> Help Desk at info at arin.net if you experience any issues.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070912/634aedf1/attachment.htm>

From mysidia at gmail.com  Wed Sep 12 23:37:47 2007
From: mysidia at gmail.com (James Hess)
Date: Wed, 12 Sep 2007 22:37:47 -0500
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <NABBJOELMNGNJNGPKDDOOEMIHDAA.tedm@ipinc.net>
References: <D03E4899F2FB3D4C8464E8C76B3B68B00102FF01@E03MVC4-UKBR.domain1.systemhost.net>
	<NABBJOELMNGNJNGPKDDOOEMIHDAA.tedm@ipinc.net>
Message-ID: <6eb799ab0709122037wbba2d0dgddced2104df30dac@mail.gmail.com>

> This is a rather silly statement.  The entire DNS system depends on
> everyone doing things "one right way".  The TCP/IP protocol itself
> won't work if everyone did their own version.  I could point to numerous
> examples of everyone on the Internet having to do things "one right way"

I consider this reasoning mistaken, because there are differences in
 implementation choices, especially when different software is used:
TCP/IP and DNS are not examples of protocols where every
implementation is 100% identical, there can be substantial
differences between any two valid implementations.

DNS, TCP/IP do not rely on everyone doing things "one right way",
in practice, the good implementations have to be flexible and robust enough
to accept  the minor deviations that do occur, or could occur in newer
versions of the protocol.

(Deviations such as inclusion of an unknown DNS RR type,
or an unknown TCP extension, different ways of picking outgoing
port numbers, TTLs, etc.)

Protocol standards have  optional MAYand SHOULD sections,
in addition to MUST requirements.


Good implementations that follow all MUST requirements of a
well-designed protocol can communicate with other solid implementations
of said protocols that also follow MUST requirements.


It is possible that a implementation of TCP/IP or DNS that misses
some requirements is not sufficiently broken to prevent peers from
communicating.

There are many desirable practices that are not an absolute requirement
given clearly by any standards documents, in many cases the best
practice may be merely a subtle suggestion in a RFC.


This may well be the case with reverse records -- rfc1034/1035 will
say how these records are formulated, if the reverse exists, but there
is no DNS protocol requirement that every IP in the world has an
existent reverse map (particularly not that addresses of hosts that
don't exist will reverse).



> If you want to argue that in-addr.arpa handing is not a requirement for
> DNS and thus is optional, fine.  But arguing to allow everyone to do
> their own thing merely for the sake of being able to do their own thing is
> preposterous on a shared network.

People have the discretion to pick how they interact with the
world; there may be a shared network, but the hosts still belong
to their owner(s).

Provided their choices of implementation are in-line with the relevant
standards, and of good design, they should be able to interoperate on
the shared network.

So long as the parties they need to communicate through/with
can accept their implementation choices.

But if they can't accept those choices, a better reason is needed
than "We didn't come up with the same choice"

--
-J


From john at quonix.net  Thu Sep 13 01:00:53 2007
From: john at quonix.net (John Von Essen)
Date: Thu, 13 Sep 2007 01:00:53 -0400
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <46E81590.9040304@internap.com>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<46E8007C.6010507@arin.net> <46E81590.9040304@internap.com>
Message-ID: <1FD70B23-BC2E-4355-9AF4-531024B3B033@quonix.net>

Below are three Org's that are examples of partially lame. Several in- 
addr.arpa's in their range correctly return an SOA request, but the / 
24 prefixes listed below do not. These three were actually quickly  
gathered by just trial and error. Cavalier is the ISP I have been  
having trouble with, Cogent was a pure guess (I had a feeling they'd  
be doing something wrong somewhere, so I just tested some random  
ranges, and in a few minutes found a few culprits), and Interland is  
a large hosting provider. Took about 10 minutes to find these. If I  
had all day, I could probably find many more.



Cavalier Telephone
Ord ID: CTLL
NetRange:   76.160.0.0 - 76.161.255.255
NameServer: DNS01.CAVTEL.NET
NameServer: DNS02.CAVTEL.NET
Lame in-addr.arpa zones for Org CTLL:
76.161.193.0/24 - Is advertised by AS16810
76.161.194.0/24 - Is advertised by AS16810
76.161.195.0/24 - Is advertised by AS16810
and there are more


Cogent Communications
Ord ID: COGC
NetRange:   66.250.0.0 - 66.250.255.255
NameServer: AUTH1.DNS.COGENTCO.COM
NameServer: AUTH2.DNS.COGENTCO.COM
Lame in-addr.arpa zones for Org COGC:
66.250.60.0/24 - Is advertised by AS174
66.250.61.0/24 - Is advertised by AS174
and there are more


Interland, Inc.
Org ID: INTD
NetRange:   209.237.128.0 - 209.237.191.255
NameServer: A.NS.MYREGISTEREDSITE.COM
NameServer: B.NS.MYREGISTEREDSITE.COM
Lame in-addr.arpa zones for Org INTD:
209.237.139.0/24 - Is advertised by AS36476
209.237.140.0/24 - Is advertised by AS36476
and there are more



-John


On Sep 12, 2007, at 12:36 PM, Scott Leibrand wrote:

> John,
>
> Do you have any examples of Partially Lame Delegations (or, to use
> Brian's slightly more precise terminology, Lame Zone Delegations to a
> non-Lame Server)?  I'm not opposed to your policy rewrite, but I'm as
> yet unconvinced that we have a real life non-hypothetical problem that
> can't be fixed by application of current policies and procedures.
>
> Thanks,
> Scott
>
> Member Services wrote:
>> ARIN received the following policy proposal. In accordance with  
>> the ARIN
>> Internet Resource Policy Evaluation Process, the proposal is being
>> posted to the ARIN Public Policy Mailing List (PPML) and being  
>> placed on
>> ARIN's website.
>>
>> The ARIN Advisory Council (AC) will review this proposal at their  
>> next
>> regularly scheduled meeting. The AC may decide to:
>>
>>     1. Accept the proposal as a formal policy proposal as written.  
>> If the
>> AC accepts the proposal, it will be posted as a formal policy  
>> proposal
>> to PPML and it will be presented at a Public Policy Meeting.
>>
>>     2. Postpone their decision regarding the proposal until the next
>> regularly scheduled AC meeting in order to work with the author.  
>> The AC
>> will work with the author to clarify, combine or divide the  
>> proposal. At
>> their following meeting the AC will accept or not accept the  
>> proposal.
>>
>>     3. Not accept the proposal. If the AC does not accept the  
>> proposal,
>> the AC will explain their decision. If a proposal is not accepted,  
>> then
>> the author may elect to use the petition process to advance their
>> proposal. If the author elects not to petition or the  petition  
>> fails,
>> then the proposal will be closed.
>>
>> The AC will assign shepherds in the near future. ARIN will provide  
>> the
>> names of the shepherds to the community via the PPML.
>>
>> In the meantime, the AC invites everyone to comment on this  
>> 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 Internet Resource Policy Evaluation Process can be found at:
>> http://www.arin.net/policy/irpep.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: Modification to Reverse Mapping Policy
>>
>> Author: John Von Essen
>>
>> Proposal Version: 1.0
>>
>> Submission Date: September 11, 2007
>>
>> Proposal type: modify
>>
>> Policy term: permanent
>>
>> Policy statement:
>>
>> I am proposing a modification to section 7 of the IPv4 policy such  
>> that
>> a more precise definition and overview of lameness is described.
>> Below is how I think section 7 should be re-written.
>>
>> START NEW Section
>>
>> 7. Reverse Mapping
>>
>> 7.1. Maintaining IN-ADDRs
>>
>> All ISPs receiving one or more distinct /16 CIDR blocks of IP  
>> addresses
>> from ARIN will be responsible for maintaining all IN- ADDR.ARPA  
>> domain
>> records for their respective customers. For blocks smaller than / 
>> 16, and
>> for the segment of larger blocks which start or end with a CIDR  
>> prefix
>> longer than /16, ARIN can maintain IN-ADDRs through the use of the  
>> SWIP
>> (Reallocate and Reassign) templates or the Netmod template for /24  
>> and
>> shorter prefixes.
>>
>> 7.2 Definitions
>>
>> 7.2.1 Lame Delegation
>>
>> A delegation is defined as being lame if all of the in-addr.arpa  
>> zones
>> for a given name server of a specific network registration are  
>> lame. An
>> in- addr.arpa zone is defined as lame when ARIN requests the SOA  
>> record
>> from the name server registered in whois, but does not receive an  
>> answer.
>>
>> 7.2.2 Partially Lame Delegation
>>
>> A delegation is defined as being partially lame if at least one in-
>> addr.arpa zone for a given name server of a specific network
>> registration is lame. An in- addr.arpa zone is defined as lame  
>> when ARIN
>> requests the SOA record from the name server registered in whois, but
>> does not receive an answer.
>>
>> 7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA
>>
>> ARIN will actively identify lame and partially lame DNS name server
>> (s) for reverse address delegations associated with address blocks
>> allocated, assigned or administered by ARIN. Upon identification of a
>> lame or partially 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 or partially lame delegation, ARIN
>> will update the WHOIS database records resulting in the removal of  
>> lame
>> or partially lame DNS servers. ARIN's actions in resolving lame and
>> partially lame delegations is governed by the procedures set forth in
>> (Lame-Ref).
>>
>> 7.4 References
>>
>> (Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
>> reference/lame_delegations.html
>>
>>
>> STOP NEW Section
>>
>>
>> Rationale:
>>
>> Current policy only considers an Org's delegation being deemed  
>> lame if
>> all of in-addr.arpa zones for a given name server of a specific  
>> network
>> registration are lame. Lame is defined when ARIN tests an in- 
>> addr.arpa
>> zone by requesting the SOA record from the name server registered in
>> whois, but does not receive an answer. If deemed lame, ARIN has an
>> appropriate procedure for contacting the Org and handling the  
>> issue as
>> per "http://www.arin.net/ reference/lame_delegations.html".
>>
>> Unfortunately, the policy does not cover the situation of a so-called
>> partially lame delegation. That is, some of the in-addr.arpa zones
>> belonging to the network registration return a valid SOA upon  
>> testing,
>> and some do not. Even if only one /24 in-addr.arpa reverse tests  
>> comes
>> back as lame, it is my opinion that this still taints the  
>> reputation of
>> entire network registration. IPs belonging to that lame in-addr.arpa
>> zone will cause query timeouts to 3rd party dns resolvers, both  
>> public
>> and private. These excessive timeouts in my opinion can harm the  
>> overall
>> well-being of reverse dns functionality throughout the internet. The
>> only way to prevent such harm is for ARIN to not delegate reverse
>> authority to the so-called partially lame dns server as registered in
>> whois. That is the purpose of this policy proposal, to consider  
>> partial
>> lameness with the same prejudice as traditionally defined lameness.
>> Org's who are partially lame should be contacted by ARIN and lame
>> in-addr.arpa zones should be resolved as the procedures per
>> "http://www.arin.net/reference/ lame_delegations.html" dictate.
>>
>> Timetable for implementation: June 1, 2008
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the  
>> ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the  
>> ARIN Member Services
>> Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070913/35f4f0f2/attachment.htm>

From michel at arneill-py.sacramento.ca.us  Thu Sep 13 01:37:25 2007
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Wed, 12 Sep 2007 22:37:25 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <1712.1188707832@sa.vix.com>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org><D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com><DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
Message-ID: <DD7FE473A8C3C245ADA2A2FE1709D90B1C8E65@server2003.arneill-py.sacramento.ca.us>

Hi Paul,

>> Michel Py wrote:
>> - It never delivered initial promises, such as aggregation (the
>> "8K DFZ"). In their great wisdom, the IETF pushed the protocol
>> out with the promise that they will deliver the missing features
>> (such as multihoming and effortless renumbering) later.

> Paul Vixie wrote:
> agreed.

>> Problem, nobody figured it out.

> disagreed.  see A6, DNAME, bitstring labels, and 8+8.

I won't comment on A6, DNAME or bitstring labels but I have something to
say about 8+8/GSE: Long after it was shot down in flames, I came up with
a protocol named MHAP (I'm sure Iljitsch would remember) that was not
inpired by GSE but had similarities (being an ID/LOC). Anyway, after a
while I realized that it did not really address the issue. It added
complexity, and it shifted the political/economical/legal issues into
another unknown alternate reality.

Bottom line is: there is currently no substitute for IPv6 PI. The real
world would probably go for IPv6 NAT instead, but the IETF is
deadlocked; instead of choosing between the lesser and two evils and
sacrifice one of the "features", they want to have the cake and eat it
too.

We could have had IPv6 without PI or IPv6 without NAT but not without
both. As of today, we have don't have jack.



> with respect to the oft-quoted axiom that if pigs had wings they
> could fly, i remember telling a lot of people (who reported to me
> inside an ISP) in Y2K or so is that "the rocket boosters have been
> attached to the pig called IPv6". what i meant by this is anybody's
> guess, really, but i think i was trying to say that even though it
> was useless and solved the wrong problem, it was also inevitable.

Well, pigs don't necessarily need wings or rockets to fly. I remember
the Pink Floyd inflatable pig.... it did fly.

Besides the initial lift from never-delivered politician promises, it
seems to me like IPv6 has raised due to some hot air as well, such as
"if the DoD mandates it, it will be adopted" (looking back at ADA and
GOSIP that is an assured failure looming ;-)

The jury is still out on the "inevitable" part though. And we won't know
for sure until 2 years after IPv4 becomes unavailable. 

Michel.



From paul at vix.com  Thu Sep 13 01:47:11 2007
From: paul at vix.com (Paul Vixie)
Date: Thu, 13 Sep 2007 05:47:11 +0000
Subject: [ppml] IPv6 flawed?
In-Reply-To: Your message of "Wed, 12 Sep 2007 22:37:25 MST."
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E65@server2003.arneill-py.sacramento.ca.us>
References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com><82435.1188567258@sa.vix.com><6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org><D67329E9-CAB1-42F3-8E71-24F99ED08FC0@muada.com><DD7FE473A8C3C245ADA2A2FE1709D90B1C8E4D@server2003.arneill-py.sacramento.ca.us>
	<1712.1188707832@sa.vix.com>
	<DD7FE473A8C3C245ADA2A2FE1709D90B1C8E65@server2003.arneill-py.sacramento.ca.us>
Message-ID: <99066.1189662431@sa.vix.com>

> Bottom line is: there is currently no substitute for IPv6 PI.

right.  very sad, but very true.

> The real world would probably go for IPv6 NAT instead, but the IETF is
> deadlocked; instead of choosing between the lesser and two evils and
> sacrifice one of the "features", they want to have the cake and eat it too.

ietf said don't do nat in v4.  the market said screw you.  the market won, and
ietf ended up having to add nat support into various protocols, and started
having nat oriented working groups, and so on.  i expect the same with nat v6.
don't let ietf scare you -- they're really just you, or will be once they're
up s**t creek without your paddle.  (again.)

> As of today, we have don't have jack.

as of today, we have ip with bigger addresses, and so we have the ability to
explode the global routing table at faster than light speeds.  with ipv4 we
had to make due with sublight speeds.  wheee, warp drive.  yay.

> The jury is still out on the "inevitable" part though. And we won't know
> for sure until 2 years after IPv4 becomes unavailable. 

i have more confidence in the ability of router vendors to bend moore's law
and in backbone architects and routing protocol architects to bend graph
theory, than i have for example in diesel-from-algae as a way to solve the
world's carbon problem.  so i'm not nec'ily hopeful, but i'm more hopeless
about other things than i am about a 2M-route DFZ.


From davids at webmaster.com  Thu Sep 13 02:48:41 2007
From: davids at webmaster.com (David Schwartz)
Date: Wed, 12 Sep 2007 23:48:41 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <46E84642.8050602@rancid.berkeley.edu>
Message-ID: <MDEHLPKNGKAHNMBLJOLKOEDCGMAC.davids@webmaster.com>


> I believe the current policy deals with this situation.  Once the policy
> went into place, I was able to deal with exactly this issue (with some
> escalation on my part).
>
> michael

I think it deals with this only for the case where the main delegation is
lame. If sub-delegations are lame, even deliberately preying on someone
else's server, the current policy is not clear. ARIN staff may be
interpreting it to give them authority to act or they may not, but either
way, it fails to provide guidance as to what is expected.

I think the ARIN should prohibit intentionally delegating a reverse address
zone, sub zone, or CNAME target of a reverse address delegated to an ARIN
zone to a server that will not be authoritative for that query or will fail
to respond to queries for it. The policy should require a reasonable effort
to fix this type of problem when notified of it.

If ARIN is going to delegate a zone to you, you are taking on the obligation
to make that zone work properly. Deliberately making others use extra
resources is a malicious act, comparable to spam in type but lesser in
degree. It wastes human beings' time and resources.

If you agree/promise to provide a service, you have an obligation to provide
it. You have no obligation to agree/promise to provide a service, but *if*
you agree/promise to provide a service, you have an obligation not to
intentionally fail to provide it.

DS




From davids at webmaster.com  Thu Sep 13 04:37:14 2007
From: davids at webmaster.com (David Schwartz)
Date: Thu, 13 Sep 2007 01:37:14 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <Pine.LNX.4.44.0709121642050.12099-100000@citation2.av8.net>
Message-ID: <MDEHLPKNGKAHNMBLJOLKAEDOGMAC.davids@webmaster.com>


Dean Anderson wrote:

> This proposal is misguided since it decides lameness on a per-nameserver
> basis rather than a per zone basis.

Certainly a resolver should be able to go to any listed nameserver and get
the right answer.

> A DNS zone is working if even one nameserver responds to queries for
> that zone.

Sure, and a hosting machine is working even if it's spewing spam to innocent
victims. But we don't enable such  machines to do so because they impose
unfair costs on others.

I will try all the nameservers listed for your zone out of robustness. If
you have an operational problem and only some of your nameservers work, I
still want to be able to reach you. But you forcing me to use more than one
nameserver *intentionally* imposes time and bandwidth costs on human beings
that is not part of the DNS deal. It's a wrong for the same reason spam is,
though a lesser one.

> It doesn't matter if a nameserver serves multiple zones, some of which
> it actually is configured to serve, and thus is not lame for some zones.
> Nor does it matter if a nameserver serves multiple zones, and does not
> respond for any of those zones.

Doesn't matter to who for what reason? It matters to a human being who is
waiting for a reply so they can do something.

> The current policy properly identifies lameness by zone, and removes
> delegation records when the _zone_ is lame. A zone is only lame when
> _no_ nameservers respond to queries for that zone.  In that case, ARIN
> can, after appropriate steps, remove delegation records.  The current
> policy is proper so that ARIN nameservers can give out NXDomain
> responses (which are also cached) for those zones that won't be
> supported anyway.

Why should ARIN give out referalls to servers that *intentionally* timeout?
Why should ARIN be a party in wasting other people's time and resources?

> However, if even one nameserver responds for a zone, there is no reason
> for ARIN to take any steps at all: The zone is not lame.  It is not
> ARIN's responibility to monitor the uptime of all delegated namesevers,
> or otherwise ensure that all nameservers are working for a zone, or for
> any group of zones.  There is no harm to ARIN if the zone is not lame,
> but some of the nameservers for that zone are not working.

There is no harm to ARIN, but ARIN is facilitating harm to others. How would
you feel if ARIN added one of your nameservers as a secondary for every
single zone? There would be no harm to ARIN, and the zones wouldn't be lame.
You are saying ARIN staff should have no authority to end this abuse?

> If some other group wants to monitor nameservers and report failures,
> that is up to them. But monitoring nameservers isn't a task that belongs
> to ARIN, beyond the issue of zone lameness.
> Therefore, this policy should not be accepted.

That I agree with. This is a really bad policy. However, a policy that
*permits* ARIN to act in cases where lame delegations or sub-delegations are
actually unfairly imposing costs to complaining human beings and ARIN's
delegations are facilitating it is another story.

If someone asks where the Post Office is, you can tell them nothing or you
can tell them where the Post Office is. Giving them a list of Post Office
addresses, some of which contains Post Offices and some of which don't is
simply not acceptable. It's not your fault if you tell him where the Post
Office is and it's closed, but it is your fault if you tell him where a Post
Office is that has been closed for months and you knew it was closed.

DS





From michael.dillon at bt.com  Thu Sep 13 06:22:49 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 13 Sep 2007 11:22:49 +0100
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <a06240807c30dde26c70f@[192.168.1.100]>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com><46E8007C.6010507@arin.net>
	<a06240807c30dde26c70f@[192.168.1.100]>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00103034E@E03MVC4-UKBR.domain1.systemhost.net>

> I have a hard time following the rest of the rationale.  What 
> I can buy is asking ARIN to suspend/remove a name server if 
> it's inclusion in the DNS causes sustained negative 
> operational consequences.  This is limited to the zone 
> involved (not the network), as that is the extent of the DNS "damage."

The only way that ARIN can determine whether or not there is sustained
negative operational consequences is to wait for complaints and then
follow them up. They do this now. No policy is needed to cover this.

There are no existing tools that can determine whether or not sustained
negative operational consequences exist. You would need dozens of
servers scattered around North America on several different ISP networks
in order to detect sustained negative operational consequences. It is a
waste of money to develop such a system in order to support a free
service, i.e. in-addr.arpa hosting.

--Michael Dillon


From michael.dillon at bt.com  Thu Sep 13 07:05:36 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 13 Sep 2007 12:05:36 +0100
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKAEDOGMAC.davids@webmaster.com>
References: <Pine.LNX.4.44.0709121642050.12099-100000@citation2.av8.net>
	<MDEHLPKNGKAHNMBLJOLKAEDOGMAC.davids@webmaster.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B0010303B2@E03MVC4-UKBR.domain1.systemhost.net>


> Why should ARIN give out referalls to servers that 
> *intentionally* timeout?

Because ARIN's customer asks them to do this.

> Why should ARIN be a party in wasting other people's time and 
> resources?

Because the people whose resources are being wasted are customers of the
organization which intentionally has their servers timeout.

About a year ago, I was called in to help sort out a major incident for
a customer of ours. Our customer was providing a service over the
network to hundreds of their customers. This service was delivered by an
application which their customers ran. One day last year, hundreds of
these customers were unable to login to the service at the beginning of
the day.

The cause? Verisign, in their wisdom, had cleaned up a bunch of lame
delegations in the .com zone by replacing the registered nameservers
with two nameservers in lame-delegation.org. The application that our
customer provides their customers, depends on a certain domain being
lame, and when it did not get the correct error, it was unable to
connect to it's servers. 

That's right, I said CORRECT ERROR. I didn't design the application, but
that is how it works. The solution was to put back the lame delegation
in the .com zone, and then to transfer the registration to another
registrar who will ensure that the lame delegation is left untouched in
the future. 

I have no problem with ARIN auditing the behavior of nameservers
registered for in-addr.arpa, and I have no problems with ARIN contacting
the right people (not the wrong people) at the organizations to discuss
the results of said audits. But I do have a problem with ARIN removing
records when a nameserver is "intentionally" lame.

ARIN is not the Internet police. ARIN allocations are used for many
other networks other than the Internet. ARIN currently does not maintain
the right contact info (DNS administrators) for organizations.

And most of all, punitive policy sets a bad precedent for ARIN when we
can expect increasing scrutiny of our activities due to IPv4 exhaustion
looming.

--Michael Dillon


From michael.dillon at bt.com  Thu Sep 13 07:45:57 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 13 Sep 2007 12:45:57 +0100
Subject: [ppml] New RFC about inaddr-arpa PTR records
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B001030425@E03MVC4-UKBR.domain1.systemhost.net>

How many of you who have commented on the in-addr.arpa issue, have read
this draft?

http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-consideratio
ns-05

As you might guess, by the number 05 at the end, this is the 5th version
of the draft and is getting pretty darn close to becoming a published
RFC. 

If your suggestions for new ARIN policy, or for ARIN operational
procedures, do not agree with some part of this draft, you might want to
contact the author or join the DNSOP working group here
http://www.ietf.org/html.charters/dnsop-charter.html

I note that the word "lame" does not appear in the above draft.

-------------------------------------------------------
Michael Dillon
RadianzNet Capacity Management, 66 Prescot St., London, E1 8HG, UK
Mobile: +44 7900 823 672 
Internet: michael.dillon at btradianz.com
Phone: +44 20 7650 9493 Fax: +44 20 7650 9030
http://www.btradianz.com
 
One Community One Connection One Focus 



From info at arin.net  Thu Sep 13 11:05:41 2007
From: info at arin.net (Member Services)
Date: Thu, 13 Sep 2007 11:05:41 -0400
Subject: [ppml] ARIN Implements PGP for Template Transactions
Message-ID: <46E951C5.1020405@arin.net>

ARIN has implemented PGP (Pretty Good Privacy) as a method to secure 
template transactions sent to ARIN when managing Internet number 
resources. This is in response to a 14 June 2007 directive from the 
Board of Trustees 
(http://www.arin.net/announcements/archives/20070621.html).

Cryptographic signing enables more secure communication between ARIN and 
its customers. In addition to PGP, ARIN offers X.509 certificates as a 
method of cryptographic authentication.  A wide variety of mail and 
signing software exists; ARIN encourages its customers to examine their 
mail software for PGP and X.509 support.  While there are a few known 
issues with some mail user agent (MUA) implementations of PGP and X.509 
standards, ARIN will work with its customers to provide additional 
processing support when needed.

ARIN will also continue to support Mail-From as an authentication 
method, though it is not as secure as digitally signed transactions.

For more details on cryptographic authentication at ARIN, including 
information on using PGP and X.509 certificates with ARIN, please visit: 
http://www.arin.net/CA/.

If you have any questions regarding PGP or X.509 certificates, please 
contact Registration Services at hostmaster at arin.net or +1.703.227.0660.

Regards,

Raymond A. Plzak
President and CEO
American Registry for Internet Numbers (ARIN)




From randy at psg.com  Thu Sep 13 11:59:30 2007
From: randy at psg.com (Randy Bush)
Date: Thu, 13 Sep 2007 05:59:30 -1000
Subject: [ppml] ARIN Implements PGP for Template Transactions
In-Reply-To: <46E951C5.1020405@arin.net>
References: <46E951C5.1020405@arin.net>
Message-ID: <46E95E62.7080604@psg.com>

yes!!!  thank you!!!

randy


From tedm at ipinc.net  Thu Sep 13 13:14:50 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 13 Sep 2007 10:14:50 -0700
Subject: [ppml] New RFC about inaddr-arpa PTR records
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B001030425@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <NABBJOELMNGNJNGPKDDOOENBHDAA.tedm@ipinc.net>


My comment on this is that I fail to see any relevance here.

This draft RFC contains no language that requires anyone to
do anything.  The word "must" doesen't even appear in it.
So assuming it is published, there is nothing in it to
obligate an RIR to follow it - since anyone can follow an
RFC that doesen't require them to do anything.

In short, this isn't a standards RFC.

As for the presense or not of the word "lame" well that is
irrelevant as well.  For all we know the RFC author is crippled
and has a personal dislike to the word "lame"  I do notice that
for all his political correctness on not using the word "lame"
he has no problem using the word "spam" rather than the more
formal (and correct in this instance) term "UCE" aka Unsolicited
Commercial Email.

Ted

>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>michael.dillon at bt.com
>Sent: Thursday, September 13, 2007 4:46 AM
>To: ppml at arin.net
>Subject: [ppml] New RFC about inaddr-arpa PTR records
>
>
>How many of you who have commented on the in-addr.arpa issue, have read
>this draft?
>
>http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-consideratio
>ns-05
>
>As you might guess, by the number 05 at the end, this is the 5th version
>of the draft and is getting pretty darn close to becoming a published
>RFC. 
>
>If your suggestions for new ARIN policy, or for ARIN operational
>procedures, do not agree with some part of this draft, you might want to
>contact the author or join the DNSOP working group here
>http://www.ietf.org/html.charters/dnsop-charter.html
>
>I note that the word "lame" does not appear in the above draft.
>
>-------------------------------------------------------
>Michael Dillon
>RadianzNet Capacity Management, 66 Prescot St., London, E1 8HG, UK
>Mobile: +44 7900 823 672 
>Internet: michael.dillon at btradianz.com
>Phone: +44 20 7650 9493 Fax: +44 20 7650 9030
>http://www.btradianz.com
> 
>One Community One Connection One Focus 
>
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to the 
>ARIN Public Policy
>Mailing List (PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/ppml Please contact the 
>ARIN Member Services
>Help Desk at info at arin.net if you experience any issues.
>


From tedm at ipinc.net  Thu Sep 13 13:21:55 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 13 Sep 2007 10:21:55 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <DD7FE473A8C3C245ADA2A2FE1709D90B1C8E65@server2003.arneill-py.sacramento.ca.us>
Message-ID: <NABBJOELMNGNJNGPKDDOCENCHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Michel Py
>Sent: Wednesday, September 12, 2007 10:37 PM
>To: Paul Vixie; ARIN PPML
>Subject: Re: [ppml] IPv6 flawed?
>
>
>
>Bottom line is: there is currently no substitute for IPv6 PI. The real
>world would probably go for IPv6 NAT instead, but the IETF is
>deadlocked; instead of choosing between the lesser and two evils and
>sacrifice one of the "features", they want to have the cake and eat it
>too.
>
>We could have had IPv6 without PI or IPv6 without NAT but not without
>both. As of today, we have don't have jack.
>

I disagree.  We have worse than jack because nothing prevents any
network admin from simply picking an unused portion of the IPv6 space
and calling that private and slapping an IPv6 NAT in front of it.

If IPv6 is assigned sequentially and it is as big as everyone claims,
then how soon do you think the RIRs will run out of IPv6 assignments?
10 years?  50 years?  100 years?

I think it would be very easy to look and find a range that won't be
even close to being assigned for another 100 years and set up exactly
the same NAT-based network we have today with IPv4, despite what IETF
wants.  All you really need is the IPv6 NAT device itself - and someone
will build that once there's demand for it.

Ted



From paul at vix.com  Thu Sep 13 13:27:34 2007
From: paul at vix.com (Paul Vixie)
Date: Thu, 13 Sep 2007 17:27:34 +0000
Subject: [ppml] IPv6 flawed?
In-Reply-To: Your message of "Thu, 13 Sep 2007 10:21:55 MST."
	<NABBJOELMNGNJNGPKDDOCENCHDAA.tedm@ipinc.net> 
References: <NABBJOELMNGNJNGPKDDOCENCHDAA.tedm@ipinc.net> 
Message-ID: <59160.1189704454@sa.vix.com>

> ... nothing prevents any network admin from simply picking an unused portion
> of the IPv6 space and calling that private and slapping an IPv6 NAT in front
> of it.

easier and less risky to use ULA (see RFC 4193).  it's when you want to be
able to do ad-hoc networking with partners and customers that the lack of
centralized WHOIS and IN-ADDR will bite you (with either the RFC 4193
approach or the above-quoted suggestion, equally.)


From sleibrand at internap.com  Thu Sep 13 13:20:17 2007
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 13 Sep 2007 10:20:17 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B0010303B2@E03MVC4-UKBR.domain1.systemhost.net>
References: <Pine.LNX.4.44.0709121642050.12099-100000@citation2.av8.net>	<MDEHLPKNGKAHNMBLJOLKAEDOGMAC.davids@webmaster.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B0010303B2@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <46E97151.90305@internap.com>

Michael,

ARIN's current lame delegation procedure allows a customer to exclude 
their zone from lameness testing on the grounds that the reverse DNS 
services for the zone are not reachable by ARIN.  I presume such policy 
would allow your customer to tell ARIN "yes, it's supposed to be that 
way", and then ARIN would leave them alone.  I don't think anyone is 
trying to change that, nor should we.

-Scott

michael.dillon at bt.com wrote:
>> Why should ARIN give out referalls to servers that 
>> *intentionally* timeout?
>>     
>
> Because ARIN's customer asks them to do this.
>
>   
>> Why should ARIN be a party in wasting other people's time and 
>> resources?
>>     
>
> Because the people whose resources are being wasted are customers of the
> organization which intentionally has their servers timeout.
>
> About a year ago, I was called in to help sort out a major incident for
> a customer of ours. Our customer was providing a service over the
> network to hundreds of their customers. This service was delivered by an
> application which their customers ran. One day last year, hundreds of
> these customers were unable to login to the service at the beginning of
> the day.
>
> The cause? Verisign, in their wisdom, had cleaned up a bunch of lame
> delegations in the .com zone by replacing the registered nameservers
> with two nameservers in lame-delegation.org. The application that our
> customer provides their customers, depends on a certain domain being
> lame, and when it did not get the correct error, it was unable to
> connect to it's servers. 
>
> That's right, I said CORRECT ERROR. I didn't design the application, but
> that is how it works. The solution was to put back the lame delegation
> in the .com zone, and then to transfer the registration to another
> registrar who will ensure that the lame delegation is left untouched in
> the future. 
>
> I have no problem with ARIN auditing the behavior of nameservers
> registered for in-addr.arpa, and I have no problems with ARIN contacting
> the right people (not the wrong people) at the organizations to discuss
> the results of said audits. But I do have a problem with ARIN removing
> records when a nameserver is "intentionally" lame.
>
> ARIN is not the Internet police. ARIN allocations are used for many
> other networks other than the Internet. ARIN currently does not maintain
> the right contact info (DNS administrators) for organizations.
>
> And most of all, punitive policy sets a bad precedent for ARIN when we
> can expect increasing scrutiny of our activities due to IPv4 exhaustion
> looming.
>
> --Michael Dillon
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>   



From randy at psg.com  Thu Sep 13 13:53:28 2007
From: randy at psg.com (Randy Bush)
Date: Thu, 13 Sep 2007 07:53:28 -1000
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <46E97151.90305@internap.com>
References: <Pine.LNX.4.44.0709121642050.12099-100000@citation2.av8.net>	<MDEHLPKNGKAHNMBLJOLKAEDOGMAC.davids@webmaster.com>	<D03E4899F2FB3D4C8464E8C76B3B68B0010303B2@E03MVC4-UKBR.domain1.systemhost.net>
	<46E97151.90305@internap.com>
Message-ID: <46E97918.9030509@psg.com>

> ARIN's current lame delegation procedure allows a customer to exclude 
> their zone from lameness testing on the grounds that the reverse DNS 
> services for the zone are not reachable by ARIN.  I presume such policy 
> would allow your customer to tell ARIN "yes, it's supposed to be that 
> way", and then ARIN would leave them alone.

can we safely presume that the [non-]reachability of the servers is
congruent with the [non-]reachability of the address space?

randy


From tedm at ipinc.net  Thu Sep 13 13:56:33 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 13 Sep 2007 10:56:33 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <59160.1189704454@sa.vix.com>
Message-ID: <NABBJOELMNGNJNGPKDDOOENCHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Paul Vixie
>Sent: Thursday, September 13, 2007 10:28 AM
>To: ARIN PPML
>Subject: Re: [ppml] IPv6 flawed?
>
>
>> ... nothing prevents any network admin from simply picking an 
>unused portion
>> of the IPv6 space and calling that private and slapping an IPv6 
>NAT in front
>> of it.
>
>easier and less risky to use ULA (see RFC 4193).  it's when you want to be
>able to do ad-hoc networking with partners and customers that the lack of
>centralized WHOIS and IN-ADDR will bite you (with either the RFC 4193
>approach or the above-quoted suggestion, equally.)

IETF probably would like that.

Ted


From kkargel at polartel.com  Thu Sep 13 14:14:59 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 13 Sep 2007 13:14:59 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <59160.1189704454@sa.vix.com>
References: <NABBJOELMNGNJNGPKDDOCENCHDAA.tedm@ipinc.net>
	<59160.1189704454@sa.vix.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707458@mail>

There is nothing preventing any sysadmin now from grabbing a chunk of
IPv4 space that they have no need of communicating with and
commandeering  it for "private" space.  The only penalty will be that
they will be unable to communicate with the legitimate IP.  I have
actually dealt with some of my customers who have VPN's to major
corporations and their VPN space uses IP's that belong to someone in
another RIR.

I still don't understand the controversy about private IPv6 space.  My
IPv6 allocation is plenty big.  If I want a private section of it all I
have to do is set an access list for it in my edge routers denying
traffic for that subnet in or out of my network.  Voila, I have a
private network.

Then I have the added advantage that if I ever need temporary access to
the world for an internal box (let's say I want to update patches) all I
have to do is punch a temporary hole in the access list.  No setting up
NAT, no renumbering, nothing fancy at all, it just instantly works. 

If I decide to peer with another network and allow them access to my
"private" space it is the same algorythm, I just set an access list
allowing traffic to and from their "private" IP space to my "private" IP
space.  No big deal.  I do have to rely on them not to transit traffic
to/from my space, but that same concern exists with NAT.  I assume if I
am going to initiate peering with a neighboring network their sysadmin
and I will actually have a conversation before we implement the merger.
Part of that conversation would be the exchange of "private" netblock
info.

If I buy another company or they buy me, and our networks completely
merge, I would see it as an advantage to maintain separate netblocks for
the disparate sites anyway.  If it is mandatory for some reason to have
a homogenous and contiguaous address space, then most likely someone is
going to be renumbering no matter what ULA type scheme we are using.

I am sure there is some aspect I am not paying attention to in my
limited need case, but for me it is not a big deal.



  

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Paul Vixie
> Sent: Thursday, September 13, 2007 12:28 PM
> To: ARIN PPML
> Subject: Re: [ppml] IPv6 flawed?
> 
> > ... nothing prevents any network admin from simply picking 
> an unused 
> > portion of the IPv6 space and calling that private and slapping an 
> > IPv6 NAT in front of it.
> 
> easier and less risky to use ULA (see RFC 4193).  it's when 
> you want to be able to do ad-hoc networking with partners and 
> customers that the lack of centralized WHOIS and IN-ADDR will 
> bite you (with either the RFC 4193 approach or the 
> above-quoted suggestion, equally.) 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at info at arin.net if you 
> experience any issues.
> 


From michael at rancid.berkeley.edu  Thu Sep 13 14:33:16 2007
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Thu, 13 Sep 2007 11:33:16 -0700
Subject: [ppml] Policy Proposal 2007-20: Definition of known ISP and
 changes to IPv6 initial allocation criteria
In-Reply-To: <46D43429.1000306@arin.net>
References: <46D43429.1000306@arin.net>
Message-ID: <46E9826C.7060705@rancid.berkeley.edu>

Member Services wrote:

> d. be an existing ISP in the ARIN region or have a plan for making
> assignments to at least 200 separate organizations within five years.
> 
> Rationale:
> 
> This policy proposal would change two things in the IPv6 Initial
> allocation criteria. It adds a definition for "known ISP" and changes
> "200 /48 assignments" to 200 assignments of any size, but to separate
> organizations.

Clarification question: What's the difference between "separate 
organizations" in this text and the "other organizations" in the current 
section of the NRPM?  Is the intent that if I allocated 3 /48s to the 
same "other" organization that it would now count as one organization 
instead of 3 /48s toward my goal of 200?

thanks,
michael


From tedm at ipinc.net  Thu Sep 13 14:35:00 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 13 Sep 2007 11:35:00 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066707458@mail>
Message-ID: <NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>


You don't understand it because you are large enough to have your
own allocation.

For the orgs too small to meet justification requirements to get
a direct allocation of IPv6 from an RIR, it is a big problem.

They do not want to get IPv6 from an ISP AKA "local internet registry"
and put time and money into numbering all their servers and suchlike -
because if they find a better deal down the street from the ISP's
(I mean local internet registry's) competitor, they want to be free
to dump the existing ISP and go to the competitor without having to
renumber internally.

This IMHO is the single largest reason so many orgs adopted NAT.

Ted

>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Kevin Kargel
>Sent: Thursday, September 13, 2007 11:15 AM
>To: ppml at arin.net
>Subject: Re: [ppml] IPv6 flawed?
>
>
>There is nothing preventing any sysadmin now from grabbing a chunk of
>IPv4 space that they have no need of communicating with and
>commandeering  it for "private" space.  The only penalty will be that
>they will be unable to communicate with the legitimate IP.  I have
>actually dealt with some of my customers who have VPN's to major
>corporations and their VPN space uses IP's that belong to someone in
>another RIR.
>
>I still don't understand the controversy about private IPv6 space.  My
>IPv6 allocation is plenty big.  If I want a private section of it all I
>have to do is set an access list for it in my edge routers denying
>traffic for that subnet in or out of my network.  Voila, I have a
>private network.
>
>Then I have the added advantage that if I ever need temporary access to
>the world for an internal box (let's say I want to update patches) all I
>have to do is punch a temporary hole in the access list.  No setting up
>NAT, no renumbering, nothing fancy at all, it just instantly works. 
>
>If I decide to peer with another network and allow them access to my
>"private" space it is the same algorythm, I just set an access list
>allowing traffic to and from their "private" IP space to my "private" IP
>space.  No big deal.  I do have to rely on them not to transit traffic
>to/from my space, but that same concern exists with NAT.  I assume if I
>am going to initiate peering with a neighboring network their sysadmin
>and I will actually have a conversation before we implement the merger.
>Part of that conversation would be the exchange of "private" netblock
>info.
>
>If I buy another company or they buy me, and our networks completely
>merge, I would see it as an advantage to maintain separate netblocks for
>the disparate sites anyway.  If it is mandatory for some reason to have
>a homogenous and contiguaous address space, then most likely someone is
>going to be renumbering no matter what ULA type scheme we are using.
>
>I am sure there is some aspect I am not paying attention to in my
>limited need case, but for me it is not a big deal.
>
>
>
>  
>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
>> Behalf Of Paul Vixie
>> Sent: Thursday, September 13, 2007 12:28 PM
>> To: ARIN PPML
>> Subject: Re: [ppml] IPv6 flawed?
>> 
>> > ... nothing prevents any network admin from simply picking 
>> an unused 
>> > portion of the IPv6 space and calling that private and slapping an 
>> > IPv6 NAT in front of it.
>> 
>> easier and less risky to use ULA (see RFC 4193).  it's when 
>> you want to be able to do ad-hoc networking with partners and 
>> customers that the lack of centralized WHOIS and IN-ADDR will 
>> bite you (with either the RFC 4193 approach or the 
>> above-quoted suggestion, equally.) 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to 
>> the ARIN Public Policy Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact 
>> the ARIN Member Services Help Desk at 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 (PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/ppml Please contact the 
>ARIN Member Services
>Help Desk at info at arin.net if you experience any issues.
>


From BehmJL at bv.com  Thu Sep 13 14:42:26 2007
From: BehmJL at bv.com (Behm, Jeffrey L.)
Date: Thu, 13 Sep 2007 13:42:26 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066707458@mail>
References: <NABBJOELMNGNJNGPKDDOCENCHDAA.tedm@ipinc.net><59160.1189704454@sa.vix.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066707458@mail>
Message-ID: <0C3670BC9169B244AA6E7B2E436180D1963803@TSMC-MAIL-04.na.bvcorp.net>

Another data point to consider:  

On Thursday, September 13, 2007 1:15 PM, Kevin Kargel said:

>If I want a private section of it all I
>have to do is set an access list for it in my edge routers denying
>traffic for that subnet in or out of my network.  Voila, I have a
>private network.
>
Not a private network, just a public network that is firewalled...read
on.

>Then I have the added advantage that if I ever need temporary access to
>the world for an internal box (let's say I want to update patches) all
I
>have to do is punch a temporary hole in the access list.  No setting up
>NAT, no renumbering, nothing fancy at all, it just instantly works. 

Similarly, if your admin *accidentally* (they're human, right?) punches
a not-so-temporary hole to that so-called private network, then your
private network isn't private anymore. If it was private, ala rfc1918,
then it wouldn't be such a big deal as opening up a non-rfc1918 address
(range?), which the rest of the Internet would then be able to access.

Jeff


From info at arin.net  Thu Sep 13 14:50:55 2007
From: info at arin.net (Member Services)
Date: Thu, 13 Sep 2007 14:50:55 -0400
Subject: [ppml] Policy Proposal -- Eliminate Lame Server policy
In-Reply-To: <46E732E9.5030108@arin.net>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<46E732E9.5030108@arin.net>
Message-ID: <46E9868F.7030005@arin.net>

 > The AC will assign shepherds in the near future. ARIN will provide the
 > names of the shepherds to the community via the PPML.

The shepherds from the ARIN Advisory Council for this proposal are Cathy 
Aronson and Robert Seastrom.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


Member Services wrote:
> ARIN received the following policy proposal. In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
> ARIN's website.
> 
> The ARIN Advisory Council (AC) will review this proposal at their next
> regularly scheduled meeting. The AC may decide to:
> 
>     1. Accept the proposal as a formal policy proposal as written. If the
> AC accepts the proposal, it will be posted as a formal policy proposal
> to PPML and it will be presented at a Public Policy Meeting.
> 
>     2. Postpone their decision regarding the proposal until the next
> regularly scheduled AC meeting in order to work with the author. The AC
> will work with the author to clarify, combine or divide the proposal. At
> their following meeting the AC will accept or not accept the proposal.
> 
>     3. Not accept the proposal. If the AC does not accept the proposal,
> the AC will explain their decision. If a proposal is not accepted, then
> the author may elect to use the petition process to advance their
> proposal. If the author elects not to petition or the  petition fails,
> then the proposal will be closed.
> 
> The AC will assign shepherds in the near future. ARIN will provide the
> names of the shepherds to the community via the PPML.
> 
> In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
> 
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Owen DeLong wrote:
> 
>>Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
>>
>>1.	Policy Proposal Name: Deprecate Lame Server Policy
>>2.	Author
>>	a.	name: Owen DeLong
>>	b.	email: owen at delong.com
>>	c.	telephone: 408-921-6984
>>	d.	organization: JITTR Networks
>>
>>3.	Proposal Version: 1.0
>>4.	Submission Date: 11 September, 2007
>>5.	Proposal type: delete
>>	new, modify, or delete.
>>6.	Policy term: permanent
>>	temporary, permanent, or renewable.
>>7.	Policy statement:
>>		Delete section 7 from the NRPM
>>
>>8.	Rationale:
>>		Recent PPML discussion has called attention to the
>>		fact that lame DNS delegations are more an operational
>>		issue than one of policy.  As such, the existing lame
>>		delegation policy should be removed from the NRPM
>>		to remove the resultant confusion.  This is not meant
>>		to prevent ARIN staff from taking reasonable action
>>		WRT DNS operational issues related to resources issued
>>		by ARIN, but, such action can be covered by staff
>>		operational guidelines and is not within the scope
>>		of Address Policy.
>>
>>9.	Timetable for implementation:
>>		1 June, 2008
>>10.	Meeting presenter:
>>END OF TEMPLATE
>>_______________________________________________
>>PPML
>>You are receiving this message because you are subscribed to the ARIN Public Policy
>>Mailing List (PPML at arin.net).
>>Unsubscribe or manage your mailing list subscription at:
>>http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
>>Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 



From info at arin.net  Thu Sep 13 14:52:57 2007
From: info at arin.net (Member Services)
Date: Thu, 13 Sep 2007 14:52:57 -0400
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <46E8007C.6010507@arin.net>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<46E8007C.6010507@arin.net>
Message-ID: <46E98709.5000808@arin.net>

 > The AC will assign shepherds in the near future. ARIN will provide the
 > names of the shepherds to the community via the PPML.

The shepherds from the ARIN Advisory Council for this proposal are 
Robert Seastrom and Cathy Aronson.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


Member Services wrote:
> ARIN received the following policy proposal. In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
> ARIN's website.
> 
> The ARIN Advisory Council (AC) will review this proposal at their next
> regularly scheduled meeting. The AC may decide to:
> 
>     1. Accept the proposal as a formal policy proposal as written. If the
> AC accepts the proposal, it will be posted as a formal policy proposal
> to PPML and it will be presented at a Public Policy Meeting.
> 
>     2. Postpone their decision regarding the proposal until the next
> regularly scheduled AC meeting in order to work with the author. The AC
> will work with the author to clarify, combine or divide the proposal. At
> their following meeting the AC will accept or not accept the proposal.
> 
>     3. Not accept the proposal. If the AC does not accept the proposal,
> the AC will explain their decision. If a proposal is not accepted, then
> the author may elect to use the petition process to advance their
> proposal. If the author elects not to petition or the  petition fails,
> then the proposal will be closed.
> 
> The AC will assign shepherds in the near future. ARIN will provide the
> names of the shepherds to the community via the PPML.
> 
> In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
> 
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Policy Proposal Name: Modification to Reverse Mapping Policy
> 
> Author: John Von Essen
> 
> Proposal Version: 1.0
> 
> Submission Date: September 11, 2007
> 
> Proposal type: modify
> 
> Policy term: permanent
> 
> Policy statement:
> 
> I am proposing a modification to section 7 of the IPv4 policy such that
> a more precise definition and overview of lameness is described.
> Below is how I think section 7 should be re-written.
> 
> START NEW Section
> 
> 7. Reverse Mapping
> 
> 7.1. Maintaining IN-ADDRs
> 
> All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
> from ARIN will be responsible for maintaining all IN- ADDR.ARPA domain
> records for their respective customers. For blocks smaller than /16, and
> for the segment of larger blocks which start or end with a CIDR prefix
> longer than /16, ARIN can maintain IN-ADDRs through the use of the SWIP
> (Reallocate and Reassign) templates or the Netmod template for /24 and
> shorter prefixes.
> 
> 7.2 Definitions
> 
> 7.2.1 Lame Delegation
> 
> A delegation is defined as being lame if all of the in-addr.arpa zones
> for a given name server of a specific network registration are lame. An
> in- addr.arpa zone is defined as lame when ARIN requests the SOA record
> from the name server registered in whois, but does not receive an answer.
> 
> 7.2.2 Partially Lame Delegation
> 
> A delegation is defined as being partially lame if at least one in-
> addr.arpa zone for a given name server of a specific network
> registration is lame. An in- addr.arpa zone is defined as lame when ARIN
> requests the SOA record from the name server registered in whois, but
> does not receive an answer.
> 
> 7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA
> 
> ARIN will actively identify lame and partially lame DNS name server
> (s) for reverse address delegations associated with address blocks
> allocated, assigned or administered by ARIN. Upon identification of a
> lame or partially 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 or partially lame delegation, ARIN
> will update the WHOIS database records resulting in the removal of lame
> or partially lame DNS servers. ARIN's actions in resolving lame and
> partially lame delegations is governed by the procedures set forth in
> (Lame-Ref).
> 
> 7.4 References
> 
> (Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
> reference/lame_delegations.html
> 
> 
> STOP NEW Section
> 
> 
> Rationale:
> 
> Current policy only considers an Org's delegation being deemed lame if
> all of in-addr.arpa zones for a given name server of a specific network
> registration are lame. Lame is defined when ARIN tests an in-addr.arpa
> zone by requesting the SOA record from the name server registered in
> whois, but does not receive an answer. If deemed lame, ARIN has an
> appropriate procedure for contacting the Org and handling the issue as
> per "http://www.arin.net/ reference/lame_delegations.html".
> 
> Unfortunately, the policy does not cover the situation of a so-called
> partially lame delegation. That is, some of the in-addr.arpa zones
> belonging to the network registration return a valid SOA upon testing,
> and some do not. Even if only one /24 in-addr.arpa reverse tests comes
> back as lame, it is my opinion that this still taints the reputation of
> entire network registration. IPs belonging to that lame in-addr.arpa
> zone will cause query timeouts to 3rd party dns resolvers, both public
> and private. These excessive timeouts in my opinion can harm the overall
> well-being of reverse dns functionality throughout the internet. The
> only way to prevent such harm is for ARIN to not delegate reverse
> authority to the so-called partially lame dns server as registered in
> whois. That is the purpose of this policy proposal, to consider partial
> lameness with the same prejudice as traditionally defined lameness.
> Org's who are partially lame should be contacted by ARIN and lame
> in-addr.arpa zones should be resolved as the procedures per
> "http://www.arin.net/reference/ lame_delegations.html" dictate.
> 
> Timetable for implementation: June 1, 2008
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 



From drc at virtualized.org  Thu Sep 13 15:02:17 2007
From: drc at virtualized.org (David Conrad)
Date: Thu, 13 Sep 2007 12:02:17 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOCENCHDAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOCENCHDAA.tedm@ipinc.net>
Message-ID: <A4A8C0EF-A30A-41D8-AC81-EC0B2A732AAB@virtualized.org>

On Sep 13, 2007, at 10:21 AM, Ted Mittelstaedt wrote:
> I disagree.  We have worse than jack because nothing prevents any
> network admin from simply picking an unused portion of the IPv6 space
> and calling that private and slapping an IPv6 NAT in front of it.

Interoperability.  If you want to play by yourself, you can do  
anything you want.  If you want to play with others, you have to  
abide by some rules.  If you happen to pick an IPv6 prefix somebody  
or something else is using, bzzzt.  Even behind NAT.

> If IPv6 is assigned sequentially and it is as big as everyone claims,
> then how soon do you think the RIRs will run out of IPv6 assignments?
> 10 years?  50 years?  100 years?

Obviously depends on how big the assignments are and how frequently  
they're made.  When RIRs are handing out /19s and /20s (and shorter),  
hard to guess how long the entire address space will last.

> I think it would be very easy to look and find a range that won't be
> even close to being assigned for another 100 years and set up exactly
> the same NAT-based network we have today with IPv4, despite what IETF
> wants.

Maybe.  Pick something outside of 2000::/3.  Will it last a hundred  
years?  Hard to say.  Will it last long enough that you won't need to  
worry about it?  Probably (again depending on size and frequency of  
RIR allocation).

> All you really need is the IPv6 NAT device itself - and someone
> will build that once there's demand for it.

I'm sure it already exists (perhaps not yet in commercial form).  ULA  
(of any form) guarantees it.  Maybe this isn't a bad thing -- at  
least you'd have provider independence and easy site-level multi- 
homing.  (I'm reminded of the scene in the book 'Salem's Lot where a  
character is about to be bitten by a vampire and thinks to himself  
that maybe over a few centuries he'll get used to it and the undead  
existence won't be so terrible).

Regards,
-drc



From dean at av8.com  Thu Sep 13 15:15:47 2007
From: dean at av8.com (Dean Anderson)
Date: Thu, 13 Sep 2007 15:15:47 -0400 (EDT)
Subject: [ppml] New RFC about inaddr-arpa PTR records
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B001030425@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <Pine.LNX.4.44.0709131442340.15654-100000@citation2.av8.net>

I did not agree with this draft. This draft has actually been in the
DNSOP WG for 7 years.  This is not the '5th' draft, but rather the 5th
draft with that name.  The original draft was submitted in 2000 under
the name 'inaddr-required' (google inaddr-required and in-addr-required)  
Almost no one agrees with the premise that in-addr should be required.  
The authors repeatedly made assurances that they "did not mean that
in-addr would be required", but the text of the draft continued to work
in the requirement implicitly or explicitly, despite continuous and
widespread objections to this.  Finally, they were forced to change the
name to eliminate the implication that in-addr would be required.  We
are now on the 5th revision of the re-named draft.

However, the current draft still contains a number of false statements
and false implications, and misleads people to think that in-addr is
required and improves security, etc.  Many people on the WG don't
believe that in-addr should be required. Every time someone complains
about the implication of the draft that in-addr is required or that the
draft implies that in-addr improves security, etc, the authors make
gratuitous changes to the wording, announce that they have 'addressed
the concerns', and try again, without changing the meaning.

They have also changed the draft type to 'informational' in an attempt
to address charges about lack of facts and the discredited claims
contained within the draft. Documents in the IETF 'informational'
category doesn't need to be 'true' in any scientific sense. But most
people, and particularly most system administrators, don't know the
difference.

Frustrated by the continuing willfull attempts to assert and imply that
in-addr is required and other false claims in the draft, I authored a
draft with true statements on the status of the in-addr system, and
which debunked certain claims. My draft informs readers about the status
and good practices of the reverse dns system.  My draft can be found at

http://www.ietf.org/internet-drafts/draft-anderson-reverse-dns-status-00.txt

At present, no one participating in the DNSOP WG was interested in
considering my alternative draft. This gives a good idea of who
participates in the DNSOP WG---reasonable people need to participate in
DNSOP WG!

I'll probably publish my document elsewhere as a technical report. It
might make a good magazine article.

		--Dean

On Thu, 13 Sep 2007 michael.dillon at bt.com wrote:

> How many of you who have commented on the in-addr.arpa issue, have read
> this draft?
> 
> http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-consideratio
> ns-05
> 
> As you might guess, by the number 05 at the end, this is the 5th version
> of the draft and is getting pretty darn close to becoming a published
> RFC. 
> 
> If your suggestions for new ARIN policy, or for ARIN operational
> procedures, do not agree with some part of this draft, you might want to
> contact the author or join the DNSOP working group here
> http://www.ietf.org/html.charters/dnsop-charter.html
> 
> I note that the word "lame" does not appear in the above draft.
> 
> -------------------------------------------------------
> Michael Dillon
> RadianzNet Capacity Management, 66 Prescot St., London, E1 8HG, UK
> Mobile: +44 7900 823 672 
> Internet: michael.dillon at btradianz.com
> Phone: +44 20 7650 9493 Fax: +44 20 7650 9030
> http://www.btradianz.com
>  
> One Community One Connection One Focus 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




From mcr at xdsinc.net  Thu Sep 13 15:46:40 2007
From: mcr at xdsinc.net (mcr at xdsinc.net)
Date: Thu, 13 Sep 2007 15:46:40 -0400
Subject: [ppml] IPv6 flawed?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066707458@mail> 
References: <NABBJOELMNGNJNGPKDDOCENCHDAA.tedm@ipinc.net>
	<59160.1189704454@sa.vix.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066707458@mail>
Message-ID: <20070913194642.ED5EF14466E@smtp2.arin.net>

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


>>>>> "Kevin" == Kevin Kargel <kkargel at polartel.com> writes:
    Kevin> I still don't understand the controversy about private IPv6 space.  My
    Kevin> IPv6 allocation is plenty big.  If I want a private section of it all I
    Kevin> have to do is set an access list for it in my edge routers denying
    Kevin> traffic for that subnet in or out of my network.  Voila, I have a
    Kevin> private network.

  Yes, and that's precisely what I want to do.
  (Except that most of the space will be initially private, with some if
possibly being accessible to some places to do exactly that... get
updates in an emergency, when some other internal update server is
broken)
  The problem is that I can't, under the current policy, even get a /48
of space, if I didn't previously qualify for a v4 allocation. 
  (This is greenfield deployment, which is one reason I can think about
just using IPv6...)

- -- 
Michael Richardson <mcr at xdsinc.net>
XDS Inc, Ottawa, ON             
Personal: http://www.sandelman.ca/mcr/ 


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

iQDVAwUBRumTnu0sRu40D6vCAQKHcAYAgs/6ijzLIMRNwLShua/rNgVt1DyvBr6e
kzusATLc713iznynbVSE3RIGtmDglnegg6+RWmgLP/XnB51EK4sWE/6MktGvCtzm
gLQc03j0Llc13+6+cIcIeJFoLh+DV9Od+tIqpl7mpRqi2tiT888xZvir2xISemJZ
EUAw+8fnH+S783hRk8r7qrACdpEAv24BTtsUwnak1D/IG5RZWt+7exp8oSuVcMH3
t0D07V1tYMeImD0Q/2e0QyaIgem/SZE4
=5vay
-----END PGP SIGNATURE-----


From leroy at emailsorting.com  Thu Sep 13 16:35:36 2007
From: leroy at emailsorting.com (Leroy Ladyzhensky)
Date: Thu, 13 Sep 2007 16:35:36 -0400
Subject: [ppml] IPv6 flawed?
References: <NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
Message-ID: <021c01c7f645$a3fd47d0$065e5e0a@integrated.net>

I totally agree with this...

I know of some companies that may have 1000 plus workstations and servers on
their internal network but would never qualify for IPv4 or IPv6 address's
because that don't need much... 10 or so real IP's

so, way down the road, when the move to IPv6 why would they number all their
inside machines just because that's the block their ISP handed to them? just
to renumber when they change to another ISP?

it bad enough now with IPv4 when only their firewall and DNS entries need to
be changed when they get a new IP block from an ISP...

As much as I hate NAT ... you can beat it in this situation...

leroy l.


----- Original Message ----- 
From: "Ted Mittelstaedt" <tedm at ipinc.net>
To: "Kevin Kargel" <kkargel at polartel.com>; <ppml at arin.net>
Sent: Thursday, September 13, 2007 2:35 PM
Subject: Re: [ppml] IPv6 flawed?


>
> You don't understand it because you are large enough to have your
> own allocation.
>
> For the orgs too small to meet justification requirements to get
> a direct allocation of IPv6 from an RIR, it is a big problem.
>
> They do not want to get IPv6 from an ISP AKA "local internet registry"
> and put time and money into numbering all their servers and suchlike -
> because if they find a better deal down the street from the ISP's
> (I mean local internet registry's) competitor, they want to be free
> to dump the existing ISP and go to the competitor without having to
> renumber internally.
>
> This IMHO is the single largest reason so many orgs adopted NAT.
>
> Ted
>
>>-----Original Message-----
>>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>>Kevin Kargel
>>Sent: Thursday, September 13, 2007 11:15 AM
>>To: ppml at arin.net
>>Subject: Re: [ppml] IPv6 flawed?
>>
>>
>>There is nothing preventing any sysadmin now from grabbing a chunk of
>>IPv4 space that they have no need of communicating with and
>>commandeering  it for "private" space.  The only penalty will be that
>>they will be unable to communicate with the legitimate IP.  I have
>>actually dealt with some of my customers who have VPN's to major
>>corporations and their VPN space uses IP's that belong to someone in
>>another RIR.
>>
>>I still don't understand the controversy about private IPv6 space.  My
>>IPv6 allocation is plenty big.  If I want a private section of it all I
>>have to do is set an access list for it in my edge routers denying
>>traffic for that subnet in or out of my network.  Voila, I have a
>>private network.
>>
>>Then I have the added advantage that if I ever need temporary access to
>>the world for an internal box (let's say I want to update patches) all I
>>have to do is punch a temporary hole in the access list.  No setting up
>>NAT, no renumbering, nothing fancy at all, it just instantly works.
>>
>>If I decide to peer with another network and allow them access to my
>>"private" space it is the same algorythm, I just set an access list
>>allowing traffic to and from their "private" IP space to my "private" IP
>>space.  No big deal.  I do have to rely on them not to transit traffic
>>to/from my space, but that same concern exists with NAT.  I assume if I
>>am going to initiate peering with a neighboring network their sysadmin
>>and I will actually have a conversation before we implement the merger.
>>Part of that conversation would be the exchange of "private" netblock
>>info.
>>
>>If I buy another company or they buy me, and our networks completely
>>merge, I would see it as an advantage to maintain separate netblocks for
>>the disparate sites anyway.  If it is mandatory for some reason to have
>>a homogenous and contiguaous address space, then most likely someone is
>>going to be renumbering no matter what ULA type scheme we are using.
>>
>>I am sure there is some aspect I am not paying attention to in my
>>limited need case, but for me it is not a big deal.
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On
>>> Behalf Of Paul Vixie
>>> Sent: Thursday, September 13, 2007 12:28 PM
>>> To: ARIN PPML
>>> Subject: Re: [ppml] IPv6 flawed?
>>>
>>> > ... nothing prevents any network admin from simply picking
>>> an unused
>>> > portion of the IPv6 space and calling that private and slapping an
>>> > IPv6 NAT in front of it.
>>>
>>> easier and less risky to use ULA (see RFC 4193).  it's when
>>> you want to be able to do ad-hoc networking with partners and
>>> customers that the lack of centralized WHOIS and IN-ADDR will
>>> bite you (with either the RFC 4193 approach or the
>>> above-quoted suggestion, equally.)
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml Please contact
>>> the ARIN Member Services Help Desk at 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 (PPML at arin.net).
>>Unsubscribe or manage your mailing list subscription at:
>>http://lists.arin.net/mailman/listinfo/ppml Please contact the
>>ARIN Member Services
>>Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member 
> Services
> Help Desk at info at arin.net if you experience any issues.
> 



From mcr at xdsinc.net  Thu Sep 13 17:38:41 2007
From: mcr at xdsinc.net (mcr at xdsinc.net)
Date: Thu, 13 Sep 2007 17:38:41 -0400
Subject: [ppml] IPv6 flawed?
In-Reply-To: <021c01c7f645$a3fd47d0$065e5e0a@integrated.net> 
References: <NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
	<021c01c7f645$a3fd47d0$065e5e0a@integrated.net>
Message-ID: <20070913213843.31ADF1444DF@smtp2.arin.net>

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


>>>>> "Leroy" == Leroy Ladyzhensky <leroy at emailsorting.com> writes:
    Leroy> so, way down the road, when the move to IPv6 why would they
    Leroy> number all their inside machines just because that's the
    Leroy> block their ISP handed to them? just to renumber when they
    Leroy> change to another ISP? 

    Leroy> it bad enough now with IPv4 when only their firewall and DNS
    Leroy> entries need to be changed when they get a new IP block from
    Leroy> an ISP... 

    Leroy> As much as I hate NAT ... you can beat it in this
    Leroy> situation...

  Yes, you can.

  In IPv6, it is strictly not uncommon for a host to have multiple IP
addresses.  So, you don't renumber the hosts or use NAT. You just let
them have an IP address from your ISP, if you have one.
  FURTHERMORE, shim6 will let you failover active connections from one
host to another without starting a new TCP connection.

  The problem is that, if you have a 1000 hosts, and they are on
multiple subnets (perhaps at multiple locations via VPNs or leased
lined, or ad-hoc wireless networks, or...), that you'd like to continue
to be able to address them even when your ISP is dead, etc. 

- -- 
Michael Richardson <mcr at xdsinc.net>
XDS Inc, Ottawa, ON             
Personal: http://www.sandelman.ca/mcr/ 



  
  

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

iQDVAwUBRumt4O0sRu40D6vCAQI/AAYAhXdPGMJFDHxFPidv8vlT9knBECKNRp70
pPF2+MDLRrI5nke8x0LBueN4Tgwsly0ccmv34xw3y11c/uxf0DjnMx6gB5DkU422
cuf/vNi3WTHiEUY7MKGQrsO7c4IXfOQrZNq2zzx7lNDjreOB4jFA9RrbWkPGNYIZ
U0bonIMRIXwqOfKfmLh2H0CjGTYgrxJVCUrbkuZ1bqWU/3PQyOfmEoilXOXP5sxj
txQaKUDN8+1QsKZzy51VgK8jBgF64JR9
=F8uM
-----END PGP SIGNATURE-----


From sleibrand at internap.com  Thu Sep 13 18:19:14 2007
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 13 Sep 2007 15:19:14 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <1FD70B23-BC2E-4355-9AF4-531024B3B033@quonix.net>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>	<46E8007C.6010507@arin.net>
	<46E81590.9040304@internap.com>
	<1FD70B23-BC2E-4355-9AF4-531024B3B033@quonix.net>
Message-ID: <46E9B762.2080607@internap.com>

John Von Essen wrote:
> Below are three Org's that are examples of partially lame. Several 
> in-addr.arpa's in their range correctly return an SOA request, but the 
> /24 prefixes listed below do not. These three were actually quickly 
> gathered by just trial and error. Cavalier is the ISP I have been 
> having trouble with, Cogent was a pure guess (I had a feeling they'd 
> be doing something wrong somewhere, so I just tested some random 
> ranges, and in a few minutes found a few culprits), and Interland is a 
> large hosting provider. Took about 10 minutes to find these. If I had 
> all day, I could probably find many more.
>
>
>
> Cavalier Telephone
> Ord ID: CTLL
> NetRange:   76.160.0.0 - 76.161.255.255
> NameServer: DNS01.CAVTEL.NET
> NameServer: DNS02.CAVTEL.NET
> Lame in-addr.arpa zones for Org CTLL:
> 76.161.193.0/24 - Is advertised by AS16810 
> 76.161.194.0/24 - Is advertised by AS16810
> 76.161.195.0/24 - Is advertised by AS16810
> and there are more

As far as I can tell this is not an example of a partially lame 
registration.  It appears to me that both /16 delegations are fully 
lame, so this should be covered under existing policies and procedures.
>
>
> Cogent Communications
> Ord ID: COGC
> NetRange:   66.250.0.0 - 66.250.255.255
> NameServer: AUTH1.DNS.COGENTCO.COM
> NameServer: AUTH2.DNS.COGENTCO.COM
> Lame in-addr.arpa zones for Org COGC:
> 66.250.60.0/24 - Is advertised by AS174
> 66.250.61.0/24 - Is advertised by AS174
> and there are more

This one is a case of lame subdelegations.  The /16 delegation from ARIN 
to Cogent is fine.  It's (some of) Cogent's /24 subdelegations to their 
customers that are lame.  In my opinion that's not directly ARIN's problem.
>
>
> Interland, Inc.
> Org ID: INTD
> NetRange:   209.237.128.0 - 209.237.191.255
> NameServer: A.NS.MYREGISTEREDSITE.COM
> NameServer: B.NS.MYREGISTEREDSITE.COM
> Lame in-addr.arpa zones for Org INTD:
> 209.237.139.0/24 - Is advertised by AS36476
> 209.237.140.0/24 - Is advertised by AS36476
> and there are more

This one is the only one of these that truly appears to be partially 
lame.  129.237.209.in-addr.arpa. returns SOA, but others do not.

It appears to me that this would indeed be newly covered under your 
revised policy.  However, I'm still undecided whether such procedural 
changes require policy changes as well, or whether we could get 
http://www.arin.net/reference/lame_delegations.html updated via the 
suggestion/consultation process (ASCP), and accomplish the same thing 
without having to redefine policy (thereby leaving more operational 
discretion to ARIN staff).  I suppose the ARIN AC will decide at their 
next meeting whether they think this policy proposal would best be 
addressed through the public policy process or the suggestion and 
consultation process.

-Scott
>
>
>
> -John
>
>
> On Sep 12, 2007, at 12:36 PM, Scott Leibrand wrote:
>
>> John,
>>
>> Do you have any examples of Partially Lame Delegations (or, to use 
>> Brian's slightly more precise terminology, Lame Zone Delegations to a 
>> non-Lame Server)?  I'm not opposed to your policy rewrite, but I'm as 
>> yet unconvinced that we have a real life non-hypothetical problem that 
>> can't be fixed by application of current policies and procedures.
>>
>> Thanks,
>> Scott
>>
>> Member Services wrote:
>>> ARIN received the following policy proposal. In accordance with the ARIN
>>> Internet Resource Policy Evaluation Process, the proposal is being
>>> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
>>> ARIN's website.
>>>
>>> The ARIN Advisory Council (AC) will review this proposal at their next
>>> regularly scheduled meeting. The AC may decide to:
>>>
>>>     1. Accept the proposal as a formal policy proposal as written. 
>>> If the
>>> AC accepts the proposal, it will be posted as a formal policy proposal
>>> to PPML and it will be presented at a Public Policy Meeting.
>>>
>>>     2. Postpone their decision regarding the proposal until the next
>>> regularly scheduled AC meeting in order to work with the author. The AC
>>> will work with the author to clarify, combine or divide the proposal. At
>>> their following meeting the AC will accept or not accept the proposal.
>>>
>>>     3. Not accept the proposal. If the AC does not accept the proposal,
>>> the AC will explain their decision. If a proposal is not accepted, then
>>> the author may elect to use the petition process to advance their
>>> proposal. If the author elects not to petition or the  petition fails,
>>> then the proposal will be closed.
>>>
>>> The AC will assign shepherds in the near future. ARIN will provide the
>>> names of the shepherds to the community via the PPML.
>>>
>>> In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at:
>>> http://www.arin.net/policy/irpep.html
>>>
>>> Mailing list subscription information can be found at:
>>> http://www.arin.net/mailing_lists/
>>>
>>> Regards,
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>> ## * ##
>>>
>>>
>>> Policy Proposal Name: Modification to Reverse Mapping Policy
>>>
>>> Author: John Von Essen
>>>
>>> Proposal Version: 1.0
>>>
>>> Submission Date: September 11, 2007
>>>
>>> Proposal type: modify
>>>
>>> Policy term: permanent
>>>
>>> Policy statement:
>>>
>>> I am proposing a modification to section 7 of the IPv4 policy such that
>>> a more precise definition and overview of lameness is described.
>>> Below is how I think section 7 should be re-written.
>>>
>>> START NEW Section
>>>
>>> 7. Reverse Mapping
>>>
>>> 7.1. Maintaining IN-ADDRs
>>>
>>> All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
>>> from ARIN will be responsible for maintaining all IN- ADDR.ARPA domain
>>> records for their respective customers. For blocks smaller than /16, and
>>> for the segment of larger blocks which start or end with a CIDR prefix
>>> longer than /16, ARIN can maintain IN-ADDRs through the use of the SWIP
>>> (Reallocate and Reassign) templates or the Netmod template for /24 and
>>> shorter prefixes.
>>>
>>> 7.2 Definitions
>>>
>>> 7.2.1 Lame Delegation
>>>
>>> A delegation is defined as being lame if all of the in-addr.arpa zones
>>> for a given name server of a specific network registration are lame. An
>>> in- addr.arpa zone is defined as lame when ARIN requests the SOA record
>>> from the name server registered in whois, but does not receive an 
>>> answer.
>>>
>>> 7.2.2 Partially Lame Delegation
>>>
>>> A delegation is defined as being partially lame if at least one in-
>>> addr.arpa zone for a given name server of a specific network
>>> registration is lame. An in- addr.arpa zone is defined as lame when ARIN
>>> requests the SOA record from the name server registered in whois, but
>>> does not receive an answer.
>>>
>>> 7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA
>>>
>>> ARIN will actively identify lame and partially lame DNS name server
>>> (s) for reverse address delegations associated with address blocks
>>> allocated, assigned or administered by ARIN. Upon identification of a
>>> lame or partially 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 or partially lame delegation, ARIN
>>> will update the WHOIS database records resulting in the removal of lame
>>> or partially lame DNS servers. ARIN's actions in resolving lame and
>>> partially lame delegations is governed by the procedures set forth in
>>> (Lame-Ref).
>>>
>>> 7.4 References
>>>
>>> (Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
>>> reference/lame_delegations.html
>>>
>>>
>>> STOP NEW Section
>>>
>>>
>>> Rationale:
>>>
>>> Current policy only considers an Org's delegation being deemed lame if
>>> all of in-addr.arpa zones for a given name server of a specific network
>>> registration are lame. Lame is defined when ARIN tests an in-addr.arpa
>>> zone by requesting the SOA record from the name server registered in
>>> whois, but does not receive an answer. If deemed lame, ARIN has an
>>> appropriate procedure for contacting the Org and handling the issue as
>>> per "http://www.arin.net/ reference/lame_delegations.html".
>>>
>>> Unfortunately, the policy does not cover the situation of a so-called
>>> partially lame delegation. That is, some of the in-addr.arpa zones
>>> belonging to the network registration return a valid SOA upon testing,
>>> and some do not. Even if only one /24 in-addr.arpa reverse tests comes
>>> back as lame, it is my opinion that this still taints the reputation of
>>> entire network registration. IPs belonging to that lame in-addr.arpa
>>> zone will cause query timeouts to 3rd party dns resolvers, both public
>>> and private. These excessive timeouts in my opinion can harm the overall
>>> well-being of reverse dns functionality throughout the internet. The
>>> only way to prevent such harm is for ARIN to not delegate reverse
>>> authority to the so-called partially lame dns server as registered in
>>> whois. That is the purpose of this policy proposal, to consider partial
>>> lameness with the same prejudice as traditionally defined lameness.
>>> Org's who are partially lame should be contacted by ARIN and lame
>>> in-addr.arpa zones should be resolved as the procedures per
>>> "http://www.arin.net/reference/ lame_delegations.html" dictate.
>>>
>>> Timetable for implementation: June 1, 2008
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the 
>>> ARIN Public Policy
>>> Mailing List (PPML at arin.net <mailto:PPML at arin.net>).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN 
>>> Member Services
>>> Help Desk at info at arin.net <mailto: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 (PPML at arin.net <mailto:PPML at arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN 
>> Member Services
>> Help Desk at info at arin.net <mailto:info at arin.net> if you experience 
>> any issues.
>
> Thanks, 
> John Von Essen
> (800) 248-1736 ext 100
> john at quonix.net <mailto:john at quonix.net>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>   


From davids at webmaster.com  Thu Sep 13 19:36:36 2007
From: davids at webmaster.com (David Schwartz)
Date: Thu, 13 Sep 2007 16:36:36 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B0010303B2@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <MDEHLPKNGKAHNMBLJOLKAEIBGMAC.davids@webmaster.com>


Michael Dillon wrote:

> > Why should ARIN give out referalls to servers that
> > *intentionally* timeout?

> Because ARIN's customer asks them to do this.

That can justify providing services to a spammer, after all, they ask you to
do so.

> > Why should ARIN be a party in wasting other people's time and
> > resources?

> Because the people whose resources are being wasted are customers of the
> organization which intentionally has their servers timeout.

Not so. I may or may not be an ARIN customer if I'm reverse resolving an IP
address assigned by ARIN.

> About a year ago, I was called in to help sort out a major incident for
> a customer of ours. Our customer was providing a service over the
> network to hundreds of their customers. This service was delivered by an
> application which their customers ran. One day last year, hundreds of
> these customers were unable to login to the service at the beginning of
> the day.
>
> The cause? Verisign, in their wisdom, had cleaned up a bunch of lame
> delegations in the .com zone by replacing the registered nameservers
> with two nameservers in lame-delegation.org. The application that our
> customer provides their customers, depends on a certain domain being
> lame, and when it did not get the correct error, it was unable to
> connect to it's servers.
>
> That's right, I said CORRECT ERROR. I didn't design the application, but
> that is how it works. The solution was to put back the lame delegation
> in the .com zone, and then to transfer the registration to another
> registrar who will ensure that the lame delegation is left untouched in
> the future.

So long as the address space involved doesn't connect to people who aren't
in on this scheme, I have no problem. If they do, this is simply an abuse of
the cooperation necessary to make the Internet work. It is morally in the
same category as a business model based on spam. You make other people do
extra work simply because you can, even though it's outside the scope of the
implied agreement that connects them to you.

Though I do agree that this is sufficiently minor that it shouldn't policed
by ARIN.

Let me make it clear that I don't think it's sensible to try to create a
policy that can, by robotic mindless operation perfectly handle every
situation. However, ARIN should police its delegations at least minimally to
curtail what is actual abuse.

The policy should give ARIN the power to deal with the cases that are really
bad and the descretion to allow the cases that are borderline or obviously
okay. The policy should tell ARIN customers that delegation of a zone is a
promise to properly serve those zones, and a promise that other people will
rely on.

DS




From weiler at tislabs.com  Thu Sep 13 19:55:45 2007
From: weiler at tislabs.com (Sam Weiler)
Date: Thu, 13 Sep 2007 19:55:45 -0400 (EDT)
Subject: [ppml] Faster lame delegation removal (was: Comments on ARIN's
 reverse DNS mapping policy)
In-Reply-To: <Pine.LNX.4.64.0709111142110.15772@mint.samweiler.com>
References: <Pine.LNX.4.64.0709111142110.15772@mint.samweiler.com>
Message-ID: <Pine.LNX.4.64.0709131955210.8341@mint.samweiler.com>

On Tue, 11 Sep 2007, Sam Weiler wrote:

> Perhaps some guidance from the staff would be useful here.  Is the current 
> policy sufficient for you to clean these up?  Are you reading "lame" broadly 
> enough to cover the cases raised by Mr. Von Essen and myself?  Absent 
> instructions from the community specifying a timetable[1], how long will it 
> take between these being reported and them being cleaned up?  (FWIW, I'd 
> prefer to see a short timetable, on the order of two weeks.)

Having been pointed to 
http://www.arin.net/reference/lame_delegations.html:

It appears that ARIN is now testing for lame delegations every 30 
days, but ARIN waits 30 days before notifying the POCs of the 
lameness.  Then ARIN waits 30 more days before sending a follow-up 
email.  The lame delegation isn't removed until 90 days after its 
detected (and potentially 119 days since it first appeared on the 
network, depending on the testing cycle).

That timetable seems needlessly drawn out to me.

I've sumbitted a suggestion (under the ACSP) asking ARIN to send the 
first email sooner (2-5 days), send reminders at least weekly, and 
strip the lame delegation after only one month.

-- Sam


From arin-contact at dirtside.com  Thu Sep 13 21:14:01 2007
From: arin-contact at dirtside.com (William Herrin)
Date: Thu, 13 Sep 2007 21:14:01 -0400
Subject: [ppml] IPv6 flawed?
In-Reply-To: <20070913213843.31ADF1444DF@smtp2.arin.net>
References: <NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
	<021c01c7f645$a3fd47d0$065e5e0a@integrated.net>
	<20070913213843.31ADF1444DF@smtp2.arin.net>
Message-ID: <3c3e3fca0709131814q2c65fab8le376b598a74f404c@mail.gmail.com>

On 9/13/07, mcr at xdsinc.net <mcr at xdsinc.net> wrote:
>   In IPv6, it is strictly not uncommon for a host to have multiple IP
> addresses.  So, you don't renumber the hosts or use NAT. You just let
> them have an IP address from your ISP, if you have one.
>   FURTHERMORE, shim6 will let you failover active connections from one
> host to another without starting a new TCP connection.
>
>   The problem is that, [snip]

The problem is that:

1. That's only close to true if you use stateless autoconfiguration
which suffers from such a severe security issue that it might well
drop out of use.

2. Its not actually true even if you do use stateless
autoconfiguration because you have to talk to other hosts on your
interior network via their full IP addresses, not via just the however
many bits that haven't changed. There's much more to communication
than a host's own IP address.

3. Shim6 is still in the research stage and at least 5 years from
ubiquitous deployment. Its not at all clear that it will ever make it
out of the research stage.


The answer might have been some sort of locality-mask that operates
like a reverse-netmask allowing interior hosts discard the high-order
address bits when communicating with each other. Since that wasn't
done and we're not on a path to IPv6 PI space, the answer is going to
be NAT.

Standard or no standard, someone is going to build it, someone is
going to sell it and when folks start buying it everybody else is
going to follow.

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin at dirtside.com  bill at herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From christopher.morrow at gmail.com  Thu Sep 13 21:21:26 2007
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Thu, 13 Sep 2007 21:21:26 -0400
Subject: [ppml] IPv6 flawed?
In-Reply-To: <20070913213843.31ADF1444DF@smtp2.arin.net>
References: <NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
	<021c01c7f645$a3fd47d0$065e5e0a@integrated.net>
	<20070913213843.31ADF1444DF@smtp2.arin.net>
Message-ID: <75cb24520709131821r196fa8ete6aaad5a9389fb35@mail.gmail.com>

On 9/13/07, mcr at xdsinc.net <mcr at xdsinc.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

>   In IPv6, it is strictly not uncommon for a host to have multiple IP
> addresses.  So, you don't renumber the hosts or use NAT. You just let
> them have an IP address from your ISP, if you have one.
>   FURTHERMORE, shim6 will let you failover active connections from one
> host to another without starting a new TCP connection.

There have been more than a few talks/panels/discussions of shim6/ipv6
at previous nanog, arin, IETF meetings. The situation is far from this
simple for production enterprise networks. It's even less simple for
ISP-type networks.

SHIM6 seems to fit certain niches, I'm not sure that enterprise
multi-homing nor 'provider' multihoming are them. Content provider
multihoming seems even less likely to use shim6...

>
>   The problem is that, if you have a 1000 hosts, and they are on
> multiple subnets (perhaps at multiple locations via VPNs or leased
> lined, or ad-hoc wireless networks, or...), that you'd like to continue
> to be able to address them even when your ISP is dead, etc.
>

in today's world that's a NAT, VPN, multi-homed solution... tomorrow
that may not be the case, this is all to be determined. (and yes, NAT
isn't even required in the existing case, but... )


From izumi at nic.ad.jp  Thu Sep 13 22:02:57 2007
From: izumi at nic.ad.jp (Izumi Okutani)
Date: Fri, 14 Sep 2007 11:02:57 +0900
Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations
 to	RIRs
In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A02A4C89E@nyrofcs2ke2k01.corp.pvt>
References: <454810F09B5AA04E9D78D13A5C39028A02A4C89E@nyrofcs2ke2k01.corp.pvt>
Message-ID: <46E9EBD1.2010508@nic.ad.jp>

Thanks for your input Marla, and apologies for taking some time to reply.

Just to clarify our intention, we think this will help reduce confusion
for distribution of the last few IANA blocks.

For example, if ARIN was planning to request for 2*/8 next month, but
APNIC (or any other RIR) comes just before and IANA pool runs out as a
result, ARIN will be left with 0 additional block it was counting on.
This will also affect distribution of the last ARIN block within the
region as you don't know which would be the last block until the last
minute.

By pre-defining what each RIR will receive in advance (with the size
which does not affect each RIR's exhaustion date), we think it helps
solve this issue and minimize confusion at the time of exhaustion.

I see your point about section 2, so I'll remove it from my slides at
the meeting. thanks. I'd also be happy to remove section 3 if it's an
obvious fact which doesn't need to be shared.


izumi

Azinger, Marla ????????:
> Here are my two cents:
> 
> -I don't support this.  Let it run out.  Write a policy figuring out what IANA does once contiguous requests cant be met.
> 
> -Section 2 needs to be removed.  It isn't policy and more a suggestion/guidance of things that RIR's should think about doing.
> -Section 3 needs to be removed.  It isn't policy and more a staff requirement for RIR's.
> 
> Cheers!
> Marla Azinger
> Frontier Communications
> 
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
> Member Services
> Sent: Friday, August 17, 2007 8:20 AM
> To: ppml at arin.net
> Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations to
> RIRs
> 
> 
> ARIN received the following policy proposal. In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
> ARIN's website.
> 
> The ARIN Advisory Council (AC) will review this proposal at their next
> regularly scheduled meeting. The AC may decide to:
> 
>    1. Accept the proposal as a formal policy proposal as written. If the
> AC accepts the proposal, it will be posted as a formal policy proposal
> to PPML and it will be presented at a Public Policy Meeting.
> 
>    2. Postpone their decision regarding the proposal until the next
> regularly scheduled AC meeting in order to work with the author. The AC
> will work with the author to clarify, combine or divide the proposal. At
> their following meeting the AC will accept or not accept the proposal.
> 
>    3. Not accept the proposal. If the AC does not accept the proposal,
> the AC will explain their decision. If a proposal is not accepted, then
> the author may elect to use the petition process to advance their
> proposal. If the author elects not to petition or the  petition fails,
> then the proposal will be closed.
> 
> The AC will assign shepherds in the near future. ARIN will provide the
> names of the shepherds to the community via the PPML.
> 
> In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
> 
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Policy Proposal Name: End Policy for IANA IPv4 allocations to RIRs
> 
> Author: JPNIC IPv4 countdown policy team;
>                    Akinori MAEMURA
>                    Akira NAKAGAWA
>                    Izumi OKUTANI
>                    Kosuke ITO
>                    Kuniaki KONDO
>                    Shuji NAKAMURA
>                    Susumu SATO
>                    Takashi ARANO
>                    Tomohiro FUJISAKI
>                    Tomoya YOSHIDA
>                    Toshiyuki HOSAKA
> 
> Proposal Version: 2
> 
> Submission Date: 2007/08/17
> 
> Proposal type: new
> 
> Policy term:renewable
> 
> Policy statement:
> 
> 1) Distribute a single /8 to each RIR at the point when new IANA free
>     pool hits 5 */8. This date is defined as "IANA Exhaustion Date".
> 
> 2) It should be completely left up to each RIR communities to define a
>     regional policy on how to distribute the remaining RIR free pool to
>     LIRs within their respective regions after "IANA Exhaustion Date".
> 
>     Note 1: It is fine for an RIR to continue operations with the
>             existing policy if that is the consensus decision of the
>             respective RIR community.
> 
>     Note 2: Address recovery and re-distribution of recovered address
>             space is another important measure for considerations, but
>             should be treated as a separate policy proposal from
>             distribution of new IANA pool.
> 
> 3) RIRs should provide an official projection on IANA Exhaustion Date
>     to the community through their website, at their Policy Meetings
>     and through any other effective means.
> 
> 
> Rationale:
> [current problem]
> There are two major issues in terms of address management if no measures
> are taken for IPv4 address exhaustion.
> 
> 1) Continue applying a global coordinated policy for distribution of the
>     last piece(s) of RIR's unallocated address block does not match the
>     reality of the situation in each RIR region.
> 
>     Issues each RIR region will face during the exhaustion period vary by
>     region as the level of development of IPv4 and IPv6 are widely
>     different. As a result, applying a global co-ordinated policy may not
>     adequately address issues in a certain region while it could be work
>     for the others.
> 
>     For example, in a region where late comers desperately need even
>     small blocks of IPv4 addresses to access to the IPv4 Internet, a
>     policy that defines the target of allocations/assignments of IPv4
>     address space to be late comers would be appropriate in such region.
>     This would allow availablilty of IPv4 address space for such
>     requirements for more years.
> 
>     Another example comes from difference in IPv6 deployment rate.
>     For a region where IPv6 deployment rate is low, measures may be
>     necessary to prolong IPv4 address life for the existing business as
>     well as for new businesses until networks are IPv6 ready. Some
>     regions may have strong needs to secure IPv4 address space for
>     translators.
> 
>     A globally coordinated policy which addresses all the issues listed
>     above to meet the needs for all RIR regions may result in not solving
>     issues in any of the regions.
> 
> 2) LIRs and stakeholders remain unprepared for the situation if they are
>     not informed
> 
>     If LIRs and the community are uninformed of the exhaustion, their
>     services and networks remain unprepared to face the situation at the
>     time of exhaustion.
> 
> [Objective of the proposal]
> This proposal seeks to provide the following solutions to the problems
> listed above.
> 
> 1) RIR community should be able to define their own regional policies on
>     how to assign the last piece(s) of allocation block in order to
>     address their own regional issues during the exhaustion period.
> 
> 2) RIRs should provide official projection of the date when LIRs will be
>     able to receive the allocations under the current criteria. The
>     criteria should remain consistent until this date in order to avoid
>     confusion.
> 
> [Pros and Cons]
> Pros:
> + It allows each RIR community to define a policy on how to distribute
>    the last piece(s) of allocations which best matches their situation.
> 
> + It helps LIR better informed of the date when they are able to receive
>    allocations from RIRs under the current criteria and prepare for the
>    event.
> 
> Cons:
> + Concerns could be raised about allocating a fixed size to all RIRs,
>    that it artificially fastens the consumption rate of some RIR regions.
>    However, its impact is kept to minimum by keeping the allocation size
>    to a single /8 which makes merely 3-4 months difference.
> 
> + Concerns could be raised that explicitly allowing regional policies
>    will encourage RIR shopping. However, this should not happen if the
>    requirements within each region is adequately reflected in each RIR's
>    policy through PDP. RIR may also chose to add criteria to prevent LIRs
>    from other regions submitting such requests.
> 
> 
> Timetable for implementation:
> Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy.
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.



From izumi at nic.ad.jp  Thu Sep 13 22:05:45 2007
From: izumi at nic.ad.jp (Izumi Okutani)
Date: Fri, 14 Sep 2007 11:05:45 +0900
Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations
 to	RIRs
In-Reply-To: <46E9EBD1.2010508@nic.ad.jp>
References: <454810F09B5AA04E9D78D13A5C39028A02A4C89E@nyrofcs2ke2k01.corp.pvt>
	<46E9EBD1.2010508@nic.ad.jp>
Message-ID: <46E9EC79.3050908@nic.ad.jp>

One more note.

I wasn't clear about if this is a global policy or a regional ARIN
policy - it is intended to be a global policy as it defines distribution
of IANA blocks.

izumi

Izumi Okutani ????????:
> Thanks for your input Marla, and apologies for taking some time to reply.
> 
> Just to clarify our intention, we think this will help reduce confusion
> for distribution of the last few IANA blocks.
> 
> For example, if ARIN was planning to request for 2*/8 next month, but
> APNIC (or any other RIR) comes just before and IANA pool runs out as a
> result, ARIN will be left with 0 additional block it was counting on.
> This will also affect distribution of the last ARIN block within the
> region as you don't know which would be the last block until the last
> minute.
> 
> By pre-defining what each RIR will receive in advance (with the size
> which does not affect each RIR's exhaustion date), we think it helps
> solve this issue and minimize confusion at the time of exhaustion.
> 
> I see your point about section 2, so I'll remove it from my slides at
> the meeting. thanks. I'd also be happy to remove section 3 if it's an
> obvious fact which doesn't need to be shared.
> 
> 
> izumi
> 
> Azinger, Marla ????????:
>> Here are my two cents:
>>
>> -I don't support this.  Let it run out.  Write a policy figuring out what IANA does once contiguous requests cant be met.
>>
>> -Section 2 needs to be removed.  It isn't policy and more a suggestion/guidance of things that RIR's should think about doing.
>> -Section 3 needs to be removed.  It isn't policy and more a staff requirement for RIR's.
>>
>> Cheers!
>> Marla Azinger
>> Frontier Communications
>>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>> Member Services
>> Sent: Friday, August 17, 2007 8:20 AM
>> To: ppml at arin.net
>> Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations to
>> RIRs
>>
>>
>> ARIN received the following policy proposal. In accordance with the ARIN
>> Internet Resource Policy Evaluation Process, the proposal is being
>> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
>> ARIN's website.
>>
>> The ARIN Advisory Council (AC) will review this proposal at their next
>> regularly scheduled meeting. The AC may decide to:
>>
>>    1. Accept the proposal as a formal policy proposal as written. If the
>> AC accepts the proposal, it will be posted as a formal policy proposal
>> to PPML and it will be presented at a Public Policy Meeting.
>>
>>    2. Postpone their decision regarding the proposal until the next
>> regularly scheduled AC meeting in order to work with the author. The AC
>> will work with the author to clarify, combine or divide the proposal. At
>> their following meeting the AC will accept or not accept the proposal.
>>
>>    3. Not accept the proposal. If the AC does not accept the proposal,
>> the AC will explain their decision. If a proposal is not accepted, then
>> the author may elect to use the petition process to advance their
>> proposal. If the author elects not to petition or the  petition fails,
>> then the proposal will be closed.
>>
>> The AC will assign shepherds in the near future. ARIN will provide the
>> names of the shepherds to the community via the PPML.
>>
>> In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at:
>> http://www.arin.net/policy/irpep.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: End Policy for IANA IPv4 allocations to RIRs
>>
>> Author: JPNIC IPv4 countdown policy team;
>>                    Akinori MAEMURA
>>                    Akira NAKAGAWA
>>                    Izumi OKUTANI
>>                    Kosuke ITO
>>                    Kuniaki KONDO
>>                    Shuji NAKAMURA
>>                    Susumu SATO
>>                    Takashi ARANO
>>                    Tomohiro FUJISAKI
>>                    Tomoya YOSHIDA
>>                    Toshiyuki HOSAKA
>>
>> Proposal Version: 2
>>
>> Submission Date: 2007/08/17
>>
>> Proposal type: new
>>
>> Policy term:renewable
>>
>> Policy statement:
>>
>> 1) Distribute a single /8 to each RIR at the point when new IANA free
>>     pool hits 5 */8. This date is defined as "IANA Exhaustion Date".
>>
>> 2) It should be completely left up to each RIR communities to define a
>>     regional policy on how to distribute the remaining RIR free pool to
>>     LIRs within their respective regions after "IANA Exhaustion Date".
>>
>>     Note 1: It is fine for an RIR to continue operations with the
>>             existing policy if that is the consensus decision of the
>>             respective RIR community.
>>
>>     Note 2: Address recovery and re-distribution of recovered address
>>             space is another important measure for considerations, but
>>             should be treated as a separate policy proposal from
>>             distribution of new IANA pool.
>>
>> 3) RIRs should provide an official projection on IANA Exhaustion Date
>>     to the community through their website, at their Policy Meetings
>>     and through any other effective means.
>>
>>
>> Rationale:
>> [current problem]
>> There are two major issues in terms of address management if no measures
>> are taken for IPv4 address exhaustion.
>>
>> 1) Continue applying a global coordinated policy for distribution of the
>>     last piece(s) of RIR's unallocated address block does not match the
>>     reality of the situation in each RIR region.
>>
>>     Issues each RIR region will face during the exhaustion period vary by
>>     region as the level of development of IPv4 and IPv6 are widely
>>     different. As a result, applying a global co-ordinated policy may not
>>     adequately address issues in a certain region while it could be work
>>     for the others.
>>
>>     For example, in a region where late comers desperately need even
>>     small blocks of IPv4 addresses to access to the IPv4 Internet, a
>>     policy that defines the target of allocations/assignments of IPv4
>>     address space to be late comers would be appropriate in such region.
>>     This would allow availablilty of IPv4 address space for such
>>     requirements for more years.
>>
>>     Another example comes from difference in IPv6 deployment rate.
>>     For a region where IPv6 deployment rate is low, measures may be
>>     necessary to prolong IPv4 address life for the existing business as
>>     well as for new businesses until networks are IPv6 ready. Some
>>     regions may have strong needs to secure IPv4 address space for
>>     translators.
>>
>>     A globally coordinated policy which addresses all the issues listed
>>     above to meet the needs for all RIR regions may result in not solving
>>     issues in any of the regions.
>>
>> 2) LIRs and stakeholders remain unprepared for the situation if they are
>>     not informed
>>
>>     If LIRs and the community are uninformed of the exhaustion, their
>>     services and networks remain unprepared to face the situation at the
>>     time of exhaustion.
>>
>> [Objective of the proposal]
>> This proposal seeks to provide the following solutions to the problems
>> listed above.
>>
>> 1) RIR community should be able to define their own regional policies on
>>     how to assign the last piece(s) of allocation block in order to
>>     address their own regional issues during the exhaustion period.
>>
>> 2) RIRs should provide official projection of the date when LIRs will be
>>     able to receive the allocations under the current criteria. The
>>     criteria should remain consistent until this date in order to avoid
>>     confusion.
>>
>> [Pros and Cons]
>> Pros:
>> + It allows each RIR community to define a policy on how to distribute
>>    the last piece(s) of allocations which best matches their situation.
>>
>> + It helps LIR better informed of the date when they are able to receive
>>    allocations from RIRs under the current criteria and prepare for the
>>    event.
>>
>> Cons:
>> + Concerns could be raised about allocating a fixed size to all RIRs,
>>    that it artificially fastens the consumption rate of some RIR regions.
>>    However, its impact is kept to minimum by keeping the allocation size
>>    to a single /8 which makes merely 3-4 months difference.
>>
>> + Concerns could be raised that explicitly allowing regional policies
>>    will encourage RIR shopping. However, this should not happen if the
>>    requirements within each region is adequately reflected in each RIR's
>>    policy through PDP. RIR may also chose to add criteria to prevent LIRs
>>    from other regions submitting such requests.
>>
>>
>> Timetable for implementation:
>> Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy.
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
>> Help Desk at 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 (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
>> Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.



From michael.dillon at bt.com  Fri Sep 14 07:24:33 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 14 Sep 2007 12:24:33 +0100
Subject: [ppml] IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOCENCHDAA.tedm@ipinc.net>
References: <DD7FE473A8C3C245ADA2A2FE1709D90B1C8E65@server2003.arneill-py.sacramento.ca.us>
	<NABBJOELMNGNJNGPKDDOCENCHDAA.tedm@ipinc.net>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00107D101@E03MVC4-UKBR.domain1.systemhost.net>

> I disagree.  We have worse than jack because nothing prevents 
> any network admin from simply picking an unused portion of 
> the IPv6 space and calling that private and slapping an IPv6 
> NAT in front of it.

Nothing prevents that today. I know of several IPv4 networks which do
just that. There is also at least one network that used to be a customer
of a company that we acquired 15 years ago. They still use the addresses
that they were allocated way back when and we only found out when some
bright spark decided to send some spam from their mailservers behind the
NAT.

In another incident 3 years ago, a former customer threatened to sue us
because we had reused the PA addresses that had once been assigned to
him. It was somehow interfering with his ability to communicate with an
important customer.

The fact is that using random addresses behind NAT works just fine. The
only downside is that you are unable to communicate to the network which
has registered those addresses, but if you don't need to communicate to
them, no loss. As you pointed out, the much larger IPv6 space gets rid
of that downside because there is a vast unallocated region from which
you can pick your random addresses.

I wouldn't recommend doing this in IPv6 since ULA addresses will do just
as well. See RFC 4193 for details http://www.ietf.org/rfc/rfc4193.txt
and if you are concerned that someone else might choose the same block,
then select your block using this tool
http://www.sixxs.net/tools/grh/ula/ which will reduce the chances of
collision.

> If IPv6 is assigned sequentially and it is as big as everyone 
> claims, then how soon do you think the RIRs will run out of 
> IPv6 assignments?
> 10 years?  50 years?  100 years?

You need to read these PPML messages
http://lists.arin.net/pipermail/ppml/2005-May/003674.html
http://lists.arin.net/pipermail/ppml/2005-May/003704.html
Before we put /56s into the equation, the runout date was no less than
120 years from now. And, as Tony noted in the second message, a minor
change to the HD ratio pushes that out to 1200 years from now.

In any case, I am opposed to policies which would deny my descendants
from having thorny addressing problems to solve. Assuming that they
survive the meteorite collisons in 2029 and 2036, and the flooding of
coastal cities caused by global warming, and the destruction of the
Eastern seabord of North America (including ARIN) from the tsunamic
caused by the volcanic eruption of the Canary Islands.

By the way, nothing that we can do will prevent people from doing weird
things with IPv6, NAT included. I consider NAT and address-borrowing to
be corner cases. We need to focus on ISP networks, consumer Internet
access and medium-to-large enterprise access.

--Michael Dillon


From michael.dillon at bt.com  Fri Sep 14 07:41:57 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 14 Sep 2007 12:41:57 +0100
Subject: [ppml] IPv6 flawed?
In-Reply-To: <20070913213843.31ADF1444DF@smtp2.arin.net>
References: <NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net><021c01c7f645$a3fd47d0$065e5e0a@integrated.net>
	<20070913213843.31ADF1444DF@smtp2.arin.net>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00107D126@E03MVC4-UKBR.domain1.systemhost.net>

>   In IPv6, it is strictly not uncommon for a host to have 
> multiple IP addresses.  So, you don't renumber the hosts or 
> use NAT. You just let them have an IP address from your ISP, 
> if you have one.

True

>   FURTHERMORE, shim6 will let you failover active connections 
> from one host to another without starting a new TCP connection.

False. SHIM6 does not exist.

--Michael Dillon


From michael.dillon at bt.com  Fri Sep 14 07:57:44 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 14 Sep 2007 12:57:44 +0100
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKAEIBGMAC.davids@webmaster.com>
References: <D03E4899F2FB3D4C8464E8C76B3B68B0010303B2@E03MVC4-UKBR.domain1.systemhost.net>
	<MDEHLPKNGKAHNMBLJOLKAEIBGMAC.davids@webmaster.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00107D14C@E03MVC4-UKBR.domain1.systemhost.net>

> > > Why should ARIN give out referalls to servers that
> > > *intentionally* timeout?
> 
> > Because ARIN's customer asks them to do this.
> 
> That can justify providing services to a spammer, after all, 
> they ask you to do so.

ARIN is fully justified in providing number allocations and in-addr.arpa
services to spammers since nothing in ARIN policy give ARIN the right to
refuse such services. In fact, ARIN policy does not allow ARIN to
consider business models at all.

> > > Why should ARIN be a party in wasting other people's time and 
> > > resources?
> 
> > Because the people whose resources are being wasted are 
> customers of 
> > the organization which intentionally has their servers timeout.
> 
> Not so. I may or may not be an ARIN customer if I'm reverse 
> resolving an IP address assigned by ARIN.

Now you are saying that an ARIN customer is hurting you and you want
ARIN to go and hurt them back because you yourself are unable to
retaliate. That is not within the scope of ARIN's charter, and in fact,
not within the scope of most police forces.

> > That's right, I said CORRECT ERROR. I didn't design the 
> application, 
> > but that is how it works. The solution was to put back the lame 
> > delegation in the .com zone, and then to transfer the 
> registration to 
> > another registrar who will ensure that the lame delegation is left 
> > untouched in the future.
> 
> So long as the address space involved doesn't connect to 
> people who aren't in on this scheme, I have no problem. If 
> they do, this is simply an abuse of the cooperation necessary 
> to make the Internet work.

It is an abuse of cooperation when you do not follow the principle of
being liberal about what you accept. Instead, you want ARIN to force
others to be conservative about what they send. This is not a
cooperative stance to take.

> It is morally in the same category 
> as a business model based on spam. You make other people do 
> extra work simply because you can, even though it's outside 
> the scope of the implied agreement that connects them to you.

I could claim that your proposals are morally in the same category as
genocide but I won't because I cannot prove that claim anymore than you
can prove yours.

> Though I do agree that this is sufficiently minor that it 
> shouldn't policed by ARIN.

Then it clearly is not in the same category as spam which is a major
problem on the Internet today.

> Let me make it clear that I don't think it's sensible to try 
> to create a policy that can, by robotic mindless operation 
> perfectly handle every situation. However, ARIN should police 
> its delegations at least minimally to curtail what is actual abuse.

You just said that it shouldn't be policed by ARIN!? 

ARIN is not a police force. ARIN doesn't carry a big stick. ARIN's main
tool is talking softly. In order to have a workable policy, we need to
approach it with talking softly in mind. ARIN can and should keep its
database clean. ARIN can and should maintain contacts with the
appropriate people in organizations who use its services. Here there is
a gap since ARIN currently does not maintain contact with DNS
administrators. ARIN could and should educate the organizations using
its services, and the general Internet public. Here there is also a gap
since ARIN does not inform DNS admins when it finds full or partial
lameness. ARIN does not record the results of its lameness survey in the
public whois directory. These are areas that policy can and should
address. 

--Michael Dillon


From mysidia at gmail.com  Fri Sep 14 08:46:01 2007
From: mysidia at gmail.com (James Hess)
Date: Fri, 14 Sep 2007 07:46:01 -0500
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B00107D14C@E03MVC4-UKBR.domain1.systemhost.net>
References: <D03E4899F2FB3D4C8464E8C76B3B68B0010303B2@E03MVC4-UKBR.domain1.systemhost.net>
	<MDEHLPKNGKAHNMBLJOLKAEIBGMAC.davids@webmaster.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B00107D14C@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <6eb799ab0709140546t7df53a9cxd59d0c00fd49b523@mail.gmail.com>

On 9/14/07, michael.dillon at bt.com <michael.dillon at bt.com> wrote:
>
> ARIN is fully justified in providing number allocations and in-addr.arpa
> services to spammers since nothing in ARIN policy give ARIN the right to
> refuse such services. In fact, ARIN policy does not allow ARIN to
> consider business models at all.

I think we should recognize that this is totally different from the situation
with spam, just like putting advertising on your website or your FTP server
is not like spam.

Because noone forces anyone to try to reverse lookup their IP address
-- if you attempt a reverse lookup, then it's because you took some manual
action, or you have setup software on your  equipment that is
automatically attempts reverse lookups on the DNS.


You've gone out to their address block's DNS servers and made a
request. This is different from the situation with spam, where a spammer
connects to your mail server and gives you a big message you didn't want or
ask for; it is actually the content of the message and the list of
recipients that
is what makes a spammer (not the remote connection to a publicly bound service).


I hope ARIN doesn't consider it required to give everyone everything they need
based on business model.

I would hope that ARIN would not go out of their way to give spammers
everything the spammers can justify based on their business model,
being totally non-judgemental.

In particular, that ARIN would not give spammers new allocations
based on the justification of the need to evade IP-based blocklists on
the prior IP range.

Essentially, I think spammers would love to get additional blocks of IPs every
couple weeks, once all the blacklists out there have fully included
the old range
and if spammers could do what they want would probably return the old range to
ARIN, in exchange for a new one,  since it being widely blocked makes it
useless for spamming.

That's exactly the sort of "help" ARIN should watch out for and refuse, IMO.
With some care, since spammers might not admit the real reasons they want
to do strange stuff.


--
-J


From davids at webmaster.com  Fri Sep 14 09:43:08 2007
From: davids at webmaster.com (David Schwartz)
Date: Fri, 14 Sep 2007 06:43:08 -0700
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
In-Reply-To: <6eb799ab0709140546t7df53a9cxd59d0c00fd49b523@mail.gmail.com>
Message-ID: <MDEHLPKNGKAHNMBLJOLKEELJGMAC.davids@webmaster.com>


> On 9/14/07, michael.dillon at bt.com <michael.dillon at bt.com> wrote:

> > ARIN is fully justified in providing number allocations and in-addr.arpa
> > services to spammers since nothing in ARIN policy give ARIN the right to
> > refuse such services. In fact, ARIN policy does not allow ARIN to
> > consider business models at all.

Number allocations are not operational in the sense they're just unique.
However, DNS delegations *are* operational in this sense.

> I think we should recognize that this is totally different from
> the situation
> with spam, just like putting advertising on your website or your
> FTP server
> is not like spam.

> Because noone forces anyone to try to reverse lookup their IP address
> -- if you attempt a reverse lookup, then it's because you took some manual
> action, or you have setup software on your  equipment that is
> automatically attempts reverse lookups on the DNS.

Nobody forces you to receive email either. If you put up an email server,
it's because you took some manual action, or you have setup software on your
equipment that automatically attempts to receive email.

See? Same thing.

DNS is an agreement. I do this, and you do that. If you violate the
agreement, and deliberately make me do more work than my share of the
agreement, that is abuse. If it wastes the time and resources of real human
beings, that's a bad thing.

The only difference is who reaches out first. But I'll bet in most of these
cases, the person with the lame delegation reaches out first and that's why
you attempt to reverse resolve them.

You have a right to reverse resolve people who connect to you, just like you
have a right to run a mail server. I have no right to make you work
overly-hard or slow down your reverse resolve just as I have no right to
push spam at you.

> You've gone out to their address block's DNS servers and made a
> request. This is different from the situation with spam, where a spammer
> connects to your mail server and gives you a big message you
> didn't want or
> ask for; it is actually the content of the message and the list of
> recipients that
> is what makes a spammer (not the remote connection to a publicly
> bound service).

No, it's the same thing conceptually. They give you a lame delegation that
you didn't want or ask for. (Does DNS have a way to ask for lame
delegations? I don't think so.)

Email works by cooperation. Spammers abuse that cooperation. DNS works by
cooperation. Intentional lame delegations abuse that cooperation. In both
cases, the time and resources of real human beings are wasted.

An ARIN address assignment is nothing like Internet service. But if ARIN
provided Internet services, it should impose operational controls on those
services, like disconnecting spammers.

Reverse address delegation is nothing like address assignment. It's more
like Internet service. It's a way of telling others "this is how to reach me
and you can access me for this purpose". It's an operational service, not a
registry service, and it should have operational controls.

However, even for address services, I think ARIN would apply operational
controls if the services caused operational problems. For example suppose
ARIN had a policy that allowed people to exchange their blocks for new
equally-sized blocks any time they wanted. If spammers were using this to
evade blacklists, I'm pretty confident ARIN would change the policy.

When you understand why the policy would be changed in that case, you will
understand why the policy could benefit from a change in this case. A flaw
in the policy permits direct operational harm.

Again, I'm not arguing that an intentional lame delegation is of anywhere
near the degree as spam, just that it's of the same type.

DS




From info at arin.net  Fri Sep 14 10:11:23 2007
From: info at arin.net (Member Services)
Date: Fri, 14 Sep 2007 10:11:23 -0400
Subject: [ppml] ARIN commments regarding Lame Delegation Policy
Message-ID: <46EA968B.40104@arin.net>

The following comments are being provided in response to recent 
discussions and questions raised on the ppml.

ARIN has implemented the methodology for identifying lameness as 
described at:

      http://www.arin.net/reference/lame_delegations.html

Using the 208.114.64.0/19 example posted on ppml, each name server would 
be tested for all 32 reverse zones.  A name server would be deemed lame 
only when all zones fail. If one or more of the reverse zones in the /19 
is configured properly for a given name server, the name server 
delegation for that /19 would be declared 'good'.

With regard to lame delegations reported to ARIN by third parties, ARIN 
will not respond to requests to remove these delegations without 
exercising the procedure adopted to implement the lame delegation policy.

ARIN staff believes the current policy, as ratified, provides sufficient 
direction for lame delegations to be cleaned up.

Regards,

Nate Davis
Chief Operations Officer
American Registry for Internet Numbers (ARIN)


From Ed.Lewis at neustar.biz  Fri Sep 14 10:42:49 2007
From: Ed.Lewis at neustar.biz (Edward Lewis)
Date: Fri, 14 Sep 2007 10:42:49 -0400
Subject: [ppml] ARIN commments regarding Lame Delegation Policy
In-Reply-To: <46EA968B.40104@arin.net>
References: <46EA968B.40104@arin.net>
Message-ID: <a06240803c3104dc7b8e8@[10.31.32.66]>

At 10:11 -0400 9/14/07, Member Services wrote:

>Using the 208.114.64.0/19 example posted on ppml, each name server would
>be tested for all 32 reverse zones.  A name server would be deemed lame
>only when all zones fail. If one or more of the reverse zones in the /19
>is configured properly for a given name server, the name server
>delegation for that /19 would be declared 'good'.
...
>ARIN staff believes the current policy, as ratified, provides sufficient
>direction for lame delegations to be cleaned up.

I agree with the point about the policy but I have submitted an ACSP 
item to suggest that lame delegations be managed on a per-zone basis 
and not per-network.  As this isn't a policy issue (to me) and we 
have other proposals that should be hammered out in a month's time, I 
don't plan to follow up on this on PPML.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.


From mcr at xdsinc.net  Fri Sep 14 10:53:44 2007
From: mcr at xdsinc.net (mcr at xdsinc.net)
Date: Fri, 14 Sep 2007 10:53:44 -0400
Subject: [ppml] IPv6 flawed?
In-Reply-To: <3c3e3fca0709131814q2c65fab8le376b598a74f404c@mail.gmail.com> 
References: <NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
	<021c01c7f645$a3fd47d0$065e5e0a@integrated.net>
	<20070913213843.31ADF1444DF@smtp2.arin.net>
	<3c3e3fca0709131814q2c65fab8le376b598a74f404c@mail.gmail.com>
Message-ID: <20070914145346.2EF9C144711@smtp2.arin.net>

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


>>>>> "William" == William Herrin <arin-contact at dirtside.com> writes:
    William> The problem is that:

    William> 1. That's only close to true if you use stateless autoconfiguration
    William> which suffers from such a severe security issue that it might well
    William> drop out of use.

  shim6 doesn't depend upon using stateless autoconfiguration.
  You can use whatever other method you like, including dhcpv6.
(I have written a document on securing dhcp(v4) with RSA keys, but never
implemented it, as yet)

    William> 2. Its not actually true even if you do use stateless
    William> autoconfiguration because you have to talk to other hosts on your
    William> interior network via their full IP addresses, not via just the however
    William> many bits that haven't changed. There's much more to communication
    William> than a host's own IP address.

  This is why you need a "site" (not-local) prefix which is always available.

    William> Standard or no standard, someone is going to build it, someone is
    William> going to sell it and when folks start buying it everybody else is
    William> going to follow.

  okay. but why bother? v4+NAT does everything that v6+NAT does.

- -- 
Michael Richardson <mcr at xdsinc.net>
XDS Inc, Ottawa, ON             
Personal: http://www.sandelman.ca/mcr/ 


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

iQDVAwUBRuqgdu0sRu40D6vCAQI7kwX/XNGBhC/xRwUrAMZtXVsLvnB8NkWug7iD
9jtZUGQQo397tC6L2OdYu8UxpfleazVGnSjzEFagUiQ08irfl0IkkqlMJMK75ZGn
X+gRKrAsL7XNXZCuTugGSgWNBcc3Ik0TUQstjROenPRFccIqpt+lOhZmPYTfltPw
I65AcnLZxqoJv4x+CShwLpAVebQ8/Hy51tAHNAsn0OTkmW2pioUhLO+AuhF/tU1c
Wqa1jQH49s37xlsi/M5hamzOr7CZLNYk
=z88F
-----END PGP SIGNATURE-----


From mcr at xdsinc.net  Fri Sep 14 10:55:29 2007
From: mcr at xdsinc.net (mcr at xdsinc.net)
Date: Fri, 14 Sep 2007 10:55:29 -0400
Subject: [ppml] IPv6 flawed?
In-Reply-To: <75cb24520709131821r196fa8ete6aaad5a9389fb35@mail.gmail.com> 
References: <NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
	<021c01c7f645$a3fd47d0$065e5e0a@integrated.net>
	<20070913213843.31ADF1444DF@smtp2.arin.net>
	<75cb24520709131821r196fa8ete6aaad5a9389fb35@mail.gmail.com>
Message-ID: <20070914145530.BF006144711@smtp2.arin.net>

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


>>>>> "Christopher" == Christopher Morrow <christopher.morrow at gmail.com> writes:
    Christopher> There have been more than a few talks/panels/discussions of shim6/ipv6
    Christopher> at previous nanog, arin, IETF meetings. The situation is far from this
    Christopher> simple for production enterprise networks. It's even less simple for
    Christopher> ISP-type networks.

  ISPs are not supposed to use shim6.

    Christopher> SHIM6 seems to fit certain niches, I'm not sure that enterprise
    Christopher> multi-homing nor 'provider' multihoming are them. Content provider
    Christopher> multihoming seems even less likely to use shim6...

  if it doesn't solve enterprise multihoming, then there is a problem.
  The rest of the uses are not really in scope.

- -- 
Michael Richardson <mcr at xdsinc.net>
XDS Inc, Ottawa, ON             
Personal: http://www.sandelman.ca/mcr/ 


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

iQDVAwUBRuqg3+0sRu40D6vCAQL8NAYAhkCWXWX42ugPlNZL+lKbznkMwzScIpJ0
Xf+dpC/OOm50MbzAzX39xXopD6Fg1dd/yxZQuQeZv7BaTpnycc2W3oIzQpCjRI21
X6TFHORPk8nUE8dvSa78LObEus+3x0AQLxmTxqnmNWqvt1Ri5Foup4uz5sLjWC9m
fkSR4tUI/jp9O6OptBfwg9GN9v06o1J39Ni6HAlupd6rKQqnsJ8xvHOVLjds7tZX
nMIaz42joGGQrQHRetMuz9VmC7eryEeZ
=ar3A
-----END PGP SIGNATURE-----


From owen at delong.com  Fri Sep 14 11:16:57 2007
From: owen at delong.com (Owen DeLong)
Date: Fri, 14 Sep 2007 08:16:57 -0700
Subject: [ppml] ARIN commments regarding Lame Delegation Policy
In-Reply-To: <46EA968B.40104@arin.net>
References: <46EA968B.40104@arin.net>
Message-ID: <734511B2-BC6D-4496-9B9D-6105324A6880@delong.com>

Nate,
	Could you clarify if you feel that ARIN would be unable to continue  
this
function if section 7 were deleted?

Thanks,

Owen

On Sep 14, 2007, at 7:11 AM, Member Services wrote:

> The following comments are being provided in response to recent
> discussions and questions raised on the ppml.
>
> ARIN has implemented the methodology for identifying lameness as
> described at:
>
>       http://www.arin.net/reference/lame_delegations.html
>
> Using the 208.114.64.0/19 example posted on ppml, each name server  
> would
> be tested for all 32 reverse zones.  A name server would be deemed  
> lame
> only when all zones fail. If one or more of the reverse zones in  
> the /19
> is configured properly for a given name server, the name server
> delegation for that /19 would be declared 'good'.
>
> With regard to lame delegations reported to ARIN by third parties,  
> ARIN
> will not respond to requests to remove these delegations without
> exercising the procedure adopted to implement the lame delegation  
> policy.
>
> ARIN staff believes the current policy, as ratified, provides  
> sufficient
> direction for lame delegations to be cleaned up.
>
> Regards,
>
> Nate Davis
> Chief Operations Officer
> American Registry for Internet Numbers (ARIN)
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.



From christopher.morrow at gmail.com  Fri Sep 14 11:19:43 2007
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Fri, 14 Sep 2007 11:19:43 -0400
Subject: [ppml] IPv6 flawed?
In-Reply-To: <46eaa0e3.1f538c0a.5010.ffff8788SMTPIN_ADDED@mx.google.com>
References: <NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
	<021c01c7f645$a3fd47d0$065e5e0a@integrated.net>
	<20070913213843.31ADF1444DF@smtp2.arin.net>
	<75cb24520709131821r196fa8ete6aaad5a9389fb35@mail.gmail.com>
	<46eaa0e3.1f538c0a.5010.ffff8788SMTPIN_ADDED@mx.google.com>
Message-ID: <75cb24520709140819p63d1eef9gcfeadff123645b23@mail.gmail.com>

On 9/14/07, mcr at xdsinc.net <mcr at xdsinc.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> >>>>> "Christopher" == Christopher Morrow <christopher.morrow at gmail.com> writes:
>     Christopher> There have been more than a few talks/panels/discussions of shim6/ipv6
>     Christopher> at previous nanog, arin, IETF meetings. The situation is far from this
>     Christopher> simple for production enterprise networks. It's even less simple for
>     Christopher> ISP-type networks.
>
>   ISPs are not supposed to use shim6.

correct.

>
>     Christopher> SHIM6 seems to fit certain niches, I'm not sure that enterprise
>     Christopher> multi-homing nor 'provider' multihoming are them. Content provider
>     Christopher> multihoming seems even less likely to use shim6...
>
>   if it doesn't solve enterprise multihoming, then there is a problem.
>   The rest of the uses are not really in scope.
>

like I said, look for the preso's on shim6 from nanog/arin/ietf of the
last 3 years. shim6 operationally doesn't seem to fit the needs of the
enterprise, atleast not a medium or large enterprise.

Like I said, there exist a few niche places where shim6 seems to make
some sense... enterprise and ISP multi-homing are not them.

-Chris


From stephen at sprunk.org  Fri Sep 14 13:08:46 2007
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 14 Sep 2007 12:08:46 -0500
Subject: [ppml] IPv6 flawed?
References: <NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
	<021c01c7f645$a3fd47d0$065e5e0a@integrated.net>
Message-ID: <018a01c7f6f9$49194170$593816ac@atlanta.polycom.com>

Thus spake "Leroy Ladyzhensky" <leroy at emailsorting.com>
> I know of some companies that may have 1000 plus workstations
> and servers on their internal network but would never qualify for
> IPv4 or IPv6 address's because that don't need much... 10 or so
> real IP's

Such a company would qualify for PIv4 and thus PIv6 because the policy 
counts _all_ hosts, not just publicly-visible hosts or NAT boxes.  You can 
get a PI assignment for a _completely disconnected_ network if you have 
enough hosts, though RFC 1918/4193 space is recommended in such a case.

> so, way down the road, when the move to IPv6 why would they
> number all their inside machines just because that's the block
> their ISP handed to them? just to renumber when they change to
> another ISP?

That's why we have PI policies for both v4 and v6.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 




From randy at psg.com  Fri Sep 14 14:03:05 2007
From: randy at psg.com (Randy Bush)
Date: Fri, 14 Sep 2007 08:03:05 -1000
Subject: [ppml] ARIN commments regarding Lame Delegation Policy
In-Reply-To: <46EA968B.40104@arin.net>
References: <46EA968B.40104@arin.net>
Message-ID: <46EACCD9.7090503@psg.com>

> Using the 208.114.64.0/19 example posted on ppml, each name server would 
> be tested for all 32 reverse zones.  A name server would be deemed lame 
> only when all zones fail. If one or more of the reverse zones in the /19 
> is configured properly for a given name server, the name server 
> delegation for that /19 would be declared 'good'.

is arin eng/ops happy/comfortable with this?  i.e. does arin ops/eng
feel that re-classifying a delegation as erroneous when any sub-zone
delegation is lame to be ill-advised?

> ARIN staff believes the current policy, as ratified, provides sufficient 
> direction for lame delegations to be cleaned up.

you folk live too near to dc :)  using "lame delegations" in this way is
deliciously ambiguous.

lame delegations or lame delegations as currently defined?  i.e. you
have the needed ammo to deal with the problem as defined today, but are
not commenting on what could/should be defined?

randy


From info at arin.net  Fri Sep 14 15:37:48 2007
From: info at arin.net (Member Services)
Date: Fri, 14 Sep 2007 15:37:48 -0400
Subject: [ppml] ARIN commments regarding Lame Delegation Policy
In-Reply-To: <734511B2-BC6D-4496-9B9D-6105324A6880@delong.com>
References: <46EA968B.40104@arin.net>
	<734511B2-BC6D-4496-9B9D-6105324A6880@delong.com>
Message-ID: <46EAE30C.10704@arin.net>

Hi Owen-

Yes, ARIN would be able to continue to actively test for lameness in the 
reverse DNS zones if section 7 were to be removed from the NRPM.  This 
is because the community has clearly expressed its interest in having 
ARIN identify and remedy lame IN-ADDR.ARPA delegations for address 
blocks that it administers.  In fact, additional community input on the 
lameness testing has come in just recently through the ARIN Consultation 
and Suggestion Process.  Had the ACSP been in place previously, we feel 
that lame delegations would likely have been addressed through that 
process as an operational issue rather than a policy issue.

Regards,

Leslie Nobile
Director, Registration Services
American Registry for Internet Numbers


Owen DeLong wrote:
> Nate,
>     Could you clarify if you feel that ARIN would be unable to continue  
> this
> function if section 7 were deleted?
> 
> Thanks,
> 
> Owen
> 
> On Sep 14, 2007, at 7:11 AM, Member Services wrote:
> 
>> The following comments are being provided in response to recent
>> discussions and questions raised on the ppml.
>>
>> ARIN has implemented the methodology for identifying lameness as
>> described at:
>>
>>       http://www.arin.net/reference/lame_delegations.html
>>
>> Using the 208.114.64.0/19 example posted on ppml, each name server  would
>> be tested for all 32 reverse zones.  A name server would be deemed  lame
>> only when all zones fail. If one or more of the reverse zones in  the /19
>> is configured properly for a given name server, the name server
>> delegation for that /19 would be declared 'good'.
>>
>> With regard to lame delegations reported to ARIN by third parties,  ARIN
>> will not respond to requests to remove these delegations without
>> exercising the procedure adopted to implement the lame delegation  
>> policy.
>>
>> ARIN staff believes the current policy, as ratified, provides  sufficient
>> direction for lame delegations to be cleaned up.
>>
>> Regards,
>>
>> Nate Davis
>> Chief Operations Officer
>> American Registry for Internet Numbers (ARIN)
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the  ARIN 
>> Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
>> Member Services
>> Help Desk at info at arin.net if you experience any issues.
> 
> 


From sleibrand at internap.com  Fri Sep 14 16:15:59 2007
From: sleibrand at internap.com (Scott Leibrand)
Date: Fri, 14 Sep 2007 13:15:59 -0700
Subject: [ppml] ARIN commments regarding Lame Delegation Policy
In-Reply-To: <46EAE30C.10704@arin.net>
References: <46EA968B.40104@arin.net>	<734511B2-BC6D-4496-9B9D-6105324A6880@delong.com>
	<46EAE30C.10704@arin.net>
Message-ID: <46EAEBFF.4070900@internap.com>

Thanks for that feedback, Leslie.

Based on this assessment, I believe that John's policy proposal should 
be transitioned over to the ACSP, rather than being adopted through the 
policy process.  As a suggested change to operational procedure, I think 
I would support John's proposed changes.  I'm still undecided on whether 
to support Owen's proposal to remove section 7, but at least would not 
oppose it...

-Scott

Member Services wrote:
> Hi Owen-
>
> Yes, ARIN would be able to continue to actively test for lameness in the 
> reverse DNS zones if section 7 were to be removed from the NRPM.  This 
> is because the community has clearly expressed its interest in having 
> ARIN identify and remedy lame IN-ADDR.ARPA delegations for address 
> blocks that it administers.  In fact, additional community input on the 
> lameness testing has come in just recently through the ARIN Consultation 
> and Suggestion Process.  Had the ACSP been in place previously, we feel 
> that lame delegations would likely have been addressed through that 
> process as an operational issue rather than a policy issue.
>
> Regards,
>
> Leslie Nobile
> Director, Registration Services
> American Registry for Internet Numbers
>
>
> Owen DeLong wrote:
>   
>> Nate,
>>     Could you clarify if you feel that ARIN would be unable to continue  
>> this
>> function if section 7 were deleted?
>>
>> Thanks,
>>
>> Owen
>>
>> On Sep 14, 2007, at 7:11 AM, Member Services wrote:
>>
>>     
>>> The following comments are being provided in response to recent
>>> discussions and questions raised on the ppml.
>>>
>>> ARIN has implemented the methodology for identifying lameness as
>>> described at:
>>>
>>>       http://www.arin.net/reference/lame_delegations.html
>>>
>>> Using the 208.114.64.0/19 example posted on ppml, each name server  would
>>> be tested for all 32 reverse zones.  A name server would be deemed  lame
>>> only when all zones fail. If one or more of the reverse zones in  the /19
>>> is configured properly for a given name server, the name server
>>> delegation for that /19 would be declared 'good'.
>>>
>>> With regard to lame delegations reported to ARIN by third parties,  ARIN
>>> will not respond to requests to remove these delegations without
>>> exercising the procedure adopted to implement the lame delegation  
>>> policy.
>>>
>>> ARIN staff believes the current policy, as ratified, provides  sufficient
>>> direction for lame delegations to be cleaned up.
>>>
>>> Regards,
>>>
>>> Nate Davis
>>> Chief Operations Officer
>>> American Registry for Internet Numbers (ARIN)
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the  ARIN 
>>> Public Policy
>>> Mailing List (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
>>> Member Services
>>> Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>   


From owen at delong.com  Sat Sep 15 11:42:34 2007
From: owen at delong.com (Owen DeLong)
Date: Sat, 15 Sep 2007 08:42:34 -0700
Subject: [ppml] Revised 2007-17
Message-ID: <2E14E78C-06D7-49CC-9093-1385B436CF58@delong.com>

Based on input from the AC and comments on the mailing list, I have
decided to revise 2007-17.

Specific ideas incorporated into this proposal:
	1.	Specific fee statements removed.  Fees are not the realm
		of IRPEP, so, it is replaced with a requirement for the BoT
		to develop appropriate incentives.

	2.	An oversight in the original version did not provide a
		timeframe in which addresses were to be returned.
		This version adopts a 12 month timeframe with staff
		discretion for up to 2 extensions of 6 months each.

	3.	This proposal differs from the existing section 4.6 in
		that it places discretion over whether a subnet of
		a returned block may be retained or not in the hands
		of the address holder.  There was some suggestion
		from some AC members that this discretion should
		only be given to legacy holders while ARIN staff should
		retain discretion over non-legacy resources.  I do not
		have a strong opposition to such a change, but, I do
		feel that the policy is actually better as is, so, I have
		chosen not to add this revision.  I would like to see
		discussion on this area, and, if it is possible, I would
		like this version to allow the AC discretion to gauge
		consensus on whether this edit should be added
		prior to last call.


Revised proposal is as follows:


Policy Proposal 2007-17
Legacy Outreach and Partial Reclamation

Author: Owen DeLong

Proposal Version: 1.0
Submission Date: 2007 September 15

Proposal type: modify

Policy term: permanent

Policy statement:

Modify section 4.6 as follows:

4.6 Amnesty Requests:

ARIN will accept the return or relinquishment of
any address space from any existing address holder. If the address
holder wishes to aggregate into a single block, ARIN may work with the
address holder to arrive at an allocation or assignment which is equal
to or smaller than the sum of their existing blocks and which best meets
the needs of the existing holder and the community. The organization
returning the addresses shall have 12 months from the date they receive
their new addresses to return the addresses under this policy.  
Organizations
may request no more than 2 six month extensions to this time, which,
may be granted at ARIN the discretion of ARIN staff. There shall be no
fee for returning addresses under this policy. Further, organizations
returning addresses under this policy shall receive the following  
benefits:

1. If the organization does not currently pay ARIN fees, they shall
remain fee exempt.

2. The BoT shall develop an incentive program to encourage such
returns.  Such incentives may include fee reductions and/or other
such mechanisms as the BoT deems appropriate.

3. Any organization returning address space under this policy shall
continue under their existing RSA or they may choose to sign the current
RSA. For organizations which currently do not have an RSA, they may sign
the current RSA, or, they may choose to remain without an RSA.

4. All organizations returning space under this policy shall, if they
meet other eligibility requirements and so request, obtain an
appropriate IPv6 end-user assignment or ISP allocation as applicable,
with no fees for the first 5 years. Organizations electing to receive
IPv6 allocation/assignment under this provision must sign a current RSA
and must agree that all of their IPv4 and ASN resources are  
henceforth subject
to the RSA. Organizations taking this election shall be subject to
end-user fees for their IPv4 resources not previously under an ARIN RSA.
If they are already an ARIN subscriber, then IPv4 resources affected by
this process may, instead, be added to their existing subscriber
agreement at the address holder's discretion.

Rationale:

The current amnesty policy does a nice job of facilitating aggregation,
which was the intent when it was drafted. However, as we approach IPv4
free-space exhaustion, the community now has an additional need to
facilitate address reclamation.

A very high percentage of underutilized space is in the hands of legacy
holders who currently have no benefit to joining the ARIN process.
Further, there is an unfortunate perception that doing so will require
force the legacy holder into certain future disadvantages. This proposal
attempts to resolve both of those issues while also providing some
incentive to legacy organizations to start using IPv6 resources and
bring their IPv4 resources into the ARIN process.

This policy attempts to provide some benefit and remove most of the
costs of making partial IPv4 returns. It also attempts to provide an
incentive for these IPv4 holders to join the ARIN process.

It is suggested that the BoT adopt fee incentives such as the
elimination of 2 years of ARIN fees for each /20 returned.


Timetable for implementation: Immediate



From owen at delong.com  Sat Sep 15 11:51:04 2007
From: owen at delong.com (Owen DeLong)
Date: Sat, 15 Sep 2007 08:51:04 -0700
Subject: [ppml] Revised Proposal -- Eliminate Lame Server Policy
Message-ID: <6C803415-DC66-4AAC-BF39-DA4C7CC3D96B@delong.com>

Based on discussions with the AC Shepherds and input received on the
mailing list, I am revising my Lame Server proposal.

Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0

1.	Policy Proposal Name: Deprecate Lame Server Policy
2.	Author
	a.	name: Owen DeLong
	b.	email: owen at delong.com
	c.	telephone: 408-921-6984
	d.	organization: JITTR Networks

3.	Proposal Version: 2.0
4.	Submission Date: 11 September, 2007
5.	Proposal type: modify
	new, modify, or delete.
6.	Policy term: permanent
	temporary, permanent, or renewable.
7.	Policy statement:
		Replace Section 7 of the NRPM in it's entirety with the
		following text:

	7.	Staff action to improve ARIN public database accuracy and
		consistency.

		7.1	ARIN staff shall take reasonable and practicable means to
			ensure and improve the accuracy of all ARIN public
			databases, including, but, not limited to WHOIS,
			delegations of the in-addr.arpa zone, and, delegations
			of the ip6.arpa zone.

8.	Rationale:
		Recent PPML discussion has called attention to the
		fact that lame DNS delegations are more an operational
		issue than one of policy.  As such, the existing lame
		delegation policy should be removed from the NRPM
		to remove the resultant confusion.  This is not meant
		to prevent ARIN staff from taking reasonable action
		WRT DNS operational issues related to resources issued
		by ARIN, but, such action can be covered by staff
		operational guidelines and is not within the scope
		of Address Policy.

9.	Timetable for implementation:
		1 June, 2008
10.	Meeting presenter: Owen DeLong

END OF TEMPLATE



From sleibrand at internap.com  Sat Sep 15 20:04:37 2007
From: sleibrand at internap.com (Scott Leibrand)
Date: Sat, 15 Sep 2007 17:04:37 -0700
Subject: [ppml] Revised Proposal -- Eliminate Lame Server Policy
In-Reply-To: <6C803415-DC66-4AAC-BF39-DA4C7CC3D96B@delong.com>
References: <6C803415-DC66-4AAC-BF39-DA4C7CC3D96B@delong.com>
Message-ID: <46EC7315.2070602@internap.com>

Thanks, Owen.  I would support this revised proposal, as it does a good 
job of moving public discussions of operational procedure over to the 
ACSP, while retaining a general policy mandate supporting such activities.

-Scott

Owen DeLong wrote:
> Based on discussions with the AC Shepherds and input received on the
> mailing list, I am revising my Lame Server proposal.
>
> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
>
> 1.	Policy Proposal Name: Deprecate Lame Server Policy
> 2.	Author
> 	a.	name: Owen DeLong
> 	b.	email: owen at delong.com
> 	c.	telephone: 408-921-6984
> 	d.	organization: JITTR Networks
>
> 3.	Proposal Version: 2.0
> 4.	Submission Date: 11 September, 2007
> 5.	Proposal type: modify
> 	new, modify, or delete.
> 6.	Policy term: permanent
> 	temporary, permanent, or renewable.
> 7.	Policy statement:
> 		Replace Section 7 of the NRPM in it's entirety with the
> 		following text:
>
> 	7.	Staff action to improve ARIN public database accuracy and
> 		consistency.
>
> 		7.1	ARIN staff shall take reasonable and practicable means to
> 			ensure and improve the accuracy of all ARIN public
> 			databases, including, but, not limited to WHOIS,
> 			delegations of the in-addr.arpa zone, and, delegations
> 			of the ip6.arpa zone.
>
> 8.	Rationale:
> 		Recent PPML discussion has called attention to the
> 		fact that lame DNS delegations are more an operational
> 		issue than one of policy.  As such, the existing lame
> 		delegation policy should be removed from the NRPM
> 		to remove the resultant confusion.  This is not meant
> 		to prevent ARIN staff from taking reasonable action
> 		WRT DNS operational issues related to resources issued
> 		by ARIN, but, such action can be covered by staff
> 		operational guidelines and is not within the scope
> 		of Address Policy.
>
> 9.	Timetable for implementation:
> 		1 June, 2008
> 10.	Meeting presenter: Owen DeLong
>
> END OF TEMPLATE
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>   


From bjohnson at drtel.com  Sun Sep 16 00:51:36 2007
From: bjohnson at drtel.com (Brian Johnson)
Date: Sat, 15 Sep 2007 23:51:36 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOCENCHDAA.tedm@ipinc.net>
References: <DD7FE473A8C3C245ADA2A2FE1709D90B1C8E65@server2003.arneill-py.sacramento.ca.us>
	<NABBJOELMNGNJNGPKDDOCENCHDAA.tedm@ipinc.net>
Message-ID: <29A54911243620478FF59F00EBB12F47B39E90@ex01.drtel.lan>

Ted wrote:
> 
> If IPv6 is assigned sequentially and it is as big as everyone claims,
> then how soon do you think the RIRs will run out of IPv6 assignments?
> 10 years?  50 years?  100 years?
> 

Well, I think this math is straight forward. If every ASN possible
(currently 65536 or 2^16) requested a /32 of IPv6 space (which is 2^64 *
(the entire size of IPv4 space 2^32) then there would still be 16 bits
of unused space available (minus any reserved space).

Currently the 001 space has been set aside for global unicast
assignment. ARIN has 5 /23s and 1 /12 within this range (according to
http://www.iana.org/assignments/ipv6-unicast-address-assignments). That
gives ARIN 1051136 /32 assignments it can assign currently. This is
enough to provide a /32 to every possible asn (even the reserved and
unassigned) more than 16 times over.

However, shortly after ARIN (or any other RIR) runs out of space I
believe your hover car may need its 10 million mile tune-up and my
great-great-great-great-great-grandson can help you out with that. ;-)


> I think it would be very easy to look and find a range that won't be
> even close to being assigned for another 100 years and set up exactly
> the same NAT-based network we have today with IPv4, despite what IETF
> wants.  All you really need is the IPv6 NAT device itself - and
someone
> will build that once there's demand for it.
> 

Feel free to do what you want, but it is very poor form to utilize
something that is not yours to use and when you have issues, don't
complain unless you want a clue stick to the side of the noggin.

- Brian



From michael.dillon at bt.com  Sun Sep 16 07:47:23 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sun, 16 Sep 2007 12:47:23 +0100
Subject: [ppml] The wiki at www.getipv6.info
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00107D422@E03MVC4-UKBR.domain1.systemhost.net>


There is a wiki at www.getipv6.info that we should be making more use
of.

Also, ARIN staff should not be neglecting this wiki as they have in the
past. In particular, staff have locked changes to the main page but they
do not monitor the discussion tab of that page where changes are
requested.

This wiki was announced in the recent ARIN newsletter but visitors to it
will find it sadly empty. Given the importance of planning IPv6
deployment in preparation for IPv4 exhaustion, I think we should promote
this wiki more widely and encourage more broadly-based participation in
the wiki.

-------------------------------------------------------
Michael Dillon
RadianzNet Capacity Management, 66 Prescot St., London, E1 8HG, UK
Mobile: +44 7900 823 672 
Internet: michael.dillon at btradianz.com
Phone: +44 20 7650 9493 Fax: +44 20 7650 9030
http://www.btradianz.com
 
One Community One Connection One Focus 



From Yves.Poppe at vsnlinternational.com  Sun Sep 16 19:07:15 2007
From: Yves.Poppe at vsnlinternational.com (Yves Poppe)
Date: Sun, 16 Sep 2007 19:07:15 -0400
Subject: [ppml] The wiki at www.getipv6.info
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B00107D422@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <D830F165560AAC48AE5C9DFB93F75CF501228C9D@CAN-MSG.vsnl.co.in>

all,

another decent IPv6 wiki is maintained on the go6 IPv6 portal website maintained by Hexago see http://wiki.go6.net/index.php?title=IPv6_Addressing

they also maintain a quite active dicussion forum on IPv6 issues; see 
http://wiki.go6.net/index.php?title=IPv6_Addressing

It might be worth to consider if pooling some of the effort makes sense, to avoid duplication and increase effectiveness


Yves


Yves Poppe
Director Business Development IP Services
VSNL International
tel: 1-514-8687248
cell: 1-514-8048162
fax: 1-514-8687033
e-mail: yves.poppe at vsnlinternational.com 
web: www.vsnlinternational.com 
 


-----Message d'origine-----
De : ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]De la part de
michael.dillon at bt.com
Envoy? : Sunday, September 16, 2007 7:47 AM
? : ppml at arin.net
Objet : [ppml] The wiki at www.getipv6.info



There is a wiki at www.getipv6.info that we should be making more use
of.

Also, ARIN staff should not be neglecting this wiki as they have in the
past. In particular, staff have locked changes to the main page but they
do not monitor the discussion tab of that page where changes are
requested.

This wiki was announced in the recent ARIN newsletter but visitors to it
will find it sadly empty. Given the importance of planning IPv6
deployment in preparation for IPv4 exhaustion, I think we should promote
this wiki more widely and encourage more broadly-based participation in
the wiki.

-------------------------------------------------------
Michael Dillon
RadianzNet Capacity Management, 66 Prescot St., London, E1 8HG, UK
Mobile: +44 7900 823 672 
Internet: michael.dillon at btradianz.com
Phone: +44 20 7650 9493 Fax: +44 20 7650 9030
http://www.btradianz.com
 
One Community One Connection One Focus 

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.


From iljitsch at muada.com  Mon Sep 17 05:25:05 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Mon, 17 Sep 2007 11:25:05 +0200
Subject: [ppml] IPv6 flawed?
In-Reply-To: <3c3e3fca0709131814q2c65fab8le376b598a74f404c@mail.gmail.com>
References: <NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
	<021c01c7f645$a3fd47d0$065e5e0a@integrated.net>
	<20070913213843.31ADF1444DF@smtp2.arin.net>
	<3c3e3fca0709131814q2c65fab8le376b598a74f404c@mail.gmail.com>
Message-ID: <BCC6566F-E3D2-4B4F-8EFA-5C6E852670D3@muada.com>

On 14-sep-2007, at 3:14, William Herrin wrote:

> 3. Shim6 is still in the research stage and at least 5 years from
> ubiquitous deployment. Its not at all clear that it will ever make it
> out of the research stage.

Actually I hear that there are implementations of certain parts of  
shim6 and the specs have been stable for a year or so, so whatever  
your opinion of shim6 and its status 5 years from now, I wouldn't  
consider it "research".


From bjohnson at drtel.com  Mon Sep 17 10:00:22 2007
From: bjohnson at drtel.com (Brian Johnson)
Date: Mon, 17 Sep 2007 09:00:22 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
References: <70DE64CEFD6E9A4EB7FAF3A063141066707458@mail>
	<NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
Message-ID: <29A54911243620478FF59F00EBB12F47B39EC4@ex01.drtel.lan>

Ted wrote:
> 
> You don't understand it because you are large enough to have your
> own allocation.
> 
> For the orgs too small to meet justification requirements to get
> a direct allocation of IPv6 from an RIR, it is a big problem.
> 
> They do not want to get IPv6 from an ISP AKA "local internet registry"
> and put time and money into numbering all their servers and suchlike -
> because if they find a better deal down the street from the ISP's
> (I mean local internet registry's) competitor, they want to be free
> to dump the existing ISP and go to the competitor without having to
> renumber internally.
> 
> This IMHO is the single largest reason so many orgs adopted NAT.
> 

I agree with Ted that there is a noticeable benefit to having NAT
capability, but not that it is the "single largest reason so many orgs
adopted NAT." It does act as a pseudo-security feature, and it does make
a network "portable".

I would have no problem with a say a /32 of IPv6 being set aside as
"private space." This will only increase the longevity of IPv6 when used
by companies who only need limited IP addresses and want to use private
space and NAT. What arguments are there against this?

- Brian



From marla.azinger at frontiercorp.com  Mon Sep 17 11:26:00 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Mon, 17 Sep 2007 11:26:00 -0400
Subject: [ppml] IPv6 flawed?
Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>

Hmmm...Now...what was that long drawn out conversation....that addressed private space in a good way.....oh yeah!  ULA-C!

Cheers!
Marla

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Brian Johnson
Sent: Monday, September 17, 2007 7:00 AM
To: Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
Subject: Re: [ppml] IPv6 flawed?


Ted wrote:
> 
> You don't understand it because you are large enough to have your
> own allocation.
> 
> For the orgs too small to meet justification requirements to get
> a direct allocation of IPv6 from an RIR, it is a big problem.
> 
> They do not want to get IPv6 from an ISP AKA "local internet registry"
> and put time and money into numbering all their servers and suchlike -
> because if they find a better deal down the street from the ISP's
> (I mean local internet registry's) competitor, they want to be free
> to dump the existing ISP and go to the competitor without having to
> renumber internally.
> 
> This IMHO is the single largest reason so many orgs adopted NAT.
> 

I agree with Ted that there is a noticeable benefit to having NAT
capability, but not that it is the "single largest reason so many orgs
adopted NAT." It does act as a pseudo-security feature, and it does make
a network "portable".

I would have no problem with a say a /32 of IPv6 being set aside as
"private space." This will only increase the longevity of IPv6 when used
by companies who only need limited IP addresses and want to use private
space and NAT. What arguments are there against this?

- Brian

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.


From paul at vix.com  Mon Sep 17 11:32:08 2007
From: paul at vix.com (Paul Vixie)
Date: Mon, 17 Sep 2007 15:32:08 +0000
Subject: [ppml] IPv6 flawed?
In-Reply-To: Your message of "Mon, 17 Sep 2007 11:26:00 -0400."
	<454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt> 
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
Message-ID: <39278.1190043128@sa.vix.com>

> Hmmm...Now...what was that long drawn out conversation....that addressed
> private space in a good way.....oh yeah!  ULA-C!

ULA-C is apparently quite dead, since noone whose job includes defending
the DFZ from explosion believes that ULA-C would be as "local" as ULA.


From owen at delong.com  Mon Sep 17 11:36:43 2007
From: owen at delong.com (Owen DeLong)
Date: Mon, 17 Sep 2007 08:36:43 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
Message-ID: <9873B4CE-026C-4355-9E3C-2BC79FAFDD38@delong.com>

Um, no... ULA-C is not a good way to address private space.  ULA-C is  
a bad
way to create PI under the table.

Owen

On Sep 17, 2007, at 8:26 AM, Azinger, Marla wrote:

> Hmmm...Now...what was that long drawn out conversation....that  
> addressed private space in a good way.....oh yeah!  ULA-C!
>
> Cheers!
> Marla
>
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
> Brian Johnson
> Sent: Monday, September 17, 2007 7:00 AM
> To: Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
> Subject: Re: [ppml] IPv6 flawed?
>
>
> Ted wrote:
>>
>> You don't understand it because you are large enough to have your
>> own allocation.
>>
>> For the orgs too small to meet justification requirements to get
>> a direct allocation of IPv6 from an RIR, it is a big problem.
>>
>> They do not want to get IPv6 from an ISP AKA "local internet  
>> registry"
>> and put time and money into numbering all their servers and  
>> suchlike -
>> because if they find a better deal down the street from the ISP's
>> (I mean local internet registry's) competitor, they want to be free
>> to dump the existing ISP and go to the competitor without having to
>> renumber internally.
>>
>> This IMHO is the single largest reason so many orgs adopted NAT.
>>
>
> I agree with Ted that there is a noticeable benefit to having NAT
> capability, but not that it is the "single largest reason so many orgs
> adopted NAT." It does act as a pseudo-security feature, and it does  
> make
> a network "portable".
>
> I would have no problem with a say a /32 of IPv6 being set aside as
> "private space." This will only increase the longevity of IPv6 when  
> used
> by companies who only need limited IP addresses and want to use  
> private
> space and NAT. What arguments are there against this?
>
> - Brian
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.



From dean at av8.com  Mon Sep 17 11:34:38 2007
From: dean at av8.com (Dean Anderson)
Date: Mon, 17 Sep 2007 11:34:38 -0400 (EDT)
Subject: [ppml] Revised Proposal -- Eliminate Lame Server Policy
In-Reply-To: <6C803415-DC66-4AAC-BF39-DA4C7CC3D96B@delong.com>
Message-ID: <Pine.LNX.4.44.0709171107090.8401-100000@citation2.av8.net>

This is the tail wagging the dog.  I think that operations should
implement the policies, not the other way around.  I have to say that I
am greatly concerned by the nature of this notion that "operations will
do whatever it wants", in spite of policy. Historically, ISPs have 
separated engineering from operations so that engineering designs the 
network and makes the policy while operations supervises the craftpeople 
and implements the policies and the design.  Allowing operations to 
operate unsupervised is, and has been proven to be, a very poor 
decision.

1. That "motivating problem" for this discussion as Scott Leibrand
succinctly summarized it, is at best a corner condition.

> ARIN's current operational policy requires that all zones for a given
> registration be lame before considering the registration lame, and
> triggering the notification and removal process.  If a registrant gets
> a /22, and only sets up reverse DNS for one /24, ARIN does not take
> action against the other three zones (/24's).  This seems to be an
> artifact of the fact that you define a single set of DNS server per
> registration, not per zone (/24, /16, or /8), so ARIN only takes
> action at the level of the registration, not the level of the zone
> (where the problems actually arise).

While there has been a lot of talk about what ARIN should do in this
case, no one has presented any evidence that there is any actual harm,
nor that that harm is so great that policy must be changed. Nowhere is
there is a reason that operations in this case is so difficult that it
should simply be entirely free of policy constraints.

There is no compelling reason for the change in policy.  


2. Removing Section 7 also changes the compliance with RFC2050 and
impacts agreements with IANA, ICANN, DoC which mention RFC2050.

There are additional impacts which have not been examined.


3. It is entirely possible within the existing policy, to remove the DNS
delegation for a subset of zones of an Address block assignment. It is
only the registration software that limits one set of nameservers for
all zones, and the ARIN DNS zone generation software that has this
limitation.  It is not section 7 of the policy manual that requires 'all
zones for a given registration be lame' before removing an in-addr
delegation, but rather limitations in the operations tools used to
implement policy.  There is no such language in section 7.2.

There is no need to change the policy manual.


Therefore, I think this policy should be not be adopted. 

Dean Anderson
Av8 Internet, Inc



On Sat, 15 Sep 2007, Owen DeLong wrote:

> Based on discussions with the AC Shepherds and input received on the
> mailing list, I am revising my Lame Server proposal.
> 
> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
> 
> 1.	Policy Proposal Name: Deprecate Lame Server Policy
> 2.	Author
> 	a.	name: Owen DeLong
> 	b.	email: owen at delong.com
> 	c.	telephone: 408-921-6984
> 	d.	organization: JITTR Networks
> 
> 3.	Proposal Version: 2.0
> 4.	Submission Date: 11 September, 2007
> 5.	Proposal type: modify
> 	new, modify, or delete.
> 6.	Policy term: permanent
> 	temporary, permanent, or renewable.
> 7.	Policy statement:
> 		Replace Section 7 of the NRPM in it's entirety with the
> 		following text:
> 
> 	7.	Staff action to improve ARIN public database accuracy and
> 		consistency.
> 
> 		7.1	ARIN staff shall take reasonable and practicable means to
> 			ensure and improve the accuracy of all ARIN public
> 			databases, including, but, not limited to WHOIS,
> 			delegations of the in-addr.arpa zone, and, delegations
> 			of the ip6.arpa zone.
> 
> 8.	Rationale:
> 		Recent PPML discussion has called attention to the
> 		fact that lame DNS delegations are more an operational
> 		issue than one of policy.  As such, the existing lame
> 		delegation policy should be removed from the NRPM
> 		to remove the resultant confusion.  This is not meant
> 		to prevent ARIN staff from taking reasonable action
> 		WRT DNS operational issues related to resources issued
> 		by ARIN, but, such action can be covered by staff
> 		operational guidelines and is not within the scope
> 		of Address Policy.
> 
> 9.	Timetable for implementation:
> 		1 June, 2008
> 10.	Meeting presenter: Owen DeLong
> 
> END OF TEMPLATE
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   






From iljitsch at muada.com  Mon Sep 17 11:37:52 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Mon, 17 Sep 2007 17:37:52 +0200
Subject: [ppml] IPv6 flawed?
In-Reply-To: <39278.1190043128@sa.vix.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
	<39278.1190043128@sa.vix.com>
Message-ID: <3241FDB1-9567-4EC0-ACA6-C5FA8494D4C7@muada.com>

On 17-sep-2007, at 17:32, Paul Vixie wrote:

>> Hmmm...Now...what was that long drawn out conversation....that  
>> addressed
>> private space in a good way.....oh yeah!  ULA-C!

> ULA-C is apparently quite dead, since noone whose job includes  
> defending
> the DFZ from explosion believes that ULA-C would be as "local" as ULA.

Riiiight... that must be why several people told me that PI is a good  
alternative for ULA-C, people holding a PI block will of course never  
be tempted to announce THAT.

I'll be filtering ULA-Cs that people announce, or they'll be giving  
me enough money that I'm happy to accept the advertisements. No  
problem either way.


From marla.azinger at frontiercorp.com  Mon Sep 17 11:37:36 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Mon, 17 Sep 2007 11:37:36 -0400
Subject: [ppml] IPv6 flawed?
Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4CA0F@nyrofcs2ke2k01.corp.pvt>

yeah...and I still wonder...if that is more a fear than anything.  I would like to think the community has learned some leassons.  And then there was always the counter debate that the number of true offenders was small but they were just large offenders.  Which makes me wonder why they arnt just publicly humiliated into doing things right.  And I question, if they would do the same thing with ULA or actually use that one right with all the publicity its gotten.

So I am still left thinking that it should be used correctly that way.

Cheers!
Marla

-----Original Message-----
From: vixie at vix.com [mailto:vixie at vix.com]On Behalf Of Paul Vixie
Sent: Monday, September 17, 2007 8:32 AM
To: Azinger, Marla
Cc: Brian Johnson; Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
Subject: Re: [ppml] IPv6 flawed? 


> Hmmm...Now...what was that long drawn out conversation....that addressed
> private space in a good way.....oh yeah!  ULA-C!

ULA-C is apparently quite dead, since noone whose job includes defending
the DFZ from explosion believes that ULA-C would be as "local" as ULA.


From cort at kanren.net  Mon Sep 17 11:39:09 2007
From: cort at kanren.net (Cort Buffington)
Date: Mon, 17 Sep 2007 10:39:09 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
Message-ID: <42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>

My organization recently changed IPv6 numbers. We had used EUI64  
addressing on servers and used a "subnetting" scheme that was logical  
and sustainable. It did not require actually touching any servers to  
change IPs. It was done as such: Add IP prefix to appropriate router  
interfaces, run find-replace script to fix prefixes in DNS, wait,  
remove old IP prefixes from router interfaces.

While I  am not trying to diminish the valid conversation about  
difficulties involved in renumbering, etc., I am actually doing, and  
have done this. IPv6 is not IPv4, and there are some aspects of it  
that change the ways things are/can be done. In our experience, the  
largest hurdle involved in using IPv6 effectively is getting folks to  
break out of the IPv4 way of thinking. With larger address spaces  
come the ability to address interfaces, etc. in a more logical way,  
that when added to some of the nice things like EUI64 addressing, can  
make "re-numbering" considerably easier.


On Sep 17, 2007, at 10:26 AM, Azinger, Marla wrote:

> Hmmm...Now...what was that long drawn out conversation....that  
> addressed private space in a good way.....oh yeah!  ULA-C!
>
> Cheers!
> Marla
>
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
> Brian Johnson
> Sent: Monday, September 17, 2007 7:00 AM
> To: Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
> Subject: Re: [ppml] IPv6 flawed?
>
>
> Ted wrote:
>>
>> You don't understand it because you are large enough to have your
>> own allocation.
>>
>> For the orgs too small to meet justification requirements to get
>> a direct allocation of IPv6 from an RIR, it is a big problem.
>>
>> They do not want to get IPv6 from an ISP AKA "local internet  
>> registry"
>> and put time and money into numbering all their servers and  
>> suchlike -
>> because if they find a better deal down the street from the ISP's
>> (I mean local internet registry's) competitor, they want to be free
>> to dump the existing ISP and go to the competitor without having to
>> renumber internally.
>>
>> This IMHO is the single largest reason so many orgs adopted NAT.
>>
>
> I agree with Ted that there is a noticeable benefit to having NAT
> capability, but not that it is the "single largest reason so many orgs
> adopted NAT." It does act as a pseudo-security feature, and it does  
> make
> a network "portable".
>
> I would have no problem with a say a /32 of IPv6 being set aside as
> "private space." This will only increase the longevity of IPv6 when  
> used
> by companies who only need limited IP addresses and want to use  
> private
> space and NAT. What arguments are there against this?
>
> - Brian
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.
>

--
Cort Buffington
Assistant Director for Technical Services
The Kansas Research and Education Network
cort at kanren.net
Office: +1-785-856-9800 x301
Mobile: +1-785-865-7206





From marla.azinger at frontiercorp.com  Mon Sep 17 11:40:32 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Mon, 17 Sep 2007 11:40:32 -0400
Subject: [ppml] IPv6 flawed?
Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4CA10@nyrofcs2ke2k01.corp.pvt>

I luve the Um soo...

Um no...ULA-C would not negate PI.  So see ...your comment right there, just tells me there is unnecessary "fear" getting in the way of ULA-C getting used.

Cheers!
Marla

-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com]
Sent: Monday, September 17, 2007 8:37 AM
To: Azinger, Marla
Cc: Brian Johnson; Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
Subject: Re: [ppml] IPv6 flawed?


Um, no... ULA-C is not a good way to address private space.  ULA-C is  
a bad
way to create PI under the table.

Owen

On Sep 17, 2007, at 8:26 AM, Azinger, Marla wrote:

> Hmmm...Now...what was that long drawn out conversation....that  
> addressed private space in a good way.....oh yeah!  ULA-C!
>
> Cheers!
> Marla
>
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
> Brian Johnson
> Sent: Monday, September 17, 2007 7:00 AM
> To: Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
> Subject: Re: [ppml] IPv6 flawed?
>
>
> Ted wrote:
>>
>> You don't understand it because you are large enough to have your
>> own allocation.
>>
>> For the orgs too small to meet justification requirements to get
>> a direct allocation of IPv6 from an RIR, it is a big problem.
>>
>> They do not want to get IPv6 from an ISP AKA "local internet  
>> registry"
>> and put time and money into numbering all their servers and  
>> suchlike -
>> because if they find a better deal down the street from the ISP's
>> (I mean local internet registry's) competitor, they want to be free
>> to dump the existing ISP and go to the competitor without having to
>> renumber internally.
>>
>> This IMHO is the single largest reason so many orgs adopted NAT.
>>
>
> I agree with Ted that there is a noticeable benefit to having NAT
> capability, but not that it is the "single largest reason so many orgs
> adopted NAT." It does act as a pseudo-security feature, and it does  
> make
> a network "portable".
>
> I would have no problem with a say a /32 of IPv6 being set aside as
> "private space." This will only increase the longevity of IPv6 when  
> used
> by companies who only need limited IP addresses and want to use  
> private
> space and NAT. What arguments are there against this?
>
> - Brian
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.



From randy at psg.com  Mon Sep 17 11:42:06 2007
From: randy at psg.com (Randy Bush)
Date: Mon, 17 Sep 2007 05:42:06 -1000
Subject: [ppml] IPv6 flawed?
In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A02A4CA0F@nyrofcs2ke2k01.corp.pvt>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0F@nyrofcs2ke2k01.corp.pvt>
Message-ID: <46EEA04E.80803@psg.com>

Azinger, Marla wrote:
> yeah...and I still wonder...if that is more a fear than anything.  I
> would like to think the community has learned some leassons.

wake me when we stop seeing rfc 1918 leaks of bgp, dns, ... and rfc 1918
space on traceroutes.

randy


From marla.azinger at frontiercorp.com  Mon Sep 17 11:45:01 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Mon, 17 Sep 2007 11:45:01 -0400
Subject: [ppml] IPv6 flawed?
Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4CA11@nyrofcs2ke2k01.corp.pvt>

ok I'm done beating my head on the wall today. 

Cheers!
Marla

-----Original Message-----
From: Randy Bush [mailto:randy at psg.com]
Sent: Monday, September 17, 2007 8:42 AM
To: Azinger, Marla
Cc: Paul Vixie; ppml at arin.net
Subject: Re: [ppml] IPv6 flawed?


Azinger, Marla wrote:
> yeah...and I still wonder...if that is more a fear than anything.  I
> would like to think the community has learned some leassons.

wake me when we stop seeing rfc 1918 leaks of bgp, dns, ... and rfc 1918
space on traceroutes.

randy


From colin at thusa.co.za  Mon Sep 17 11:50:14 2007
From: colin at thusa.co.za (Colin Alston)
Date: Mon, 17 Sep 2007 17:50:14 +0200
Subject: [ppml] IPv6 flawed?
In-Reply-To: <46EEA04E.80803@psg.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0F@nyrofcs2ke2k01.corp.pvt>
	<46EEA04E.80803@psg.com>
Message-ID: <46EEA236.1050800@thusa.co.za>

On 17/09/2007 17:42 Randy Bush wrote:
> Azinger, Marla wrote:
>> yeah...and I still wonder...if that is more a fear than anything.  I
>> would like to think the community has learned some leassons.
> 
> wake me when we stop seeing rfc 1918 leaks of bgp, dns, ... and rfc 1918
> space on traceroutes.

And the fun that ensues when it collides with your space :D

-- 
Colin Alston <colin at thusa.co.za>     ______
Linux & Internet Services           /\_\_\_\
Thusa Business Support (Pty) Ltd   /\/\_\_\_\
http://www.thusa.co.za/           /\/\/\_\_\_\
Tel:  (+27) 031 277 1257          \/\/\/_/_/_/
Fax:  (+27) 031 277 1269           \/\/_/_/_/
                                     \/_/_/_/
"To the world you may be one person, to one person you may be the 
world" ~ Rachel Ann Nunes.


From iljitsch at muada.com  Mon Sep 17 11:50:53 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Mon, 17 Sep 2007 17:50:53 +0200
Subject: [ppml] IPv6 flawed?
In-Reply-To: <46EEA04E.80803@psg.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0F@nyrofcs2ke2k01.corp.pvt>
	<46EEA04E.80803@psg.com>
Message-ID: <922D0875-2403-4BCC-8825-21832CB60DA2@muada.com>

On 17-sep-2007, at 17:42, Randy Bush wrote:

>> yeah...and I still wonder...if that is more a fear than anything.  I
>> would like to think the community has learned some leassons.

> wake me when we stop seeing rfc 1918 leaks of bgp, dns, ... and rfc  
> 1918
> space on traceroutes.

1. AFAIK, it is not "illegal" to number router interfaces out of 1918  
space (but you don't want to do that if you need to generate path MTU  
discovery messages)

2. DNS is escaping packets, not escaping routes = irrelevant

3. Leaking RFC 1918 prefixes in BGP only means that SOME people don't  
use good filters SOME of the time (probably all people some of the  
time / some people all of the time, but that aside), not that the  
state of route filtering is such that internet-wide connectivity can  
be had using address space that most people feel should be filtered

What happened to "I encourage my competitors to run their networks  
this way"?


From paul at vix.com  Mon Sep 17 11:51:09 2007
From: paul at vix.com (Paul Vixie)
Date: Mon, 17 Sep 2007 15:51:09 +0000
Subject: [ppml] IPv6 flawed?
In-Reply-To: Your message of "Mon, 17 Sep 2007 11:37:36 -0400."
	<454810F09B5AA04E9D78D13A5C39028A02A4CA0F@nyrofcs2ke2k01.corp.pvt> 
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0F@nyrofcs2ke2k01.corp.pvt>
Message-ID: <41133.1190044269@sa.vix.com>

> yeah...and I still wonder...if that is more a fear than anything.  I would
> like to think the community has learned some leassons.  And then there was
> always the counter debate that the number of true offenders was small but
> they were just large offenders.  Which makes me wonder why they arnt just
> publicly humiliated into doing things right.  And I question, if they would
> do the same thing with ULA or actually use that one right with all the
> publicity its gotten.

relevance in competition among internet carriers depends on reachability, and
so if someone somewhere announces a ULA-C (or ULA-G, which is my own version)
and if a small-but-critical mass of other carriers accepts that announcement,
then anyone anywhere who doesn't also have that route would lose business.  i
don't like the system but i don't know how to change it, short of some kind of
micropayment-for-route-slot system that we also don't know how to deploy in a
capital based system.

the tyranny of the core will apparently be with us for ever and ever, and the
kind of ad-hoc MANET that could reduce pressure on the DFZ will only come into
existence if someone other than the existing I* organizations puts together an
ad-hoc central registry for things like in-addr and whois, based on RFC 4193
("ULA") prefixes.

(it's a triple-indirect assymetric value proposition, the first i've studied.)


From owen at delong.com  Mon Sep 17 11:58:31 2007
From: owen at delong.com (Owen DeLong)
Date: Mon, 17 Sep 2007 08:58:31 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
	<42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
Message-ID: <1F476111-95E8-4023-B367-357AA75EBD29@delong.com>

Please expand on the following details of your ease of renumbering:

	1.	How many VPNs did you have terminating on devices in the
		space you renumbered at one end with the other end terminating
		on devices you did not control?

	2.	How many external organizations had firewalls you don't control
		with policies containing your addresses when you renumbered?

If your answers to questions 1 and 2 are zero or near zero, then, I  
would
argue that you have not demonstrated a meaningful difference in the
effort required to renumber IPv6 vs. IPv4.

Owen

On Sep 17, 2007, at 8:39 AM, Cort Buffington wrote:

> My organization recently changed IPv6 numbers. We had used EUI64
> addressing on servers and used a "subnetting" scheme that was logical
> and sustainable. It did not require actually touching any servers to
> change IPs. It was done as such: Add IP prefix to appropriate router
> interfaces, run find-replace script to fix prefixes in DNS, wait,
> remove old IP prefixes from router interfaces.
>
> While I  am not trying to diminish the valid conversation about
> difficulties involved in renumbering, etc., I am actually doing, and
> have done this. IPv6 is not IPv4, and there are some aspects of it
> that change the ways things are/can be done. In our experience, the
> largest hurdle involved in using IPv6 effectively is getting folks to
> break out of the IPv4 way of thinking. With larger address spaces
> come the ability to address interfaces, etc. in a more logical way,
> that when added to some of the nice things like EUI64 addressing, can
> make "re-numbering" considerably easier.
>
>
> On Sep 17, 2007, at 10:26 AM, Azinger, Marla wrote:
>
>> Hmmm...Now...what was that long drawn out conversation....that
>> addressed private space in a good way.....oh yeah!  ULA-C!
>>
>> Cheers!
>> Marla
>>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On  
>> Behalf Of
>> Brian Johnson
>> Sent: Monday, September 17, 2007 7:00 AM
>> To: Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
>> Subject: Re: [ppml] IPv6 flawed?
>>
>>
>> Ted wrote:
>>>
>>> You don't understand it because you are large enough to have your
>>> own allocation.
>>>
>>> For the orgs too small to meet justification requirements to get
>>> a direct allocation of IPv6 from an RIR, it is a big problem.
>>>
>>> They do not want to get IPv6 from an ISP AKA "local internet
>>> registry"
>>> and put time and money into numbering all their servers and
>>> suchlike -
>>> because if they find a better deal down the street from the ISP's
>>> (I mean local internet registry's) competitor, they want to be free
>>> to dump the existing ISP and go to the competitor without having to
>>> renumber internally.
>>>
>>> This IMHO is the single largest reason so many orgs adopted NAT.
>>>
>>
>> I agree with Ted that there is a noticeable benefit to having NAT
>> capability, but not that it is the "single largest reason so many  
>> orgs
>> adopted NAT." It does act as a pseudo-security feature, and it does
>> make
>> a network "portable".
>>
>> I would have no problem with a say a /32 of IPv6 being set aside as
>> "private space." This will only increase the longevity of IPv6 when
>> used
>> by companies who only need limited IP addresses and want to use
>> private
>> space and NAT. What arguments are there against this?
>>
>> - Brian
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the
>> ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
>> Member Services
>> Help Desk at 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 (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
>> Member Services
>> Help Desk at info at arin.net if you experience any issues.
>>
>
> --
> Cort Buffington
> Assistant Director for Technical Services
> The Kansas Research and Education Network
> cort at kanren.net
> Office: +1-785-856-9800 x301
> Mobile: +1-785-865-7206
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.



From cort at kanren.net  Mon Sep 17 12:08:54 2007
From: cort at kanren.net (Cort Buffington)
Date: Mon, 17 Sep 2007 11:08:54 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <1F476111-95E8-4023-B367-357AA75EBD29@delong.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
	<42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
	<1F476111-95E8-4023-B367-357AA75EBD29@delong.com>
Message-ID: <853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>

Yep, that's right. I really don't do enough meaningful networking to  
speak up here. I should have kept my mouth shut.

On Sep 17, 2007, at 10:58 AM, Owen DeLong wrote:

> Please expand on the following details of your ease of renumbering:
>
> 	1.	How many VPNs did you have terminating on devices in the
> 		space you renumbered at one end with the other end terminating
> 		on devices you did not control?
>
> 	2.	How many external organizations had firewalls you don't control
> 		with policies containing your addresses when you renumbered?
>
> If your answers to questions 1 and 2 are zero or near zero, then, I  
> would
> argue that you have not demonstrated a meaningful difference in the
> effort required to renumber IPv6 vs. IPv4.
>
> Owen
>
> On Sep 17, 2007, at 8:39 AM, Cort Buffington wrote:
>
>> My organization recently changed IPv6 numbers. We had used EUI64
>> addressing on servers and used a "subnetting" scheme that was logical
>> and sustainable. It did not require actually touching any servers to
>> change IPs. It was done as such: Add IP prefix to appropriate router
>> interfaces, run find-replace script to fix prefixes in DNS, wait,
>> remove old IP prefixes from router interfaces.
>>
>> While I  am not trying to diminish the valid conversation about
>> difficulties involved in renumbering, etc., I am actually doing, and
>> have done this. IPv6 is not IPv4, and there are some aspects of it
>> that change the ways things are/can be done. In our experience, the
>> largest hurdle involved in using IPv6 effectively is getting folks to
>> break out of the IPv4 way of thinking. With larger address spaces
>> come the ability to address interfaces, etc. in a more logical way,
>> that when added to some of the nice things like EUI64 addressing, can
>> make "re-numbering" considerably easier.
>>
>>
>> On Sep 17, 2007, at 10:26 AM, Azinger, Marla wrote:
>>
>>> Hmmm...Now...what was that long drawn out conversation....that
>>> addressed private space in a good way.....oh yeah!  ULA-C!
>>>
>>> Cheers!
>>> Marla
>>>
>>> -----Original Message-----
>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On  
>>> Behalf Of
>>> Brian Johnson
>>> Sent: Monday, September 17, 2007 7:00 AM
>>> To: Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
>>> Subject: Re: [ppml] IPv6 flawed?
>>>
>>>
>>> Ted wrote:
>>>>
>>>> You don't understand it because you are large enough to have your
>>>> own allocation.
>>>>
>>>> For the orgs too small to meet justification requirements to get
>>>> a direct allocation of IPv6 from an RIR, it is a big problem.
>>>>
>>>> They do not want to get IPv6 from an ISP AKA "local internet
>>>> registry"
>>>> and put time and money into numbering all their servers and
>>>> suchlike -
>>>> because if they find a better deal down the street from the ISP's
>>>> (I mean local internet registry's) competitor, they want to be free
>>>> to dump the existing ISP and go to the competitor without having to
>>>> renumber internally.
>>>>
>>>> This IMHO is the single largest reason so many orgs adopted NAT.
>>>>
>>>
>>> I agree with Ted that there is a noticeable benefit to having NAT
>>> capability, but not that it is the "single largest reason so many  
>>> orgs
>>> adopted NAT." It does act as a pseudo-security feature, and it does
>>> make
>>> a network "portable".
>>>
>>> I would have no problem with a say a /32 of IPv6 being set aside as
>>> "private space." This will only increase the longevity of IPv6 when
>>> used
>>> by companies who only need limited IP addresses and want to use
>>> private
>>> space and NAT. What arguments are there against this?
>>>
>>> - Brian
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the
>>> ARIN Public Policy
>>> Mailing List (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
>>> Member Services
>>> Help Desk at 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 (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
>>> Member Services
>>> Help Desk at info at arin.net if you experience any issues.
>>>
>>
>> --
>> Cort Buffington
>> Assistant Director for Technical Services
>> The Kansas Research and Education Network
>> cort at kanren.net
>> Office: +1-785-856-9800 x301
>> Mobile: +1-785-865-7206
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the  
>> ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the  
>> ARIN Member Services
>> Help Desk at info at arin.net if you experience any issues.
>
>

--
Cort Buffington
Assistant Director for Technical Services
The Kansas Research and Education Network
cort at kanren.net
Office: +1-785-856-9800 x301
Mobile: +1-785-865-7206





From michael.dillon at bt.com  Mon Sep 17 12:21:31 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 17 Sep 2007 17:21:31 +0100
Subject: [ppml] IPv6 flawed?
In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A02A4CA0F@nyrofcs2ke2k01.corp.pvt>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0F@nyrofcs2ke2k01.corp.pvt>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00107D994@E03MVC4-UKBR.domain1.systemhost.net>

>  Which makes me wonder why they arnt 
> just publicly humiliated into doing things right.  And I 
> question, if they would do the same thing with ULA or 
> actually use that one right with all the publicity its gotten.

As an ARIN AC member, I would have thought that you would take the time
to understand the technology that you were talking about, ESPECIALLY
when you talk about applying punitive measures.

Let me reword this. It is JUST PLAIN STUPID to suggest that we should
publicly humiliate people who use ULA addressing. ULA was created by the
IETF to address the need for addressing private interfaces which are
never intended to communicate outside a particular network. There is
nothing wrong with using ULA addresses.

As for ULA-C, this is something which does not exist. There are at least
two different proposals for something which may or may not be what
people think of as ULA-C. The IETF is rechartering the ipv6 working
group and one of the work items in that charter is to resolve what to do
about ULA-C and the various proposals. It is entirely possible that the
IETF will create something called ULA-C which is not at all like what
you think it is. If you care about this, I suggest that you should join
the WG, read the drafts, comment on them, or write your own draft.

But it is premature to be promoting punitive measures on the ARIN PPML.

And for the record, I don't care what hat you were wearing when you made
that comment, I will not be voting for your re-election to the AC.

--Michael Dillon

P.S. If you are still confused about ULA then read RFC 4193
http://www.ietf.org/rfc/rfc4193.txt



From dlw+arin at tellme.com  Mon Sep 17 12:22:03 2007
From: dlw+arin at tellme.com (David Williamson)
Date: Mon, 17 Sep 2007 09:22:03 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
	<42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
	<1F476111-95E8-4023-B367-357AA75EBD29@delong.com>
	<853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
Message-ID: <20070917162202.GH23649@shell01.cell.sv2.tellme.com>

On Mon, Sep 17, 2007 at 11:08:54AM -0500, Cort Buffington wrote:
> Yep, that's right. I really don't do enough meaningful networking to  
> speak up here. I should have kept my mouth shut.

I don't think that's the point.

>From the sound of it, you've managed to renumber your local environment
fairly easily.  Congrats!  It's nice to hear that someone has had a
fairly easy renumbering experience with IPv6.

Owen's point is valid, though - unless there is some mechanism for
renumbering addresses stored in places not under your control, this
isn't really any easier than with IPv4.  For organnizations that don't
utilize VPNs and don't have their addressess embedded all over the
place, the two are mostly equivalent, although IPv6 has more natural
methods for renumbering in a fairly painless way.

Unfortunately, many orgs are not in that space, and renumbering is hard
and painful.  If there's a broad solution to that problem space, I'd
really like to hear about it.

That, I think, is the point.

-David


From kkargel at polartel.com  Mon Sep 17 12:23:22 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Sep 2007 11:23:22 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <29A54911243620478FF59F00EBB12F47B39EC4@ex01.drtel.lan>
References: <70DE64CEFD6E9A4EB7FAF3A063141066707458@mail>
	<NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
	<29A54911243620478FF59F00EBB12F47B39EC4@ex01.drtel.lan>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707483@mail>

 I personally have no opposition to IPv6 "private space, so long as it
is private and not routable.  Where I do have problems is where people
want pseudo-routable space that is uniquely assigned and registered and
advertised.  That is just an end run around PI/PA.

The renumbering issue is handled nicely within IPv6 by using the network
prefix functionality.  IPv6 interfaces by design can hold multiple
addresses, and can superimpose a network prefix on the most significant
portion of one or more of those addresses. By numbering the least
significant portion and using the prefix, renumbering becomes trivial.

Kevin

> -----Original Message-----
> From: Brian Johnson [mailto:bjohnson at drtel.com] 
> Sent: Monday, September 17, 2007 9:00 AM
> To: Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
> Subject: RE: [ppml] IPv6 flawed?
> 
> Ted wrote:
> > 
> > You don't understand it because you are large enough to 
> have your own 
> > allocation.
> > 
> > For the orgs too small to meet justification requirements to get a 
> > direct allocation of IPv6 from an RIR, it is a big problem.
> > 
> > They do not want to get IPv6 from an ISP AKA "local 
> internet registry"
> > and put time and money into numbering all their servers and 
> suchlike - 
> > because if they find a better deal down the street from the 
> ISP's (I 
> > mean local internet registry's) competitor, they want to be free to 
> > dump the existing ISP and go to the competitor without having to 
> > renumber internally.
> > 
> > This IMHO is the single largest reason so many orgs adopted NAT.
> > 
> 
> I agree with Ted that there is a noticeable benefit to having 
> NAT capability, but not that it is the "single largest reason 
> so many orgs adopted NAT." It does act as a pseudo-security 
> feature, and it does make a network "portable".
> 
> I would have no problem with a say a /32 of IPv6 being set 
> aside as "private space." This will only increase the 
> longevity of IPv6 when used by companies who only need 
> limited IP addresses and want to use private space and NAT. 
> What arguments are there against this?
> 
> - Brian
> 
> 


From paul at vix.com  Mon Sep 17 12:24:00 2007
From: paul at vix.com (Paul Vixie)
Date: Mon, 17 Sep 2007 16:24:00 +0000
Subject: [ppml] IPv6 flawed?
In-Reply-To: Your message of "Mon, 17 Sep 2007 11:08:54 EST."
	<853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net> 
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
	<42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
	<1F476111-95E8-4023-B367-357AA75EBD29@delong.com>
	<853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net> 
Message-ID: <52056.1190046240@sa.vix.com>

> Yep, that's right. I really don't do enough meaningful networking to  
> speak up here. I should have kept my mouth shut.

i disagree on both counts.  your example was good, since it showed what
can be done if the original network was provisioned "lightly".  and as
for keeping your mouth shut, i'm glad you didn't, since it means folks
got to hear somebody say "ipv6 enables different provisioning philosophies
than ipv4, and renumbering can be made less painful in v6 than in v4."

was anybody else here alive at the time microsoft decided to get into IP?
i myself was a beame and whiteside fan, though i had friends at ftp
software and other ip-on-windows companies.  the common belief was that
with microsoft coming 20 years late to the party, they would be an also-ran.
(i think similar thoughts were spoken aloud when internet explored came
out in a mostly-mosaic web community.)  hopefully a lesson was learned?

that lesson is, the installed base is meaningless, and how we did it before
is meaningless, all that matters is getting growth right.  with all due
respect to owen, the number of other people's firewalls that had our old
ip addresses in it is not going to matter in the long run, and the long run
is what we've got to plan for and worry about.

that said, ipv6 doesn't have the same inevitability than, for example,
internet explorer had in a mostly-mosaic web, since it's a new technology
that's not interoperable with anything that existed before.  so, i'm in
total sympathy for those who say ipv6 might die before deployment, or that
we might all die of old age before deployment, and so on.  i am particularly
upset that ipv6 failed to address the failed ipv4 routing paradigm, which
was (and which remains) the biggest reason ipv4 had to be replaced.

but it's not about the number of vpn's landing on current networks.


From michael.dillon at bt.com  Mon Sep 17 12:35:07 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 17 Sep 2007 17:35:07 +0100
Subject: [ppml] IPv6 flawed?
In-Reply-To: <52056.1190046240@sa.vix.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net><1F476111-95E8-4023-B367-357AA75EBD29@delong.com><853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
	<52056.1190046240@sa.vix.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00107D9AD@E03MVC4-UKBR.domain1.systemhost.net>

> i disagree on both counts.  your example was good, since it 
> showed what can be done if the original network was 
> provisioned "lightly".  and as for keeping your mouth shut, 
> i'm glad you didn't, since it means folks got to hear 
> somebody say "ipv6 enables different provisioning 
> philosophies than ipv4, and renumbering can be made less 
> painful in v6 than in v4."

I agree. We need more examples of IPv6 best practices to show that IPv6
really is different and you have fundamentally reexamine all your
practices when you deploy IPv6.

I copied your words and put it here on ARIN's IPv6 Wiki
http://www.getipv6.info/index.php/Renumbering_an_IPv6_Network

Now if only the ARIN staff would get off their butts and maintain the
home page, it might encourage more people to get involved in adding
content to the Wiki.

Mailing lists are fine, but the good content tends to get lost in a sea
of trivia.

--Michael Dillon


From randy at psg.com  Mon Sep 17 12:34:52 2007
From: randy at psg.com (Randy Bush)
Date: Mon, 17 Sep 2007 06:34:52 -1000
Subject: [ppml] IPv6 flawed?
In-Reply-To: <52056.1190046240@sa.vix.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>	<42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>	<1F476111-95E8-4023-B367-357AA75EBD29@delong.com>	<853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
	<52056.1190046240@sa.vix.com>
Message-ID: <46EEACAC.9050401@psg.com>

> was anybody else here alive at the time microsoft decided to get into IP?

which time?  there were three.  the last one stuck.  with deep enough
pockets, a 1000kg gorilla can afford a few failures.

what is critical to ipv6 deployment is vendor support, vendor support,
and did i mention vendor support; from the core to the edge.  with
nat-pt + algs for dns, http, smtp, and sip.  otherwise the cost to move
to v6 is bigger than v4 nat; end of game.

but this is not really the list for this.

randy


From owen at delong.com  Mon Sep 17 12:39:05 2007
From: owen at delong.com (Owen DeLong)
Date: Mon, 17 Sep 2007 09:39:05 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <20070917162202.GH23649@shell01.cell.sv2.tellme.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
	<42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
	<1F476111-95E8-4023-B367-357AA75EBD29@delong.com>
	<853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
	<20070917162202.GH23649@shell01.cell.sv2.tellme.com>
Message-ID: <6D35D536-0A80-4B6F-B6D4-2D54579E7A26@delong.com>

David is, indeed, correct about my true point.  No offense or
disparagement of Mr. Buffington's accomplishments was intended.
(I don't know him well enough to comment one way or another on
such things.  Indeed, I don't know him at all.)

Owen

On Sep 17, 2007, at 9:22 AM, David Williamson wrote:

> On Mon, Sep 17, 2007 at 11:08:54AM -0500, Cort Buffington wrote:
>> Yep, that's right. I really don't do enough meaningful networking to
>> speak up here. I should have kept my mouth shut.
>
> I don't think that's the point.
>
>> From the sound of it, you've managed to renumber your local  
>> environment
> fairly easily.  Congrats!  It's nice to hear that someone has had a
> fairly easy renumbering experience with IPv6.
>
> Owen's point is valid, though - unless there is some mechanism for
> renumbering addresses stored in places not under your control, this
> isn't really any easier than with IPv4.  For organnizations that don't
> utilize VPNs and don't have their addressess embedded all over the
> place, the two are mostly equivalent, although IPv6 has more natural
> methods for renumbering in a fairly painless way.
>
> Unfortunately, many orgs are not in that space, and renumbering is  
> hard
> and painful.  If there's a broad solution to that problem space, I'd
> really like to hear about it.
>
> That, I think, is the point.
>
> -David



From paul at vix.com  Mon Sep 17 12:37:14 2007
From: paul at vix.com (Paul Vixie)
Date: Mon, 17 Sep 2007 16:37:14 +0000
Subject: [ppml] IPv6 flawed?
In-Reply-To: Your message of "Mon, 17 Sep 2007 11:23:22 EST."
	<70DE64CEFD6E9A4EB7FAF3A063141066707483@mail> 
References: <70DE64CEFD6E9A4EB7FAF3A063141066707458@mail>
	<NABBJOELMNGNJNGPKDDOIENEHDAA.tedm@ipinc.net>
	<29A54911243620478FF59F00EBB12F47B39EC4@ex01.drtel.lan>
	<70DE64CEFD6E9A4EB7FAF3A063141066707483@mail> 
Message-ID: <61955.1190047034@sa.vix.com>

> ...  Where I do have problems is where people want pseudo-routable space
> that is uniquely assigned and registered and advertised.  That is just an
> end run around PI/PA.

no, it's not.  it's an end run around the internet core.  and as a courtesy,
i'd rather not be told what my agenda is.  i like the PI/PA split for the
DFZ.  i just don't like the DFZ very much as "the only way to do internet".
see http://sa.vix.com/~vixie/ula-global.txt for my own cutaway from RFC4193
and ULA-C.


From paul at vix.com  Mon Sep 17 12:45:43 2007
From: paul at vix.com (Paul Vixie)
Date: Mon, 17 Sep 2007 16:45:43 +0000
Subject: [ppml] IPv6 flawed?
In-Reply-To: Your message of "Mon, 17 Sep 2007 17:35:07 +0100."
	<D03E4899F2FB3D4C8464E8C76B3B68B00107D9AD@E03MVC4-UKBR.domain1.systemhost.net>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net><1F476111-95E8-4023-B367-357AA75EBD29@delong.com><853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
	<52056.1190046240@sa.vix.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B00107D9AD@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <62489.1190047543@sa.vix.com>

> I copied your words and put it here on ARIN's IPv6 Wiki
> http://www.getipv6.info/index.php/Renumbering_an_IPv6_Network

great.  thanks.  i don't wiki well, since i find web browser textarea boxes
to be the worst of all possible text editors.

> Now if only the ARIN staff would get off their butts and maintain the
> home page, it might encourage more people to get involved in adding
> content to the Wiki.

in defense of arin staff, they aren't on their butts, they work hard and they
get a lot of stuff done.  i think the wiki is new enough that nobody knows
exactly how to guide it -- you ought to volunteer to edit the home page and
see if somebody takes you up on it.



From kkargel at polartel.com  Mon Sep 17 12:48:11 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Sep 2007 11:48:11 -0500
Subject: [ppml] Revised Proposal -- Eliminate Lame Server Policy
In-Reply-To: <6C803415-DC66-4AAC-BF39-DA4C7CC3D96B@delong.com>
References: <6C803415-DC66-4AAC-BF39-DA4C7CC3D96B@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707488@mail>

 I support this this proposal.  Dealing with operational issues
operationally just makes sense.

Kevin Kargel


> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Owen DeLong
> Sent: Saturday, September 15, 2007 10:51 AM
> To: policy at arin.net; Public Policy Mailing List
> Cc: Robert E. Seastrom
> Subject: [ppml] Revised Proposal -- Eliminate Lame Server Policy
> 
> Based on discussions with the AC Shepherds and input received 
> on the mailing list, I am revising my Lame Server proposal.
> 
> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
> 
> 1.	Policy Proposal Name: Deprecate Lame Server Policy
> 2.	Author
> 	a.	name: Owen DeLong
> 	b.	email: owen at delong.com
> 	c.	telephone: 408-921-6984
> 	d.	organization: JITTR Networks
> 
> 3.	Proposal Version: 2.0
> 4.	Submission Date: 11 September, 2007
> 5.	Proposal type: modify
> 	new, modify, or delete.
> 6.	Policy term: permanent
> 	temporary, permanent, or renewable.
> 7.	Policy statement:
> 		Replace Section 7 of the NRPM in it's entirety with the
> 		following text:
> 
> 	7.	Staff action to improve ARIN public database 
> accuracy and
> 		consistency.
> 
> 		7.1	ARIN staff shall take reasonable and 
> practicable means to
> 			ensure and improve the accuracy of all 
> ARIN public
> 			databases, including, but, not limited to WHOIS,
> 			delegations of the in-addr.arpa zone, 
> and, delegations
> 			of the ip6.arpa zone.
> 
> 8.	Rationale:
> 		Recent PPML discussion has called attention to the
> 		fact that lame DNS delegations are more an operational
> 		issue than one of policy.  As such, the existing lame
> 		delegation policy should be removed from the NRPM
> 		to remove the resultant confusion.  This is not meant
> 		to prevent ARIN staff from taking reasonable action
> 		WRT DNS operational issues related to resources issued
> 		by ARIN, but, such action can be covered by staff
> 		operational guidelines and is not within the scope
> 		of Address Policy.
> 
> 9.	Timetable for implementation:
> 		1 June, 2008
> 10.	Meeting presenter: Owen DeLong
> 
> END OF TEMPLATE
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at info at arin.net if you 
> experience any issues.
> 


From stephen at sprunk.org  Mon Sep 17 12:24:12 2007
From: stephen at sprunk.org (Stephen Sprunk)
Date: Mon, 17 Sep 2007 11:24:12 -0500
Subject: [ppml] Policy Proposal 2007-20: Definition of known ISP and
	changes to IPv6 initial allocation criteria
References: <46D43429.1000306@arin.net> <46E9826C.7060705@rancid.berkeley.edu>
Message-ID: <013601c7f94a$b9ede420$363816ac@atlanta.polycom.com>

Thus spake "Michael Sinatra" <michael at rancid.berkeley.edu>
> Member Services wrote:
>
>> d. be an existing ISP in the ARIN region or have a plan for
>> making assignments to at least 200 separate organizations
>> within five years.
>>
>> Rationale:
>>
>> This policy proposal would change two things in the IPv6 Initial
>> allocation criteria. It adds a definition for "known ISP" and
>> changes "200 /48 assignments" to 200 assignments of any
>> size, but to separate organizations.
>
> Clarification question: What's the difference between "separate
> organizations" in this text and the "other organizations" in the
> current section of the NRPM?  Is the intent that if I allocated 3
> /48s to the same "other" organization that it would now count as
> one organization instead of 3 /48s toward my goal of 200?

AFAIK, the intent has always been that they be 200 distinct organizations; 
otherwise one could assign 200 /48s to the same organization and qualify as 
an LIR.  If the existing policy doesn't make that clear, IMHO it needs 
fixing.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 




From kkargel at polartel.com  Mon Sep 17 12:55:55 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Sep 2007 11:55:55 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <3241FDB1-9567-4EC0-ACA6-C5FA8494D4C7@muada.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><39278.1190043128@sa.vix.com>
	<3241FDB1-9567-4EC0-ACA6-C5FA8494D4C7@muada.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707489@mail>

 How will you know their announcement is ULA-C to filter it?  Are you
saying that you will build a statement for every ULA-C for each ASN in
the world into your edge access-list?  Or is there some aggregatable
filter list I am unaware of?  Even if it were as few as 500 filter
statements, I would not be happy to have to extend an access list that
far, and I suspect the number of statements required would far outrun
that humble number.

Feel free to educate me, I want to learn.

Kevin


> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Iljitsch van Beijnum
> Sent: Monday, September 17, 2007 10:38 AM
> To: Paul Vixie
> Cc: ppml at arin.net
> Subject: Re: [ppml] IPv6 flawed?
> 
> On 17-sep-2007, at 17:32, Paul Vixie wrote:
> 
> >> Hmmm...Now...what was that long drawn out conversation....that 
> >> addressed private space in a good way.....oh yeah!  ULA-C!
> 
> > ULA-C is apparently quite dead, since noone whose job includes 
> > defending the DFZ from explosion believes that ULA-C would be as 
> > "local" as ULA.
> 
> Riiiight... that must be why several people told me that PI 
> is a good alternative for ULA-C, people holding a PI block 
> will of course never be tempted to announce THAT.
> 
> I'll be filtering ULA-Cs that people announce, or they'll be 
> giving me enough money that I'm happy to accept the 
> advertisements. No problem either way.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at info at arin.net if you 
> experience any issues.
> 


From kkargel at polartel.com  Mon Sep 17 12:57:25 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Sep 2007 11:57:25 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
	<42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670748A@mail>

 
Great to hear of a real-world use case.  Thank you!

Kevin

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Cort Buffington
> Sent: Monday, September 17, 2007 10:39 AM
> To: ppml at arin.net
> Subject: Re: [ppml] IPv6 flawed?
> 
> My organization recently changed IPv6 numbers. We had used 
> EUI64 addressing on servers and used a "subnetting" scheme 
> that was logical and sustainable. It did not require actually 
> touching any servers to change IPs. It was done as such: Add 
> IP prefix to appropriate router interfaces, run find-replace 
> script to fix prefixes in DNS, wait, remove old IP prefixes 
> from router interfaces.
> 
> While I  am not trying to diminish the valid conversation 
> about difficulties involved in renumbering, etc., I am 
> actually doing, and have done this. IPv6 is not IPv4, and 
> there are some aspects of it that change the ways things 
> are/can be done. In our experience, the largest hurdle 
> involved in using IPv6 effectively is getting folks to break 
> out of the IPv4 way of thinking. With larger address spaces 
> come the ability to address interfaces, etc. in a more 
> logical way, that when added to some of the nice things like 
> EUI64 addressing, can make "re-numbering" considerably easier.
> 
> 
> On Sep 17, 2007, at 10:26 AM, Azinger, Marla wrote:
> 
> > Hmmm...Now...what was that long drawn out conversation....that 
> > addressed private space in a good way.....oh yeah!  ULA-C!
> >
> > Cheers!
> > Marla
> >
> > -----Original Message-----
> > From: ppml-bounces at arin.net 
> [mailto:ppml-bounces at arin.net]On Behalf Of 
> > Brian Johnson
> > Sent: Monday, September 17, 2007 7:00 AM
> > To: Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
> > Subject: Re: [ppml] IPv6 flawed?
> >
> >
> > Ted wrote:
> >>
> >> You don't understand it because you are large enough to 
> have your own 
> >> allocation.
> >>
> >> For the orgs too small to meet justification requirements to get a 
> >> direct allocation of IPv6 from an RIR, it is a big problem.
> >>
> >> They do not want to get IPv6 from an ISP AKA "local internet 
> >> registry"
> >> and put time and money into numbering all their servers 
> and suchlike 
> >> - because if they find a better deal down the street from 
> the ISP's 
> >> (I mean local internet registry's) competitor, they want 
> to be free 
> >> to dump the existing ISP and go to the competitor without 
> having to 
> >> renumber internally.
> >>
> >> This IMHO is the single largest reason so many orgs adopted NAT.
> >>
> >
> > I agree with Ted that there is a noticeable benefit to having NAT 
> > capability, but not that it is the "single largest reason 
> so many orgs 
> > adopted NAT." It does act as a pseudo-security feature, and it does 
> > make a network "portable".
> >
> > I would have no problem with a say a /32 of IPv6 being set aside as 
> > "private space." This will only increase the longevity of IPv6 when 
> > used by companies who only need limited IP addresses and 
> want to use 
> > private space and NAT. What arguments are there against this?
> >
> > - Brian
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN 
> > Member Services Help Desk at 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 (PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN 
> > Member Services Help Desk at info at arin.net if you experience any 
> > issues.
> >
> 
> --
> Cort Buffington
> Assistant Director for Technical Services The Kansas Research 
> and Education Network cort at kanren.net
> Office: +1-785-856-9800 x301
> Mobile: +1-785-865-7206
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at info at arin.net if you 
> experience any issues.
> 


From owen at delong.com  Mon Sep 17 13:02:01 2007
From: owen at delong.com (Owen DeLong)
Date: Mon, 17 Sep 2007 10:02:01 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <62489.1190047543@sa.vix.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net><1F476111-95E8-4023-B367-357AA75EBD29@delong.com><853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
	<52056.1190046240@sa.vix.com>
	<D03E4899F2FB3D4C8464E8C76B3B68B00107D9AD@E03MVC4-UKBR.domain1.systemhost.net>
	<62489.1190047543@sa.vix.com>
Message-ID: <4B5BA487-A367-4BB3-95D9-B16B53BB7CD5@delong.com>

>> Now if only the ARIN staff would get off their butts and maintain the
>> home page, it might encourage more people to get involved in adding
>> content to the Wiki.
>
> in defense of arin staff, they aren't on their butts, they work  
> hard and they
> get a lot of stuff done.  i think the wiki is new enough that  
> nobody knows
> exactly how to guide it -- you ought to volunteer to edit the home  
> page and
> see if somebody takes you up on it.

I really have to second what Paul is saying here.  I was recently in  
Virginia,
and, took the opportunity to pay a visit to the ARIN office.  Richard  
Jimmerson
was kind enough to give me a very nice tour.  At the end of the tour,  
I asked
him where everyone else worked.  At first, he was puzzled by my  
question.
Given the amount of work accomplished by ARIN, I had always presumed
that in addition to the 40 or so visible people I'd corresponded  
with, met at
meetings, etc., there were probably 60 or so additional people  
backing them
up at the office.  NOPE... Turns out that get all that done with a  
relatively small
staff of very dedicated people, and, they're constantly working to  
find new
ways to get even more done.

I like the idea of ARIN improving the home page and wiki as suggested,
and, I'm willing to bet that a polite suggestion to do so, or, even the
comment that was made will probably result in some effort in that  
direction.
However, they are definitely not sitting on their butts or goofing off.

Owen



From marla.azinger at frontiercorp.com  Mon Sep 17 13:02:46 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Mon, 17 Sep 2007 13:02:46 -0400
Subject: [ppml] IPv6 flawed?
Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272FA1D@nyrofcs2ke2k01.corp.pvt>

1. From your response I just have to gather you are not comprhending my points.  I can understand disagreement, but from your response, it appears you are only able to see one view of things.  And I am familiar with the technical documents and have actively debated the pros and cons.  But again, you must not comprehend the fact that I am pointing out Pro's.

So just to make it clear.  I think Owen and Paul have valid points.  And I cant, nor do I say they are wrong.  What I have pointed out is that there are positive aspects that keep getting overlooked.  And there can be hope in it working if it were worked on more.  That said, I think hope is diminishing due to the strong beliefs that it will be misused.  I think that is really unfortunate because there are enterprises that could benefit from it.

2.Nowhere did I suggest ARIN take punitive measures.  If public humility was to be used, it would be exactly that.  Public.  And...I know this is not an original thought.

Cheers!
Marla  





-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
michael.dillon at bt.com
Sent: Monday, September 17, 2007 9:22 AM
To: ppml at arin.net
Subject: Re: [ppml] IPv6 flawed?


>  Which makes me wonder why they arnt 
> just publicly humiliated into doing things right.  And I 
> question, if they would do the same thing with ULA or 
> actually use that one right with all the publicity its gotten.

As an ARIN AC member, I would have thought that you would take the time
to understand the technology that you were talking about, ESPECIALLY
when you talk about applying punitive measures.

Let me reword this. It is JUST PLAIN STUPID to suggest that we should
publicly humiliate people who use ULA addressing. ULA was created by the
IETF to address the need for addressing private interfaces which are
never intended to communicate outside a particular network. There is
nothing wrong with using ULA addresses.

As for ULA-C, this is something which does not exist. There are at least
two different proposals for something which may or may not be what
people think of as ULA-C. The IETF is rechartering the ipv6 working
group and one of the work items in that charter is to resolve what to do
about ULA-C and the various proposals. It is entirely possible that the
IETF will create something called ULA-C which is not at all like what
you think it is. If you care about this, I suggest that you should join
the WG, read the drafts, comment on them, or write your own draft.

But it is premature to be promoting punitive measures on the ARIN PPML.

And for the record, I don't care what hat you were wearing when you made
that comment, I will not be voting for your re-election to the AC.

--Michael Dillon

P.S. If you are still confused about ULA then read RFC 4193
http://www.ietf.org/rfc/rfc4193.txt

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.


From kkargel at polartel.com  Mon Sep 17 13:03:41 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Sep 2007 12:03:41 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <1F476111-95E8-4023-B367-357AA75EBD29@delong.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
	<1F476111-95E8-4023-B367-357AA75EBD29@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670748B@mail>

 
Cort,
	Wouldn't both of your examples have the same difficulty no
matter how the network was renumbered?  Devices outside of ones control
are just that, and if you change your PI/PA space they are going to need
to be adjusted by their local admin, by that admin's policy.  This 'may'
be ameliorated by using DNS for resolution, but again, that is the
admin's policy to decide.
	Connected networks need communication between admins for smooth
connectivity during transitions..  
Kevin

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Owen DeLong
> Sent: Monday, September 17, 2007 10:59 AM
> To: Cort Buffington
> Cc: ppml at arin.net
> Subject: Re: [ppml] IPv6 flawed?
> 
> Please expand on the following details of your ease of renumbering:
> 
> 	1.	How many VPNs did you have terminating on devices in the
> 		space you renumbered at one end with the other 
> end terminating
> 		on devices you did not control?
> 
> 	2.	How many external organizations had firewalls 
> you don't control
> 		with policies containing your addresses when 
> you renumbered?
> 
> If your answers to questions 1 and 2 are zero or near zero, 
> then, I would argue that you have not demonstrated a 
> meaningful difference in the effort required to renumber IPv6 
> vs. IPv4.
> 
> Owen
> 
> On Sep 17, 2007, at 8:39 AM, Cort Buffington wrote:
> 
> > My organization recently changed IPv6 numbers. We had used EUI64 
> > addressing on servers and used a "subnetting" scheme that 
> was logical 
> > and sustainable. It did not require actually touching any 
> servers to 
> > change IPs. It was done as such: Add IP prefix to 
> appropriate router 
> > interfaces, run find-replace script to fix prefixes in DNS, wait, 
> > remove old IP prefixes from router interfaces.
> >
> > While I  am not trying to diminish the valid conversation about 
> > difficulties involved in renumbering, etc., I am actually 
> doing, and 
> > have done this. IPv6 is not IPv4, and there are some aspects of it 
> > that change the ways things are/can be done. In our experience, the 
> > largest hurdle involved in using IPv6 effectively is 
> getting folks to 
> > break out of the IPv4 way of thinking. With larger address 
> spaces come 
> > the ability to address interfaces, etc. in a more logical way, that 
> > when added to some of the nice things like EUI64 
> addressing, can make 
> > "re-numbering" considerably easier.
> >
> >
> > On Sep 17, 2007, at 10:26 AM, Azinger, Marla wrote:
> >
> >> Hmmm...Now...what was that long drawn out conversation....that 
> >> addressed private space in a good way.....oh yeah!  ULA-C!
> >>
> >> Cheers!
> >> Marla
> >>
> >> -----Original Message-----
> >> From: ppml-bounces at arin.net 
> [mailto:ppml-bounces at arin.net]On Behalf 
> >> Of Brian Johnson
> >> Sent: Monday, September 17, 2007 7:00 AM
> >> To: Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
> >> Subject: Re: [ppml] IPv6 flawed?
> >>
> >>
> >> Ted wrote:
> >>>
> >>> You don't understand it because you are large enough to have your 
> >>> own allocation.
> >>>
> >>> For the orgs too small to meet justification requirements 
> to get a 
> >>> direct allocation of IPv6 from an RIR, it is a big problem.
> >>>
> >>> They do not want to get IPv6 from an ISP AKA "local internet 
> >>> registry"
> >>> and put time and money into numbering all their servers 
> and suchlike 
> >>> - because if they find a better deal down the street from 
> the ISP's 
> >>> (I mean local internet registry's) competitor, they want 
> to be free 
> >>> to dump the existing ISP and go to the competitor without 
> having to 
> >>> renumber internally.
> >>>
> >>> This IMHO is the single largest reason so many orgs adopted NAT.
> >>>
> >>
> >> I agree with Ted that there is a noticeable benefit to having NAT 
> >> capability, but not that it is the "single largest reason so many 
> >> orgs adopted NAT." It does act as a pseudo-security 
> feature, and it 
> >> does make a network "portable".
> >>
> >> I would have no problem with a say a /32 of IPv6 being set 
> aside as 
> >> "private space." This will only increase the longevity of 
> IPv6 when 
> >> used by companies who only need limited IP addresses and 
> want to use 
> >> private space and NAT. What arguments are there against this?
> >>
> >> - Brian
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed 
> to the ARIN 
> >> Public Policy Mailing List (PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN 
> >> Member Services Help Desk at 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 (PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN 
> >> Member Services Help Desk at info at arin.net if you experience any 
> >> issues.
> >>
> >
> > --
> > Cort Buffington
> > Assistant Director for Technical Services The Kansas Research and 
> > Education Network cort at kanren.net
> > Office: +1-785-856-9800 x301
> > Mobile: +1-785-865-7206
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN 
> > Member Services Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at info at arin.net if you 
> experience any issues.
> 


From kkargel at polartel.com  Mon Sep 17 13:36:24 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Sep 2007 12:36:24 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <20070917162202.GH23649@shell01.cell.sv2.tellme.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net><1F476111-95E8-4023-B367-357AA75EBD29@delong.com><853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
	<20070917162202.GH23649@shell01.cell.sv2.tellme.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670748C@mail>

 If you *could* easily renumber IP addresses not under your control
wouldn't that make them *under* your control?

Kevin

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of David Williamson
> Sent: Monday, September 17, 2007 11:22 AM
> To: Cort Buffington
> Cc: ppml at arin.net
> Subject: Re: [ppml] IPv6 flawed?
> 
> On Mon, Sep 17, 2007 at 11:08:54AM -0500, Cort Buffington wrote:
> > Yep, that's right. I really don't do enough meaningful 
> networking to 
> > speak up here. I should have kept my mouth shut.
> 
> I don't think that's the point.
> 
> >From the sound of it, you've managed to renumber your local 
> environment
> fairly easily.  Congrats!  It's nice to hear that someone has 
> had a fairly easy renumbering experience with IPv6.
> 
> Owen's point is valid, though - unless there is some 
> mechanism for renumbering addresses stored in places not 
> under your control, this isn't really any easier than with 
> IPv4.  For organnizations that don't utilize VPNs and don't 
> have their addressess embedded all over the place, the two 
> are mostly equivalent, although IPv6 has more natural methods 
> for renumbering in a fairly painless way.
> 
> Unfortunately, many orgs are not in that space, and 
> renumbering is hard and painful.  If there's a broad solution 
> to that problem space, I'd really like to hear about it.
> 
> That, I think, is the point.
> 
> -David
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at info at arin.net if you 
> experience any issues.
> 


From info at arin.net  Mon Sep 17 13:41:23 2007
From: info at arin.net (Member Services)
Date: Mon, 17 Sep 2007 13:41:23 -0400
Subject: [ppml] ARIN XX - Policy Proposals and Draft Agenda
Message-ID: <46EEBC43.7070805@arin.net>

The following policy proposals have been under discussion on the ARIN
Public Policy Mailing List and will be presented for consideration at
the upcoming ARIN XX Public Policy Meeting in Albuquerque, New Mexico,
on 17-18 October 2007.

2007-25: IPv6 Policy Housekeeping

2007-24: IPv6 Assignment Guidelines

2007-23: End Policy for IANA IPv4 allocations to RIRs

2007-22: Expand timeframe of Additional Requests

2007-21: PIv6 for legacy holders with RSA and efficient use

2007-20: Definition of known ISP and changes to IPv6 initial allocation
criteria

2007-19: IANA Policy for Allocation of ASN Blocks to RIRs

2007-18: Global Policy for the Allocation of the Remaining IPv4 Address
Space

2007-17: Legacy Outreach and Partial Reclamation

2007-16: IPv4 Soft Landing

2007-15: Authentication of Legacy Resources

2007:14: Resource Review Process

2007-13: Removal of ISP Immediate Need from End-User

2006-7: Changes to IPv6 initial allocation criteria

The full text for each proposal can be found at:
http://www.arin.net/policy/proposal_archive.html

Agenda information has been updated. Find the draft agenda as well as 
hotel information at:
http://www.arin.net/ARIN-XX/

Check back as the agenda information is updated periodically.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)



From michael.dillon at bt.com  Mon Sep 17 13:58:27 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 17 Sep 2007 18:58:27 +0100
Subject: [ppml] IPv6 flawed?
In-Reply-To: <4B5BA487-A367-4BB3-95D9-B16B53BB7CD5@delong.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net><1F476111-95E8-4023-B367-357AA75EBD29@delong.com><853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net><52056.1190046240@sa.vix.com><D03E4899F2FB3D4C8464E8C76B3B68B00107D9AD@E03MVC4-UKBR.domain1.systemhost.net><62489.1190047543@sa.vix.com>
	<4B5BA487-A367-4BB3-95D9-B16B53BB7CD5@delong.com>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00107DA05@E03MVC4-UKBR.domain1.systemhost.net>

> I like the idea of ARIN improving the home page and wiki as 
> suggested, and, I'm willing to bet that a polite suggestion 
> to do so, or, even the comment that was made will probably 
> result in some effort in that direction.
> However, they are definitely not sitting on their butts or 
> goofing off.

The polite request was already made privately to Member Services. After
no reponse, I made another polite request on this list. Still no
response, except for two people who pointed me to their similar IPv6
wikis. So I made the comment about the wiki being neglected. I don't
know who does what behind the scenes and I'm not willing to accept your
annecdotal account as the definitive statement. Who knows how many
contractors, consultants, summer interns or others have been involved in
getting the work done. That is not policy anyway.

The fact is that the IPv6 wiki *IS* being neglected administratively,
even though they announced it in the latest newsletter which is where I
learned about it.

I don't know why they are neglecting it because I think a wiki is a
great way to collaboratively develop documents.

--Michael Dillon


From cort at kanren.net  Mon Sep 17 13:57:50 2007
From: cort at kanren.net (Cort Buffington)
Date: Mon, 17 Sep 2007 12:57:50 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <EA9B1801BA3A584887D7D4AB70DC30B008B93447@athena.graceland.edu>
References: <EA9B1801BA3A584887D7D4AB70DC30B008B93447@athena.graceland.edu>
Message-ID: <02785056-45F3-4539-B8C0-0E057C27C8DA@kanren.net>

We are one of the "old school" state RENs. Our business is WAN  
networking to connect institutions with a research and/or educational  
mission together and to the Internet, Internet 2 (as appropriate),  
etc. Over the course of our existence, we have gathered a fair number  
of support servers performing various functions for ourselves and our  
members, as well as co-location of servers for members within our PoPs.

We do not terminate VPNs, and in fact, because of limitations  
associated with traditional VPN-V4 L3 MPLS where services like  
Multicast and IPv6 have been concerned, we don't use that technology  
(much - we have the luxury of being able to not use it for the most  
part). We do have a great many downstream members (members to us,  
most would call them "customers") who use our IP space. One of them  
is very active with IPv6 (a larger community college of all places,  
not a major university), and I understand they simply made prefix  
changes much as we did, as they planned for this eventuality when  
they initially deployed.

We became fully operational with IPv6 in 2004. Yes, there have been  
issues -- spotty vendor support being a big one -- but we did it  
because as an R&E network (Research and Education) it is our mission  
to do things like this so that we can (hopefully) be ahead of the  
curve. Rather than a specific case study, my poorly made point was  
that many issues arising with IPv6 since we've been using it have  
been because we are thinking 4 and not thinking 6. The size of the  
address space in and of itself has made a lot of things better, but  
not from a "we're out of addresses" standpoint. It has made it  
possible to more logically break down a network, change prefixes (as  
I mentioned earlier), and have member networks (customers) that don't  
have several tiny networks they're trying to send to us because  
addresses are such a precious commodity small incremental growth and  
contiguous space are not possible. With IPv6's address space it's  
easy to throw someone hundreds, or thousands of /64s and not even be  
over-allocating. So, even though we may not have fixed the routing  
paradigm, at least we only see ONE PREFIX coming from the downstream  
instead of several, so that's one routing table entry, and one prefix  
for them to send to a second provider when they multihome. Not  
necessarily glamorous, but there are things about 6 that do work and  
are working. The challenge is thinking 6 and thinking what 6 can or  
will do instead of letting our minds be locked into the limitations  
of IPv4. Now, that wasn't a great example of how great IPv6 might be,  
but it shows how thinking in 6 can solve some problems. Making a lot  
of small things a little better amounts to a lot of improvement over  
time.

Sadly, (I believe it was Paul Vixie that mentioned it) IPv6 did not  
address the routing paradigm, but there are some nice things it did  
address. In my case, something was improved. And I believe there is a  
lot more good out there to be gleaned from it. If we ever see things  
(really working, and working well) like authentication and encryption  
built into IPv6 via extension headers, maybe we won't even need VPNs  
as we know them today.

On Sep 17, 2007, at 11:30 AM, Dave Mohler wrote:

> I'm sorry you felt dismissed by Owen's request.  I have no idea if  
> Owen
> knows of the network on which you did the IPv6 renumbering, but I'm  
> sure
> I don't have any idea and I'm sure many other list readers don't know
> your network.
>
> I feel that these are reasonable questions that help the group
> understand the implications of IPv6 renumbering.  I assumed that  
> Owen's
> inclusion of his reasons for asking were just as a means of explaining
> the importance of the questions for the benefit of the discussion and
> not an advanced dismissal of your contribution.  (Perhaps they were  
> not
> worded in the best way, but in general I've felt that I could trust  
> most
> list contributors' motives as being for the good of the group.)
>
> I, for one, would appreciate your answers to Owen's questions to  
> help us
> better understand the issues.
>
> Thanks for your contributions!
>
> David A. Mohler
> Senior Network Specialist
> Graceland University
>
>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf
> Of
>> Cort Buffington
>> Sent: Monday, September 17, 2007 11:09 AM
>> To: Owen DeLong
>> Cc: ppml at arin.net
>> Subject: Re: [ppml] IPv6 flawed?
>>
>> Yep, that's right. I really don't do enough meaningful networking to
>> speak up here. I should have kept my mouth shut.
>>
>> On Sep 17, 2007, at 10:58 AM, Owen DeLong wrote:
>>
>>> Please expand on the following details of your ease of renumbering:
>>>
>>> 	1.	How many VPNs did you have terminating on devices in the
>>> 		space you renumbered at one end with the other end
> terminating
>>> 		on devices you did not control?
>>>
>>> 	2.	How many external organizations had firewalls you don't
>> control
>>> 		with policies containing your addresses when you
> renumbered?
>>>
>>> If your answers to questions 1 and 2 are zero or near zero, then, I
>>> would
>>> argue that you have not demonstrated a meaningful difference in the
>>> effort required to renumber IPv6 vs. IPv4.
>>>
>>> Owen
>>>
>>> On Sep 17, 2007, at 8:39 AM, Cort Buffington wrote:
>>>
>>>> My organization recently changed IPv6 numbers. We had used EUI64
>>>> addressing on servers and used a "subnetting" scheme that was
> logical
>>>> and sustainable. It did not require actually touching any servers
> to
>>>> change IPs. It was done as such: Add IP prefix to appropriate
> router
>>>> interfaces, run find-replace script to fix prefixes in DNS, wait,
>>>> remove old IP prefixes from router interfaces.
>>>>
>>>> While I  am not trying to diminish the valid conversation about
>>>> difficulties involved in renumbering, etc., I am actually doing,
> and
>>>> have done this. IPv6 is not IPv4, and there are some aspects of it
>>>> that change the ways things are/can be done. In our experience, the
>>>> largest hurdle involved in using IPv6 effectively is getting folks
> to
>>>> break out of the IPv4 way of thinking. With larger address spaces
>>>> come the ability to address interfaces, etc. in a more logical way,
>>>> that when added to some of the nice things like EUI64 addressing,
> can
>>>> make "re-numbering" considerably easier.
>>>>
>>>>
>>>> On Sep 17, 2007, at 10:26 AM, Azinger, Marla wrote:
>>>>
>>>>> Hmmm...Now...what was that long drawn out conversation....that
>>>>> addressed private space in a good way.....oh yeah!  ULA-C!
>>>>>
>>>>> Cheers!
>>>>> Marla
>>>>>
>>>>> -----Original Message-----
>>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On
>>>>> Behalf Of
>>>>> Brian Johnson
>>>>> Sent: Monday, September 17, 2007 7:00 AM
>>>>> To: Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
>>>>> Subject: Re: [ppml] IPv6 flawed?
>>>>>
>>>>>
>>>>> Ted wrote:
>>>>>>
>>>>>> You don't understand it because you are large enough to have your
>>>>>> own allocation.
>>>>>>
>>>>>> For the orgs too small to meet justification requirements to get
>>>>>> a direct allocation of IPv6 from an RIR, it is a big problem.
>>>>>>
>>>>>> They do not want to get IPv6 from an ISP AKA "local internet
>>>>>> registry"
>>>>>> and put time and money into numbering all their servers and
>>>>>> suchlike -
>>>>>> because if they find a better deal down the street from the ISP's
>>>>>> (I mean local internet registry's) competitor, they want to be
> free
>>>>>> to dump the existing ISP and go to the competitor without having
> to
>>>>>> renumber internally.
>>>>>>
>>>>>> This IMHO is the single largest reason so many orgs adopted NAT.
>>>>>>
>>>>>
>>>>> I agree with Ted that there is a noticeable benefit to having NAT
>>>>> capability, but not that it is the "single largest reason so many
>>>>> orgs
>>>>> adopted NAT." It does act as a pseudo-security feature, and it
> does
>>>>> make
>>>>> a network "portable".
>>>>>
>>>>> I would have no problem with a say a /32 of IPv6 being set aside
> as
>>>>> "private space." This will only increase the longevity of IPv6
> when
>>>>> used
>>>>> by companies who only need limited IP addresses and want to use
>>>>> private
>>>>> space and NAT. What arguments are there against this?
>>>>>
>>>>> - Brian
>>>>>
>>>>> _______________________________________________
>>>>> PPML
>>>>> You are receiving this message because you are subscribed to the
>>>>> ARIN Public Policy
>>>>> Mailing List (PPML at arin.net).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the
> ARIN
>>>>> Member Services
>>>>> Help Desk at 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 (PPML at arin.net).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the
> ARIN
>>>>> Member Services
>>>>> Help Desk at info at arin.net if you experience any issues.
>>>>>
>>>>
>>>> --
>>>> Cort Buffington
>>>> Assistant Director for Technical Services
>>>> The Kansas Research and Education Network
>>>> cort at kanren.net
>>>> Office: +1-785-856-9800 x301
>>>> Mobile: +1-785-865-7206
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to the
>>>> ARIN Public Policy
>>>> Mailing List (PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the
>>>> ARIN Member Services
>>>> Help Desk at info at arin.net if you experience any issues.
>>>
>>>
>>
>> --
>> Cort Buffington
>> Assistant Director for Technical Services
>> The Kansas Research and Education Network
>> cort at kanren.net
>> Office: +1-785-856-9800 x301
>> Mobile: +1-785-865-7206
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
> Member
>> Services
>> Help Desk at info at arin.net if you experience any issues.
>

--
Cort Buffington
Assistant Director for Technical Services
The Kansas Research and Education Network
cort at kanren.net
Office: +1-785-856-9800 x301
Mobile: +1-785-865-7206





From BillD at cait.wustl.edu  Mon Sep 17 14:09:20 2007
From: BillD at cait.wustl.edu (Bill Darte)
Date: Mon, 17 Sep 2007 13:09:20 -0500
Subject: [ppml] ARIN XX - Policy Proposals and Draft Agenda
In-Reply-To: <46EEBC43.7070805@arin.net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030871E5C99@ex1.cait.wustl.edu>

Hello everyone,

As you can see, we'll be having fun in Albuquerque!
So please join in...in person if possible, or remotely.

If neither is possible, please read each of these proposals on the ARIN
website (http://www.arin.net/policy/proposals/proposal_archive.html) and
post your comments and especially whether you SUPPORT or DO NOT SUPPORT
each proposal.

For those attending the meeting, please also review each proposal prior
to the meeting in order to voice your own sentiment similarly.

The ARIN AC has among its roles the assessment of industry consensus on
policy proposals and we judge this against all inputs (PPML, Meeting,
Remote participation, private emails, etc.) The more and more clearly
stated, the better we can assist this industry effort.

Thank you all for your involvement and support.

Bill Darte
ARIN AC

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Member Services
> Sent: Monday, September 17, 2007 12:41 PM
> To: ppml at arin.net
> Subject: [ppml] ARIN XX - Policy Proposals and Draft Agenda
> 
> 
> The following policy proposals have been under discussion on 
> the ARIN Public Policy Mailing List and will be presented for 
> consideration at the upcoming ARIN XX Public Policy Meeting 
> in Albuquerque, New Mexico, on 17-18 October 2007.
> 
> 2007-25: IPv6 Policy Housekeeping
> 
> 2007-24: IPv6 Assignment Guidelines
> 
> 2007-23: End Policy for IANA IPv4 allocations to RIRs
> 
> 2007-22: Expand timeframe of Additional Requests
> 
> 2007-21: PIv6 for legacy holders with RSA and efficient use
> 
> 2007-20: Definition of known ISP and changes to IPv6 initial 
> allocation criteria
> 
> 2007-19: IANA Policy for Allocation of ASN Blocks to RIRs
> 
> 2007-18: Global Policy for the Allocation of the Remaining 
> IPv4 Address Space
> 
> 2007-17: Legacy Outreach and Partial Reclamation
> 
> 2007-16: IPv4 Soft Landing
> 
> 2007-15: Authentication of Legacy Resources
> 
> 2007:14: Resource Review Process
> 
> 2007-13: Removal of ISP Immediate Need from End-User
> 
> 2006-7: Changes to IPv6 initial allocation criteria
> 
> The full text for each proposal can be found at: 
> http://www.arin.net/policy/proposal_archive.html
> 
> Agenda information has been updated. Find the draft agenda as well as 
> hotel information at:
> http://www.arin.net/ARIN-XX/
> 
> Check back as the agenda information is updated periodically.
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net). 
> Unsubscribe or manage your mailing list subscription at: 
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at info at arin.net if you 
> experience any issues.
> 


From sleibrand at internap.com  Mon Sep 17 14:01:30 2007
From: sleibrand at internap.com (Scott Leibrand)
Date: Mon, 17 Sep 2007 11:01:30 -0700
Subject: [ppml] ULA
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066707489@mail>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><39278.1190043128@sa.vix.com>	<3241FDB1-9567-4EC0-ACA6-C5FA8494D4C7@muada.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066707489@mail>
Message-ID: <46EEC0FA.3080007@internap.com>

Kevin,

All ULA space (L, C, G, or whatever) will come out of a single /7, which 
should be route-filtered on all DFZ routers.  That's the main benefit of 
using ULA-* space rather than PI space for private addressing (and even 
private internetworking): everyone who isn't part of your private 
network can filter your routes with no additional effort, so they don't 
pollute the DFZ if they leak.

-Scott

Kevin Kargel wrote:
>  How will you know their announcement is ULA-C to filter it?  Are you
> saying that you will build a statement for every ULA-C for each ASN in
> the world into your edge access-list?  Or is there some aggregatable
> filter list I am unaware of?  Even if it were as few as 500 filter
> statements, I would not be happy to have to extend an access list that
> far, and I suspect the number of statements required would far outrun
> that humble number.
>
> Feel free to educate me, I want to learn.
>
> Kevin
>
>
>   
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
>> Behalf Of Iljitsch van Beijnum
>> Sent: Monday, September 17, 2007 10:38 AM
>> To: Paul Vixie
>> Cc: ppml at arin.net
>> Subject: Re: [ppml] IPv6 flawed?
>>
>> On 17-sep-2007, at 17:32, Paul Vixie wrote:
>>
>>     
>>>> Hmmm...Now...what was that long drawn out conversation....that 
>>>> addressed private space in a good way.....oh yeah!  ULA-C!
>>>>         
>>> ULA-C is apparently quite dead, since noone whose job includes 
>>> defending the DFZ from explosion believes that ULA-C would be as 
>>> "local" as ULA.
>>>       
>> Riiiight... that must be why several people told me that PI 
>> is a good alternative for ULA-C, people holding a PI block 
>> will of course never be tempted to announce THAT.
>>
>> I'll be filtering ULA-Cs that people announce, or they'll be 
>> giving me enough money that I'm happy to accept the 
>> advertisements. No problem either way.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to 
>> the ARIN Public Policy Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact 
>> the ARIN Member Services Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>   


From tedm at ipinc.net  Mon Sep 17 14:02:25 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 17 Sep 2007 11:02:25 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106670748C@mail>
Message-ID: <NABBJOELMNGNJNGPKDDOCENKHDAA.tedm@ipinc.net>


When are people going to realize that the renumbering issue
is a big deal for some organizations, no matter whether your
using IPv4 or IPv6, regardless of the new features in IPv6.

Renumbering isn't about just changing interfaces, folks.  For
the sake of discussion (and since they aren't our customer anymore
and can't do anything to us) I'll name names.  As a disclaimer
I will say it's been a couple years since I've touched that network,
so they may have cleaned up their act.  But, I don't believe it.

We used to work on Legacy Health Systems internal network.  For
those of you who never had the pleasure there's literally dozens
of IT groups under that umbrella - all very mistrustful of each other.
There's a central numbering authority - I know his name but I
won't make any more trouble for him - who is largely ignored
by these groups until they do something stupid like use the same
numbering for their networks and then want to talk to each other -
even though he's designated as the number's Czar.  And half the
time the solution to this was to introduce yet another NAT device
in between the conflicting networks rather than renumbering one
or both of them. For various 
business/political reasons it's clearly obvious that the powers
that be at the top like it this way.

Firewalls are common and plentiful in that WAN/LAN all run by
these different fiefdoms and they all use large access lists with
hard-coded host numbers in them.  There is really not one single
person - in my humble opinion - who knows all about all applications
on the network and all servers and who all is supposed to be using
them.  The typical MO to setup a worker bee in the organization can
involve discussions with tens of different admins to get access
to all the stuff the person needs.

For the people that talk about IPv6 renumbering like you just flip a
switch and change the prefix in the router, may I humbly suggest
you are out of your fricking mind.  If and when Legacy ever does
switchover to IPv6, some bird-brained admin that tried that would
be shot as it would knock hundreds of workers offline and generate
numerous support calls, mostly to desktop support staff who would
have no idea what the problem was and even less on how to solve it.

And I might also add that LHS is easily large enough to qualify
for their own IPv4 numbers let alone IPv6 - but they use RFC1918
numbers like everyone else does - at least, all the parts of the
network that we ever saw did.  For all I know they might have 
public numbers widely deployed in some part of their network - not
that most of the IT groups within would pay any attention to that.

Ted

>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Kevin Kargel
>Sent: Monday, September 17, 2007 10:36 AM
>To: ppml at arin.net
>Subject: Re: [ppml] IPv6 flawed?
>
>
> If you *could* easily renumber IP addresses not under your control
>wouldn't that make them *under* your control?
>
>Kevin
>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
>> Behalf Of David Williamson
>> Sent: Monday, September 17, 2007 11:22 AM
>> To: Cort Buffington
>> Cc: ppml at arin.net
>> Subject: Re: [ppml] IPv6 flawed?
>> 
>> On Mon, Sep 17, 2007 at 11:08:54AM -0500, Cort Buffington wrote:
>> > Yep, that's right. I really don't do enough meaningful 
>> networking to 
>> > speak up here. I should have kept my mouth shut.
>> 
>> I don't think that's the point.
>> 
>> >From the sound of it, you've managed to renumber your local 
>> environment
>> fairly easily.  Congrats!  It's nice to hear that someone has 
>> had a fairly easy renumbering experience with IPv6.
>> 
>> Owen's point is valid, though - unless there is some 
>> mechanism for renumbering addresses stored in places not 
>> under your control, this isn't really any easier than with 
>> IPv4.  For organnizations that don't utilize VPNs and don't 
>> have their addressess embedded all over the place, the two 
>> are mostly equivalent, although IPv6 has more natural methods 
>> for renumbering in a fairly painless way.
>> 
>> Unfortunately, many orgs are not in that space, and 
>> renumbering is hard and painful.  If there's a broad solution 
>> to that problem space, I'd really like to hear about it.
>> 
>> That, I think, is the point.
>> 
>> -David
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to 
>> the ARIN Public Policy Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact 
>> the ARIN Member Services Help Desk at 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 (PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/ppml Please contact the 
>ARIN Member Services
>Help Desk at info at arin.net if you experience any issues.
>


From michael.dillon at bt.com  Mon Sep 17 14:06:38 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 17 Sep 2007 19:06:38 +0100
Subject: [ppml] IPv6 flawed?
In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272FA1D@nyrofcs2ke2k01.corp.pvt>
References: <454810F09B5AA04E9D78D13A5C39028A0272FA1D@nyrofcs2ke2k01.corp.pvt>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00107DA0C@E03MVC4-UKBR.domain1.systemhost.net>

> 2.Nowhere did I suggest ARIN take punitive measures.  If 
> public humility was to be used, it would be exactly that.  
> Public.  And...I know this is not an original thought.

I hope English is not your native language because I could forgive this
statement if that was so.

Punitive measures means any actions which punish an individual or an
organization. Historically, public humility has often been used as a
punishment. Some recent examples are sitting in the stocks in colonial
America or shaving the heads of collaborators in Italy after liberation
from the Fascists/Nazis.

I do not think that it is appropriate for ARIN to take punitive
measures, not even public humiliation, until all other measures have
been exhausted. These other measures are communication, negotiation and
education. I don't see any area where ARIN policy needs to be made more
punitive. We need things like clarity much more than punitive measures.

--Michael Dillon

P.S. the words punitive, punishment, punish, penal and penitentiary all
come from the same Latin roots.


From michael.dillon at bt.com  Mon Sep 17 14:15:11 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 17 Sep 2007 19:15:11 +0100
Subject: [ppml] IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOCENKHDAA.tedm@ipinc.net>
References: <70DE64CEFD6E9A4EB7FAF3A06314106670748C@mail>
	<NABBJOELMNGNJNGPKDDOCENKHDAA.tedm@ipinc.net>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00107DA0E@E03MVC4-UKBR.domain1.systemhost.net>


> Firewalls are common and plentiful in that WAN/LAN all run by 
> these different fiefdoms and they all use large access lists 
> with hard-coded host numbers in them.  There is really not 
> one single person - in my humble opinion - who knows all 
> about all applications on the network and all servers and who 
> all is supposed to be using them.  The typical MO to setup a 
> worker bee in the organization can involve discussions with 
> tens of different admins to get access to all the stuff the 
> person needs.

And every single one of those devices needs to be CHANGED in order to
convert it to IPv6. At the time of conversion (or preferably during the
audit preceding conversion) it makes sense to try and get some control
over these ACLs to facilitate renumbering.

Of course, one solution is to not convert certain devices to IPv6 but
just live with the IPv4 stuff that works. When those networks become
isolated IPv4 islands in an IPv6 network, it will never again be
necessary to renumber the IPv4 interfaces.

> For the people that talk about IPv6 renumbering like you just 
> flip a switch and change the prefix in the router, may I 
> humbly suggest you are out of your fricking mind. 

The people who tell you to renumber this way, also point out how they
planned and prepared from the time they were first installing their
network. The real lesson, is not that IPv6 networks can be renumbered at
a flick of a switch, but that building renumberability in from the
start, makes it very easy to do. Also, note that IPv6 requires two
switch flicks. One to turn on the new prefix, and the other to turn off
the old prefix after a delay of days or weeks. 

During those interim weeks, you could probably renumber the firewalls
one by one.

IPv6 is *NOT* just IPv4 with more bits. It works differently and
seemingly small differences have larger knock-on effects.

--Michael Dillon



From randy at psg.com  Mon Sep 17 14:18:02 2007
From: randy at psg.com (Randy Bush)
Date: Mon, 17 Sep 2007 08:18:02 -1000
Subject: [ppml] ULA
In-Reply-To: <46EEC0FA.3080007@internap.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><39278.1190043128@sa.vix.com>	<3241FDB1-9567-4EC0-ACA6-C5FA8494D4C7@muada.com>	<70DE64CEFD6E9A4EB7FAF3A063141066707489@mail>
	<46EEC0FA.3080007@internap.com>
Message-ID: <46EEC4DA.40806@psg.com>

> All ULA space (L, C, G, or whatever) will come out of a single /7, which 
> should be route-filtered on all DFZ routers.

the problem is the same old site local problem, what is a border.  this
is exacerbated in ula-c by expecting conversation between 'private'
spaces.  so you will have semi-permeable borders.  so i share part of my
space with my vendor to the left, part with my customers to my right,
and ...

can you say "massive misconfiguration and leakage" three times quickly?

randy


From michael.dillon at bt.com  Mon Sep 17 14:35:11 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 17 Sep 2007 19:35:11 +0100
Subject: [ppml] IPv6 flawed?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106670748B@mail>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net><1F476111-95E8-4023-B367-357AA75EBD29@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106670748B@mail>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B00107DA19@E03MVC4-UKBR.domain1.systemhost.net>

> 	Connected networks need communication between admins 
> for smooth connectivity during transitions..  

There are parallels here with the way people renumber nameservers. Many
sites on the Internet will have your old address cached for some period
of time. In some cases, a long-running application could have it cached
for months. And if you make use of DNS slave servers at another
organization, they have your address hard-coded in their config.

A good way to renumber nameservers is to a) notify slave server admins,
b) turn on the new addressing, c) maintain the old addressing on you
master servers for a transition period, d) monitor the master server's
traffic, e) followup any sites using the old address for too long, and
finally f) stop using the old addresses.

IPv6 only handles steps b and f automatically. However, the fact that
IPv6 has this two-step process built-in, is new for the base level
network renumbering of routers, servers etc.

--Michael Dillon


From cort at kanren.net  Mon Sep 17 14:35:08 2007
From: cort at kanren.net (Cort Buffington)
Date: Mon, 17 Sep 2007 13:35:08 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106670748B@mail>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
	<1F476111-95E8-4023-B367-357AA75EBD29@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106670748B@mail>
Message-ID: <2669BD93-2466-4CE3-8E66-3B2BC306EFAF@kanren.net>

Yes, there certainly does need to be communication, and this does  
effect our downstreams or colo folks who use our numbers -- I didn't  
fix all of the difficulties, but we did find ways to make some of  
them go a way and make the job somewhat easier. Not a no-effort  
solution, but a reduced-effort one.

On Sep 17, 2007, at 12:03 PM, Kevin Kargel wrote:

>
> Cort,
> 	Wouldn't both of your examples have the same difficulty no
> matter how the network was renumbered?  Devices outside of ones  
> control
> are just that, and if you change your PI/PA space they are going to  
> need
> to be adjusted by their local admin, by that admin's policy.  This  
> 'may'
> be ameliorated by using DNS for resolution, but again, that is the
> admin's policy to decide.
> 	Connected networks need communication between admins for smooth
> connectivity during transitions..
> Kevin
>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On
>> Behalf Of Owen DeLong
>> Sent: Monday, September 17, 2007 10:59 AM
>> To: Cort Buffington
>> Cc: ppml at arin.net
>> Subject: Re: [ppml] IPv6 flawed?
>>
>> Please expand on the following details of your ease of renumbering:
>>
>> 	1.	How many VPNs did you have terminating on devices in the
>> 		space you renumbered at one end with the other
>> end terminating
>> 		on devices you did not control?
>>
>> 	2.	How many external organizations had firewalls
>> you don't control
>> 		with policies containing your addresses when
>> you renumbered?
>>
>> If your answers to questions 1 and 2 are zero or near zero,
>> then, I would argue that you have not demonstrated a
>> meaningful difference in the effort required to renumber IPv6
>> vs. IPv4.
>>
>> Owen
>>
>> On Sep 17, 2007, at 8:39 AM, Cort Buffington wrote:
>>
>>> My organization recently changed IPv6 numbers. We had used EUI64
>>> addressing on servers and used a "subnetting" scheme that
>> was logical
>>> and sustainable. It did not require actually touching any
>> servers to
>>> change IPs. It was done as such: Add IP prefix to
>> appropriate router
>>> interfaces, run find-replace script to fix prefixes in DNS, wait,
>>> remove old IP prefixes from router interfaces.
>>>
>>> While I  am not trying to diminish the valid conversation about
>>> difficulties involved in renumbering, etc., I am actually
>> doing, and
>>> have done this. IPv6 is not IPv4, and there are some aspects of it
>>> that change the ways things are/can be done. In our experience, the
>>> largest hurdle involved in using IPv6 effectively is
>> getting folks to
>>> break out of the IPv4 way of thinking. With larger address
>> spaces come
>>> the ability to address interfaces, etc. in a more logical way, that
>>> when added to some of the nice things like EUI64
>> addressing, can make
>>> "re-numbering" considerably easier.
>>>
>>>
>>> On Sep 17, 2007, at 10:26 AM, Azinger, Marla wrote:
>>>
>>>> Hmmm...Now...what was that long drawn out conversation....that
>>>> addressed private space in a good way.....oh yeah!  ULA-C!
>>>>
>>>> Cheers!
>>>> Marla
>>>>
>>>> -----Original Message-----
>>>> From: ppml-bounces at arin.net
>> [mailto:ppml-bounces at arin.net]On Behalf
>>>> Of Brian Johnson
>>>> Sent: Monday, September 17, 2007 7:00 AM
>>>> To: Ted Mittelstaedt; Kevin Kargel; ppml at arin.net
>>>> Subject: Re: [ppml] IPv6 flawed?
>>>>
>>>>
>>>> Ted wrote:
>>>>>
>>>>> You don't understand it because you are large enough to have your
>>>>> own allocation.
>>>>>
>>>>> For the orgs too small to meet justification requirements
>> to get a
>>>>> direct allocation of IPv6 from an RIR, it is a big problem.
>>>>>
>>>>> They do not want to get IPv6 from an ISP AKA "local internet
>>>>> registry"
>>>>> and put time and money into numbering all their servers
>> and suchlike
>>>>> - because if they find a better deal down the street from
>> the ISP's
>>>>> (I mean local internet registry's) competitor, they want
>> to be free
>>>>> to dump the existing ISP and go to the competitor without
>> having to
>>>>> renumber internally.
>>>>>
>>>>> This IMHO is the single largest reason so many orgs adopted NAT.
>>>>>
>>>>
>>>> I agree with Ted that there is a noticeable benefit to having NAT
>>>> capability, but not that it is the "single largest reason so many
>>>> orgs adopted NAT." It does act as a pseudo-security
>> feature, and it
>>>> does make a network "portable".
>>>>
>>>> I would have no problem with a say a /32 of IPv6 being set
>> aside as
>>>> "private space." This will only increase the longevity of
>> IPv6 when
>>>> used by companies who only need limited IP addresses and
>> want to use
>>>> private space and NAT. What arguments are there against this?
>>>>
>>>> - Brian
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed
>> to the ARIN
>>>> Public Policy Mailing List (PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/ppml Please contact
>> the ARIN
>>>> Member Services Help Desk at 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 (PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/ppml Please contact
>> the ARIN
>>>> Member Services Help Desk at info at arin.net if you experience any
>>>> issues.
>>>>
>>>
>>> --
>>> Cort Buffington
>>> Assistant Director for Technical Services The Kansas Research and
>>> Education Network cort at kanren.net
>>> Office: +1-785-856-9800 x301
>>> Mobile: +1-785-865-7206
>>>
>>>
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed
>> to the ARIN
>>> Public Policy Mailing List (PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN
>>> Member Services Help Desk at 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 (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact
>> the ARIN Member Services Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.
>

--
Cort Buffington
Assistant Director for Technical Services
The Kansas Research and Education Network
cort at kanren.net
Office: +1-785-856-9800 x301
Mobile: +1-785-865-7206





From tedm at ipinc.net  Mon Sep 17 14:51:41 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 17 Sep 2007 11:51:41 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B00107DA0E@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <NABBJOELMNGNJNGPKDDOAENLHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>michael.dillon at bt.com
>Sent: Monday, September 17, 2007 11:15 AM
>To: ppml at arin.net
>Subject: Re: [ppml] IPv6 flawed?
>
>
>
>> Firewalls are common and plentiful in that WAN/LAN all run by 
>> these different fiefdoms and they all use large access lists 
>> with hard-coded host numbers in them.  There is really not 
>> one single person - in my humble opinion - who knows all 
>> about all applications on the network and all servers and who 
>> all is supposed to be using them.  The typical MO to setup a 
>> worker bee in the organization can involve discussions with 
>> tens of different admins to get access to all the stuff the 
>> person needs.
>
>And every single one of those devices needs to be CHANGED in order to
>convert it to IPv6. At the time of conversion (or preferably during the
>audit preceding conversion) it makes sense to try and get some control
>over these ACLs to facilitate renumbering.
>

I agree.  However I think you missed the part where I said that the
network is organized - a misuse of the term organized if I ever
heard of one - into a set of fiefdoms, and the powers that be
like it that way.

What this means is that UNLESS the board of directors empowers
the CIO to tell every last group in the organization that they
are going to do it this way or the highway, then a conversion is
simply going to muck it up worse than it is now.  You think it is
bad when 2 IPv4 networks use back-to-back NAT to communicate within
that org - just wait til you have 2 fiefdoms switched to IPv6
and a fiefdom that is used to connect the 2 that refuses to
switch to IPv6, and the 2 IPv6 fiefdoms now want to send IPv6
to each other.

I very strongly suspect with LHS that if they ever had to go
to IPv6 to get internet connectivity, that they will just put in
proxies.  I fully expect that their internal net will be IPv4
long after most companies have switched.  Forunately, my doctor
doesen't work in that company. ;-)

>Of course, one solution is to not convert certain devices to IPv6 but
>just live with the IPv4 stuff that works. When those networks become
>isolated IPv4 islands in an IPv6 network, it will never again be
>necessary to renumber the IPv4 interfaces.
>
>> For the people that talk about IPv6 renumbering like you just 
>> flip a switch and change the prefix in the router, may I 
>> humbly suggest you are out of your fricking mind. 
>
>The people who tell you to renumber this way, also point out how they
>planned and prepared from the time they were first installing their
>network. The real lesson, is not that IPv6 networks can be renumbered at
>a flick of a switch, but that building renumberability in from the
>start, makes it very easy to do. Also, note that IPv6 requires two
>switch flicks. One to turn on the new prefix, and the other to turn off
>the old prefix after a delay of days or weeks. 
>
>During those interim weeks, you could probably renumber the firewalls
>one by one.
>

At least half the firewalls simply aren't even required.  They exist
for political reasons - to justify someone's position in the company.
A doctor group in that company may have their own IT group because
they always had one, or because they are primma-donnas who think the
normal desktop support people aren't fast enough, or because they
think it's a badge of status like a marked parking spot, or because
they think they make so much money for the company that they can
do what they want, and they just like sticking it to authority.
And I couldn't renumber those firewalls because I would have to
convince every admin in charge of them that renumbering was necessary -
and if they didn't understand IPv6 they likely would not do it.

Seriously, if LHS came to me and asked me to organize a renumber I
would not do it unless I got 20 million bucks up front that would
be forfeited to me if they did not uphold their end of the contract -
and I would have written in to the contract that I could tell
any IT person or user in the company that they had to follow my
IT guidelines or figure out how to do their jobs without benefit
of connectivity to the network.  No, on second thought, make that
200 million bucks.  It would have to be large enough to be
noticed by the stockholders.  20 million is pocket change for that
company.

Without that kind of big stick, that network could not ever be
organized. Even the CEO
and chairman of the board of that company don't have that big of
a stick.

>IPv6 is *NOT* just IPv4 with more bits. It works differently and
>seemingly small differences have larger knock-on effects.
>

For companies like LHS that are 2 steps away from network anarchy,
IPv6 will come just like all other network upgrades on that network
come - in bits and pieces, here and there on their network.  It will
not be organized.  But it will serve to perpetuate the beaucracy
and the people who have manufactured positions in that org for
themselves will continue to have their positions.

Ted


From cort at kanren.net  Mon Sep 17 14:56:15 2007
From: cort at kanren.net (Cort Buffington)
Date: Mon, 17 Sep 2007 13:56:15 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOAENLHDAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOAENLHDAA.tedm@ipinc.net>
Message-ID: <6A0CF8DD-8A0B-47AC-81E6-78B8917C368D@kanren.net>

Concerning the example organization we're talking about (which is  
typical of the large healthcare networks we have encountered -- for  
some reason healthcare seems to really struggle): Their problems are  
organizational, not technical. They will not be solved with an  
network layer protocol.

On Sep 17, 2007, at 1:51 PM, Ted Mittelstaedt wrote:

>
>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On  
>> Behalf Of
>> michael.dillon at bt.com
>> Sent: Monday, September 17, 2007 11:15 AM
>> To: ppml at arin.net
>> Subject: Re: [ppml] IPv6 flawed?
>>
>>
>>
>>> Firewalls are common and plentiful in that WAN/LAN all run by
>>> these different fiefdoms and they all use large access lists
>>> with hard-coded host numbers in them.  There is really not
>>> one single person - in my humble opinion - who knows all
>>> about all applications on the network and all servers and who
>>> all is supposed to be using them.  The typical MO to setup a
>>> worker bee in the organization can involve discussions with
>>> tens of different admins to get access to all the stuff the
>>> person needs.
>>
>> And every single one of those devices needs to be CHANGED in order to
>> convert it to IPv6. At the time of conversion (or preferably  
>> during the
>> audit preceding conversion) it makes sense to try and get some  
>> control
>> over these ACLs to facilitate renumbering.
>>
>
> I agree.  However I think you missed the part where I said that the
> network is organized - a misuse of the term organized if I ever
> heard of one - into a set of fiefdoms, and the powers that be
> like it that way.
>
> What this means is that UNLESS the board of directors empowers
> the CIO to tell every last group in the organization that they
> are going to do it this way or the highway, then a conversion is
> simply going to muck it up worse than it is now.  You think it is
> bad when 2 IPv4 networks use back-to-back NAT to communicate within
> that org - just wait til you have 2 fiefdoms switched to IPv6
> and a fiefdom that is used to connect the 2 that refuses to
> switch to IPv6, and the 2 IPv6 fiefdoms now want to send IPv6
> to each other.
>
> I very strongly suspect with LHS that if they ever had to go
> to IPv6 to get internet connectivity, that they will just put in
> proxies.  I fully expect that their internal net will be IPv4
> long after most companies have switched.  Forunately, my doctor
> doesen't work in that company. ;-)
>
>> Of course, one solution is to not convert certain devices to IPv6 but
>> just live with the IPv4 stuff that works. When those networks become
>> isolated IPv4 islands in an IPv6 network, it will never again be
>> necessary to renumber the IPv4 interfaces.
>>
>>> For the people that talk about IPv6 renumbering like you just
>>> flip a switch and change the prefix in the router, may I
>>> humbly suggest you are out of your fricking mind.
>>
>> The people who tell you to renumber this way, also point out how they
>> planned and prepared from the time they were first installing their
>> network. The real lesson, is not that IPv6 networks can be  
>> renumbered at
>> a flick of a switch, but that building renumberability in from the
>> start, makes it very easy to do. Also, note that IPv6 requires two
>> switch flicks. One to turn on the new prefix, and the other to  
>> turn off
>> the old prefix after a delay of days or weeks.
>>
>> During those interim weeks, you could probably renumber the firewalls
>> one by one.
>>
>
> At least half the firewalls simply aren't even required.  They exist
> for political reasons - to justify someone's position in the company.
> A doctor group in that company may have their own IT group because
> they always had one, or because they are primma-donnas who think the
> normal desktop support people aren't fast enough, or because they
> think it's a badge of status like a marked parking spot, or because
> they think they make so much money for the company that they can
> do what they want, and they just like sticking it to authority.
> And I couldn't renumber those firewalls because I would have to
> convince every admin in charge of them that renumbering was  
> necessary -
> and if they didn't understand IPv6 they likely would not do it.
>
> Seriously, if LHS came to me and asked me to organize a renumber I
> would not do it unless I got 20 million bucks up front that would
> be forfeited to me if they did not uphold their end of the contract -
> and I would have written in to the contract that I could tell
> any IT person or user in the company that they had to follow my
> IT guidelines or figure out how to do their jobs without benefit
> of connectivity to the network.  No, on second thought, make that
> 200 million bucks.  It would have to be large enough to be
> noticed by the stockholders.  20 million is pocket change for that
> company.
>
> Without that kind of big stick, that network could not ever be
> organized. Even the CEO
> and chairman of the board of that company don't have that big of
> a stick.
>
>> IPv6 is *NOT* just IPv4 with more bits. It works differently and
>> seemingly small differences have larger knock-on effects.
>>
>
> For companies like LHS that are 2 steps away from network anarchy,
> IPv6 will come just like all other network upgrades on that network
> come - in bits and pieces, here and there on their network.  It will
> not be organized.  But it will serve to perpetuate the beaucracy
> and the people who have manufactured positions in that org for
> themselves will continue to have their positions.
>
> Ted
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the  
> ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
> Member Services
> Help Desk at info at arin.net if you experience any issues.
>

--
Cort Buffington
Assistant Director for Technical Services
The Kansas Research and Education Network
cort at kanren.net
Office: +1-785-856-9800 x301
Mobile: +1-785-865-7206





From bmanning at vacation.karoshi.com  Mon Sep 17 15:08:42 2007
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 17 Sep 2007 19:08:42 +0000
Subject: [ppml] Mo's Law
In-Reply-To: <52056.1190046240@sa.vix.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
	<42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
	<1F476111-95E8-4023-B367-357AA75EBD29@delong.com>
	<853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
	<52056.1190046240@sa.vix.com>
Message-ID: <20070917190842.GA3961@vacation.karoshi.com.>

On Mon, Sep 17, 2007 at 04:24:00PM +0000, Paul Vixie wrote:
> i myself was a beame and whiteside fan, though i had friends at ftp
> software and other ip-on-windows companies.  the common belief was that
> with microsoft coming 20 years late to the party, they would be an also-ran.
> (i think similar thoughts were spoken aloud when internet explored came
> out in a mostly-mosaic web community.)  hopefully a lesson was learned?

	ftp software kicked B&W to the curb... :)
`
> that lesson is, the installed base is meaningless, and how we did it before
> is meaningless, all that matters is getting growth right.
	
	Mike O'dell...  Mo's Law.  1994

--bill



From kkargel at polartel.com  Mon Sep 17 15:09:36 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Sep 2007 14:09:36 -0500
Subject: [ppml] *Spam?* Re:  IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOAENLHDAA.tedm@ipinc.net>
References: <D03E4899F2FB3D4C8464E8C76B3B68B00107DA0E@E03MVC4-UKBR.domain1.systemhost.net>
	<NABBJOELMNGNJNGPKDDOAENLHDAA.tedm@ipinc.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707493@mail>

 Ted,
	I completely hear what you are saying, and I agree that the
situation not only exists but is just as drastic as you are saying.
This is not a unique situation, and exists with distressing frequency.
	Having stipulated that, bad network design should not be a
driver for protocol specification.  Rather, a good protocol
specification should be a leading factor to good network design.  People
involved in bad networks are just going to have to bite the expensive
bullets and get their house in order some time.  For many that time will
come at meltdown, as they will refuse to spend the money until they are
boken and a crisis exists.  
	I feel sorry for the admins who will have to untangle the can of
worms, but that does not give the WG the onus for protecting their
convoluted networks.

	While I admit I'm a meanie-butt (well, it's close to polite
language), we all need to remember that the migration to IPv6 from IPv4
is a conversion, not an upgrade.  We are not simply modifying an
existing network, we arecreating or installing a new network.  The IPv6
network may overlay, and in some fashion interoperate with the IPv4
network, but they will not be merged.  
	
	Due to the hard work and due diligence of the many amazing
people involved this will be a lot less painful than it could be, but
there will necessarily be some different network architectures in place
when the dust settles.

jmho
Kevin

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Ted Mittelstaedt
> Sent: Monday, September 17, 2007 1:52 PM
> To: michael.dillon at bt.com; ppml at arin.net
> Subject: *Spam?* Re: [ppml] IPv6 flawed?
> 
> 
> 
> >-----Original Message-----
> >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On 
> Behalf Of 
> >michael.dillon at bt.com
> >Sent: Monday, September 17, 2007 11:15 AM
> >To: ppml at arin.net
> >Subject: Re: [ppml] IPv6 flawed?
> >
> >
> >
> >> Firewalls are common and plentiful in that WAN/LAN all run 
> by these 
> >> different fiefdoms and they all use large access lists with 
> >> hard-coded host numbers in them.  There is really not one single 
> >> person - in my humble opinion - who knows all about all 
> applications 
> >> on the network and all servers and who all is supposed to be using 
> >> them.  The typical MO to setup a worker bee in the 
> organization can 
> >> involve discussions with tens of different admins to get access to 
> >> all the stuff the person needs.
> >
> >And every single one of those devices needs to be CHANGED in 
> order to 
> >convert it to IPv6. At the time of conversion (or preferably 
> during the 
> >audit preceding conversion) it makes sense to try and get 
> some control 
> >over these ACLs to facilitate renumbering.
> >
> 
> I agree.  However I think you missed the part where I said 
> that the network is organized - a misuse of the term 
> organized if I ever heard of one - into a set of fiefdoms, 
> and the powers that be like it that way.
> 
> What this means is that UNLESS the board of directors 
> empowers the CIO to tell every last group in the organization 
> that they are going to do it this way or the highway, then a 
> conversion is simply going to muck it up worse than it is 
> now.  You think it is bad when 2 IPv4 networks use 
> back-to-back NAT to communicate within that org - just wait 
> til you have 2 fiefdoms switched to IPv6 and a fiefdom that 
> is used to connect the 2 that refuses to switch to IPv6, and 
> the 2 IPv6 fiefdoms now want to send IPv6 to each other.
> 
> I very strongly suspect with LHS that if they ever had to go 
> to IPv6 to get internet connectivity, that they will just put 
> in proxies.  I fully expect that their internal net will be 
> IPv4 long after most companies have switched.  Forunately, my 
> doctor doesen't work in that company. ;-)
> 
> >Of course, one solution is to not convert certain devices to 
> IPv6 but 
> >just live with the IPv4 stuff that works. When those networks become 
> >isolated IPv4 islands in an IPv6 network, it will never again be 
> >necessary to renumber the IPv4 interfaces.
> >
> >> For the people that talk about IPv6 renumbering like you 
> just flip a 
> >> switch and change the prefix in the router, may I humbly 
> suggest you 
> >> are out of your fricking mind.
> >
> >The people who tell you to renumber this way, also point out 
> how they 
> >planned and prepared from the time they were first installing their 
> >network. The real lesson, is not that IPv6 networks can be 
> renumbered 
> >at a flick of a switch, but that building renumberability in 
> from the 
> >start, makes it very easy to do. Also, note that IPv6 requires two 
> >switch flicks. One to turn on the new prefix, and the other 
> to turn off 
> >the old prefix after a delay of days or weeks.
> >
> >During those interim weeks, you could probably renumber the 
> firewalls 
> >one by one.
> >
> 
> At least half the firewalls simply aren't even required.  
> They exist for political reasons - to justify someone's 
> position in the company.
> A doctor group in that company may have their own IT group 
> because they always had one, or because they are 
> primma-donnas who think the normal desktop support people 
> aren't fast enough, or because they think it's a badge of 
> status like a marked parking spot, or because they think they 
> make so much money for the company that they can do what they 
> want, and they just like sticking it to authority.
> And I couldn't renumber those firewalls because I would have 
> to convince every admin in charge of them that renumbering 
> was necessary - and if they didn't understand IPv6 they 
> likely would not do it.
> 
> Seriously, if LHS came to me and asked me to organize a 
> renumber I would not do it unless I got 20 million bucks up 
> front that would be forfeited to me if they did not uphold 
> their end of the contract - and I would have written in to 
> the contract that I could tell any IT person or user in the 
> company that they had to follow my IT guidelines or figure 
> out how to do their jobs without benefit of connectivity to 
> the network.  No, on second thought, make that 200 million 
> bucks.  It would have to be large enough to be noticed by the 
> stockholders.  20 million is pocket change for that company.
> 
> Without that kind of big stick, that network could not ever 
> be organized. Even the CEO and chairman of the board of that 
> company don't have that big of a stick.
> 
> >IPv6 is *NOT* just IPv4 with more bits. It works differently and 
> >seemingly small differences have larger knock-on effects.
> >
> 
> For companies like LHS that are 2 steps away from network anarchy,
> IPv6 will come just like all other network upgrades on that 
> network come - in bits and pieces, here and there on their 
> network.  It will not be organized.  But it will serve to 
> perpetuate the beaucracy and the people who have manufactured 
> positions in that org for themselves will continue to have 
> their positions.
> 
> Ted
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at info at arin.net if you 
> experience any issues.
> 


From iljitsch at muada.com  Mon Sep 17 15:13:24 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Mon, 17 Sep 2007 21:13:24 +0200
Subject: [ppml] IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOCENKHDAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOCENKHDAA.tedm@ipinc.net>
Message-ID: <789BD5AB-4DE8-49D0-96DC-F5C7ADAD8887@muada.com>

On 17-sep-2007, at 20:02, Ted Mittelstaedt wrote:

[cut illuminating example]

> For the people that talk about IPv6 renumbering like you just flip a
> switch and change the prefix in the router, may I humbly suggest
> you are out of your fricking mind.

Somehow, deep within myself, I find the ability to not care much  
about the plight of these people. On the IETF list, a number of  
people have been arguing that it's possible to design an IPv6 network  
such that renumbering it is doable. Others have argued that there are  
numerous designs that make renumbering very hard.

Both are right. The questions are: how much is an organization  
prepared to pay to avoid renumbering, and how much is the community  
prepared to pay to make things such that certain organizations don't  
have to renumber? The answer to the first question is that there are  
only some 20000 organizations in the world that pay the RIR/ISP fees  
for portable address space and buy equipment and hire people to run  
BGP. The answer to the second is that the current level is widely  
considered painful but allowing PI with IPv6 shows that the pain has  
so far been bearable.


From tedm at ipinc.net  Mon Sep 17 15:51:15 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 17 Sep 2007 12:51:15 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <6A0CF8DD-8A0B-47AC-81E6-78B8917C368D@kanren.net>
Message-ID: <NABBJOELMNGNJNGPKDDOEENMHDAA.tedm@ipinc.net>


"Solved" and "eased" are two different things.  This thread wasn't
about "solving" things as I recall.

Of course, I agree the proper way to fix a mess like I outlined
is to sweep it away and start over.  I'd love to do that with a
lot of things.  When my kid spits out some nasty phrase he
learned watching some movie or TV program of course I think it
would be better if it was just swept out of his vocabulary.  But
the real world doesen't work that way as much as we want it to.

Legacy's operational problems won't be solved by IPv6 no matter
what we do to the protocol. I have full confidence that when they
do deploy IPv6 they will botch it.  They will end up with an
IPv6 network that would be as difficult to renumber as their
current IPv4 network.  Their admins know this, and so most likely
when they do renumber, they will not accept IPv6 addresses assigned
from a "local registry AKA ISP"  They aren't completely stupid
after all, at least some of the admins there do know how screwed
they really are.

Most likely they will go with RFC 4193
addresses - assuming that RFC 4193 does in fact become a standard
instead of merely a proposal - and if it doesen't, why then as I
pointed out earlier, they will just use any old addresses out of
the IPv6 address space.  To hell if its assigned to someone else
or not.  Then they will go find some vendor who will cobble together
some proprietary NAT proxy solution for them.

So, getting back to the original point of the thread - what do you
want?  I'm guessing you are of the camp that would look at Legacy
and say "screw them, they get what they deserve"

I am from the camp that has a bit more compassion.  It is no skin off
my nose if RFC 4193 is standardized or not, or if IETF standardizes IPv6
NAT or not.  It completely doesen't hurt or harm me if those standards
exist.  So, because of this, and because the existence of those things
would help make life just a bit more bearable for the poor admins that
do have to work in an environment like LHS - I don't understand how
people like you can take such a cold attitude.

After all, these things like network protocols and suchlike are mere
devices, created to make life easier for us humans.  When we start
worshipping the machine as more important than the human - which I
feel is at the base of these "network purity" religious wars - we lose
sight of what is important.

Ted


>-----Original Message-----
>From: Cort Buffington [mailto:cort at kanren.net]
>Sent: Monday, September 17, 2007 11:56 AM
>To: Ted Mittelstaedt
>Cc: michael.dillon at bt.com; ppml at arin.net
>Subject: Re: [ppml] IPv6 flawed?
>
>
>Concerning the example organization we're talking about (which is  
>typical of the large healthcare networks we have encountered -- for  
>some reason healthcare seems to really struggle): Their problems are  
>organizational, not technical. They will not be solved with an  
>network layer protocol.
>
>On Sep 17, 2007, at 1:51 PM, Ted Mittelstaedt wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On  
>>> Behalf Of
>>> michael.dillon at bt.com
>>> Sent: Monday, September 17, 2007 11:15 AM
>>> To: ppml at arin.net
>>> Subject: Re: [ppml] IPv6 flawed?
>>>
>>>
>>>
>>>> Firewalls are common and plentiful in that WAN/LAN all run by
>>>> these different fiefdoms and they all use large access lists
>>>> with hard-coded host numbers in them.  There is really not
>>>> one single person - in my humble opinion - who knows all
>>>> about all applications on the network and all servers and who
>>>> all is supposed to be using them.  The typical MO to setup a
>>>> worker bee in the organization can involve discussions with
>>>> tens of different admins to get access to all the stuff the
>>>> person needs.
>>>
>>> And every single one of those devices needs to be CHANGED in order to
>>> convert it to IPv6. At the time of conversion (or preferably  
>>> during the
>>> audit preceding conversion) it makes sense to try and get some  
>>> control
>>> over these ACLs to facilitate renumbering.
>>>
>>
>> I agree.  However I think you missed the part where I said that the
>> network is organized - a misuse of the term organized if I ever
>> heard of one - into a set of fiefdoms, and the powers that be
>> like it that way.
>>
>> What this means is that UNLESS the board of directors empowers
>> the CIO to tell every last group in the organization that they
>> are going to do it this way or the highway, then a conversion is
>> simply going to muck it up worse than it is now.  You think it is
>> bad when 2 IPv4 networks use back-to-back NAT to communicate within
>> that org - just wait til you have 2 fiefdoms switched to IPv6
>> and a fiefdom that is used to connect the 2 that refuses to
>> switch to IPv6, and the 2 IPv6 fiefdoms now want to send IPv6
>> to each other.
>>
>> I very strongly suspect with LHS that if they ever had to go
>> to IPv6 to get internet connectivity, that they will just put in
>> proxies.  I fully expect that their internal net will be IPv4
>> long after most companies have switched.  Forunately, my doctor
>> doesen't work in that company. ;-)
>>
>>> Of course, one solution is to not convert certain devices to IPv6 but
>>> just live with the IPv4 stuff that works. When those networks become
>>> isolated IPv4 islands in an IPv6 network, it will never again be
>>> necessary to renumber the IPv4 interfaces.
>>>
>>>> For the people that talk about IPv6 renumbering like you just
>>>> flip a switch and change the prefix in the router, may I
>>>> humbly suggest you are out of your fricking mind.
>>>
>>> The people who tell you to renumber this way, also point out how they
>>> planned and prepared from the time they were first installing their
>>> network. The real lesson, is not that IPv6 networks can be  
>>> renumbered at
>>> a flick of a switch, but that building renumberability in from the
>>> start, makes it very easy to do. Also, note that IPv6 requires two
>>> switch flicks. One to turn on the new prefix, and the other to  
>>> turn off
>>> the old prefix after a delay of days or weeks.
>>>
>>> During those interim weeks, you could probably renumber the firewalls
>>> one by one.
>>>
>>
>> At least half the firewalls simply aren't even required.  They exist
>> for political reasons - to justify someone's position in the company.
>> A doctor group in that company may have their own IT group because
>> they always had one, or because they are primma-donnas who think the
>> normal desktop support people aren't fast enough, or because they
>> think it's a badge of status like a marked parking spot, or because
>> they think they make so much money for the company that they can
>> do what they want, and they just like sticking it to authority.
>> And I couldn't renumber those firewalls because I would have to
>> convince every admin in charge of them that renumbering was  
>> necessary -
>> and if they didn't understand IPv6 they likely would not do it.
>>
>> Seriously, if LHS came to me and asked me to organize a renumber I
>> would not do it unless I got 20 million bucks up front that would
>> be forfeited to me if they did not uphold their end of the contract -
>> and I would have written in to the contract that I could tell
>> any IT person or user in the company that they had to follow my
>> IT guidelines or figure out how to do their jobs without benefit
>> of connectivity to the network.  No, on second thought, make that
>> 200 million bucks.  It would have to be large enough to be
>> noticed by the stockholders.  20 million is pocket change for that
>> company.
>>
>> Without that kind of big stick, that network could not ever be
>> organized. Even the CEO
>> and chairman of the board of that company don't have that big of
>> a stick.
>>
>>> IPv6 is *NOT* just IPv4 with more bits. It works differently and
>>> seemingly small differences have larger knock-on effects.
>>>
>>
>> For companies like LHS that are 2 steps away from network anarchy,
>> IPv6 will come just like all other network upgrades on that network
>> come - in bits and pieces, here and there on their network.  It will
>> not be organized.  But it will serve to perpetuate the beaucracy
>> and the people who have manufactured positions in that org for
>> themselves will continue to have their positions.
>>
>> Ted
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the  
>> ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN  
>> Member Services
>> Help Desk at info at arin.net if you experience any issues.
>>
>
>--
>Cort Buffington
>Assistant Director for Technical Services
>The Kansas Research and Education Network
>cort at kanren.net
>Office: +1-785-856-9800 x301
>Mobile: +1-785-865-7206
>
>
>
>


From tedm at ipinc.net  Mon Sep 17 15:54:44 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 17 Sep 2007 12:54:44 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <789BD5AB-4DE8-49D0-96DC-F5C7ADAD8887@muada.com>
Message-ID: <NABBJOELMNGNJNGPKDDOIENMHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: Iljitsch van Beijnum [mailto:iljitsch at muada.com]
>Sent: Monday, September 17, 2007 12:13 PM
>To: Ted Mittelstaedt
>Cc: Kevin Kargel; ppml at arin.net
>Subject: Re: [ppml] IPv6 flawed?
>
>
>On 17-sep-2007, at 20:02, Ted Mittelstaedt wrote:
>
>[cut illuminating example]
>
>> For the people that talk about IPv6 renumbering like you just flip a
>> switch and change the prefix in the router, may I humbly suggest
>> you are out of your fricking mind.
>
>Somehow, deep within myself, I find the ability to not care much  
>about the plight of these people. On the IETF list, a number of  
>people have been arguing that it's possible to design an IPv6 network  
>such that renumbering it is doable. Others have argued that there are  
>numerous designs that make renumbering very hard.
>
>Both are right. The questions are: how much is an organization  
>prepared to pay to avoid renumbering, and how much is the community  
>prepared to pay to make things such that certain organizations don't  
>have to renumber? 

These payments are wildly variable and the amounts affect the decision.

The first guy to duplicate PI and NAT with IPv6 will pay a lot.  The next
guy behind him will pay a bit less.  And so on, until the day we have
$49.95 Linksys routers for sale at Fry's that do IPv6 translation.  At
that point it is completely immaterial what the community is willing to
pay or not, to allow or disallow something, because the market will have
bypassed the community.

Ted


From tedm at ipinc.net  Mon Sep 17 16:02:40 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 17 Sep 2007 13:02:40 -0700
Subject: [ppml] *Spam?* Re:  IPv6 flawed?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066707493@mail>
Message-ID: <NABBJOELMNGNJNGPKDDOMENMHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Kevin Kargel
>Sent: Monday, September 17, 2007 12:10 PM
>To: ppml at arin.net
>Subject: Re: [ppml] *Spam?* Re: IPv6 flawed?
>
>
> Ted,
>	I completely hear what you are saying, and I agree that the
>situation not only exists but is just as drastic as you are saying.
>This is not a unique situation, and exists with distressing frequency.
>	Having stipulated that, bad network design should not be a
>driver for protocol specification.  Rather, a good protocol
>specification should be a leading factor to good network design. 

Bad network design should not LIMIT good protocol design.  But, if while
your designing your good protocol you have two different ways of doing
something, both equally good for your purposes, why would you pick the
way that causes problems for the people who have bad networks, when you
could pick the way that would be neutral to their bad networks?

I can't say one way or another if IETF has deliberately made choices
with IPv6 that make it more difficult to design an IPv6 NAT, simply for
the sake of making it more difficult to design an IPv6 NAT.  Since,
I'm not tasked with designing an IPv6 NAT and have not researched it.
But, from what some people
seem to have said in the past, an outsider would certainly draw that
conclusion.

Ted


From iljitsch at muada.com  Mon Sep 17 16:19:55 2007
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Mon, 17 Sep 2007 22:19:55 +0200
Subject: [ppml] *Spam?* Re:  IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOMENMHDAA.tedm@ipinc.net>
References: <NABBJOELMNGNJNGPKDDOMENMHDAA.tedm@ipinc.net>
Message-ID: <6A672CC7-7EB1-4AAE-A075-05EE38024CF4@muada.com>

On 17-sep-2007, at 22:02, Ted Mittelstaedt wrote:

> I can't say one way or another if IETF has deliberately made choices
> with IPv6 that make it more difficult to design an IPv6 NAT, simply  
> for
> the sake of making it more difficult to design an IPv6 NAT.  Since,
> I'm not tasked with designing an IPv6 NAT and have not researched it.
> But, from what some people
> seem to have said in the past, an outsider would certainly draw that
> conclusion.

Don't know when NAT was invented, but I'm pretty sure even if it  
existed back when IPv6 was designed it wasn't on the radar at all.

I don't believe it's harder to do NAT with IPv6 than with IPv4.  
Certainly the people who created PF didn't seem daunted by the  
prospect. But the question is: when you have IPv6 NAT, what are you  
going to do with it? I don't see people bending over backwards to  
make their applications work through IPv6 NAT like they do for IPv4  
NAT: if you don't mind NAT, you're better off sticking with IPv4. Or  
use IPv6 with a proxy, that pretty much does the same thing as NAT  
but only cleaner because the applications have to know about it.  
Bonus: you can proxy between IPv4 and IPv6.

But I believe it would actually be easier to do the whole NAT/ALG/ 
workaround thing with IPv4 because unlike with IPv4, you don't have  
to NAT from a single public address to a bunch of internal addresses,  
but you can do a 1-to-1 mapping between public and internal addresses.


From kkargel at polartel.com  Mon Sep 17 16:22:59 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Sep 2007 15:22:59 -0500
Subject: [ppml] *Spam?* Re:  IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOMENMHDAA.tedm@ipinc.net>
References: <70DE64CEFD6E9A4EB7FAF3A063141066707493@mail>
	<NABBJOELMNGNJNGPKDDOMENMHDAA.tedm@ipinc.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707498@mail>

I also agree with and support your first paragraph.  In a neutral
decision I will try to side with the more liberal postion.  I don't know
if I will go so far as to say what we were discussing was a neutral
decision.

I do believe the assumption that NAT would not be necessary was part and
parcel with the core of current IPv6 design.  I will go on to say that
any enterprise or carrier class router or firewall I know of has the
capability to do header rewriting, so whether or not there is a protocol
for NAT any technically competent admin who really wants to do it will
be able to, whether under IPv4 or IPv6.  

If they broke the ability to rewrite headers there would be a lot of
functionality besides NAT we would lose. 

Kevin

:$s/worry/happy/g 



> -----Original Message-----
> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] 
> Sent: Monday, September 17, 2007 3:03 PM
> To: Kevin Kargel; 
> Subject: RE: [ppml] *Spam?* Re: IPv6 flawed?
> 
> 
> 
> >-----Original Message-----
> >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On 
> Behalf Of 
> >Kevin Kargel
> >Sent: Monday, September 17, 2007 12:10 PM
> >To: ppml at arin.net
> >Subject: Re: [ppml] *Spam?* Re: IPv6 flawed?
> >
> >
> > Ted,
> >	I completely hear what you are saying, and I agree that 
> the situation 
> >not only exists but is just as drastic as you are saying.
> >This is not a unique situation, and exists with distressing 
> frequency.
> >	Having stipulated that, bad network design should not 
> be a driver for 
> >protocol specification.  Rather, a good protocol 
> specification should 
> >be a leading factor to good network design.
> 
> Bad network design should not LIMIT good protocol design.  
> But, if while your designing your good protocol you have two 
> different ways of doing something, both equally good for your 
> purposes, why would you pick the way that causes problems for 
> the people who have bad networks, when you could pick the way 
> that would be neutral to their bad networks?
> 
> I can't say one way or another if IETF has deliberately made 
> choices with IPv6 that make it more difficult to design an 
> IPv6 NAT, simply for the sake of making it more difficult to 
> design an IPv6 NAT.  Since, I'm not tasked with designing an 
> IPv6 NAT and have not researched it.
> But, from what some people
> seem to have said in the past, an outsider would certainly 
> draw that conclusion.
> 
> Ted
> 


From kkargel at polartel.com  Mon Sep 17 16:25:36 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Sep 2007 15:25:36 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOEENMHDAA.tedm@ipinc.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707499@mail>

Ah, but every rule and law we have in our society is more important than
the human.  The highway patrol officer doesn't care that there was
nobody else on the road when you were going 85mph completely under
control in a safe vehicle.. even if you did have a pressing need because
you didn't organize your schedule efficiently..  Granted there are
extenuating circumstances like life or limb, but I doubt being late for
your job or working more efficiently would be accepted.

It would be great if we could make a policy that said "just be good and
play nice with others" and everyone would do that..  but I don't really
expect that to work.

BTW, I personally think we owe Legacy owners something.  Those were by
and large the folks that jumped in and did the early experimenting, they
spent the big chunks of R&D money when it was expensive and paved the
way for the rest of us.  We are living in the results of their work and
dreams and adventurousness.  I think they actually deserve a little
extra consideration. So (imho) if they want to continue using the IP
space that was granted them back when nobody else cared or wanted it I
say "More power to em"..  If they are not using the space and see their
way to return it I will think nicer things about them, but I won't think
bad things if they want to keep what they have.

Kevin

:$s/worry/happy/g 





> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Ted Mittelstaedt
> Sent: Monday, September 17, 2007 2:51 PM
> To: Cort Buffington
> Cc: ppml at arin.net
> Subject: Re: [ppml] IPv6 flawed?
> 
> 
> "Solved" and "eased" are two different things.  This thread 
> wasn't about "solving" things as I recall.
> 
> Of course, I agree the proper way to fix a mess like I 
> outlined is to sweep it away and start over.  I'd love to do 
> that with a lot of things.  When my kid spits out some nasty 
> phrase he learned watching some movie or TV program of course 
> I think it would be better if it was just swept out of his 
> vocabulary.  But the real world doesen't work that way as 
> much as we want it to.
> 
> Legacy's operational problems won't be solved by IPv6 no 
> matter what we do to the protocol. I have full confidence 
> that when they do deploy IPv6 they will botch it.  They will 
> end up with an
> IPv6 network that would be as difficult to renumber as their 
> current IPv4 network.  Their admins know this, and so most 
> likely when they do renumber, they will not accept IPv6 
> addresses assigned from a "local registry AKA ISP"  They 
> aren't completely stupid after all, at least some of the 
> admins there do know how screwed they really are.
> 
> Most likely they will go with RFC 4193
> addresses - assuming that RFC 4193 does in fact become a 
> standard instead of merely a proposal - and if it doesen't, 
> why then as I pointed out earlier, they will just use any old 
> addresses out of the IPv6 address space.  To hell if its 
> assigned to someone else or not.  Then they will go find some 
> vendor who will cobble together some proprietary NAT proxy 
> solution for them.
> 
> So, getting back to the original point of the thread - what 
> do you want?  I'm guessing you are of the camp that would 
> look at Legacy and say "screw them, they get what they deserve"
> 
> I am from the camp that has a bit more compassion.  It is no 
> skin off my nose if RFC 4193 is standardized or not, or if 
> IETF standardizes IPv6 NAT or not.  It completely doesen't 
> hurt or harm me if those standards exist.  So, because of 
> this, and because the existence of those things would help 
> make life just a bit more bearable for the poor admins that 
> do have to work in an environment like LHS - I don't 
> understand how people like you can take such a cold attitude.
> 
> After all, these things like network protocols and suchlike 
> are mere devices, created to make life easier for us humans.  
> When we start worshipping the machine as more important than 
> the human - which I feel is at the base of these "network 
> purity" religious wars - we lose sight of what is important.
> 
> Ted
> 
> 
> >-----Original Message-----
> >From: Cort Buffington [mailto:cort at kanren.net]
> >Sent: Monday, September 17, 2007 11:56 AM
> >To: Ted Mittelstaedt
> >Cc: michael.dillon at bt.com; ppml at arin.net
> >Subject: Re: [ppml] IPv6 flawed?
> >
> >
> >Concerning the example organization we're talking about (which is 
> >typical of the large healthcare networks we have encountered -- for 
> >some reason healthcare seems to really struggle): Their problems are 
> >organizational, not technical. They will not be solved with 
> an network 
> >layer protocol.
> >
> >On Sep 17, 2007, at 1:51 PM, Ted Mittelstaedt wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: ppml-bounces at arin.net 
> [mailto:ppml-bounces at arin.net]On Behalf 
> >>> Of michael.dillon at bt.com
> >>> Sent: Monday, September 17, 2007 11:15 AM
> >>> To: ppml at arin.net
> >>> Subject: Re: [ppml] IPv6 flawed?
> >>>
> >>>
> >>>
> >>>> Firewalls are common and plentiful in that WAN/LAN all 
> run by these 
> >>>> different fiefdoms and they all use large access lists with 
> >>>> hard-coded host numbers in them.  There is really not one single 
> >>>> person - in my humble opinion - who knows all about all 
> >>>> applications on the network and all servers and who all 
> is supposed 
> >>>> to be using them.  The typical MO to setup a worker bee in the 
> >>>> organization can involve discussions with tens of 
> different admins 
> >>>> to get access to all the stuff the person needs.
> >>>
> >>> And every single one of those devices needs to be CHANGED 
> in order 
> >>> to convert it to IPv6. At the time of conversion (or preferably 
> >>> during the audit preceding conversion) it makes sense to 
> try and get 
> >>> some control over these ACLs to facilitate renumbering.
> >>>
> >>
> >> I agree.  However I think you missed the part where I said 
> that the 
> >> network is organized - a misuse of the term organized if I 
> ever heard 
> >> of one - into a set of fiefdoms, and the powers that be 
> like it that 
> >> way.
> >>
> >> What this means is that UNLESS the board of directors empowers the 
> >> CIO to tell every last group in the organization that they 
> are going 
> >> to do it this way or the highway, then a conversion is 
> simply going 
> >> to muck it up worse than it is now.  You think it is bad 
> when 2 IPv4 
> >> networks use back-to-back NAT to communicate within that 
> org - just 
> >> wait til you have 2 fiefdoms switched to IPv6 and a 
> fiefdom that is 
> >> used to connect the 2 that refuses to switch to IPv6, and 
> the 2 IPv6 
> >> fiefdoms now want to send IPv6 to each other.
> >>
> >> I very strongly suspect with LHS that if they ever had to 
> go to IPv6 
> >> to get internet connectivity, that they will just put in 
> proxies.  I 
> >> fully expect that their internal net will be IPv4 long after most 
> >> companies have switched.  Forunately, my doctor doesen't 
> work in that 
> >> company. ;-)
> >>
> >>> Of course, one solution is to not convert certain devices to IPv6 
> >>> but just live with the IPv4 stuff that works. When those networks 
> >>> become isolated IPv4 islands in an IPv6 network, it will 
> never again 
> >>> be necessary to renumber the IPv4 interfaces.
> >>>
> >>>> For the people that talk about IPv6 renumbering like you 
> just flip 
> >>>> a switch and change the prefix in the router, may I 
> humbly suggest 
> >>>> you are out of your fricking mind.
> >>>
> >>> The people who tell you to renumber this way, also point out how 
> >>> they planned and prepared from the time they were first 
> installing 
> >>> their network. The real lesson, is not that IPv6 networks can be 
> >>> renumbered at a flick of a switch, but that building 
> renumberability 
> >>> in from the start, makes it very easy to do. Also, note that IPv6 
> >>> requires two switch flicks. One to turn on the new 
> prefix, and the 
> >>> other to turn off the old prefix after a delay of days or weeks.
> >>>
> >>> During those interim weeks, you could probably renumber the 
> >>> firewalls one by one.
> >>>
> >>
> >> At least half the firewalls simply aren't even required.  
> They exist 
> >> for political reasons - to justify someone's position in 
> the company.
> >> A doctor group in that company may have their own IT group because 
> >> they always had one, or because they are primma-donnas who 
> think the 
> >> normal desktop support people aren't fast enough, or because they 
> >> think it's a badge of status like a marked parking spot, 
> or because 
> >> they think they make so much money for the company that 
> they can do 
> >> what they want, and they just like sticking it to authority.
> >> And I couldn't renumber those firewalls because I would have to 
> >> convince every admin in charge of them that renumbering 
> was necessary 
> >> - and if they didn't understand IPv6 they likely would not do it.
> >>
> >> Seriously, if LHS came to me and asked me to organize a renumber I 
> >> would not do it unless I got 20 million bucks up front 
> that would be 
> >> forfeited to me if they did not uphold their end of the contract - 
> >> and I would have written in to the contract that I could 
> tell any IT 
> >> person or user in the company that they had to follow my IT 
> >> guidelines or figure out how to do their jobs without benefit of 
> >> connectivity to the network.  No, on second thought, make that 200 
> >> million bucks.  It would have to be large enough to be 
> noticed by the 
> >> stockholders.  20 million is pocket change for that company.
> >>
> >> Without that kind of big stick, that network could not ever be 
> >> organized. Even the CEO and chairman of the board of that company 
> >> don't have that big of a stick.
> >>
> >>> IPv6 is *NOT* just IPv4 with more bits. It works differently and 
> >>> seemingly small differences have larger knock-on effects.
> >>>
> >>
> >> For companies like LHS that are 2 steps away from network anarchy,
> >> IPv6 will come just like all other network upgrades on 
> that network 
> >> come - in bits and pieces, here and there on their 
> network.  It will 
> >> not be organized.  But it will serve to perpetuate the 
> beaucracy and 
> >> the people who have manufactured positions in that org for 
> themselves 
> >> will continue to have their positions.
> >>
> >> Ted
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed 
> to the ARIN 
> >> Public Policy Mailing List (PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN 
> >> Member Services Help Desk at info at arin.net if you experience any 
> >> issues.
> >>
> >
> >--
> >Cort Buffington
> >Assistant Director for Technical Services The Kansas Research and 
> >Education Network cort at kanren.net
> >Office: +1-785-856-9800 x301
> >Mobile: +1-785-865-7206
> >
> >
> >
> >
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at info at arin.net if you 
> experience any issues.
> 


From owen at delong.com  Mon Sep 17 16:33:00 2007
From: owen at delong.com (Owen DeLong)
Date: Mon, 17 Sep 2007 13:33:00 -0700
Subject: [ppml] *Spam?* Re:  IPv6 flawed?
In-Reply-To: <6A672CC7-7EB1-4AAE-A075-05EE38024CF4@muada.com>
References: <NABBJOELMNGNJNGPKDDOMENMHDAA.tedm@ipinc.net>
	<6A672CC7-7EB1-4AAE-A075-05EE38024CF4@muada.com>
Message-ID: <AD1B6D32-B5CF-4FD3-9E29-15F31D16ECD2@delong.com>


On Sep 17, 2007, at 1:19 PM, Iljitsch van Beijnum wrote:

> On 17-sep-2007, at 22:02, Ted Mittelstaedt wrote:
>
>> I can't say one way or another if IETF has deliberately made choices
>> with IPv6 that make it more difficult to design an IPv6 NAT, simply
>> for
>> the sake of making it more difficult to design an IPv6 NAT.  Since,
>> I'm not tasked with designing an IPv6 NAT and have not researched it.
>> But, from what some people
>> seem to have said in the past, an outsider would certainly draw that
>> conclusion.
>
> Don't know when NAT was invented, but I'm pretty sure even if it
> existed back when IPv6 was designed it wasn't on the radar at all.
>
You're actually wrong about that.  NAT was developed very close
to the time CIDR was developed, prior to RFC-1918, back when
private addressing was initially created using RFC-1597.  The
date on RFC1597 is March, 1994.  RFC1631 addresses NAT
as early as May 1994.  The earliest IPv6 RFC I could find is
RFC 1809, June 1995.

> I don't believe it's harder to do NAT with IPv6 than with IPv4.

That's true.  It's equally broken for either protocol.

> Certainly the people who created PF didn't seem daunted by the
> prospect. But the question is: when you have IPv6 NAT, what are you
> going to do with it? I don't see people bending over backwards to
> make their applications work through IPv6 NAT like they do for IPv4

Let's hope not.

> NAT: if you don't mind NAT, you're better off sticking with IPv4. Or
> use IPv6 with a proxy, that pretty much does the same thing as NAT
> but only cleaner because the applications have to know about it.
> Bonus: you can proxy between IPv4 and IPv6.
>
This is definitely a better approach than NAT, but, still not ideal in
my opinion.

> But I believe it would actually be easier to do the whole NAT/ALG/
> workaround thing with IPv4 because unlike with IPv4, you don't have
> to NAT from a single public address to a bunch of internal addresses,
> but you can do a 1-to-1 mapping between public and internal addresses.

I'll assume that the first IPv4 should be IPv6 in this paragraph.
Ture, 1:1 NAT is more feasible in IPv6 and that could simplify a
number of the NAT workarounds vs. IPv4 where you are usually
having to deal with PAT to overload a single IP address in the
translation process.

Owen



From info at arin.net  Mon Sep 17 16:52:24 2007
From: info at arin.net (Member Services)
Date: Mon, 17 Sep 2007 16:52:24 -0400
Subject: [ppml] Revised 2007-17
In-Reply-To: <2E14E78C-06D7-49CC-9093-1385B436CF58@delong.com>
References: <2E14E78C-06D7-49CC-9093-1385B436CF58@delong.com>
Message-ID: <46EEE908.6080101@arin.net>

Policy Proposal 2007-17: Legacy Outreach and Partial Reclamation has 
been revised. This proposal is open for discussion on this mailing list 
and will be on the agenda at the upcoming ARIN Public Policy Meeting.

The current policy proposal text is provided below and is also available
at: http://www.arin.net/policy/proposals/2007_17.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

Owen DeLong wrote:
> Based on input from the AC and comments on the mailing list, I have
> decided to revise 2007-17.
> 
> Specific ideas incorporated into this proposal:
> 	1.	Specific fee statements removed.  Fees are not the realm
> 		of IRPEP, so, it is replaced with a requirement for the BoT
> 		to develop appropriate incentives.
> 
> 	2.	An oversight in the original version did not provide a
> 		timeframe in which addresses were to be returned.
> 		This version adopts a 12 month timeframe with staff
> 		discretion for up to 2 extensions of 6 months each.
> 
> 	3.	This proposal differs from the existing section 4.6 in
> 		that it places discretion over whether a subnet of
> 		a returned block may be retained or not in the hands
> 		of the address holder.  There was some suggestion
> 		from some AC members that this discretion should
> 		only be given to legacy holders while ARIN staff should
> 		retain discretion over non-legacy resources.  I do not
> 		have a strong opposition to such a change, but, I do
> 		feel that the policy is actually better as is, so, I have
> 		chosen not to add this revision.  I would like to see
> 		discussion on this area, and, if it is possible, I would
> 		like this version to allow the AC discretion to gauge
> 		consensus on whether this edit should be added
> 		prior to last call.
> 
> 
> Revised proposal is as follows:
> 
> 
> Policy Proposal 2007-17
> Legacy Outreach and Partial Reclamation
> 
> Author: Owen DeLong
> 
> Proposal Version: 1.0
> Submission Date: 2007 September 15
> 
> Proposal type: modify
> 
> Policy term: permanent
> 
> Policy statement:
> 
> Modify section 4.6 as follows:
> 
> 4.6 Amnesty Requests:
> 
> ARIN will accept the return or relinquishment of
> any address space from any existing address holder. If the address
> holder wishes to aggregate into a single block, ARIN may work with the
> address holder to arrive at an allocation or assignment which is equal
> to or smaller than the sum of their existing blocks and which best meets
> the needs of the existing holder and the community. The organization
> returning the addresses shall have 12 months from the date they receive
> their new addresses to return the addresses under this policy.  
> Organizations
> may request no more than 2 six month extensions to this time, which,
> may be granted at ARIN the discretion of ARIN staff. There shall be no
> fee for returning addresses under this policy. Further, organizations
> returning addresses under this policy shall receive the following  
> benefits:
> 
> 1. If the organization does not currently pay ARIN fees, they shall
> remain fee exempt.
> 
> 2. The BoT shall develop an incentive program to encourage such
> returns.  Such incentives may include fee reductions and/or other
> such mechanisms as the BoT deems appropriate.
> 
> 3. Any organization returning address space under this policy shall
> continue under their existing RSA or they may choose to sign the current
> RSA. For organizations which currently do not have an RSA, they may sign
> the current RSA, or, they may choose to remain without an RSA.
> 
> 4. All organizations returning space under this policy shall, if they
> meet other eligibility requirements and so request, obtain an
> appropriate IPv6 end-user assignment or ISP allocation as applicable,
> with no fees for the first 5 years. Organizations electing to receive
> IPv6 allocation/assignment under this provision must sign a current RSA
> and must agree that all of their IPv4 and ASN resources are  
> henceforth subject
> to the RSA. Organizations taking this election shall be subject to
> end-user fees for their IPv4 resources not previously under an ARIN RSA.
> If they are already an ARIN subscriber, then IPv4 resources affected by
> this process may, instead, be added to their existing subscriber
> agreement at the address holder's discretion.
> 
> Rationale:
> 
> The current amnesty policy does a nice job of facilitating aggregation,
> which was the intent when it was drafted. However, as we approach IPv4
> free-space exhaustion, the community now has an additional need to
> facilitate address reclamation.
> 
> A very high percentage of underutilized space is in the hands of legacy
> holders who currently have no benefit to joining the ARIN process.
> Further, there is an unfortunate perception that doing so will require
> force the legacy holder into certain future disadvantages. This proposal
> attempts to resolve both of those issues while also providing some
> incentive to legacy organizations to start using IPv6 resources and
> bring their IPv4 resources into the ARIN process.
> 
> This policy attempts to provide some benefit and remove most of the
> costs of making partial IPv4 returns. It also attempts to provide an
> incentive for these IPv4 holders to join the ARIN process.
> 
> It is suggested that the BoT adopt fee incentives such as the
> elimination of 2 years of ARIN fees for each /20 returned.
> 
> 
> Timetable for implementation: Immediate
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 




From dean at av8.com  Mon Sep 17 16:57:16 2007
From: dean at av8.com (Dean Anderson)
Date: Mon, 17 Sep 2007 16:57:16 -0400 (EDT)
Subject: [ppml] IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOCENKHDAA.tedm@ipinc.net>
Message-ID: <Pine.LNX.4.44.0709171620560.8401-100000@citation2.av8.net>

Ditto.  Ted nailed it.

I can also give some examples of companies (e.g. large insurance
companies) also continuing to privately use the public address space of
their former providers, unable themselves to renumber, and unwilling to
spend the money on consulting to renumber the affected turnkey offices. 
Other companies have the same problems with RFC1918 space; placing a NAT 
is something than can be done today. Fixing things the right way takes 
longer and costs more. Sometimes that means it won't get done.

I see nothing in IPv6 that makes that any easier; There are still going
to be devices that have or depend on static configuration, and therein
lies the problem.  The autoconfiguration features in IPv6 make certain
things easier, and probably makes larger networks possible with the same
staff, but it doesn't eliminate the underlying problems of altering the
static configuration of equipment.  As long as you have NVram, or a
tftpserver, or even a dhcp server with static configuration of
something, renumbering will remain a problem.

I'm not convinced that ULA is a solution, but I claim no expertise in
this subject. But the first thing that appears as a problem is: if I had
a large private network, I'd want to be able aggregate the routes.  I
could be wrong, but non-aggregation seems to mean that it will take much
longer to do OSPFv6 graph calculation on each route, and it looks
impossible to do OSPF areas with ULA.  It seems to preferable to have an
RFC1918-like space or PI space for IPv6 private networks.


Another issue occurs to me on this subject: 

It seems to me that underlying many of these arguments, people are
concerned about the growth of the DFZ, and so want PI space allocation
policy limited in order to control the size of the DFZ. Yet, nowhere in
ARIN's charter do I see DFZ size as an objective or proper purpose of
ARIN, or of IANA either.  Why shouldn't the market (the router vendors,
and the ISPs) control the DFZ size by its own cost structures?  
Clearly, ARIN can influence the size of the IPv6 DFZ by denying IPv6 PI
space but why should ARIN, rather than the market, control this?


		--Dean
		

On Mon, 17 Sep 2007, Ted Mittelstaedt wrote:

> 
> When are people going to realize that the renumbering issue
> is a big deal for some organizations, no matter whether your
> using IPv4 or IPv6, regardless of the new features in IPv6.
> 
> Renumbering isn't about just changing interfaces, folks.  For
> the sake of discussion (and since they aren't our customer anymore
> and can't do anything to us) I'll name names.  As a disclaimer
> I will say it's been a couple years since I've touched that network,
> so they may have cleaned up their act.  But, I don't believe it.
> 
> We used to work on Legacy Health Systems internal network.  For
> those of you who never had the pleasure there's literally dozens
> of IT groups under that umbrella - all very mistrustful of each other.
> There's a central numbering authority - I know his name but I
> won't make any more trouble for him - who is largely ignored
> by these groups until they do something stupid like use the same
> numbering for their networks and then want to talk to each other -
> even though he's designated as the number's Czar.  And half the
> time the solution to this was to introduce yet another NAT device
> in between the conflicting networks rather than renumbering one
> or both of them. For various 
> business/political reasons it's clearly obvious that the powers
> that be at the top like it this way.
> 
> Firewalls are common and plentiful in that WAN/LAN all run by
> these different fiefdoms and they all use large access lists with
> hard-coded host numbers in them.  There is really not one single
> person - in my humble opinion - who knows all about all applications
> on the network and all servers and who all is supposed to be using
> them.  The typical MO to setup a worker bee in the organization can
> involve discussions with tens of different admins to get access
> to all the stuff the person needs.
> 
> For the people that talk about IPv6 renumbering like you just flip a
> switch and change the prefix in the router, may I humbly suggest
> you are out of your fricking mind.  If and when Legacy ever does
> switchover to IPv6, some bird-brained admin that tried that would
> be shot as it would knock hundreds of workers offline and generate
> numerous support calls, mostly to desktop support staff who would
> have no idea what the problem was and even less on how to solve it.
> 
> And I might also add that LHS is easily large enough to qualify
> for their own IPv4 numbers let alone IPv6 - but they use RFC1918
> numbers like everyone else does - at least, all the parts of the
> network that we ever saw did.  For all I know they might have 
> public numbers widely deployed in some part of their network - not
> that most of the IT groups within would pay any attention to that.
> 
> Ted
> 
> >-----Original Message-----
> >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
> >Kevin Kargel
> >Sent: Monday, September 17, 2007 10:36 AM
> >To: ppml at arin.net
> >Subject: Re: [ppml] IPv6 flawed?
> >
> >
> > If you *could* easily renumber IP addresses not under your control
> >wouldn't that make them *under* your control?
> >
> >Kevin
> >
> >> -----Original Message-----
> >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> >> Behalf Of David Williamson
> >> Sent: Monday, September 17, 2007 11:22 AM
> >> To: Cort Buffington
> >> Cc: ppml at arin.net
> >> Subject: Re: [ppml] IPv6 flawed?
> >> 
> >> On Mon, Sep 17, 2007 at 11:08:54AM -0500, Cort Buffington wrote:
> >> > Yep, that's right. I really don't do enough meaningful 
> >> networking to 
> >> > speak up here. I should have kept my mouth shut.
> >> 
> >> I don't think that's the point.
> >> 
> >> >From the sound of it, you've managed to renumber your local 
> >> environment
> >> fairly easily.  Congrats!  It's nice to hear that someone has 
> >> had a fairly easy renumbering experience with IPv6.
> >> 
> >> Owen's point is valid, though - unless there is some 
> >> mechanism for renumbering addresses stored in places not 
> >> under your control, this isn't really any easier than with 
> >> IPv4.  For organnizations that don't utilize VPNs and don't 
> >> have their addressess embedded all over the place, the two 
> >> are mostly equivalent, although IPv6 has more natural methods 
> >> for renumbering in a fairly painless way.
> >> 
> >> Unfortunately, many orgs are not in that space, and 
> >> renumbering is hard and painful.  If there's a broad solution 
> >> to that problem space, I'd really like to hear about it.
> >> 
> >> That, I think, is the point.
> >> 
> >> -David
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to 
> >> the ARIN Public Policy Mailing List (PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> >> the ARIN Member Services Help Desk at 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 (PPML at arin.net).
> >Unsubscribe or manage your mailing list subscription at:
> >http://lists.arin.net/mailman/listinfo/ppml Please contact the 
> >ARIN Member Services
> >Help Desk at 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 (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




From vgill at vijaygill.com  Mon Sep 17 17:11:18 2007
From: vgill at vijaygill.com (vijay gill)
Date: Mon, 17 Sep 2007 14:11:18 -0700
Subject: [ppml] Mo's Law
In-Reply-To: <20070917190842.GA3961@vacation.karoshi.com.>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
	<42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
	<1F476111-95E8-4023-B367-357AA75EBD29@delong.com>
	<853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
	<52056.1190046240@sa.vix.com>
	<20070917190842.GA3961@vacation.karoshi.com.>
Message-ID: <21ef2c1c0709171411t6361df0fp874ab3910b5a1fbd@mail.gmail.com>

On 9/17/07, bmanning at vacation.karoshi.com <bmanning at vacation.karoshi.com>
wrote:
>
> On Mon, Sep 17, 2007 at 04:24:00PM +0000, Paul Vixie wrote:
> > i myself was a beame and whiteside fan, though i had friends at ftp
> > software and other ip-on-windows companies.  the common belief was that
> > with microsoft coming 20 years late to the party, they would be an
> also-ran.
> > (i think similar thoughts were spoken aloud when internet explored came
> > out in a mostly-mosaic web community.)  hopefully a lesson was learned?
>
>         ftp software kicked B&W to the curb... :)
> `
> > that lesson is, the installed base is meaningless, and how we did it
> before
> > is meaningless, all that matters is getting growth right.
>
>         Mike O'dell...  Mo's Law.  1994



I believe the quote is What installed base?
CC'ing mo for clarification

/vijay


--bill
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member
> Services
> Help Desk at info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070917/3ebb40a0/attachment.htm>

From drc at virtualized.org  Mon Sep 17 18:36:25 2007
From: drc at virtualized.org (David Conrad)
Date: Tue, 18 Sep 2007 00:36:25 +0200
Subject: [ppml] IPv6 flawed?
In-Reply-To: <46EEACAC.9050401@psg.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>	<42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>	<1F476111-95E8-4023-B367-357AA75EBD29@delong.com>	<853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
	<52056.1190046240@sa.vix.com> <46EEACAC.9050401@psg.com>
Message-ID: <E8F85772-215A-4569-8BD3-68CC9745C2D2@virtualized.org>

On Sep 17, 2007, at 6:34 PM, Randy Bush wrote:
> what is critical to ipv6 deployment is vendor support, vendor support,
> and did i mention vendor support; from the core to the edge.  with
> nat-pt + algs for dns, http, smtp, and sip.  otherwise the cost to  
> move
> to v6 is bigger than v4 nat; end of game.
>
> but this is not really the list for this.

Serious question: what's the right list?

Regards,
-drc



From randy at psg.com  Mon Sep 17 18:48:00 2007
From: randy at psg.com (Randy Bush)
Date: Mon, 17 Sep 2007 12:48:00 -1000
Subject: [ppml] IPv6 flawed?
In-Reply-To: <E8F85772-215A-4569-8BD3-68CC9745C2D2@virtualized.org>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>	<42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>	<1F476111-95E8-4023-B367-357AA75EBD29@delong.com>	<853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
	<52056.1190046240@sa.vix.com> <46EEACAC.9050401@psg.com>
	<E8F85772-215A-4569-8BD3-68CC9745C2D2@virtualized.org>
Message-ID: <46EF0420.8050707@psg.com>

>> what is critical to ipv6 deployment is vendor support, vendor support,
>> and did i mention vendor support; from the core to the edge.  with
>> nat-pt + algs for dns, http, smtp, and sip.  otherwise the cost to move
>> to v6 is bigger than v4 nat; end of game.
>> but this is not really the list for this.
> Serious question: what's the right list?

my assertion that this was the wrong one is because it's not address
allocation/management policy.

nanog would be fun :)

or reality6 at psg.com

randy


From marla.azinger at frontiercorp.com  Mon Sep 17 18:56:36 2007
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Mon, 17 Sep 2007 18:56:36 -0400
Subject: [ppml] IPv6 flawed?
Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4CA26@nyrofcs2ke2k01.corp.pvt>

I see your point.  Nanog would be good.  But the discussion can lead to policy needs and creations.

So I kinda see it as the chicken and the egg problem.

Maybe the arin discuss site would be better.  But are all members subscribed to that like they are ppml?

Marla

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Randy Bush
Sent: Monday, September 17, 2007 3:48 PM
To: David Conrad
Cc: Public Policy Mailing List
Subject: Re: [ppml] IPv6 flawed?


>> what is critical to ipv6 deployment is vendor support, vendor support,
>> and did i mention vendor support; from the core to the edge.  with
>> nat-pt + algs for dns, http, smtp, and sip.  otherwise the cost to move
>> to v6 is bigger than v4 nat; end of game.
>> but this is not really the list for this.
> Serious question: what's the right list?

my assertion that this was the wrong one is because it's not address
allocation/management policy.

nanog would be fun :)

or reality6 at psg.com

randy
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.


From kloch at kl.net  Mon Sep 17 21:15:58 2007
From: kloch at kl.net (Kevin Loch)
Date: Mon, 17 Sep 2007 21:15:58 -0400
Subject: [ppml] proposal 2007-20
Message-ID: <46EF26CE.20800@kl.net>

I would like to withdraw my 2007-20 from consideration. If the community
finds parts of it useful I recommend incorporating them into one of the
other proposals up for consideration (perhaps 2007-25).

2007-25 already addresses one of the issues (200 /48 -> 200 separate
customers).  A definition of what exactly an "existing ISP" is might
still be useful.

- Kevin


From bonomi at mail.r-bonomi.com  Mon Sep 17 21:47:22 2007
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Mon, 17 Sep 2007 20:47:22 -0500 (CDT)
Subject: [ppml] Revised Proposal -- Eliminate Lame Server Policy
Message-ID: <200709180147.l8I1lMe5015361@mail.r-bonomi.com>


> Date: Sat, 15 Sep 2007 08:51:04 -0700
> To: policy at arin.net, Public Policy Mailing List <ppml at arin.net>
> Subject: [ppml] Revised Proposal -- Eliminate Lame Server Policy
>
> Based on discussions with the AC Shepherds and input received on the
> mailing list, I am revising my Lame Server proposal.

I generally support the intent of this proposal.

I have two minor linquistic quibbles with the specific words used,
plus one substantive issue with the wording, as indicated below.


> 1.	Policy Proposal Name: Deprecate Lame Server Policy
>
> 7.	Policy statement:
> 		Replace Section 7 of the NRPM in it's entirety with the
> 		following text:
>
> 	7.	Staff action to improve ARIN public database accuracy and
> 		consistency.


Linguistic quibble:
  'Action to improve' implies that there are other "initial" actions being 
  taken with regard to `accuracy'/'consistency'.  Of which there is no 
  mention, anywhere.

Fix:
  Substitute: "actions with regard to" for the suspect phrase.

>
> 		7.1	ARIN staff shall take reasonable and practicable means to

Linguistic quibble:
  '... shall take ... means to ..." is improper usage.

Fix:
  use one of --
  "... shall employ ... means to ..."
  "... shall take ... steps to ..."
  or similar

> 			ensure and improve the accuracy of all ARIN public
> 			databases, including, but, not limited to WHOIS,
> 			delegations of the in-addr.arpa zone, and, delegations
> 			of the ip6.arpa zone.

Issue:
  A) The above language is unclear as to the scope of ativities that staff are
     expected to undertake.
     There are at least three separate 'relevant' senarios;
       1) at time of resoure allocation/assignment
       2) when a complaint of an 'error' is  received,
       3) staff-initiated "compliance checking"
  B) _If_ staff-initiated testing is included in the scope of activities,
     there needs to be a parallel  "operations" suggestion as to the basic
     parameters for that testing -- e.g., how frequently sweeps should be 
     run, how fast something that fails an initial sweep should be re-tested,
     how long a problem must persist before it is considered an "error" 
     requiring action, etc., etc.

Discussion:
  1) 'to ensure ... accuracy' clearly implies that some verification must be 
     done at the time of origial allocation/assignent.
  2) '... improve the accuracy of..." clerly implies that some investigationn
     is called for when a valid complaint is received.  
     NOTE: is it appropriate _somewhere_ to set minimum requirements for what
     constitutes a 'complaint'?  Something like "5 consecutive failures within
     a 1 week period, with minimum of 12 hours between any two checks"?
  3) Pro-ative checking is clearly authorized under this language.  It is not
     clear if the intent is to (a) mandate, (b) recommend, but not require, 
     or (c) merely 'allow for the possibility of' (as in 'when staff has 
     nothing better to do with their time.')

Suggestion:
  1) Proposed NPRM 7.1 be modified to explicitly list all the above-mentioned
     scenarios as being with the scope of this policy.

  2) the acompanying 'operational' guidelines specifies:
     a) that staff MAY perform pro-active checks at will, and SHOULD do so at 
	least quarterly.  (Rationale: staff is free to act agressively, while 
	setting 'minimum' standards.)
     b) that testing SHALL origiate from several 'unrelated' locations within 
	the ARIN region. and that any test must fail from all such points, 
	before it is concluded that that test failed.  (Rationale: to prevent 
	network connectivity issues from being mistaken as database issues.)
     c) that a failed test SHALL be repeated daily, until it has failed on 5 
	consecutive attempts.  After 5 consecutive failures, it is deemed to
	be an 'error', calling for corrective ation to be taken.  (Rationale:
	to prevent 'short-term, transient' problems from being mistaken as
	database issues.)
     d) that an 'externally generated' complaint of a database fault SHOULD 
	show at least 5 failed queries over a period of a week or more, with 
	at least 12 hours between any 2 attempts.  (Rationale: To reduce the 
	liklihood of external complaints being the result of 'short-term, 
	transient' problems, rather than being actual database errors.)
     e) that in-addr.arpa and ip6.arpa delegation checking is limited to zones
	that are a top-level component of an ARIN allocation/assigment.
	e.g., for a /14, staff checks only the 4 constituent /16 zones.
	If the /16 has been delegated to a customer, it _is_ still checked.
	Secondary zone delegations -- e.g., in this case, customers who are
	delegated 1 or more /24s -- are _not_ checked.  (Rationale: It is the 
	task of the zone owner to police sub-delegations.)
    NOTE: "Somewhere" it will be necessary to specify an objective standard
        test for determining/establishing access. 
	E.g., for a 'whois' contact, is it sufficient to verify that there is 
	functioning mail exchanger for the domain named, and that it responds
	'2xx' to a RCPT TO for the given address, or does one actally need to 
	send e-mail to the address, and make sure that it was delivered/
	received. (something similar to the closed-loop confirmation process 
	used by various mailing lists.  e.g., for rDNS, do _ALL_ the responding
	nameservers have to return the same authoritative information for that 
	zone, or is it sufficient for _one_ of them to do it?  Does the zone 
	need to contain _any_ PTR records, or is a SOA, with at least 2 NS 
	records sufficient?
      
	





From owen at delong.com  Mon Sep 17 22:04:25 2007
From: owen at delong.com (Owen DeLong)
Date: Mon, 17 Sep 2007 19:04:25 -0700
Subject: [ppml] Revised Proposal -- Eliminate Lame Server Policy
In-Reply-To: <200709180147.l8I1lMe5015361@mail.r-bonomi.com>
References: <200709180147.l8I1lMe5015361@mail.r-bonomi.com>
Message-ID: <6FE0D25E-3B8D-4CC7-B08E-59730D41AE56@delong.com>


On Sep 17, 2007, at 6:47 PM, Robert Bonomi wrote:

>
>> Date: Sat, 15 Sep 2007 08:51:04 -0700
>> To: policy at arin.net, Public Policy Mailing List <ppml at arin.net>
>> Subject: [ppml] Revised Proposal -- Eliminate Lame Server Policy
>>
>> Based on discussions with the AC Shepherds and input received on the
>> mailing list, I am revising my Lame Server proposal.
>
> I generally support the intent of this proposal.
>
> I have two minor linquistic quibbles with the specific words used,
> plus one substantive issue with the wording, as indicated below.
>
>
>> 1.	Policy Proposal Name: Deprecate Lame Server Policy
>>
>> 7.	Policy statement:
>> 		Replace Section 7 of the NRPM in it's entirety with the
>> 		following text:
>>
>> 	7.	Staff action to improve ARIN public database accuracy and
>> 		consistency.
>
>
> Linguistic quibble:
>   'Action to improve' implies that there are other "initial"  
> actions being
>   taken with regard to `accuracy'/'consistency'.  Of which there is no
>   mention, anywhere.
>
Not at all.  Action to improve implies that the existing accuracy of  
such
databases has room for improvement which requires action.

> Fix:
>   Substitute: "actions with regard to" for the suspect phrase.
>
The problem with this is that it allows for actions whether they improve
or degrade the database.  Clearly, the intent of the policy is to  
improve
the accuracy of the databases, and, as such, I think that preserving
the existing wording is preferable.

>>
>> 		7.1	ARIN staff shall take reasonable and practicable means to
>
> Linguistic quibble:
>   '... shall take ... means to ..." is improper usage.
>
> Fix:
>   use one of --
>   "... shall employ ... means to ..."
>   "... shall take ... steps to ..."
>   or similar
>
I'll take your word for it, and, I have no issue with any of the
choices presented.

>> 			ensure and improve the accuracy of all ARIN public
>> 			databases, including, but, not limited to WHOIS,
>> 			delegations of the in-addr.arpa zone, and, delegations
>> 			of the ip6.arpa zone.
>
> Issue:
>   A) The above language is unclear as to the scope of ativities  
> that staff are
>      expected to undertake.
>      There are at least three separate 'relevant' senarios;
>        1) at time of resoure allocation/assignment
>        2) when a complaint of an 'error' is  received,
>        3) staff-initiated "compliance checking"

Yes.  The intent is to move these decisions out of the public policy  
process
and place them where they belong in the staff operational procedures
domain.  As such, it is fully expected that this policy would result  
in the
development of several operational guidelines by the ARIN staff and
management to implement the policy in each of those areas mentioned.

>   B) _If_ staff-initiated testing is included in the scope of  
> activities,
>      there needs to be a parallel  "operations" suggestion as to  
> the basic
>      parameters for that testing -- e.g., how frequently sweeps  
> should be
>      run, how fast something that fails an initial sweep should be  
> re-tested,
>      how long a problem must persist before it is considered an  
> "error"
>      requiring action, etc., etc.
>
Yes... There are already some of these going through the ACSP, and,
I expect there will be more, both ACSP and Staff initiated.

> Discussion:
>   1) 'to ensure ... accuracy' clearly implies that some  
> verification must be
>      done at the time of origial allocation/assignent.
>   2) '... improve the accuracy of..." clerly implies that some  
> investigationn
>      is called for when a valid complaint is received.
>      NOTE: is it appropriate _somewhere_ to set minimum  
> requirements for what
>      constitutes a 'complaint'?  Something like "5 consecutive  
> failures within
>      a 1 week period, with minimum of 12 hours between any two  
> checks"?
>   3) Pro-ative checking is clearly authorized under this language.   
> It is not
>      clear if the intent is to (a) mandate, (b) recommend, but not  
> require,
>      or (c) merely 'allow for the possibility of' (as in 'when  
> staff has
>      nothing better to do with their time.')
>
Heh... Spelling quibble:  I presume you mean Pro-active checking.

All of the above are intended.  As to the specifics of item 3, it is
intended to be somewhat left to the discretion of staff and management
to implement the best process based on community input and
knowledge of the situation.  If the community feels that staff needs
additional direction in this area, the ACSP is an excellent tool
to further fine-tune the process.

> Suggestion:
>   1) Proposed NPRM 7.1 be modified to explicitly list all the above- 
> mentioned
>      scenarios as being with the scope of this policy.
>
>   2) the acompanying 'operational' guidelines specifies:
>      a) that staff MAY perform pro-active checks at will, and  
> SHOULD do so at
> 	least quarterly.  (Rationale: staff is free to act agressively, while
> 	setting 'minimum' standards.)
>      b) that testing SHALL origiate from several 'unrelated'  
> locations within
> 	the ARIN region. and that any test must fail from all such points,
> 	before it is concluded that that test failed.  (Rationale: to prevent
> 	network connectivity issues from being mistaken as database issues.)
>      c) that a failed test SHALL be repeated daily, until it has  
> failed on 5
> 	consecutive attempts.  After 5 consecutive failures, it is deemed to
> 	be an 'error', calling for corrective ation to be taken.  (Rationale:
> 	to prevent 'short-term, transient' problems from being mistaken as
> 	database issues.)
>      d) that an 'externally generated' complaint of a database  
> fault SHOULD
> 	show at least 5 failed queries over a period of a week or more, with
> 	at least 12 hours between any 2 attempts.  (Rationale: To reduce the
> 	liklihood of external complaints being the result of 'short-term,
> 	transient' problems, rather than being actual database errors.)
>      e) that in-addr.arpa and ip6.arpa delegation checking is  
> limited to zones
> 	that are a top-level component of an ARIN allocation/assigment.
> 	e.g., for a /14, staff checks only the 4 constituent /16 zones.
> 	If the /16 has been delegated to a customer, it _is_ still checked.
> 	Secondary zone delegations -- e.g., in this case, customers who are
> 	delegated 1 or more /24s -- are _not_ checked.  (Rationale: It is the
> 	task of the zone owner to police sub-delegations.)
>     NOTE: "Somewhere" it will be necessary to specify an objective  
> standard
>         test for determining/establishing access.
> 	E.g., for a 'whois' contact, is it sufficient to verify that there is
> 	functioning mail exchanger for the domain named, and that it responds
> 	'2xx' to a RCPT TO for the given address, or does one actally need to
> 	send e-mail to the address, and make sure that it was delivered/
> 	received. (something similar to the closed-loop confirmation process
> 	used by various mailing lists.  e.g., for rDNS, do _ALL_ the  
> responding
> 	nameservers have to return the same authoritative information for  
> that
> 	zone, or is it sufficient for _one_ of them to do it?  Does the zone
> 	need to contain _any_ PTR records, or is a SOA, with at least 2 NS
> 	records sufficient?
>
Yes.  It is the firm belief of the author that all of this belongs  
squarely in
the hands of the staff and management at ARIN and the should this policy
be adopted, such documentation would be forthcoming within a reasonable
time. Further, the author believes that the ACSP provides a sufficient
mechanism for the community to provide additional guidance to staff.
The author does, however, believe that such operational guidelines need
to be published and that ARIN does not currently have a good mechanism
for doing so.  Author is, in parallel working with ARIN in hopes of
creating such a framework, but, this work is outside of the IRPEP.

This is definitely _NOT_ a fire-and-forget policy.  It is an attempt  
to move the
focus of these efforts to the ACSP and ARIN staff while allowing the  
process
to be improved without the full weight and overhead of the IRPEP for  
every
detail.  The intent being to facilitate better and more responsive  
action by
ARIN staff in all of the above cases rather than to in any way reduce  
any
such existing efforts.

Owen



From ppml at rsuc.gweep.net  Mon Sep 17 21:27:48 2007
From: ppml at rsuc.gweep.net (Joe Provo)
Date: Mon, 17 Sep 2007 21:27:48 -0400
Subject: [ppml] Mo's Law
In-Reply-To: <21ef2c1c0709171411t6361df0fp874ab3910b5a1fbd@mail.gmail.com>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt>
	<42C4191E-9DFE-4D7F-9A5F-310D53C7F043@kanren.net>
	<1F476111-95E8-4023-B367-357AA75EBD29@delong.com>
	<853C7C4A-95AA-4AA4-8514-09C44DC1A53A@kanren.net>
	<52056.1190046240@sa.vix.com>
	<20070917190842.GA3961@vacation.karoshi.com.>
	<21ef2c1c0709171411t6361df0fp874ab3910b5a1fbd@mail.gmail.com>
Message-ID: <20070918012748.GA89242@gweep.net>

On Mon, Sep 17, 2007 at 02:11:18PM -0700, vijay gill wrote:
> On 9/17/07, bmanning at vacation.karoshi.com <bmanning at vacation.karoshi.com>
> wrote:
[snip]
> >         Mike O'dell...  Mo's Law.  1994
> 
> I believe the quote is What installed base?
> CC'ing mo for clarification

Uh "The only problem is scale; all other problems inherit from that."

-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE


From mcr at xdsinc.net  Tue Sep 18 10:58:00 2007
From: mcr at xdsinc.net (mcr at xdsinc.net)
Date: Tue, 18 Sep 2007 10:58:00 -0400
Subject: [ppml] ULA
In-Reply-To: <46EEC4DA.40806@psg.com> 
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><39278.1190043128@sa.vix.com>
	<3241FDB1-9567-4EC0-ACA6-C5FA8494D4C7@muada.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066707489@mail>
	<46EEC0FA.3080007@internap.com> <46EEC4DA.40806@psg.com>
Message-ID: <20070918145806.91D831444C1@smtp2.arin.net>

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


>>>>> "Randy" == Randy Bush <randy at psg.com> writes:
    >> All ULA space (L, C, G, or whatever) will come out of a single /7, which 
    >> should be route-filtered on all DFZ routers.

    Randy> the problem is the same old site local problem, what is a border.  this
    Randy> is exacerbated in ula-c by expecting conversation between 'private'
    Randy> spaces.  so you will have semi-permeable borders.  so i share part of my
    Randy> space with my vendor to the left, part with my customers to my right,
    Randy> and ...

  Randy, but you missed the point.
  The ULA proposal should say that all routers, everywhere, should
filter ULA/7 space --- by this I mean, blackhole route, not ACL. (Plus
ingress filtering on source IPs)

  Then, when you want to have semi-permeable borders, you permit
specific /32 or /48s through.  This is MUCH easier than with site-local
addresses, because the router is assured that it doesn't have the same
site-local address on two interfaces.

  Further, the reason I don't like rfc4193 for use in other than ad-hoc
networks is that a third party can't tell who an address belongs to. So,
when you *do* get:

    Randy> can you say "massive misconfiguration and leakage" three times quickly?

  you can use whois to find out who it belongs to.
  In the absense of ULA-Vixie (which letter is your's Paul?), people
like me are going to ask for PI space. (Thank you to those who offered
me a /48 out of their assignment, btw)

- -- 
Michael Richardson <mcr at xdsinc.net>
XDS Inc, Ottawa, ON             
Personal: http://www.sandelman.ca/mcr/ 



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

iQDVAwUBRu/ndu0sRu40D6vCAQKgMgX+M5b/lk1dCiWhhBXfDOPTp7OoWRyzFxjh
n5e6qqnXMNPldUCTI+oxL9L1DNs7dVbUh6vPHxDevJbcwCx29EA8XP8BTUSLktZf
Zpcs5IdA5cSN9elAoZVaUq4bPpJOdG+GthSCAqRgcQ3Eqt8RY7MD3LLvDclHppy0
55H4jL9mUiKLhuOCQ86VdmLY+rhrAI3GEkHzDF7slNqzRbgqYodJgckd+q+QD6KU
/jnlfx4Pq461MVP/D6fCAc3x6Iac4gNr
=jeIi
-----END PGP SIGNATURE-----


From randy at psg.com  Tue Sep 18 11:01:24 2007
From: randy at psg.com (Randy Bush)
Date: Tue, 18 Sep 2007 05:01:24 -1000
Subject: [ppml] ULA
In-Reply-To: <20070918145806.91D831444C1@smtp2.arin.net>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><39278.1190043128@sa.vix.com>	<3241FDB1-9567-4EC0-ACA6-C5FA8494D4C7@muada.com>	<70DE64CEFD6E9A4EB7FAF3A063141066707489@mail>	<46EEC0FA.3080007@internap.com>
	<46EEC4DA.40806@psg.com>
	<20070918145806.91D831444C1@smtp2.arin.net>
Message-ID: <46EFE844.9040907@psg.com>

>   In the absense of ULA-Vixie (which letter is your's Paul?), people
> like me are going to ask for PI space. (Thank you to those who offered
> me a /48 out of their assignment, btw)

go for it.  what is the difference to me?  you use it privately, i will
not see it.  you use it publicly, i will.  big whoopiedoo.

randy


From michael.dillon at bt.com  Tue Sep 18 11:16:37 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 18 Sep 2007 16:16:37 +0100
Subject: [ppml] ULA
In-Reply-To: <20070918145806.91D831444C1@smtp2.arin.net>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><39278.1190043128@sa.vix.com><3241FDB1-9567-4EC0-ACA6-C5FA8494D4C7@muada.com><70DE64CEFD6E9A4EB7FAF3A063141066707489@mail><46EEC0FA.3080007@internap.com>
	<46EEC4DA.40806@psg.com>
	<20070918145806.91D831444C1@smtp2.arin.net>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B0010D6FC8@E03MVC4-UKBR.domain1.systemhost.net>

>   The ULA proposal should say that all routers, everywhere, 
> should filter ULA/7 space --- by this I mean, blackhole 
> route, not ACL. (Plus ingress filtering on source IPs)

It is not ARIN's business to tell ISPs what they should or should not do
in their routers.

However, it is the IETF's business to say such things, and lo and
behold, what do we find here in RFC 4193, section 4.1 Routing?

   The default behavior of exterior routing protocol sessions between
   administrative routing regions must be to ignore receipt of and not
   advertise prefixes in the FC00::/7 block.  A network operator may
   specifically configure prefixes longer than FC00::/7 for inter-site
   communication.

Golly gee!
Right there where it belongs

>   you can use whois to find out who it belongs to.
>   In the absense of ULA-Vixie (which letter is your's Paul?), 
> people like me are going to ask for PI space. (Thank you to 
> those who offered me a /48 out of their assignment, btw)

Interesting. Not only can you register your RFC 4193 ULA address in this
global registry:
http://www.sixxs.net/tools/grh/ula/
You could also ask a friend at a smaller ISP to give you a /48 from
their vast allocation. With so many ways to skin a cat, it is clear that
ARIN doesn't need to worry about it from a policy point of view.

--Michael Dillon


From owen at delong.com  Tue Sep 18 11:23:33 2007
From: owen at delong.com (Owen DeLong)
Date: Tue, 18 Sep 2007 08:23:33 -0700
Subject: [ppml] ULA
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B0010D6FC8@E03MVC4-UKBR.domain1.systemhost.net>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><39278.1190043128@sa.vix.com><3241FDB1-9567-4EC0-ACA6-C5FA8494D4C7@muada.com><70DE64CEFD6E9A4EB7FAF3A063141066707489@mail><46EEC0FA.3080007@internap.com>
	<46EEC4DA.40806@psg.com>
	<20070918145806.91D831444C1@smtp2.arin.net>
	<D03E4899F2FB3D4C8464E8C76B3B68B0010D6FC8@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <084443B2-7FBB-4E72-841E-7CAD0DEA9BF6@delong.com>

>
> Interesting. Not only can you register your RFC 4193 ULA address in  
> this
> global registry:
> http://www.sixxs.net/tools/grh/ula/
> You could also ask a friend at a smaller ISP to give you a /48 from
> their vast allocation. With so many ways to skin a cat, it is clear  
> that
> ARIN doesn't need to worry about it from a policy point of view.
>
Yes and no.

I agree that ARIN doesn't need to make policy with regard to ULA.   
However, I
do think that the situation above makes it pretty clear that we  
either need
a good universal PI policy going forward, or, the IPv6 swamp will,  
instead,
be built out of ULA and randomly distributed /48s and /64s.

Organizations need portable addressing.  Eventually, the internet is  
going to
have to simply solve the scaling problems associated with the current
interdomain routing paradigm.  I believe this will require a paradigm  
shift
most likely involving some form of ID/Locator split.

I propose a relatively light-weight and backwards compatible mechanism
here:  http://www.delong.com/IPRouting

I welcome comments on it.

However, my fear is that as long as the IETF and router vendors believe
they can get away with extending the current paradigm, efforts to truly
resolve this issue will be delayed until it approaches a crisis.  At  
that
point, it will probably be too late to take graceful action in time.

Owen



From mcr at xdsinc.net  Tue Sep 18 11:25:40 2007
From: mcr at xdsinc.net (mcr at xdsinc.net)
Date: Tue, 18 Sep 2007 11:25:40 -0400
Subject: [ppml] ULA
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B0010D6FC8@E03MVC4-UKBR.domain1.systemhost.net>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><39278.1190043128@sa.vix.com><3241FDB1-9567-4EC0-ACA6-C5FA8494D4C7@muada.com><70DE64CEFD6E9A4EB7FAF3A063141066707489@mail><46EEC0FA.3080007@internap.com>
	<46EEC4DA.40806@psg.com>
	<20070918145806.91D831444C1@smtp2.arin.net>
	<D03E4899F2FB3D4C8464E8C76B3B68B0010D6FC8@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <20070918152542.1D2DF144635@smtp2.arin.net>

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


>>>>> "michael" == michael dillon <michael.dillon at bt.com> writes:
    michael> Interesting. Not only can you register your RFC 4193 ULA address in this
    michael> global registry:
    michael> http://www.sixxs.net/tools/grh/ula/

  Cool. I didn't know that it also provided a whois.
  Is it linked in to the rest of the network, or do I have to know to
ask whois.sixxs.net when I see a ULA prefix?
  I don't see a delegation for c.f.ip6.arpa.

  Do you think that ICANN could be convinced to delegate that to
sixxs.net as well?

    michael> You could also ask a friend at a smaller ISP to give you a /48 from
    michael> their vast allocation. With so many ways to skin a cat, it is clear that
    michael> ARIN doesn't need to worry about it from a policy point of view.

  I am growing fonder of ULA, even straight rfc4193 ULA.
  But, I'm not completely convinced yet.

- -- 
Michael Richardson <mcr at xdsinc.net>
XDS Inc, Ottawa, ON             
Personal: http://www.sandelman.ca/mcr/ 


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

iQDVAwUBRu/t8e0sRu40D6vCAQJmpAX/aGx34ec4lhbDnXWp4VnyaJAY6VDPfUeF
BHMTxv4xd5DQRG0gJdbdrjCmLmQ5o/BLZS8xBH2g6q3gkXtbvY5hWvU+62oYUpEO
MPI4vF1wQIgEn9ZVDUZw87q5oZUbu0+ERYj29hNo4u4N+GGPmfrUT2XAguVHoLl1
i/D+Rhs+f7ZQGX3ckUtAXO0Q2t5KUf+MyyTjRPiAVujWSmVGH1ldp53U4eEB3R/6
ClEKTKwBz49a931ffB/PmN8B2rIQgOgn
=5Wk+
-----END PGP SIGNATURE-----


From paul at vix.com  Tue Sep 18 13:38:34 2007
From: paul at vix.com (Paul Vixie)
Date: Tue, 18 Sep 2007 17:38:34 +0000
Subject: [ppml] ULA
In-Reply-To: Your message of "Tue, 18 Sep 2007 11:25:40 -0400."
	<20070918152542.1D2DF144635@smtp2.arin.net> 
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><39278.1190043128@sa.vix.com><3241FDB1-9567-4EC0-ACA6-C5FA8494D4C7@muada.com><70DE64CEFD6E9A4EB7FAF3A063141066707489@mail><46EEC0FA.3080007@internap.com>
	<46EEC4DA.40806@psg.com>
	<20070918145806.91D831444C1@smtp2.arin.net>
	<D03E4899F2FB3D4C8464E8C76B3B68B0010D6FC8@E03MVC4-UKBR.domain1.systemhost.net>
	<20070918152542.1D2DF144635@smtp2.arin.net> 
Message-ID: <41435.1190137114@sa.vix.com>

>   Do you think that ICANN could be convinced to delegate that to
> sixxs.net as well?

that would be great.


From info at arin.net  Tue Sep 18 14:27:27 2007
From: info at arin.net (Member Services)
Date: Tue, 18 Sep 2007 14:27:27 -0400
Subject: [ppml] proposal 2007-20
In-Reply-To: <46EF26CE.20800@kl.net>
References: <46EF26CE.20800@kl.net>
Message-ID: <46F0188F.5030708@arin.net>

Policy Proposal 2007-20 has been withdrawn by the author.

The proposal text has been archived at:
http://www.arin.net/policy/proposals/2007_20.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


Kevin Loch wrote:
> I would like to withdraw my 2007-20 from consideration. If the community
> finds parts of it useful I recommend incorporating them into one of the
> other proposals up for consideration (perhaps 2007-25).
> 
> 2007-25 already addresses one of the issues (200 /48 -> 200 separate
> customers).  A definition of what exactly an "existing ISP" is might
> still be useful.
> 
> - Kevin
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 



From dean at av8.com  Tue Sep 18 15:14:11 2007
From: dean at av8.com (Dean Anderson)
Date: Tue, 18 Sep 2007 15:14:11 -0400 (EDT)
Subject: [ppml] IPv6 flawed?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066707499@mail>
Message-ID: <Pine.LNX.4.44.0709181307030.12663-100000@citation2.av8.net>

On Mon, 17 Sep 2007, Kevin Kargel wrote:

> Ah, but every rule and law we have in our society is more important than
> the human.  The highway patrol officer doesn't care that there was
> nobody else on the road when you were going 85mph completely under
> control in a safe vehicle.. even if you did have a pressing need because
> you didn't organize your schedule efficiently..  Granted there are
> extenuating circumstances like life or limb, but I doubt being late for
> your job or working more efficiently would be accepted.

I think you misunderstand. These laws are created to protect the
human(s): The person and occupants driving at unsafely high speeds that
put themselves and others at risk of serious injury.  In the midwest,
highway speed speed limits _are_ higher. SD has 75mph, with a $5 fine
and no points for the first 5 mph over.  Montana has 80mph. These areas
of the midwest are flat, straight, are well maintained, have good
signage, and largely unpopulated with large safety margins. High speeds
there are not very dangerous to the driver or other occupants. By
contrast, the roads in say, New England, hardly have a straight section,
are often poorly maintained, have poor signage, and don't have safety
margins to contain accidents to the roadway.  New England roads are
barely safe at any speed.  Putting race tires on a BMW or Corvette
changes nothing.

The highway patrolman does not care that the _speeder_ thought it was
safe: The speeder isn't qualified to pass judgment on the safety of the
highway.  Others who were qualified, decided it was unsafe at those
speeds. And of course, speed limits were reduced in the 70's not for
safety (at least not primarilly for safety), but for fuel efficiency so
to reduce dependence on foreign oil. This is also a social policy that
benefits society.

Your example provides a good metaphor for the differences between
craft/operations and engineering for ISPs. Operations people sometimes
like to "speed", and because they don't immediately "crash", they assert
that it was therefore "safe", just like the guy in the 'vette.  But an
engineering person comes along, 'does the math', and like the civil
engineer for the highway, calculates that the practice is "unsafe", and
that a rule against that practice should be adopted.

It would be ridiculous for the speeder to say:

  "I'm an experienced driver, and I think it is safe at 85mph. I don't
  care what the civil engineer calculated, or policy required".

It would also be ridiculous for the operations people to say,
essentially:

  "I'm an experienced administrator and I believe differently, and I 
  don't need any facts to justify my belief. I'm going to tell other
  people it is safe, and hide the reasons that it isn't safe (with
  hardball tactics)."

It seems entirely ridiculous, but I have actually experienced operations
people really saying such things (at the IETF even!---Well, I should add
those were NANOG/Vixie-associated operations/craftspeople. That group
has a greater propensity for such statements.)

Of course, such incredible statements make more sense when you realize
they will make a great deal of money on the unreliable practice, or will
ingratiate themselves to their cronys (who can then act later in
conflict of interest).  But just like the speeder, they are still often
not qualified to make those decisions, regardless of how many "cars they
have operated". Belief and faith does not refute science and math.  
Belief motivated by money and cronyism is especially dubious.

Good social policy requires honesty and integrity, and solid technical
analysis of the impacts and cost/benefits.  People play nice until some
person or group figures out a way to screw the others and make a lot of
money for doing so.  No one plays "hardball" for the hell of it;  they
have motivation: money and cronyism.  Tort law, the Law of Agency, the
Law of Corporations, Associations and Groups, the Law of Trusts stands
against this anti-social behavior, and provides definitions of
obligations, proper conduct, misconduct, and legal procedures for
reparation and redress.  But there are often simpler ways to fix things.
That things need to be fixed is certain once you can identify people
playing hardball, or behaving dishonestly, or benefiting from a conflict
of interest. Cronyism by itself may not be that bad, but it is certain
to be bad when it is mixed with these other things, especially money.

> It would be great if we could make a policy that said "just be good and
> play nice with others" and everyone would do that..  but I don't really
> expect that to work.

You can work against those who don't have honesty and integrity; those
who play hardball, behave dishonestly, and benefit from conflict of
interest.  Resist corruption, even if you benefit from it; _especially_
if you benefit from it.  Ignoring corruption just allows things to get
worse. Be patient; don't expect results overnight. Shining a light onto
corruption has always, and will always, prevail eventually.

But policy implies policing, and that requires some introduction to law
and justice. Civil society can't work without some kind of coercion and
penalty. Laws are not suggestions.  But coercion and penalty must be
consistent with the laws and constitutions.  Coercion that is
inconsistent with laws and constitutions is unjust and is simply a form
of warlordism or gang rule; things that civil society must oppose as a
first order of business.

> BTW, I personally think we owe Legacy owners something.  Those were by
> and large the folks that jumped in and did the early experimenting,
> they spent the big chunks of R&D money when it was expensive and paved
> the way for the rest of us.  We are living in the results of their
> work and dreams and adventurousness.  I think they actually deserve a
> little extra consideration. So (imho) if they want to continue using
> the IP space that was granted them back when nobody else cared or
> wanted it I say "More power to em"..  If they are not using the space
> and see their way to return it I will think nicer things about them,
> but I won't think bad things if they want to keep what they have.

Thanks for the sentiment.  I think legacy holders always appreciate
recognition of their efforts. However, more significant than recognition
is that legacy's already have a license or lease agreement with the
government that ARIN isn't authorized to break. ARIN is just the latest
agent of the government, maintaining the government records that SRI and
Network Solutions previously maintained.

Let me give you another example: Many states have leased toll roads to
private companies. The private companies get to set and collect tolls,
and in return must maintain the roads. But they do not _own_ the roads,
and they cannot interrupt legacy buried or overhead cables which have a
previous permanent or unexpired right-of-way agreement.  The state
governments can put someone else in charge, or do it themselves, again.
Likewise, ARIN can be replaced, just like SRI and Netsol were previously
replaced.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




From kkargel at polartel.com  Tue Sep 18 15:34:36 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 18 Sep 2007 14:34:36 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <Pine.LNX.4.44.0709181307030.12663-100000@citation2.av8.net>
References: <70DE64CEFD6E9A4EB7FAF3A063141066707499@mail>
	<Pine.LNX.4.44.0709181307030.12663-100000@citation2.av8.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667074BA@mail>

 Now that is patently untrue..  I got a speeding ticket in South Dakota
last year for 79 mph on the interstate and it cost me $73.  Agreed that
penalties are adjusted to the severity of the condition, but the Officer
is still not going to let you off because you say you need to go fast to
make your job more efficient.

As for the rest, I think you actually reinforced my point.  Thanks.

So far as I know, Legacy owners have no license from "the government"..
there is no piece of paper from "the government" giving them rights.
Maybe I am wrong, but I have not heard of such a document.  

I have already said that the Legacy owners need to be able to retain
what they have, if they choose to do so.

Yes ARIN can be replaced, as can any agreement ever made.  Look at most
of the treaties entered in to between the US and another governance.

Kevin


> -----Original Message-----
> From: Dean Anderson [mailto:dean at av8.com] 
> Sent: Tuesday, September 18, 2007 2:14 PM
> To: Kevin Kargel
> Cc: 
> Subject: Re: [ppml] IPv6 flawed?
> 
> On Mon, 17 Sep 2007, Kevin Kargel wrote:
> 
> > Ah, but every rule and law we have in our society is more important 
> > than the human.  The highway patrol officer doesn't care that there 
> > was nobody else on the road when you were going 85mph 
> completely under 
> > control in a safe vehicle.. even if you did have a pressing need 
> > because you didn't organize your schedule efficiently..  
> Granted there 
> > are extenuating circumstances like life or limb, but I doubt being 
> > late for your job or working more efficiently would be accepted.
> 
> I think you misunderstand. These laws are created to protect the
> human(s): The person and occupants driving at unsafely high 
> speeds that put themselves and others at risk of serious 
> injury.  In the midwest, highway speed speed limits _are_ 
> higher. SD has 75mph, with a $5 fine and no points for the 
> first 5 mph over.  Montana has 80mph. These areas of the 
> midwest are flat, straight, are well maintained, have good 
> signage, and largely unpopulated with large safety margins. 
> High speeds there are not very dangerous to the driver or 
> other occupants. By contrast, the roads in say, New England, 
> hardly have a straight section, are often poorly maintained, 
> have poor signage, and don't have safety margins to contain 
> accidents to the roadway.  New England roads are barely safe 
> at any speed.  Putting race tires on a BMW or Corvette 
> changes nothing.
> 
> The highway patrolman does not care that the _speeder_ thought it was
> safe: The speeder isn't qualified to pass judgment on the 
> safety of the highway.  Others who were qualified, decided it 
> was unsafe at those speeds. And of course, speed limits were 
> reduced in the 70's not for safety (at least not primarilly 
> for safety), but for fuel efficiency so to reduce dependence 
> on foreign oil. This is also a social policy that benefits society.
> 
> Your example provides a good metaphor for the differences 
> between craft/operations and engineering for ISPs. Operations 
> people sometimes like to "speed", and because they don't 
> immediately "crash", they assert that it was therefore 
> "safe", just like the guy in the 'vette.  But an engineering 
> person comes along, 'does the math', and like the civil 
> engineer for the highway, calculates that the practice is 
> "unsafe", and that a rule against that practice should be adopted.
> 
> It would be ridiculous for the speeder to say:
> 
>   "I'm an experienced driver, and I think it is safe at 85mph. I don't
>   care what the civil engineer calculated, or policy required".
> 
> It would also be ridiculous for the operations people to say,
> essentially:
> 
>   "I'm an experienced administrator and I believe differently, and I
>   don't need any facts to justify my belief. I'm going to tell other
>   people it is safe, and hide the reasons that it isn't safe (with
>   hardball tactics)."
> 
> It seems entirely ridiculous, but I have actually experienced 
> operations people really saying such things (at the IETF 
> even!---Well, I should add those were NANOG/Vixie-associated 
> operations/craftspeople. That group has a greater propensity 
> for such statements.)
> 
> Of course, such incredible statements make more sense when 
> you realize they will make a great deal of money on the 
> unreliable practice, or will ingratiate themselves to their 
> cronys (who can then act later in conflict of interest).  But 
> just like the speeder, they are still often not qualified to 
> make those decisions, regardless of how many "cars they have 
> operated". Belief and faith does not refute science and math.  
> Belief motivated by money and cronyism is especially dubious.
> 
> Good social policy requires honesty and integrity, and solid 
> technical analysis of the impacts and cost/benefits.  People 
> play nice until some person or group figures out a way to 
> screw the others and make a lot of money for doing so.  No 
> one plays "hardball" for the hell of it;  they have 
> motivation: money and cronyism.  Tort law, the Law of Agency, 
> the Law of Corporations, Associations and Groups, the Law of 
> Trusts stands against this anti-social behavior, and provides 
> definitions of obligations, proper conduct, misconduct, and 
> legal procedures for reparation and redress.  But there are 
> often simpler ways to fix things.
> That things need to be fixed is certain once you can identify 
> people playing hardball, or behaving dishonestly, or 
> benefiting from a conflict of interest. Cronyism by itself 
> may not be that bad, but it is certain to be bad when it is 
> mixed with these other things, especially money.
> 
> > It would be great if we could make a policy that said "just be good 
> > and play nice with others" and everyone would do that..  
> but I don't 
> > really expect that to work.
> 
> You can work against those who don't have honesty and 
> integrity; those who play hardball, behave dishonestly, and 
> benefit from conflict of interest.  Resist corruption, even 
> if you benefit from it; _especially_ if you benefit from it.  
> Ignoring corruption just allows things to get worse. Be 
> patient; don't expect results overnight. Shining a light onto 
> corruption has always, and will always, prevail eventually.
> 
> But policy implies policing, and that requires some 
> introduction to law and justice. Civil society can't work 
> without some kind of coercion and penalty. Laws are not 
> suggestions.  But coercion and penalty must be consistent 
> with the laws and constitutions.  Coercion that is 
> inconsistent with laws and constitutions is unjust and is 
> simply a form of warlordism or gang rule; things that civil 
> society must oppose as a first order of business.
> 
> > BTW, I personally think we owe Legacy owners something.  
> Those were by 
> > and large the folks that jumped in and did the early experimenting, 
> > they spent the big chunks of R&D money when it was 
> expensive and paved 
> > the way for the rest of us.  We are living in the results of their 
> > work and dreams and adventurousness.  I think they actually 
> deserve a 
> > little extra consideration. So (imho) if they want to 
> continue using 
> > the IP space that was granted them back when nobody else cared or 
> > wanted it I say "More power to em"..  If they are not using 
> the space 
> > and see their way to return it I will think nicer things 
> about them, 
> > but I won't think bad things if they want to keep what they have.
> 
> Thanks for the sentiment.  I think legacy holders always 
> appreciate recognition of their efforts. However, more 
> significant than recognition is that legacy's already have a 
> license or lease agreement with the government that ARIN 
> isn't authorized to break. ARIN is just the latest agent of 
> the government, maintaining the government records that SRI 
> and Network Solutions previously maintained.
> 
> Let me give you another example: Many states have leased toll 
> roads to private companies. The private companies get to set 
> and collect tolls, and in return must maintain the roads. But 
> they do not _own_ the roads, and they cannot interrupt legacy 
> buried or overhead cables which have a previous permanent or 
> unexpired right-of-way agreement.  The state governments can 
> put someone else in charge, or do it themselves, again.
> Likewise, ARIN can be replaced, just like SRI and Netsol were 
> previously replaced.
> 
> 		--Dean
> 
> -- 
> Av8 Internet   Prepared to pay a premium for better service?
> www.av8.net         faster, more reliable, better service
> 617 344 9000   
> 
> 
> 


From dean at av8.com  Tue Sep 18 16:47:25 2007
From: dean at av8.com (Dean Anderson)
Date: Tue, 18 Sep 2007 16:47:25 -0400 (EDT)
Subject: [ppml] IPv6 flawed?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410667074BA@mail>
Message-ID: <Pine.LNX.4.44.0709181627170.12663-100000@citation2.av8.net>

On Tue, 18 Sep 2007, Kevin Kargel wrote:

>  Now that is patently untrue..  I got a speeding ticket in South Dakota
> last year for 79 mph on the interstate and it cost me $73.  

I didn't say that the entire interstate system in SD had a 75mph posted
speed limit. Just that some parts did. Try I90 west of Mitchell. I also
suppose they could have changed the speed limit since I was last there.
The speed limits also slow down near and though cities, so it depends on
where you got the ticket.

> Agreed that penalties are adjusted to the severity of the condition,
> but the Officer is still not going to let you off because you say you
> need to go fast to make your job more efficient.

Of course not. But it isn't because they don't care about the human, as
you originally stated. Its just the opposite; its because they do care
about the human.

> As for the rest, I think you actually reinforced my point.  Thanks.

You are welcome.  I think we agree on the facts, but not the principles
behind the facts.

> So far as I know, Legacy owners have no license from "the government"..
> there is no piece of paper from "the government" giving them rights.
> Maybe I am wrong, but I have not heard of such a document.  

There is indeed a piece of paper, and ARIN keeps it in a book.  
Registrations were originally by paper and mail.  I suppose you
young'uns don't know what those are. We also didn't have cell phones
back that, and numeric pagers were "cool", unless you had to carry one
for work.

> I have already said that the Legacy owners need to be able to retain
> what they have, if they choose to do so.

And I, for one, appreciate that.

> Yes ARIN can be replaced, as can any agreement ever made.  Look at most
> of the treaties entered in to between the US and another governance.

Certainly, any agreement can be changed with the consent of both
parties.  However, ARIN doesn't have to consent not to be the registrar
anymore.  That can be dictated by DoC/IANA.  I think perhaps it might be
a good idea to change registrar's again, just so that people don't
forget that its a possibility.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




From kkargel at polartel.com  Tue Sep 18 17:11:22 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 18 Sep 2007 16:11:22 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <Pine.LNX.4.44.0709181627170.12663-100000@citation2.av8.net>
References: <70DE64CEFD6E9A4EB7FAF3A0631410667074BA@mail>
	<Pine.LNX.4.44.0709181627170.12663-100000@citation2.av8.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667074BE@mail>

 
> > So far as I know, Legacy owners have no license from "the 
> government"..
> > there is no piece of paper from "the government" giving them rights.
> > Maybe I am wrong, but I have not heard of such a document.  
> 
> There is indeed a piece of paper, and ARIN keeps it in a book.  
> Registrations were originally by paper and mail.  I suppose 
> you young'uns don't know what those are. We also didn't have 
> cell phones back that, and numeric pagers were "cool", unless 
> you had to carry one for work.
> 

But that piece of paper is not from a "government".  ARIN is not a
governmental agency or department, they are not paid through tax
dollars, they do not carry the "force of law".  I still maintain that
legacy holders hold no license from any government to the use of those
numbers.  I also still maintain that we should let them continue to use
them, but because it is right, not because it would be illegal to do
otherwise.

KEvin


From bmanning at vacation.karoshi.com  Tue Sep 18 20:05:53 2007
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 19 Sep 2007 00:05:53 +0000
Subject: [ppml] ULA
In-Reply-To: <41435.1190137114@sa.vix.com>
References: <46EEC4DA.40806@psg.com>
	<20070918145806.91D831444C1@smtp2.arin.net>
	<D03E4899F2FB3D4C8464E8C76B3B68B0010D6FC8@E03MVC4-UKBR.domain1.systemhost.net>
	<20070918152542.1D2DF144635@smtp2.arin.net>
	<41435.1190137114@sa.vix.com>
Message-ID: <20070919000553.GB13936@vacation.karoshi.com.>

 so paul... do you mind that the IETF creates a new RIR?

--bill


On Tue, Sep 18, 2007 at 05:38:34PM +0000, Paul Vixie wrote:
> >   Do you think that ICANN could be convinced to delegate that to
> > sixxs.net as well?
> 
> that would be great.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.


From paul at vix.com  Tue Sep 18 21:03:37 2007
From: paul at vix.com (Paul Vixie)
Date: Wed, 19 Sep 2007 01:03:37 +0000
Subject: [ppml] ULA
In-Reply-To: Your message of "Wed, 19 Sep 2007 00:05:53 GMT."
	<20070919000553.GB13936@vacation.karoshi.com.> 
References: <46EEC4DA.40806@psg.com>
	<20070918145806.91D831444C1@smtp2.arin.net>
	<D03E4899F2FB3D4C8464E8C76B3B68B0010D6FC8@E03MVC4-UKBR.domain1.systemhost.net>
	<20070918152542.1D2DF144635@smtp2.arin.net>
	<41435.1190137114@sa.vix.com>
	<20070919000553.GB13936@vacation.karoshi.com.> 
Message-ID: <48530.1190163817@sa.vix.com>

>  so paul... do you mind that the IETF creates a new RIR?

i didn't, and don't, see delegation of the ULA IN-ADDR space as semantically
similar to creating a new RIR.  i would mind IETF creating RIRs, since there
is a working existing process for same and IETF isn't part of that process.

for lurkers here, i'd like to explain in more detail.  bmanning does not see
"the internet" as a static entity in the way it's often described.  to bill,
what "the internet" is depends on where you connect to it, what routing
policy you have, what routing policy other people have, what's up or down at
the moment, and what time of the day, week, year, or century it then is.  i
struggled for a long decade or so to reconcile the common "newtonian" view
with bill's "relativistic" view, and i'm convinced that bill's perception is
a useful one to keep in mind while contemplating internet-related topics.

but knowing this helps understand the context of bmanning's question above:
from bill's point of view, ULA as registered at SIXXS.NET would be just as
much part of "the internet" as any PI or PA space ever was.  outlawing ULA
in "the core" would be a meaningless act in bill's world view, since it's
already the case that a lot of non-ULA space is in common every day use but
never appears in "the core".

my answer, in that context, is that i see a difference between ULA+SIXXS and
PA/PI since one is allowed in "the core" and one is not, and i therefore do
not think that delegating the ULA in-addr prefix to SIXXS would create an RIR.

i hope this helps understand what would otherwise be a very terse exchange.


From randy at psg.com  Tue Sep 18 21:21:22 2007
From: randy at psg.com (Randy Bush)
Date: Tue, 18 Sep 2007 15:21:22 -1000
Subject: [ppml] ULA
In-Reply-To: <48530.1190163817@sa.vix.com>
References: <46EEC4DA.40806@psg.com>	<20070918145806.91D831444C1@smtp2.arin.net>	<D03E4899F2FB3D4C8464E8C76B3B68B0010D6FC8@E03MVC4-UKBR.domain1.systemhost.net>	<20070918152542.1D2DF144635@smtp2.arin.net>	<41435.1190137114@sa.vix.com>	<20070919000553.GB13936@vacation.karoshi.com.>
	<48530.1190163817@sa.vix.com>
Message-ID: <46F07992.20902@psg.com>

> my answer, in that context, is that i see a difference between ULA+SIXXS and
> PA/PI since one is allowed in "the core" and one is not

and rfc 1918 space does not leak

i gotta go with bif here

randy


From dean at av8.com  Tue Sep 18 21:34:00 2007
From: dean at av8.com (Dean Anderson)
Date: Tue, 18 Sep 2007 21:34:00 -0400 (EDT)
Subject: [ppml] IPv6 flawed?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410667074BE@mail>
Message-ID: <Pine.LNX.4.44.0709182100150.12663-100000@citation2.av8.net>

On Tue, 18 Sep 2007, Kevin Kargel wrote:

> > > So far as I know, Legacy owners have no license from "the 
> > government"..
> > > there is no piece of paper from "the government" giving them rights.
> > > Maybe I am wrong, but I have not heard of such a document.  
> > 
> > There is indeed a piece of paper, and ARIN keeps it in a book.  
> > Registrations were originally by paper and mail.  I suppose 
> > you young'uns don't know what those are. We also didn't have 
> > cell phones back that, and numeric pagers were "cool", unless 
> > you had to carry one for work.
> > 
> 
> But that piece of paper is not from a "government".  ARIN is not a
> governmental agency or department,

The legacy paper is not from ARIN. It is from SRI, or NetSol, on behalf
of the government.  The government told SRI to give the records to
NetSol. SRI didn't invent that transfer. Then the G. told NetSol to give
the records to ARIN. NetSol didn't invent that.  The G. can tell ARIN to
give the records to someone else.  The records don't belong to ARIN.
ARIN is just the administrator.

The 'paper', electronic records of delegation, you get from ARIN is on
behalf of the government. The RSA terms are different from the legacy
terms.  Even within the ARIN RSA regime, there are different sets of
terms, as the court found in the Kremen case: It found 3 different sets
of terms that Kremen could accept.

> they are not paid through tax dollars, they do not carry the "force of
> law".

ARIN doesn't have to be a goverment agency 'paid by tax dollars with
force of law' to administer government records. Many government
activities are paid directly through fees to private contractors, as the
toll road operation example demonstrates.  The government has long used
private contractors to perform some functions for the government, and
the practice is increasing. The lack of tax dollars and force of law
does not prove your claim that the records are the private property of
ARIN and that ARIN can do with them as it pleases.

BTW, some government agencies paid by tax dollars don't have 'force of
law' (NIST comes to mind as an example of that)

The records are government records, licenses/leases, that ARIN maintains
and administers and in return collects fees. Just like the toll road
operator maintains the road and in return collects fees.

> I still maintain that legacy holders hold no license from any
> government to the use of those numbers.

You seem to have no facts to support that argument, and what facts there
are, contradict that view.

> I also still maintain that we should let them continue to use them,
> but because it is right, not because it would be illegal to do
> otherwise.

It is right. And it is also illegal to do otherwise (well, illegal isn't
the precisely correct word. It violates the legal rights of the legacy
in the license/lease to do otherwise; 'illegal' usually suggests there
is a law that would be violated by doing so, which isn't the case)

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




From bmanning at vacation.karoshi.com  Tue Sep 18 22:17:30 2007
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 19 Sep 2007 02:17:30 +0000
Subject: [ppml] ULA
In-Reply-To: <48530.1190163817@sa.vix.com>
References: <46EEC4DA.40806@psg.com>
	<20070918145806.91D831444C1@smtp2.arin.net>
	<D03E4899F2FB3D4C8464E8C76B3B68B0010D6FC8@E03MVC4-UKBR.domain1.systemhost.net>
	<20070918152542.1D2DF144635@smtp2.arin.net>
	<41435.1190137114@sa.vix.com>
	<20070919000553.GB13936@vacation.karoshi.com.>
	<48530.1190163817@sa.vix.com>
Message-ID: <20070919021730.GB14208@vacation.karoshi.com.>

 thats an interesting take on my world view... but i would
 not be so bold as to put words in your mouth.  thoughts in
 your mind - sure. you should preface your remarks w/ "I think" 
 when you describe my thoughts/views to leave yourself enough 
 wiggle room when you turn out to be wrong.

 that said, if ICANN delegates the c.f.ip6.arpa to a private
 organization who's sole job is to act as a "title office" -
 then that group becomes a global scale RIR in fact.  Just
 because you don't see it (closing your eyes won't help) 
 does not remove that reality.

 and so - i am uncomfortable with the IETF creating, ex nilo,
 a functional RIR outside the existing system.

--bill


On Wed, Sep 19, 2007 at 01:03:37AM +0000, Paul Vixie wrote:
> >  so paul... do you mind that the IETF creates a new RIR?
> 
> i didn't, and don't, see delegation of the ULA IN-ADDR space as semantically
> similar to creating a new RIR.  i would mind IETF creating RIRs, since there
> is a working existing process for same and IETF isn't part of that process.
> 
> for lurkers here, i'd like to explain in more detail.  bmanning does not see
> "the internet" as a static entity in the way it's often described.  to bill,
> what "the internet" is depends on where you connect to it, what routing
> policy you have, what routing policy other people have, what's up or down at
> the moment, and what time of the day, week, year, or century it then is.  i
> struggled for a long decade or so to reconcile the common "newtonian" view
> with bill's "relativistic" view, and i'm convinced that bill's perception is
> a useful one to keep in mind while contemplating internet-related topics.
> 
> but knowing this helps understand the context of bmanning's question above:
> from bill's point of view, ULA as registered at SIXXS.NET would be just as
> much part of "the internet" as any PI or PA space ever was.  outlawing ULA
> in "the core" would be a meaningless act in bill's world view, since it's
> already the case that a lot of non-ULA space is in common every day use but
> never appears in "the core".
> 
> my answer, in that context, is that i see a difference between ULA+SIXXS and
> PA/PI since one is allowed in "the core" and one is not, and i therefore do
> not think that delegating the ULA in-addr prefix to SIXXS would create an RIR.
> 
> i hope this helps understand what would otherwise be a very terse exchange.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.


From randy at psg.com  Tue Sep 18 22:21:35 2007
From: randy at psg.com (Randy Bush)
Date: Tue, 18 Sep 2007 16:21:35 -1000
Subject: [ppml] ULA
In-Reply-To: <20070919021730.GB14208@vacation.karoshi.com.>
References: <46EEC4DA.40806@psg.com>	<20070918145806.91D831444C1@smtp2.arin.net>	<D03E4899F2FB3D4C8464E8C76B3B68B0010D6FC8@E03MVC4-UKBR.domain1.systemhost.net>	<20070918152542.1D2DF144635@smtp2.arin.net>	<41435.1190137114@sa.vix.com>	<20070919000553.GB13936@vacation.karoshi.com.>	<48530.1190163817@sa.vix.com>
	<20070919021730.GB14208@vacation.karoshi.com.>
Message-ID: <46F087AF.3070001@psg.com>

>  and so - i am uncomfortable with the IETF creating, ex nilo,
>  a functional RIR outside the existing system.

it's the ivtf making ops decisions while having negligible ops clue.
every year or two they have to be beat back with a hammer.  remember
tla, nla, ...?  grrrr.

randy


From kkargel at polartel.com  Wed Sep 19 09:43:26 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 19 Sep 2007 08:43:26 -0500
Subject: [ppml] ULA
In-Reply-To: <48530.1190163817@sa.vix.com>
References: <46EEC4DA.40806@psg.com><20070918145806.91D831444C1@smtp2.arin.net><D03E4899F2FB3D4C8464E8C76B3B68B0010D6FC8@E03MVC4-UKBR.domain1.systemhost.net><20070918152542.1D2DF144635@smtp2.arin.net><41435.1190137114@sa.vix.com><20070919000553.GB13936@vacation.karoshi.com.>
	<48530.1190163817@sa.vix.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667074C5@mail>

 Paul,

	Please pardon me for interjecting, but aren't both Newtonian and
Relatavistic views concurrently existing modes depending on your point
of origin?

	It seems to me that looking at "the internet" from high in the
cloud would necessarily present a Newtonian landscape, while looking out
through the porthole of foo.bar will present the more volatile
Relativistic view. 

	Keeping both modes in mind when considering strategies is tough,
but necessary.

	Thanks for taking the time to explain, and for your obvious
efforts to work with the community.

Kevin

:$s/worry/happy/g 




> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Paul Vixie
> Sent: Tuesday, September 18, 2007 8:04 PM
> To: 
> Subject: Re: [ppml] ULA
> 
> >  so paul... do you mind that the IETF creates a new RIR?
> 
> i didn't, and don't, see delegation of the ULA IN-ADDR space 
> as semantically similar to creating a new RIR.  i would mind 
> IETF creating RIRs, since there is a working existing process 
> for same and IETF isn't part of that process.
> 
> for lurkers here, i'd like to explain in more detail.  
> bmanning does not see "the internet" as a static entity in 
> the way it's often described.  to bill, what "the internet" 
> is depends on where you connect to it, what routing policy 
> you have, what routing policy other people have, what's up or 
> down at the moment, and what time of the day, week, year, or 
> century it then is.  i struggled for a long decade or so to 
> reconcile the common "newtonian" view with bill's 
> "relativistic" view, and i'm convinced that bill's perception 
> is a useful one to keep in mind while contemplating 
> internet-related topics.
> 
> but knowing this helps understand the context of bmanning's 
> question above:
> from bill's point of view, ULA as registered at SIXXS.NET 
> would be just as much part of "the internet" as any PI or PA 
> space ever was.  outlawing ULA in "the core" would be a 
> meaningless act in bill's world view, since it's already the 
> case that a lot of non-ULA space is in common every day use 
> but never appears in "the core".
> 
> my answer, in that context, is that i see a difference 
> between ULA+SIXXS and PA/PI since one is allowed in "the 
> core" and one is not, and i therefore do not think that 
> delegating the ULA in-addr prefix to SIXXS would create an RIR.
> 
> i hope this helps understand what would otherwise be a very 
> terse exchange.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at info at arin.net if you 
> experience any issues.
> 


From kkargel at polartel.com  Wed Sep 19 09:53:10 2007
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 19 Sep 2007 08:53:10 -0500
Subject: [ppml] IPv6 flawed?
In-Reply-To: <Pine.LNX.4.44.0709182100150.12663-100000@citation2.av8.net>
References: <70DE64CEFD6E9A4EB7FAF3A0631410667074BE@mail>
	<Pine.LNX.4.44.0709182100150.12663-100000@citation2.av8.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667074C6@mail>

I still have a hard time with this..  ARIN serves a wide area..  far
wider than just the United States or Canada..  which government are you
referencing that is giving ARIN authority and control?  Which
governmental agency is on the documents you refer to?

 

> -----Original Message-----
> From: Dean Anderson [mailto:dean at av8.com] 
> Sent: Tuesday, September 18, 2007 8:34 PM
> To: Kevin Kargel
> Cc: 
> Subject: RE: [ppml] IPv6 flawed?
> 
> On Tue, 18 Sep 2007, Kevin Kargel wrote:
> 
> > > > So far as I know, Legacy owners have no license from "the
> > > government"..
> > > > there is no piece of paper from "the government" giving 
> them rights.
> > > > Maybe I am wrong, but I have not heard of such a document.  
> > > 
> > > There is indeed a piece of paper, and ARIN keeps it in a book.  
> > > Registrations were originally by paper and mail.  I suppose you 
> > > young'uns don't know what those are. We also didn't have 
> cell phones 
> > > back that, and numeric pagers were "cool", unless you had 
> to carry 
> > > one for work.
> > > 
> > 
> > But that piece of paper is not from a "government".  ARIN is not a 
> > governmental agency or department,
> 
> The legacy paper is not from ARIN. It is from SRI, or NetSol, 
> on behalf of the government.  The government told SRI to give 
> the records to NetSol. SRI didn't invent that transfer. Then 
> the G. told NetSol to give the records to ARIN. NetSol didn't 
> invent that.  The G. can tell ARIN to give the records to 
> someone else.  The records don't belong to ARIN.
> ARIN is just the administrator.
> 
> The 'paper', electronic records of delegation, you get from 
> ARIN is on behalf of the government. The RSA terms are 
> different from the legacy terms.  Even within the ARIN RSA 
> regime, there are different sets of terms, as the court found 
> in the Kremen case: It found 3 different sets of terms that 
> Kremen could accept.
> 
> > they are not paid through tax dollars, they do not carry 
> the "force of 
> > law".
> 
> ARIN doesn't have to be a goverment agency 'paid by tax 
> dollars with force of law' to administer government records. 
> Many government activities are paid directly through fees to 
> private contractors, as the toll road operation example 
> demonstrates.  The government has long used private 
> contractors to perform some functions for the government, and 
> the practice is increasing. The lack of tax dollars and force 
> of law does not prove your claim that the records are the 
> private property of ARIN and that ARIN can do with them as it pleases.
> 
> BTW, some government agencies paid by tax dollars don't have 
> 'force of law' (NIST comes to mind as an example of that)
> 
> The records are government records, licenses/leases, that 
> ARIN maintains and administers and in return collects fees. 
> Just like the toll road operator maintains the road and in 
> return collects fees.
> 
> > I still maintain that legacy holders hold no license from any 
> > government to the use of those numbers.
> 
> You seem to have no facts to support that argument, and what 
> facts there are, contradict that view.
> 
> > I also still maintain that we should let them continue to use them, 
> > but because it is right, not because it would be illegal to do 
> > otherwise.
> 
> It is right. And it is also illegal to do otherwise (well, 
> illegal isn't the precisely correct word. It violates the 
> legal rights of the legacy in the license/lease to do 
> otherwise; 'illegal' usually suggests there is a law that 
> would be violated by doing so, which isn't the case)
> 
> 		--Dean
> 
> -- 
> Av8 Internet   Prepared to pay a premium for better service?
> www.av8.net         faster, more reliable, better service
> 617 344 9000   
> 
> 
> 


From info at arin.net  Wed Sep 19 11:15:13 2007
From: info at arin.net (Member Services)
Date: Wed, 19 Sep 2007 11:15:13 -0400
Subject: [ppml] ARIN XX: Act Now and Save Money!
Message-ID: <46F13D01.7040201@arin.net>

ARIN looks forward to your participation at the ARIN XX Public Policy 
and Members Meeting, taking place 17-19 October 2007, in Albuquerque, 
New Mexico. Register today to take advantage of the early registration 
fee of $100. It increases to $150 on 3 October.

The meeting will take place at the Hyatt Regency Albuquerque. ARIN XX 
attendees are eligible for a special room rate of $158 (USD), based on 
availability, if reservations are made before 24 September.

Hotel and travel information, meeting registration, and agenda details, 
are available through http://www.arin.net/ARIN-XX/.

In addition to ARIN policy proposal discussions, the meeting will also 
feature the following:

Sunday, 14 October
	* An all-day program focusing on IPv6, including a workshop, tutorial, 
and panel discussions. Visit http://www.arin.net/ARIN-XX/v6_sunday.html 
for details.

Tuesday, 16 October
	* A First Timer Lunch from 12:30 - 1:30 PM,  where those new to the 
ARIN community or meetings can meet members of ARIN's Board, Advisory 
Council, and staff
	* A brief session "Introduction to the Internet Resource Policy 
Evaluation Process" will begin at 5:30 PM
	* The Open Policy Hour will begin at 6:00 PM

Wednesday, 17 October
	* The ARIN XX Social Event, a southwestern evening at the Los Amigos 
Roundup Ranch on the Sandia Indian Reservation from 7:00 PM to 10:00 PM. 
More information is available at: http://www.arin.net/ARIN-XX/social.html

If you are interested in any of the Tuesday or Wednesday activities, 
select the events on your registration form; the Sunday IPv6 training 
sessions do not require pre-registration. If you have already 
registered, but would like to modify your choice of events, click on the 
"Update Existing Registration" link available through the URL at the top 
of the page.

As always, please contact ARIN Member Services at info at arin.net with any 
questions. We look forward to seeing you in Albuquerque!

Regards,

Member Services
American Registry for Internet Numbers (ARIN)




From michael.dillon at bt.com  Wed Sep 19 12:15:20 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 19 Sep 2007 17:15:20 +0100
Subject: [ppml] ULA
In-Reply-To: <20070918145806.91D831444C1@smtp2.arin.net>
References: <454810F09B5AA04E9D78D13A5C39028A02A4CA0D@nyrofcs2ke2k01.corp.pvt><39278.1190043128@sa.vix.com><3241FDB1-9567-4EC0-ACA6-C5FA8494D4C7@muada.com><70DE64CEFD6E9A4EB7FAF3A063141066707489@mail><46EEC0FA.3080007@internap.com><46EEC4DA.40806@psg.com><20070918145806.91D831444C1@smtp2.arin.net>
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B0010D766B@E03MVC4-UKBR.domain1.systemhost.net>

>   The ULA proposal should say that all routers, everywhere, 
> should filter ULA/7 space --- by this I mean, blackhole 
> route, not ACL. (Plus ingress filtering on source IPs)

It is not ARIN's business to tell ISPs what they should or should not do
in their routers.

However, it is the IETF's business to say such things, and lo and
behold, what do we find here in RFC 4193, section 4.1 Routing?

   The default behavior of exterior routing protocol sessions between
   administrative routing regions must be to ignore receipt of and not
   advertise prefixes in the FC00::/7 block.  A network operator may
   specifically configure prefixes longer than FC00::/7 for inter-site
   communication.

Golly gee!
Right there where it belongs

>   you can use whois to find out who it belongs to.
>   In the absense of ULA-Vixie (which letter is your's Paul?), 
> people like me are going to ask for PI space. (Thank you to 
> those who offered me a /48 out of their assignment, btw)

Interesting. Not only can you register your RFC 4193 ULA address in this
global registry:
http://www.sixxs.net/tools/grh/ula/
You could also ask a friend at a smaller ISP to give you a /48 from
their vast allocation. With so many ways to skin a cat, it is clear that
ARIN doesn't need to worry about it from a policy point of view.

--Michael Dillon
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.


From dean at av8.com  Wed Sep 19 13:48:22 2007
From: dean at av8.com (Dean Anderson)
Date: Wed, 19 Sep 2007 13:48:22 -0400 (EDT)
Subject: [ppml] IPv6 flawed?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410667074C6@mail>
Message-ID: <Pine.LNX.4.44.0709191319020.13475-100000@citation2.av8.net>

US Department of Commerce. (DoC)

ICANN documents regarding the IANA function of the DoC, are a good place
to start.  DoC has also intervened previously when Jon Postel and Paul
Vixie some others tried to take over the Root DNS system in 1998.

DoC delegates IANA function to ICANN. IANA delegates control to the
RIRs. ARIN is an RIR, subject to IANA, subject to DoC.  The records
maintained by SRI, NetSol, and subsequently ARIN belong ultimately to
DoC.

There is good book entitled "Who controls the Internet, Illusions of a
Borderless World" by Goldsmith and Wu, 2006, which is quite helpful, and
explains a great deal of history, including the "MoUvement" in which
root server operators previously tried to exclude DoC contro and
transfer control into the hands of a few people with no accountability.  
One of their ulterior goals was to exclude Network Solutions from
operation of the .com and .net registry.

The "MoUvement" was the name given to the effort to circumvent DoC
because it involved signing MoU (Memoranda of Understanding) agreements
between operators. The MoUvement effort failed with the intervention of
the DoC against Postel, but you can kind of see it still in the NRO and
the ASO (which also operate by MoU), and the statements of the people
involved with these organizations to the effect that 'RIRs could ignore
IANA and replace IANA with the ASO or NRO.' Of course, this would have
the same effect as before: DoC would intervene as necessary to restore
order.  

		--Dean

On Wed, 19 Sep 2007, Kevin Kargel wrote:

> I still have a hard time with this..  ARIN serves a wide area..  far
> wider than just the United States or Canada..  which government are you
> referencing that is giving ARIN authority and control?  Which
> governmental agency is on the documents you refer to?
> 
>  
> 
> > -----Original Message-----
> > From: Dean Anderson [mailto:dean at av8.com] 
> > Sent: Tuesday, September 18, 2007 8:34 PM
> > To: Kevin Kargel
> > Cc: 
> > Subject: RE: [ppml] IPv6 flawed?
> > 
> > On Tue, 18 Sep 2007, Kevin Kargel wrote:
> > 
> > > > > So far as I know, Legacy owners have no license from "the
> > > > government"..
> > > > > there is no piece of paper from "the government" giving 
> > them rights.
> > > > > Maybe I am wrong, but I have not heard of such a document.  
> > > > 
> > > > There is indeed a piece of paper, and ARIN keeps it in a book.  
> > > > Registrations were originally by paper and mail.  I suppose you 
> > > > young'uns don't know what those are. We also didn't have 
> > cell phones 
> > > > back that, and numeric pagers were "cool", unless you had 
> > to carry 
> > > > one for work.
> > > > 
> > > 
> > > But that piece of paper is not from a "government".  ARIN is not a 
> > > governmental agency or department,
> > 
> > The legacy paper is not from ARIN. It is from SRI, or NetSol, 
> > on behalf of the government.  The government told SRI to give 
> > the records to NetSol. SRI didn't invent that transfer. Then 
> > the G. told NetSol to give the records to ARIN. NetSol didn't 
> > invent that.  The G. can tell ARIN to give the records to 
> > someone else.  The records don't belong to ARIN.
> > ARIN is just the administrator.
> > 
> > The 'paper', electronic records of delegation, you get from 
> > ARIN is on behalf of the government. The RSA terms are 
> > different from the legacy terms.  Even within the ARIN RSA 
> > regime, there are different sets of terms, as the court found 
> > in the Kremen case: It found 3 different sets of terms that 
> > Kremen could accept.
> > 
> > > they are not paid through tax dollars, they do not carry 
> > the "force of 
> > > law".
> > 
> > ARIN doesn't have to be a goverment agency 'paid by tax 
> > dollars with force of law' to administer government records. 
> > Many government activities are paid directly through fees to 
> > private contractors, as the toll road operation example 
> > demonstrates.  The government has long used private 
> > contractors to perform some functions for the government, and 
> > the practice is increasing. The lack of tax dollars and force 
> > of law does not prove your claim that the records are the 
> > private property of ARIN and that ARIN can do with them as it pleases.
> > 
> > BTW, some government agencies paid by tax dollars don't have 
> > 'force of law' (NIST comes to mind as an example of that)
> > 
> > The records are government records, licenses/leases, that 
> > ARIN maintains and administers and in return collects fees. 
> > Just like the toll road operator maintains the road and in 
> > return collects fees.
> > 
> > > I still maintain that legacy holders hold no license from any 
> > > government to the use of those numbers.
> > 
> > You seem to have no facts to support that argument, and what 
> > facts there are, contradict that view.
> > 
> > > I also still maintain that we should let them continue to use them, 
> > > but because it is right, not because it would be illegal to do 
> > > otherwise.
> > 
> > It is right. And it is also illegal to do otherwise (well, 
> > illegal isn't the precisely correct word. It violates the 
> > legal rights of the legacy in the license/lease to do 
> > otherwise; 'illegal' usually suggests there is a law that 
> > would be violated by doing so, which isn't the case)
> > 
> > 		--Dean
> > 
> > -- 
> > Av8 Internet   Prepared to pay a premium for better service?
> > www.av8.net         faster, more reliable, better service
> > 617 344 9000   
> > 
> > 
> > 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




From tedm at ipinc.net  Wed Sep 19 14:15:00 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 19 Sep 2007 11:15:00 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <Pine.LNX.4.44.0709182100150.12663-100000@citation2.av8.net>
Message-ID: <NABBJOELMNGNJNGPKDDOGEOAHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Dean Anderson
>Sent: Tuesday, September 18, 2007 6:34 PM
>To: Kevin Kargel
>Cc: ppml at arin.net
>Subject: Re: [ppml] IPv6 flawed?
>
>
>> I also still maintain that we should let them continue to use them,
>> but because it is right, not because it would be illegal to do
>> otherwise.
>
>It is right. And it is also illegal to do otherwise (well, illegal isn't
>the precisely correct word. It violates the legal rights of the legacy
>in the license/lease to do otherwise; 'illegal' usually suggests there
>is a law that would be violated by doing so, which isn't the case
>

This whole Legacy Holder argument is moot anyway because the Legacy
holders were given IPv4 not IPv6 numbers.  Numbers that will become
obsolete sooner or later.  The entire Legacy Holder argument/discussion
can be ignored as it is a self-terminating system.

The only value the Legacy holders numbers have on today's Internet is
in use of possibly extending the period of IPv4 before it expires.  I
will point out that if the Legacy holders sit on unused IPv4 allocations
and do not return them to the RIRs, then it merely shortens the time
that IPv4 will remain viable - and thus hastens the deadline where the
Legacy holders themselves must switch over to IPv6.  "Look mommy,
their screwing themselves" she exclaimed in amazement.

As for the speed limit analogy, I feel compelled to add that while it
sounds great in principle in reality, speed limits are also set by
political decisions in addition to engineers comments - while sometimes
they are decisions that may help society - such as the energy-saving
55 mph limit, or the decision to lower speeds around schools - many
other times they are not helpful to society - such as "speed traps"
where speeds are lowered in order to generate ticket revenue in some
po-dunk small town in the sticks.

But the most important problem with the speed limit analogy is that
the ability of drivers and their vehicles is not quantifable except
as an average.

An engineer may conclude that a speed limit of 75Mph is safe on a highway
with a gentle 3 degree radius turn - but this is assuming average
vehicles and average driving skills.  It may NOT be safe at all for a
pickem-up truck jacked way up into God's ass on gigantic donut tractor
tires, driven by Redneck Billy and his bird huntin' dog.  And it's margin
may be well execeeded by the 'vette with sticky tires driven by a
skilled driver.

I can certainly say that an engineer isn't going to use the 'vette driven
by the skilled driver as the variable in his math equation used to determine
a safe speed.  Nor is he going to use the pickemup truck.  So, despite
whatever mathmatics are used to determine a speed limit - the limit itself
remains arbitrary because the variables that went into the equation are
arbitrary.

So, while fun, a poor analogy I think.

Ted

PS  So when we are all driving hybrids running on biodiesel, and the
justification
of foreign oil dependence doesen't exist anymore, can I look forward to the
recinding of the double-nickel speed limit?  Yeah, sssuurree I can.



From tedm at ipinc.net  Wed Sep 19 15:40:49 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 19 Sep 2007 12:40:49 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <Pine.LNX.4.44.0709191319020.13475-100000@citation2.av8.net>
Message-ID: <NABBJOELMNGNJNGPKDDOKEOBHDAA.tedm@ipinc.net>


Actually this is only part of the story.  The World Intellectual
Property Organization, under the United Nations (WIPO) has already
taken control of the DNS system.  The way they did it was to declare
domain names to be Intellectual Property, and then use existing
copyright and trademark law to tell the registrars how to do
their jobs.

There wss, of course, no discussion or debate or any input from
the Internet community before such declaration happened.  There
was discussion afterwards, but it only happened in the guidelines
that WIPO setup.

This is how prior to this, individuals could own domain names
like mcdonalds.com or cocacola.com and so forth.  (and a number
of people did in fact own those domains at one time)

You might be interested in the following article:

http://www.bizreport.com/2006/10/icann_reaches_deal_on_more_freedom_with_us_
department_of_commerce.html

"...The international lobby for the United Nations to have the ultimate
authority over the corporation (ICANN) is strong and noisy. However a few
months ago, the UN bowed down to pressure by the US Bush administration for
ICANN to continue to be in charge of domain names. For the time being, the
UN will have to make do with participation only in the Internet Governance
Forum (IGF), the organization that the international lobby would like to
replace ICANN. The IGF has as yet no real authority or involvement in the
day-to-day operations of Internet governance..."

I personally would be vociferiously opposed to any organization
taking responsibility from DoC that does not have as part of it's
charter, the recognition of NON-religious control of government,
the recognition of individual rights, the recognition of freedom
of the press, and several other major things of personal freedom.

This excludes, for example, the governments of just
about all Mid-East countries, (including Israel, as their
government is effectively under religious control) the
governments of China and India, and in addition, the
government of Germany.  (Germany outlaws even discussion of
Naziism in their country)

I have serious misgivings on allowing the UN to exercise any
control.  As things are right now, if China or Germany wants
to censor stuff on the Internet, they can do so by simply
inserting censorship on the major Internet gateways into their
countries.  The same goes for the MidEast religously-controlled
governments.

If the UN had control, it would be simple for China to tell
ICANN to censor at the source.  And why not?  It would certainly
be a lot more efficient than censoring at the country's borders.

There are many governments in the world that do not like criticism
and more importantly, the do not like a forum to exist that allows
government critics to find each other and organize.  The Internet is
such a forum and countries like Germany would like nothing better than
to censor it.

Ted

>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Dean Anderson
>Sent: Wednesday, September 19, 2007 10:48 AM
>To: Kevin Kargel
>Cc: ppml at arin.net
>Subject: Re: [ppml] IPv6 flawed?
>
>
>US Department of Commerce. (DoC)
>
>ICANN documents regarding the IANA function of the DoC, are a good place
>to start.  DoC has also intervened previously when Jon Postel and Paul
>Vixie some others tried to take over the Root DNS system in 1998.
>
>DoC delegates IANA function to ICANN. IANA delegates control to the
>RIRs. ARIN is an RIR, subject to IANA, subject to DoC.  The records
>maintained by SRI, NetSol, and subsequently ARIN belong ultimately to
>DoC.
>
>There is good book entitled "Who controls the Internet, Illusions of a
>Borderless World" by Goldsmith and Wu, 2006, which is quite helpful, and
>explains a great deal of history, including the "MoUvement" in which
>root server operators previously tried to exclude DoC contro and
>transfer control into the hands of a few people with no accountability.
>One of their ulterior goals was to exclude Network Solutions from
>operation of the .com and .net registry.
>
>The "MoUvement" was the name given to the effort to circumvent DoC
>because it involved signing MoU (Memoranda of Understanding) agreements
>between operators. The MoUvement effort failed with the intervention of
>the DoC against Postel, but you can kind of see it still in the NRO and
>the ASO (which also operate by MoU), and the statements of the people
>involved with these organizations to the effect that 'RIRs could ignore
>IANA and replace IANA with the ASO or NRO.' Of course, this would have
>the same effect as before: DoC would intervene as necessary to restore
>order.
>
>		--Dean
>
>On Wed, 19 Sep 2007, Kevin Kargel wrote:
>
>> I still have a hard time with this..  ARIN serves a wide area..  far
>> wider than just the United States or Canada..  which government are you
>> referencing that is giving ARIN authority and control?  Which
>> governmental agency is on the documents you refer to?
>>
>>
>>
>> > -----Original Message-----
>> > From: Dean Anderson [mailto:dean at av8.com]
>> > Sent: Tuesday, September 18, 2007 8:34 PM
>> > To: Kevin Kargel
>> > Cc:
>> > Subject: RE: [ppml] IPv6 flawed?
>> >
>> > On Tue, 18 Sep 2007, Kevin Kargel wrote:
>> >
>> > > > > So far as I know, Legacy owners have no license from "the
>> > > > government"..
>> > > > > there is no piece of paper from "the government" giving
>> > them rights.
>> > > > > Maybe I am wrong, but I have not heard of such a document.
>> > > >
>> > > > There is indeed a piece of paper, and ARIN keeps it in a book.
>> > > > Registrations were originally by paper and mail.  I suppose you
>> > > > young'uns don't know what those are. We also didn't have
>> > cell phones
>> > > > back that, and numeric pagers were "cool", unless you had
>> > to carry
>> > > > one for work.
>> > > >
>> > >
>> > > But that piece of paper is not from a "government".  ARIN is not a
>> > > governmental agency or department,
>> >
>> > The legacy paper is not from ARIN. It is from SRI, or NetSol,
>> > on behalf of the government.  The government told SRI to give
>> > the records to NetSol. SRI didn't invent that transfer. Then
>> > the G. told NetSol to give the records to ARIN. NetSol didn't
>> > invent that.  The G. can tell ARIN to give the records to
>> > someone else.  The records don't belong to ARIN.
>> > ARIN is just the administrator.
>> >
>> > The 'paper', electronic records of delegation, you get from
>> > ARIN is on behalf of the government. The RSA terms are
>> > different from the legacy terms.  Even within the ARIN RSA
>> > regime, there are different sets of terms, as the court found
>> > in the Kremen case: It found 3 different sets of terms that
>> > Kremen could accept.
>> >
>> > > they are not paid through tax dollars, they do not carry
>> > the "force of
>> > > law".
>> >
>> > ARIN doesn't have to be a goverment agency 'paid by tax
>> > dollars with force of law' to administer government records.
>> > Many government activities are paid directly through fees to
>> > private contractors, as the toll road operation example
>> > demonstrates.  The government has long used private
>> > contractors to perform some functions for the government, and
>> > the practice is increasing. The lack of tax dollars and force
>> > of law does not prove your claim that the records are the
>> > private property of ARIN and that ARIN can do with them as it pleases.
>> >
>> > BTW, some government agencies paid by tax dollars don't have
>> > 'force of law' (NIST comes to mind as an example of that)
>> >
>> > The records are government records, licenses/leases, that
>> > ARIN maintains and administers and in return collects fees.
>> > Just like the toll road operator maintains the road and in
>> > return collects fees.
>> >
>> > > I still maintain that legacy holders hold no license from any
>> > > government to the use of those numbers.
>> >
>> > You seem to have no facts to support that argument, and what
>> > facts there are, contradict that view.
>> >
>> > > I also still maintain that we should let them continue to use them,
>> > > but because it is right, not because it would be illegal to do
>> > > otherwise.
>> >
>> > It is right. And it is also illegal to do otherwise (well,
>> > illegal isn't the precisely correct word. It violates the
>> > legal rights of the legacy in the license/lease to do
>> > otherwise; 'illegal' usually suggests there is a law that
>> > would be violated by doing so, which isn't the case)
>> >
>> > 		--Dean
>> >
>> > --
>> > Av8 Internet   Prepared to pay a premium for better service?
>> > www.av8.net         faster, more reliable, better service
>> > 617 344 9000
>> >
>> >
>> >
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the
>ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the
>ARIN Member Services
>> Help Desk at info at arin.net if you experience any issues.
>>
>>
>
>--
>Av8 Internet   Prepared to pay a premium for better service?
>www.av8.net         faster, more reliable, better service
>617 344 9000
>
>
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to the
>ARIN Public Policy
>Mailing List (PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/ppml Please contact the
>ARIN Member Services
>Help Desk at info at arin.net if you experience any issues.
>



From bjohnson at drtel.com  Wed Sep 19 15:47:28 2007
From: bjohnson at drtel.com (Brian Johnson)
Date: Wed, 19 Sep 2007 14:47:28 -0500
Subject: [ppml] IPv6 flawed? [so off topic it's scary]
In-Reply-To: <NABBJOELMNGNJNGPKDDOKEOBHDAA.tedm@ipinc.net>
References: <Pine.LNX.4.44.0709191319020.13475-100000@citation2.av8.net>
	<NABBJOELMNGNJNGPKDDOKEOBHDAA.tedm@ipinc.net>
Message-ID: <29A54911243620478FF59F00EBB12F47B3A056@ex01.drtel.lan>

Ted Mittelstaedt writes:
>
> I personally would be vociferiously opposed to any organization
> taking responsibility from DoC that does not have as part of it's
> charter, the recognition of NON-religious control of government,
> the recognition of individual rights, the recognition of freedom
> of the press, and several other major things of personal freedom.
> 
> This excludes, for example, the governments of just
> about all Mid-East countries, (including Israel, as their
> government is effectively under religious control) the
> governments of China and India, and in addition, the
> government of Germany.  (Germany outlaws even discussion of
> Naziism in their country)
> 
> I have serious misgivings on allowing the UN to exercise any
> control.  As things are right now, if China or Germany wants
> to censor stuff on the Internet, they can do so by simply
> inserting censorship on the major Internet gateways into their
> countries.  The same goes for the MidEast religously-controlled
> governments.
> 
> If the UN had control, it would be simple for China to tell
> ICANN to censor at the source.  And why not?  It would certainly
> be a lot more efficient than censoring at the country's borders.
> 
> There are many governments in the world that do not like criticism
> and more importantly, the do not like a forum to exist that allows
> government critics to find each other and organize.  The Internet is
> such a forum and countries like Germany would like nothing better than
> to censor it.
> 

What was this thread about?
- Brian


From tedm at ipinc.net  Wed Sep 19 15:58:07 2007
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 19 Sep 2007 12:58:07 -0700
Subject: [ppml] IPv6 flawed? [so off topic it's scary]
In-Reply-To: <29A54911243620478FF59F00EBB12F47B3A056@ex01.drtel.lan>
Message-ID: <NABBJOELMNGNJNGPKDDOOEOBHDAA.tedm@ipinc.net>



>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Brian Johnson
>Sent: Wednesday, September 19, 2007 12:47 PM
>To: ppml at arin.net
>Subject: Re: [ppml] IPv6 flawed? [so off topic it's scary]
>

>> 
>
>What was this thread about?

Is that the best you can do?  Sheesh!  Obvious mailing
list newbie.  And after I worked so hard to set it up for
an invocation of Godwin's Rule.

[stamps off in disgust]

Ted


From davids at webmaster.com  Sun Sep 23 23:55:13 2007
From: davids at webmaster.com (David Schwartz)
Date: Sun, 23 Sep 2007 20:55:13 -0700
Subject: [ppml] IPv6 flawed?
In-Reply-To: <NABBJOELMNGNJNGPKDDOKEOBHDAA.tedm@ipinc.net>
Message-ID: <MDEHLPKNGKAHNMBLJOLKIEAKHAAC.davids@webmaster.com>


> There are many governments in the world that do not like criticism
> and more importantly, the do not like a forum to exist that allows
> government critics to find each other and organize.  The Internet is
> such a forum and countries like Germany would like nothing better than
> to censor it.
>
> Ted

As would the United States. Some of what the United States would like to
suppress is not controversial, such as people using the Internet to hire
killers. Some of it is not so controversial as to goals but conversial as to
means, such as efforts to suppress the production of child pornograhy by
criminalizing its distribution. Some of it is as about as crazy as what
countries like Germany would like to do, such as suppress gambling.

The United States is also interested in forms of business model regulation
that border on censorship. I would put net neutrality in this category but
certainly others would disagree. However, there's no point is fighting
censorship on the Internet across countries if "business model" regulation
can, for example, mandate charging more for controversial content.

To take a principled stand against other governments, the United States
would have to give up its own censorship and regulation aspirations. Who is
willing to do that?

DS




From darden at armc.org  Mon Sep 24 08:40:10 2007
From: darden at armc.org (Darden, Patrick S.)
Date: Mon, 24 Sep 2007 08:40:10 -0400
Subject: [ppml] IPv6 flawed?
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKIEAKHAAC.davids@webmaster.com>
Message-ID: <CBE22E5FF427B149A272DD1DDE1075240184E1F1@EX2K3.armc.org>


I'm unsure what any of this has to do with IPv6.  You might want to
start a separate "Net Neutrality" thread.  AFAIK, there are no
provisions (e.g. "politics" header) in IPv6 for net neutrality. ;-)

--Patrick Darden


-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
David Schwartz
Sent: Sunday, September 23, 2007 11:55 PM
To: Tedm at Ipinc. Net
Cc: ppml at arin.net
Subject: Re: [ppml] IPv6 flawed?



> There are many governments in the world that do not like criticism
> and more importantly, the do not like a forum to exist that allows
> government critics to find each other and organize.  The Internet is
> such a forum and countries like Germany would like nothing better than
> to censor it.
>
> Ted

As would the United States. Some of what the United States would like to
suppress is not controversial, such as people using the Internet to hire
killers. Some of it is not so controversial as to goals but conversial as to
means, such as efforts to suppress the production of child pornograhy by
criminalizing its distribution. Some of it is as about as crazy as what
countries like Germany would like to do, such as suppress gambling.

The United States is also interested in forms of business model regulation
that border on censorship. I would put net neutrality in this category but
certainly others would disagree. However, there's no point is fighting
censorship on the Internet across countries if "business model" regulation
can, for example, mandate charging more for controversial content.

To take a principled stand against other governments, the United States
would have to give up its own censorship and regulation aspirations. Who is
willing to do that?

DS


_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.


From info at arin.net  Mon Sep 24 08:45:37 2007
From: info at arin.net (Member Services)
Date: Mon, 24 Sep 2007 08:45:37 -0400
Subject: [ppml] ARIN XX - Open Policy Hour
Message-ID: <46F7B171.3050906@arin.net>

Some Questions about the Policy Process:
1. Do you want to know what policy proposals will be discussed at the 
upcoming ARIN Public Policy Meeting?
2. Do you have an idea about how ARIN should manage Internet Number 
Resources?
3. Do you think that a current policy should be enhanced or changed, or 
even retired?
4. Are you hesitant about making a formal proposal on the Public Policy 
Mail List (PPML)?
5. Are you new to the Policy Development Process?

If the answer to any of these questions is yes, then you should attend 
the Open Policy Hour!

What is The Open Policy Hour? It is your opportunity to get a better 
understanding of what is going to be discussed at the upcoming Public 
Policy Meeting or for you to discuss your ideas in an open, informal 
forum and receive feedback or both! The Open Policy Hour consists of two 
parts.

Part One is the P2B2 or the Policy Proposal Background Briefing. ARIN 
staff will provide summary information regarding the policy proposals 
that will be discussed at the meeting. Members of the ARIN Advisory
Council will be present to answer general questions about the policy 
proposals. There will be no discussion of the proposals, just the 
information that you need to help you understand the nature of the 
proposals.

Part Two is the P2B or the Policy Proposal BoF. This is where you get a 
chance to "test drive" a policy idea. How can you participate? Bring 
your ideas and questions. If you have a policy suggestion for which you 
would like to receive feedback prior to submitting it to the community 
on the PPML, here is your opportunity. If you have a short (3-minute) 
presentation prepared you will be given the first opportunity to present 
it. To sign up to give a presentation please send an e-mail to 
policy at arin.net by 12 October 2007 with your name, organization, and a 
brief description of your policy subject.

Come join your colleagues in this informal setting. The Open Policy Hour 
for ARIN XX will be held on Tuesday, 16 October, from 6:00 - 7:00 PM. If 
you are not familiar with the way policies are developed in the ARIN 
region, join ARIN staff a half hour earlier, at 5:30 PM, for a review of 
the Internet Resource Policy Evaluation Process.

Registration and hotel information for ARIN XX is available at:
http://www.arin.net/ARIN-XX/

Contact Member Services at info at arin.net if you have any questions.

Regards,

Member Services Department
American Registry for Internet Numbers (ARIN)




From michael.dillon at bt.com  Tue Sep 25 11:28:48 2007
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 25 Sep 2007 16:28:48 +0100
Subject: [ppml] IPv6 Information Wiki
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B001178116@E03MVC4-UKBR.domain1.systemhost.net>


ARIN has set up a wiki at http://www.getipv6.info to publish information
that will help ISPs, large and small in implementing IPv6 and migrating
to an IPv6 Internet.

I have collected info from some recent emails to the NANOG list, and
other sources, and published it on the wiki. Since this is a wiki,
anyone with something useful can contribute. In particular, it would be
good for more eyes to review the wiki for technical correctness and for
more people to participate in discussing IPv6 addressing plans at
http://www.getipv6.info/index.php/IPv6_Addressing_Plans

Thanks,

--Michael Dillon


From jabley at ca.afilias.info  Tue Sep 25 12:08:38 2007
From: jabley at ca.afilias.info (Joe Abley)
Date: Tue, 25 Sep 2007 12:08:38 -0400
Subject: [ppml] IPv6 Information Wiki
In-Reply-To: <D03E4899F2FB3D4C8464E8C76B3B68B001178116@E03MVC4-UKBR.domain1.systemhost.net>
References: <D03E4899F2FB3D4C8464E8C76B3B68B001178116@E03MVC4-UKBR.domain1.systemhost.net>
Message-ID: <CC67929A-2CE6-4333-9831-7022DEA64FBE@ca.afilias.info>


On 25-Sep-2007, at 1128, <michael.dillon at bt.com>  
<michael.dillon at bt.com> wrote:

> ARIN has set up a wiki at http://www.getipv6.info to publish  
> information
> that will help ISPs, large and small in implementing IPv6 and  
> migrating
> to an IPv6 Internet.

It might be worth syncing up with the people who are working on  
<http://ipv6.cluepon.net/>, in the interests of concentrating effort.


Joe



From randy at psg.com  Tue Sep 25 12:11:56 2007
From: randy at psg.com (Randy Bush)
Date: Tue, 25 Sep 2007 06:11:56 -1000
Subject: [ppml] IPv6 Information Wiki
In-Reply-To: <CC67929A-2CE6-4333-9831-7022DEA64FBE@ca.afilias.info>
References: <D03E4899F2FB3D4C8464E8C76B3B68B001178116@E03MVC4-UKBR.domain1.systemhost.net>
	<CC67929A-2CE6-4333-9831-7022DEA64FBE@ca.afilias.info>
Message-ID: <46F9334C.2040609@psg.com>

>> ARIN has set up a wiki at http://www.getipv6.info to publish 
>> information that will help ISPs, large and small in implementing
>> IPv6 and migrating to an IPv6 Internet.
> It might be worth syncing up with the people who are working on 
> <http://ipv6.cluepon.net/>, in the interests of concentrating effort.

or the folk working on <http://www.civil-tongue.net/clusterf/>.  there
seem to be more folk working on v6 wikis than vendors working on fully
functional v6/dual-stack implementations.

randy


From info at arin.net  Tue Sep 25 14:11:32 2007
From: info at arin.net (Member Services)
Date: Tue, 25 Sep 2007 14:11:32 -0400
Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
 - AC did not accept
In-Reply-To: <46E8007C.6010507@arin.net>
References: <B465FE71-9FDD-4838-A45A-174DD7AA7E1D@delong.com>
	<46E8007C.6010507@arin.net>
Message-ID: <46F94F54.1090601@arin.net>

On 20 September 2007, the ARIN Advisory Council (AC) concluded its
review of the proposed policy 'Modification to Reverse Mapping Policy'
and did not accept it as a formal policy proposal. The AC provided the
following explanation of their decision:

"Although the Advisory Council is sympathetic to your cause we have
moved to not accept your proposal: Modification to Reverse Mapping
Policy. The reason we have chosen this motion is because detailed
operational techniques do not belong in the the NRPM. Although this may
have occurred in the past, we are taking measures to ensure that we move
detailed operations into staff process and not the NRPM. We believe
moving forward that the best way to suggest and or change operational
process is through the ARIN Consultation and Suggestion Process."

During the initial review period the AC may decide to:
1)  Accept the proposal as a formal policy proposal as written.
2)  Postpone their decision regarding the proposal until the next
regularly scheduled AC meeting in order to work with the author.
3)  Not accept the policy proposal.

In the event that the AC decides not to accept the proposal, then the
author may elect to use the petition process to advance the proposal.
For petition details see the section called "Petition Process" in the
ARIN Internet Resource Policy Evaluation Process which can be found at:
http://www.arin.net/policy/irpep.html

The deadline for the author to initiate a petition per the ARIN Internet
Resource Policy Evaluation Process is 40 days prior to the meeting; the
petition deadline for the ARIN XXI Public Policy Meeting is 23:59 EDT,
27 February 2008. If the author chooses not to petition or the petition
is unsuccessful, then the proposed policy is closed. If a petition is
successful, then the proposal will be numbered and posted for discussion
and presented at ARIN's Public Policy Meeting.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


Member Services wrote:
> ARIN received the following policy proposal. In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
> ARIN's website.
> 
> The ARIN Advisory Council (AC) will review this proposal at their next
> regularly scheduled meeting. The AC may decide to:
> 
>     1. Accept the proposal as a formal policy proposal as written. If the
> AC accepts the proposal, it will be posted as a formal policy proposal
> to PPML and it will be presented at a Public Policy Meeting.
> 
>     2. Postpone their decision regarding the proposal until the next
> regularly scheduled AC meeting in order to work with the author. The AC
> will work with the author to clarify, combine or divide the proposal. At
> their following meeting the AC will accept or not accept the proposal.
> 
>     3. Not accept the proposal. If the AC does not accept the proposal,
> the AC will explain their decision. If a proposal is not accepted, then
> the author may elect to use the petition process to advance their
> proposal. If the author elects not to petition or the  petition fails,
> then the proposal will be closed.
> 
> The AC will assign shepherds in the near future. ARIN will provide the
> names of the shepherds to the community via the PPML.
> 
> In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
> 
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Policy Proposal Name: Modification to Reverse Mapping Policy
> 
> Author: John Von Essen
> 
> Proposal Version: 1.0
> 
> Submission Date: September 11, 2007
> 
> Proposal type: modify
> 
> Policy term: permanent
> 
> Policy statement:
> 
> I am proposing a modification to section 7 of the IPv4 policy such that
> a more precise definition and overview of lameness is described.
> Below is how I think section 7 should be re-written.
> 
> START NEW Section
> 
> 7. Reverse Mapping
> 
> 7.1. Maintaining IN-ADDRs
> 
> All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
> from ARIN will be responsible for maintaining all IN- ADDR.ARPA domain
> records for their respective customers. For blocks smaller than /16, and
> for the segment of larger blocks which start or end with a CIDR prefix
> longer than /16, ARIN can maintain IN-ADDRs through the use of the SWIP
> (Reallocate and Reassign) templates or the Netmod template for /24 and
> shorter prefixes.
> 
> 7.2 Definitions
> 
> 7.2.1 Lame Delegation
> 
> A delegation is defined as being lame if all of the in-addr.arpa zones
> for a given name server of a specific network registration are lame. An
> in- addr.arpa zone is defined as lame when ARIN requests the SOA record
> from the name server registered in whois, but does not receive an answer.
> 
> 7.2.2 Partially Lame Delegation
> 
> A delegation is defined as being partially lame if at least one in-
> addr.arpa zone for a given name server of a specific network
> registration is lame. An in- addr.arpa zone is defined as lame when ARIN
> requests the SOA record from the name server registered in whois, but
> does not receive an answer.
> 
> 7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA
> 
> ARIN will actively identify lame and partially lame DNS name server
> (s) for reverse address delegations associated with address blocks
> allocated, assigned or administered by ARIN. Upon identification of a
> lame or partially 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 or partially lame delegation, ARIN
> will update the WHOIS database records resulting in the removal of lame
> or partially lame DNS servers. ARIN's actions in resolving lame and
> partially lame delegations is governed by the procedures set forth in
> (Lame-Ref).
> 
> 7.4 References
> 
> (Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
> reference/lame_delegations.html
> 
> 
> STOP NEW Section
> 
> 
> Rationale:
> 
> Current policy only considers an Org's delegation being deemed lame if
> all of in-addr.arpa zones for a given name server of a specific network
> registration are lame. Lame is defined when ARIN tests an in-addr.arpa
> zone by requesting the SOA record from the name server registered in
> whois, but does not receive an answer. If deemed lame, ARIN has an
> appropriate procedure for contacting the Org and handling the issue as
> per "http://www.arin.net/ reference/lame_delegations.html".
> 
> Unfortunately, the policy does not cover the situation of a so-called
> partially lame delegation. That is, some of the in-addr.arpa zones
> belonging to the network registration return a valid SOA upon testing,
> and some do not. Even if only one /24 in-addr.arpa reverse tests comes
> back as lame, it is my opinion that this still taints the reputation of
> entire network registration. IPs belonging to that lame in-addr.arpa
> zone will cause query timeouts to 3rd party dns resolvers, both public
> and private. These excessive timeouts in my opinion can harm the overall
> well-being of reverse dns functionality throughout the internet. The
> only way to prevent such harm is for ARIN to not delegate reverse
> authority to the so-called partially lame dns server as registered in
> whois. That is the purpose of this policy proposal, to consider partial
> lameness with the same prejudice as traditionally defined lameness.
> Org's who are partially lame should be contacted by ARIN and lame
> in-addr.arpa zones should be resolved as the procedures per
> "http://www.arin.net/reference/ lame_delegations.html" dictate.
> 
> Timetable for implementation: June 1, 2008
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
> 





From info at arin.net  Tue Sep 25 14:12:27 2007
From: info at arin.net (Member Services)
Date: Tue, 25 Sep 2007 14:12:27 -0400
Subject: [ppml] Policy Proposal 2007-26: Deprecate Lame Server Policy
Message-ID: <46F94F8B.7050100@arin.net>

On 20 September 2007, the ARIN Advisory Council (AC) concluded their
initial review of "Deprecate Lame Server Policy" and accepted it as a
formal policy proposal for discussion by the community.

The proposal is designated Policy Proposal 2007-26: Deprecate Lame
Server Policy. The proposal text is below and can be found at:
http://www.arin.net/policy/proposals/2007_26.html

All persons in the community are encouraged to discuss Policy Proposal
2007-26 prior to it being presented at the ARIN XXI Public Policy
Meeting in April 2008. Both the discussion on the Public Policy Mailing
List and at the Public Policy Meeting will be used to determine the
community consensus regarding this policy proposal.

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 2007-26
Deprecate Lame Server Policy

Author: Owen DeLong

Proposal type: modify

Policy term: permanent

Policy statement:

Replace Section 7 of the NRPM in it's entirety with the following text:

7. Staff action to improve ARIN public database accuracy and consistency.

7.1 ARIN staff shall take reasonable and practicable means to ensure and
improve the accuracy of all ARIN public databases, including, but, not
limited to WHOIS, delegations of the in-addr.arpa zone, and, delegations
of the ip6.arpa zone.

Rationale:

Recent PPML discussion has called attention to the fact that lame DNS
delegations are more an operational issue than one of policy. As such,
the existing lame delegation policy should be removed from the NRPM to
remove the resultant confusion. This is not meant to prevent ARIN staff
from taking reasonable action WRT DNS operational issues related to
resources issued by ARIN, but, such action can be covered by staff
operational guidelines and is not within the scope of Address Policy.

Timetable for implementation: 1 June, 2008



From info at arin.net  Thu Sep 27 12:49:29 2007
From: info at arin.net (Member Services)
Date: Thu, 27 Sep 2007 12:49:29 -0400
Subject: [ppml] ARIN XX Remote Participation and Webcast
Message-ID: <46FBDF19.6080401@arin.net>

Unable to join us in Albuquerque for ARIN XX?  If so, and you?re 
frustrated at the thought of missing the policy discussions  and other 
interesting presentations, we have a solution for you! In its continuing 
effort to provide  the community with an open forum, ARIN is offering a 
live webcast of the entire  ARIN XX Public Policy and Member Meeting. In 
addition to the policy  discussions, you?ll be able to hear the NRO 
Number Council candidate speeches  on Wednesday morning and the Board of 
Trustees and Advisory Council candidate  speeches on Friday morning.

ARIN also invites individuals who cannot attend the  meeting in person 
to participate remotely. Remote participants may e-mail  questions and 
comments to be addressed in normal question and answer periods 
throughout the agenda.

To register for remote participation, please visit 
http://www.arin.net/ARIN-XX/. Click the  "Meeting Registration" button 
at the top of the page, choose  "ARIN XX Remote Participant" from the 
drop-down box, and complete the  form. The live meeting webcast is 
available without registering as a remote  participant.

All remote participants are subject to the Remote  Participation 
Acceptable Use Policy (AUP). Additional information about remote 
participation and the webcast, including the Remote Participation AUP, 
is  available at:
http://www.arin.net/ARIN-XX/webcast.html

Detailed information on how to access the meeting  webcast will be 
posted through the URL above before the meeting. There are a  variety of 
formats in which the meeting webcast will be streamed, and the broadcast 
will begin Wednesday, 17 October 2007 at 9:00 AM MDT (UTC/GMT -7 hours). 
For details on what types of feeds are available, please see the URL  above.

Regards,
Member  Services
American Registry for Internet Numbers (ARIN)