RE: Towards closure on NAT traversal.

["Tony Hain" <alh-ietf@tndh.net>]

Hallam-Baker, Phillip wrote:
> Wait for IPv6 is not an acceptable solution. If nothing is
> done until IPv6
> is deployable the vendors will long since have taken their
> IPSEC standards
> business to another forum.

I am simply pointing out that IPv6 will be there well before this group
can figure out a solution that works with the deployed NATs, agree on
all the details, implement them, and deploy. In some parts of the world
IPv6 is being deployed today, so just because you don't see it happening
in your area is no reason to take the toys to another forum.

>
> You appear to be arguing that
> 	1) The group should do nothing to accomodate NAT
> 	2) The proposal to provide minimal accomodation of NAT is
> insufficient.
>
> So which is it? Both arguments may point to 'do nothing' but they are
> inconsistent. When I see that type of bifurcated argument being made I
> suspect that the true position is 'I don't want to accomodate
> NAT in any
> circumstance whatsoever but I will be opportunistic in my arguments'.

Try; the set of applications to be addressed (all client side) is
inadequate, and this group should give requirements to MidCom for IPv4
capabilities, but otherwise rely on IPv6. Wasting time in yet another WG
on figuring out how to work around NAT is a bad idea, so the IESG should
revisit the IPsec WG charter.

>
> NAT introduces some intrinsic problems with any protocol that
> opens up a
> listening port. IPSEC will inevitable screw up sone of the kludges and
> work-arrounds out in the wild. I don't think that is a
> problem, demand for
> IPSEC is much stronger than any of the protocols affected by
> the kludges
> that will be broken.

If demand for IPsec is really that strong, why are people still putting
in NATs when they know that it will be broken? If people really want
IPsec they can still get IPv4 addresses. Yes we need IPsec, and yes we
need to live in a world with IPv4 NAT, but those two requirements don't
mean the IPsec WG needs to be wasting time figuring out how to get IPsec
through a NAT. MidCom is working on a generic solution to the problem
for IPv4, and using IPv6 to push the entire IPv4/NAT mess down a layer
gives you a cleaner way out.

>
> The Internet may be about much more than client side HTTP and
> email, however
> if you are behind a NAT box that does not provide for a
> principled support
> for advertising a listening port to the NAT you should
> probably learn not to
> expect very much more. The problem is at that point outside
> IPSEC scope.
>

I am sorry, I thought this discussion was about traversing NAT to make
IPsec work. So it is really about how to do the easy half (and a small
subset of that), maybe it should be titled 'the client side of a few
applications NAT traversal'.

>
> IPv6 does not eliminate the need for NAT, in fact some
> companies will be
> deploying NAT to conceal leakage of ethernet MAC addresses
> and the like from
> their domain that people seem to want to encode into IPv6 addresses.

And clearly the consultants that lead them there need to be fired. There
is no requirement to encode MAC addresses, it is simply suggested as a
simple way to get a number that should be unique. If people were keeping
up rather than nay-saying IPv6 they would have noticed that RFC 3041
addresses that specific issue in a much cleaner way than NAT, and it
even works without modifications to IPsec.

>
> One of the uses of NAT is to provide an auditable means of determining
> whether the trafic on a network segment is compliant with the
> routing policy
> or not and in particular whether there is an unauthorized bridge to an
> external network in operation.

Clearly the network manager in this case doesn't understand the reality
of NAT. If that unauthorized bridge were operating behind an
unauthorized NAT that had an allowed address, the ability to detect it
would fail. Further if that unauthorized NAT from time-to-time changed
it's MAC and used DHCP (or better gratuitous arp to detect unassigned
addresses), there would be no easy way to track it down.

Tony