headers
Spencer Dawkins | 2 Jun 2008 17:27

Re: Dynamic Port Reuse

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?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Iljitsch van Beijnum | 3 Jun 2008 00:08
Favicon

Re: Dynamic Port Reuse

On 2 jun 2008, at 17:27, Spencer Dawkins wrote:

> 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...

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.

> 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.

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.
Permalink | Reply | 0 comments |
headers
Dan Wing | 3 Jun 2008 01:18
Picon
Favicon

Re: Dynamic Port Reuse

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
Permalink | Reply | 4 comments |
headers
Christian Huitema | 3 Jun 2008 01:32
Picon
Favicon

Re: Dynamic Port Reuse

> 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.

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
Permalink | Reply | 3 comments |
headers
Dan Wing | 3 Jun 2008 02:02
Picon
Favicon

Re: Dynamic Port Reuse

> > 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.
> 
> 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
Permalink | Reply | 2 comments |
headers
Christian Huitema | 3 Jun 2008 02:36
Picon
Favicon

Re: Dynamic Port Reuse

> > > 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.
> >
> > 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?

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
Permalink | Reply | 1 comment |
headers
Xavier Marjou | 3 Jun 2008 10:42

Re: Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt

This mail tries to sum-up the conversations of the WGLC and makes
proposals for a next update of the draft.

1 - 0 bytes packets:
There's a need to merge sections 4.1 and 4.2 and to generalize the
section for any RTP-capable transport protocol.

2 - static payload
There is no consensus to accept a static payload number for
rtp-keepalive, so the draft will keep a dynamic payload type.

3 - Advertisement of rtp-keepalive with SDP
There's some interest to declare support for rtp-keepalive in the SDP.
Do we want to make it mandatory or recommended?

Note that doing so requires the registration of additional media types
(like audio/rtp-keepalive, video/rtp-keepalive, and
text/rtp-keepalive, application/rtp-keepalive). In addition, it should
also be noted the indication for rtp-keepalive support within an SDP
offer is a declarative usage only, as the the local agent will use
rtp-keepalive even if the peer does not support this format in the SDP
answer.

4 - Security issues
There's a need to discuss that RTP keepalive packets may be perceived
as an attack by the peer and that the peer needs to react as described
by RFC3550 by ignoring them.
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 3 Jun 2008 17:37
Picon
Favicon

Re: Dynamic Port Reuse


> 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
Permalink | Reply | 0 comments |
headers
Bruce Lowekamp | 3 Jun 2008 20:25

Re: Degree of compatibility of BitTorrent with endpoint-independent mapping?

Iljitsch van Beijnum wrote:
> On 26 mei 2008, at 22:32, Bruce Lowekamp wrote:
> 
>> To the best of my knowledge (and I have not studied BitTorrent
>> implementations extensively), they don't try to make any allowances for
>> NAT behavior because there are enough hosts for which that is not an
>> issue that the applications work if they try enough connections.
> 
> No, that's not exactly true. In practice, you get much lower download 
> speeds with BitTorrent if you can't accept incoming connections. So 
> (some) clients implement UPnP and NAT-PMP to open up ports for incoming 
> sessions in the NAT, if present. It's also very common for BitTorrent 
> users to set up a mapping manually.
> 
> So BitTorrent does often use NAT traversal, just not with any of the 
> mechanisms that the IETF is familiar with.  :-)
> 

You're right, I was thinking about techniques other than NAT control.

More importantly, though, neither of those techniques work with 
multi-level NATs (or NATs on the other side of routers), so aren't 
really appropriate for the problem domain we're talking about here, as I 
understand it.  Now I suppose we could work more on extensions to NAT 
control protocols, but I don't know if those would be well received in 
the ISP space.  I wasn't involved in the midcom wg.  Maybe things have 
changed, though...

>> If NATs become even more common than they are now, BitTorrent
>> applications may need to do more NAT traversal, so then TCP-SO would be
(Continue reading)

Permalink | Reply | 3 comments |
headers
Saikat Guha | 3 Jun 2008 20:49
Picon
Favicon

Re: Degree of compatibility of BitTorrent with endpoint-independent mapping?

On Tue, Jun 3, 2008 at 8:25 PM, Bruce Lowekamp <lowekamp <at> sipeerior.com> wrote:
> Iljitsch van Beijnum wrote:
>> On 26 mei 2008, at 22:32, Bruce Lowekamp wrote:
>>> If NATs become even more common than they are now, BitTorrent
>>> applications may need to do more NAT traversal, so then TCP-SO would be
>>> more important.
>>
>> I don't see simultaneous open happen for BitTorrent very soon. They may
>> switch to UDP instead.
>>
>
> I suspect that if it worked reliably, it would be used.

FWIW, the stumbling block of using TCP traversal per Bram Cohen was
the active signaling plane (where the tracker would have to relay the
ICE or equiv. messages). UDP traversal is simpler in that (for many
NATs -- NB=I, EF=I) once you punch one hole, you can keep that hole
open indefinitely and publish the hole address in the tracker.

If someone can implement a BT tracker that performs the ICE relaying
at scale, I am sure BT clients would switch in a heartbeat.

--

-- 
Saikat
Permalink | Reply | 0 comments |

Gmane