Re: Some unanswered questions from January 2011 [telecom]

On , 21 Jan 2012 04:53:51 +0000 (UTC) snipped-for-privacy@bimajority.org (Garrett Wollman) wrote,

> >Garrett Wollman wrote: > > > >> Codecs that couldn't do this were rejected as unsuitable. > > > > ... which kind of brings me back to the original question: if codecs > >that don't handle dropped datagrams gracefully were discarded as > >unsuitable as streaming evolved, why the heck wasn't SIP discarded as > >unsuitable for VoIP when it became apparent that it was not going to > >play well with NAT? > >Your question works just as well the other way around, and NAT has the >additional disadvantage that it's Clearly, Deeply, Architecturally >Wrong, And Besides It Can't Possibly Work Once Everyone Uses IPsec.

Joining in the disagreement... NAT is architecturally Right. It is only Wrong in the fundamentalist sense that, say, global warming can't be occurring because it's not explicitly described in the King James Bible. The IETF is somewhere to the right of the Taliban when it comes to rigidity.

NAT only breaks broken applications. If applications are layered correctly, then an IP address is merely a local-to-its-layer construct. Applications should use names, not IP addresses.

There's a fundamental flaw in the TCP/IP architecture where the application does the DNS lookup. Thus the canonical name of the application is the IP address + Port, hence a 48-bit value. That's sort of foolish. Interface address + Port *as an application name* was meant as a temporary hack on the ARPANET in the early 1970s until the upper layer naming could be worked out, but that wasn't funded by ARPA, and somehow users got the notion that it was all handed To Moses On Sinai.

But it's even more foolish to not allow that 48-bit address to be swapped for another one en route, just as many other protocols have local connection IDs. Frame Relay, for instance, has a local DLCI; you can be DLCI=100 at one end and 200 at the other. NAT applies the same thing to the 48-bit name. Fine. It only fails if the IP address is inside the application protocol, where it doesn't belong.

FTP did it (in the early 1970s) for a very specific reason, but that should not be used as a model. The reason is no longer applicable. (Anybody else here know the reason? I'll withhold it for now.)

The correct answer, of course, is to phase out TCP/IP and move to RINA (see

formatting link

/). It recurses the same layer-machine (the DIF) as many layers as needed, no more no less. The DIF has two protocols, one doing the error and flow control (EFCP) and one doing the application (CDAP). so those are the only two protocols. Relaying (passing the packet along in real time) and routing (building the table used for relaying among peers) are applications; the application of a low layer is to relay stuff so it can reach a higher layer user. (That's what happens now; RINA just recognizes that to each layer, it is really an application.) The "address" is local to the layer, but the application-name propagates all the way down. Encryption is a capability of the DIF, so nobody can see what's above it in the stack (no DPI possible). This is clean, secure, scales infinitely, and does multicasting, mobility and mulithoming cleanly (because the name dynamically binds to a set of destinations).

IETF is still pretending it's the 1980s, that its ARPANET is under attack from the PTTs with X.25, that the main applications are TELNET, FTP, SMTP and NNTP, and that they have to defend some imaginary "end to end principle" that pleases their gods. So they're pushing that misbeggen monster, IPv6, which tastes bad and is more filling. Pathetic.

-- Fred Goldstein k1io fgoldstein "at" ionary.com ionary Consulting

formatting link

+1 617 795 2701