[arin-ppml] Draft Policy 2009-1: Transfer Policy - Revisedandforwarded to the Board

[Kevin Kargel]

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Lee Howard
> Sent: Thursday, May 07, 2009 9:37 AM
> To: William Herrin; Martin Hannigan
> Cc: arin ppml
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy -
> Revisedandforwarded to the Board
> 
> 
> 
> > No. I'm saying that the ones who deliver stateful firewalled service
> > to a large base of customers using global IPs instead of private IPs,
> > and who deliberately built it that way just in the last couple of
> > years did so knowing the score.
> >
> > The number of service providers delivering that kind of service is
> > relatively small but scope of some of those services is quite large.
> > And some of them are hoarding.
> 
> Which of these statements better reflects your position?
> If an organization can use NAT44, they SHOULD.
> If an organization can use NAT44, they MUST.
> 
> Do we need a policy proposal requiring NAT44, or requiring
> demonstration why NAT44 can't be used?
> 
> Lee
> 

We have had this discussion before and beat it soundly to death.  A great
many organizations (such as ISP's) cannot successfully deploy NAT to their
customers.  Reasonable configurations of NAT break many p2p applications
that are demanded by customers.  

Residential customers demand that now common applications such as IM file
transfers, p2p file sharing (not always bad or illegal), VOIP, remote
desktop all work without needing to do custom configurations or silly router
tricks.  The customers demand that these things work out of the box.

Also remember that what we commonly call NAT is actually PAT, and operates
differently.

A single PAT at a residential installation where no more than one instance
of an application will be running will work with minimal configuration.  The
rub comes in when you try to put dozens, or even thousands of customers who
could all be running the same application behind one IP address.  This can
be resolved by putting RFC1918 addresses behind a pool of public addresses
in a 1-1 relationship, but then there is no conservative gain.

Can tech savvy customers do custom configurations so that these apps work?
Sure.  Are they willing to do so?  Nope.  Will they take their business next
door where it will work?  You bet.

NAT is a reasonable conservation solution for corporate enterprises, but not
globally for end user transit providers (ISP's).  ISP's are huge consumers
of IPv4.    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090507/cabb29a4/attachment.bin>