Re: [tae] [tsv-area] Transport negotiation

Joe Touch <touch@ISI.EDU> wrote:
> Stuart Cheshire wrote:
>> On 9 Dec, 2008, at 19:01, james woodyatt wrote:
>> 
>>> From where I stand, i.e. smack in the middle of your transport-aware
>>> packet-forwarding plane
>> 
>> Why do we want a transport-aware packet-forwarding plane?

   (I'd like to hear an answer...)

>> The primary reason NAT gateways need to peek into the transport header
>> is to get at the ports for receiver demultiplexing. 
> 
> The IP header has exactly what a NAT needs for receiver demultiplexing -
> the IP address.

   This might be true for some yet-defined IPv6 NAT: it's clearly not the
de-facto design of most IPv4 NATs.

>> It's purely a historical mistake that we forgot to put the demultiplexing
>> identifiers into the IP-layer header like other protocols do,

   "Historical mistake" is not quite right. "Hosts" were very expensive
at the time, and all indications were that the cost of a "host" couldn't
be justified unless it time-shared many applications. Thus the design to
place demultiplexing to applications within the "host".

>> which is why every IP-based transport layer has to duplicate that
>> functionality, which is why NAT gateways need to peek into those
>> transport headers.

   That's not quite right either. NAT gateways could have done 1:1
address transforms if the economics weren't driving users to conserve
IP addresses _and_ place a much smaller limit on applications per host.

> Ports are intended for demultiplexing within a host.

   Ports were _designed_ for that, but watch out for that loose definition
of "host".

   Remember, IP addresses are actually _interface_ addresses on a network
of networks. They are not, and never have been "host" addresses. It's
just as legitimate to think of them as a way into an enterprise as it
is to thing of them as a way into a "host".

> The fact that a NAT masks multiple hosts

   Now we're beginning to get in trouble with that loose definition.
>From an architectural standpoint it _shouldn't_ make any difference which
CPU an application runs on, or which physical box holds that CPU.

   The NAT design assumed an architecture in which there was routing
within an enterprise to different interfaces to different CPUs, each
of which ran very few applications. In effect, the NAT design stole
"port" bits to add to the incoming IP addresses to address particular
applications running on different CPUs within the enterprise. The IP
address itself remained an interface address of the enterprise.

> breaks port demultiplexing *by design*; NATs are intended to hide the
> fact that there are multiple hosts.

   That's only partly true. There were indeed cases where particular
ISPs wanted to charge per "computer" and the customer didn't want to
pay separate fees for each box connected to an internal ethernet. But
more often the ISP simply charged for each "IP address" and NAT makers
saw a business opportunity to exchange a "low monthly fee" for a
one-time purchase.

>> It's too late to fix the IPv6 header format, but if we regard UDP/IPv6
>> as our new combined datagram header, the way Bryan Ford proposes, then a
>> whole bunch of problems go away. It's not a deficiency of NAT gateways
>> that they need to understand every transport header (and thereby impede
>> adoption of transports they don't understand); it's a deficiency of our
>> transport headers that they include demultiplexing identifiers that they
>> should not.

   That would be a good question for discussion...

> IMO, NATs need to understand the demultiplexing that is designed to be
> internal to a host exactly because of what a NAT is and what it does. It
> doesn't make sense to be to bemoan that fact.

   I tend to agree (other than using the term "host"), but NATs in
combination do lead to confusion. The most serious problems with NATs come
when we aim for "NAT traversal" to override the intended configuration of
a NAT. This is, IMHO, simply a tussle destined to lead to escalation.

   The _archtectural_ problem with NATs is that they "need" to be marketed
as zero-configuration devices: thus very clever people are constantly
trying to write routines to guess what the configuration should be. If
they guess wrong "too often" the product won't sell; if they guess right
"often enough" some users will be frustrated when the guess is wrong.

   The proper architectural fix is to remove the need for "NAT traversal"
tricks, and have services registered in such a way that no amount of
translation of ports and IP addresses will interrupt them -- then let
"firewalls" take over the task of policing "unauthorized services" from
being registered.

   And please, don't speak as if services and computers are mapped 1:1.

--
John Leslie <john@jlc.net>
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae