par nl » 17 Mars 2004 18:00
Ca peut aider :
<BR>
<BR><!-- BBCode auto-link start --><a href="http://www.vpnc.org/ietf-ipsec/02.ipsec/msg02485.html" target="_blank">http://www.vpnc.org/ietf-ipsec/02.ipsec/msg02485.html</a><!-- BBCode auto-link end --> :
<BR>
<BR>The NAT-T protocol stuff does not change even if you start directly on
<BR>port 4500 (rekey or preconfiguration), i.e you send normal Vendor-ID,
<BR>NAT-D etc stuff and detect NAT normally. Only thing that is left out
<BR>is the changing of the port if NAT is detected.
<BR>
<BR>There is also possibility that some clients start directly to port
<BR>4500 instead of 500 if they know that the other end support NAT-T (i.e
<BR>preconfigured). They will do that before they know if there is NAT
<BR>between. If the NAT is then detected they will use the UDP
<BR>encapsulation otherwise they will use normal IPsec transport / tunnel
<BR>mode.
<BR>----------------------------------------------------------------------
<BR>...
<BR>Similarly, if the responder needs to rekey the phase 1 SA, then he MUST
<BR>start the negotiation using UDP(4500,Y). Any implementation that
<BR>supports NAT traversal, MUST support negotiations that begin on port
<BR>4500. If a negotiation starts on 4500, then it doesn't need to change
<BR>anywhere else in the exchange.
<BR>
<BR>
Si l'automobile avait progressé de la même façon que l'informatique, une Rolls-Royce couterait aujourd'hui 100 dollars, ferait 300.000 kilomètres avec un seul litre d'essence et exploserait une fois par an en tuant tous ses passagers. (Cringely)