Re: bidding down attach on NAT-T

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:
   
   >  In your previous mail you wrote:
   > 
   >    Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:
   >    
   >    >    How important is it for everyone to support NAT-T?
   >    > 
   >    > => I don't believe a MUST support is a good idea because this makes no
   >    > sense for an IPv6 implementation.
   >    
   >    Can we agree on "MUST support NAT-T if you support IPv4"?
   > 
   > => I am not in favor of a MUST which has nothing to do with
   > interoperability, IMHO we should let the market do its job...
   > And I don't believe implementors who still have NAT-T support
   > in their plans like to become not compliant.
   
   HUH?  What do you mean it has nothing to do with interoperability.

=> I should have put an explicit reference to RFC 2119.

   If implementations don't implement NAT-T then it wont work across a NAT.
   I would certainly call that an interoperability problem, wouldn't you?
   
=> I disagree. A MUST for NAT-T support doesn't make more sense than
a MUST for IPv6 support for instance.

   I also do not understand your last sentence.

=> easy: if a feature is mandatory then all implementations which don't
(yet) support it are (still) not compliant.

   If they are implementing
   NAT-T then they WOULD be compliant -- it's only people who DON'T
   implement who would be compliant.  Besides, this is only for implementors
   who support IPv6.  Your initial complaint about MUST was that it didn't
   make sense for v6.

=> IPv6 is an example of a real world environment where there is *no* NAT.

   I agree with that, but now you say it doesn't make sense for v4, either?

=> MUST is not about what we'd like to get, it is about what is needed
in order to get the protocol work.
   
   If we're not going to make sure that IKEv2 works across NAT, then I
   think we should just go home now.  Read after me: A road warrior has
   no choice over whether there is a NAT is between them and their home
   base.  We should support this (EXTREMELY) common case.
   
=> we disagree only about the good usage of a MUST in a standard track
document. IMHO here a MUST should not be used and even if we put a MUST
it'll have no direct effect about what we'll get in the real world.

   -derek, who has been stuck behind a NAT at TOO MANY conferences.
   
=> yes, I have no NAT at my office or at home, but conferences or
worse, interop events are places where I can keep up my hate for NATs!

Thanks

Francis.Dupont@enst-bretagne.fr

PS: from RFC 2119:

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

So NAT-T support should not get a MUST, but support of NAT-T detection
(i.e., NAT-DETECTION-*-IP (or better) stuff) should get one.