Re: Issue 24: NAT prevention details (was: Review of draft-ietf-mobike-protocol-00)

Jari Arkko <[email protected]>
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
I agree that the naming needs to change. Maybe

initiator -------------DISALLOW_NAT------------------------------->
              <-----------UNEXPECTED_NAT_DETECTED-------responder

I'm also wondering about this text in Section 2.7:

   If the values do match, the responder initializes (local_address,
   local_port, peer_address, peer_port) in the to-be-created IKE_SA with
   values from the IP header.  The same applies if neither
   NAT_PREVENTION nor NAT_DETECTION_*_IP payloads were included, or if
   the responder does not support NAT Traversal.

which would seem to indicate that if you don't include any
NAT-D payloads you get NAT-prevention by default... perhaps
this would be the right way to signal DISALLOW_NAT -- but
how would you do the comparison then?

--Jari

Bill Sommerfeld wrote:

>On Wed, 2005-07-13 at 04:25, Tero Kivinen wrote:
>  
>
>>[email protected] writes:
>>    
>>
>>>that contain NATs. If the responder notices that a NAT is
>>>present anyway, the request fails with error code NAT_PREVENTED.
>>>      
>>>
>>NAT_PREVENTED would say that you somehow managed to get rid of the
>>NAT... 
>>    
>>
>How about "NAT_DETECTED" or "UNEXPECTED_NAT_DETECTED" ?
>
>						- Bill
>
>
>
>_______________________________________________
>Mobike mailing list
>[email protected]
>https://www.machshav.com/mailman/listinfo.cgi/mobike
>
>
>  
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.