Groupe de travail Réseau	B. Storer, Cisco Systems	
Request for Comments : 5571	C. Pignataro, éd., Cisco Systems	
Catégorie : Sur la voie de la normalisation	M. Dos Santos, Cisco Systems	
	B. Stevant, éd., TELECOM Bretagne	
Traduction Claude Brière de L'Isle	L. Toutain, TELECOM Bretagne	
	J. Tremblay, Videotron Ltd.	
	juin 2009	

Cadre de déploiement de centre et rayons de passage logiciel avec la version 2 du protocole de tunnelage de couche deux (L2TPv2)

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. 

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.

Résumé
Le présent document décrit le cadre de la solution de passage logiciel (Softwire) "centre et rayons" (Hub and Spoke) avec la version 2 du protocole de tunnelage de couche deux (L2TPv2, Layer Two Tunneling Protocol version 2). Les détails de la mise en œuvre spécifiée dans ce document devraient être respectés pour réaliser l'interopérabilité entre les mises en œuvre de fabricants différents.
Table des matières
1. Introduction	2
1.1 Abréviations	3
1.2 Langage des exigences	3
1.3 Considérations	3
2. Applicabilité de L2TPv2 pour les exigences de passage logiciel	3
2.1 Traduction traditionnelle d'adresse réseau (NAT et NAPT)	3
2.2 Adaptabilité	4
2.3 Acheminement	4
2.4 Diffusion groupée	4
2.5 Authentification, autorisation, et comptabilité (AAA)	4
2.6 Confidentialité, intégrité, et protection contre la répétition	4
2.7 Fonctionnement et gestion	4
2.8 Encapsulations	5
3. Scénarios de déploiement	5
3.1 Passages logiciels IPv6 sur IPv4 avec L2TPv2	5
3.2 Passages logiciels IPv4 sur IPv6 avec L2TPv2	8
4. Références aux documents de normalisation	11
4.1 L2TPv2	11
4.2 Sécurisation du transport de passage logiciel	11
4.3 Authentification, autorisation, et comptabilité	11
4.4 MIB	11
4.5 Charge utile relative au passage logiciel	11
5. Établissement de passage logiciel	12
5.1 Établissement de tunnel L2TPv2	13
5.2 Connexion PPP	16
5.3 Allocation d'adresse IPv6 mondiale aux points d'extrémité	17
5.4 DHCP	18
6. Considérations sur le modèle de provisionnement d'adresse	18
6.1 Adresses de points d'extrémité de passage logiciel	18
6.2 Préfixes délégués	19
6.3 Scénarios possibles de provisionnement d'adresse	19
7. Considérations sur la stabilité d'adresse	20
8. Considérations sur l'intégration de RADIUS	20
8.1 Points d'extrémité de passage logiciel	20
8.2 Préfixes délégués	20
9. Considérations sur la maintenance et les statistiques	21
9.1 Comptabilité RADIUS	21
9.2 MIB	21
10. Considérations sur la sécurité	21
11. Remerciements	22
12. Références	22
12.1 Références normatives	22
12.2 Références pour information	23
Adresse des auteurs	24
 	1.	Introduction

Le groupe de travail Softwires (passages logiciels) a choisi la version 2 du protocole de tunnelage de couche 2 (L2TPv2, Layer Two Tunneling Protocol version 2) comme protocole de phase 1 à déployer dans l'espace de solution de "centre et rayons" (Hub and Spoke) de passage logiciel. Le présent document décrit le cadre pour la solution "centre et rayons" de L2TPv2, et les détails de mise en œuvre spécifiés dans le présent document devraient être suivis pour réaliser l'interopérabilité entre les mises en œuvre de fabricants différents.

Dans l'espace de solution "centre et rayons", un passage logiciel (Softwire) est établi pour fournir au réseau de rattachement avec IPv4 la connexité à travers un réseau d'accès seulement IPv6, ou la connexité IPv6 à travers un réseau d'accès seulement IPv4. Quand L2TPv2 est utilisé dans le contexte du passage logiciel, le modèle de tunnelage volontaire s'applique. L'initiateur du passage logiciel (SI, Softwire Initiator) au réseau de rattachement prend le rôle de client de concentrateur d'accès L2TP (LAC, L2TP Access Concentrator) (qui initie à la fois le tunnel/session L2TP et la liaison PPP) tandis que le concentrateur de passage logiciel (SC, Softwire Concentrator) chez le FAI prend le rôle de serveur de réseau L2TP (LNS, L2TP Network Server). Les termes de tunnelage volontaire et de tunnelage obligatoire sont définis au paragraphe 1.1 de la [RFC3193]. Comme le modèle de tunnelage obligatoire de L2TPv2 ne s'applique pas aux passages logiciels, il NE DEVRAIT PAS être demandé ni honoré. Le présent document identifie tous les attributs L2TPv2 relatifs au tunnelage volontaire qui s'appliquent à tous les passages logiciels et spécifie le mécanisme de traitement de tels attributs afin d'éviter des ambiguïtés dans les mises en œuvre. Le présent document identifie aussi l'ensemble d'attributs L2TPv2 spécifiques du modèle de tunnelage obligatoire qui ne s'appliquent pas aux passages logiciels et spécifie le mécanisme pour ignorer ou annuler leur effet dans le contexte de passage logiciel.

Le SI et le SC DOIVENT suivre les opérations L2TPv2 décrites dans la [RFC2661] quand ils effectuent l'établissement, la suppression, et les opérations, administration, et gestion (OAM) de passage logiciel. Avec L2TPv2, un passage logiciel consiste en une connexion de contrôle L2TPv2 (aussi appelé un canal de contrôle) une seule session L2TPv2, et la liaison PPP négociée sur la session. Pour établir le passage logiciel, le SI initie d'abord un canal de contrôle L2TPv2 avec le SC, qui accepte la demande et termine le canal de contrôle. L2TPv2 prend en charge une authentification facultative mutuelle de canal de contrôle qui permet au SI et au SC de valider l'identité de chaque autre à la phase initiale de prise de contact avant de procéder à l'établissement du canal de contrôle. Après que le canal de contrôle L2TPv2 est établi entre le SI et le SC, le SI initie une session L2TPv2 avec le SC. Ensuite la liaison PPP/IP est négociée sur la session L2TPv2 entre le SI et le SC. Après l'établissement de la liaison PPP/IP, elle agit comme passage logiciel entre le SI et le SC pour tunneler le trafic IP d'une famille d'adresses (AF) à travers le réseau d'accès d'une autre famille d'adresses.

Durant la vie du passage logiciel, le SI et le SC envoient tous deux des messages HELLO L2TPv2 de maintien en vie pour surveiller la santé du passage logiciel et du point d'extrémité de connexion de contrôle (LCCE, L2TP Control Connection Endpoint) de l'homologue, et potentiellement rafraîchir l'entrée de traduction d'adresse réseau/traduction d'accès d'adresse réseau (NAT/NAPT, Network Address Translation / Network Address Port Translation) au CPE ou à l'autre extrémité de la liaison d'accès. Facultativement, des messages ECHO du protocole de contrôle de liaison (LCP, Link Control Protocol) peuvent être utilisés comme maintiens en vie dans le même but. En cas de fin de temporisation de maintien en vie ou de fermeture administrative du passage logiciel, le SI ou le SC PEUT supprimer le passage logiciel en supprimant le canal de contrôle et la session L2TPv2 comme spécifié dans la [RFC2661].

 	1.1	Abréviations
AF (Address Family) : famille d'adresses, IPv4 ou IPv6.

CPE (Customer Premises Equipment) : équipement d’installation d'abonné.

LCCE (L2TP Control Connection Endpoint) : point d'extrémité de connexion de contrôle de L2TP, nœud L2TP qui existe à l'une et l'autre extrémité d'une connexion de contrôle L2TP. (Voir la [RFC3931].)

LNS (L2TP Network Server) : serveur de réseau L2TP, nœud qui agit comme un côté d'un point d'extrémité d'un tunnel L2TP (connexion de contrôle). Le LNS est le point de terminaison logique d'une session PPP qui est tunnelée du système distant par l'homologue LCCE. (Voir la [RFC2661].)

SC (Softwire concentrator) : concentrateur de passage logiciel, nœud terminant le passage logiciel dans le réseau du fournisseur de service. (Voir la [RFC4925].)

SI (Softwire Initiator) : initiateur de passage logiciel, nœud qui initie le passage logiciel au sein du réseau du consommateur. (Voir la [RFC4925].)

SPH (Softwire Payload Header) : en-tête de charge utile de passage logiciel, en-têtes IP portés dans un passage logiciel. (Voir la [RFC4925].)

STH (Softwire Transport Header) : en-tête de transport de passage logiciel, en-tête IP la plus externe d'un passage logiciel. (Voir la [RFC4925].)

SW (Softwire) passage logiciel, état de "tunnel" partagé créé entre le SC et le SI. (Voir la [RFC4925].)

 	1.2	Langage des exigences
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].

 	1.3	Considérations
Certains paragraphes du présent document contiennent des considérations qui ne sont pas exigées pour l'interopérabilité et le fonctionnement correct des mises en œuvre de passage logiciel. Les titres de ces paragraphes sont marqués en commençant par "Considérations".

 	2.	Applicabilité de L2TPv2 pour les exigences de Softwire

Une liste des exigences de "centre et rayons" de passage logiciel a été identifiée par la [RFC4925] "Position du problème de passage logiciel". Les paragraphes qui suivent décrivent comment L2TPv2 satisfait chacune d'elles.

 	2.1	Traduction traditionnelle d'adresse réseau (NAT et NAPT)
Un passage logiciel de "centre et rayons" doit être capable de traverser les appareils de traduction d'adresse réseau (NAT, Network Address Translation) et de traduction d'accès d'adresse réseau (NAPT, Network Address Port Translation) aussi appelé traduction d'adresse d'accès (PAT, Port Address Translation) [RFC3022] dans le cas où le scénario en question implique une passerelle de rattachement IPv4 préexistante qui ne peut pas être mise à niveau en effectuant la NAT/NAPT ou un équipement de transporteur à l'autre extrémité de la liaison d'accès qui effectue la NAT/NAPT. Le passage logiciel L2TPv2 (c'est-à-dire, le canal et session de contrôle) est capable de traversée de NAT/NAPT car L2TPv2 peut fonctionner sur UDP.

Comme L2TPv2 ne détecte pas les NAT/NAPT le long du chemin, L2TPv2 n'offre pas l'option de désactiver UDP. L'encapsulation UDP est présente sans considération de la présence de NAT/NAPT. Les deux exigences "d'auto détection" de NAT/NAPT et d'outrepassement de UDP sont facultatives au paragraphe 2.3 de la [RFC4925].

Comme mentionné au paragraphe 8.1 de la [RFC2661] et à la Section 4 de la [RFC3193], un répondeur (SC) L2TP de réponse de début de connexion de contrôle (SCCRP, Start-Control-Connection-Reply) peut choisir une adresse IP et/ou un accès UDP différents de ceux de la demande de début de connexion de contrôle (SCCRQ, Start-Control-Connection-Request) de l'initiateur (SI). Cela peut ou non traverser un NAT/NAPT selon le comportement de filtrage du NAT/NAPT (voir la Section 5 de la [RFC4787]). Spécifiquement, toute combinaison d'adresse et accès IP va fonctionner avec le filtrage indépendant du point d'extrémité, mais changer l'adresse et l'accès IP ne va pas fonctionner à travers un filtrage dépendant de l'adresse ou un filtrage dépendant de l'adresse et de l'accès. Étant donné cela, répondre d'une adresse IP et/ou accès UDP différents n'est PAS RECOMMANDÉ.

 	2.2	Adaptabilité
Dans le modèle "centre et rayons", un transporteur doit être capable d'adapter la solution à des millions d'initiateurs de passage logiciel en ajoutant plus de centres (c'est-à-dire, des concentrateurs de passage logiciel). L2TPv2 est un protocole largement déployé dans les services large bande, et son adaptabilité a été prouvée dans plusieurs déploiements de réseau privé virtuel IPv4 à grande échelle qui s'adaptent à des millions d'abonnés chacun.

 	2.3	Acheminement
Il n'y a pas de protocole d'acheminement dynamique entre le SC et le SI. Un chemin par défaut du SI au SC est utilisé.

 	2.4	Diffusion groupée
Les protocoles de diffusion groupée fonctionnent simplement de façon transparente sur les passages logiciels L2TPv2 avec les autres trafics IP réguliers.

 	2.5	Authentification, autorisation, et comptabilité (AAA)
L2TPv2 prend en charge l'authentification mutuelle facultative de canal de contrôle et renforce l'authentification mutuelle facultative PPP par session. L2TPv2 est bien intégré avec les solutions d'AAA (comme RADIUS) pour l'authentification et l'autorisation. La plupart des mises en œuvre de L2TPv2 disponibles sur le marché prennent en charge l'enregistrement des événements d'authentification et d'autorisation.

L'intégration de L2TPv2 avec la comptabilité RADIUS (extension RADIUS Accounting pour les tunnels [RFC2867]) permet la collecte et le rapport des statistiques d'usage de passage logiciel L2TPv2.

 	2.6	Confidentialité, intégrité, et protection contre la répétition
Comme L2TPv2 fonctionne sur IP/UDP dans le contexte de passage logiciel, l'encapsulation de charge utile de sécurité (ESP, Encapsulating Security Payload) IPsec peut être utilisée conjointement pour fournir l'authentification, l'intégrité, la protection contre la répétition, et la confidentialité par paquet pour le contrôle L2TPv2 et le trafic de données [RFC3193] et [RFC3948].

Pour les déploiements de passage logiciel dans lesquels une pleine sécurité de la charge utile n'est pas exigée, l'authentification de canal de contrôle incorporée de L2TPv2 et l'authentification héritée de PPP et du protocole de contrôle de chiffrement PPP peuvent être envisagées.

 	2.7	Fonctionnement et gestion
L2TPv2 prend en charge un mécanisme facultatif de maintien en vie dans la bande qui injecte des messages de contrôle HELLO après qu'un délai spécifié s'est écoulé depuis que le dernier message de données ou de contrôle a été reçu sur un tunnel (voir le paragraphe 5.5 de la [RFC2661]). Si le message de contrôle HELLO n'est pas livré de façon fiable, le canal de contrôle et sa session vont alors être supprimés. Dans le contexte du passage logiciel, le maintien en vie L2TPv2 est utilisé pour surveiller l'état de connexité entre le SI et le SC et/ou comme mécanisme de rafraîchissement pour toute entrée de traduction de NAT/NAPT le long de la liaison d'accès.

L'ECHO LCP offre un mécanisme similaire pour surveiller l'état de connexité, comme décrit dans la [RFC1661]. Les mises en œuvre de passage logiciel DEVRAIENT utiliser les maintiens en vie Hello L2TPv2, et de plus PEUVENT utiliser les messages Echo de LCP PPP pour assurer la détection d'extrémité morte et/ou pour rafraîchir les entrées de traduction de NAT/NAPT. La combinaison de ces deux mécanismes peut être utilisée comme optimisation.

La MIB L2TPv2 [RFC3371] prend en charge la suite complète des opérations de gestion comme la configuration de canal et session de contrôle, l'interrogation de l'état du canal et session de contrôle et leurs statistiques de trafic et les notifications d'événements UP/DOWN de canal et session de contrôle.

 	2.8	Encapsulations
L2TPv2 prend en charge les encapsulations suivantes :
o	IPv6/PPP/L2TPv2/UDP/IPv4
o	IPv4/PPP/L2TPv2/UDP/IPv6
o	IPv4/PPP/L2TPv2/UDP/IPv4
o	IPv6/PPP/L2TPv2/UDP/IPv6

Noter que l'outrepassement d'UDP n'est pas pris en charge par L2TPv2 car L2TPv2 ne prend pas en charge "l'auto détection" de NAT/NAPT.

 	3.	Scénarios de déploiement

Pour l'espace de problème de "centre et rayons", quatre scénarios ont été identifiés. Dans chacun de ces quatre scénarios, différents équipements de rattachement jouent le rôle de l'initiateur de passage logiciel. Cette section élabore chaque scénario avec L2TPv2 comme protocole de passage logiciel et d'autres protocoles possibles impliqués pour compléter la solution. Cette section examine les quatre scénarios pour les encapsulations IPv6 sur IPv4 (paragraphe 3.1) et IPv4 sur IPv6 (paragraphe 3.2).

 	3.1	Passages logiciels IPv6 sur IPv4 avec L2TPv2
Les paragraphes qui suivent couvrent la connexité IPv6 (SPH) à travers un réseau d'accès IPv4 seulement (STH) utilisant un passage logiciel.

 	3.1.1	CPE hôte comme initiateur de passage logiciel
L'initiateur de passage logiciel (SI) est le CPE hôte (directement connecté à un modem) qui est double piles. Il n'y a pas d'autre appareil de passerelle. Le trafic IPv4 NE DEVRAIT PAS traverser le passage logiciel. Voir la Figure 1.

            IPv6 ou double pile    IPv4 seulement   Double piles
            |------------------||-----------------||----------|
      I                    SC                          SI
      N                  +-----+                   +----------+
      T                  | LNS |                   | CPE hôte |
      E  <==[Réseau ]....|v4/v6|....[ Réseau  ]....|  v4/v6   |
      R     [ IPv6  ]    |     |    [IPv4 seul]    |          |
      N                  |     |                   |LAC client|
      E                  +-----+                   +----------+
      T                          _ _ _ _ _ _ _ _ _
                               ()_ _ _ _ _ _ _ _ _() <-- trafic IPv6 (SPH)
                             PPP o L2TPv2 o UDP o IPv4
                                Passage logiciel

                               <------------------>
                    IPV6CP : capable d'allocation d'id d'interface /64 ou
                       de vérification d'unicité

                               |------------------> préfixe/64
                                        RA
                               |------------------> DNS, etc.
                                      DHCPv6

Figure 1 : CPE hôte comme initiateur de passage logiciel

Dans ce scénario, après que l'établissement du canal ou session de contrôle L2TPv2 et la négociation de LCP PPP (et facultativement l'authentification PPP) ont réussi, le protocole de contrôle IPv6 (IPV6CP) négocie IPv6 sur PPP, qui fournit aussi au FAI la capacité d'allouer l'identifiant d'interface de 64 bits au CPE hôte ou d'effectuer la validation d'unicité pour les deux identifiants d'interface aux deux extrémités PPP [RFC5072]. Après que IPv6 sur PPP est activé, l'auto configuration d'adresse IPv6 sans état / découverte de voisin fonctionne sur la liaison IPv6 sur PPP, et le LNS peut informer le CPE hôte d'un préfixe à utiliser pour l'auto configuration d'adresse sans état par une annonce de routeur (RA, Router Advertisement) tandis que d'autres options de configuration non d'adresse (comme du DNS [RFC3646] ou des adresses d'autres serveurs qui pourraient être disponibles) peuvent être envoyées  au CPE hôte via DHCPv6.

 	3.1.2	CPE routeur comme initiateur de passage logiciel
L'initiateur de passage logiciel (SI) est le CPE routeur, qui est un appareil double piles. Le trafic IPv4 NE DEVRAIT PAS traverser le passage logiciel. Voir la Figure 2.

          IPv6 ou double pile  IPv4 seulement      Double pile
         |------------------||-----------------||---------------------|

   I                    SC                          SI
   N                  +-----+                   +----------+
   T                  |     |                   |   CPE    |    +-----+
   E  <==[Réseau ]....|v4/v6|....[ Réseau  ]....|  v4/v6   |----|v4/v6|
   R     [ IPv6  ]    |     |    [IPv4 seul]    |          |    | hôte|
   N                  | LNS |                   |LAC client|    +-----+
   E                  +-----+                   +----------+
   T                          _ _ _ _ _ _ _ _ _
                            ()_ _ _ _ _ _ _ _ _() <-------- trafic IPv6 (SPH)
                          PPP o L2TPv2 o UDP o IPv4
                              passage logiciel

                            <------------------>
                    IPV6CP : capable d'allocation d'id d'interface /64 ou
                       de vérification d'unicité

                            |------------------> préfixe /64
                                     RA
                            |------------------> préfixe /48, DNS, etc.
                                   DHCPv6      

                                                     |-------> préfixe /64
                                                         RA
                                                     |-------> DNS, etc.
                                                     DHCPv4/v6

Figure 2 : CPE routeur comme initiateur de passage logiciel

Dans ce scénario, après que l'établissement du canal ou session de contrôle L2TPv2 et la négociation de LCP PPP (et facultativement l'authentification PPP) ont réussi, IPV6CP négocie IPv6 sur PPP, qui fournit aussi au FAI la capacité d'allouer l'identifiant d'interface de 64 bits au CPE routeur ou d'effectuer la validation d'unicité pour les deux identifiants d'interface aux deux extrémités PPP [RFC5072]. Après que IPv6 sur PPP est activé, l'auto configuration d'adresse IPv6 sans état / découverte de voisin fonctionne sur la liaison IPv6 sur PPP, et le LNS peut informer le CPE routeur d'un préfixe à utiliser pour l'auto configuration d'adresse sans état par une annonce de routeur (RA). DHCPv6 peut être utilisé pour effectuer la délégation de préfixe IPv6 (par exemple, délégant un préfixe à utiliser dans le réseau de rattachement [RFC3633]) et porter d'autres options de configuration non d'adresse (comme du DNS [RFC3646]) au CPE routeur.

 	3.1.3	Hôte derrière CPE comme initiateur de passage logiciel
Le CPE est IPv4 seulement. L'initiateur de passage logiciel (SI) est un hôte double piles (derrière le CPE IPv4 seulement) qui agit comme un CPE hôte IPv6. Le trafic IPv4 NE DEVRAIT PAS traverser le passage logiciel. Voir la Figure 3.

          IPv6 ou double pile  IPv4 seulement      Double piles
         |------------------||-----------------||---------------------|

    I                   SC                                    SI
    N                 +-----+                              +----------+
    T                 |     |                   +-------+  |   Hôte   |
    E <==[Réseau ]....| LNS |....[ Réseau  ]....|v4 seul|--|   v4/v6  |
    R    [ IPv6  ]    |v4/v6|    [IPv4 seul]    |  CPE  |  |          |
    N                 |     |                   +-------+  |LAC client|
    E                 +-----+                              +----------+
    T                         _ _ _ _ _ _ _ _ _ _ _ _ _ _
                            ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- trafic IPv6 (SPH)
                               PPP o L2TPv2 o UDP o IPv4
                                     passage logiciel

                            <------------------------------>
                    IPV6CP : capable d'allocation d'id d'interface /64 ou
                       de vérification d'unicité

                            |------------------------------> préfixe /64
                                           RA
                            |------------------------------>DNS, etc.
                                         DHCPv6

Figure 3 : Hôte derrière CPE comme initiateur de passage logiciel

Dans ce scénario, après que l'établissement du canal ou session de contrôle L2TPv2 et la négociation de LCP PPP (et facultativement l'authentification PPP) ont réussi, IPV6CP négocie IPv6 sur PPP, qui fournit aussi au FAI la capacité d'allouer l'identifiant d'interface de 64 bits à l'hôte ou d'effectuer la validation d'unicité pour les deux identifiants d'interface aux deux extrémités PPP [RFC5072]. Après l'activité de IPv6 sur PPP, l'auto configuration d'adresse IPv6 sans état / découverte de voisin fonctionne sur la liaison IPv6 sur PPP, et le LNS peut informer l'hôte d'un préfixe à utiliser pour l'auto configuration d'adresse sans état par une annonce de routeur (RA) tandis que d'autres options de configuration non d'adresse (comme du DNS [RFC3646]) peuvent être envoyées  au CPE hôte via DHCPv6.

 	3.1.4	Routeur derrière un CPE comme initiateur de passage logiciel
Le CPE est IPv4 seul. L'initiateur de passage logiciel (SI) est un appareil double piles (derrière le CPE IPv4 seul) agissant comme un routeur CPE IPv6 à l'intérieur du réseau de rattachement. Le trafic IPv4 NE DEVRAIT PAS traverser le passage logiciel. Voir la Figure 4.

          IPv6 ou double pile  IPv4 seulement      Double piles
         |------------------||-----------------||---------------------|

   I                   SC                                 SI
   N                 +-----+                           +----------+
   T                 |     |               +-------+   |  Routeur |
   E <==[Réseau ]....| LNS |..[Réseau   ]..|  CPE  |---|  v4/v6   |
   R    [ IPv6  ]    |v4/v6|  [IPv4 seul]  |v4 seul| | |          |
   N                 |     |               +-------+ | |LAC client|
   E                 +-----+                         | +----------+
   T                                                 |
                                                     ---------+-----+
                                                              | Hôte|
                                                              |v4/v6|
                             _ _ _ _ _ _ _ _ _ _ _ _ _        +-----+
                           ()_ _ _ _ _ _ _ _ _ _ _ _ _() <-- trafic IPv6 (SPH)
                              PPP o L2TPv2 o UDP o IPv4
                                   passage logiciel

                           <--------------------------->
                    IPV6CP : capable d'allocation d'id d'interface /64 ou
                       de vérification d'unicité

                           |---------------------------> préfixe /64
                                         RA
                           |---------------------------> préfixe /48, DNS, etc.
                                       DHCPv6          

                                                         |----> préfixe /64
                                                           RA  
                                                         |----> DNS, DHCPv6 etc.

Figure 4 : Routeur derrière CPE comme initiateur de passage logiciel

Dans ce scénario, après que l'établissement du canal ou session de contrôle L2TPv2 et la négociation de LCP PPP (et facultativement l'authentification PPP) ont réussi, IPV6CP négocie IPv6 sur PPP, qui fournit aussi au FAI la capacité d'allouer l'identifiant d'interface de 64 bits au routeur v4/v6 ou d'effectuer la validation d'unicité pour les deux identifiants d'interface aux deux extrémités PPP [RFC5072]. Après l'activation de IPv6 sur PPP, l'auto configuration d'adresse IPv6 sans état / découverte de voisin fonctionne sur la liaison IPv6 sur PPP, et le LNS peut informer le CPE routeur d'un préfixe à utiliser pour l'auto configuration d'adresse sans état par une annonce de routeur (RA). DHCPv6 peut être utilisé pour effectuer une délégation de préfixe IPv6 (par exemple, déléguer un préfixe à utiliser dans le réseau de rattachement [RFC3633]) et porter d'autres options de configuration non d'adresse (comme du DNS [RFC3646]) au routeur v4/v6.

 	3.2	Passages logiciels IPv4 sur IPv6 avec L2TPv2
Les paragraphes qui suivent couvrent la connexité IPv4 (SPH) à travers un réseau d'accès IPv6 seul (STH) en utilisant un passage logiciel.

 	3.2.1	CPE hôte comme initiateur de passage logiciel
L'initiateur de passage logiciel (SI) est le CPE hôte (directement connecté à un modem) qui  est double piles. Il n'y a pas d'autre appareil de passerelle. Le trafic IPv6 NE DEVRAIT PAS traverser le passage logiciel. Voir la Figure 5.

          IPv6 ou double pile  IPv4 seulement      Double piles
         |------------------||-----------------||---------------------|

       I                   SC                          SI
       N                 +-----+                   +----------+
       T                 |     |                   | CPE hôte |
       E <==[Réseau ]....| LNS |....[ Réseau  ]....|  v4/v6   |
       R    [ IPv4  ]    |v4/v6|    [IPv6 seul]    |          |
       N                 |     |                   |LAC client|
       E                 +-----+                   +----------+
       T                         _ _ _ _ _ _ _ _ _
                               ()_ _ _ _ _ _ _ _ _() <-- trafic IPv4 (SPH)
               passage logiciel PPP o L2TPv2 o UDP o IPv6         

                               <------------------>
                       IPCP: capable d'allocation IP mondiale et DNS, etc.

Figure 5 : CPE hôte comme initiateur de passage logiciel

Dans ce scénario, après que l'établissement du canal ou session de contrôle L2TPv2 et la négociation de LCP PPP (et facultativement l'authentification PPP) ont réussi, le protocole de contrôle IP (IPCP) négocie IPv4 sur PPP, qui fournit aussi au FAI la capacité d'allouer une adresse IPv4 mondiale au CPE hôte. Une adresse IPv4 mondiale peut aussi être allouée via DHCP. D'autres options de configuration (comme le DNS) peuvent être portées au CPE hôte via IPCP [RFC1877] ou DHCP [RFC2132].

 	3.2.2	CPE routeur comme initiateur de passage logiciel
L'initiateur de passage logiciel (SI) est le CPE routeur, qui est un appareil double pile. Le trafic IPv6 NE DEVRAIT PAS traverser le passage logiciel. Voir la Figure 6.

          IPv6 ou double pile  IPv4 seulement   Double piles de rattachement
         |------------------||-----------------||-------------------------|

   I                   SC                          SI
   N                 +-----+                   +----------+
   T                 |     |                   | CPE v4/v6|  +-----+
   E <==[Réseau ]....| LNS |....[ Réseau  ]....|          |--|Hôte |
   R    [ IPv4  ]    |v4/v6|    [IPv6 seul]    |          |  |v4/v6|
   N                 |     |                   |LAC client|  +-----+
   E                 +-----+                   +----------+
   T                         _ _ _ _ _ _ _ _ _
                           ()_ _ _ _ _ _ _ _ _() <--------- trafic IPv4 (SPH)
                         PPP o L2TPv2 o UDP o IPv6
                             passage logiciel

                           <------------------>
                       IPCP : capable d'allocation IP mondiale et DNS, etc.

                           |------------------>
                         DHCPv4 : préfixe, gabarit, PD

                                                               IP privée/mondiale,
                                                         |----> DNS, etc.
                                                          DHCP 

Figure 6 : Routeur CPE comme initiateur de passage logiciel

Dans ce scénario, après que l'établissement du canal ou session de contrôle L2TPv2 et la négociation de LCP PPP (et facultativement l'authentification PPP) ont réussi, IPCP négocie IPv4 sur PPP, qui fournit aussi au FAI la capacité d'allouer une adresse IPv4 mondiale au CPE routeur. Une adresse IPv4 mondiale peut aussi être allouée via DHCP. D'autres options de configuration (comme le DNS) peuvent être portées au CPE routeur via IPCP [RFC1877] ou DHCP [RFC2132]. Pour la délégation de préfixe IPv4 pour le réseau de rattachement, DHCP [RFC6656] peut être utilisé.

 	3.2.3	Hôte derrière CPE comme initiateur de passage logiciel
Le CPE est IPv6 seul. L'initiateur de passage logiciel (SI) est un hôte double piles (derrière le CPE IPv6) qui agit comme un CPE hôte IPv4. Le trafic IPv6 NE DEVRAIT PAS traverser le passage logiciel. Voir la Figure 7.

        IPv6 ou double piles   IPv4 seulement      Double piles
         |------------------||-----------------||---------------------|

    I                   SC                                      SI
    N                 +-----+                              +----------+
    T                 |     |                   +-------+  |   Hôte   |
    E <==[Réseau ]....| LNS |....[ Réseau  ]....| CPE   |--|   v4/v6  |
    R    [ IPv4  ]    |v4/v6|    [IPv6 seul]    |v6 seul|  |          |
    N                 |     |                   +-------+  |LAC client|
    E                 +-----+                              +----------+
    T                         _ _ _ _ _ _ _ _ _ _ _ _ _ _
                            ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- trafic IPv4
                               PPP o L2TPv2 o UDP o IPv6       
                                   passage logiciel

                            <------------------------------>
                       IPCP : capable d'allocation IP mondiale et DNS, etc.

Figure 7 : Hôte derrière CPE comme initiateur de passage logiciel

Dans ce scénario, après que l'établissement du canal ou session de contrôle L2TPv2 et la négociation de LCP PPP (et facultativement l'authentification PPP) ont réussi, IPCP négocie IPv4 sur PPP, qui fournit aussi au FAI la capacité d'allouer une adresse IPv4 mondiale à l'hôte. Une adresse IPv4 mondiale peut aussi être allouée via DHCP. D'autres options de configuration (comme le DNS) peuvent être portées au CPE hôte via IPCP [RFC1877] ou DHCP [RFC2132].

 	3.2.4	Routeur derrière CPE comme initiateur de passage logiciel
Le CPE est IPv6 seulement. L'initiateur de passage logiciel (SI) est un appareil double piles (derrière le CPE IPv6 seul) agissant comme un CPE routeur IPv4 dans le réseau de rattachement. Le trafic IPv6 NE DEVRAIT PAS traverser le passage logiciel. Voir la Figure 8.

        IPv6 ou double piles  IPv4 seulement      Double piles
         |------------------||-----------------||---------------------|

   I                   SC                                 SI
   N                 +-----+                           +----------+
   T                 |     |               +-------+   | Routeur  |
   E <==[Réseau ]....| LNS |..[ Réseau  ]..|  CPE  |---|  v4/v6   |
   R    [ IPv4  ]    |v4/v6|  [IPv6 seul]  |v6 seul| | |          |
   N                 |     |               +-------+ | |LAC client|
   E                 +-----+                         | +----------+
   T                                                 |
                                                     --------+-----+
                                                             | Hôte|
                                                             |v4/v6|
                             _ _ _ _ _ _ _ _ _ _ _ _ _       +-----+
                           ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- trafic IPv4
                             PPP o L2TPv2 o UDP o IPv4
                                   passage logiciel

                           <--------------------------->
                   IPCP : alloue une adresse mondiale IP et DNS, etc.

                           |--------------------------->
                              DHCPv4 : préfixe, gabarit, PD

                                                               IP privée/mondiale,
                                                         |----> DNS, etc.
                                                          DHCP 

Figure 8 : Routeur derrière CPE comme initiateur de passage logiciel

Dans ce scénario, après que l'établissement du canal ou session de contrôle L2TPv2 et la négociation de LCP PPP (et facultativement l'authentification PPP) ont réussi, IPCP négocie IPv4 sur PPP, qui fournit aussi au FAI la capacité d'allouer une adresse IPv4 mondiale au routeur v4/v6. Une adresse IPv4 mondiale peut aussi être allouée via DHCP. D'autres options de configuration (comme le DNS) peuvent être apportées au routeur v4/v6 via IPCP [RFC1877] ou DHCP [RFC2132]. Pour la délégation de préfixe IPv4 pour le réseau de rattachement, DHCP [RFC6656] peut être utilisé.

 	4.	Références aux documents de normalisation

Cette section fait la liste et groupe les documents de la normalisation de l'Internet qui décrivent les technologies utilisées pour concevoir le cadre de la solution "centre et rayons" de passage logiciel. Cela souligne la motivation de Softwire de réutiliser autant que possible beaucoup des normes existantes. Cette liste contient des documents sur la voie de la normalisation (normes proposées, projets de normes, et normes) et d'information. La liste des documents et leur statut devraient seulement être seulement utilisés pour des besoins de description.

 	4.1	L2TPv2
 [RFC2661] "Protocole de tunnelage de couche 2 (L2TP)".
*	Pour les charges utiles IPv4 et IPv6 (SPH) la prise en charge est complète.
*	Pour les transports IPv4 et IPv6 (STH) la prise en charge est complète.

 	4.2	Sécurisation du transport de passage logiciel
[RFC3193] "Sécurisation de L2TP avec IPsec".

[RFC3948] "Encapsulation UDP de paquets IPsec ESP".
*	IPsec prend en charge les transports IPv4 et IPv6.

 	4.3	Authentification, autorisation, et comptabilité
[RFC2865] "Authentification à distance du service d'utilisateur appelant (RADIUS)".
* Mis à jour par les [RFC2868], [RFC3575], et [RFC5080].

[RFC2867] "Modifications de la comptabilité RADIUS pour la prise en charge du protocole de tunnel".

[RFC2868] "Attributs RADIUS pour la prise en charge du protocole de tunnel".

[RFC3162] "RADIUS et IPv6" .

 	4.4	MIB
[RFC1471] "Définitions des objets gérés pour le protocole de gestion de liaison du protocole Point à Point".

[RFC1473] "Définitions des objets gérés pour le protocole de contrôle de réseau IP du protocole point à point".

[RFC3371] "Base d'informations de gestion du protocole de tunnelage de couche 2 "L2TP".

[RFC4087] "MIB de tunnel IP".
* Les transports IPv4 et IPv6 sont tous deux pris en charge.

 	4.5	Charge utile relative au passage logiciel
 	4.5.1	Pour charges utiles IPv6
[RFC4861] "Découverte de voisin pour IP version 6 (IPv6)".

[RFC4862] "Auto configuration d'adresse IPv6 sans état".

[RFC5072] "IP version 6 sur PPP" .

[RFC3315] "Protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)".

[RFC3633] "Options de préfixe IPv6 pour le protocole de configuration dynamique d'hôte (DHCP) version 6".

[RFC3646] "Options de configuration du DNS pour le protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)".

[RFC3736] "Service du protocole de configuration dynamique d'hôte sans état (DHCP) pour IPv6".

 	4.5.2	Pour charges utiles IPv4
[RFC1332] "Protocole de contrôle du protocole PPP Internet (IPCP)".

[RFC1661] "Protocole point à point (PPP)".

[RFC1877] "Extensions du protocole de contrôle de réseau pour la configuration d'adresses de serveurs de noms sur IP en PPP".

[RFC2131] "Protocole de configuration dynamique d'hôte".

[RFC2132] "Options DHCP et extensions de fabricant BOOTP".

[RFC6656] "Option allocation de sous réseau".

 	5.	Établissement de passage logiciel

Un passage logiciel est établi en trois étapes distinctes, potentiellement précédées par une étape 0 facultative relative à IPsec (voir la Figure 9). D'abord, un tunnel L2TPv2 avec une seule session est établi du SI au SC. Ensuite, une session PPP est établie sur la session L2TPv2 et le SI obtient une adresse. Enfin, le SI obtient facultativement d'autres informations par DHCP comme un préfixe délégué et des serveurs DNS.

      SC                                 SI
       |                                 |
       |<-------------IKEv1------------->| Étape 0
       |                                 | Établissement de SA IPsec (facultatif)
       |                                 |
       |<-------------L2TPv2------------>| Étape 1
       |                                 | Établissement de tunnel L2TPv2
       |                                 |
       |<--------------PPP-------------->| Étape 2
       |<--Config. de point d'extrémité->| Configuration PPP et point d'extrémité
       |                                 |
       |<---Configuration de routeur---->| Étape 3
       |                                 | Configuration supplémentaire
       |                                 | (facultatif)

Figure 9 : Étapes de l'établissement d'un passage logiciel

La Figure 10 décrit les détails de chaque étape requise pour établir un passage logiciel.

         SC                                 SI
          |                                 |
          |                                 | Étape 0
          |<------------IKEv1-------------->| = IKEv1 (Facultatif)
          |                                 |
          |                                 | Étape 1
          |<------------SCCRQ---------------| -
          |-------------SCCRP-------------->| |
          |<------------SCCCN---------------| |
          |<------------ICRQ----------------| | L2TPv2
          |-------------ICRP--------------->| |
          |<------------ICCN----------------| -
          |                                 |
          |                                 | Étape 2
          |<-----Configuration-Request------| -
          |------Configuration-Request----->| | PPP
          |--------Configuration-Ack------->| | LCP
          |<-------Configuration-Ack--------| -
          |                                 |
          |-----------Défi----------------->| - Authentification PPP
          |<----------Réponse---------------| | (Facultative - CHAP)
          |------------Succès-------------->| -
          |                                 |
          |<-----Configuration-Request------| -
          |------Configuration-Request----->| | PPP NCP
          |--------Configuration-Ack------->| | (IPV6CP ou IPCP)
          |<-------Configuration-Ack--------| -
          |                                 |
          |<------Router-Solicitation-------| - Découverte de voisin
          |-------Router-Advertisement----->| | (IPv6 seulement)
          |                                 | -
          |                                 |
          |                                 | Étape 3
          |                                 | DHCP (facultatif)
          |<-----------SOLICIT--------------| -
          |-----------ADVERTISE------------>| | DHCPv6
          |<---------- REQUEST--------------| | (IPv6 SW, facultatif)
          |-------------REPLY-------------->| -
          |                                 | ou
          |<---------DHCPDISCOVER-----------| -
          |-----------DHCPOFFER------------>| | DHCPv4
          |<---------DHCPREQUEST------------| | (SW IPv4, facultatif)
          |------------DHCPACK------------->| -

Figure 10 : Étapes détaillées de l'établissement d'un passage logiciel

Les négociations relatives à IPsec dans l'étape 0 sont facultatives. Les négociations L2TPv2 dans l'étape 1 sont décrites au paragraphe 5.1. Les négociations du protocole de contrôle de réseau (NCP, Network Control Protocol) PPP dans l'étape 2 utilisent IPV6CP pour les passages logiciels IPv6 sur IPv4, et IPCP pour les passages logiciels IPv4 sur IPv6 (voir le paragraphe 5.2.4). Les négociations DHCP facultatives dans l'étape 3 utilisent DHCPv6 pour les passages logiciels IPv6 sur IPv4, et DHCPv4 pour les passages logiciels IPv4 sur IPv6 (voir le paragraphe 5.4). De plus, pour les passages logiciels IPv6 sur IPv4, l'échange DHCPv6 pour une configuration non d'adresse (comme du DNS) peut utiliser DHCPv6 sans état, l'échange de deux messages avec des messages Demande d'information et Réponse d'information (voir le paragraphe 1.2 de la [RFC3315] et la [RFC3736]).

 	5.1	Établissement de tunnel L2TPv2
L2TPv2 [RFC2661] était à l'origine conçu pour fournir un accès de réseau privé aux utilisateurs finaux connectés à un réseau public. Dans le modèle d'appel entrant L2TPv2, l'utilisateur final fait une connexion à un concentrateur d'accès L2TP (LAC, L2TP Access Concentrator). Le LAC initie alors un tunnel L2TPv2 à un serveur de réseau L2TP (LNS, L2TP Network Server). Le LNS transfère alors le trafic de l'utilisateur final entre le tunnel L2TPv2 et le réseau privé.

Dans le modèle de passage logiciel "centre et rayons", l'initiateur de passage logiciel (SI) assume le rôle de client de LAC et le concentrateur de passage logiciel (SC) assume le rôle de LNS.

Dans le modèle de passage logiciel, un paquet L2TPv2 DOIT être porté sur UDP. La version sous-jacente de protocole IP peut être IPv4 ou IPv6, selon le scénario de passage logiciel.

Dans les paragraphes qui suivent, le terme "tunnel" suit la définition du paragraphe 1.2 de la [RFC2661], à savoir: "le tunnel consiste en une connexion de contrôle et zéro, une ou plusieurs sessions L2TP".

 	5.1.1	Établissement de tunnel
La Figure 11 décrit les messages échangés et les paires d'attribut valeurs (AVP) utilisées pour établir un tunnel entre un SI (LAC) et un SC (LNS). Les messages et AVP décrits ici sont seulement un sous ensemble de ceux définis dans la [RFC2661]. C'est parce que les passages logiciels utilisent seulement un sous ensemble de la fonctionnalité L2TPv2. Le sous ensemble des AVP de gestion de connexion de contrôle L2TP qui est applicable aux passages logiciels est groupé en AVP exigées et AVP facultatives par message de contrôle (voir la Figure 11). Pour chaque message de contrôle, les AVP exigées incluent toutes les AVP "DOIT être présente" de la [RFC2661] pour ce message de contrôle, et les AVP facultatives incluent les AVP "PEUT être présente" de la [RFC2661] qui sont utilisées dans le contexte de passage logiciel sur ce message de contrôle. Noter que dans l'environnement de passage logiciel, le SI initie toujours les AVP de tunnel. Les AVP L2TPv2 NE DEVRAIENT PAS être cachées.

                        SC                       SI
                         |<--------SCCRQ---------|
                          AVP exigées :
                             Type de message 
                             Version de protocole
                             Nom d'hôte
                             Capacités de tramage
                             Identifiant de tunnel alloué
                          AVP facultatives :
                             Taille de fenêtre de réception
                             Défi
                             Révision de logiciel
                             Nom de fabricant

                         |---------SCCRP-------->|
                          AVP exigées :
                             Type de message 
                             Version de protocole
                             Capacités de tramage
                             Nom d'hôte
                             Identifiant de tunnel alloué
                          AVP facultatives :
                             Révision de logiciel
                             Nom de fabricant
                             Taille de fenêtre de réception
                             Défi
                             Réponse au défi

                         |<--------SCCCN---------|
                          AVP exigées :
                             Type de message 
                          AVP facultatives :
                             Réponse au défi

Figure 11 : Établissement de connexion de contrôle

Dans L2TPv2, généralement, le tunnel entre un LAC et un LNS peut porter les données de plusieurs utilisateurs. Chacun de ces utilisateurs est représenté par une session L2TPv2 au sein du tunnel. Dans l'environnement de passage logiciel, le tunnel porte les informations d'un seul utilisateur. Par conséquent, il y a seulement une session L2TPv2 par tunnel. La Figure 12 décrit les messages échangés et les AVP utilisées pour établir une session entre un SI (LAC) et un SC (LNS). Les messages et AVP décrits ici sont seulement un sous ensemble de ceux définis dans la [RFC2661]. C'est parce que les passages logiciels utilisent seulement un sous ensemble de la fonctionnalité de L2TPv2. Le sous ensemble des AVP de gestion d'appel L2TP (c'est-à-dire, de gestion de session) qui est applicable aux passages logiciels est groupé dans les AVP exigées et les AVP facultatives par message de contrôle (voir la Figure 12). Pour chaque message de contrôle, les AVP exigées incluent toutes les AVP qui "DOIVENT être présentes" d'après la [RFC2661] pour ce message de contrôle, et les AVP facultatives incluent les AVP qui "PEUVENT être présentes" d'après la [RFC2661] qui sont utilisées dans le contexte de passage logiciel sur ce message de contrôle. Noter que dans l'environnement de passage logiciel, le SI initie toujours la session. Un établissement de session L2TPv2 pour un passage logiciel utilise seulement le modèle d'appel entrant. Aucun appel sortant ou analogue (session) n'est permis. Les AVP L2TPv2 NE DEVRAIENT PAS être cachées.

                         SC                      SI
                          |<--------ICRQ---------|
                           AVP exigées :
                              Type de message
                              Identifiant de session alloué
                              Numéro de série d'appel

                          |---------ICRP-------->|
                           AVP exigées :
                              Type de message
                              Identifiant de session alloué

                          |<--------ICCN---------|
                           AVP exigées :
                              Type de message
                              Vitesse de connexion (Tx)
                              Type de tramage

Figure 12 : Établissement de session 

Les paragraphes suivants (5.1.1.1 à 5.1.1.3) décrivent plus en détails les AVP établies pour la connexion et session de contrôle (voir les flux de messages dans les Figures 11 et 12, respectivement) qui sont exigées, facultatives et non pertinentes pour l'établissement de tunnel L2TPv2 d'un passage logiciel. Les messages et flux de protocole spécifiques de L2TPv2 qui ne sont pas explicitement décrits dans ces paragraphes sont traités comme défini dans la [RFC2661].

Le mécanisme pour cacher les valeurs d'attribut d'AVP est utilisé, comme décrit au paragraphe 4.3 de la [RFC2661], pour cacher les données sensibles de message de contrôle comme les noms d'utilisateur, les mots de passe d'utilisateur, ou les identifiants, au lieu d'envoyer le contenu de l'AVP en clair. Comme les AVP utilisées dans les messages2TP pour l'établissement de passage logiciel ne transportent pas de telles données sensibles, les AVP L2TPv2 NE DEVRAIENT PAS être cachées.

 	5.1.1.1	AVP requises pour les passages logiciels
Ce paragraphe prescrit les valeurs spécifiques pour les AVP dont la présence est exigée (par la [RFC2661]) dans un ou plusieurs des messages utilisés pour l'établissement du passage logiciel, comme elles sont utilisées dans le contexte de passage logiciel. Il combine toutes les AVP exigées provenant de tous les messages de contrôle du paragraphe 5.1.1, et donne des lignes directrices d'utilisation spécifiques de passage logiciel.

AVP Nom d'hôte : cette AVP est exigée dans les messages SCCRQ et SCCRP. Cette AVP PEUT être utilisée pour authentifier les utilisateurs, cas dans lequel elle va contenir une identification d'utilisateur. Si cette AVP n'est pas utilisée pour authentifier des utilisateurs, elle peut être utilisée à des fins d'enregistrement.

AVP Capacités de tramage : les deux bits synchrone (S) et asynchrone (A) DEVRAIENT être réglés à 1. Cette AVP DEVRAIT être ignorée par le receveur.

AVP Type de tramage : le bit synchrone DEVRAIT être réglé à 1 et le bit asynchrone à 0. Cette AVP DEVRAIT être ignorée par le receveur.

AVP Vitesse de connexion (Tx) : Vitesse de connexion (Tx) est une AVP exigée mais n'est pas significative dans le contexte de passage logiciel. Sa valeur DEVRAIT être réglée à 0 et ignorée par le receveur.

AVP Type de message, AVP Version de protocole, AVP Identifiant de tunnel alloué, AVP Numéro de série d'appel, et AVP Identifiant de session alloué : comme défini dans la [RFC2661].

 	5.1.1.2	AVP facultatives pour les passages logiciels
Ce paragraphe prescrit les valeurs spécifiques pour les AVP qui sont facultatives (non exigées par la [RFC2661]) mais utilisées dans le contexte de passage logiciel. Il combine toutes les AVP facultatives de tous les messages de contrôle du paragraphe 5.1.1, et donne des lignes directrices d'utilisation spécifiques de passage logiciel.

AVP Défi et AVP Réponse de défi : ces AVP ne sont pas exigées, mais sont nécessaires pour mettre en œuvre l'authentification de tunnel. Comme l'authentification de tunnel arrive au début de la création du tunnel L2TPv2, elle peut être utile pour prévenir les attaques de déni de service (DoS). Voir le paragraphe 5.1.1 de la [RFC2661].

L'usage de ces AVP dans les messages L2TP est FACULTATIF, mais DEVRAIT être mis en œuvre dans le SC.

AVP Taille de fenêtre de réception, AVP Révision de logiciel, et AVP Nom de fabricant : comme défini dans la [RFC2661].

 	5.1.1.3	AVP non pertinentes pour les passages logiciels
L2TPv2 spécifie de nombreuses AVP qui, bien que permises pour un message donné, ne sont pas pertinentes pour les passages logiciels. Ce peut être parce que elles ne s'appliquent pas au flux d'établissement du passage logiciel (par exemple, elles sont seulement utilisées dans l'échange de message d'établissement d'appel sortant, tandis que les passages logiciels utilisent seulement le flux de messages d'appel entrant) ou parce qu'elles sont des AVP facultatives qui ne sont pas utilisées. Les AVP L2TPv2 qui sont pertinentes pour les passages logiciels ont été traitées dans les paragraphes 5.1.1, 5.1.1.1, et 5.1.1.2. Les mises en œuvre de passages logiciels NE DEVRAIENT PAS envoyer des AVP qui ne sont pas pertinentes pour les passages logiciels. Cependant, elles DEVRAIENT les ignorer quand elles sont reçues. Cela va simplifier la création des applications de passage logiciel qui s'appuient sur les mises en œuvre existantes de L2TPv2.

 	5.1.2	Maintenance de tunnel
Périodiquement, le SI/SC DOIT transmettre un message à l'homologue pour détecter une défaillance du tunnel ou de l'homologue et maintenir les contextes de NAT/NAPT. Le message L2TPv2 HELLO fournit une méthode simple, à faible frais, pour faire cela.

Les valeurs par défaut spécifiées dans la [RFC2661] pour les messages L2TPv2 HELLO pourraient résulter en un temps de détection d'extrémité morte de 83 secondes. Bien que ces temporisateurs et compteurs de retransmission DEVRAIENT être configurables (voir le paragraphe 5.8 de la [RFC2661]) ces valeurs ne peuvent pas être adaptées pour toutes les situations, lorsque une détection d'extrémité morte plus rapide est exigée, ou lorsque le contexte de NAT/NAPT a besoin d'être rafraîchi plus fréquemment. Dans ces cas, le SI/SC PEUT utiliser, en combinaison avec les messages L2TPv2 HELLO, les messages LCP ECHO (codes de demande d'écho et de réponse d'écho) décrits dans la [RFC1661]. Quand ils sont utilisés, les messages LCP ECHO DEVRAIENT avoir un temporisateur de ré-émission inférieur à la valeur pour les messages L2TPv2 HELLO. La valeur par défaut recommandée au paragraphe 6.5 de la [RFC2661] pour l'intervalle de retransmission de message HELLO est de 60 secondes. Quand il est utilisé, un ensemble de valeurs suggérées (incluses ici à titre d'indication) pour l'intervalle de demande de message LCP ECHO est par défaut de 30 secondes, un minimum de 10  secondes, et un maximum du plus court de l'intervalle de retransmission de L2TPv2 HELLO configuré et 60 secondes.

 	5.1.3	Suppression de tunnel
Le SI ou le SC peut supprimer la session et le tunnel. Ceci est fait comme spécifié au paragraphe 5.7 de la [RFC2661], en envoyant un message de contrôle StopCCN. Il n'y a pas d'action spécifique des passages logiciels dans ce cas.

 	5.1.4	Considérations supplémentaires sur L2TPv2
Dans le cadre de "centre et rayons" de passage logiciel, L2TPv2 est mis en couche par dessus UDP, au titre d'un tunnel IP dans IP ; le paragraphe 8.1 de la [RFC2661] décrit L2TP sur UDP/IP. Donc, les lignes directrices d'UDP spécifiées dans la [RFC5405] s'appliquent, car elles relèvent des scénarios de tunnelage UDP portant du trafic fondé sur IP. Le paragraphe 3.1.3 de la [RFC5405] spécifie que dans ce cas, des mécanismes spécifiques du contrôle d'encombrement pour le tunnel ne sont pas nécessaires. De plus, le paragraphe 3.2 de la [RFC5405] donne des directives pour la taille de message pour les datagrammes d'encapsulation (externes) incluant la recommandation de mettre en œuvre la découverte de la MTU du chemin (PMTUD).

 	5.2	Connexion PPP
Ce paragraphe décrit les négociations PPP entre le SI et le SC dans le contexte de passage logiciel.

 	5.2.1	MTU
La MTU de la liaison PPP présentée au SPH DEVRAIT être la MTU de liaison moins la taille des en-têtes IP, UDP, L2TPv2, et PPP ensemble. Sur une liaison IPv4 avec une MTU égale à 1500 octets, cela pourrait normalement signifier une MTU PPP de 1460 octets. Quand la liaison est gérée par IPsec, cette MTU DEVRAIT être diminuée pour tenir compte de l'encapsulation ESP (voir la [RFC5619]). La valeur de la MTU peut aussi varier selon la taille de l'en-tête L2TP, comme défini par les bits du début de l'en-tête de message L2TP (voir la [RFC2661]). De plus, voir dans la [RFC4623] une discussion détaillée des questions de fragmentation.

 	5.2.2	LCP
Une fois la session L2TPv2 établie, le SI et le SC initie la connexion PPP en négociant LCP comme décrit dans la [RFC1661]. L'option de configuration Compression de champ Adresse et Contrôle (ACFC, Address-and-Control-Field-Compression) [RFC1661] PEUT être rejetée.

 	5.2.3	Authentification
Après l'achèvement de la négociation LCP, le SI et le SC PEUVENT facultativement effectuer l'authentification. Si l'authentification est choisie, l'authentification du protocole d’authentification par dialogue à énigme (CHAP, Challenge Handshake Authentication Protocol) [RFC1994] DOIT être prise en charge par l'initiateur de passage logiciel et par le concentrateur de passage logiciel. D'autres méthodes d'authentification comme Microsoft CHAP version 1 (MS-CHAPv1) [RFC2433] et le protocole d'authentification extensible (EAP, Extensible Authentication Protocol) [RFC3748] PEUVENT être prises en charge.

Une discussion détaillée de la sécurité du passage logiciel figure dans la [RFC5619].

 	5.2.4	IPCP
Le seul protocole de contrôle de réseau (NCP, Network Control Protocol) négocié dans le contexte du passage logiciel est IPV6CP (voir le paragraphe 5.2.4.1) pour IPv6 comme SPH, et IPCP (voir le paragraphe 5.2.4.2) pour IPv4 comme SPH.

 	5.2.4.1	IPV6CP
Dans les scénarios IPv6 sur IPv4 (voir le paragraphe 3.1) après la phase facultative d'authentification, l'initiateur de passage logiciel DOIT négocier IPV6CP comme défini dans la [RFC5072]. IPV6CP fournit un moyen de négocier un identifiant d'interface unique de 64 bits à utiliser pour l'auto configuration d'adresse à l'extrémité locale de la liaison.

 	5.2.4.2	IPv4CP
Dans les scénarios IPv4 sur IPv6 (voir le paragraphe 3.2) un initiateur de passage logiciel DOIT négocier IPCP [RFC1332]. Le SI utilise IPCP pour obtenir du SC une adresse IPv4. IPCP PEUT aussi être utilisé pour obtenir des informations du DNS comme décrit dans la [RFC1877].

 	5.3	Allocation d'adresse IPv6 mondiale aux points d'extrémité
Dans plusieurs scénarios définis au paragraphe 3.1, les adresses IPv6 mondiales sont supposées être allouées aux points d'extrémité de passage logiciel (en plus des adresses de liaison locale auto configurée en utilisant l'identifiant d'interface IPV6CP négocié). L'initiateur de passage logiciel alloue les adresses IPv6 mondiales en utilisant l'identifiant d'interface IPV6CP négocié et en utilisant l'auto configuration d'adresse sans état [RFC4862], et/ou en utilisant les extensions de confidentialité pour l'auto configuration d'adresse sans état [RFC4941], (comme décrit dans la Section 5 de la [RFC5072]), et/ou en utilisant DHCPv6 [RFC3315].

L'initiateur de passage logiciel d'un passage logiciel IPv6 DOIT envoyer un message Sollicitation de routeur au concentrateur de passage logiciel après l'achèvement de IPV6CP. Le concentrateur de passage logiciel DOIT répondre avec une annonce de routeur. Ce message DOIT contenir le préfixe IPv6 mondial de la liaison PPP si la découverte de voisin est utilisée pour configurer les adresses des points d'extrémité de passage logiciel.

Si DHCPv6 est disponible pour la délégation d'adresse, les bits M de l'annonce de routeur DEVRAIENT être établis. L'initiateur de passage logiciel DOIT alors envoyer une demande DHCPv6 pour configurer l'adresse du point d'extrémité de passage logiciel.

La détection d'adresse dupliquée [RFC4861] DOIT être effectuée sur le passage logiciel dans les deux cas.

 	5.4	DHCP
L'initiateur de passage logiciel PEUT utiliser DHCP pour obtenir des informations supplémentaires comme le préfixe délégué et les serveurs DNS.

 	5.4.1	DHCPv6
Dans les scénarios du paragraphe 3.1, si le SI prend en charge DHCPv6, il DEVRAIT envoyer un message Sollicite pour vérifier si plus d'informations sont disponibles.

Si un SI établissant un passage logiciel IPv6 agit comme un routeur (c'est-à-dire, dans les scénarios des paragraphes 3.1.2 et 3.1.4) il DOIT inclure l'option Association d'identité pour délégation de préfixe (IA_PD) [RFC3633] dans le message DHCPv6 Sollicite [RFC3315] afin de demander un préfixe IPv6.

Quand il délègue un préfixe IPv6 au SI en retournant un message DHCPv6 Annonce avec les options Préfixe IA_PD et IP_PD [RFC3633], le SC DEVRAIT injecter un chemin pour ce préfixe dans le tableau d'acheminement IPv6 afin de transmettre le trafic au passage logiciel pertinent.

La configuration de DNS DOIT être faite comme spécifié dans la [RFC3646] et transmise conformément aux [RFC3315] et [RFC3736]. En général, toutes les options DHCPv6 DOIVENT être transmises conformément aux [RFC3315] et [RFC3736].

 	5.4.2	DHCPv4
Un SI établissant un passage logiciel IPv4 PEUT envoyer une demande DHCP contenant l'option Allocation de sous réseau [RFC6656]. Cette pratique n'est pas courante, mais peut être utilisée pour connecter des sous réseaux IPv4 en utilisant les passages logiciels, comme défini aux paragraphes 3.2.2 et 3.2.4.

Une sous option Demande de sous réseau DOIT être configurée avec le bit "h" réglé à "1", car le SI est supposé effectuer la fonction de serveur DHCP. Le bit "i" de la sous option Demande de sous réseau DEVRAIT être réglé à "0" la première fois qu'un préfixe est demandé et à "1" sur les demandes suivantes, si un préfixe a été alloué. La sous option Longueur de préfixe DEVRAIT être 0 par défaut. Si le SI est configuré à prendre en charge seulement des longueurs de préfixe spécifiques, il DEVRAIT spécifier la plus longue (plus courte) longueur de préfixe qu'il accepte.

Si un préfixe a été alloué précédemment au SI par le même SC, il DEVRAIT inclure la sous option Informations de sous réseau avec le préfixe alloué précédemment. Les bits "c" et "s" de la sous option DEVRAIENT être réglés à "0".

Dans les scénarios du paragraphe 3.2, quand il délègue un préfixe IPv4 au SI, le SC DEVRAIT injecter un chemin pour ce préfixe dans le tableau d'acheminement IPv4 afin de transmettre le trafic au passage logiciel pertinent.

 	6.	Considérations sur le modèle de provisionnement d'adresse

Cette section décrit comment un concentrateur de passage logiciel peut gérer les adresses déléguées pour les points d'extrémité de passage logiciel et pour les sous réseaux derrière l'initiateur de passage logiciel. Une pratique courante est d'agréger les adresses des points d'extrémité et les préfixes délégués en un préfixe acheminé au SC. Le principal avantage est de faciliter le schéma d'acheminement en isolant des injections suivantes de chemin au SC (quand il délègue de nouveaux préfixes pour le SI).

 	6.1	Adresses de points d'extrémité de passage logiciel
 	6.1.1	IPv6
Un concentrateur de passage logiciel devrait fournir des adresses d'acheminement mondial aux points d'extrémité de passage logiciel. D'autres types d'adresses comme des adresse locales uniques (ULA, Unique Local Address) [RFC4193] peuvent être utilisés pour l'adressage de points d'extrémité de passage logiciel dans un réseau privé sans connexité mondiale. Un seul /64 devrait être alloué au passage logiciel pour l'adressage des deux points d'extrémité de passage logiciel.

Des adresses mondiales ou des ULA doivent être allouées aux points d'extrémité quand le déploiement du scénario "CPE hôte comme initiateur de passage logiciel" (décrit au paragraphe 3.1.1) est considéré. Pour les autres scénarios, des adresses de liaison locale peuvent aussi être utilisées.

 	6.1.2	IPv4
Un concentrateur de passage logiciel peut fournir soit des adresses IPv4 d'acheminement mondial soit des adresses IPv4 privées. Quand il utilise des adresses IPv4 privées [RFC1918] sur les points d'extrémité, il n'est pas recommandé de déléguer un préfixe IPv4 privé au SI, car cela peut conduire à une situation de NAT incorporé.

Les points d'extrémité de la liaison PPP utilisent des adresses d'hôte (c'est-à-dire, /32) négociées en utilisant IPCP.

 	6.2	Préfixes délégués
 	6.2.1	Préfixes IPv6
Les préfixes IPv6 délégués devraient être de portée mondiale si les adresses IPv6 allouées aux points d'extrémité sont mondiales. Utiliser des ULA n'est pas recommandé quand le sous réseau est connecté à l'Internet IPv6 mondial. Quand on utilise des ULA IPv6 sur les points d'extrémité, le préfixe IPv6 délégué peut être de portée mondiabe ou d'ULA.

La longueur des préfixes IPv6 délégués est entre /48 et /64. Quand un SI reçoit un préfixe plus court que 64, il peut allouer des préfixes /64 différents à chacune de ses interfaces. Un SI qui reçoit un seul /64 est supposé effectuer un pontage si plus d'une interface est disponible (par exemple, filaire et sans fil).

 	6.2.2	Préfixes IPv4
Les préfixes IPv4 délégués devraient être acheminables au sein de l'espace d'adresses utilisé par les adresses IPv4 allouées.  Déléguer des préfixes IPv4 non acheminables (c'est-à-dire, un préfixe IPv4 privé sur des adresses IPv4 publiques ou sur une autre classe d'adresses IPv4 privées) n'est pas une pratique recommandée pour le provisionnement et la traduction d'adresse devrait être envisagée dans ces cas. La longueur de préfixe est entre /8 et /30.

 	6.3	Scénarios possibles de provisionnement d'adresse
Ce paragraphe résume les différents scénarios pour le provisionnement d'adresse avec les considérations données dans les paragraphes précédents.

 	6.3.1	Scénarios pour IPv6
Ce tableau décrit la combinaison possible d'une portée d'adresse IPv6 pour les points d'extrémité et les préfixes délégués.

Adresse de point d'extrémité IPv6	Préfixe délégué IPv6 mondial	Préfixe délégué d'ULA IPv6
Liaison locale	Possible	Possible
ULA	Possible	Possible
Mondiale	Possible	Possible, mais non recommandé

Tableau 1 : Scénarios pour IPv6

 	6.3.2	Scénarios pour IPv4
Ce tableau décrit la combinaison possible d'une portée d'adresse IPv4 pour les points d'extrémité et les préfixes délégués.

Adresse de point d'extrémité IPv4	Préfixe délégué IPv4 public	Préfixe délégué IPv4 privé
IPv4 privé	Possible	Possible, mais non recommandé quand on utilise un NAT (cf. paragraphe 6.1.2)
IPv4 public	Possible	Possible, mais l'usage de NAT est recommandé (cf. paragraphe 6.2.2)

Tableau 2 : Scénarios pour IPv4

 	7.	Considérations sur la stabilité d'adresse

Un passage logiciel peut fournir des adresses stables même si le schéma d'adressage sous-jacent change, par opposition à un tunnelage automatique. Un concentrateur de passage logiciel devrait toujours fournir la même adresse et le même préfixe à un utilisateur qui se reconnecte. Cependant, si le but du service de passage logiciel est de fournir une adresse temporaire pour un utilisateur en itinérance, il peut être provisionné à fournir seulement une adresse temporaire.

L'adresse et le préfixe sont supposés changer quand ils se reconnectent à un concentrateur de passage logiciel différent. Cependant, une organisation qui fournit un service de passage logiciel peut fournir la même adresse et le même préfixe à travers différents concentrateurs de passage logiciel au prix d'un tableau d'acheminement plus fragmenté. Le problème de la fragmentation de l'acheminement peut être limité si les préfixes sont agrégés dans une localisation topologiquement proche du SC. Cela serait le cas, par exemple, si plusieurs SC sont mis en parallèle pour les besoins d'équilibrage de charge.

 	8.	Considérations sur l'intégration de RADIUS

Le concentrateur de passage logiciel est supposé agir comme client d'un serveur AAA, par exemple, un serveur RADIUS. Durant la phase d'authentification PPP, le serveur RADIUS peut retourner des informations supplémentaires sous la forme d'attributs dans le message Access-Accept.

Le concentrateur de passage logiciel peut inclure les attributs Type de tunnel et Type de support de tunnel [RFC2868] dans les messages Access-Request pour fournir une indication du type de passage logiciel configuré.

 	8.1	Points d'extrémité de passage logiciel
 	8.1.1	Passages logiciels IPv6
Si le serveur RADIUS inclut un attribut Framed-Interface-Id [RFC3162], le concentrateur de passage logiciel doit l'envoyer à l'initiateur de passage logiciel dans le champ Interface-Identifier de son message de demande de configuration IPV6CP.

Si l'attribut Framed-IPv6-Prefix [RFC3162] est inclus, ce préfixe doit être utilisé dans les annonces de routeur envoyées au SI. Si Framed-IPv6-Prefix n'est pas présent mais si Framed-IPv6-Pool l'est, le SC doit choisir un préfixe dans ce réservoir pour envoyer les RA.

 	8.1.2	Passages logiciels IPv4
Si l'attribut Framed-IP-Address [RFC2865] est présent, le concentrateur de passage logiciel doit fournir cette adresse à l'initiateur de passage logiciel durant la négociation d'adresse IPCP. C'est-à-dire, quand l'initiateur de passage logiciel demande une adresse IP au concentrateur de passage logiciel, l'adresse fournie devrait être la Framed-IP-Address.

 	8.2	Préfixes délégués
 	8.2.1	Préfixes IPv6 
Si l'attribut Delegated-IPv6-Prefix [RFC4818] est présent dans le message RADIUS Access-Accept, il doit être utilisé par le concentrateur de passage logiciel pour la délégation du préfixe IPv6. Comme la délégation de préfixe est effectuée par DHCPv6 et que l'attribut est lié à un nom d'utilisateur, le SC doit associer l'identifiant unique de DHCP (DUID) d'une demande DHCPv6 au tunnel d'où il vient et à son utilisateur.

L'interaction entre RADIUS, PPP, et le serveur DHCPv6 peut suivre le mécanisme proposé dans la [RFC7037]. Dans ce cas, durant la phase d'authentification du passage logiciel, PPP collecte les attributs RADIUS pour l'utilisateur comme Delegated-IPv6-Prefix. Un relais spécifique de DHCPv6 est alloué au passage logiciel. Le relais DHCPv6 remplit ces attributs dans l'option DHCPv6 Attribut d'agent de relais RADIUS (RRAO) avant de transmettre les demandes DHCPv6 au serveur DHCPv6.

 	8.2.2	Préfixes IPv4
RADIUS ne définit pas d'attribut pour le préfixe délégué IPv4. Les attributs qui indiquent un préfixe IPv4 et sa longueur (par exemple la combinaison des attributs Framed-IP-Address et Framed-IP-Netmask [RFC2865]) peuvent être utilisés par le concentrateur de passage logiciel pour déléguer un préfixe IPv4 à l'initiateur de passage logiciel. Le concentrateur de passage logiciel doit ajouter un chemin correspondant avec l'initiateur de passage logiciel comme prochain bond.

Comme cette pratique a été utilisée, l'inclusion de l'attribut Framed-IP-Netmask avec l'attribut Framed-IP-Address dit au concentrateur de passage logiciel de déléguer un préfixe IPv4 à l'initiateur de passage logiciel (par exemple, dans les scénarios IPv4 sur IPv6 où l'initiateur de passage logiciel est un routeur, voir les paragraphes 3.2.2 et 3.2.4) car le SC devrait transmettre au SI les paquets destinés à toute adresse IPv4 dans le préfixe.

 	9.	Considérations sur la maintenance et les statistiques

Les mécanismes de protocole existants pour porter des informations adjointes ou accessoires pour des besoins d'enregistrement, incluant les méthodes L2TPv2 et RADIUS, peuvent inclure du texte pour information que le comportement est conforme au cadre "centre et rayons" de passage logiciel (suivant les détails de mise en œuvre spécifiés dans le présent document).

 	9.1	Comptabilité RADIUS
La comptabilité RADIUS pour L2TP et PPP est documentée (voir le paragraphe 4.3).

Quand ils déploient des solutions de passage logiciel, les opérateurs peuvent rencontrer des difficultés pour différencier la famille d'adresses du trafic rapporté en informations de comptabilité de RADIUS. Ce problème et des solutions potentielles sont décrits dans [SW-ACCT].

 	9.2	MIB
La prise en charge d'une MIB pour L2TPv2 et PPP est documentée (voir le paragraphe 4.4). Voir aussi la [RFC4293].

 	10.	Considérations sur la sécurité

Un objectif de la conception du problème de "centre et rayons" est de considérer très fortement la réutilisation des protocoles déjà déployés (voir la [RFC4925]). Un autre objectif de conception est une solution avec de très fortes propriétés d'adaptabilité. L2TPv2 [RFC2661] est le protocole de phase 1 utilisé dans l'espace de solution de "centre et rayons" de passage logiciel, et les considérations sur la sécurité de L2TPv2 s'appliquent au présent document (voir la Section 9 de la [RFC2661]).

La solution de passage logiciel L2TPv2 ajoute les considérations suivantes :
o	L'authentification de tunnel L2TP (voir les paragraphes 5.1.1 et 9.1 de la [RFC2661]) fournit l'authentification à l'établissement du tunnel. Elle peut être utilisée pour limiter les attaques de déni de service en authentifiant le tunnel avant que les ressources de L2TP et PPP soient allouées.
o	Dans un environnement de passage logiciel, les AVP L2TPv2 ne transportent pas de données sensibles, et donc le mécanisme de dissimulation d'AVP L2TPv2 n'est pas utilisé (voir le paragraphe 5.1.1).
o	CHAP PPP [RFC1994] fournit l'authentification de base de l'utilisateur. D'autres protocoles d'authentification peuvent de plus être pris en charge (voir le paragraphe 5.2.3).

L2TPv2 peut aussi être sécurisé avec IPsec pour assurer la protection de la confidentialité, de l'intégrité, et contre la répétition. Actuellement, il y a deux solutions différentes pour sécuriser L2TPv2 avec IPsec :
o	Sécuriser L2TPv2 en utilisant IPsec "version 2" (IKEv1) est spécifié dans les [RFC3193], [RFC3947], et [RFC3948]. Quand L2TPv2 est utilisé dans le contexte de passage logiciel, le modèle de tunnelage volontaire s'applique. La [RFC3193] décrit l'interaction entre IPsec et L2TPv2, et est déployée. La [RFC3193] DOIT être prise en charge, étant donné que la technologie déployée doit être considérée très fortement [RFC4925] pour cette solution au goût du jour.
o	La [RFC5619] spécifie aussi une nouvelle solution (incompatible) pour sécuriser L2TPv2 avec IPsec "version 3" (IKEv2). Le paragraphe 3.5 de la [RFC5619] décrit les avantages de l'utilisation de IKEv2, et cette solution doit être considérée pour les phases futures.

Une discussion supplémentaire de la sécurité du passage logiciel figure dans la [RFC5619].

 	11.	Remerciements

Les auteurs tiennent à remercier les contributeurs suivants qui ont fourni d'utiles apports au présent document : Florent Parent, Jordi Palet Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, Francis Dupont, Ralph Droms, Hemant Singh, et Alain Durand.

Les auteurs tiennent aussi à remercier les participants aux réunions intérimaires Softwires tenues à Hong Kong, Chine, et Barcelone, Espagne. Les minutes de la réunion intérimaire à l'Université chinoise - Hong Kong (23-24 février 2006) sont à <http://www.ietf.org/proceedings/06mar/isoftwire.html>. Les minutes de la réunion intérimaire à l'Université Polytechnique de Catalogne - Barcelone (14-15 septembre 2006) sont accessibles à <http://www.ietf.org/proceedings/06nov/isoftwire.html>. La page auxiliaire de Softwires à <http://bgp.nu/~dward/softwires/> contient des informations supplémentaires sur la réunion.

Durant et après le dernier appel à l'IETF, d'utiles commentaires et discussions ont été fournis par Jari Arkko, David Black, Lars Eggert, Pasi Eronen, et Dan Romascanu.

 	12.	Références
 	12.1	Références normatives

[RFC1332]	G. McGregor, "Protocole de contrôle de protocole Internet point à point (IPCP)", mai 1992. (MàJ par RFC3241)

[RFC1661]	W. Simpson, éditeur, "Protocole point à point (PPP)", STD 51, juillet 1994. (MàJ par la RFC2153)

[RFC1918]	Y. Rekhter et autres, "Allocation d'adresse pour les internets privés", BCP 5, février 1996, DOI 10.17487/RFC1918.

[RFC1994]	W. Simpson, "Protocole d'authentification par mise en cause de la prise de contact en PPP (CHAP)", août 1996.

[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)

[RFC2661]	W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn et B. Palter, "Protocole de tunnelage de couche 2 "L2TP"", DOI 10.17487/RFC2661, (P.S.)

[RFC2865]	C. Rigney et autres, "Service d'authentification à distance de l'utilisateur appelant (RADIUS)", juin 2000. (MàJ par RFC2868, RFC3575, RFC5080, RFC8044) (D.S.)

[RFC3162]	B. Aboba, G. Zorn, D. Mitton, "RADIUS et IPv6", août 2001. (P.S. ; MàJ par RFC8044)

[RFC3193]	B. Patel et autres, "Sécuriser L2TP avec IPsec", novembre 2001. (P.S.)

[RFC3315]	R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins et M. Carney, "Protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)", juillet 2003. (MàJ par RFC6422 et RFC6644, RFC7227 ; rendue obsolète par RFC8415)

[RFC3371]	E. Caves, P. Calhoun, R. Wheeler, "Base de données d'informations de gestion du protocole de tunnelage de couche deux (L2TP)", août 2002. (P.S.)

[RFC3633]	O. Troan, R. Droms, "Options de préfixes IPv6 pour le protocole de configuration dynamique d'hôte (DHCP) version  6", décembre 2003. (MàJ par la RFC6603) (P.S. ; Obsolète voir RFC8415)

[RFC3736]	R. Droms, "Service sans état du protocole de configuration dynamique d'hôte (DHCP) pour IPv6", avril 2004. (P.S. ; rendue obsolète par RFC8415)

[RFC3947]	T. Kivinen et autres, "Négociation de traversée de NAT dans IKE", janvier 2005. (P.S.)

[RFC3948]	A. Huttunen et autres, "Encapsulation UDP de paquets ESP d'IPsec", janvier 2005. (P.S.)

[RFC4818]	J. Salowey, R. Droms, "Attribut de préfixe IPv6 délégué pour RADIUS", avril 2007. (P.S.)

[RFC4862]	S. Thomson et autres, "Auto configuration d'adresse IPv6 sans état", septembre 2007. (Remplace RFC2462) (D.S.)

[RFC5072]	S.Varada et autres, "IP version 6, sur PPP", septembre 2007. (Remplace RFC2472) (D.S , MàJ par RFC8064)

 	12.2	Références pour information

[RFC1471]	F. Kastenholz, "Définitions des objets gérés pour le protocole de contrôle de liaison PPP", juin 1993. (P.S.)

[RFC1473]	F. Kastenholz, "Définitions des objets gérés pour le protocole de contrôle de réseau IP PPP", juin 1993. (P.S.)

[RFC1877]	S. Cobb, "Extensions du protocole de contrôle de réseau pour la configuration d'adresses de serveurs de noms sur IP en PPP", décembre 1995 (Information)

[RFC2131]	R. Droms, "Protocole de configuration dynamique d'hôte", mars 1997. (DS ; MàJ par RFC3396, RFC4361, RFC5494, et RFC6849)

[RFC2132]	S. Alexander et R. Droms, "Options DHCP et Extensions de fabricant BOOTP", mars 1997.

[RFC2433]	G. Zorn, S. Cobb, "Extensions CHAP de Microsoft à PPP", octobre 1998. (Information)

[RFC2867]	G. Zorn, B. Aboba, D. Mitton, "Modifications de la comptabilité RADIUS pour la prise en charge du protocole de tunnel", juin 2000. (Information)

[RFC2868]	G. Zorn et autres, "Attributs RADIUS pour la prise en charge du protocole de tunnel", juin 2000. (Information)

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

[RFC3575]	B. Aboba, "Considérations relatives à l'IANA pour le service d'authentification distante d'utilisateur appelant (RADIUS)", juillet 2003. (MàJ RFC2865) (P.S.)

[RFC3646]	R. Droms, éd., "Options de configuration du DNS pour le protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)", décembre 2003. (P.S.)

[RFC3748]	B. Aboba et autres, "Protocole extensible d'authentification (EAP)", juin 2004. (P.S., MàJ par RFC5247)

[RFC3931]	J. Lau et autres, "Protocole de tunnelage de couche deux - version 3 (L2TPv3)", DOI 10.17487/RFC3931, mars 2005. (P.S.)

[RFC4087]	D. Thaler, "MIB de tunnel IP", juin 2005. (Remplace RFC2667) (P.S.)

[RFC4193]	R. Hinden, B. Haberman, "Adresses IPv6 en envoi individuel uniques localement", octobre 2005. (P.S.)

[RFC4293]	S. Routhier, éd., "Base de données d'informations de gestion pour le protocole Internet (IP)", avril 2006. (P.S.)

[RFC4623]	A. Malis, M. Townsley, "Fragmentation et réassemblage d'émulation bord à bord pseudo filaire (PWE3)", août 2006. (P.S.)

[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)

[RFC4861]	T. Narten et autres, "Découverte du voisin pour IP version 6 (IPv6)", septembre 2007. (Remplace RFC2461) (D.S. ; MàJ par RFC8028, RFC8319, RFC8425, 9131) 

[RFC4925]	X. Li et autres, "Position du problème du passage logiciel", juillet 2007. (Information)

[RFC4941]	T. Narten et autres, "Extensions de confidentialité pour l'auto configuration d'adresse sans état dans IPv6", septembre  2007, DOI 10.17487/RFC4941. (D.S. ; remplace RFC3041 ; remplacée par 8981)

[RFC5080]	D. Nelson, A. DeKok, "Problèmes de mise en œuvre courants du service d'authentification distante d'utilisateur appelant (RADIUS) et solutions suggérées", décembre 2007. (P.S. ; MàJ RFC2865, RFC2866, RFC2869, RFC3579)

[RFC5405]	L. Eggert, G. Fairhurst, "Lignes directrices pour l'utilisation d'UDP en envoi individuel pour les concepteurs d'applications", novembre 2008. (BCP0145 ; MàJ par RFC8085)

[RFC5619]	S. Yamamoto, C. Williams, H. Yokota, F. Parent, "Analyse et exigences pour la sécurité des passages logiciels", août 2009. (P.S.)

[RFC6656]	R. Johnson, K. Kinnear, M. Stapp, "Description du système de Cisco Option d’allocation de sous-réseau pour DHCPv4", juillet 2012. (Information)

[RFC7037]	L. Yeh, M. Boucadair, "Option RADIUS pour l’agent de relais DHCPv6", octobre 2013. (P.S.)

[SW-ACCT]	Stevant, B., Toutain, L., Dupont, F., and D. Binet, "Accounting on Softwires", Travail en cours, avril 2009.

 	Adresse des auteurs

Bill Storer	Carlos Pignataro (éditeur)	Maria Alice Dos Santos	
Cisco Systems	Cisco Systems	Cisco Systems	
170 W Tasman Dr	7200 Kit Creek Road	170 W Tasman Dr	
San Jose, CA  95134	PO Box 14987	San Jose, CA  95134	
USA	Research Triangle Park, NC  27709	USA	
mél : bstorer@cisco.com	USA	mél : mariados@cisco.com	
	mél : cpignata@cisco.com		

Bruno Stevant (éditeur)	Laurent Toutain	Jean-Francois Tremblay	
TELECOM Bretagne	TELECOM Bretagne	Videotron Ltd.	
2 rue de la Chataigneraie CS17607	2 rue de la Chataigneraie CS17607	612 Saint-Jacques	
Cesson Sevigne,   35576	Cesson Sevigne,   35576	Montreal, QC  H3C 4M8	
France	France	Canada	
mél : bruno.stevant@telecom-bretagne.eu	mél : laurent.toutain@telecom-bretagne.eu	mél : jf@jftremblay.com