[arin-ppml] Stepping forward, opening my mouth and removing all doubt about

Tom Vest tvest at pch.net
Thu Aug 28 11:03:21 EDT 2008

On Aug 28, 2008, at 10:12 AM, William Herrin wrote:

> On Thu, Aug 28, 2008 at 1:07 AM, Ted Mittelstaedt <tedm at ipinc.net>  
> wrote:
>>> Is it your position that more than 10% of those users would
>>> be inconvenienced by having an RFC 1918 address behind a NAT
>>> box instead?
>> No, however the issue is that with those large ISP's almost
>> certainly a percentage of their customers are running some app
>> that is dependent on a public IP.
> My guess puts it at 3% to 5% but let's use 10% for our calculations
> just to be on the safe side. That's the maximum number of folks choose
> to use applications which either fail or function suboptimally when
> behind a typical NAT firewall.
>> The large ISPs do not want
>> to have to deal with the thousands of irate phone calls that
>> would result out of their million+ customer base if they
>> just arbitrairly switched people over to private IP numbers.
>> Now, this does not mean that they couldn't do a gradual
>> switchover, I agree.  But I don't agree that it is for
>> us to force them to do it.
> A liberalized transfer policy doesn't force anyone to do anything.
> What it does do is enable an ISP to reap a benefit from making the
> effort to use RFC 1918 addresses.
>> BUT - the fact of the matter is that stateful inspection
>> of packets through a firewall shouldn't require this icky
>> disgusting rewriting of source IP addresses.  NAT is a
>> transition technology and it has a lot more years left in
>> it, but we cannot lose sight of the fact that it is a hack,
>> despite our amazement that the elephant can actually dance.
>> And you do not lay the foundations of a stable Internet
>> on a hack.
> Actually, that icky rewriting is a benefit from a network security
> perspective. NAT has a tendency to fail closed while non-translating
> firewalls have a tendency to fail open.
> But that's beside the point. No one is extolling the merits of
> ditching IPv6 in favor of a NAT-based Internet. What we are saying is
> that it is essentially impossible to achieve sufficiently ubiquitous
> IPv6 deployment in the next 3 years as to allow IPv6-only deployments
> to customers. Ain't gonna happen. Get past it and realize that however
> fast or slow IPv6 is deployed, we're going to need an interim solution
> so that until the long term solution is ubiquitously usable the folks
> who -can't- engineer their systems to use NAT still have a viable way
> to get IPv4 addresses.
>> Your asking my generation to committ a terribly immoral act
>> by making the very fabric of the Internet dependent on a cheap
>> hack.
> Providing a working interim solution between depletion of the IPv4
> free pool and whatever long term solution comes next is an -immoral-
> act? That is an astonishing claim.
> On Thu, Aug 28, 2008 at 8:50 AM, Iljitsch van Beijnum
> <iljitsch at muada.com> wrote:
>> Making IPv4 tradable means that our trajectory towards the wall  
>> will change
>> in ways that we can't predict.
> We went through this pretty extensively last year. Control of IPv4
> addresses can be legitimately traded now using The Ruse and The
> Container Sale. No one is proposing that we suddenly make IPv4
> tradable; for all practical purposes it already is. One point of a
> liberalized transfer policy is to give ARIN better control over the
> trading process so that the community can avoid the more egregious
> abuses (like heavy disaggregation).

Hi Bill,

Could you provide pointers to where this was discussed extensively  
last year?
I've tried to point out some potential issues at the mike or on this  
list since 2008-2 was introduced, but I don't recall much related  
discussion going back that far.

I also don't think that many of the concerns that I have raised have  
been addressed fully, much less discredited.

I still don't understand how one reconciles the two conflicting  
beliefs (a) that a transfer policy is essential because people will  
violate any transfer restrictions if that serves their private  
interests, and (b) transfer participants will comply with all transfer- 
related policy restrictions even if they if they conflict with their  
private interests. Why does that make sense?

My impression is that the proposal counts on the benefits of ongoing  
RIR registration and whois to haul most of the freight -- i.e., to  
keep transactions within the regulated channel, to assure ongoing  
compliance after transfers have occurred, etc. That faith seems a  
little incongruous today, given the fact that whois is widely assumed  
to be full of cruft, and to have been even worse before RIR mechanisms  
like subsequent allocation reviews and annual renewal fees helped to  
establish some basis for evaluating even minimum accuracy --  
conditions that will be roughly similar to the post-runout world. The  
mixed views that some express about resource certification leave the  
impression that some people still view whois and identifiability in  
general (or beyond bilateral relationships with direct peers,  
customers, and providers) as more of a liability than an advantage.

Matters would probably be dramatically different if res cert was  
already widely accepted, adopted, and clearly/solidly anchored at some  
level where ongoing uniqueness and public identifiability was assured,  
but since it's not I don't think it can be or should be assumed as a  
feature of the transfer market at this point.



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

More information about the ARIN-PPML mailing list