Livre IPv6 - User contributions [en]

Talk:Site-local

2006-02-27T23:13:08Z

Emmanuel Berre: Correction du schéma ULA

Changement de la section Unique Local Address. Remplacement du draft draft-ietf-ipv6-ula-central-01.txt par le RFC 4193.
Suppression nécessaire de l'entrée de la bilbio [[Bibliographie#HH-id|[HH-id]]].

Les adresses de type site-local étant supprimées du standard IPv6 [RFC 3879], le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local Address''). Ces adresses sont destinées à une utilisation locale. Elles ne sont pas définies pour être routées dans l'Internet, mais seulement au sein d'une zone limitée telle qu'un site ou entre un nombre limité de sites. Les adresses uniques locales ont les caractéristiques suivantes :

* Prefixe ''globalement'' unique.
* Préfixe clairement définit facilitant le filtrage sur les routeurs de bordure.
* Permet l'interconnexion de sites sans générer de conflit d'adresse et sans nécessiter de renumérotation.
* Indépendantes des fournisseurs d'accès à l'Internet et ne nécessitent donc pas de connectivité.
* Pas de conflit en cas de routage par erreur en dehors d'un site.
* Aucune différences pour les applications, qui peuvent les considérer comme des adresses globales unicast standard.

Les adresses uniques locales sont créées en utilisant un identifiant global (''Global ID'') généré pseudo-aléatoirement. Ces adresses suivent le format suivant :

(lien vers schéma)

* <tt>Prefix</tt> (7 bits) : <tt>FC00::/7</tt> préfixe identifiant les adresses IPv6 locales (''ULA'')
* <tt>L</tt> (1 bit) : Positionné à 1, le préfixe est assigné localement. La valeur 0 est réservée pour une utilisation future.
* <tt>Global ID</tt> (40 bits) : Identifiant global utilisé pour la création d'un préfixe ''unique'' (''Globally Unique Prefix'').
* <tt>Subnet ID</tt> (16 bits) : Identifiant d'un sous réseau à l'intérieur du site.
* <tt>Interface ID</tt> (64 bits) : L'indentifiant d'interface tel que définit dans [[Identifiant d'interface]].

== Correction du schéma ULA ==

Il manque 1 bit (le bit L à rajouter sur le schéma) entre le Prefix et le GlobalId.

[[image:CS15.gif]]

-EB

Site-local

2006-02-27T23:10:11Z

Emmanuel Berre: /* <div id="ula">Unique Local Address */

{{suivi |Identifiant d'interface|Identifiant d'interface|Autres types d'adresses|Autres types d'adresses}}

Les adresses site-local sont des adresses dont la validité était restreinte à un site. Par exemple, un site qui n'est pas encore connecté à l'Internet pouvait utiliser ces adresses, ce qui le dispensait de demander ou d'emprunter un préfixe. Ce système généralisait le concept d'adresse privée d'IPv4 (comme le réseau <tt>10.x.y.z</tt>). Un autre intérêt apparent des adresses site-local est qu'elles ne sont pas modifiées lors d'un changement de fournisseur de connectivité, qui ne perturbe donc pas les communications locales.

Une adresse site-local était construite en concaténant le préfixe <tt>FEC0::/48</tt>, un champ de 16 bits qui permet de définir plusieurs sous-réseaux, et les 64 bits de l'[[Identifiant d'interface|identifiant d'interface]].



[[image:CS14.gif]]

Malgré ces propriétés, les adresses site-local n'ont pas réussi à s'imposer durant la phase de standardisation d'IPv6. Suivant les règles de l'IETF, elle doivent donc être retirées des documents pour la version finale du RFC décrivant IPv6. Le RFC 3879 décrit les problèmes liés à l'utilisation des adresses site-local. Contrairement à un lien facilement délimité par le support physique, la frontière du site est beaucoup plus vague. Il s'en suit des ambiguïtés qui rendent difficile l'utilisation de ce concept. En particulier, si un utilisateur est connecté à deux sites de deux companies différentes, l'adressage à plat offert par les adresses site-local rendent le routage difficile. Si le site dispose aussi d'adresse globales, l'ajout systématique d'adresses site-local rend également plus difficile le choix des adresses source et destination ainsi que la réponse aux requêtes DNS qui dépendent de la position de l'équipement demandeur.

De plus si le réseau de deux companies fusionnent, comme l'adressage des sous-réseaux ne se fait que dans la partie Subnet ID, il y a de fortes chances de trouver des collisions dans les valeurs choisies.

===<div id="ula">Unique Local Address===

Les adresses de type site-local étant supprimées du standard IPv6 [RFC 3879], le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local Address''). Ces adresses sont destinées à une utilisation locale. Elles ne sont pas définies pour être routées dans l'Internet, mais seulement au sein d'une zone limitée telle qu'un site ou entre un nombre limité de sites. Les adresses uniques locales ont les caractéristiques suivantes :

* Prefixe ''globalement'' unique.
* Préfixe clairement définit facilitant le filtrage sur les routeurs de bordure.
* Permet l'interconnexion de sites sans générer de conflit d'adresse et sans nécessiter de renumérotation.
* Indépendantes des fournisseurs d'accès à l'Internet et ne nécessitent donc pas de connectivité.
* Pas de conflit en cas de routage par erreur en dehors d'un site.
* Aucune différences pour les applications, qui peuvent les considérer comme des adresses globales unicast standard.

Les adresses uniques locales sont créées en utilisant un identifiant global (''Global ID'') généré pseudo-aléatoirement. Ces adresses suivent le format suivant :

* <tt>Prefix</tt> (7 bits) : <tt>FC00::/7</tt> préfixe identifiant les adresses IPv6 locales (''ULA'')
* <tt>L</tt> (1 bit) : Positionné à 1, le préfixe est assigné localement. La valeur 0 est réservée pour une utilisation future.
* <tt>Global ID</tt> (40 bits) : Identifiant global utilisé pour la création d'un préfixe ''unique'' (''Globally Unique Prefix'').
* <tt>Subnet ID</tt> (16 bits) : Identifiant d'un sous réseau à l'intérieur du site.
* <tt>Interface ID</tt> (64 bits) : L'indentifiant d'interface tel que définit dans [[Identifiant d'interface]].

{{suivi |Identifiant d'interface|Identifiant d'interface|Autres types d'adresses|Autres types d'adresses}}

Déploiement IPv6 des fournisseurs d'accès (ISP)

2006-02-27T23:01:06Z

Emmanuel Berre: /* <div id="6to4">6to4</div> */

{{suivi| Déploiement d'IPv6 et mécanismes d'intégration | Déploiement d'IPv6 et mécanismes d'intégration | Accès des entreprises et des particuliers à l'Internet IPv6 | Accès des entreprises et des particuliers à l'Internet IPv6 }}
Les mécanismes disponibles pour ce segment de réseau, contrairement à ceux décrits précédemment, mettent en oeuvre une architecture type client/serveur. Sauf exception ou cas particulier, la partie cliente est localisée côté utilisateur et la partie serveur côté ISP.

Le point fort des mécanismes présentés ici est de permettre une mise en oeuvre de solutions dites automatiques, où l'intervention de l'administrateur est réduite à une phase de configuration/ initialisation du service.

===<div id="6to4">6to4</div>===

Le mécanisme 6to4 permet d'interconnecter entre eux des sites IPv6 isolés en créant des tunnels automatiques IPv6 dans IPv4 en fonction du destinataire des données. Le mécanisme définit plusieurs composants.

* la machine terminale 6to4 (dépendante de l'implantation dans le système d'exploitation)
* le routeur de bordure (ou gateway), qui doit encapsuler les paquets IPv6 dans des paquets IPv4, est connecté à IPv4 et IPv6
* le relais 6to4 est un équipement réseau dont l'adresse est bien connue (adresse anycast). Il assure la connexion à l'Internetv6.

6to4 permet à un ISP de fournir de la connectivité IPv6 à ses usagers en installant une machine unique connectée aux deux mondes IP. Il peut aussi permettre à un usager de router du trafic IPv6 même si son prestataire ne fournit qu'une connectivité et des adresses IPv4. Il faut noter que le routage entre les machines distantes a de bonnes probabilités d'être asymétrique notamment si le routeur de bordure utilise un relais 6to4 et que l'utilisation des tunnels peut conduire à des délais de propagation élevés.

On peut envisager l'usage de la technique 6to4 de deux manières :

* Comme un moyen de pression envers les ISP. Un site dont le fournisseur de service refuse d'offrir un service IPv6, n'est pas bloqué. Il dispose d'une méthode simple pour construire ses adresses IPv6 et la création de tunnels. Il suffit de trouver l'adresse IPv4 d'un routeur passerelle qui traitera les paquets. <br>Cette approche conduit à un routage sous-optimal, comme indiqué précédemment, et à une anarchie dans le réseau en terme d'administration.
* Pour permettre aux ISP d'offrir un service IPv6 minimum à leurs clients. Cette approche est acceptable dans la période de déploiement d'IPv6. Le fournisseur de services met en place un routeur passerelle uniquement pour ses clients et le place par exemple dans un point d'interconnexion. D'une part, la charge administrative et technique est réduite puisque l'ISP n'a pas à gérer un nouveau plan d'adressage ou la création de nombreux tunnels. D'autre part, le routage est plus optimal puisque le relais est proche des clients et du réseau IPv6 auquel l'ISP est relié.

On pourrait envisager l'installation de relais 6to4 sur les points d'échange de l'Internet pour accélérer le déploiement et l'usage d'IPv6 par les ISP. Mais il n'y a pas de demande dans ce sens actuellement et ce mécanisme est actuellement peu déployé par les ISP. La question de sa résistance au facteur d'échelle, et des aspect liés à la sécurité, sont posées depuis longtemps. Ils n'ont pas encore trouvé de réponse.

Le préfixe <tt>2002::/16</tt> a été alloué par l'IANA à ce type d'adressage (cf. figure Adresse 6to4). Le gestionnaire d'un site peut aisément créer un préfixe de longueur 48 en y concaténant l'adresse IPv4 (convertie en hexadécimal) d'un routeur en bordure des réseaux IPv4 et IPv6.

[[image:CS178.gif]]

La figure Exemple de numérotation en utilisant le préfixe de 6to4 illustre le mécanisme d'attribution de préfixes. Le routeur RB se trouve en bordure du réseau. Il est connecté à la fois à l'Internet v4 et à un (ou des) réseau(x) IPv6. Le routeur possède obligatoirement une adresse IPv4 sur le réseau de l'ISP. Il va s'en servir pour construire les 48 premiers bits de l'adresse IPv6. C'est ce préfixe de 48 bits qui va être utilisé par l'ensemble des équipements 6to4 du site. Ce préfixe identifie un site donné. On peut remarquer que ce plan d'adressage est conforme aux plans d'adressage globaux actuellement en vigueur, puisqu'il réserve 16 bits pour numéroter les réseaux du site et 64 bits pour les identifiants d'interface.

[[image:CS179.gif]]

La figure Exemple de routage des paquets explique comment les paquets sont routés quand l'équipement A veut envoyer un paquet IPv6 à l'équipement B. Dans un premier temps, A interroge le DNS pour connaître l'adresse IPv6 de B. La réponse est une adresse du type <tt>2002:C0C0:C0C0:.... </tt>La machine A émet un paquet vers cette destination. Les paquets dont l'adresse destination commence par le préfixe <tt>2002::/16</tt>, correspondant au plan d'adressage 6to4, sont routés vers un routeur tunnelier pour 6to4. Ce dernier analyse l'adresse IPv6 de destination et trouve l'adresse IPv4 de l'autre extrémité du tunnel (<tt>192.192.192.192</tt> dans l'exemple). Le paquet est reçu par le routeur RB qui retire l'encapsulation IPv4 et le route normalement vers la destination B en utilisant le routage interne.

[[image:CS180.gif]]

On peut remarquer dans cet exemple que l'adresse de la source peut être aussi bien une adresse IPv6 6to4 qu'une adresse IPv6 globale. Mais le dialogue dans le sens opposé est plus complexe et montre les limites de cette technique.

Un site utilisant 6to4 n'est pas, par définition, connecté à l'Internet v6. Il doit donc exister dans l'Internet v4 des routeurs servant de passerelle vers le réseau Internet IPv6. Un routeur de bordure faisant l'encapsulation des paquets IPv6 dans des paquets IPv4 peut être configuré de la manière suivante :

* si l'adresse du destinataire commence par le préfixe <tt>2002::/16</tt>, effectuer l'encapsulation du paquet vers le destinataire IPv4 dont l'adresse est incluse dans l'adresse IPv6 de destination,
* sinon, il s'agit d'une adresse IPv6 globale et le paquet doit être tunnelé à l'adresse IPv4 d'un routeur servant de passerelle vers le réseau IPv6.

De même, dans la figure Exemple de routage des paquets, nous avons supposé que le routeur faisant l'encapsulation était situé en bordure du réseau du site où se trouve la machine A. C'est probable si le site utilise également un plan d'adressage 6to4. Par contre si le site n'utilise que des adresses globales, voire n'a pas de connexion IPv4, l'encapsulation peut être déléguée à un routeur passerelle. Ce routeur passerelle peut en utilisant les protocoles de routage interne et externe annoncer aux équipements IPv6 cette fonctionnalité.

Le danger est d'engorger les tables de routage IPv6 avec une complexité lié à l'adressage IPv4. Pour éviter cet écueil, un routeur passerelle ne doit pas annoncer un préfixe IPv6 autre que <tt>2002::/16</tt>. En conséquence, les paquets émis à destination d'une adresse 6to4 seront traités par le routeur le plus proche au sens des protocoles de routage.

Il est important de respecter cette règle au niveau des annonces BGP, comme le montre l'exemple de configuration des routeurs See Règles d'annonce et d'agrégation.

Si 6to4 est une technique intéressante pour relier deux nuages IPv6 à travers un nuage IPv4, elle se complique et n'est pas optimale lorsqu'il s'agit de communiquer avec une machine dont l'adresse est issue d'un plan de numérotation global. Le routage n'est pas toujours optimal et presque assurément asymétrique :

* le site 6to4 peut avoir choisi un routeur passerelle loin du destinataire,
* le site ayant un plan d'adressage global envoie les paquets vers le routeur passerelle le plus proche au sens du routage.

Pour réduire la taille des tunnels, une adresse IP anycast a été proposée pour automatiser et simplifier la phase de configuration de l'adresse du relais. Le préfixe <tt>192.88.99.0/24</tt> a été attribué à ce propos [RFC 3068] et le relais prend l'adresse <tt>2002:c058:6301::</tt>, ou <tt>192.88.99.1</tt> en utilisant l'adresse IPv4. Un site offrant ce service peut annoncer ce préfixe dans le routage global de l'Internetv4 et les paquets à destination d'un relais iront vers l'équipement le plus proche.

===Tunnel Broker===

Un serveur de tunnels (IPv6 dans IPv4) permet de connecter à l'Internetv6 une machine double pile isolée dans l'Internetv4. Dans certaines versions de ce service un réseau local peut être ainsi connecté, quel que soit le nombre de machines qu'il comporte. La configuration du tunnel entre le serveur et la machine cliente est automatique et repose sur le protocole TSP. La demande de connexion au serveur est réalisée par une page HTML dont l'URL est connue à l'avance.

Ce mécanisme/service permet de fournir de la connectivité IPv6 à des équipements/réseaux locaux isolés dans l'Internetv4. Cette connectivité est en générale fournie à titre provisoire (soit en attendant que l'offre des ISP soit disponible soit pour faire des tests de validation, par exemple). Elle peut aussi être une première étape pour un prestataire de service pour procurer de la connectivité IPv6 à ses usagers.

Le service Tunnel Broker repose sur une architecture à base de client/serveur. Côté usager l'installation d'un simple client permet de faire la demande de tunnels au serveur. Ce client est en général authentifié. Pour le prestataire, il faut mettre en oeuvre un serveur qui a plusieurs fonctions : l'interface HTML pour accueillir les demandes de tunnels des usagers et la « comptabilité » qui peut l'accompagner, le configurateur de tunnels qui envoie les paramètres d'extrémité du tunnel entre l'équipement de concentration et celui de l'usager d'une part et le concentrateur de tunnels d'autre part.

De nombreuses évolutions de ce mécanisme sont en cours :

* L'authentification du client demandant à [r]établir une connexion au serveur de tunnels permet de disposer d'une fonction VPN quel que soit le lieu où se trouve l'usager dans l'Internet.
* Les implantations s'appuyant sur des tunnels UDP permettent la traversée de NAT, fonction indispensable aux terminaux (ou réseaux) situés dans un plan d'adressage privé.
* Le découpage de l'espace d'adresse pour numéroter les extrémités de tunnels et les réseaux d'interconnexion, nécessite un peu de doigté. Là aussi des évolutions sont en cours pour simplifier les implantations actuelles et mieux coller à l'expérience de déploiement des réseaux IPv6 acquise ces dernières années.

===TSP : tunnel setup protocol===

Le tunnel setup protocole [[Bibliographie#BP-id|[BP-id]]] a été défini en complément du Tunnel Broker afin de permettre une négociation automatisée des différents paramètres entrant en jeu lors de l'établissement d'un tunnel. En effet, nombre d'implémentations de Tunnel Broker sont basées aujourd'hui sur une interface Web qui permet de saisir ou de récupérer implicitement les paramètres nécessaires à l'établissement du tunnel entre le terminal et le Tunnel serveur. L'architecture d'un Tunnel broker implémentant TSP est donné figure Configuration d'un Tunnel Broker avec TSP.

[[image:CS181.gif]]

TSP permet la négociation automatique et transparente à l'utilisateur de tout ou partie des paramètres suivants :

* le mécanisme d'authentification utilisateur utilisé,
* le type d'encapsulation utilisée : IPv4 dans IPv6, IPv6 dans IPv4, IPv6 dans UDP IPv4
* l'adresse IPv6 assignée lorsque le client TSP est un terminal
* le préfixe IPv6 alloué lorsque le client TSP est un routeur
* l'enregistrement DNS dans le cas d'un terminal
* la résolution DNS inverse dans le cas d'un routeur

La disponibilité du type d'encapsulation IPv6 dans UDP IPv4, permet d'offrir une solution de traversée de NAT, alternative à celle proposée par exemple par Teredo. Dans ce cas, le client TSP met en oeuvre un processus de découverte de NAT qui consiste simplement à envoyer au TSP serveur du Broker, un message UDP contenant l'adresse IP du terminal. Le serveur TSP serveur compare simplement l'adresse contenue dans le message avec l'adresse source du paquet UDP. Si elles sont différentes alors le terminal est situé derrière un NAT.

TSP s'appuie sur l'échange de simples messages XML dont un exemple est donné ci-dessous. Cet exemple correspond à la demande de création d'un tunnel simple par un client TSP :

-- Successful TCP Connection --
C:VERSION=2.0.0 CR LF
S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:200 Authentication successful CR LF
C:Content-length: 123 CR LF
<tunnel action="create" type="v6v4">
<client>
<address type="ipv4">1.1.1.1</address>
</client>
</tunnel> CR LF
S: Content-length: 234 CR LF
200 OK CR LF
<tunnel action="info" type="v6v4" lifetime="1440">
<server>
<address type="ipv4">206.123.31.114</address>
<address type= "ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
</server>
<client>
<address type="ipv4">1.1.1.1</address>
<address type= "ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
<address type="dn">userid.domain</address>
</client>
</tunnel> CR LF
C: Content-length: 35 CR LF
<tunnel action="accept"></tunnel> CR LF
{{suivi| Déploiement d'IPv6 et mécanismes d'intégration | Déploiement d'IPv6 et mécanismes d'intégration | Accès des entreprises et des particuliers à l'Internet IPv6 | Accès des entreprises et des particuliers à l'Internet IPv6 }}

Unicast Global

2006-02-27T22:49:09Z

Emmanuel Berre: /* Adressage global : plan d'adressage agrégé */

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

=== Adressage global : plan d'adressage agrégé ===

Ce plan, proposée dans le RFC 3587, précise la structure d'adressage IPv6 définie dans le RFC 3513 en précisant les tailles de chacun des blocs. Une adresse intègre trois niveaux de hiérarchie :

[[image:Fig3-3.png|thumb|right|350px|Figure 3-4 ''Adresse de type plan agrégé'']]

* une topologie publique codé sur 48 bits, allouée par le fournisseur d'accès;
* une topologie de site codé sur 16 bits. Ce champ permet de coder les numéros de sous réseau du site;
* un [[identifiant d'interface]] (64 bits) distinguant les différentes machines sur le lien.

Il existe plusieurs instanciations de ce plan d'adressage. Historiquement la première (préfixe <tt>3FFE::/16</tt>) a servi aux réseaux expérimentaux, puis une seconde (préfixe <tt>2001::/16</tt>) est définie par les autorités régionales pour les réseaux dits de production, enfin une troisième est dédiée (préfixe <tt>2002::/16</tt>) au mécanisme de transition [[Déploiement IPv6 des fournisseurs d'accès (ISP)#6to4|6to4]]. Ces instanciations sont différenciées par la valeur du préfixe initial de 16 bits (cf. Tableau). Très récemment, d'autres préfixes ont été libérés. En effet, si l'on garde l'attribution de préfixe de longueur 48 pour les sites terminaux, et que l'on intègre les réseaux domotiques, les opérateurs peuvent justifier d'un besoin important d'adresses que les autorités régionales ne peuvent leur refuser. Il semble que cela pourrait remettre en cause l'attribution de préfixes de longueur 48 pour tous les utilisateurs au profit de préfixes plus long. Une version, à jour des allocations est disponible sur le site http://www.iana.org/assignments/ipv6-unicast-address-assignments.

{|
!Global Unicast Prefix!!Assignment!!Date
|-style="background:silver"
|2001:0000::/23 ||IANA||01 Jul 99
|-
|2001:0200::/23||APNIC||01 Jul 99
|-style="background:silver"
|2001:0400::/23||ARIN ||01 Jul 99
|-
|2001:0600::/23||RIPE NCC||01 Jul 99
|-style="background:silver"
|2001:0800::/23||RIPE NCC ||01 May 02
|-
|2001:0A00::/23||RIPE NCC||02 Nov 02
|-style="background:silver"
|2001:0C00::/23||APNIC||01 May 02
|-
|2001:0E00::/23||APNIC||01 Jan 03
|-style="background:silver"
|2001:1200::/23||LACNIC||01 Nov 02
|-
|2001:1400::/23||RIPE NCC||01 Feb 03
|-style="background:silver"
|2001:1600::/23||RIPE NCC||01 Jul 03
|-
|2001:1800::/23||ARIN ||01 Apr 03
|-style="background:silver"
|2001:1A00::/23|| RIPE NCC ||01 Jan 04
|-
|2001:1C00::/22||RIPE NCC ||01 May 04
|-style="background:silver"
|2001:2000::/20||RIPE NCC||01 May 04
|-
|2001:3000::/21||RIPE NCC||01 May 04
|-style="background:silver"
|2001:3800::/22|| RIPE NCC||01 May 04
|-
|2001:3C00::/22||RESERVED||11 Jun 04
|-style="background:silver"
|2001:4000::/23||RIPE NCC||11 Jun 04
|-
|2001:4200::/23||ARIN||01 Jun 04
|-style="background:silver"
|2001:4400::/23||APNIC||11 Jun 04
|-
|2001:4600::/23||RIPE NCC||17 Aug 04
|-style="background:silver"
|2001:4800::/23||ARIN||24 Aug 04
|-
|2001:4A00::/23||RIPE NCC||15 Oct 04
|-style="background:silver"
|2001:4C00::/23||RIPE NCC||17 Dec 04
|-
|2001:5000::/20||RIPE NCC||10 Sep 04
|-style="background:silver"
|2001:8000::/19||APNIC||30 Nov 04
|-
|2001:A000::/20||APNIC ||30 Nov 04
|-style="background:silver"
|2002:0000::/16||[[Déploiement IPv6 des fournisseurs d'accès (ISP)#6to4|6to4]]||01 Feb 01
|-
|2003:0000::/18 ||RIPE NCC ||12 Jan 05
|-style="background:silver"
|2400:0000::/19||APNIC||20 May 05
|-
|2400:2000::/19||APNIC ||08 Jul 05
|-style="background:silver"
|2400:4000::/21||APNIC||08 Aug 05
|-
|2404:0000::/23||APNIC||19 Jan 06
|-style="background:silver"
|2600:0000::/22||ARIN ||19 Apr 05
|-
|2604:0000::/22||ARIN||19 Apr 05
|-style="background:silver"
|2608:0000::/22||ARIN||19 Apr 05
|-
|260C:0000::/22||ARIN||19 Apr 05
|-style="background:silver"
|2610:0000::/23||ARIN||17 Nov 05
|-
|2800:0000::/23||LACNIC||17 Nov 05
|-style="background:silver"
|2A00:0000::/21||RIPE NCC||19 Apr 05
|-
|2A01:0000::/26||RIPE NCC||15 Dec 05
|-style="background:silver"
|3FFE:0000::/16||6BONE||01 Dec 98
|}

== Adresses de test ==

Les expérimentations d'IPv6 sur un réseau devaient commencer avant que les règles d'attribution des préfixes soient complètement finalisées. La valeur 0x1FFE a été attribué par l'IANA au 6bone dans le plan d'adressage agrégé pour les expérimentations (RFC 3701). Il correspond au préfixe <tt>3FFE::/16</tt> pour l'ensemble du 6bone.

[[image:Fig3-4.jpg|thumb|right|350px|Figure 3-4 ''Adresse de test du plan agrégé'']]

Les 48 bits restant avant le champ Subnet ID recréent les niveaux hiérarchiques d'un réseau IPv6 défini dans le RFC 3587, d'où le terme pseudo accolé au nom du champ. La taille réduite n'étant pas un facteur limitant dans la phase expérimentale. Des pseudo-TLA d'une taille initialement de 8, mais portées à 12 bits par la suite, sont attribués à des opérateurs voulant expérimenter le protocole. Les 24 ou 20 bits suivants sont utilisés pour numéroter les sites.

Les pseudo-TLA ont été alloués jusqu'en décembre 2003 aux opérateurs qui en faisaient la demande. La liste complète est disponible sur le serveur Web http://www.6bone.net/6bone_pTLA_list.html. Le tableau Pseudo TLA attribués par le groupe ngtrans reprend quelques unes de ces valeurs.

{|
|+'''''Pseudo TLA attribués par le groupe ngtrans'''''
!Organismes/Pays!!Préfixe!! !!Organismes/Pays!!Préfixe
|-style="background:silver"
|ROOT66/US-CA||3FFE:0000::/24|| ||TRUMPET/AU||3FFE:8000::/28
|-
|TELEBIT/DK||3FFE:0100::/24|| ||ICM-PL/PL||3FFE:8010::/28
|-style="background:silver"
|SICS/SE||3FFE:0200::/24|| ||IIJ/JP||3FFE:8020::/28
|-
|G6/FR||3FFE:0300::/24|| ||QTPVSIX/EU||3FFE:8030::/28
|-style="background:silver"
|JOIN/DE||3FFE:0400::/24|| ||APAN-KR||3FFE:8040::/28
|-
|WIDE/JP||3FFE:0500::/24|| ||MIBH||3FFE:8050::/28
|-style="background:silver"
|SURFNET/NL||3FFE:0600::/24|| ||ATNET-AT||3FFE:8060::/28
|}

L'expérimentation lié au 6bone devrait se terminer bientôt, la date d'arrêt a été symboliquement choisie le mardi 6 juin 2006 RFC 3701. En effet, si ce réseau au début de l'introduction d'IPv6 palier à l'absence d'opérateurs officiels, il a vite montré ses limites. L'utilisation de tunnels pour créer la connectivité, a conduit à un trop fort maillage, à des routes relativement longues et par conséquence à une faible qualité de service.

== Adresses gérées par les RIR ==

La valeur <tt>0x0001</tt> a été attribué par l'IANA pour un plan d'adressage où les autorités régionales attribuent les préfixes. Le préfixe initial est par conséquent <tt>2001::/16</tt>. Ce plan reproduit, en étendant la largeur des champs les principes de délagation et de gestion introduits en IPv4 par CIDR. Un site voulant se connecter reçoit de son fournisseur d'accès un préfixe global de 48 bits.

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

Unicast Global

2006-02-27T22:44:20Z

Emmanuel Berre: /* Adressage global : plan d'adressage agrégé */

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

=== Adressage global : plan d'adressage agrégé ===

Ce plan, proposée dans le RFC 3587, précise la structure d'adressage IPv6 définie dans le RFC 3513 en précisant les tailles de chacun des blocs. Une adresse intègre trois niveaux de hiérarchie :

[[image:Fig3-3.png|thumb|right|350px|Figure 3-4 ''Adresse de type plan agrégé'']]

* une topologie publique codé sur 48 bits, allouée par le fournisseur d'accès;
* une topologie de site codé sur 16 bits. Ce champ permet de coder les numéros de sous réseau du site;
* un [[identifiant d'interface]] (64 bits) distinguant les différentes machines sur le lien.

Il existe plusieurs instanciations de ce plan d'adressage. Historiquement la première (préfixe <tt>3FFE::/16</tt>) a servi aux réseaux expérimentaux, puis une seconde (préfixe <tt>2001::/16</tt>) est définie par les autorités régionales pour les réseaux dits de production, enfin une troisième est dédiée (préfixe <tt>2002::/16</tt>) au mécanisme de transition [[Déploiement IPv6 des fournisseurs d'accès (ISP)#6to4|6to4]]. Ces instanciations sont différenciées par la valeur du préfixe initial de 16 bits (cf. Tableau). Très récemment, d'autres préfixes ont été libérés. En effet, si l'on garde l'attribution de préfixe de longueur 48 pour les sites terminaux, et que l'on intègre les réseaux domotiques, les opérateurs peuvent justifier d'un besoin important d'adresses que les autorités régionales ne peuvent leur refuser. Il semble que cela pourrait remettre en cause l'attribution de préfixes de longueur 48 pour tous les utilisateurs au profit de préfixes plus long. Une version, à jour des allocations est disponible sur le site http://www.iana.org/assignments/ipv6-unicast-address-assignments.

{|
!Global Unicast Prefix!!Assignment!!Date
|-style="background:silver"
|2001:0000::/23 ||IANA||01 Jul 99
|-
|2001:0200::/23||APNIC||01 Jul 99
|-style="background:silver"
|2001:0400::/23||ARIN ||01 Jul 99
|-
|2001:0600::/23||RIPE NCC||01 Jul 99
|-style="background:silver"
|2001:0800::/23||RIPE NCC ||01 May 02
|-
|2001:0A00::/23||RIPE NCC||02 Nov 02
|-style="background:silver"
|2001:0C00::/23||APNIC||01 May 02
|-
|2001:0E00::/23||APNIC||01 Jan 03
|-style="background:silver"
|2001:1200::/23||LACNIC||01 Nov 02
|-
|2001:1400::/23||RIPE NCC||01 Feb 03
|-style="background:silver"
|2001:1600::/23||RIPE NCC||01 Jul 03
|-
|2001:1800::/23||ARIN ||01 Apr 03
|-style="background:silver"
|2001:1A00::/23|| RIPE NCC ||01 Jan 04
|-
|2001:1C00::/22||RIPE NCC ||01 May 04
|-style="background:silver"
|2001:2000::/20||RIPE NCC||01 May 04
|-
|2001:3000::/21||RIPE NCC||01 May 04
|-style="background:silver"
|2001:3800::/22|| RIPE NCC||01 May 04
|-
|2001:3C00::/22||RESERVED||11 Jun 04
|-style="background:silver"
|2001:4000::/23||RIPE NCC||11 Jun 04
|-
|2001:4200::/23||ARIN||01 Jun 04
|-style="background:silver"
|2001:4400::/23||APNIC||11 Jun 04
|-
|2001:4600::/23||RIPE NCC||17 Aug 04
|-style="background:silver"
|2001:4800::/23||ARIN||24 Aug 04
|-
|2001:4A00::/23||RIPE NCC||15 Oct 04
|-style="background:silver"
|2001:4C00::/23||RIPE NCC||17 Dec 04
|-
|2001:5000::/20||RIPE NCC||10 Sep 04
|-style="background:silver"
|2001:8000::/19||APNIC||30 Nov 04
|-
|2001:A000::/20||APNIC ||30 Nov 04
|-style="background:silver"
|2002:0000::/16||[[Déploiement IPv6 des fournisseurs d'accès (ISP)#6to4|6to4]]||01 Feb 01
|-
|2003:0000::/18 ||RIPE NCC ||12 Jan 05
|-style="background:silver"
|2400:0000::/19||APNIC||20 May 05
|-
|2400:2000::/19||APNIC ||08 Jul 05
|-style="background:silver"
|2400:4000::/21||APNIC||08 Aug 05
|-
|-style="background:silver"
|2404:0000::/23||APNIC||19 Jan 06
|-
|2600:0000::/22||ARIN ||19 Apr 05
|-style="background:silver"
|2604:0000::/22||ARIN||19 Apr 05
|-
|2608:0000::/22||ARIN||19 Apr 05
|-style="background:silver"
|260C:0000::/22||ARIN||19 Apr 05
|-
|-style="background:silver"
|2610:0000::/23||ARIN||17 Nov 05
|-
|-style="background:silver"
|2800:0000::/23||LACNIC||17 Nov 05
|-
|2A00:0000::/21||RIPE NCC||19 Apr 05
|-style="background:silver"
|2A01:0000::/26||RIPE NCC||15 Dec 05
|-
|3FFE:0000::/16||6BONE||01 Dec 98
|}

== Adresses de test ==

Les expérimentations d'IPv6 sur un réseau devaient commencer avant que les règles d'attribution des préfixes soient complètement finalisées. La valeur 0x1FFE a été attribué par l'IANA au 6bone dans le plan d'adressage agrégé pour les expérimentations (RFC 3701). Il correspond au préfixe <tt>3FFE::/16</tt> pour l'ensemble du 6bone.

[[image:Fig3-4.jpg|thumb|right|350px|Figure 3-4 ''Adresse de test du plan agrégé'']]

Les 48 bits restant avant le champ Subnet ID recréent les niveaux hiérarchiques d'un réseau IPv6 défini dans le RFC 3587, d'où le terme pseudo accolé au nom du champ. La taille réduite n'étant pas un facteur limitant dans la phase expérimentale. Des pseudo-TLA d'une taille initialement de 8, mais portées à 12 bits par la suite, sont attribués à des opérateurs voulant expérimenter le protocole. Les 24 ou 20 bits suivants sont utilisés pour numéroter les sites.

Les pseudo-TLA ont été alloués jusqu'en décembre 2003 aux opérateurs qui en faisaient la demande. La liste complète est disponible sur le serveur Web http://www.6bone.net/6bone_pTLA_list.html. Le tableau Pseudo TLA attribués par le groupe ngtrans reprend quelques unes de ces valeurs.

{|
|+'''''Pseudo TLA attribués par le groupe ngtrans'''''
!Organismes/Pays!!Préfixe!! !!Organismes/Pays!!Préfixe
|-style="background:silver"
|ROOT66/US-CA||3FFE:0000::/24|| ||TRUMPET/AU||3FFE:8000::/28
|-
|TELEBIT/DK||3FFE:0100::/24|| ||ICM-PL/PL||3FFE:8010::/28
|-style="background:silver"
|SICS/SE||3FFE:0200::/24|| ||IIJ/JP||3FFE:8020::/28
|-
|G6/FR||3FFE:0300::/24|| ||QTPVSIX/EU||3FFE:8030::/28
|-style="background:silver"
|JOIN/DE||3FFE:0400::/24|| ||APAN-KR||3FFE:8040::/28
|-
|WIDE/JP||3FFE:0500::/24|| ||MIBH||3FFE:8050::/28
|-style="background:silver"
|SURFNET/NL||3FFE:0600::/24|| ||ATNET-AT||3FFE:8060::/28
|}

L'expérimentation lié au 6bone devrait se terminer bientôt, la date d'arrêt a été symboliquement choisie le mardi 6 juin 2006 RFC 3701. En effet, si ce réseau au début de l'introduction d'IPv6 palier à l'absence d'opérateurs officiels, il a vite montré ses limites. L'utilisation de tunnels pour créer la connectivité, a conduit à un trop fort maillage, à des routes relativement longues et par conséquence à une faible qualité de service.

== Adresses gérées par les RIR ==

La valeur <tt>0x0001</tt> a été attribué par l'IANA pour un plan d'adressage où les autorités régionales attribuent les préfixes. Le préfixe initial est par conséquent <tt>2001::/16</tt>. Ce plan reproduit, en étendant la largeur des champs les principes de délagation et de gestion introduits en IPv4 par CIDR. Un site voulant se connecter reçoit de son fournisseur d'accès un préfixe global de 48 bits.

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

Talk:Accès des entreprises et des particuliers à l'Internet IPv6

2006-02-24T10:08:51Z

Emmanuel Berre:

Je pense qu'ici il faut différencier les moyens d'accéder à IPv6 avec et sans fournisseur d'accés.

Sans fournisseur on a
* ISATAP, plutôt destiné aux réseaux d'entreprise
* TEREDO, plutôt destiné à des applications chez le particulier

Avec fournisseur d'accès, on donner différents opérateurs en fonction des solutions utilisées :
* Tunnel 6over4 : [https://tb.ipv6.btexact.com/ BTExact], [http://www.sixxs.net SixXs] (?)
* TSP : Hexago, Renater
* Point6 ? :)

Il serait peut-être intéressant d'y ajouter 6to4.

BSD

2006-02-23T22:06:26Z

Emmanuel Berre: /* Configuration manuelle */

{{suivi| Linux | Linux | Routage | Routage}}
Il existe de nombreux systèmes dérivés de BSD : BSD/OS, FreeBSD, NetBSD, OpenBSD, MAC OS X,... IPv6 est disponible sur ces systèmes depuis très longtemps, plusieurs implémentations ont existé. Aujourd'hui la plupart de ces systèmes proposent IPv6 en standard, en utilisant un code dérivé d'une même souche (KAME). On se concentrera ici sur FreeBSD et NetBSD, mais les mises en ?uvre sur les autres systèmes sont proches.

==FreeBSD==

FreeBSD propose IPv6 en standard depuis la version 4.0. La bibliothèque <tt>libc</tt> et la plupart des applications supportent IPv6 (RPC et NFS seulement à partir de FreeBSD 5). Dans le cas le plus simple (machine utilisant l'autoconfiguration sans état), les menus d'installation système proposent de configurer IPv6, il suffit de répondre à la question de configuration d'une interface en IPv6. Si on n'a pas activé IPv6 à l'installation, on peut rappeler le programme de configuration <tt>/stand/sysinstall</tt> pour reconfigurer les interfaces. On peut aussi configurer «à la main» en éditant le fichier <tt>/etc/rc.conf</tt>.

Le fichier <tt>/etc/rc.conf</tt> sert à définir la plupart des variables de configuration d'une machine FreeBSD. Les valeurs par défaut (et les commentaires) sont dans le fichier de référence <tt>/etc/default/rc.conf</tt> (à ne pas modifier).

Pour activer manuellement IPv6 dans le cas le plus simple (autoconfiguration sans état), il suffit d'ajouter dans le fichier <tt>/etc/rc.conf</tt> la ligne :

ipv6_enable=YES

IPv6 sera disponible au prochain reboot.

Pour vérifier que IPv6 fonctionne correctement, on dispose des commandes <tt>ping6</tt> et <tt>traceroute6</tt> pour tester l'accessibilité d'une machine, et netstat pour visualiser les tables de routage, et de connexions actives.

Par exemple pour tester la connectivité IPv6 :

> '''/usr/sbin/traceroute6 www6.ipv6.imag.fr'''
traceroute6 to www6.ipv6.imag.fr (2001:660:181:1::50) from
2001:660:282:5:2b0:d0ff:fe3b:e565, 30 hops max, 12 byte packets
1 2001:660:282:5:200:c0ff:fee4:caa0 22.234 ms 0.993 ms 0.919 ms
2 pallas.ipv6.rennes.enst-bretagne.fr 3.81 ms * 3.684 ms
3 horace.ipv6.rennes.enst-bretagne.fr 7.93 ms * 15.773 ms
4 2001:660:80:4002::1 14.876 ms * 14.941 ms
5 2001:660:80:4004::2 22.877 ms * 22.835 ms
6 luna-v6.ipv6.imag.fr 50.509 ms 46.267 ms 46.148 ms

La commande suivante montre les interfaces activées en IPv6. Il existe un tunnel IPv4 dans IPv6 <tt>gif0</tt>, et l'interface <tt>xl0</tt> a deux adresses IPv6 globales :

> '''netstat -inf inet6'''
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
xl0 1500 <Link#1> 00:b0:d0:3b:e5:65 82186 0 74502 0 0
xl0 1500 193.52.74 193.52.74.217 58006 - 72342 - -
xl0 1500 fe80:1::2b0 fe80:1::2b0:d0ff: 70 - 2131 - -
xl0 1500 2001:660:28 2001:660:282:5:2b 1388 - 0 - -
xl0 1500 3ffe:305:10 3ffe:305:1002:5:2 467 - 0 - -
lp0* 1500 <Link#2> 0 0 0 0 0
gif0 1280 <Link#3> 279 0 388 0 0
gif0 1280 fe80:3::2b0 fe80:3::2b0:d0ff: 0 - 0 - -
gif0 1280 192.108.119.1 192.108.119.195 279 - 386 - -
...

===Configuration manuelle===

Pour configurer des adresses IPv6 de manière statique sur une interface de nom <tt>IFX</tt>, il suffit de mettre dans le fichier de configuration <tt>/etc/rc.conf</tt> les informations nécessaires. Les variables à définir ont pour nom <tt>ipv6_ifconfig_IFX</tt> (une seule adresse) ou <tt>ipv6_ifconfig_IFX_aliasY</tt> (<tt>Y</tt> entier de 0 à N-1 si <tt>IFX</tt> a N adresses IPv6). La syntaxe est celle des arguments de la commande <tt>ifconfig</tt>. L'adresse lien-local est toujours générée automatiquement et ne doit pas être positionnée de cette manière. Ainsi les lignes suivantes ajoutées dans le fichier <tt>/etc/rc.conf</tt> configurent deux adresses IPv6 sur l'interface <tt>fxp0</tt> :

ipv6_ifconfig_fxp0_alias0="3ffe:3ff:92:55:a00:20ff:fe8e:f324 prefixlen 64"
ipv6_ifconfig_fxp0_alias1="2001:6ff:43:55:a00:20ff:fe8e:f324 prefixlen 64"

===<div id="tunnel">Configuration d'un tunnel</div>===

Pour créer un tunnel configuré, il faut configurer une interface de type gif. Les lignes suivantes ajoutées dans le fichier <tt>/etc/rc.conf</tt> déclarent un tunnel IPv6 dans IPv4, l'adresse de IPv4 de l'extrémité locale étant <tt>128.1.2.3</tt>, celle de l'extrémité distante <tt>192.1.2.5</tt>, le tunnel est entre les adresses IPv6 locale <tt>2001:6ff::45</tt> et distante <tt>2001:6ff::46</tt> :

gif_interfaces="gif0"
gif_config_gif0="128.1.2.3 192.1.2.5"
ipv6_ifconfig_gif0="2001:6ff:45 2001:6ff:46"

===Configuration de règles de sécurité===

FreeBSD propose le filtrage de paquets en IPv4 comme en IPv6. L'activation est contrôlée par les variables du fichier <tt>/etc/rc.conf ipv6_firewall_enable</tt> (<tt>YES</tt> ou <tt>NO</tt>) et <tt>ipv6_firewall_type</tt>. Cette seconde variable peut valoir <tt>open</tt> (pas de filtre installé), <tt>client</tt> (utiliser un jeu de filtre standard pour une machine simple), <tt>simple</tt> (utiliser un jeu de filtre standard pour un réseau), <tt>closed</tt> (tout interdire sauf le trafic via l'interface <tt>lo0</tt>), ou être le nom d'un fichier de règles (voir <tt>man ip6fw</tt>). Par exemple, on peut bloquer la commande «<tt>ping6 ::1</tt>» en positionnant «<tt>ipv6_firewall_type=/etc/my_ip6fw_rules</tt>» et en créant le fichier <tt>/etc/my_ip6fw_rules</tt> :

add 100 deny ipv6-icmp from ::1 to any
add 65000 pass all from any to any

Une autre méthode pour contrôler les connexions est d'utiliser la librairie «tcpwrappers». De nombreuses commandes réseau (<tt>sendmail</tt>, <tt>sshd</tt>, les commandes lancées par <tt>inetd</tt>, ...) utilisent cette librairie pour vérifier si un accès distant est autorisé par un fichier de configuration (voir <tt>man 5 hosts_access</tt>). Voici un exemple de fichier de configuration <tt>/etc/hosts.allow</tt> qui limite les connections entrantes ssh à deux réseaux :

sshd: [2001:660:5301:2::]/64 : allow
sshd: 192.0.2.32/255.255.255.224 : allow
sshd : ALL : deny

==NetBSD==

NetBSD propose IPv6 en standard depuis la version 1.5. La plupart des applications sont portées pour IPv6, y compris RPC et NFS.

Si on n'a pas activé IPv6 à l'installation, on peut le configurer «à la main» en éditant le fichier <tt>/etc/rc.conf</tt>.

Le fichier <tt>/etc/rc.conf</tt> définit la plupart des variables de configuration. Les valeurs par défaut (et les commentaires) sont dans le fichier <tt>/etc/default/rc.conf</tt> (à ne pas modifier).

Pour activer manuellement IPv6 sur une machine NetBSD dans le cas le plus simple (autoconfiguration sans état), il suffit d'ajouter dans le fichier <tt>/etc/rc.conf</tt> la ligne :

ip6mode=autohost

IPv6 sera disponible au prochain reboot.

===Configuration manuelle===

Pour configurer des adresses IPv6 de manière statique sur une interface de nom IFX, il suffit de mettre dans le fichier de configuration <tt>/etc/ifconfig.IFX</tt> les informations nécessaires, selon la syntaxe des arguments de la commande ifconfig. L'adresse lien-local est toujours générée automatiquement et ne doit pas être positionnée de cette manière. Par exemple les deux dernières lignes du fichier suivant définissent 2 adresses sur l'interface <tt>epic0</tt> :

> '''cat /etc/ifconfig.epic0'''
up media autoselect
132.227.10.10 netmask 0xffffffe0
inet6 2001:660:282:1:260:97ff:fe41:6143 prefixlen 64
inet6 3ffe:304:282:1:260:97ff:fe41:6143 prefixlen 64 alias

Par défaut une machine NetBSD ne remplit pas la fonction de routeur. La valeur de la variable ip6mode dans le fichier <tt>/etc/rc.conf</tt> permet de choisir le mode de fonctionnement :

* routeur relayant les paquets (<tt>ip6mode=router</tt>),
* hôte s'autoconfigurant (<tt>ip6mode=autohost</tt>)
* hôte avec adresses IPv6 statiques (<tt>ip6mode=host</tt>).

===Configuration d'un tunnel===

La configuration d'un tunnel passe par la configuration du pseudo-device gif qui est utilisé pour la configuration de tunnel IPv6 dans IPv4 et IPv6 dans IPv6.

De la même manière que nous avons configuré notre interface Ethernet, nous configurons notre premier tunnel créant le fichier <tt>/etc/ifconfig.gif0</tt>.

Pour un tunnel IPv6 dans IPv6 on aurait :

> '''cat /etc/ifconfig.gif0'''
inet6 tunnel 2001:660:10c:3d:280:c8ff:fe46:308f 2001:660:80:4000::2
inet6 3ffe:304:124:ff01::1 3ffe:304:124:ff01::2

et pour IPv6 dans IPv4 :

> '''cat /etc/ifconfig.gif0'''
tunnel 132.227.72.30 129.88.26.8
inet6 3ffe:304:124:ff01::1 3ffe:304:124:ff01::2

La première ligne établit le tunnel ; elle est équivalente à la commande suivante :

> '''ifconfig gif0 inet6 tunnel 132.227.72.30 129.88.26.8'''

===Configuration de règles de sécurité===

NetBSD propose le filtrage de paquets en IPv4 comme en IPv6. L'activation est contrôlée par la variable du fichier <tt>/etc/rc.conf ipv6_filter</tt> (<tt>YES</tt> ou <tt>NO</tt>). Le fichier de règles est <tt>/etc/ipf6.conf</tt> (voir <tt>man ipf6.conf</tt>). Par exemple, on peut bloquer la commande «<tt>ping6 ::1</tt>» avec le fichier suivant :

> cat /etc/ipf6.conf
block in quick from ::1 to any
pass in all

Une autre méthode pour contrôler les connexions est d'utiliser la librairie «tcpwrappers». De nombreuses commandes réseau (<tt>sendmail</tt>, <tt>sshd</tt>, les commandes lancées par inetd, ...) utilisent cette librairie pour vérifier si un accès distant est autorisé par un fichier de configuration (voir <tt>man 5 hosts_access</tt>). Voici un exemple de fichier de configuration <tt>/etc/hosts.allow</tt> qui limite les connections entrantes ssh à deux réseaux :

sshd: [2001:660:5301:2::/64] : allow
sshd: 192.0.2.32/255.255.255.224 : allow
sshd : ALL : deny

{{suivi| Linux | Linux | Routage | Routage}}

BSD

2006-02-23T22:04:52Z

Emmanuel Berre: /* Configuration manuelle */

{{suivi| Linux | Linux | Routage | Routage}}
Il existe de nombreux systèmes dérivés de BSD : BSD/OS, FreeBSD, NetBSD, OpenBSD, MAC OS X,... IPv6 est disponible sur ces systèmes depuis très longtemps, plusieurs implémentations ont existé. Aujourd'hui la plupart de ces systèmes proposent IPv6 en standard, en utilisant un code dérivé d'une même souche (KAME). On se concentrera ici sur FreeBSD et NetBSD, mais les mises en ?uvre sur les autres systèmes sont proches.

==FreeBSD==

FreeBSD propose IPv6 en standard depuis la version 4.0. La bibliothèque <tt>libc</tt> et la plupart des applications supportent IPv6 (RPC et NFS seulement à partir de FreeBSD 5). Dans le cas le plus simple (machine utilisant l'autoconfiguration sans état), les menus d'installation système proposent de configurer IPv6, il suffit de répondre à la question de configuration d'une interface en IPv6. Si on n'a pas activé IPv6 à l'installation, on peut rappeler le programme de configuration <tt>/stand/sysinstall</tt> pour reconfigurer les interfaces. On peut aussi configurer «à la main» en éditant le fichier <tt>/etc/rc.conf</tt>.

Le fichier <tt>/etc/rc.conf</tt> sert à définir la plupart des variables de configuration d'une machine FreeBSD. Les valeurs par défaut (et les commentaires) sont dans le fichier de référence <tt>/etc/default/rc.conf</tt> (à ne pas modifier).

Pour activer manuellement IPv6 dans le cas le plus simple (autoconfiguration sans état), il suffit d'ajouter dans le fichier <tt>/etc/rc.conf</tt> la ligne :

ipv6_enable=YES

IPv6 sera disponible au prochain reboot.

Pour vérifier que IPv6 fonctionne correctement, on dispose des commandes <tt>ping6</tt> et <tt>traceroute6</tt> pour tester l'accessibilité d'une machine, et netstat pour visualiser les tables de routage, et de connexions actives.

Par exemple pour tester la connectivité IPv6 :

> '''/usr/sbin/traceroute6 www6.ipv6.imag.fr'''
traceroute6 to www6.ipv6.imag.fr (2001:660:181:1::50) from
2001:660:282:5:2b0:d0ff:fe3b:e565, 30 hops max, 12 byte packets
1 2001:660:282:5:200:c0ff:fee4:caa0 22.234 ms 0.993 ms 0.919 ms
2 pallas.ipv6.rennes.enst-bretagne.fr 3.81 ms * 3.684 ms
3 horace.ipv6.rennes.enst-bretagne.fr 7.93 ms * 15.773 ms
4 2001:660:80:4002::1 14.876 ms * 14.941 ms
5 2001:660:80:4004::2 22.877 ms * 22.835 ms
6 luna-v6.ipv6.imag.fr 50.509 ms 46.267 ms 46.148 ms

La commande suivante montre les interfaces activées en IPv6. Il existe un tunnel IPv4 dans IPv6 <tt>gif0</tt>, et l'interface <tt>xl0</tt> a deux adresses IPv6 globales :

> '''netstat -inf inet6'''
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
xl0 1500 <Link#1> 00:b0:d0:3b:e5:65 82186 0 74502 0 0
xl0 1500 193.52.74 193.52.74.217 58006 - 72342 - -
xl0 1500 fe80:1::2b0 fe80:1::2b0:d0ff: 70 - 2131 - -
xl0 1500 2001:660:28 2001:660:282:5:2b 1388 - 0 - -
xl0 1500 3ffe:305:10 3ffe:305:1002:5:2 467 - 0 - -
lp0* 1500 <Link#2> 0 0 0 0 0
gif0 1280 <Link#3> 279 0 388 0 0
gif0 1280 fe80:3::2b0 fe80:3::2b0:d0ff: 0 - 0 - -
gif0 1280 192.108.119.1 192.108.119.195 279 - 386 - -
...

===Configuration manuelle===

Pour configurer des adresses IPv6 de manière statique sur une interface de nom <tt>IFX</tt>, il suffit de mettre dans le fichier de configuration <tt>/etc/rc.conf</tt> les informations nécessaires. Les variables à définir ont pour nom <tt>ipv6_ifconfig_IFX</tt> (une seule adresse) ou <tt>ipv6_ifconfig_IFX_aliasY</tt> (<tt>Y</tt> entier de 0 à N-1 si <tt>IFX</tt> a N adresses IPv6). La syntaxe est celle des arguments de la commande <tt>ifconfig</tt>. L'adresse lien-local est toujours générée automatiquement et ne doit pas être positionnée de cette manière. Ainsi les lignes suivantes ajoutées dans le fichier <tt>/etc/rc.conf</tt> configurent deux adresses IPv6 sur l'interface <tt>fxp0</tt> :

ipv6_ifconfig_fxp0_alias0="3ffe:3ff:92:55:A00:20ff:fe8e:f324 prefixlen 64"
ipv6_ifconfig_fxp0_alias1="2001:6ff:43:55:A00:20ff:fe8e:f324 prefixlen 64"

===<div id="tunnel">Configuration d'un tunnel</div>===

Pour créer un tunnel configuré, il faut configurer une interface de type gif. Les lignes suivantes ajoutées dans le fichier <tt>/etc/rc.conf</tt> déclarent un tunnel IPv6 dans IPv4, l'adresse de IPv4 de l'extrémité locale étant <tt>128.1.2.3</tt>, celle de l'extrémité distante <tt>192.1.2.5</tt>, le tunnel est entre les adresses IPv6 locale <tt>2001:6ff::45</tt> et distante <tt>2001:6ff::46</tt> :

gif_interfaces="gif0"
gif_config_gif0="128.1.2.3 192.1.2.5"
ipv6_ifconfig_gif0="2001:6ff:45 2001:6ff:46"

===Configuration de règles de sécurité===

FreeBSD propose le filtrage de paquets en IPv4 comme en IPv6. L'activation est contrôlée par les variables du fichier <tt>/etc/rc.conf ipv6_firewall_enable</tt> (<tt>YES</tt> ou <tt>NO</tt>) et <tt>ipv6_firewall_type</tt>. Cette seconde variable peut valoir <tt>open</tt> (pas de filtre installé), <tt>client</tt> (utiliser un jeu de filtre standard pour une machine simple), <tt>simple</tt> (utiliser un jeu de filtre standard pour un réseau), <tt>closed</tt> (tout interdire sauf le trafic via l'interface <tt>lo0</tt>), ou être le nom d'un fichier de règles (voir <tt>man ip6fw</tt>). Par exemple, on peut bloquer la commande «<tt>ping6 ::1</tt>» en positionnant «<tt>ipv6_firewall_type=/etc/my_ip6fw_rules</tt>» et en créant le fichier <tt>/etc/my_ip6fw_rules</tt> :

add 100 deny ipv6-icmp from ::1 to any
add 65000 pass all from any to any

Une autre méthode pour contrôler les connexions est d'utiliser la librairie «tcpwrappers». De nombreuses commandes réseau (<tt>sendmail</tt>, <tt>sshd</tt>, les commandes lancées par <tt>inetd</tt>, ...) utilisent cette librairie pour vérifier si un accès distant est autorisé par un fichier de configuration (voir <tt>man 5 hosts_access</tt>). Voici un exemple de fichier de configuration <tt>/etc/hosts.allow</tt> qui limite les connections entrantes ssh à deux réseaux :

sshd: [2001:660:5301:2::]/64 : allow
sshd: 192.0.2.32/255.255.255.224 : allow
sshd : ALL : deny

==NetBSD==

NetBSD propose IPv6 en standard depuis la version 1.5. La plupart des applications sont portées pour IPv6, y compris RPC et NFS.

Si on n'a pas activé IPv6 à l'installation, on peut le configurer «à la main» en éditant le fichier <tt>/etc/rc.conf</tt>.

Le fichier <tt>/etc/rc.conf</tt> définit la plupart des variables de configuration. Les valeurs par défaut (et les commentaires) sont dans le fichier <tt>/etc/default/rc.conf</tt> (à ne pas modifier).

Pour activer manuellement IPv6 sur une machine NetBSD dans le cas le plus simple (autoconfiguration sans état), il suffit d'ajouter dans le fichier <tt>/etc/rc.conf</tt> la ligne :

ip6mode=autohost

IPv6 sera disponible au prochain reboot.

===Configuration manuelle===

Pour configurer des adresses IPv6 de manière statique sur une interface de nom IFX, il suffit de mettre dans le fichier de configuration <tt>/etc/ifconfig.IFX</tt> les informations nécessaires, selon la syntaxe des arguments de la commande ifconfig. L'adresse lien-local est toujours générée automatiquement et ne doit pas être positionnée de cette manière. Par exemple les deux dernières lignes du fichier suivant définissent 2 adresses sur l'interface <tt>epic0</tt> :

> '''cat /etc/ifconfig.epic0'''
up media autoselect
132.227.10.10 netmask 0xffffffe0
inet6 2001:660:282:1:260:97ff:fe41:6143 prefixlen 64
inet6 3ffe:304:282:1:260:97ff:fe41:6143 prefixlen 64 alias

Par défaut une machine NetBSD ne remplit pas la fonction de routeur. La valeur de la variable ip6mode dans le fichier <tt>/etc/rc.conf</tt> permet de choisir le mode de fonctionnement :

* routeur relayant les paquets (<tt>ip6mode=router</tt>),
* hôte s'autoconfigurant (<tt>ip6mode=autohost</tt>)
* hôte avec adresses IPv6 statiques (<tt>ip6mode=host</tt>).

===Configuration d'un tunnel===

La configuration d'un tunnel passe par la configuration du pseudo-device gif qui est utilisé pour la configuration de tunnel IPv6 dans IPv4 et IPv6 dans IPv6.

De la même manière que nous avons configuré notre interface Ethernet, nous configurons notre premier tunnel créant le fichier <tt>/etc/ifconfig.gif0</tt>.

Pour un tunnel IPv6 dans IPv6 on aurait :

> '''cat /etc/ifconfig.gif0'''
inet6 tunnel 2001:660:10c:3d:280:c8ff:fe46:308f 2001:660:80:4000::2
inet6 3ffe:304:124:ff01::1 3ffe:304:124:ff01::2

et pour IPv6 dans IPv4 :

> '''cat /etc/ifconfig.gif0'''
tunnel 132.227.72.30 129.88.26.8
inet6 3ffe:304:124:ff01::1 3ffe:304:124:ff01::2

La première ligne établit le tunnel ; elle est équivalente à la commande suivante :

> '''ifconfig gif0 inet6 tunnel 132.227.72.30 129.88.26.8'''

===Configuration de règles de sécurité===

NetBSD propose le filtrage de paquets en IPv4 comme en IPv6. L'activation est contrôlée par la variable du fichier <tt>/etc/rc.conf ipv6_filter</tt> (<tt>YES</tt> ou <tt>NO</tt>). Le fichier de règles est <tt>/etc/ipf6.conf</tt> (voir <tt>man ipf6.conf</tt>). Par exemple, on peut bloquer la commande «<tt>ping6 ::1</tt>» avec le fichier suivant :

> cat /etc/ipf6.conf
block in quick from ::1 to any
pass in all

Une autre méthode pour contrôler les connexions est d'utiliser la librairie «tcpwrappers». De nombreuses commandes réseau (<tt>sendmail</tt>, <tt>sshd</tt>, les commandes lancées par inetd, ...) utilisent cette librairie pour vérifier si un accès distant est autorisé par un fichier de configuration (voir <tt>man 5 hosts_access</tt>). Voici un exemple de fichier de configuration <tt>/etc/hosts.allow</tt> qui limite les connections entrantes ssh à deux réseaux :

sshd: [2001:660:5301:2::/64] : allow
sshd: 192.0.2.32/255.255.255.224 : allow
sshd : ALL : deny

{{suivi| Linux | Linux | Routage | Routage}}

User:Emmanuel Berre

2006-02-23T13:20:18Z

Emmanuel Berre:

Ingénieur réseau chez Silicomp-AQL au sein de l'équipe IPv6.

Talk:Linux

2006-02-23T13:18:34Z

Emmanuel Berre: 6to4 howto linux ?

Il serait peut-être intéresant de montrer la mise en place d'un tunnel 6to4 dans cette partie.

MPLS

2006-02-23T13:12:32Z

Emmanuel Berre: /* MPLS comme outil de transition IPv4 vers IPv6 */

{{suivi| Routage externe | Routage externe | La technique 6PE | La technique 6PE}}
Ce chapitre a pour objectif de montrer l'impact d'IPv6 sur la technologie MPLS (Multi Protocol Label Switching). Trois usages qui lient IPv6 à MPLS peuvent être différenciés :

* transition IPv4 vers IPv6 : dans ce contexte, MPLS a été identifié comme une technologie permettant le transport de flux IPv6 à moindre coût. En effet, une fois que le paquet IPv6 est encapsulé dans une trame MPLS sur le routeur d'entrée (le PE-routeur en terminologie MPLS), celle-ci est commutée comme toute autre trame sur les routeurs MPLS de coeur (les P-routeurs). Cette méthode, appelée 6PE (IPv6 Provider Edge) permet de connecter des sites distants IPv6 au travers d'un réseau de coeur MPLS IPv4. La [[La technique 6PE|première partie]] de ce chapitre décrit en détail cette technique. On y trouvera également un [[ Exemple de mise en oeuvre de 6PE|exemple concret]] d'activation de tunnel 6PE sur routeur Cisco;
* mise en place des tunnels MPLS : des protocoles spécifiques (LDP : Label Distribution Protocol, TDP : Tag Distribution Protocol) ou adaptés (BGP, RSVP) construisent les chemins MPLS (les LSP : Label Switched Path) sur la base des informations contenues dans les tables de routage interne. Si les extensions sont décrites dans les RFC 3036 pour LDP et RFC 3209 pour RSVP-TE, aucun contructeur ne les implémente ;
* réseaux privés virtuels : les L3 VPN MPLS représentent le service le plus utilisé de la technologie MPLS. Ils permettent le déploiement de réseaux privés (virtuels car une seule infrastructure physique est utilisée) en assurant une étanchéité entre eux, tout comme si chaque réseau était physiquement différent. Ils se basent sur le RFC 2547 (BGP/MPLS VPN), à laquelle des extensions ont été ajoutées pour le support d'IPv6. La [[Réseaux privés virtuels IPv6 sur MPLS|deuxième partie]] de ce chapitre explore cette technique.

==MPLS comme outil de transition IPv4 vers IPv6==

Utiliser un coeur de réseau MPLS pour transporter des flux IPv6 permet d'interconnecter des îlots IPv6 au travers d'un coeur de réseau IPv4 MPLS. Cette solution est intéressante dans le cadre d'un déploiement d'IPv6 car MPLS commute des labels et non pas des en-têtes IP. Elle offre donc l'avantage de ne pas avoir à mettre à jour les routeurs de coeur.

Historiquement, plusieurs solutions d'encapsulation ont été proposées. Nous allons les décrire rapidement afin d'arriver à [[La technique 6PE|la technique 6PE]] qui est la plus aboutie et finalement la dernière solution avant de passer à un coeur de réseau MPLS gérant directement IPv6.

La figure Architecture MPLS dans le contexte IPv6 schématise ces différentes architectures dans le cadre de l'interconnexion de sites IPv6.

[[image:CS82.gif]]

* Tunnels IP : dans ce cas, le routeur CE encapsule les paquets IPv6 dans des paquets IPv4, les envoie en direction du routeur PE qui les traite comme des paquets IPv4 "normaux" et les transmet dans le LSP MPLS. La liaison CE-PE dans ce cas n'est pas IPv6. Cette technique, repose sur un relayage traditionnel et par conséquent, il n'est pas nécessaire d'avoir des équipments MPLS. L'inconvénient est que d'une part les performances d'encapsulation IPv6 dans IPv4 sont médiocres (lorsqu'elle n'est pas traitée par une carte tunnel dédiée) et d'autre part que la configuration de ces tunnels doit être faite de façon unitaire (ce qui ne tient pas le facteur d'échelle);
* VPN de niveau 2 : dans ce cas, le routeur CE encapsule les paquets IPv6 dans des trames de niveau 2 (Ethernet ou ATM) et les envoie au routeur PE. Celui-ci les transmet directement dans les LSP MPLS. L'avantage de cette technique est la performance de commutation (qui se fait au niveau trame et non plus au niveau 3 comme la solution précédente). L'interconnexion CE-PE voit passer de l'IPv6 dans des trames de niveau 2 mais le routeur PE ne sait pas qu'il met en tunnel des paquets IPv6 (pour lui il s'agit uniquement du niveau 2 transmis dans MPLS). Il n'a donc pas besoin d'être double pile IPv4/IPv6;
* VPN de niveau 3 : dans ce cas, l'interconnexion CE-PE est IPv6. Le routeur PE créé une classe d'équivalence MPLS dédié à chaque préfixe IPv6 et lui attribue un label MPLS. Comme pour les autres types de L3VPN, les trames MPLS ont alors deux labels :
** un label de transport pour déterminer le LSP (qui peut éventuellement changer à chaque commutation sur un routeur P) et
** un label de "service 6PE" qui est inchangé pour un préfixe IPv6 donné.
: L'avantage de cette méthode est la performance de commutation d'une part et le fait que l'interconnexion CE-PE est IPv6. Par ailleurs, MP-iBGP est utilisé pour attribuer dynamiquement les labels (cela évite d'avoir une configuration manuelle full-mesh des tunnels). Il faut que le routeur PE implémente la fonction 6PE (les routeurs P restent inchangés par contre).

Il est intéressant de constater l'évolution de ces techniques. En effet, au fur et à mesure, les paquets IPv6 se sont rapprochés du routeur PE et donc du coeur de réseau. Aujourd'hui [[La technique 6PE|la technique 6PE]] est la plus aboutie et la plus performante dans le cas d'un déploiement d'IPv6 sur un coeur MPLS IPv4.

{{suivi| Routage externe | Routage externe | La technique 6PE | La technique 6PE}}

MPLS

2006-02-23T13:10:58Z

Emmanuel Berre: /* MPLS comme outil de transition IPv4 vers IPv6 */

{{suivi| Routage externe | Routage externe | La technique 6PE | La technique 6PE}}
Ce chapitre a pour objectif de montrer l'impact d'IPv6 sur la technologie MPLS (Multi Protocol Label Switching). Trois usages qui lient IPv6 à MPLS peuvent être différenciés :

* transition IPv4 vers IPv6 : dans ce contexte, MPLS a été identifié comme une technologie permettant le transport de flux IPv6 à moindre coût. En effet, une fois que le paquet IPv6 est encapsulé dans une trame MPLS sur le routeur d'entrée (le PE-routeur en terminologie MPLS), celle-ci est commutée comme toute autre trame sur les routeurs MPLS de coeur (les P-routeurs). Cette méthode, appelée 6PE (IPv6 Provider Edge) permet de connecter des sites distants IPv6 au travers d'un réseau de coeur MPLS IPv4. La [[La technique 6PE|première partie]] de ce chapitre décrit en détail cette technique. On y trouvera également un [[ Exemple de mise en oeuvre de 6PE|exemple concret]] d'activation de tunnel 6PE sur routeur Cisco;
* mise en place des tunnels MPLS : des protocoles spécifiques (LDP : Label Distribution Protocol, TDP : Tag Distribution Protocol) ou adaptés (BGP, RSVP) construisent les chemins MPLS (les LSP : Label Switched Path) sur la base des informations contenues dans les tables de routage interne. Si les extensions sont décrites dans les RFC 3036 pour LDP et RFC 3209 pour RSVP-TE, aucun contructeur ne les implémente ;
* réseaux privés virtuels : les L3 VPN MPLS représentent le service le plus utilisé de la technologie MPLS. Ils permettent le déploiement de réseaux privés (virtuels car une seule infrastructure physique est utilisée) en assurant une étanchéité entre eux, tout comme si chaque réseau était physiquement différent. Ils se basent sur le RFC 2547 (BGP/MPLS VPN), à laquelle des extensions ont été ajoutées pour le support d'IPv6. La [[Réseaux privés virtuels IPv6 sur MPLS|deuxième partie]] de ce chapitre explore cette technique.

==MPLS comme outil de transition IPv4 vers IPv6==

Utiliser un coeur de réseau MPLS pour transporter des flux IPv6 permet d'interconnecter des îlots IPv6 au travers d'un coeur de réseau IPv4 MPLS. Cette solution est intéressante dans le cadre d'un déploiement d'IPv6 car MPLS commute des labels et non pas des en-têtes IP. Elle offre donc l'avantage de ne pas avoir à mettre à jour les routeurs de coeur.

Historiquement, plusieurs solutions d'encapsulation ont été proposées. Nous allons les décrire rapidement afin d'arriver à [[La technique 6PE|la technique 6PE]] qui est la plus aboutie et finalement la dernière solution avant de passer à un coeur de réseau MPLS gérant directement IPv6.

La figure Architecture MPLS dans le contexte IPv6 schématise ces différentes architectures dans le cadre de l'interconnexion de sites IPv6.

[[image:CS82.gif]]

* Tunnels IP : dans ce cas, le routeur CE encapsule les paquets IPv6 dans des paquets IPv4 et les envoie en direction du routeur PE qui les traite comme des paquets IPv4 "normaux" et les transmet dans le LSP MPLS. La liaison CE-PE dans ce cas n'est pas IPv6. Cette technique, repose sur un relayage traditionnel et par conséquent, il n'est pas nécessaire d'avoir des équipments MPLS. L'inconvénient est que d'une part les performances d'encapsulation IPv6 dans IPv4 sont médiocres (lorsqu'elle n'est pas traitée par une carte tunnel dédiée) et d'autre part que la configuration de ces tunnels doit être faite de façon unitaire (ce qui ne tient pas le facteur d'échelle);
* VPN de niveau 2 : dans ce cas, le routeur CE encapsule les paquets IPv6 dans des trames de niveau 2 (Ethernet ou ATM) et les envoie au routeur PE. Celui-ci les transmet directement dans les LSP MPLS. L'avantage de cette technique est la performance de commutation (qui se fait au niveau trame et non plus au niveau 3 comme la solution précédente). L'interconnexion CE-PE voit passer de l'IPv6 dans des trames de niveau 2 mais le routeur PE ne sait pas qu'il met en tunnel des paquets IPv6 (pour lui il s'agit uniquement du niveau 2 transmis dans MPLS). Il n'a donc pas besoin d'être double pile IPv4/IPv6;
* VPN de niveau 3 : dans ce cas, l'interconnexion CE-PE est IPv6. Le routeur PE créé une classe d'équivalence MPLS dédié à chaque préfixe IPv6 et lui attribue un label MPLS. Comme pour les autres types de L3VPN, les trames MPLS ont alors deux labels :
** un label de transport pour déterminer le LSP (qui peut éventuellement changer à chaque commutation sur un routeur P) et
** un label de "service 6PE" qui est inchangé pour un préfixe IPv6 donné.
: L'avantage de cette méthode est la performance de commutation d'une part et le fait que l'interconnexion CE-PE est IPv6. Par ailleurs, MP-iBGP est utilisé pour attribuer dynamiquement les labels (cela évite d'avoir une configuration manuelle full-mesh des tunnels). Il faut que le routeur PE implémente la fonction 6PE (les routeurs P restent inchangés par contre).

Il est intéressant de constater l'évolution de ces techniques. En effet, au fur et à mesure, les paquets IPv6 se sont rapprochés du routeur PE et donc du coeur de réseau. Aujourd'hui [[La technique 6PE|la technique 6PE]] est la plus aboutie et la plus performante dans le cas d'un déploiement d'IPv6 sur un coeur MPLS IPv4.

{{suivi| Routage externe | Routage externe | La technique 6PE | La technique 6PE}}

Linux

2006-02-23T11:29:25Z

Emmanuel Berre: /* Configuration manuelle */

{{suivi| Macintosh | Macintosh | BSD | BSD}}

De nombreuses distributions de Linux existent. Debian, RedHat, Mandrake, Suse en sont quelques unes parmi les plus connues. Une distribution Linux est constituée du noyau Linux proprement dit, et d'un ensemble de programmes (essentiellement d'origine GNU ou BSD) utilisant des librairies. D'une manière générale, pour qu'une distribution Linux fonctionne en IPv6, il faut qu'elle intègre un noyau, des librairies, des scripts de configuration et des applications supportant IPv6. Bien que dérivant de noyaux et d'outils de même origine, chaque distribution a ses particularités. Le programme d'installation est différent, et chaque société ou organisme maintenant cette distribution fait le choix d'intégrer -ou non- des programmes différents en fonction du public visé. Il est donc impossible, dans ce chapitre, de particulariser pour chaque distribution. On donne ici des remarques générales, et on développera l'exemple de RedHat/FedoraCore. Pour les autres distributions, la documentation (ou une recherche sur le Web) permet de trouver les adaptations nécessaires.

La souche IPv6 est intégrée officiellement au noyau depuis les versions 2.2, mais ces noyaux étaient incomplets et non conformes aux RFC. Les noyaux 2.4 sont plus corrects, mais eux aussi présentent quelques lacunes. Les noyaux 2.6 sont donc préférables ; ils intègrent un partie des développements du projet japonais USAGI, en particulier la sécurité (IPsec). Il faut aussi un noyau compilé avec l'option IPv6 (dans le noyau ou en module). Ce type de noyau est en général disponible dans tous les distributions (au moins comme paquetage optionnel).

Les applications, quand à elles, doivent utiliser une librairie C supportant IPv6. La GNU Libc 2 intègre correctement le support IPv6 à partir de la version 2.2 de la Glibc. Aussi, il est important d'utiliser une distribution Linux qui réponde à ces critères.

C'est le cas des distributions récentes, par exemple Debian (version Woody ou supérieure), RedHat ≥ = 7.1, Mandrake ≥ = 8.0. Cette liste n'est bien entendu pas exhaustive.

==Linux RedHat et FedoraCore==

Linux RedHat et FedoraCore proposent IPv6 en standard depuis la version RedHat 7.1. La bibliothèque <tt>libc</tt> et la plupart des applications supportent IPv6 (sauf RPC et NFS). Pour le cas le plus simple (machine utilisant l'autoconfiguration sans état), il suffit de valider à l'installation. On peut modifier l'activation de IPv6 en définissant à ''yes'' ou à ''no'' la variable <tt>NETWORKING_IPV6</tt> dans le fichier <tt>/etc/sysconfig/network</tt>. Notons que dans les dernières versions de FedoraCore, la génération d'adresses autoconfigurées est active par défaut ; toutefois les scripts de configuration IPv6 ne seront pas appelés si la variable <tt>NETWORKING_IPV6</tt> n'est pas validée, et la configuration risque donc d'être incomplète.

Pour vérifier que IPv6 fonctionne correctement, on dispose des commandes <tt>ping6</tt> ou <tt>traceroute6</tt> pour tester l'accessibilité d'une machine, et <tt>netstat</tt> ou <tt>ip</tt> pour visualiser les tables de routage, et de connexions actives.

==Configuration manuelle==

Pour configurer des adresses IPv6 de manière statique sur une interface de nom <tt>ethX</tt>, il suffit de mettre les informations nécessaires dans le fichier de configuration de l'interface <tt>/etc/sysconfig/network-scripts/ifcfg-ethX</tt>. Les variables à définir sont <tt>IPV6INIT</tt>, <tt>IPV6_AUTOCONF</tt>, <tt>IPV6ADDR</tt>. Toutes les variables utiles sont documentées dans le fichier <tt>/etc/sysconfig/network-scripts/init.ipv6</tt>. Par exemple voici comment définir une adresse statique sur une interface :

IPV6INIT=YES
IPV6_AUTOCONF=no
IPV6ADDR=2001:6ff:10:1::1000/64

Il est aussi possible d'ajouter une adresse IPv6 explicitement grace à la commande <tt>ifconfig</tt>.

ifconfig eth0 inet6 add 2001:6ff:10:1::1000/64

L'ajout de la route par défaut correspondante se fait comment en IPv4 à l'aide de la commande <tt>route</tt>.

route -A inet6 add default gw 2001:6ff:10:1::ffff

Une autre soluton consiste à utiliser la commande <tt>ip</tt> du pakcage iproute2. Iproute2 est une collection d'utilitaires permettant de contrôler divers aspects réseau sous Linux. Iproute2 et sa commande <tt>ip</tt> visent à remplacer les commandes <tt>ifconfig</tt> et <tt>route</tt> jugées obsolètes.

L'ajout d'une adresse IP en utilisant la commande <tt>ip</tt> se fait de la manière suivante :

ip -6 addr add 2001:6ff:10:1::1000/64 dev eth0

Cette commande est strictement équivalente à la commande <tt>ifconfig</tt> utilisée précédemment. Tout comme pour ifconfig, il est aussi possible d'utiliser la commande <tt>ip</tt> pour remplacer la commande <tt>route</tt>.

ip -6 route add default via 2001:6ff:10:1::ffff

==Configuration d'un tunnel==

Pour créer un tunnel configuré, il faut configurer une interface de nom <tt>sitX</tt> (X≥1). Le fichier suivant <tt>/etc/sysconfig/network-scripts/ifcfg-sit1</tt> déclare un tunnel IPv6 dans IPv4, l'adresse de IPv4 de l'extrémité distante étant <tt>192.1.2.5</tt>, sans adresses IPv6 :

DEVICE="sit1"
BOOTPROTO="none"
ONBOOT="yes"
IPV6INIT="yes"
IPV6TUNNELIPv4="192.1.2.5"

Comme le tunnel n'a pas d'adresse IPv6, il faut configurer le routage pour l'utiliser. Voici un exemple de fichier <tt>/etc/sysconfig/static-routes-ipv6</tt> qui définit une route statique envoyant tout le trafic IPv6 unicast dans le tunnel :

sit1 2001::/3

==Configuration de règles de sécurité==

Linux RedHat et FedoraCore proposent le filtrage de paquets «iptables» en IPv4 comme en IPv6 (voir http://www.netfilter.org ). Le paquetage (rpm) à installer est iptables-ipv6, et la commande principale est ip6tables. La table de filtrage installée est rangée dans le fichier /etc/sysconfig/ip6tables. Par exemple, la table suivante bloque la commande «ping ::1» :

> '''cat /etc/sysconfig/ip6tables'''
# Generated by ip6tables-save v1.2.11 on Sun Jan 30 17:03:16 2005
*filter
:INPUT ACCEPT [13:1352]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [12:1248]
-A INPUT -s ::1/128 -d ::/0 -p ipv6-icmp -j DROP
COMMIT
# Completed on Sun Jan 30 17:03:16 2005

Ce fichier a été créé par les commandes :

> '''ip6tables -A INPUT -s ::1 -p ipv6-icmp -j DROP'''
> '''ip6tables-save > /etc/sysconfig/ip6tables'''

Pour plus de détails, se référer à la documentation de iptables (en remplaçant les adresses IPv4 par des adresses IPv6 !).

Une autre méthode pour contrôler les connexions est d'utiliser la librairie «tcpwrappers». De nombreuses commandes réseau (sendmail, sshd, les commandes lancées par xinetd, ...) utilisent cette librairie pour vérifier si un accès distant est autorisé par un fichier de configuration (voir man 5 hosts_access). Voici un exemple de fichier de configuration /etc/hosts.allow qui limite les connections entrantes ssh à deux réseaux :

sshd: [2001:660:5301:2::]/64 : allow
sshd: 192.0.2.32/255.255.255.224 : allow
sshd : ALL : deny

{{suivi| Macintosh | Macintosh | BSD | BSD}}

Linux

2006-02-22T17:38:16Z

Emmanuel Berre: /* Configuration manuelle */

{{suivi| Macintosh | Macintosh | BSD | BSD}}

De nombreuses distributions de Linux existent. Debian, RedHat, Mandrake, Suse en sont quelques unes parmi les plus connues. Une distribution Linux est constituée du noyau Linux proprement dit, et d'un ensemble de programmes (essentiellement d'origine GNU ou BSD) utilisant des librairies. D'une manière générale, pour qu'une distribution Linux fonctionne en IPv6, il faut qu'elle intègre un noyau, des librairies, des scripts de configuration et des applications supportant IPv6. Bien que dérivant de noyaux et d'outils de même origine, chaque distribution a ses particularités. Le programme d'installation est différent, et chaque société ou organisme maintenant cette distribution fait le choix d'intégrer -ou non- des programmes différents en fonction du public visé. Il est donc impossible, dans ce chapitre, de particulariser pour chaque distribution. On donne ici des remarques générales, et on développera l'exemple de RedHat/FedoraCore. Pour les autres distributions, la documentation (ou une recherche sur le Web) permet de trouver les adaptations nécessaires.

La souche IPv6 est intégrée officiellement au noyau depuis les versions 2.2, mais ces noyaux étaient incomplets et non conformes aux RFC. Les noyaux 2.4 sont plus corrects, mais eux aussi présentent quelques lacunes. Les noyaux 2.6 sont donc préférables ; ils intègrent un partie des développements du projet japonais USAGI, en particulier la sécurité (IPsec). Il faut aussi un noyau compilé avec l'option IPv6 (dans le noyau ou en module). Ce type de noyau est en général disponible dans tous les distributions (au moins comme paquetage optionnel).

Les applications, quand à elles, doivent utiliser une librairie C supportant IPv6. La GNU Libc 2 intègre correctement le support IPv6 à partir de la version 2.2 de la Glibc. Aussi, il est important d'utiliser une distribution Linux qui réponde à ces critères.

C'est le cas des distributions récentes, par exemple Debian (version Woody ou supérieure), RedHat ≥ = 7.1, Mandrake ≥ = 8.0. Cette liste n'est bien entendu pas exhaustive.

==Linux RedHat et FedoraCore==

Linux RedHat et FedoraCore proposent IPv6 en standard depuis la version RedHat 7.1. La bibliothèque <tt>libc</tt> et la plupart des applications supportent IPv6 (sauf RPC et NFS). Pour le cas le plus simple (machine utilisant l'autoconfiguration sans état), il suffit de valider à l'installation. On peut modifier l'activation de IPv6 en définissant à ''yes'' ou à ''no'' la variable <tt>NETWORKING_IPV6</tt> dans le fichier <tt>/etc/sysconfig/network</tt>. Notons que dans les dernières versions de FedoraCore, la génération d'adresses autoconfigurées est active par défaut ; toutefois les scripts de configuration IPv6 ne seront pas appelés si la variable <tt>NETWORKING_IPV6</tt> n'est pas validée, et la configuration risque donc d'être incomplète.

Pour vérifier que IPv6 fonctionne correctement, on dispose des commandes <tt>ping6</tt> ou <tt>traceroute6</tt> pour tester l'accessibilité d'une machine, et <tt>netstat</tt> ou <tt>ip</tt> pour visualiser les tables de routage, et de connexions actives.

==Configuration manuelle==

Pour configurer des adresses IPv6 de manière statique sur une interface de nom <tt>ethX</tt>, il suffit de mettre les informations nécessaires dans le fichier de configuration de l'interface <tt>/etc/sysconfig/network-scripts/ifcfg-ethX</tt>. Les variables à définir sont <tt>IPV6INIT</tt>, <tt>IPV6_AUTOCONF</tt>, <tt>IPV6ADDR</tt>. Toutes les variables utiles sont documentées dans le fichier <tt>/etc/sysconfig/network-scripts/init.ipv6</tt>. Par exemple voici comment définir une adresse statique sur une interface :

IPV6INIT=YES
IPV6_AUTOCONF=no
IPV6ADDR=2001:6ff:10:1::1000/64

Il est aussi possible d'ajouter une adresse IPv6 explicitement grace à la commande <tt>ifconfig</tt>.

ifconfig eth0 inet6 add 2001:6ff:10:1::1000/64

L'ajout de la route par défaut correspondante se fait comment en IPv4 à l'aide de la commande <tt>route</tt>.

route -A inet6 add default gw 2001:6ff:10:1::ffff

==Configuration d'un tunnel==

Pour créer un tunnel configuré, il faut configurer une interface de nom <tt>sitX</tt> (X≥1). Le fichier suivant <tt>/etc/sysconfig/network-scripts/ifcfg-sit1</tt> déclare un tunnel IPv6 dans IPv4, l'adresse de IPv4 de l'extrémité distante étant <tt>192.1.2.5</tt>, sans adresses IPv6 :

DEVICE="sit1"
BOOTPROTO="none"
ONBOOT="yes"
IPV6INIT="yes"
IPV6TUNNELIPv4="192.1.2.5"

Comme le tunnel n'a pas d'adresse IPv6, il faut configurer le routage pour l'utiliser. Voici un exemple de fichier <tt>/etc/sysconfig/static-routes-ipv6</tt> qui définit une route statique envoyant tout le trafic IPv6 unicast dans le tunnel :

sit1 2001::/3

==Configuration de règles de sécurité==

Linux RedHat et FedoraCore proposent le filtrage de paquets «iptables» en IPv4 comme en IPv6 (voir http://www.netfilter.org ). Le paquetage (rpm) à installer est iptables-ipv6, et la commande principale est ip6tables. La table de filtrage installée est rangée dans le fichier /etc/sysconfig/ip6tables. Par exemple, la table suivante bloque la commande «ping ::1» :

> '''cat /etc/sysconfig/ip6tables'''
# Generated by ip6tables-save v1.2.11 on Sun Jan 30 17:03:16 2005
*filter
:INPUT ACCEPT [13:1352]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [12:1248]
-A INPUT -s ::1/128 -d ::/0 -p ipv6-icmp -j DROP
COMMIT
# Completed on Sun Jan 30 17:03:16 2005

Ce fichier a été créé par les commandes :

> '''ip6tables -A INPUT -s ::1 -p ipv6-icmp -j DROP'''
> '''ip6tables-save > /etc/sysconfig/ip6tables'''

Pour plus de détails, se référer à la documentation de iptables (en remplaçant les adresses IPv4 par des adresses IPv6 !).

Une autre méthode pour contrôler les connexions est d'utiliser la librairie «tcpwrappers». De nombreuses commandes réseau (sendmail, sshd, les commandes lancées par xinetd, ...) utilisent cette librairie pour vérifier si un accès distant est autorisé par un fichier de configuration (voir man 5 hosts_access). Voici un exemple de fichier de configuration /etc/hosts.allow qui limite les connections entrantes ssh à deux réseaux :

sshd: [2001:660:5301:2::]/64 : allow
sshd: 192.0.2.32/255.255.255.224 : allow
sshd : ALL : deny

{{suivi| Macintosh | Macintosh | BSD | BSD}}

Protocoles de Niveau 4

2006-02-22T17:23:06Z

Emmanuel Berre: /* UDP et TCP */

{{suivi|ICMPv6|ICMPv6|Découverte de voisins|Découverte de voisins}}

== UDP et TCP ==

Les modifications apportées aux protocoles de niveau 4 UDP et TCP sont minimes. L'un des pré-requis à la mise en œuvre d'IPv6 était de laisser en l'état aussi bien TCP (''Transmission Control Protocol'') qu'UDP (''User Datagram Protocol''). Ces protocoles de transport sont utilisés par la très grande majorité des applications réseau et l'absence de modification facilitera grandement le passage de IPv4 à IPv6.

La principale modification à ces protocoles concerne le checksum. Comme il a été précisé [[Checksum au niveau transport]], il a été adapté au format de paquet IPv6 et englobe le pseudo-en-tête. De plus, pour UDP, le checksum qui était facultatif en IPv4, devient obligatoire.

Un autre changement au niveau des protocoles de niveau 4 concerne la prise en compte de l'option jumbogramme de l'extension [[Les extensions#PeP|proche-en-proche]]. Le RFC 2675 définit le comportement de UDP et de TCP quand les jumbogrammes sont utilisés. En effet, les en-têtes de ces messages contiennent eux aussi un champ longueur codé sur 16 bits et par conséquent insuffisant pour coder la longueur du jumbogramme :

* Pour le protocole UDP, si la longueur des données excède 65 535 octets, le champ longueur est mis à 0. Le récepteur détermine la longueur des données par la connaissance de la taille dans l'option jumbogramme.
* Le protocole TCP pose plus de problèmes. En effet, bien que les messages TCP ne contiennent pas de champ longueur, plusieurs compteurs sont codés sur 16 bits.
* Le champ longueur de la fenêtre de réception ne pose pas de problème depuis que le RFC 1323 a défini l'option TCP window scale qui donne le facteur multiplicatif qui doit être appliqué à ce champ.
* À l'ouverture de connexion, la taille maximale des segments (MSS) est négociée. Le RFC 2675 précise que si cette taille doit être supérieure à 65 535, la valeur 65 535 est envoyée et le récepteur prend en compte la longueur déterminée par l'algorithme de découverte du MTU.
* Pour l'envoi de données urgentes avec TCP, on utilise un bit spécifique de l'en-tête (bit URG) ainsi que le champ "pointeur urgent". Ce dernier sert à référencer la fin des données à traiter de manière particulière. Trois cas peuvent se présenter :
** Le premier, qui est identique à IPv4, est celui où le pointeur indique une position de moins de 65 535.
** Le second se produit lorsque le déplacement est supérieur à 65 535 et supérieur ou égal à la taille des données TCP envoyées. Cette fois-ci, on place la valeur 65 535 dans le champ "pointeur urgent" et on continue le traitement normal des paquets TCP.
** Le dernier cas intervient quand le pointeur indique un déplacement de plus de 65 535 qui est inférieur à la taille des données TCP. Un premier paquet est alors envoyé, dans lequel on met la valeur 65 535 dans le champ "pointeur urgent". L'important est de choisir une taille de paquet de manière à ce que le déplacement dans le second paquet, pour indiquer la fin des données urgentes, soit inférieur à 65 535.

Il existe d'autres propositions pour faire évoluer TCP. Il faut remarquer que le travail n'est pas de même ampleur que pour IP. En effet, TCP est un protocole de bout-en-bout, la transition vers une nouvelle génération du protocole peut se faire par négociation entre les deux extrémités. Pour IP, tous les routeurs intermédiaires doivent prendre en compte les modifications.

== UDP-lite ==

UDP-lite permet de remonter aux couches supérieures des données erronées pendant leur transport. Si dans un environnement informatique, une erreur peut avoir des conséquences relativement grave quant à l'intégrité des données et il est normal de rejeter ces paquets, or, la plupart des décodeurs de flux multimédias sont capables de supporter un certains nombre d'erreurs binaires dans un flux de données. Pour améliorer la qualité perçue par l'utilisateur, il est donc préférable d'accepter des paquets erronés plutôt que de rejeter un bloc complet d'information.

En IPv4, l'utilisation du checksum UDP étant optionnelle (la valeur 0 indique que le checksum n'est pas calculé), UDP peut être utilisé pour transporter des flux multimédia. Avec IPv6, l'utilisation du checksum a été rendue obligatoire puisque le niveau 3 n'en possède pas. Pour éviter qu'un paquet comportant des erreurs ne puisse pas être remonté aux couche supérieures, le protocole UDP-lite a été défini RFC 3828. Les modifications sont minimes par rapport à UDP. Le format de la trame reste le même, seule la sémantique du champ longueur est changée. Avec UDP, ce champ est inutile puisqu'il est facilement déduit du champ longueur de l'en-tête IP. UDP-lite le transforme en champ couverture du checksum. Si la longueur est 0, UDP-lite considère que tout le checksum couvre tout le paquet. La valeur 8 indique que seul l'en-tête UDP est protégé par le checksum (ainsi qu'une partie de l'en-tête IP grâce au pseudo-header). Les valeurs comprises entre 1 et 7 sont interdites car le checksum UDP-lite doit toujours couvrir l'en-tête. Une valeur supérieure à 8 indique qu'une partie des données sont protégées. Si la couverture est égale à la longueur du message on se retrouve dans un cas compatible avec UDP.

== SCTP ==

Le protocole SCTP (''Stream Control Transmission Protocol'') RFC 2960 est fortement lié au protocole IPv6. SCTP est un protocole de niveau 4 initialement conçu pour transporter des informations de signalisation. La fiabilité est donc un prérequis important et la gestion de la multi-domiciliation est prise en compte. L'idée est de permettre aux deux équipements terminaux d'échanger à l'initialisation de la connexion (appelée dans le standard association), l'ensemble de leurs adresses IPv4 et IPv6. Chaque équipement choisi une adresse privilégiée pour émettre les données vers l'autre extrémité et surveille périodiquement l'accessibilité des autres adresses. Si l'équipement n'est plus accessible par l'adresse principale, une adresse secondaire sera choisie.

SCTP permet une transition douce d'IPv4 vers IPv6 puisque l'application n'a plus à se préoccuper de la gestion des adresses. Si les deux entités possèdent une adresse IPv6, celle-ci sera privilégiée. De plus, SCTP peut servir de brique de base à la gestion de la multi-domiciliation IPv6. En effet, avec TCP une connexion est identifiée par ses adresses. Si une adresse n'est plus accessible, le fait d'en changer peut conduire à la coupure de la connexion. Il faut avoir recours à des superfuges, comme la mobilité IP pour maintenir la connexion. SCTP brise ce lien entre la localisation de l'équipement et l'identification des associations.

{{suivi|ICMPv6|ICMPv6|Découverte de voisins|Découverte de voisins}}

Protocoles de Niveau 4

2006-02-22T17:21:05Z

Emmanuel Berre: /* UDP et TCP */

{{suivi|ICMPv6|ICMPv6|Découverte de voisins|Découverte de voisins}}

== UDP et TCP ==

Les modifications apportées aux protocoles de niveau 4 UDP et TCP sont minimes. L'un des pré-requis à la mise en œuvre d'IPv6 était de laisser en l'état aussi bien TCP (''Transmission Control Protocol'') qu'UDP (''User Datagram Protocol''). Ces protocoles de transport sont utilisés par la très grande majorité des applications réseau et l'absence de modification facilitera grandement le passage de IPv4 à IPv6.

La principale modification à ces protocoles concerne le checksum. Comme il a été précisé [[Checksum au niveau transport]], il a été adapté au format de paquet IPv6 et englobe le pseudo-en-tête. De plus, pour UDP, le checksum qui était facultatif en IPv4, devient obligatoire.

Un autre changement au niveau des protocoles de niveau 4 concerne la prise en compte de l'option jumbogramme de l'extension [[Les extensions#PeP|proche-en-proche]]. Le RFC 2675 définit le comportement de UDP et de TCP quand les jumbogrammes sont utilisés. En effet, les en-têtes de ces messages contiennent eux aussi un champ longueur codé sur 16 bits et par conséquent insuffisant pour coder la longueur du jumbogramme :

* Pour le protocole UDP, si la longueur des données excède 65 535 octets, le champ longueur est mis à 0. Le récepteur détermine la longueur des données par la connaissance de la taille dans l'option jumbogramme.
* Le protocole TCP pose plus de problèmes. En effet, bien que les messages TCP ne contiennent pas de champ longueur, plusieurs compteurs sont codés sur 16 bits.
* Le champ longueur de la fenêtre de réception ne pose pas de problème depuis que le RFC 1323 a défini l'option TCP window scale qui donne le facteur multiplicatif qui doit être appliqué à ce champ.
* À l'ouverture de connexion, la taille maximale des segments (MSS) est négociée. Le RFC 2675 précise que si cette taille doit être supérieure à 65 535, la valeur 65 535 est envoyée et le récepteur prend en compte la longueur déterminée par l'algorithme de découverte du MTU.
* Pour l'envoi de données urgentes avec TCP, on utilise un bit spécifique de l'en-tête (bit URG) ainsi que le champ "pointeur urgent". Ce dernier sert à référencer la fin des données à traiter de manière particulière. Trois cas peuvent se présenter :
** Le premier, qui est identique à IPv4, est celui où le pointeur indique une position de moins de 65 535.
** Le second se produit lorsque le déplacement est supérieur à 65 535 et supérieur ou égal à la taille des données TCP envoyées. Cette fois-ci, on place la valeur 65 535 dans le champ "pointeur urgent" et on continue le traitement normal des paquets TCP.
** Le dernier cas intervient quand le pointeur indique un déplacement de plus de 65 535 qui est inférieur à la taille des données TCP. Un premier paquet est alors envoyé dans lequel on met la valeur 65 535 dans le champ "pointeur urgent". L'important est de choisir une taille de paquet de manière à ce que le déplacement dans le second paquet pour indiquer la fin des données urgentes soit inférieur à 65 535.

Il existe d'autres propositions pour faire évoluer TCP. Il faut remarquer que le travail n'est pas de même ampleur que pour IP. En effet, TCP est un protocole de bout-en-bout, la transition vers une nouvelle génération du protocole peut se faire par négociation entre les deux extrémités. Pour IP, tous les routeurs intermédiaires doivent prendre en compte les modifications.

== UDP-lite ==

UDP-lite permet de remonter aux couches supérieures des données erronées pendant leur transport. Si dans un environnement informatique, une erreur peut avoir des conséquences relativement grave quant à l'intégrité des données et il est normal de rejeter ces paquets, or, la plupart des décodeurs de flux multimédias sont capables de supporter un certains nombre d'erreurs binaires dans un flux de données. Pour améliorer la qualité perçue par l'utilisateur, il est donc préférable d'accepter des paquets erronés plutôt que de rejeter un bloc complet d'information.

En IPv4, l'utilisation du checksum UDP étant optionnelle (la valeur 0 indique que le checksum n'est pas calculé), UDP peut être utilisé pour transporter des flux multimédia. Avec IPv6, l'utilisation du checksum a été rendue obligatoire puisque le niveau 3 n'en possède pas. Pour éviter qu'un paquet comportant des erreurs ne puisse pas être remonté aux couche supérieures, le protocole UDP-lite a été défini RFC 3828. Les modifications sont minimes par rapport à UDP. Le format de la trame reste le même, seule la sémantique du champ longueur est changée. Avec UDP, ce champ est inutile puisqu'il est facilement déduit du champ longueur de l'en-tête IP. UDP-lite le transforme en champ couverture du checksum. Si la longueur est 0, UDP-lite considère que tout le checksum couvre tout le paquet. La valeur 8 indique que seul l'en-tête UDP est protégé par le checksum (ainsi qu'une partie de l'en-tête IP grâce au pseudo-header). Les valeurs comprises entre 1 et 7 sont interdites car le checksum UDP-lite doit toujours couvrir l'en-tête. Une valeur supérieure à 8 indique qu'une partie des données sont protégées. Si la couverture est égale à la longueur du message on se retrouve dans un cas compatible avec UDP.

== SCTP ==

Le protocole SCTP (''Stream Control Transmission Protocol'') RFC 2960 est fortement lié au protocole IPv6. SCTP est un protocole de niveau 4 initialement conçu pour transporter des informations de signalisation. La fiabilité est donc un prérequis important et la gestion de la multi-domiciliation est prise en compte. L'idée est de permettre aux deux équipements terminaux d'échanger à l'initialisation de la connexion (appelée dans le standard association), l'ensemble de leurs adresses IPv4 et IPv6. Chaque équipement choisi une adresse privilégiée pour émettre les données vers l'autre extrémité et surveille périodiquement l'accessibilité des autres adresses. Si l'équipement n'est plus accessible par l'adresse principale, une adresse secondaire sera choisie.

SCTP permet une transition douce d'IPv4 vers IPv6 puisque l'application n'a plus à se préoccuper de la gestion des adresses. Si les deux entités possèdent une adresse IPv6, celle-ci sera privilégiée. De plus, SCTP peut servir de brique de base à la gestion de la multi-domiciliation IPv6. En effet, avec TCP une connexion est identifiée par ses adresses. Si une adresse n'est plus accessible, le fait d'en changer peut conduire à la coupure de la connexion. Il faut avoir recours à des superfuges, comme la mobilité IP pour maintenir la connexion. SCTP brise ce lien entre la localisation de l'équipement et l'identification des associations.

{{suivi|ICMPv6|ICMPv6|Découverte de voisins|Découverte de voisins}}

Protocoles de Niveau 4

2006-02-22T17:18:40Z

Emmanuel Berre: /* UDP et TCP */

{{suivi|ICMPv6|ICMPv6|Découverte de voisins|Découverte de voisins}}

== UDP et TCP ==

Les modifications apportées aux protocoles de niveau 4 UDP et TCP sont minimes. L'un des pré-requis à la mise en œuvre d'IPv6 était de laisser en l'état aussi bien TCP (''Transmission Control Protocol'') qu'UDP (''User Datagram Protocol''). Ces protocoles de transport sont utilisés par la très grande majorité des applications réseau et l'absence de modification facilitera grandement le passage de IPv4 à IPv6.

La principale modification à ces protocoles concerne le checksum. Comme il a été précisé [[Checksum au niveau transport]], il a été adapté au format de paquet IPv6 et englobe le pseudo-en-tête. De plus, pour UDP, le checksum qui était facultatif en IPv4, devient obligatoire.

Un autre changement au niveau des protocoles de niveau 4 concerne la prise en compte de l'option jumbogramme de l'extension [[Les extensions#PeP|proche-en-proche]]. Le RFC 2675 définit le comportement de UDP et de TCP quand les jumbogrammes sont utilisés. En effet, les en-têtes de ces messages contiennent eux aussi un champ longueur codé sur 16 bits et par conséquent insuffisant pour coder la longueur du jumbogramme :

* Pour le protocole UDP, si la longueur des données excède 65 535 octets, le champ longueur est mis à 0. Le récepteur détermine la longueur des données par la connaissance de la taille dans l'option jumbogramme.
* Le protocole TCP pose plus de problèmes. En effet, bien que les messages TCP ne contiennent pas de champ longueur, plusieurs compteurs sont codés sur 16 bits.
* Le champ longueur de la fenêtre de réception ne pose pas de problème depuis que le RFC 1323 a défini l'option TCP window scale qui donne le facteur multiplicatif qui doit être appliqué à ce champ.
* À l'ouverture de connexion, la taille maximale des segments (MSS) est négociée. Le RFC 2675 précise que si cette taille doit être supérieure à 65 535, la valeur 65 535 est envoyée et le récepteur prend en compte la longueur déterminée par l'algorithme de découverte du MTU.
* Pour l'envoi de données urgentes avec TCP, on utilise un bit spécifique de l'en-tête (bit URG) ainsi que le champ "pointeur urgent". Ce dernier sert à référencer la fin des données à traiter de manière particulière. Trois cas peuvent se présenter :
* Le premier, qui est identique à IPv4, est celui où le pointeur indique une position de moins de 65 535.
* Le second se produit lorsque le déplacement est supérieur à 65 535 et supérieur ou égal à la taille des données TCP envoyées. Cette fois-ci, on place la valeur 65 535 dans le champ "pointeur urgent" et on continue le traitement normal des paquets TCP.
* Le dernier cas intervient quand le pointeur indique un déplacement de plus de 65 535 qui est inférieur à la taille des données TCP. Un premier paquet est alors envoyé dans lequel on met la valeur 65 535 dans le champ "pointeur urgent". L'important est de choisir une taille de paquet de manière à ce que le déplacement dans le second paquet pour indiquer la fin des données urgentes soit inférieur à 65 535.

Il existe d'autres propositions pour faire évoluer TCP. Il faut remarquer que le travail n'est pas de même ampleur que pour IP. En effet, TCP est un protocole de bout-en-bout, la transition vers une nouvelle génération du protocole peut se faire par négociation entre les deux extrémités. Pour IP, tous les routeurs intermédiaires doivent prendre en compte les modifications.

== UDP-lite ==

UDP-lite permet de remonter aux couches supérieures des données erronées pendant leur transport. Si dans un environnement informatique, une erreur peut avoir des conséquences relativement grave quant à l'intégrité des données et il est normal de rejeter ces paquets, or, la plupart des décodeurs de flux multimédias sont capables de supporter un certains nombre d'erreurs binaires dans un flux de données. Pour améliorer la qualité perçue par l'utilisateur, il est donc préférable d'accepter des paquets erronés plutôt que de rejeter un bloc complet d'information.

En IPv4, l'utilisation du checksum UDP étant optionnelle (la valeur 0 indique que le checksum n'est pas calculé), UDP peut être utilisé pour transporter des flux multimédia. Avec IPv6, l'utilisation du checksum a été rendue obligatoire puisque le niveau 3 n'en possède pas. Pour éviter qu'un paquet comportant des erreurs ne puisse pas être remonté aux couche supérieures, le protocole UDP-lite a été défini RFC 3828. Les modifications sont minimes par rapport à UDP. Le format de la trame reste le même, seule la sémantique du champ longueur est changée. Avec UDP, ce champ est inutile puisqu'il est facilement déduit du champ longueur de l'en-tête IP. UDP-lite le transforme en champ couverture du checksum. Si la longueur est 0, UDP-lite considère que tout le checksum couvre tout le paquet. La valeur 8 indique que seul l'en-tête UDP est protégé par le checksum (ainsi qu'une partie de l'en-tête IP grâce au pseudo-header). Les valeurs comprises entre 1 et 7 sont interdites car le checksum UDP-lite doit toujours couvrir l'en-tête. Une valeur supérieure à 8 indique qu'une partie des données sont protégées. Si la couverture est égale à la longueur du message on se retrouve dans un cas compatible avec UDP.

== SCTP ==

Le protocole SCTP (''Stream Control Transmission Protocol'') RFC 2960 est fortement lié au protocole IPv6. SCTP est un protocole de niveau 4 initialement conçu pour transporter des informations de signalisation. La fiabilité est donc un prérequis important et la gestion de la multi-domiciliation est prise en compte. L'idée est de permettre aux deux équipements terminaux d'échanger à l'initialisation de la connexion (appelée dans le standard association), l'ensemble de leurs adresses IPv4 et IPv6. Chaque équipement choisi une adresse privilégiée pour émettre les données vers l'autre extrémité et surveille périodiquement l'accessibilité des autres adresses. Si l'équipement n'est plus accessible par l'adresse principale, une adresse secondaire sera choisie.

SCTP permet une transition douce d'IPv4 vers IPv6 puisque l'application n'a plus à se préoccuper de la gestion des adresses. Si les deux entités possèdent une adresse IPv6, celle-ci sera privilégiée. De plus, SCTP peut servir de brique de base à la gestion de la multi-domiciliation IPv6. En effet, avec TCP une connexion est identifiée par ses adresses. Si une adresse n'est plus accessible, le fait d'en changer peut conduire à la coupure de la connexion. Il faut avoir recours à des superfuges, comme la mobilité IP pour maintenir la connexion. SCTP brise ce lien entre la localisation de l'équipement et l'identification des associations.

{{suivi|ICMPv6|ICMPv6|Découverte de voisins|Découverte de voisins}}

ICMPv6

2006-02-22T17:13:50Z

Emmanuel Berre: /* <div id="grand">Paquet trop grand</div> */

__NOTOC__
{{suivi|Checksum au niveau transport|Checksum au niveau transport|Protocoles de Niveau 4|Protocoles de Niveau 4}}

Le protocole de contrôle d'IP a été revu. Dans IPv4, ICMP (Internet Message Control Protocol) sert à la détection d'erreurs (par exemple : équipement inaccessible, durée de vie expirée,...), au test (par exemple ping), à la configuration automatique des équipements (redirection ICMP, découverte des routeurs). Ces trois fonctions ont été mieux définies dans IPv6. De plus ICMPv6 (RFC 2463) intègre les fonctions de gestion des groupes de multicast (MLD : Multicast Listener Discovery) qui sont effectuées par le protocole IGMP (Internet Group Message Protocol) dans IPv4. ICMPv6 reprend aussi les fonctions du protocole ARP utilisé par IPv4.

Le protocole se voit attribuer le numéro 58. Le format générique des paquets ICMPv6 est donné See Format générique d'un message ICMP :

[[image:CS38.gif]]

* Le champ <tt>type</tt> (voir tableau Valeurs des champs type et code d'ICMPv6) code la nature du message ICMPv6. Contrairement à IPv4 où la numérotation ne suivait aucune logique, les valeurs inférieures à 127 sont réservées aux messages d'erreur. Les autres valeurs réservées aux messages d'information, parmi lesquels se trouvent ceux utilisés par le protocole [[Découverte de voisins|découverte des voisins]] (''neighbor discovery'') pour la configuration automatique des équipements.
* Le champ <tt>code</tt> précise la cause du message ICMPv6.
* Le champ <tt>checksum</tt> permet de vérifier l'intégrité du paquet ICMP. Ce champ est calculé avec le pseudo-en-tête décrit au chapitre [[Checksum au niveau transport]].

Les messages ICMPv6 de compte rendu d'erreur contiennent dans la partie données le paquet IPv6 ayant provoqué l'erreur. Pour éviter des problèmes de fragmentation puisqu'il est difficilement envisageable de mettre en œuvre la découverte du MTU, la longueur du message ICMPv6 est limitée à 1 280 octets et par conséquent le contenu du paquet IPv6 peut être tronqué.

{{Tableau ICMPv6}}

== <div id="inaccessible">Destination inaccessible</div> ==

Ce message est émis par un routeur intermédiaire quand le paquet ne peut pas être transmis parce que soit :

[[image:CS39.gif]]

* le routeur ne trouve pas dans ses tables la route vers la destination (code = 0) ;
* le franchissement d'un équipement de type firewall est interdit ("raison administrative", code = 1) ;
* l'adresse destination ne peut être atteinte avec l'adresse source fournie, par exemple si le message est adressé à un destinataire hors du lien, l'adresse source ne doit pas être une adresse lien-local (code = 2) ;
* toute autre raison comme par exemple la tentative de routage d'une adresse locale au lien (code = 3) ;
* le destinataire peut aussi émettre un message ICMPv6 de ce type quand le port destination contenu dans le paquet n'est pas affecté à une application (code = 4).

== <div id="grand">Paquet trop grand</div> ==

[[image:CS40.gif]]

Ce message ICMPv6 est utilisé par le protocole de découverte du MTU pour trouver la taille optimale des paquets IPv6 afin qu'ils puissent traverser les routeurs. Ce message contient la taille du MTU acceptée par le routeur pour que la source puisse efficacement adapter la taille des données. Ce champ manquait cruellement dans les spécifications initiales de IPv4, ce qui compliquait la découverte de la taille maximale des paquets utilisables sur l'ensemble du chemin (cf. [[découverte du PMTU]] (RFC 1981)). Pour IPv4, le RFC 1191 proposait déjà une modification du comportement des routeurs pour y inclure cette information.

== <div id="depasse">Temps dépassé</div> ==

[[image:CS41.gif]]

Ce message indique que le paquet a été rejeté par le routeur :

* soit parce que le champ nombre de sauts a atteint 0 (code = 0) ;
* soit qu'un fragment s'est perdu et le temps alloué au réassemblage a été dépassé (code = 1).

Ce message sert aussi à la commande traceroute pour déterminer le chemin pris par les paquets.

== <div id="parametre">Erreur de paramètre</div> ==

[[image:CS42.gif]]

Ce message est émis par un nœud ayant détecté une erreur de syntaxe dans l'en-tête du paquet IP ou des extensions. Le champ code révèle la cause de l'erreur :

* la syntaxe de l'en-tête n'est pas correcte (code = 0) ;
* le numéro en-tête suivant n'est pas reconnu (code = 1) ;
* une option de l'extension (par exemple [[Les extensions#PeP|proche-en-proche]] ou [[Les extensions#dest|destination]]) n'est pas reconnue et le codage des deux bits de poids fort oblige à rejeter le paquet (code = 2).

Le champ pointeur indique l'octet où l'erreur est survenue dans le paquet retourné.

== <div id="echo">Demande et réponse d'écho</div> ==

[[image:CS43.gif]]

Ces deux messages servent en particulier à la commande ping permettant de tester l'accessibilité d'une machine. Le principe de fonctionnement est le même que pour IPv4, une requête (type 128) est envoyée vers l'équipement dont on veut tester le fonctionnement, celui-ci répond par le message réponse d'écho (type 129). Le champ identificateur permet de distinguer les réponses dans le cas où plusieurs commandes ping seraient lancées simultanément sur la machine. Le champ numéro de séquence permet d'associer la réponse à une requête pour mesurer le temps d'aller et retour dans le cas où les demandes sont émises en continu et que le délai de propagation est élevé. Le champ données permet d'augmenter la taille du message pour les mesures.

Le chapitre sur l'API, [[mini-ping]], donne un exemple de programmation utilisant ces messages ICMPv6.

{{suivi|Checksum au niveau transport|Checksum au niveau transport|Protocoles de Niveau 4|Protocoles de Niveau 4}}

ICMPv6

2006-02-22T17:12:38Z

Emmanuel Berre: /* <div id="inaccessible">Destination inaccessible</div> */

__NOTOC__
{{suivi|Checksum au niveau transport|Checksum au niveau transport|Protocoles de Niveau 4|Protocoles de Niveau 4}}

Le protocole de contrôle d'IP a été revu. Dans IPv4, ICMP (Internet Message Control Protocol) sert à la détection d'erreurs (par exemple : équipement inaccessible, durée de vie expirée,...), au test (par exemple ping), à la configuration automatique des équipements (redirection ICMP, découverte des routeurs). Ces trois fonctions ont été mieux définies dans IPv6. De plus ICMPv6 (RFC 2463) intègre les fonctions de gestion des groupes de multicast (MLD : Multicast Listener Discovery) qui sont effectuées par le protocole IGMP (Internet Group Message Protocol) dans IPv4. ICMPv6 reprend aussi les fonctions du protocole ARP utilisé par IPv4.

Le protocole se voit attribuer le numéro 58. Le format générique des paquets ICMPv6 est donné See Format générique d'un message ICMP :

[[image:CS38.gif]]

* Le champ <tt>type</tt> (voir tableau Valeurs des champs type et code d'ICMPv6) code la nature du message ICMPv6. Contrairement à IPv4 où la numérotation ne suivait aucune logique, les valeurs inférieures à 127 sont réservées aux messages d'erreur. Les autres valeurs réservées aux messages d'information, parmi lesquels se trouvent ceux utilisés par le protocole [[Découverte de voisins|découverte des voisins]] (''neighbor discovery'') pour la configuration automatique des équipements.
* Le champ <tt>code</tt> précise la cause du message ICMPv6.
* Le champ <tt>checksum</tt> permet de vérifier l'intégrité du paquet ICMP. Ce champ est calculé avec le pseudo-en-tête décrit au chapitre [[Checksum au niveau transport]].

Les messages ICMPv6 de compte rendu d'erreur contiennent dans la partie données le paquet IPv6 ayant provoqué l'erreur. Pour éviter des problèmes de fragmentation puisqu'il est difficilement envisageable de mettre en œuvre la découverte du MTU, la longueur du message ICMPv6 est limitée à 1 280 octets et par conséquent le contenu du paquet IPv6 peut être tronqué.

{{Tableau ICMPv6}}

== <div id="inaccessible">Destination inaccessible</div> ==

Ce message est émis par un routeur intermédiaire quand le paquet ne peut pas être transmis parce que soit :

[[image:CS39.gif]]

* le routeur ne trouve pas dans ses tables la route vers la destination (code = 0) ;
* le franchissement d'un équipement de type firewall est interdit ("raison administrative", code = 1) ;
* l'adresse destination ne peut être atteinte avec l'adresse source fournie, par exemple si le message est adressé à un destinataire hors du lien, l'adresse source ne doit pas être une adresse lien-local (code = 2) ;
* toute autre raison comme par exemple la tentative de routage d'une adresse locale au lien (code = 3) ;
* le destinataire peut aussi émettre un message ICMPv6 de ce type quand le port destination contenu dans le paquet n'est pas affecté à une application (code = 4).

== <div id="grand">Paquet trop grand</div> ==

[[image:CS40.gif]]

Ce message ICMPv6 est utilisé par le protocole de découverte du MTU pour trouver la taille optimale des paquets IPv6 pour qu'ils puissent traverser les routeurs. Ce message contient la taille du MTU acceptée par le routeur pour que la source puisse efficacement adapter la taille des données. Ce champ manquait cruellement dans les spécifications initiales de IPv4, ce qui compliquait la découverte de la taille maximale des paquets utilisables sur l'ensemble du chemin (cf. [[découverte du PMTU]] (RFC 1981)). Pour IPv4, le RFC 1191 proposait déjà une modification du comportement des routeurs pour y inclure cette information.

== <div id="depasse">Temps dépassé</div> ==

[[image:CS41.gif]]

Ce message indique que le paquet a été rejeté par le routeur :

* soit parce que le champ nombre de sauts a atteint 0 (code = 0) ;
* soit qu'un fragment s'est perdu et le temps alloué au réassemblage a été dépassé (code = 1).

Ce message sert aussi à la commande traceroute pour déterminer le chemin pris par les paquets.

== <div id="parametre">Erreur de paramètre</div> ==

[[image:CS42.gif]]

Ce message est émis par un nœud ayant détecté une erreur de syntaxe dans l'en-tête du paquet IP ou des extensions. Le champ code révèle la cause de l'erreur :

* la syntaxe de l'en-tête n'est pas correcte (code = 0) ;
* le numéro en-tête suivant n'est pas reconnu (code = 1) ;
* une option de l'extension (par exemple [[Les extensions#PeP|proche-en-proche]] ou [[Les extensions#dest|destination]]) n'est pas reconnue et le codage des deux bits de poids fort oblige à rejeter le paquet (code = 2).

Le champ pointeur indique l'octet où l'erreur est survenue dans le paquet retourné.

== <div id="echo">Demande et réponse d'écho</div> ==

[[image:CS43.gif]]

Ces deux messages servent en particulier à la commande ping permettant de tester l'accessibilité d'une machine. Le principe de fonctionnement est le même que pour IPv4, une requête (type 128) est envoyée vers l'équipement dont on veut tester le fonctionnement, celui-ci répond par le message réponse d'écho (type 129). Le champ identificateur permet de distinguer les réponses dans le cas où plusieurs commandes ping seraient lancées simultanément sur la machine. Le champ numéro de séquence permet d'associer la réponse à une requête pour mesurer le temps d'aller et retour dans le cas où les demandes sont émises en continu et que le délai de propagation est élevé. Le champ données permet d'augmenter la taille du message pour les mesures.

Le chapitre sur l'API, [[mini-ping]], donne un exemple de programmation utilisant ces messages ICMPv6.

{{suivi|Checksum au niveau transport|Checksum au niveau transport|Protocoles de Niveau 4|Protocoles de Niveau 4}}

Template:Tableau ICMPv6

2006-02-22T17:10:47Z

Emmanuel Berre:

{|
|+ Valeurs des champs type et code d'ICMPv6
!type !! code !! nature
|-style="background:silver"
!colspan=3|Gestion des erreurs
|-
|1 || || [[#inaccessible|Destination inaccessible]] :
|-style="background:silver"
| || 0 ||* aucune route vers la destination
|-
| || 1 ||* la communication avec la destination est administrativement interdite
|-style="background:silver"
| || 2 ||* hors portée de l'adresse source
|-
| || 3 ||* l'adresse est inaccessible
|-style="background:silver"
| || 4 ||* le numéro de port est inaccessible
|-
| 2 || || <div id="2">[[#grand|Paquet trop grand]]</div>
|-style="background:silver"
|3 || || [[#depasse|Temps dépassé]] :
|-
| || 0 ||* limite du nombre de sauts atteinte
|-style="background:silver"
| || 1 ||* temps de réassemblage dépassé
|-
|4 || || [[#parametre|Erreur de paramètre]] :
|-style="background:silver"
| || 0 ||* champ d'en-tête erroné
|-
| || 1 ||* champ d'en-tête suivant non reconnu
|-style="background:silver"
| || 2 ||* option non reconnue
|-
! colspan=3|Information
|-style="background:silver"
|128 || || [[#echo|Demande d'écho]]
|-
|129 || || [[#echo|Réponse d'écho]]
|-style="background:silver"
!colspan=3 |Gestion des groupes multicast ([[Le multicast IPv6 sur le lien-local|MLD]], RFC 2710)
|-
|130 || || Requête d'abonnement
|-style="background:silver"
|131 || || Rapport d'abonnement
|-
|132 || || Fin d'abonnement
|-style="background:silver"
!colspan=3 | [[Découverte de voisins]] (RFC 2461)
|-
|133 || || Sollicitation du routeur
|-style="background:silver"
|134 || || Annonce du routeur
|-
|135 || || Sollicitation d'un voisin
|-style="background:silver"
|136 || || Annonce d'un voisin
|-
|137 || || Redirection
|-style="background:silver"
!colspan=3 | Renumérotation des routeurs (expérimental, RFC 2894)
|-
|138 || || <div id="138">Renumérotation des routeurs :</div>
|-style="background:silver"
| || 0 ||* Commande
|-
| || 1 ||* Résultat
|-style="background:silver"
| || 255 ||* Remise à zéro du numéro de séquence
|-
!colspan=3 | Recherche d'information sur un noeud (expérimental)
|-style="background:silver"
|139 || || Demande d'information
|-
|140 || || Réponse
|-style="background:silver"
! colspan=3| Découverte de voisins inverse (RFC 3122)
|-
|141 || || Sollicitation
|-style="background:silver"
|142 || || Annonce
|-
!colspan=3 | Gestion des groupes multicast (MLDv2, RFC 3810)
|-style="background:silver"
|143 || || Rapport d'abonnement MLDv2
|-
!colspan=3 | Mobilité (RFC 3775)
|-style="background:silver"
|144 || || Découverte d'agent mère (requête)
|-
|145 || ||Découverte d'agent mère (réponse)
|-style="background:silver"
|146 || ||Sollicitation de préfixe mobile
|-
|147 || || Annonce de préfixe mobile
|-style="background:silver"
!colspan=3 | Découverte de voisins sécurisée (SEND, RFC 3971)
|-
|148 || || Sollicitation de chemin de certification
|-style="background:silver"
|149 || ||Annonce de chemin de certification
|-
! colspan=3 | Mobilité (expérimental)
|-style="background:silver"
|150 || || Protocoles de mobilité expérimentaux, tels que Seamoby
|}

Template:Tableau ICMPv6

2006-02-22T17:10:24Z

Emmanuel Berre:

{|
|+ Valeurs des champs type et code d'ICMPv6
!type !! code !! nature
|-style="background:silver"
!colspan=3|Gestion des erreurs
|-
|1 || || [[#inaccessible|Destination inaccessible]] :
|-style="background:silver"
| || 0 ||* aucune route vers la destination
|-
| || 1 ||* la communication avec la destination est administrativement interdite
|-style="background:silver"
| || 2 ||* hors portée de l'adresse source
|-
| || 3 ||* l'adresse est inaccessible
|-style="background:silver"
| || 4 ||* le numéro de port est inaccessible
|-
| 2 || || <div id="2">[[#grand|Paquet trop grand]]</div>
|-style="background:silver"
|3 || || [[#depasse|Temps dépassé]] :
|-
| || 0 ||* limite du nombre de sauts atteinte
|-style="background:silver"
| || 1 ||* temps de réassemblage dépassé
|-
|4 || || [[#parametre|Erreur de paramètre]] :
|-style="background:silver"
| || 0 ||* champ d'en-tête erroné
|-
| || 1 ||* champ d'en-tête suivant non reconnu
|-style="background:silver"
| || 2 ||* option non reconnue
|-
! colspan=3|Information
|-style="background:silver"
|128 || || [[#echo|Demande d'écho]]
|-
|129 || || [[#echo|Réponse d'écho]]
|-style="background:silver"
!colspan=3 |Gestion des groupes multicast ([[Le multicast IPv6 sur le lien-local|MLD]], RFC 2710)
|-
|130 || || Requête d'abonnement
|-style="background:silver"
|131 || || Rapport d'abonnement
|-
|132 || || Fin d'abonnement
|-style="background:silver"
!colspan=3 | [[Découverte de voisins]] (RFC 2461)
|-
|133 || || Sollicitation du routeur
|-style="background:silver"
|134 || || Annonce du routeur
|-
|135 || || Sollicitation d'un voisin
|-style="background:silver"
|136 || || Annonce d'un voisin
|-
|137 || || Redirection
|-style="background:silver"
!colspan=3 | Renumérotation des routeurs (expérimental, RFC 2894)
|-
|138 || || <div id="138">Renumérotation des routeurs :</div>
|-style="background:silver"
| || 0 ||* commande
|-
| || 1 ||* résultat
|-style="background:silver"
| || 255 ||* remise à zéro du numéro de séquence
|-
!colspan=3 | Recherche d'information sur un noeud (expérimental)
|-style="background:silver"
|139 || || Demande d'information
|-
|140 || || Réponse
|-style="background:silver"
! colspan=3| Découverte de voisins inverse (RFC 3122)
|-
|141 || || Sollicitation
|-style="background:silver"
|142 || || Annonce
|-
!colspan=3 | Gestion des groupes multicast (MLDv2, RFC 3810)
|-style="background:silver"
|143 || || Rapport d'abonnement MLDv2
|-
!colspan=3 | Mobilité (RFC 3775)
|-style="background:silver"
|144 || || Découverte d'agent mère (requête)
|-
|145 || ||Découverte d'agent mère (réponse)
|-style="background:silver"
|146 || ||Sollicitation de préfixe mobile
|-
|147 || || Annonce de préfixe mobile
|-style="background:silver"
!colspan=3 | Découverte de voisins sécurisée (SEND, RFC 3971)
|-
|148 || || Sollicitation de chemin de certification
|-style="background:silver"
|149 || ||Annonce de chemin de certification
|-
! colspan=3 | Mobilité (expérimental)
|-style="background:silver"
|150 || || Protocoles de mobilité expérimentaux, tels que Seamoby
|}

ICMPv6

2006-02-22T17:07:27Z

Emmanuel Berre:

__NOTOC__
{{suivi|Checksum au niveau transport|Checksum au niveau transport|Protocoles de Niveau 4|Protocoles de Niveau 4}}

Le protocole de contrôle d'IP a été revu. Dans IPv4, ICMP (Internet Message Control Protocol) sert à la détection d'erreurs (par exemple : équipement inaccessible, durée de vie expirée,...), au test (par exemple ping), à la configuration automatique des équipements (redirection ICMP, découverte des routeurs). Ces trois fonctions ont été mieux définies dans IPv6. De plus ICMPv6 (RFC 2463) intègre les fonctions de gestion des groupes de multicast (MLD : Multicast Listener Discovery) qui sont effectuées par le protocole IGMP (Internet Group Message Protocol) dans IPv4. ICMPv6 reprend aussi les fonctions du protocole ARP utilisé par IPv4.

Le protocole se voit attribuer le numéro 58. Le format générique des paquets ICMPv6 est donné See Format générique d'un message ICMP :

[[image:CS38.gif]]

* Le champ <tt>type</tt> (voir tableau Valeurs des champs type et code d'ICMPv6) code la nature du message ICMPv6. Contrairement à IPv4 où la numérotation ne suivait aucune logique, les valeurs inférieures à 127 sont réservées aux messages d'erreur. Les autres valeurs réservées aux messages d'information, parmi lesquels se trouvent ceux utilisés par le protocole [[Découverte de voisins|découverte des voisins]] (''neighbor discovery'') pour la configuration automatique des équipements.
* Le champ <tt>code</tt> précise la cause du message ICMPv6.
* Le champ <tt>checksum</tt> permet de vérifier l'intégrité du paquet ICMP. Ce champ est calculé avec le pseudo-en-tête décrit au chapitre [[Checksum au niveau transport]].

Les messages ICMPv6 de compte rendu d'erreur contiennent dans la partie données le paquet IPv6 ayant provoqué l'erreur. Pour éviter des problèmes de fragmentation puisqu'il est difficilement envisageable de mettre en œuvre la découverte du MTU, la longueur du message ICMPv6 est limitée à 1 280 octets et par conséquent le contenu du paquet IPv6 peut être tronqué.

{{Tableau ICMPv6}}

== <div id="inaccessible">Destination inaccessible</div> ==

Ce message est émis par un routeur intermédiaire quand le paquet ne peut pas être transmis parce que soit :

[[image:CS39.gif]]

* le routeur ne trouve pas dans ses tables la route vers la destination (code = 0) ;
* le franchissement d'un équipement de type firewall est interdit ("raison administrative", code = 1) ;
* l'adresse destination ne peut être atteinte avec l'adresse source fournie, par exemple si le message est adressé à un destinataire hors du lien, l'adresse source ne doit pas être une adresse lien-local (code = 2) ;
* toute autre raison comme par exemple la tentative de router une adresse locale au lien (code = 3) ;
* le destinataire peut aussi émettre un message ICMPv6 de ce type quand le port destination contenu dans le paquet n'est pas affecté à une application (code = 4).

== <div id="grand">Paquet trop grand</div> ==

[[image:CS40.gif]]

Ce message ICMPv6 est utilisé par le protocole de découverte du MTU pour trouver la taille optimale des paquets IPv6 pour qu'ils puissent traverser les routeurs. Ce message contient la taille du MTU acceptée par le routeur pour que la source puisse efficacement adapter la taille des données. Ce champ manquait cruellement dans les spécifications initiales de IPv4, ce qui compliquait la découverte de la taille maximale des paquets utilisables sur l'ensemble du chemin (cf. [[découverte du PMTU]] (RFC 1981)). Pour IPv4, le RFC 1191 proposait déjà une modification du comportement des routeurs pour y inclure cette information.

== <div id="depasse">Temps dépassé</div> ==

[[image:CS41.gif]]

Ce message indique que le paquet a été rejeté par le routeur :

* soit parce que le champ nombre de sauts a atteint 0 (code = 0) ;
* soit qu'un fragment s'est perdu et le temps alloué au réassemblage a été dépassé (code = 1).

Ce message sert aussi à la commande traceroute pour déterminer le chemin pris par les paquets.

== <div id="parametre">Erreur de paramètre</div> ==

[[image:CS42.gif]]

Ce message est émis par un nœud ayant détecté une erreur de syntaxe dans l'en-tête du paquet IP ou des extensions. Le champ code révèle la cause de l'erreur :

* la syntaxe de l'en-tête n'est pas correcte (code = 0) ;
* le numéro en-tête suivant n'est pas reconnu (code = 1) ;
* une option de l'extension (par exemple [[Les extensions#PeP|proche-en-proche]] ou [[Les extensions#dest|destination]]) n'est pas reconnue et le codage des deux bits de poids fort oblige à rejeter le paquet (code = 2).

Le champ pointeur indique l'octet où l'erreur est survenue dans le paquet retourné.

== <div id="echo">Demande et réponse d'écho</div> ==

[[image:CS43.gif]]

Ces deux messages servent en particulier à la commande ping permettant de tester l'accessibilité d'une machine. Le principe de fonctionnement est le même que pour IPv4, une requête (type 128) est envoyée vers l'équipement dont on veut tester le fonctionnement, celui-ci répond par le message réponse d'écho (type 129). Le champ identificateur permet de distinguer les réponses dans le cas où plusieurs commandes ping seraient lancées simultanément sur la machine. Le champ numéro de séquence permet d'associer la réponse à une requête pour mesurer le temps d'aller et retour dans le cas où les demandes sont émises en continu et que le délai de propagation est élevé. Le champ données permet d'augmenter la taille du message pour les mesures.

Le chapitre sur l'API, [[mini-ping]], donne un exemple de programmation utilisant ces messages ICMPv6.

{{suivi|Checksum au niveau transport|Checksum au niveau transport|Protocoles de Niveau 4|Protocoles de Niveau 4}}

ICMPv6

2006-02-22T16:49:16Z

Emmanuel Berre:

__NOTOC__
{{suivi|Checksum au niveau transport|Checksum au niveau transport|Protocoles de Niveau 4|Protocoles de Niveau 4}}

Le protocole de contrôle d'IP a été revu. Dans IPv4, ICMP (Internet Message Control Protocol) sert à la détection d'erreurs (par exemple : équipement inaccessible, durée de vie expirée,...), au test (par exemple ping), à la configuration automatique des équipements (redirection ICMP, découverte des routeurs). Ces trois fonctions ont été mieux définies dans IPv6. De plus ICMPv6 (RFC 2463) intègre les fonctions de gestion des groupes de multicast (MLD : Multicast Listener Discovery) qui sont effectuées par le protocole IGMP (Internet Group Message Protocol) dans IPv4. ICMPv6 reprend aussi les fonctions du protocole ARP utilisé par IPv4.

Le protocole se voit attribuer le numéro 58. Le format générique des paquets ICMPv6 est donné See Format générique d'un message ICMP :

[[image:CS38.gif]]

* Le champ type (voir tableau Valeurs des champs type et code d'ICMPv6) code la nature du message ICMPv6. Contrairement à IPv4 où la numérotation ne suivait aucune logique, les valeurs inférieures à 127 sont réservées aux messages d'erreur. Les autres valeurs réservées aux messages d'information, parmi lesquels se trouvent ceux utilisés par le protocole [[Découverte de voisins|découverte des voisins]] (''neighbor discovery'') pour la configuration automatique des équipements.
* Le champ code précise la cause du message ICMPv6.
* Le champ checksum permet de vérifier l'intégrité du paquet ICMP. Ce champ est calculé avec le pseudo-en-tête décrit au chapitre [[Checksum au niveau transport]].

Les messages ICMPv6 de compte rendu d'erreur contiennent dans la partie données le paquet IPv6 ayant provoqué l'erreur. Pour éviter des problèmes de fragmentation puisqu'il est difficilement envisageable de mettre en œuvre la découverte du MTU, la longueur du message ICMPv6 est limitée à 1 280 octets et par conséquent le contenu du paquet IPv6 peut être tronqué.

{{Tableau ICMPv6}}

== <div id="inaccessible">Destination inaccessible</div> ==

Ce message est émis par un routeur intermédiaire quand le paquet ne peut pas être transmis parce que soit :

[[image:CS39.gif]]

* le routeur ne trouve pas dans ses tables la route vers la destination (code = 0) ;
* le franchissement d'un équipement de type firewall est interdit ("raison administrative", code = 1) ;
* l'adresse destination ne peut être atteinte avec l'adresse source fournie, par exemple si le message est adressé à un destinataire hors du lien, l'adresse source ne doit pas être une adresse lien-local (code = 2) ;
* toute autre raison comme par exemple la tentative de router une adresse locale au lien (code = 3) ;
* le destinataire peut aussi émettre un message ICMPv6 de ce type quand le port destination contenu dans le paquet n'est pas affecté à une application (code = 4).

== <div id="grand">Paquet trop grand</div> ==

[[image:CS40.gif]]

Ce message ICMPv6 est utilisé par le protocole de découverte du MTU pour trouver la taille optimale des paquets IPv6 pour qu'ils puissent traverser les routeurs. Ce message contient la taille du MTU acceptée par le routeur pour que la source puisse efficacement adapter la taille des données. Ce champ manquait cruellement dans les spécifications initiales de IPv4, ce qui compliquait la découverte de la taille maximale des paquets utilisables sur l'ensemble du chemin (cf. [[découverte du PMTU]] (RFC 1981)). Pour IPv4, le RFC 1191 proposait déjà une modification du comportement des routeurs pour y inclure cette information.

== <div id="depasse">Temps dépassé</div> ==

[[image:CS41.gif]]

Ce message indique que le paquet a été rejeté par le routeur :

* soit parce que le champ nombre de sauts a atteint 0 (code = 0) ;
* soit qu'un fragment s'est perdu et le temps alloué au réassemblage a été dépassé (code = 1).

Ce message sert aussi à la commande traceroute pour déterminer le chemin pris par les paquets.

== <div id="parametre">Erreur de paramètre</div> ==

[[image:CS42.gif]]

Ce message est émis par un nœud ayant détecté une erreur de syntaxe dans l'en-tête du paquet IP ou des extensions. Le champ code révèle la cause de l'erreur :

* la syntaxe de l'en-tête n'est pas correcte (code = 0) ;
* le numéro en-tête suivant n'est pas reconnu (code = 1) ;
* une option de l'extension (par exemple [[Les extensions#PeP|proche-en-proche]] ou [[Les extensions#dest|destination]]) n'est pas reconnue et le codage des deux bits de poids fort oblige à rejeter le paquet (code = 2).

Le champ pointeur indique l'octet où l'erreur est survenue dans le paquet retourné.

== <div id="echo">Demande et réponse d'écho</div> ==

[[image:CS43.gif]]

Ces deux messages servent en particulier à la commande ping permettant de tester l'accessibilité d'une machine. Le principe de fonctionnement est le même que pour IPv4, une requête (type 128) est envoyée vers l'équipement dont on veut tester le fonctionnement, celui-ci répond par le message réponse d'écho (type 129). Le champ identificateur permet de distinguer les réponses dans le cas où plusieurs commandes ping seraient lancées simultanément sur la machine. Le champ numéro de séquence permet d'associer la réponse à une requête pour mesurer le temps d'aller et retour dans le cas où les demandes sont émises en continu et que le délai de propagation est élevé. Le champ données permet d'augmenter la taille du message pour les mesures.

Le chapitre sur l'API, [[mini-ping]], donne un exemple de programmation utilisant ces messages ICMPv6.

{{suivi|Checksum au niveau transport|Checksum au niveau transport|Protocoles de Niveau 4|Protocoles de Niveau 4}}

Talk:Adressage

2006-02-21T12:41:42Z

Emmanuel Berre: IPv6 Address Prefix Reserved for Documentation

Il serait intéressant de se baser sur le RFC 3849 ''IPv6 Address Prefix Reserved for Documentation''.

Afin d'harmoniser les documents et d'éviter de diffuser des adresses d'équipements inutilement, il pourrait être intéressant de reprendre les divers exemples du livre et d'utiliser le préfixe 2001:DB8::/32 réservé pour la documentation.

Pur les adresses multicast, se baser sur le RFC 3306 ''Unicast-Prefix-based IPv6 Multicast Addresses''.

Talk:Site-local

2006-02-21T11:03:31Z

Emmanuel Berre:

Talk:Site-local

2006-02-21T11:02:00Z

Emmanuel Berre: Request for comments

Changement de la section Unique Local Address. Remplacement du draft draft-ietf-ipv6-ula-central-01.txt par le RFC 4193.
Suppression nécessaire de l'entrée de la bilbio [HH-id].

Les adresses de type site-local étant supprimées du standard IPv6 [RFC 3879], le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local Address''). Ces adresses sont destinées à une utilisation locale. Elles ne sont pas définies pour être routées dans l'Internet, mais seulement au sein d'une zone limitée telle qu'un site ou entre un nombre limité de sites. Les adresses uniques locales ont les caractéristiques suivantes :

* Prefixe ''globalement'' unique.
* Préfixe clairement définit facilitant le filtrage sur les routeurs de bordure.
* Permet l'interconnexion de sites sans générer de conflit d'adresse et sans nécessiter de renumérotation.
* Indépendantes des fournisseurs d'accès à l'Internet et ne nécessitent donc pas de connectivité.
* Pas de conflit en cas de routage par erreur en dehors d'un site.
* Aucune différences pour les applications, qui peuvent les considérer comme des adresses globales unicast standard.

Les adresses uniques locales sont créées en utilisant un identifiant global (''Global ID'') généré pseudo-aléatoirement. Ces adresses suivent le format suivant :

(lien vers schéma)

* <tt>Prefix</tt> (7 bits) : <tt>FC00::/7</tt> préfixe identifiant les adresses IPv6 locales (''ULA'')
* <tt>L</tt> (1 bit) : Positionné à 1, le préfixe est assigné localement. La valeur 0 est réservée pour une utilisation future.
* <tt>Global ID</tt> (40 bits) : Identifiant global utilisé pour la création d'un préfixe ''unique'' (''Globally Unique Prefix'').
* <tt>Subnet ID</tt> (16 bits) : Identifiant d'un sous réseau à l'intérieur du site.
* <tt>Interface ID</tt> (64 bits) : L'indentifiant d'interface tel que définit dans [[Identifiant d'interface]].