Subject: RE: IPv4 depletion makes CNN

From: "Fleischman, Eric" <[email-masked]>
Date: Fri, 28 May 2010 11:07:10 -0700

You articulated the view from my knothole. Thanks!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Friday, May 28, 2010 1:29 AM
To: David Conrad
Cc: IETF Discussion
Subject: Re: IPv4 depletion makes CNN

<snip>

No, it means it is going to require double NAT unless providers deploy IPv6.
That is the message that needs to be got across.

   Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 30 May 2010 21:49:44 -0400

So we need to extend the UPNP protocol so that when the local NAT box
receives a request to open up an external port, it relays the request
to the carrier NAT.

Or we could do what we did last time and pretend that nobody will
deploy carrier grade NAT if we don't specify a way that it can work
without pain.

On Sun, May 30, 2010 at 11:02 AM, Arnt Gulbrandsen
<[email-masked]> wrote:
> On 05/30/2010 04:44 PM, Sabahattin Gucukoglu wrote:
>>
>> BitTorrent is popular, yes.  People at home *are* behind NAT boxes, with
>> all the usual pain that implies *.  It's just that BitTorrent, being a
>> straightforward TCP protocol with no embedded payload addresses **, can
>> operate behind NATs, and those NATs can be configured either manually or
>> automatically by users or their client software ***.  If the NAT should move
>> to the ISP, it seems possible that this is no longer true.
>
> Not quite.
>
> 1. Bittorrent clients connect to each other via TCP. Each connection is
> incoming at one end. Torrent clients mostly use UPNP to accept incoming
> connections.
>
> 2. UPNP is an ethernet-level protocol (it uses UDP/IP broadcasts), so it
> works only if the USER is on the public internet. Hence, NAT within the
> user's network is now very different from NAT within the ISP's network.
>
> That's why I said the wide popularity of bittorrent shows that USERS are on
> the public internet.
>
> Arnt
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 31 May 2010 13:43:06 -0400

It is a feature that should be part of the Internet base protocol
stack. It is bad enough having to work out which RFCs matter and which
should be ignored. Knowing that you have to search out to various
other organizations to find secret sauce to make it work is a recipe
for chaos.

Its bad enough having kludges like the robots.txt file in HTTP.

On Mon, May 31, 2010 at 7:59 AM, Arnt Gulbrandsen
<[email-masked]> wrote:
> On 05/31/2010 03:49 AM, Phillip Hallam-Baker wrote:
>>
> So what are you waiting for? Go ahead, read http://upnp.org, find the
> relevant WG, propose the extension, talk to implementers, you know the
> routine as well as I do.
>
> Arnt
>

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Tue, 1 Jun 2010 21:12:35 +0100

> deploy carrier grade NAT if we don't specify a way that it can work

Well, I'd be interested to know what your plan is.  Do you think we should use DNS for everything, SRV to specify the location of every service, and make port numbers insignificant?  Do you think this is better than IPv6, or that it will take any more time to deploy IPv6?  And, what do you think of the NAT scaling problem that you are proposing we mutely suffer in perpetuity?

I don't like IPv4+NAT for sure (my favourite has got to be A+P) however I really don't see anything but good coming of (A) not delaying IPv6 deployment any further and (B) making every arrangement to avoid NAT in future.  This seems to work for everybody except the end-users, for whom this whole thing is completely insignificant, who drag the market with them into a state of complacency.  They don't care.  Therefore, I think we must elongate IPv4's life as much as possible, so as to give the unfortunate time to transition, but no more.  Then, content providers and end-users can continue enjoying the 'net (albeit more slowly than usual due to all that translation load for all the usual purposes) while the faster and more capable Internet gradually transitions into use.  This is the best we can do given that the dual-stack opportunity passed over a decade ago, and even then it was important enough to commence work on what was, and I think is, the obvious (if a little imperfect) plan for the future.  That's where we stand today, everybody capable of IPv6, and nobody connected, while the red alert signs all begin to flash.

Cheers,
Sabahattin

---

From: joel jaeggli <[email-masked]>
Date: Wed, 02 Jun 2010 23:45:42 -0700

> receives a request to open up an external port, it relays the request

That's like msdp multicast state, who is going to allow you to 
instantiate it in their box?

Automated port binding requests depend on the availbility of ports and 
port numbers are a fairly scarce resource in huge nat boxes.

IGD in the context normal upnp device had at least two of not more 
properties that simply don't fly in the move from a residential gateway 
to a many gig per second cg nat box. enumeration of exsting port 
bindings (that would be comical to consider) and an assumption that the 
device requesting the port is well behaved when the device for example 
requests 500 other ports you give it those too...