Groupe de travail Réseau	G. Fairhurst, University of Aberdeen	
Request for Comments: 5596	septembre 2009	
RFC mise à jour : 4340		
Catégorie : Sur la voie de la normalisation 	Traduction Claude Brière de L'Isle	

Technique d'ouverture simultanée du protocole de contrôle d'encombrement de datagramme (DCCP) pour faciliter la traversée de NAT/boîtier de médiation

Résumé
Le présent document spécifie une mise à jour du protocole de contrôle d'encombrement de datagramme (DCCP, Datagram Congestion Control Protocol) un protocole de transport en mode connexion fondé sur le datagramme. La mise à jour ajoute la prise en charge du paquet DCCP-Listen. Cela aide les applications DCCP à communiquer à travers des boîtiers de médiation (middlebox) (par exemple, un traducteur d'adresse/accès réseau ou un serveur DCCP derrière un pare-feu) où les points d'extrémité qui échangent du trafic ont besoin d'initier la communication de manière presque simultanée pour établir l'état nécessaire sur le boîtier de médiation.

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Table des matières
1. Introduction	2
1.1 Domaine d'application du document	2
1.2 Traversée de NAT DCCP	2
1.3 Structure du document	3
2. Procédure d'ouverture presque simultanée	3
2.1 Conventions et terminologie	3
2.2 Méthode du protocole	3
2.3 Exemples d'utilisation	7
2.3.2 Retransmission déclenchée facultative de demande DCCP	8
2.4 Rétro compatibilité avec la RFC 4340	9
3. Discussion des décisions de conception	9
3.1 Raison d'un nouveau type de paquet	9
3.2 Génération des paquets Listen	10
3.3 Répétition des paquets DCCP-Listen	10
4. Considérations sur la sécurité	11
5. Considérations relatives à l'IANA	11
6. Remerciements	12
7. Références	12
7.1 Références normatives	12
7.2 Références pour information	12
Appendice A. Discussion des techniques existantes de traversée de NAT	13
A.1 Traversée de NAT fondée sur une demande simultanée	13
A.2 Inversion de rôle	14
Adresse de l'auteur	15

 	1.	Introduction

Le protocole de contrôle d'encombrement de datagrammes (DCCP, Datagram Congestion Control Protocol) [RFC4340] est à la fois fondé sur le datagramme et en mode connexion. Selon la RFC 4340, les serveurs DCCP établissent des connexions en écoutant passivement les demandes de connexion entrantes qui sont activement transmises par les clients DCCP. Ces rôles asymétriques peuvent causer des problèmes quand le serveur est "à l'intérieur" d'un boîtier de médiation, comme de traduction d'accès d'adresse réseau (NAPT, Network Address Port Translation) qui permet seulement les demandes de connexion initiées de l'intérieur (par exemple, du fait d'une surcharge de l'accès) [RFC5597]. Les pare-feu fondés sur l'hôte et de réseau peuvent aussi mettre en œuvre des politiques qui conduisent à des problèmes similaires. Ce comportement est actuellement celui par défaut pour de nombreux pare-feu.

UDP peut prendre en charge la traversée de boîtier de médiation en utilisant diverses techniques [RFC4787] qui renforcent la nature sans connexion de UDP et ne conviennent donc pas pour DCCP. TCP prend en charge la traversée de boîtier de médiation par l'utilisation de sa procédure d'ouverture simultanée [RFC5382]. Les concepts de la solution TCP sont applicables à DCCP, mais DCCP ne peut pas simplement réutiliser les mêmes méthodes (voir l'Appendice A).

Après la discussion de l'espace de problème pour DCCP, le présent document spécifie une mise à jour de l'automate à états de DCCP pour offrir une prise en charge d'origine qui permette à un client DCCP d'établir une connexion à un serveur DCCP à l'intérieur d'un ou plusieurs boîtiers de médiation. Cela réduit la dépendance à des aides externes telles que des serveurs de relais de données [RFC5766] en prenant explicitement en charge un principe largement utilisé appelé "perforation" (hole punching).

La méthode exige seulement un changement mineur à la procédure standard du fonctionnement de DCCP. L'utilisation d'un type dédié de paquet DCCP lie l'usage à une condition spécifique, ce qui assure que la méthode inter-opère avec les hôtes qui ne mettent pas en œuvre cette mise à jour ou choisissent de la désactiver (voir la Section 4).

 	1.1	Domaine d'application du document
Cette méthode est utile dans les scénarios où un serveur DCCP est situé à l'intérieur du périmètre contrôlé par un boîtier de médiation. Elle est pertinente pour les applications de client/serveur et d'homologue à homologue, comme la voix sur IP (VoIP, Voice over IP) le partage de fichiers, ou les jeux en ligne, et aide les connexions qui utilisent une signalisation hors bande préalable (par exemple, via un serveur de rendez-vous bien connu ([RFC3261], [H.323])) pour notifier aux deux points d'extrémité les paramètres de la connexion ([RFC3235], [NAT-APP]).

 	1.2	Traversée de NAT DCCP
Les exigences comportementales pour les appareils de NAT qui prennent en charge DCCP sont décrites dans la [RFC5597]. Un "NAT traditionnel" [RFC3022] qui transpose directement une en une adresse IP différente n'exige pas la technique d'ouverture simultanée décrite dans le présent document.

La méthode est requise quand le serveur DCCP est positionné derrière un ou plusieurs appareils NAPT dans le chemin (des hiérarchies d'appareils NAPT incorporés sont possibles). Le présent document se réfère aux hôtes DCCP situés dans le périmètre contrôlé par un ou plusieurs appareils NAPT comme ayant des adresses "privées", et aux hôtes DCCP situés dans le domaine d'adresse mondial comme ayant des adresses "publiques".

La traversée de NAT par DCCP est examinée pour les scénarios suivants :
1.	Le client privé se connecte à un serveur public.
2.	Le client public se connecte à un serveur privé.
3.	Le client privé se connecte à un serveur privé.

Une caractéristique qui définit les appareils de NAT traditionnels [RFC3022] est que les hôtes privés peuvent se connecter aux hôtes externes, mais pas vice versa. Donc, le cas (1) est possible en utilisant le protocole défini dans la [RFC4340]. Une transposition statique pré-configurée d'adresse de NAT permettrait aux hôtes externes d'établir des connexions dans les cas (2) et (3).

Une mise en œuvre de DCCP conforme à la [RFC4340] et un appareil de NAT conforme à la [RFC5597] exigerait qu'un serveur relais DCCP effectue la traversée de NAT pour les cas (2) et (3).

Le présent document décrit une méthode pour prendre en charge les cas (2) et (3) sans l'aide d'un serveur relais DCCP. Cette méthode met à jour la RFC 4340 et exige du serveur DCCP qu'il découvre l'adresse IP et l'accès DCCP qui correspondent au client DCCP. Une telle signalisation peut être effectuée hors bande (par exemple, en utilisant le protocole de description de session (SDP) [RFC4566]).

 	1.3	Structure du document
Pour les informations de base sur les techniques existantes de traversée de NAT, voir l'Appendice A.

La spécification normative de la mise à jour est présentée dans la Section 2. Une discussion pour information des décisions de conception sous-jacentes suit à la Section 3. Les considérations sur la sécurité sont données à la Section 4 et les considérations relatives à l'IANA sont données à la Section 5.

 	2.	Procédure d'ouverture presque simultanée

Cette Section est normative et spécifie la technique d'ouverture simultanée pour DCCP. Elle met à jour les procédures d'établissement de connexion [RFC4340].

 	2.1	Conventions et terminologie
Le document utilise les termes et définitions fournis dans la [RFC4340]. Une certaine familiarité avec cette spécification est supposée. En particulier, on utilise la convention suivante du paragraphe 3.2 de la [RFC4340] :

Chaque connexion DCCP fonctionne entre deux hôtes, qu'on appelle souvent DCCP A et DCCP B. Chaque connexion est activement initiée par un des hôtes, qu'on appelle le client ; l'autre hôte, initialement passif est appelé le serveur.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	2.2	Méthode du protocole
Le terme "session" est utilisé comme défini au paragraphe 2.3 de la [RFC2663] : les sessions DCCP sont identifiées de façon univoque par le quadruplet <adresse IP de source, accès de source, adresse IP cible, accès cible>.

De plus, DCCP introduit des codes de service, qui peuvent être utilisés pour identifier les différents services disponibles via le même accès [RFC5595].

 	2.2.1	Format de paquet DCCP-Listen
Le présent document ajoute un nouveau type de paquet DCCP, DCCP-Listen, dont le format est montré ci-dessous.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Accès de source         |     Accès de destination      |
+---------------+---------------+---------------+---------------+
| Décalage dns  | CCVal | CsCov |     Somme de contrôle         |
+---------------+-------+-------+---------------+---------------+
| Rés | Type  |X|   Réservé     | Bits poids fort num. séquence |
+-----+-------+-+---------------+---------------+---------------+
|         Bits de moindre poids du numéro de séquence           |
+---------------+---------------+---------------+---------------+
|                         Code de service                       |
+---------------+---------------+---------------+---------------+

Figure 1 : Format d'un paquet DCCP-Listen

o	Le champ Accès de source indique l'accès sur lequel écoute le serveur DCCP pour une connexion à partir de l'adresse IP qui apparaît comme adresse IP de destination dans le paquet.

o	Le champ Accès de destination indique l'accès choisi par un client DCCP pour identifier la connexion. Dans cette technique, cette valeur doit être communiquée hors bande au serveur.

o	La valeur de X DOIT être réglée à 1. Un paquet DCCP-Listen est envoyé avant qu'une connexion soit établie ; donc, il n'y a pas de moyen de négocier l'utilisation de courts numéros de séquence ([RFC4340], paragraphe 5.1).

o	La valeur du champ Numéro de séquence dans un paquet DCCP-Listen n'a pas de relation avec le numéro de séquence DCCP utilisé dans les messages DCCP normaux (voir à la Section 3 une description de l'utilisation du numéro de séquence DCCP). Donc, pour les paquets DCCP-Listen :
*	Un serveur DCCP DEVRAIT régler les bits de poids fort et de moindre poids du numéro de séquence à 0.
*	Un client DCCP DOIT ignorer la valeur du champ Numéro de séquence.
*	Les boîtiers de médiation NE DOIVENT PAS interpréter les numéros de séquence dans les paquets DCCP-Listen.

o	Le champ Code de service contient la valeur de code de service pour laquelle le serveur écoute pour une connexion (paragraphe 8.1.2 de la [RFC4340] et [RFC5595]). Cette valeur DOIT correspondre à un code de service que le serveur offre actuellement pour une connexion identifiée par la même adresse IP de source et le même accès de source que celles du paquet DCCP-Listen. Comme le serveur peut utiliser plusieurs codes de service, la valeur spécifique du champ Code de service doit être communiquée hors bande, du client au serveur, avant d'envoyer le paquet DCCP-Listen, par exemple, décrite en utilisant le protocole de description de session (SDP) [RFC4566].

o	Au moment de la rédaction, il n'y a pas d'utilisation connue des options d'en-tête ([RFC4340], paragraphe 5.8) avec un paquet DCCP-Listen. Les clients DOIVENT ignorer toutes les options dans les paquets DCCP-Listen reçus. Donc, des valeurs de caractéristiques ne peuvent pas être négociées en utilisant un paquet DCCP-Listen.

o	Au moment de la rédaction, il n'y a pas d'utilisation connue de données de charge utile avec un paquet DCCP-Listen. Comme les paquets DCCP-Listen sont produits avant qu'une connexion réelle soit établie, les points d'extrémité DOIVENT ignorer toutes les données de charge utile rencontrées dans les paquets DCCP-Listen.

o	Les champs de protocole suivants sont obligés d'avoir des valeurs spécifiques :
*	Décalage des données DOIT avoir une valeur de cinq ou plus (c'est-à-dire, au moins 20 octets).
*	CCVal DOIT être zéro (une connexion n'a pas été établie).
*	CsCov DOIT être zéro (l'utilisation de la caractéristique CsCov ne peut pas être négociée).
*	Type a la valeur 10, allouée par l'IANA pour noter un paquet DCCP-Listen.
*	X DOIT être 1 (l'en-tête générique doit être utilisé).

Les champs restants, y compris les champ "Rés" et "Réservé" sont spécifiés par la [RFC4340] et ses successeurs. L'interprétation de ces champs n'est pas modifiée par le présent document.

 	2.2.2	Méthode du protocole pour les points d'extrémité de serveur DCCP
Le présent document met à jour le paragraphe 8.1 de la [RFC4340] pour le cas d'un point d'extrémité de serveur DCCP  pleinement spécifié. La mise à jour modifie la façon dont le serveur effectue une ouverture passive.

Avant l'établissement de la connexion, il est courant qu'un point d'extrémité de serveur DCCP ne soit pas pleinement spécifié : avant que la connexion soit établie, un serveur spécifie généralement seulement l'accès de destination et le code de service. (Parfois l'adresse de destination est aussi spécifiée.) Cela laisse non spécifiés l'adresse de source et l'accès de source. Le point d'extrémité devient pleinement spécifié seulement après avoir effectué la prise de contact pour une connexion entrante. Dans ce cas, le présent document ne met pas à jour le paragraphe 8.4 de la [RFC4340], c'est-à-dire, le serveur adhère aux transitions d'état existantes dans la moitié gauche de la Figure 2 (CLOSED => LISTEN => RESPOND).

Un point d'extrémité de serveur DCCP pleinement spécifié permet exactement un client, identifié par une adresse:accès de source IP, une adresse:accès de destination IP, plus un seul code de service, pour établir la connexion. Un tel serveur DEVRAIT effectuer les actions et transitions d'état montrées dans la moitié droite de la Figure 2 et spécifiées ci-dessous.

           distant non spécifié +--------+ distant pleinement spécifié
          +---------------------| CLOSED |---------------------+
          |                     +--------+  envoie DCCP-Listen |
          |                                                    |
          v                                                    v
     +--------+                      fin de temporisation +---------+
     | LISTEN |                           +---+-----------| INVITED |
     +--------+                           |   |           +---------+
          |                               |   |  1ère / 2nd ^  |
          |                 plus de 2     |   | retransm.   |  | reçoit la
          |               retransmissions |   +-------------+  | demande
          |                               |   renvoie Listen   v
          |                               |               +---------+
          |                               +-------------->| LISTEN1 |
          |                                               +---------+
          |                                                    |
          |  reçoit Demande    +---------+    reçoit Demande*  |
          +------------------->| RESPOND |<--------------------+
             envoie Réponse    +---------+    envoie Réponse

* Note : Le cas d'un serveur qui répond à une DCCP-Request dans l'état INVITED, transite à l'état LISTEN1, et ensuite transite immédiatement à l'état RESPOND n'exige pas la réception d'un paquet DCCP-Request supplémentaire.

Figure 2 : Mise à jour du diagramme de transition d'état pour DCCP-Listen

Ce diagramme introduit deux états de serveur DCCP supplémentaires en plus de ceux mentionnés au paragraphe 4.3 de la [RFC4340] :

INVITED : l'état INVITED est associé à une connexion DCCP spécifique et représente une prise de serveur pleinement spécifiée dans l'état d'écoute qui génère des paquets DCCP-Listen vers le client.

LISTEN1 : l'état LISTEN1 est associé à une connexion DCCP spécifique et représente une prise de serveur pleinement spécifiée dans l'état d'écoute passive qui ne va pas générer plus de paquets DCCP-Listen vers le client.

Un point d'extrémité de serveur pleinement spécifié effectue une ouverture passive à partir de l'état CLOSED en invitant le client distant à se connecter. Cela est effectué en envoyant un seul paquet DCCP-Listen à l'adresse:accès distante spécifiée, en utilisant le format spécifié au paragraphe 2.2.1. La figure ci-dessous donne le pseudo code qui décrit le traitement de paquet dans l'état INVITED. Cette étape de traitement suit l'étape 2 du paragraphe 8.5 de la [RFC4340]).

L'état INVITED est, comme LISTEN, un état passif, caractérisé par l'attente, en l'absence d'une connexion établie. Si le point d'extrémité de serveur dans l'état INVITED reçoit une DCCP-Request qui correspond à l'ensemble d'accès et adresses liés, il transite à l'état LISTEN1 et ensuite transite immédiatement à l'état RESPOND, où la suite du traitement reprend comme spécifié dans la [RFC4340].

Le serveur DEVRAIT répéter l'envoi d'un paquet DCCP-Listen quand il est dans l'état INVITED, à un intervalle de 200 millisecondes avec au plus 2 répétitions (la Section 3 discute ce choix de l'intervalle). Si le serveur est encore dans l'état INVITED après une autre période de 200 ms suivant la transmission du troisième paquet DCCP-Listen, il DEVRAIT avancer à l'état LISTEN1.

Les points d'extrémité de serveur pleinement spécifié DEVRAIENT traiter les messages d'erreur ICMP reçus en réponse à un paquet DCCP-Listen comme des "erreurs douces" qui ne causent pas de transition d'état. La réception d'un message d'erreur ICMP par suite de l'envoi d'un paquet DCCP-Listen n'indique pas nécessairement une défaillance de la demande de connexion suivante, et donc ne devrait pas résulter en un changement d'état du serveur. Cette réaction aux erreurs douces exploite la caractéristique précieuse de l'Internet que, pour de nombreuses défaillances du réseau, le réseau peut être reconstruit dynamiquement sans aucune perturbation des points d'extrémité.

Les points d'extrémité de serveur DEVRAIENT ignorer tout paquet DCCP-Listen entrant. Un serveur DCCP dans les états LISTEN, INVITED, ou LISTEN1 PEUT générer un paquet DCCP-Reset (code 7, "Connexion refusée") en réponse à un paquet DCCP-Listen reçu. Ce paquet DCCP-Reset est l'indication que deux serveurs sont simultanément en attente de connexions sur le même accès.

Plus de détails sur les raisons de la conception sont discutées dans la Section 3.

La figure ci-dessous donne un pseudo code qui décrit le traitement de paquet dans l'état INVITED. Cette étape de traitement suit l'étape 2 du paragraphe 8.5 de la [RFC4340].

Étape 2a : traiter l'état INVITED
      Si S.state == INVITED,
          /* État entré seulement pour les points d'extrémité de serveur pleinement spécifié */
          /* sur l'entrée S qui auront été réglés à une prise */
          Si P.type == Request
             /* Sort de l'état INVITED et continue de traiter le paquet */
             S.state = LISTEN1
             Continuer avec l'état S:= LISTEN1
         Autrement,
             Si type P == Listen
                /* La ligne suivante est facultative */
                Générer Reset(Connexion refusée)
                /*Autrement, éliminer le paquet et retour */
            Autrement,
                Générer Reset(Pas de connexion) sauf si P.type == Reset

    Étape 2b : traiter l'état LISTEN1
      Si S.state == LISTEN1,
          /* État entré seulement pour des points d'extrémité de serveur pleinement spécifié */
          /* Suit la réception d'un paquet Réponse */
          /* ou l'envoi d'un troisième paquet Listen (après l'expiration du temporisateur) */
          Si P.type == Request,
             S.state = RESPOND
             Choisir S.ISS (numéro de séquence initial) ou réglé à partir des mouchards Init
             Initialiser S.GAR := S.ISS
             Régler S.ISR, S.GSR, S.SWL, S.SWH à partir du paquet ou des mouchards Init
             Continuer avec S.state == RESPOND
             /* Un paquet Response va être généré dans l'étape 11 */
         Autrement,
             Si P.type == Listen
                /* La ligne suivante est facultative */
                Générer Reset(Connexion refusée)
                /*Autrement, éliminer le paquet et retourner */
            Autrement,
                Générer Reset(Pas de connexion) sauf si P.type == Reset

Figure 3 : Pseudo code DCCP mis à jour pour les états INVITED et LISTEN1

 	2.2.3	Méthode du protocole pour les points d'extrémité de client DCCP
Le présent document met à jour le paragraphe 8.1.1 de la [RFC4340] en ajoutant la règle suivante pour la réception de paquets DCCP-Listen par les clients :

Il est exigé des points d'extrémité qu'ils ignorent toutes les options d'en-tête ou données de charge utile rencontrées dans les paquets DCCP-Listen (paragraphe 2.2.1) et donc ils ne fournissent pas de communication significative à un client. Un client dans tout état DOIT éliminer en silence tout paquet DCCP-Listen reçu, sauf si il met en œuvre la procédure facultative définie dans le paragraphe qui suit.

 	2.2.3.1	Génération facultative de demandes déclenchées
Ce paragraphe décrit une optimisation facultative chez le client qui peut lui permettre d'éviter d'avoir à attendre la fin d'une temporisation à la suite d'une DCCP-Request éliminée. L'opération exige des clients qu'ils répondent à la réception des paquets DCCP-Listen quand ils sont reçus dans l'état REQUEST. Les paquets DCCP-Listen DOIVENT être éliminés en silence dans tous les autres états.

Un client qui met en œuvre cette optimisation PEUT effectuer immédiatement une retransmission d'une DCCP-Request suite à la réception du premier paquet DCCP-Listen. La retransmission est effectuée de la même manière qu'une fin de temporisation dans l'état REQUEST [RFC4340]. Une retransmission déclenchée DEVRAIT résulter en ce que le client augmente l'intervalle du temporisateur de retard exponentiel.

Noter qu'un délai de chemin de plus de 200 ms va résulter en ce que plusieurs paquets DCCP-Listen arrivent au client avant qu'une DCCP-Response soit reçue. Les clients DOIVENT donc effectuer seulement une retransmission pour chaque connexion DCCP. Cela exige de conserver l'état local (par exemple, un fanion par connexion).

Les mises en œuvre et les utilisateurs de cette méthode facultative doivent être conscients qu'une temporisation d'hôte ou une réorganisation de chemin peut résulter en ce qu'un serveur reçoive deux DCCP-Request (c'est-à-dire, le serveur envoie un paquet inutile). Cela va, à son tour, déclencher l'envoi par un client d'une seconde DCCP-Response correspondante (elle aussi inutile). Ces paquets supplémentaires ne sont pas censés modifier ou retarder la procédure ouverte de DCCP [RFC4340].

Le paragraphe 2.3.2 donne des exemples de l'utilisation de la retransmission déclenchée.

 	2.2.4	Traitement par les routeurs et les boîtiers de médiation
Les paquets DCCP-Listen n'exigent pas de traitement particulier et devraient donc être transmis de bout en bout sur les chemins de l'Internet, par les routeurs et les boîtiers de médiation.

Les boîtiers de médiation peuvent utiliser les informations de connexion (adresse, accès, code de service) pour établir l'état de transmission local. Le paquet DCCP-Listen porte les informations nécessaires pour identifier de façon univoque la session DCCP en combinaison avec les adresses de source et destination (trouvées dans l'en-tête IP) y compris la valeur de code de service DCCP [RFC5595]. Le traitement du paquet DCCP-Listen par les appareils de NAT est spécifié dans la [RFC5597].

 	2.3	Exemples d'utilisation
Dans les exemples ci-dessous, DCCP A est le client et DCCP B est le serveur. Un appareil de boîtier de médiation (NAT/pare-feu) NA, est placé avant DCCP A, et un autre boîtier de médiation, NB, est placé avant DCCP B. Les deux NA et NB utilisent une politique qui permet aux paquets DCCP de traverser l'appareil pour les liaisons sortantes, mais permet seulement les paquets DCCP sortants quand un précédent paquet a été envoyé pour la même connexion.

Dans la figure ci-dessous, DCCP A et DCCP B décident de communiquer en utilisant un mécanisme hors bande (dans ce cas, l'étiquetage SDP) lorsque le client et le serveur démarrent. DCCP B indique activement son état d'écoute en envoyant un message DCCP-Listen. Cela satisfait l'exigence de poinçonnage dans NB (créant aussi le lien à l'adresse et accès externes). Ce message est éliminé par NA parce qu'aucun trou d'épingle n'existe encore. DCCP A initie une connexion en entrant dans l'état REQUEST et en envoyant une DCCP-Request. (On suppose que si NA était un appareil de NAT, il en résulterait alors aussi un lien qui transposerait le trou d'épingle en l'adresse et accès externes.) La DCCP-Request est reçue par DCCP B, via le lien à NB. DCCP B transmet la DCCP-Response et se connecte par les liens maintenant en place à NA et NB.

 DCCP A                                           DCCP B
 ------                NA      NB                 ------
  +-----------------+  +-+    +-+  +-----------------+
  |                 |  | |    | |  |                 | État = CLOSED
  | SDP -->         |--+-+----+-+->|                 | État = INVITED
  |                 |  | |X---+-+--|<-- DCCP-Listen  |
  |(État = REQUEST) |  | |    | |  |                 |
  |DCCP-Request --> |--+-+----+-+->|                 |
  |(État =PARTOPEN) | <+-+----+-+--|<-- DCCP-Response| État = RESPOND
  |DCCP-Ack -->     |--+-+----+-+> |                 |
  |                 |  | |    | |  |                 |
  |                 |  | |    | |  |                 |
  |DCCP-Data -->    |--+-+----+-+->|                 | État = OPEN
  +-----------------+  +-+    +-+  +-----------------+

Figure 4 : Séquence d'événement quand le serveur démarre avant le client

 	2.3.1	Répétition de DCCP-Listen
Ce paragraphe examine les effets de ne pas recevoir la DCCP-Request.
La figure ci-dessous montre la séquence de paquets où le serveur DCCP entre dans l'état INVITED après la réception de signalisation hors bande (par exemple, SDP). Les opérations clé de temporisation chez le client et le serveur sont montrées respectivement sur le côté gauche et droit du diagramme. Elle considère le cas où le serveur ne reçoit pas de DCCP-Request dans les premières 600 ms (la demande va souvent être reçue dans cet intervalle).

La répétition des paquets DCCP-Listen peut être mise en œuvre en utilisant un temporisateur. Le temporisateur est redémarré à un intervalle de 200 ms quand on envoie chaque paquet DCCP-Listen. Il est annulé quand le serveur quitte l'état INVITED. Si le temporisateur expire après la première et la seconde transmission, cela déclenche la transmission d'un autre paquet DCCP-Listen. Si il expire après l'envoi du troisième paquet DCCP-Listen, le serveur quitte l'état INVITED pour entrer dans l'état LISTEN1 (où il attend passivement une DCCP-Request).

                DCCP A                           DCCP B
                ------  NA      NB               ------
                +----+  +-+    +-+  +-----------------+
                |    |  | |    | |  |                 | État = CLOSED
                | -->|--+-+----+-+--|--> SDP          |
                |    |  | |    | |  |                 | État = INVITED
                |    |  | |    | |  |                 |
                |    |  | |X---+-+--|<-- DCCP-Listen  | Début du temporisateur
                |    |  | |    | |  |                 |      |
   Début du     | -->|--->+--X | |  |   (éliminé)     |      |
  temporisateur |    |  | |    | |  |                 |      |
   DCCP-Request |    |  | |    | |  |                 | 1ère expiration
         |      |    |<-+-+----+++--|<-- DCCP-Listen  |
         |      |    |  | |    | |  |                 | Début du temporisateur
         |      |    |  | |    | |  |                 |       |
         |      |    |  | |    | |  |                 | 2nd expiration
         |      |    |  | |    | |  |                 |
         |      |    |<-+-+----+-+--|<-- DCCP-Listen  | Début du temporisateur
         |      |    |  | |    | |  |                 |       |
         |      |    |  | |    | |  |                 | 3ème expiration
         |      |    |  | |    | |  |                 |
         |      |    |  | |    | |  |                 | État = LISTEN1
         |      ~    ~  ~ ~    ~ ~  ~                 ~
         |      |    |  | |    | |  |                 |
  Expiration du | -->|--+-+----+-+--|--> DCCP-Request |
  temporisateur |    |  | |    | |  |                 | État = RESPOND
                | <--|--+-+----+-+--|<-- DCCP-Response|
                +----+  +-+    +-+  +-----------------+

Figure 5 : Répétition du paquet DCCP-Listen

 	2.3.2	Retransmission déclenchée facultative de demande DCCP
La figure suivante illustre une retransmission déclenchée. Dans cette figure, le premier DCCP-Listen est supposé être perdu dans le réseau (par exemple, il n'ouvre pas de trou d'épingle à NB). Une DCCP-Request ultérieure est aussi non reçue (peut-être par un effet collatéral de la première perte). Après 200 ms, le paquet DCCP-Listen est retransmis et correctement reçu. Cela déclenche la retransmission de la DCCP-Request, qui, quand elle est reçue, résulte en une DCCP-Response correspondante.

   DCCP A                                         DCCP B
   ------               NA      NB               ------
   +-----------------+  +-+    +-+  +-----------------+
   |                 |  | |    | |  |                 | État = CLOSED
   |SDP              |--+-+----+-+->|                 | État = INVITED
   |(État = REQUEST) |  | |    | |  |                 |
   |                 |  | |    | |X-|<-- DCCP-Listen  |
   |DCCP-Request --> |--+-+---X| |  |                 |
   |                 | <+-+----+-+--|<-- DCCP-Listen  |(retransmis)
   |                 |  | |    | |  |                 |
   |DCCP-Request --> |--+-+----+-+->|                 | État = RESPOND
   |  (déclenchée)   |  | |    | |  |                 |
   |                 |<-+-+----+-+--|<-- DCCP-Response|
   |(État = PARTOPEN)|  | |    | |  |                 |
   |DCCP-Ack -->     |--+-+----+-+->|                 | État = OPEN
   +-----------------+  +-+    +-+  +-----------------+

Figure 6 : Exemple montrant une DCCP-Request déclenchée

La figure suivante illustre la séquence de paquets échangés quand une DCCP-Listen et une DCCP-Request sont traitées dans le désordre. La réception du paquet DCCP-Listen par le client déclenche la retransmission de la DCCP-Request. Le serveur répond à la première DCCP-Request et entre dans l'état RESPOND. Le serveur répond ensuite à la seconde DCCP-Request avec une autre DCCP-Response, qui est ignorée par le client (qui est déjà dans l'état PARTOPEN).

   DCCP A                                        DCCP B
   ------                NA     NB              ------
   +-----------------+  +-+    +-+  +-----------------+
   |                 |  | |    | |  |                 | État = CLOSED
   |SDP              |--+-+----+-+->|                 | État = INVITED
   |(État = REQUEST) |  | |    | |  |                 |
   |DCCP-Request --> |--+-+-  -+-+--|<-- DCCP-Listen  |
   |                 |  | | \/ | |  |                 |
   |                 |  | | /\ | |  |                 |
   |                 |<-+-+-  -+-+->|                 |
   |DCCP-Request --> |--+-+-  -+-+--|<-- DCCP-Response| État = RESPOND
   |  (déclenchée)   |  | | \/ | |  |                 |
   |                 |  | | /\ | |  |                 |
   |                 |<-+-+-  -+-+->|                 |
   |(État = PARTOPEN)|  | |    | |  |                 |
   |DCCP-Ack     --> |--+-+-  -+-+--|<-- DCCP-Response|
   |  (déclenchée)   |  | | \/ | |  |                 |
   |                 |  | | /\ | |  |                 |
   |  (ignoré)       |<-+-+-  -+-+->|                 | État = OPEN
   |                 |  | |    | |  |                 |
   +-----------------+  +-+    +-+  +-----------------+

Figure 7 : Exemple montrant une DCCP-Request déclenchée inutilement

 	2.4	Rétro compatibilité avec la RFC 4340
Aucun changement n'est requis si un client DCCP qui se conforme au présent document communique avec un serveur DCCP qui se conforme à la [RFC4340].

Si un client met en œuvre seulement la [RFC4340], un paquet DCCP-Listen entrant va être ignoré du fait de l'étape 1 du paragraphe 8.1 de la [RFC4340], qui en même temps se conforme aussi au comportement spécifié par le présent document.

Le présent document ne modifie pas la communication pour un serveur DCCP qui met en œuvre une ouverture passive sans pleinement lier les adresses, accès, et codes de service à utiliser. Les auteurs ne s'attendent donc pas à des problèmes pratiques de déploiement avec les mises en œuvre existantes conformes de DCCP.

 	3.	Discussion des décisions de conception
Cette Section pour information passe en revue les raisons de la conception de cette méthode.

 	3.1	Raison d'un nouveau type de paquet
Le paquet DCCP-Listen spécifié au paragraphe 2.2.1 a le même format que le paquet DCCP-Request ([RFC4340], paragraphe 5.1) la seule différence étant dans la valeur du champ Type. L'usage diffère cependant. Le paquet DCCP-Listen sert de message d'information, qui ne fait pas partie de l'établissement de connexion réel : les numéros de séquence n'ont pas de signification, et aucune charge utile ne peut être communiquée.

Un paquet DCCP-Request pourraient, en théorie, avoir aussi été utilisé pour le même objet. Les arguments suivants allaient contre cela :

Le premier problème était celui de la surcharge sémantique : la DCCP-Request définie dans la [RFC4340] sert un objet bien défini, qui est le paquet initial de la prise de contact en trois phases. Une utilisation supplémentaire à la manière d'un paquet DCCP-Listen aurait exigé que les processeurs DCCP aient deux chemins de traitement différents : un où une DCCP-Request est interprétée au titre de la prise de contact initiale, et un autre où le même paquet serait interprété comme une indication de l'intention d'accepter une nouvelle connexion. Cela compliquerait le traitement de paquet chez les hôtes et, en particulier, dans les boîtiers de médiation à états pleins (qui peuvent avoir des ressources de calcul restreintes).

Le second problème est celui qu'un client recevant une DCCP-Request d'un serveur pourrait générer un paquet DCCP-Reset si il n'est pas déjà entré dans l'état REQUEST (étape 7 du paragraphe 8.5 de la [RFC4340]). La méthode spécifiée dans le présent document laisse les points d'extrémité de client ignorer les paquets DCCP-Listen. Ajouter une règle similaire pour le paquet DCCP-Request aurait été étrange : les clients ne seraient pas capables de distinguer entre un paquet DCCP-Request destiné à indiquer l'intention d'accepter une nouvelle connexion et une initiation de connexion réellement erratique.

Le troisième problème est similaire et se réfère à un client recevant l'indication après avoir lui-même envoyé une DCCP-Request (d'initiation de connexion). L'étape 7 du paragraphe 8.5 de la [RFC4340] exige que le client réponde à une DCCP-Request provenant du serveur avec un paquet DCCP-Sync. Comme les numéros de séquence sont ignorés pour ce type de message, un traitement supplémentaire et complexe deviendrait nécessaire : soit pour demander au client de ne pas répondre à une DCCP-Request quand la demande est utilisé comme indication, soit pour demander aux boîtiers de médiation et serveurs d'ignorer les paquets DCCP-Sync générés en réponse aux paquets DCCP-Request qui sont utilisés comme des indications. De plus, comme aucun numéro de séquence initial n'a été négocié à ce stade, l'envoi d'un DCCP-SyncAck n'aurait aucun sens.

L'utilisation d'un type de paquet distinct permet donc un traitement plus simple et plus clair.

 	3.1.1	Utilisation de numéros de séquence
Bien que les champs de numéro de séquence de DCCP-Listen soient ignorés, ils ont été conservés dans l'en-tête de paquet DCCP-Listen pour réutiliser le format générique d'en-tête du paragraphe 5.1 de la [RFC4340].

DCCP alloue une valeur initiale aléatoire au numéro de séquence quand une connexion DCCP est établie [RFC4340]. Cependant, il est exigé d'un envoyeur qu'il règle cette valeur à zéro pour un paquet DCCP-Listen. Les clients et les boîtiers de médiation sont aussi tenus d'ignorer cette valeur.

La raison pour ignorer les champs de numéro de séquence des paquets DCCP-Listen est que, au moment où le DCCP-Listen est échangé, les points d'extrémité ne sont pas encore entrés dans l'établissement de connexion : le paquet DCCP-Listen est envoyé alors que le serveur est encore dans l'état d'ouverture passive (INVITED) c'est-à-dire, il n'a pas encore d'état alloué, autre que de lier l'adresse:accès et code de service du client.

 	3.2	Génération des paquets Listen
Un serveur DCCP devrait par défaut permettre la génération de paquets DCCP-Listen. Comme les paquets DCCP-Listen résolvent un problème particulier avec la traversée de NAT et/ou de pare-feu, la génération de paquets DCCP-Listen sur des prises passives est liée à une condition (le lien à une adresse et code de service distants sont tous deux connus a priori) pour assurer que cela n'interfère pas avec le cas général des connexions DCCP "normales" (où les adresses de clients ne sont généralement pas connues à l'avance).

Dans le monde de TCP, l'analogue est une transition de LISTEN à SYN_SENT en vertu de l'envoi de données : "Un appel passif pleinement spécifié peut être rendu actif par l'exécution suivante d'un SEND" ([RFC0793], paragraphe 3.8). À la différence de TCP, la présente mise à jour n'effectue pas de changement de rôle de passif à actif. Comme dans TCP, les paquets DCCP-Listen sont seulement envoyés par un serveur DCCP quand le point d'extrémité est pleinement spécifié (paragraphe 2.2).

 	3.3	Répétition des paquets DCCP-Listen
La répétition est une exigence nécessaire pour augmenter la robustesse et les chances de réussite de l'établissement de connexion quand un paquet DCCP-Listen est perdu à cause de l'encombrement, la perte de liaison, ou une autre raison.

La décision de recommander un nombre maximum de trois fins de temporisation (deux copies répétées du paquet DCCP-Listen original) résulte de la considération suivante : les copies répétées ont besoin d'être suffisamment espacées dans le temps pour éviter de subir des pertes corrélées. L'intervalle de 200 ms a été choisi pour s'accommoder d'une large gamme de chemins de réseaux filaires et sans fil.

Une autre contrainte est donnée par l'intervalle de retransmission pour la DCCP-Request ([RFC4340], paragraphe 8.1.1). Pour établir l'état, les systèmes intermédiaires ont besoin de recevoir un paquet DCCP-Listen (retransmis) avant que la DCCP-Request arrive en fin de temporisation (1 seconde). Avec trois temporisations, espacées chacune de 200 millisecondes, le temps global est encore en dessous d'une seconde. La somme de 600 millisecondes est suffisamment longue pour pourvoir à de plus longs délais unidirectionnels, comme c'est le cas, par exemple, sur certaines liaisons sans fil.

La raison derrière la transition à l'état LISTEN1 après deux répétitions est que d'autres problèmes, indépendants de l'établissement de l'état de boîtier de médiation, peuvent survenir (comme des retards ou la perte de la DCCP-Request initiale). Tout paquet DCCP-Request tardif ou retransmis va alors quand même atteindre le serveur, permettant que l'établissement de connexion se termine avec succès.

 	4.	Considérations sur la sécurité

Les considérations générales sur la sécurité pour DCCP sont décrites dans la [RFC4340]. Les considérations sur la sécurité pour les codes de service sont de plus décrites dans la [RFC5595].

La méthode spécifiée dans le présent document génère un paquet DCCP-Listen adressé à un client DCCP spécifique. Cela expose l'état d'un serveur DCCP qui est en état d'écoute passive (c'est-à-dire, attendant d'accepter une connexion d'un client connu).

Les informations exposées ne sont pas chiffrées et donc pourraient être vues sur le chemin de réseau au client DCCP. Un attaquant sur ce chemin de retour pourrait observer un paquet DCCP-Listen et exploiter ensuite cela en falsifiant un paquet (par exemple, DCCP-Request ou DCCP-Reset) avec les adresses IP, les accès DCCP, et le code de service qui correspondent aux valeurs à utiliser pour la connexion. Comme dans d'autres attaques en chemin, cela pourrait être utilisé pour injecter des données dans une connexion ou pour refuser une demande de connexion. Un attaque en chemin similaire est aussi possible pour toute connexion DCCP, une fois la session initiée par le client ([RFC4340], Section 18).

Le paquet DCCP-Listen est seulement envoyé en réponse à une signalisation hors bande antérieure explicite, provenant d'un client DCCP pour le serveur DCCP (par exemple, des informations SDP [RFC4566] communiquées via le protocole d'initialisation de session [RFC3261]) et va normalement précéder directement une DCCP-Request envoyée par le client (qui porte les mêmes informations).

La présente mise à jour n'augmente pas significativement la complexité ou la vulnérabilité d'une mise en œuvre de DCCP qui se conforme à la [RFC4340]. Un serveur DCCP DEVRAIT donc, par défaut, permettre la génération de paquets DCCP-Listen. Un serveur qui souhaite empêcher la divulgation de ces informations PEUT s'abstenir de générer des paquets DCCP-Listen sans impacter les transitions d'état DCCP suivantes, mais inhibant éventuellement la traversée de boîtier de médiation.

La spécification de base de DCCP dans la RFC 4340 définit une option Init Cookie, qui permet à un serveur DCCP d'éviter d'avoir à conserver un état jusqu'à ce que la prise de contact en trois phases d'établissement de connexion soit achevée. La présente spécification permet un mécanisme hors bande qui force le serveur à conserver l'état pour une connexion qui n'a pas encore été établie. Ceci est un changement dans le profil de sécurité de DCCP, bien que son impact soit supposé être minimal et dépende des caractéristiques de sécurité du mécanisme hors bande (SIP SDP est un de ces mécanismes qui fournissent des caractéristiques de sécurité suffisantes).

La méthode crée une nouvelle façon pour qu'un client établisse une connexion DCCP avec un serveur en utilisant des données hors bande, transportées sur une connexion de signalisation. Si la connexion de signalisation n'est pas chiffrée, un espion pourrait voir l'adresse IP et l'accès du client pour la connexion DCCP à établir, et générer un paquet DCCP-Listen vers le client en utilisant sa propre adresse IP et accès de serveur. Cependant, un client va seulement répondre à un paquet DCCP-Listen reçu si l'adresse IP et accès du serveur correspondent à une connexion DCCP existante qui est dans l'état REQUEST (paragraphe 2.3.2). La méthode ne peut donc pas être utilisée pour rediriger la connexion sur une adresse IP de serveur différent.

 	5.	Considérations relatives à l'IANA

L'IANA a enregistré un nouveau type de paquet, "DCCP-Listen", dans le registre IANA Types de paquet DCCP. La valeur décimale 10 a été allouée à ce type. Cette entrée de registre fait référence au présent document.

 	6.	Remerciements

Le Dr. Gerrit Renker, de l'Université d'Aberdeen était à l'origine co-auteur du présent document, et le présent auteur le remercie de ses vues sur la conception du mécanisme de protocole et sa révision attentive des premières révisions du texte de ce document. Dan Wing a apporté son assistance sur les questions relatives à l'utilisation de NAT et NAPT.

 	7.	Références
 	7.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC4340]	E. Kohler et autres, "Protocole de contrôle d'encombrement de datagrammes (DCCP)", mars 2006. (P.S.) (MàJ par 6773)

[RFC5595]	G. Fairhurst, "Codes de service du protocole de contrôle d'encombrement de datagrammes (DCCP)", septembre 2009. (MàJ RFC4340) (P.S.)

 	7.2	Références pour information

[Epp05]	Eppinger, J-L., "TCP Connections for P2P Apps: A Software Approach to Solving the NAT Problem", Carnegie Mellon University/ISRI Technical Report CMU-ISRI-05-104, janvier 2005.

[FSK05]	Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer Communication Across Network Address Translators", Proceedings of USENIX-05, pages 179-192, 2005.

[GF05]	Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Proceedings of Internet Measurement Conference (IMC-05), pages 199-211, 2005.

[GTF04]	Guha, S., Takeda, Y., and P. Francis, "NUTSS: A SIP based approach to UDP and TCP connectivity", Proceedings of SIGCOMM-04 Workshops, Portland, OR, pages 43-48, 2004.

[H.323]	Recommandation UIT-T H.323v3, "Systèmes de communication multimédia fondés sur le paquet", UIT, Genève, septembre 1998.

[NAT-APP]	Ford, B., "Application Design Guidelines for Traversal through Network Address Translators", Travail en cours, mars 2007.

[RFC0793]	J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", STD 7,  DOI 10.17487/RFC0793, septembre 1981. (Remplacée par 9293)

[RFC2663]	P. Srisuresh, M. Holdrege, "Terminologie et considérations sur les traducteurs d'adresse réseau IP (NAT)", août 1999. (Information)

[RFC3022]	P. Srisuresh, K. Egevang, "Traducteur d'adresse réseau IP traditionnel", janvier 2001. (Information)

[RFC3235]	D. Senie, "Traducteurs d'adresse réseau (NAT) : lignes directrices pour une conception d'application facile à comprendre", janvier 2002, DOI 10.17487/RFC3235. (Information)

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002, DOI 10.17487/RFC3261. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006, DOI 10.17487/RFC4566. (P.S.  ; remplacée par RFC8866)

[RFC4787]	F. Audet, éd., C. Jennings, "Exigences sur le comportement des traducteurs d'adresse réseau (NAT) pour UDP en envoi individuel", janvier 2007, DOI 10.17487/RFC4787. (BCP0127) (MàJ par RFC7857)

[RFC5382]	S. Guha et autres, "Exigences sur le comportement des NAT pour TCP", octobre 2008, DOI 10.17487/RFC5382. (BCP0142) (MàJ par RFC7857)

[RFC5597]	R. Denis-Courmont, "Exigences comportementales des traducteurs d'adresse réseau (NAT) pour le protocole de contrôle d'encombrement de datagramme", BCP0150, septembre 2009. 

[RFC5766]	R. Mahy, P. Matthews, J. Rosenberg, "Traversée de NAT au moyen d'un relais (TURN) : Extensions de relais aux utilitaires de traversée de session pour les NAT (STUN)", avril 2010, DOI 10.17487/RFC5766. (P. S. ; MàJ par RFC8155 ; Remplacée par RFC8656)

[RFC6544]	J. Rosenberg et autres, "Candidats TCP avec établissement de connexité interactive (ICE)", mars 2012, DOI 10.17487/RFC6544. (P.S.)

 	Appendice A.	Discussion des techniques existantes de traversée de NAT

Le présent appendice donne une brève revue des techniques existantes pour établir la connexité à travers les appareils de NAT, dans le but de fournir des informations d'arrière plan. Il considère d'abord la traversée de NAT TCP sur la base d'une ouverture simultanée, et discute ensuite d'une seconde technique fondée sur l'inversion de rôle. Plus d'informations se trouvent dans [GTF04] et [GF05].

Une idée centrale partagée par ces techniques est de faire que des sessions d'homologue à homologue ressemblent à des sessions "sortantes" sur chaque appareil de NAT. Souvent un serveur de rendez-vous, situé dans le domaine d'adresses public, est utilisé pour permettre aux clients de découvrir leur topologie de NAT et les adresses des homologues.

Le terme de "perforation" a été élaboré dans [FSK05] et se réfère à la création d'un état mou dans un appareil de NAT traditionnel en initiant une connexion sortante. Un NAT qui se comporte bien peut ensuite exploiter cela pour permettre une connexion inverse en retour vers l'hôte dans le domaine d'adresses privé.

La perforation UDP et TCP utilise presque la même technique [RFC4787]. L'adaptation du principe de la perforation UDP de base à la traversée de NAT TCP [RFC5382] a été introduite dans la Section 4 de [FSK05] et s'appuie sur la caractéristique d'ouverture simultanée de TCP [RFC0793]. Une autre différence entre UDP et TCP tient à la façon dont le client effectue les vérifications de connexité après avoir obtenu des paires d'adresses convenables pour l'établissement de la connexion. Alors que dans UDP une seule prise est suffisante, les clients TCP exigent plusieurs prises pour le même couple d'adresse et accès :
o	une prise passive pour écouter les essais de connexité des homologues, et
o	plusieurs connexions actives de la même adresse pour vérifier l'accessibilité des autres homologues.

Le SYN envoyé par le client A à son homologue B crée un état mou dans le NAT de A. Au même moment, B essaye de se connecter à A :
o	si le SYN provenant de B a quitté le NAT de B avant l'arrivée du SYN de A, les deux points d'extrémité effectuent une ouverture simultanée (prise de contact en quatre phases de SYN/SYNACK) ;
o	autrement, le SYN de A ne peut pas entrer dans le NAT de B, ce qui fait que B effectue une ouverture normale (SYN_SENT => ESTABLISHED) et que A effectue une ouverture simultanée (SYN_SENT => SYN_RCVD => ESTABLISHED).

Dans le dernier cas, il est nécessaire que le NAT n'interfère pas avec un segment RST (REQ-4 dans la [RFC5382]). La solution d'ouverture simultanée est convenable par sa simplicité, et est donc le mode préféré de fonctionnement dans l'extension TCP pour l'établissement de connexité interactive (ICE, Interactive Connectivity Establishment) ([RFC6544], Section 2).

 	A.1	Traversée de NAT fondée sur une demande simultanée
Parmi les diverses approches de traversée de NAT TCP, celle qui utilise une ouverture TCP simultanée suggère qu'elle est une candidate pour DCCP du fait de sa simplicité ([GF05], [NAT-APP]).

Une caractéristique de l'ouverture simultanée de TCP est que cela efface la claire distinction entre client et serveur : les deux côtés entrent dans les états actif (SYN_SENT) aussi bien que passif (SYN_RCVD). Cette caractéristique entre en conflit avec la décision de conception de DCCP de faire une claire séparation entre les fonctions de client et de serveur ([RFC4340], paragraphe 4.6).

Dans DCCP, plusieurs mécanismes s'appuient implicitement sur des rôles clairement définis de client/serveur :
o	Négociation de caractéristique : à peu d'exceptions près, presque toutes les caractéristiques négociables de DCCP utilisent la règle de réconciliation de "priorité de serveur" ([RFC4340], paragraphe 6.3.1) par laquelle un homologue échange ses listes de préférences de valeurs de caractéristiques, et le serveur décide du résultat.
o	État de clôture : seul un serveur peut générer des paquets DCCP-CloseReq (demandant à l'homologue de conserver l'état timewait) tandis qu'il est seulement permis à un client d'envoyer des paquets DCCP-Close ou DCCP-Reset pour terminer une connexion ([RFC4340], paragraphe 8.3).
o	Codes de service [RFC5595] : un serveur peut être associé à plusieurs codes de service, tandis que le client doit être associé à exactement un ([RFC4340], paragraphe 8.1.2).
o	Mouchard Init : peut seulement être utilisé par un serveur et sur les paquets DCCP-Response ([RFC4340], paragraphe  8.1.4).

Les deux derniers points ne sont pas des obstacles en eux-mêmes, mais entraveraient la transition d'une prise passive à active. Dans DCCP, une DCCP-Request est seulement générée par un client. L'hypothèse que "tous les hôtes DCCP peuvent être des clients" a été rejetée, car cela exigerait des changements indésirables à l'automate à états et limiterait la programmation d'application. Par conséquent, la réintroduction d'une ouverture simultanée de style TCP dans DCCP pour permettre l'échange simultané de paquets DCCP-Connect n'a pas été recommandée.

 	A.2	Inversion de rôle
Un autre schéma simple de traversée de NAT TCP utilise la traversée de rôle ([Epp05], [GTF04]) où un homologue ouvre d'abord une connexion active dans le seul but de percer un trou dans le pare-feu, et ensuite revient au rôle de prise d'écoute, acceptant les connexions qui arrivent via le nouveau chemin.

Cette solution aurait plusieurs inconvénients si elle était utilisée avec DCCP. D'abord, un serveur DCCP serait obligé de changer son rôle pour devenir temporairement un "client". Cela aurait exigé des modifications à l'automate à états -- en particulier, le traitement des codes de service et peut-être des mouchards Init. De plus, la méthode aurait exigé de suivre la négociation de caractéristiques, car le choix d'un point d'extrémité des options initiales peut s'appuyer sur son rôle (c'est-à-dire, un point d'extrémité qui sait qu'il est le serveur peut faire des hypothèses a priori sur les listes de préférences des caractéristiques qu'il négocie avec le client, appliquant ainsi une politique particulière). Finalement, le serveur aurait besoin d'un traitement supplémentaire pour s'assurer que la connexion qui arrive à la prise qui écoute correspond à la connexion active ouverte précédemment.
Cette approche n'a donc pas été recommandée pour DCCP.

 	Adresse de l'auteur

Godred Fairhurst,
School of Engineering,
University of Aberdeen,
Kings College,
Aberdeen, AB24 3UE,
Scotland
mél : gorry@erg.abdn.ac.uk
URL : http://www.erg.abdn.ac.uk/users/gorry