http://livre.g6.asso.fr/api.php?action=feedcontributions&feedformat=atom&user=Bruno+DeniaudLivre IPv6 - User contributions [en]2026-05-29T20:00:27ZUser contributionsMediaWiki 1.25.2http://livre.g6.asso.fr/index.php?title=Les_extensions&diff=3157Les extensions2006-03-14T14:27:46Z<p>Bruno Deniaud: /* <div id="routage">Routage */</p>
<hr />
<div>{{suivi |Justification des extensions|Justification des extensions|Exemples d'extensions|Exemples d'extensions}}<br />
<br />
__NOTOC__<br />
<br />
Les extensions d'IPv6 peuvent être vues comme un prolongement de l'encapsulation d'IP dans IP. À part l'extension de proche-en-proche traitée par tous les routeurs intermédiaires, les autres extensions ne sont prises en compte que par les équipements destinataires du paquet.<br />
<br />
Une extension a une longueur multiple de 8 octets. Elle commence par un champ en-tête suivant d'un octet qui définit le type de données qui suit l'extension : une autre extension ou un protocole de niveau 4 (voir tableau Valeurs du champ en-tête suivant). Pour les extensions à longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier n'étant pas compté (une extension de 16 octets a un champ longueur de 1).<br />
<br />
{{Valeurs du champ en-tête suivant}}<br />
<br />
Le RFC 2460 recommande l'ordre suivant :<br />
<br />
*[[#PeP|Proche-en-proche]] (doit toujours être en première position)<br />
*[[#dest|Destination]] (sera aussi traité par les routeurs listés dans l'extension de routage par la source)<br />
*[[#routage|Routage]] par la source<br />
*[[#frag|Fragmentation]]<br />
*Authentification<br />
*Destination (traité uniquement par l'équipement terminal)<br />
<br />
== <div id=PeP> Proche-en-proche </div> ==<br />
<br />
[[image:Fig4-6.png|thumb|right|350px|Figure 4-6 ''Format générique des options "proche-en-proche" et "destination"'']]<br />
<br />
Cette extension (en anglais : ''hop-by-hop'') se situe toujours en première position et est traitée par tous les routeurs que le paquet traverse. Le type associé (contenu dans le champ d'en-tête en-tête suivant de l'en-tête précédent) est 0 et le champ longueur de l'extension contient le nombre de mots de 64 bits moins 1.<br />
<br />
L'extension est composée d'options. Pour l'instant, seules quatre options, dont deux de bourrage, sont définies (cf. Format des options IPv6). Chaque option est une suite d'octets. Le premier octet est un type, le deuxième (sauf pour l'option 0) contient la longueur de l'option moins 2. Les deux premiers bits de poids fort du type définissent le comportement du routeur quand il rencontre une option inconnue :<br />
<br />
*00 : le routeur ignore l'option ;<br />
*01 : le routeur rejette le paquet ;<br />
*10 : le routeur rejette le paquet et retourne un message ICMPv6 d'inaccessibilité ;<br />
*11 : le routeur rejette le paquet et retourne un message ICMPv6 d'inaccessibilité si l'adresse de destination n'est pas multicast.<br />
<br />
Le bit suivant du type indique que le routeur peut modifier le contenu du champ option (valeur à 1) ou non (valeur à 0).<br />
<br />
[[image:Fig4-7.png|thumb|right|350px|Figure 4-7 ''Format des options IPv6'']]<br />
<br />
Les quatre options de proche-en-proche sont :<br />
<br />
*<div id="Pad1">Pad1 (type 0). Cette option est utilisée pour introduire un octet de bourrage.</div><br />
*<div id="Padn">Padn (type 1). Cette option est utilisée pour introduire plus de 2 octets de bourrage. Le champ longueur indique le nombre d'octets qui suivent.</div><br />
<br />
Les options de bourrage peuvent sembler inutiles avec IPv6 puisqu'un champ longueur pourrait en donner la longueur exacte. En fait les options de bourrage servent à optimiser le traitement des paquets en alignant les champs sur des mots de 32, voire 64 bits ; le RFC 2460 discute en annexe de la manière d'optimiser le traitement tout en minimisant la place prise par les options.<br />
<br />
*Jumbogramme (type 194 ou 0xc2, RFC 2675). Cette option est utilisée quand le champ longueur des données du paquet IPv6 n'est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l'option jumbogramme est utilisée, le champ longueur des données utiles dans l'en-tête IPv6 vaut 0. <br> Noter que le type commence par la séquence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d'en informer la source. Celle-ci pourra réémettre l'information sans utiliser cette option.<br />
<br />
*L'option Router Alert (RFC 2675) demande à un routeur d'examiner le contenu des données qu'il relaie (Router Alert existe également en IPv4, RFC 2113). En principe, le processus de relayage (recopier le paquet sur une interface de sortie en fonction de l'adresse destination et des tables de routage) doit être le plus rapide possible. Mais pour des protocoles comme la gestion des groupes de multicast avec MLD (''Multicast Listener Discovery'') ou la signalisation des flux avec RSVP, tous les routeurs intermédiaires doivent tenir compte des données. <br>L'émetteur envoie les données à la destination, mais s'il précise l'option Router Alert, les routeurs intermédiaires vont analyser les données, voire modifier leur contenu avant de relayer le paquet. Ce mécanisme est efficace puisque les routeurs n'ont pas à analyser le contenu de tous les paquets d'un flux. <br> Le type de l'option vaut 5. Il commence par la séquence binaire 00, puisqu'un routeur qui ne connaît pas cette option doit relayer le paquet sans le modifier. Le champ valeur de l'option contient :<br />
**0 : pour les messages du protocole MLD de gestion des groupes multicast ;<br />
**1 : pour les messages RSVP ;<br />
**2 : pour les réseaux actifs ;<br />
:les autres valeurs sont réservées.<br />
<br />
== <div id=dest>Destination </div>==<br />
Cette extension, dont le format est identique à l'extension de proche-en-proche (cf. figure Format des extensions "proche-en-proche" et "destination"), contient des options qui sont traitées par l'équipement destinataire. Pour l'instant, à part les options de bourrage (voir [[#Pad1|Pad1]] et [[#Padn|Padn]]) et de mobilité (cf. [[Mobilité dans IPv6]]), la seule autre option concerne le tunnelage dans des paquets IPv6 (RFC 2473). Cette option permet de limiter le niveau d'encapsulation dans des tunnels des paquets IPv6.<br />
<br />
== <div id="routage">Routage ==<br />
Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau. Pour l'instant seul le routage par la source (type = 0), similaire à l'option ''Loose Source Routing'' d'IPv4, est défini pour IPv6. La [[Mobilité dans IPv6|mobilité IPv6]] a également introduit une extension de routage (type = 2) (cf. [[La gestion de la mobilité IPv6#Optimisation dans le cas du mobile dans un réseau étranger|Optimisation dans le cas du mobile dans un réseau étranger]]<br />
<br />
Dans IPv4, le routage peut être strict (le routeur suivant présent dans la liste doit être un voisin directement accessible) ou libéral (''loose'') (un routeur peut utiliser les tables de routage pour joindre le routeur suivant servant de relais). Dans IPv6, seul le routage libéral est autorisé. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau.<br />
<br />
Le principe du routage par la source ou Source Routing dans IPv4 est rappelé en introduction de ce chapitre sur les extensions. Le principe est le même pour IPv6. L'émetteur met dans le champ destination du paquet IPv6, l'adresse du premier routeur servant de relais, l'extension contient la suite de la liste des autres routeurs relais et le destinataire. Quand un routeur reçoit un paquet qui lui est adressé comportant une extension de routage par la source, il permute son adresse avec l'adresse du prochain routeur et réémet le paquet vers cette adresse suivante.<br />
<br />
[[image:Fig4-8.png|thumb|right|350px|Figure 4-8 ''Format de l'extension routage par la source'']]<br />
<br />
<br />
La figure Format de l'extension routage par la source donne le format de l'extension de routage par la source :<br />
<br />
*Le champ longueur de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de type 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2.<br />
*Le champ type indique la nature du routage. Pour l'instant, seul le routage par la source, de type 0 est spécifié. La suite de l'en-tête correspond à ce type.<br />
*Le nombre de segments restant est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée.<br />
*Les 32 bits suivants sont inutilisés pour préserver l'alignement.<br />
<br />
La liste comprenant les routeurs à traverser et le destinataire est fournie. Ces adresses ne peuvent pas être multicast.<br />
<br />
== <div id="frag">Fragmentation </div>==<br />
<br />
La fragmentation telle qu'elle est pratiquée dans IPv4 n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4 quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille et si le bit <tt>DF</tt> (''don't fragment'') est à 0, il découpe l'information à transmettre en fragments. Or le réseau IP étant un réseau à datagramme, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et par conséquent seul le destinataire peut effectuer le réassemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite.<br />
<br />
Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir [[Mécanisme de découverte du PMTU]] (RFC 1981)). En pratique une taille de paquets de 1 500 octets est presque universelle.<br />
<br />
Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de grande taille. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera chez l'émetteur et le réassemblage chez le récepteur.<br />
<br />
[[image:Fig4-9.png|thumb|right|350px|Figure 4-9 ''Format de l'extension de fragmentation'']]<br />
<br />
Le format de l'extension de fragmentation est donné figure Format de l'extension de fragmentation. La signification des champs est identique à celle d'IPv4 :<br />
<br />
*Le champ <tt>place du fragment</tt> indique lors du réassemblage où les données doivent être insérées. Ceci permet de parer les problèmes dus au déséquencement dans les réseaux orientés datagrammes. Comme ce champ est sur 13 bits, la taille de tous les segments, sauf du dernier, doit être multiple de 8 octets.<br />
*Le bit <tt>M</tt> s'il vaut 1 indique qu'il y aura d'autres fragments émis.<br />
*Le champ <tt>identification</tt> permet de repérer les fragments appartenant à un même paquet initial. Il est différent pour chaque paquet et recopié dans ses fragments.<br />
*Le bit <tt>DF</tt> (''don't fragment'') n'est plus nécessaire puisque, si un paquet est trop grand, il y aura rejet du paquet par le routeur.<br />
<br />
Dans IPv4, la valeur d'une option était codée de manière à indiquer au routeur effectuant la fragmentation si elle devait être copiée dans les fragments. Dans IPv6, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant proche-en-proche, routage par la source) sont recopiées dans chaque fragment.<br />
<br />
== Sécurité ==<br />
Deux extensions de sécurité -- les extensions d'authentification AH (''Authentication Header'') et de confidentialité ESP (''Encapsulating Security Payload'') -- sont définies par l'IETF. Elles permettent de protéger les communications passées sur les réseaux IPv6 mais aussi IPv4 en assurant les services de confidentialité, authentification, intégrité et détection de rejeux. Le chapite [[Sécurité]], RFC 2402 donne une description détaillée de ces extensions, et présente les modes de protection existants.<br />
<br />
{{suivi |Justification des extensions|Justification des extensions|Exemples d'extensions|Exemples d'extensions}}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Bibliographie&diff=2983Bibliographie2006-02-27T14:26:44Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi |Bases whois|Bases whois|Accueil|Accueil}}<br />
= Livres sur IPv6 =<br />
<br />
<div id="BM95">[BM95] S. O. Bradner & A. Mankin ed : IPng, Internet Protocol Next Generation, Addison-Wesley (IPng Series), ISBN0201633957, Septembre 1995.</div><br />
<br />
[Gai98] S. Gai, Internetworking IPv6 With Cisco Routers (Computer Communications), McGraw-Hill, ISBN: 0-070-22836-1, Février 1998.<br />
<br />
[Hui97] C. Huitema: IPv6: The New Internet Protocol, Prentice Hall, ISBN: 0-138-50505-5, Octbre 1997.<br />
<br />
[LL99] Peter Loshin & Pete Loshin: IPv6 Clearly Explained (Clearly Explained), Ap Professional, ISBN: 0-124-55838-0, Janvier 1999.<br />
<br />
[MM00] Mark A. Miller & P. E. Miller: Implementing IPv6, second edition (Network Troubleshooting Library), IDG Books Worldwide, ISBN: 0-764-54589-2, Janvier 2000.<br />
<br />
<br />
[Mil97] Stewart S. Miller: IPv6 : The Next Generation Internet Protocol, DigitalPress, ISBN: 1-555-58188-9, Décembre 1997.<br />
<br />
[MK98] Marcus Goncalves & Kitty Niles: IPv6 Networks, McGraw-Hill, ISBN: 0-070-24807-9, Mai 1998.<br />
<br />
[Sal00] Peter H. Salus: Big Book of IPV6 Addressing RFCs, Morgan Kaufmann Publishers, ISBN: 0-126-16770-2, Mars 2000.<br />
<br />
[WR99] J. D. Wegner & Robert Rockwell: IP Addressing and Subnetting, Including IPv6, Syngress Media, ISBN: 1-928-99401-6, Décembre 1999.<br />
<br />
== Internet Drafts sur IPv6 ==<br />
<br />
''Remarque : Il faut rappeler que les Internet drafts sont des documents de travail à durée de vie limitée. Ils ont vocation à devenir des RFC. Le lecteur est donc invité à vérifier quelle est la version la plus récente, ou si un RFC le remplace, en consultant l'index à jour (cf. Les RFC (Request For Comments)).''<br />
<br />
;<div id="BCP2-id">[BCP2-id]</div><br />
: J. Bound, M. Carney, C. Perkins: Extensions for the Dynamic Host Configuration Protocol for IPv6, [http://www.watersprings.org/pub/id/draft-ietf-dhcpv6exts-12.txt draft-ietf-dhc-v6exts-12.txt], Internet Draft, 5 Mai 2000 - Obsolete.<br />
<br />
;<div id="BKLSPTSDY-id">[BKLSPTSDY-id]</div><br />
: W. Biemolt, M. Kaat, T. Larder, H. Steenman, R. van der Pol, G. Tsirtsis, Y. Sekiya, A. Durand, K. Yamamoto: On overview of the introduction of IPv6 in the Internet, draft-ietf-ngtrans-introduction-to-ipv6-transition-08.txt, Internet Draft, Février 2002. Working Group Concluded.<br />
<br />
;<div id="BTM-id>[BTM-id]</div><br />
: J. Bound, L. Toutain, O. Medina, F. Dupont, A. Durand, H Afifi,: Dual Stack Transition Mechanism (DSTM), draft-ietf-ngtrans-dstm-07.txt, Internet Draft, Aout 2002. Obsolete.<br />
<br />
;<div id="BP-id">[BP-id]</div><br />
: M. Blanchet, F. Parent, IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP), [http://www.watersprings.org/pub/id/draft-blanchet-v6ops-tunnelbroker-tsp-03.txt draft-blanchet-v6ops-tunnelbroker-tsp-03.txt], Aout 2005. Work in progress.<br />
<br />
;<div id="CMB-id">[CMB-id]</div><br />
: Hesham Soliman, Claude Castelluccia, Karim Malki, Ludovic Bellier, Hierarchical Mobile IPv6 mobility management (HMIPv6), [http://www.watersprings.org/pub/id/draft-ietf-mipshop-hmipv6-04.txt draft-ietf-mipshop-hmipv6-04.txt], Décembre 04. Obsolete - Experimental RFC 4140.<br />
<br />
;<div id="Craw-id">[Craw-id]</div><br />
: Matt Crawford: IPv6 Node Information Queries, [http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-15.txt draft-ietf-ipngwg-icmp-name-lookups-15.txt, Internet Draft, 13 Février 2006. Work in progress.<br />
<br />
;<div id="Drave-id">[Drave-id]</div><br />
: R. Draves: Default Address Selection for IPv6, draft-ietf-ipngwg-default-addr-select-06.txt, Internet Draft, 28 Septembre 2001. Obsolete - RFC 3484.<br />
<br />
;<div id="DHZ-id">[DHZ-id]</div><br />
: S. Deering, B. Haberman, B. Zill, T. Jinmei, E. Nordmark, A. Onoe: IP Version 6 Scoped Address Architecture, draft-ietf-ipngwg-scoping-arch-03.txt Internet Draft, 30 Novembre 2001. Obsolete - RFC 4007.<br />
<br />
;<div id="DIS-id">[DIS-id]</div><br />
: Alain Durand, Johan Ihren, Pekka Savola, Operational Considerations and Issues with IPv6 DNS, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-issues-12.txt draft-ietf-dnsop-ipv6-dns-issues-12.txt], Internet Draft, 19 Octobre 2005,. Work in progress. <br />
<br />
;<div id="Dupont-id">[Dupont-id]</div><br />
: F. Dupont, M. Laurent-Maknavicius: AAA for mobile IPv6, draft-dupont-mipv6-AAA-01.txt, Internet Draft, 20 Novembre 2001, Obsolete.<br />
<br />
;<div id="Ernst-id">[Ernst-id]</div><br />
: Thierry Ernst, Network Mobility Support Requirements, [http://www.watersprings.org/pub/id/draft-ietf-nemo-requirements-05.txt draft-ietf-nemo-requirements-05.txt], Octobre 2005<br />
<br />
;<div id="Fenner-id">[Fenner-id]</div><br />
: Bill Fenner, Haixiang He, Brian Haberman, Hal Sandick, IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying'), [http://www.watersprings.org/pub/id/draft-ietf-magma-igmp-proxy-06.txt draft-ietf-magma-igmp-proxy-06.txt]<br />
<br />
;<div id="Fenner2-id">[Fenner2-id]</div><br />
: Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas Protocol Independent Multicast - Sparse Mode (PIM -SM): Protocol Specification (Revised), IETF Internet Draft, [http://www.watersprings.org/pub/id/draft-ietf-pim-sm-v2-new-11.txt draft-ietf-pim-sm-v2-new-11.txt], 4 Octobre 2004. Work in progress.<br />
<br />
;<div id="Haber-id">[Haber-id]</div><br />
: B. Haberman: Dynamic Allocation Guidelines for IPv6 Multicast Addresses, draft-ietf-malloc-ipv6-guide-01.txt, Internet Draft, 12 Octobre 2000. Obsolete - RFC 3307.<br />
<br />
;<div id="HD-id">[HD-id]</div><br />
: R. Hinden, S. Deering: IP Version 6 Addressing Architecture, [[http://tools.ietf.org/wg/ipv6/draft-ietf-ipv6-addr-arch-v4/draft-ietf-ipv6-addr-arch-v4-04.txt draft-ietf-ipv6-addr-arch-v4-04.txt]], Internet Draft, 20 Mai 2005. Work in progress.<br />
<br />
;<div id="HH-id">[HH-id]</div><br />
: Robert Hinden, Brian Haberman, Centrally Assigned Unique Local IPv6 Unicast Addresses, [http://www.watersprings.org/pub/id/draft-ietf-ipv6-ula-central-01.txt draft-ietf-ipv6-ula-central-01.txt], Internet Draft, 21 Février 2005, Obsolete - See RFC 4193.<br />
<br />
;<div id="Hopps-if">[Hopps-id]</div><br />
: C. E. Hopps: Routing IPv6 with IS-IS, [http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-06.txt draft-ietf-isis-ipv6-06.txt], Internet Draft, Octobre 2005. Work in progress.<br />
<br />
;<div id="Huitema-id">[Huitéma-id]</div><br />
: C. Huitema, Teredo: Tunneling IPv6 over UDP through NATs, [http://www.watersprings.org/pub/id/draft-huitema-v6ops-teredo-05.txt draft-huitema-v6ops-teredo-05.txt], Avril 2005, Obsolete - See RFC 4380.<br />
<br />
;<div id="Jeong-id">[Jeong-id]</div><br />
: Jae-Hoon Jeong, IPv6 Host Configuration of DNS Server Information Approaches, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-configuration-06.txt draft-ietf-dnsop-ipv6-dns-configuration-06.txt], Internet Draft, 5 Mai 2005. RFC Editor Queue.<br />
<br />
;<div id="JP-id">[JP-id]</div><br />
: D. B. Johnson, C. Perkins: Mobility Support in IPv6, draft-ietf-mobileip-ipv6-15.txt, Internet Draft, 2 Juillet 2001. Obsolete - RFC 3775.<br />
<br />
; <div id="NFG-id">[NGF-id]</div><br />
: Tri Nguyen, Gerard Gastaud, Francois Le Faucheur, Dirk Ooms, Jeremy De Clercq, Stuart Prevost, Connecting IPv6 Domains across IPv4 Clouds with BGP, [http://tools.ietf.org/wg/v6ops/draft-ooms-v6ops-bgp-tunnel-06.txt draft-ooms-v6ops-bgp-tunnel-06.txt], Janvier 2006. Proposed standard.<br />
<br />
;<div id="NPE-id">[NPE-id]</div><br />
: Chan Wah Ng, Eun Kyoung Paik, Thierry Ernst, Analysis of Multihoming in Network Mobility Support, [http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-04.txt draft-ietf-nemo-multihoming-issues-04.txt], 24 Octobre 2005. Work in progress<br />
<br />
;<div id="Prz-id">[Prz-id]</div><br />
: Tony Przygienda, M-ISIS: Multi Topology (MT) Routing in IS-IS, [http://www.watersprings.org/pub/id/draft-ietf-isis-wg-multi-topology-11.txt draft-ietf-isis-wg-multi-topology-11.txt], 21 Octobre 2005.<br />
<br />
;<div id="Prigent-id">[Prigent-id]</div><br />
: N. Prigent, J. Marchand, F. Dupont, B. Cousin, M. Laurent-Maknavicius, J. Bournelle: DHCPv6 Threats, draft-prigent-dhcpv6-threats-00.txt, Internet Draft, 24 mai 2001, Expired.<br />
<br />
;<div id="RFC2547bis">[RFC2547bis]</div><br />
: Eric C. Rosen, Yakov Rekhter, BGP/MPLS IP VPNs, [http://www.watersprings.org/pub/id/draft-ietf-l3vpn-rfc2547bis-03.txt draft-ietf-l3vpn-rfc2547bis-03.txt], Internet Draft, October 2004, Obsolete - RFC 4364.<br />
<br />
;<div id="Templin-id">[Templin-id]</div><br />
:Fred Templin, T. Gleeson, M. Talwar D. Thaler, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), [http://www.watersprings.org/pub/id/draft-ietf-ngtrans-isatap-24.txt draft-ietf-ngtrans-isatap-24.txt], Juillet 2005, Obsolete - RFC 4214.<br />
<br />
;<div id="Thubert-id">[Thubert-id]</div><br />
:Pascal Thubert, NEMO Home Network models, [http://www.watersprings.org/pub/id/draft-ietf-nemo-home-network-models-06.txt draft-ietf-nemo-home-network-models-06.txt], 17 Fevrier 2006.<br />
<br />
==Autres documents de travail==<br />
[FIPS-46]<br />
<br />
Data Encryption Standard, Federal Information Processing Standards Publication 46, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 15 Janvier 1977.<br />
<br />
[FIPS-81]<br />
<br />
DES Modes of Operation, Federal Information Processing Standards Publication 81, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 2 Décembre 1980.<br />
<br />
[FIPS-180-1]<br />
<br />
Secure Hash Standard, Federal Information Processing Standards Publication 180-1, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, Avril 1995.<br />
<br />
==Autres Références==<br />
[AL00]<br />
<br />
Mohammed Achemlal, Maryline Laurent, Analyse des fonctions des protocoles IPsec et leur intégration dans un réseau privé virtuel, Annales des télécommunications, 2000.<br />
<br />
<br />
[AL98]<br />
<br />
P. Albitz and C. Liu: DNS and BIND, 3rd Edition, ISBN: 1-56592-512-2, O'Reilly and Associates, Septembre 1998.<br />
<br />
<br />
;<div id="BTC02">[BTC02]</div><br />
: T. Bu, L. Gao, D. Towsley, On Characterizing Routing Table Growth, GlobalInternet 2002. http://www-unix.ecs.umass.edu/~lgao/globalinternet2002_tian.pdf<br />
<br />
<br />
;<div id="Ernst01f-fr">[Ernst01f-fr]</div><br />
:Ernst, Thierry, Le Support des Réseaux Mobiles dans IPv6, UniversitéJoseph Fourier, Octobre 2001, Grenoble, France, http://www.inria.fr/rrrt/tu-0714.html<br />
<br />
<br />
;<div id="Ernst03f">[Ernst03f]</div><br />
:Thierry Ernst, Le Support des Réseaux Mobiles dans IPv6, CFIP: Colloque Francophone sur l'Ingenierie des Protocoles, Octobre 2003, Paris<br />
<br />
<br />
[Fen-id]<br />
<br />
Bill Fenner, Management Information Base for the User Datagram Protocol (UDP), draft-ietf-ipv6-rfc2013-update-04.txt, Internet Draft, 20 Octobre 2004, Work in progress.<br />
<br />
<br />
[Hui95]<br />
<br />
C. Huitema: Le routage dans l'Internet, Eyrolles, Octobre 1995.<br />
<br />
[IEEE]<br />
<br />
Protocol Independant Interfaces, IEEE Std 1003.1g, DRAFT~6.6, Mars 1997.<br />
<br />
<br />
;<div id="JH-id">[JH-id]</div><br />
: Jeffrey Haas, Susan Hares, Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), draft-ietf-idr-bgp4-mib-05.txt, Internet Draft, 31 Août 2004, Work in progress.<br />
<br />
<br />
[JM-id]<br />
<br />
Dan Joyal, Vishwas Manral, Management Information Base for OSPFv3, draft-ietf-ospf-ospfv3-mib-09.txt, Internet Draft, 13 Mai 2005, Work in progress.<br />
<br />
<br />
;<div id="Kau-id">[Kau-id]</div><br />
:Charlie Kaufman, Internet Key Exchange (IKEv2) Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-ikev2-17.txt draft-ietf-ipsec-ikev2-17.txt], Internet Draft, 4 Octobre 2004, Work in progress.<br />
<br />
;<div id="LAU03">[LAU03]</div><br />
: M. Laurent-Maknavicius, Le protocole IPsec, [http://www.techniques-ingenieur.fr/affichage/DispIntro.asp?nGcmID=TE7545 TE7545], [http://www.techniques-ingenieur.fr/ Techniques de l'Ingénieur], Sécurité des systèmes d'information, Novembre 2003.<br />
<br />
[LAU04-A]<br />
<br />
M. Laurent-Maknavicius, M. Gardie, LDAP et la certification, Rapport de recherche du GET, 04001 LOR, 2004.<br />
<br />
[LAU04-B]<br />
<br />
M. Laurent-Maknavicius, La sécurité de l'accès distant, Technique et Science Informatiques (TSI), 2004.<br />
<br />
;<div id="MHF-id">[MHF-id]</div><br />
:Ambarish Malpani, Russ Housley, Trevor Freeman, Simple Certificate Validation Protocol (SCVP), [http://www.watersprings.org/pub/id/draft-ietf-pkix-scvp-22.txt draft-ietf-pkix-scvp-22.txt], Internet Draft, Octobre 2005, Work in progress.<br />
<br />
;<div id="Mos-id">[Mos-id]</div><br />
:Robert Moskowitz, Host Identity Protocol, [http://www.watersprings.org/pub/id/draft-ietf-hip-base-04.txt draft-ietf-hip-base-04.txt], Internet Draft, 24 Octobre 2005, Work in progress<br />
<br />
;<div id="Pui02-A">[Pui02-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse critique d'IPsec, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-analyse-rapport/ipsec-analyse-rapport.pdf rapport de recherche 03 004 LOR], 2002.<br />
<br />
;<div id="Pui02-B">[Pui02-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse de l'impact de la mise en oeuvre d'IPsec dans les architectures de Communication, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-interactions-rapport/ipsec-interactions-rapport.pdf rapport de recherche 03 002 LOR], octobre 2002.<br />
<br />
;<div id="Pui03">[Pui03]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects ARP), [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/environnement-reel-1-rapport/environnement-reel-1-rapport.pdf rapport de recherche 03 001 LOR], janvier 2003.<br />
<br />
;<div id="Pui04-A">[Pui04-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Etude des interactions IPsec/DNS, [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/InteractionDNS.pdf rapport de recherche 04002 LOR], 2004.<br />
<br />
;<div id="Pui04-B">[Pui04-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects liés à ICMP), [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/IPsec_ICMP.pdf rapport de recherche 04004 LOR], 2004.<br />
<br />
;<div id="RFC2401bis">[RFC2401bis]</div><br />
: Stephen Kent, Karen Seo, Security Architecture for the Internet Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2401bis-06.txt draft-ietf-ipsec-rfc2401bis-06.txt], Internet Draft, 1 Avril 2005, Work in progress<br />
<br />
<br />
;<div id="RFC2402bis">[RFC2402bis]</div><br />
:Stephen Kent, IP Authentication Header, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2402bis-11.txt draft-ietf-ipsec-rfc2402bis-11.txt], Internet Draft, 21 Mars 2005, Work in progress.<br />
<br />
[Rou-id]<br />
<br />
Shawn Routhier, Management Information Base for the Internet Protocol (IP), draft-ietf-ipv6-rfc2011-update-10.txt; Internet Draft, 24 Mai 2004, Work in progress.<br />
<br />
[Sch95]<br />
<br />
B. Schneier: Applied Cryptography : protocols, algorithms, and source code in C, (second edition), John Wiley & Sons, ISBN: 0-471-12845-7, 1996.<br />
<br />
[Sta99]<br />
<br />
William Stallings: Snmp, Snmpv2, Snmpv3, and Rmon 1 and 2, Addison Wesley, ISBN: 0-201-48534-6, Janvier 1999.<br />
<br />
[Tout03]<br />
<br />
Laurent Toutain: Réseaux Locaux et Internet: des protocoles à l'interconnexion, Troisième édition revue et augmentée, Hermès, ISBN: 2-7462-0670-6, 2003.<br />
<br />
[Uni31]<br />
<br />
ATM Forum: ATM User-Network Interface (UNI) Specification Version 3.1, Prentice Hall, Englewood Cliffs, NJ, Juin 1995.<br />
<br />
[WH-id]<br />
<br />
Margaret Wasserman, Brian Haberman, IP Forwarding Table MIB, draft-ietf-ipv6-rfc2096-update-07.txt, Internet Draft, 12 février 2004, Work in progress.<br />
<br />
[WK99]<br />
<br />
M. Welsh et L. Kaufman: Le système Linux, 2e édition révisée, Éditions O'Reilly, ISBN: 2-84177-033-8, Janvier 1999.<br />
<br />
==Sites Web sur IPv6 ==<br />
<br />
;[IETF]<br />
:http://www.imag.fr/pub/archive/IETF: Mirroir français du serveur de l'IETF.<br />
<br />
;[6bone]<br />
:http://www.6bone.net: Réseau 6bone.<br />
<br />
;[G6bone]<br />
:http://peirce.logique.jussieu.fr/G6/ Réseau G6-bone (partie francophone de 6bone).<br />
<br />
;[hs247] <br />
:http://hs247.com/ Informations sur le 6bone et IPv6 en général.<br />
<br />
;[ipv6.org]<br />
: http://www.ipv6.org/ pages d'information sur le protocole IPv6<br />
<br />
;[ipv6forum] <br />
:http://www.ipv6forum.org/ Groupement d'industriels pour promouvoir IPv6.<br />
<br />
;[playground] <br />
:http://playground.sun.com/pub/ipng/html/ipng-main.html liste des mises en oeuvre d'IPv6 dans les équipements.<br />
{{suivi |Bases whois|Bases whois|Accueil|Accueil}}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Bibliographie&diff=2982Bibliographie2006-02-27T14:24:59Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi |Bases whois|Bases whois}}<br />
= Livres sur IPv6 =<br />
<br />
<div id="BM95">[BM95] S. O. Bradner & A. Mankin ed : IPng, Internet Protocol Next Generation, Addison-Wesley (IPng Series), ISBN0201633957, Septembre 1995.</div><br />
<br />
[Gai98] S. Gai, Internetworking IPv6 With Cisco Routers (Computer Communications), McGraw-Hill, ISBN: 0-070-22836-1, Février 1998.<br />
<br />
[Hui97] C. Huitema: IPv6: The New Internet Protocol, Prentice Hall, ISBN: 0-138-50505-5, Octbre 1997.<br />
<br />
[LL99] Peter Loshin & Pete Loshin: IPv6 Clearly Explained (Clearly Explained), Ap Professional, ISBN: 0-124-55838-0, Janvier 1999.<br />
<br />
[MM00] Mark A. Miller & P. E. Miller: Implementing IPv6, second edition (Network Troubleshooting Library), IDG Books Worldwide, ISBN: 0-764-54589-2, Janvier 2000.<br />
<br />
<br />
[Mil97] Stewart S. Miller: IPv6 : The Next Generation Internet Protocol, DigitalPress, ISBN: 1-555-58188-9, Décembre 1997.<br />
<br />
[MK98] Marcus Goncalves & Kitty Niles: IPv6 Networks, McGraw-Hill, ISBN: 0-070-24807-9, Mai 1998.<br />
<br />
[Sal00] Peter H. Salus: Big Book of IPV6 Addressing RFCs, Morgan Kaufmann Publishers, ISBN: 0-126-16770-2, Mars 2000.<br />
<br />
[WR99] J. D. Wegner & Robert Rockwell: IP Addressing and Subnetting, Including IPv6, Syngress Media, ISBN: 1-928-99401-6, Décembre 1999.<br />
<br />
== Internet Drafts sur IPv6 ==<br />
<br />
''Remarque : Il faut rappeler que les Internet drafts sont des documents de travail à durée de vie limitée. Ils ont vocation à devenir des RFC. Le lecteur est donc invité à vérifier quelle est la version la plus récente, ou si un RFC le remplace, en consultant l'index à jour (cf. Les RFC (Request For Comments)).''<br />
<br />
;<div id="BCP2-id">[BCP2-id]</div><br />
: J. Bound, M. Carney, C. Perkins: Extensions for the Dynamic Host Configuration Protocol for IPv6, [http://www.watersprings.org/pub/id/draft-ietf-dhcpv6exts-12.txt draft-ietf-dhc-v6exts-12.txt], Internet Draft, 5 Mai 2000 - Obsolete.<br />
<br />
;<div id="BKLSPTSDY-id">[BKLSPTSDY-id]</div><br />
: W. Biemolt, M. Kaat, T. Larder, H. Steenman, R. van der Pol, G. Tsirtsis, Y. Sekiya, A. Durand, K. Yamamoto: On overview of the introduction of IPv6 in the Internet, draft-ietf-ngtrans-introduction-to-ipv6-transition-08.txt, Internet Draft, Février 2002. Working Group Concluded.<br />
<br />
;<div id="BTM-id>[BTM-id]</div><br />
: J. Bound, L. Toutain, O. Medina, F. Dupont, A. Durand, H Afifi,: Dual Stack Transition Mechanism (DSTM), draft-ietf-ngtrans-dstm-07.txt, Internet Draft, Aout 2002. Obsolete.<br />
<br />
;<div id="BP-id">[BP-id]</div><br />
: M. Blanchet, F. Parent, IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP), [http://www.watersprings.org/pub/id/draft-blanchet-v6ops-tunnelbroker-tsp-03.txt draft-blanchet-v6ops-tunnelbroker-tsp-03.txt], Aout 2005. Work in progress.<br />
<br />
;<div id="CMB-id">[CMB-id]</div><br />
: Hesham Soliman, Claude Castelluccia, Karim Malki, Ludovic Bellier, Hierarchical Mobile IPv6 mobility management (HMIPv6), [http://www.watersprings.org/pub/id/draft-ietf-mipshop-hmipv6-04.txt draft-ietf-mipshop-hmipv6-04.txt], Décembre 04. Obsolete - Experimental RFC 4140.<br />
<br />
;<div id="Craw-id">[Craw-id]</div><br />
: Matt Crawford: IPv6 Node Information Queries, [http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-15.txt draft-ietf-ipngwg-icmp-name-lookups-15.txt, Internet Draft, 13 Février 2006. Work in progress.<br />
<br />
;<div id="Drave-id">[Drave-id]</div><br />
: R. Draves: Default Address Selection for IPv6, draft-ietf-ipngwg-default-addr-select-06.txt, Internet Draft, 28 Septembre 2001. Obsolete - RFC 3484.<br />
<br />
;<div id="DHZ-id">[DHZ-id]</div><br />
: S. Deering, B. Haberman, B. Zill, T. Jinmei, E. Nordmark, A. Onoe: IP Version 6 Scoped Address Architecture, draft-ietf-ipngwg-scoping-arch-03.txt Internet Draft, 30 Novembre 2001. Obsolete - RFC 4007.<br />
<br />
;<div id="DIS-id">[DIS-id]</div><br />
: Alain Durand, Johan Ihren, Pekka Savola, Operational Considerations and Issues with IPv6 DNS, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-issues-12.txt draft-ietf-dnsop-ipv6-dns-issues-12.txt], Internet Draft, 19 Octobre 2005,. Work in progress. <br />
<br />
;<div id="Dupont-id">[Dupont-id]</div><br />
: F. Dupont, M. Laurent-Maknavicius: AAA for mobile IPv6, draft-dupont-mipv6-AAA-01.txt, Internet Draft, 20 Novembre 2001, Obsolete.<br />
<br />
;<div id="Ernst-id">[Ernst-id]</div><br />
: Thierry Ernst, Network Mobility Support Requirements, [http://www.watersprings.org/pub/id/draft-ietf-nemo-requirements-05.txt draft-ietf-nemo-requirements-05.txt], Octobre 2005<br />
<br />
;<div id="Fenner-id">[Fenner-id]</div><br />
: Bill Fenner, Haixiang He, Brian Haberman, Hal Sandick, IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying'), [http://www.watersprings.org/pub/id/draft-ietf-magma-igmp-proxy-06.txt draft-ietf-magma-igmp-proxy-06.txt]<br />
<br />
;<div id="Fenner2-id">[Fenner2-id]</div><br />
: Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas Protocol Independent Multicast - Sparse Mode (PIM -SM): Protocol Specification (Revised), IETF Internet Draft, [http://www.watersprings.org/pub/id/draft-ietf-pim-sm-v2-new-11.txt draft-ietf-pim-sm-v2-new-11.txt], 4 Octobre 2004. Work in progress.<br />
<br />
;<div id="Haber-id">[Haber-id]</div><br />
: B. Haberman: Dynamic Allocation Guidelines for IPv6 Multicast Addresses, draft-ietf-malloc-ipv6-guide-01.txt, Internet Draft, 12 Octobre 2000. Obsolete - RFC 3307.<br />
<br />
;<div id="HD-id">[HD-id]</div><br />
: R. Hinden, S. Deering: IP Version 6 Addressing Architecture, [[http://tools.ietf.org/wg/ipv6/draft-ietf-ipv6-addr-arch-v4/draft-ietf-ipv6-addr-arch-v4-04.txt draft-ietf-ipv6-addr-arch-v4-04.txt]], Internet Draft, 20 Mai 2005. Work in progress.<br />
<br />
;<div id="HH-id">[HH-id]</div><br />
: Robert Hinden, Brian Haberman, Centrally Assigned Unique Local IPv6 Unicast Addresses, [http://www.watersprings.org/pub/id/draft-ietf-ipv6-ula-central-01.txt draft-ietf-ipv6-ula-central-01.txt], Internet Draft, 21 Février 2005, Obsolete - See RFC 4193.<br />
<br />
;<div id="Hopps-if">[Hopps-id]</div><br />
: C. E. Hopps: Routing IPv6 with IS-IS, [http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-06.txt draft-ietf-isis-ipv6-06.txt], Internet Draft, Octobre 2005. Work in progress.<br />
<br />
;<div id="Huitema-id">[Huitéma-id]</div><br />
: C. Huitema, Teredo: Tunneling IPv6 over UDP through NATs, [http://www.watersprings.org/pub/id/draft-huitema-v6ops-teredo-05.txt draft-huitema-v6ops-teredo-05.txt], Avril 2005, Obsolete - See RFC 4380.<br />
<br />
;<div id="Jeong-id">[Jeong-id]</div><br />
: Jae-Hoon Jeong, IPv6 Host Configuration of DNS Server Information Approaches, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-configuration-06.txt draft-ietf-dnsop-ipv6-dns-configuration-06.txt], Internet Draft, 5 Mai 2005. RFC Editor Queue.<br />
<br />
;<div id="JP-id">[JP-id]</div><br />
: D. B. Johnson, C. Perkins: Mobility Support in IPv6, draft-ietf-mobileip-ipv6-15.txt, Internet Draft, 2 Juillet 2001. Obsolete - RFC 3775.<br />
<br />
; <div id="NFG-id">[NGF-id]</div><br />
: Tri Nguyen, Gerard Gastaud, Francois Le Faucheur, Dirk Ooms, Jeremy De Clercq, Stuart Prevost, Connecting IPv6 Domains across IPv4 Clouds with BGP, [http://tools.ietf.org/wg/v6ops/draft-ooms-v6ops-bgp-tunnel-06.txt draft-ooms-v6ops-bgp-tunnel-06.txt], Janvier 2006. Proposed standard.<br />
<br />
;<div id="NPE-id">[NPE-id]</div><br />
: Chan Wah Ng, Eun Kyoung Paik, Thierry Ernst, Analysis of Multihoming in Network Mobility Support, [http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-04.txt draft-ietf-nemo-multihoming-issues-04.txt], 24 Octobre 2005. Work in progress<br />
<br />
;<div id="Prz-id">[Prz-id]</div><br />
: Tony Przygienda, M-ISIS: Multi Topology (MT) Routing in IS-IS, [http://www.watersprings.org/pub/id/draft-ietf-isis-wg-multi-topology-11.txt draft-ietf-isis-wg-multi-topology-11.txt], 21 Octobre 2005.<br />
<br />
;<div id="Prigent-id">[Prigent-id]</div><br />
: N. Prigent, J. Marchand, F. Dupont, B. Cousin, M. Laurent-Maknavicius, J. Bournelle: DHCPv6 Threats, draft-prigent-dhcpv6-threats-00.txt, Internet Draft, 24 mai 2001, Expired.<br />
<br />
;<div id="RFC2547bis">[RFC2547bis]</div><br />
: Eric C. Rosen, Yakov Rekhter, BGP/MPLS IP VPNs, [http://www.watersprings.org/pub/id/draft-ietf-l3vpn-rfc2547bis-03.txt draft-ietf-l3vpn-rfc2547bis-03.txt], Internet Draft, October 2004, Obsolete - RFC 4364.<br />
<br />
;<div id="Templin-id">[Templin-id]</div><br />
:Fred Templin, T. Gleeson, M. Talwar D. Thaler, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), [http://www.watersprings.org/pub/id/draft-ietf-ngtrans-isatap-24.txt draft-ietf-ngtrans-isatap-24.txt], Juillet 2005, Obsolete - RFC 4214.<br />
<br />
;<div id="Thubert-id">[Thubert-id]</div><br />
:Pascal Thubert, NEMO Home Network models, [http://www.watersprings.org/pub/id/draft-ietf-nemo-home-network-models-06.txt draft-ietf-nemo-home-network-models-06.txt], 17 Fevrier 2006.<br />
<br />
==Autres documents de travail==<br />
[FIPS-46]<br />
<br />
Data Encryption Standard, Federal Information Processing Standards Publication 46, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 15 Janvier 1977.<br />
<br />
[FIPS-81]<br />
<br />
DES Modes of Operation, Federal Information Processing Standards Publication 81, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 2 Décembre 1980.<br />
<br />
[FIPS-180-1]<br />
<br />
Secure Hash Standard, Federal Information Processing Standards Publication 180-1, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, Avril 1995.<br />
<br />
==Autres Références==<br />
[AL00]<br />
<br />
Mohammed Achemlal, Maryline Laurent, Analyse des fonctions des protocoles IPsec et leur intégration dans un réseau privé virtuel, Annales des télécommunications, 2000.<br />
<br />
<br />
[AL98]<br />
<br />
P. Albitz and C. Liu: DNS and BIND, 3rd Edition, ISBN: 1-56592-512-2, O'Reilly and Associates, Septembre 1998.<br />
<br />
<br />
;<div id="BTC02">[BTC02]</div><br />
: T. Bu, L. Gao, D. Towsley, On Characterizing Routing Table Growth, GlobalInternet 2002. http://www-unix.ecs.umass.edu/~lgao/globalinternet2002_tian.pdf<br />
<br />
<br />
;<div id="Ernst01f-fr">[Ernst01f-fr]</div><br />
:Ernst, Thierry, Le Support des Réseaux Mobiles dans IPv6, UniversitéJoseph Fourier, Octobre 2001, Grenoble, France, http://www.inria.fr/rrrt/tu-0714.html<br />
<br />
<br />
;<div id="Ernst03f">[Ernst03f]</div><br />
:Thierry Ernst, Le Support des Réseaux Mobiles dans IPv6, CFIP: Colloque Francophone sur l'Ingenierie des Protocoles, Octobre 2003, Paris<br />
<br />
<br />
[Fen-id]<br />
<br />
Bill Fenner, Management Information Base for the User Datagram Protocol (UDP), draft-ietf-ipv6-rfc2013-update-04.txt, Internet Draft, 20 Octobre 2004, Work in progress.<br />
<br />
<br />
[Hui95]<br />
<br />
C. Huitema: Le routage dans l'Internet, Eyrolles, Octobre 1995.<br />
<br />
[IEEE]<br />
<br />
Protocol Independant Interfaces, IEEE Std 1003.1g, DRAFT~6.6, Mars 1997.<br />
<br />
<br />
;<div id="JH-id">[JH-id]</div><br />
: Jeffrey Haas, Susan Hares, Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), draft-ietf-idr-bgp4-mib-05.txt, Internet Draft, 31 Août 2004, Work in progress.<br />
<br />
<br />
[JM-id]<br />
<br />
Dan Joyal, Vishwas Manral, Management Information Base for OSPFv3, draft-ietf-ospf-ospfv3-mib-09.txt, Internet Draft, 13 Mai 2005, Work in progress.<br />
<br />
<br />
;<div id="Kau-id">[Kau-id]</div><br />
:Charlie Kaufman, Internet Key Exchange (IKEv2) Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-ikev2-17.txt draft-ietf-ipsec-ikev2-17.txt], Internet Draft, 4 Octobre 2004, Work in progress.<br />
<br />
;<div id="LAU03">[LAU03]</div><br />
: M. Laurent-Maknavicius, Le protocole IPsec, [http://www.techniques-ingenieur.fr/affichage/DispIntro.asp?nGcmID=TE7545 TE7545], [http://www.techniques-ingenieur.fr/ Techniques de l'Ingénieur], Sécurité des systèmes d'information, Novembre 2003.<br />
<br />
[LAU04-A]<br />
<br />
M. Laurent-Maknavicius, M. Gardie, LDAP et la certification, Rapport de recherche du GET, 04001 LOR, 2004.<br />
<br />
[LAU04-B]<br />
<br />
M. Laurent-Maknavicius, La sécurité de l'accès distant, Technique et Science Informatiques (TSI), 2004.<br />
<br />
;<div id="MHF-id">[MHF-id]</div><br />
:Ambarish Malpani, Russ Housley, Trevor Freeman, Simple Certificate Validation Protocol (SCVP), [http://www.watersprings.org/pub/id/draft-ietf-pkix-scvp-22.txt draft-ietf-pkix-scvp-22.txt], Internet Draft, Octobre 2005, Work in progress.<br />
<br />
;<div id="Mos-id">[Mos-id]</div><br />
:Robert Moskowitz, Host Identity Protocol, [http://www.watersprings.org/pub/id/draft-ietf-hip-base-04.txt draft-ietf-hip-base-04.txt], Internet Draft, 24 Octobre 2005, Work in progress<br />
<br />
;<div id="Pui02-A">[Pui02-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse critique d'IPsec, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-analyse-rapport/ipsec-analyse-rapport.pdf rapport de recherche 03 004 LOR], 2002.<br />
<br />
;<div id="Pui02-B">[Pui02-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse de l'impact de la mise en oeuvre d'IPsec dans les architectures de Communication, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-interactions-rapport/ipsec-interactions-rapport.pdf rapport de recherche 03 002 LOR], octobre 2002.<br />
<br />
;<div id="Pui03">[Pui03]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects ARP), [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/environnement-reel-1-rapport/environnement-reel-1-rapport.pdf rapport de recherche 03 001 LOR], janvier 2003.<br />
<br />
;<div id="Pui04-A">[Pui04-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Etude des interactions IPsec/DNS, [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/InteractionDNS.pdf rapport de recherche 04002 LOR], 2004.<br />
<br />
;<div id="Pui04-B">[Pui04-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects liés à ICMP), [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/IPsec_ICMP.pdf rapport de recherche 04004 LOR], 2004.<br />
<br />
;<div id="RFC2401bis">[RFC2401bis]</div><br />
: Stephen Kent, Karen Seo, Security Architecture for the Internet Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2401bis-06.txt draft-ietf-ipsec-rfc2401bis-06.txt], Internet Draft, 1 Avril 2005, Work in progress<br />
<br />
<br />
;<div id="RFC2402bis">[RFC2402bis]</div><br />
:Stephen Kent, IP Authentication Header, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2402bis-11.txt draft-ietf-ipsec-rfc2402bis-11.txt], Internet Draft, 21 Mars 2005, Work in progress.<br />
<br />
[Rou-id]<br />
<br />
Shawn Routhier, Management Information Base for the Internet Protocol (IP), draft-ietf-ipv6-rfc2011-update-10.txt; Internet Draft, 24 Mai 2004, Work in progress.<br />
<br />
[Sch95]<br />
<br />
B. Schneier: Applied Cryptography : protocols, algorithms, and source code in C, (second edition), John Wiley & Sons, ISBN: 0-471-12845-7, 1996.<br />
<br />
[Sta99]<br />
<br />
William Stallings: Snmp, Snmpv2, Snmpv3, and Rmon 1 and 2, Addison Wesley, ISBN: 0-201-48534-6, Janvier 1999.<br />
<br />
[Tout03]<br />
<br />
Laurent Toutain: Réseaux Locaux et Internet: des protocoles à l'interconnexion, Troisième édition revue et augmentée, Hermès, ISBN: 2-7462-0670-6, 2003.<br />
<br />
[Uni31]<br />
<br />
ATM Forum: ATM User-Network Interface (UNI) Specification Version 3.1, Prentice Hall, Englewood Cliffs, NJ, Juin 1995.<br />
<br />
[WH-id]<br />
<br />
Margaret Wasserman, Brian Haberman, IP Forwarding Table MIB, draft-ietf-ipv6-rfc2096-update-07.txt, Internet Draft, 12 février 2004, Work in progress.<br />
<br />
[WK99]<br />
<br />
M. Welsh et L. Kaufman: Le système Linux, 2e édition révisée, Éditions O'Reilly, ISBN: 2-84177-033-8, Janvier 1999.<br />
<br />
==Sites Web sur IPv6 ==<br />
<br />
;[IETF]<br />
:http://www.imag.fr/pub/archive/IETF: Mirroir français du serveur de l'IETF.<br />
<br />
;[6bone]<br />
:http://www.6bone.net: Réseau 6bone.<br />
<br />
;[G6bone]<br />
:http://peirce.logique.jussieu.fr/G6/ Réseau G6-bone (partie francophone de 6bone).<br />
<br />
;[hs247] <br />
:http://hs247.com/ Informations sur le 6bone et IPv6 en général.<br />
<br />
;[ipv6.org]<br />
: http://www.ipv6.org/ pages d'information sur le protocole IPv6<br />
<br />
;[ipv6forum] <br />
:http://www.ipv6forum.org/ Groupement d'industriels pour promouvoir IPv6.<br />
<br />
;[playground] <br />
:http://playground.sun.com/pub/ipng/html/ipng-main.html liste des mises en oeuvre d'IPv6 dans les équipements.<br />
{{suivi |Bases whois|Bases whois}}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Bases_whois&diff=2981Bases whois2006-02-27T14:24:16Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi |La standardisation d'IPv6|La standardisation d'IPv6|Bibliographie|Bibliographie}}<br />
==Définition et concepts de base==<br />
<br />
Les bases de type WHOIS contiennent des informations techniques et administratives permettant entre autres de savoir qui est le titulaire d'un nom de domaine, qui gère tel bloc d'adresses IP (v4 ou v6), quelle est la politique de routage de tel AS... Il s'agit de bases distribuées à accès public dont l'interrogation est possible en utilisant des outils disponibles en standard sur une grande partie des systèmes Unix (commande <tt>whois</tt> tout simplement). Si ce n'est pas le cas, il existe un certain nombre de clients dont l'un des plus usités est celui qu'il est possible de télécharger sur le site du RIPE.<br />
<br />
Il existe de plus, sur les sites des organismes assurant la gestion de bases WHOIS, des outils de consultation via une interface Web. De telles interfaces peuvent être trouvées sur les sites du RIPE, de l'INTERNIC, du 6BONE, ou bien encore de l'AFNIC. En ce qui concerne la distribution de l'information, tout ce qui concerne l'adressage IP et les informations de routage se trouve réparti sur 3 bases. La base ARIN pour l'Amérique du nord et du sud, les Caraïbes et l'Afrique sub-saharienne; la base RIPE pour l'Europe et une partie de l'Afrique; enfin la base APNIC pour la zone Asie Pacifique. Pour les adresses IPv6 de test (préfixe <tt>3FFE::/16</tt>) il existe une base spécifique gérée par le 6BONE.<br />
<br />
==Types de données spécifiques à IPv6==<br />
<br />
Il existe 2 types de données qui ont été spécialement créés pour répondre aux besoins spécifiques à IPv6. Il s'agit des types inet6num et ipv6-site.<br />
<br />
Les objets de type inet6num sont présents dans les bases RIPE, ARIN, APNIC et 6BONE, ceux de type ipv6-site ne sont utilisés que dans la base 6BONE car ils sont pour l'instant réservés aux adresses de test. D'ailleurs, ces deux types sont utilisés à titre expérimental et leurs format peut être amené à être modifié selon les besoins futurs.<br />
<br />
==Type inet6num==<br />
<br />
Ce type de données va permettre de définir les propriétés associées à un préfixe IPv6 donné. Le format qui est décrit ci-après ne concerne pas la base ARIN qui adopte un format minimaliste à l'image de la base INTERNIC pour les noms de domaines.<br />
<br />
===Format générique (template) d'un objet de type inet6num===<br />
<br />
Chaque ligne du template donne des informations sur un attribut. Après le nom de l'attribut, on indique sont statut (obligatoire, optionnel ou généré), s'il ne doit être présent qu'une seule fois ou non dans un objet et pour finir si cet attribut est une clef de recherche dans la base.<br />
<br />
inet6num: [mandatory] [single] [primary/look-up key]<br />
netname: [mandatory] [single] [lookup key]<br />
descr: [mandatory] [multiple] [ ]<br />
country: [mandatory] [multiple] [ ]<br />
admin-c: [mandatory] [multiple] [inverse key]<br />
tech-c: [mandatory] [multiple] [inverse key]<br />
rev-srv: [optional] [multiple] [inverse key]<br />
status: [generated] [single] [ ]<br />
remarks: [optional] [multiple] [ ]<br />
notify: [optional] [multiple] [inverse key]<br />
mnt-by: [mandatory] [multiple] [inverse key]<br />
mnt-lower: [optional] [multiple] [inverse key]<br />
changed: [mandatory] [multiple] [ ]<br />
source: [mandatory] [single] [ ]<br />
<br />
* inet6num: Préfixe IPv6 dont on définit les attributs (format préfixe/taille du préfixe).<br />
* netname: Le nom associé à la plage d'adresses définie par le préfixe.<br />
* descr: Description succincte de l'objet.<br />
* country: Code en 2 lettres (ISO 3166) identifiant le pays du contact administratif de l'organisme auquel appartient le préfixe.<br />
* admin-c: Référence à un objet de type person/role identifiant un contact administratif pour l'objet inet6num. Cette référence est un NIC-Handle, c'est-à-dire un objet unique dans la base.<br />
* tech-c: Référence à un objet de type person/role identifiant un contact technique pour l'objet inet6num. Cette référence est un NIC-Handle, c'est à dire un objet unique dans la base.<br />
* rev-srv: Serveur de noms pour les reverses de la plage d'adresses définie par le préfixe.<br />
* status: Type du préfixe (TLA, Sub-TLA, NLA, ...).<br />
* remarks: Remarques divers et variées.<br />
* notify: E-Mail de la personne qui est prévenue lors de toute modification effectuer sur l'objet.<br />
* mnt-by: Référence à un objet de type mntner identifiant les personnes habilitées à modifier l'objet, ainsi que la méthode d'authentification.<br />
* mnt-lower: Référence à un objet de type mntner identifiant les personnes habilitées à fournir des espaces d'adresses (avec ce préfixe) a des utilisateurs finaux.<br />
* changed: E-Mail de la personne ayant effectuer la dernière mise à jour de l'objet, ainsi que la date de cette modification.<br />
* source: Identification de la base où se trouve cet objet (6BONE, RIPE, APNIC, ARIN, ...)<br />
<br />
===Exemple d'objet de type inet6num===<br />
<br />
Si on utilise la commande suivante :<br />
<br />
> '''whois -h whois.ripe.net 2001:0660::/35'''<br />
<br />
On obtient le résultat suivant :<br />
<br />
inet6num: 2001:0660::/35<br />
netname: FR-RENATER-20000321<br />
descr: Renater Sub-TLA block<br />
descr: Réseau National de télécommunications pour la<br />
descr: Technologie l'Enseignement et la Recherche<br />
descr: National telecommunications network<br />
descr: for Technology, Education and Research<br />
country: FR<br />
admin-c: BT261-RIPE<br />
admin-c: GR1378-RIPE<br />
tech-c: GR1378-RIPE<br />
status: SUBTLA<br />
mnt-by: RIPE-NCC-HM-MNT<br />
mnt-lower: RENATER-MNT<br />
changed: hostmaster@ripe.net 20000321<br />
changed: hostmaster@ripe.net 20000322<br />
source: RIPE<br />
<br />
On peut donc en déduire que le préfixe <tt>2001:0660::/35</tt> appartient au réseau FR-RENATER-20000321, qu'il s'agit d'un sub-TLA français géré par Renater. On a aussi les NIC-handles des différents contacts techniques et administratifs.<br />
<br />
==Type ipv6-site==<br />
<br />
Ce type d'objet est uniquement utilisé, pour le moment en tout cas, dans la base 6BONE, c'est à dire sur les adresses de test IPv6 (de type <tt>3FFE::/16</tt>). Il sert a décrire les sites utilisant des adresses en IPv6.<br />
<br />
===Template d'un objet de type ipv6-site===<br />
<br />
Le type ipv6-site est décrit dans un document dont la validité a expiré le draft draft-ietf-ngtrans-6bone-registry-03.txt.<br />
<br />
ipv6-site: [mandatory] [single]<br />
origin: [mandatory] [single]<br />
descr: [mandatory] [single]<br />
location: [optional] [multiple]<br />
country: [mandatory] [multiple]<br />
prefix: [mandatory] [multiple]<br />
application: [optional] [multiple]<br />
tunnel: [optional] [multiple]<br />
native: [optional] [multiple]<br />
contact: [mandatory] [multiple]<br />
remarks: [optional] [multiple]<br />
url: [optional] [multiple]<br />
notify: [optional] [multiple]<br />
mnt-by: [optional] [multiple]<br />
changed: [mandatory] [multiple]<br />
source: [mandatory] [single]<br />
<br />
* ipv6-site: Nom du site.<br />
* origin: Numéro de l'AS (Autonomous System) dont fait partie le site.<br />
* descr: Description succinte de l'objet.<br />
* location: "Coordonnées terrestre" du site, pour plus de détails, se référer au RFC 1876.<br />
* country: Code en 2 lettres (ISO 3166) identifiant le pays du contact administratif de l'organisme auquel appartient le site.<br />
* prefix: Liste des préfixes IPv6 utilisés sur ce site.<br />
* application: Liste des applications disponibles sur le site. En plus du nom de l'application, on indique l'équipement sur lequel elle est accessible. Par exemple "http://www.ipv6.toto.fr".<br />
* tunnel: Les tunnels permettent d'encapsuler un protocole dans un autre. En l'occurrence, il s'agit principalement de tunnels IPv6 au-dessus d'une infrastructure en IPv4. On indique le protocole du tunnel, celui de l'infrastructure, le nom de la machine sur le site qui fait une des extrémités du tunnel, le nom de la machine distante qui fait l'autre bout du tunnel, le site où cette machine se trouve (optionnel), et pour finir le protocole de routage utilisé : STATIC, BGP4+... (optionnel). Par exemple:<br />
<br />
IPv6 in IPv4 popeye.site1.fr -> olive.site2.fr OLIVE-SITE BGP4+<br />
<br />
* native: Similaire a l'attribut "tunnel", à ceci près que cette fois-ci on décrit les connexion natives IPv6. La syntaxe est la même.<br />
* contact: Référence à un objet de type "person" identifiant un contact pour le site.<br />
* remarks: Remarques diverses et variées sur le fonctionnement général du site.<br />
* url: Pointeurs sur quelques pages d'informations supplémentaires à propos du site.<br />
* notify: E-Mail de la personne qui est prévenue lors de toute modification effectuée sur l'objet.<br />
* mnt-by: Référence à un objet de type mntner identifiant les personnes habilitées à modifier l'objet, ainsi que la méthode d'authentification.<br />
* changed: E-Mail de la personne ayant effectuée la dernière mise à jour de l'objet, ainsi que la date de cette modification.<br />
* source: Identification de la base où se trouve cet objet (6BONE, RIPE, APNIC, ARIN, ...)<br />
<br />
===Exemple d'objet de type ipv6-site===<br />
<br />
Si on utilise la commande suivante :<br />
<br />
> '''whois -h whois.6bone.net G6-UTBM'''<br />
<br />
On obtient le résultat suivant :<br />
<br />
ipv6-site: G6-UTBM<br />
origin: AS1717<br />
descr: Université de Technologie de Belfort-Montbéliard<br />
country: FR<br />
prefix: 3FFE:303:22::/48<br />
tunnel: IPv6 in IPv4 testnm.utbm.fr -><br />
ipv6-cisco.ipv6.u-strasbg.fr G6-PIR-GE STTIC<br />
contact: TN1-6BONE<br />
remarks: This object is automatically converted from the RIPE181 registry<br />
changed: noel@dpt-info.u-strasbg.fr 20000315<br />
changed: auto-dbm@whois.6bone.net 20010117<br />
source: 6BONE<br />
<br />
==Création, modification et suppression d'objets==<br />
<br />
Les différentes opérations possibles sur les objets contenus dans les bases de type WHOIS se passent toutes de la même manière, il suffit d'envoyer un mail a une adresse spécifique :<br />
<br />
* auto-dbm@whois.6bone.net pour la base du 6BONE,<br />
* auto-dbm@ripe.net pour la base RIPE.<br />
<br />
Certains sites proposent des interfaces plus pratiques, comme sur le site de Viagenie65 qui permettent de réaliser tous les types d'opérations beaucoup plus facilement en évitant les habituelles erreurs de syntaxes qui ne manquent pas d'arriver en utilisant la technique des mails.<br />
<br />
===Création===<br />
<br />
Avant toute création, il est nécessaire d'avoir au moins un objet de type "person" ou "role" dans la base où l'on souhaite travailler afin d'obtenir un identifiant unique, plus communément appelé NIC-handle. Un objet de type "person" va être créé pour définir une personne physique.<br />
<br />
L'objet de type role, lui, définit plus une fonction qu'un individu et son utilisation principale est de décrire par exemple une équipe technique d'un organisme. Lorsqu'un des membres de cette équipe s'en va ou qu'un nouveau arrive il suffit de modifier le contenu de l'objet de type role, il n'y a pas besoin de mettre à jour les autres objets qui référencent ce NIC-handle. Donc, la technique la plus approprié pour débuter tout enregistrement dans une base est de créer les objets "person" nécessaires afin d'obtenir des NIC-Handles, puis de créer le ou les objets "role" qui référencent les objets de types "person" précédemment créés et c'est ce dernier NIC-Handle obtenu que l'on choisira d'utiliser en priorité pour les contacts techniques ou administratifs. Si on choisit d'utiliser la technique de création par mail, il suffit d'envoyer un template correspondant à l'objet a créer correctement rempli. Pour avoir le format exact et la syntaxe de chaque attribut, il faut utiliser la commande suivante :<br />
<br />
> '''whois -h whois.6bone.net -v ipv6-site'''<br />
<br />
La commande précédente permet d'obtenir une documentation complète de l'objet de type ipv6-site tel qu'il est défini dans la base du 6BONE. Selon le même principe on peut demander la documentation concernant un objet de type person dans la base RIPE :<br />
<br />
> '''whois -h whois.ripe.net -v person'''<br />
<br />
Si jamais l'option "-v" n'est pas prise en compte par le client whois de votre système, il faut télécharger une version prenant quelques options avancées66.<br />
<br />
===Modification===<br />
<br />
Pour la modification par mail, il faut récupérer l'objet tel qu'il est stocké dans la base en utilisant tout simplement la commande whois, modifier le contenu et envoyer le mail ainsi compose.<br />
<br />
===Suppression===<br />
<br />
Pour la suppression, il faut récupérer l'objet dans la base et le renvoyer en ajoutant un attribut supplémentaire "delete" dans le template. Cela donnera quelque chose comme :<br />
<br />
...<br />
remarks: Ceci est un objet de test<br />
delete: Un texte quelconque<br />
changed: test@test.tt 20011111<br />
source: G6BONE<br />
<br />
Toutefois, si l'objet est protégé, il ne pourra être supprimé que si l'on connaît la méthode d'authentification.<br />
<br />
==Problèmes spécifiques à WHOIS==<br />
<br />
Le principal problème des bases WHOIS est qu'il existe deux grandes tendances au niveau du format des données, le style INTERNIC, minimaliste et à la lecture peu aisée et le style RIPE, plus complet et plus facile à comprendre.<br />
<br />
Le second problème, qui en découle, est que les informations ne sont plus centralisées comme cela a été le cas à une époque. Si cela n'est pas trop dramatique en ce qui concerne les adresses IP puisqu'il n'y a que 3 bases (ARIN, APNIC et RIPE), cela est beaucoup plus gênant pour les noms de domaines puisque pratiquement chaque organisme d'enregistrement possède sa propre base. Et bien entendu, chacun utilise des templates plus ou moins différents dérivés des style RIPE et INTERNIC.<br />
<br />
Le troisième problème, qui résulte des deux précédents, est qu'une même information stockée dans deux bases différentes n'aura pas du tout le même format et donc offrira plus ou moins de détails. Pour finir, il faut savoir que ces bases ne sont là qu'à titre d'information et leur contenu n'influence pas le fonctionnement de l'Internet. Il arrive donc que l'information que l'on obtient soit incomplète ou erronée.<br />
<br />
Conclusion, si les bases de type WHOIS sont des alliés précieux pour obtenir des informations rapidement et facilement, une analyse technique un peu plus poussée est souvent nécessaire pour en vérifier la véracité et la complétude.<br />
{{suivi |La standardisation d'IPv6|La standardisation d'IPv6|Bibliographie|Bibliographie}}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=La_standardisation_d%27IPv6&diff=2980La standardisation d'IPv62006-02-27T14:23:09Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi |Historique de la standardisation d’IPv6|Historique de la standardisation d’IPv6|Bases whois|Bases whois}}<br />
__TOC__<br />
<br />
Dans cette première phase, commencée en août 1990 lors de la réunion IETF de Vancouver, le taux de croissance continu de l'Internet met en évidence le gaspillage des adresses dû à la structure en classes de l'adressage IPv4. L'activité a surtout consisté à quantifier le problème et à proposer quelques solutions à plus ou moins court terme.<br />
Un certain nombre de sites ne peuvent plus se contenter d'un simple réseau de classe C pour les équipements qu'ils ont à mettre en réseau. Leurs besoins d'adressage sont intermédiaires entre un réseau de classe C (254 adresses disponibles) et un réseau de classe B (65534 adresses disponibles). Une simulation montre alors que si chacun de ces sites fait une demande de réseau de classe B, compte tenu de la vitesse de croissance de l'Internet, il n'y aurait plus eu de réseaux de classe B disponibles pour de nouvelles allocations vers mars 1994.<br />
<br />
La solution adoptée, qui consiste à attribuer plusieurs réseaux de classe C à un même site va générer un autre problème qui est la saturation de la mémoire disponible pour maintenir les tables de routage sur les routeurs principaux de l'Internet.<br />
<br />
La question de fond commence alors à émerger : faut-il conserver le protocole IP en l'adaptant tant bien que mal aux exigences de l'évolution de l'Internet et en acceptant les contraintes (en particulier la limitation de la croissance à cause de la pénurie prévisible d'adresses), ou bien opter pour la modification de la structure des adresses et refondre le standard IP en acceptant le bouleversement que cela va provoquer ?<br />
<br />
En novembre 1991, lors de la réunion IETF de Santa Fe, les groupes de travail ROAD (''Routing and Addressing'') et ALE (''Address Lifetime Expectations'') sont créés. Ils sont chargés d'étudier les trois problèmes suivants pour guider l'IETF dans ses choix :<br />
*la pénurie des réseaux de classe B,<br />
*la croissance des tables de routage des routeurs principaux,<br />
*la pénurie des adresses de machines.<br />
<br />
==L'émergence des premières idées==<br />
<br />
En mars 1992, lors de la réunion IETF de San Diego, le groupe ROAD rend compte de ses travaux et propose pour le court terme d'adopter CIDR (''Classless Inter-Domain Routing'') qui règle provisoirement le problème de la croissance des tables de routage par l'agrégation des préfixes contigus.<br />
<br />
Pour le long terme, il propose de faire un appel à propositions et de former des groupes de travail chargés d'étudier différentes approches possibles pour un nouveau protocole IP doté d'un espace d'adressage plus grand qu'IPv4. Quatre groupes sont alors au travail avec des propositions sérieuses, il s'agit de :<br />
*PIP : The ‘P’ Internet Protocol, qui introduit la notion d'identificateur et de localisateur,<br />
*TUBA : TCP and UDP with Bigger Addresses ([RFC 1347]) basée sur CLNS,<br />
*IPAE : IP Address Encapsulation, basée sur une extension des adresses IPv4,<br />
*SIP : Simple Internet Protocol, version simplifiée de IPv4 avec des adresses à 64 bits.<br />
<br />
Parallèlement à ce travail, l'IAB produit une version 7 du protocole IP basée sur CNLP (''Connectionless Protocol'') de l'ISO.<br />
<br />
D'autre part, plusieurs propositions indépendantes ont vu le jour. On peut citer notamment CATNIP [RFC 1707], proposant une standardisation de l'interface entre les couches réseau et transport. Après discussions, l'IETF décide de rejeter la proposition de l'IAB et adopte les propositions du groupe ROAD.<br />
<br />
En juillet 1992, lors de la réunion IETF de Cambridge, un appel à propositions est donc lancé à la communauté mondiale pour définir les caractéristiques de l'IP de nouvelle génération (IPng).<br />
<br />
==Définition du cahier des charges du nouvel IP==<br />
<br />
En novembre 1992, lors de la réunion IETF de Washington, CIDR est adopté par l'IESG pour répondre au problème de la croissance trop rapide des tables de routage. Il sera rapidement inclus dans les protocoles de routage externe comme BGP4.<br />
<br />
L'IESG publie le RFC 1380 "Délibérations de l'IESG pour le routage et l'adressage". Ce document fixe un premier cahier des charges que devront respecter les propositions pour le nouveau standard IP, et une grille d'évaluation qui sera utilisée pour les comparer. Ainsi, le nouveau standard devra être capable :<br />
*d'adresser au moins un milliard de réseaux,<br />
*de proposer un plan de transition "sans jour J",<br />
*de prendre en compte à terme la mobilité, la réservation de ressources, les hauts débits, etc.<br />
<br />
Les propositions devront préciser les changements induits sur :<br />
*les machines,<br />
*les routeurs intérieurs et extérieurs,<br />
*la sécurité et l'authentification,<br />
*la gestion du réseau et les outils (ping, traceroute, etc.),<br />
*les modes opératoires et les procédures d'administration,<br />
*les autres protocoles (ARP, RARP, IP, ICMP...).<br />
<br />
Et étudier :<br />
*l'impact sur les performances et la sécurité,<br />
*un schéma complet de routage et d'adressage,<br />
*un plan de déploiement.<br />
<br />
Tous les groupes sont invités à présenter leurs propositions pour la réunion IETF de mars 1993 à Columbus. Lors de cette réunion, les groupes IPAE, PIP, SIP, TUBA présentent leurs premiers travaux et parfois des premières implémentations de leurs protocoles. Les groupes SIP/IPAE fusionnent en gardant le nom de SIP. Mais la compétition entre les groupes qui défendent chacun leur solution est très forte et tend à disperser les efforts tout en ralentissant le processus d'émergence du nouveau standard. Aussi en juillet 1993, lors de la réunion IETF d'Amsterdam, et sous la pression des acteurs industriels, l'objectif est redéfini : il faut arriver rapidement à produire un standard minimum fondé sur tous les éléments techniques pour lesquels il y a consensus. L'IESG est également chargé de clarifier le processus de sélection. Pour limiter la dispersion des efforts due à la concurrence de groupes de travail rivaux, un domaine IPng (IP next generation) est formellement créé pour coordonner leur action [RFC 1454].<br />
En novembre 93, lors de la réunion IETF de Houston, le groupe ALE présente des projections de croissance de l'Internet et propose les mesures suivantes pour prolonger la vie d'IPv4 :<br />
*récupération des numéros de réseaux assignés non utilisés ou sous-utilisés,<br />
*durcissement de la politique d'allocation de réseaux, <br />
*incitation des sites largement pourvus à renuméroter pour restituer une partie de leurs numéros de réseaux ou pour revenir dans l'espace d'adressage de leur fournisseur d'accès.<br />
<br />
Lors de cette même réunion, les groupes de travail PIP et SIP fusionnent dans le groupe SIPP (Simple Internet Protocol Plus [RFC 1710]). L'IESG publie un livre blanc ([RFC 1550]) qui est un appel à propositions pour définir les critères qui serviront à apprécier les propositions des différents groupes de travail sur le nouveau protocole IP. En mars 1994, lors de la réunion IETF de Seattle, le groupe ALE dans son étude sur la croissance du nombre de machines connectées à l'Internet prédit qu'il n'y aura plus d'adresses disponibles en 2008 (à 3 ans près) sur la base du taux de croissance actuel. Il propose de standardiser quelques numéros de réseaux non routables pour les utiliser dans les réseaux IP privés (Intranets).<br />
Parallèlement, une forte incitation sera lancée pour utiliser l'agrégation de routes au moyen du ''Classless Interdomain Routing'' (CIDR).<br />
<br />
L'appel du RFC 1550 sera entendu, et un document définissant les critères de sélection du nouveau protocole IP parmi les candidats restants a pu être élaboré à partir des réponses obtenues. Un appel à commentaires est lancé avec comme objectif de pouvoir disposer d'une version définitive lors de la prochaine réunion de l'IETF en juillet 1994 à Toronto.<br />
<br />
==Le choix d'IPv6==<br />
<br />
Lors de la réunion IETF de Toronto, les projets de protocoles TUBA, CATNIP, SIPP qui ont été finalisés courant 1994 sont analysés. Il en ressort les principaux éléments suivants :<br />
*CATNIP est bien considéré, mais trop jeune. Le risque lié à un protocole très nouveau et le manque de plan de transition le font rejeter.<br />
*TUBA est assez globalement rejeté à cause de la dualité IETF/ISO.<br />
*SIPP, qui est devenu SIPP+ quand la taille de ses adresses a été portée à 16 octets, est adopté : la philosophie principale d'IPv4 est conservée et le nombre de champs de l'en-tête est moindre.<br />
<br />
Recommandation "impérative" est faite d'adopter le protocole SIPP+ comme successeur d'IPv4.<br />
<br />
Le choix de SIPP+ comme nouveau protocole a aussi le mérite d'arrêter la compétition entre groupes de travail rivaux, et de concentrer les efforts autour d'un même projet. Car si le format du paquet IP nouveau est défini, beaucoup de choses restent à faire, et notamment définir la structure de l'adressage qui reste un problème majeur non résolu à cette époque.<br />
<br />
Fin 1994, le nom définitif du protocole est adopté, ce sera IPv6 (la version 5 ayant déjà été attribuée à un protocole expérimental : ST-II, [RFC 1819] et la version 7 réservée au transport sur CLNP). L'IESG approuve alors la création de deux nouveaux groupes de travail :<br />
*IPng (''IP next generation'') va devoir définir complètement les spécifications du nouveau protocole sur les bases de SIPP, en respectant le cahier des charges élaboré.<br />
*NGTRANS (''IPng Transition'') qui s'attèle au problème de la migration de l'Internet d'IPv4 vers IPv6.<br />
<br />
En même temps, les premières implémentations du protocole vont permettre des tests à plus grande échelle, en interconnectant les plates-formes de test IPv6 intra- et inter- continent.<br />
<br />
==Des premières implémentations au démarrage du 6bone==<br />
<br />
Après la publication d'une nouvelle version des recommandations pour le nouveau protocole IP [RFC 1752], en janvier 1995 et la création de l'enregistrement de type AAAA pour supporter les adresses IPv6 dans le DNS d'IPv4 en février, les trois premières souches IPv6 sont produites par DIGITAL, l'INRIA, et le NRL (''US Naval Research Laboratory''). Le 30 mars 1995, les premiers paquets IPv6 sont échangés entre des machines utilisant ces codes.<br />
<br />
Les choses vont s'accélérer à partir de la réunion IETF de fin avril 1995 à Denver qui donne lieu à première diffusion des souches IPv6 existantes. Les implémentations d'IPv6 se multiplient, et début juin 1995, la liste des systèmes supportant IPv6 est la suivante : NetBSD (INRIA), BSDI (NRL), DIGITAL Unix, HP-UX (SICS).<br />
<br />
La fin de l'année 1995 va voir un grand nombre de tests et démonstrations d'interopérabilité d'IPv6 se dérouler. En particulier :<br />
*juillet 1995 : interopérabilité démontrée à la réunion IETF de Stockholm.<br />
*8-10 août 1995 : TCP/IP expo show (SICS, Mitre, INRIA, HP, DIGITAL).<br />
*27-29 septembre 1995 : démonstration publique de machines échangeant du trafic IPv6 à l’Atlanta User Interop.<br />
*7 décembre 1995 : rencontre des implémenteurs IPv6 à la réunion IETF de Dallas.<br />
<br />
La plupart de ces tests d'interopérabilité ont eu lieu sur un même réseau local. La suite logique est de vouloir étendre ces tests dans un contexte de réseau étendu pour tester les équipements et protocoles de routage.<br />
<br />
C'est ainsi que naît l'idée du G6 en France. Ce groupe se donne un double objectif :<br />
*regrouper les expérimentateurs d'IPv6 en France en les aidant à partager leur expérience et en coordonnant des actions communes. <br />
*faire connaître et promouvoir le proctocole IPv6.<br />
<br />
Il tient sa première réunion le 20 décembre 1995.<br />
<br />
Au plan international, c'est à la réunion IETF de Los Angeles en mars 1996 que germe l'idée de créer un réseau mondial de machines implémentant IPv6. Il est appelé le 6bone. Lors de la réunion IETF suivante à Montréal en Juillet 1996, il est imaginé de construire le 6bone à partir d’un ensemble de tunnels reliant entre eux des îlots de machines.<br />
<br />
Le 15 juillet 1996 comme prévu à Montréal, a lieu le démarrage officiel du 6bone reliant l'IMAG en France pour le G6, Uni-C au Danemark et le projet WIDE au Japon. En Décembre 1996, lors de la réunion IETF de San José, le 6bone devient un groupe de travail de l'IETF. Il est décidé de structurer géographiquement le réseau, tous les tunnels d'un même pays arrivant sur un ou quelques noeuds qui échangent eux-même leurs trafics.<br />
<br />
Pendant toute l'année 1997, le 6bone raccorde de plus en plus de sites, jouant son rôle de terrain d'expérimentation pour IPv6. Dans le domaine du routage, il utilise d'abord RIPng [RFC 2080] qui est une adaptation à IPv6 de RIP et IDRPv6, puis BGP4+ qui est une adaptation à IPv6 de BGP4.<br />
<br />
Il permet surtout de déployer et de tester à grande échelle les deux plans d'adressage qui se succèdent en cette année 1997.<br />
<br />
==<div id="plan">Mise au point du plan d'adressage d'IPv6</div>==<br />
<br />
Comme on l'a vu précédemment, la structure de l'adressage n'a pas été définie lors de l'adoption du nouveau format de paquet IP en juillet 1994. La seule chose de sûre est que les adresses IPv6 ont 128 bits de long. Une des premières tâches a donc été de définir comment ces 128 bits allaient être utilisés. <br />
<br />
Cela va donner lieu à beaucoup d'activité et à des échanges passionnés tant les enjeux sont importants. En effet, les principaux acteurs que sont les fournisseurs d'accès au réseau, leurs clients, et les constructeurs d'équipements routage ou de postes de travail ont des intérêts et donc des points de vue qui peuvent être sensiblement opposés. Par exemple les fourniseurs d'accès sont plutôt enclins à garder captifs leurs clients en maîtrisant l'espace d'adressage, alors que les clients souhaitent garder la possibilité de changer de fournisseurs facilement. Les constructeurs quant à eux souhaitent que les protocoles soient simples à implémenter.<br />
<br />
Plusieurs plans d'adressages ont été étudiés pour arriver finalement au plan d'adressage dit [[Unicast Global|agrégé]] basé sur 3 niveaux d'agrégation. <br />
<br />
En juillet 1995, lors de la réunion IETF de Stockholm, un premier débat oppose les partisans d'un plan d'adressage géographique aux fournisseurs d'accès. Ces derniers souhaitent pouvoir faire de l'agrégation d'adresses (type CIDR) indépendamment des critères géographiques. Les premières spécifications d'IPv6 sont publiées sous forme d'une suite de RFC ([RFC 1883], [RFC 1884], [RFC 1885], [RFC 1886], [RFC 1887]) lors de la réunion IETF de Dallas en décembre 1995. Ils spécifient complètement la structure des en-têtes du paquet IPv6, le plan d'adressage est structuré par fournisseur d'accès à l'Internet.<br />
<br />
En décembre 1996, lors de la réunion IETF de San José la proposition "8+8" qui découpe les 16 octets de l'adresse en 8 octets fournisseur d'accès et 8 octets utilisateur est discutée. Elle a pour objectif de limiter la croissance des tables de routage et de rendre l'utilisateur indépendant de son fournisseur en effectuant une traduction partielle d'adresse sur les 8 octets réservés au fournisseur d'accès en sortie de site. En mars 1997, lors de la réunion IETF de Palo Alto, la proposition 8+8 qui est devenue GSE (''Global, Site and End-system'') est à nouveau discutée, mais est rejetée.<br />
<br />
===Plan d'adressage géographique (geographic-based unicast address)===<br />
<br />
C'est l'un des premiers plans d'adressage proposés. Il découpe hiérarchiquement les adresses en entités géographiques (continents, pays, région, ville, etc.). Ce plan est aujourd'hui abandonné, car difficile à mettre en œuvre pour des raisons d'ordre technique notamment. Il n'est valable que dans des situations monopolistiques où les opérateurs contrôlent une partie de territoire.<br />
<br />
Les adresses étaient caractérisées par le préfixe 8000::/3.<br />
<br />
===Plan d'adressage fournisseur (provider-based unicast address) ===<br />
<br />
Ce type d'adresse (cf. figure 17-4) est décrit dans le RFC 2073, classé historique. Une adresse de ce type avait pour préfixe <tt>4000::/3</tt> et possèdait 5 niveaux hiérarchiques :<br />
<br />
[[image:CS214.gif]]<br />
<br />
{|<br />
|+Allocation des valeurs des registry ID<br />
!registry ID || Nature<br />
|-style="background:silver" <br />
|10000 || IANA (Internet Assigned Numbers Authority)<br />
|-<br />
|01000 || RIPE NCC (Réseaux IP Européens, Network Coordination Center)<br />
|-style="background:silver" <br />
|11000 || InterNIC (Internet Network Information Center)<br />
|-<br />
|10100 || APNIC (Asia-Pacific Network Information Center)<br />
|}<br />
<br />
<br />
*Le premier niveau avait une longueur fixée à 5 bits (<tt>i=5</tt>) et ses valeurs possibles étaient donné par le tableau précédent.<br />
*Un fournisseur d'accès à l’Internet était identifié par un numéro qu'il obtient d’un des organismes mentionnés ci-dessus. <br />
<br />
De même, un souscripteur obtienait son identificateur de son fournisseur. C’est un mot de 24 bits suivi de 8 bits laissés à zéro (donc <tt>k=32</tt>). <br />
<br />
Les deux derniers niveaux, gérés par le souscripteur, étaient respectivement le numéro de sous-réseau (<tt>l=16</tt>) et l'identificateur de l'interface (48 bits), typiquement son adresse MAC.<br />
Dans ce plan d'adressage, les adresses appartiennent aux fournisseurs de connectivité IP et non pas aux utilisateurs. Tout changement de fournisseur implique donc pour un client de renuméroter toutes ses machines. De plus, si un client est abonné à un "petit" fournisseur lui-même revendant de la connectivité IP d'un plus gros fournisseur, et si le fournisseur intermédiaire décide de changer de fournisseur principal, le client final doit renuméroter tout son réseau. Ceci a été jugé inacceptable.<br />
<br />
===Adresses de test dans le plan d'adressage fournisseur===<br />
<br />
Ces adresses (cf. figure 17-5) sont décrites dans le RFC 1897. L'intérêt principal de ces adresses de test est de fournir un algorithme simple basé sur les adresses IPv4 existantes afin de construire des adresses IPv6 pour des équipements expérimentaux sans avoir à demander de délégation d'autorité. Ces adresses ont été largement utilisées lors de la création du 6bone:<br />
<br />
[[image:CS215.gif]]<br />
<br />
===Plan d'adressage GSE===<br />
<br />
Le plan d'adressage fournisseur a été largement critiqué, surtout par les opérateurs, qui tiennent essentiellement aux problèmes de renumérotation.<br />
<br />
L'approche GSE (''Global, Site and End-system'') propose une construction dynamique des adresses avec une partie basse fixe d'identificateur globalement unique (au niveau de l'Internet) sur 64 bits et une partie haute variable identifiant le fournisseur d'accès, insérée à la volée par le routeur de sortie du site.<br />
<br />
Tant qu'un paquet reste à l'intérieur du site, la partie haute des adresses sources des paquets émis depuis le site est forcée à zéro. Il en va de même pour les adresses destinations des paquets reçus depuis l'extérieur à destination d'une machine du site. La partie haute des paquets sortants est positionnée à la "bonne" valeur par le routeur de sortie. Si le site est connecté à plusieurs fournisseurs d'accès, ce routeur sélectionne cette valeur en fonction du fournisseur choisi. Ceci facilite le changement de fournisseur en éliminant la nécessité de renumérotation manuelle. En outre, la gestion d'un site dépendant de plusieurs fournisseurs est facilitée.<br />
<br />
Le plan d'adressage proposé par GSE présente des avantages :<br />
*GSE facilite la renumérotation du réseau puisqu'il suffit de changer l'adresse dans le routeur en frontière ;<br />
*GSE supporte facilement les réseaux à attachements multiples (multihomed). Les réseaux ayant plusieurs attachements à des fournisseurs d'accès différents posent un problème d'adressage dans les plans d'adressages classiques~: si une station choisit l'une des adresses possibles, des exceptions doivent être introduites dans les tables de routage de l'Internet. Si la station prend toutes les adresses possibles, elle ne sait quelle adresse source optimale utiliser. Avec GSE l'adresse de la source est construite dynamiquement au moment de la traversée du routeur en frontière, elle est donc la meilleure pour une destination donnée.<br />
<br />
Par contre GSE présente plusieurs inconvénients graves :<br />
*TCP associe un contexte en fonction des adresses IP. Si celles-ci changent, la connexion doit quand même être maintenue, d'où l'existence d'un identifiant unique au niveau mondial ; cela implique une refonte de TCP qui n'est pas à l'ordre du jour à l'IETF ;<br />
*le calcul des checksums doit être modifié puisque la station ne connaît qu'une partie de l'adresse ; <br />
*la question de l'enregistrement des adresses dans le DNS inverse, faisant la correspondance entre une adresse et un nom de machine, n'est pas résolue ; <br />
*la partie identificateur est supposée "globalement" unique ; on ne sait pas s'il faut une garantie absolue, et si oui, comment la vérifier ; <br />
les mécanismes de mascarade (utiliser l'adresse source d'une autre machine) sont mal compris, et il semble que l'utilisation de sécurité active (IPsec) soit quasiment obligatoire.<br />
<br />
==Mise au point finale du cœur des spécifications d’IPv6==<br />
<br />
En août 1997, lors de la réunion IETF de Munich, le protocole BGP4+ est choisi de préférence à BGP5 (la possibilité d'avoir des numéros de systèmes autonomes codés sur 4 octets au lieu de 2 dans la version IPv4 n’est pas retenue).<br />
<br />
En décembre 1997, lors de la réunion IETF de Washington, le rapport d’un test d’interopérabilité fait par un laboratoire de l’UNH (Université du New Hampshire) est présenté au groupe IPng. Ce test qui met en oeuvre 10 machines et 6 routeurs, montre que 90% des machines et 70% des routeurs interopèrent bien (en RIPng ou BGP4+ pour ces derniers). Lors de cette même réunion, les règles d’attribution des TLA et NLA et les critères définissant les niveaux d'agrégation donnent lieu à beaucoup de controverses, ces éléments ne pourront être finalisées que mi 1998.<br />
<br />
Pendant cette année 1998, une intense activité de test et de déploiements de réseaux expérimentaux, permet d’affiner les propositions de standards, les implémentations (machines et routeurs) et de valider les plans d’adressage expérimentaux et de production.<br />
<br />
En octobre 1998, ESnet (''Energy Sciences Network'') établit une connexion IPv6 sur ATM avec les réseaux CAIRN, Internet2/vBNS et CA*net2, puis, en décembre avec WIDE (Japon). ESnet crée aussi l'initiative 6REN (''IPv6 Research and Education Networks Initiative'') qui a pour but de donner au monde de l'enseignement et la recherche américain un service IPv6 de production en complément du 6bone qui est un réseau d’expérimentation et ne peut assurer la continuité de service necessaire à un réseau de production. Le 6REN est à considérer comme un équivalent du NANOG dédié à IPv6. C’est aussi ESnet qui assure la connecticité 6BONE/6REN. On peut aussi noter à cette époque des ébauches de projets similaires en australie (AARNET: ''Australian Academic and Research Network'') et en chine (CERNET: ''China Education and Research Network''). En France, le G6bone effectue sa migration dans le nouveau plan d’adressage de test.<br />
<br />
Pendant la réunion IETF de décembre 1998 à Orlando, le groupe IPng décide de fusionner les codes IPv6 INRIA, NRL, et KAME dans la souche KAME regroupant ainsi sur une seule souche les efforts d’implémentation sous système d’exploitation BSD.<br />
<br />
Cette fin d’année 1998 marque une nouvelle étape dans l’histoire d’IPv6, en effet, 15 RFC ont été publiés (dont 4 sont passés en Draft Standard), fixant ainsi le cœur des spécifications d’IPv6 et définissant un premier plan d’adressage aggrégé. Quatre ans après l’étape décisive de fin 1994 qui avait vu fixer les éléments consensuels d’alors (les 128 bits d’adresse, et le format d’en-tête simplifié), cette étape fixe de la même manière ce qui peut l’être, laissant à la suite du processus le soin de résoudre les nombreux problèmes encore en suspens (migration, mobilité, DNS, autoconfiguration, etc...).<br />
<br />
==Les schémas de migration et d’intégration IPv4/IPv6==<br />
<br />
Bien que la standardisation d’IPv6 ne soit pas achevée, loin s’en faut, les membres de l’IETF, considèrent qu’il faut maintenant s’attaquer à un nouveau problème de taille : celui de la transition d’IPv4 vers IPv6. Lors de la réunion intérimaire de l’IETF de février 1999 (qui a lieu à l’IMAG à Grenoble) les propositions de schémas de migration et d’intégration IPv4/IPv6 sont si nombreux qu’il est décidé d’en faire une taxonomie pour y voir plus clair et faire naître des convergences.<br />
<br />
Au premier trimestre 2000, la plupart des propositions sont formalisées par des RFC. On peut les répartir dans les trois grandes familles suivantes :<br />
<br />
Des outils au niveau réseau comme :<br />
*les adresses IPv4 compatibles : utilisées au début quand il n’y avait que très peu de machines IPv6,<br />
*les adresses IPv4 mappées : qui permettent à des machines IPv4 de communiquer avec des machines IPv6,<br />
*les adresses ’6to4’ : qui permettent de joindre un site IPv6 à travers un réseau IPv4 sans configuration de tunnels,<br />
*les tunnels configurés : utilisés pour le déploiement des réseaux de test, mais comme tous les tunnels, ils réduisent le MTU et empilent deux routages,<br />
*les générateurs automatiques de tunnels (tunnels brokers) : solution permettant à une machine d’obtenir une connectivité IPv6 sans avoir intervention manuelle du gestionnaire du site offrant cette connectivité.<br />
<br />
Des protocoles de traduction d’adresses comme :<br />
*SIIT [RFC 2765] : qui permet à des machines IPv6 de communiquer avec des machines IPv4 au moyen de traducteurs d’adresses, situés en bordure des domaines IPv4/IPv6. Ces traducteurs traitent les paquets IP et ICMP, sans introduire d’état dans le réseau,<br />
*NAT-PT [RFC 2766] : semblable à SIIT, il utilise des adresses globales IPv6 (et non pas des adresses dérivées d’IPv4). Les traducteurs de bordure modifient les adresses et les en-tête, ils doivent disposer d’un préfixe IPv4,<br />
*DSTM [BTM-id] : qui permet de résoudre tous les cas de communication entre les mondes IPv6 et IPv4 sans nécessiter de portage des applications IPv4. Les traducteurs de bordure doivent disposer d’un préfixe IPv4.<br />
Des protocoles intervenant au niveau TCP ou des applicatifs comme :<br />
*BIS [RFC 2767] : qui permet à des aplications IPv4 de fonctionner sur les machines IPv6 en effectuant les traductions d’adresses nécessaires dans le noyau du système d’exploitation,<br />
*SOCKS [RFC 3089] : fonctionnellement similaire à BIS, c’est une extension du protocole SOCKS (défini dans le RFC 1928) à la communication entre des piles TCP/IPv4 et TCP/IPv6.<br />
<br />
Durant le reste de l’année 2000 et toute l’année 2001, ces protocoles sont retravaillés, notamment pour prendre mieux en compte les aspects sécurité et dénis de service ainsi que les mécanismes de mise à jour du DNS qui peuvent ou doivent leur être associés.<br />
<br />
==La longue marche vers un Internet IPv6==<br />
<br />
Le 14 juillet 1999, presque 3 ans jour pour jour après le démarrage du 6bone, l’IANA annonce que la première délégation officielle de préfixes IPv6 vient d’être effectuée auprès du RIPE-NCC, de l’ARIN, et de l’APNIC. On peut considérer que cette date marque la naissance du nouvel Internet IPv6. Ces organismes vont alors commencer à distribuer des sTLA à un rythme tel qu’indiqué dans le tableau suivant.<br />
<br />
{|<br />
|+Allocation des sTLA IPv6 par les RIR<br />
! APNIC || ARIN || RIPE-NCC<br />
|-style="background:silver" <br />
|mai 2000 ||13 sTLA || 3 sTLA || 14 sTLA<br />
|-<br />
|décembre 2000 ||21 sTLA || 10 sTLA || 23 sTLA<br />
|-style="background:silver" <br />
|décembre 2001 ||48 sTLA || 20 sTLA || 51 sTLA<br />
|}<br />
<br />
Comme les chiffres le montrent, ce déploiement, s’il est bien réel, reste limité en volume et assez hétérogène géographiquement. L’hétérogénéité géographique s’explique par le fait que les utilisateurs nord américains ne sont pas en situation de pénurie d’adresses IPv4, et donc ne sollicitent que faiblement leurs opérateurs en connectivité et adresses IPv6. Le déploiement limité sur les autres continents s’explique par la non complétude de la standardisation des protocoles IPv6. C’est le deuxième axe de travail de l’IETF (en plus de celui sur les mécanismes de transition/intégration) durant les années 2000 et 2001, car cette complétude constitue un pré-requis à un développement à grande échelle d’IPv6.<br />
<br />
En décembre 1999, le RFC 2740 standardise la version IPv6 d’OSPF, et en juillet 2000, lors de la réunion IETF de Pittsburgh, une communication dans le groupe de travail OSPF informe les participants que le logiciel de routage Zebra dispose d’une première version IPv6 d’OSPF implémentée et testée avec succès.<br />
<br />
En juillet et août 2000, les RFC 2874 et RFC 2894 sont publiés, ils concernent des extensions au DNS pour l’aggrégation et la renumérotation ainsi que la renumérotation de routeurs. En fin d’année 2000, les RFC 3007 et RFC 3008 concernant la sécurisation des DNS sont publiés. Ce sont les compléments indispensables pour gérer la dynamicité introduite par les mécanismes de renumérotation.<br />
<br />
Début 2001, le RFC 3041 améliore la protection de la vie privée ou professionnelle qui pouvait être mis en cause par le mécanisme d’autoconfiguration. En effet, ce dernier, en construisant un identifiant d’interface unique et permanent à partir de l’adresse Ethernet aurait pu permettre la tracabilité dans le temps ou dans l’espace du possesseur d’une machine IPv6. L’introduction d’une durée de vie limitée pour les identifiants d’interface et leur remplacement régulier par d’autres règle cette question.<br />
<br />
Mi 2001, le groupe de travail IPng constate qu'il a presque terminé sa tâche. Il décide de changer de nom ; un nouveau groupe est créé, IPv6, qui a pour but de terminer les documents en attente et de traiter de points encore en débat (renumérotation automatique, adressage de site, ...). Un autre groupe, multi6, est créé pour s'occuper du problème de la multi-domiciliation.<br />
<br />
En août 2001, le RFC 3152 met en place la délégation de la racine (<tt>ip6.arpa</tt>) de l’arbre de nommage inverse pour IPv6, complétant ainsi le dispositif pour le DNS.<br />
<br />
Fin 2001, les travaux de standardisation sont principalement centrés sur les mécanismes de transition comme DSTM et BIA (''Bump In the API'') ainsi que sur la gestion du multicast IPv6. Des liens sont aussi établis avec la téléphonie mobile dont la version UMTS a choisi IPv6 comme technologie de transport pour pallier les insuffisances d’IPv4 en matière d’espace d’adressage.<br />
<br />
Début 2002, l’ensemble des systèmes d’exploitation sont équipés d’une double pile IPv4 et IPv6, la plupart des routeurs implémentent au moins un protocole de routage interne (RIPng) et un protocole de routage externe (BGP4+). Même si la suite des protocoles IPv6 n’est pas encore aussi complète qu’il serait souhaitable, l’Internet IPv6 est bien en cours de déploiement, et des noeuds importants comme le Startap, aux Etats-Unis, le Nspixp au Japon ou le Sfinx en France échangent désormais du trafic natif IPv6.<br />
{{suivi |Historique de la standardisation d’IPv6|Historique de la standardisation d’IPv6|Bases whois|Bases whois}}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Historique_de_la_standardisation_d%E2%80%99IPv6&diff=2979Historique de la standardisation d’IPv62006-02-27T14:21:46Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi |Les applications spécifiques|Les applications spécifiques|La standardisation d'IPv6|La standardisation d'IPv6}}<br />
Cette annexe décrit les principales étapes qui jalonnent la standardisation d’IPv6, depuis la prise en compte de la nécessité d’un nouveau protocole jusqu’à la production de standards. Ce processus est toujours en cours même si une grande partie du chemin a déjà été parcourue.<br />
<br />
==<div id="stand">La standardisation de l'Internet</div>==<br />
<br />
Il est difficile de comprendre comment est né IPv6, et comment le protocole continue d’évoluer, si l’on ne connaît pas le processus de standardisation des protocoles utilisés dans l’Internet.<br />
Les organismes qui pilotent la standardisation de l’Internet sont l’IETF, l’IESG, l’IAB, l’ISOC et l’ICANN. Le résultat final de l’activité de standardisation est la production de documents appelés RFC (Request for Comments) dont certains sont des standards. L’ensemble du processus de standardisation est décrit dans le RFC 2026.<br />
<br />
===L'IETF (''Internet Engineering Task Force'')===<br />
<br />
L’activité au sein de l'’ETF est organisée en groupes de travail (''working group''). Les groupes agissant autour d’un même thème sont regroupés dans un Domaine (Area), comme le routage, la gestion des réseaux, la sécurité... Chaque Domaine est coordonné par un directeur (Area Director). L’ensemble des directeurs de Domaines compose l’IESG (voir ci-après).<br />
Les groupes de travail de l’IETF sont constitués de personnes volontaires et bénévoles qui sont motivées pour faire évoluer les standards de l’Internet sur la base de leur expérience acquise à partir de mises en œuvre et d’essais concrets. Toute personne intéressée (et ayant des disponibilités) peut faire partie d’un groupe de travail IETF. La participation à l’IETF et à ses groupes de travail est donc le fait d’individus proposant des contributions techniques plutôt que de représentants formels d’organisations.<br />
Chaque groupe de travail définit ses objectifs dans une charte, qu’il soumet à l’IESG lors de son processus de constitution. Le groupe est dirigé par un ou plusieurs présidents (''Working Group Chairs''). Le fonctionnement des groupes de travail de l’IETF est décrit en détail dans le RFC 2418.<br />
Dans un groupe le travail, les échanges de points de vue et d’expériences visant à élaborer les projets de standards (''Internet Drafts''), se font essentiellement par courrier électronique. Trois réunions annuelles permettent aux membres des groupes de se rencontrer pour une interaction plus directe. Lorsqu’un consensus est atteint, le groupe en demande la publication en tant que RFC (''Request For Comments'').<br />
Quand un groupe considère que ses objectifs sont atteints, il se dissout.<br />
Un certain nombre de groupes et sous-groupes IETF travaillent actuellement sur IPv6 ; on peut citer notamment:<br />
*IPng (aujourd'hui IPv6) : principal groupe de travail sur la production de protocoles liés à IPv6.<br />
*NGtrans (aujourd'hui v6ops) : étudie les modalités de la migration d’IPv4 vers IPv6. Ce groupe gère le déploiement du 6bone, un réseau expérimental IPv6 interconnectant des sites de test à travers le monde. <br />
Les groupes de travail de l’IETF doivent faire preuve d’esprit de coopération, ainsi que d’un haut degré de maturité technique ; les participants à l’IETF reconnaissent que les plus grands bénéfices pour tous les membres de la communauté de l’Internet proviennent du développement coopératif des protocoles et services (voir http://www.ietf.org pour plus de détails).<br />
<br />
===L'IESG (''Internet Engineering Steering Group'')===<br />
<br />
L’IESG est responsable de la direction des activités techniques de l’IETF. Il est composé des directeurs de Domaines (il y en a 7 actuellement) et du président de l’IETF qui est aussi le président de l’IESG. L’IESG administre le processus de standardisation de l’Internet suivant des règles et procédures détaillées dans le RFC 2028.<br />
C'est donc l’IESG qui décide de l’évolution du statut des spécifications techniques émises par les groupes de travail, ce qui peut élever certaines d’entre elles au rang de Standard Internet. L’IESG approuve également la constitution des nouveaux groupes de travail.<br />
<br />
===Les RFC (''Request For Comments'')===<br />
<br />
Les RFC sont les documents officiels de l’Internet ; ils sont disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/. Un RFC est complètement identifié par le numéro qui lui est attribué lors de sa publication. Ce numéro n'a pas de signification ; il est attribué par ordre chronologique de publication. Les premiers RFC sont sortis en 1969 ; début 2006, nous en sommes au numéro 4400, pour un flux supérieur à 200 RFC par an.<br />
Il existe plusieurs types de RFC d’importance différente pour la communauté IETF. On distingue deux catégories principales : ceux faisant partie du processus de standardisation (''Standard Track'') et les autres.<br />
<br />
Les documents entrant dans la première catégorie suivent un parcours bien défini. Ils sont d’abord publiés comme "Internet Drafts" par le groupe de travail. Ce sont des documents de travail à durée de vie limitée, disponibles en ligne sur les mêmes serveurs que les RFC. Lorsqu’un consensus semble atteint, le responsable lance un appel aux derniers commentaires dans le groupe. Il transmet ensuite le document à l’IESG qui, à son tour, lance un appel aux derniers commentaires à tout l’IETF. S’il n’y a pas d’objections majeures, le document est alors publié comme RFC avec un statut de (''Proposed Standard'').<br />
<br />
Après une période où se succèdent mises en œuvre et retours d’informations sur le protocole décrit, le groupe de travail auteur revoit le document.<br />
<br />
Si seuls des changements mineurs sont nécessaires, il demande alors à l’IESG de le faire avancer en le publiant en tant que nouveau RFC mais avec un statut de Draft Standard) après un nouvel appel à commentaires. Si les changements sont majeurs, le nouveau RFC garde le statut de Proposed Standard.<br />
<br />
Suit alors une nouvelle période de mises en œuvre et de retours d’informations où l’on doit faire la preuve de l’interopérabilité de deux implantations indépendantes. Puis le responsable du groupe de travail demande à l’IESG de faire avancer le document en le publiant (après un dernier appel à commentaires) en tant que RFC avec un statut de type "Standard". Il faut noter qu’à chaque étape, un nouveau numéro de RFC est attribué. Un RFC peut passer à l’état "historique" si son utilisation est devenue déconseillée. S’il est remplacé par un autre il devient "obsolète".<br />
<br />
La publication d’un RFC hors du processus de standardisation est plus facile. L’IESG peut directement faire publier un RFC avec un statut de type "Information", "Experimental" ou "''Best Current Practice''". Un RFC "Information" documente un protocole ou une approche particulière d’un problème. Il peut aussi donner des informations d’intérêt général. Il n’a aucune valeur de standard. Un RFC "Expérimental" décrit un protocole nécessitant que l’on mène des expériences avant de décider ou non d’entrer dans le processus de standardisation. Un RFC "''Best Current Practice''" documente une pratique d’ingénierie recommandée. La répartition par types des RFC édités en 2001 est donnée dans figure 17-2.<br />
<br />
===L'ISOC (Internet Society)===<br />
<br />
L’ISOC est une organisation internationale s’occupant de la croissance et de l’évolution de l’Internet à l’échelle mondiale et des aspects sociaux, politiques et techniques de son utilisation. Les membres de l’ISOC sont des personnes physiques ou morales. L’ISOC est dirigée par un Bureau des Administrateurs élu par les membres individuels.<br />
La standardisation de l’Internet est une activité chapeautée par l’ISOC, le Bureau des Administrateurs étant responsable de l’approbation des procédures et des règles du processus de standardisation de l’Internet.<br />
Le moyen selon lequel les membres du Bureau des Administrateurs de l’ISOC sont choisis, et les autres aspects concernant le fonctionnement de l’Internet Society sont décrits dans le document ISOC By-Laws [RFC 2135] et http://www.isoc.org.<br />
<br />
===L’IAB (Internet Architecture Board)===<br />
<br />
L’IAB est chargé par les Administrateurs de l’ISOC de fournir une supervision de l’architecture de l’Internet et de ses protocoles. L’IAB désigne le président de l’IETF et approuve les autres candidats pour l’IESG, présentés par le comité de nomination. L’IAB est aussi responsable de l’examen et de l’approbation des chartes des nouveaux groupes de travail proposés.<br />
<br />
L’IAB supervise le processus utilisé pour créer des Standards Internet et sert de cour d’appel pour les réclamations comme par exemple une violation des procédures de standardisation, ou pour un conflit entre les groupes de travail de l’IETF et l’IESG. L’IAB conseille l’IETF et l’ISOC en matière technique, politique, d’architecture, de procédure se rapportant à l’Internet et aux technologies associées. Les membres de l’IAB sont nommés par un comité (le Nomcom) et approuvés par le conseil d’administration de l’ISOC.<br />
<br />
===L’ICANN (Internet Corporation for Assigned Names and Numbers)===<br />
<br />
L’ICANN est un organisme international créé en octobre 1998 pour remplacer l’IANA (Internet Assigned Numbers Authority) qui n’était contrôlé que par le gouvernement américain. <br />
Beaucoup de spécifications de protocoles comportent des nombres, mots clés et paramètres qui doivent être affectés de manière unique, par exemple les numéros de versions, les numéros de protocoles, les numéros de ports et de MIB (Management Information Base). C'est l’ICANN qui affecte les valeurs de ces paramètres pour l’Internet. L’ICANN publie aussi les tables de toutes les valeurs affectées dans des RFC nommés Assigned Numbers. L’ICANN sert aussi de "sommet de la pyramide" pour la gestion des domaines de noms (DNS) et l’affectation des adresses et en établit les règles.<br />
<br />
===Les RIR (Regional Internet Registries)===<br />
<br />
Les RIR ou RIAR (''Regional Internet Address Registries'') reçoivent une délégation de l’ICANN pour distribuer les adresses IPv4 et IPv6. Ils sont au nombre de quatre actuellement, répartis sur 4 continents pour assurer une gestion de "proximité" à cette échelle. Ce sont :<br />
*APNIC : Asia Pacific Network Information Centre,<br />
*ARIN : American Registry for Internet Numbers,<br />
*RIPE-NCC : Réseaux IP Européen (Network Coordination Centre),<br />
*LACNIC : Réseaux d'Amérique Latine et des Caraïbes. <br />
<br />
Un cinquième, l’AFRINIC destiné à assurer la couverture du continent Africain est en cours de gestation (l’Afrique dépend actuellement du RIPE et de l’APNIC). En 2001, sept préfixes IPv4 de longueur 16 ont été affectés aux RIR pour être distribués aux opérateurs<br />
{{suivi |Les applications spécifiques|Les applications spécifiques|La standardisation d'IPv6|La standardisation d'IPv6}}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Historique_de_la_standardisation_d%E2%80%99IPv6&diff=2978Historique de la standardisation d’IPv62006-02-27T14:19:53Z<p>Bruno Deniaud: /* Les RIR (Regional Internet Registries) */</p>
<hr />
<div>Cette annexe décrit les principales étapes qui jalonnent la standardisation d’IPv6, depuis la prise en compte de la nécessité d’un nouveau protocole jusqu’à la production de standards. Ce processus est toujours en cours même si une grande partie du chemin a déjà été parcourue.<br />
<br />
==<div id="stand">La standardisation de l'Internet</div>==<br />
<br />
Il est difficile de comprendre comment est né IPv6, et comment le protocole continue d’évoluer, si l’on ne connaît pas le processus de standardisation des protocoles utilisés dans l’Internet.<br />
Les organismes qui pilotent la standardisation de l’Internet sont l’IETF, l’IESG, l’IAB, l’ISOC et l’ICANN. Le résultat final de l’activité de standardisation est la production de documents appelés RFC (Request for Comments) dont certains sont des standards. L’ensemble du processus de standardisation est décrit dans le RFC 2026.<br />
<br />
===L'IETF (''Internet Engineering Task Force'')===<br />
<br />
L’activité au sein de l'’ETF est organisée en groupes de travail (''working group''). Les groupes agissant autour d’un même thème sont regroupés dans un Domaine (Area), comme le routage, la gestion des réseaux, la sécurité... Chaque Domaine est coordonné par un directeur (Area Director). L’ensemble des directeurs de Domaines compose l’IESG (voir ci-après).<br />
Les groupes de travail de l’IETF sont constitués de personnes volontaires et bénévoles qui sont motivées pour faire évoluer les standards de l’Internet sur la base de leur expérience acquise à partir de mises en œuvre et d’essais concrets. Toute personne intéressée (et ayant des disponibilités) peut faire partie d’un groupe de travail IETF. La participation à l’IETF et à ses groupes de travail est donc le fait d’individus proposant des contributions techniques plutôt que de représentants formels d’organisations.<br />
Chaque groupe de travail définit ses objectifs dans une charte, qu’il soumet à l’IESG lors de son processus de constitution. Le groupe est dirigé par un ou plusieurs présidents (''Working Group Chairs''). Le fonctionnement des groupes de travail de l’IETF est décrit en détail dans le RFC 2418.<br />
Dans un groupe le travail, les échanges de points de vue et d’expériences visant à élaborer les projets de standards (''Internet Drafts''), se font essentiellement par courrier électronique. Trois réunions annuelles permettent aux membres des groupes de se rencontrer pour une interaction plus directe. Lorsqu’un consensus est atteint, le groupe en demande la publication en tant que RFC (''Request For Comments'').<br />
Quand un groupe considère que ses objectifs sont atteints, il se dissout.<br />
Un certain nombre de groupes et sous-groupes IETF travaillent actuellement sur IPv6 ; on peut citer notamment:<br />
*IPng (aujourd'hui IPv6) : principal groupe de travail sur la production de protocoles liés à IPv6.<br />
*NGtrans (aujourd'hui v6ops) : étudie les modalités de la migration d’IPv4 vers IPv6. Ce groupe gère le déploiement du 6bone, un réseau expérimental IPv6 interconnectant des sites de test à travers le monde. <br />
Les groupes de travail de l’IETF doivent faire preuve d’esprit de coopération, ainsi que d’un haut degré de maturité technique ; les participants à l’IETF reconnaissent que les plus grands bénéfices pour tous les membres de la communauté de l’Internet proviennent du développement coopératif des protocoles et services (voir http://www.ietf.org pour plus de détails).<br />
<br />
===L'IESG (''Internet Engineering Steering Group'')===<br />
<br />
L’IESG est responsable de la direction des activités techniques de l’IETF. Il est composé des directeurs de Domaines (il y en a 7 actuellement) et du président de l’IETF qui est aussi le président de l’IESG. L’IESG administre le processus de standardisation de l’Internet suivant des règles et procédures détaillées dans le RFC 2028.<br />
C'est donc l’IESG qui décide de l’évolution du statut des spécifications techniques émises par les groupes de travail, ce qui peut élever certaines d’entre elles au rang de Standard Internet. L’IESG approuve également la constitution des nouveaux groupes de travail.<br />
<br />
===Les RFC (''Request For Comments'')===<br />
<br />
Les RFC sont les documents officiels de l’Internet ; ils sont disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/. Un RFC est complètement identifié par le numéro qui lui est attribué lors de sa publication. Ce numéro n'a pas de signification ; il est attribué par ordre chronologique de publication. Les premiers RFC sont sortis en 1969 ; début 2006, nous en sommes au numéro 4400, pour un flux supérieur à 200 RFC par an.<br />
Il existe plusieurs types de RFC d’importance différente pour la communauté IETF. On distingue deux catégories principales : ceux faisant partie du processus de standardisation (''Standard Track'') et les autres.<br />
<br />
Les documents entrant dans la première catégorie suivent un parcours bien défini. Ils sont d’abord publiés comme "Internet Drafts" par le groupe de travail. Ce sont des documents de travail à durée de vie limitée, disponibles en ligne sur les mêmes serveurs que les RFC. Lorsqu’un consensus semble atteint, le responsable lance un appel aux derniers commentaires dans le groupe. Il transmet ensuite le document à l’IESG qui, à son tour, lance un appel aux derniers commentaires à tout l’IETF. S’il n’y a pas d’objections majeures, le document est alors publié comme RFC avec un statut de (''Proposed Standard'').<br />
<br />
Après une période où se succèdent mises en œuvre et retours d’informations sur le protocole décrit, le groupe de travail auteur revoit le document.<br />
<br />
Si seuls des changements mineurs sont nécessaires, il demande alors à l’IESG de le faire avancer en le publiant en tant que nouveau RFC mais avec un statut de Draft Standard) après un nouvel appel à commentaires. Si les changements sont majeurs, le nouveau RFC garde le statut de Proposed Standard.<br />
<br />
Suit alors une nouvelle période de mises en œuvre et de retours d’informations où l’on doit faire la preuve de l’interopérabilité de deux implantations indépendantes. Puis le responsable du groupe de travail demande à l’IESG de faire avancer le document en le publiant (après un dernier appel à commentaires) en tant que RFC avec un statut de type "Standard". Il faut noter qu’à chaque étape, un nouveau numéro de RFC est attribué. Un RFC peut passer à l’état "historique" si son utilisation est devenue déconseillée. S’il est remplacé par un autre il devient "obsolète".<br />
<br />
La publication d’un RFC hors du processus de standardisation est plus facile. L’IESG peut directement faire publier un RFC avec un statut de type "Information", "Experimental" ou "''Best Current Practice''". Un RFC "Information" documente un protocole ou une approche particulière d’un problème. Il peut aussi donner des informations d’intérêt général. Il n’a aucune valeur de standard. Un RFC "Expérimental" décrit un protocole nécessitant que l’on mène des expériences avant de décider ou non d’entrer dans le processus de standardisation. Un RFC "''Best Current Practice''" documente une pratique d’ingénierie recommandée. La répartition par types des RFC édités en 2001 est donnée dans figure 17-2.<br />
<br />
===L'ISOC (Internet Society)===<br />
<br />
L’ISOC est une organisation internationale s’occupant de la croissance et de l’évolution de l’Internet à l’échelle mondiale et des aspects sociaux, politiques et techniques de son utilisation. Les membres de l’ISOC sont des personnes physiques ou morales. L’ISOC est dirigée par un Bureau des Administrateurs élu par les membres individuels.<br />
La standardisation de l’Internet est une activité chapeautée par l’ISOC, le Bureau des Administrateurs étant responsable de l’approbation des procédures et des règles du processus de standardisation de l’Internet.<br />
Le moyen selon lequel les membres du Bureau des Administrateurs de l’ISOC sont choisis, et les autres aspects concernant le fonctionnement de l’Internet Society sont décrits dans le document ISOC By-Laws [RFC 2135] et http://www.isoc.org.<br />
<br />
===L’IAB (Internet Architecture Board)===<br />
<br />
L’IAB est chargé par les Administrateurs de l’ISOC de fournir une supervision de l’architecture de l’Internet et de ses protocoles. L’IAB désigne le président de l’IETF et approuve les autres candidats pour l’IESG, présentés par le comité de nomination. L’IAB est aussi responsable de l’examen et de l’approbation des chartes des nouveaux groupes de travail proposés.<br />
<br />
L’IAB supervise le processus utilisé pour créer des Standards Internet et sert de cour d’appel pour les réclamations comme par exemple une violation des procédures de standardisation, ou pour un conflit entre les groupes de travail de l’IETF et l’IESG. L’IAB conseille l’IETF et l’ISOC en matière technique, politique, d’architecture, de procédure se rapportant à l’Internet et aux technologies associées. Les membres de l’IAB sont nommés par un comité (le Nomcom) et approuvés par le conseil d’administration de l’ISOC.<br />
<br />
===L’ICANN (Internet Corporation for Assigned Names and Numbers)===<br />
<br />
L’ICANN est un organisme international créé en octobre 1998 pour remplacer l’IANA (Internet Assigned Numbers Authority) qui n’était contrôlé que par le gouvernement américain. <br />
Beaucoup de spécifications de protocoles comportent des nombres, mots clés et paramètres qui doivent être affectés de manière unique, par exemple les numéros de versions, les numéros de protocoles, les numéros de ports et de MIB (Management Information Base). C'est l’ICANN qui affecte les valeurs de ces paramètres pour l’Internet. L’ICANN publie aussi les tables de toutes les valeurs affectées dans des RFC nommés Assigned Numbers. L’ICANN sert aussi de "sommet de la pyramide" pour la gestion des domaines de noms (DNS) et l’affectation des adresses et en établit les règles.<br />
<br />
===Les RIR (Regional Internet Registries)===<br />
<br />
Les RIR ou RIAR (''Regional Internet Address Registries'') reçoivent une délégation de l’ICANN pour distribuer les adresses IPv4 et IPv6. Ils sont au nombre de quatre actuellement, répartis sur 4 continents pour assurer une gestion de "proximité" à cette échelle. Ce sont :<br />
*APNIC : Asia Pacific Network Information Centre,<br />
*ARIN : American Registry for Internet Numbers,<br />
*RIPE-NCC : Réseaux IP Européen (Network Coordination Centre),<br />
*LACNIC : Réseaux d'Amérique Latine et des Caraïbes. <br />
<br />
Un cinquième, l’AFRINIC destiné à assurer la couverture du continent Africain est en cours de gestation (l’Afrique dépend actuellement du RIPE et de l’APNIC). En 2001, sept préfixes IPv4 de longueur 16 ont été affectés aux RIR pour être distribués aux opérateurs</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Historique_de_la_standardisation_d%E2%80%99IPv6&diff=2977Historique de la standardisation d’IPv62006-02-27T14:12:10Z<p>Bruno Deniaud: /* Les RFC (''Request For Comments'') */</p>
<hr />
<div>Cette annexe décrit les principales étapes qui jalonnent la standardisation d’IPv6, depuis la prise en compte de la nécessité d’un nouveau protocole jusqu’à la production de standards. Ce processus est toujours en cours même si une grande partie du chemin a déjà été parcourue.<br />
<br />
==<div id="stand">La standardisation de l'Internet</div>==<br />
<br />
Il est difficile de comprendre comment est né IPv6, et comment le protocole continue d’évoluer, si l’on ne connaît pas le processus de standardisation des protocoles utilisés dans l’Internet.<br />
Les organismes qui pilotent la standardisation de l’Internet sont l’IETF, l’IESG, l’IAB, l’ISOC et l’ICANN. Le résultat final de l’activité de standardisation est la production de documents appelés RFC (Request for Comments) dont certains sont des standards. L’ensemble du processus de standardisation est décrit dans le RFC 2026.<br />
<br />
===L'IETF (''Internet Engineering Task Force'')===<br />
<br />
L’activité au sein de l'’ETF est organisée en groupes de travail (''working group''). Les groupes agissant autour d’un même thème sont regroupés dans un Domaine (Area), comme le routage, la gestion des réseaux, la sécurité... Chaque Domaine est coordonné par un directeur (Area Director). L’ensemble des directeurs de Domaines compose l’IESG (voir ci-après).<br />
Les groupes de travail de l’IETF sont constitués de personnes volontaires et bénévoles qui sont motivées pour faire évoluer les standards de l’Internet sur la base de leur expérience acquise à partir de mises en œuvre et d’essais concrets. Toute personne intéressée (et ayant des disponibilités) peut faire partie d’un groupe de travail IETF. La participation à l’IETF et à ses groupes de travail est donc le fait d’individus proposant des contributions techniques plutôt que de représentants formels d’organisations.<br />
Chaque groupe de travail définit ses objectifs dans une charte, qu’il soumet à l’IESG lors de son processus de constitution. Le groupe est dirigé par un ou plusieurs présidents (''Working Group Chairs''). Le fonctionnement des groupes de travail de l’IETF est décrit en détail dans le RFC 2418.<br />
Dans un groupe le travail, les échanges de points de vue et d’expériences visant à élaborer les projets de standards (''Internet Drafts''), se font essentiellement par courrier électronique. Trois réunions annuelles permettent aux membres des groupes de se rencontrer pour une interaction plus directe. Lorsqu’un consensus est atteint, le groupe en demande la publication en tant que RFC (''Request For Comments'').<br />
Quand un groupe considère que ses objectifs sont atteints, il se dissout.<br />
Un certain nombre de groupes et sous-groupes IETF travaillent actuellement sur IPv6 ; on peut citer notamment:<br />
*IPng (aujourd'hui IPv6) : principal groupe de travail sur la production de protocoles liés à IPv6.<br />
*NGtrans (aujourd'hui v6ops) : étudie les modalités de la migration d’IPv4 vers IPv6. Ce groupe gère le déploiement du 6bone, un réseau expérimental IPv6 interconnectant des sites de test à travers le monde. <br />
Les groupes de travail de l’IETF doivent faire preuve d’esprit de coopération, ainsi que d’un haut degré de maturité technique ; les participants à l’IETF reconnaissent que les plus grands bénéfices pour tous les membres de la communauté de l’Internet proviennent du développement coopératif des protocoles et services (voir http://www.ietf.org pour plus de détails).<br />
<br />
===L'IESG (''Internet Engineering Steering Group'')===<br />
<br />
L’IESG est responsable de la direction des activités techniques de l’IETF. Il est composé des directeurs de Domaines (il y en a 7 actuellement) et du président de l’IETF qui est aussi le président de l’IESG. L’IESG administre le processus de standardisation de l’Internet suivant des règles et procédures détaillées dans le RFC 2028.<br />
C'est donc l’IESG qui décide de l’évolution du statut des spécifications techniques émises par les groupes de travail, ce qui peut élever certaines d’entre elles au rang de Standard Internet. L’IESG approuve également la constitution des nouveaux groupes de travail.<br />
<br />
===Les RFC (''Request For Comments'')===<br />
<br />
Les RFC sont les documents officiels de l’Internet ; ils sont disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/. Un RFC est complètement identifié par le numéro qui lui est attribué lors de sa publication. Ce numéro n'a pas de signification ; il est attribué par ordre chronologique de publication. Les premiers RFC sont sortis en 1969 ; début 2006, nous en sommes au numéro 4400, pour un flux supérieur à 200 RFC par an.<br />
Il existe plusieurs types de RFC d’importance différente pour la communauté IETF. On distingue deux catégories principales : ceux faisant partie du processus de standardisation (''Standard Track'') et les autres.<br />
<br />
Les documents entrant dans la première catégorie suivent un parcours bien défini. Ils sont d’abord publiés comme "Internet Drafts" par le groupe de travail. Ce sont des documents de travail à durée de vie limitée, disponibles en ligne sur les mêmes serveurs que les RFC. Lorsqu’un consensus semble atteint, le responsable lance un appel aux derniers commentaires dans le groupe. Il transmet ensuite le document à l’IESG qui, à son tour, lance un appel aux derniers commentaires à tout l’IETF. S’il n’y a pas d’objections majeures, le document est alors publié comme RFC avec un statut de (''Proposed Standard'').<br />
<br />
Après une période où se succèdent mises en œuvre et retours d’informations sur le protocole décrit, le groupe de travail auteur revoit le document.<br />
<br />
Si seuls des changements mineurs sont nécessaires, il demande alors à l’IESG de le faire avancer en le publiant en tant que nouveau RFC mais avec un statut de Draft Standard) après un nouvel appel à commentaires. Si les changements sont majeurs, le nouveau RFC garde le statut de Proposed Standard.<br />
<br />
Suit alors une nouvelle période de mises en œuvre et de retours d’informations où l’on doit faire la preuve de l’interopérabilité de deux implantations indépendantes. Puis le responsable du groupe de travail demande à l’IESG de faire avancer le document en le publiant (après un dernier appel à commentaires) en tant que RFC avec un statut de type "Standard". Il faut noter qu’à chaque étape, un nouveau numéro de RFC est attribué. Un RFC peut passer à l’état "historique" si son utilisation est devenue déconseillée. S’il est remplacé par un autre il devient "obsolète".<br />
<br />
La publication d’un RFC hors du processus de standardisation est plus facile. L’IESG peut directement faire publier un RFC avec un statut de type "Information", "Experimental" ou "''Best Current Practice''". Un RFC "Information" documente un protocole ou une approche particulière d’un problème. Il peut aussi donner des informations d’intérêt général. Il n’a aucune valeur de standard. Un RFC "Expérimental" décrit un protocole nécessitant que l’on mène des expériences avant de décider ou non d’entrer dans le processus de standardisation. Un RFC "''Best Current Practice''" documente une pratique d’ingénierie recommandée. La répartition par types des RFC édités en 2001 est donnée dans figure 17-2.<br />
<br />
===L'ISOC (Internet Society)===<br />
<br />
L’ISOC est une organisation internationale s’occupant de la croissance et de l’évolution de l’Internet à l’échelle mondiale et des aspects sociaux, politiques et techniques de son utilisation. Les membres de l’ISOC sont des personnes physiques ou morales. L’ISOC est dirigée par un Bureau des Administrateurs élu par les membres individuels.<br />
La standardisation de l’Internet est une activité chapeautée par l’ISOC, le Bureau des Administrateurs étant responsable de l’approbation des procédures et des règles du processus de standardisation de l’Internet.<br />
Le moyen selon lequel les membres du Bureau des Administrateurs de l’ISOC sont choisis, et les autres aspects concernant le fonctionnement de l’Internet Society sont décrits dans le document ISOC By-Laws [RFC 2135] et http://www.isoc.org.<br />
<br />
===L’IAB (Internet Architecture Board)===<br />
<br />
L’IAB est chargé par les Administrateurs de l’ISOC de fournir une supervision de l’architecture de l’Internet et de ses protocoles. L’IAB désigne le président de l’IETF et approuve les autres candidats pour l’IESG, présentés par le comité de nomination. L’IAB est aussi responsable de l’examen et de l’approbation des chartes des nouveaux groupes de travail proposés.<br />
<br />
L’IAB supervise le processus utilisé pour créer des Standards Internet et sert de cour d’appel pour les réclamations comme par exemple une violation des procédures de standardisation, ou pour un conflit entre les groupes de travail de l’IETF et l’IESG. L’IAB conseille l’IETF et l’ISOC en matière technique, politique, d’architecture, de procédure se rapportant à l’Internet et aux technologies associées. Les membres de l’IAB sont nommés par un comité (le Nomcom) et approuvés par le conseil d’administration de l’ISOC.<br />
<br />
===L’ICANN (Internet Corporation for Assigned Names and Numbers)===<br />
<br />
L’ICANN est un organisme international créé en octobre 1998 pour remplacer l’IANA (Internet Assigned Numbers Authority) qui n’était contrôlé que par le gouvernement américain. <br />
Beaucoup de spécifications de protocoles comportent des nombres, mots clés et paramètres qui doivent être affectés de manière unique, par exemple les numéros de versions, les numéros de protocoles, les numéros de ports et de MIB (Management Information Base). C'est l’ICANN qui affecte les valeurs de ces paramètres pour l’Internet. L’ICANN publie aussi les tables de toutes les valeurs affectées dans des RFC nommés Assigned Numbers. L’ICANN sert aussi de "sommet de la pyramide" pour la gestion des domaines de noms (DNS) et l’affectation des adresses et en établit les règles.<br />
<br />
===Les RIR (Regional Internet Registries)===<br />
<br />
Les RIR ou RIAR (''Regional Internet Address Registries'') reçoivent une délégation de l’ICANN pour distribuer les adresses IPv4 et IPv6. Ils sont au nombre de trois actuellement, répartis sur 4 continents pour assurer une gestion de "proximité" à celle échelle. Ce sont :<br />
*APNIC : Asia Pacific Network Information Centre,<br />
*ARIN : American Registry for Internet Numbers,<br />
*RIPE-NCC : Réseaux IP Européen (Network Coordination Centre),<br />
*LACNIC : Réseaux d'Amérique Latine et des Caraïbes. <br />
<br />
Un cinquième, l’AFRINIC destiné à assurer la couverture du continent Africain est en cours de gestation (l’Afrique dépend actuellement du RIPE et de l’APNIC). En 2001, sept préfixes IPv4 de longueur 16 ont été affectés aux RIR pour être distribués aux opérateurs</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Historique_de_la_standardisation_d%E2%80%99IPv6&diff=2976Historique de la standardisation d’IPv62006-02-27T14:10:12Z<p>Bruno Deniaud: /* Les RFC (''Request For Comments'') */</p>
<hr />
<div>Cette annexe décrit les principales étapes qui jalonnent la standardisation d’IPv6, depuis la prise en compte de la nécessité d’un nouveau protocole jusqu’à la production de standards. Ce processus est toujours en cours même si une grande partie du chemin a déjà été parcourue.<br />
<br />
==<div id="stand">La standardisation de l'Internet</div>==<br />
<br />
Il est difficile de comprendre comment est né IPv6, et comment le protocole continue d’évoluer, si l’on ne connaît pas le processus de standardisation des protocoles utilisés dans l’Internet.<br />
Les organismes qui pilotent la standardisation de l’Internet sont l’IETF, l’IESG, l’IAB, l’ISOC et l’ICANN. Le résultat final de l’activité de standardisation est la production de documents appelés RFC (Request for Comments) dont certains sont des standards. L’ensemble du processus de standardisation est décrit dans le RFC 2026.<br />
<br />
===L'IETF (''Internet Engineering Task Force'')===<br />
<br />
L’activité au sein de l'’ETF est organisée en groupes de travail (''working group''). Les groupes agissant autour d’un même thème sont regroupés dans un Domaine (Area), comme le routage, la gestion des réseaux, la sécurité... Chaque Domaine est coordonné par un directeur (Area Director). L’ensemble des directeurs de Domaines compose l’IESG (voir ci-après).<br />
Les groupes de travail de l’IETF sont constitués de personnes volontaires et bénévoles qui sont motivées pour faire évoluer les standards de l’Internet sur la base de leur expérience acquise à partir de mises en œuvre et d’essais concrets. Toute personne intéressée (et ayant des disponibilités) peut faire partie d’un groupe de travail IETF. La participation à l’IETF et à ses groupes de travail est donc le fait d’individus proposant des contributions techniques plutôt que de représentants formels d’organisations.<br />
Chaque groupe de travail définit ses objectifs dans une charte, qu’il soumet à l’IESG lors de son processus de constitution. Le groupe est dirigé par un ou plusieurs présidents (''Working Group Chairs''). Le fonctionnement des groupes de travail de l’IETF est décrit en détail dans le RFC 2418.<br />
Dans un groupe le travail, les échanges de points de vue et d’expériences visant à élaborer les projets de standards (''Internet Drafts''), se font essentiellement par courrier électronique. Trois réunions annuelles permettent aux membres des groupes de se rencontrer pour une interaction plus directe. Lorsqu’un consensus est atteint, le groupe en demande la publication en tant que RFC (''Request For Comments'').<br />
Quand un groupe considère que ses objectifs sont atteints, il se dissout.<br />
Un certain nombre de groupes et sous-groupes IETF travaillent actuellement sur IPv6 ; on peut citer notamment:<br />
*IPng (aujourd'hui IPv6) : principal groupe de travail sur la production de protocoles liés à IPv6.<br />
*NGtrans (aujourd'hui v6ops) : étudie les modalités de la migration d’IPv4 vers IPv6. Ce groupe gère le déploiement du 6bone, un réseau expérimental IPv6 interconnectant des sites de test à travers le monde. <br />
Les groupes de travail de l’IETF doivent faire preuve d’esprit de coopération, ainsi que d’un haut degré de maturité technique ; les participants à l’IETF reconnaissent que les plus grands bénéfices pour tous les membres de la communauté de l’Internet proviennent du développement coopératif des protocoles et services (voir http://www.ietf.org pour plus de détails).<br />
<br />
===L'IESG (''Internet Engineering Steering Group'')===<br />
<br />
L’IESG est responsable de la direction des activités techniques de l’IETF. Il est composé des directeurs de Domaines (il y en a 7 actuellement) et du président de l’IETF qui est aussi le président de l’IESG. L’IESG administre le processus de standardisation de l’Internet suivant des règles et procédures détaillées dans le RFC 2028.<br />
C'est donc l’IESG qui décide de l’évolution du statut des spécifications techniques émises par les groupes de travail, ce qui peut élever certaines d’entre elles au rang de Standard Internet. L’IESG approuve également la constitution des nouveaux groupes de travail.<br />
<br />
===Les RFC (''Request For Comments'')===<br />
<br />
Les RFC sont les documents officiels de l’Internet ; ils sont disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/. Un RFC est complètement identifié par le numéro qui lui est attribué lors de sa publication. Ce numéro n'a pas de signification ; il est attribué par ordre chronologique de publication. Les premiers RFC sont sortis en 1969 ; début 2006, nous en sommes au numéro 4400, pour un flux supérieur à 200 RFC par an.<br />
Il existe plusieurs types de RFC d’importance différente pour la communauté IETF. On distingue deux catégories principales : ceux faisant partie du processus de standardisation (''Standard Track'') et les autres.<br />
<br />
Les documents entrant dans la première catégorie suivent un parcours bien défini. Ils sont d’abord publiés comme "Internet Drafts" par le groupe de travail. Ce sont des documents de travail à durée de vie limitée, disponibles en ligne sur les mêmes serveurs que les RFC. Lorsqu’un consensus semble atteint, le responsable lance un appel aux derniers commentaires dans le groupe. Il transmet ensuite le document à l’IESG qui, à son tour, lance un appel aux derniers commentaires à tout l’IETF. S’il n’y a pas d’objections majeures, le document est alors publié comme RFC avec un statut de (''Proposed Standard'').<br />
<br />
Après une période où se succèdent mises en œuvre et retours d’informations sur le protocole décrit, le groupe de travail auteur revoit le document.<br />
<br />
Si seuls des changements mineurs sont nécessaires, il demande alors à l’IESG de le faire avancer en le publiant en tant que nouveau RFC mais avec un statut de Draft Standard) après un nouvel appel à commentaires. Si les changements sont majeurs, le nouveau RFC garde le statut de Proposed Standard.<br />
<br />
Suit alors une nouvelle période de mises en œuvre et de retours d’informations où l’on doit faire la preuve de l’interopérabilité de deux implantations indépendantes. Puis le responsable du groupe de travail demande à l’IESG de faire avancer le document en le publiant (après un dernier appel à commentaires) en tant que RFC avec un statut de type "Standard". Il faut noter qu’à chaque étape, un nouveau numéro de RFC est attribué. Un RFC peut passer à l’état "historique" si son utilisation est devenue déconseillée. S’il est remplacé par un autre il devient "obsolète".<br />
<br />
La publication d’un RFC hors du processus de standardisation est plus facile. L’IESG peut directement faire publier un RFC avec un statut de type "Information", "Experimental" ou "''Best Current Practice''". Un RFC "Information" documente un protocole ou une approche particulière d’un problème. Il peut aussi donner des informations d’intérêt général. Il n’a aucune valeur de standard. Un RFC "Expérimental" décrit un protocole nécessitant que l’on mène des expériences avant de décider ou non d’entrer dans le processus de standardisation. Un RFC Best Current Practice documente une pratique d’ingénierie recommandée. La répartition par types des RFC édités en 2001 est donnée dans figure 17-2.<br />
<br />
===L'ISOC (Internet Society)===<br />
<br />
L’ISOC est une organisation internationale s’occupant de la croissance et de l’évolution de l’Internet à l’échelle mondiale et des aspects sociaux, politiques et techniques de son utilisation. Les membres de l’ISOC sont des personnes physiques ou morales. L’ISOC est dirigée par un Bureau des Administrateurs élu par les membres individuels.<br />
La standardisation de l’Internet est une activité chapeautée par l’ISOC, le Bureau des Administrateurs étant responsable de l’approbation des procédures et des règles du processus de standardisation de l’Internet.<br />
Le moyen selon lequel les membres du Bureau des Administrateurs de l’ISOC sont choisis, et les autres aspects concernant le fonctionnement de l’Internet Society sont décrits dans le document ISOC By-Laws [RFC 2135] et http://www.isoc.org.<br />
<br />
===L’IAB (Internet Architecture Board)===<br />
<br />
L’IAB est chargé par les Administrateurs de l’ISOC de fournir une supervision de l’architecture de l’Internet et de ses protocoles. L’IAB désigne le président de l’IETF et approuve les autres candidats pour l’IESG, présentés par le comité de nomination. L’IAB est aussi responsable de l’examen et de l’approbation des chartes des nouveaux groupes de travail proposés.<br />
<br />
L’IAB supervise le processus utilisé pour créer des Standards Internet et sert de cour d’appel pour les réclamations comme par exemple une violation des procédures de standardisation, ou pour un conflit entre les groupes de travail de l’IETF et l’IESG. L’IAB conseille l’IETF et l’ISOC en matière technique, politique, d’architecture, de procédure se rapportant à l’Internet et aux technologies associées. Les membres de l’IAB sont nommés par un comité (le Nomcom) et approuvés par le conseil d’administration de l’ISOC.<br />
<br />
===L’ICANN (Internet Corporation for Assigned Names and Numbers)===<br />
<br />
L’ICANN est un organisme international créé en octobre 1998 pour remplacer l’IANA (Internet Assigned Numbers Authority) qui n’était contrôlé que par le gouvernement américain. <br />
Beaucoup de spécifications de protocoles comportent des nombres, mots clés et paramètres qui doivent être affectés de manière unique, par exemple les numéros de versions, les numéros de protocoles, les numéros de ports et de MIB (Management Information Base). C'est l’ICANN qui affecte les valeurs de ces paramètres pour l’Internet. L’ICANN publie aussi les tables de toutes les valeurs affectées dans des RFC nommés Assigned Numbers. L’ICANN sert aussi de "sommet de la pyramide" pour la gestion des domaines de noms (DNS) et l’affectation des adresses et en établit les règles.<br />
<br />
===Les RIR (Regional Internet Registries)===<br />
<br />
Les RIR ou RIAR (''Regional Internet Address Registries'') reçoivent une délégation de l’ICANN pour distribuer les adresses IPv4 et IPv6. Ils sont au nombre de trois actuellement, répartis sur 4 continents pour assurer une gestion de "proximité" à celle échelle. Ce sont :<br />
*APNIC : Asia Pacific Network Information Centre,<br />
*ARIN : American Registry for Internet Numbers,<br />
*RIPE-NCC : Réseaux IP Européen (Network Coordination Centre),<br />
*LACNIC : Réseaux d'Amérique Latine et des Caraïbes. <br />
<br />
Un cinquième, l’AFRINIC destiné à assurer la couverture du continent Africain est en cours de gestation (l’Afrique dépend actuellement du RIPE et de l’APNIC). En 2001, sept préfixes IPv4 de longueur 16 ont été affectés aux RIR pour être distribués aux opérateurs</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Historique_de_la_standardisation_d%E2%80%99IPv6&diff=2975Historique de la standardisation d’IPv62006-02-27T14:06:42Z<p>Bruno Deniaud: /* Les RFC (''Request For Comments'') */</p>
<hr />
<div>Cette annexe décrit les principales étapes qui jalonnent la standardisation d’IPv6, depuis la prise en compte de la nécessité d’un nouveau protocole jusqu’à la production de standards. Ce processus est toujours en cours même si une grande partie du chemin a déjà été parcourue.<br />
<br />
==<div id="stand">La standardisation de l'Internet</div>==<br />
<br />
Il est difficile de comprendre comment est né IPv6, et comment le protocole continue d’évoluer, si l’on ne connaît pas le processus de standardisation des protocoles utilisés dans l’Internet.<br />
Les organismes qui pilotent la standardisation de l’Internet sont l’IETF, l’IESG, l’IAB, l’ISOC et l’ICANN. Le résultat final de l’activité de standardisation est la production de documents appelés RFC (Request for Comments) dont certains sont des standards. L’ensemble du processus de standardisation est décrit dans le RFC 2026.<br />
<br />
===L'IETF (''Internet Engineering Task Force'')===<br />
<br />
L’activité au sein de l'’ETF est organisée en groupes de travail (''working group''). Les groupes agissant autour d’un même thème sont regroupés dans un Domaine (Area), comme le routage, la gestion des réseaux, la sécurité... Chaque Domaine est coordonné par un directeur (Area Director). L’ensemble des directeurs de Domaines compose l’IESG (voir ci-après).<br />
Les groupes de travail de l’IETF sont constitués de personnes volontaires et bénévoles qui sont motivées pour faire évoluer les standards de l’Internet sur la base de leur expérience acquise à partir de mises en œuvre et d’essais concrets. Toute personne intéressée (et ayant des disponibilités) peut faire partie d’un groupe de travail IETF. La participation à l’IETF et à ses groupes de travail est donc le fait d’individus proposant des contributions techniques plutôt que de représentants formels d’organisations.<br />
Chaque groupe de travail définit ses objectifs dans une charte, qu’il soumet à l’IESG lors de son processus de constitution. Le groupe est dirigé par un ou plusieurs présidents (''Working Group Chairs''). Le fonctionnement des groupes de travail de l’IETF est décrit en détail dans le RFC 2418.<br />
Dans un groupe le travail, les échanges de points de vue et d’expériences visant à élaborer les projets de standards (''Internet Drafts''), se font essentiellement par courrier électronique. Trois réunions annuelles permettent aux membres des groupes de se rencontrer pour une interaction plus directe. Lorsqu’un consensus est atteint, le groupe en demande la publication en tant que RFC (''Request For Comments'').<br />
Quand un groupe considère que ses objectifs sont atteints, il se dissout.<br />
Un certain nombre de groupes et sous-groupes IETF travaillent actuellement sur IPv6 ; on peut citer notamment:<br />
*IPng (aujourd'hui IPv6) : principal groupe de travail sur la production de protocoles liés à IPv6.<br />
*NGtrans (aujourd'hui v6ops) : étudie les modalités de la migration d’IPv4 vers IPv6. Ce groupe gère le déploiement du 6bone, un réseau expérimental IPv6 interconnectant des sites de test à travers le monde. <br />
Les groupes de travail de l’IETF doivent faire preuve d’esprit de coopération, ainsi que d’un haut degré de maturité technique ; les participants à l’IETF reconnaissent que les plus grands bénéfices pour tous les membres de la communauté de l’Internet proviennent du développement coopératif des protocoles et services (voir http://www.ietf.org pour plus de détails).<br />
<br />
===L'IESG (''Internet Engineering Steering Group'')===<br />
<br />
L’IESG est responsable de la direction des activités techniques de l’IETF. Il est composé des directeurs de Domaines (il y en a 7 actuellement) et du président de l’IETF qui est aussi le président de l’IESG. L’IESG administre le processus de standardisation de l’Internet suivant des règles et procédures détaillées dans le RFC 2028.<br />
C'est donc l’IESG qui décide de l’évolution du statut des spécifications techniques émises par les groupes de travail, ce qui peut élever certaines d’entre elles au rang de Standard Internet. L’IESG approuve également la constitution des nouveaux groupes de travail.<br />
<br />
===Les RFC (''Request For Comments'')===<br />
<br />
Les RFC sont les documents officiels de l’Internet ; ils sont disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/. Un RFC est complètement identifié par le numéro qui lui est attribué lors de sa publication. Ce numéro n'a pas de signification ; il est attribué par ordre chronologique de publication. Les premiers RFC sont sortis en 1969 ; début 2006, nous en sommes au numéro 4400, pour un flux supérieur à 200 RFC par an.<br />
Il existe plusieurs types de RFC d’importance différente pour la communauté IETF. On distingue deux catégories principales : ceux faisant partie du processus de standardisation (''Standard Track'') et les autres.<br />
<br />
Les documents entrant dans la première catégorie suivent un parcours bien défini. Ils sont d’abord publiés comme "Internet Drafts" par le groupe de travail. Ce sont des documents de travail à durée de vie limitée, disponibles en ligne sur les mêmes serveurs que les RFC. Lorsqu’un consensus semble atteint, le responsable lance un appel aux derniers commentaires dans le groupe. Il transmet ensuite le document à l’IESG qui, à son tour, lance un appel aux derniers commentaires à tout l’IETF. S’il n’y a pas d’objections majeures, le document est alors publié comme RFC avec un statut de (''Proposed Standard'').<br />
<br />
Après une période où se succèdent mises en œuvre et retours d’informations sur le protocole décrit, le groupe de travail auteur revoit le document.<br />
<br />
Si seuls des changements mineurs sont nécessaires, il demande alors à l’IESG de le faire avancer en le publiant en tant que nouveau RFC mais avec un statut de Draft Standard) après un nouvel appel à commentaires. Si les changements sont majeurs, le nouveau RFC garde le statut de Proposed Standard.<br />
<br />
Suit alors une nouvelle période de mises en œuvre et de retours d’informations où l’on doit faire la preuve de l’interopérabilité de deux implantations indépendantes. Puis le responsable du groupe de travail demande à l’IESG de faire avancer le document en le publiant (après un dernier appel à commentaires) en tant que RFC avec un statut de type "Standard". Il faut noter qu’à chaque étape, un nouveau numéro de RFC est attribué. Un RFC peut passer à l’état "historique" si son utilisation est devenue déconseillée. S’il est remplacé par un autre il devient "obsolète".<br />
<br />
La publication d’un RFC hors du processus de standardisation est plus facile. L’IESG peut directement faire publier un RFC avec un statut de type "Information", "Experimental" ou ''Best Current Practice''). Un RFC "Information" documente un protocole ou une approche particulière d’un problème. Il peut aussi donner des informations d’intérêt général. Il n’a aucune valeur de standard. Un RFC "Expérimental" décrit un protocole nécessitant que l’on mène des expériences avant de décider ou non d’entrer dans le processus de standardisation. Un RFC Best Current Practice documente une pratique d’ingénierie recommandée. La répartition par types des RFC édités en 2001 est donnée dans figure 17-2.<br />
<br />
===L'ISOC (Internet Society)===<br />
<br />
L’ISOC est une organisation internationale s’occupant de la croissance et de l’évolution de l’Internet à l’échelle mondiale et des aspects sociaux, politiques et techniques de son utilisation. Les membres de l’ISOC sont des personnes physiques ou morales. L’ISOC est dirigée par un Bureau des Administrateurs élu par les membres individuels.<br />
La standardisation de l’Internet est une activité chapeautée par l’ISOC, le Bureau des Administrateurs étant responsable de l’approbation des procédures et des règles du processus de standardisation de l’Internet.<br />
Le moyen selon lequel les membres du Bureau des Administrateurs de l’ISOC sont choisis, et les autres aspects concernant le fonctionnement de l’Internet Society sont décrits dans le document ISOC By-Laws [RFC 2135] et http://www.isoc.org.<br />
<br />
===L’IAB (Internet Architecture Board)===<br />
<br />
L’IAB est chargé par les Administrateurs de l’ISOC de fournir une supervision de l’architecture de l’Internet et de ses protocoles. L’IAB désigne le président de l’IETF et approuve les autres candidats pour l’IESG, présentés par le comité de nomination. L’IAB est aussi responsable de l’examen et de l’approbation des chartes des nouveaux groupes de travail proposés.<br />
<br />
L’IAB supervise le processus utilisé pour créer des Standards Internet et sert de cour d’appel pour les réclamations comme par exemple une violation des procédures de standardisation, ou pour un conflit entre les groupes de travail de l’IETF et l’IESG. L’IAB conseille l’IETF et l’ISOC en matière technique, politique, d’architecture, de procédure se rapportant à l’Internet et aux technologies associées. Les membres de l’IAB sont nommés par un comité (le Nomcom) et approuvés par le conseil d’administration de l’ISOC.<br />
<br />
===L’ICANN (Internet Corporation for Assigned Names and Numbers)===<br />
<br />
L’ICANN est un organisme international créé en octobre 1998 pour remplacer l’IANA (Internet Assigned Numbers Authority) qui n’était contrôlé que par le gouvernement américain. <br />
Beaucoup de spécifications de protocoles comportent des nombres, mots clés et paramètres qui doivent être affectés de manière unique, par exemple les numéros de versions, les numéros de protocoles, les numéros de ports et de MIB (Management Information Base). C'est l’ICANN qui affecte les valeurs de ces paramètres pour l’Internet. L’ICANN publie aussi les tables de toutes les valeurs affectées dans des RFC nommés Assigned Numbers. L’ICANN sert aussi de "sommet de la pyramide" pour la gestion des domaines de noms (DNS) et l’affectation des adresses et en établit les règles.<br />
<br />
===Les RIR (Regional Internet Registries)===<br />
<br />
Les RIR ou RIAR (''Regional Internet Address Registries'') reçoivent une délégation de l’ICANN pour distribuer les adresses IPv4 et IPv6. Ils sont au nombre de trois actuellement, répartis sur 4 continents pour assurer une gestion de "proximité" à celle échelle. Ce sont :<br />
*APNIC : Asia Pacific Network Information Centre,<br />
*ARIN : American Registry for Internet Numbers,<br />
*RIPE-NCC : Réseaux IP Européen (Network Coordination Centre),<br />
*LACNIC : Réseaux d'Amérique Latine et des Caraïbes. <br />
<br />
Un cinquième, l’AFRINIC destiné à assurer la couverture du continent Africain est en cours de gestation (l’Afrique dépend actuellement du RIPE et de l’APNIC). En 2001, sept préfixes IPv4 de longueur 16 ont été affectés aux RIR pour être distribués aux opérateurs</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Historique_de_la_standardisation_d%E2%80%99IPv6&diff=2974Historique de la standardisation d’IPv62006-02-27T14:01:43Z<p>Bruno Deniaud: /* L'IESG (''Internet Engineering Steering Group'') */</p>
<hr />
<div>Cette annexe décrit les principales étapes qui jalonnent la standardisation d’IPv6, depuis la prise en compte de la nécessité d’un nouveau protocole jusqu’à la production de standards. Ce processus est toujours en cours même si une grande partie du chemin a déjà été parcourue.<br />
<br />
==<div id="stand">La standardisation de l'Internet</div>==<br />
<br />
Il est difficile de comprendre comment est né IPv6, et comment le protocole continue d’évoluer, si l’on ne connaît pas le processus de standardisation des protocoles utilisés dans l’Internet.<br />
Les organismes qui pilotent la standardisation de l’Internet sont l’IETF, l’IESG, l’IAB, l’ISOC et l’ICANN. Le résultat final de l’activité de standardisation est la production de documents appelés RFC (Request for Comments) dont certains sont des standards. L’ensemble du processus de standardisation est décrit dans le RFC 2026.<br />
<br />
===L'IETF (''Internet Engineering Task Force'')===<br />
<br />
L’activité au sein de l'’ETF est organisée en groupes de travail (''working group''). Les groupes agissant autour d’un même thème sont regroupés dans un Domaine (Area), comme le routage, la gestion des réseaux, la sécurité... Chaque Domaine est coordonné par un directeur (Area Director). L’ensemble des directeurs de Domaines compose l’IESG (voir ci-après).<br />
Les groupes de travail de l’IETF sont constitués de personnes volontaires et bénévoles qui sont motivées pour faire évoluer les standards de l’Internet sur la base de leur expérience acquise à partir de mises en œuvre et d’essais concrets. Toute personne intéressée (et ayant des disponibilités) peut faire partie d’un groupe de travail IETF. La participation à l’IETF et à ses groupes de travail est donc le fait d’individus proposant des contributions techniques plutôt que de représentants formels d’organisations.<br />
Chaque groupe de travail définit ses objectifs dans une charte, qu’il soumet à l’IESG lors de son processus de constitution. Le groupe est dirigé par un ou plusieurs présidents (''Working Group Chairs''). Le fonctionnement des groupes de travail de l’IETF est décrit en détail dans le RFC 2418.<br />
Dans un groupe le travail, les échanges de points de vue et d’expériences visant à élaborer les projets de standards (''Internet Drafts''), se font essentiellement par courrier électronique. Trois réunions annuelles permettent aux membres des groupes de se rencontrer pour une interaction plus directe. Lorsqu’un consensus est atteint, le groupe en demande la publication en tant que RFC (''Request For Comments'').<br />
Quand un groupe considère que ses objectifs sont atteints, il se dissout.<br />
Un certain nombre de groupes et sous-groupes IETF travaillent actuellement sur IPv6 ; on peut citer notamment:<br />
*IPng (aujourd'hui IPv6) : principal groupe de travail sur la production de protocoles liés à IPv6.<br />
*NGtrans (aujourd'hui v6ops) : étudie les modalités de la migration d’IPv4 vers IPv6. Ce groupe gère le déploiement du 6bone, un réseau expérimental IPv6 interconnectant des sites de test à travers le monde. <br />
Les groupes de travail de l’IETF doivent faire preuve d’esprit de coopération, ainsi que d’un haut degré de maturité technique ; les participants à l’IETF reconnaissent que les plus grands bénéfices pour tous les membres de la communauté de l’Internet proviennent du développement coopératif des protocoles et services (voir http://www.ietf.org pour plus de détails).<br />
<br />
===L'IESG (''Internet Engineering Steering Group'')===<br />
<br />
L’IESG est responsable de la direction des activités techniques de l’IETF. Il est composé des directeurs de Domaines (il y en a 7 actuellement) et du président de l’IETF qui est aussi le président de l’IESG. L’IESG administre le processus de standardisation de l’Internet suivant des règles et procédures détaillées dans le RFC 2028.<br />
C'est donc l’IESG qui décide de l’évolution du statut des spécifications techniques émises par les groupes de travail, ce qui peut élever certaines d’entre elles au rang de Standard Internet. L’IESG approuve également la constitution des nouveaux groupes de travail.<br />
<br />
===Les RFC (''Request For Comments'')===<br />
<br />
Les RFC sont les documents officiels de l’Internet ; ils sont disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/. Un RFC est complètement identifié par le numéro qui lui est attribué lors de sa publication. Ce numéro n'a pas de signification ; il est attribué par ordre chronologique de publication. Les premiers RFC sont sortis en 1969 ; début 2002, nous en sommes au numéro 3221, pour un flux supérieur à 200 RFC par an.<br />
Il existe plusieurs types de RFC d’importance différente pour la communauté IETF. On distingue deux catégories principales : ceux faisant partie du processus de standardisation (''Standard Track'') et les autres.<br />
<br />
Les documents entrant dans la première catégorie suivent un parcours bien défini. Ils sont d’abord publiés comme "Internet Drafts" par le groupe de travail. Ce sont des documents de travail à durée de vie limitée, disponibles en ligne sur les mêmes serveurs que les RFC. Lorsqu’un consensus semble atteint, le responsable lance un appel aux derniers commentaires dans le groupe. Il transmet ensuite le document à l’IESG qui, à son tour, lance un appel aux derniers commentaires à tout l’IETF. S’il n’y a pas d’objections majeures, le document est alors publié comme RFC avec un statut de (''Proposed Standard'').<br />
<br />
Après une période où se succèdent mises en œuvre et retours d’informations sur le protocole décrit, le groupe de travail auteur revoit le document.<br />
<br />
Si seuls des changements mineurs sont nécessaires, il demande alors à l’IESG de le faire avancer en le publiant en tant que nouveau RFC mais avec un statut de Draft Standard) après un nouvel appel à commentaires. Si les changements sont majeurs, le nouveau RFC garde le statut de Proposed Standard.<br />
<br />
Suit alors une nouvelle période de mises en œuvre et de retours d’informations où l’on doit faire la preuve de l’interopérabilité de deux implantations indépendantes. Puis le responsable du groupe de travail demande à l’IESG de faire avancer le document en le publiant (après un dernier appel à commentaires) en tant que RFC avec un statut de type "Standard". Il faut noter qu’à chaque étape, un nouveau numéro de RFC est attribué. Un RFC peut passer à l’état "historique" si son utilisation est devenue déconseillée. S’il est remplacé par un autre il devient "obsolète".<br />
<br />
La publication d’un RFC hors du processus de standardisation est plus facile. L’IESG peut directement faire publier un RFC avec un statut de type "Information", "Experimental" ou ''Best Current Practice''). Un RFC "Information" documente un protocole ou une approche particulière d’un problème. Il peut aussi donner des informations d’intérêt général. Il n’a aucune valeur de standard. Un RFC "Expérimental" décrit un protocole nécessitant que l’on mène des expériences avant de décider ou non d’entrer dans le processus de standardisation. Un RFC Best Current Practice documente une pratique d’ingénierie recommandée. La répartition par types des RFC édités en 2001 est donnée dans figure 17-2.<br />
<br />
===L'ISOC (Internet Society)===<br />
<br />
L’ISOC est une organisation internationale s’occupant de la croissance et de l’évolution de l’Internet à l’échelle mondiale et des aspects sociaux, politiques et techniques de son utilisation. Les membres de l’ISOC sont des personnes physiques ou morales. L’ISOC est dirigée par un Bureau des Administrateurs élu par les membres individuels.<br />
La standardisation de l’Internet est une activité chapeautée par l’ISOC, le Bureau des Administrateurs étant responsable de l’approbation des procédures et des règles du processus de standardisation de l’Internet.<br />
Le moyen selon lequel les membres du Bureau des Administrateurs de l’ISOC sont choisis, et les autres aspects concernant le fonctionnement de l’Internet Society sont décrits dans le document ISOC By-Laws [RFC 2135] et http://www.isoc.org.<br />
<br />
===L’IAB (Internet Architecture Board)===<br />
<br />
L’IAB est chargé par les Administrateurs de l’ISOC de fournir une supervision de l’architecture de l’Internet et de ses protocoles. L’IAB désigne le président de l’IETF et approuve les autres candidats pour l’IESG, présentés par le comité de nomination. L’IAB est aussi responsable de l’examen et de l’approbation des chartes des nouveaux groupes de travail proposés.<br />
<br />
L’IAB supervise le processus utilisé pour créer des Standards Internet et sert de cour d’appel pour les réclamations comme par exemple une violation des procédures de standardisation, ou pour un conflit entre les groupes de travail de l’IETF et l’IESG. L’IAB conseille l’IETF et l’ISOC en matière technique, politique, d’architecture, de procédure se rapportant à l’Internet et aux technologies associées. Les membres de l’IAB sont nommés par un comité (le Nomcom) et approuvés par le conseil d’administration de l’ISOC.<br />
<br />
===L’ICANN (Internet Corporation for Assigned Names and Numbers)===<br />
<br />
L’ICANN est un organisme international créé en octobre 1998 pour remplacer l’IANA (Internet Assigned Numbers Authority) qui n’était contrôlé que par le gouvernement américain. <br />
Beaucoup de spécifications de protocoles comportent des nombres, mots clés et paramètres qui doivent être affectés de manière unique, par exemple les numéros de versions, les numéros de protocoles, les numéros de ports et de MIB (Management Information Base). C'est l’ICANN qui affecte les valeurs de ces paramètres pour l’Internet. L’ICANN publie aussi les tables de toutes les valeurs affectées dans des RFC nommés Assigned Numbers. L’ICANN sert aussi de "sommet de la pyramide" pour la gestion des domaines de noms (DNS) et l’affectation des adresses et en établit les règles.<br />
<br />
===Les RIR (Regional Internet Registries)===<br />
<br />
Les RIR ou RIAR (''Regional Internet Address Registries'') reçoivent une délégation de l’ICANN pour distribuer les adresses IPv4 et IPv6. Ils sont au nombre de trois actuellement, répartis sur 4 continents pour assurer une gestion de "proximité" à celle échelle. Ce sont :<br />
*APNIC : Asia Pacific Network Information Centre,<br />
*ARIN : American Registry for Internet Numbers,<br />
*RIPE-NCC : Réseaux IP Européen (Network Coordination Centre),<br />
*LACNIC : Réseaux d'Amérique Latine et des Caraïbes. <br />
<br />
Un cinquième, l’AFRINIC destiné à assurer la couverture du continent Africain est en cours de gestation (l’Afrique dépend actuellement du RIPE et de l’APNIC). En 2001, sept préfixes IPv4 de longueur 16 ont été affectés aux RIR pour être distribués aux opérateurs</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Historique_de_la_standardisation_d%E2%80%99IPv6&diff=2973Historique de la standardisation d’IPv62006-02-27T13:59:53Z<p>Bruno Deniaud: /* L'IETF (''Internet Engineering Task Force'') */</p>
<hr />
<div>Cette annexe décrit les principales étapes qui jalonnent la standardisation d’IPv6, depuis la prise en compte de la nécessité d’un nouveau protocole jusqu’à la production de standards. Ce processus est toujours en cours même si une grande partie du chemin a déjà été parcourue.<br />
<br />
==<div id="stand">La standardisation de l'Internet</div>==<br />
<br />
Il est difficile de comprendre comment est né IPv6, et comment le protocole continue d’évoluer, si l’on ne connaît pas le processus de standardisation des protocoles utilisés dans l’Internet.<br />
Les organismes qui pilotent la standardisation de l’Internet sont l’IETF, l’IESG, l’IAB, l’ISOC et l’ICANN. Le résultat final de l’activité de standardisation est la production de documents appelés RFC (Request for Comments) dont certains sont des standards. L’ensemble du processus de standardisation est décrit dans le RFC 2026.<br />
<br />
===L'IETF (''Internet Engineering Task Force'')===<br />
<br />
L’activité au sein de l'’ETF est organisée en groupes de travail (''working group''). Les groupes agissant autour d’un même thème sont regroupés dans un Domaine (Area), comme le routage, la gestion des réseaux, la sécurité... Chaque Domaine est coordonné par un directeur (Area Director). L’ensemble des directeurs de Domaines compose l’IESG (voir ci-après).<br />
Les groupes de travail de l’IETF sont constitués de personnes volontaires et bénévoles qui sont motivées pour faire évoluer les standards de l’Internet sur la base de leur expérience acquise à partir de mises en œuvre et d’essais concrets. Toute personne intéressée (et ayant des disponibilités) peut faire partie d’un groupe de travail IETF. La participation à l’IETF et à ses groupes de travail est donc le fait d’individus proposant des contributions techniques plutôt que de représentants formels d’organisations.<br />
Chaque groupe de travail définit ses objectifs dans une charte, qu’il soumet à l’IESG lors de son processus de constitution. Le groupe est dirigé par un ou plusieurs présidents (''Working Group Chairs''). Le fonctionnement des groupes de travail de l’IETF est décrit en détail dans le RFC 2418.<br />
Dans un groupe le travail, les échanges de points de vue et d’expériences visant à élaborer les projets de standards (''Internet Drafts''), se font essentiellement par courrier électronique. Trois réunions annuelles permettent aux membres des groupes de se rencontrer pour une interaction plus directe. Lorsqu’un consensus est atteint, le groupe en demande la publication en tant que RFC (''Request For Comments'').<br />
Quand un groupe considère que ses objectifs sont atteints, il se dissout.<br />
Un certain nombre de groupes et sous-groupes IETF travaillent actuellement sur IPv6 ; on peut citer notamment:<br />
*IPng (aujourd'hui IPv6) : principal groupe de travail sur la production de protocoles liés à IPv6.<br />
*NGtrans (aujourd'hui v6ops) : étudie les modalités de la migration d’IPv4 vers IPv6. Ce groupe gère le déploiement du 6bone, un réseau expérimental IPv6 interconnectant des sites de test à travers le monde. <br />
Les groupes de travail de l’IETF doivent faire preuve d’esprit de coopération, ainsi que d’un haut degré de maturité technique ; les participants à l’IETF reconnaissent que les plus grands bénéfices pour tous les membres de la communauté de l’Internet proviennent du développement coopératif des protocoles et services (voir http://www.ietf.org pour plus de détails).<br />
<br />
===L'IESG (''Internet Engineering Steering Group'')===<br />
<br />
L’IESG est responsable de la direction des activités techniques de l’IETF. Il est composé des directeurs de Domaines (il y en a 7 actuellement) et du président de l’IETF qui est aussi le président de l’IESG. L’IESG administre le processus de standardisation de l’Internet suivant des règles et procédures détaillées dans [RFC2028].<br />
C'est donc l’IESG qui décide de l’évolution du statut des spécifications techniques émises par les groupes de travail, ce qui peut élever certaines d’entre elles au rang de Standard Internet. L’IESG approuve également la constitution des nouveaux groupes de travail.<br />
<br />
===Les RFC (''Request For Comments'')===<br />
<br />
Les RFC sont les documents officiels de l’Internet ; ils sont disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/. Un RFC est complètement identifié par le numéro qui lui est attribué lors de sa publication. Ce numéro n'a pas de signification ; il est attribué par ordre chronologique de publication. Les premiers RFC sont sortis en 1969 ; début 2002, nous en sommes au numéro 3221, pour un flux supérieur à 200 RFC par an.<br />
Il existe plusieurs types de RFC d’importance différente pour la communauté IETF. On distingue deux catégories principales : ceux faisant partie du processus de standardisation (''Standard Track'') et les autres.<br />
<br />
Les documents entrant dans la première catégorie suivent un parcours bien défini. Ils sont d’abord publiés comme "Internet Drafts" par le groupe de travail. Ce sont des documents de travail à durée de vie limitée, disponibles en ligne sur les mêmes serveurs que les RFC. Lorsqu’un consensus semble atteint, le responsable lance un appel aux derniers commentaires dans le groupe. Il transmet ensuite le document à l’IESG qui, à son tour, lance un appel aux derniers commentaires à tout l’IETF. S’il n’y a pas d’objections majeures, le document est alors publié comme RFC avec un statut de (''Proposed Standard'').<br />
<br />
Après une période où se succèdent mises en œuvre et retours d’informations sur le protocole décrit, le groupe de travail auteur revoit le document.<br />
<br />
Si seuls des changements mineurs sont nécessaires, il demande alors à l’IESG de le faire avancer en le publiant en tant que nouveau RFC mais avec un statut de Draft Standard) après un nouvel appel à commentaires. Si les changements sont majeurs, le nouveau RFC garde le statut de Proposed Standard.<br />
<br />
Suit alors une nouvelle période de mises en œuvre et de retours d’informations où l’on doit faire la preuve de l’interopérabilité de deux implantations indépendantes. Puis le responsable du groupe de travail demande à l’IESG de faire avancer le document en le publiant (après un dernier appel à commentaires) en tant que RFC avec un statut de type "Standard". Il faut noter qu’à chaque étape, un nouveau numéro de RFC est attribué. Un RFC peut passer à l’état "historique" si son utilisation est devenue déconseillée. S’il est remplacé par un autre il devient "obsolète".<br />
<br />
La publication d’un RFC hors du processus de standardisation est plus facile. L’IESG peut directement faire publier un RFC avec un statut de type "Information", "Experimental" ou ''Best Current Practice''). Un RFC "Information" documente un protocole ou une approche particulière d’un problème. Il peut aussi donner des informations d’intérêt général. Il n’a aucune valeur de standard. Un RFC "Expérimental" décrit un protocole nécessitant que l’on mène des expériences avant de décider ou non d’entrer dans le processus de standardisation. Un RFC Best Current Practice documente une pratique d’ingénierie recommandée. La répartition par types des RFC édités en 2001 est donnée dans figure 17-2.<br />
<br />
===L'ISOC (Internet Society)===<br />
<br />
L’ISOC est une organisation internationale s’occupant de la croissance et de l’évolution de l’Internet à l’échelle mondiale et des aspects sociaux, politiques et techniques de son utilisation. Les membres de l’ISOC sont des personnes physiques ou morales. L’ISOC est dirigée par un Bureau des Administrateurs élu par les membres individuels.<br />
La standardisation de l’Internet est une activité chapeautée par l’ISOC, le Bureau des Administrateurs étant responsable de l’approbation des procédures et des règles du processus de standardisation de l’Internet.<br />
Le moyen selon lequel les membres du Bureau des Administrateurs de l’ISOC sont choisis, et les autres aspects concernant le fonctionnement de l’Internet Society sont décrits dans le document ISOC By-Laws [RFC 2135] et http://www.isoc.org.<br />
<br />
===L’IAB (Internet Architecture Board)===<br />
<br />
L’IAB est chargé par les Administrateurs de l’ISOC de fournir une supervision de l’architecture de l’Internet et de ses protocoles. L’IAB désigne le président de l’IETF et approuve les autres candidats pour l’IESG, présentés par le comité de nomination. L’IAB est aussi responsable de l’examen et de l’approbation des chartes des nouveaux groupes de travail proposés.<br />
<br />
L’IAB supervise le processus utilisé pour créer des Standards Internet et sert de cour d’appel pour les réclamations comme par exemple une violation des procédures de standardisation, ou pour un conflit entre les groupes de travail de l’IETF et l’IESG. L’IAB conseille l’IETF et l’ISOC en matière technique, politique, d’architecture, de procédure se rapportant à l’Internet et aux technologies associées. Les membres de l’IAB sont nommés par un comité (le Nomcom) et approuvés par le conseil d’administration de l’ISOC.<br />
<br />
===L’ICANN (Internet Corporation for Assigned Names and Numbers)===<br />
<br />
L’ICANN est un organisme international créé en octobre 1998 pour remplacer l’IANA (Internet Assigned Numbers Authority) qui n’était contrôlé que par le gouvernement américain. <br />
Beaucoup de spécifications de protocoles comportent des nombres, mots clés et paramètres qui doivent être affectés de manière unique, par exemple les numéros de versions, les numéros de protocoles, les numéros de ports et de MIB (Management Information Base). C'est l’ICANN qui affecte les valeurs de ces paramètres pour l’Internet. L’ICANN publie aussi les tables de toutes les valeurs affectées dans des RFC nommés Assigned Numbers. L’ICANN sert aussi de "sommet de la pyramide" pour la gestion des domaines de noms (DNS) et l’affectation des adresses et en établit les règles.<br />
<br />
===Les RIR (Regional Internet Registries)===<br />
<br />
Les RIR ou RIAR (''Regional Internet Address Registries'') reçoivent une délégation de l’ICANN pour distribuer les adresses IPv4 et IPv6. Ils sont au nombre de trois actuellement, répartis sur 4 continents pour assurer une gestion de "proximité" à celle échelle. Ce sont :<br />
*APNIC : Asia Pacific Network Information Centre,<br />
*ARIN : American Registry for Internet Numbers,<br />
*RIPE-NCC : Réseaux IP Européen (Network Coordination Centre),<br />
*LACNIC : Réseaux d'Amérique Latine et des Caraïbes. <br />
<br />
Un cinquième, l’AFRINIC destiné à assurer la couverture du continent Africain est en cours de gestation (l’Afrique dépend actuellement du RIPE et de l’APNIC). En 2001, sept préfixes IPv4 de longueur 16 ont été affectés aux RIR pour être distribués aux opérateurs</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Historique_de_la_standardisation_d%E2%80%99IPv6&diff=2972Historique de la standardisation d’IPv62006-02-27T13:52:36Z<p>Bruno Deniaud: /* <div id="stand">La standardisation de l'Internet</div> */</p>
<hr />
<div>Cette annexe décrit les principales étapes qui jalonnent la standardisation d’IPv6, depuis la prise en compte de la nécessité d’un nouveau protocole jusqu’à la production de standards. Ce processus est toujours en cours même si une grande partie du chemin a déjà été parcourue.<br />
<br />
==<div id="stand">La standardisation de l'Internet</div>==<br />
<br />
Il est difficile de comprendre comment est né IPv6, et comment le protocole continue d’évoluer, si l’on ne connaît pas le processus de standardisation des protocoles utilisés dans l’Internet.<br />
Les organismes qui pilotent la standardisation de l’Internet sont l’IETF, l’IESG, l’IAB, l’ISOC et l’ICANN. Le résultat final de l’activité de standardisation est la production de documents appelés RFC (Request for Comments) dont certains sont des standards. L’ensemble du processus de standardisation est décrit dans le RFC 2026.<br />
<br />
===L'IETF (''Internet Engineering Task Force'')===<br />
<br />
L’activité au sein de l'’ETF est organisée en groupes de travail (''working group''). Les groupes agissant autour d’un même thème sont regroupés dans un Domaine (Area), comme le routage, la gestion des réseaux, la sécurité... Chaque Domaine est coordonné par un directeur (Area Director). L’ensemble des directeurs de Domaines compose l’IESG (voir ci-après).<br />
Les groupes de travail de l’IETF sont constitués de personnes volontaires et bénévoles qui sont motivées pour faire évoluer les standards de l’Internet sur la base de leur expérience acquise à partir de mises en œuvre et d’essais concrets. Toute personne intéressée (et ayant des disponibilités) peut faire partie d’un groupe de travail IETF. La participation à l’IETF et à ses groupes de travail est donc le fait d’individus proposant des contributions techniques plutôt que de représentants formels d’organisations.<br />
Chaque groupe de travail définit ses objectifs dans une charte, qu’il soumet à l’IESG lors de son processus de constitution. Le groupe est dirigé par un ou plusieurs présidents (''Working Group Chairs''). Le fonctionnement des groupes de travail de l’IETF est décrit en détail dans le RFC 2418.<br />
Dans un groupe le travail, les échanges de points de vue et d’expériences visant à élaborer les projets de standards (''Internet Drafts''), se font essentiellement par courrier électronique. Trois réunions annuelles permettent aux membres des groupes de se rencontrer pour une interaction plus directe. Lorsqu’un consensus est atteint, le groupe en demande la publication en tant que RFC (''Request For Comments'').<br />
Quand un groupe considère que ses objectifs sont atteints, il se dissout.<br />
Un certain nombre de groupes et sous-groupes IETF travaillent actuellement sur IPv6 ; on peut citer notamment:<br />
*IPng (aujourd'hui IPv6) : principal groupe de travail sur la production de protocoles liés à IPv6.<br />
*NGtrans : étudie les modalités de la migration d’IPv4 vers IPv6. Ce groupe gère le déploiement du 6bone, un réseau expérimental IPv6 interconnectant des sites de test à travers le monde. <br />
Les groupes de travail de l’IETF doivent faire preuve d’esprit de coopération, ainsi que d’un haut degré de maturité technique ; les participants à l’IETF reconnaissent que les plus grands bénéfices pour tous les membres de la communauté de l’Internet proviennent du développement coopératif des protocoles et services (voir http://www.ietf.org pour plus de détails).<br />
<br />
===L'IESG (''Internet Engineering Steering Group'')===<br />
<br />
L’IESG est responsable de la direction des activités techniques de l’IETF. Il est composé des directeurs de Domaines (il y en a 7 actuellement) et du président de l’IETF qui est aussi le président de l’IESG. L’IESG administre le processus de standardisation de l’Internet suivant des règles et procédures détaillées dans [RFC2028].<br />
C'est donc l’IESG qui décide de l’évolution du statut des spécifications techniques émises par les groupes de travail, ce qui peut élever certaines d’entre elles au rang de Standard Internet. L’IESG approuve également la constitution des nouveaux groupes de travail.<br />
<br />
===Les RFC (''Request For Comments'')===<br />
<br />
Les RFC sont les documents officiels de l’Internet ; ils sont disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/. Un RFC est complètement identifié par le numéro qui lui est attribué lors de sa publication. Ce numéro n'a pas de signification ; il est attribué par ordre chronologique de publication. Les premiers RFC sont sortis en 1969 ; début 2002, nous en sommes au numéro 3221, pour un flux supérieur à 200 RFC par an.<br />
Il existe plusieurs types de RFC d’importance différente pour la communauté IETF. On distingue deux catégories principales : ceux faisant partie du processus de standardisation (''Standard Track'') et les autres.<br />
<br />
Les documents entrant dans la première catégorie suivent un parcours bien défini. Ils sont d’abord publiés comme "Internet Drafts" par le groupe de travail. Ce sont des documents de travail à durée de vie limitée, disponibles en ligne sur les mêmes serveurs que les RFC. Lorsqu’un consensus semble atteint, le responsable lance un appel aux derniers commentaires dans le groupe. Il transmet ensuite le document à l’IESG qui, à son tour, lance un appel aux derniers commentaires à tout l’IETF. S’il n’y a pas d’objections majeures, le document est alors publié comme RFC avec un statut de (''Proposed Standard'').<br />
<br />
Après une période où se succèdent mises en œuvre et retours d’informations sur le protocole décrit, le groupe de travail auteur revoit le document.<br />
<br />
Si seuls des changements mineurs sont nécessaires, il demande alors à l’IESG de le faire avancer en le publiant en tant que nouveau RFC mais avec un statut de Draft Standard) après un nouvel appel à commentaires. Si les changements sont majeurs, le nouveau RFC garde le statut de Proposed Standard.<br />
<br />
Suit alors une nouvelle période de mises en œuvre et de retours d’informations où l’on doit faire la preuve de l’interopérabilité de deux implantations indépendantes. Puis le responsable du groupe de travail demande à l’IESG de faire avancer le document en le publiant (après un dernier appel à commentaires) en tant que RFC avec un statut de type "Standard". Il faut noter qu’à chaque étape, un nouveau numéro de RFC est attribué. Un RFC peut passer à l’état "historique" si son utilisation est devenue déconseillée. S’il est remplacé par un autre il devient "obsolète".<br />
<br />
La publication d’un RFC hors du processus de standardisation est plus facile. L’IESG peut directement faire publier un RFC avec un statut de type "Information", "Experimental" ou ''Best Current Practice''). Un RFC "Information" documente un protocole ou une approche particulière d’un problème. Il peut aussi donner des informations d’intérêt général. Il n’a aucune valeur de standard. Un RFC "Expérimental" décrit un protocole nécessitant que l’on mène des expériences avant de décider ou non d’entrer dans le processus de standardisation. Un RFC Best Current Practice documente une pratique d’ingénierie recommandée. La répartition par types des RFC édités en 2001 est donnée dans figure 17-2.<br />
<br />
===L'ISOC (Internet Society)===<br />
<br />
L’ISOC est une organisation internationale s’occupant de la croissance et de l’évolution de l’Internet à l’échelle mondiale et des aspects sociaux, politiques et techniques de son utilisation. Les membres de l’ISOC sont des personnes physiques ou morales. L’ISOC est dirigée par un Bureau des Administrateurs élu par les membres individuels.<br />
La standardisation de l’Internet est une activité chapeautée par l’ISOC, le Bureau des Administrateurs étant responsable de l’approbation des procédures et des règles du processus de standardisation de l’Internet.<br />
Le moyen selon lequel les membres du Bureau des Administrateurs de l’ISOC sont choisis, et les autres aspects concernant le fonctionnement de l’Internet Society sont décrits dans le document ISOC By-Laws [RFC 2135] et http://www.isoc.org.<br />
<br />
===L’IAB (Internet Architecture Board)===<br />
<br />
L’IAB est chargé par les Administrateurs de l’ISOC de fournir une supervision de l’architecture de l’Internet et de ses protocoles. L’IAB désigne le président de l’IETF et approuve les autres candidats pour l’IESG, présentés par le comité de nomination. L’IAB est aussi responsable de l’examen et de l’approbation des chartes des nouveaux groupes de travail proposés.<br />
<br />
L’IAB supervise le processus utilisé pour créer des Standards Internet et sert de cour d’appel pour les réclamations comme par exemple une violation des procédures de standardisation, ou pour un conflit entre les groupes de travail de l’IETF et l’IESG. L’IAB conseille l’IETF et l’ISOC en matière technique, politique, d’architecture, de procédure se rapportant à l’Internet et aux technologies associées. Les membres de l’IAB sont nommés par un comité (le Nomcom) et approuvés par le conseil d’administration de l’ISOC.<br />
<br />
===L’ICANN (Internet Corporation for Assigned Names and Numbers)===<br />
<br />
L’ICANN est un organisme international créé en octobre 1998 pour remplacer l’IANA (Internet Assigned Numbers Authority) qui n’était contrôlé que par le gouvernement américain. <br />
Beaucoup de spécifications de protocoles comportent des nombres, mots clés et paramètres qui doivent être affectés de manière unique, par exemple les numéros de versions, les numéros de protocoles, les numéros de ports et de MIB (Management Information Base). C'est l’ICANN qui affecte les valeurs de ces paramètres pour l’Internet. L’ICANN publie aussi les tables de toutes les valeurs affectées dans des RFC nommés Assigned Numbers. L’ICANN sert aussi de "sommet de la pyramide" pour la gestion des domaines de noms (DNS) et l’affectation des adresses et en établit les règles.<br />
<br />
===Les RIR (Regional Internet Registries)===<br />
<br />
Les RIR ou RIAR (''Regional Internet Address Registries'') reçoivent une délégation de l’ICANN pour distribuer les adresses IPv4 et IPv6. Ils sont au nombre de trois actuellement, répartis sur 4 continents pour assurer une gestion de "proximité" à celle échelle. Ce sont :<br />
*APNIC : Asia Pacific Network Information Centre,<br />
*ARIN : American Registry for Internet Numbers,<br />
*RIPE-NCC : Réseaux IP Européen (Network Coordination Centre),<br />
*LACNIC : Réseaux d'Amérique Latine et des Caraïbes. <br />
<br />
Un cinquième, l’AFRINIC destiné à assurer la couverture du continent Africain est en cours de gestation (l’Afrique dépend actuellement du RIPE et de l’APNIC). En 2001, sept préfixes IPv4 de longueur 16 ont été affectés aux RIR pour être distribués aux opérateurs</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Bibliographie&diff=2971Bibliographie2006-02-27T13:35:11Z<p>Bruno Deniaud: /* Autres Références */</p>
<hr />
<div>= Livres sur IPv6 =<br />
<br />
<div id="BM95">[BM95] S. O. Bradner & A. Mankin ed : IPng, Internet Protocol Next Generation, Addison-Wesley (IPng Series), ISBN0201633957, Septembre 1995.</div><br />
<br />
[Gai98] S. Gai, Internetworking IPv6 With Cisco Routers (Computer Communications), McGraw-Hill, ISBN: 0-070-22836-1, Février 1998.<br />
<br />
[Hui97] C. Huitema: IPv6: The New Internet Protocol, Prentice Hall, ISBN: 0-138-50505-5, Octbre 1997.<br />
<br />
[LL99] Peter Loshin & Pete Loshin: IPv6 Clearly Explained (Clearly Explained), Ap Professional, ISBN: 0-124-55838-0, Janvier 1999.<br />
<br />
[MM00] Mark A. Miller & P. E. Miller: Implementing IPv6, second edition (Network Troubleshooting Library), IDG Books Worldwide, ISBN: 0-764-54589-2, Janvier 2000.<br />
<br />
<br />
[Mil97] Stewart S. Miller: IPv6 : The Next Generation Internet Protocol, DigitalPress, ISBN: 1-555-58188-9, Décembre 1997.<br />
<br />
[MK98] Marcus Goncalves & Kitty Niles: IPv6 Networks, McGraw-Hill, ISBN: 0-070-24807-9, Mai 1998.<br />
<br />
[Sal00] Peter H. Salus: Big Book of IPV6 Addressing RFCs, Morgan Kaufmann Publishers, ISBN: 0-126-16770-2, Mars 2000.<br />
<br />
[WR99] J. D. Wegner & Robert Rockwell: IP Addressing and Subnetting, Including IPv6, Syngress Media, ISBN: 1-928-99401-6, Décembre 1999.<br />
<br />
== Internet Drafts sur IPv6 ==<br />
<br />
''Remarque : Il faut rappeler que les Internet drafts sont des documents de travail à durée de vie limitée. Ils ont vocation à devenir des RFC. Le lecteur est donc invité à vérifier quelle est la version la plus récente, ou si un RFC le remplace, en consultant l'index à jour (cf. Les RFC (Request For Comments)).''<br />
<br />
;<div id="BCP2-id">[BCP2-id]</div><br />
: J. Bound, M. Carney, C. Perkins: Extensions for the Dynamic Host Configuration Protocol for IPv6, [http://www.watersprings.org/pub/id/draft-ietf-dhcpv6exts-12.txt draft-ietf-dhc-v6exts-12.txt], Internet Draft, 5 Mai 2000 - Obsolete.<br />
<br />
;<div id="BKLSPTSDY-id">[BKLSPTSDY-id]</div><br />
: W. Biemolt, M. Kaat, T. Larder, H. Steenman, R. van der Pol, G. Tsirtsis, Y. Sekiya, A. Durand, K. Yamamoto: On overview of the introduction of IPv6 in the Internet, draft-ietf-ngtrans-introduction-to-ipv6-transition-08.txt, Internet Draft, Février 2002. Working Group Concluded.<br />
<br />
;<div id="BTM-id>[BTM-id]</div><br />
: J. Bound, L. Toutain, O. Medina, F. Dupont, A. Durand, H Afifi,: Dual Stack Transition Mechanism (DSTM), draft-ietf-ngtrans-dstm-07.txt, Internet Draft, Aout 2002. Obsolete.<br />
<br />
;<div id="BP-id">[BP-id]</div><br />
: M. Blanchet, F. Parent, IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP), [http://www.watersprings.org/pub/id/draft-blanchet-v6ops-tunnelbroker-tsp-03.txt draft-blanchet-v6ops-tunnelbroker-tsp-03.txt], Aout 2005. Work in progress.<br />
<br />
;<div id="CMB-id">[CMB-id]</div><br />
: Hesham Soliman, Claude Castelluccia, Karim Malki, Ludovic Bellier, Hierarchical Mobile IPv6 mobility management (HMIPv6), [http://www.watersprings.org/pub/id/draft-ietf-mipshop-hmipv6-04.txt draft-ietf-mipshop-hmipv6-04.txt], Décembre 04. Obsolete - Experimental RFC 4140.<br />
<br />
;<div id="Craw-id">[Craw-id]</div><br />
: Matt Crawford: IPv6 Node Information Queries, [http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-15.txt draft-ietf-ipngwg-icmp-name-lookups-15.txt, Internet Draft, 13 Février 2006. Work in progress.<br />
<br />
;<div id="Drave-id">[Drave-id]</div><br />
: R. Draves: Default Address Selection for IPv6, draft-ietf-ipngwg-default-addr-select-06.txt, Internet Draft, 28 Septembre 2001. Obsolete - RFC 3484.<br />
<br />
;<div id="DHZ-id">[DHZ-id]</div><br />
: S. Deering, B. Haberman, B. Zill, T. Jinmei, E. Nordmark, A. Onoe: IP Version 6 Scoped Address Architecture, draft-ietf-ipngwg-scoping-arch-03.txt Internet Draft, 30 Novembre 2001. Obsolete - RFC 4007.<br />
<br />
;<div id="DIS-id">[DIS-id]</div><br />
: Alain Durand, Johan Ihren, Pekka Savola, Operational Considerations and Issues with IPv6 DNS, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-issues-12.txt draft-ietf-dnsop-ipv6-dns-issues-12.txt], Internet Draft, 19 Octobre 2005,. Work in progress. <br />
<br />
;<div id="Dupont-id">[Dupont-id]</div><br />
: F. Dupont, M. Laurent-Maknavicius: AAA for mobile IPv6, draft-dupont-mipv6-AAA-01.txt, Internet Draft, 20 Novembre 2001, Obsolete.<br />
<br />
;<div id="Ernst-id">[Ernst-id]</div><br />
: Thierry Ernst, Network Mobility Support Requirements, [http://www.watersprings.org/pub/id/draft-ietf-nemo-requirements-05.txt draft-ietf-nemo-requirements-05.txt], Octobre 2005<br />
<br />
;<div id="Fenner-id">[Fenner-id]</div><br />
: Bill Fenner, Haixiang He, Brian Haberman, Hal Sandick, IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying'), [http://www.watersprings.org/pub/id/draft-ietf-magma-igmp-proxy-06.txt draft-ietf-magma-igmp-proxy-06.txt]<br />
<br />
;<div id="Fenner2-id">[Fenner2-id]</div><br />
: Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas Protocol Independent Multicast - Sparse Mode (PIM -SM): Protocol Specification (Revised), IETF Internet Draft, [http://www.watersprings.org/pub/id/draft-ietf-pim-sm-v2-new-11.txt draft-ietf-pim-sm-v2-new-11.txt], 4 Octobre 2004. Work in progress.<br />
<br />
;<div id="Haber-id">[Haber-id]</div><br />
: B. Haberman: Dynamic Allocation Guidelines for IPv6 Multicast Addresses, draft-ietf-malloc-ipv6-guide-01.txt, Internet Draft, 12 Octobre 2000. Obsolete - RFC 3307.<br />
<br />
;<div id="HD-id">[HD-id]</div><br />
: R. Hinden, S. Deering: IP Version 6 Addressing Architecture, [[http://tools.ietf.org/wg/ipv6/draft-ietf-ipv6-addr-arch-v4/draft-ietf-ipv6-addr-arch-v4-04.txt draft-ietf-ipv6-addr-arch-v4-04.txt]], Internet Draft, 20 Mai 2005. Work in progress.<br />
<br />
;<div id="HH-id">[HH-id]</div><br />
: Robert Hinden, Brian Haberman, Centrally Assigned Unique Local IPv6 Unicast Addresses, [http://www.watersprings.org/pub/id/draft-ietf-ipv6-ula-central-01.txt draft-ietf-ipv6-ula-central-01.txt], Internet Draft, 21 Février 2005, Obsolete - See RFC 4193.<br />
<br />
;<div id="Hopps-if">[Hopps-id]</div><br />
: C. E. Hopps: Routing IPv6 with IS-IS, [http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-06.txt draft-ietf-isis-ipv6-06.txt], Internet Draft, Octobre 2005. Work in progress.<br />
<br />
;<div id="Huitema-id">[Huitéma-id]</div><br />
: C. Huitema, Teredo: Tunneling IPv6 over UDP through NATs, [http://www.watersprings.org/pub/id/draft-huitema-v6ops-teredo-05.txt draft-huitema-v6ops-teredo-05.txt], Avril 2005, Obsolete - See RFC 4380.<br />
<br />
;<div id="Jeong-id">[Jeong-id]</div><br />
: Jae-Hoon Jeong, IPv6 Host Configuration of DNS Server Information Approaches, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-configuration-06.txt draft-ietf-dnsop-ipv6-dns-configuration-06.txt], Internet Draft, 5 Mai 2005. RFC Editor Queue.<br />
<br />
;<div id="JP-id">[JP-id]</div><br />
: D. B. Johnson, C. Perkins: Mobility Support in IPv6, draft-ietf-mobileip-ipv6-15.txt, Internet Draft, 2 Juillet 2001. Obsolete - RFC 3775.<br />
<br />
; <div id="NFG-id">[NGF-id]</div><br />
: Tri Nguyen, Gerard Gastaud, Francois Le Faucheur, Dirk Ooms, Jeremy De Clercq, Stuart Prevost, Connecting IPv6 Domains across IPv4 Clouds with BGP, [http://tools.ietf.org/wg/v6ops/draft-ooms-v6ops-bgp-tunnel-06.txt draft-ooms-v6ops-bgp-tunnel-06.txt], Janvier 2006. Proposed standard.<br />
<br />
;<div id="NPE-id">[NPE-id]</div><br />
: Chan Wah Ng, Eun Kyoung Paik, Thierry Ernst, Analysis of Multihoming in Network Mobility Support, [http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-04.txt draft-ietf-nemo-multihoming-issues-04.txt], 24 Octobre 2005. Work in progress<br />
<br />
;<div id="Prz-id">[Prz-id]</div><br />
: Tony Przygienda, M-ISIS: Multi Topology (MT) Routing in IS-IS, [http://www.watersprings.org/pub/id/draft-ietf-isis-wg-multi-topology-11.txt draft-ietf-isis-wg-multi-topology-11.txt], 21 Octobre 2005.<br />
<br />
;<div id="Prigent-id">[Prigent-id]</div><br />
: N. Prigent, J. Marchand, F. Dupont, B. Cousin, M. Laurent-Maknavicius, J. Bournelle: DHCPv6 Threats, draft-prigent-dhcpv6-threats-00.txt, Internet Draft, 24 mai 2001, Expired.<br />
<br />
;<div id="RFC2547bis">[RFC2547bis]</div><br />
: Eric C. Rosen, Yakov Rekhter, BGP/MPLS IP VPNs, [http://www.watersprings.org/pub/id/draft-ietf-l3vpn-rfc2547bis-03.txt draft-ietf-l3vpn-rfc2547bis-03.txt], Internet Draft, October 2004, Obsolete - RFC 4364.<br />
<br />
;<div id="Templin-id">[Templin-id]</div><br />
:Fred Templin, T. Gleeson, M. Talwar D. Thaler, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), [http://www.watersprings.org/pub/id/draft-ietf-ngtrans-isatap-24.txt draft-ietf-ngtrans-isatap-24.txt], Juillet 2005, Obsolete - RFC 4214.<br />
<br />
;<div id="Thubert-id">[Thubert-id]</div><br />
:Pascal Thubert, NEMO Home Network models, [http://www.watersprings.org/pub/id/draft-ietf-nemo-home-network-models-06.txt draft-ietf-nemo-home-network-models-06.txt], 17 Fevrier 2006.<br />
<br />
==Autres documents de travail==<br />
[FIPS-46]<br />
<br />
Data Encryption Standard, Federal Information Processing Standards Publication 46, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 15 Janvier 1977.<br />
<br />
[FIPS-81]<br />
<br />
DES Modes of Operation, Federal Information Processing Standards Publication 81, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 2 Décembre 1980.<br />
<br />
[FIPS-180-1]<br />
<br />
Secure Hash Standard, Federal Information Processing Standards Publication 180-1, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, Avril 1995.<br />
<br />
==Autres Références==<br />
[AL00]<br />
<br />
Mohammed Achemlal, Maryline Laurent, Analyse des fonctions des protocoles IPsec et leur intégration dans un réseau privé virtuel, Annales des télécommunications, 2000.<br />
<br />
<br />
[AL98]<br />
<br />
P. Albitz and C. Liu: DNS and BIND, 3rd Edition, ISBN: 1-56592-512-2, O'Reilly and Associates, Septembre 1998.<br />
<br />
<br />
;<div id="BTC02">[BTC02]</div><br />
: T. Bu, L. Gao, D. Towsley, On Characterizing Routing Table Growth, GlobalInternet 2002. http://www-unix.ecs.umass.edu/~lgao/globalinternet2002_tian.pdf<br />
<br />
<br />
;<div id="Ernst01f-fr">[Ernst01f-fr]</div><br />
:Ernst, Thierry, Le Support des Réseaux Mobiles dans IPv6, UniversitéJoseph Fourier, Octobre 2001, Grenoble, France, http://www.inria.fr/rrrt/tu-0714.html<br />
<br />
<br />
;<div id="Ernst03f">[Ernst03f]</div><br />
:Thierry Ernst, Le Support des Réseaux Mobiles dans IPv6, CFIP: Colloque Francophone sur l'Ingenierie des Protocoles, Octobre 2003, Paris<br />
<br />
<br />
[Fen-id]<br />
<br />
Bill Fenner, Management Information Base for the User Datagram Protocol (UDP), draft-ietf-ipv6-rfc2013-update-04.txt, Internet Draft, 20 Octobre 2004, Work in progress.<br />
<br />
<br />
[Hui95]<br />
<br />
C. Huitema: Le routage dans l'Internet, Eyrolles, Octobre 1995.<br />
<br />
[IEEE]<br />
<br />
Protocol Independant Interfaces, IEEE Std 1003.1g, DRAFT~6.6, Mars 1997.<br />
<br />
<br />
;<div id="JH-id">[JH-id]</div><br />
: Jeffrey Haas, Susan Hares, Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), draft-ietf-idr-bgp4-mib-05.txt, Internet Draft, 31 Août 2004, Work in progress.<br />
<br />
<br />
[JM-id]<br />
<br />
Dan Joyal, Vishwas Manral, Management Information Base for OSPFv3, draft-ietf-ospf-ospfv3-mib-09.txt, Internet Draft, 13 Mai 2005, Work in progress.<br />
<br />
<br />
;<div id="Kau-id">[Kau-id]</div><br />
:Charlie Kaufman, Internet Key Exchange (IKEv2) Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-ikev2-17.txt draft-ietf-ipsec-ikev2-17.txt], Internet Draft, 4 Octobre 2004, Work in progress.<br />
<br />
;<div id="LAU03">[LAU03]</div><br />
: M. Laurent-Maknavicius, Le protocole IPsec, [http://www.techniques-ingenieur.fr/affichage/DispIntro.asp?nGcmID=TE7545 TE7545], [http://www.techniques-ingenieur.fr/ Techniques de l'Ingénieur], Sécurité des systèmes d'information, Novembre 2003.<br />
<br />
[LAU04-A]<br />
<br />
M. Laurent-Maknavicius, M. Gardie, LDAP et la certification, Rapport de recherche du GET, 04001 LOR, 2004.<br />
<br />
[LAU04-B]<br />
<br />
M. Laurent-Maknavicius, La sécurité de l'accès distant, Technique et Science Informatiques (TSI), 2004.<br />
<br />
;<div id="MHF-id">[MHF-id]</div><br />
:Ambarish Malpani, Russ Housley, Trevor Freeman, Simple Certificate Validation Protocol (SCVP), [http://www.watersprings.org/pub/id/draft-ietf-pkix-scvp-22.txt draft-ietf-pkix-scvp-22.txt], Internet Draft, Octobre 2005, Work in progress.<br />
<br />
;<div id="Mos-id">[Mos-id]</div><br />
:Robert Moskowitz, Host Identity Protocol, [http://www.watersprings.org/pub/id/draft-ietf-hip-base-04.txt draft-ietf-hip-base-04.txt], Internet Draft, 24 Octobre 2005, Work in progress<br />
<br />
;<div id="Pui02-A">[Pui02-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse critique d'IPsec, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-analyse-rapport/ipsec-analyse-rapport.pdf rapport de recherche 03 004 LOR], 2002.<br />
<br />
;<div id="Pui02-B">[Pui02-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse de l'impact de la mise en oeuvre d'IPsec dans les architectures de Communication, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-interactions-rapport/ipsec-interactions-rapport.pdf rapport de recherche 03 002 LOR], octobre 2002.<br />
<br />
;<div id="Pui03">[Pui03]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects ARP), [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/environnement-reel-1-rapport/environnement-reel-1-rapport.pdf rapport de recherche 03 001 LOR], janvier 2003.<br />
<br />
;<div id="Pui04-A">[Pui04-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Etude des interactions IPsec/DNS, [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/InteractionDNS.pdf rapport de recherche 04002 LOR], 2004.<br />
<br />
;<div id="Pui04-B">[Pui04-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects liés à ICMP), [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/IPsec_ICMP.pdf rapport de recherche 04004 LOR], 2004.<br />
<br />
;<div id="RFC2401bis">[RFC2401bis]</div><br />
: Stephen Kent, Karen Seo, Security Architecture for the Internet Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2401bis-06.txt draft-ietf-ipsec-rfc2401bis-06.txt], Internet Draft, 1 Avril 2005, Work in progress<br />
<br />
<br />
;<div id="RFC2402bis">[RFC2402bis]</div><br />
:Stephen Kent, IP Authentication Header, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2402bis-11.txt draft-ietf-ipsec-rfc2402bis-11.txt], Internet Draft, 21 Mars 2005, Work in progress.<br />
<br />
[Rou-id]<br />
<br />
Shawn Routhier, Management Information Base for the Internet Protocol (IP), draft-ietf-ipv6-rfc2011-update-10.txt; Internet Draft, 24 Mai 2004, Work in progress.<br />
<br />
[Sch95]<br />
<br />
B. Schneier: Applied Cryptography : protocols, algorithms, and source code in C, (second edition), John Wiley & Sons, ISBN: 0-471-12845-7, 1996.<br />
<br />
[Sta99]<br />
<br />
William Stallings: Snmp, Snmpv2, Snmpv3, and Rmon 1 and 2, Addison Wesley, ISBN: 0-201-48534-6, Janvier 1999.<br />
<br />
[Tout03]<br />
<br />
Laurent Toutain: Réseaux Locaux et Internet: des protocoles à l'interconnexion, Troisième édition revue et augmentée, Hermès, ISBN: 2-7462-0670-6, 2003.<br />
<br />
[Uni31]<br />
<br />
ATM Forum: ATM User-Network Interface (UNI) Specification Version 3.1, Prentice Hall, Englewood Cliffs, NJ, Juin 1995.<br />
<br />
[WH-id]<br />
<br />
Margaret Wasserman, Brian Haberman, IP Forwarding Table MIB, draft-ietf-ipv6-rfc2096-update-07.txt, Internet Draft, 12 février 2004, Work in progress.<br />
<br />
[WK99]<br />
<br />
M. Welsh et L. Kaufman: Le système Linux, 2e édition révisée, Éditions O'Reilly, ISBN: 2-84177-033-8, Janvier 1999.<br />
<br />
==Sites Web sur IPv6 ==<br />
<br />
;[IETF]<br />
:http://www.imag.fr/pub/archive/IETF: Mirroir français du serveur de l'IETF.<br />
<br />
;[6bone]<br />
:http://www.6bone.net: Réseau 6bone.<br />
<br />
;[G6bone]<br />
:http://peirce.logique.jussieu.fr/G6/ Réseau G6-bone (partie francophone de 6bone).<br />
<br />
;[hs247] <br />
:http://hs247.com/ Informations sur le 6bone et IPv6 en général.<br />
<br />
;[ipv6.org]<br />
: http://www.ipv6.org/ pages d'information sur le protocole IPv6<br />
<br />
;[ipv6forum] <br />
:http://www.ipv6forum.org/ Groupement d'industriels pour promouvoir IPv6.<br />
<br />
;[playground] <br />
:http://playground.sun.com/pub/ipng/html/ipng-main.html liste des mises en oeuvre d'IPv6 dans les équipements.</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Mise_en_%C5%93uvre_par_les_constructeurs&diff=2970Mise en œuvre par les constructeurs2006-02-27T13:33:32Z<p>Bruno Deniaud: /* Les MIBs */</p>
<hr />
<div>{{suivi |Supervision|Supervision|Les applications spécifiques |Les applications spécifiques}}<br />
<br />
<br />
Dans cette partie, nous avons choisi un ensemble de constructeurs dont leurs équipements offrent des fonctionnalités pour la supervision des réseaux IPv6. A noter que cette liste n’est pas exhaustive.<br />
Dans un premier temps, certains constructeurs implémentant des MIBs IPv6 seront passés en revue, ensuite, dans un second temps ceux proposant l’utilisation de SNMP en IPv6 seront listé. Nous présenterons ceux qui offrent la possibilité d’exporter des flux IPv6 vers un collecteur.<br />
<br />
===Les MIBs===<br />
<br />
Nous avons vu précédemment que le modèle SNMP est très utilisé ; il est donc important que les constructeurs implémentent les MIBs définies par l’IETF :<br />
*Juniper a conçu une première réalisation en mettant en œuvre une MIB privée en se basant sur le RFC 2465. Cette MIB permet en autre de faire de la métrologie sur le nombre de paquets entrants et sortants. D’autre part, ce constructeur a implémenté une MIB privée basée sur le draft [[Bibliographie#JH-id|JH-id]] qui permet de récupérer des informations sur le routage BGP4.<br />
*Cisco a mis en œuvre sur ses équipements une MIB privée (CISCO-IETF-IP-MIB) permettant de récupérer un certain nombre d’informations IPv6 de base (interfaces, messages ICMP). Par contre, il n’a pas encore développé une MIB permettant de différencier le trafic sur les interfaces transportant les deux versions IP le trafic IPv6.<br />
*Hitachi a développé sur ces routeurs (GR2000/GR4000) et sur les switchs (GS4000) les MIBs décrites dans les RFC 2452, RFC 2454, RFC 2465 et RFC 2466. Par contre, les MIBs unifiées ne sont pas encore prêtes.<br />
*6Wind a implémenté sur ses équipements les RFC 2465 et RFC 2466.<br />
<br />
Le tableau suivant récapitule les MIBs implémentés par les principaux constructeurs. <br />
<br />
{|<br />
! RFC/draft de référence || Nom de la MIB<br />
|-style="background:silver" <br />
|Cisco ||RFC 2466 <br> cisco-ietf-ip-mib (privé)<br />
|-<br />
|Juniper || RFC 2465 RFC 2466 <br>draft ietf-idr-bgp4-mibv2-0 <br>mib-jnx-ipv6.txt (privé) <br>mib-jnx-ipv6.txt (privé)<br> mib-jnx-bgpmib2.txt (privé)<br />
|-style="background:silver" <br />
|Hitachi || RFC 2452 RFC 2454 RFC 2465 RFC 2466 <br>MIBs standard implémentées<br />
|- <br />
|6wind ||RFC 2465 RFC 2466<br> MIBs standard implémentées <br />
|}<br />
<br />
===Le transport IPv6 du protocole SNMP===<br />
<br />
Afin que le transport de SNMP puisse se faire en IPv6, il est nécessaire que le serveur SNMP ainsi que les agents situés sur les équipements supportent la pile IPv6. En ce qui concerne les serveurs, il existe un nombre important d’application qui supporte déjà le transport IPv6. De même, chez un grand nombre de constructeurs, les agents SNMP sont capables de répondre à des requêtes IPv6.<br />
<br />
{|<br />
!Constructeur || Agent SNMP IPv6<br />
|-style="background:silver" <br />
|Cisco ||A partir de la version d’IOS 12.0 (27)S<br />
|-<br />
|Juniper ||Disponible<br />
|-style="background:silver" <br />
|Hitachi ||Disponible<br />
|-<br />
|6wind ||Disponible<br />
|}<br />
<br />
===L’export des flux IPv6===<br />
<br />
[[image:CS203.png|thumb|right|200px|Figure 16-3 ''Exportation des flux'']]<br />
<br />
Un autre élément très important de nos jours dans la supervision des réseaux est l’export des flux. En effet, les flux permettent de caractériser le trafic acheminé sur le réseau. Il est donc essentiel de disposer de cette fonctionnalité d’export pour les flux IPv6.<br />
<br />
Le groupe de travail IPFIX de l’IETF travaille pour définir un format standard pour l’export des flux. Cependant, aujourd’hui chaque constructeur a développé sa propre technologie. Voici un tableau indiquant les différentes technologies utilisées par chaque constructeur et si elles supportent l’export de flux IPv6. <br />
<br />
<br />
{|<br />
!Constructeur ||technologie pour l'export des flux ||Export des flux IPv6<br />
|-style="background:silver" <br />
|Cisco ||Netflow (version 9) ||A partir de la version d’IOS 12.3(7)T<br />
|-<br />
|Juniper ||Cflowd ||Non disponible<br />
|-style="background:silver" <br />
|Hitachi ||sflow ||Disponible<br />
|-<br />
|6wind ||Netflow ||Non disponible<br />
|}<br />
<br />
==<div id="plateformes">Les plates-formes.</div> ==<br />
<br />
Les plates-formes de supervision disponibles dans le marché visent à intégrer un ensemble d’outils permettant d’administrer de façon globale le réseau. Vu que tout les éléments de base ne sont pas disponibles, il est difficile de trouver aujourd’hui une plateforme qui permette de superviser un réseau IPv6 de la même façon qu’IPv4. Cependant, certaines versions de ces plateformes disposent de quelques fonctionnalités de supervision IPv6.<br />
Voici un tableau récapitulant un ensemble de fonctionnalités avec les différentes plateformes d’administration.<br />
<br />
{|<br />
!Plate-forme ||outil ||Fonctionnalités disponibles<br />
|-style="background:silver" <br />
|HP OpenView ||Network Node Manager (NMM 7.5)|| Implémentation de MIBs IPv6 standard <br>Découverte de réseau IPv6<br />
|-<br />
|CiscoWorks ||Campus manager 4.0 ||Transport IPv6 : trace d’équipements terminaux IPv6 En phase de test<br />
|-style="background:silver" <br />
| || Resource Manager Essentials (RME) || Inventaire et configuration d’équipements En phase de test<br />
|-<br />
| || Cisco View || En cours de développement<br />
|-style="background:silver" <br />
|Tivoli-Netview || || Pas de fonctionnalité IPv6 disponible<br />
|-<br />
|Infovista || || Pas de fonctionnalité IPv6 disponible et aucune prévision d’en intégrer.<br />
|}<br />
<br />
{{suivi |Supervision|Supervision|Les applications spécifiques |Les applications spécifiques}}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Mise_en_%C5%93uvre_par_les_constructeurs&diff=2969Mise en œuvre par les constructeurs2006-02-27T13:29:03Z<p>Bruno Deniaud: /* Les MIBs */</p>
<hr />
<div>{{suivi |Supervision|Supervision|Les applications spécifiques |Les applications spécifiques}}<br />
<br />
<br />
Dans cette partie, nous avons choisi un ensemble de constructeurs dont leurs équipements offrent des fonctionnalités pour la supervision des réseaux IPv6. A noter que cette liste n’est pas exhaustive.<br />
Dans un premier temps, certains constructeurs implémentant des MIBs IPv6 seront passés en revue, ensuite, dans un second temps ceux proposant l’utilisation de SNMP en IPv6 seront listé. Nous présenterons ceux qui offrent la possibilité d’exporter des flux IPv6 vers un collecteur.<br />
<br />
===Les MIBs===<br />
<br />
Nous avons vu précédemment que le modèle SNMP est très utilisé ; il est donc important que les constructeurs implémentent les MIBs définies par l’IETF :<br />
*Juniper a conçu une première réalisation en mettant en œuvre une MIB privée en se basant sur le RFC 2465. Cette MIB permet en autre de faire de la métrologie sur le nombre de paquets entrants et sortants. D’autre part, ce constructeur a implémenté une MIB privée basée sur le draft [[Bibliographie#JH-id]] qui permet de récupérer des informations sur le routage BGP4.<br />
*Cisco a mis en œuvre sur ses équipements une MIB privée (CISCO-IETF-IP-MIB) permettant de récupérer un certain nombre d’informations IPv6 de base (interfaces, messages ICMP). Par contre, il n’a pas encore développé une MIB permettant de différencier le trafic sur les interfaces transportant les deux versions IP le trafic IPv6.<br />
*Hitachi a développé sur ces routeurs (GR2000/GR4000) et sur les switchs (GS4000) les MIBs décrites dans les RFC 2452, RFC 2454, RFC 2465 et RFC 2466. Par contre, les MIBs unifiées ne sont pas encore prêtes.<br />
*6Wind a implémenté sur ses équipements les RFC 2465 et RFC 2466.<br />
<br />
Le tableau suivant récapitule les MIBs implémentés par les principaux constructeurs. <br />
<br />
{|<br />
! RFC/draft de référence || Nom de la MIB<br />
|-style="background:silver" <br />
|Cisco ||RFC 2466 <br> cisco-ietf-ip-mib (privé)<br />
|-<br />
|Juniper || RFC 2465 RFC 2466 <br>draft ietf-idr-bgp4-mibv2-0 <br>mib-jnx-ipv6.txt (privé) <br>mib-jnx-ipv6.txt (privé)<br> mib-jnx-bgpmib2.txt (privé)<br />
|-style="background:silver" <br />
|Hitachi || RFC 2452 RFC 2454 RFC 2465 RFC 2466 <br>MIBs standard implémentées<br />
|- <br />
|6wind ||RFC 2465 RFC 2466<br> MIBs standard implémentées <br />
|}<br />
<br />
===Le transport IPv6 du protocole SNMP===<br />
<br />
Afin que le transport de SNMP puisse se faire en IPv6, il est nécessaire que le serveur SNMP ainsi que les agents situés sur les équipements supportent la pile IPv6. En ce qui concerne les serveurs, il existe un nombre important d’application qui supporte déjà le transport IPv6. De même, chez un grand nombre de constructeurs, les agents SNMP sont capables de répondre à des requêtes IPv6.<br />
<br />
{|<br />
!Constructeur || Agent SNMP IPv6<br />
|-style="background:silver" <br />
|Cisco ||A partir de la version d’IOS 12.0 (27)S<br />
|-<br />
|Juniper ||Disponible<br />
|-style="background:silver" <br />
|Hitachi ||Disponible<br />
|-<br />
|6wind ||Disponible<br />
|}<br />
<br />
===L’export des flux IPv6===<br />
<br />
[[image:CS203.png|thumb|right|200px|Figure 16-3 ''Exportation des flux'']]<br />
<br />
Un autre élément très important de nos jours dans la supervision des réseaux est l’export des flux. En effet, les flux permettent de caractériser le trafic acheminé sur le réseau. Il est donc essentiel de disposer de cette fonctionnalité d’export pour les flux IPv6.<br />
<br />
Le groupe de travail IPFIX de l’IETF travaille pour définir un format standard pour l’export des flux. Cependant, aujourd’hui chaque constructeur a développé sa propre technologie. Voici un tableau indiquant les différentes technologies utilisées par chaque constructeur et si elles supportent l’export de flux IPv6. <br />
<br />
<br />
{|<br />
!Constructeur ||technologie pour l'export des flux ||Export des flux IPv6<br />
|-style="background:silver" <br />
|Cisco ||Netflow (version 9) ||A partir de la version d’IOS 12.3(7)T<br />
|-<br />
|Juniper ||Cflowd ||Non disponible<br />
|-style="background:silver" <br />
|Hitachi ||sflow ||Disponible<br />
|-<br />
|6wind ||Netflow ||Non disponible<br />
|}<br />
<br />
==<div id="plateformes">Les plates-formes.</div> ==<br />
<br />
Les plates-formes de supervision disponibles dans le marché visent à intégrer un ensemble d’outils permettant d’administrer de façon globale le réseau. Vu que tout les éléments de base ne sont pas disponibles, il est difficile de trouver aujourd’hui une plateforme qui permette de superviser un réseau IPv6 de la même façon qu’IPv4. Cependant, certaines versions de ces plateformes disposent de quelques fonctionnalités de supervision IPv6.<br />
Voici un tableau récapitulant un ensemble de fonctionnalités avec les différentes plateformes d’administration.<br />
<br />
{|<br />
!Plate-forme ||outil ||Fonctionnalités disponibles<br />
|-style="background:silver" <br />
|HP OpenView ||Network Node Manager (NMM 7.5)|| Implémentation de MIBs IPv6 standard <br>Découverte de réseau IPv6<br />
|-<br />
|CiscoWorks ||Campus manager 4.0 ||Transport IPv6 : trace d’équipements terminaux IPv6 En phase de test<br />
|-style="background:silver" <br />
| || Resource Manager Essentials (RME) || Inventaire et configuration d’équipements En phase de test<br />
|-<br />
| || Cisco View || En cours de développement<br />
|-style="background:silver" <br />
|Tivoli-Netview || || Pas de fonctionnalité IPv6 disponible<br />
|-<br />
|Infovista || || Pas de fonctionnalité IPv6 disponible et aucune prévision d’en intégrer.<br />
|}<br />
<br />
{{suivi |Supervision|Supervision|Les applications spécifiques |Les applications spécifiques}}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Supervision&diff=2968Supervision2006-02-27T13:28:06Z<p>Bruno Deniaud: /* Administration d’un réseau uniquement en IPv6 */</p>
<hr />
<div>{{suivi |L'exemple « mini-ping » revisité|L'exemple « mini-ping » revisité|Mise en œuvre par les constructeurs | Mise en œuvre par les constructeurs }}<br />
<br />
<br />
__TOC__<br />
<br />
L'administration des réseaux se décompose en un ensemble de tâches, chacune ayant une fonction bien particulière qui peuvent brièvement être décrite de la manière suivante :<br />
*Supervision (''Monitoring'') : La supervision est essentielle à la bonne administration d'un réseau. Elle consiste à vérifier qu'un ensemble d'équipements constituant un réseau (Routeurs, switchs, serveurs, PCs) fonctionne correctement. Elle permet de connaître à tout moment la disponibilité mais aussi les performances qu'offre le réseau.<br />
*Métrologie : Elle consiste à surveiller et analyser le trafic véhiculé par les équipements réseaux. Elle permet donc d'évaluer le type et la quantité de trafic dans le réseau. La métrologie a pris ainsi une place importante dans le monde de l'administration des réseaux. Parmi les utilisateurs de ce service se trouvent les opérateurs qui l'emploient entre autres pour suivre la consommation de leurs clients et vérifier qu'elle est conforme à leur contrat (''Accounting - Billing''). De même, ils vérifient que leurs liens physiques n'atteignent pas la capacité limite. Grâce aux fonctions de quelques outils, il est possible de faire du "reporting". Il est ainsi plus facile de prévoir le dimensionnement du réseau lors de migrations.<br />
*Sécurité: Il est indispensable d'avoir une politique de sécurité dans un réseau afin d'assurer principalement l'intégrité et la confidentialité des données. Pour cela, il faut mettre en place plusieurs niveaux de sécurité :<br />
**il est nécessaire de sécuriser l'accès physique aux équipements réseaux (routeurs, commutateurs) et aux serveurs (collecteurs, serveur d'authentification...).<br />
**pour restreindre l'accès aux utilisateurs non autorisés, des filtres sur les adresses IP et les ports (Access List, IPTables, ACL) ainsi que sur les services applicatifs (Certificats de sécurité, PKI) sont mis en place.<br />
**l'information transmise sur le réseau doit être chiffrée pour éviter que des informations confidentielles comme les mots de passe circulent en clair.<br />
La plus part des outils d'administration offrent ces fonctionnalités :<br />
*Découverte de la Topologie: La topologie permet de connaître à travers l'élaboration de schémas l'architecture du réseau. Il est donc très important de maintenir à jour ces schémas pour avoir une vision correcte du réseau.<br />
*Inventaire: L'inventaire permet de recenser l'ensemble des équipements qui constitue un réseau. Il a aussi pour but de tenir à jour la configuration de ces équipements. Si un inventaire n'est pas fait, il se peut, par exemple, que certains équipements du réseau ne soient pas supervisés. C'est pour cela qu'il est important de maintenir à jour l'inventaire, en même temps que le réseau évolue.<br />
<br />
==<div id="MIBIPv6">MIBs IPv6</div>==<br />
<br />
[[image:Sup3.png|thumb|right|200px|Figure 16-1 ''Architecture d'administration - Interrogation des MIB'']]<br />
<br />
La croissance rapide des réseaux et la diversité des systèmes pendant la dernière décennie a entraîné le besoin d'une gestion globale des infrastructures réseaux. SNMP (''Simple Network Management Protocol'') s'est avéré être une bonne solution proposée et standardisée par l'IETF. Ce protocole permet de collecter diverses informations stockées dans les équipements du réseau dans des bases de données appelées MIBs (''Management Information Base''). Les équipements sont aussi capables de faire remonter des alertes (''traps'') au collecteur SNMP via ce protocole (cf. figure Architecture d'administration - Interrogation des MIB.).<br />
<br />
<br />
Le protocole SNMP et les MIBs sont devenus les deux éléments principaux du modèle de supervision de réseaux.<br />
Le protocole SNMP étant indépendant de l'architecture du protocole IP, son évolution vers IPv6 n'a pas représenté un problème majeur. La première implémentation de SNMP pour le protocole IPv6 a été réalisée par l'équipe du Loria de l'université de Nancy (NET-SNMP OpenSource) et a été disponible dans la version 5.0.3 de net-snmp, en mai 2002. Avant cette première version, l'administration des réseaux IPv6 était possible du fait que les équipements avaient une double pile configurée IPv4 et IPv6. En effet, il n'était possible d'accéder en SNMP sur un équipement qu'en IPv4 et de récupérer des champs de la MIB concernant IPv6. Aujourd'hui, certains réseaux projets ne véhiculent que du trafic IPv6 d'où la nécessité de disposer d'une version IPv6 pour le transport du protocole SNMP.<br />
L'évolution des MIB est plus complexe. Depuis les spécifications initiales du protocole IPv6, en 1995, la définition de la MIB-2 pour l'administration des réseaux IPv6 a été modifiée à deux occasions en 1998 et en 2000 (cf. figure Evolution de la MIB.). Le problème principal était de définir le type du champ "IP ADDRESS". En 1996, une représentation initiale du champ <tt>IP ADDRESS</tt> est décrite dans le RFC 1902 où la longueur réservée pour ce champ est de 4 octets. Avec ce champ ne peuvent être représentées que les adresses IPv4 puisque les adresses IPv6 ayant une longueur de 128 bits. C'est pourquoi, en 1998, le RFC 2465 introduit la définition d'un champ "Ipv6Address" sur 16 octets.<br />
<br />
[[image:Sup4.png|thumb|none|500px|Figure 16-2 ''Evolution de la MIB'']]<br />
<br />
<br />
Ainsi de nombreuses RFCs ont été affectées par ces modifications. D'abord, avec la première approche de créer des MIBs IPv4 et IPv6 indépendantes, de nouveaux RFC ont vu le jour. Principalement, les RFCs décrivant les MIBs IPv6 sur transport TCP ou UDP (RFC 2452 et RFC 2454) ont été publiés en 1998. De même, une MIB concernant le protocole ICMPv6 a été décrite dans le RFC 2466.<br />
<br />
Cependant, cette approche implique une gestion indépendante des protocoles IPv4 et IPv6. Ainsi, l'IETF a décidé de définir une MIB-2 unifiée, permettant de superviser les réseaux IPv4 et IPv6 (RFC 2851 - Juin 2000). Ce RFC définit le champ <tt>IP ADDRESS</tt> comme une structure avec deux champs. Le premier champ permet de différencier le type d'adresses (IPv4 ou IPv6). Le deuxième champ est une chaîne de caractères de longueur variable qui peut contenir des valeurs de longueur égale à 4 ou 16 octets (IPv4 ou IPv6). Il devient possible de définir dans les MIBs des tables compatibles avec les deux versions d'IP.<br />
<br />
Afin d'améliorer la description de la MIB, en mai 2002, le RFC4001 obsolète les RFC 2851 et RFC 3291. Des informations supplémentaires y sont décrites comme le préfixe réseau, le numéro de port utilisé par la couche transport ou le numéro d'AS (''Automous System'') correspondant à l'adresse IPv4 ou IPv6.<br />
<br />
Cette volonté d'avoir une MIB unifiée entraîne aussi la mise à jour des MIB déjà existantes. Actuellement, l'IETF publie des drafts de mise à jour pour les RFC 2011, RFC 2012, RFC 2013 et RFC 2096. Les dernières propositions publiées sont :<br />
<br />
*draft-ietf-ipv6-rfc2011-update-10.txt (mai 2004) (RFC Editor Queue), <br />
*RFC 4022 (Mars 2005),<br />
*RFC 4113 (Juin 2005),<br />
*draft-ietf-ipv6-rfc2096-update-07.txt (février 2004) (RFC Editor Queue).<br />
<br />
Ces drafts concernent respectivement les MIBs IP, TCP, UDP et IP Forwarding table. Pour les MIBs concernant le routage BGP4+ et OSPFv3, les derniers drafts proposés sont <tt>draft-ietf-idr-bgp4-mibv2-05.txt</tt> (Juillet 2005) et <tt>draft-ietf-ospf-ospfv3-mib-10.txt</tt> (Décembre 2005) mais le premier de ces drafts a expiré en janvier 2006, ce qui laisse les MIBs concernant le routage externe IPv6 en suspens.<br />
En raison de toutes ces modifications, les MIBs ne sont pas entièrement disponibles aujourd'hui. En effet, uniquement quelques réalisations ont été effectuées par les constructeurs. Nous verrons par la suite les implémentations des différents constructeurs.<br />
<br />
==Administration des réseaux IPv6==<br />
<br />
===Administration d’un réseau Double Pile===<br />
<br />
Le fait d’administrer des réseaux IPv6 ne se traduit pas toujours par l’emploi d’outils qui transportent l’information en IPv6. En effet, la plupart des équipements sur le réseau étant en double pile (IPv4 – IPv6), l’accès peut se faire en IPv4 puis les informations concernant la supervision IPv6 sont récupérées. Cette solution est retenue très souvent car certaines applications ne supportent pas encore le transport en IPv6.<br />
<br />
Cela permet aussi aux NOC (''Network Operations Center'') n’ayant pas déployé encore un plan d’adressage IPv6 pour la supervision, d’administrer des réseaux aussi bien IPv4 qu’IPv6.<br />
<br />
===Administration d’un réseau uniquement en IPv6===<br />
<br />
L’administration d’un réseau uniquement en IPv6 est différente de l’administration d’un réseau ayant une double pile. En effet, du fait que les équipements ne sont accessibles qu’en IPv6, toute l’information de supervision doit être récupérée via le protocole IPv6. Il est donc indispensable dans ce cas là que toutes les applications utilisées pour l’administration du réseau supportent ce protocole.<br />
L’administration d’un réseau IPv6 est donc semblable à celle d’un réseau IPv4. Les informations récupérées sont souvent les mêmes dans les deux cas. Le point essentiel reste les constructeurs ainsi que les éditeurs de logiciels qui doivent rendre disponible les protocoles ainsi que les applications permettant l’administration d’un réseau IPv6.<br />
<br />
{{suivi |L'exemple « mini-ping » revisité|L'exemple « mini-ping » revisité|Mise en œuvre par les constructeurs | Mise en œuvre par les constructeurs }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Supervision&diff=2967Supervision2006-02-27T13:25:19Z<p>Bruno Deniaud: /* <div id="MIBIPv6">MIBs IPv6</div> */</p>
<hr />
<div>{{suivi |L'exemple « mini-ping » revisité|L'exemple « mini-ping » revisité|Mise en œuvre par les constructeurs | Mise en œuvre par les constructeurs }}<br />
<br />
<br />
__TOC__<br />
<br />
L'administration des réseaux se décompose en un ensemble de tâches, chacune ayant une fonction bien particulière qui peuvent brièvement être décrite de la manière suivante :<br />
*Supervision (''Monitoring'') : La supervision est essentielle à la bonne administration d'un réseau. Elle consiste à vérifier qu'un ensemble d'équipements constituant un réseau (Routeurs, switchs, serveurs, PCs) fonctionne correctement. Elle permet de connaître à tout moment la disponibilité mais aussi les performances qu'offre le réseau.<br />
*Métrologie : Elle consiste à surveiller et analyser le trafic véhiculé par les équipements réseaux. Elle permet donc d'évaluer le type et la quantité de trafic dans le réseau. La métrologie a pris ainsi une place importante dans le monde de l'administration des réseaux. Parmi les utilisateurs de ce service se trouvent les opérateurs qui l'emploient entre autres pour suivre la consommation de leurs clients et vérifier qu'elle est conforme à leur contrat (''Accounting - Billing''). De même, ils vérifient que leurs liens physiques n'atteignent pas la capacité limite. Grâce aux fonctions de quelques outils, il est possible de faire du "reporting". Il est ainsi plus facile de prévoir le dimensionnement du réseau lors de migrations.<br />
*Sécurité: Il est indispensable d'avoir une politique de sécurité dans un réseau afin d'assurer principalement l'intégrité et la confidentialité des données. Pour cela, il faut mettre en place plusieurs niveaux de sécurité :<br />
**il est nécessaire de sécuriser l'accès physique aux équipements réseaux (routeurs, commutateurs) et aux serveurs (collecteurs, serveur d'authentification...).<br />
**pour restreindre l'accès aux utilisateurs non autorisés, des filtres sur les adresses IP et les ports (Access List, IPTables, ACL) ainsi que sur les services applicatifs (Certificats de sécurité, PKI) sont mis en place.<br />
**l'information transmise sur le réseau doit être chiffrée pour éviter que des informations confidentielles comme les mots de passe circulent en clair.<br />
La plus part des outils d'administration offrent ces fonctionnalités :<br />
*Découverte de la Topologie: La topologie permet de connaître à travers l'élaboration de schémas l'architecture du réseau. Il est donc très important de maintenir à jour ces schémas pour avoir une vision correcte du réseau.<br />
*Inventaire: L'inventaire permet de recenser l'ensemble des équipements qui constitue un réseau. Il a aussi pour but de tenir à jour la configuration de ces équipements. Si un inventaire n'est pas fait, il se peut, par exemple, que certains équipements du réseau ne soient pas supervisés. C'est pour cela qu'il est important de maintenir à jour l'inventaire, en même temps que le réseau évolue.<br />
<br />
==<div id="MIBIPv6">MIBs IPv6</div>==<br />
<br />
[[image:Sup3.png|thumb|right|200px|Figure 16-1 ''Architecture d'administration - Interrogation des MIB'']]<br />
<br />
La croissance rapide des réseaux et la diversité des systèmes pendant la dernière décennie a entraîné le besoin d'une gestion globale des infrastructures réseaux. SNMP (''Simple Network Management Protocol'') s'est avéré être une bonne solution proposée et standardisée par l'IETF. Ce protocole permet de collecter diverses informations stockées dans les équipements du réseau dans des bases de données appelées MIBs (''Management Information Base''). Les équipements sont aussi capables de faire remonter des alertes (''traps'') au collecteur SNMP via ce protocole (cf. figure Architecture d'administration - Interrogation des MIB.).<br />
<br />
<br />
Le protocole SNMP et les MIBs sont devenus les deux éléments principaux du modèle de supervision de réseaux.<br />
Le protocole SNMP étant indépendant de l'architecture du protocole IP, son évolution vers IPv6 n'a pas représenté un problème majeur. La première implémentation de SNMP pour le protocole IPv6 a été réalisée par l'équipe du Loria de l'université de Nancy (NET-SNMP OpenSource) et a été disponible dans la version 5.0.3 de net-snmp, en mai 2002. Avant cette première version, l'administration des réseaux IPv6 était possible du fait que les équipements avaient une double pile configurée IPv4 et IPv6. En effet, il n'était possible d'accéder en SNMP sur un équipement qu'en IPv4 et de récupérer des champs de la MIB concernant IPv6. Aujourd'hui, certains réseaux projets ne véhiculent que du trafic IPv6 d'où la nécessité de disposer d'une version IPv6 pour le transport du protocole SNMP.<br />
L'évolution des MIB est plus complexe. Depuis les spécifications initiales du protocole IPv6, en 1995, la définition de la MIB-2 pour l'administration des réseaux IPv6 a été modifiée à deux occasions en 1998 et en 2000 (cf. figure Evolution de la MIB.). Le problème principal était de définir le type du champ "IP ADDRESS". En 1996, une représentation initiale du champ <tt>IP ADDRESS</tt> est décrite dans le RFC 1902 où la longueur réservée pour ce champ est de 4 octets. Avec ce champ ne peuvent être représentées que les adresses IPv4 puisque les adresses IPv6 ayant une longueur de 128 bits. C'est pourquoi, en 1998, le RFC 2465 introduit la définition d'un champ "Ipv6Address" sur 16 octets.<br />
<br />
[[image:Sup4.png|thumb|none|500px|Figure 16-2 ''Evolution de la MIB'']]<br />
<br />
<br />
Ainsi de nombreuses RFCs ont été affectées par ces modifications. D'abord, avec la première approche de créer des MIBs IPv4 et IPv6 indépendantes, de nouveaux RFC ont vu le jour. Principalement, les RFCs décrivant les MIBs IPv6 sur transport TCP ou UDP (RFC 2452 et RFC 2454) ont été publiés en 1998. De même, une MIB concernant le protocole ICMPv6 a été décrite dans le RFC 2466.<br />
<br />
Cependant, cette approche implique une gestion indépendante des protocoles IPv4 et IPv6. Ainsi, l'IETF a décidé de définir une MIB-2 unifiée, permettant de superviser les réseaux IPv4 et IPv6 (RFC 2851 - Juin 2000). Ce RFC définit le champ <tt>IP ADDRESS</tt> comme une structure avec deux champs. Le premier champ permet de différencier le type d'adresses (IPv4 ou IPv6). Le deuxième champ est une chaîne de caractères de longueur variable qui peut contenir des valeurs de longueur égale à 4 ou 16 octets (IPv4 ou IPv6). Il devient possible de définir dans les MIBs des tables compatibles avec les deux versions d'IP.<br />
<br />
Afin d'améliorer la description de la MIB, en mai 2002, le RFC4001 obsolète les RFC 2851 et RFC 3291. Des informations supplémentaires y sont décrites comme le préfixe réseau, le numéro de port utilisé par la couche transport ou le numéro d'AS (''Automous System'') correspondant à l'adresse IPv4 ou IPv6.<br />
<br />
Cette volonté d'avoir une MIB unifiée entraîne aussi la mise à jour des MIB déjà existantes. Actuellement, l'IETF publie des drafts de mise à jour pour les RFC 2011, RFC 2012, RFC 2013 et RFC 2096. Les dernières propositions publiées sont :<br />
<br />
*draft-ietf-ipv6-rfc2011-update-10.txt (mai 2004) (RFC Editor Queue), <br />
*RFC 4022 (Mars 2005),<br />
*RFC 4113 (Juin 2005),<br />
*draft-ietf-ipv6-rfc2096-update-07.txt (février 2004) (RFC Editor Queue).<br />
<br />
Ces drafts concernent respectivement les MIBs IP, TCP, UDP et IP Forwarding table. Pour les MIBs concernant le routage BGP4+ et OSPFv3, les derniers drafts proposés sont <tt>draft-ietf-idr-bgp4-mibv2-05.txt</tt> (Juillet 2005) et <tt>draft-ietf-ospf-ospfv3-mib-10.txt</tt> (Décembre 2005) mais le premier de ces drafts a expiré en janvier 2006, ce qui laisse les MIBs concernant le routage externe IPv6 en suspens.<br />
En raison de toutes ces modifications, les MIBs ne sont pas entièrement disponibles aujourd'hui. En effet, uniquement quelques réalisations ont été effectuées par les constructeurs. Nous verrons par la suite les implémentations des différents constructeurs.<br />
<br />
==Administration des réseaux IPv6==<br />
<br />
===Administration d’un réseau Double Pile===<br />
<br />
Le fait d’administrer des réseaux IPv6 ne se traduit pas toujours par l’emploi d’outils qui transportent l’information en IPv6. En effet, la plupart des équipements sur le réseau étant en double pile (IPv4 – IPv6), l’accès peut se faire en IPv4 puis les informations concernant la supervision IPv6 sont récupérées. Cette solution est retenue très souvent car certaines applications ne supportent pas encore le transport en IPv6.<br />
<br />
Cela permet aussi aux NOC (''Network Operations Center'') n’ayant pas déployé encore un plan d’adressage IPv6 pour la supervision, d’administrer des réseaux aussi bien IPv4 qu’IPv6.<br />
<br />
===Administration d’un réseau uniquement en IPv6===<br />
<br />
L’administration d’un réseau uniquement en IPv6 est différente de l’administration d’un réseau ayant une double pile. En effet, du fait que les équipements ne sont accessibles qu’en IPv6, toute l’information de supervision doit être récupérée via le protocole IPv6. Il est donc indispensable dans ce cas là que toutes les applications utilisées pour l’administration du réseau supporte ce protocole.<br />
L’administration d’un réseau IPv6 est donc semblable à celle d’un réseau IPv4. Les informations récupérées sont souvent les mêmes dans les deux cas. Le point essentiel reste les constructeurs ainsi que les éditeurs de logiciels qui doivent rendre disponible les protocoles ainsi que les applications permettant l’administration d’un réseau IPv6.<br />
<br />
{{suivi |L'exemple « mini-ping » revisité|L'exemple « mini-ping » revisité|Mise en œuvre par les constructeurs | Mise en œuvre par les constructeurs }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Supervision&diff=2966Supervision2006-02-27T13:22:22Z<p>Bruno Deniaud: /* <div id="MIBIPv6">MIBs IPv6</div> */</p>
<hr />
<div>{{suivi |L'exemple « mini-ping » revisité|L'exemple « mini-ping » revisité|Mise en œuvre par les constructeurs | Mise en œuvre par les constructeurs }}<br />
<br />
<br />
__TOC__<br />
<br />
L'administration des réseaux se décompose en un ensemble de tâches, chacune ayant une fonction bien particulière qui peuvent brièvement être décrite de la manière suivante :<br />
*Supervision (''Monitoring'') : La supervision est essentielle à la bonne administration d'un réseau. Elle consiste à vérifier qu'un ensemble d'équipements constituant un réseau (Routeurs, switchs, serveurs, PCs) fonctionne correctement. Elle permet de connaître à tout moment la disponibilité mais aussi les performances qu'offre le réseau.<br />
*Métrologie : Elle consiste à surveiller et analyser le trafic véhiculé par les équipements réseaux. Elle permet donc d'évaluer le type et la quantité de trafic dans le réseau. La métrologie a pris ainsi une place importante dans le monde de l'administration des réseaux. Parmi les utilisateurs de ce service se trouvent les opérateurs qui l'emploient entre autres pour suivre la consommation de leurs clients et vérifier qu'elle est conforme à leur contrat (''Accounting - Billing''). De même, ils vérifient que leurs liens physiques n'atteignent pas la capacité limite. Grâce aux fonctions de quelques outils, il est possible de faire du "reporting". Il est ainsi plus facile de prévoir le dimensionnement du réseau lors de migrations.<br />
*Sécurité: Il est indispensable d'avoir une politique de sécurité dans un réseau afin d'assurer principalement l'intégrité et la confidentialité des données. Pour cela, il faut mettre en place plusieurs niveaux de sécurité :<br />
**il est nécessaire de sécuriser l'accès physique aux équipements réseaux (routeurs, commutateurs) et aux serveurs (collecteurs, serveur d'authentification...).<br />
**pour restreindre l'accès aux utilisateurs non autorisés, des filtres sur les adresses IP et les ports (Access List, IPTables, ACL) ainsi que sur les services applicatifs (Certificats de sécurité, PKI) sont mis en place.<br />
**l'information transmise sur le réseau doit être chiffrée pour éviter que des informations confidentielles comme les mots de passe circulent en clair.<br />
La plus part des outils d'administration offrent ces fonctionnalités :<br />
*Découverte de la Topologie: La topologie permet de connaître à travers l'élaboration de schémas l'architecture du réseau. Il est donc très important de maintenir à jour ces schémas pour avoir une vision correcte du réseau.<br />
*Inventaire: L'inventaire permet de recenser l'ensemble des équipements qui constitue un réseau. Il a aussi pour but de tenir à jour la configuration de ces équipements. Si un inventaire n'est pas fait, il se peut, par exemple, que certains équipements du réseau ne soient pas supervisés. C'est pour cela qu'il est important de maintenir à jour l'inventaire, en même temps que le réseau évolue.<br />
<br />
==<div id="MIBIPv6">MIBs IPv6</div>==<br />
<br />
[[image:Sup3.png|thumb|right|200px|Figure 16-1 ''Architecture d'administration - Interrogation des MIB'']]<br />
<br />
La croissance rapide des réseaux et la diversité des systèmes pendant la dernière décennie a entraîné le besoin d'une gestion globale des infrastructures réseaux. SNMP (''Simple Network Management Protocol'') s'est avéré être une bonne solution proposée et standardisée par l'IETF. Ce protocole permet de collecter diverses informations stockées dans les équipements du réseau dans des bases de données appelées MIBs (''Management Information Base''). Les équipements sont aussi capables de faire remonter des alertes (''traps'') au collecteur SNMP via ce protocole (cf. figure Architecture d'administration - Interrogation des MIB.).<br />
<br />
<br />
Le protocole SNMP et les MIBs sont devenus les deux éléments principaux du modèle de supervision de réseaux.<br />
Le protocole SNMP étant indépendant de l'architecture du protocole IP, son évolution vers IPv6 n'a pas représenté un problème majeur. La première implémentation de SNMP pour le protocole IPv6 a été réalisée par l'équipe du Loria de l'université de Nancy (NET-SNMP OpenSource) et a été disponible dans la version 5.0.3 de net-snmp, en mai 2002. Avant cette première version, l'administration des réseaux IPv6 était possible du fait que les équipements avaient une double pile configurée IPv4 et IPv6. En effet, il n'était possible d'accéder en SNMP sur un équipement qu'en IPv4 et de récupérer des champs de la MIB concernant IPv6. Aujourd'hui, certains réseaux projets ne véhiculent que du trafic IPv6 d'où la nécessité de disposer d'une version IPv6 pour le transport du protocole SNMP.<br />
L'évolution des MIB est plus complexe. Depuis les spécifications initiales du protocole IPv6, en 1995, la définition de la MIB-2 pour l'administration des réseaux IPv6 a été modifiée à deux occasions en 1998 et en 2000 (cf. figure Evolution de la MIB.). Le problème principal était de définir le type du champ "IP ADDRESS". En 1996, une représentation initiale du champ <tt>IP ADDRESS</tt> est décrite dans le RFC 1902 où la longueur réservée pour ce champ est de 4 octets. Avec ce champ ne peuvent être représentées que les adresses IPv4 puisque les adresses IPv6 ayant une longueur de 128 bits. C'est pourquoi, en 1998, le RFC 2465 introduit la définition d'un champ "Ipv6Address" sur 16 octets.<br />
<br />
[[image:Sup4.png|thumb|none|500px|Figure 16-2 ''Evolution de la MIB'']]<br />
<br />
<br />
Ainsi de nombreuses RFCs ont été affectées par ces modifications. D'abord, avec la première approche de créer des MIBs IPv4 et IPv6 indépendantes, de nouveaux RFC ont vu le jour. Principalement, les RFCs décrivant les MIBs IPv6 sur transport TCP ou UDP (RFC 2452 et RFC 2454) ont été publiés en 1998. De même, une MIB concernant le protocole ICMPv6 a été décrite dans le RFC 2466.<br />
<br />
Cependant, cette approche implique une gestion indépendante des protocoles IPv4 et IPv6. Ainsi, l'IETF a décidé de définir une MIB-2 unifiée, permettant de superviser les réseaux IPv4 et IPv6 (RFC 2851 - Juin 2000). Ce RFC définit le champ <tt>IP ADDRESS</tt> comme une structure avec deux champs. Le premier champ permet de différencier le type d'adresses (IPv4 ou IPv6). Le deuxième champ est une chaîne de caractères de longueur variable qui peut contenir des valeurs de longueur égale à 4 ou 16 octets (IPv4 ou IPv6). Il devient possible de définir dans les MIBs des tables compatibles avec les deux versions d'IP.<br />
<br />
Afin d'améliorer la description de la MIB, en mai 2002, le RFC4001 obsolète les RFC 2851 et RFC 3291. Des informations supplémentaires y sont décrites comme le préfixe réseau, le numéro de port utilisé par la couche transport ou le numéro d'AS (''Automous System'') correspondant à l'adresse IPv4 ou IPv6.<br />
<br />
Cette volonté d'avoir une MIB unifiée entraîne aussi la mise à jour des MIB déjà existantes. Actuellement, l'IETF publie des drafts de mise à jour pour les RFC 2011, RFC 2012, RFC 2013 et RFC 2096. Les dernières propositions publiées sont :<br />
<br />
*draft-ietf-ipv6-rfc2011-update-10.txt (mai 2004), RFC 4022 (Mars 2005),<br />
*draft-ietf-ipv6-rfc2013-update-04.txt (octobre 2004),<br />
*draft-ietf-ipv6-rfc2096-update-07.txt (février 2004).<br />
<br />
Ces drafts concernent respectivement les MIBs IP, TCP, UDP et IP Forwarding table. Pour les MIBs concernant le routage BGP4+ et OSPFv3, les derniers drafts proposés sont <tt>draft-ietf-idr-bgp4-mibv2-05.txt</tt> (Juillet 2005) et <tt>draft-ietf-ospf-ospfv3-mib-10.txt</tt> (Décembre 2005) mais le premier de ces drafts a expiré en janvier 2006, ce qui laisse les MIBs concernant le routage externe IPv6 en suspens.<br />
En raison de toutes ces modifications, les MIBs ne sont pas entièrement disponibles aujourd'hui. En effet, uniquement quelques réalisations ont été effectuées par les constructeurs. Nous verrons par la suite les implémentations des différents constructeurs.<br />
<br />
==Administration des réseaux IPv6==<br />
<br />
===Administration d’un réseau Double Pile===<br />
<br />
Le fait d’administrer des réseaux IPv6 ne se traduit pas toujours par l’emploi d’outils qui transportent l’information en IPv6. En effet, la plupart des équipements sur le réseau étant en double pile (IPv4 – IPv6), l’accès peut se faire en IPv4 puis les informations concernant la supervision IPv6 sont récupérées. Cette solution est retenue très souvent car certaines applications ne supportent pas encore le transport en IPv6.<br />
<br />
Cela permet aussi aux NOC (''Network Operations Center'') n’ayant pas déployé encore un plan d’adressage IPv6 pour la supervision, d’administrer des réseaux aussi bien IPv4 qu’IPv6.<br />
<br />
===Administration d’un réseau uniquement en IPv6===<br />
<br />
L’administration d’un réseau uniquement en IPv6 est différente de l’administration d’un réseau ayant une double pile. En effet, du fait que les équipements ne sont accessibles qu’en IPv6, toute l’information de supervision doit être récupérée via le protocole IPv6. Il est donc indispensable dans ce cas là que toutes les applications utilisées pour l’administration du réseau supporte ce protocole.<br />
L’administration d’un réseau IPv6 est donc semblable à celle d’un réseau IPv4. Les informations récupérées sont souvent les mêmes dans les deux cas. Le point essentiel reste les constructeurs ainsi que les éditeurs de logiciels qui doivent rendre disponible les protocoles ainsi que les applications permettant l’administration d’un réseau IPv6.<br />
<br />
{{suivi |L'exemple « mini-ping » revisité|L'exemple « mini-ping » revisité|Mise en œuvre par les constructeurs | Mise en œuvre par les constructeurs }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Supervision&diff=2965Supervision2006-02-27T13:19:52Z<p>Bruno Deniaud: /* <div id="MIBIPv6">MIBs IPv6</div> */</p>
<hr />
<div>{{suivi |L'exemple « mini-ping » revisité|L'exemple « mini-ping » revisité|Mise en œuvre par les constructeurs | Mise en œuvre par les constructeurs }}<br />
<br />
<br />
__TOC__<br />
<br />
L'administration des réseaux se décompose en un ensemble de tâches, chacune ayant une fonction bien particulière qui peuvent brièvement être décrite de la manière suivante :<br />
*Supervision (''Monitoring'') : La supervision est essentielle à la bonne administration d'un réseau. Elle consiste à vérifier qu'un ensemble d'équipements constituant un réseau (Routeurs, switchs, serveurs, PCs) fonctionne correctement. Elle permet de connaître à tout moment la disponibilité mais aussi les performances qu'offre le réseau.<br />
*Métrologie : Elle consiste à surveiller et analyser le trafic véhiculé par les équipements réseaux. Elle permet donc d'évaluer le type et la quantité de trafic dans le réseau. La métrologie a pris ainsi une place importante dans le monde de l'administration des réseaux. Parmi les utilisateurs de ce service se trouvent les opérateurs qui l'emploient entre autres pour suivre la consommation de leurs clients et vérifier qu'elle est conforme à leur contrat (''Accounting - Billing''). De même, ils vérifient que leurs liens physiques n'atteignent pas la capacité limite. Grâce aux fonctions de quelques outils, il est possible de faire du "reporting". Il est ainsi plus facile de prévoir le dimensionnement du réseau lors de migrations.<br />
*Sécurité: Il est indispensable d'avoir une politique de sécurité dans un réseau afin d'assurer principalement l'intégrité et la confidentialité des données. Pour cela, il faut mettre en place plusieurs niveaux de sécurité :<br />
**il est nécessaire de sécuriser l'accès physique aux équipements réseaux (routeurs, commutateurs) et aux serveurs (collecteurs, serveur d'authentification...).<br />
**pour restreindre l'accès aux utilisateurs non autorisés, des filtres sur les adresses IP et les ports (Access List, IPTables, ACL) ainsi que sur les services applicatifs (Certificats de sécurité, PKI) sont mis en place.<br />
**l'information transmise sur le réseau doit être chiffrée pour éviter que des informations confidentielles comme les mots de passe circulent en clair.<br />
La plus part des outils d'administration offrent ces fonctionnalités :<br />
*Découverte de la Topologie: La topologie permet de connaître à travers l'élaboration de schémas l'architecture du réseau. Il est donc très important de maintenir à jour ces schémas pour avoir une vision correcte du réseau.<br />
*Inventaire: L'inventaire permet de recenser l'ensemble des équipements qui constitue un réseau. Il a aussi pour but de tenir à jour la configuration de ces équipements. Si un inventaire n'est pas fait, il se peut, par exemple, que certains équipements du réseau ne soient pas supervisés. C'est pour cela qu'il est important de maintenir à jour l'inventaire, en même temps que le réseau évolue.<br />
<br />
==<div id="MIBIPv6">MIBs IPv6</div>==<br />
<br />
[[image:Sup3.png|thumb|right|200px|Figure 16-1 ''Architecture d'administration - Interrogation des MIB'']]<br />
<br />
La croissance rapide des réseaux et la diversité des systèmes pendant la dernière décennie a entraîné le besoin d'une gestion globale des infrastructures réseaux. SNMP (''Simple Network Management Protocol'') s'est avéré être une bonne solution proposée et standardisée par l'IETF. Ce protocole permet de collecter diverses informations stockées dans les équipements du réseau dans des bases de données appelées MIBs (''Management Information Base''). Les équipements sont aussi capables de faire remonter des alertes (''traps'') au collecteur SNMP via ce protocole (cf. figure Architecture d'administration - Interrogation des MIB.).<br />
<br />
<br />
Le protocole SNMP et les MIBs sont devenus les deux éléments principaux du modèle de supervision de réseaux.<br />
Le protocole SNMP étant indépendant de l'architecture du protocole IP, son évolution vers IPv6 n'a pas représenté un problème majeur. La première implémentation de SNMP pour le protocole IPv6 a été réalisée par l'équipe du Loria de l'université de Nancy (NET-SNMP OpenSource) et a été disponible dans la version 5.0.3 de net-snmp, en mai 2002. Avant cette première version, l'administration des réseaux IPv6 était possible du fait que les équipements avaient une double pile configurée IPv4 et IPv6. En effet, il n'était possible d'accéder en SNMP sur un équipement qu'en IPv4 et de récupérer des champs de la MIB concernant IPv6. Aujourd'hui, certains réseaux projets ne véhiculent que du trafic IPv6 d'où la nécessité de disposer d'une version IPv6 pour le transport du protocole SNMP.<br />
L'évolution des MIB est plus complexe. Depuis les spécifications initiales du protocole IPv6, en 1995, la définition de la MIB-2 pour l'administration des réseaux IPv6 a été modifiée à deux occasions en 1998 et en 2000 (cf. figure Evolution de la MIB.). Le problème principal était de définir le type du champ "IP ADDRESS". En 1996, une représentation initiale du champ <tt>IP ADDRESS</tt> est décrite dans le RFC 1902 où la longueur réservée pour ce champ est de 4 octets. Avec ce champ ne peuvent être représentées que les adresses IPv4 puisque les adresses IPv6 ayant une longueur de 128 bits. C'est pourquoi, en 1998, le RFC 2465 introduit la définition d'un champ "Ipv6Address" sur 16 octets.<br />
<br />
[[image:Sup4.png|thumb|none|500px|Figure 16-2 ''Evolution de la MIB'']]<br />
<br />
<br />
Ainsi de nombreuses RFCs ont été affectées par ces modifications. D'abord, avec la première approche de créer des MIBs IPv4 et IPv6 indépendantes, de nouveaux RFC ont vu le jour. Principalement, les RFCs décrivant les MIBs IPv6 sur transport TCP ou UDP (RFC 2452 et RFC 2454) ont été publiés en 1998. De même, une MIB concernant le protocole ICMPv6 a été décrite dans le RFC 2466.<br />
<br />
Cependant, cette approche implique une gestion indépendante des protocoles IPv4 et IPv6. Ainsi, l'IETF a décidé de définir une MIB-2 unifiée, permettant de superviser les réseaux IPv4 et IPv6 (RFC 2851 - Juin 2000). Ce RFC définit le champ <tt>IP ADDRESS</tt> comme une structure avec deux champs. Le premier champ permet de différencier le type d'adresses (IPv4 ou IPv6). Le deuxième champ est une chaîne de caractères de longueur variable qui peut contenir des valeurs de longueur égale à 4 ou 16 octets (IPv4 ou IPv6). Il devient possible de définir dans les MIBs des tables compatibles avec les deux versions d'IP.<br />
<br />
Afin d'améliorer la description de la MIB, en mai 2002, le RFC4001 obsolète les RFC 2851 et RFC 3291. Des informations supplémentaires y sont décrites comme le préfixe réseau, le numéro de port utilisé par la couche transport ou le numéro d'AS (''Automous System'') correspondant à l'adresse IPv4 ou IPv6.<br />
<br />
Cette volonté d'avoir une MIB unifiée entraîne aussi la mise à jour des MIB déjà existantes. Actuellement, l'IETF publie des drafts de mise à jour pour les RFC 2011, RFC 2012, RFC 2013 et RFC 2096. Les dernières propositions publiées sont :<br />
<br />
*draft-ietf-ipv6-rfc2011-update-10.txt (mai 2004), RFC 4022 (Mars 2005),<br />
*draft-ietf-ipv6-rfc2013-update-04.txt (octobre 2004),<br />
*draft-ietf-ipv6-rfc2096-update-07.txt (février 2004).<br />
<br />
Ces drafts concernent respectivement les MIBs IP, TCP, UDP et IP Forwarding table. Pour les MIBs concernant le routage BGP4+ et OSPFv3, les derniers drafts proposés sont <tt>draft-ietf-idr-bgp4-mibv2-05.txt</tt> (Août 2004) et <tt>draft-ietf-ospf-ospfv3-mib-09.txt</tt> (avril 2004) mais le premier de ces drafts a expiré en juin 2004, ce qui laisse les MIBs concernant le routage externe IPv6 en suspens.<br />
En raison de toutes ces modifications, les MIBs ne sont pas entièrement disponibles aujourd'hui. En effet, uniquement quelques réalisations ont été effectuées par les constructeurs. Nous verrons par la suite les implémentations des différents constructeurs.<br />
<br />
==Administration des réseaux IPv6==<br />
<br />
===Administration d’un réseau Double Pile===<br />
<br />
Le fait d’administrer des réseaux IPv6 ne se traduit pas toujours par l’emploi d’outils qui transportent l’information en IPv6. En effet, la plupart des équipements sur le réseau étant en double pile (IPv4 – IPv6), l’accès peut se faire en IPv4 puis les informations concernant la supervision IPv6 sont récupérées. Cette solution est retenue très souvent car certaines applications ne supportent pas encore le transport en IPv6.<br />
<br />
Cela permet aussi aux NOC (''Network Operations Center'') n’ayant pas déployé encore un plan d’adressage IPv6 pour la supervision, d’administrer des réseaux aussi bien IPv4 qu’IPv6.<br />
<br />
===Administration d’un réseau uniquement en IPv6===<br />
<br />
L’administration d’un réseau uniquement en IPv6 est différente de l’administration d’un réseau ayant une double pile. En effet, du fait que les équipements ne sont accessibles qu’en IPv6, toute l’information de supervision doit être récupérée via le protocole IPv6. Il est donc indispensable dans ce cas là que toutes les applications utilisées pour l’administration du réseau supporte ce protocole.<br />
L’administration d’un réseau IPv6 est donc semblable à celle d’un réseau IPv4. Les informations récupérées sont souvent les mêmes dans les deux cas. Le point essentiel reste les constructeurs ainsi que les éditeurs de logiciels qui doivent rendre disponible les protocoles ainsi que les applications permettant l’administration d’un réseau IPv6.<br />
<br />
{{suivi |L'exemple « mini-ping » revisité|L'exemple « mini-ping » revisité|Mise en œuvre par les constructeurs | Mise en œuvre par les constructeurs }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Supervision&diff=2964Supervision2006-02-27T13:14:41Z<p>Bruno Deniaud: /* <div id="MIBIPv6">MIBs IPv6</div> */</p>
<hr />
<div>{{suivi |L'exemple « mini-ping » revisité|L'exemple « mini-ping » revisité|Mise en œuvre par les constructeurs | Mise en œuvre par les constructeurs }}<br />
<br />
<br />
__TOC__<br />
<br />
L'administration des réseaux se décompose en un ensemble de tâches, chacune ayant une fonction bien particulière qui peuvent brièvement être décrite de la manière suivante :<br />
*Supervision (''Monitoring'') : La supervision est essentielle à la bonne administration d'un réseau. Elle consiste à vérifier qu'un ensemble d'équipements constituant un réseau (Routeurs, switchs, serveurs, PCs) fonctionne correctement. Elle permet de connaître à tout moment la disponibilité mais aussi les performances qu'offre le réseau.<br />
*Métrologie : Elle consiste à surveiller et analyser le trafic véhiculé par les équipements réseaux. Elle permet donc d'évaluer le type et la quantité de trafic dans le réseau. La métrologie a pris ainsi une place importante dans le monde de l'administration des réseaux. Parmi les utilisateurs de ce service se trouvent les opérateurs qui l'emploient entre autres pour suivre la consommation de leurs clients et vérifier qu'elle est conforme à leur contrat (''Accounting - Billing''). De même, ils vérifient que leurs liens physiques n'atteignent pas la capacité limite. Grâce aux fonctions de quelques outils, il est possible de faire du "reporting". Il est ainsi plus facile de prévoir le dimensionnement du réseau lors de migrations.<br />
*Sécurité: Il est indispensable d'avoir une politique de sécurité dans un réseau afin d'assurer principalement l'intégrité et la confidentialité des données. Pour cela, il faut mettre en place plusieurs niveaux de sécurité :<br />
**il est nécessaire de sécuriser l'accès physique aux équipements réseaux (routeurs, commutateurs) et aux serveurs (collecteurs, serveur d'authentification...).<br />
**pour restreindre l'accès aux utilisateurs non autorisés, des filtres sur les adresses IP et les ports (Access List, IPTables, ACL) ainsi que sur les services applicatifs (Certificats de sécurité, PKI) sont mis en place.<br />
**l'information transmise sur le réseau doit être chiffrée pour éviter que des informations confidentielles comme les mots de passe circulent en clair.<br />
La plus part des outils d'administration offrent ces fonctionnalités :<br />
*Découverte de la Topologie: La topologie permet de connaître à travers l'élaboration de schémas l'architecture du réseau. Il est donc très important de maintenir à jour ces schémas pour avoir une vision correcte du réseau.<br />
*Inventaire: L'inventaire permet de recenser l'ensemble des équipements qui constitue un réseau. Il a aussi pour but de tenir à jour la configuration de ces équipements. Si un inventaire n'est pas fait, il se peut, par exemple, que certains équipements du réseau ne soient pas supervisés. C'est pour cela qu'il est important de maintenir à jour l'inventaire, en même temps que le réseau évolue.<br />
<br />
==<div id="MIBIPv6">MIBs IPv6</div>==<br />
<br />
[[image:Sup3.png|thumb|right|200px|Figure 16-1 ''Architecture d'administration - Interrogation des MIB'']]<br />
<br />
La croissance rapide des réseaux et la diversité des systèmes pendant la dernière décennie a entraîné le besoin d'une gestion globale des infrastructures réseaux. SNMP (''Simple Network Management Protocol'') s'est avéré être une bonne solution proposée et standardisée par l'IETF. Ce protocole permet de collecter diverses informations stockées dans les équipements du réseau dans des bases de données appelées MIBs (''Management Information Base''). Les équipements sont aussi capables de faire remonter des alertes (''traps'') au collecteur SNMP via ce protocole (cf. figure Architecture d'administration - Interrogation des MIB.).<br />
<br />
<br />
Le protocole SNMP et les MIBs sont devenus les deux éléments principaux du modèle de supervision de réseaux.<br />
Le protocole SNMP étant indépendant de l'architecture du protocole IP, son évolution vers IPv6 n'a pas représenté un problème majeur. La première implémentation de SNMP pour le protocole IPv6 a été réalisée par l'équipe du Loria de l'université de Nancy (NET-SNMP OpenSource) et a été disponible dans la version 5.0.3 de net-snmp, en mai 2002. Avant cette première version, l'administration des réseaux IPv6 était possible du fait que les équipements avaient une double pile configurée IPv4 et IPv6. En effet, il n'était possible d'accéder en SNMP sur un équipement qu'en IPv4 et de récupérer des champs de la MIB concernant IPv6. Aujourd'hui, certains réseaux projets ne véhiculent que du trafic IPv6 d'où la nécessité de disposer d'une version IPv6 pour le transport du protocole SNMP.<br />
L'évolution des MIB est plus complexe. Depuis les spécifications initiales du protocole IPv6, en 1995, la définition de la MIB-2 pour l'administration des réseaux IPv6 a été modifiée à deux occasions en 1998 et en 2000 (cf. figure Evolution de la MIB.). Le problème principal était de définir le type du champ "IP ADDRESS". En 1996, une représentation initiale du champ <tt>IP ADDRESS</tt> est décrite dans le RFC 1902 où la longueur réservée pour ce champ est de 4 octets. Avec ce champ ne peuvent être représentées que les adresses IPv4 puisque les adresses IPv6 ayant une longueur de 128 bits. C'est pourquoi, en 1998, le RFC 2465 introduit la définition d'un champ "Ipv6Address" sur 16 octets.<br />
<br />
[[image:Sup4.png|thumb|none|500px|Figure 16-2 ''Evolution de la MIB'']]<br />
<br />
<br />
Ainsi de nombreuses RFCs ont été affectées par ces modifications. D'abord, avec la première approche de créer des MIBs IPv4 et IPv6 indépendantes, de nouveaux RFC ont vu le jour. Principalement, les RFCs décrivant les MIBs IPv6 sur transport TCP ou UDP (RFC 2452 et RFC 2454) ont été publiés en 1998. De même, une MIB concernant le protocole ICMPv6 a été décrite dans le RFC 2466.<br />
<br />
Cependant, cette approche implique une gestion indépendante des protocoles IPv4 et IPv6. Ainsi, l'IETF a décidé de définir une MIB-2 unifiée, permettant de superviser les réseaux IPv4 et IPv6 (RFC 2851 - Juin 2000). Ce RFC définit le champ <tt>IP ADDRESS</tt> comme une structure avec deux champs. Le premier champ permet de différencier le type d'adresses (IPv4 ou IPv6). Le deuxième champ est une chaîne de caractères de longueur variable qui peut contenir des valeurs de longueur égale à 4 ou 16 octets (IPv4 ou IPv6). Il devient possible de définir dans les MIBs des tables compatibles avec les deux versions d'IP.<br />
<br />
Afin d'améliorer la description de la MIB, en mai 2002, le RFC4001 obsolète les RFC 2851 et RFC 3291. Des informations supplémentaires y sont décrites comme le préfixe réseau, le numéro de port utilisé par la couche transport ou le numéro d'AS (''Automous System'') correspondant à l'adresse IPv4 ou IPv6.<br />
<br />
Cette volonté d'avoir une MIB unifiée entraîne aussi la mise à jour des MIB déjà existantes. Actuellement, l'IETF publie des drafts de mise à jour pour les RFC 2011, RFC 2012, RFC 2013 et RFC 2096. Les dernières propositions publiées sont :<br />
<br />
*draft-ietf-ipv6-rfc2011-update-10.txt (mai 2004), RFC 4022 (Mars 2005),<br />
*draft-ietf-ipv6-rfc2013-update-04.txt (octobre 2004),<br />
*draft-ietf-ipv6-rfc2096-update-07.txt (février 2004).<br />
<br />
Ces drafts concernent respectivement les MIBs IP, TCP, UDP et IP Forwarding table. Pour les MIBs concernant le routage BGP4+ et OSPFv3, les derniers drafts proposés sont <tt>draft-ietf-idr-bgp4-mibv2-15.txt</tt> (Août 2004) et <tt>draft-ietf-ospf-ospfv3-mib-09.txt</tt> (avril 2004) mais le premier de ces drafts a expiré en juin 2004, ce qui laisse les MIBs concernant le routage externe IPv6 en suspens.<br />
En raison de toutes ces modifications, les MIBs ne sont pas entièrement disponibles aujourd'hui. En effet, uniquement quelques réalisations ont été effectuées par les constructeurs. Nous verrons par la suite les implémentations des différents constructeurs.<br />
<br />
==Administration des réseaux IPv6==<br />
<br />
===Administration d’un réseau Double Pile===<br />
<br />
Le fait d’administrer des réseaux IPv6 ne se traduit pas toujours par l’emploi d’outils qui transportent l’information en IPv6. En effet, la plupart des équipements sur le réseau étant en double pile (IPv4 – IPv6), l’accès peut se faire en IPv4 puis les informations concernant la supervision IPv6 sont récupérées. Cette solution est retenue très souvent car certaines applications ne supportent pas encore le transport en IPv6.<br />
<br />
Cela permet aussi aux NOC (''Network Operations Center'') n’ayant pas déployé encore un plan d’adressage IPv6 pour la supervision, d’administrer des réseaux aussi bien IPv4 qu’IPv6.<br />
<br />
===Administration d’un réseau uniquement en IPv6===<br />
<br />
L’administration d’un réseau uniquement en IPv6 est différente de l’administration d’un réseau ayant une double pile. En effet, du fait que les équipements ne sont accessibles qu’en IPv6, toute l’information de supervision doit être récupérée via le protocole IPv6. Il est donc indispensable dans ce cas là que toutes les applications utilisées pour l’administration du réseau supporte ce protocole.<br />
L’administration d’un réseau IPv6 est donc semblable à celle d’un réseau IPv4. Les informations récupérées sont souvent les mêmes dans les deux cas. Le point essentiel reste les constructeurs ainsi que les éditeurs de logiciels qui doivent rendre disponible les protocoles ainsi que les applications permettant l’administration d’un réseau IPv6.<br />
<br />
{{suivi |L'exemple « mini-ping » revisité|L'exemple « mini-ping » revisité|Mise en œuvre par les constructeurs | Mise en œuvre par les constructeurs }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=L%27exemple_%C2%AB_mini-ping_%C2%BB_revisit%C3%A9&diff=2963L'exemple « mini-ping » revisité2006-02-27T12:52:49Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| L'implémentation | L'implémentation | Supervision | Supervision }}<br />
Le programme <tt>one_ping6.c</tt> va être repris afin de lui ajouter deux fonctionnalités dont l'implémentation s'appuiera sur l'usage de données auxiliaires. On souhaite d'une part afficher le nombre de sauts (''hop limit'') du paquet ECHO_REPLY (éventuellement) reçu et d'autre part de permettre, à l'instar de la commande <tt>ping6</tt>, de passer une liste de relais par lesquels le paquet ECHO_REQUEST devra transiter avant d'être envoyé à l'hôte destinataire (routage par la source).<br />
<br />
Par exemple, pour envoyer un paquet ECHO_REQUEST à la machine <tt>ipv6.imag.fr</tt> tout en transitant tout d'abord par les machines <tt>www.kame.net</tt> et <tt>relai.imag.fr</tt>, la commande <tt>xapi_ping6</tt> sera :<br />
<br />
$ '''xapi_ping6 www.kame.net relais.imag.fr ipv6.imag.fr'''<br />
Sending ECHO REQUEST to: ipv6.imag.fr via:<br />
www.kame.net<br />
relais.imag.fr<br />
Waiting for answer (timeout = 5s)...<br />
Got answer from 2001:660:9510:25::632 (seq = 0, hoplimit = 241)<br />
<br />
L'affichage du nombre de sauts a déjà été en grande partie traité dans l'exemple du paragraphe consacré à l'implémentation de l'API avancée. Nous indiquerons donc seulement les changements significatifs par rapport à la version originale. Ces changements concernent essentiellement la routine <tt>wait_for_echo_reply6</tt>. La première tâche à effectuer est, comme dans l'exemple précédent, de positionner l'option <tt>IPV6_RECVHOPLIMIT</tt>, juste après avoir mis en place le filtrage ICMPv6. L'instruction :<br />
<br />
noc = recvfrom(sock, buf, sizeof(buf), 0, (struct sockaddr *) from, &from_len);<br />
<br />
est remplacée par la nouvelle instruction :<br />
<br />
noc = recv_data(sock, buf, sizeof(buf), 0, (struct sockaddr *) from, &from_len, &hoplimit);<br />
<br />
où <tt>hoplimit</tt> est un entier qui a été précédemment déclaré dans le corps de la fonction <tt>wait_for_echo_reply6</tt> et <tt>recv_data</tt> a pour texte :<br />
<br />
<br />
1| #ifdef sun /* For Solaris */<br />
2| #define _XOPEN_SOURCE 500 /* correct recvmsg/sendmsg/msg/CMSG_xx syntax */<br />
3| #define __EXTENSIONS__<br />
4| #endif<br />
5| #include <stdio.h><br />
6| #include <stdlib.h><br />
7| #include <unistd.h><br />
8| #include <sys/uio.h><br />
9| #include <sys/types.h><br />
10| #include <sys/socket.h><br />
11| #include <netinet/in.h><br />
12| #include <netinet/ip6.h><br />
13| #ifndef CMSG_SPACE /* Solaris <= 9 */<br />
14| #define CMSG_SPACE(l) ((size_t)_CMSG_HDR_ALIGN(sizeof (struct cmsghdr) + (l)))<br />
15| #define CMSG_LEN(l) ((size_t)_CMSG_DATA_ALIGN(sizeof (struct cmsghdr)) + (l))<br />
16| #endif<br />
17| <br />
18| int recv_data(int sock, void *buf, int len, unsigned int flags,<br />
19| struct sockaddr *from, socklen_t *fromlen, int *hoplimit)<br />
20| {<br />
21| int ret, found = 0, cmsgspace = CMSG_SPACE(sizeof(int));<br />
22| struct iovec iov = {buf, len};<br />
23| struct cmsghdr *cmsg = (struct cmsghdr *) malloc(cmsgspace), *ptr;<br />
24| struct msghdr msg = {<br />
25| (caddr_t) from, *fromlen, &iov, 1,<br />
26| (caddr_t) cmsg, cmsgspace<br />
27| };<br />
28| <br />
29| if (cmsg == NULL) {<br />
30| perror("recv_data: malloc");<br />
31| return -1;<br />
32| }<br />
33| ret = recvmsg(sock, &msg, flags);<br />
34| if (ret < 0) {<br />
35| perror("recv_data: recvmsg");<br />
36| goto done;<br />
37| }<br />
38| if (msg.msg_flags & MSG_TRUNC) {<br />
39| fprintf(stderr, "recv_data: recvmsg: data discarded before delivery\n");<br />
40| goto bad;<br />
41| }<br />
42| if (msg.msg_flags & MSG_CTRUNC) {<br />
43| fprintf(stderr,<br />
44| "recv_data: recvmsg: control data lost before delivery\n");<br />
45| goto bad;<br />
46| }<br />
47| if (msg.msg_controllen)<br />
48| for (ptr = CMSG_FIRSTHDR(&msg); ptr; ptr = CMSG_NXTHDR(&msg, ptr)) {<br />
49| if (ptr->cmsg_level==IPPROTO_IPV6 && ptr->cmsg_type==IPV6_HOPLIMIT) {<br />
50| if (ptr->cmsg_len != CMSG_LEN(sizeof(int))) {<br />
51| fprintf(stderr,<br />
52| "recvmsg: ancillary data with invalid length\n");<br />
53| goto bad;<br />
54| }<br />
55| *hoplimit = *((int *) CMSG_DATA(ptr));<br />
56| goto done;<br />
57| }<br />
58| }<br />
59| fprintf(stderr,<br />
60| "recv_data: recvmsg: hoplimit not found in ancillary data\n");<br />
61| bad:<br />
62| ret = -1;<br />
63| done:<br />
64| free(cmsg);<br />
65| return ret;<br />
66| }<br />
<br />
Le code de la fonction <tt>recv_data</tt> ne sera pas commenté car la réception du nombre de sauts via une donnée auxiliaire a été étudiée dans un précédent exemple, la seule différence étant que la gestion des erreurs est ici plus détaillée.<br />
<br />
Il faut enfin modifier trivialement le code de la routine <tt>recv_icmp_pkt</tt> afin que celle-ci imprime le nombre de sauts du paquet ECHO_REPLY (éventuellement) reçu. Nous en laissons le soin au lecteur.<br />
<br />
Pour l'autre donnée auxiliaire (cette fois ci en émission), à savoir le routage par la source, il faut naturellement tout d'abord modifier la fonction <tt>send_echo_request6</tt> et en premier lieu son prototype qui devient :<br />
<br />
int send_echo_request6(int sock, struct sockaddr_in6 *dst, uint16_t id,<br />
uint16_t seq, char *opt_data, int opt_data_size,<br />
struct in6_addr *seg, int nseg)<br />
<br />
La routine <tt>send_echo_request6</tt> modifié possède deux arguments supplémentaires ajoutés à la fin. Le premier de ces nouveaux arguments est un pointeur vers un tableau contenant les adresses IPv6 des relais par lesquels on souhaite effectuer le routage par la source. Le dernier argument est le nombre d'éléments de ce tableau, c'est-à-dire le nombre de relais.<br />
<br />
Il faut ensuite substituer dans le corps de la fonction <tt>send_echo_request6</tt> l'instruction suivante :<br />
<br />
noc = sendto(sock, (char *) icmp, icmp_pkt_size, 0, (struct sockaddr *) dst,<br />
<br />
par :<br />
<br />
noc = send_data(sock, (void *) icmp, icmp_pkt_size, 0, <br />
(struct sockaddr *) dst, sizeof(struct sockaddr_in6),<br />
seg, nseg);<br />
<br />
Si la variable <tt>seg</tt> est le pointeur <tt>NULL</tt>, la liste des relais est vide. On fait appel à la fonction <tt>send_data</tt>, dont le code va être commenté en détails :<br />
<br />
<br />
1| #ifdef sun /* For Solaris */<br />
2| #define _XOPEN_SOURCE 500 /* correct recvmsg/sendmsg/msg/CMSG_xx syntax */<br />
3| #define __EXTENSIONS__<br />
4| #endif<br />
5| #include <stdio.h><br />
6| #include <stdlib.h><br />
7| #include <unistd.h><br />
8| #include <sys/uio.h><br />
9| #include <sys/types.h><br />
10| #include <sys/socket.h><br />
11| #include <netinet/in.h><br />
12| #include <netinet/ip6.h><br />
13| #ifndef CMSG_SPACE /* Solaris <= 9 */<br />
14| #define CMSG_SPACE(l) ((size_t)_CMSG_HDR_ALIGN(sizeof (struct cmsghdr) + (l)))<br />
15| #define CMSG_LEN(l) ((size_t)_CMSG_DATA_ALIGN(sizeof (struct cmsghdr)) + (l))<br />
16| #endif<br />
17| #ifndef IPV6_RECVHOPLIMIT<br />
18| #define IPV6_RECVHOPLIMIT IPV6_HOPLIMIT<br />
19| #endif<br />
20| <br />
21| extern void * inet6_rth_init(); /* sometimes not in ip6.h */<br />
22| <br />
23| int send_data(int sock, void *buf, int len, unsigned int flags,<br />
24| struct sockaddr *to, socklen_t tolen,<br />
25| struct in6_addr *seg, int nseg)<br />
26| {<br />
27| int ret = -1, rthsp, cmsgspace;<br />
28| void *data;<br />
29| struct in6_addr *in6;<br />
30| struct iovec iov = {buf, len};<br />
31| struct cmsghdr *cmsg = NULL;<br />
32| struct msghdr msg = {<br />
33| (caddr_t) to, tolen, &iov, 1,<br />
34| NULL, 0, 0<br />
35| };<br />
36| <br />
37| if (seg != NULL) {<br />
38| rthsp = inet6_rth_space(IPV6_RTHDR_TYPE_0, nseg);<br />
39| cmsgspace = CMSG_SPACE(rthsp);<br />
40| msg.msg_control = cmsg = (struct cmsghdr *) malloc(cmsgspace);<br />
41| if (cmsg == NULL) {<br />
42| perror("recv_data: malloc");<br />
43| goto bad;<br />
44| }<br />
45| cmsg->cmsg_level = IPPROTO_IPV6;<br />
46| msg.msg_controllen = cmsg->cmsg_len = CMSG_LEN(rthsp);<br />
47| cmsg->cmsg_type = IPV6_RTHDR;<br />
48| data = CMSG_DATA(cmsg);<br />
49| data = (void *)inet6_rth_init(data, rthsp, IPV6_RTHDR_TYPE_0, nseg);<br />
50| if (!data) {<br />
51| fprintf(stderr, "send_data: inet6_rth_init failed\n");<br />
52| goto bad;<br />
53| }<br />
54| for (in6 = seg; in6 - seg < nseg; in6++)<br />
55| if (inet6_rth_add(data, in6) == -1) {<br />
56| fprintf(stderr, "send_data: inet6_rth_add failed\n");<br />
57| goto bad;<br />
58| }<br />
59| }<br />
60| ret = sendmsg(sock, &msg, flags);<br />
61| if (ret < 0) {<br />
62| perror("send_data: sendmsg");<br />
63| goto bad;<br />
64| }<br />
65| bad:<br />
66| if (cmsg)<br />
67| free(cmsg);<br />
68| return ret;<br />
69| }<br />
<br />
Les six premiers paramètres de la fonction <tt>send_data</tt> sont identiques à ceux de la primitive système <tt>sendto</tt>, les deux derniers étant quant à eux identiques aux deux derniers arguments de la routine <tt>send_echo_request6</tt>.<br />
<br />
Si la liste de relais est vide, on appelle <tt>sendmsg</tt> sans données auxiliaires (<tt>msg.msg_control</tt> est nul). Sinon on alloue (ligne 40) un tampon pour contenir les données auxiliaires.<br />
<br />
La routine <tt>inet6_rth_space</tt> est l'une des six nouvelles routines proposées par l'API avancée afin de faciliter la tâche du programmeur lors de la manipulation des en-têtes de routage. Elle prend en arguments le type de l'extension de routage (en l'occurrence la constante <tt>IPV6_RTHDR_TYPE_0</tt> dont la valeur numérique est 0 est qui est définie dans <tt><netinet/in.h></tt>) et le nombre de relais contenus dans cette extension (pour ce type d'extension, ce nombre doit être compris entre 0 et 127 inclus). Elle retourne la taille en octets nécessaire pour contenir cette en-tête de routage. Ici cette routine va permettre d'initialiser, via la variable <tt>rthsp</tt> et à l'aide de la macro <tt>CMSG_SPACE</tt>, la variable <tt>cmsgspace</tt> à la taille en octets de la donnée auxiliaire associée à cette extension de routage.<br />
<br />
En lignes 45 à 47, la longueur des données auxiliaires et la structure <tt>cmsg</tt> sont initialisés au moyen de la macro <tt>CMSG_LEN</tt> pour le champ <tt>cmsg_len</tt>.<br />
<br />
Il faut maintenant initialiser les données transmises par la donnée auxiliaire avec l'en-tête routage (lignes 48 à 53). Nous allons nous servir de la routine <tt>inet6_rth_init</tt> fournie par l'API avancée. Celle-ci prend en premier argument un pointeur vers la zone mémoire qui contiendra l'en-tête de routage, le deuxième argument étant la taille en octets de cette zone mémoire. Les deux derniers arguments sont identiques à ceux de la routine <tt>inet6_rth_space</tt>. <tt>inet6_rth_init</tt> retourne un pointeur vers cette zone mémoire ou le pointeur <tt>NULL</tt> si la taille de celle-ci est insuffisante.<br />
<br />
Après ces diverses initialisations, la donnée auxiliaire est représentée à la figure Initialisation de l'en-tête de routage où l'on a supposé, afin de fixer les idées, que l'on est en présence d'une architecture 32 bits et que l'alignement se fait sur 32 bits également (autrement dit il n'y a pas de bourrage entre la structure cmsg et le début des données transmises, cf. [[figure Structure des données auxiliaires]]).<br />
<br />
[[image:CS197.gif]]<br />
<br />
Dans la boucle qui suit (lignes 54 à 58), l'initialisation de l'en-tête de routage se termine en ajoutant successivement les adresses IPv6 des relais du routage par la source. Ces ajouts se font au moyen de la fonction <tt>inet6_rth_add</tt> qui prend en premier argument la zone mémoire contenant l'en-tête de routage et en deuxième argument un pointeur (de type <tt>struct in6_addr *</tt>) vers l'adresse du relais à ajouter.<br />
<br />
A l'issue de cette boucle, si l'on reprend l'exemple qui nous a servi à présenter la nouvelle version de la commande one_ping6 :<br />
<br />
$ '''xapi_ping6 www.kame.net relais.imag.fr ipv6.imag.fr'''<br />
<br />
la donnée auxiliaire sera maintenant comme représentée à la figure Adjonction des deux relais dans l'en-tête de routage, (avec les mêmes hypothèses sur l'architecture et l'alignement). Le message ainsi construit est expédié tout en gérant les erreurs éventuelles (nous laissons le soin au lecteur l'adaptation de la fonction main afin de prendre en compte les nouveaux arguments (optionnels) du programme <tt>one_ping6</tt>).<br />
<br />
[[image:CS198.gif]]<br />
<br />
On remarque que la donnée auxiliaire contient les adresses des relais intermédiaires, alors que dans un paquet IPv6, [[Les extensions#routage|l'en-tête de routage]] contient les adresses à partir du deuxième relais et l'adresse destination finale, l'adresse du premier relais étant dans l'en-tête IPv6. Le noyau lors du <tt>sendmsg</tt> va permuter les adresses pour rétablir l'ordre correct.<br />
<br />
===Portabilité du code===<br />
<br />
Solaris définit des prototypes de <tt>sendmsg</tt> et <tt>recvmsg</tt> variables selon les modes de compilation. De plus, jusqu'à la version 9 incluse, il ne définit pas les macros <tt>CMSG_SPACE</tt> et <tt>CMSG_LEN</tt>. Les lignes 1 à 4 et 13 à 19 du programme servent à éviter ces problèmes de compatibilité.<br />
<br />
D'autre part, les fonctions <tt>inet6_rth_xxx</tt>, définies dans le RFC 3542 sont encore souvent absentes de la librairie système (c'est le cas pour Solaris 9, FreeBSD4.x, NetBSD1.x, et Linux). Le lecteur peut les remplacer par un codage à la main, ou récupérer leur texte, par exemple dans la distribution KAME.<br />
{{suivi| L'implémentation | L'implémentation | Supervision | Supervision }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=L%27impl%C3%A9mentation&diff=2962L'implémentation2006-02-27T11:08:57Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| Programmation avancée | Programmation avancée | L'exemple « mini-ping » revisité | L'exemple « mini-ping » revisité }}<br />
Comme indiqué précédemment, l'implémentation de l'API avancée repose principalement sur les primitives <tt>sendmsg</tt> et <tt>recvmsg</tt> dont les prototypes sont les suivants :<br />
<br />
int sendmsg(int s, const struct msghdr *msg, int flags);<br />
int recvmsg(int s, struct msghdr *msg, unsigned int flags);<br />
<br />
Le premier paramètre s désigne le descripteur d'E/S associée à la socket et le dernier paramètre flags est identique au 3ème paramètre des primitives sendto et recvfrom. Le second paramètre est une structure définie (dans <tt><sys/socket.h></tt>) comme suit :<br />
<br />
struct msghdr {<br />
void *msg_name; /* pointeur vers l'adresse de la socket */<br />
socklen_t msg_namelen; /* longueur de l'adresse de la socket */<br />
struct iovec *msg_iov; /* tampon mémoire vectoriel (scatter/gather array) */<br />
int msg_iovlen; /* nombre d'éléments de msg_iov */<br />
void *msg_control; /* données auxiliaires */<br />
socklen_t msg_controllen; /* longueur des données auxiliaires */<br />
int msg_flags; /* drapeaux des messages reçus */<br />
};<br />
<br />
Les deux premiers champs spécifient pour <tt>sendmsg</tt> (respectivement <tt>recvmsg</tt>) l'adresse de destination (respectivement d'origine). Le premier champ peut être le pointeur <tt>NULL</tt> en mode connecté. Les deux champs suivants contiennent le tampon mémoire vectoriel en émission ou en réception suivant le cas (voir le manuel de la primitive <tt>readv</tt>).<br />
<br />
Les champs <tt>msg_control</tt> et <tt>msg_controllen</tt> spécifient le tableau des données auxiliaires reçues ou émises, le champ <tt>msg_control</tt> pouvant être le pointeur <tt>NULL</tt> s'il n'y a aucune donnée auxiliaire à émettre ou recevoir. Chaque donnée auxiliaire se présente sous la forme d'une structure de type struct <tt>cmsghdr</tt> définie (dans <tt>sys/socket.h</tt>) :<br />
<br />
struct cmsghdr {<br />
socklen_t cmsg_len; /* longueur en octet, en-tête inclus */<br />
int cmsg_level; /* protocole (IPPROTO_IPV6, ...) */<br />
int cmsg_type; /* sous-type dans le protocole (IPV6_RTHDR, ...) */<br />
/* suivi par unsigned char cmsg_data[]; */<br />
};<br />
<br />
En raison de problèmes d'alignement (cf. figure Structure des données auxiliaires), l'accès au tableau des données auxiliaires ainsi que la manipulation de ces dernières ne doivent se faire qu'au moyen de cinq macros appropriées, définies dans <tt><sys/socket.h></tt> :<br />
<br />
[[image:CS196.gif]]<br />
<br />
* <tt>struct cmsghdr *CMSG_FIRSTHDR(const struct msghdr *msgh);</tt><br><tt>CMSG_FIRSTHDR</tt> renvoie un pointeur vers la première donnée auxiliaire contenue dans la structure de type <tt>struct msghdr</tt> pointée par <tt>msgh</tt>.<br />
* <tt>struct cmsghdr *CMSG_NXTHDR(const struct msghdr *msgh, const struct cmsghdr *cmsg);</tt><br><tt>CMSG_NXTHDR</tt> renvoie un pointeur vers la donnée auxiliaire qui suit celle pointée par <tt>cmsg</tt> ou le pointeur <tt>NULL</tt> s'il n'y en a pas. Si <tt>cmsg</tt> est le pointeur <tt>NULL</tt>, <tt>CMSG_NXTHDR</tt> renvoie un pointeur vers la première donnée auxiliaire. Ainsi, <tt>CMSG_NXTHDR(msgh, NULL)</tt> est équivalent à <tt>CMSG_FIRSTHDR(msgh)</tt>.<br />
* <tt>socklen_t CMSG_SPACE(socklen_t length);</tt><br><tt>CMSG_SPACE</tt> renvoie le nombre d'octets occupés par une donnée auxiliaire dont la taille des données transmises est <tt>length</tt>, tout en tenant compte des alignements.<br />
* <tt>socklen_t CMSG_LEN(socklen_t length);</tt><br><tt>CMSG_LEN</tt> retourne la valeur à stocker dans le champ <tt>cmsg_len</tt> de la structure (de type <tt>struct cmsghdr</tt>) associée à une donnée auxiliaire dont la taille des données transmises est <tt>length</tt>, ceci en tenant compte des alignements.<br />
* <tt>unsigned char *CMSG_DATA(const struct cmsghdr *cmsg);</tt><br><tt>CMSG_DATA</tt> retourne un pointeur vers les données contenues dans la donnée auxiliaire pointée par le paramètre <tt>cmsg</tt>.<br />
<br />
Le dernier champ <tt>msg_flags</tt> de la structure msghdr est rempli au retour de <tt>recvmsg()</tt>. Plusieurs drapeaux peuvent avoir été levés dont le drapeau <tt>MSG_TRUNC</tt> pour indiquer que les données ont été tronquées ou le drapeau <tt>MSG_CTRUNC</tt> pour indiquer que les données auxiliaires ont été tronquées.<br />
<br />
Afin de recevoir toute donnée auxiliaire sur une socket, il faut auparavant le demander en positionnant l'option correspondante. Plus précisément, le RFC 3542 liste de manière exhaustive des options disponibles et comment les positionner :<br />
<br />
int on = 1;<br />
/* interface de réception / adresse destination */<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on));<br />
/* nombre de sauts */<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on));<br />
/* en-tête de routage */<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));<br />
/* options proche-en-proche */<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on));<br />
/* option destination */<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));<br />
/* classe de trafic */<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVTCLASS, &on, sizeof(on));<br />
<br />
En ce qui concerne l'émission d'une donnée auxiliaire, deux possibilités s'offrent au programmeur :<br />
<br />
* soit il fait appel à la primitive <tt>setsockopt</tt> pour positionner l'option correspondante avec les données adéquates. Ce sont alors des options dites permanentes (''sticky'') car elles s'appliquent à tous les paquets transmis par la suite et ce jusqu'à un nouvel appel à <tt>setsockopt</tt> ou une surcharge par une donnée auxiliaire.<br />
* soit il utilise <tt>sendmsg</tt> et les données auxiliaires affectent uniquement le datagramme concerné (non applicable au socket de type <tt>SOCK_STREAM</tt>)<br />
<br />
Le tableau Options de données auxiliaires en émission, extrait du RFC 3542, donne la liste des options disponibles en émission (avec leur type de données associées) :<br />
<br />
{|<br />
|+'''''Options de données auxiliaires en émission'''''<br />
|-<br />
!opt level / cmsg_level || optname / cmsg_type || optval / cmsg_data[]<br />
|-style="background:silver" <br />
|IPPROTO_IPV6 || IPV6_PKTINFO ||structure in6_pktinfo<br />
|-<br />
|IPPROTO_IPV6 || IPV6_HOPLIMIT ||int<br />
|-style="background:silver" <br />
|IPPROTO_IPV6 || IPV6_NEXTHOP || structure sockaddr_in6<br />
|-<br />
|IPPROTO_IPV6 || IPV6_RTHDR || structure ip6_rthdr<br />
|-style="background:silver" <br />
|IPPROTO_IPV6 || IPV6_HOPOPTS (prochain saut / next hop) || structure ip6_hbh<br />
|-<br />
|IPPROTO_IPV6 || IPV6_DSTOPTS || structure ip6_dest<br />
|-style="background:silver" <br />
|IPPROTO_IPV6 || IPV6_RTHDRDSTOPTS || structure ip6_dest<br />
|-<br />
|IPPROTO_IPV6 || IPV6_TCLASS || int<br />
|}<br />
<br />
Les options proposées par cette API avancée, ne seront pas toutes détaillées dans ce chapitre. Nous recommandons au lecteur intéressé de se reporter au RFC 3542. L'exemple simple qui suit, met en oeuvre ces notions. Il s'agit d'un extrait de programme qui, outre les données habituelles, souhaite recevoir également deux données auxiliaires :<br />
<br />
* index de l'interface de réception du paquet / adresse destination du paquet reçu (option <tt> IPV6_RECVPKTINFO</tt>) et<br />
* le nombre de sauts (hop limit) du paquet reçu (option <tt>IPV6_RECVHOPLIMIT</tt>).<br />
<br />
La première partie de ce programme, où les variables sont déclarées et initialisées ne présente aucune difficulté. On notera l'usage de la macro <tt>CMSG_SPACE</tt> afin d'initialiser la variable <tt>cmsg_buf</tt> destinée à accueillir les données auxiliaires demandées.<br />
<br />
int noc, o = 1, s;<br />
struct sockaddr_storage from;<br />
char buf[1024];<br />
struct iovec iov = {buf, sizeof(buf)};<br />
char cmsg_buf[CMSG_SPACE(sizeof(struct in6_pktinfo)) + CMSG_SPACE(sizeof(int))];<br />
struct cmsghdr *cmsg;<br />
struct msghdr msg = {(void *) &from, sizeof(from), &iov, 1,<br />
(void *) cmsg_buf, sizeof(cmsg_buf), 0};<br />
<br />
Actuellement, un grand nombre d'implémentations ne sont pas à jour du RFC 3542 (bien que publié en mai 2003). En particulier, certaines implémentations ne distinguent toujours pas entre les options de réception et les options d'émission. Si bien qu'il peut être nécessaire d'ajouter les lignes suivantes :<br />
<br />
#ifndef IPV6_RECVHOPLIMIT<br />
#define IPV6_RECVHOPLIMIT IPV6_HOPLIMIT<br />
#endif<br />
#ifndef IPV6_RECVPKTINFO<br />
#define IPV6_RECVPKTINFO IPV6_PKTINFO<br />
#endif<br />
<br />
Ensuite on indique par l'intermédiaire de la primitive <tt>setsockopt</tt> que les données auxiliaires mentionnées plus haut doivent être reçues. La variable <tt>s</tt> est un descripteur d'entrées/sorties associé à une socket <tt>PF_INET6</tt>.<br />
<br />
if (setsockopt(s, IPPROTO_IPV6, IPV6_RECVPKTINFO, &o, sizeof(o)) ||<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &o, sizeof(o))) {<br />
/* traitement de l'erreur */<br />
}<br />
<br />
La primitive <tt>recvmsg</tt> est exécutée et les erreurs éventuelles sont traitées :<br />
<br />
if ((noc = recvmsg(s, &msg, 0)) < 0) {<br />
/* traitement de l'erreur */<br />
}<br />
if (msg.msg_flags & MSG_TRUNC) {<br />
/* traitement de l'erreur (les données sont tronquées) */<br />
}<br />
if (msg.msg_flags & MSG_CTRUNC) {<br />
/* traitement de l'erreur (les données auxiliaires sont tronquées) */<br />
}<br />
<br />
Finalement, au moyen des macros <tt>CMSG_FIRSTHDR</tt> et <tt>CMSG_NXTHDR</tt> précédemment décrites, une boucle traite les données auxiliaires reçues :<br />
<br />
for (cmsg = CMSG_FIRSTHDR(&msg); cmsg; cmsg = CMSG_NXTHDR(&msg, cmsg)) {<br />
if ((cmsg->cmsg_level == IPPROTO_IPV6) && (cmsg->cmsg_type == IPV6_PKTINFO)) {<br />
struct in6_pktinfo *pi = (struct in6_pktinfo *) CMSG_DATA(cmsg);<br />
/* suite du traitement */<br />
}<br />
if ((cmsg->cmsg_level == IPPROTO_IPV6) && (cmsg->cmsg_type == IPV6_HOPLIMIT)) {<br />
int hlim = *(int *)CMSG_DATA(cmsg);<br />
/* suite du traitement */<br />
}<br />
/* suite du programme */<br />
}<br />
{{suivi| Programmation avancée | Programmation avancée | L'exemple « mini-ping » revisité | L'exemple « mini-ping » revisité }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=L%27impl%C3%A9mentation&diff=2961L'implémentation2006-02-27T11:07:53Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| Programmation avancée | Programmation avancée | L'exemple « mini-ping » revisité | L'exemple « mini-ping » revisité }}<br />
Comme indiqué précédemment, l'implémentation de l'API avancée repose principalement sur les primitives <tt>sendmsg</tt> et <tt>recvmsg</tt> dont les prototypes sont les suivants :<br />
<br />
int sendmsg(int s, const struct msghdr *msg, int flags);<br />
int recvmsg(int s, struct msghdr *msg, unsigned int flags);<br />
<br />
Le premier paramètre s désigne le descripteur d'E/S associée à la socket et le dernier paramètre flags est identique au 3ème paramètre des primitives sendto et recvfrom. Le second paramètre est une structure définie (dans <tt><sys/socket.h></tt>) comme suit :<br />
<br />
struct msghdr {<br />
void *msg_name; /* pointeur vers l'adresse de la socket */<br />
socklen_t msg_namelen; /* longueur de l'adresse de la socket */<br />
struct iovec *msg_iov; /* tampon mémoire vectoriel (scatter/gather array) */<br />
int msg_iovlen; /* nombre d'éléments de msg_iov */<br />
void *msg_control; /* données auxiliaires */<br />
socklen_t msg_controllen; /* longueur des données auxiliaires */<br />
int msg_flags; /* drapeaux des messages reçus */<br />
};<br />
<br />
Les deux premiers champs spécifient pour <tt>sendmsg</tt> (respectivement <tt>recvmsg</tt>) l'adresse de destination (respectivement d'origine). Le premier champ peut être le pointeur <tt>NULL</tt> en mode connecté. Les deux champs suivants contiennent le tampon mémoire vectoriel en émission ou en réception suivant le cas (voir le manuel de la primitive <tt>readv</tt>).<br />
<br />
Les champs <tt>msg_control</tt> et <tt>msg_controllen</tt> spécifient le tableau des données auxiliaires reçues ou émises, le champ <tt>msg_control</tt> pouvant être le pointeur <tt>NULL</tt> s'il n'y a aucune donnée auxiliaire à émettre ou recevoir. Chaque donnée auxiliaire se présente sous la forme d'une structure de type struct <tt>cmsghdr</tt> définie (dans <tt>sys/socket.h</tt>) :<br />
<br />
struct cmsghdr {<br />
socklen_t cmsg_len; /* longueur en octet, en-tête inclus */<br />
int cmsg_level; /* protocole (IPPROTO_IPV6, ...) */<br />
int cmsg_type; /* sous-type dans le protocole (IPV6_RTHDR, ...) */<br />
/* suivi par unsigned char cmsg_data[]; */<br />
};<br />
<br />
En raison de problèmes d'alignement (cf. figure Structure des données auxiliaires), l'accès au tableau des données auxiliaires ainsi que la manipulation de ces dernières ne doivent se faire qu'au moyen de cinq macros appropriées, définies dans <tt><sys/socket.h></tt> :<br />
<br />
[[image:CS196.gif]]<br />
<br />
* <tt>struct cmsghdr *CMSG_FIRSTHDR(const struct msghdr *msgh);</tt><br><tt>CMSG_FIRSTHDR</tt> renvoie un pointeur vers la première donnée auxiliaire contenue dans la structure de type <tt>struct msghdr</tt> pointée par <tt>msgh</tt>.<br />
* <tt>struct cmsghdr *CMSG_NXTHDR(const struct msghdr *msgh, const struct cmsghdr *cmsg);</tt><br><tt>CMSG_NXTHDR</tt> renvoie un pointeur vers la donnée auxiliaire qui suit celle pointée par <tt>cmsg</tt> ou le pointeur <tt>NULL</tt> s'il n'y en a pas. Si <tt>cmsg</tt> est le pointeur <tt>NULL</tt>, <tt>CMSG_NXTHDR</tt> renvoie un pointeur vers la première donnée auxiliaire. Ainsi, <tt>CMSG_NXTHDR(msgh, NULL)</tt> est équivalent à <tt>CMSG_FIRSTHDR(msgh)</tt>.<br />
* <tt>socklen_t CMSG_SPACE(socklen_t length);</tt><br><tt>CMSG_SPACE</tt> renvoie le nombre d'octets occupés par une donnée auxiliaire dont la taille des données transmises est <tt>length</tt>, tout en tenant compte des alignements.<br />
* <tt>socklen_t CMSG_LEN(socklen_t length);</tt><br><tt>CMSG_LEN</tt> retourne la valeur à stocker dans le champ <tt>cmsg_len</tt> de la structure (de type <tt>struct cmsghdr</tt>) associée à une donnée auxiliaire dont la taille des données transmises est <tt>length</tt>, ceci en tenant compte des alignements.<br />
* <tt>unsigned char *CMSG_DATA(const struct cmsghdr *cmsg);</tt><br><tt>CMSG_DATA</tt> retourne un pointeur vers les données contenues dans la donnée auxiliaire pointée par le paramètre <tt>cmsg</tt>.<br />
<br />
Le dernier champ <tt>msg_flags</tt> de la structure msghdr est rempli au retour de <tt>recvmsg()</tt>. Plusieurs drapeaux peuvent avoir été levés dont le drapeau <tt>MSG_TRUNC</tt> pour indiquer que les données ont été tronquées ou le drapeau <tt>MSG_CTRUNC</tt> pour indiquer que les données auxiliaires ont été tronquées.<br />
<br />
Afin de recevoir toute donnée auxiliaire sur une socket, il faut auparavant le demander en positionnant l'option correspondante. Plus précisément, le RFC 3542 liste de manière exhaustive des options disponibles et comment les positionner :<br />
<br />
int on = 1;<br />
/* interface de réception / adresse destination */<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on));<br />
/* nombre de sauts */<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on));<br />
/* en-tête de routage */<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));<br />
/* options proche-en-proche */<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on));<br />
/* option destination */<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));<br />
/* classe de trafic */<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVTCLASS, &on, sizeof(on));<br />
<br />
En ce qui concerne l'émission d'une donnée auxiliaire, deux possibilités s'offrent au programmeur :<br />
<br />
* soit il fait appel à la primitive <tt>setsockopt</tt> pour positionner l'option correspondante avec les données adéquates. Ce sont alors des options dites permanentes (''sticky'') car elles s'appliquent à tous les paquets transmis par la suite et ce jusqu'à un nouvel appel à <tt>setsockopt</tt> ou une surcharge par une donnée auxiliaire.<br />
* soit il utilise <tt>sendmsg</tt> et les données auxiliaires affectent uniquement le datagramme concerné (non applicable au socket de type <tt>SOCK_STREAM</tt>)<br />
<br />
Le tableau Options de données auxiliaires en émission, extrait du RFC 3542, donne la liste des options disponibles en émission (avec leur type de données associées) :<br />
<br />
{|<br />
|+'''''Options de données auxiliaires en émission'''''<br />
|-<br />
!opt level / cmsg_level || optname / cmsg_type || optval / cmsg_data[]<br />
|-style="background:silver" <br />
|IPPROTO_IPV6 || IPV6_PKTINFO ||structure in6_pktinfo<br />
|-<br />
|IPPROTO_IPV6 || IPV6_HOPLIMIT ||int<br />
|-style="background:silver" <br />
|IPPROTO_IPV6 || IPV6_NEXTHOP || structure sockaddr_in6<br />
|-<br />
|IPPROTO_IPV6 || IPV6_RTHDR || structure ip6_rthdr<br />
|-style="background:silver" <br />
|IPPROTO_IPV6 || IPV6_HOPOPTS (prochain saut / next hop) || structure ip6_hbh<br />
|-<br />
|IPPROTO_IPV6 || IPV6_DSTOPTS || structure ip6_dest<br />
|-style="background:silver" <br />
|IPPROTO_IPV6 || IPV6_RTHDRDSTOPTS || structure ip6_dest<br />
|-<br />
|IPPROTO_IPV6 || IPV6_TCLASS || int<br />
|}<br />
<br />
Les options proposées par cette API avancée, ne seront pas toutes détaillées dans ce chapitre. Nous recommandons au lecteur intéressé de se reporter au RFC 3542. L'exemple simple qui suit, met en oeuvre ces notions. Il s'agit d'un extrait de programme qui, outre les données habituelles, souhaite recevoir également deux données auxiliaires :<br />
<br />
* index de l'interface de réception du paquet / adresse destination du paquet reçu (option <tt> IPV6_RECVPKTINFO</tt>) et<br />
* le nombre de sauts (hop limit) du paquet reçu (option <tt>IPV6_RECVHOPLIMIT</tt>).<br />
<br />
La première partie de ce programme, où les variables sont déclarées et initialisées ne présente aucune difficulté. On notera l'usage de la macro <tt>CMSG_SPACE</tt> afin d'initialiser la variable <tt>cmsg_buf</tt> destinée à accueillir les données auxiliaires demandées.<br />
<br />
int noc, o = 1, s;<br />
struct sockaddr_storage from;<br />
char buf[1024];<br />
struct iovec iov = {buf, sizeof(buf)};<br />
char cmsg_buf[CMSG_SPACE(sizeof(struct in6_pktinfo)) + CMSG_SPACE(sizeof(int))];<br />
struct cmsghdr *cmsg;<br />
struct msghdr msg = {(void *) &from, sizeof(from), &iov, 1,<br />
(void *) cmsg_buf, sizeof(cmsg_buf), 0};<br />
<br />
Actuellement, un grand nombre d'implémentations ne sont pas à jour du RFC 3542 (bien que publié en mai 2003). En particulier, certaines implémentations ne distinguent toujours pas entre les options de réception et les options d'émission. Si bien qu'il peut être nécessaire d'ajouter les lignes suivantes :<br />
<br />
#ifndef IPV6_RECVHOPLIMIT<br />
#define IPV6_RECVHOPLIMIT IPV6_HOPLIMIT<br />
#endif<br />
#ifndef IPV6_RECVPKTINFO<br />
#define IPV6_RECVPKTINFO IPV6_PKTINFO<br />
#endif<br />
<br />
Ensuite on indique par l'intermédiaire de la primitive <tt>setsockopt</tt> que les données auxiliaires mentionnées plus haut doivent être reçues. La variable <tt>s</tt> est un descripteur d'entrées/sorties associé à une socket <tt>PF_INET6</tt>.<br />
<br />
if (setsockopt(s, IPPROTO_IPV6, IPV6_RECVPKTINFO, &o, sizeof(o)) ||<br />
setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &o, sizeof(o))) {<br />
/* traitement de l'erreur */<br />
}<br />
<br />
La primitive <tt>recvmsg</tt> est exécutée et les erreurs éventuelles sont traitées :<br />
<br />
if ((noc = recvmsg(s, &msg, 0)) < 0) {<br />
/* traitement de l'erreur */<br />
}<br />
if (msg.msg_flags & MSG_TRUNC) {<br />
/* traitement de l'erreur (les données sont tronquées) */<br />
}<br />
if (msg.msg_flags & MSG_CTRUNC) {<br />
/* traitement de l'erreur (les données auxiliaires sont tronquées) */<br />
}<br />
<br />
Finalement, au moyen des macros <tt>CMSG_FIRSTHDR</tt> et <tt>CMSG_NXTHDR</tt> précédemment décrites, une boucle traite les données auxiliaires reçues :<br />
<br />
for (cmsg = CMSG_FIRSTHDR(&msg); cmsg; cmsg = CMSG_NXTHDR(&msg, cmsg)) {<br />
if ((cmsg->cmsg_level == IPPROTO_IPV6) && (cmsg->cmsg_type == IPV6_PKTINFO)) {<br />
struct in6_pktinfo *pi = (struct in6_pktinfo *) CMSG_DATA(cmsg);<br />
/* suite du traitement */<br />
}<br />
if ((cmsg->cmsg_level == IPPROTO_IPV6) && (cmsg->cmsg_type == IPV6_HOPLIMIT)) {<br />
int hlim = *(int *)CMSG_DATA(cmsg);<br />
/* suite du traitement */<br />
}<br />
/* suite du programme */<br />
}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Programmation_avanc%C3%A9e&diff=2960Programmation avancée2006-02-27T11:06:34Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| Utilisation du multicast | Utilisation du multicast | L'implémentation | L'implémentation }}<br />
L'API « avancée » (''Advanced API''), définie par le RFC 3542, a pour objet la standardisation de la manipulation en émission/réception des datagrammes IPv6. Elle permet notamment au programmeur d'écrire des applications utilisant les nouvelles fonctionnalités proposées par le protocole IPv6 et ce de façon portable.<br />
<br />
Cette API avancée concerne essentiellement les sockets de type <tt>SOCK_DGRAM</tt> (UDP) ou de type <tt>SOCK_RAW</tt> (ICMPv6,...). En effet, comme il n'y a pas de correspondance biunivoque entre les opérations de réception (respectivement d'émission) et les segments TCP reçus (respectivement émis), la plupart des options proposées ne sont pas applicables ou voire dénuées de sens pour une socket de type <tt>SOCK_STREAM</tt>. L'API avancée est utile pour programmer des applications comme <tt>ping</tt>, <tt>traceroute</tt>, des implémentations de protocoles de routage et, de manière générale, toute application construite avec des sockets de type <tt>SOCK_RAW</tt> et devant accéder aux champs des en-têtes IPv6 ou ICMPv6.<br />
<br />
La standardisation des appels systèmes et de fonctions a pour but de fournir un interface uniforme, évitant ainsi l'hétérogénéité qui existe en IPv4.<br />
<br />
Les opérations disponibles sont les suivantes :<br />
<br />
* Calcul/vérification des checksums par le noyau (pour les sockets de type <tt>SOCK_RAW</tt>)<br />
* Filtrage des réceptions des paquets ICMPv6<br />
* Modification des caractéristiques du datagramme IPv6 (packet information)<br />
* Manipulation des en-têtes d'extension IPv6<br />
* proche-en-proche (hop-by-hop)<br />
* routage par la source (routing header)<br />
* destination (destination)<br />
* Gestion du MTU et du mécanisme de découverte du PMTU (Path MTU discovery)<br />
<br />
En outre, des fonctions facilitant le traitement des en-têtes d'extension IPv6 ont été définies ainsi qu'une interface étendant les primitives <tt>rresvport</tt>, <tt>rcmd</tt> et <tt>rexec</tt> à IPv6. Cette API avancée ne prend pas en compte les en-têtes d'extension IPv6 liés à IPsec.<br />
<br />
L'implémentation de ce nouveau standard est réalisé à l'aide des primitives <tt>sendmsg</tt> et <tt>recvmsg</tt>, les données en émission/réception étant traitées via les données auxiliaires (ancillary data) associées à la socket et gérées par ces primitives. Également, de nouvelles options ont été définies pour les sockets.<br />
{{suivi| Utilisation du multicast | Utilisation du multicast | L'implémentation | L'implémentation }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Utilisation_du_multicast&diff=2959Utilisation du multicast2006-02-27T11:05:18Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| mini-ping | mini-ping | Programmation avancée | Programmation avancée }}<br />
La programmation avec les groupes multicast n'est pas standardisée en IPv4. La nouvelle API "socket" propose un ensemble de structures et appels systèmes pour étendre l'interface de programmation sockets aux applications utilisant le multicast. Cet exemple va illustrer ce point.<br />
<br />
Le but des deux programmes est d'échanger des données par multicast. Le programme <tt>in2multi6</tt> diffuse les données lues en entrée ("standard input") vers un groupe multicast donné. Le programme <tt>multi2out6</tt> écoute les paquets transmis dans ce groupe et les copie sur la sortie standard ("stdout").<br />
<br />
==multi2out6==<br />
<br />
Pour ce faire <tt>multi2out6</tt> va faire des appels systèmes qui vont produire des paquets d'abonnement (et de désabonnement) à un groupe multicast. L'abonnement sera réalisé grâce à l'envoi de deux messages ICMPv6 successifs de type 131, c'est-à-dire des "rapports d'abonnement". Puis les messages émis dans le groupe sont reçus par le programme. Lorsque le programme s'arrête, le code de l'interface va automatiquement provoquer l'émission d'un message de réduction d'un groupe de multicast (132).<br />
<br />
Le programme multi2out6 est appelé de la manière suivante :<br />
<br />
'''multi2out6 [-i interface] <adresse de groupe multicast>'''<br />
<br />
Voici le code complet du programme. Le port utilisé (ligne 15) est quelconque mais ne doit bien sûr pas correspondre à un service déjà existant.<br />
<br />
1| #include <sys/types.h><br />
2| #include <sys/socket.h><br />
3| #include <netinet/in.h><br />
4| #include <arpa/inet.h><br />
5| #include <stdio.h><br />
6| #include <signal.h><br />
7| #include <unistd.h><br />
8| <br />
9| #ifndef SO_REUSEPORT<br />
10| #define SO_REUSEPORT SO_REUSEADDR<br />
11| #endif<br />
12| <br />
13| struct sockaddr_in6 sin6;<br />
14| <br />
15| #define IPPORT 54321<br />
16| <br />
17| void Perror(const char *c)<br />
18| {<br />
19| perror(c);<br />
20| exit(1);<br />
21| }<br />
22| <br />
23| void Usage ()<br />
24| {<br />
25| fprintf(stderr, "%s\n", "Usage: multi2out6 [-i interface] addr");<br />
26| exit(1);<br />
27| }<br />
28| <br />
29| void BrokenPipe(int Signal)<br />
30| {<br />
31| signal(SIGPIPE, BrokenPipe);<br />
32| return;<br />
33| }<br />
34| <br />
<br />
La partie principale du programme traite les options éventuelles. En fait, il n'y en a qu'une, le choix de l'interface à abonner au groupe multicast. Une fois ces operations effectuées, il faut créer et attacher une socket à une adresse. Ces opérations sont réalisées par l'utilisation des fonctions classiques socket et bind.<br />
<br />
On utilise une structure de données spéciale pour stocker l'adresse multicast du groupe (définie dans <tt>netinet/in.h</tt>) :<br />
<br />
struct ipv6_mreq {<br />
struct in6_addr ipv6mr_multiaddr; /* IPv6 mcast address of group */<br />
unsigned int ipv6mr_interface; /* local IPv6 address of interface */<br />
};<br />
<br />
<br />
<br />
<br />
35| main(int argc, char **argv)<br />
36| {<br />
37| struct ipv6_mreq mreq;<br />
38| int cc, ccb, ch, s;<br />
39| char buf[10240];<br />
40| u_int one = 1;<br />
41| u_int ifi = 0;<br />
42| <br />
43| signal(SIGPIPE, BrokenPipe);<br />
44| while ((ch = getopt(argc, argv, "i:")) != -1)<br />
45| switch(ch) {<br />
46| case 'i':<br />
47| if (sscanf(optarg, "%u\0", &ifi) != 1 &&<br />
48| (ifi = if_nametoindex(optarg)) == 0)<br />
49| Usage();<br />
50| break;<br />
51| default:<br />
52| Usage();<br />
53| }<br />
54| argc -= optind;<br />
55| argv += optind;<br />
56| if (argc != 1)<br />
57| Usage();<br />
58| <br />
59| if ((s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP)) < 0)<br />
60| Perror("socket");<br />
61| setsockopt(s, SOL_SOCKET, SO_REUSEPORT, &one, sizeof(one));<br />
62| <br />
63| #ifdef SIN6_LEN<br />
64| sin6.sin6_len = sizeof(sin6);<br />
65| #endif<br />
66| sin6.sin6_family = AF_INET6;<br />
67| sin6.sin6_port = htons(IPPORT);<br />
68| if (bind(s, (struct sockaddr *)&sin6, sizeof(sin6)) < 0)<br />
69| Perror("bind");<br />
<br />
La fonction <tt>inet_pton</tt> va permettre la conversion du nom de groupe passé en option sous une forme textuelle (par exemple <tt>ff12::1234:5678</tt>) en forme numérique. Le résultat est directement stocké dans la variable <tt>mreq</tt> qui sera utilisée par la commande <tt>setsockop</tt>. On passe en paramètre à cette fonction l'option <tt>IPV6_JOIN_GROUP</tt> avec la variable <tt>mreq</tt>. À partir de ce moment, il y a émission de deux messages d'abonnement. La boucle qui suit va permettre la lecture des informations envoyées sur le groupe auquel on vient de s'abonner et les afficher sur la sortie standard ainsi que leur longueur sur la sortie erreur standard.<br />
<br />
<br />
70| if (inet_pton(AF_INET6, *argv, &mreq.ipv6mr_multiaddr) != 1)<br />
71| Usage();<br />
72| mreq.ipv6mr_interface = ifi;<br />
73| if (setsockopt(s,IPPROTO_IPV6, IPV6_JOIN_GROUP, &mreq, sizeof(mreq)) < 0)<br />
74| Perror("setsockopt IPV6_JOIN_GROUP");<br />
75| for (;;) {<br />
76| cc = read(s, buf, 10240);<br />
77| if (cc < 0)<br />
78| Perror("read socket");<br />
79| if (cc == 0) {<br />
80| fprintf(stderr, "..\n");<br />
81| exit (0);<br />
82| }<br />
83| ccb = write(1, buf, cc);<br />
84| if (ccb != cc)<br />
85| Perror("write file");<br />
86| fprintf(stderr, "<-%d-\n", cc);<br />
87| }<br />
88| }<br />
<br />
Lorsque le programme s'arrête, un <tt>close(s)</tt> implicite a lieu, et le code de l'interface va envoyer un message de réduction de groupe si elle est la dernière à avoir envoyé un rapport d'abonnement au groupe.<br />
<br />
==in2multi6==<br />
<br />
Le programme est appelé de la manière suivante :<br />
<br />
'''in2multi6 [-i interface][-h max-hop-count][-l loop] <adresse de groupe multicast>'''<br />
<br />
Le code est relativement simple, principalement une analyse des arguments, le positionnement d'option et une boucle lecture--émission. En effet il n'est pas nécessaire de s'abonner pour faire de l'émission multicast.<br />
<br />
Il y a quatre arguments, trois optionnels qui sont l'interface d'émission (nom ou index numérique), le "ttl" mis dans les paquets multicast (voir le manuel de la primitive <tt>readv</tt>), et un drapeau qui sert à dire si la machine émettrice reçoit ou non les paquet émis. Le dernier argument est l'adresse du groups sous forme numérique.<br />
<br />
Voici le code complet du programme. Le port utilisé (ligne 10) est naturellement celui de <tt>in2multi6</tt>.<br />
<br />
<br />
1| #include <sys/types.h><br />
2| #include <sys/socket.h><br />
3| #include <netinet/in.h><br />
4| #include <arpa/inet.h><br />
5| #include <stdio.h><br />
6| #include <unistd.h><br />
7| <br />
8| struct sockaddr_in6 sin6;<br />
9| <br />
10| #define IPPORT 54321<br />
11| <br />
12| void Perror(const char *c)<br />
13| {<br />
14| perror(c);<br />
15| exit(1);<br />
16| }<br />
17| <br />
18| void Usage ()<br />
19| {<br />
20| fprintf(stderr, "%s\n", "Usage: in2multi6 [-i interface][-h hop][-l loop] addr");<br />
21| exit(1);<br />
22| }<br />
23| <br />
24| main(int argc, char **argv)<br />
25| {<br />
26| u_int hops = 1, /* as defined in rfc2553 */<br />
27| loop = 1, /* as defined in rfc2553 */<br />
28| ifi = 0;<br />
29| int s, cc, ch;<br />
30| char buf[1024];<br />
31| struct in6_addr addr6;<br />
32| extern char *optarg;<br />
33| extern int optind;<br />
34| <br />
35| addr6 = in6addr_any;<br />
36| if ((s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP)) < 0)<br />
37| Perror("socket");<br />
38| while ((ch = getopt(argc, argv, "h:t:l:i:")) != -1)<br />
39| switch(ch) {<br />
40| case 'h':<br />
41| case 't':<br />
42| hops = atoi(optarg);<br />
43| break;<br />
44| case 'l':<br />
45| loop = atoi(optarg);<br />
46| break;<br />
47| case 'i':<br />
48| if (sscanf(optarg, "%u\0", &ifi) != 1) {<br />
49| ifi = if_nametoindex(optarg);<br />
50| if (ifi == 0)<br />
51| Usage();<br />
52| }<br />
53| break;<br />
54| default:<br />
55| Usage();<br />
56| }<br />
57| argc -= optind;<br />
58| argv += optind;<br />
59| if (argc != 1 || inet_pton(AF_INET6, *argv, &addr6) <= 0)<br />
60| Usage();<br />
61| if (setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_HOPS,<br />
62| &hops, sizeof(hops)) < 0)<br />
63| Perror("setsockopt IPV6_MULTICAST_HOPS");<br />
64| if (setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_LOOP,<br />
65| &loop, sizeof(loop)) < 0)<br />
66| Perror("setsockopt IPV6_MULTICAST_LOOP");<br />
67| if (ifi && (setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_IF,<br />
68| &ifi, sizeof(u_int)) < 0))<br />
69| Perror("setsockopt IPV6_MULTICAST_IF");<br />
70| <br />
71| #ifdef SIN6_LEN<br />
72| sin6.sin6_len = sizeof(sin6);<br />
73| #endif<br />
74| sin6.sin6_family = AF_INET6;<br />
75| sin6.sin6_addr = addr6;<br />
76| sin6.sin6_port = htons(54321);<br />
77| <br />
78| for (;;) {<br />
79| cc = read(0, buf, 1024);<br />
80| if (cc < 0)<br />
81| Perror("read file");<br />
82| if (cc == 0) {<br />
83| fprintf(stderr, ".\n", cc);<br />
84| exit (0);<br />
85| }<br />
86| if (sendto(s, buf, cc, 0,<br />
87| (struct sockaddr *)&sin6, sizeof(sin6)) < 0)<br />
88| Perror("sendto");<br />
89| fprintf(stderr, "-%d->\n", cc);<br />
90| }<br />
91| }<br />
{{suivi| mini-ping | mini-ping | Programmation avancée | Programmation avancée }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Mini-ping&diff=2958Mini-ping2006-02-27T11:04:21Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| Exemple de client/serveur TCP | Exemple de client/serveur TCP | Utilisation du multicast | Utilisation du multicast }}<br />
==Description==<br />
<br />
La commande proposée est une version très simplifiée de <tt>ping6</tt>. Néanmoins, cela permettra de comprendre l'essentiel du fonctionnement de cette commande. Son principe est le suivant, on émet un paquet ICMPv6 du type ECHO_REQUEST et on active une temporisation. Si, le délai étant expiré, on n'a pas reçu de paquet ICMPv6 de type ECHO_REPLY en provenance de la machine cible, on imprime un message d'erreur. Dans le cas contraire, on imprime le nom de la machine émettrice de l'ECHO_REPLY. Par exemple, si le nom donné à cette commande est one_ping6 :<br />
<br />
$ '''one_ping6 peirce'''<br />
Sending ECHO REQUEST to: peirce.ipv6.logique.jussieu.fr<br />
Waiting for answer (timeout = 5s)...<br />
Got answer from 2001:660:101:201:200:f8ff:fe31:1942 (seq = 0)<br />
$<br />
<br />
Remarque : ICMP étant un protocole non fiable, il peut arriver qu'un premier paquet soit perdu, par exemple à cause du temps passé à exécuter le protocole de "recherche de voisins". Il suffit en général de relancer la commande pour que la réponse apparaisse la seconde fois.<br />
<br />
one_ping6 accepte les options suivantes :<br />
<br />
* <tt>-d données</tt>. Ces données seront incluses dans le paquet ECHO_REQUEST.<br />
* <tt>-s numéro de séquence</tt>. La valeur défaut est zéro.<br />
* <tt>-t durée de la temporisation</tt>. La valeur par défaut est fixée lors de la compilation via la macro-définition TIMEOUT.<br />
<br />
Par exemple,<br />
<br />
$ '''one_ping6 -d 'Un petit essai' -s 12 -t 3 peirce'''<br />
Sending ECHO REQUEST to: peirce.ipv6.logique.jussieu.fr<br />
Waiting for answer (timeout = 3s)...<br />
Got answer from 2001:660:101:201:200:f8ff:fe31:1942 (seq = 12)<br />
with data [<br />
Un petit essai<br />
] (end of data)<br />
$<br />
<br />
Les sources de ce programme se composent de trois fichiers : le programme principal, le source de la fonction assurant l'émission du paquet ECHO_REQUEST et le source de la fonction ayant en charge la gestion de la temporisation et la réception du paquet ECHO_REPLY.<br />
<br />
==Envoi du paquet ECHO_REQUEST==<br />
<br />
Rappelons tout d'abord que le nouveau protocole ICMPv6 est une refonte presque complète d'ICMP (sur IPv4). Néanmoins, le format des paquets ECHO_REQUEST et ECHO_REPLY est inchangé excepté la valeur du champ type (cf. figure format d'un message ICMPv6 demande et réponse d'écho).<br />
<br />
[[image:CS43.gif]]<br />
<br />
La préparation d'un paquet ECHO_REQUEST est similaire en ICMP(v4) ou ICMPv6. La seule différence est que le calcul du checksum n'est maintenant plus à la charge du programmeur mais effectué par le noyau. Plus précisément, ainsi qu'il est spécifié dans l'API "avancée", pour toutes les sockets de type <tt>SOCK_RAW</tt> et de protocole <tt>IPPROTO_ICMPV6</tt>, c'est le noyau qui doit calculer le checksum des paquets ICMPv6 sortants (dans le cas des Linux anciens, il faut activer le calcul du checksum, comme on le voit en lignes 81 à 95 du fichier [[#progprinc|ping.c]] ).<br />
<br />
Le paquet ICMPv6 de type ECHO_REQUEST, étant ainsi constitué, on l'expédie, via la primitive sendto à la machine cible.<br />
<br />
<br />
1| #include <stdio.h><br />
2| #include <string.h><br />
3| #include <sys/types.h><br />
4| #include <sys/socket.h><br />
5| #include <netinet/in.h><br />
6| #include <netinet/ip6.h><br />
7| #include <netinet/icmp6.h><br />
8| #include <arpa/inet.h><br />
9| #include <netdb.h><br />
10| <br />
11| #ifndef MAX_DATALEN<br />
12| #define MAX_DATALEN (1280 - sizeof(struct ip6_hdr) - sizeof(struct icmp6_hdr))<br />
13| #endif<br />
14| <br />
15| static u_char buf[sizeof(struct icmp6_hdr) + MAX_DATALEN]; <br />
16| <br />
17| int send_echo_request6(int sock, struct sockaddr_in6 *dst, uint16_t id,<br />
18| uint16_t seq, char *opt_data, int opt_data_size)<br />
19| {<br />
20| int noc, icmp_pkt_size = sizeof(struct icmp6_hdr);<br />
21| struct icmp6_hdr *icmp; <br />
22| <br />
23| if (opt_data && opt_data_size > MAX_DATALEN) {<br />
24| fprintf(stderr, "send_echo_request6: too much data (%d > %d)\n",<br />
25| opt_data_size, MAX_DATALEN);<br />
26| return -1;<br />
27| }<br />
28| <br />
29| memset((void *) buf, 0, sizeof(buf));<br />
30| icmp = (struct icmp6_hdr *) buf;<br />
31| icmp->icmp6_type = ICMP6_ECHO_REQUEST;<br />
32| icmp->icmp6_id = id;<br />
33| icmp->icmp6_seq = seq;<br />
34| if (opt_data) {<br />
35| memcpy(buf + sizeof(struct icmp6_hdr), opt_data, opt_data_size);<br />
36| icmp_pkt_size += opt_data_size;<br />
37| } <br />
39| noc = sendto(sock, (char *) icmp, icmp_pkt_size, 0,<br />
39| (struct sockaddr *) dst, sizeof(struct sockaddr_in6));<br />
40| if (noc < 0) {<br />
41| perror("send_echo_request6: sendto");<br />
42| return -1;<br />
43| }<br />
44| if (noc != icmp_pkt_size) {<br />
45| fprintf(stderr, "send_echo_request6: wrote %d bytes, ret=%d\n",<br />
46| icmp_pkt_size, noc);<br />
47| return -1;<br />
48| }<br />
49| return 0;<br />
50| }<br />
<br />
Une dernière remarque avant de clore cette section. On a vu que l'on pouvait inclure des données dans le paquet ICMPv6 émis. La taille maximale de celles-ci a été choisie (ligne 12) pour que les paquets ne soient jamais fragmentés (le protocole IPv6 exigeant une taille de paquet minimale de 1280 octets, en-têtes comprises). Une taille plus grande serait possible, les paquets ICMP ECHO pouvant parfaitement être fragmentés.<br />
<br />
==La réception du paquet ECHO_REPLY==<br />
<br />
C'est la fonction wait_for_echo_reply6 qui gère la réception du paquet ECHO_REPLY. Cette fonction tout d'abord (lignes 32 à 35) utilise le mécanisme de filtrage des paquets ICMPv6, mécanisme défini dans l'API "étendue", afin que seuls les paquets ICMPv6 de type ECHO_REPLY soient reçus sur la socket d'écoute.<br />
<br />
On trouve ensuite une boucle sans fin dont on sort soit sur réception du signal SIGALRM (armé juste avant l'entrée de la boucle à la ligne 36), c'est-à-dire lorsque le délai de temporisation (argument timeout) est expiré, soit lorsque la fonction <tt>recv_icmp_pkt</tt>, qui analyse tous les paquets ICMPv6 de type ECHO_REPLY reçus sur la socket d'écoute (argument sock) par l'émetteur, retourne 0, c'est-à-dire lorsque le paquet ECHO_REPLY en provenance de la machine cible a été détecté.<br />
<br />
<br />
1| #include <stdio.h><br />
2| #include <unistd.h><br />
3| #include <string.h><br />
4| #include <sys/types.h><br />
5| #include <sys/socket.h><br />
6| #include <netinet/in.h><br />
7| #include <netinet/ip6.h><br />
8| #include <netinet/icmp6.h><br />
9| #include <arpa/inet.h><br />
10| #include <errno.h><br />
11| #include <signal.h><br />
12| #include <setjmp.h><br />
13| <br />
14| #ifndef MAX_DATALEN<br />
15| #define MAX_DATALEN (1280 - sizeof(struct ip6_hdr) - sizeof(struct icmp6_hdr))<br />
16| #endif<br />
17| <br />
18| static void on_timeout(int);<br />
19| static int recv_icmp_pkt(int, struct sockaddr_in6 *, uint16_t, uint16_t);<br />
20| <br />
21| static u_char buf[sizeof(struct icmp6_hdr) + MAX_DATALEN];<br />
22| static jmp_buf j_buf;<br />
23| <br />
24| void wait_for_echo_reply6(int sock, struct sockaddr_in6 *from, uint16_t id,<br />
25| uint16_t seq, int timeout)<br />
26| {<br />
27| struct icmp6_filter filter;<br />
28| char from_ascii[INET6_ADDRSTRLEN];<br />
29| <br />
30| inet_ntop(AF_INET6, &from->sin6_addr, from_ascii, INET6_ADDRSTRLEN);<br />
31| <br />
32| ICMP6_FILTER_SETBLOCKALL(&filter);<br />
33| ICMP6_FILTER_SETPASS(ICMP6_ECHO_REPLY, &filter);<br />
34| setsockopt(sock, IPPROTO_ICMPV6, ICMP6_FILTER, (const void *) &filter,<br />
35| sizeof(filter));<br />
36| signal(SIGALRM, on_timeout);<br />
37| alarm(timeout);<br />
38| for (;;) {<br />
39| int noc, from_len = sizeof(struct sockaddr_in6);<br />
40| <br />
41| if (setjmp(j_buf) == SIGALRM) {<br />
42| fprintf(stderr, "No answer from %s\n", from_ascii);<br />
43| break;<br />
44| }<br />
45| noc = recvfrom(sock, buf, sizeof(buf), 0,<br />
46| (struct sockaddr *) from, &from_len);<br />
47| if (noc < 0) {<br />
48| if (errno == EINTR)<br />
49| continue;<br />
50| perror("wait_for_echo_reply6: recvfrom");<br />
51| continue;<br />
52| }<br />
53| if (recv_icmp_pkt(noc, from, id, seq) == 0)<br />
54| break;<br />
55| }<br />
56| alarm(0);<br />
57| signal(SIGALRM, SIG_DFL);<br />
58| return;<br />
59| }<br />
60| <br />
61| static void on_timeout(int sig)<br />
62| {<br />
63| longjmp(j_buf, sig);<br />
64| } <br />
<br />
Contrairement à ce qui se passait en IPv4, l'entête IPv6 n'est pas incluse lors de la réception d'un paquet ICMPv6 (sauf si l'option I<tt>P_HDRINCL</tt> est positionnée). Ainsi dans la fonction <tt>recv_icmp_pkt</tt>, on commence directement par tester le champ identificateur et le numéro de séquence (lignes 84 et 85). Si ce test a été passé avec succès, c'est-à-dire que l'on a bien reçu le paquet attendu, la fonction <tt>recv_icmp_pkt</tt> retourne <tt>0</tt> après avoir, s'il y en a, imprimé les données incluses dans le paquet. Dans le cas contraire, la valeur retournée est 1.<br />
<br />
<br />
65| static int recv_icmp_pkt(int noc, struct sockaddr_in6 *from, uint16_t id,<br />
66| uint16_t seq)<br />
67| {<br />
68| int opt_data_size;<br />
69| char from_ascii[INET6_ADDRSTRLEN];<br />
70| struct icmp6_hdr *icmp;<br />
71| <br />
72| if (inet_ntop(AF_INET6, &from->sin6_addr, from_ascii,<br />
73| INET6_ADDRSTRLEN) == NULL) {<br />
74| perror("inet_ntop");<br />
75| return -1;<br />
76| }<br />
77| if (noc < sizeof(struct icmp6_hdr)) {<br />
78| fprintf(stderr, "recv_icmp_pkt: packet too short from %s\n",<br />
79| from_ascii);<br />
80| return -1;<br />
81| }<br />
82| opt_data_size = noc - sizeof(struct icmp6_hdr);<br />
83| icmp = (struct icmp6_hdr *) buf;<br />
84| if (icmp->icmp6_id != id || icmp->icmp6_seq != seq)<br />
85| return 1;<br />
86| fprintf(stdout, "Got answer from %s (seq = %d)\n", from_ascii, seq);<br />
87| if (opt_data_size > 0) {<br />
88| fprintf(stdout, "with data [\n");<br />
89| fflush(stdout);<br />
90| if (opt_data_size > MAX_DATALEN) {<br />
91| fprintf(stderr,<br />
92| "recv_icmp_pkt: received too much data from %s\n",<br />
93| from_ascii);<br />
94| }<br />
95| else<br />
96| write(1, (char *) icmp + sizeof(struct icmp6_hdr), opt_data_size);<br />
97| fprintf(stdout, "\n] (end of data)\n");<br />
98| }<br />
99| return 0;<br />
100| }<br />
<br />
==<div id="progprinc">Programme principal</div>==<br />
<br />
Le programme principal ne présente pas de difficulté particulière puisqu'il est une application directe des fonctions décrites dans les deux sections précédentes.<br />
<br />
La première partie est triviale : elle concerne le traitement des (éventuelles) options.<br />
<br />
<br />
1| #include <stdio.h><br />
2| #include <stdlib.h><br />
3| #include <unistd.h><br />
4| #include <string.h><br />
5| #include <sys/socket.h><br />
6| #include <netinet/in.h><br />
7| #include <netinet/icmp6.h><br />
8| #include <arpa/inet.h><br />
9| #include <netdb.h><br />
10| #ifdef __linux__<br />
11| #include <linux/version.h><br />
12| #if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,19)<br />
13| #define LINUX_CKSUM_CALCUL_EXPLICITE<br />
14| #endif<br />
15| #endif<br />
16| <br />
17| #ifndef TIMEOUT<br />
18| #define TIMEOUT 5<br />
19| #endif<br />
20| <br />
21| extern int send_echo_request6(int, struct sockaddr_in6 *, uint16_t,<br />
22| uint16_t, char *, int);<br />
23| extern void wait_for_echo_reply6(int, struct sockaddr_in6 *, uint16_t,<br />
24| uint16_t, int);<br />
25| <br />
26| static void usage(char *);<br />
27| <br />
28| int main(int argc, char **argv)<br />
29| {<br />
30| int sock, timeout = TIMEOUT, a, ecode;<br />
31| char *opt_data = NULL, *dst_ascii;<br />
32| int opt_data_size = 0;<br />
33| uint16_t id, seq = 0;<br />
34| struct sockaddr_in6 *dst;<br />
35| struct addrinfo *res;<br />
36| struct addrinfo hints = {<br />
37| AI_CANONNAME,<br />
38| PF_INET6,<br />
39| SOCK_RAW,<br />
40| IPPROTO_ICMPV6,<br />
41| 0,<br />
42| NULL,<br />
43| NULL,<br />
44| NULL<br />
45| };<br />
46| <br />
47| while((a = getopt(argc, argv, "d:s:t:")) != EOF)<br />
48| switch(a) {<br />
49| case 'd':<br />
50| opt_data = optarg;<br />
51| opt_data_size = strlen(optarg) + 1;<br />
52| break;<br />
53| case 's':<br />
54| seq = (uint16_t) atoi(optarg);<br />
55| break;<br />
56| case 't':<br />
57| timeout = atoi(optarg);<br />
58| break;<br />
59| default:<br />
60| usage(*argv);<br />
61| }<br />
62| argc -= optind;<br />
63| if (argc != 1)<br />
64| usage(*argv);<br />
65| argv += optind; <br />
<br />
Ensuite c'est la préparation de l'adresse de la socket distante, opération qui est devenue maintenant familière. Noter que l'on a affecté au champ <tt>ai_family</tt> de la structure <tt>hints</tt> la valeur <tt>PF_INET6</tt> lors de sa déclaration (ligne 38) : on doit s'assurer que la machine cible est une machine IPv6 (il n'existe pas de mode double pile avec utilisation d'[[Autres types d'adresses#mappee|adresse IPv4 mappé]] pour le protocole ICMP, car celui-ci a fortement changé entre IPv4 et IPv6). On s'est interdit des adresses destination de type multicast (lignes 73 à 76) car, comme l'on ne traite qu'un paquet en réception, cela n'aurait guère d'intérêt.<br />
<br />
On crée la socket qui servira à l'émission du paquet ECHO_REQUEST et à la réception du paquet ECHO_REPLY en provenance de la machine cible.<br />
<br />
À la ligne 96, la valeur du champ identificateur du paquet ICMPv6 est calculée en fonction du numéro de processus en prenant les 16 premiers bits. C'est une technique sûre (et simple) quant à la garantie de l'unicité de l'identificateur. Enfin le paquet ECHO_REQUEST est émis (<tt>send_echo_request6</tt>) puis on attend la réponse éventuelle (<tt>wait_for_echo_reply6</tt>).<br />
<br />
<br />
66| ecode = getaddrinfo(*argv, NULL, &hints, &res);<br />
67| if (ecode) {<br />
68| fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(ecode));<br />
69| exit(1);<br />
70| }<br />
71| dst_ascii = res->ai_canonname ? res->ai_canonname : *argv;<br />
72| dst = (struct sockaddr_in6 *) res->ai_addr;<br />
73| if (IN6_IS_ADDR_MULTICAST(&dst->sin6_addr)) {<br />
74| fprintf(stderr, "%s multicast address not supported\n", dst_ascii);<br />
75| exit(1);<br />
76| }<br />
77| if ((sock = socket(res->ai_family, res->ai_socktype, res->ai_protocol)) < 0) {<br />
78| perror("socket (RAW)");<br />
79| exit(1);<br />
80| }<br />
81| #ifdef LINUX_CKSUM_CALCUL_EXPLICITE<br />
82| {<br />
83| /*<br />
84| * Pour linux avant 2.4.19, il faut demander le calcul des checksums<br />
85| * sur les sockets raw, meme pour des paquets icmpv6<br />
86| */<br />
87| #define OFFSETOF(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)<br />
88| int off = OFFSETOF(struct icmp6_hdr, icmp6_cksum);<br />
89| <br />
90| if (setsockopt(sock, SOL_RAW, IPV6_CHECKSUM, &off, sizeof off) < 0) {<br />
91| perror("setsockopt (IPV6_CHECKSUM)");<br />
92| exit(1);<br />
93| }<br />
94| }<br />
95| #endif<br />
96| id = (uint16_t) (getpid() & 0xffff);<br />
97| fprintf(stdout, "Sending ECHO REQUEST to: %s\n", dst_ascii);<br />
98| if (send_echo_request6(sock, dst, id, seq, opt_data,<br />
99| opt_data_size) < 0)<br />
100| exit(1);<br />
101| fprintf(stdout, "Waiting for answer (timeout = %ds)...\n", timeout);<br />
102| wait_for_echo_reply6(sock, dst, id, seq, timeout);<br />
103| close(sock);<br />
104| exit(0);<br />
105| }<br />
106| <br />
107| static void usage(char *s)<br />
108| {<br />
109| fprintf(stderr, "Usage: %s [-d data] [-s seq] [-t timeout] host | addr\n", s);<br />
110| exit(1);<br />
111| }<br />
{{suivi| Exemple de client/serveur TCP | Exemple de client/serveur TCP | Utilisation du multicast | Utilisation du multicast }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Exemple_de_client/serveur_TCP&diff=2957Exemple de client/serveur TCP2006-02-27T11:02:26Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| La commande haah (host-address-address-host) | La commande haah (host-address-address-host) | mini-ping | mini-ping }}<br />
==Vue d'ensemble==<br />
<br />
Le client/serveur choisi est particulièrement simple quant à sa fonction de service, de façon à privilégier l'aspect réseau dans la présentation. Il calcule le nombre d'utilisateurs connectés sur une machine donnée. Plus précisément :<br />
<br />
$ '''nbus bernays'''<br />
3 user(s) logged on bernays<br />
$<br />
<br />
Il se compose de cinq fichiers sources :<br />
<br />
* <tt>nbus.h</tt> le fichier d'en-tête commun aux fichiers sources du client et du serveur<br />
* <tt>nbus.c</tt> le fichier source principal du client<br />
* <tt>open_conn.c</tt> le fichier source qui gère les connexions du côté client<br />
* <tt>nbusd.c</tt> le fichier source du serveur propre au service<br />
* <tt>serv_daemon.c</tt> le fichier source qui gère les connexions du côté serveur<br />
<br />
Le client, prend en argument un nom de machine (ou une adresse numérique), le convertit en une adresse IPv4 ou IPv6 et ainsi envoie ses requêtes à un serveur.<br />
<br />
Le fichier source du serveur, selon les options de compilation, génère un code IPv6 ou un code IPv4. Dans le premier cas, le serveur est à même de satisfaire les requêtes d'un client IPv6 mais aussi d'un client IPv4. Dans le second cas, seuls les clients IPv4 pourront être pris en compte.<br />
<br />
Il faut noter qu'il existe deux modes de fonctionnement pour une machine à double pile IPv4 et IPv6, la figure Le client/serveur nbus résume la situation. Soit les espaces d'adresses sont disjoints, et dans ce cas il faut deux serveurs, un qui écoute les requêtes IPv4 (<tt>nbus4d</tt>) et un qui écoute les requêtes IPv6 (<tt>nbus6d</tt>) (ou un seul serveur, <tt>nbusd</tt>, avec deux sockets IPv4 et IPv6 séparées). Soit l'espace d'adresse IPv4 est inclus dans l'espace IPv6 et dans ce cas il suffit d'un serveur IPv6 (<tt>nbus6d</tt>) qui recevra les requêtes venant en IPv4 comme une requête IPv6 venant d'une adresse "IPv4 mappée".<br />
<br />
[[image:CS192.gif]]<br />
<br />
Suivant les systèmes le mode de fonctionnement est prédéfini, configurable globalement dans le noyeau, ou configurable séparément pour chaque socket IPv6. Ainsi en FreeBSD le mode par défaut est "espace partagé" (choix modifiable par "<tt>sysctl -w net.inet6.ip6.v6only=1</tt>") et modifiable pour chaque socket, en précisant tcp4, tcp6 ou tcp46 dans le fichier de configuration d'inetd, ou en utilisant "<tt>setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY,&val)</tt>" dans le code du serveur.<br />
<br />
Deux mêmes programmes serveur ne peuvent s'exécuter en même temps sur une machine : chaque serveur réserve le port nbus (par un bind) et par suite si un serveur est lancé, tout autre serveur échouera avec une erreur "port en service" (<tt>EADDRINUSE</tt>). Cela peut être aussi vrai entre les deux types de serveurs, nbus4d et nbus6d sur une machine "double pile avec espace partagé", car les espaces de service TCP et UDP sont communs à IPv4 et IPv6 et un port en service l'est aussi bien en IPv4 qu'en IPv6 ; simplement si le port correspond à une socket <tt>PF_INET</tt>, une requête de connexion IPv6 sera rejetée avec une erreur "port inaccessible". Dans la réalité le comportement est plus complexe. Même en mode "double pile avec espace partagé", on peut avoir deux sockets, l'une PF_INET et l'autre PF_INET6, comme le montre le programme nbusd.<br />
<br />
Le code des différents serveurs est très semblable, le choix est fait en donnant une option à la compilation : <tt>nbusd</tt> par défaut, <tt>nbus4d</tt> si on ajoute l'option -DIPV4,et <tt>nbus6d</tt> si on ajoute l'option <tt>-DIPV6</tt>.<br />
<br />
Le fichier d'en-tête <tt>nbus.h</tt> ne contient que le nom du service correspondant.<br />
<br />
#define SERVICE "nbus"<br />
<br />
Ainsi doit-on trouver, par exemple, dans le fichier <tt>/etc/services</tt> des machines concernées, la ligne suivante :<br />
<br />
nbus 20000/tcp<br />
<br />
Le programme client nbus établit tout d'abord une connexion TCP avec la machine cible (donnée en argument à <tt>nbus</tt>) via la fonction <tt>open_conn</tt> (cette fonction sera décrite ci-après). Il lit ensuite un entier court, résultat du calcul du nombre d'utilisateurs connectés sur la machine cible, puis l'imprime.<br />
<br />
On notera la présence de la macro <tt>ntohs</tt> rendue nécessaire du fait des représentations différentes des entiers selon les machines.<br />
<br />
1| #include <stdio.h><br />
2| #include <unistd.h><br />
3| <br />
4| #include "nbus.h"<br />
5| <br />
6| extern open_conn(char *, char *);<br />
7| <br />
8| int main(int argc, char **argv)<br />
9| {<br />
10| int sock;<br />
11| short nu; <br />
12| <br />
13| if (argc != 2) {<br />
14| fprintf(stderr, "Usage: %s host\n", argv[0]);<br />
15| exit(1);<br />
16| }<br />
17| if ((sock = open_conn(argv[1], SERVICE)) < 0)<br />
18| exit(1);<br />
19| read(sock, (char *) &nu, sizeof(nu));<br />
20| nu = ntohs(nu);<br />
21| if (nu == -1) {<br />
22| fprintf(stderr, "Can't read \"utmp\" on %s\n", argv[1]);<br />
23| exit(1);<br />
24| }<br />
25| if (nu) {<br />
26| fprintf(stdout, "%d user(s) logged on %s\n", nu, argv[1]);<br />
27| exit(0);<br />
28| }<br />
29| fprintf(stdout, "Nobody on %s\n", argv[1]);<br />
30| exit(0);<br />
31| }<br />
<br />
Le serveur <tt>nbusd</tt>, quant à lui, lance en tâche de fond un processus "démon" qui exécutera la fonction de service nbus (lignes 28 à 60) à chaque requête d'un client. Ce processus démon est réalisé par la fonction <tt>serv_daemon</tt>.<br />
<br />
<br />
1| #include <stdio.h><br />
2| #include <unistd.h><br />
3| #include <fcntl.h><br />
4| #include <utmp.h><br />
5| #include <sys/socket.h> <br />
6| <br />
7| #include "nbus.h" <br />
8| <br />
9| <br />
10| #if defined(IPV6)<br />
11| #define FAMILY PF_INET6<br />
12| #elif defined(IPV4)<br />
13| #define FAMILY PF_INET<br />
14| #else<br />
15| #define FAMILY PF_UNSPEC<br />
16| #endif<br />
17| <br />
18| extern serv_daemon(int, char *, void (*)(int), char *);<br />
19| <br />
20| void nbus(int);<br />
21| <br />
22| int main(void)<br />
23| {<br />
24| serv_daemon(FAMILY, SERVICE, nbus, NULL);<br />
25| exit(0);<br />
26| }<br />
27| <br />
28| void nbus(int sock)<br />
29| {<br />
30| short nu = -1;<br />
31| #ifdef USER_PROCESS /* Solaris/Linux, use getutent */<br />
32| struct utmp *up;<br />
33| <br />
34| up = getutent();<br />
35| if (up != NULL) {<br />
36| for (nu = 0; up != NULL; up = getutent())<br />
37| if (up->ut_type == USER_PROCESS)<br />
38| nu++;<br />
39| }<br />
40| endutent();<br />
41| #else /* *BSD read directly utmp file */<br />
42| #ifndef UTMP<br />
43| #define UTMP "/var/run/utmp" /* for FreeBSD/NetBSD */<br />
44| #endif<br />
45| <br />
46| struct utmp ut;<br />
47| int fd;<br />
48| <br />
49| if ((fd = open(UTMP, O_RDONLY)) >= 0) {<br />
50| nu = 0;<br />
51| while (read(fd, (char *) &ut, sizeof(ut)) == sizeof(ut))<br />
52| if (ut.ut_name[0])<br />
53| nu++;<br />
54| }<br />
55| close(fd);<br />
56| #endif<br />
57| nu = htons(nu);<br />
58| write(sock, (char *) &nu, sizeof(nu));<br />
59| return;<br />
60| }<br />
<br />
==L'établissement d'une connexion TCP, côté client==<br />
<br />
Comme on l'a vu plus haut dans le code du client <tt>nbus.c</tt>, l'établissement de la connexion TCP se fait au moyen de la fonction <tt>open_conn</tt>. Cette fonction prend en premier argument le nom de la machine avec laquelle on va établir la connexion TCP et en deuxième argument le nom du service tel qu'il apparaît dans le fichier <tt>/etc/services</tt>. La valeur retournée par <tt>open_conn</tt> est soit <tt>-1</tt> en cas d'erreur, soit le descripteur associé à la socket réalisant la connexion. La figure Algorithme du client visualise l'algorithme employé.<br />
<br />
[[image:CS193.gif]]<br />
<br />
La première étape sera la construction de l'adresse de la socket distante, ceci via la primitive getaddrinfo. On remarquera que le champ <tt>ai_family</tt> de la structure <tt>hints</tt> a été initialisé à la valeur <tt>PF_UNSPEC</tt>, ce qui signifie que, suivant que l'on donne en argument à la commande nbus un nom de machine (ou une adresse numérique) IPv4 ou IPv6, on travaillera avec une socket soit dans la famille des protocoles <tt>PF_INET</tt>, soit dans la famille des protocoles <tt>PF_INET6</tt>. Si on avait fait le choix de forcer la famille des protocoles à la valeur <tt>PF_INET6</tt>, il aurait fallu initialiser les champs <tt>ai_flags</tt> et <tt>ai_family</tt> respectivement aux valeurs <tt>AI_V4MAPPED</tt> et <tt>PF_INET6</tt> (les adresses IPv4 seraient dans ce cas "mappées"). Si, comme dans l'exemple proposé, on ne fait pas ce choix, on notera qu'il n'y a aucune différence entre le code IPv4 et le code IPv6.<br />
<br />
Ensuite, après avoir créé une socket, on la connecte au serveur de la machine cible (primitive <tt>connect</tt>). Là encore, le code est le même pour IPv4 et IPv6. Remarquons que <tt>getaddrinfo</tt> peut avoir rendu plusieurs valeurs. Un programme plus évolué devrait essayer de se connecter à chaque adresse rendue jusqu'à obtenir une réponse.<br />
<br />
<br />
1| #include <stdio.h><br />
2| #include <unistd.h><br />
3| #include <sys/socket.h><br />
4| #include <netdb.h><br />
5| <br />
6| int open_conn(char *host, char *serv)<br />
7| {<br />
8| int sock, ecode;<br />
9| struct addrinfo *res;<br />
10| struct addrinfo hints = {<br />
11| 0,<br />
12| PF_UNSPEC,<br />
13| SOCK_STREAM,<br />
14| 0,<br />
15| 0,<br />
16| NULL,<br />
17| NULL,<br />
18| NULL<br />
19| };<br />
20| <br />
21| ecode = getaddrinfo(host, serv, &hints, &res);<br />
22| <br />
23| if (ecode) {<br />
24| fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(ecode));<br />
25| exit(1);<br />
26| }<br />
27| <br />
28| if ((sock = socket(res->ai_family, res->ai_socktype, res->ai_protocol)) < 0) {<br />
29| freeaddrinfo(res);<br />
30| perror("socket");<br />
31| return -1;<br />
32| }<br />
33| <br />
34| if (connect(sock, res->ai_addr, res->ai_addrlen) < 0) {<br />
35| close(sock);<br />
36| freeaddrinfo(res);<br />
37| perror("connect");<br />
38| return -1;<br />
39| }<br />
40| freeaddrinfo(res);<br />
41| return sock;<br />
42| }<br />
<br />
==Le serveur==<br />
<br />
Le serveur proprement dit est réalisé par une unique fonction. C'est la fonction <tt>serv_daemon</tt> qui a quatre arguments. Le premier est la famille d'adresse gérée, <tt>PF_INET</tt> ou <tt>PF_INET6</tt>, ou <tt>PF_UNSPEC</tt> pour écouter dans les deux familles. Le deuxième est, comme dans le cas de <tt>open_conn</tt>, le nom du service tel qu'il apparaît dans le fichier <tt>/etc/services</tt>. Le troisième argument est un pointeur vers la fonction de service dont le type <tt>(int(*)(void))</tt> sera commenté ultérieurement. Enfin le dernier argument est le nom passé au démon <tt>syslogd</tt> lors de l'impression des messages d'erreur [[(ligne See )]]. Si le dernier argument est le pointeur nul, ce nom est par défaut le nom du service. Un aperçu du déroulement de la fonction <tt>serv_daemon</tt> est donné par la figure Algorithme du serveur.<br />
<br />
[[image:CS194.gif]]<br />
<br />
<br />
1| #include <stdio.h><br />
2| #include <stdlib.h><br />
3| #include <unistd.h><br />
4| #include <errno.h><br />
5| #include <sys/socket.h><br />
6| #include <netdb.h><br />
7| #include <signal.h><br />
8| #include <syslog.h><br />
9| #include <sys/select.h><br />
10| #include <sys/wait.h><br />
11| <br />
12| static void reap_child(int); <br />
13| <br />
14| void serv_daemon(int family, char *serv, void (*serv_funct)(int), char *serv_logname)<br />
15| {<br />
16| int sock[2], ecode, n = 0;<br />
17| struct addrinfo *res, *rres, hints;<br />
18| <br />
19| memset(&hints, 0, sizeof hints) ;<br />
20| hints.ai_flags = AI_PASSIVE;<br />
21| hints.ai_socktype = SOCK_STREAM;<br />
22| hints.ai_family = family;<br />
23| ecode = getaddrinfo(NULL, serv, &hints, &rres);<br />
24| if (ecode) {<br />
25| fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(ecode));<br />
26| exit(1);<br />
27| }<br />
28| for (res = rres; res; res = res->ai_next) {<br />
29| if (n == 2) { /* au plus 2 : anyaddr PF_INET et anyaddr PF_INET6 */<br />
30| fprintf(stderr, "erreur interne: trop d'adresses\n");<br />
31| exit(1);<br />
32| }<br />
33| sock[n] = socket(res->ai_family, res->ai_socktype, res->ai_protocol);<br />
34| if (sock[n] < 0) {<br />
35| perror("socket");<br />
36| exit(1);<br />
37| }<br />
38| if (bind(sock[n], res->ai_addr, res->ai_addrlen) < 0) {<br />
39| perror("bind");<br />
40| exit(1);<br />
41| }<br />
42| listen(sock[n], SOMAXCONN);<br />
43| n++;<br />
44| #ifdef __linux__<br />
45| /* En Linux, utiliser seulement la premiere<br />
46| * reponse, sinon on a un conflit sur bind */<br />
47| break;<br />
48| #endif<br />
49| }<br />
50| freeaddrinfo(rres);<br />
<br />
<br />
La première étape consiste en la préparation de l'adresse de la socket d'écoute du serveur en faisant appel, comme d'habitude, à la primitive <tt>getaddrinfo</tt>. Comme il s'agit d'une socket d'écoute, le champ <tt>ai_flags</tt> de la structure <tt>hints</tt> a été initialisé à la valeur <tt>AI_PASSIVE</tt> tandis que le champ <tt>ai_family</tt> de cette même structure a lui été initialisé à la valeur passé en argument à l'appel.<br />
<br />
Pour chaque réponse de getaddrinfo (une seule si la famille est définie, deux si la famille est <tt>PF_UNSPEC</tt>), on crée une socket d'écoute, puis effectue son attachement en faisant appel à la primitive <tt>bind</tt>. La socket d'écoute créée et attachée à une adresse, le serveur doit signifier au système qu'il est prêt à accepter les demandes de connexions. C'est l'objet de la primitive listen dont le deuxième argument <tt>SOMAXCONN</tt> (macro-définition que l'on trouve dans le fichier <tt>sys/socket.h</tt>) est le nombre maximal de connexions pendantes.<br />
<br />
Dans les lignes qui suivent (51 à 58), le processus est détaché du terminal de contrôle et est lancé en tâche de fond (processus "démon"), sauf en Solaris, le code étant trop différent, si le fichier source n'est pas compilé avec l'option <tt>-DDEBUG</tt> (dans le cas contraire, cela peut être bien utile lors de la phase de mise au point).<br />
<br />
<br />
51| #ifndef DEBUG<br />
52| #ifndef sun /* no daemon function in Solaris */<br />
53| if (daemon(0, 0) < 0) {<br />
54| perror("daemon");<br />
55| exit(1);<br />
56| }<br />
57| #endif<br />
58| #endif <br />
<br />
Dans la boucle sans fin [[(lignes See à See )]], on attend les connexions. Comme il peut y avoir plusieurs sockets actives, on utilise select [[(lignes See à See )]] pour attendre sur toutes les sockets ouverts. Au retour de <tt>select</tt>, on teste les sockets qui ont des connexions pendantes [[(ligne See )]], chaque connexion pendante dans la file d'attente associée à la socket d'écoute est extraite par le serveur et le circuit virtuel avec la socket du client est établi via la création d'une nouvelle socket. Ce travail est effectué par la primitive <tt>accept</tt> dont la valeur de retour est le descripteur d'E/S de la socket nouvellement créée. Ensuite le serveur crée un processus fils [[(ligne See )]] qui exécutera la fonction de service à laquelle on passe en argument la valeur retournée par la primitive accept.<br />
<br />
Il faut également veiller à ce que chaque processus fils, lors de sa terminaison (qui se produit à la fin de l'exécution de la fonction de service), ne devienne un processus "zombie", ce qui à terme peut provoquer une saturation de la table des processus. Pour cela il faut, sous UNIX BSD, capter le signal <tt>SIGCHLD</tt> [[(ligne See , fonction reap_child)]]. Notons qu'en SYSTEM V, on pourrait simplement ignorer le signal <tt>SIGCLD</tt>.<br />
<br />
<br />
59| signal(SIGCHLD, reap_child);<br />
60| if (!serv_logname)<br />
61| serv_logname = serv;<br />
62| openlog(serv_logname, LOG_PID | LOG_CONS, LOG_USER);<br />
63| for (;;) {<br />
64| int a, f, len, fd, m = -1;<br />
65| struct sockaddr_storage from;<br />
66| fd_set fdset;<br />
67| <br />
68| FD_ZERO(&fdset);<br />
69| for (fd = 0; fd < n; fd++) {<br />
70| if (m < sock[fd])<br />
71| m = sock[fd];<br />
72| FD_SET(sock[fd], &fdset);<br />
73| }<br />
74| ecode = select(m+1, &fdset, NULL, NULL, NULL);<br />
75| if (ecode < 0)<br />
76| syslog(LOG_ERR, "%s: select: %m", serv);<br />
77| if (ecode <= 0)<br />
78| break;<br />
79| for (fd = 0; fd < n; fd++) {<br />
80| if (FD_ISSET(sock[fd], &fdset)) {<br />
81| len = sizeof from;<br />
82| a = accept(sock[fd], (struct sockaddr *)&from, &len);<br />
83| if (a < 0) {<br />
84| if (errno != EINTR)<br />
85| syslog(LOG_ERR, "%s: accept: %m", serv);<br />
86| continue;<br />
87| }<br />
88| f = fork(); <br />
89| if (f == 0) {<br />
80| /* Par correction, il faudrait fermer dans le fils<br />
90| * tous les descripteurs hérités (i.e. tous sauf a) */<br />
91| serv_funct(a);<br />
92| exit(0);<br />
93| }<br />
94| close(a);<br />
95| if (f == -1) {<br />
96| syslog(LOG_ERR, "%s: fork: %m", serv);<br />
97| continue;<br />
98| }<br />
99| }<br />
100| }<br />
101| }<br />
102| }<br />
103| <br />
104| static void reap_child(int sig)<br />
105| {<br />
106| int status;<br />
107| <br />
108| while (wait3(&status, WNOHANG, NULL) > 0);<br />
109| }<br />
<br />
Une dernière remarque toujours à propos de la similitude des codes IPv6 et IPv4 : la seule différence dans le code de <tt>serv_daemon</tt> entre IPv4 et IPv6 est la valeur du premier argument, qui définit la famille d'adresses écoutée.<br />
{{suivi| La commande haah (host-address-address-host) | La commande haah (host-address-address-host) | mini-ping | mini-ping }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=La_commande_haah_(host-address-address-host)&diff=2956La commande haah (host-address-address-host)2006-02-27T10:53:51Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| Les primitives de conversion entre noms et adresses | Les primitives de conversion entre noms et adresses | Exemple de client/serveur TCP | Exemple de client/serveur TCP }}<br />
L'exemple proposé n'est autre qu'une sorte de nslookup (très) simplifié. Si par exemple on lui donne en argument une adresse numérique (IPv4 ou IPv6), il imprime le nom complètement qualifié correspondant lorsque la requête DNS aboutit. L'extrait de session qui suit illustre l'utilisation de cette commande.<br />
<br />
$ '''haah bernays'''<br />
Canonical name:<br />
bernays.ipv6.logique.jussieu.fr<br />
Adresses:<br />
2001:660:101:101:200:f8ff:fe31:17ec<br />
3ffe:304:101:1:200:f8ff:fe31:17ec<br />
$ '''haah 134.157.19.71'''<br />
Canonical name:<br />
bernays.logique.jussieu.fr<br />
Adresses:<br />
134.157.19.71<br />
$<br />
<br />
Le programme réalisant la commande <tt>haah</tt> ne présente aucune difficulté. C'est une simple application des primitives précédemment décrites.<br />
<br />
1| #include <stdio.h> </tt><br />
2|<br />
3| #include <string.h><br />
4| #include <errno.h><br />
5| #include <sys/types.h><br />
6| #include <sys/socket.h><br />
7| #include <netinet/in.h><br />
8| #include <netdb.h><br />
9| #include <arpa/inet.h><br />
10|<br />
11| <br />
12| int main(int argc, char **argv)<br />
13| {<br />
14| int ret;<br />
15| struct addrinfo *res, *ptr;<br />
16| struct addrinfo hints = {<br />
17| AI_CANONNAME,<br />
18| PF_UNSPEC,<br />
19| SOCK_STREAM,<br />
20| 0,<br />
21| 0,<br />
22| NULL,<br />
23| NULL,<br />
24| NULL<br />
25| };<br />
26| <br />
27| if (argc != 2) {<br />
28| fprintf(stderr, "%s: usage: %s host | addr.\n", *argv, *argv);<br />
29| exit(1);<br />
30| }<br />
31| ret = getaddrinfo(argv[1], NULL, &hints, &res);<br />
32| if (ret) {<br />
33| fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(ret));<br />
34| exit(1);<br />
35| }<br />
37| for (ptr = res; ptr; ptr = ptr->ai_next) {<br />
38| if (ptr->ai_canonname)<br />
39| fprintf(stdout,"Canonical name:\n%s\nAdresses:\n", ptr->ai_canonname);<br />
40| switch (ptr->ai_family) {<br />
41| case AF_INET:<br />
42| {<br />
43| char dst[INET_ADDRSTRLEN];<br />
44| struct in_addr *src = &((struct sockaddr_in *) ptr->ai_addr)->sin_addr;<br />
45| <br />
46| if(!inet_ntop(AF_INET, (const void *) src, dst, sizeof(dst))) {<br />
47| fprintf(stderr, "inet_ntop: %s\n", strerror(errno));<br />
48| break;<br />
49| }<br />
50| fprintf(stdout, "%s\n", dst);<br />
51| break;<br />
52| } <br />
53| case AF_INET6:<br />
54| {<br />
55| char dst[INET6_ADDRSTRLEN];<br />
56| struct in6_addr *src=&((struct sockaddr_in6 *)ptr->ai_addr)->sin6_addr;<br />
57| <br />
58| if (!inet_ntop(AF_INET6, (const void *) src, dst, sizeof(dst))) {<br />
59| fprintf(stderr, "inet_ntop: %s\n", strerror(errno));<br />
60| break;<br />
61| }<br />
62| fprintf(stdout, "%s\n", dst);<br />
63| break;<br />
64| }<br />
65| default:<br />
66| fprintf(stderr, "getaddrinfo: %s\n", strerror(EAFNOSUPPORT));<br />
67| }<br />
68| } <br />
69| freeaddrinfo(res);<br />
70| exit(0);<br />
71| }<br />
{{suivi| Les primitives de conversion entre noms et adresses | Les primitives de conversion entre noms et adresses | Exemple de client/serveur TCP | Exemple de client/serveur TCP }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Les_primitives_de_conversion_entre_noms_et_adresses&diff=2955Les primitives de conversion entre noms et adresses2006-02-27T10:52:02Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| L'interface socket | L'interface socket | La commande haah (host-address-address-host) | La commande haah (host-address-address-host) }}<br />
Les primitives <tt>gethostbyname</tt>, <tt>gethostbyaddr</tt>, <tt>getservbyname</tt> et <tt>getservbyport</tt> ont été remplacées par les deux primitives indépendantes de la famille d'adresses et normalisées par la RFC 3493 <tt>getaddrinfo</tt> et <tt>getnameinfo</tt> :<br />
<br />
#include <sys/socket.h><br />
#include <netdb.h><br />
<br />
int<br />
getaddrinfo(const char *nodename, const char *servname,<br />
const struct addrinfo *hints, struct addrinfo **res);<br />
<br />
void freeaddrinfo(struct addrinfo *res);<br />
<br />
const char *gai_strerror(int errcode);<br />
<br />
Le type <tt>struct addrinfo</tt> est défini comme suit :<br />
<br />
struct addrinfo {<br />
int ai_flags; /* AI_PASSIVE, AI_CANONNAME, ... */<br />
int ai_family; /* PF_xxx */<br />
int ai_socktype; /* SOCK_xxx */<br />
int ai_protocol; /* 0 ou IPPROTO_xxx pour IPv4 et IPv6 */<br />
size_t ai_addrlen; /* la taille de l'adresse binaire ai_addr */<br />
char *ai_canonname; /* le nom complétement qualifié */<br />
struct sockaddr *ai_addr; /* l'adresse binaire */<br />
struct addrinfo *ai_next; /* la structure suivante dans la liste chaînée */<br />
};<br />
<br />
<tt>getaddrinfo</tt> prend en entrée le nom d'une machine (<tt>nodename</tt>) et le nom d'un service (<tt>servname</tt>). S'il n'y a pas d'erreur, <tt>getaddrinfo</tt> rend 0 et res pointe sur une liste dynamiquement allouée de <tt>struct addrinfo</tt>. Chaque élément de cette liste contient la description et l'adresse d'une <tt>struct sockaddr</tt> initialisée pour fournir l'accès au service servname sur nodename. Les champs <tt>ai_family</tt>, <tt>ai_socktype</tt> et <tt>ai_protocol</tt> ont la valeur utilisable dans l'appel système socket.<br />
<br />
Lorsque la liste de résultat n'est plus nécessaire, la mémoire allouée peut être libérée par la primitive <tt>freeaddrinfo</tt>. En cas d'erreur, <tt>getaddrinfo</tt> rend un code d'erreur non nul qui peut être imprimé par la fonction <tt>gai_strerror</tt>.<br />
<br />
<tt>getaddrinfo</tt> peut donner des réponses de la famille d'adresses IPv4 ou IPv6, et des réponses pour les protocoles connectés ou non (<tt>ai_socktype</tt> peut valoir <tt>SOCK_DGRAM</tt> ou <tt>SOCK_STREAM</tt>). L'argument <tt>hints</tt> permet de choisir les réponses souhaitées. Un argument égal à <tt>NULL</tt> signifie que la liste des réponses doit contenir toutes les adresses et tous les protocoles. Sinon <tt>hints</tt> doit pointer sur une structure dont les champs <tt>ai_family</tt>, <tt>ai_socktype</tt> et <tt>ai_protocol</tt> définissent les types de résultat attendus. Une valeur de <tt>PF_UNSPEC</tt> du champ <tt>ai_family</tt> signifie que toutes les familles d'adresse (IPv4 et IPv6) sont admises, un <tt>0</tt> dans les champs <tt>ai_socktype</tt> (resp. <tt>ai_protocol</tt>) signifie que tous les types de socket (resp. protocole) sont admis. Le champ <tt>ai_flags</tt> permet de préciser des options supplémentaires.<br />
<br />
L'argument <tt>servname</tt> peut être le nom d'un service ou un nombre décimal. De même, l'argument <tt>nodename</tt> peut être un nom (au format DNS habituel) ou une adresse sous forme numérique IPv4 ou IPv6 (si <tt>ai_flags</tt> contient le bit <tt>AI_NUMERICHOST</tt>, <tt>nodename</tt> doit être sous forme numérique et aucun appel au serveur de nom n'est fait). De plus l'un ou l'autre des arguments <tt>servname</tt> et <tt>nodename</tt> peut être un pointeur <tt>NULL</tt>, mais pas tous les deux. Si <tt>servname</tt> est <tt>NULL</tt>, le champ <tt>port</tt> des réponses ne sera pas initialisé (il restera égal à <tt>0</tt>). Si <tt>nodename</tt> est <tt>NULL</tt>, l'adresse réseau dans les réponses est mis à "non initialisé" (<tt>INADDR_ANY</tt> en IPv4, <tt>IN6ADDR_ANY_INIT</tt> en IPv6) si <tt>ai_flags</tt> contient le bit <tt>AI_PASSIVE</tt>, et à l'adresse de "loopback" (<tt>INADDR_LOOPBACK</tt> ou <tt>IN6ADDR_LOOPBACK_INIT</tt>) sinon. Le cas <tt>AI_PASSIVE</tt> sert donc à obtenir des réponses utilisables par un programme serveur dans un ''bind'' pour recevoir des requêtes. Enfin si le bit <tt>AI_CANONNAME</tt> est positionné, le champ <tt>ai_canonname</tt> de la réponse contient le nom canonique de <tt>nodename</tt>.<br />
<br />
La primitive <tt>getnameinfo</tt> remplace les primitives <tt>gethostbyaddr</tt> et <tt>getservbyport</tt>. Elle effectue la traduction d'une adresse vers un nom :<br />
<br />
#include <sys/socket.h><br />
#include <netdb.h><br />
<br />
int getnameinfo(const struct sockaddr *sa, socklen_t salen,<br />
char *host, size_t hostlen,<br />
char *serv, size_t servlen, int flags);<br />
<br />
En entrée l'argument sa pointe vers une structure d'adresse générique (de type <tt>sockaddr_in</tt> ou <tt>sockaddr_in6</tt>) et salen contient sa longueur. Le champ <tt>host</tt> (resp. <tt>serv</tt>) doit pointer sur une zone de longueur <tt>hostlen</tt> (resp. <tt>servlen</tt>) caractères. <tt>getnameinfo</tt> retourne la valeur <tt>0</tt> si tout est correct et un code d'erreur non nul si une erreur est détectée. S'il n'y a pas d'erreur, le champ <tt>host</tt> (resp. <tt>serv</tt>) reçoit en sortie le nom de la machine (resp. du service) correspondant. Les arguments <tt>host</tt> et <tt>serv</tt> peuvent être <tt>NULL</tt> si la réponse est inutile. Deux constantes sont définies pour permettre de réserver des zones de réponses de longueur raisonnable :<br />
<br />
# define NI_MAXHOST 1025<br />
# define NI_MAXSERV 32<br />
<br />
Le champ <tt>flags</tt> permet de modifier la réponse : si flags contient le bit <tt>NI_NUMERICHOST</tt> (resp. <tt>NI_NUMERICSERV</tt>) la réponse sera l'adresse et non le nom de la machine (resp. le numéro et non le nom du service) ; si on ne sait pas trouver dans le serveur de nom le nom de la machine, <tt>getnameinfo</tt> rendra une erreur si le bit <tt>NI_NAMEREQD</tt> est positionné et l'adresse numérique sinon ; le bit <tt>NI_DGRAM</tt> indique si le service est sur UDP et non sur TCP.<br />
<br />
==<div id="conv">Les fonctions de conversion numériques d'adresses</div>==<br />
<br />
Elles sont l'analogue des fonctions <tt>inet_addr</tt> et <tt>inet_ntoa</tt> d'IPv4, la seule véritable différence étant qu'elles ont un argument précisant la famille d'adresse et peuvent donc aussi bien convertir les adresses IPv4 que les adresses IPv6. Comme la plupart des programmes manipulent des <tt>struct sockaddr*</tt>, il est souvent préferable d'utiliser les fonctions <tt>getaddrinfo</tt> et <tt>getnameinfo</tt>, au besoin avec le flag <tt>AI_NUMERICHOST</tt>.<br />
<br />
#include <sys/socket.h><br />
#include <arpa/inet.h><br />
<br />
int<br />
inet_pton(af, src, dst)<br />
int af; /* AF_INET ou AF_INET6 */<br />
const char *src; /* l'adresse (chaine de caract.) à traiter */<br />
void *dst; /* le tampon où est rangé le résultat */<br />
<br />
char *<br />
inet_ntop(af, src, dst, size)<br />
int af; /* AF_INET ou AF_INET6 */<br />
const void *src; /* l'adresse binaire à traiter */<br />
char *dst; /* le tampon où est rangé le résultat */<br />
size_t size; /* la taille de ce tampon */<br />
<br />
La primitive <tt>inet_pton</tt> convertit une adresse textuelle en sa forme binaire. Elle retourne <tt>1</tt> lorsque la conversion a été réussie, <tt>0</tt> si la chaine de caractères qui lui a été fournie n'est pas une adresse valide et <tt>-1</tt> en cas d'erreur, c'est-à-dire lorsque la famille d'adresses (premier argument) n'est pas supportée. Actuellement, les deux seules familles d'adresses supportées sont <tt>AF_INET</tt> et <tt>AF_INET6</tt>.<br />
<br />
La primitive duale <tt>inet_ntop</tt> convertit une adresse sous forme binaire en sa forme textuelle. Le troisième argument est un tampon destiné à recevoir le résultat de la conversion. Il doit être d'une taille suffisante, à savoir 16 octets pour les adresses IPv4 et 46 octets pour les adresses IPv6. Ces deux tailles sont définies dans le fichier <tt>netinet/in.h</tt> :<br />
<br />
#define INET_ADDRSTRLEN 16<br />
#define INET6_ADDRSTRLEN 46<br />
<br />
Si la conversion est réussie, <tt>inet_ntop</tt> retourne un pointeur vers le tampon où est rangé le résultat de la conversion. Dans le cas contraire, <tt>inet_ntop</tt> retourne le pointeur nul, ce qui se produit soit lorsque la famille d'adresses n'est pas reconnue, soit lorsque la taille du tampon est insuffisante.<br />
{{suivi| L'interface socket | L'interface socket | La commande haah (host-address-address-host) | La commande haah (host-address-address-host) }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Les_primitives_de_conversion_entre_noms_et_adresses&diff=2954Les primitives de conversion entre noms et adresses2006-02-27T10:44:56Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| L'interface socket | L'interface socket | La commande haah (host-address-address-host) | La commande haah (host-address-address-host) }}<br />
Les primitives <tt>gethostbyname</tt>, <tt>gethostbyaddr</tt>, <tt>getservbyname</tt> et <tt>getservbyport</tt> ont été remplacées par les deux primitives indépendantes de la famille d'adresses et normalisées par [[Bibliographie#RFC2401bis|[RFC2401bis]]] <tt>getaddrinfo</tt> et <tt>getnameinfo</tt> :<br />
<br />
#include <sys/socket.h><br />
#include <netdb.h><br />
<br />
int<br />
getaddrinfo(const char *nodename, const char *servname,<br />
const struct addrinfo *hints, struct addrinfo **res);<br />
<br />
void freeaddrinfo(struct addrinfo *res);<br />
<br />
const char *gai_strerror(int errcode);<br />
<br />
Le type <tt>struct addrinfo</tt> est défini comme suit :<br />
<br />
struct addrinfo {<br />
int ai_flags; /* AI_PASSIVE, AI_CANONNAME, ... */<br />
int ai_family; /* PF_xxx */<br />
int ai_socktype; /* SOCK_xxx */<br />
int ai_protocol; /* 0 ou IPPROTO_xxx pour IPv4 et IPv6 */<br />
size_t ai_addrlen; /* la taille de l'adresse binaire ai_addr */<br />
char *ai_canonname; /* le nom complétement qualifié */<br />
struct sockaddr *ai_addr; /* l'adresse binaire */<br />
struct addrinfo *ai_next; /* la structure suivante dans la liste chaînée */<br />
};<br />
<br />
<tt>getaddrinfo</tt> prend en entrée le nom d'une machine (<tt>nodename</tt>) et le nom d'un service (<tt>servname</tt>). S'il n'y a pas d'erreur, <tt>getaddrinfo</tt> rend 0 et res pointe sur une liste dynamiquement allouée de <tt>struct addrinfo</tt>. Chaque élément de cette liste contient la description et l'adresse d'une <tt>struct sockaddr</tt> initialisée pour fournir l'accès au service servname sur nodename. Les champs <tt>ai_family</tt>, <tt>ai_socktype</tt> et <tt>ai_protocol</tt> ont la valeur utilisable dans l'appel système socket.<br />
<br />
Lorsque la liste de résultat n'est plus nécessaire, la mémoire allouée peut être libérée par la primitive <tt>freeaddrinfo</tt>. En cas d'erreur, <tt>getaddrinfo</tt> rend un code d'erreur non nul qui peut être imprimé par la fonction <tt>gai_strerror</tt>.<br />
<br />
<tt>getaddrinfo</tt> peut donner des réponses de la famille d'adresses IPv4 ou IPv6, et des réponses pour les protocoles connectés ou non (<tt>ai_socktype</tt> peut valoir <tt>SOCK_DGRAM</tt> ou <tt>SOCK_STREAM</tt>). L'argument <tt>hints</tt> permet de choisir les réponses souhaitées. Un argument égal à <tt>NULL</tt> signifie que la liste des réponses doit contenir toutes les adresses et tous les protocoles. Sinon <tt>hints</tt> doit pointer sur une structure dont les champs <tt>ai_family</tt>, <tt>ai_socktype</tt> et <tt>ai_protocol</tt> définissent les types de résultat attendus. Une valeur de <tt>PF_UNSPEC</tt> du champ <tt>ai_family</tt> signifie que toutes les familles d'adresse (IPv4 et IPv6) sont admises, un <tt>0</tt> dans les champs <tt>ai_socktype</tt> (resp. <tt>ai_protocol</tt>) signifie que tous les types de socket (resp. protocole) sont admis. Le champ <tt>ai_flags</tt> permet de préciser des options supplémentaires.<br />
<br />
L'argument <tt>servname</tt> peut être le nom d'un service ou un nombre décimal. De même, l'argument <tt>nodename</tt> peut être un nom (au format DNS habituel) ou une adresse sous forme numérique IPv4 ou IPv6 (si <tt>ai_flags</tt> contient le bit <tt>AI_NUMERICHOST</tt>, <tt>nodename</tt> doit être sous forme numérique et aucun appel au serveur de nom n'est fait). De plus l'un ou l'autre des arguments <tt>servname</tt> et <tt>nodename</tt> peut être un pointeur <tt>NULL</tt>, mais pas tous les deux. Si <tt>servname</tt> est <tt>NULL</tt>, le champ <tt>port</tt> des réponses ne sera pas initialisé (il restera égal à <tt>0</tt>). Si <tt>nodename</tt> est <tt>NULL</tt>, l'adresse réseau dans les réponses est mis à "non initialisé" (<tt>INADDR_ANY</tt> en IPv4, <tt>IN6ADDR_ANY_INIT</tt> en IPv6) si <tt>ai_flags</tt> contient le bit <tt>AI_PASSIVE</tt>, et à l'adresse de "loopback" (<tt>INADDR_LOOPBACK</tt> ou <tt>IN6ADDR_LOOPBACK_INIT</tt>) sinon. Le cas <tt>AI_PASSIVE</tt> sert donc à obtenir des réponses utilisables par un programme serveur dans un ''bind'' pour recevoir des requêtes. Enfin si le bit <tt>AI_CANONNAME</tt> est positionné, le champ <tt>ai_canonname</tt> de la réponse contient le nom canonique de <tt>nodename</tt>.<br />
<br />
La primitive <tt>getnameinfo</tt> remplace les primitives <tt>gethostbyaddr</tt> et <tt>getservbyport</tt>. Elle effectue la traduction d'une adresse vers un nom :<br />
<br />
#include <sys/socket.h><br />
#include <netdb.h><br />
<br />
int getnameinfo(const struct sockaddr *sa, socklen_t salen,<br />
char *host, size_t hostlen,<br />
char *serv, size_t servlen, int flags);<br />
<br />
En entrée l'argument sa pointe vers une structure d'adresse générique (de type <tt>sockaddr_in</tt> ou <tt>sockaddr_in6</tt>) et salen contient sa longueur. Le champ <tt>host</tt> (resp. <tt>serv</tt>) doit pointer sur une zone de longueur <tt>hostlen</tt> (resp. <tt>servlen</tt>) caractères. <tt>getnameinfo</tt> retourne la valeur <tt>0</tt> si tout est correct et un code d'erreur non nul si une erreur est détectée. S'il n'y a pas d'erreur, le champ <tt>host</tt> (resp. <tt>serv</tt>) reçoit en sortie le nom de la machine (resp. du service) correspondant. Les arguments <tt>host</tt> et <tt>serv</tt> peuvent être <tt>NULL</tt> si la réponse est inutile. Deux constantes sont définies pour permettre de réserver des zones de réponses de longueur raisonnable :<br />
<br />
# define NI_MAXHOST 1025<br />
# define NI_MAXSERV 32<br />
<br />
Le champ <tt>flags</tt> permet de modifier la réponse : si flags contient le bit <tt>NI_NUMERICHOST</tt> (resp. <tt>NI_NUMERICSERV</tt>) la réponse sera l'adresse et non le nom de la machine (resp. le numéro et non le nom du service) ; si on ne sait pas trouver dans le serveur de nom le nom de la machine, <tt>getnameinfo</tt> rendra une erreur si le bit <tt>NI_NAMEREQD</tt> est positionné et l'adresse numérique sinon ; le bit <tt>NI_DGRAM</tt> indique si le service est sur UDP et non sur TCP.<br />
<br />
==<div id="conv">Les fonctions de conversion numériques d'adresses</div>==<br />
<br />
Elles sont l'analogue des fonctions <tt>inet_addr</tt> et <tt>inet_ntoa</tt> d'IPv4, la seule véritable différence étant qu'elles ont un argument précisant la famille d'adresse et peuvent donc aussi bien convertir les adresses IPv4 que les adresses IPv6. Comme la plupart des programmes manipulent des <tt>struct sockaddr*</tt>, il est souvent préferable d'utiliser les fonctions <tt>getaddrinfo</tt> et <tt>getnameinfo</tt>, au besoin avec le flag <tt>AI_NUMERICHOST</tt>.<br />
<br />
#include <sys/socket.h><br />
#include <arpa/inet.h><br />
<br />
int<br />
inet_pton(af, src, dst)<br />
int af; /* AF_INET ou AF_INET6 */<br />
const char *src; /* l'adresse (chaine de caract.) à traiter */<br />
void *dst; /* le tampon où est rangé le résultat */<br />
<br />
char *<br />
inet_ntop(af, src, dst, size)<br />
int af; /* AF_INET ou AF_INET6 */<br />
const void *src; /* l'adresse binaire à traiter */<br />
char *dst; /* le tampon où est rangé le résultat */<br />
size_t size; /* la taille de ce tampon */<br />
<br />
La primitive <tt>inet_pton</tt> convertit une adresse textuelle en sa forme binaire. Elle retourne <tt>1</tt> lorsque la conversion a été réussie, <tt>0</tt> si la chaine de caractères qui lui a été fournie n'est pas une adresse valide et <tt>-1</tt> en cas d'erreur, c'est-à-dire lorsque la famille d'adresses (premier argument) n'est pas supportée. Actuellement, les deux seules familles d'adresses supportées sont <tt>AF_INET</tt> et <tt>AF_INET6</tt>.<br />
<br />
La primitive duale <tt>inet_ntop</tt> convertit une adresse sous forme binaire en sa forme textuelle. Le troisième argument est un tampon destiné à recevoir le résultat de la conversion. Il doit être d'une taille suffisante, à savoir 16 octets pour les adresses IPv4 et 46 octets pour les adresses IPv6. Ces deux tailles sont définies dans le fichier <tt>netinet/in.h</tt> :<br />
<br />
#define INET_ADDRSTRLEN 16<br />
#define INET6_ADDRSTRLEN 46<br />
<br />
Si la conversion est réussie, <tt>inet_ntop</tt> retourne un pointeur vers le tampon où est rangé le résultat de la conversion. Dans le cas contraire, <tt>inet_ntop</tt> retourne le pointeur nul, ce qui se produit soit lorsque la famille d'adresses n'est pas reconnue, soit lorsque la taille du tampon est insuffisante.<br />
{{suivi| L'interface socket | L'interface socket | La commande haah (host-address-address-host) | La commande haah (host-address-address-host) }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=L%27interface_socket&diff=2953L'interface socket2006-02-27T10:42:04Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| L'interface de programmation "socket" IPv6 | L'interface de programmation "socket" IPv6 | Les primitives de conversion entre noms et adresses | Les primitives de conversion entre noms et adresses }}<br />
La création d'une socket se fait comme auparavant en appelant la primitive socket. La distinction entre les protocoles IPv4 et IPv6 se fait sur la valeur du premier argument passé à <tt>socket</tt>, à savoir la famille d'adresses (ou de protocoles), c'est-à-dire ici <tt>PF_INET</tt> ou <tt>PF_INET6</tt>. Par exemple, si on veut créer un socket IPv4/UDP, on écrira :<br />
<br />
sock = socket(PF_INET, SOCK_DGRAM, 0);<br />
<br />
tandis qu'une création de socket IPv6/UDP se fera ainsi :<br />
<br />
sock = socket(PF_INET6, SOCK_DGRAM, 0);<br />
<br />
Une erreur de programmation classique consiste à utiliser <tt>AF_INET</tt> à la place de <tt>PF_INET</tt>. Cela n'a pas d'effet en général car rares sont les systèmes pour lesquels ces deux constantes diffèrent. Pour éviter en IPv6 des problèmes liés à cette erreur, il est demandé que les deux constantes <tt>PF_INET6</tt> et <tt>AF_INET6</tt> soient identiques.<br />
<br />
Quant aux autres primitives constituant l'interface socket, leur syntaxe reste inchangée. Il faut simplement leur fournir des adresses IPv6, en l'occurrence des pointeurs vers des structures de type <tt>struct sockaddr_in6</tt> au préalable convertis en des pointeurs vers des structures génériques de type <tt>struct sockaddr</tt>.<br />
<br />
Donnons pour mémoire une liste des primitives les plus importantes :<br />
<br />
bind() connect() sendmsg()<br />
sendto() accept() recvfrom()<br />
recvmsg() getsockname() getpeername()<br />
<br />
==<div id="wildcard">L'adresse "wildcard"</div>==<br />
<br />
Lors du nommage d'une socket via la primitive <tt>bind</tt>, il arrive fréquemment qu'une application (par exemple un serveur TCP) laisse au système la détermination de l'adresse source pour elle. En IPv4, pour ce faire, elle passe à bind une structure <tt>sockaddr_in</tt> avec le champ <tt>sin_addr.s_addr</tt> ayant pour valeur la constante <tt>INADDR_ANY</tt>, constante définie dans le fichier <tt>netinet/in.h</tt>.<br />
<br />
En IPv6, il y a deux manières de faire cela, à cause des règles du langage C sur les initialisations et affectations de structures. La première est d'initialiser une structure de type <tt>struct in6_addr</tt> par la constante <tt>IN6ADDR_ANY_INIT</tt> :<br />
<br />
struct in6_addr any_addr = IN6ADDR_ANY_INIT;<br />
<br />
Attention, ceci ne peut se faire qu'au moment de la déclaration. Par exemple le code qui suit est incorrect (en C il est interdit d'affecter une constante complexe à une structure) :<br />
<br />
struct sockaddr_in6 sin6;<br />
<br />
sin6.sin6_addr = IN6ADDR_ANY_INIT; /* erreur de syntaxe !! */<br />
<br />
La seconde manière utilise une variable globale :<br />
<br />
extern const struct in6_addr in6addr_any;<br />
struct sockaddr_in6 sin6;<br />
<br />
sin6.sin6_addr = in6addr_any;<br />
<br />
Cette méthode n'est pas possible dans une déclaration de variable globale ou statique.<br />
<br />
La constante <tt>IN6ADDR_ANY_INIT</tt> et la variable <tt>in6addr_any</tt> sont toutes deux définies dans le fichier <tt>netinet/in.h</tt>.<br />
<br />
==<div id="loopback">L'adresse de bouclage</div>==<br />
<br />
En IPv4, c'est la constante <tt>INADDR_LOOPBACK</tt>. En IPv6, de manière tout à fait similaire à l'adresse "wildcard", il y a deux façons d'affecter cette adresse. Ceci peut se faire au moment de la déclaration avec la constante <tt>IN6ADDR_LOOPBACK_INIT</tt> :<br />
<br />
struct in6_addr loopback_addr = IN6ADDR_LOOPBACK_INIT;<br />
<br />
ou via la variable globale <tt>in6addr_loopback</tt> :<br />
<br />
extern const struct in6_addr in6addr_loopback;<br />
struct sockaddr_in6 sin6;<br />
<br />
sin6.sin6_addr = in6addr_loopback;<br />
<br />
Cette constante et cette variable sont définies dans le fichier <tt>netinet/in.h</tt>.<br />
{{suivi| L'interface de programmation "socket" IPv6 | L'interface de programmation "socket" IPv6 | Les primitives de conversion entre noms et adresses | Les primitives de conversion entre noms et adresses }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=L%27interface_de_programmation_%22socket%22_IPv6&diff=2952L'interface de programmation "socket" IPv62006-02-27T10:40:58Z<p>Bruno Deniaud: /* <div id="struct">Les structures de données d'adresses</div> */</p>
<hr />
<div>{{suivi| Programmation d'applications | Programmation d'applications | L'interface socket | L'interface socket }}<br />
==<div id="change">Ce qui a changé</div>==<br />
<br />
Les changements opérés de façon à intégrer IPv6 concernent les quatre domaines suivants :<br />
<br />
* les structures de données d'adresses ;<br />
* l'interface socket ;<br />
* les primitives de conversion entre noms et adresses ;<br />
* les fonctions de conversions d'adresses.<br />
<br />
Ces changements ont été minimisés autant que possible de manière à faciliter le portage des applications IPv4 existantes. En outre, et ce point est important, cette nouvelle API doit permettre l'interopérabilité entre machines IPv4 et machines IPv6 grâce au mécanisme de double pile décrit ci-après.<br />
<br />
L'API décrite ici est celle utilisée en Solaris, Linux et systèmes *BSD. Elle correspond à celle définie dans le RFC 3493 avec quelques modifications nécessaires pour prendre en compte les dernières évolutions des protocoles sous-jacents. Cette API est explicitement conçue pour fonctionner sur des machines possédant la double pile IPv4 et IPv6 (cf. See Double pile IPv4/IPv6 pour le schéma d'implémentation d'une telle double pile sous UNIX 4.4BSD). Cette API "socket" est celle disponible dans de nombreux environnements de programmation tels que Java, perl, python, ruby, ...<br />
<br />
[[image:CS191.gif]]<br />
<br />
Une API "avancée", décrite dans le RFC 3542 permet de programmer les échanges réseaux de manière très précise. Elle sera également utilisée mais de manière succinte et essentiellement par le biais de l'exemple [[one_ping6]].<br />
<br />
==<div id="struct">Les structures de données d'adresses</div>==<br />
<br />
Une nouvelle famille d'adresses ayant pour nom <tt>AF_INET6</tt> et dont la valeur peut varier d'une implémentation à l'autre, a été définie (dans <tt>sys/socket.h</tt>). Également, une nouvelle famille de protocoles ayant pour nom <tt>PF_INET6</tt> a été définie (dans <tt>sys/socket.h</tt>). En principe, on doit avoir :<br />
<br />
#define PF_INET6 AF_INET6<br />
<br />
La structure de données destinée à contenir une adresse IPv6 est définie comme suit (dans <tt>netinet/in.h</tt>) :<br />
<br />
struct in6_addr {<br />
uint8_t s6_addr[16];<br />
};<br />
<br />
les octets constituant l'adresse étant rangés comme d'habitude dans l'ordre réseau (''network byte order'').<br />
<br />
La structure de données IPv6 <tt>struct sockaddr_in6</tt>, est équivalente à la structure <tt>struct sockaddr_in</tt> d'IPv4. Elle est définie comme suit (dans <tt>netinet/in.h</tt>) pour les systèmes dérivés d'UNIX 4.3BSD :<br />
<br />
struct sockaddr_in6 {<br />
sa_family_t sin6_family; /* AF_INET6 */<br />
in_port_t sin6_port; /* numéro de port */<br />
uint32_t sin6_flowinfo; /* identificateur de flux */<br />
struct in6_addr sin6_addr; /* adresse IPv6 */<br />
uint32_t sin6_scope_id; /* ensemble d'interfaces correspondant<br />
* à la portée de l'adresse */<br />
};<br />
<br />
Il faut noter que cette structure a une longueur de 28 octets, et est donc plus grande que le type générique <tt>struct sockaddr</tt>. Il n'est donc plus possible de réserver une <tt>struct sockaddr</tt> si la valeur à stocker peut être une <tt>struct sockaddr_in6</tt>. Afin de faciliter la tâche des implémenteurs, une nouvelle structure de données, <tt>struct sockaddr_storage</tt>, a été définie. Celle-ci est de taille suffisante afin de pouvoir prendre en compte tous les protocoles supportés et alignée de telle sorte que les conversions de type entre pointeurs vers les structures de données d'adresse des protocoles supportés et pointeurs vers elle-même n'engendrent pas de problèmes d'alignement. Un exemple d'utilisation pourrait être le suivant :<br />
<br />
struct sockaddr_storage ss;<br />
<br />
struct sockaddr_in *sin = (struct sockaddr_in *) &ss;<br />
struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *) &ss;<br />
<br />
Dans la version 4.4 d'UNIX BSD, la longueur du champ <tt>sin6_family</tt> est passée de 2 octets à 1 octet. L'octet ainsi récupéré contient la taille de la structure <tt>sockaddr_in6</tt> et sert à effectuer correctement la conversion de type vers la structure de données générique <tt>sockaddr</tt> utilisée par bon nombre de primitives de l'interface socket.<br />
<br />
La macro-définition <tt>SIN6_LEN</tt>, présente dans toute implémentation 4.4BSD, permet alors de distinguer les versions. Les autres champs restant inchangés, cette structure est presque identique à celle de la précédente version :<br />
<br />
#define SIN6_LEN<br />
<br />
struct sockaddr_in6 {<br />
u_int8_t sin6_len; /* la longueur de cette structure */<br />
sa_family_t sin6_family; /* AF_INET6 */<br />
in_port_t sin6_port; /* numéro de port */<br />
uint32_t sin6_flowinfo; /* identificateur de flux */<br />
struct in6_addr sin6_addr; /* adresse IPv6 */<br />
uint32_t sin6_scope_id; /* ensemble d'interfaces correspondant<br />
* à la portée de l'adresse */<br />
};<br />
<br />
Si le champ <tt>sin6_len</tt> existe (ce qui est testable par le fait que le symbole <tt>SIN6_LEN</tt> est défini), il doit être initialisé par la taille de la structure <tt>sockaddr_in6</tt>.<br />
<br />
On notera la présence de deux nouveaux champs (ils n'ont pas d'équivalents dans la structure <tt>sockaddr_in</tt>) dans la structure de données <tt>sockaddr_in6</tt>, les champs <tt>sin6_flowinfo</tt> et <tt>sin6_scope_id</tt>. Le premier, en réalité structuré, est décrit dans le RFC 2460 et [[Identificateur de flux]]. Le second désigne un ensemble d'interfaces en adéquation avec la portée de l'adresse contenue dans le champ <tt>sin6_addr</tt>. Par exemple, si l'adresse en question est de type [[Lien-local|lien local]], le champ <tt>sin6_scope_id</tt> devrait être un index d'interface.<br />
{{suivi| Programmation d'applications | Programmation d'applications | L'interface socket | L'interface socket }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=L%27interface_de_programmation_%22socket%22_IPv6&diff=2951L'interface de programmation "socket" IPv62006-02-27T10:37:11Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| Programmation d'applications | Programmation d'applications | L'interface socket | L'interface socket }}<br />
==<div id="change">Ce qui a changé</div>==<br />
<br />
Les changements opérés de façon à intégrer IPv6 concernent les quatre domaines suivants :<br />
<br />
* les structures de données d'adresses ;<br />
* l'interface socket ;<br />
* les primitives de conversion entre noms et adresses ;<br />
* les fonctions de conversions d'adresses.<br />
<br />
Ces changements ont été minimisés autant que possible de manière à faciliter le portage des applications IPv4 existantes. En outre, et ce point est important, cette nouvelle API doit permettre l'interopérabilité entre machines IPv4 et machines IPv6 grâce au mécanisme de double pile décrit ci-après.<br />
<br />
L'API décrite ici est celle utilisée en Solaris, Linux et systèmes *BSD. Elle correspond à celle définie dans le RFC 3493 avec quelques modifications nécessaires pour prendre en compte les dernières évolutions des protocoles sous-jacents. Cette API est explicitement conçue pour fonctionner sur des machines possédant la double pile IPv4 et IPv6 (cf. See Double pile IPv4/IPv6 pour le schéma d'implémentation d'une telle double pile sous UNIX 4.4BSD). Cette API "socket" est celle disponible dans de nombreux environnements de programmation tels que Java, perl, python, ruby, ...<br />
<br />
[[image:CS191.gif]]<br />
<br />
Une API "avancée", décrite dans le RFC 3542 permet de programmer les échanges réseaux de manière très précise. Elle sera également utilisée mais de manière succinte et essentiellement par le biais de l'exemple [[one_ping6]].<br />
<br />
==<div id="struct">Les structures de données d'adresses</div>==<br />
<br />
Une nouvelle famille d'adresses ayant pour nom <tt>AF_INET6</tt> et dont la valeur peut varier d'une implémentation à l'autre, a été définie (dans <tt>sys/socket.h</tt>). Également, une nouvelle famille de protocoles ayant pour nom <tt>PF_INET6</tt> a été définie (dans <tt>sys/socket.h</tt>). En principe, on doit avoir :<br />
<br />
#define PF_INET6 AF_INET6<br />
<br />
La structure de données destinée à contenir une adresse IPv6 est définie comme suit (dans <tt>netinet/in.h</tt>) :<br />
<br />
struct in6_addr {<br />
uint8_t s6_addr[16];<br />
};<br />
<br />
les octets constituant l'adresse étant rangés comme d'habitude dans l'ordre réseau (''network byte order'').<br />
<br />
La structure de données IPv6 <tt>struct sockaddr_in6</tt>, est équivalente à la structure <tt>struct sockaddr_in</tt> d'IPv4. Elle est définie comme suit (dans <tt>netinet/in.h</tt>) pour les systèmes dérivés d'UNIX 4.3BSD :<br />
<br />
struct sockaddr_in6 {<br />
sa_family_t sin6_family; /* AF_INET6 */<br />
in_port_t sin6_port; /* numéro de port */<br />
uint32_t sin6_flowinfo; /* identificateur de flux */<br />
struct in6_addr sin6_addr; /* adresse IPv6 */<br />
uint32_t sin6_scope_id; /* ensemble d'interfaces correspondant<br />
* à la portée de l'adresse */<br />
};<br />
<br />
Il faut noter que cette structure a une longueur de 28 octets, et est donc plus grande que le type générique <tt>struct sockaddr</tt>. Il n'est donc plus possible de réserver une <tt>struct sockaddr</tt> si la valeur à stocker peut être une <tt>struct sockaddr_in6</tt>. Afin de faciliter la tâche des implémenteurs, une nouvelle structure de données, <tt>struct sockaddr_storage</tt>, a été définie. Celle-ci est de taille suffisante afin de pouvoir prendre en compte tous les protocoles supportés et alignée de telle sorte que les conversions de type entre pointeurs vers les structures de données d'adresse des protocoles supportés et pointeurs vers elle-même n'engendrent pas de problèmes d'alignement. Un exemple d'utilisation pourrait être le suivant :<br />
<br />
struct sockaddr_storage ss;<br />
<br />
struct sockaddr_in *sin = (struct sockaddr_in *) &ss;<br />
struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *) &ss;<br />
<br />
Dans la version 4.4 d'UNIX BSD, la longueur du champ <tt>sin6_family</tt> est passée de 2 octets à 1 octet. L'octet ainsi récupéré contient la taille de la structure <tt>sockaddr_in6</tt> et sert à effectuer correctement la conversion de type vers la structure de données générique <tt>sockaddr</tt> utilisée par bon nombre de primitives de l'interface socket.<br />
<br />
La macro-définition <tt>SIN6_LEN</tt>, présente dans toute implémentation 4.4BSD, permet alors de distinguer les versions. Les autres champs restant inchangés, cette structure est presque identique à celle de la précédente version :<br />
<br />
#define SIN6_LEN<br />
<br />
struct sockaddr_in6 {<br />
u_int8_t sin6_len; /* la longueur de cette structure */<br />
sa_family_t sin6_family; /* AF_INET6 */<br />
in_port_t sin6_port; /* numéro de port */<br />
uint32_t sin6_flowinfo; /* identificateur de flux */<br />
struct in6_addr sin6_addr; /* adresse IPv6 */<br />
uint32_t sin6_scope_id; /* ensemble d'interfaces correspondant<br />
* à la portée de l'adresse */<br />
};<br />
<br />
Si le champ <tt>sin6_len</tt> existe (ce qui est testable par le fait que le symbole <tt>SIN6_LEN</tt> est défini), il doit être initialisé par la taille de la structure <tt>sockaddr_in6</tt>.<br />
<br />
On notera la présence de deux nouveaux champs (ils n'ont pas d'équivalents dans la structure <tt>sockaddr_in</tt>) dans la structure de données <tt>sockaddr_in6<§tt>, les champs <tt>sin6_flowinfo</tt> et <tt>sin6_scope_id</tt>. Le premier, en réalité structuré, est décrit dans le RFC 2460 et [[Identificateur de flux]]. Le second désigne un ensemble d'interfaces en adéquation avec la portée de l'adresse contenue dans le champ <tt>sin6_addr</tt>. Par exemple, si l'adresse en question est de type [[Lien-local|lien local]], le champ <tt>sin6_scope_id</tt> devrait être un index d'interface.<br />
{{suivi| Programmation d'applications | Programmation d'applications | L'interface socket | L'interface socket }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Programmation_d%27applications&diff=2950Programmation d'applications2006-02-27T10:27:47Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| Mécanismes d'interopérabilité | Mécanismes d'interopérabilité | L'interface de programmation "socket" IPv6 | L'interface de programmation "socket" IPv6 }}<br />
L'évolution de IPv4 vers IPv6 a été conçue pour minimiser les changements visibles. Un grand nombre de concepts n'ont pas changé : les noms, les "ports", l'envoi et la réception de données,... Un certain nombre de points ont malgré tout dû être modifiés. Le principal est lié à la taille de l'adresse : en IPv4, une adresse a une longueur de 32 bits (et de nombreux programmes confondent les types adresse et entier) alors qu'en IPv6 une adresse a une longueur de 128 bits ; les types liés aux adresses doivent donc être modifiés. En fait l'effet est plus profond : les nouvelles structures sont plus grandes, et certaines réservations de mémoire avec conversion de type implicite (en particulier : un entier pour une adresse, une <tt>struct sockaddr</tt> pour une <tt>struct sockaddr_in</tt>, un tampon de 16 octets pour afficher une adresse sous forme numérique) doivent être corrigés sous peine de débordement de mémoire.<br />
<br />
L'interface de programmation réseau ("API") la plus connue est l'interface "socket" (dite aussi interface "BSD"). Le but de ce chapitre est de présenter pour cette interface de programmation les modifications introduites pour supporter IPv6, et notamment de donner une brève description des nouvelles primitives d'appel au DNS et de conversion d'adresses.<br />
<br />
Ces modifications ont été définies pour être aussi transparentes que possible, et, s'il est en pratique toujours nécessaire de modifier un programme pour le porter de IPv4 à IPv6, un programme conçu avec des règles de typage strict est portable sans grandes modifications.<br />
<br />
Ce chapitre illustrera l'interface de programmation "socket" pour IPv6 en présentant plusieurs exemples de programmes. Plus précisément, il détaillera successivement :<br />
<br />
* un programme combinant les différentes fonctions de conversion d'adresse ;<br />
* un client/serveur TCP calculant le nombre d'utilisateurs connectés sur une machine cible. En particulier, on aura soin de comparer les codes IPv4 et IPv6 de ce client/serveur, ce qui amènera à constater qu'à ce niveau de programmation, la migration vers IPv6 n'offre aucune difficulté ;<br />
* un "mini ping" qui permettra de se familiariser avec le protocole ICMPv6 qui présente de notables différences avec son prédécesseur le protocole ICMPv4 ;<br />
* un exemple qui génère un trafic multicast, avec abonnement et désabonnement ;<br />
* un programme illustant l'utilisation de l'API socket avancée.<br />
{{suivi| Mécanismes d'interopérabilité | Mécanismes d'interopérabilité | L'interface de programmation "socket" IPv6 | L'interface de programmation "socket" IPv6 }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Programmation_d%27applications&diff=2949Programmation d'applications2006-02-27T10:27:26Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| Accès des entreprises et des particuliers à l'Internet IPv6 | Accès des entreprises et des particuliers à l'Internet IPv6 | Programmation d'applications | Programmation d'applications }}<br />
L'évolution de IPv4 vers IPv6 a été conçue pour minimiser les changements visibles. Un grand nombre de concepts n'ont pas changé : les noms, les "ports", l'envoi et la réception de données,... Un certain nombre de points ont malgré tout dû être modifiés. Le principal est lié à la taille de l'adresse : en IPv4, une adresse a une longueur de 32 bits (et de nombreux programmes confondent les types adresse et entier) alors qu'en IPv6 une adresse a une longueur de 128 bits ; les types liés aux adresses doivent donc être modifiés. En fait l'effet est plus profond : les nouvelles structures sont plus grandes, et certaines réservations de mémoire avec conversion de type implicite (en particulier : un entier pour une adresse, une <tt>struct sockaddr</tt> pour une <tt>struct sockaddr_in</tt>, un tampon de 16 octets pour afficher une adresse sous forme numérique) doivent être corrigés sous peine de débordement de mémoire.<br />
<br />
L'interface de programmation réseau ("API") la plus connue est l'interface "socket" (dite aussi interface "BSD"). Le but de ce chapitre est de présenter pour cette interface de programmation les modifications introduites pour supporter IPv6, et notamment de donner une brève description des nouvelles primitives d'appel au DNS et de conversion d'adresses.<br />
<br />
Ces modifications ont été définies pour être aussi transparentes que possible, et, s'il est en pratique toujours nécessaire de modifier un programme pour le porter de IPv4 à IPv6, un programme conçu avec des règles de typage strict est portable sans grandes modifications.<br />
<br />
Ce chapitre illustrera l'interface de programmation "socket" pour IPv6 en présentant plusieurs exemples de programmes. Plus précisément, il détaillera successivement :<br />
<br />
* un programme combinant les différentes fonctions de conversion d'adresse ;<br />
* un client/serveur TCP calculant le nombre d'utilisateurs connectés sur une machine cible. En particulier, on aura soin de comparer les codes IPv4 et IPv6 de ce client/serveur, ce qui amènera à constater qu'à ce niveau de programmation, la migration vers IPv6 n'offre aucune difficulté ;<br />
* un "mini ping" qui permettra de se familiariser avec le protocole ICMPv6 qui présente de notables différences avec son prédécesseur le protocole ICMPv4 ;<br />
* un exemple qui génère un trafic multicast, avec abonnement et désabonnement ;<br />
* un programme illustant l'utilisation de l'API socket avancée.<br />
{{suivi| Mécanismes d'interopérabilité | Mécanismes d'interopérabilité | L'interface de programmation "socket" IPv6 | L'interface de programmation "socket" IPv6 }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=M%C3%A9canismes_d%27interop%C3%A9rabilit%C3%A9&diff=2948Mécanismes d'interopérabilité2006-02-27T10:26:22Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| Accès des entreprises et des particuliers à l'Internet IPv6 | Accès des entreprises et des particuliers à l'Internet IPv6 | Programmation d'applications | Programmation d'applications }}<br />
==Relais applicatifs==<br />
<br />
Les relais applicatifs ou ALG (''Application Level Gateway'') représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure Exemple de relais applicatif pour le courrier électronique) configurées pour accéder aux deux versions du protocole. Les équipements IPv6 émettent leur requête vers le relais applicatif qui interprète le contenu de la requête et la retransmet en IPv4.<br />
<br />
Un ou plusieurs relais peuvent être installés en fonction des services rendus disponibles sur le réseau (par exemple serveur d'impression, serveur de messagerie, relais http, ...). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces relais.<br />
<br />
L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les relais applicatifs, par exemple telnet. Mais comme la liste précédente l'indique, les ALG concernent des applications courantes qui représentent une partie importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.<br />
<br />
[[image:CS186.gif]]<br />
<br />
Les relais applicatifs regroupent :<br />
<br />
* les proxies et les caches web,<br />
* les spoolers d'impression,<br />
* les serveurs de courrier électronique,<br />
* les serveurs DNS,<br />
* ...<br />
<br />
===Configuration d'un relais applicatif pour le Web===<br />
<br />
Le listing suivant donne un extrait de la configuration d'un serveur apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.<br />
<br />
#cat /usr/local/etc/apache/httpd.conf<br />
#<br />
# Proxy Server directives. Uncomment the following lines to<br />
# enable the proxy server:<br />
#<br />
<IfModule mod_proxy.c><br />
ProxyRequests On<br />
<Directory proxy:*><br />
Order deny,allow<br />
Allow from all<br />
</Directory><br />
#<br />
# Enable/disable the handling of HTTP/1.1 "Via:" headers.<br />
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)<br />
# Set to one of: Off | On | Full | Block<br />
#<br />
ProxyVia On<br />
</IfModule><br />
# End of proxy directives.<br />
<br />
==SOCKS==<br />
<br />
Cette technique est aussi issue des solutions pour passer d'un adressage privé à un adressage public. SOCKS ajoute un "canal de signalisation" aux données transportées, ce qui permet de piloter à distance l'ouverture de connexion. En IPv4, cette technique permet d'utiliser un adressage privé en interne pour atteindre un relais SOCKS qui se trouve dans une zone démilitarisée. Le relais SOCKS se charge d'ouvrir une connexion normale avec l'équipement distant. Le relais SOCKS se plaçant dans le modèle architectural en dessous de l'application, il est relativement indépendant de celle-ci, il n'est pas nécessaire de recourir à différents types de relais. De plus, SOCKS permet aussi bien les communications entrantes que sortantes.<br />
<br />
SOCKS s'applique à tout type de réseau, ainsi qu'à des réseaux utilisant l'adressage privé IPv4.<br />
<br />
Le RFC 3089 étend ce mécanisme en permettant les deux versions du protocole IP. Quatre scénarios sont possibles, comme l'indique la figure suivante :<br />
<br />
[[image:CS187.gif]]<br />
<br />
* les protocoles X et Y sont IPv4. On est dans le cadre d'une utilisation classique de SOCKS telle qu'elle est prévue dans le RFC 1928 initial pour permettre à des équipements utilisant un plan d'adressage privé d'accéder aux ressources de l'Internet et de contrôler l'accès au réseau.<br />
* le protocole X est IPv4 et le protocole Y est IPv6. Ce scénario permet de v6fier une application ne connaissant qu'IPv4.<br />
* le protocole X est IPv6 et le protocole Y est IPv4. Ce scénario permet à une application IPv6 d'accéder à des ressources uniquement disponibles en IPv4<br />
* les protocoles X et Y sont IPv6. Vu la taille des adresses IPv6, il est peu probable qu'il y ait toujours un plan d'adressage privé, non routable sur l'Internet. L'utilisation de SOCKS dans ce cas serait surtout pour contrôler l'usage des ressources réseau.<br />
<br />
Le RFC 3089 prévoit aussi l'enchaînement de plusieurs relais SOCKS.<br />
<br />
La principale difficulté introduite par l'utilisation de SOCKS pour la transition provient de l'interrogation du DNS. Dans le cas du deuxième scénario, où X vaut 4 et Y vaut 6, l'application ne peut que manipuler des adresses IPv4. En particulier les appels aux serveurs DNS pour la résolution de nom ne portent que sur des ''Resource Records'' de type <tt>A</tt>.<br />
<br />
Le RFC 1928 prévoit que dans la partie "signalisation", le nom de l'équipement distant peut être envoyé de trois manières différentes :<br />
<br />
* une adresse IPv4,<br />
* un nom de machine,<br />
* une adresse IPv6.<br />
<br />
Si l'application utilise un nom de machine (FQDN : ''Fully Qualified Domain Name''), SOCKS intercepte l'appel procédural pour la résolution et retourne à l'application une fausse adresse IP prise dans un poule. Quand l'application ouvre une connexion en utilisant cette adresse, le nom de la machine distante peut être retrouvé et est envoyé au relais SOCKS qui pourra, si le DNS retourne un enregistrement <tt>AAAA</tt>, ouvrir la connexion en utilisant le protocole IPv6.<br />
<br />
==DSTM==<br />
<br />
L'objectif de DSTM (''Dual Stack Transition Mechanism'') est de donner une connectivité IPv4 temporaire à un terminal dual-stack connecté à un réseau uniquement IPv6. La connectivité IPv4 n'est disponible que le temps nécessaire à une communication avec un terminal distant qui ne possède qu'une pile IPv4. Dans le principe, DSTM est en quelque sorte la réciproque du Tunnel Broker.<br />
<br />
En général DSTM est identifié comme un mécanisme intervenant en fin de période de cohabitation IPv4/IPv6, lorsque les réseaux IPv6 sont dévenus majoritaires. Dans ce cas, DSTM peut typiquement s'appliquer soit à un réseau d'entreprise, soit à un réseau d'ISP.<br />
<br />
DSTM se place dans la situation où une partie d'un site est passée en IPv6, mais où certaines applications continuent à utiliser IPv4. DSTM utilise une interface spéciale DTI (''Dynamic Tunneling Interface'') qui permet l'encapsulation des paquets IPv4 dans des paquets IPv6. Du point de vue de l'application, ce mécanisme est relativement transparent, puisque l'interface DTI est considérée comme une interface réseau classique.<br />
<br />
Un routeur particulier appelé TEP (''Tunnel End Point'') possédant la connectivité entre le monde IPv4 et le monde IPv6 effectue l'encapsulation et la désencapsulation des données.<br />
<br />
Initialement, les interfaces sont actives, mais ne disposent pas d'adresses IPv4, l'attribution d'une adresse n'est faite que lorsqu'un premier paquet est routé vers l'interface DTI. Dans ce cas, une demande d'allocation est envoyée par la machine à un serveur et une adresse IPv4 est allouée pendant la durée d'utilisation de l'interface DTI. Les paquets IPv4 sont envoyés à un TEP dont l'adresse IPv6 est généralement obtenue en même temps que l'adresse IPv4 temporaire. Le TEP garde en mémoire la correspondance entre les adresses sources IPv4 et IPv6 des paquets qu'il reçoit. De cette manière quand le destinataire sur le réseau IPv4 répond, le TEP peut déterminer vers quel équipement il peut tunneler les paquets.<br />
<br />
[[image:CS188.gif]]<br />
<br />
L'usage de DSTM permet de ne configurer que la pile IPv6 d'un équipement. La pile IPv4 est configurée à la demande en fonction des besoins applicatifs. Le travail de configuation, de routage et de supervision de l'administrateur est donc simplifié.<br />
<br />
Le fait d'utiliser des tunnels facilite l'allocation des adresses IPv4, car celles-ci perdent leur fonction de localisation, elles doivent juste conserver leur propriété d'unicité, ce qui est relativement facile à garantir.<br />
<br />
==NAT-PT==<br />
<br />
Le principe reste identique à celui de NAT pour IPv4. Il s'agit ici de traduire les en-têtes des datagrammes IPv6 en en-têtes de datagrammes IPv4. NAT-PT permet le déploiement de réseaux uniquement IPv6 et offrir une « compatibilité » avec le monde IPv4. Les boitiers NAT-PT sont des routeurs réalisant la traduction des paquets IPv6 en paquets IPv4 et servant de proxy DNS. Les autres équipements du réseau (derrière le boitier NAT-PT) n'ont besoin de rien de spécial pour que ce mécanisme puisse être utilisé.<br />
<br />
* NAT-PT permet de s'affranchir d'IPv4 tout en permettant de continuer à bénéficier des services qui lui sont encore associés. Ce mécanisme introduit apres la phase de mise en œuvre (qui n'est pas très simple) un réel allègement de la tâche de l'administrateur.<br />
* Le mécanisme NAT-PT est en discussion dans le groupe v6ops de l'IETF pour être classé historique, son usage semble devoir être limité (voire confiné) à des situations qui ne peuvent être gérées autrement. Un document de travail inventorie les scénarios qui en ont « absolument » besoin et tente de proposer des mécanismes de remplacement.<br />
<br />
Le principe de fonctionnement de NAT-PT pour passer d'une version à l'autre du protocole IP est le même que pour passer d'un adressage privé à une adressage public, avec également les mêmes limitations, par exemple, si les paquets transportent des adresses. Par contre, ce mécanisme offre une certaine transparence au niveau du réseau.<br />
<br />
Les paquets émis vers un équipement uniquement IPv4 utilisent l'adresse IPv4 mappée. Par contre, l'adresse source est une des adresses IPv6 globale que possède la machine émettrice. Le préfixe des adresses IPv4 mappées est routé vers un boîtier de traduction. Ce dernier dispose d'un poule d'adresses IPv4 officielles. Quand une nouvelle session est initiée par une machine IPv6, le boîtier alloue à la nouvelle adresse IPv6, une adresse IPv4 du poule, et construit un paquet IPv4 en extrayant de l'adresse IPv4, l'adresse IPv4 mappée de destination.<br />
{{suivi| Accès des entreprises et des particuliers à l'Internet IPv6 | Accès des entreprises et des particuliers à l'Internet IPv6 | Programmation d'applications | Programmation d'applications }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=M%C3%A9canismes_d%27interop%C3%A9rabilit%C3%A9&diff=2947Mécanismes d'interopérabilité2006-02-27T10:24:43Z<p>Bruno Deniaud: /* NAT-PT */</p>
<hr />
<div>==Relais applicatifs==<br />
<br />
Les relais applicatifs ou ALG (''Application Level Gateway'') représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure Exemple de relais applicatif pour le courrier électronique) configurées pour accéder aux deux versions du protocole. Les équipements IPv6 émettent leur requête vers le relais applicatif qui interprète le contenu de la requête et la retransmet en IPv4.<br />
<br />
Un ou plusieurs relais peuvent être installés en fonction des services rendus disponibles sur le réseau (par exemple serveur d'impression, serveur de messagerie, relais http, ...). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces relais.<br />
<br />
L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les relais applicatifs, par exemple telnet. Mais comme la liste précédente l'indique, les ALG concernent des applications courantes qui représentent une partie importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.<br />
<br />
[[image:CS186.gif]]<br />
<br />
Les relais applicatifs regroupent :<br />
<br />
* les proxies et les caches web,<br />
* les spoolers d'impression,<br />
* les serveurs de courrier électronique,<br />
* les serveurs DNS,<br />
* ...<br />
<br />
===Configuration d'un relais applicatif pour le Web===<br />
<br />
Le listing suivant donne un extrait de la configuration d'un serveur apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.<br />
<br />
#cat /usr/local/etc/apache/httpd.conf<br />
#<br />
# Proxy Server directives. Uncomment the following lines to<br />
# enable the proxy server:<br />
#<br />
<IfModule mod_proxy.c><br />
ProxyRequests On<br />
<Directory proxy:*><br />
Order deny,allow<br />
Allow from all<br />
</Directory><br />
#<br />
# Enable/disable the handling of HTTP/1.1 "Via:" headers.<br />
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)<br />
# Set to one of: Off | On | Full | Block<br />
#<br />
ProxyVia On<br />
</IfModule><br />
# End of proxy directives.<br />
<br />
==SOCKS==<br />
<br />
Cette technique est aussi issue des solutions pour passer d'un adressage privé à un adressage public. SOCKS ajoute un "canal de signalisation" aux données transportées, ce qui permet de piloter à distance l'ouverture de connexion. En IPv4, cette technique permet d'utiliser un adressage privé en interne pour atteindre un relais SOCKS qui se trouve dans une zone démilitarisée. Le relais SOCKS se charge d'ouvrir une connexion normale avec l'équipement distant. Le relais SOCKS se plaçant dans le modèle architectural en dessous de l'application, il est relativement indépendant de celle-ci, il n'est pas nécessaire de recourir à différents types de relais. De plus, SOCKS permet aussi bien les communications entrantes que sortantes.<br />
<br />
SOCKS s'applique à tout type de réseau, ainsi qu'à des réseaux utilisant l'adressage privé IPv4.<br />
<br />
Le RFC 3089 étend ce mécanisme en permettant les deux versions du protocole IP. Quatre scénarios sont possibles, comme l'indique la figure suivante :<br />
<br />
[[image:CS187.gif]]<br />
<br />
* les protocoles X et Y sont IPv4. On est dans le cadre d'une utilisation classique de SOCKS telle qu'elle est prévue dans le RFC 1928 initial pour permettre à des équipements utilisant un plan d'adressage privé d'accéder aux ressources de l'Internet et de contrôler l'accès au réseau.<br />
* le protocole X est IPv4 et le protocole Y est IPv6. Ce scénario permet de v6fier une application ne connaissant qu'IPv4.<br />
* le protocole X est IPv6 et le protocole Y est IPv4. Ce scénario permet à une application IPv6 d'accéder à des ressources uniquement disponibles en IPv4<br />
* les protocoles X et Y sont IPv6. Vu la taille des adresses IPv6, il est peu probable qu'il y ait toujours un plan d'adressage privé, non routable sur l'Internet. L'utilisation de SOCKS dans ce cas serait surtout pour contrôler l'usage des ressources réseau.<br />
<br />
Le RFC 3089 prévoit aussi l'enchaînement de plusieurs relais SOCKS.<br />
<br />
La principale difficulté introduite par l'utilisation de SOCKS pour la transition provient de l'interrogation du DNS. Dans le cas du deuxième scénario, où X vaut 4 et Y vaut 6, l'application ne peut que manipuler des adresses IPv4. En particulier les appels aux serveurs DNS pour la résolution de nom ne portent que sur des ''Resource Records'' de type <tt>A</tt>.<br />
<br />
Le RFC 1928 prévoit que dans la partie "signalisation", le nom de l'équipement distant peut être envoyé de trois manières différentes :<br />
<br />
* une adresse IPv4,<br />
* un nom de machine,<br />
* une adresse IPv6.<br />
<br />
Si l'application utilise un nom de machine (FQDN : ''Fully Qualified Domain Name''), SOCKS intercepte l'appel procédural pour la résolution et retourne à l'application une fausse adresse IP prise dans un poule. Quand l'application ouvre une connexion en utilisant cette adresse, le nom de la machine distante peut être retrouvé et est envoyé au relais SOCKS qui pourra, si le DNS retourne un enregistrement <tt>AAAA</tt>, ouvrir la connexion en utilisant le protocole IPv6.<br />
<br />
==DSTM==<br />
<br />
L'objectif de DSTM (''Dual Stack Transition Mechanism'') est de donner une connectivité IPv4 temporaire à un terminal dual-stack connecté à un réseau uniquement IPv6. La connectivité IPv4 n'est disponible que le temps nécessaire à une communication avec un terminal distant qui ne possède qu'une pile IPv4. Dans le principe, DSTM est en quelque sorte la réciproque du Tunnel Broker.<br />
<br />
En général DSTM est identifié comme un mécanisme intervenant en fin de période de cohabitation IPv4/IPv6, lorsque les réseaux IPv6 sont dévenus majoritaires. Dans ce cas, DSTM peut typiquement s'appliquer soit à un réseau d'entreprise, soit à un réseau d'ISP.<br />
<br />
DSTM se place dans la situation où une partie d'un site est passée en IPv6, mais où certaines applications continuent à utiliser IPv4. DSTM utilise une interface spéciale DTI (''Dynamic Tunneling Interface'') qui permet l'encapsulation des paquets IPv4 dans des paquets IPv6. Du point de vue de l'application, ce mécanisme est relativement transparent, puisque l'interface DTI est considérée comme une interface réseau classique.<br />
<br />
Un routeur particulier appelé TEP (''Tunnel End Point'') possédant la connectivité entre le monde IPv4 et le monde IPv6 effectue l'encapsulation et la désencapsulation des données.<br />
<br />
Initialement, les interfaces sont actives, mais ne disposent pas d'adresses IPv4, l'attribution d'une adresse n'est faite que lorsqu'un premier paquet est routé vers l'interface DTI. Dans ce cas, une demande d'allocation est envoyée par la machine à un serveur et une adresse IPv4 est allouée pendant la durée d'utilisation de l'interface DTI. Les paquets IPv4 sont envoyés à un TEP dont l'adresse IPv6 est généralement obtenue en même temps que l'adresse IPv4 temporaire. Le TEP garde en mémoire la correspondance entre les adresses sources IPv4 et IPv6 des paquets qu'il reçoit. De cette manière quand le destinataire sur le réseau IPv4 répond, le TEP peut déterminer vers quel équipement il peut tunneler les paquets.<br />
<br />
[[image:CS188.gif]]<br />
<br />
L'usage de DSTM permet de ne configurer que la pile IPv6 d'un équipement. La pile IPv4 est configurée à la demande en fonction des besoins applicatifs. Le travail de configuation, de routage et de supervision de l'administrateur est donc simplifié.<br />
<br />
Le fait d'utiliser des tunnels facilite l'allocation des adresses IPv4, car celles-ci perdent leur fonction de localisation, elles doivent juste conserver leur propriété d'unicité, ce qui est relativement facile à garantir.<br />
<br />
==NAT-PT==<br />
<br />
Le principe reste identique à celui de NAT pour IPv4. Il s'agit ici de traduire les en-têtes des datagrammes IPv6 en en-têtes de datagrammes IPv4. NAT-PT permet le déploiement de réseaux uniquement IPv6 et offrir une « compatibilité » avec le monde IPv4. Les boitiers NAT-PT sont des routeurs réalisant la traduction des paquets IPv6 en paquets IPv4 et servant de proxy DNS. Les autres équipements du réseau (derrière le boitier NAT-PT) n'ont besoin de rien de spécial pour que ce mécanisme puisse être utilisé.<br />
<br />
* NAT-PT permet de s'affranchir d'IPv4 tout en permettant de continuer à bénéficier des services qui lui sont encore associés. Ce mécanisme introduit apres la phase de mise en œuvre (qui n'est pas très simple) un réel allègement de la tâche de l'administrateur.<br />
* Le mécanisme NAT-PT est en discussion dans le groupe v6ops de l'IETF pour être classé historique, son usage semble devoir être limité (voire confiné) à des situations qui ne peuvent être gérées autrement. Un document de travail inventorie les scénarios qui en ont « absolument » besoin et tente de proposer des mécanismes de remplacement.<br />
<br />
Le principe de fonctionnement de NAT-PT pour passer d'une version à l'autre du protocole IP est le même que pour passer d'un adressage privé à une adressage public, avec également les mêmes limitations, par exemple, si les paquets transportent des adresses. Par contre, ce mécanisme offre une certaine transparence au niveau du réseau.<br />
<br />
Les paquets émis vers un équipement uniquement IPv4 utilisent l'adresse IPv4 mappée. Par contre, l'adresse source est une des adresses IPv6 globale que possède la machine émettrice. Le préfixe des adresses IPv4 mappées est routé vers un boîtier de traduction. Ce dernier dispose d'un poule d'adresses IPv4 officielles. Quand une nouvelle session est initiée par une machine IPv6, le boîtier alloue à la nouvelle adresse IPv6, une adresse IPv4 du poule, et construit un paquet IPv4 en extrayant de l'adresse IPv4, l'adresse IPv4 mappée de destination.</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=M%C3%A9canismes_d%27interop%C3%A9rabilit%C3%A9&diff=2946Mécanismes d'interopérabilité2006-02-27T10:19:31Z<p>Bruno Deniaud: /* Relais applicatifs */</p>
<hr />
<div>==Relais applicatifs==<br />
<br />
Les relais applicatifs ou ALG (''Application Level Gateway'') représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure Exemple de relais applicatif pour le courrier électronique) configurées pour accéder aux deux versions du protocole. Les équipements IPv6 émettent leur requête vers le relais applicatif qui interprète le contenu de la requête et la retransmet en IPv4.<br />
<br />
Un ou plusieurs relais peuvent être installés en fonction des services rendus disponibles sur le réseau (par exemple serveur d'impression, serveur de messagerie, relais http, ...). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces relais.<br />
<br />
L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les relais applicatifs, par exemple telnet. Mais comme la liste précédente l'indique, les ALG concernent des applications courantes qui représentent une partie importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.<br />
<br />
[[image:CS186.gif]]<br />
<br />
Les relais applicatifs regroupent :<br />
<br />
* les proxies et les caches web,<br />
* les spoolers d'impression,<br />
* les serveurs de courrier électronique,<br />
* les serveurs DNS,<br />
* ...<br />
<br />
===Configuration d'un relais applicatif pour le Web===<br />
<br />
Le listing suivant donne un extrait de la configuration d'un serveur apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.<br />
<br />
#cat /usr/local/etc/apache/httpd.conf<br />
#<br />
# Proxy Server directives. Uncomment the following lines to<br />
# enable the proxy server:<br />
#<br />
<IfModule mod_proxy.c><br />
ProxyRequests On<br />
<Directory proxy:*><br />
Order deny,allow<br />
Allow from all<br />
</Directory><br />
#<br />
# Enable/disable the handling of HTTP/1.1 "Via:" headers.<br />
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)<br />
# Set to one of: Off | On | Full | Block<br />
#<br />
ProxyVia On<br />
</IfModule><br />
# End of proxy directives.<br />
<br />
==SOCKS==<br />
<br />
Cette technique est aussi issue des solutions pour passer d'un adressage privé à un adressage public. SOCKS ajoute un "canal de signalisation" aux données transportées, ce qui permet de piloter à distance l'ouverture de connexion. En IPv4, cette technique permet d'utiliser un adressage privé en interne pour atteindre un relais SOCKS qui se trouve dans une zone démilitarisée. Le relais SOCKS se charge d'ouvrir une connexion normale avec l'équipement distant. Le relais SOCKS se plaçant dans le modèle architectural en dessous de l'application, il est relativement indépendant de celle-ci, il n'est pas nécessaire de recourir à différents types de relais. De plus, SOCKS permet aussi bien les communications entrantes que sortantes.<br />
<br />
SOCKS s'applique à tout type de réseau, ainsi qu'à des réseaux utilisant l'adressage privé IPv4.<br />
<br />
Le RFC 3089 étend ce mécanisme en permettant les deux versions du protocole IP. Quatre scénarios sont possibles, comme l'indique la figure suivante :<br />
<br />
[[image:CS187.gif]]<br />
<br />
* les protocoles X et Y sont IPv4. On est dans le cadre d'une utilisation classique de SOCKS telle qu'elle est prévue dans le RFC 1928 initial pour permettre à des équipements utilisant un plan d'adressage privé d'accéder aux ressources de l'Internet et de contrôler l'accès au réseau.<br />
* le protocole X est IPv4 et le protocole Y est IPv6. Ce scénario permet de v6fier une application ne connaissant qu'IPv4.<br />
* le protocole X est IPv6 et le protocole Y est IPv4. Ce scénario permet à une application IPv6 d'accéder à des ressources uniquement disponibles en IPv4<br />
* les protocoles X et Y sont IPv6. Vu la taille des adresses IPv6, il est peu probable qu'il y ait toujours un plan d'adressage privé, non routable sur l'Internet. L'utilisation de SOCKS dans ce cas serait surtout pour contrôler l'usage des ressources réseau.<br />
<br />
Le RFC 3089 prévoit aussi l'enchaînement de plusieurs relais SOCKS.<br />
<br />
La principale difficulté introduite par l'utilisation de SOCKS pour la transition provient de l'interrogation du DNS. Dans le cas du deuxième scénario, où X vaut 4 et Y vaut 6, l'application ne peut que manipuler des adresses IPv4. En particulier les appels aux serveurs DNS pour la résolution de nom ne portent que sur des ''Resource Records'' de type <tt>A</tt>.<br />
<br />
Le RFC 1928 prévoit que dans la partie "signalisation", le nom de l'équipement distant peut être envoyé de trois manières différentes :<br />
<br />
* une adresse IPv4,<br />
* un nom de machine,<br />
* une adresse IPv6.<br />
<br />
Si l'application utilise un nom de machine (FQDN : ''Fully Qualified Domain Name''), SOCKS intercepte l'appel procédural pour la résolution et retourne à l'application une fausse adresse IP prise dans un poule. Quand l'application ouvre une connexion en utilisant cette adresse, le nom de la machine distante peut être retrouvé et est envoyé au relais SOCKS qui pourra, si le DNS retourne un enregistrement <tt>AAAA</tt>, ouvrir la connexion en utilisant le protocole IPv6.<br />
<br />
==DSTM==<br />
<br />
L'objectif de DSTM (''Dual Stack Transition Mechanism'') est de donner une connectivité IPv4 temporaire à un terminal dual-stack connecté à un réseau uniquement IPv6. La connectivité IPv4 n'est disponible que le temps nécessaire à une communication avec un terminal distant qui ne possède qu'une pile IPv4. Dans le principe, DSTM est en quelque sorte la réciproque du Tunnel Broker.<br />
<br />
En général DSTM est identifié comme un mécanisme intervenant en fin de période de cohabitation IPv4/IPv6, lorsque les réseaux IPv6 sont dévenus majoritaires. Dans ce cas, DSTM peut typiquement s'appliquer soit à un réseau d'entreprise, soit à un réseau d'ISP.<br />
<br />
DSTM se place dans la situation où une partie d'un site est passée en IPv6, mais où certaines applications continuent à utiliser IPv4. DSTM utilise une interface spéciale DTI (''Dynamic Tunneling Interface'') qui permet l'encapsulation des paquets IPv4 dans des paquets IPv6. Du point de vue de l'application, ce mécanisme est relativement transparent, puisque l'interface DTI est considérée comme une interface réseau classique.<br />
<br />
Un routeur particulier appelé TEP (''Tunnel End Point'') possédant la connectivité entre le monde IPv4 et le monde IPv6 effectue l'encapsulation et la désencapsulation des données.<br />
<br />
Initialement, les interfaces sont actives, mais ne disposent pas d'adresses IPv4, l'attribution d'une adresse n'est faite que lorsqu'un premier paquet est routé vers l'interface DTI. Dans ce cas, une demande d'allocation est envoyée par la machine à un serveur et une adresse IPv4 est allouée pendant la durée d'utilisation de l'interface DTI. Les paquets IPv4 sont envoyés à un TEP dont l'adresse IPv6 est généralement obtenue en même temps que l'adresse IPv4 temporaire. Le TEP garde en mémoire la correspondance entre les adresses sources IPv4 et IPv6 des paquets qu'il reçoit. De cette manière quand le destinataire sur le réseau IPv4 répond, le TEP peut déterminer vers quel équipement il peut tunneler les paquets.<br />
<br />
[[image:CS188.gif]]<br />
<br />
L'usage de DSTM permet de ne configurer que la pile IPv6 d'un équipement. La pile IPv4 est configurée à la demande en fonction des besoins applicatifs. Le travail de configuation, de routage et de supervision de l'administrateur est donc simplifié.<br />
<br />
Le fait d'utiliser des tunnels facilite l'allocation des adresses IPv4, car celles-ci perdent leur fonction de localisation, elles doivent juste conserver leur propriété d'unicité, ce qui est relativement facile à garantir.<br />
<br />
==NAT-PT==<br />
<br />
Le principe reste identique à celui de NAT pour IPv4. Il s'agit ici de traduire les en-têtes des datagrammes IPv6 en en-têtes de datagrammes IPv4. NAT-PT permet le déploiement de réseaux uniquement IPv6 et offrir une « compatibilité » avec le monde IPv4. Les boitiers NAT-PT sont des routeurs réalisant la traduction des paquets IPv6 en paquets IPv4 et servant de proxy DNS. Les autres équipements du réseau (derrière le boitier NAT-PT) n'ont besoin de rien de spécial pour que ce mécanisme puisse être utilisé.<br />
<br />
* NAT-PT permet de s'affranchir d'IPv4 tout en permettant de continuer à bénéficier des services qui lui sont encore associés. Ce mécanisme introduit apres la phase de mise en ?uvre (qui n'est pas très simple) un réel allègement de la tâche de l'administrateur.<br />
* Le mécanisme NAT-PT est en discussion dans le groupe v6ops de l'IETF pour être classé historique, son usage semble devoir être limité (voire confiné) à des situations qui ne peuvent être gérées autrement. Un document de travail inventorie les scénarios qui en ont « absolument » besoin et tente de proposer des mécanismes de remplacement.<br />
<br />
Le principe de fonctionnement de NAT-PT pour passer d'une version à l'autre du protocole IP est le même que pour passer d'un adressage privé à une adressage public, avec également les mêmes limitations, par exemple, si les paquets transportent des adresses. Par contre, ce mécanisme offre une certaine transparence au niveau du réseau.<br />
<br />
Les paquets émis vers un équipement uniquement IPv4 utilisent l'adresse IPv4 mappée. Par contre, l'adresse source est une des adresses IPv6 globale que possède la machine émettrice. Le préfixe des adresses IPv4 mappées est routé vers un boîtier de traduction. Ce dernier dispose d'un poule d'adresses IPv4 officielles. Quand une nouvelle session est initiée par une machine IPv6, le boîtier alloue à la nouvelle adresse IPv6, une adresse IPv4 du poule, et construit un paquet IPv4 en extrayant de l'adresse IPv4, l'adresse IPv4 mappée de destination.</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=M%C3%A9canismes_d%27interop%C3%A9rabilit%C3%A9&diff=2945Mécanismes d'interopérabilité2006-02-27T10:17:43Z<p>Bruno Deniaud: /* Relais applicatifs */</p>
<hr />
<div>==Relais applicatifs==<br />
<br />
Un relais applicatif est une machine avec une double pile IP configurée pour accéder aux deux versions du protocole. Les équipements IPv6 émettent leurs requêtes vers un relais applicatif qui interprète le contenu de la requête et la retransmet en IPv4.<br />
<br />
Un ou plusieurs relais peuvent être installés en fonction des services rendus disponibles sur le réseau (par exemple serveur d'impression, serveur de messagerie, relais http, ...). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces relais.<br />
<br />
L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les relais applicatifs, par exemple telnet. Mais comme la liste précédente l'indique, les ALG (''Application Level Gateway'') concernent des applications courantes qui représentent une partie importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.<br />
<br />
Les relais applicatifs ou ALG (''Application Level Gateway'') représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure Exemple de relais applicatif pour le courrier électronique) configurées pour accéder aux deux versions du protocole. Les équipements IPv6 émettent leur requête vers le relais applicatif qui interprète le contenu de la requête et la retransmet en IPv4.<br />
<br />
[[image:CS186.gif]]<br />
<br />
Ils regroupent :<br />
<br />
* les proxies et les caches web,<br />
* les spoolers d'impression,<br />
* les serveurs de courrier électronique,<br />
* les serveurs DNS,<br />
* ...<br />
<br />
===Configuration d'un relais applicatif pour le Web===<br />
<br />
Le listing suivant donne un extrait de la configuration d'un serveur apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.<br />
<br />
#cat /usr/local/etc/apache/httpd.conf<br />
#<br />
# Proxy Server directives. Uncomment the following lines to<br />
# enable the proxy server:<br />
#<br />
<IfModule mod_proxy.c><br />
ProxyRequests On<br />
<Directory proxy:*><br />
Order deny,allow<br />
Allow from all<br />
</Directory><br />
#<br />
# Enable/disable the handling of HTTP/1.1 "Via:" headers.<br />
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)<br />
# Set to one of: Off | On | Full | Block<br />
#<br />
ProxyVia On<br />
</IfModule><br />
# End of proxy directives.<br />
<br />
==SOCKS==<br />
<br />
Cette technique est aussi issue des solutions pour passer d'un adressage privé à un adressage public. SOCKS ajoute un "canal de signalisation" aux données transportées, ce qui permet de piloter à distance l'ouverture de connexion. En IPv4, cette technique permet d'utiliser un adressage privé en interne pour atteindre un relais SOCKS qui se trouve dans une zone démilitarisée. Le relais SOCKS se charge d'ouvrir une connexion normale avec l'équipement distant. Le relais SOCKS se plaçant dans le modèle architectural en dessous de l'application, il est relativement indépendant de celle-ci, il n'est pas nécessaire de recourir à différents types de relais. De plus, SOCKS permet aussi bien les communications entrantes que sortantes.<br />
<br />
SOCKS s'applique à tout type de réseau, ainsi qu'à des réseaux utilisant l'adressage privé IPv4.<br />
<br />
Le RFC 3089 étend ce mécanisme en permettant les deux versions du protocole IP. Quatre scénarios sont possibles, comme l'indique la figure suivante :<br />
<br />
[[image:CS187.gif]]<br />
<br />
* les protocoles X et Y sont IPv4. On est dans le cadre d'une utilisation classique de SOCKS telle qu'elle est prévue dans le RFC 1928 initial pour permettre à des équipements utilisant un plan d'adressage privé d'accéder aux ressources de l'Internet et de contrôler l'accès au réseau.<br />
* le protocole X est IPv4 et le protocole Y est IPv6. Ce scénario permet de v6fier une application ne connaissant qu'IPv4.<br />
* le protocole X est IPv6 et le protocole Y est IPv4. Ce scénario permet à une application IPv6 d'accéder à des ressources uniquement disponibles en IPv4<br />
* les protocoles X et Y sont IPv6. Vu la taille des adresses IPv6, il est peu probable qu'il y ait toujours un plan d'adressage privé, non routable sur l'Internet. L'utilisation de SOCKS dans ce cas serait surtout pour contrôler l'usage des ressources réseau.<br />
<br />
Le RFC 3089 prévoit aussi l'enchaînement de plusieurs relais SOCKS.<br />
<br />
La principale difficulté introduite par l'utilisation de SOCKS pour la transition provient de l'interrogation du DNS. Dans le cas du deuxième scénario, où X vaut 4 et Y vaut 6, l'application ne peut que manipuler des adresses IPv4. En particulier les appels aux serveurs DNS pour la résolution de nom ne portent que sur des ''Resource Records'' de type <tt>A</tt>.<br />
<br />
Le RFC 1928 prévoit que dans la partie "signalisation", le nom de l'équipement distant peut être envoyé de trois manières différentes :<br />
<br />
* une adresse IPv4,<br />
* un nom de machine,<br />
* une adresse IPv6.<br />
<br />
Si l'application utilise un nom de machine (FQDN : ''Fully Qualified Domain Name''), SOCKS intercepte l'appel procédural pour la résolution et retourne à l'application une fausse adresse IP prise dans un poule. Quand l'application ouvre une connexion en utilisant cette adresse, le nom de la machine distante peut être retrouvé et est envoyé au relais SOCKS qui pourra, si le DNS retourne un enregistrement <tt>AAAA</tt>, ouvrir la connexion en utilisant le protocole IPv6.<br />
<br />
==DSTM==<br />
<br />
L'objectif de DSTM (''Dual Stack Transition Mechanism'') est de donner une connectivité IPv4 temporaire à un terminal dual-stack connecté à un réseau uniquement IPv6. La connectivité IPv4 n'est disponible que le temps nécessaire à une communication avec un terminal distant qui ne possède qu'une pile IPv4. Dans le principe, DSTM est en quelque sorte la réciproque du Tunnel Broker.<br />
<br />
En général DSTM est identifié comme un mécanisme intervenant en fin de période de cohabitation IPv4/IPv6, lorsque les réseaux IPv6 sont dévenus majoritaires. Dans ce cas, DSTM peut typiquement s'appliquer soit à un réseau d'entreprise, soit à un réseau d'ISP.<br />
<br />
DSTM se place dans la situation où une partie d'un site est passée en IPv6, mais où certaines applications continuent à utiliser IPv4. DSTM utilise une interface spéciale DTI (''Dynamic Tunneling Interface'') qui permet l'encapsulation des paquets IPv4 dans des paquets IPv6. Du point de vue de l'application, ce mécanisme est relativement transparent, puisque l'interface DTI est considérée comme une interface réseau classique.<br />
<br />
Un routeur particulier appelé TEP (''Tunnel End Point'') possédant la connectivité entre le monde IPv4 et le monde IPv6 effectue l'encapsulation et la désencapsulation des données.<br />
<br />
Initialement, les interfaces sont actives, mais ne disposent pas d'adresses IPv4, l'attribution d'une adresse n'est faite que lorsqu'un premier paquet est routé vers l'interface DTI. Dans ce cas, une demande d'allocation est envoyée par la machine à un serveur et une adresse IPv4 est allouée pendant la durée d'utilisation de l'interface DTI. Les paquets IPv4 sont envoyés à un TEP dont l'adresse IPv6 est généralement obtenue en même temps que l'adresse IPv4 temporaire. Le TEP garde en mémoire la correspondance entre les adresses sources IPv4 et IPv6 des paquets qu'il reçoit. De cette manière quand le destinataire sur le réseau IPv4 répond, le TEP peut déterminer vers quel équipement il peut tunneler les paquets.<br />
<br />
[[image:CS188.gif]]<br />
<br />
L'usage de DSTM permet de ne configurer que la pile IPv6 d'un équipement. La pile IPv4 est configurée à la demande en fonction des besoins applicatifs. Le travail de configuation, de routage et de supervision de l'administrateur est donc simplifié.<br />
<br />
Le fait d'utiliser des tunnels facilite l'allocation des adresses IPv4, car celles-ci perdent leur fonction de localisation, elles doivent juste conserver leur propriété d'unicité, ce qui est relativement facile à garantir.<br />
<br />
==NAT-PT==<br />
<br />
Le principe reste identique à celui de NAT pour IPv4. Il s'agit ici de traduire les en-têtes des datagrammes IPv6 en en-têtes de datagrammes IPv4. NAT-PT permet le déploiement de réseaux uniquement IPv6 et offrir une « compatibilité » avec le monde IPv4. Les boitiers NAT-PT sont des routeurs réalisant la traduction des paquets IPv6 en paquets IPv4 et servant de proxy DNS. Les autres équipements du réseau (derrière le boitier NAT-PT) n'ont besoin de rien de spécial pour que ce mécanisme puisse être utilisé.<br />
<br />
* NAT-PT permet de s'affranchir d'IPv4 tout en permettant de continuer à bénéficier des services qui lui sont encore associés. Ce mécanisme introduit apres la phase de mise en ?uvre (qui n'est pas très simple) un réel allègement de la tâche de l'administrateur.<br />
* Le mécanisme NAT-PT est en discussion dans le groupe v6ops de l'IETF pour être classé historique, son usage semble devoir être limité (voire confiné) à des situations qui ne peuvent être gérées autrement. Un document de travail inventorie les scénarios qui en ont « absolument » besoin et tente de proposer des mécanismes de remplacement.<br />
<br />
Le principe de fonctionnement de NAT-PT pour passer d'une version à l'autre du protocole IP est le même que pour passer d'un adressage privé à une adressage public, avec également les mêmes limitations, par exemple, si les paquets transportent des adresses. Par contre, ce mécanisme offre une certaine transparence au niveau du réseau.<br />
<br />
Les paquets émis vers un équipement uniquement IPv4 utilisent l'adresse IPv4 mappée. Par contre, l'adresse source est une des adresses IPv6 globale que possède la machine émettrice. Le préfixe des adresses IPv4 mappées est routé vers un boîtier de traduction. Ce dernier dispose d'un poule d'adresses IPv4 officielles. Quand une nouvelle session est initiée par une machine IPv6, le boîtier alloue à la nouvelle adresse IPv6, une adresse IPv4 du poule, et construit un paquet IPv4 en extrayant de l'adresse IPv4, l'adresse IPv4 mappée de destination.</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=M%C3%A9canismes_d%27interop%C3%A9rabilit%C3%A9&diff=2944Mécanismes d'interopérabilité2006-02-27T10:17:15Z<p>Bruno Deniaud: /* Relais applicatifs */</p>
<hr />
<div>==Relais applicatifs==<br />
<br />
Un relais applicatif est une machine avec une double pile IP configurée pour accéder aux deux versions du protocole. Les équipements IPv6 émettent leurs requêtes vers un relais applicatif qui interprète le contenu de la requête et la retransmet en IPv4.<br />
<br />
Un ou plusieurs relais peuvent être installés en fonction des services rendus disponibles sur le réseau (par exemple serveur d'impression, serveur de messagerie, relais http, ...). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces relais.<br />
<br />
L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les relais applicatifs, par exemple telnet. Mais comme la liste précédente l'indique, les ALG concernent des applications courantes qui représentent une partie importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.<br />
<br />
Les relais applicatifs ou ALG (''Application Level Gateway'') représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure Exemple de relais applicatif pour le courrier électronique) configurées pour accéder aux deux versions du protocole. Les équipements IPv6 émettent leur requête vers le relais applicatif qui interprète le contenu de la requête et la retransmet en IPv4.<br />
<br />
[[image:CS186.gif]]<br />
<br />
Ils regroupent :<br />
<br />
* les proxies et les caches web,<br />
* les spoolers d'impression,<br />
* les serveurs de courrier électronique,<br />
* les serveurs DNS,<br />
* ...<br />
<br />
===Configuration d'un relais applicatif pour le Web===<br />
<br />
Le listing suivant donne un extrait de la configuration d'un serveur apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.<br />
<br />
#cat /usr/local/etc/apache/httpd.conf<br />
#<br />
# Proxy Server directives. Uncomment the following lines to<br />
# enable the proxy server:<br />
#<br />
<IfModule mod_proxy.c><br />
ProxyRequests On<br />
<Directory proxy:*><br />
Order deny,allow<br />
Allow from all<br />
</Directory><br />
#<br />
# Enable/disable the handling of HTTP/1.1 "Via:" headers.<br />
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)<br />
# Set to one of: Off | On | Full | Block<br />
#<br />
ProxyVia On<br />
</IfModule><br />
# End of proxy directives.<br />
<br />
==SOCKS==<br />
<br />
Cette technique est aussi issue des solutions pour passer d'un adressage privé à un adressage public. SOCKS ajoute un "canal de signalisation" aux données transportées, ce qui permet de piloter à distance l'ouverture de connexion. En IPv4, cette technique permet d'utiliser un adressage privé en interne pour atteindre un relais SOCKS qui se trouve dans une zone démilitarisée. Le relais SOCKS se charge d'ouvrir une connexion normale avec l'équipement distant. Le relais SOCKS se plaçant dans le modèle architectural en dessous de l'application, il est relativement indépendant de celle-ci, il n'est pas nécessaire de recourir à différents types de relais. De plus, SOCKS permet aussi bien les communications entrantes que sortantes.<br />
<br />
SOCKS s'applique à tout type de réseau, ainsi qu'à des réseaux utilisant l'adressage privé IPv4.<br />
<br />
Le RFC 3089 étend ce mécanisme en permettant les deux versions du protocole IP. Quatre scénarios sont possibles, comme l'indique la figure suivante :<br />
<br />
[[image:CS187.gif]]<br />
<br />
* les protocoles X et Y sont IPv4. On est dans le cadre d'une utilisation classique de SOCKS telle qu'elle est prévue dans le RFC 1928 initial pour permettre à des équipements utilisant un plan d'adressage privé d'accéder aux ressources de l'Internet et de contrôler l'accès au réseau.<br />
* le protocole X est IPv4 et le protocole Y est IPv6. Ce scénario permet de v6fier une application ne connaissant qu'IPv4.<br />
* le protocole X est IPv6 et le protocole Y est IPv4. Ce scénario permet à une application IPv6 d'accéder à des ressources uniquement disponibles en IPv4<br />
* les protocoles X et Y sont IPv6. Vu la taille des adresses IPv6, il est peu probable qu'il y ait toujours un plan d'adressage privé, non routable sur l'Internet. L'utilisation de SOCKS dans ce cas serait surtout pour contrôler l'usage des ressources réseau.<br />
<br />
Le RFC 3089 prévoit aussi l'enchaînement de plusieurs relais SOCKS.<br />
<br />
La principale difficulté introduite par l'utilisation de SOCKS pour la transition provient de l'interrogation du DNS. Dans le cas du deuxième scénario, où X vaut 4 et Y vaut 6, l'application ne peut que manipuler des adresses IPv4. En particulier les appels aux serveurs DNS pour la résolution de nom ne portent que sur des ''Resource Records'' de type <tt>A</tt>.<br />
<br />
Le RFC 1928 prévoit que dans la partie "signalisation", le nom de l'équipement distant peut être envoyé de trois manières différentes :<br />
<br />
* une adresse IPv4,<br />
* un nom de machine,<br />
* une adresse IPv6.<br />
<br />
Si l'application utilise un nom de machine (FQDN : ''Fully Qualified Domain Name''), SOCKS intercepte l'appel procédural pour la résolution et retourne à l'application une fausse adresse IP prise dans un poule. Quand l'application ouvre une connexion en utilisant cette adresse, le nom de la machine distante peut être retrouvé et est envoyé au relais SOCKS qui pourra, si le DNS retourne un enregistrement <tt>AAAA</tt>, ouvrir la connexion en utilisant le protocole IPv6.<br />
<br />
==DSTM==<br />
<br />
L'objectif de DSTM (''Dual Stack Transition Mechanism'') est de donner une connectivité IPv4 temporaire à un terminal dual-stack connecté à un réseau uniquement IPv6. La connectivité IPv4 n'est disponible que le temps nécessaire à une communication avec un terminal distant qui ne possède qu'une pile IPv4. Dans le principe, DSTM est en quelque sorte la réciproque du Tunnel Broker.<br />
<br />
En général DSTM est identifié comme un mécanisme intervenant en fin de période de cohabitation IPv4/IPv6, lorsque les réseaux IPv6 sont dévenus majoritaires. Dans ce cas, DSTM peut typiquement s'appliquer soit à un réseau d'entreprise, soit à un réseau d'ISP.<br />
<br />
DSTM se place dans la situation où une partie d'un site est passée en IPv6, mais où certaines applications continuent à utiliser IPv4. DSTM utilise une interface spéciale DTI (''Dynamic Tunneling Interface'') qui permet l'encapsulation des paquets IPv4 dans des paquets IPv6. Du point de vue de l'application, ce mécanisme est relativement transparent, puisque l'interface DTI est considérée comme une interface réseau classique.<br />
<br />
Un routeur particulier appelé TEP (''Tunnel End Point'') possédant la connectivité entre le monde IPv4 et le monde IPv6 effectue l'encapsulation et la désencapsulation des données.<br />
<br />
Initialement, les interfaces sont actives, mais ne disposent pas d'adresses IPv4, l'attribution d'une adresse n'est faite que lorsqu'un premier paquet est routé vers l'interface DTI. Dans ce cas, une demande d'allocation est envoyée par la machine à un serveur et une adresse IPv4 est allouée pendant la durée d'utilisation de l'interface DTI. Les paquets IPv4 sont envoyés à un TEP dont l'adresse IPv6 est généralement obtenue en même temps que l'adresse IPv4 temporaire. Le TEP garde en mémoire la correspondance entre les adresses sources IPv4 et IPv6 des paquets qu'il reçoit. De cette manière quand le destinataire sur le réseau IPv4 répond, le TEP peut déterminer vers quel équipement il peut tunneler les paquets.<br />
<br />
[[image:CS188.gif]]<br />
<br />
L'usage de DSTM permet de ne configurer que la pile IPv6 d'un équipement. La pile IPv4 est configurée à la demande en fonction des besoins applicatifs. Le travail de configuation, de routage et de supervision de l'administrateur est donc simplifié.<br />
<br />
Le fait d'utiliser des tunnels facilite l'allocation des adresses IPv4, car celles-ci perdent leur fonction de localisation, elles doivent juste conserver leur propriété d'unicité, ce qui est relativement facile à garantir.<br />
<br />
==NAT-PT==<br />
<br />
Le principe reste identique à celui de NAT pour IPv4. Il s'agit ici de traduire les en-têtes des datagrammes IPv6 en en-têtes de datagrammes IPv4. NAT-PT permet le déploiement de réseaux uniquement IPv6 et offrir une « compatibilité » avec le monde IPv4. Les boitiers NAT-PT sont des routeurs réalisant la traduction des paquets IPv6 en paquets IPv4 et servant de proxy DNS. Les autres équipements du réseau (derrière le boitier NAT-PT) n'ont besoin de rien de spécial pour que ce mécanisme puisse être utilisé.<br />
<br />
* NAT-PT permet de s'affranchir d'IPv4 tout en permettant de continuer à bénéficier des services qui lui sont encore associés. Ce mécanisme introduit apres la phase de mise en ?uvre (qui n'est pas très simple) un réel allègement de la tâche de l'administrateur.<br />
* Le mécanisme NAT-PT est en discussion dans le groupe v6ops de l'IETF pour être classé historique, son usage semble devoir être limité (voire confiné) à des situations qui ne peuvent être gérées autrement. Un document de travail inventorie les scénarios qui en ont « absolument » besoin et tente de proposer des mécanismes de remplacement.<br />
<br />
Le principe de fonctionnement de NAT-PT pour passer d'une version à l'autre du protocole IP est le même que pour passer d'un adressage privé à une adressage public, avec également les mêmes limitations, par exemple, si les paquets transportent des adresses. Par contre, ce mécanisme offre une certaine transparence au niveau du réseau.<br />
<br />
Les paquets émis vers un équipement uniquement IPv4 utilisent l'adresse IPv4 mappée. Par contre, l'adresse source est une des adresses IPv6 globale que possède la machine émettrice. Le préfixe des adresses IPv4 mappées est routé vers un boîtier de traduction. Ce dernier dispose d'un poule d'adresses IPv4 officielles. Quand une nouvelle session est initiée par une machine IPv6, le boîtier alloue à la nouvelle adresse IPv6, une adresse IPv4 du poule, et construit un paquet IPv4 en extrayant de l'adresse IPv4, l'adresse IPv4 mappée de destination.</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Talk:Bibliographie&diff=2940Talk:Bibliographie2006-02-24T10:37:37Z<p>Bruno Deniaud: </p>
<hr />
<div>Mmmh mais il ne manquerait pas toute la liste des RFC ssur cette page ?? -- BS<br />
<br />
Legerement ouais. Et du coup y a les les RFC rajoutés dans la liste des Drafts obsolètes a mettre. -- BD<br />
Pour info : RFC 4140, RFC 3484, RFC 4007, RFC 3307, RFC 4193, RFC 4380, RFC 3775, RFC 4364, RFC 4214.</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Talk:Bibliographie&diff=2939Talk:Bibliographie2006-02-24T10:37:06Z<p>Bruno Deniaud: </p>
<hr />
<div>Mmmh mais il ne manquerait pas toute la liste des RFC ssur cette page ?? -- BS<br />
<br />
Legerement ouais. Et du coup y a les les RFC rajoutés dans la liste des Drafts obsolètes a mettre. -- BD<br />
Pour info : RFC 4140, 3484, 4007, 3307, 4193, 4380, 3775, 4364, 4214.</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Talk:Bibliographie&diff=2938Talk:Bibliographie2006-02-24T10:34:56Z<p>Bruno Deniaud: </p>
<hr />
<div>Mmmh mais il ne manquerait pas toute la liste des RFC ssur cette page ?? -- BS<br />
<br />
Legerement ouais. Et du coup y a les les RFC rajoutés dans la liste des Drafts obsolètes a mettre. -- BD</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Bibliographie&diff=2935Bibliographie2006-02-24T10:04:43Z<p>Bruno Deniaud: /* Internet Drafts sur IPv6 */</p>
<hr />
<div>= Livres sur IPv6 =<br />
<br />
<div id="BM95">[BM95] S. O. Bradner & A. Mankin ed : IPng, Internet Protocol Next Generation, Addison-Wesley (IPng Series), ISBN0201633957, Septembre 1995.</div><br />
<br />
[Gai98] S. Gai, Internetworking IPv6 With Cisco Routers (Computer Communications), McGraw-Hill, ISBN: 0-070-22836-1, Février 1998.<br />
<br />
[Hui97] C. Huitema: IPv6: The New Internet Protocol, Prentice Hall, ISBN: 0-138-50505-5, Octbre 1997.<br />
<br />
[LL99] Peter Loshin & Pete Loshin: IPv6 Clearly Explained (Clearly Explained), Ap Professional, ISBN: 0-124-55838-0, Janvier 1999.<br />
<br />
[MM00] Mark A. Miller & P. E. Miller: Implementing IPv6, second edition (Network Troubleshooting Library), IDG Books Worldwide, ISBN: 0-764-54589-2, Janvier 2000.<br />
<br />
<br />
[Mil97] Stewart S. Miller: IPv6 : The Next Generation Internet Protocol, DigitalPress, ISBN: 1-555-58188-9, Décembre 1997.<br />
<br />
[MK98] Marcus Goncalves & Kitty Niles: IPv6 Networks, McGraw-Hill, ISBN: 0-070-24807-9, Mai 1998.<br />
<br />
[Sal00] Peter H. Salus: Big Book of IPV6 Addressing RFCs, Morgan Kaufmann Publishers, ISBN: 0-126-16770-2, Mars 2000.<br />
<br />
[WR99] J. D. Wegner & Robert Rockwell: IP Addressing and Subnetting, Including IPv6, Syngress Media, ISBN: 1-928-99401-6, Décembre 1999.<br />
<br />
== Internet Drafts sur IPv6 ==<br />
<br />
''Remarque : Il faut rappeler que les Internet drafts sont des documents de travail à durée de vie limitée. Ils ont vocation à devenir des RFC. Le lecteur est donc invité à vérifier quelle est la version la plus récente, ou si un RFC le remplace, en consultant l'index à jour (cf. Les RFC (Request For Comments)).''<br />
<br />
;<div id="BCP2-id">[BCP2-id]</div><br />
: J. Bound, M. Carney, C. Perkins: Extensions for the Dynamic Host Configuration Protocol for IPv6, [http://www.watersprings.org/pub/id/draft-ietf-dhcpv6exts-12.txt draft-ietf-dhc-v6exts-12.txt], Internet Draft, 5 Mai 2000 - Obsolete.<br />
<br />
;<div id="BKLSPTSDY-id">[BKLSPTSDY-id]</div><br />
: W. Biemolt, M. Kaat, T. Larder, H. Steenman, R. van der Pol, G. Tsirtsis, Y. Sekiya, A. Durand, K. Yamamoto: On overview of the introduction of IPv6 in the Internet, draft-ietf-ngtrans-introduction-to-ipv6-transition-08.txt, Internet Draft, Février 2002. Working Group Concluded.<br />
<br />
;<div id="BTM-id>[BTM-id]</div><br />
: J. Bound, L. Toutain, O. Medina, F. Dupont, A. Durand, H Afifi,: Dual Stack Transition Mechanism (DSTM), draft-ietf-ngtrans-dstm-07.txt, Internet Draft, Aout 2002. Obsolete.<br />
<br />
;<div id="BP-id">[BP-id]</div><br />
: M. Blanchet, F. Parent, IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP), [http://www.watersprings.org/pub/id/draft-blanchet-v6ops-tunnelbroker-tsp-03.txt draft-blanchet-v6ops-tunnelbroker-tsp-03.txt], Aout 2005. Work in progress.<br />
<br />
;<div id="CMB-id">[CMB-id]</div><br />
: Hesham Soliman, Claude Castelluccia, Karim Malki, Ludovic Bellier, Hierarchical Mobile IPv6 mobility management (HMIPv6), [http://www.watersprings.org/pub/id/draft-ietf-mipshop-hmipv6-04.txt draft-ietf-mipshop-hmipv6-04.txt], Décembre 04. Obsolete - Experimental RFC 4140.<br />
<br />
;<div id="Craw-id">[Craw-id]</div><br />
: Matt Crawford: IPv6 Node Information Queries, [http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-15.txt draft-ietf-ipngwg-icmp-name-lookups-15.txt, Internet Draft, 13 Février 2006. Work in progress.<br />
<br />
;<div id="Drave-id">[Drave-id]</div><br />
: R. Draves: Default Address Selection for IPv6, draft-ietf-ipngwg-default-addr-select-06.txt, Internet Draft, 28 Septembre 2001. Obsolete - RFC 3484.<br />
<br />
;<div id="DHZ-id">[DHZ-id]</div><br />
: S. Deering, B. Haberman, B. Zill, T. Jinmei, E. Nordmark, A. Onoe: IP Version 6 Scoped Address Architecture, draft-ietf-ipngwg-scoping-arch-03.txt Internet Draft, 30 Novembre 2001. Obsolete - RFC 4007.<br />
<br />
;<div id="DIS-id">[DIS-id]</div><br />
: Alain Durand, Johan Ihren, Pekka Savola, Operational Considerations and Issues with IPv6 DNS, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-issues-12.txt draft-ietf-dnsop-ipv6-dns-issues-12.txt], Internet Draft, 19 Octobre 2005,. Work in progress. <br />
<br />
;<div id="Dupont-id">[Dupont-id]</div><br />
: F. Dupont, M. Laurent-Maknavicius: AAA for mobile IPv6, draft-dupont-mipv6-AAA-01.txt, Internet Draft, 20 Novembre 2001, Obsolete.<br />
<br />
;<div id="Ernst-id">[Ernst-id]</div><br />
: Thierry Ernst, Network Mobility Support Requirements, [http://www.watersprings.org/pub/id/draft-ietf-nemo-requirements-05.txt draft-ietf-nemo-requirements-05.txt], Octobre 2005<br />
<br />
;<div id="Fenner-id">[Fenner-id]</div><br />
: Bill Fenner, Haixiang He, Brian Haberman, Hal Sandick, IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying'), [http://www.watersprings.org/pub/id/draft-ietf-magma-igmp-proxy-06.txt draft-ietf-magma-igmp-proxy-06.txt]<br />
<br />
;<div id="Fenner2-id">[Fenner2-id]</div><br />
: Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas Protocol Independent Multicast - Sparse Mode (PIM -SM): Protocol Specification (Revised), IETF Internet Draft, [http://www.watersprings.org/pub/id/draft-ietf-pim-sm-v2-new-11.txt draft-ietf-pim-sm-v2-new-11.txt], 4 Octobre 2004. Work in progress.<br />
<br />
;<div id="Haber-id">[Haber-id]</div><br />
: B. Haberman: Dynamic Allocation Guidelines for IPv6 Multicast Addresses, draft-ietf-malloc-ipv6-guide-01.txt, Internet Draft, 12 Octobre 2000. Obsolete - RFC 3307.<br />
<br />
;<div id="HD-id">[HD-id]</div><br />
: R. Hinden, S. Deering: IP Version 6 Addressing Architecture, [[http://tools.ietf.org/wg/ipv6/draft-ietf-ipv6-addr-arch-v4/draft-ietf-ipv6-addr-arch-v4-04.txt draft-ietf-ipv6-addr-arch-v4-04.txt]], Internet Draft, 20 Mai 2005. Work in progress.<br />
<br />
;<div id="HH-id">[HH-id]</div><br />
: Robert Hinden, Brian Haberman, Centrally Assigned Unique Local IPv6 Unicast Addresses, [http://www.watersprings.org/pub/id/draft-ietf-ipv6-ula-central-01.txt draft-ietf-ipv6-ula-central-01.txt], Internet Draft, 21 Février 2005, Obsolete - See RFC 4193.<br />
<br />
;<div id="Hopps-if">[Hopps-id]</div><br />
: C. E. Hopps: Routing IPv6 with IS-IS, [http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-06.txt draft-ietf-isis-ipv6-06.txt], Internet Draft, Octobre 2005. Work in progress.<br />
<br />
;<div id="Huitema-id">[Huitéma-id]</div><br />
: C. Huitema, Teredo: Tunneling IPv6 over UDP through NATs, [http://www.watersprings.org/pub/id/draft-huitema-v6ops-teredo-05.txt draft-huitema-v6ops-teredo-05.txt], Avril 2005, Obsolete - See RFC 4380.<br />
<br />
;<div id="Jeong-id">[Jeong-id]</div><br />
: Jae-Hoon Jeong, IPv6 Host Configuration of DNS Server Information Approaches, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-configuration-06.txt draft-ietf-dnsop-ipv6-dns-configuration-06.txt], Internet Draft, 5 Mai 2005. RFC Editor Queue.<br />
<br />
;<div id="JP-id">[JP-id]</div><br />
: D. B. Johnson, C. Perkins: Mobility Support in IPv6, draft-ietf-mobileip-ipv6-15.txt, Internet Draft, 2 Juillet 2001. Obsolete - RFC 3775.<br />
<br />
; <div id="NFG-id">[NGF-id]</div><br />
: Tri Nguyen, Gerard Gastaud, Francois Le Faucheur, Dirk Ooms, Jeremy De Clercq, Stuart Prevost, Connecting IPv6 Domains across IPv4 Clouds with BGP, [http://tools.ietf.org/wg/v6ops/draft-ooms-v6ops-bgp-tunnel-06.txt draft-ooms-v6ops-bgp-tunnel-06.txt], Janvier 2006. Proposed standard.<br />
<br />
;<div id="NPE-id">[NPE-id]</div><br />
: Chan Wah Ng, Eun Kyoung Paik, Thierry Ernst, Analysis of Multihoming in Network Mobility Support, [http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-04.txt draft-ietf-nemo-multihoming-issues-04.txt], 24 Octobre 2005. Work in progress<br />
<br />
;<div id="Prz-id">[Prz-id]</div><br />
: Tony Przygienda, M-ISIS: Multi Topology (MT) Routing in IS-IS, [http://www.watersprings.org/pub/id/draft-ietf-isis-wg-multi-topology-11.txt draft-ietf-isis-wg-multi-topology-11.txt], 21 Octobre 2005.<br />
<br />
;<div id="Prigent-id">[Prigent-id]</div><br />
: N. Prigent, J. Marchand, F. Dupont, B. Cousin, M. Laurent-Maknavicius, J. Bournelle: DHCPv6 Threats, draft-prigent-dhcpv6-threats-00.txt, Internet Draft, 24 mai 2001, Expired.<br />
<br />
;<div id="RFC2547bis">[RFC2547bis]</div><br />
: Eric C. Rosen, Yakov Rekhter, BGP/MPLS IP VPNs, [http://www.watersprings.org/pub/id/draft-ietf-l3vpn-rfc2547bis-03.txt draft-ietf-l3vpn-rfc2547bis-03.txt], Internet Draft, October 2004, Obsolete - RFC 4364.<br />
<br />
;<div id="Templin-id">[Templin-id]</div><br />
:Fred Templin, T. Gleeson, M. Talwar D. Thaler, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), [http://www.watersprings.org/pub/id/draft-ietf-ngtrans-isatap-24.txt draft-ietf-ngtrans-isatap-24.txt], Juillet 2005, Obsolete - RFC 4214.<br />
<br />
;<div id="Thubert-id">[Thubert-id]</div><br />
:Pascal Thubert, NEMO Home Network models, [http://www.watersprings.org/pub/id/draft-ietf-nemo-home-network-models-06.txt draft-ietf-nemo-home-network-models-06.txt], 17 Fevrier 2006.<br />
<br />
==Autres documents de travail==<br />
[FIPS-46]<br />
<br />
Data Encryption Standard, Federal Information Processing Standards Publication 46, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 15 Janvier 1977.<br />
<br />
[FIPS-81]<br />
<br />
DES Modes of Operation, Federal Information Processing Standards Publication 81, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 2 Décembre 1980.<br />
<br />
[FIPS-180-1]<br />
<br />
Secure Hash Standard, Federal Information Processing Standards Publication 180-1, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, Avril 1995.<br />
<br />
==Autres Références==<br />
[AL00]<br />
<br />
Mohammed Achemlal, Maryline Laurent, Analyse des fonctions des protocoles IPsec et leur intégration dans un réseau privé virtuel, Annales des télécommunications, 2000.<br />
<br />
<br />
[AL98]<br />
<br />
P. Albitz and C. Liu: DNS and BIND, 3rd Edition, ISBN: 1-56592-512-2, O'Reilly and Associates, Septembre 1998.<br />
<br />
<br />
;<div id="BTC02">[BTC02]</div><br />
: T. Bu, L. Gao, D. Towsley, On Characterizing Routing Table Growth, GlobalInternet 2002. http://www-unix.ecs.umass.edu/~lgao/globalinternet2002_tian.pdf<br />
<br />
<br />
;<div id="Ernst01f-fr">[Ernst01f-fr]</div><br />
:Ernst, Thierry, Le Support des Réseaux Mobiles dans IPv6, UniversitéJoseph Fourier, Octobre 2001, Grenoble, France, http://www.inria.fr/rrrt/tu-0714.html<br />
<br />
<br />
;<div id="Ernst03f">[Ernst03f]</div><br />
:Thierry Ernst, Le Support des Réseaux Mobiles dans IPv6, CFIP: Colloque Francophone sur l'Ingenierie des Protocoles, Octobre 2003, Paris<br />
<br />
<br />
[Fen-id]<br />
<br />
Bill Fenner, Management Information Base for the User Datagram Protocol (UDP), draft-ietf-ipv6-rfc2013-update-04.txt, Internet Draft, 20 Octobre 2004, Work in progress.<br />
<br />
<br />
[Hui95]<br />
<br />
C. Huitema: Le routage dans l'Internet, Eyrolles, Octobre 1995.<br />
<br />
[IEEE]<br />
<br />
Protocol Independant Interfaces, IEEE Std 1003.1g, DRAFT~6.6, Mars 1997.<br />
<br />
<br />
[JH-id]<br />
<br />
Jeffrey Haas, Susan Hares, Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), draft-ietf-idr-bgp4-mib-15.txt, Internet Draft, 31 Août 2004, Work in progress.<br />
<br />
<br />
[JM-id]<br />
<br />
Dan Joyal, Vishwas Manral, Management Information Base for OSPFv3, draft-ietf-ospf-ospfv3-mib-09.txt, Internet Draft, 13 Mai 2005, Work in progress.<br />
<br />
<br />
;<div id="Kau-id">[Kau-id]</div><br />
:Charlie Kaufman, Internet Key Exchange (IKEv2) Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-ikev2-17.txt draft-ietf-ipsec-ikev2-17.txt], Internet Draft, 4 Octobre 2004, Work in progress.<br />
<br />
;<div id="LAU03">[LAU03]</div><br />
: M. Laurent-Maknavicius, Le protocole IPsec, [http://www.techniques-ingenieur.fr/affichage/DispIntro.asp?nGcmID=TE7545 TE7545], [http://www.techniques-ingenieur.fr/ Techniques de l'Ingénieur], Sécurité des systèmes d'information, Novembre 2003.<br />
<br />
[LAU04-A]<br />
<br />
M. Laurent-Maknavicius, M. Gardie, LDAP et la certification, Rapport de recherche du GET, 04001 LOR, 2004.<br />
<br />
[LAU04-B]<br />
<br />
M. Laurent-Maknavicius, La sécurité de l'accès distant, Technique et Science Informatiques (TSI), 2004.<br />
<br />
;<div id="MHF-id">[MHF-id]</div><br />
:Ambarish Malpani, Russ Housley, Trevor Freeman, Simple Certificate Validation Protocol (SCVP), [http://www.watersprings.org/pub/id/draft-ietf-pkix-scvp-22.txt draft-ietf-pkix-scvp-22.txt], Internet Draft, Octobre 2005, Work in progress.<br />
<br />
;<div id="Mos-id">[Mos-id]</div><br />
:Robert Moskowitz, Host Identity Protocol, [http://www.watersprings.org/pub/id/draft-ietf-hip-base-04.txt draft-ietf-hip-base-04.txt], Internet Draft, 24 Octobre 2005, Work in progress<br />
<br />
;<div id="Pui02-A">[Pui02-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse critique d'IPsec, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-analyse-rapport/ipsec-analyse-rapport.pdf rapport de recherche 03 004 LOR], 2002.<br />
<br />
;<div id="Pui02-B">[Pui02-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse de l'impact de la mise en oeuvre d'IPsec dans les architectures de Communication, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-interactions-rapport/ipsec-interactions-rapport.pdf rapport de recherche 03 002 LOR], octobre 2002.<br />
<br />
;<div id="Pui03">[Pui03]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects ARP), [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/environnement-reel-1-rapport/environnement-reel-1-rapport.pdf rapport de recherche 03 001 LOR], janvier 2003.<br />
<br />
;<div id="Pui04-A">[Pui04-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Etude des interactions IPsec/DNS, [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/InteractionDNS.pdf rapport de recherche 04002 LOR], 2004.<br />
<br />
;<div id="Pui04-B">[Pui04-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects liés à ICMP), [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/IPsec_ICMP.pdf rapport de recherche 04004 LOR], 2004.<br />
<br />
;<div id="RFC2401bis">[RFC2401bis]</div><br />
: Stephen Kent, Karen Seo, Security Architecture for the Internet Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2401bis-06.txt draft-ietf-ipsec-rfc2401bis-06.txt], Internet Draft, 1 Avril 2005, Work in progress<br />
<br />
<br />
;<div id="RFC2402bis">[RFC2402bis]</div><br />
:Stephen Kent, IP Authentication Header, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2402bis-11.txt draft-ietf-ipsec-rfc2402bis-11.txt], Internet Draft, 21 Mars 2005, Work in progress.<br />
<br />
[Rou-id]<br />
<br />
Shawn Routhier, Management Information Base for the Internet Protocol (IP), draft-ietf-ipv6-rfc2011-update-10.txt; Internet Draft, 24 Mai 2004, Work in progress.<br />
<br />
[Sch95]<br />
<br />
B. Schneier: Applied Cryptography : protocols, algorithms, and source code in C, (second edition), John Wiley & Sons, ISBN: 0-471-12845-7, 1996.<br />
<br />
[Sta99]<br />
<br />
William Stallings: Snmp, Snmpv2, Snmpv3, and Rmon 1 and 2, Addison Wesley, ISBN: 0-201-48534-6, Janvier 1999.<br />
<br />
[Tout03]<br />
<br />
Laurent Toutain: Réseaux Locaux et Internet: des protocoles à l'interconnexion, Troisième édition revue et augmentée, Hermès, ISBN: 2-7462-0670-6, 2003.<br />
<br />
[Uni31]<br />
<br />
ATM Forum: ATM User-Network Interface (UNI) Specification Version 3.1, Prentice Hall, Englewood Cliffs, NJ, Juin 1995.<br />
<br />
[WH-id]<br />
<br />
Margaret Wasserman, Brian Haberman, IP Forwarding Table MIB, draft-ietf-ipv6-rfc2096-update-07.txt, Internet Draft, 12 février 2004, Work in progress.<br />
<br />
[WK99]<br />
<br />
M. Welsh et L. Kaufman: Le système Linux, 2e édition révisée, Éditions O'Reilly, ISBN: 2-84177-033-8, Janvier 1999.<br />
<br />
==Sites Web sur IPv6 ==<br />
<br />
;[IETF]<br />
:http://www.imag.fr/pub/archive/IETF: Mirroir français du serveur de l'IETF.<br />
<br />
;[6bone]<br />
:http://www.6bone.net: Réseau 6bone.<br />
<br />
;[G6bone]<br />
:http://peirce.logique.jussieu.fr/G6/ Réseau G6-bone (partie francophone de 6bone).<br />
<br />
;[hs247] <br />
:http://hs247.com/ Informations sur le 6bone et IPv6 en général.<br />
<br />
;[ipv6.org]<br />
: http://www.ipv6.org/ pages d'information sur le protocole IPv6<br />
<br />
;[ipv6forum] <br />
:http://www.ipv6forum.org/ Groupement d'industriels pour promouvoir IPv6.<br />
<br />
;[playground] <br />
:http://playground.sun.com/pub/ipng/html/ipng-main.html liste des mises en oeuvre d'IPv6 dans les équipements.</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Bibliographie&diff=2934Bibliographie2006-02-24T10:02:23Z<p>Bruno Deniaud: /* Internet Drafts sur IPv6 */</p>
<hr />
<div>= Livres sur IPv6 =<br />
<br />
<div id="BM95">[BM95] S. O. Bradner & A. Mankin ed : IPng, Internet Protocol Next Generation, Addison-Wesley (IPng Series), ISBN0201633957, Septembre 1995.</div><br />
<br />
[Gai98] S. Gai, Internetworking IPv6 With Cisco Routers (Computer Communications), McGraw-Hill, ISBN: 0-070-22836-1, Février 1998.<br />
<br />
[Hui97] C. Huitema: IPv6: The New Internet Protocol, Prentice Hall, ISBN: 0-138-50505-5, Octbre 1997.<br />
<br />
[LL99] Peter Loshin & Pete Loshin: IPv6 Clearly Explained (Clearly Explained), Ap Professional, ISBN: 0-124-55838-0, Janvier 1999.<br />
<br />
[MM00] Mark A. Miller & P. E. Miller: Implementing IPv6, second edition (Network Troubleshooting Library), IDG Books Worldwide, ISBN: 0-764-54589-2, Janvier 2000.<br />
<br />
<br />
[Mil97] Stewart S. Miller: IPv6 : The Next Generation Internet Protocol, DigitalPress, ISBN: 1-555-58188-9, Décembre 1997.<br />
<br />
[MK98] Marcus Goncalves & Kitty Niles: IPv6 Networks, McGraw-Hill, ISBN: 0-070-24807-9, Mai 1998.<br />
<br />
[Sal00] Peter H. Salus: Big Book of IPV6 Addressing RFCs, Morgan Kaufmann Publishers, ISBN: 0-126-16770-2, Mars 2000.<br />
<br />
[WR99] J. D. Wegner & Robert Rockwell: IP Addressing and Subnetting, Including IPv6, Syngress Media, ISBN: 1-928-99401-6, Décembre 1999.<br />
<br />
== Internet Drafts sur IPv6 ==<br />
<br />
''Remarque : Il faut rappeler que les Internet drafts sont des documents de travail à durée de vie limitée. Ils ont vocation à devenir des RFC. Le lecteur est donc invité à vérifier quelle est la version la plus récente, ou si un RFC le remplace, en consultant l'index à jour (cf. Les RFC (Request For Comments)).''<br />
<br />
;<div id="BCP2-id">[BCP2-id]</div><br />
: J. Bound, M. Carney, C. Perkins: Extensions for the Dynamic Host Configuration Protocol for IPv6, [http://www.watersprings.org/pub/id/draft-ietf-dhcpv6exts-12.txt draft-ietf-dhc-v6exts-12.txt], Internet Draft, 5 Mai 2000 - Obsolete.<br />
<br />
;<div id="BKLSPTSDY-id">[BKLSPTSDY-id]</div><br />
: W. Biemolt, M. Kaat, T. Larder, H. Steenman, R. van der Pol, G. Tsirtsis, Y. Sekiya, A. Durand, K. Yamamoto: On overview of the introduction of IPv6 in the Internet, draft-ietf-ngtrans-introduction-to-ipv6-transition-08.txt, Internet Draft, Février 2002. Working Group Concluded.<br />
<br />
;<div id="BTM-id>[BTM-id]</div><br />
: J. Bound, L. Toutain, O. Medina, F. Dupont, A. Durand, H Afifi,: Dual Stack Transition Mechanism (DSTM), draft-ietf-ngtrans-dstm-07.txt, Internet Draft, Aout 2002. Obsolete.<br />
<br />
;<div id="BP-id">[BP-id]</div><br />
: M. Blanchet, F. Parent, IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP), [http://www.watersprings.org/pub/id/draft-blanchet-v6ops-tunnelbroker-tsp-03.txt draft-blanchet-v6ops-tunnelbroker-tsp-03.txt], Aout 2005. Work in progress.<br />
<br />
;<div id="CMB-id">[CMB-id]</div><br />
: Hesham Soliman, Claude Castelluccia, Karim Malki, Ludovic Bellier, Hierarchical Mobile IPv6 mobility management (HMIPv6), [http://www.watersprings.org/pub/id/draft-ietf-mipshop-hmipv6-04.txt draft-ietf-mipshop-hmipv6-04.txt], Décembre 04. Obsolete - Experimental RFC 4140.<br />
<br />
;<div id="Craw-id">[Craw-id]</div><br />
: Matt Crawford: IPv6 Node Information Queries, [http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-15.txt draft-ietf-ipngwg-icmp-name-lookups-15.txt, Internet Draft, 13 Février 2006. Work in progress.<br />
<br />
;<div id="Drave-id">[Drave-id]</div><br />
: R. Draves: Default Address Selection for IPv6, draft-ietf-ipngwg-default-addr-select-06.txt, Internet Draft, 28 Septembre 2001. Obsolete - RFC 3484.<br />
<br />
;<div id="DHZ-id">[DHZ-id]</div><br />
: S. Deering, B. Haberman, B. Zill, T. Jinmei, E. Nordmark, A. Onoe: IP Version 6 Scoped Address Architecture, draft-ietf-ipngwg-scoping-arch-03.txt Internet Draft, 30 Novembre 2001. Obsolete - RFC 4007.<br />
<br />
;<div id="DIS-id">[DIS-id]</div><br />
: Alain Durand, Johan Ihren, Pekka Savola, Operational Considerations and Issues with IPv6 DNS, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-issues-12.txt draft-ietf-dnsop-ipv6-dns-issues-12.txt], Internet Draft, 19 Octobre 2005,. Work in progress. <br />
<br />
;<div id="Dupont-id">[Dupont-id]</div><br />
: F. Dupont, M. Laurent-Maknavicius: AAA for mobile IPv6, draft-dupont-mipv6-AAA-01.txt, Internet Draft, 20 Novembre 2001, Obsolete.<br />
<br />
;<div id="Ernst-id">[Ernst-id]</div><br />
: Thierry Ernst, Network Mobility Support Requirements, [http://www.watersprings.org/pub/id/draft-ietf-nemo-requirements-05.txt draft-ietf-nemo-requirements-05.txt], Octobre 2005<br />
<br />
;<div id="Fenner-id">[Fenner-id]</div><br />
: Bill Fenner, Haixiang He, Brian Haberman, Hal Sandick, IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying'), [http://www.watersprings.org/pub/id/draft-ietf-magma-igmp-proxy-06.txt draft-ietf-magma-igmp-proxy-06.txt]<br />
<br />
;<div id="Fenner2-id">[Fenner2-id]</div><br />
: Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas Protocol Independent Multicast - Sparse Mode (PIM -SM): Protocol Specification (Revised), IETF Internet Draft, [http://www.watersprings.org/pub/id/draft-ietf-pim-sm-v2-new-11.txt draft-ietf-pim-sm-v2-new-11.txt], 4 Octobre 2004. Work in progress.<br />
<br />
;<div id="Haber-id">[Haber-id]</div><br />
: B. Haberman: Dynamic Allocation Guidelines for IPv6 Multicast Addresses, draft-ietf-malloc-ipv6-guide-01.txt, Internet Draft, 12 Octobre 2000. Obsolete - RFC 3307.<br />
<br />
;<div id="HD-id">[HD-id]</div><br />
: R. Hinden, S. Deering: IP Version 6 Addressing Architecture, [[http://tools.ietf.org/wg/ipv6/draft-ietf-ipv6-addr-arch-v4/draft-ietf-ipv6-addr-arch-v4-04.txt draft-ietf-ipv6-addr-arch-v4-04.txt]], Internet Draft, 20 Mai 2005. Work in progress.<br />
<br />
;<div id="HH-id">[HH-id]</div><br />
: Robert Hinden, Brian Haberman, Centrally Assigned Unique Local IPv6 Unicast Addresses, [http://www.watersprings.org/pub/id/draft-ietf-ipv6-ula-central-01.txt draft-ietf-ipv6-ula-central-01.txt], Internet Draft, 21 Février 2005, Obsolete - See RFC 4193.<br />
<br />
;<div id="Hopps-if">[Hopps-id]</div><br />
: C. E. Hopps: Routing IPv6 with IS-IS, [http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-06.txt draft-ietf-isis-ipv6-06.txt], Internet Draft, Octobre 2005. Work in progress.<br />
<br />
;<div id="Huitema-id">[Huitéma-id]</div><br />
: C. Huitema, Teredo: Tunneling IPv6 over UDP through NATs, [http://www.watersprings.org/pub/id/draft-huitema-v6ops-teredo-05.txt draft-huitema-v6ops-teredo-05.txt], Avril 2005, Obsolete - See RFC 4380.<br />
<br />
;<div id="Jeong-id">[Jeong-id]</div><br />
: Jae-Hoon Jeong, IPv6 Host Configuration of DNS Server Information Approaches, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-configuration-06.txt draft-ietf-dnsop-ipv6-dns-configuration-06.txt], Internet Draft, 5 Mai 2005. RFC Editor Queue.<br />
<br />
;<div id="JP-id">[JP-id]</div><br />
: D. B. Johnson, C. Perkins: Mobility Support in IPv6, draft-ietf-mobileip-ipv6-15.txt, Internet Draft, 2 Juillet 2001. Obsolete - RFC 3775.<br />
<br />
; <div id="NFG-id">[NGF-id]</div><br />
: Tri Nguyen, Gerard Gastaud, Francois Le Faucheur, Dirk Ooms, Jeremy De Clercq, Stuart Prevost, Connecting IPv6 Domains across IPv4 Clouds with BGP, [http://tools.ietf.org/wg/v6ops/draft-ooms-v6ops-bgp-tunnel-06.txt draft-ooms-v6ops-bgp-tunnel-06.txt], Janvier 2006. Proposed standard.<br />
<br />
;<div id="NPE-id">[NPE-id]</div><br />
: Chan Wah Ng, Eun Kyoung Paik, Thierry Ernst, Analysis of Multihoming in Network Mobility Support, [http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-04.txt draft-ietf-nemo-multihoming-issues-04.txt], 24 Octobre 2005. Work in progress<br />
<br />
;<div id="Prz-id">[Prz-id]</div><br />
: Tony Przygienda, M-ISIS: Multi Topology (MT) Routing in IS-IS, [http://www.watersprings.org/pub/id/draft-ietf-isis-wg-multi-topology-11.txt draft-ietf-isis-wg-multi-topology-11.txt], 21 Octobre 2005.<br />
<br />
[Prigent-id]<br />
N. Prigent, J. Marchand, F. Dupont, B. Cousin, M. Laurent-Maknavicius, J. Bournelle: DHCPv6 Threats, draft-prigent-dhcpv6-threats-00.txt, Internet Draft, 24 mai 2001, Expired.<br />
<br />
;<div id="RFC2547bis">[RFC2547bis]</div><br />
: Eric C. Rosen, Yakov Rekhter, BGP/MPLS IP VPNs, [http://www.watersprings.org/pub/id/draft-ietf-l3vpn-rfc2547bis-03.txt draft-ietf-l3vpn-rfc2547bis-03.txt], Internet Draft, October 2004, Obsolete - RFC 4364.<br />
<br />
;<div id="Templin-id">[Templin-id]</div><br />
:Fred Templin, T. Gleeson, M. Talwar D. Thaler, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), [http://www.watersprings.org/pub/id/draft-ietf-ngtrans-isatap-24.txt draft-ietf-ngtrans-isatap-24.txt], Juillet 2005, Obsolete - RFC 4214.<br />
<br />
;<div id="Thubert-id">[Thubert-id]</div><br />
:Pascal Thubert, NEMO Home Network models, [http://www.watersprings.org/pub/id/draft-ietf-nemo-home-network-models-06.txt draft-ietf-nemo-home-network-models-06.txt], 17 Fevrier 2006.<br />
<br />
==Autres documents de travail==<br />
[FIPS-46]<br />
<br />
Data Encryption Standard, Federal Information Processing Standards Publication 46, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 15 Janvier 1977.<br />
<br />
[FIPS-81]<br />
<br />
DES Modes of Operation, Federal Information Processing Standards Publication 81, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 2 Décembre 1980.<br />
<br />
[FIPS-180-1]<br />
<br />
Secure Hash Standard, Federal Information Processing Standards Publication 180-1, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, Avril 1995.<br />
<br />
==Autres Références==<br />
[AL00]<br />
<br />
Mohammed Achemlal, Maryline Laurent, Analyse des fonctions des protocoles IPsec et leur intégration dans un réseau privé virtuel, Annales des télécommunications, 2000.<br />
<br />
<br />
[AL98]<br />
<br />
P. Albitz and C. Liu: DNS and BIND, 3rd Edition, ISBN: 1-56592-512-2, O'Reilly and Associates, Septembre 1998.<br />
<br />
<br />
;<div id="BTC02">[BTC02]</div><br />
: T. Bu, L. Gao, D. Towsley, On Characterizing Routing Table Growth, GlobalInternet 2002. http://www-unix.ecs.umass.edu/~lgao/globalinternet2002_tian.pdf<br />
<br />
<br />
;<div id="Ernst01f-fr">[Ernst01f-fr]</div><br />
:Ernst, Thierry, Le Support des Réseaux Mobiles dans IPv6, UniversitéJoseph Fourier, Octobre 2001, Grenoble, France, http://www.inria.fr/rrrt/tu-0714.html<br />
<br />
<br />
;<div id="Ernst03f">[Ernst03f]</div><br />
:Thierry Ernst, Le Support des Réseaux Mobiles dans IPv6, CFIP: Colloque Francophone sur l'Ingenierie des Protocoles, Octobre 2003, Paris<br />
<br />
<br />
[Fen-id]<br />
<br />
Bill Fenner, Management Information Base for the User Datagram Protocol (UDP), draft-ietf-ipv6-rfc2013-update-04.txt, Internet Draft, 20 Octobre 2004, Work in progress.<br />
<br />
<br />
[Hui95]<br />
<br />
C. Huitema: Le routage dans l'Internet, Eyrolles, Octobre 1995.<br />
<br />
[IEEE]<br />
<br />
Protocol Independant Interfaces, IEEE Std 1003.1g, DRAFT~6.6, Mars 1997.<br />
<br />
<br />
[JH-id]<br />
<br />
Jeffrey Haas, Susan Hares, Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), draft-ietf-idr-bgp4-mib-15.txt, Internet Draft, 31 Août 2004, Work in progress.<br />
<br />
<br />
[JM-id]<br />
<br />
Dan Joyal, Vishwas Manral, Management Information Base for OSPFv3, draft-ietf-ospf-ospfv3-mib-09.txt, Internet Draft, 13 Mai 2005, Work in progress.<br />
<br />
<br />
;<div id="Kau-id">[Kau-id]</div><br />
:Charlie Kaufman, Internet Key Exchange (IKEv2) Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-ikev2-17.txt draft-ietf-ipsec-ikev2-17.txt], Internet Draft, 4 Octobre 2004, Work in progress.<br />
<br />
;<div id="LAU03">[LAU03]</div><br />
: M. Laurent-Maknavicius, Le protocole IPsec, [http://www.techniques-ingenieur.fr/affichage/DispIntro.asp?nGcmID=TE7545 TE7545], [http://www.techniques-ingenieur.fr/ Techniques de l'Ingénieur], Sécurité des systèmes d'information, Novembre 2003.<br />
<br />
[LAU04-A]<br />
<br />
M. Laurent-Maknavicius, M. Gardie, LDAP et la certification, Rapport de recherche du GET, 04001 LOR, 2004.<br />
<br />
[LAU04-B]<br />
<br />
M. Laurent-Maknavicius, La sécurité de l'accès distant, Technique et Science Informatiques (TSI), 2004.<br />
<br />
;<div id="MHF-id">[MHF-id]</div><br />
:Ambarish Malpani, Russ Housley, Trevor Freeman, Simple Certificate Validation Protocol (SCVP), [http://www.watersprings.org/pub/id/draft-ietf-pkix-scvp-22.txt draft-ietf-pkix-scvp-22.txt], Internet Draft, Octobre 2005, Work in progress.<br />
<br />
;<div id="Mos-id">[Mos-id]</div><br />
:Robert Moskowitz, Host Identity Protocol, [http://www.watersprings.org/pub/id/draft-ietf-hip-base-04.txt draft-ietf-hip-base-04.txt], Internet Draft, 24 Octobre 2005, Work in progress<br />
<br />
;<div id="Pui02-A">[Pui02-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse critique d'IPsec, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-analyse-rapport/ipsec-analyse-rapport.pdf rapport de recherche 03 004 LOR], 2002.<br />
<br />
;<div id="Pui02-B">[Pui02-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse de l'impact de la mise en oeuvre d'IPsec dans les architectures de Communication, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-interactions-rapport/ipsec-interactions-rapport.pdf rapport de recherche 03 002 LOR], octobre 2002.<br />
<br />
;<div id="Pui03">[Pui03]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects ARP), [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/environnement-reel-1-rapport/environnement-reel-1-rapport.pdf rapport de recherche 03 001 LOR], janvier 2003.<br />
<br />
;<div id="Pui04-A">[Pui04-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Etude des interactions IPsec/DNS, [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/InteractionDNS.pdf rapport de recherche 04002 LOR], 2004.<br />
<br />
;<div id="Pui04-B">[Pui04-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects liés à ICMP), [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/IPsec_ICMP.pdf rapport de recherche 04004 LOR], 2004.<br />
<br />
;<div id="RFC2401bis">[RFC2401bis]</div><br />
: Stephen Kent, Karen Seo, Security Architecture for the Internet Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2401bis-06.txt draft-ietf-ipsec-rfc2401bis-06.txt], Internet Draft, 1 Avril 2005, Work in progress<br />
<br />
<br />
;<div id="RFC2402bis">[RFC2402bis]</div><br />
:Stephen Kent, IP Authentication Header, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2402bis-11.txt draft-ietf-ipsec-rfc2402bis-11.txt], Internet Draft, 21 Mars 2005, Work in progress.<br />
<br />
[Rou-id]<br />
<br />
Shawn Routhier, Management Information Base for the Internet Protocol (IP), draft-ietf-ipv6-rfc2011-update-10.txt; Internet Draft, 24 Mai 2004, Work in progress.<br />
<br />
[Sch95]<br />
<br />
B. Schneier: Applied Cryptography : protocols, algorithms, and source code in C, (second edition), John Wiley & Sons, ISBN: 0-471-12845-7, 1996.<br />
<br />
[Sta99]<br />
<br />
William Stallings: Snmp, Snmpv2, Snmpv3, and Rmon 1 and 2, Addison Wesley, ISBN: 0-201-48534-6, Janvier 1999.<br />
<br />
[Tout03]<br />
<br />
Laurent Toutain: Réseaux Locaux et Internet: des protocoles à l'interconnexion, Troisième édition revue et augmentée, Hermès, ISBN: 2-7462-0670-6, 2003.<br />
<br />
[Uni31]<br />
<br />
ATM Forum: ATM User-Network Interface (UNI) Specification Version 3.1, Prentice Hall, Englewood Cliffs, NJ, Juin 1995.<br />
<br />
[WH-id]<br />
<br />
Margaret Wasserman, Brian Haberman, IP Forwarding Table MIB, draft-ietf-ipv6-rfc2096-update-07.txt, Internet Draft, 12 février 2004, Work in progress.<br />
<br />
[WK99]<br />
<br />
M. Welsh et L. Kaufman: Le système Linux, 2e édition révisée, Éditions O'Reilly, ISBN: 2-84177-033-8, Janvier 1999.<br />
<br />
==Sites Web sur IPv6 ==<br />
<br />
;[IETF]<br />
:http://www.imag.fr/pub/archive/IETF: Mirroir français du serveur de l'IETF.<br />
<br />
;[6bone]<br />
:http://www.6bone.net: Réseau 6bone.<br />
<br />
;[G6bone]<br />
:http://peirce.logique.jussieu.fr/G6/ Réseau G6-bone (partie francophone de 6bone).<br />
<br />
;[hs247] <br />
:http://hs247.com/ Informations sur le 6bone et IPv6 en général.<br />
<br />
;[ipv6.org]<br />
: http://www.ipv6.org/ pages d'information sur le protocole IPv6<br />
<br />
;[ipv6forum] <br />
:http://www.ipv6forum.org/ Groupement d'industriels pour promouvoir IPv6.<br />
<br />
;[playground] <br />
:http://playground.sun.com/pub/ipng/html/ipng-main.html liste des mises en oeuvre d'IPv6 dans les équipements.</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Bibliographie&diff=2931Bibliographie2006-02-23T15:49:16Z<p>Bruno Deniaud: /* Internet Drafts sur IPv6 */</p>
<hr />
<div>= Livres sur IPv6 =<br />
<br />
<div id="BM95">[BM95] S. O. Bradner & A. Mankin ed : IPng, Internet Protocol Next Generation, Addison-Wesley (IPng Series), ISBN0201633957, Septembre 1995.</div><br />
<br />
[Gai98] S. Gai, Internetworking IPv6 With Cisco Routers (Computer Communications), McGraw-Hill, ISBN: 0-070-22836-1, Février 1998.<br />
<br />
[Hui97] C. Huitema: IPv6: The New Internet Protocol, Prentice Hall, ISBN: 0-138-50505-5, Octbre 1997.<br />
<br />
[LL99] Peter Loshin & Pete Loshin: IPv6 Clearly Explained (Clearly Explained), Ap Professional, ISBN: 0-124-55838-0, Janvier 1999.<br />
<br />
[MM00] Mark A. Miller & P. E. Miller: Implementing IPv6, second edition (Network Troubleshooting Library), IDG Books Worldwide, ISBN: 0-764-54589-2, Janvier 2000.<br />
<br />
<br />
[Mil97] Stewart S. Miller: IPv6 : The Next Generation Internet Protocol, DigitalPress, ISBN: 1-555-58188-9, Décembre 1997.<br />
<br />
[MK98] Marcus Goncalves & Kitty Niles: IPv6 Networks, McGraw-Hill, ISBN: 0-070-24807-9, Mai 1998.<br />
<br />
[Sal00] Peter H. Salus: Big Book of IPV6 Addressing RFCs, Morgan Kaufmann Publishers, ISBN: 0-126-16770-2, Mars 2000.<br />
<br />
[WR99] J. D. Wegner & Robert Rockwell: IP Addressing and Subnetting, Including IPv6, Syngress Media, ISBN: 1-928-99401-6, Décembre 1999.<br />
<br />
== Internet Drafts sur IPv6 ==<br />
<br />
''Remarque : Il faut rappeler que les Internet drafts sont des documents de travail à durée de vie limitée. Ils ont vocation à devenir des RFC. Le lecteur est donc invité à vérifier quelle est la version la plus récente, ou si un RFC le remplace, en consultant l'index à jour (cf. Les RFC (Request For Comments)).''<br />
<br />
;<div id="BCP2-id">[BCP2-id]</div><br />
: J. Bound, M. Carney, C. Perkins: Extensions for the Dynamic Host Configuration Protocol for IPv6, [http://www.watersprings.org/pub/id/draft-ietf-dhcpv6exts-12.txt draft-ietf-dhc-v6exts-12.txt], Internet Draft, 5 Mai 2000 - Obsolete.<br />
<br />
;<div id="BKLSPTSDY-id">[BKLSPTSDY-id]</div><br />
: W. Biemolt, M. Kaat, T. Larder, H. Steenman, R. van der Pol, G. Tsirtsis, Y. Sekiya, A. Durand, K. Yamamoto: On overview of the introduction of IPv6 in the Internet, draft-ietf-ngtrans-introduction-to-ipv6-transition-08.txt, Internet Draft, Février 2002. Working Group Concluded.<br />
<br />
;<div id="BTM-id>[BTM-id]</div><br />
: J. Bound, L. Toutain, O. Medina, F. Dupont, A. Durand, H Afifi,: Dual Stack Transition Mechanism (DSTM), draft-ietf-ngtrans-dstm-07.txt, Internet Draft, Aout 2002. Obsolete.<br />
<br />
;<div id="BP-id">[BP-id]</div><br />
: M. Blanchet, F. Parent, IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP), [http://www.watersprings.org/pub/id/draft-blanchet-v6ops-tunnelbroker-tsp-03.txt draft-blanchet-v6ops-tunnelbroker-tsp-03.txt], Aout 2005. Work in progress.<br />
<br />
;<div id="CMB-id">[CMB-id]</div><br />
: Hesham Soliman, Claude Castelluccia, Karim Malki, Ludovic Bellier, Hierarchical Mobile IPv6 mobility management (HMIPv6), [http://www.watersprings.org/pub/id/draft-ietf-mipshop-hmipv6-04.txt draft-ietf-mipshop-hmipv6-04.txt], Décembre 04. Obsolete - Experimental RFC 4140.<br />
<br />
;<div id="Craw-id">[Craw-id]</div><br />
: Matt Crawford: IPv6 Node Information Queries, [http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-15.txt draft-ietf-ipngwg-icmp-name-lookups-15.txt, Internet Draft, 13 Février 2006. Work in progress.<br />
<br />
;<div id="Drave-id">[Drave-id]</div><br />
: R. Draves: Default Address Selection for IPv6, draft-ietf-ipngwg-default-addr-select-06.txt, Internet Draft, 28 Septembre 2001. Obsolete - RFC 3484.<br />
<br />
;<div id="DHZ-id">[DHZ-id]</div><br />
: S. Deering, B. Haberman, B. Zill, T. Jinmei, E. Nordmark, A. Onoe: IP Version 6 Scoped Address Architecture, draft-ietf-ipngwg-scoping-arch-03.txt Internet Draft, 30 Novembre 2001. Obsolete - RFC 4007.<br />
<br />
;<div id="DIS-id">[DIS-id]</div><br />
: Alain Durand, Johan Ihren, Pekka Savola, Operational Considerations and Issues with IPv6 DNS, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-issues-12.txt draft-ietf-dnsop-ipv6-dns-issues-12.txt], Internet Draft, 19 Octobre 2005,. Work in progress. <br />
<br />
;<div id="Dupont-id">[Dupont-id]</div><br />
: F. Dupont, M. Laurent-Maknavicius: AAA for mobile IPv6, draft-dupont-mipv6-AAA-01.txt, Internet Draft, 20 Novembre 2001, Obsolete.<br />
<br />
;<div id="Ernst-id">[Ernst-id]</div><br />
: Thierry Ernst, Network Mobility Support Requirements, [http://www.watersprings.org/pub/id/draft-ietf-nemo-requirements-05.txt draft-ietf-nemo-requirements-05.txt], Octobre 2005<br />
<br />
;<div id="Fenner-id">[Fenner-id]</div><br />
: Bill Fenner, Haixiang He, Brian Haberman, Hal Sandick, IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying'), [http://www.watersprings.org/pub/id/draft-ietf-magma-igmp-proxy-06.txt draft-ietf-magma-igmp-proxy-06.txt]<br />
<br />
;<div id="Fenner2-id">[Fenner2-id]</div><br />
: Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas Protocol Independent Multicast - Sparse Mode (PIM -SM): Protocol Specification (Revised), IETF Internet Draft, [http://www.watersprings.org/pub/id/draft-ietf-pim-sm-v2-new-11.txt draft-ietf-pim-sm-v2-new-11.txt], 4 Octobre 2004. Work in progress.<br />
<br />
[Haber-id]<br />
B. Haberman: Dynamic Allocation Guidelines for IPv6 Multicast Addresses, draft-ietf-malloc-ipv6-guide-01.txt, Internet Draft, 12 Octobre 200. Work in progress.<br />
<br />
[HD-id]<br />
R. Hinden, S. Deering: IP Version 6 Addressing Architecture, draft-ietf-ipngwg-addr-arch-v3-07.txt, Internet Draft, 27 Novembre 2001. Work in progress.<br />
<br />
;<div id="HH-id">[HH-id]</div><br />
:Robert Hinden, Brian Haberman, Centrally Assigned Unique Local IPv6 Unicast Addresses, [http://www.watersprings.org/pub/id/draft-ietf-ipv6-ula-central-01.txt draft-ietf-ipv6-ula-central-01.txt], Internet Draft, 21 Février 2005, Obsolete - See RFC 4193.<br />
<br />
;<div id="Hopps-if">[Hopps-id]</div><br />
:C. E. Hopps: Routing IPv6 with IS-IS, [http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-06.txt draft-ietf-isis-ipv6-06.txt], Internet Draft, Octobre 2005. Work in progress.<br />
<br />
;<div id="Huitema-id">[Huitéma-id]</div><br />
:C. Huitema, Teredo: Tunneling IPv6 over UDP through NATs, [http://www.watersprings.org/pub/id/draft-huitema-v6ops-teredo-05.txt draft-huitema-v6ops-teredo-05.txt], Avril 2005, Obsolete - See RFC 4380.<br />
<br />
;<div id="Jeong-id">[Jeong-id]</div><br />
: Jae-Hoon Jeong, IPv6 Host Configuration of DNS Server Information Approaches, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-configuration-06.txt draft-ietf-dnsop-ipv6-dns-configuration-06.txt], Internet Draft, 5 Mai 2005. Work in progress.<br />
<br />
[JP-id]<br />
D. B. Johnson, C. Perkins: Mobility Support in IPv6, draft-ietf-mobileip-ipv6-15.txt, Internet Draft, 2 Juillet 2001. Work in progress.<br />
<br />
; <div id="NFG-id">[NGF-id]</div><br />
: Tri Nguyen, Gerard Gastaud, Francois Le Faucheur, Dirk Ooms, Jeremy De Clercq, Stuart Prevost, Connecting IPv6 Domains across IPv4 Clouds with BGP, [http://www.watersprings.org/pub/id/draft-ietf-ngtrans-bgp-tunnel-05.txt draft-ietf-ngtrans-bgp-tunnel-05.txt], 3 Mai 2005. Work in progress<br />
<br />
;<div id="NPE-id">[NPE-id]</div><br />
:Chan Wah Ng, Eun Kyoung Paik, Thierry Ernst, Analysis of Multihoming in Network Mobility Support, [http://www.watersprings.org/pub/id/draft-ietf-nemo-multihoming-issues-02.txt draft-ietf-nemo-multihoming-issues-02.txt], 22 Février 2005. Work in progress<br />
<br />
;<div id="Prz-id">[Prz-id]</div><br />
: Tony Przygienda, M-ISIS: Multi Topology (MT) Routing in IS-IS, [http://www.watersprings.org/pub/id/draft-ietf-isis-wg-multi-topology-10.txt draft-ietf-isis-wg-multi-topology-10.txt], 9 Mai 2005.<br />
<br />
[Prigent-id]<br />
N. Prigent, J. Marchand, F. Dupont, B. Cousin, M. Laurent-Maknavicius, J. Bournelle: DHCPv6 Threats, draft-prigent-dhcpv6-threats-00.txt, Internet Draft, 24 mai 2001, Work in Progress.<br />
<br />
;<div id="RFC2547bis">[RFC2547bis]</div><br />
: Eric C. Rosen, Yakov Rekhter, BGP/MPLS IP VPNs, [http://www.watersprings.org/pub/id/draft-ietf-l3vpn-rfc2547bis-03.txt draft-ietf-l3vpn-rfc2547bis-03.txt], Internet Draft, October 2004, Work in Progress.<br />
<br />
;<div id="Templin-id">[Templin-id]</div><br />
:Fred Templin, T. Gleeson, M. Talwar D. Thaler, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), [http://www.watersprings.org/pub/id/draft-ietf-ngtrans-isatap-24.txt draft-ietf-ngtrans-isatap-24.txt], Juillet 2005, Work in progress.<br />
<br />
;<div id="Thubert-id">[Thubert-id]</div><br />
:Pascal Thubert, NEMO Home Network models, [http://www.watersprings.org/pub/id/draft-ietf-nemo-home-network-models-05.txt draft-ietf-nemo-home-network-models-05.txt], Octobre 2005.<br />
<br />
==Autres documents de travail==<br />
[FIPS-46]<br />
<br />
Data Encryption Standard, Federal Information Processing Standards Publication 46, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 15 Janvier 1977.<br />
<br />
[FIPS-81]<br />
<br />
DES Modes of Operation, Federal Information Processing Standards Publication 81, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 2 Décembre 1980.<br />
<br />
[FIPS-180-1]<br />
<br />
Secure Hash Standard, Federal Information Processing Standards Publication 180-1, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, Avril 1995.<br />
<br />
==Autres Références==<br />
[AL00]<br />
<br />
Mohammed Achemlal, Maryline Laurent, Analyse des fonctions des protocoles IPsec et leur intégration dans un réseau privé virtuel, Annales des télécommunications, 2000.<br />
<br />
<br />
[AL98]<br />
<br />
P. Albitz and C. Liu: DNS and BIND, 3rd Edition, ISBN: 1-56592-512-2, O'Reilly and Associates, Septembre 1998.<br />
<br />
<br />
;<div id="BTC02">[BTC02]</div><br />
: T. Bu, L. Gao, D. Towsley, On Characterizing Routing Table Growth, GlobalInternet 2002. http://www-unix.ecs.umass.edu/~lgao/globalinternet2002_tian.pdf<br />
<br />
<br />
;<div id="Ernst01f-fr">[Ernst01f-fr]</div><br />
:Ernst, Thierry, Le Support des Réseaux Mobiles dans IPv6, UniversitéJoseph Fourier, Octobre 2001, Grenoble, France, http://www.inria.fr/rrrt/tu-0714.html<br />
<br />
<br />
;<div id="Ernst03f">[Ernst03f]</div><br />
:Thierry Ernst, Le Support des Réseaux Mobiles dans IPv6, CFIP: Colloque Francophone sur l'Ingenierie des Protocoles, Octobre 2003, Paris<br />
<br />
<br />
[Fen-id]<br />
<br />
Bill Fenner, Management Information Base for the User Datagram Protocol (UDP), draft-ietf-ipv6-rfc2013-update-04.txt, Internet Draft, 20 Octobre 2004, Work in progress.<br />
<br />
<br />
[Hui95]<br />
<br />
C. Huitema: Le routage dans l'Internet, Eyrolles, Octobre 1995.<br />
<br />
[IEEE]<br />
<br />
Protocol Independant Interfaces, IEEE Std 1003.1g, DRAFT~6.6, Mars 1997.<br />
<br />
<br />
[JH-id]<br />
<br />
Jeffrey Haas, Susan Hares, Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), draft-ietf-idr-bgp4-mib-15.txt, Internet Draft, 31 Août 2004, Work in progress.<br />
<br />
<br />
[JM-id]<br />
<br />
Dan Joyal, Vishwas Manral, Management Information Base for OSPFv3, draft-ietf-ospf-ospfv3-mib-09.txt, Internet Draft, 13 Mai 2005, Work in progress.<br />
<br />
<br />
;<div id="Kau-id">[Kau-id]</div><br />
:Charlie Kaufman, Internet Key Exchange (IKEv2) Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-ikev2-17.txt draft-ietf-ipsec-ikev2-17.txt], Internet Draft, 4 Octobre 2004, Work in progress.<br />
<br />
;<div id="LAU03">[LAU03]</div><br />
: M. Laurent-Maknavicius, Le protocole IPsec, [http://www.techniques-ingenieur.fr/affichage/DispIntro.asp?nGcmID=TE7545 TE7545], [http://www.techniques-ingenieur.fr/ Techniques de l'Ingénieur], Sécurité des systèmes d'information, Novembre 2003.<br />
<br />
[LAU04-A]<br />
<br />
M. Laurent-Maknavicius, M. Gardie, LDAP et la certification, Rapport de recherche du GET, 04001 LOR, 2004.<br />
<br />
[LAU04-B]<br />
<br />
M. Laurent-Maknavicius, La sécurité de l'accès distant, Technique et Science Informatiques (TSI), 2004.<br />
<br />
;<div id="MHF-id">[MHF-id]</div><br />
:Ambarish Malpani, Russ Housley, Trevor Freeman, Simple Certificate Validation Protocol (SCVP), [http://www.watersprings.org/pub/id/draft-ietf-pkix-scvp-22.txt draft-ietf-pkix-scvp-22.txt], Internet Draft, Octobre 2005, Work in progress.<br />
<br />
;<div id="Mos-id">[Mos-id]</div><br />
:Robert Moskowitz, Host Identity Protocol, [http://www.watersprings.org/pub/id/draft-ietf-hip-base-04.txt draft-ietf-hip-base-04.txt], Internet Draft, 24 Octobre 2005, Work in progress<br />
<br />
;<div id="Pui02-A">[Pui02-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse critique d'IPsec, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-analyse-rapport/ipsec-analyse-rapport.pdf rapport de recherche 03 004 LOR], 2002.<br />
<br />
;<div id="Pui02-B">[Pui02-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse de l'impact de la mise en oeuvre d'IPsec dans les architectures de Communication, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-interactions-rapport/ipsec-interactions-rapport.pdf rapport de recherche 03 002 LOR], octobre 2002.<br />
<br />
;<div id="Pui03">[Pui03]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects ARP), [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/environnement-reel-1-rapport/environnement-reel-1-rapport.pdf rapport de recherche 03 001 LOR], janvier 2003.<br />
<br />
;<div id="Pui04-A">[Pui04-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Etude des interactions IPsec/DNS, [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/InteractionDNS.pdf rapport de recherche 04002 LOR], 2004.<br />
<br />
;<div id="Pui04-B">[Pui04-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects liés à ICMP), [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/IPsec_ICMP.pdf rapport de recherche 04004 LOR], 2004.<br />
<br />
;<div id="RFC2401bis">[RFC2401bis]</div><br />
: Stephen Kent, Karen Seo, Security Architecture for the Internet Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2401bis-06.txt draft-ietf-ipsec-rfc2401bis-06.txt], Internet Draft, 1 Avril 2005, Work in progress<br />
<br />
<br />
;<div id="RFC2402bis">[RFC2402bis]</div><br />
:Stephen Kent, IP Authentication Header, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2402bis-11.txt draft-ietf-ipsec-rfc2402bis-11.txt], Internet Draft, 21 Mars 2005, Work in progress.<br />
<br />
[Rou-id]<br />
<br />
Shawn Routhier, Management Information Base for the Internet Protocol (IP), draft-ietf-ipv6-rfc2011-update-10.txt; Internet Draft, 24 Mai 2004, Work in progress.<br />
<br />
[Sch95]<br />
<br />
B. Schneier: Applied Cryptography : protocols, algorithms, and source code in C, (second edition), John Wiley & Sons, ISBN: 0-471-12845-7, 1996.<br />
<br />
[Sta99]<br />
<br />
William Stallings: Snmp, Snmpv2, Snmpv3, and Rmon 1 and 2, Addison Wesley, ISBN: 0-201-48534-6, Janvier 1999.<br />
<br />
[Tout03]<br />
<br />
Laurent Toutain: Réseaux Locaux et Internet: des protocoles à l'interconnexion, Troisième édition revue et augmentée, Hermès, ISBN: 2-7462-0670-6, 2003.<br />
<br />
[Uni31]<br />
<br />
ATM Forum: ATM User-Network Interface (UNI) Specification Version 3.1, Prentice Hall, Englewood Cliffs, NJ, Juin 1995.<br />
<br />
[WH-id]<br />
<br />
Margaret Wasserman, Brian Haberman, IP Forwarding Table MIB, draft-ietf-ipv6-rfc2096-update-07.txt, Internet Draft, 12 février 2004, Work in progress.<br />
<br />
[WK99]<br />
<br />
M. Welsh et L. Kaufman: Le système Linux, 2e édition révisée, Éditions O'Reilly, ISBN: 2-84177-033-8, Janvier 1999.<br />
<br />
==Sites Web sur IPv6 ==<br />
<br />
;[IETF]<br />
:http://www.imag.fr/pub/archive/IETF: Mirroir français du serveur de l'IETF.<br />
<br />
;[6bone]<br />
:http://www.6bone.net: Réseau 6bone.<br />
<br />
;[G6bone]<br />
:http://peirce.logique.jussieu.fr/G6/ Réseau G6-bone (partie francophone de 6bone).<br />
<br />
;[hs247] <br />
:http://hs247.com/ Informations sur le 6bone et IPv6 en général.<br />
<br />
;[ipv6.org]<br />
: http://www.ipv6.org/ pages d'information sur le protocole IPv6<br />
<br />
;[ipv6forum] <br />
:http://www.ipv6forum.org/ Groupement d'industriels pour promouvoir IPv6.<br />
<br />
;[playground] <br />
:http://playground.sun.com/pub/ipng/html/ipng-main.html liste des mises en oeuvre d'IPv6 dans les équipements.</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Bibliographie&diff=2929Bibliographie2006-02-23T13:41:28Z<p>Bruno Deniaud: /* Internet Drafts sur IPv6 */</p>
<hr />
<div>= Livres sur IPv6 =<br />
<br />
<div id="BM95">[BM95] S. O. Bradner & A. Mankin ed : IPng, Internet Protocol Next Generation, Addison-Wesley (IPng Series), ISBN0201633957, Septembre 1995.</div><br />
<br />
[Gai98] S. Gai, Internetworking IPv6 With Cisco Routers (Computer Communications), McGraw-Hill, ISBN: 0-070-22836-1, Février 1998.<br />
<br />
[Hui97] C. Huitema: IPv6: The New Internet Protocol, Prentice Hall, ISBN: 0-138-50505-5, Octbre 1997.<br />
<br />
[LL99] Peter Loshin & Pete Loshin: IPv6 Clearly Explained (Clearly Explained), Ap Professional, ISBN: 0-124-55838-0, Janvier 1999.<br />
<br />
[MM00] Mark A. Miller & P. E. Miller: Implementing IPv6, second edition (Network Troubleshooting Library), IDG Books Worldwide, ISBN: 0-764-54589-2, Janvier 2000.<br />
<br />
<br />
[Mil97] Stewart S. Miller: IPv6 : The Next Generation Internet Protocol, DigitalPress, ISBN: 1-555-58188-9, Décembre 1997.<br />
<br />
[MK98] Marcus Goncalves & Kitty Niles: IPv6 Networks, McGraw-Hill, ISBN: 0-070-24807-9, Mai 1998.<br />
<br />
[Sal00] Peter H. Salus: Big Book of IPV6 Addressing RFCs, Morgan Kaufmann Publishers, ISBN: 0-126-16770-2, Mars 2000.<br />
<br />
[WR99] J. D. Wegner & Robert Rockwell: IP Addressing and Subnetting, Including IPv6, Syngress Media, ISBN: 1-928-99401-6, Décembre 1999.<br />
<br />
== Internet Drafts sur IPv6 ==<br />
<br />
''Remarque : Il faut rappeler que les Internet drafts sont des documents de travail à durée de vie limitée. Ils ont vocation à devenir des RFC. Le lecteur est donc invité à vérifier quelle est la version la plus récente, ou si un RFC le remplace, en consultant l'index à jour (cf. See Les RFC (Request For Comments)).''<br />
<br />
[BCP2-id] J. Bound, M. Carney, C. Perkins: Extensions for the Dynamic Host Configuration Protocol for IPv6, [http://www.watersprings.org/pub/id/draft-ietf-dhcpv6exts-12.txt draft-ietf-dhc-v6exts-12.txt], Internet Draft, 5 Mai 2000.<br />
<br />
[BKLSPTSDY-id]<br />
W. Biemolt, M. Kaat, T. Larder, H. Steenman, R. van der Pol, G. Tsirtsis, Y. Sekiya, A. Durand, K. Yamamoto: On overview of the introduction of IPv6 in the Internet, draft-ietf-ngtrans-introduction-to-ipv6-transition-07.txt, Internet Draft, 19 Juillet 2001. Work in progress.<br />
<br />
[BTM-id]<br />
J. Bound, L. Toutain, O. Medina, F. Dupont, A. Durand, H Afifi,: Dual Stack Transition Mechanism (DSTM), draft-ietf-ngtrans-dstm-05.txt, Internet Draft, 21 Novembre 2001. Work in progress.<br />
<br />
;<div id="BP-id">[BP-id]</div><br />
:M. Blanchet, F. Parent, IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP), [http://www.watersprings.org/pub/id/draft-blanchet-v6ops-tunnelbroker-tsp-03.txt draft-blanchet-v6ops-tunnelbroker-tsp-03.txt], Mars 2004. Work in progress.<br />
<br />
;<div id="CMB-id">[CMB-id]</div><br />
:Hesham Soliman, Claude Castelluccia, Karim Malki, Ludovic Bellier, Hierarchical Mobile IPv6 mobility management (HMIPv6), [http://www.watersprings.org/pub/id/draft-ietf-mipshop-hmipv6-04.txt draft-ietf-mipshop-hmipv6-04.txt], Décembre 04. Work in progress.<br />
<br />
[Craw-id]<br />
Matt Crawford: IPv6 Node Information Queries, draft-ietf-ipngwg-icmp-name-lookups-08.txt, Internet Draft, 20 Juillet 2001. Work in progress.<br />
<br />
[Drave-id]<br />
R. Draves: Default Address Selection for IPv6, draft-ietf-ipngwg-default-addr-select-06.txt, Internet Draft, 28 Septembre 2001. Work in progress.<br />
<br />
[DHZ-id]<br />
S. Deering, B. Haberman, B. Zill, T. Jinmei, E. Nordmark, A. Onoe: IP Version 6 Scoped Address Architecture, draft-ietf-ipngwg-scoping-arch-03.txt Internet Draft, 30 Novembre 2001. Work in progress.<br />
<br />
;<div id="DIS-id">[DIS-id]</div><br />
: Alain Durand, Johan Ihren, Pekka Savola, Operational Considerations and Issues with IPv6 DNS, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-issues-10.txt draft-ietf-dnsop-ipv6-dns-issues-10.txt], Internet Draft, 26 Octobre 2004,. Work in progress. <br />
<br />
[Dupont-id]<br />
F. Dupont, M. Laurent-Maknavicius: AAA for mobile IPv6, draft-dupond-mipv6-AAA-01.txt, Internet Draft, 20 Novembre 2001, Work in Progress<br />
<br />
;<div id="Ernst-id">[Ernst-id]</div><br />
:Thierry Ernst, Network Mobility Support Requirements, [http://www.watersprings.org/pub/id/draft-ietf-nemo-requirements-05.txt draft-ietf-nemo-requirements-05.txt], Octobre 2005<br />
<br />
;<div id="Fenner-id">[Fenner-id]</div><br />
: Bill Fenner, Haixiang He, Brian Haberman, Hal Sandick, IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying'), [http://www.watersprings.org/pub/id/draft-ietf-magma-igmp-proxy-06.txt draft-ietf-magma-igmp-proxy-06.txt]<br />
<br />
;<div id="Fenner2-id">[Fenner2-id]</div><br />
: Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas Protocol Independent Multicast - Sparse Mode (PIM -SM): Protocol Specification (Revised), IETF Internet Draft, [http://www.watersprings.org/pub/id/draft-ietf-pim-sm-v2-new-11.txt draft-ietf-pim-sm-v2-new-11.txt], 4 Octobre 2004. Work in progress.<br />
<br />
<br />
[Haber-id]<br />
B. Haberman: Dynamic Allocation Guidelines for IPv6 Multicast Addresses, draft-ietf-malloc-ipv6-guide-01.txt, Internet Draft, 12 Octobre 200. Work in progress.<br />
<br />
[HD-id]<br />
R. Hinden, S. Deering: IP Version 6 Addressing Architecture, draft-ietf-ipngwg-addr-arch-v3-07.txt, Internet Draft, 27 Novembre 2001. Work in progress.<br />
<br />
;<div id="HH-id">[HH-id]</div><br />
:Robert Hinden, Brian Haberman, Centrally Assigned Unique Local IPv6 Unicast Addresses, [http://www.watersprings.org/pub/id/draft-ietf-ipv6-ula-central-01.txt draft-ietf-ipv6-ula-central-01.txt], Internet Draft, 21 Février 2005, Obsolete - See RFC 4193.<br />
<br />
;<div id="Hopps-if">[Hopps-id]</div><br />
:C. E. Hopps: Routing IPv6 with IS-IS, [http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-06.txt draft-ietf-isis-ipv6-06.txt], Internet Draft, Octobre 2005. Work in progress.<br />
<br />
;<div id="Huitema-id">[Huitéma-id]</div><br />
:C. Huitema, Teredo: Tunneling IPv6 over UDP through NATs, [http://www.watersprings.org/pub/id/draft-huitema-v6ops-teredo-05.txt draft-huitema-v6ops-teredo-05.txt], Avril 2005, Obsolete - See RFC 4380.<br />
<br />
;<div id="Jeong-id">[Jeong-id]</div><br />
: Jae-Hoon Jeong, IPv6 Host Configuration of DNS Server Information Approaches, [http://www.watersprings.org/pub/id/draft-ietf-dnsop-ipv6-dns-configuration-06.txt draft-ietf-dnsop-ipv6-dns-configuration-06.txt], Internet Draft, 5 Mai 2005. Work in progress.<br />
<br />
[JP-id]<br />
D. B. Johnson, C. Perkins: Mobility Support in IPv6, draft-ietf-mobileip-ipv6-15.txt, Internet Draft, 2 Juillet 2001. Work in progress.<br />
<br />
; <div id="NFG-id">[NGF-id]</div><br />
: Tri Nguyen, Gerard Gastaud, Francois Le Faucheur, Dirk Ooms, Jeremy De Clercq, Stuart Prevost, Connecting IPv6 Domains across IPv4 Clouds with BGP, [http://www.watersprings.org/pub/id/draft-ietf-ngtrans-bgp-tunnel-05.txt draft-ietf-ngtrans-bgp-tunnel-05.txt], 3 Mai 2005. Work in progress<br />
<br />
;<div id="NPE-id">[NPE-id]</div><br />
:Chan Wah Ng, Eun Kyoung Paik, Thierry Ernst, Analysis of Multihoming in Network Mobility Support, [http://www.watersprings.org/pub/id/draft-ietf-nemo-multihoming-issues-02.txt draft-ietf-nemo-multihoming-issues-02.txt], 22 Février 2005. Work in progress<br />
<br />
;<div id="Prz-id">[Prz-id]</div><br />
: Tony Przygienda, M-ISIS: Multi Topology (MT) Routing in IS-IS, [http://www.watersprings.org/pub/id/draft-ietf-isis-wg-multi-topology-10.txt draft-ietf-isis-wg-multi-topology-10.txt], 9 Mai 2005.<br />
<br />
[Prigent-id]<br />
N. Prigent, J. Marchand, F. Dupont, B. Cousin, M. Laurent-Maknavicius, J. Bournelle: DHCPv6 Threats, draft-prigent-dhcpv6-threats-00.txt, Internet Draft, 24 mai 2001, Work in Progress.<br />
<br />
;<div id="RFC2547bis">[RFC2547bis]</div><br />
: Eric C. Rosen, Yakov Rekhter, BGP/MPLS IP VPNs, [http://www.watersprings.org/pub/id/draft-ietf-l3vpn-rfc2547bis-03.txt draft-ietf-l3vpn-rfc2547bis-03.txt], Internet Draft, October 2004, Work in Progress.<br />
<br />
;<div id="Templin-id">[Templin-id]</div><br />
:Fred Templin, T. Gleeson, M. Talwar D. Thaler, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), [http://www.watersprings.org/pub/id/draft-ietf-ngtrans-isatap-24.txt draft-ietf-ngtrans-isatap-24.txt], Juillet 2005, Work in progress.<br />
<br />
;<div id="Thubert-id">[Thubert-id]</div><br />
:Pascal Thubert, NEMO Home Network models, [http://www.watersprings.org/pub/id/draft-ietf-nemo-home-network-models-05.txt draft-ietf-nemo-home-network-models-05.txt], Octobre 2005.<br />
<br />
==Autres documents de travail==<br />
[FIPS-46]<br />
<br />
Data Encryption Standard, Federal Information Processing Standards Publication 46, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 15 Janvier 1977.<br />
<br />
[FIPS-81]<br />
<br />
DES Modes of Operation, Federal Information Processing Standards Publication 81, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, 2 Décembre 1980.<br />
<br />
[FIPS-180-1]<br />
<br />
Secure Hash Standard, Federal Information Processing Standards Publication 180-1, U.S. National Institute of Standards and Technology, U.S. Department Of Commerce, Avril 1995.<br />
<br />
==Autres Références==<br />
[AL00]<br />
<br />
Mohammed Achemlal, Maryline Laurent, Analyse des fonctions des protocoles IPsec et leur intégration dans un réseau privé virtuel, Annales des télécommunications, 2000.<br />
<br />
<br />
[AL98]<br />
<br />
P. Albitz and C. Liu: DNS and BIND, 3rd Edition, ISBN: 1-56592-512-2, O'Reilly and Associates, Septembre 1998.<br />
<br />
<br />
;<div id="BTC02">[BTC02]</div><br />
: T. Bu, L. Gao, D. Towsley, On Characterizing Routing Table Growth, GlobalInternet 2002. http://www-unix.ecs.umass.edu/~lgao/globalinternet2002_tian.pdf<br />
<br />
<br />
;<div id="Ernst01f-fr">[Ernst01f-fr]</div><br />
:Ernst, Thierry, Le Support des Réseaux Mobiles dans IPv6, UniversitéJoseph Fourier, Octobre 2001, Grenoble, France, http://www.inria.fr/rrrt/tu-0714.html<br />
<br />
<br />
;<div id="Ernst03f">[Ernst03f]</div><br />
:Thierry Ernst, Le Support des Réseaux Mobiles dans IPv6, CFIP: Colloque Francophone sur l'Ingenierie des Protocoles, Octobre 2003, Paris<br />
<br />
<br />
[Fen-id]<br />
<br />
Bill Fenner, Management Information Base for the User Datagram Protocol (UDP), draft-ietf-ipv6-rfc2013-update-04.txt, Internet Draft, 20 Octobre 2004, Work in progress.<br />
<br />
<br />
[Hui95]<br />
<br />
C. Huitema: Le routage dans l'Internet, Eyrolles, Octobre 1995.<br />
<br />
[IEEE]<br />
<br />
Protocol Independant Interfaces, IEEE Std 1003.1g, DRAFT~6.6, Mars 1997.<br />
<br />
<br />
[JH-id]<br />
<br />
Jeffrey Haas, Susan Hares, Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), draft-ietf-idr-bgp4-mib-15.txt, Internet Draft, 31 Août 2004, Work in progress.<br />
<br />
<br />
[JM-id]<br />
<br />
Dan Joyal, Vishwas Manral, Management Information Base for OSPFv3, draft-ietf-ospf-ospfv3-mib-09.txt, Internet Draft, 13 Mai 2005, Work in progress.<br />
<br />
<br />
;<div id="Kau-id">[Kau-id]</div><br />
:Charlie Kaufman, Internet Key Exchange (IKEv2) Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-ikev2-17.txt draft-ietf-ipsec-ikev2-17.txt], Internet Draft, 4 Octobre 2004, Work in progress.<br />
<br />
;<div id="LAU03">[LAU03]</div><br />
: M. Laurent-Maknavicius, Le protocole IPsec, [http://www.techniques-ingenieur.fr/affichage/DispIntro.asp?nGcmID=TE7545 TE7545], [http://www.techniques-ingenieur.fr/ Techniques de l'Ingénieur], Sécurité des systèmes d'information, Novembre 2003.<br />
<br />
[LAU04-A]<br />
<br />
M. Laurent-Maknavicius, M. Gardie, LDAP et la certification, Rapport de recherche du GET, 04001 LOR, 2004.<br />
<br />
[LAU04-B]<br />
<br />
M. Laurent-Maknavicius, La sécurité de l'accès distant, Technique et Science Informatiques (TSI), 2004.<br />
<br />
;<div id="MHF-id">[MHF-id]</div><br />
:Ambarish Malpani, Russ Housley, Trevor Freeman, Simple Certificate Validation Protocol (SCVP), [http://www.watersprings.org/pub/id/draft-ietf-pkix-scvp-22.txt draft-ietf-pkix-scvp-22.txt], Internet Draft, Octobre 2005, Work in progress.<br />
<br />
;<div id="Mos-id">[Mos-id]</div><br />
:Robert Moskowitz, Host Identity Protocol, [http://www.watersprings.org/pub/id/draft-ietf-hip-base-04.txt draft-ietf-hip-base-04.txt], Internet Draft, 24 Octobre 2005, Work in progress<br />
<br />
;<div id="Pui02-A">[Pui02-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse critique d'IPsec, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-analyse-rapport/ipsec-analyse-rapport.pdf rapport de recherche 03 004 LOR], 2002.<br />
<br />
;<div id="Pui02-B">[Pui02-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Analyse de l'impact de la mise en oeuvre d'IPsec dans les architectures de Communication, [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/ipsec-interactions-rapport/ipsec-interactions-rapport.pdf rapport de recherche 03 002 LOR], octobre 2002.<br />
<br />
;<div id="Pui03">[Pui03]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects ARP), [http://www-lor.int-evry.fr/~maknavic/Rapports_Recherche/environnement-reel-1-rapport/environnement-reel-1-rapport.pdf rapport de recherche 03 001 LOR], janvier 2003.<br />
<br />
;<div id="Pui04-A">[Pui04-A]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Etude des interactions IPsec/DNS, [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/InteractionDNS.pdf rapport de recherche 04002 LOR], 2004.<br />
<br />
;<div id="Pui04-B">[Pui04-B]</div><br />
:J.J. Puig, M. Laurent-Maknavicius, Evaluation en environnement réel de la mise en oeuvre des Services de sécurité dans les architectures typiques (Aspects liés à ICMP), [http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/IPsec_ICMP.pdf rapport de recherche 04004 LOR], 2004.<br />
<br />
;<div id="RFC2401bis">[RFC2401bis]</div><br />
: Stephen Kent, Karen Seo, Security Architecture for the Internet Protocol, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2401bis-06.txt draft-ietf-ipsec-rfc2401bis-06.txt], Internet Draft, 1 Avril 2005, Work in progress<br />
<br />
<br />
;<div id="RFC2402bis">[RFC2402bis]</div><br />
:Stephen Kent, IP Authentication Header, [http://www.watersprings.org/pub/id/draft-ietf-ipsec-rfc2402bis-11.txt draft-ietf-ipsec-rfc2402bis-11.txt], Internet Draft, 21 Mars 2005, Work in progress.<br />
<br />
[Rou-id]<br />
<br />
Shawn Routhier, Management Information Base for the Internet Protocol (IP), draft-ietf-ipv6-rfc2011-update-10.txt; Internet Draft, 24 Mai 2004, Work in progress.<br />
<br />
[Sch95]<br />
<br />
B. Schneier: Applied Cryptography : protocols, algorithms, and source code in C, (second edition), John Wiley & Sons, ISBN: 0-471-12845-7, 1996.<br />
<br />
[Sta99]<br />
<br />
William Stallings: Snmp, Snmpv2, Snmpv3, and Rmon 1 and 2, Addison Wesley, ISBN: 0-201-48534-6, Janvier 1999.<br />
<br />
[Tout03]<br />
<br />
Laurent Toutain: Réseaux Locaux et Internet: des protocoles à l'interconnexion, Troisième édition revue et augmentée, Hermès, ISBN: 2-7462-0670-6, 2003.<br />
<br />
[Uni31]<br />
<br />
ATM Forum: ATM User-Network Interface (UNI) Specification Version 3.1, Prentice Hall, Englewood Cliffs, NJ, Juin 1995.<br />
<br />
[WH-id]<br />
<br />
Margaret Wasserman, Brian Haberman, IP Forwarding Table MIB, draft-ietf-ipv6-rfc2096-update-07.txt, Internet Draft, 12 février 2004, Work in progress.<br />
<br />
[WK99]<br />
<br />
M. Welsh et L. Kaufman: Le système Linux, 2e édition révisée, Éditions O'Reilly, ISBN: 2-84177-033-8, Janvier 1999.<br />
<br />
==Sites Web sur IPv6 ==<br />
<br />
;[IETF]<br />
:http://www.imag.fr/pub/archive/IETF: Mirroir français du serveur de l'IETF.<br />
<br />
;[6bone]<br />
:http://www.6bone.net: Réseau 6bone.<br />
<br />
;[G6bone]<br />
:http://peirce.logique.jussieu.fr/G6/ Réseau G6-bone (partie francophone de 6bone).<br />
<br />
;[hs247] <br />
:http://hs247.com/ Informations sur le 6bone et IPv6 en général.<br />
<br />
;[ipv6.org]<br />
: http://www.ipv6.org/ pages d'information sur le protocole IPv6<br />
<br />
;[ipv6forum] <br />
:http://www.ipv6forum.org/ Groupement d'industriels pour promouvoir IPv6.<br />
<br />
;[playground] <br />
:http://playground.sun.com/pub/ipng/html/ipng-main.html liste des mises en oeuvre d'IPv6 dans les équipements.</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Acc%C3%A8s_des_entreprises_et_des_particuliers_%C3%A0_l%27Internet_IPv6&diff=2928Accès des entreprises et des particuliers à l'Internet IPv62006-02-23T13:34:40Z<p>Bruno Deniaud: /* TEREDO */</p>
<hr />
<div>{{suivi| Déploiement IPv6 des fournisseurs d'accès (ISP) | Déploiement IPv6 des fournisseurs d'accès (ISP) | Mécanismes d'interopérabilité | Mécanismes d'interopérabilité }}<br />
===ISATAP===<br />
<br />
ISATAP (qui se prononce ice-a-tap) est en quelque sorte la déclinaison des principes de 6to4 à un réseau local, de façon à permettre un tunneling automatique et l'échanges de flux IPv6 entre terminaux double pile interconnectés via un réseau local IPv4 uniquement. ISATAP permet le déploiement de terminaux dual-stack et d'applications IPv6 sur une infrastructure locale IPv4, comme typiquement celle d'un réseau d'entreprise. ISATAP peut être déployé de plusieurs façons : soit simplement au sein des terminaux concernés afin de leur permettre d'échanger des flux IPv6 alors qu'ils sont connectés sur une infrastructure IPv4, soit en combinaison avec des routeurs 6to4 de façon à échanger des flux IPv6 localement et avec des sites distants.<br />
<br />
ISATAP s'appuie sur un format d'adresse spécifique décrit ci-dessous, qui intègre dans la partie identifiant de terminal l'adresse IPv4 du terminal et donc la fonction d'encapsulation/désencapsulation associée.<br />
<br />
ISATAP (''Intra-Site Automatic Tunnel Addressing Protocol'') [[Bibliographie#Templin-id|[Templin-id]]] permet de connecter des équipements terminaux IPv6 isolés dans un réseau IPv4, en gérant de manière automatique l'encapsulation des paquets IPv6 dans des paquets IPv4. Contrairement à 6to4, cette technique s'applique à l'intérieur d'un domaine.<br />
<br />
ISATAP repose sur une particularité de construction des identifiants d'interface proposée par l'IEEE. La figure Identifiant d'interface pour ISATAP montre comment un identifiant d'interface est construit à partir d'une adresse MAC en ajoutant la valeur <tt>0xFFFE</tt>. Or l'IEEE a prévu qu'un identifiant d'interface pouvait contenir une adresse IPv4, la valeur insérée étant alors <tt>0xFE</tt>, comme le montre la figure . La partie sur trois octets indiquant le constructeur prend la valeur de l'OUI (''Organisational Unit identifier'') attribué à l'IANA, c'est-à-dire <tt>00-00-5E</tt>.<br />
<br />
[[image:CS182.gif]]<br />
<br />
Quand un routeur mettant en oeuvre ISATAP reçoit un paquet IPv6 dont l'identifiant d'interface commence par la séquence <tt>00-00-5E-FE</tt>, il en déduit que le paquet est destiné à une machine isolée et encapsule le paquet IPv6 dans un paquet IPv4 dont l'adresse de destination est celle contenue dans la partie identifiant d'interface.<br />
<br />
L'intérêt de cette méthode est de respecter la structure actuelle des adresses IPv6 actuellement en vigueur puisque l'identifiant d'interface a toujours une longueur de 64 octets. Les stations isolées appartiennent au même lien IPv6 et partagent en conséquence le même préfixe IPv6. Mais pour construire complètement l'adresse, il faut pouvoir connaître les préfixes utilisés. Le réseau IPv4 servant à connecter les équipements IPv6 isolés est un réseau NBMA (''Non Broadcast Multiple Access''). Neighbor Discovery possède un mode adapté pour ce type de réseaux : les routeurs ne peuvent donc pas émettre de messages Router Advertisement de manière spontanée. Ces messages ne seront émis qu'en réponse à des Router Sollication.<br />
<br />
L'algorithme de configuration d'un équipement isolé qui utilise ISATAP est le suivant :<br />
<br />
* dans un premier temps, l'équipement doit connaître l'adresse IPv4 du routeur gérant ISATAP. Cette adresse pourrait être apprise par le DNS, ou en utilisant une adresse anycast IPv4 pour joindre le routeur le plus proche.<br />
* l'équipement envoie un message IPv6 Router Sollicitation au routeur en utilisant comme adresse de la source, son adresse lien-local (<tt>fe80::5e:fe:IPv4</tt>) et comme adresse de destination l'adresse de multicast des routeurs (<tt>FF02::02</tt>). Ce message est encapsulé dans un paquet IPv4 dont l'adresse destination est l'adresse IPv4 du routeur.<br />
* le routeur répond au message IPv6 Router Sollicitation en renvoyant en point-à-point, toujours encapsulé dans un paquet IPv4, la liste des préfixes IPv6 utilisés pour joindre les équipements isolés (Router Advertisement).<br />
<br />
Il est à noter que ISATAP est compatible avec 6to4. Le préfixe global peut contenir l'adresse IPv4 du routeur d'accès et la partie identifiant d'interface l'adresse IPv4 privée de l'équiment. Deux tunnels seront nécessaire (le premier entre le routeur 6to4 de la source et le routeur d'accès du site et le second entre le routeur d'accès et le destinataire). un équipement, même s'il ne possède qu'une adresse privée en IPv4, peut de cette manière disposer une adresse IPv6 globale. Malheureusement, cette solution ne peut pas être déployée quand le routeur d'accès n'est pas configuré pour le protocole IPv6, cas généralement rencontré dans les réseaux ADSL.<br />
<br />
===TEREDO===<br />
<br />
Le principal objectif de Teredo (RFC 4380) est de fournir automatiquement une connectivité IPv6 à un terminal situé derrière un NAT et ne disposant donc pas d'une adresse IPv4 globale. Ce mécanisme de type client/serveur s'appuie sur des serveurs et des relais de façon à optimiser le chemin parcouru par les paquets IPv6 encapsulés qui transiteront via le relais le plus "proche" en non plus sytématiquement par un point unique comme avec le mécanisme de Tunnel Broker. Cependant, l'optimisation du chemin parcouru par les paquets IPv6 encapsulés conduit à une certaine complexité dans les échanges client/serveur/relais, en particulier lors de chaque phase d'initialisation d'une communication. Teredo est un outil de dernier recours, destiné à être utilisé en l'absence de connectivité IPv6 native, ou de tunnel configuré, ou de la mise oeuvre de 6to4. Ce mécanisme concerne exclusivement des terminaux individuels ne disposant pas d'une adresse IPv4 publique ; il ne s'applique pas à des sous-réseaux.<br />
<br />
Teredo s'appuie sur un format d'adresse particulier (cf. figure Format des adresse Teredo) qui intègre dans la partie préfixe l'adresse IPv4 du serveur Teredo, et dans la partie identifiant les adresse et numéro de port (en sortie de NAT) du terminal client Teredo. Cette dernière infomation est brouillée afin de ne pas être modifiée par certains NAT qui systématiquement modifient les séquences binaires ressemblant à une adresse.<br />
<br />
[[image:CS183.gif]]<br />
<br />
L'objectif de Teredo est de rendre entièrement automatique la configuration de tunnels IPv6-dans-IPv4 pour des terminaux situés derrière un ou plusieurs NAT, et utilisant par conséquent des adresses IPv4 privées. Pour cela, Teredo met en ?uvre une encapsulation UDP. Teredo s'appuie sur un serveur et des relais externes au réseau auquel est connecté le client Teredo, de façon à optimiser autant que possible le routage IPv6, en évitant un point d'encapsulation unique tel qu'on peut le rencontrer par exemple avec une solution de type tunnel broker. De plus, Teredo utilise un format d'adresse IPv6 spécifique qui ne requiert aucune allocation de la part des organismes officiels.<br />
<br />
Le préfixe Teredo de longueur 64 bits inclus l'adresse du serveur Teredo auquel le terminal est rattaché. A la date d'édition de cet ouvrage le préfixe Teredo a la valeur <tt>3FFE:831F::/32</tt> mais l'IANA pourrait assigner une valeur définitive.<br />
<br />
L'architecture globale et les différents éléments mise en oeuvre dans Teredo sont décrits figure architecture Teredo. Le but recherché est que chaque client Teredo soit rattaché au serveur Teredo le plus proche, et que le trafic IPv6 transite par le relais Teredo lui aussi le plus proche au sens routage IPv6.<br />
<br />
[[image:CS184.gif]]<br />
<br />
Cependant, il existe plusieurs types de NAT, selon la politique de traduction adoptée (en particulier pour le port UDP), qui peuvent être classés selon deux grandes familles :<br />
<br />
* celle des "cone NATs" (qui regroupe en fait trois type différents NAT) et<br />
* celle des "symmetric NATs".<br />
* Il est important de noter que Teredo tel qu'il est défini actuellement, ne peut pas fonctionner au travers d'un "symmetric NAT". En effet, contrairement aux "cone NATs", un "symmetric NAT" associe un couple adresse/port externe différent selon l'adresse et l'application destinatrices du datagramme, lors de la traduction de ce dernier. Ainsi, les caractéristiques du tunnel UDP d'un terminal Teredo ne sont pas globalement uniques, alors que le mécanisme d'initialisation et de maintien de contexte de Teredo requiert cette unicité.<br />
<br />
Globalement le fonctionnement de Teredo est plutôt complexe puisqu'il nécessite la coopération de trois types de noeuds réseau (client, serveur et relais Teredo), afin de :<br />
<br />
* de déterminer le type de NAT traversé et d'assigner une adresse IPv6 au client Teredo<br />
* de maintenir ouvert dans le NAT, l"association entre adresse/port internes et adresse/port externes<br />
<br />
La phase d'initialisation d'un client Teredo a en particulier pour but de déterminer le type de NAT derrière lequel se trouve le client Teredo. A l'issue de cette initialisation, et dès lors qu'aucun "symmetric NAT" n'est traversé, il est alors nécessaire de maintenir l'association ouverte dans le NAT, par l'envoi périodique d'un message spécifique vers le serveur Teredo qui a pour effet de ré-initialiser le time-out d'inactivité du NAT.<br />
<br />
De plus, l'initialisation d'une communication IPv6 sera différente, d'une part selon le type de cone NAT traversé, et d'autre part selon la destination : client Teredo sur le même lien, client Teredo sur un site différent, terminal IPv6 externe.<br />
<br />
L'initialisation typique d'une communication entre un client Teredo et un terminal uniquement IPv6, est illustrée dans l'exemple figure exemple d'initialisation d'une communication.<br />
<br />
[[image:CS185.gif]]<br />
{{suivi| Déploiement IPv6 des fournisseurs d'accès (ISP) | Déploiement IPv6 des fournisseurs d'accès (ISP) | Mécanismes d'interopérabilité | Mécanismes d'interopérabilité }}</div>Bruno Deniaudhttp://livre.g6.asso.fr/index.php?title=Acc%C3%A8s_des_entreprises_et_des_particuliers_%C3%A0_l%27Internet_IPv6&diff=2922Accès des entreprises et des particuliers à l'Internet IPv62006-02-23T09:50:24Z<p>Bruno Deniaud: </p>
<hr />
<div>{{suivi| Déploiement IPv6 des fournisseurs d'accès (ISP) | Déploiement IPv6 des fournisseurs d'accès (ISP) | Mécanismes d'interopérabilité | Mécanismes d'interopérabilité }}<br />
===ISATAP===<br />
<br />
ISATAP (qui se prononce ice-a-tap) est en quelque sorte la déclinaison des principes de 6to4 à un réseau local, de façon à permettre un tunneling automatique et l'échanges de flux IPv6 entre terminaux double pile interconnectés via un réseau local IPv4 uniquement. ISATAP permet le déploiement de terminaux dual-stack et d'applications IPv6 sur une infrastructure locale IPv4, comme typiquement celle d'un réseau d'entreprise. ISATAP peut être déployé de plusieurs façons : soit simplement au sein des terminaux concernés afin de leur permettre d'échanger des flux IPv6 alors qu'ils sont connectés sur une infrastructure IPv4, soit en combinaison avec des routeurs 6to4 de façon à échanger des flux IPv6 localement et avec des sites distants.<br />
<br />
ISATAP s'appuie sur un format d'adresse spécifique décrit ci-dessous, qui intègre dans la partie identifiant de terminal l'adresse IPv4 du terminal et donc la fonction d'encapsulation/désencapsulation associée.<br />
<br />
ISATAP (''Intra-Site Automatic Tunnel Addressing Protocol'') [[Bibliographie#Templin-id|[Templin-id]]] permet de connecter des équipements terminaux IPv6 isolés dans un réseau IPv4, en gérant de manière automatique l'encapsulation des paquets IPv6 dans des paquets IPv4. Contrairement à 6to4, cette technique s'applique à l'intérieur d'un domaine.<br />
<br />
ISATAP repose sur une particularité de construction des identifiants d'interface proposée par l'IEEE. La figure Identifiant d'interface pour ISATAP montre comment un identifiant d'interface est construit à partir d'une adresse MAC en ajoutant la valeur <tt>0xFFFE</tt>. Or l'IEEE a prévu qu'un identifiant d'interface pouvait contenir une adresse IPv4, la valeur insérée étant alors <tt>0xFE</tt>, comme le montre la figure . La partie sur trois octets indiquant le constructeur prend la valeur de l'OUI (''Organisational Unit identifier'') attribué à l'IANA, c'est-à-dire <tt>00-00-5E</tt>.<br />
<br />
[[image:CS182.gif]]<br />
<br />
Quand un routeur mettant en oeuvre ISATAP reçoit un paquet IPv6 dont l'identifiant d'interface commence par la séquence <tt>00-00-5E-FE</tt>, il en déduit que le paquet est destiné à une machine isolée et encapsule le paquet IPv6 dans un paquet IPv4 dont l'adresse de destination est celle contenue dans la partie identifiant d'interface.<br />
<br />
L'intérêt de cette méthode est de respecter la structure actuelle des adresses IPv6 actuellement en vigueur puisque l'identifiant d'interface a toujours une longueur de 64 octets. Les stations isolées appartiennent au même lien IPv6 et partagent en conséquence le même préfixe IPv6. Mais pour construire complètement l'adresse, il faut pouvoir connaître les préfixes utilisés. Le réseau IPv4 servant à connecter les équipements IPv6 isolés est un réseau NBMA (''Non Broadcast Multiple Access''). Neighbor Discovery possède un mode adapté pour ce type de réseaux : les routeurs ne peuvent donc pas émettre de messages Router Advertisement de manière spontanée. Ces messages ne seront émis qu'en réponse à des Router Sollication.<br />
<br />
L'algorithme de configuration d'un équipement isolé qui utilise ISATAP est le suivant :<br />
<br />
* dans un premier temps, l'équipement doit connaître l'adresse IPv4 du routeur gérant ISATAP. Cette adresse pourrait être apprise par le DNS, ou en utilisant une adresse anycast IPv4 pour joindre le routeur le plus proche.<br />
* l'équipement envoie un message IPv6 Router Sollicitation au routeur en utilisant comme adresse de la source, son adresse lien-local (<tt>fe80::5e:fe:IPv4</tt>) et comme adresse de destination l'adresse de multicast des routeurs (<tt>FF02::02</tt>). Ce message est encapsulé dans un paquet IPv4 dont l'adresse destination est l'adresse IPv4 du routeur.<br />
* le routeur répond au message IPv6 Router Sollicitation en renvoyant en point-à-point, toujours encapsulé dans un paquet IPv4, la liste des préfixes IPv6 utilisés pour joindre les équipements isolés (Router Advertisement).<br />
<br />
Il est à noter que ISATAP est compatible avec 6to4. Le préfixe global peut contenir l'adresse IPv4 du routeur d'accès et la partie identifiant d'interface l'adresse IPv4 privée de l'équiment. Deux tunnels seront nécessaire (le premier entre le routeur 6to4 de la source et le routeur d'accès du site et le second entre le routeur d'accès et le destinataire). un équipement, même s'il ne possède qu'une adresse privée en IPv4, peut de cette manière disposer une adresse IPv6 globale. Malheureusement, cette solution ne peut pas être déployée quand le routeur d'accès n'est pas configuré pour le protocole IPv6, cas généralement rencontré dans les réseaux ADSL.<br />
<br />
===TEREDO===<br />
<br />
Le principal objectif de Teredo [[Bibliographie#Huitema-id|[Huitéma-id]]] est de fournir automatiquement une connectivité IPv6 à un terminal situé derrière un NAT et ne disposant donc pas d'une adresse IPv4 globale. Ce mécanisme de type client/serveur s'appuie sur des serveurs et des relais de façon à optimiser le chemin parcouru par les paquets IPv6 encapsulés qui transiteront via le relais le plus "proche" en non plus sytématiquement par un point unique comme avec le mécanisme de Tunnel Broker. Cependant, l'optimisation du chemin parcouru par les paquets IPv6 encapsulés conduit à une certaine complexité dans les échanges client/serveur/relais, en particulier lors de chaque phase d'initialisation d'une communication. Teredo est un outil de dernier recours, destiné à être utilisé en l'absence de connectivité IPv6 native, ou de tunnel configuré, ou de la mise oeuvre de 6to4. Ce mécanisme concerne exclusivement des terminaux individuels ne disposant pas d'une adresse IPv4 publique ; il ne s'applique pas à des sous-réseaux.<br />
<br />
Teredo s'appuie sur un format d'adresse particulier (cf. figure Format des adresse Teredo) qui intègre dans la partie préfixe l'adresse IPv4 du serveur Teredo, et dans la partie identifiant les adresse et numéro de port (en sortie de NAT) du terminal client Teredo. Cette dernière infomation est brouillée afin de ne pas être modifiée par certains NAT qui systématiquement modifient les séquences binaires ressemblant à une adresse.<br />
<br />
[[image:CS183.gif]]<br />
<br />
L'objectif de Teredo est de rendre entièrement automatique la configuration de tunnels IPv6-dans-IPv4 pour des terminaux situés derrière un ou plusieurs NAT, et utilisant par conséquent des adresses IPv4 privées. Pour cela, Teredo met en ?uvre une encapsulation UDP. Teredo s'appuie sur un serveur et des relais externes au réseau auquel est connecté le client Teredo, de façon à optimiser autant que possible le routage IPv6, en évitant un point d'encapsulation unique tel qu'on peut le rencontrer par exemple avec une solution de type tunnel broker. De plus, Teredo utilise un format d'adresse IPv6 spécifique qui ne requiert aucune allocation de la part des organismes officiels.<br />
<br />
Le préfixe Teredo de longueur 64 bits inclus l'adresse du serveur Teredo auquel le terminal est rattaché. A la date d'édition de cet ouvrage le préfixe Teredo a la valeur <tt>3FFE:831F::/32</tt> mais l'IANA pourrait assigner une valeur définitive.<br />
<br />
L'architecture globale et les différents éléments mise en oeuvre dans Teredo sont décrits figure architecture Teredo. Le but recherché est que chaque client Teredo soit rattaché au serveur Teredo le plus proche, et que le trafic IPv6 transite par le relais Teredo lui aussi le plus proche au sens routage IPv6.<br />
<br />
[[image:CS184.gif]]<br />
<br />
Cependant, il existe plusieurs types de NAT, selon la politique de traduction adoptée (en particulier pour le port UDP), qui peuvent être classés selon deux grandes familles :<br />
<br />
* celle des "cone NATs" (qui regroupe en fait trois type différents NAT) et<br />
* celle des "symmetric NATs".<br />
* Il est important de noter que Teredo tel qu'il est défini actuellement, ne peut pas fonctionner au travers d'un "symmetric NAT". En effet, contrairement aux "cone NATs", un "symmetric NAT" associe un couple adresse/port externe différent selon l'adresse et l'application destinatrices du datagramme, lors de la traduction de ce dernier. Ainsi, les caractéristiques du tunnel UDP d'un terminal Teredo ne sont pas globalement uniques, alors que le mécanisme d'initialisation et de maintien de contexte de Teredo requiert cette unicité.<br />
<br />
Globalement le fonctionnement de Teredo est plutôt complexe puisqu'il nécessite la coopération de trois types de noeuds réseau (client, serveur et relais Teredo), afin de :<br />
<br />
* de déterminer le type de NAT traversé et d'assigner une adresse IPv6 au client Teredo<br />
* de maintenir ouvert dans le NAT, l"association entre adresse/port internes et adresse/port externes<br />
<br />
La phase d'initialisation d'un client Teredo a en particulier pour but de déterminer le type de NAT derrière lequel se trouve le client Teredo. A l'issue de cette initialisation, et dès lors qu'aucun "symmetric NAT" n'est traversé, il est alors nécessaire de maintenir l'association ouverte dans le NAT, par l'envoi périodique d'un message spécifique vers le serveur Teredo qui a pour effet de ré-initialiser le time-out d'inactivité du NAT.<br />
<br />
De plus, l'initialisation d'une communication IPv6 sera différente, d'une part selon le type de cone NAT traversé, et d'autre part selon la destination : client Teredo sur le même lien, client Teredo sur un site différent, terminal IPv6 externe.<br />
<br />
L'initialisation typique d'une communication entre un client Teredo et un terminal uniquement IPv6, est illustrée dans l'exemple figure exemple d'initialisation d'une communication.<br />
<br />
[[image:CS185.gif]]<br />
{{suivi| Déploiement IPv6 des fournisseurs d'accès (ISP) | Déploiement IPv6 des fournisseurs d'accès (ISP) | Mécanismes d'interopérabilité | Mécanismes d'interopérabilité }}</div>Bruno Deniaud