1. Introduction

1. Introduction

L'utilisation la plus courante d'IPsec [RFC2401] est peut-être la fourniture de capacités de réseau privé virtuel (Virtual Private Networking, VPN). Une utilisation très populaire des VPN consiste à fournir aux télétravailleurs un accès à l'intranet d'entreprise. Aujourd'hui, les traductions d'adresses réseau (Network Address Translation, NAT) telles que décrites dans [RFC3022] et [RFC2663], sont largement déployées dans les passerelles domestiques, ainsi que dans d'autres emplacements susceptibles d'être utilisés par les télétravailleurs, tels que les hôtels. Le résultat est que les incompatibilités IPsec-NAT sont devenues un obstacle majeur au déploiement d'IPsec dans l'une de ses principales utilisations. Ce document décrit les incompatibilités connues entre NAT et IPsec, et décrit les exigences pour les résoudre.

1.1. Langage des exigences

Dans ce document, les mots-clés "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD" et "SHOULD NOT" doivent être interprétés comme décrit dans [RFC2119].

Veuillez noter que les exigences spécifiées dans ce document doivent être utilisées pour évaluer les soumissions de protocoles. En tant que telles, le langage des exigences fait référence aux capacités de ces protocoles; les documents de protocole spécifieront si ces fonctionnalités sont requises, recommandées ou optionnelles. Par exemple, exiger qu'un protocole prenne en charge la confidentialité n'est pas la même chose qu'exiger que tout le trafic du protocole soit chiffré.

Une soumission de protocole n'est pas conforme si elle ne satisfait pas à une ou plusieurs des exigences MUST ou MUST NOT pour les capacités qu'elle implémente. Une soumission de protocole qui satisfait toutes les exigences MUST, MUST NOT, SHOULD et SHOULD NOT pour ses capacités est dite "inconditionnellement conforme"; une soumission qui satisfait toutes les exigences MUST et MUST NOT, mais pas toutes les exigences SHOULD ou SHOULD NOT pour ses protocoles est dite "conditionnellement conforme".