# Conceptual design of networking fundamentally flawed?

## ManDay

I can't help it but wonder whether the current design of TCP/IP et al is, given the possibilities we have, a rather obvious misdesign.

I'm specifically thinking of NAT and address-range limitation.

Reading about it on Wikipedia, the complexity of NAT appears somewhat unlimited.

In practice, the most commonly encountered problem is possibly that of me, being given one IP-address by my ISP and using that for a NAT router (+ modem + AP).

Now it becomes impossible for others to initiate connections to one of the computers behind the NAT without me explicitly forwarding the desired port(s) to that one host (if that's not true, I'd be keen to know what other possiblities I have). In any case, I'd need to configure the router specifically for that job (same here, if that's not true...).

Taking SIP (Session Protocol for Telephony), with which I was struggling last as an example:

Given an adequate transport, it should be no problem for Host A behind the NAT to speak to the SIP Service Provider, telling it "A registering for SIP at <public IP>. I am computer X behind that public IP". Other hosts should then, theoretically, have no problem to initiate a connection on their behalf (just as if A had been given an own IP).

Given an adequate transport, the amount of IPs should be unlimited.

But intead, to the present day, I haven't got SIP to work behind a router to which I do not have admin access - although that router is in no way meant to function as a firewall whatsoever. I must frankly say, I find that a rather pathetic design, given what should be possible with just a sufficiently designed (and implemented, of course) protocol.

Am I to blame here or is this really such fundamental shortcoming in design that still couldn't be alleviated?

----------

## javeree

You're not to blame: it's a fundamental 'flaw' in the addressing scheme. It's as if you have many peole living in a building and only a single letterbox. 

You cannot blame the mailman for not delivering each letter to the individual adressee. It's up to one of the inhabitants to look at the names on the envelopes (the ports) and decide who to give the letter to. If there happen to live two people with teh same name in the building, bad luck.

Is it a flaw ? Not really if you understand NAT as a workaround for something that was not initially foreseen in the protocol. It was assumed that each PC would get its own address, and that there were enough adresses.

IPV6 is supposed to cure this, but I would not be surprised if after moving to IPv6, you would still get a modem from your ISP that does some kind of NAT (just to keep you limited in what you can do and to guide you toward a more pricey upgrade  :Smile: )

----------

## ManDay

Thanks for reassuring me that this is not a mistake on my side. Going with the "letterbox" analogy (which, perhaps, you did not mean to go as far), the mailman *does* have means to "initiate" connections to the inhabitants. The inhabitant does not "reserve" himself a box in advance (as with forwarding ports).

Equally, where is the problem in contriving a protocol within the TCP/IP frame (assuming we don't want to "fix" TCP/IP - which appears to be the actual thing that should be done) which allows to identify each host in the adjacent network by yet another unique ID.

So the TCP/IP is adressed at 1.2.3.4 and (again, unfamilar with the exact specs of TCP/IP, assuming that there is no way to convey the following information as part of the TCP/IP header) specifying, in a nested protocol, that the package is meant to go to a computer identified by an ID unique to the adjacent net, say 192.168.1.2 or "mandayPC"?

Of course, the router's firmware would need to be patched, but this would be the smallest of all problems.

Edit: And in cases where the router cannot be modified, a host within the adjacent net may receive all those packages and do the forwarding to the respective hosts.

----------

## ManDay

Thanks for reassuring me that this is not a mistake on my side. Going with the "letterbox" analogy (which, perhaps, you did not mean to go as far), the mailman *does* have means to "initiate" connections to the inhabitants. The inhabitant does not "reserve" himself a box in advance (as with forwarding ports).

Equally, where is the problem in contriving a protocol within the TCP/IP frame (assuming we don't want to "fix" TCP/IP - which appears to be the actual thing that should be done) which allows to identify each host in the adjacent network by yet another unique ID.

So the TCP/IP is adressed at 1.2.3.4 and (again, unfamilar with the exact specs of TCP/IP, assuming that there is no way to convey the following information as part of the TCP/IP header) specifying, in a nested protocol, that the package is meant to go to a computer identified by an ID unique to the adjacent net, say 192.168.1.2 or "mandayPC"?

Of course, the router's firmware would need to be patched, but this would be the smallest of all problems.

----------

## Hu

 *ManDay wrote:*   

> Thanks for reassuring me that this is not a mistake on my side. Going with the "letterbox" analogy (which, perhaps, you did not mean to go as far), the mailman *does* have means to "initiate" connections to the inhabitants. The inhabitant does not "reserve" himself a box in advance (as with forwarding ports).

 The provision is to send a SYN to the IP+port pair representing the recipient.  If the recipient does not have a publicly recognized IP+port pair, then the recipient cannot directly receive unsolicited traffic.  This is a fundamental limitation of NAT.  If the recipient takes actions which allow the NAT device to expect a response, then the NAT will route those responses.

 *ManDay wrote:*   

> Equally, where is the problem in contriving a protocol within the TCP/IP frame (assuming we don't want to "fix" TCP/IP - which appears to be the actual thing that should be done) which allows to identify each host in the adjacent network by yet another unique ID.

 Could you explain why you think either TCP or IP is to blame here?  Your ISP has intentionally supplied you with a broken configuration (one address, multiple machines), and now protocols which expect a working configuration (each Internet connected machine has a publicly unique address) fail.  Adding another address within the frame is an ugly hack.  Assigning a properly routable address at the IP layer is the correct solution.  That is exactly what IPv6 promises to do.

 *ManDay wrote:*   

> So the TCP/IP is adressed at 1.2.3.4 and (again, unfamilar with the exact specs of TCP/IP, assuming that there is no way to convey the following information as part of the TCP/IP header) specifying, in a nested protocol, that the package is meant to go to a computer identified by an ID unique to the adjacent net, say 192.168.1.2 or "mandayPC"?
> 
> Of course, the router's firmware would need to be patched, but this would be the smallest of all problems.
> 
> Edit: And in cases where the router cannot be modified, a host within the adjacent net may receive all those packages and do the forwarding to the respective hosts.

 This is a terrible idea.  Although NAT is not designed to act as a firewall, many users have come to rely on that behavior.  Providing a way for external hosts to intentionally access specific internal machines breaks that assumption.  Many users do not adequately firewall their internal machines, because they believe the edge device will keep them safe.

----------

## wcg

 *Quote:*   

> Now it becomes impossible for others to initiate connections
> 
> to one of the computers behind the NAT without me explicitly
> 
> forwarding the desired port(s) to that one host

 

That is a feature, in my view. The last thing I want is external machines

being able to contact my workstation directly on their initiative. My cpu

load for iptables would be through the roof.

We don't typically see it on Linux, because our workstations do not

pop up windows whenever some remote host probes us with a udp

packet. I was helping someone with a new XP installation on a laptop

that had AOL installed and a dialup modem, however. The first time

he logged in, popups showed that probe packets from remote

spamhosts were coming several times a second, on all manner of

ports. (Finally I got zonealarm installed on it, blocked all that stuff,

and told it to lose the alerts on remotely initiated connect attempts,

which provided some relief.)

If I connect to a remote server first and expect an ack, that is a different

situation. The incoming packets are not unsolicited.

When I first read the IPv6 address spec in an RFC, it seemed like it

had a "DOS memory hole" in the address space, meaning that the

address bits in the IPv6 address were not contiguous. WTF?

Why not put the metadata for the packet at one end and the address

bits at the other? If we need to add more metadata for some as yet

unknown purpose, add another octet or two at that end, and if we need

more address space, add another octet at the other end.

Seemed obvious.

----------

## Ant P.

 *wcg wrote:*   

>  *Quote:*   Now it becomes impossible for others to initiate connections
> 
> to one of the computers behind the NAT without me explicitly
> 
> forwarding the desired port(s) to that one host 
> ...

 

If you're concerned about TCP RST packets becoming an extreme CPU load on your PC, maybe it's time to upgrade it to something faster than that 100MHz router that's currently handling the same load for your entire LAN...

----------

## wcg

 *Quote:*   

> 100MHz router that's currently handling the same load for your entire LAN

 

Right now my cpu load for iptables is microscopic, because the router is handling

all (ok, most; there are a couple of windows machines on the lan; when they get

cracked is unpredictable) of those unsolicited packets in hardware. Why throw away

cpu cycles on my workstation so that I can use a dumber router, no matter how

many cpu cycles it has to spare?

----------

## Genone

 *ManDay wrote:*   

> Thanks for reassuring me that this is not a mistake on my side. Going with the "letterbox" analogy (which, perhaps, you did not mean to go as far), the mailman *does* have means to "initiate" connections to the inhabitants. The inhabitant does not "reserve" himself a box in advance (as with forwarding ports).

 

The letterbox was an analogy for an IP address, not a port, but it's a bad analogy anyway.

 *Quote:*   

> Equally, where is the problem in contriving a protocol within the TCP/IP frame (assuming we don't want to "fix" TCP/IP - which appears to be the actual thing that should be done) which allows to identify each host in the adjacent network by yet another unique ID.

 

TCP/IP has been "fixed" for that problem in the way of IPv6, however it's taking a long time for that to be rolled out (for various reasons). Changes to network protocols are a very sensitive subject due to the number of involved parties.

 *Quote:*   

> So the TCP/IP is adressed at 1.2.3.4 and (again, unfamilar with the exact specs of TCP/IP, assuming that there is no way to convey the following information as part of the TCP/IP header) specifying, in a nested protocol, that the package is meant to go to a computer identified by an ID unique to the adjacent net, say 192.168.1.2 or "mandayPC"?
> 
> Of course, the router's firmware would need to be patched, but this would be the smallest of all problems.

 

The router firmware, the server OS, the client OS, and that for anyone/anything potentially using that extension. You start to see the not-so-small deployment problem now? Not even thinking about compability issues, added complexity causing more problems, special case handling, ....

----------

