ietf
[Top] [All Lists]

Re: Last Call: RFC 6346 successful: moving to Proposed Standard

2014-12-10 20:18:39
On 12/10/2014 06:31 PM, Ted Lemon wrote:
On Dec 10, 2014, at 7:39 PM, Doug Royer <douglasroyer(_at_)gmail(_dot_)com> 
wrote:
What about legacy software that decides what port it is going to use?
Well their packets go to the wrong hardware? Seems a BIG security hold to me.
This is equivalent to the current practice of giving a home gateway an IP 
address with all 64k ports.   These ports are _already_ shared by devices 
behind the NAT.   The difference with port sharing is just that you start out 
with fewer than 64k ports.   Legacy software of the type you describe already 
doesn't work with a NAT.


Maybe I misunderstand what I read. Currently say I have 80 hosted server each with its own IP address Each uses port 25 (smtp), 143 (imap), 80 (http) 22 (ssh) , 443 https), 465 (smtp), 587 (smtp), 10000 (webmin) , and 20000 (usermin). The host name are say 80 random host names. Some use port 5432 (postgres), some port 3306 (mysql). And others use other random ports.

My hosting provider decides to follow this spec and assigns them all to ip address 1.2.3.4 and map
the port numbers across a 80 ranges, each with at least 9 assigned ports.

So How do say http://random-host-name-xx from a browser and have it work?
It would return 1.2.3.4 with dns, so 100% of *all* browser software would need to be updated to get the port extension to determine it really should go to http://randm-host-name-xx:1234 ?

The site admin is not going to have to know the 80 different port numbers for webmin (old port 10000) ?

I can't see how changing almost all Internet software is going to move faster than waiting for IPv6.

The current text also says double nats should be avoided. Do people know that a HUGE amount of home Wifi devices are NATs behind their router (NAT) and possibly behind their ISP NAT ?

Please tell me I misunderstand the text.

--

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
DouglasRoyer(_at_)gmail(_dot_)com
714-989-6135


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

<Prev in Thread] Current Thread [Next in Thread>