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

Re: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt

I think the new text is better than the old, but the caveat isn't a NAT caveat, it is an IPSEC caveat. Yes, while IPSEC's tunnel mode could be implemented using an IP header and an IPSEC header (HAIPE, for example, which is an encryptor and *not* a NAT), it is common to include a UDP or TCP header as well. That is an *IPSEC* issue. People that use tunnel mode do so because they have chosen to hide their topology. When they convert to IPv6 (HAIPE version 3.0 for example), encryptors will continue to use tunnel mode for the same reason, and will do so inside IPv6.
I would suggest that this document reserve its negative commentary for NATs, not scattershot for other protocols, and that it not attempt to deprecate tools that people will be continuing to use. The purpose of the note was to demonstrate how to best achieve things- people-use-NATs-for using IPv6 without using NATs. I'd suggest it stick to that. 



On Jul 25, 2006, at 1:06 AM, Jari Arkko wrote:

Fred,

Are you suggesting changing the text below in some
manner? It seems that this point is still covered under
the works in some cases/does not work in all cases
language.

(By the way, it is my belief that IPsec NAT traversal UDP
encapsulation is used commonly even for tunnel mode VPN
connections, for various reasons. The primary reason is
that when there are multiple clients behind the same NAT,
the NAT is unable to determine where a particular return
packet should go to -- the SPIs are different in different
directions and their negotiation is encrypted so the NAT
can't peek into the packet to find out. You can guess, but
there is no guarantee that this always works.)

--Jari

Fred Baker wrote:
for the record, this is only true of transport mode. tunnel mode works 
just fine in IPv4, and I have every reason to believe that it will
continue to do so in IPv6. I use tunnel mode a lot, including at IETF
meetings.

On Jul 23, 2006, at 12:42 PM, Jari Arkko wrote:
4.2 -2 does not oversell IPsec, it simply states the real situation. 



I'm not going to hold your document based on the -03 text, but
I would still suggest the following edit:

While IPsec might be available in IPv4
implementations and works the same way, deployment in NAT
environments either breaks the protocol or requires complex
helper services with limited functionality or efficiency.
=>
While IPsec is commonly available in IPv4 implementations
and can support NATs, NAT support has limitations and
does not work in all situations. In addition, the use of IPsec
with NATs consumes extra bandwidth for UDP encapsulation
and keepalive overhead.