Subject: Re: [BEHAVE] Dynamic Port Reuse

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 2 Jun 2008 10:27:28 -0500

If I understand him correctly, I just want to reinforce what Dan's saying 
here...

We've been doing port-agile protocols for years. It just seems wrong to me 
that suddenly paying MORE attention to port numbers now is the right thing 
to do, especially if this algorithm gets stuck in the next generation of 
Linksys boxes that we then can't upgrade until the year 2525...

Given that there is a positive incentive for protocols to lie ("of COURSE 
I'm HTTP, why else would I be running on port 80 where the firewalls are 
passing traffic"), I don't expect this to end well.

I wish I had a better suggestion, of course.

Spencer

> Using port numbers is, itself, non-deterministic.  This is because
> no two people will generate the same list ports that are safe to
> re-use.  If ports are used, then in 3 years, as NAT64 vendors find
> value in optimizing re-use of other port numbers, the vendors will
> begin diverging which ports are re-used.
>
> For example, here would be my list of ports that are safe to re-use:
> TCP/80 (HTTP), TCP/110 (POP3), TCP/995 (POP3S), TCP/143 (IMAP), TCP/587
> (SUBMIT), TCP/25 (SMTP), TCP/22 (SSH), TCP/21 (FTP), TCP/23 (TELNET),
> TCP/7 (ECHO), TCP/9 (DISCARD), TCP/993 (IMAPS).
>
> Are there non-IETF protocols that are used which would break with
> port re-use?  That is, that use UNSAF or use TCP S-O?
>
>
> As BitTorrent has not registered their ports with IANA, I'm not sure
> what could be said in an IETF document about its ports other than
> some non-normative "and other ports that the NAT64 believes, to the
> best of its knowledge, are used by client/server applications that
> can safely have their TCP source ports re-used."  Which brings us
> to specify non-deterministic behavior for such a NAT64.
>
> -d
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
> 

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 3 Jun 2008 00:08:59 +0200

> Linksys boxes that we then can't upgrade until the year 2525...

We're talking about NATs that must scale to support thousands of users  
by having more than 64k sessions per public IPv4 address... I don't  
think Linksys makes these.

> passing traffic"), I don't expect this to end well.

In this case, there is no incentive for lying other than to do a  
denial of service on the NAT if the vendor didn't think to include per- 
user limits.

Ideally, we'd create a bunch of port numbers for applications that  
don't need endpoint independent addressing and another bunch of port  
numbers for applications that do. Unfortunately most applications have  
already settled on a well known port.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 2 Jun 2008 16:18:26 -0700

On Monday, May 26, 2008 1:38 AM, Lars Eggert wrote:

> sure, but we might be able to free up IPv4 addresses that so 
> far have been allocated to end users and use them to support the 
> NAT64 boxes.  Unless users end up having 65K connections active, the 
> NAT will be more efficient at multiplexing, and there'll be a win.
> 
> I'm curious to know if you'd think that this scenario isn't realistic?

If that scenario becomes the reality it is true that we would not need 
to worry about schemes to aggressively re-use TCP ports.

I would expect that if an ISP changed to providing IPv6-only connectivity
for its subscribers and installed some kind of NAT64 functionality so
those subscribers could still get access to the v4 Internet, that ISP
itself would have plenty of v4 addresses to assign to its newly-installed
NAT64 boxes -- because it just freed a bunch of v4 addresses from 
its subscribers and can re-use those addresses on its NAT64 boxes.

However, an ISP that does not already have a bunch of v4 addresses would
need to obtain a bunch of v4 addresses for its newly-installed NAT64 
boxes, and would be interested in reducing the number of v4 addresses
it would need to obtain for those NAT64 boxes.  Such an ISP would be
interested in aggressive TCP port re-use.

-d

---

From: Christian Huitema <[email-masked]>
Date: Mon, 2 Jun 2008 16:32:01 -0700

> interested in aggressive TCP port re-use.

So, if that is what we are focusing on, we should maybe say so. An IPv6 ISP has many options, and IPv6-IPv4 NAT is only one of them. For example, the ISP might run a Teredo relay, effectively reducing the pressure to use NAT translation for peer-to-peer applications. It may also run a 6to4 relay...

-- Christian Huitema

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 2 Jun 2008 17:02:17 -0700

> So, if that is what we are focusing on, we should maybe say 
> so. An IPv6 ISP has many options, and IPv6-IPv4 NAT is only 
> one of them. For example, the ISP might run a Teredo relay, 
> effectively reducing the pressure to use NAT translation for 
> peer-to-peer applications. It may also run a 6to4 relay...

Those seem reasonable approaches if the ISP's subscribers have
v6-capable hosts.  Or were you considering putting Teredo or 6to4
into the subscriber's CPE, so that a v4-only subscriber would -- 
unbeknownst to them -- be getting access to v4 via their CPE's
new functionality?

-d

---

From: Christian Huitema <[email-masked]>
Date: Mon, 2 Jun 2008 17:36:54 -0700

> unbeknownst to them -- be getting access to v4 via their CPE's

One has to assume that if an ISP is going "IPv6 only", a significant fraction of its subscribers will be IPv6 capable. If that was not the case, one could question the business sense of the ISP...

-- Christian Huitema

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Jun 2008 08:37:13 -0700

> One has to assume that if an ISP is going "IPv6 only", a 
> significant fraction of its subscribers will be IPv6 capable. 

It is my understanding that many subscribers have equipment or
application software that cannot become v6 capable (it cannot be 
upgraded, or the user does not want to upgrade it [cost, fear of
upgrade, lack of a neighbor kid or nephew to assist with the
upgrade]).

> If that was not the case, one could question the business 
> sense of the ISP...

The goal, as I understand it, is to provide subscribers a service
that looks, feels, and smells like the subscriber's current v4
Internet service.  In this way, the subscriber's current v4
hosts and applications will work in much the same way as today.

-d