[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IKEv2 and NAT traversal

On Mon, 17 Dec 2001, Hallam-Baker, Phillip wrote:
> People typically deploy new versions of software because they need
> to rather than for performance alone.

Performance is sometimes a "need to" issue, especially when the issue is
not throughput but response time.

> > Uh, no.  The bug is *fixed* by larger addresses, e.g. IPv6.  NAT is a
> > kludge, a workaround, with serious disadvantages [although important]
> 
> A fix is deployable. NAT appeared because IPv6 was not deployable
> when the consequences of address depletion began to be felt.

Fixes often are not deployable immediately.  That's why we have the very
concept of a workaround! 

A fix generally provides the same functionality as the thing it is fixing.
NAT does not.  For example, it is basically impractical to put a system
with servers behind a NAT.  (Remember that "server" doesn't have to mean a
huge public utility -- the service it offers can be as minor as accepting
SMTP mail for one address.)

> > The Internet infrastructure machines at the introduction of 
> > IPv4 did not have 32-bit registers.  Try 16.  The size of the
> > IPv4 address was set by
> > considerations of design, not implementation.
> 
> According to Tom Knight who attended the relevant meeting 
> the size of the registers in a particular model of PDP was 
> used to justify the address size, against protests that it 
> was insufficient.

I think you may be misremembering what he said.  There were no PDPs with
32-bit registers.  None, ever.  12, 16, 18, and 36, yes, but not 32.  And
it's a matter of public record that the original IMPs were 16-bit machines
(and were not PDPs).

> I think that we need to focus on the parts of a protocol that
> can reasonably be expected to work through a NAT box...

Agreed.

> Nobody should expect to be able to run an FTP server over IPSEC
> that is behind a NAT box for example. But running an FTP client
> for direct retrieval is reasonable.

And equally impossible, if the packets are encrypted so the NAT box cannot
edit them.  This is a significant issue for IPsec-NAT combinations,
perhaps somewhat mitigated by the now-widespread use of HTTP for anonymous
file transfer and SSH for private file transfer.

                                                          Henry Spencer
                                                       henry@spsystems.net
References: