Difference between revisions of "MOOC:Ressources"

From Livre IPv6

(→‎Durée de vie des adresses)
(→‎Internet Usage)
 
(77 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
Le format et la représentation des adresses sont les modifications les plus visibles pour l'utilisateur expérimenté et l'ingénieur réseau dans cette nouvelle version du protocole. <font color=green>En effet la taille de l'adresse reste fixe mais passe de 32 à 128 bits. </font>Même si les principes sont fortement similaires à ceux employés dans IPv4, cet adressage apparaît <font color=green> à première vue </font> beaucoup plus complexe. Il est intéressant d'en comprendre le principe et les règles d'attribution avant d'aborder les aspects protocolaires.
+
> [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Ressources|Ressources]]
 +
----
 +
= Ressources bibliographiques=
  
 +
===Articles===
 +
*Bernstein, Daniel J. [http://cr.yp.to/djbdns/ipv6mess.html The IPv6 mess].
 +
*. Cui Y., Wu P., Xu M., et al., “4over6: Network Layer Virtualization for IPv4-IPv6 Coexistence,” IEEE Network, October 2012.
  
−
Ce chapitre passe en revue les différents types d'adresses. Il explique en détail le plan d'adressage agrégé qui a été retenu pour construire les réseaux de tests et opérationnels. Il décrit également la manière de calculer les identifiants d'interface utilisé par plusieurs types d'adresses (voir également [[Supports de transmission]]).
+
=== Livres===
  
−
= Aspects fondamentaux de l'adressage IPv6=
+
* Graziani, R. (2012). Ed.: Cisco Press. [http://proquest.safaribooksonline.com/book/networking/ip/9780133033496 BookOnLine] IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6
 +
* liste sur la page de Pascal [[User:Panelli|Anelli]]
 +
* Migrating to IPv6: A Practical Guide to Implementing IPv6 in Mobile and FIxed network Par Marc Blanchet
  
−
==Représentation des adresses ==
+
====IETF WG====
 +
* [https://datatracker.ietf.org/wg/v6ops/charter/ V6ops]
 +
* [https://datatracker.ietf.org/wg/6man/charter/ IPv6 maintenance]
 +
* [https://datatracker.ietf.org/wg/softwire/charter/ Softwire]
  
−
La représentation textuelle d'une adresse IPv6 se fait en découpant le mot de 128 bits de l'adresse en 8 mots de 16 bits séparés par le caractère «:», chacun d'eux étant représenté en hexadécimal. Par exemple :
+
===RFC===
 +
Référence <strike>barrée</strike> si reprise dans une séquence
  
−
  <tt>2001:0DB8:0000:0000:0400:A987:6543:210F</tt>
+
* RFC 8956 Dissemination of Flow Specification Rules for IPv6
 +
* RFC 8883 ICMPv6 Errors for Discarding Packets Due to Processing Limits
 +
*  RFC 8781  Discovering PREF64 in Router Advertisements
 +
* RFC 8754 on IPv6 Segment Routing Header (SRH)
 +
* RFC 8504: IPv6 Node Requirements([http://www.bortzmeyer.org/8504.html Bortzmeyer])
 +
* RFC 8501: Reverse DNS in IPv6 for Internet Service Providers ([http://www.bortzmeyer.org/8501.html Bortzmeyer])
 +
* RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) ([http://www.bortzmeyer.org/8415.html Bortzmeyer])
 +
* RFC 8201 Path MTU Discovery for IP version 6 ([http://www.bortzmeyer.org/8201.html Bortzmeyer])
 +
* RFC 8200 Internet Protocol, Version 6 (IPv6) Specification ([http://www.bortzmeyer.org/8200.html Bortzmeyer])
 +
* RFC 8021: Generation of IPv6 Atomic Fragments Considered Harmful ([http://www.bortzmeyer.org/8021.html Bortzmeyer])
 +
* RFC 7608 IPv6 Prefix Length Recommendation for Forwarding
 +
* RFC 7600 IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)
 +
* RFC 7599 Mapping of Address and Port using Translation (MAP-T)
 +
* RFC 7596 Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture
 +
* RFC 7421 Analysis of the 64-bit Boundary in IPv6 Addressing ([http://www.bortzmeyer.org/7421.html Bortzmeyer])
 +
* RFC 7411 Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers
 +
* RFC 7404 Using Only Link-Local Addressing inside an IPv6 Network ([http://www.bortzmeyer.org/7404.html Bortzmeyer])
 +
* RFC 7381 Enterprise IPv6 Deployment Guidelines ([http://www.bortzmeyer.org/7381 Bortzmeyer])
 +
* RFC 7368 IPv6 Home Networking Architecture Principles
 +
* RFC 7346 IPv6 Multicast Address Scopes
 +
* RFC 7269 NAT64 Deployment Options and Experience ([http://www.bortzmeyer.org/7269 Bortzmeyer])
 +
* RFC 7227 Guidelines for Creating New DHCPv6 Options
 +
* RFC 7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)  ([http://www.bortzmeyer.org/7225 Bortzmeyer])
 +
* RFC 7219 SEcure Neighbor Discovery (SEND)  Source Address Validation Improvement (SAVI)
 +
* RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) ([http://www.bortzmeyer.org/7217.html Bortzmeyer])
 +
* RFC 7148 Prefix Delegation Support for Proxy Mobile IPv6
 +
* RFC 7136 Significance of IPv6 Interface Identifiers ([http://www.bortzmeyer.org/7136.html Bortzmeyer])
 +
* RFC 7123 Security Implications of IPv6 on IPv4 Networks ([http://www.bortzmeyer.org/7123 Bortzmeyer])
 +
* RFC 7112 Implications of Oversized IPv6 Header Chains
 +
* RFC 7098 Using the IPv6 Flow Label for Load Balancing in Server Farms
 +
* RFC 7084 Basic Requirements for IPv6 Customer Edge Routers
 +
* RFC 7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms ([http://www.bortzmeyer.org/7059 Bortzmeyer])
 +
* RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix
 +
* RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis ([http://www.bortzmeyer.org/7050 Bortzmeyer])
 +
* RFC 7048 Neighbor Unreachability Detection Is Too Impatient
 +
* RFC 7045 Transmission and Processing of IPv6 Extension Headers
 +
* RFC 7040 Public IPv4-over-IPv6 Access Network
 +
* RFC 7010 IPv6 Site Renumbering Gap Analysis ([http://www.bortzmeyer.org/7010.html Bortzmeyer])
 +
* RFC 6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
 +
* RFC 6948 Some Measurements on World IPv6 Day from an End-User Perspective ([http://www.bortzmeyer.org/6948.html Bortzmeyer])
 +
* RFC 6946 Processing of IPv6 "Atomic" Fragments
 +
* RFC 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
 +
* RFC 6935 IPv6 and UDP Checksums for Tunneled Packets ([http://www.bortzmeyer.org/6935 Bortzmeyer])
 +
* RFC 6908 Deployment Considerations for Dual-Stack Lite ([http://www.bortzmeyer.org/6908 Bortzmeyer])
 +
* RFC 6890  Special-Purpose IP Address Registries ([http://www.bortzmeyer.org/6890.html Bortzmeyer])
 +
* RFC 6889 Analysis of Stateful 64 Translation
 +
* RFC 6879 IPv6 Enterprise Network Renumbering Scenarios,  Considerations, and Methods ([http://www.bortzmeyer.org/6879.html Bortzmeyer])
 +
* RFC 6877 464XLAT: Combination of Stateful and Stateless Translation
 +
* RFC 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers ([http://www.bortzmeyer.org/6874.html Bortzmeyer])
 +
* RFC 6866 Problem Statement for Renumbering IPv6 Hosts  with Static Addresses in Enterprise Networks ([http://www.bortzmeyer.org/6866.html Bortzmeyer])
 +
* RFC 6791 Stateless Source Address Mapping for ICMPv6 Packets
 +
* RFC 6782 Wireline Incremental IPv6 ([http://www.bortzmeyer.org/6782 Bortzmeyer])
 +
* RFC 6752 Issues with Private IP Addressing in the Internet
 +
* RFC 6732 6to4 Provider Managed Tunnels
 +
* RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6) ([http://www.bortzmeyer.org/6724.html Bortzmeyer])
 +
* RFC 6611 Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario
 +
* RFC 6586 Experiences from an IPv6-Only Network  ([http://www.bortzmeyer.org/6586 Bortzmeyer])
 +
* RFC 6654 Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd)
 +
* RFC 6589 Considerations for Transitioning Content to IPv6 ([http://www.bortzmeyer.org/6589 Bortzmeyer])
 +
* RFC 6586 Experiences from an IPv6-Only Network
 +
* RFC 6583 Operational Neighbor Discovery Problems
 +
* RFC 6564 A Uniform Format for IPv6 Extension Headers
 +
* RFC 6555 Happy Eyeballs: Success with Dual-Stack Hosts ([http://www.bortzmeyer.org/6555.html Bortzmeyer])
 +
* RFC 6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6
 +
* RFC 6540 IPv6 Support Required for All IP-Capable Nodes
 +
* RFC 6496 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)
 +
* RFC 6437 IPv6 Flow Label Specification, voir aussi RFC  6438, RFC 6436
 +
* RFC 6434 IPv6 Node Requirements
 +
* RFC 6384  An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
 +
* <strike>RFC 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage ([http://www.bortzmeyer.org/6346.html Bortzmeyer])</strike>
 +
* RFC 6343 Advisory Guidelines for 6to4 Deployment
 +
* RFC 6342 Mobile Networks Considerations for IPv6 Deployment, aussi RFC 6212
 +
* RFC 6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option    for Dual-Stack Lite ([http://www.bortzmeyer.org/6334 Bortzmeyer])
 +
* RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion ([http://www.bortzmeyer.org/6333 Bortzmeyer])
 +
* RFC 6324 Routing Loop Attack Using IPv6 Automatic Tunnels
 +
* RFC 6301  A Survey of Mobility Support in the Internet
 +
* RFC 6294 Survey of Proposed Use Cases for the IPv6 Flow Label
 +
* RFC 6275 Mobility Support in IPv6
 +
* RFC 6221 Lightweight DHCPv6 Relay Agent
 +
* RFC 6204 Basic Requirements for IPv6 Customer Edge Routers
 +
* RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment ([http://www.bortzmeyer.org/6180 Bortzmeyer])
 +
* RFC 6177 IPv6 Address Assignment to End Sites ([http://www.bortzmeyer.org/6177.html Bortzmeyer])
 +
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links ([http://www.bortzmeyer.org/6164.html Bortzmeyer])
 +
* RFC 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers ([http://www.bortzmeyer.org/6147 Bortzmeyer])
 +
* RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers ([http://www.bortzmeyer.org/6146 Bortzmeyer])
 +
* RFC 6145 IP/ICMP Translation Algorithm ([http://www.bortzmeyer.org/6145 Bortzmeyer])
 +
* RFC 6144 Framework for IPv4/IPv6 Translation ([http://www.bortzmeyer.org/6144 Bortzmeyer])
 +
* RFC 6127 IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios
 +
* RFC 6106 IPv6 Router Advertisement Options for DNS Configuration
 +
* RFC 6104: Rogue IPv6 Router Advertisement Problem Statement
 +
* RFC 6092: Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092 Bortzmeyer])
 +
* RFC 6085 Address Mapping of IPv6 Multicast Packets on Ethernet
 +
* RFC 6081 Teredo Extensions
 +
* RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators ([http://www.bortzmeyer.org/6052 Bortzmeyer])
 +
* RFC 6036 Emerging Service Provider Scenarios for IPv6 Deployment ([http://www.bortzmeyer.org/6036 Bortzmeyer])
 +
* RFC 5952 A Recommendation for IPv6 Address Text Representation ([http://www.bortzmeyer.org/5952.html Bortzmeyer])
 +
* RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
 +
* RFC 5902 IAB Thoughts on IPv6 Network Address Translation ([http://www.bortzmeyer.org/5902 Bortzmeyer])
 +
* RFC 5722 Handling of Overlapping IPv6 Fragments
 +
* RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) ([http://www.bortzmeyer.org/5569 Bortzmeyer])
 +
* RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) ([http://www.bortzmeyer.org/5572 Bortzmeyer])
 +
* RFC 5453 Reserved IPv6 Interface Identifiers ([http://www.bortzmeyer.org/5453.html Bortzmeyer])
 +
* RFC 5375 IPv6 Unicast Address Assignment Considerations ([http://www.bortzmeyer.org/5375.html Bortzmeyer])
 +
* RFC 5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
 +
* RFC 5156 Special-Use IPv6 Addresses ([http://www.bortzmeyer.org/5156.html Bortzmeyer])
 +
* RFC 4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status
 +
* RFC 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks
 +
* RFC 4925 Softwire Problem Statement ([http://www.bortzmeyer.org/4925 Bortzmeyer])
 +
* RFC 4864 Local Network Protection for IPv6 ([http://www.bortzmeyer.org/4864 Bortzmeyer])
 +
* RFC 4862 IPv6 Stateless Address Autoconfiguration
 +
* RFC 4821 Packetization Layer Path MTU Discovery ([[http://www.bortzmeyer.org/4821.html Bortzmeyer]])
 +
* RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
 +
* RFC 4213 Transition Mechanisms for IPv6 Hosts and Routers  ([http://www.bortzmeyer.org/4213 Bortzmeyer])
  
−
Dans un champ, il n'est pas nécessaire d'écrire les zéros placés en tête :
+
===Support du G6===
 +
* Cours IPv6 déploiement de P. Anelli ([http://lim.univ-reunion.fr/staff/panelli/4_teaching/IUT/RT2-TR3/P-IPv6-transition.pdf pdf])
 +
* Chapitre du livre Intégration du G6 [http://livre.g6.asso.fr/index.php?title=Intégration_d%27IPv6_et_des_applications ici]
 +
* Slides du G6 sur l'Intégration ([http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/G6_slides-integration.pdf pdf])
 +
* La base des slides du G6 ( [http://lim.univ-reunion.fr/staff/panelli/Mooc-IPv6/AllG6Slides.pdf pdf] )
 +
* Formation G6 par L Toutain [http://c2.touta.in/?page_id=323]
 +
* [[Table des matières|Livre "IPv6, Théorie et Pratique"]]
 +
* [http://g6.asso.fr/formation Support de cours G6]
  
−
  <tt>2001:DB8:0:0:400:A987:6543:210F</tt>
+
=== Références générales ===
 +
* [http://www.6deploy.eu/index.php?page=tutorials2 Tutorials 6Deploy-2]
 +
* Support TutTelNet IPv6 (Telecom Lille)
 +
* Cours IPv6 de P. Anelli (IUT R&T) [http://lim.univ-reunion.fr/staff/panelli/4_teaching/IUT/index.html lien]
 +
* [http://www.ripe.net/lir-services/training/courses Cours de RIPE ]
 +
* [http://www.internetsociety.org/deploy360/roadmap/ipv6/ Dossier IPv6 par l'Internet Society]: cours stats, video, how-to, etc.
 +
* [http://www.ipv6actnow.org/info/transition/ Mécanismes de Transition] par IPv6 Act Now
 +
* [http://www.ripe.net/lir-services/training/e-learning/ipv6/useful-links Les mécanismes de Transition] par RIPE (des liens, des vidéos)
 +
* [http://www.isatap.org/ isatap.org] Les ressources pour ISATAP
 +
* [https://www.nanog.org/archives/presentations?k=IPv6&s=0&m=0&a=search NANOG] Présentations NANOG sur IPv6
 +
* [http://www.potaroo.net/ispcol/index.html The ISP Column]
 +
* Nanog: [http://www.nanog.org/meetings/nanog49/presentations/IPv6atGoogle.pdf IPv6atGoogle]
 +
* Moving to IPv6 (Nanog) [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf pdf]
 +
* IPv6 to Standard [http://www.ipv6-to-standard.org/ url]
 +
*  The IPv6 Portal [http://www.ipv6tf.org url]
 +
* Lothaire Yarding "Yet Another Ipv6 to the Next Generation", Université de Lorraine, Lothaire, par Julien Vaubourg [http://julien.vaubourg.com/files/lothaire-yarding_ipv6.pdf Lothaire Yarding]
 +
* LinkedIn Learning : [https://www.linkedin.com/learning/decouvrir-ipv6/ Découvrir IPv6 (Cours conçu par : Rudi Bruchez)]
 +
* A titre de demonstration, il y a ce site: http://www.fredbovy.com/modulation/Modules.html qui présente quelques animations
  
−
En outre plusieurs champs nuls consécutifs peuvent être abrégés par «::». Ainsi l'adresse précédente peut s'écrire comme suit :
+
===Adressage===
  
−
<tt>2001:DB8::400:A987:6543:210F</tt>
+
* http://www.cbtnuggets.com/it-training-videos/course/cbtn_ipv6 (Vidéos comprehensives mais non-gratuites de Keith )
 +
* https://www.youtube.com/channel/UCrCh8p6p2UZC18vqSBhN_sA (chaîne Youtube de Keith)
 +
* [https://www.youtube.com/watch?v=rljkNMySmuM&index=1&list=PL7FBD333BAB233A44 Keith Barker "Make Sense of an IPv6 Address"]
 +
* [https://www.youtube.com/watch?v=lNev5bboMnM&index=2&list=PL7FBD333BAB233A44 Keith Barker "Lov'n the Link Local Address"]
 +
* [https://tools.ietf.org/html/draft-ietf-6man-why64-08  IETF Draft - Analysis of the 64-bit Boundary in IPv6 Addressing]
 +
* [https://community.infoblox.com/blogs/2015/01/09/do-you-really-need-subnet-calculator-ipv6 Do you really need an IPv6 subnet calculator ?]
 +
* [http://www.ripe.net/lir-services/training/material/basic-ipv6-training-course/Basic-IPv6-Addressing-Plan-With-Possible-Solutions.pdf Exercice du RIPE sur la définition d'un plan d'adressage]
 +
* CISCO. (2008). [http://www.cisco.com/web/strategy/docs/gov/IPv6_WP.pdf IPv6 Addressing White Paper].
 +
* [http://bcop.nanog.org/images/6/62/BCOP-IPv6_Subnetting.pdf NANOG BCOP IPv6 Subnetting]
 +
* http://www.cabrillo.edu/~rgraziani/ipv6.html (Un des meilleurs sites dédié à IPv6)
  
−
Naturellement, pour éviter toute ambiguïté, l'abréviation «::» ne peut apparaître qu'une fois au plus dans une adresse. Les cas extrêmes sont l'adresse indéfinie (utilisée pour désigner les routes par défaut) à tous les bits à zéro et qui se note de manière compacte :
+
===vidéo===
 +
* [https://www.youtube.com/watch?v=Od8DDowENMI IPv6 pour les nuls] une présentation faite par des personnels de Microsoft dans un techday.
 +
* [https://www.youtube.com/watch?v=AfFG5jA2S_w Spirent video] sur la transition et globalement les vidéos you tube liées
 +
* [https://www.youtube.com/results?search_query=alantalkstech Vidéos alantalkstech sur Youtube] de spirent
 +
* [https://www.youtube.com/results?search_query=IPv6+Ipv4&search_sort=video_view_count Les vidéos IPv6 sur Youtube]
 +
* [https://www.ripe.net/support/training/videos/ipv6/transition-mechanisms IPv6 Transition Mechanisms] by RIPE
  
−
<tt>::</tt>
+
=== Presse. - rapport ===
  
−
et l'adresse de bouclage (loopback), équivalent du préfixe <tt>127/8</tt> dont tous les bits sont à zéro sauf le dernier et qui s'écrit :
+
* [https://thenewstack.io/kubernetes-warms-up-to-ipv6/ Kubernetes Warms Up to IPv6]
 +
*[https://www.numerama.com/tech/529644-ipv6-en-france-le-regulateur-des-telecoms-appelle-a-sy-mettre-de-toute-urgence.html IPv6 en France : le régulateur des télécoms appelle à s’y mettre de « toute urgence »] Numerama juin 2019
 +
* [https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/lipv6/suivi-epuisement-adresses-ipv4.html Suivi de l'épuisement des adresses IPv4] par l'ARCEP
 +
* [https://www.zdnet.fr/actualites/ipv4-la-penurie-d-adresses-disponibles-c-est-pour-novembre-2019-39891627.htm Une "Task force" créée par l'Arcep] zdnet octobre 2019
 +
*[https://www.zdnet.fr/pratique/quelles-recommandations-pour-migrer-vers-ipv6-39860280.htm Quelques recommandations pour migrer vers l'IPv6] zdnet octobre 2019
 +
* [https://www.universfreebox.com/article/51128/IPV4-la-penurie-s-accelere-moins-de-3-millions-d-adresses-disponibles IPV4 : la pénurie s’accélère, moins de 3 millions d’adresses disponibles] Univers FreeBox Juillet 2019
 +
* [https://www.lemagit.fr/actualites/252468059/Penurie-IPv4-comment-lInternet-europeen-sombre-dans-les-magouilles Pénurie IPv4 : comment l’Internet européen sombre dans les magouilles] LeMagIT Aout 2019<br>Une critique d'IPv6
 +
*  Zergy (2015) Article en ligne [http://blog.zergy.net/index.php?article2/ipocalypse Ipocalypse]
 +
* Col, P. (2016). ZDNet. [http://www.zdnet.fr/actualites/ipv6-avertissement-solennel-du-ripe-39837614.htm IPv6 : avertissement solennel du RIPE].
  
−
  <tt>::1</tt>
+
=== Internet Usage ===
  
−
La représentation des préfixes IPv6 est similaire à la notation CIDR RFC 1519 utilisée pour les préfixes IPv4. Un préfixe IPv6 est donc représenté par la notation :
+
* Cisco 2018-2023 [https://www.cisco.com/c/en/us/solutions/collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490.html Cisco Annual Internet Report]
  
−
adresse-ipv6/longueur-du-préfixe-en-bits
+
* Baromètre annuel de la transition vers IPv6 en France (ARCEP - 2021) [https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html Lien]
  
−
Les formes abrégées avec «::» sont autorisées.
+
=== TP ===
−
 
+
* JOOL [http://jool.mx/en/index.html] un code alternatif à Tayga (NAT64)
−
<tt>2001:0DB8:7654:3210:0000:0000:0000:0000/64
+
−
2001:DB8:7654:3210:0:0:0:0/64
+
−
2001:DB8:7654:3210::/64</tt>
+
−
 
+
−
Le seul piège de cette notation vient des longueurs de préfixes qui ne sont pas en frontière de «:». Ainsi le préfixe <tt>3EDC:BA98:7654:3::/56</tt> équivaut en réalité à <tt>3EDC:BA98:7654:0000::/56</tt> car il s'écrit <tt>3EDC:BA98:7654:0003::/56</tt>.
+
−
 
+
−
On peut combiner l'adresse d'une interface et la longueur du préfixe réseau associé en une seule notation.
+
−
 
+
−
<tt>2001:DB8:7654:3210:945:1321:ABA8:F4E2/64</tt>
+
−
 
+
−
Ces représentations peuvent apparaître beaucoup plus complexes qu'avec IPv4, mais leur attribution répond à des règles strictes, ce qui favorise leur mémorisation.
+
−
 
+
−
Dans certains cas, une adresse (voire plusieurs adresses) IPv4 peut être contenue dans une adresse IPv6. Pour les faire resortir, la notation classique d'IPv4 peut être utilisée au sein d'une adresse IPv6. Ainsi :
+
−
 
+
−
<tt>::128.12.13.14</tt>
+
−
 
+
−
représente une adresse IPv6 composée de 96 bits à 0 suivit des 32 bits de l'adresse IPv4 <tt>128.12.13.14</tt>
+
−
 
+
−
 
+
−
Il est pourtant parfois nécessaire de manipuler littéralement des adresses IPv6. Le caractère ":" utilisé pour séparer les mots peut créer des ambiguïtés. C'est le cas avec les URL où il est aussi utilisé pour indiquer le numéro de port. Ainsi l'URL
+
−
 
+
−
<tt><nowiki>http://2001:DB8:12::1:8000/</nowiki></tt>
+
−
 
+
−
peut aussi bien indiquer le port 8000 sur la machine ayant l'adresse IPv6 2001:DB8:12::1, que la machine 2001:DB8:12::1:8000 en utilisant le port par défaut. Pour lever cette ambiguïté, le RFC 2732 propose d'inclure l'adresse IPv6 entre "[ ]". L'adresse précédente s'écrirait :
+
−
 
+
−
<tt><nowiki>http://[2001:DB8:12::1]:8000/</nowiki></tt>
+
−
 
+
−
ou
+
−
 
+
−
<tt><nowiki>http://[2001:DB8:12::1:8000]/</nowiki></tt>
+
−
 
+
−
suivant les cas. Cette représentation peut être étendue à d'autres domaines comme X-window ou au protocole de signalisation téléphonique SIP.
+
−
 
+
−
== Type des adresses ==
+
−
 
+
−
IPv6 reconnaît trois types d'adresses : unicast, multicast et anycast.
+
−
 
+
−
Le premier de ces types, le type unicast, est le plus simple. Une adresse de ce type désigne une interface unique. Un paquet envoyé à une telle adresse, sera donc remis à l'interface ainsi identifiée.
+
−
 
+
−
Parmi les adresses unicast, on peut distinguer celles qui auront une portée globale, c'est-à-dire désignant sans ambiguïté une machine sur le réseau Internet et celles qui auront une portée locale (lien ou site). Ces dernières ne pourront pas être routées sur l'Internet.
+
−
 
+
−
Une adresse de type multicast désigne un groupe d'interfaces qui en général appartiennent à des noeuds différents pouvant être situés n'importe où dans l'Internet. Lorsqu'un paquet a pour destination une adresse de type multicast, il est acheminé par le réseau à toutes les interfaces membres de ce groupe.
+
−
 
+
−
Il faut noter qu'il n'y a plus d'adresses de type broadcast comme sous IPv4 ; elles sont remplacées par des adresses de type multicast qui saturent moins un réseau local constitué de commutateurs. L'absence de broadcast augmente la résistance au facteur d'échelle d'IPv6 dans les réseaux commutés.
+
−
 
+
−
Le dernier type, anycast, est une officialisation de propositions faites pour IPv4 RFC 1546. Comme dans le cas du multicast, une adresse de type anycast désigne un groupe d'interfaces, la différence étant que lorsqu'un paquet a pour destination une telle adresse, il est acheminé à un des éléments du groupe et non pas à tous. C'est, par exemple, le plus proche au sens de la métrique des protocoles de routage. Cet adressage est principalement expérimental, voir [[Anycast|Adresses anycast]].
+
−
 
+
−
Certains types d'adresses sont caractérisés par leur préfixe RFC 3513. Le tableau suivant (source : http://www.iana.org/assignments/ipv6-address-space) donne la liste de ces préfixes. La plage «réservée» du préfixe <tt>0::/8</tt> est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70% de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.
+
−
 
+
−
 
+
−
{|
+
−
!Préfixe IPv6!!Allouer!!Référence 
+
−
|-style="background:silver"
+
−
|<tt>0000::/8</tt>||[[Autres types d'adresses|Réservé pour la transition et loopback]]||RFC 3513
+
−
|-
+
−
|<tt>0100::/8</tt>||Réservé||RFC 3513
+
−
|-style="background:silver"
+
−
|<tt>0200::/7</tt>||Réservé (ex [[Autres types d'adresses#Les adresses NSAP|NSAP]])||RFC 4048
+
−
|-
+
−
|<tt>0400::/6</tt>||Réservé (ex IPX)||RFC 3513
+
−
|-style="background:silver"
+
−
|<tt>0800::/5</tt>||Réservé||RFC 3513
+
−
|-
+
−
|<tt>1000::/4</tt>||Réservé||RFC 3513
+
−
|-style="background:silver"
+
−
|<tt>2000::/3</tt>||[[Unicast Global]]||RFC 3513
+
−
|-
+
−
|<tt>4000::/3</tt>||Réservé||RFC 3513
+
−
|-style="background:silver"
+
−
|<tt>6000::/3</tt>||Réservé||RFC 3513
+
−
|-
+
−
|<tt>8000::/3</tt>||Réservé||RFC 3513
+
−
|-style="background:silver"
+
−
|<tt>A000::/3</tt>||Réservé||RFC 3513
+
−
|-
+
−
|<tt>C000::/3</tt>||Réservé||RFC 3513
+
−
|-style="background:silver"
+
−
|<tt>E000::/4</tt>||Réservé||RFC 3513
+
−
|-
+
−
|<tt>F000::/5</tt>||Réservé||RFC 3513
+
−
|-style="background:silver"
+
−
|<tt>F800::/6</tt>||Réservé||RFC 3513
+
−
|-
+
−
|<tt>FC00::/7</tt>||[[Site-local#ula|Unique Local Unicast]]||RFC 4193
+
−
|-style="background:silver"
+
−
|<tt>FE00::/9</tt> ||Réservé||RFC 3513
+
−
|-
+
−
|<tt>FE80::/10</tt>||[[Lien-local]]||RFC 3513
+
−
|-style="background:silver"
+
−
|<tt>FEC0::/10</tt>||Réservé||RFC 3879
+
−
|-
+
−
|<tt>FF00::/8</tt>||Multicast||RFC 3513
+
−
|}
+
−
 
+
−
Une interface possèdera généralement plusieurs adresses IPv6. En IPv4 ce comportement est exceptionnel, il est banalisé en IPv6.
+
−
 
+
−
==== Durée de vie des adresses ====
+
−
 
+
−
{{TODO|A déplacer dans Découverte de voisin}}
+
−
 
+
−
IPv6 généralisant le plan d'adressage CIDR, les préfixes restent dans tous les cas la propriété des opérateurs. Il ne peuvent plus être attribués "à vie" aux équipements. Pour faciliter la renumérotation d'une machine l'attribution d'une adresse à une interface est faite temporairement, les adresses IPv6 ne sont pas données mais prêtées. Une durée de vie est associée à l'adresse qui indique le temps pendant lequel l'adresse appartient à l'interface. Quand la durée de vie est épuisée, l'adresse devient invalide, elle est supprimée de l'interface et devient potentiellement assignable à une autre interface. Une adresse invalide ne doit jamais être utilisée comme adresse dans des communications. La valeur par défaut de la durée de vie d'une adresse est de 30 jours, mais cette durée peut être prolongée, ou portée à l'infini. L'adresse lien-local a une durée de vie illimitée.
+
−
 
+
−
<tikz title="État successif d'une adresse sur une interface">
+
−
  \clip (0, 0) rectangle (11,6.5);
+
−
% \draw[help lines] (0,0) grid (10,6);
+
−
+
−
 
+
−
\draw [thick, ->] (0,2) -- (9,2);
+
−
+
−
\draw [->] (1,4) node [above=10pt] {\tiny{allocation}}-- (1,2);
+
−
\draw (1,2) node [rectangle, minimum width=2cm, minimum height=1cm, fill, left color=green,  right color=green!50, draw=black, above right]  (preferred) {};
+
−
\draw (preferred.south east) node [rectangle, minimum width=3cm, minimum height=1cm, fill, left color=orange , right color=orange!50!red, draw=black, above right]  (deprecated) {};
+
−
\draw (deprecated.south east) node [rectangle, minimum width=2cm, minimum height=1cm, fill, color=red, draw=black, above right]  (novalid) {};
+
−
+
−
 
+
−
\draw (preferred.text) node {\tiny{Preferred}};
+
−
\draw (deprecated.text) node {\tiny{Deprecated}};
+
−
\draw (novalid.text) node {\tiny{Invalid}};
+
−
+
−
\draw [dotted] (preferred.south east) -- +(0, -1) node  {};
+
−
\draw [dotted] (1,2) -- (1, 0.5);
+
−
\draw [dashed, <->] (1, 1.25) -- (3, 1.25) node [above, midway] {\tiny{Preferred Lifetime}};
+
−
 
+
−
 
+
−
\draw [dotted] (deprecated.south east) -- +(0, -1.5) node  {};
+
−
\draw [dashed, <->] (1, 0.5) -- (6, 0.5) node [above, midway] {\tiny{Valid Lifetime}};
+
−
 
+
−
</tikz>
+
−
La renumérotation d'une interface d'une machine consiste à passer d'une adresse à une autre. Lors d'une renumérotation, il n'est pas souhaitable de changer brusquement d'adresse, sinon toutes les communications TCP, qui l'utilisent comme identificateur de connexion, seraient immédiatement coupées. Ceci entraînerait des perturbations importantes au niveau des applications.
+
−
 
+
−
Pour faciliter cette transition, un mécanisme d'obsolescence est donc mis en place pour invalider progressivement une adresse. Ce mécanisme s'appuie sur la capacité d'affectation de plusieurs adresses valides à une même interface. Ensuite pour effectuer le choix de l'adresse à utiliser, un état est associé. Il indique dans quelle phase de sa durée de vie une adresse se situent vis à vis de l'interface. Le premier de ces états est qualifié de préféré : l'utilisation n'est aucunement restreinte. Peu avant son invalidation l'adresse passe dans un état de déprécié. Dans cet état, l'utilisation de l'adresse est déconseillée, mais pas interdite. L'adresse dépréciée ne doit plus être utilisée comme adresse de source pour les nouvelles communications (comme l'établissement de connexion TCP). Par contre l'adresse dépréciée peut encore servir d'adresse de source dans le cas des communications existantes. Les paquets reçus à une adresse dépréciée continuent à être remis normalement. À la durée de vie de validité d'un adresse, il est également associé une durée de vie pour son état préféré. La figure '''État successif d'une adresse sur une interface''' représente les différents états que prend une adresse lorsqu'elle est allouée à une interface.
+
−
 
+
−
=== Adressage global : plan d'adressage agrégé ===
+
−
 
+
−
Ce plan, proposée dans le RFC 3587, précise la structure d'adressage IPv6 définie dans le RFC 3513 en précisant les tailles de chacun des blocs. Il est géré de la même manière que CIDR en IPv4. Une adresse intègre trois niveaux de hiérarchie :
+
−
 
+
−
<tikz title="Adresses Globales">
+
−
\clip (0.0, 0) rectangle (11.5,7); 
+
−
% \draw[help lines] (0,0) grid (10,6);
+
−
                 
+
−
% \draw  (0, 6.6) node [right] {Global Unicast Address:};
+
−
   
+
−
\draw (0,5) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tt{001}};
+
−
\draw (1,5) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Global Prefix};
+
−
\draw (4,5) node [right, draw, shade, top color = blue, minimum width=1.5cm, minimum height=1cm] {SID};
+
−
\draw (5.5,5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};
+
−
+
−
\draw (0.5, 5.7) node {\tiny{3}};
+
−
\draw (2.5, 5.7) node {\tiny{45}};
+
−
\draw (4.7, 5.7) node {\tiny{16}};
+
−
\draw (8, 5.7) node {\tiny{64}};
+
−
+
−
+
−
\draw [snake=brace, mirror snake] (0, 4.20) -- (4, 4.20) node [below, midway] {\tiny{
+
−
              \ifthenelse{\equal{francais}{true}}{Topologie Publique}{public topology}}
+
−
        } node [below = 8pt, midway] {\tiny{given by the provider}} ;
+
−
\draw [snake=brace, mirror snake] (4, 4.20) -- (5.5, 4.20) node [below, midway] {\tiny{local topology}} node [below = 8pt, midway] {\tiny{assigned by network engineer}} ;
+
−
\draw [snake=brace, mirror snake] (5.5, 4.20) -- (10.3, 4.20) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto or manual configuration}} ;
+
−
</tikz>
+
−
 
+
−
* une topologie publique (appelée '''Global Prefix''') codé sur 48 bits, allouée par le fournisseur d'accès;
+
−
* une topologie de site codé sur 16 bits (appelée '''Subnet ID'''). Ce champ permet de coder les numéros de sous réseau du site;
+
−
* un [[identifiant d'interface]] sur 64 bits (appelé '''Interface ID''') distinguant les différentes machines sur le lien.
+
−
 
+
−
====Structuration du prefixe global (GP)====
+
−
 
+
−
{{HorsTexte|Appréhender les tailles|France Télécom a obtenu du RIPE-NCC un <tt>/19</tt>. Si l'on enlève les troix premiers bits <tt>001</tt> désignant le plan d'adressage, il est donc possible d'avoir 2<sup>16</sup> opérateurs. Sachant qu'il y a 192 pays à l'ONU, ils pourraient abritrer 320 opérateurs de taille de FT. Chacun pouvant attribuer jusqu'à 2<sup>29</sup> <tt>/48</tt>, soit 536 870 912 sites}}
+
−
 
+
−
A part le préfixe <tt>2002::</tt> qui est est réservé au mécanisme de transition [[6to4]], cet espace est géré hierarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales ([http://www.iana.org/numbers/ RIR]) des préfixes actuellement de longueur 12 (cf. http://www.iana.org/assignments/ipv6-unicast-address-assignments) qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long. Le site http://www.sixxs.net/tools/grh/ donne en temps réel les allocations de préfixes par région, opérateur et pays.
+
−
 
+
−
Il est maintenant admis que le préfixe attribué par un opérateur à ses clients peut également être un <tt>/56</tt>. En effet, si l'on garde l'attribution de préfixe de longueur 48 pour les sites terminaux, et que l'on intègre les réseaux domotiques, les opérateurs peuvent justifier d'un besoin important d'adresses que les autorités régionales ne peuvent leur refuser.
+
−
 
+
−
{{ToDo|Ajouter comment obtenir un préfixe auprès de RIPE-NCC}}
+
−
 
+
−
====Structuration de l'identifiant de sous-réseau (SID)====
+
−
 
+
−
Il n'existe pas de règles pour allouer les identificateurs de sous-réseau au sein d'un site. Plusieurs techniques (non exclusives) peuvent être utilisées :
+
−
 
+
−
* numéroter de manière incrémentale les sous-réseaux: 0001, 0002, ... Cette technique est simple a mettre en œuvre dans des réseaux expérimentaux, mais elle peut conduire à un plan d'adressage à plat difficile à mémoriser. Elle peut être utilisée par exemple pour un sous-réseau dédié aux serveur pour simplifier l'écriture et la mémorisation des adresses.
+
−
* utiliser le numéro de VLAN. Elle permet d'éviter de mémoriser plusieurs niveau de numérotation.
+
−
* séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées pour à la gestion de ces sous-réseau pour la partie de droite. A titre d'exemple, le tableau suivant contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs :
+
−
 
+
−
{|
+
−
!Communauté !! 4bits  !! width="50%"|8bits !! 4bits
+
−
|-style="background:silver"
+
−
| Infrastructure || 0  || colspan=2 | valeurs spécifiques
+
−
|-
+
−
| Tests || 1  || colspan=2 | valeurs spécifiques
+
−
|-style="background:silver"
+
−
| Tunnels || 6 || colspan=2 | allocation de /60 aux utilisateurs
+
−
|-
+
−
| Invités Wi-Fi || 8  || colspan=2 | valeurs spécifiques
+
−
|-style="background:silver"
+
−
| Personnels || A  || Entité || Sous-Réseaux
+
−
|-
+
−
| Etudiants || E  || Entité || Sous-Réseaux
+
−
|-style="background:silver"
+
−
| Autres (Start up, etc.) || F || colspan=2 | valeurs spécifiques
+
−
|+ Affectation des SID dans une université
+
−
|}
+
−
 
+
−
Ainsi, le préfixe:
+
−
* <tt>2001:DB8:1234::/52</tt> servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs seront pris dans cet espace,
+
−
* <tt>2001:DB8:1234:8000::/52</tt> servira pour le réseau wi-fi des invités. La manière dont sont gérés les 12 bits restants du SID ne sont pas spécifiés,
+
−
* <tt>2001:DB8:1234:E000::/52</tt> servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sours-réseaux différents pour cette communauté.
+
−
 
+
−
==== Structuration de 'identifiant d'interface (IID) ====
+
−
 
+
−
Si initialement pour des raisons d'auto-configuration, l'identifiant d'interface devait toujours être dérivé de l'adresse de niveau 2, c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits:
+
−
 
+
−
* manuelle,
+
−
* basée sur l'adresse de niveau 2 de l'interface,
+
−
* aléatoire,
+
−
* cryptographique.
+
−
 
+
−
===== Manuel =====
+
−
{{HorsTexte|Le resolveur DNS|Le résolveur DNS est le cas le plus flagrant ; chaque machine sur le réseau doit être configurée avec l'adresse IPv6 du serveur DNS. En cas de changement de carte réseau, l'ensemble des machines du domaine devront être reconfigurées. Si l'on ne souhaite pas  utiliser des protocoles de configuration automatique de type DHCPv6, il est préférable d'attribuer au résolveur DNS une adresse manuelle.}}
+
−
Pour les serveurs les plus utilisé, il est préférable d'assigner manuellement des adresses aux interfaces, car dans ce cas l'adresse IPv6 est facilement mémorisable, et le serveur peut être accessible même si le DNS n'est pas actif.
+
−
Il existe plusieurs techniques plus ou moins mnémotechniques :
+
−
* incrémenter l'identifiant d'interface à chaque nouveau serveur créé
+
−
 
+
−
<tt>2001:DB8:1234:1::1</tt>
+
−
<tt>2001:DB8:1234:1::2</tt>
+
−
...
+
−
 
+
−
* reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interace. Par exemple si un serveur a comme adresse IPv4 <tt>192.0.2.123</tt>, son adresse IPv6 sera :
+
−
 
+
−
<tt>2001:DB8:1234:1::7B</tt>
+
−
ou plus simplement
+
−
<tt>2001:DB8:1234:1::123</tt>
+
−
 
+
−
* reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvient de conduire à des adresses plus longues à taper :
+
−
 
+
−
<tt>2001:DB8:1234:1::192.0.2.123</tt>
+
−
 
+
−
===== Dérivé de l'adresse de l'interface=====
+
−
 
+
−
L'avantage d'utiliser une adresse de niveau 2 pour construire un identifiant d'interface est que l'unicité de cette valeur est presque toujours assurée. En plus, cette valeur est stable tant que la carte réseau de la machine n'est pas changée. Par contre, ces valeurs sont difficilement mémorisables.
+
−
 
+
−
Les adresses lien-local sont construites en utilisant ce type d'identifiant. Par contre pour les adresses globales, il est conseillé de ne les utiliser que pour les machines client et de préférer les identifiant d'interface manuel pour les serveur.
+
−
 
+
−
Ces identifiants d'interface étant stable dans le temps, à chaque fois qu'un individu change de réseau, il change de préfixe, mais garde le même identifiant d'interface. il pourrait donc servir à tracer les déplacements d'un individu. Le risque est faible, car les cookies mis en place par les serveurs web sont bien plus efficaces, mais ils ne s'agit plus d'un problème réseau. Autre désavantage, comme les adresses MAC contiennent l'identification du matériel, il est possible d'indiquer à l'exterieur du réseau quel type de materiel est utilisé et donner des indications.
+
−
 
+
−
Si ces inconvénients sont jugés important par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. 
+
−
 
+
−
====== EUI-64 ======
+
−
 
+
−
<tikz title="Transformation d'une adresse MAC en identifiant d'interface">
+
−
+
−
\clip (0, 1) rectangle (11,5);
+
−
% \draw[help lines] (0,0) grid (11,4);
+
−
+
−
+
−
\draw (2, 1.5)  node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{u}g}}};
+
−
\draw (3, 1.5)  node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
+
−
\draw (2, 1.25)  rectangle+(3, 0.5);
+
−
 
+
−
\draw (5, 1.5)  node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};
+
−
 
+
−
</tikz>
+
−
 
+
−
L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (firewire) ou IEEE 802.15.4 (réseau de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64.
+
−
 
+
−
 
+
−
Il existe plusieurs méthodes pour construire l'identifiant :
+
−
{{HorsTexte|Ordre de transmission|L'ordre des bits ne doit pas porter à confusion. Dans la représentation numérique des valeurs, le premier bit transmis est le bit de poids faible, c'est-à-dire le bit de droite. Ainsi sur le support physique le bit <tt>g</tt>, puis le bit <tt>u</tt> puis les bits suivants sont transmis. }}
+
−
 
+
−
* Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure décrite figure Identificateur global IEEE EUI-64.
+
−
: Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802, identifient le constructeur et les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits <tt>u</tt> (septième bit du premier octet) et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :
+
−
:* <tt>u</tt> (Universel) vaut <tt>0</tt> si l'identifiant EUI-64 est universel,
+
−
:* <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g = 0</tt>), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g = 1</tt>), par exemple une adresse de multicast.
+
−
 
+
−
<tikz title="Identificateur d'interface dérivé d'une EUI-64">
+
−
+
−
\clip (0, 1) rectangle (11,5);
+
−
% \draw[help lines] (0,0) grid (11,4);
+
−
+
−
+
−
\draw (2, 1.5)  node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
+
−
\draw (3, 1.5)  node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
+
−
\draw (2, 1.25)  rectangle+(3, 0.5);
+
−
 
+
−
\draw (5, 1.5)  node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};
+
−
 
+
−
</tikz>
+
−
* L'identifiant d'interface à 64 bits est dérivé de l'EUI-64 en inversant le bit <tt>u</tt> (cf. figure Identificateur d'interface dérivé d'une EUI-64). En effet, pour la construction des adresses IPv6, on a préféré utiliser <tt>1</tt> pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur <tt>0</tt> pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de <tt>1</tt>.
+
−
 
+
−
======MAC-48======
+
−
 
+
−
<tikz title="Transformation d'une adresse MAC en identifiant d'interface">
+
−
+
−
\clip (0, 1) rectangle (11,5);
+
−
% \draw[help lines] (0,0) grid (11,4);
+
−
+
−
\only<2-> {
+
−
\draw (3, 4.5)  node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
+
−
\draw (4, 4.5)  node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
+
−
\draw (3, 4.25)  rectangle+(3, 0.5);
+
−
+
−
\draw (0,4.5) node [right] {MAC-48};
+
−
 
+
−
\draw (6, 4.5)  node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};
+
−
 
+
−
 
+
−
\draw (2, 3)  node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
+
−
\draw (3, 3)  node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
+
−
\draw (2, 2.75)  rectangle+(3, 0.5);
+
−
 
+
−
\draw (7, 3)  node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};
+
−
 
+
−
\draw (6,4.5) -- (6, 4) -- (5, 3.5) -- (5, 3);
+
−
\draw (6,4) -- (7, 3.5) -- (7, 3);
+
−
\draw (3, 4.5) -- (3, 4) -- (2, 3.5) -- (2, 3);
+
−
\draw (9, 4.5) -- (9, 4) -- (10, 3.5) -- (10, 3);
+
−
+
−
\draw (5, 3)  node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};
+
−
+
−
\draw (0,3) node [right] {EUI-64};
+
−
}
+
−
+
−
\only<3-> {
+
−
+
−
\draw (2, 1.5)  node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
+
−
\draw (3, 1.5)  node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
+
−
\draw (2, 1.25)  rectangle+(3, 0.5);
+
−
 
+
−
\draw (7, 1.5)  node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};
+
−
+
−
\draw (5, 1.5)  node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};
+
−
+
−
\draw (2,3) -- (2, 1.5);
+
−
\draw (10,3) -- (10, 1.5);
+
−
\draw (0,1.5) node [right] {IID};
+
−
}
+
−
 
+
−
</tikz>
+
−
 
+
−
* Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi). L'adresse est tout d'abord convertie en EUI-64, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure ci-contre illustre ce processus.
+
−
 
+
−
======Cas Particuliers======
+
−
* Si une interface possède une adresse locale unique sur le lien, mais non universelle (par exemple le format d'adresse IEEE 802 sur 2 octets ou une adresse sur un réseau Appletalk), l'identifiant d'interface est construit à partir de cette adresse en rajoutant des 0 en tête pour atteindre 64 bits.
+
−
 
+
−
 
+
−
{{HorsTexte|Erreur de l'IETF|A noter que l'IETF s'est trompée quand elle a défini l'algorithme de conversion. En effet, l'ajout de la valeur <tt>0xFFFE</tt> concerne les EUI-48, c'est-à-dire des identifiants, alors qu'Ethernet utilise des MAC-48, c'est-à-dire des adresses (ils servent à transporter des trames vers le bon destinataire). La bonne valeur aurait été <tt>0xFFFF</tt>. Mais cette erreur n'a aucune conséquence pour l'identification des équipements, elle n'a donc pas été corrigée par la suite.}}
+
−
 
+
−
* Si une interface ne possède aucune adresse (par exemple l'interface utilisée pour les liaisons PPP), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle ou bien une génération aléatoire, avec le bit u positionné à 0. <br>S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, et devra être résolu manuellement.
+
−
 
+
−
===== Valeur aléatoire =====
+
−
 
+
−
L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pourrait poser des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur, qui même s'il se déplace de réseau en réseau garde ce même identifiant. Il serait alors possible de traquer un individu utilisant un portable, chez lui, au bureau, lors de ses déplacements. Ce problème est similaire à l'identificateur placé dans les processeurs Pentium III.
+
−
 
+
−
Pour couper court à toute menace de boycott d'un protocole qui «menacerait la vie privée», il a été proposé d'autres algorithmes de construction d'un identifiant d'interface basé sur des tirages aléatoires (voir RFC 3041). Un utilisateur particulièrement méfiant pourrait valider ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme comme MD5 à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement l'adresse est mise dans l'état «déprécié» et un nouvel identifiant d'interface est choisi. Les connexions déjà établies continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.
+
−
 
+
−
Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globale. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (i.e. les applications serveur). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours et sert aux applications client. Dans Windows Vista, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface.
+
−
 
+
−
Bien entendu pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse ou que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit impossible.
+
−
 
+
−
En contre partie, il est plus difficile à un administrateur réseau de filtrer les machines puisque celles-ci changent périodiquement d'adresses.
+
−
 
+
−
===== Cryptographique =====
+
−
 
+
−
{{HorsTexte|Encore un sujet de recherche|L'usage de ces adresses n'est pas encore généralisé. Shim6 pour la gestion de la multi-domiciliation ou SEND pour sécuriser la découverte de voisins y on recours.}}
+
−
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.
+
−
 
+
−
=== Adressage local : adresses lien-local ===
+
−
 
+
−
Les adresses de type lien-local (''link local use address'') sont des adresses dont la validité est restreinte à un lien, c'est-à-dire l'ensemble de interfaces directement connectées sans routeur intermédiaire : par exemple machines branchées sur un même Ethernet, machines reliées par une connexion PPP, ou extrémités d'un tunnel. Les adresses lien-local sont configurées automatiquement à l'initialisation de l'interface et permettent la communication entre noeuds voisins. L'adresse est obtenue en concaténant le préfixe <tt>FE80::/64</tt> aux 64 bits de l'[[Identifiant d'interface|identifiant d'interface]]. L'identifiant d"interface est généralement basé sur l'adresse MAC. Cela ne pose pas de problème de respect de le vie privée car, contrairement aux adresses globales, les adresses lien-local ne sortent jamais du réseau où elles sont utilisées.
+
−
 
+
−
<tikz title="Adresses Lien-local">
+
−
% \draw (0, 3) node [right] {Link-Local Address:};     
+
−
\draw (0,1.5) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FE80};   
+
−
\draw (1.5,1.5) node [right, draw, minimum width=4cm, minimum height=1cm] {0...0};  
+
−
\draw (5.5,1.5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID}; 
+
−
 
+
−
\draw (0.7, 2.2) node {\tiny{10}};
+
−
\draw (3.5, 2.2) node {\tiny{54}};
+
−
\draw (8, 2.2) node {\tiny{64}};
+
−
+
−
\draw [snake=brace, mirror snake] (5.5, 0.8) -- (10.3, 0.8) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto-configuration}} ;
+
−
</tikz>
+
−
 
+
−
Ces adresses sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins (''neighbor discovery'') et de découverte de routeurs (''router discovery''). Ce sont de nouveaux dispositifs, le premier supplantant en particulier le protocole ARP (''Address Resolution Protocol''), qui permettent pas à un réseau local de se configurer automatiquement (voir [[Découverte de voisins]]). Elles sont également largement utilisées par les protocoles de routage soit pour l'échange de données (cf. RIPng, OSPFv3), soit dans les tables de routage puisque le champ prochain routeur est toujours un équipement directement accessible sur le lien.
+
−
{{HorsTexte|Unicité sur le lien|Les adresses lien-local sont uniques à l'intérieur d'un lien. Le protocole de détection de duplication d'adresse (voir [[Configuration automatique#DAD|Détection d'adresse dupliquée]]) permet de s'en assurer. Par contre la duplication d'une adresse lien-local entre deux liens différents, ou entre deux interfaces d'un même noeud est autorisée.}}
+
−
 
+
−
Un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type lien-local.
+
−
 
+
−
Le fait que ces adresses aient une portée très faible les limite dans la pratique au cas où un démarrage automatique (''bootstrap'') est nécessaire. Leur usage ne doit pas être généralisé dans les applications classiques en régime stabilisé.
+
−
 
+
−
==== Portée de l'adresse (''scoped address'') ====
+
−
 
+
−
Une adresse lien-local (ou multicast) n'indique pas intrinsèquement l'interface de sortie, puisque toutes les interfaces partagent le même préfixe <tt>fe80::/10</tt>. Il faut donc indiquer de manière explicite sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère "%". Sous Linux, un argument, généralement <tt>-I</tt> permet de la désigner.
+
−
 
+
−
===Unique Local Address===
+
−
 
+
−
Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local Address''). Ces adresses sont destinées à une utilisation locale. Elles ne sont pas définies pour être routées dans l'Internet, mais seulement au sein d'une zone limitée telle qu'un site ou entre un nombre limité de sites. Les adresses uniques locales ont les caractéristiques suivantes :
+
−
 
+
−
* Prefixe ''globalement'' unique.
+
−
* Préfixe clairement définit facilitant le filtrage sur les routeurs de bordure.
+
−
* Permet l'interconnexion de sites sans générer de conflit d'adresse et sans nécessiter de renumérotation.
+
−
* Indépendantes des fournisseurs d'accès à l'Internet et ne nécessitent donc pas de connectivité.
+
−
* Pas de conflit en cas de routage par erreur en dehors d'un site.
+
−
* Aucune différences pour les applications, qui peuvent les considérer comme des adresses globales unicast standard.
+
−
 
+
−
<tikz title="Unique Local Addresses">
+
−
\clip (0, 0) rectangle (11,4);
+
−
% \draw[help lines] (0,0) grid (10,3);
+
−
+
−
% \draw (0, 3.6) node [right] {Unique Local IPv6 Unicast Addresses:};
+
−
+
−
\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=1.5cm, minimum height=1cm] {FD};
+
−
\draw (1.5,2) node [right, draw, shade, top color = green, minimum width=2.7cm, minimum height=1cm] {Random Value};
+
−
\draw (4.5,2) node [right, draw, shade, top color = blue, minimum width=1cm, minimum height=1cm] {SID};
+
−
\draw (5.5,2) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};
+
−
+
−
\draw (0.7, 2.7) node {\tiny{8}};
+
−
\draw (2.7, 2.7) node {\tiny{40}};
+
−
\draw (4.7, 2.7) node {\tiny{16}};
+
−
\draw (8, 2.7) node {\tiny{64}};
+
−
+
−
+
−
\draw [snake=brace, mirror snake] (0, 1.20) -- (4.5, 1.20) node [below, midway] {\tiny{private topology}} node [below = 8pt, midway] {\tiny{Not Routable in the Internet}} ;
+
−
\draw [snake=brace, mirror snake] (4.5, 1.20) -- (5.5, 1.20) node [below, midway] {\tiny{local topology}};
+
−
\draw [snake=brace, mirror snake] (5.5, 1.20) -- (10.3, 1.20) node [below, midway] {\tiny{link address}}  ;
+
−
</tikz>
+
−
 
+
−
Les adresses uniques locales sont créées en utilisant un identifiant global (''Global ID'') généré pseudo-aléatoirement. Ces adresses suivent le format suivant :
+
−
<!-- [[image:CS15.gif]] -->
+
−
* <tt>Prefix</tt> (7 bits) : <tt>FC00::/7</tt> préfixe identifiant les adresses IPv6 locales (''ULA'')
+
−
* <tt>L</tt> (1 bit) : Positionné à 1, le préfixe est assigné localement. La valeur 0 est réservée pour une utilisation future.
+
−
* <tt>Global ID</tt> (40 bits) : Identifiant global utilisé pour la création d'un préfixe ''unique'' (''Globally Unique Prefix'').
+
−
* <tt>Subnet ID</tt> (16 bits) : Identifiant d'un sous réseau à l'intérieur du site.
+
−
* <tt>Interface ID</tt> (64 bits) : L'indentifiant d'interface tel que définit dans [[Identifiant d'interface]].
+
−
 
+
−
Le site http://www.sixxs.net/tools/grh/ula/ permet de créer et d'enregistrer son adresse ULA à partir d'une adresse MAC.
+
−
 
+
−
===Adresses Multicast===
+
−
{{HorsTexte|porté et porté|Il ne faut pas confondre la porté d'une adresse link-local ou multicast qui désigne l'interface par laquelle sera émis le paquet et la porté d'un groupe multicast qui désigné l'étendue de la couverture}}
+
−
Cette section décrit brièvement le système d'adressage multicast IPv6 et ne s'intéresse qu'aux adresses utilisées localement par les protocoles directements lié à IPv6 (Découverte de voisins, DHCPv6,...). Pour plus de détails sur le multicast en général, se reporter au chapitre [[Multicast]]. La figure Structure de l'adresse IPv6 Multicast donne le format de l'adresse IPv6 de multicast décrite dans le RFC 3513.
+
−
 
+
−
<tikz title="Structure de l'adresse IPv6 Multicast">
+
−
\clip (0, 1) rectangle (11,4);
+
−
% \draw[help lines] (0,0) grid (10,4 );
+
−
+
−
% \draw (0, 3.6) node [right] {Generic Format:};
+
−
+
−
\draw (0,2) node [right, draw, shade, top color = yellow, minimum width=2cm, minimum height=1cm] {FF};
+
−
\draw (2,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{\tt{xRPT}}};
+
−
\draw (3,2) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tiny{scope}};
+
−
\draw (4,2) node [right, draw, shade, top color = black!50, minimum width=6cm, minimum height=1cm] {Group ID};
+
−
+
−
\draw (1, 2.7) node {\tiny{8}};
+
−
\draw (2.5, 2.7) node {\tiny{4}};
+
−
\draw (3.5, 2.7) node {\tiny{4}};
+
−
\draw (7, 2.7) node {\tiny{112}};
+
−
 
+
−
</tikz>
+
−
 
+
−
Les adresses multicast IPv6 sont dérivées du préfixe <tt>FF00::/8</tt>. Le champ drapeaux de 4 bits est défini de la manière suivante :
+
−
 
+
−
* Seul le bit <tt>T</tt> (comme ''Transient'') du champ drapeaux est initialement décrit dans le RFC 3513. La valeur <tt>0</tt> indique une adresse multicast bien connue gérée par une autorité. La valeur <tt>1</tt> indique une valeur temporaire.
+
−
* Les bits <tt>P</tt> et <tt>R</tt> sont décrits dans le RFC 3306 et le draft Internet sur embedded-RP (RFC 3956).
+
−
* Le bit de poids fort du champ drapeaux n'est pas encore attribué.
+
−
 
+
−
Le champ drapeaux permet de définir plusieurs types d'adresses multicast IPv6 qui seront décrits dans les sections suivantes.
+
−
 
+
−
Le champ scope de l'adresse multicast IPv6 permet d'en limiter la portée (''scope'' en anglais). En IPv4, la portée d'un paquet est limitée par le champ TTL (''Time To Live''), de même des préfixes peuvent être définis pour identifier des adresses à portée réduite. Les valeurs suivantes sont définies :
+
−
 
+
−
* 1 - node-local : Les paquets ne sortent pas de la machine, cette adresse sert pour la communication entre les applications.
+
−
* 2 - link-local : La portée se limite au réseau local, les paquets ne peuvent pas traverser les routeurs multicast. Cette valeur est utilisée en particulier par le protocole de découverte des voisins.
+
−
* 3 - subnet-local : Ce type n'est pas officiellement défini, mais se retrouve dans certains documents. Il permet de faire la différence entre un lien physique et un lien logique (regroupement de plusieurs liens physiques) partageant le même préfixe IPv6.
+
−
* 4 - admin-local
+
−
* 5 - site-local
+
−
* 8 - organisation-local
+
−
* E - global
+
−
* Les portées 0 et F sont réservées.
+
−
 
+
−
http://www.iana.org/assignments/ipv6-multicast-addresses donne les adresses multicast définies. Le tableau ci-dessous liste les plus utilisées :
+
−
 
+
−
{|
+
−
!Adresse multicast !! usage
+
−
|-style="background:silver"
+
−
|  FF01::1 ||  All Nodes Address 
+
−
|-
+
−
|  FF01::2 ||    All Routers Address
+
−
|-style="background:silver"
+
−
|  FF02::1 ||    All Nodes Address 
+
−
|-
+
−
|  FF02::2 ||    All Routers Address   
+
−
|-style="background:silver"
+
−
|  FF02::5 ||    OSPFIGP
+
−
|-
+
−
|  FF02::6  ||  OSPFIGP Designated Routers
+
−
|-style="background:silver"
+
−
|  FF02::9  ||  RIP Routers 
+
−
|-
+
−
|  FF02::1:2 ||    All-dhcp-agents 
+
−
|-style="background:silver"
+
−
|  FF05::2  ||    All Routers Address 
+
−
|-
+
−
|  FF05::1:3  ||    All-dhcp-servers
+
−
|-style="background:silver"
+
−
|  FF0X::101  ||  Network Time Protocol (NTP) 
+
−
|}
+
−
 
+
−
===Adresses Anycast===
+
−
 
+
−
 
+
−
Le principe sous-jacent est simple : au lieu d'envoyer un paquet à une interface déterminée, on envoie ce paquet à une adresse (anycast) qui représente un ensemble de machines dans un domaine bien défini. Une adresse anycast permet de désigner un service par une adresse bien connue, de cette manière, il n'est pas nécessaire d'interroger un serveur pour connaître la localisation d'un équipement.
+
−
 
+
−
[[image:Fig3-13.png|thumb|right|350px|Figure 3-13 ''Adresse anycast "sous-réseau"'']]
+
−
 
+
−
La figure Adresse anycast «sous-réseau» donne la structure de l'adresse anycast. On y retrouve une partie préfixe et une partie identifiant anycast. La partie préfixe est la même que celle utilisée pour les adresses unicast. Contrairement aux structures d'adresses vue précédemment, la longueur de ce préfixe n'est pas spécifiée, car une adresse anycast doit s'adapter aussi bien aux plans d'adressage actuels (où la longueur est généralement de 64 bits) qu'aux futurs plans qui pourraient avoir des tailles différentes.
+
−
 
+
−
Si le concept anycast est simple dans son principe, son implémentation est autrement délicate. En outre, ce concept n'est encore qu'un sujet de recherche. Enfin un autre argument, de taille, explique cette prudence : il n'y a eu aucune expérience grandeur nature analogue au projet Mbone pour le multicast.
+
−
 
+
−
Comme les adresses de type sont allouées dans le même espace d'adressage, elles sont créées en attribuant une même adresse unicast à des noeuds distincts, chacun des noeuds devant être configuré pour que l'adresse ainsi attribuée soit de type anycast (sinon on aurait une adresse unicast dupliquée). La seule manière de différencier une adresse anycast d'une adresse multicast est de regarder la partie identifiant anycast qui diffère d'un identifiant d'interface. Ainsi la séquence binaire composée uniquement de 0 a été la première valeur retenue. Elle permet d'identifier un des routeurs du lien. Le RFC 2526 définit des règles de construction d'autres identifiants anycast sur un lien en réservant les 128 identifiants d'interface locaux les plus élevés. Cela permet d'éviter les conflits avec une numérotation manuelle qui partent des identifiants les plus petits vers les plus élevés. Le tableau Allocation des identifiants Anycast donne l'allocation des identifiants utilisés.
+
−
 
+
−
 
+
−
{|
+
−
|+'''''Allocation des identifiants Anycast'''''
+
−
!Description !! Valeur(hexadécimal)
+
−
|-style="background:silver"
+
−
||Réservé    || 0x7F
+
−
|-
+
−
||Adresse Anycast de l'agent mère (cf.[[Mobilité dans IPv6]])|| 0x7E
+
−
|-style="background:silver"
+
−
|Réservé    || 0x00 à 0x7D
+
−
|}
+
−
 
+
−
Deux modes de fonctionnement non exclusifs sont possibles. Le premier consiste à attribuer sur un préfixe déjà utilisé la même adresse anycast à plusieurs équipements. Le seconde consiste à définir des adresses sur un préfixe "virtuel" et à router au plus près. Les paragraphes suivants expliquent ces modes de fonctionnement.
+
−
 
+
−
==== Adresses anycast sur un même lien ====
+
−
 
+
−
Avec les adresses anycast, plusieurs équipements sur un lien physique possèdent une même adresse IPv6. Or il ne s'agit pas d'envoyer la même information à tous ces équipements comme en multicast, mais d'en choisir un seul. Une possibilité consiste à utiliser le mécanisme de découverte de voisins (cf. [[Découverte de voisins]]) pour trouver l'association entre l'adresse IPv6 et l'adresse MAC.
+
−
 
+
−
La figure Exemple d'utilisation de l'Anycast sur un lien illustre ce fonctionnement. La station A envoie un message de sollicitation de voisin pour déterminer l'adresse MAC de l'équipement. Trois serveurs reçoivent cette requête et répondent. La station A prendra une de ces réponses et dialoguera en point-à-point avec l'équipement choisi.
+
−
 
+
−
[[image:CS24.gif]]
+
−
 
+
−
==== Préfixe virtuel ====
+
−
 
+
−
Une adresse anycast peut être aussi construite à partir d'un préfixe "virtuel", c'est-à-dire appartenant au site (ou même à un domaine plus grand), mais non alloué à un lien particulier. Le schéma Exemple d'utilisation de l'Anycast dans un site donne un exemple de cette configuration. Les routeurs contiennent des adresses dans les tables de routage (c'est-à-dire des préfixes de longueur 128) pour router vers l'équipement le plus proche. Le sous-réseau 7 a été réservé aux adresses anycast. Les réseaux de 1 à 4 correspondent à des liens. Quand la station C émet un paquet Anycast vers l'adresse <tt>2001:...:7:FFFF:FFFF:FFFF:FF7D</tt>, le routeur R2 route le paquet vers les sous-réseau 1.
+
−
 
+
−
[[image:CS25.gif]]
+
−
 
+
−
= Mises en oeuvre =
+
−
Le listing suivant donne la configuration des interfaces d'une machine sous Unix.
+
−
+
−
<tt>
+
−
>'''ifconfig -au'''
+
−
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
+
−
    inet 192.108.119.159 netmask 0xffffff80 broadcast 192.108.119.255
+
−
    inet6 fe80::250:baff:febe:712%vr0 prefixlen 64 scopeid 0x1
+
−
    inet6 2001:660:7301:1:250:baff:febe:712 prefixlen 64 autoconf
+
−
    inet6 2001:688:1f99:1:250:baff:febe:712 prefixlen 64 autoconf
+
−
    ether 00:50:ba:be:07:12
+
−
    media: Ethernet autoselect (10baseT/UTP)
+
−
    status: active
+
−
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
+
−
    inet 127.0.0.1 netmask 0xff000000
+
−
    inet6 ::1 prefixlen 128
+
−
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
+
−
</tt>
+
−
 
+
−
 
+
−
L'interface Ethernet <tt>vr0</tt> possède une adresse IPv4 et trois adresses IPv6 :
+
−
 
+
−
* La première adresse correspond à l'[[Lien-local|adresse lien-local]]. On retrouve l'identifiant d'interface qui suit le préfixe <tt>FE80::/64</tt>. A noter que l'on retrouve les octets de l'adresse MAC, sauf pour le premier octet qui est à <tt>02</tt> au lieu de <tt>00</tt> suite à l'inversion du bit «universel/local». <br>A noter que la portée de l'adresse est indiquée par la chaîne de caractère <tt>%vr0</tt>. La valeur scopeid indiquée à la fin de la ligne donne le numéro cette interface.
+
−
* Les deux autres adresses correspondent à des adresses globales dont les préfixes ont éte attribués par deux opérateurs différents (la machine est sur un réseau multi-domicilié) :
+
−
** <tt>2001</tt> : une adresse unicast globale attribuée par les autorités régionales (cf. [[Unicast Global|Familles d'adressage]]),
+
−
** <tt>660</tt> : est le préfixe attibué par RIPE-NCC au réseau Renater et <tt>688</tt> à France Télécom
+
−
** <tt>7301</tt> est attribué par Renater à l'ENST-Bretagne et <tt>1f99</tt> par France Télécom,
+
−
** <tt>1</tt> : est le numéro du réseau, pour ces deux préfixes, à l'intérieur de l'ENST Bretagne. Il n'est pas nécessaire d'attribuer le même identifiant de sous-réseaux pour les deux préfixes, mais cela est préférable pour des raisons de commodité d'administration.
+
−
 
+
−
L'interface de <tt>lo0</tt> possède les adresses de loopback pour IPv4 et IPv6 (<tt>::1</tt>).
+
−
 
+
−
==Windows XP==
+
−
 
+
−
 
+
−
[[image:Fig3-A.png|thumb|right|350px|''Configuration des interfaces sous Windows'']]
+
−
 
+
−
La figure Configuration des interfaces sous Windows illustre cette propriété, en retournant le résultat de la commande <tt>ipconfig</tt>. On peut noter que l'interface du réseau sans-fils possède trois adresses IPv6 (une lien locale et deux globales). Les adresses globales possèdent le même préfixe de 64 octets (<tt>2001:660:7307:6030::/64</tt>). La première adresse globale a le bit <tt>u=0</tt> dans l'identifiant d'interface, il s'agit de celle générée aléatoirement. La deuxième à le bit <tt>u</tt> à <tt>1</tt> et l'on retrouve la séquence <tt>0xFFFE</tt> au milieu de l'identifiant d'interface; cette adresse est dérivée de l'adresse MAC. Sous Windows, par défaut, les adresses aléatoires ont une durée de vie d'une semaine. Par exemple, en utilisant la commande <tt>netsh</tt> :
+
−
 
+
−
netsh interface ipv6>'''show address'''
+
−
Recherche du statut actif...
+
−
+
−
+
−
Interface 7 : Connexion réseau sans fil
+
−
+
−
Type adr.  État DAD  Vie valide Vie préf.  Adresse
+
−
---------  --------- ---------- ---------- -----------------------------------
+
−
Temporaire Préféré    6d21h18m38s    21h15m51s 2001:660:7307:6030:c853:e48b:aafb:c354
+
−
Public    Préféré    29d23h58m59s  6d23h58m59s 2001:660:7307:6030:204:e2ff:fe5a:9f
+
−
Liaison    Préféré        infinite    infinite fe80::204:e2ff:fe5a:9f
+
−
 
+
−
==Windows Vista==
+
−
==Linux==
+
−
 
+
−
==BSD==
+
−
 
+
−
 
+
−
Ainsi dans l'exemple suivant, issue d'une machine BSD :
+
−
<tt>
+
−
>'''ping6 fe80::200:c0ff:fee4:caa0'''
+
−
PING6 fe80::1%lo0 --> fe80::200:c0ff:fee4:caa0
+
−
ping6: sendmsg: No route to host
+
−
ping6: wrote fe80::200:c0ff:fee4:caa0 16 chars, ret=-1
+
−
ping6: sendmsg: No route to host
+
−
ping6: wrote fe80::200:c0ff:fee4:caa0 16 chars, ret=-1
+
−
^C
+
−
--- fe80::200:c0ff:fee4:caa0 ping6 statistics ---
+
−
2 packets transmitted, 0 packets received, 100% packet loss
+
−
</tt>
+
−
 
+
−
La station est incapable de déterminer l'interface de sortie, par contre si l'on utilise la même adresse de destination en précisant l'interface de sortie :
+
−
 
+
−
<tt>
+
−
>'''ping6 fe80::200:c0ff:fee4:caa0%xl0'''
+
−
PING6 fe80::2b0:d0ff:fe3b:e565%xl0 --> fe80::200:c0ff:fee4:caa0%xl0
+
−
16 bytes from fe80::200:c0ff:fee4:caa0%xl0, icmp_seq=0 hlim=255 time=1 ms
+
−
16 bytes from fe80::200:c0ff:fee4:caa0%xl0, icmp_seq=1 hlim=255 time=1.067 ms
+
−
^C
+
−
--- fe80::200:c0ff:fee4:caa0%xl0 ping6 statistics ---
+
−
2 packets transmitted, 2 packets received, 0% packet loss
+
−
round-trip min/avg/max = 1/1.033/1.067 ms
+
−
</tt>
+
−
 
+
−
on obtient le résultat attendu. La portée sera également utilisée avec les adresses multicast.
+
−
 
+
−
==Mac OS==
+
−
==Cisco==
+
−
 
+
−
= Questions ouvertes =
+
−
 
+
−
= Sujets de recherche =
+
−
 
+
−
 
+
−
 
+
−
== Structuration des adresses et agrégation ==
+
−
 
+
−
Un des problèmes majeurs d'IPv4 est la croissance incontrôlée des tables de routage. Ce phénomène est dû à une mauvaise agrégation des adresses dans les tables. Il faudrait être capable de router des ensembles de réseaux identifiés par un seul descripteur. CIDR apporte une amélioration, mais celle-ci est insuffisante en pratique : les adresses IPv4 sont trop courtes pour permettre une bonne structuration, et il faut surtout assumer le coût du passé avec les adresses déjà allouées.
+
−
 
+
−
Attribuer une adresse à un équipement est un processus complexe, basé sur un compromis entre la facilité d'attribution et la facilité de gestion. Idéalement, pour minimiser la taille de routage, le réseau devrait avoir une topologie en arbre, cela rendrait l'adressage hiérarchique très efficace. Dans la réalité pour des raisons économiques, techniques, géographiques ou de performances, le réseau est beaucoup plus complexe et peut être vu comme un graphe. Il faut introduire des exceptions dans les tables de routages pour refléter cette topologie. On voit que pour avoir l'adressage le plus efficace possible, il faut dans ce graphe trouver la représentation arborescente qui génère le moins d'exceptions possibles. Or s'il était possible aujourd'hui de trouver une représentation valide, elle ne le sera pas nécessairement demain. En conséquence, la définition du plan d'adressage doit être la plus souple possible pour permettre une évolution de nature imprévisible.
+
−
 
+
−
D'autant plus que l'agrégation pour IPv4 ne semble plus aussi efficace. La figure suivante donne l'évolution de table de routage dans le coeur de l'Internet, c'est-à-dire dans les réseaux des opérateurs où aucune route par défaut n'est définie.
+
−
 
+
−
[[Image:Cidr.png|thumb|frame|Evolution de la taille des tables de routage<br>Source: http://www.cidr-report.org]]
+
−
 
+
−
En 2000, la progression linéaire de cette table a semblé compromise du fait :
+
−
 
+
−
* de la baisse du coût des liaisons longues distances, permettant une multi-domiciliation (''multi-homing'') des sites pour des raisons de fiabilité (en cas de panne d'un opérateur, le trafic pourra passer par un autre), de performances (aller directement sur le réseau avec lequel le site à un trafic important),
+
−
* le manque d'adresses IPv4 qui force les opérateurs à allouer des préfixes de plus en plus long.
+
−
 
+
−
Depuis, les opérateurs ont fortement aggrégé pour revenir à une progression linéaire de la table. Des études [[bibliographie#BTC02|[BTC02]]] montrent que :
+
−
 
+
−
* la multi-domiciliation, c'est-à-dire la connexion d'un site à plusieurs opérateurs pour fiabiliser l'accès, ajoute un surcoût de 20 à 30 pourcent,
+
−
* le partage de charge, c'est-à-dire réduire l'agregation pour annoncer un sous-ensemble de préfixe à chaque opérateur, induit un surcoût de 20 à 25 pourcent,
+
−
* de mauvaises règles d'agrégation induisent une surcharge de 15 à 20 pourcent,
+
−
* la fragmentation de l'espace d'adressage liée à la gestion des préfixes avant CIDR, et à l'allocation séquencielle des blocks d'adresses contribue à plus de 75 pourcent de la taille de la table.
+
−
 
+
−
Actuellement, pour pouvoir assurer une bonne agrégation, les règles utilisées par CIDR pour IPv4 sont conservées. Mais la gestion des tables de routage dans le coeur du réseau s'en trouvera quand même améliorée car :
+
−
 
+
−
* dès le début le plan d'adressage est hiérarchique, éliminant les longs préfixes,
+
−
* les sites multi-domiciliés posséderont autant d'adresses que de fournisseurs, permettant ainsi de garantir une agrégation.
+
−
* des mécanismes de renumérotation automatiques permettent aux sites de changer facilement de préfixe quand cela est nécessaire.
+
−
 
+
−
Si un plan d'adressage hiérarchique semble actuellement le plus adapté, d'autres règles de numérotation pourraient être utilisées dans le futur, comme par exemple, les coordonnées géographiques de l'équipement. Ces techniques ne sont actuellement utilisées que dans quelques laboratoires de recherche pour des réseaux ad hoc, mais il reste assez de place dans l'espace d'adressage pour prendre en compte ces nouveaux types de réseaux si un jour ils se généralisent.
+
−
 
+
−
Le choix d'un plan d'adressage a fait l'objet de nombreux débats à l'IETF. Il a été beaucoup plus difficile à définir que le format du paquet IPv6 présenté au chapitre suivant. Plusieurs plans ont été proposés puis abandonnés. Ces divers plans d'adressages sont commentés dans le chapitre sur l'[[La standardisation d'IPv6#plan|Historique]] de la standardisation d'IPv6. Le présent chapitre se contente de décrire les différents [[plans d'adressage]] actuellement utilisés.
+
−
 
+
−
 
+
−
== Évolution de l'adressage ==
+
−
 
+
−
La distinction entre les notions d'annuaires, de noms, d'adresses et de routes est comprise depuis longtemps. Cependant, depuis quelques années, au sein de l'Internet, la compréhension du rôle d'une adresse réseau a évolué. Dans l'Internet, une adresse sert en fait à deux fonctions distinctes : identification et localisation.
+
−
 
+
−
* L'identification est utilisée pendant une connexion par chacun des intervenants pour reconnaître son interlocuteur. Cela permet entre autres de s'assurer de l'origine des paquets reçus. <br> Cette vérification se fait dans les pseudo-en-têtes TCP ou dans les associations de sécurité d'IPsec. La durée de vie minimale d'un identificateur est celle d'une connexion TCP.
+
−
* La localisation est utilisée pour trouver un intermédiaire qui saura délivrer les paquets. La durée de vie de la fonction de localisation est assez grande. En fait, elle ne varie qu'en cas de changement de prestataire IP ou de réorganisation du site. <br> En général la localisation est découpée en deux parties : localisation globale (identifiant le réseau) et locale, distinguant les machines sur un même réseau. La localisation est intrinsèquement liée aux fonctions de routage d'IP.
+
−
 
+
−
En IPv4, on confond identification et localisation en une seule entité, l'adresse IP, globalement unique dans l'Internet. Cette construction a un prix : lors de la renumérotation d'un site, ou lorsqu'un mobile se déplace, la localisation change. Avec l'approche IPv4, l'adresse IP change, et donc l'identification... Cela implique une perte ou au mieux une renégociation des communications en cours.
+
−
 
+
−
Lors des études initiales pour IPv6, il a été proposé de séparer ces deux fonctions pour pouvoir résoudre simplement les problèmes de renumérotation, mobilité, multi-domiciliation... Ceci est encore un sujet de recherche. Cette proposition n'a donc pas été retenue ; en IPv6 comme en IPv4, l'adresse sert à la fois pour l'identification et la localisation. En effet, le plan d'adressage choisi dans un premier temps est une extension des règles d'adressage hiérarchiques (CIDR) utilisées dans IPv4.
+
−
 
+
−
Un autre débat est de savoir si une adresse identifie une machine ou une interface. Cette distinction n'est pas très importante dans le cas d'une machine simple ne possédant qu'une seule interface ; elle le devient dans le cas où elle en possède plusieurs ou est multi-domiciliée. En effet pour essayer de simplifier les tables de routage dans le coeur de réseau, si un site est connecté à plusieurs fournisseur d'accès, il possèdera autant de préfixes IPv6 que de fournisseurs. Contrairement à IPv4, où l'on associe généralement qu'une seule adresse à une interface, une interface possède plusieurs adresses IPv6.
+
−
 
+
−
==Gestion de la Multi-domiciliation==
+
−
 
+
−
La gestion de la multi-domociliation ('''multi-homing''') est encore un sujet de débat dans les groupes. Aucune solution n'est satisfaisante car le routage des paquets dans un domaine multi-domicilié se fait uniquement (comme dans tous l'Internet) sur l'adresse de la source. Si la machine choisit une adresse d'un fournisseur et que les paquets sont routés vers un autre, ce dernier va rejeter le paquet car l'adresse source ne correspond pas à une adresse qu'il a officiellement attribué.
+
−
 
+
−
Ce problème se résoud en IPv4 en attribuant aux sites multi-domiciliés des adresses PI ('''Provider Independant'''). Le site passe des accords avec ses fournisseurs pour qu'ils acceptent ces adresses. Les PI offrent aussi une très grande stabilité dans l'adressage puisque les adresses appartiennent à l'entreprie. En contre partie, les PI conduisent à une explosion des tables de routage dans le cœur du réseau.
+
−
 
+
−
IPv6 aurait IPv6 a essayé de résoudre le problème en offrant la possibilité d'affecter une adresse IPv6 par fournisseur de service. Malheureusement cette solution ne permet pas de résoudre le problème car elle bute sur le choix de l'adresse source en coordination avec le routage. Plusieurs alternatives sont en cours d'étude:
+
−
* utilisation des PI pour IPv6, mais avec le risque d'augmenter les tables de routage IPv6 dans le cœur du réseau. Comme, à court terme, il s'agit de la seule solution crédible, certaines autorités régionales offrent cette possibilité.
+
−
* le groupe [http://www.irtf.org/charter?gtype=rg&group=rrg RRG] (Routing Research Group) de l'IRTF, réfléchit à l'utilisation de tunnel entre les sites pour séparer les fonctions d'indentificateur et de localisateur de l'adresse.
+
−
 
+
−
= Historique =
+
−
 
+
−
<font color=red>Dans un premier temps, des adresses du type [[site-local]] dans l'espace <tt>FEC0::/10</tt> avaient été définies par l'IETF,
+
−
mais elles ont été retirées dans les dernières versions des standards.</font>
+
−
 
+
−
 
+
−
Les adresses site-local sont des adresses dont la validité était restreinte à un site. Par exemple, un site qui n'est pas encore connecté à l'Internet pouvait utiliser ces adresses, ce qui le dispensait de demander ou d'emprunter un préfixe. Ce système généralisait le concept d'adresse privée d'IPv4 (comme le réseau <tt>10.x.y.z</tt>). Un autre intérêt apparent des adresses site-local est qu'elles ne sont pas modifiées lors d'un changement de fournisseur de connectivité, qui ne perturbe donc pas les communications locales.
+
−
 
+
−
Une adresse site-local était construite en concaténant le préfixe <tt>FEC0::/48</tt>, un champ de 16 bits qui permet de définir plusieurs sous-réseaux, et les 64 bits de l'[[Identifiant d'interface|identifiant d'interface]].
+
−
 
+
−
[[image:Fig3-6.png|thumb|right|350px|Figure 3-6 ''Adresse Site_Local'']]
+
−
 
+
−
 
+
−
Malgré ces propriétés, les adresses site-local n'ont pas réussi à s'imposer durant la phase de standardisation d'IPv6. Suivant les règles de l'IETF, elle doivent donc être retirées des documents pour la version finale du RFC décrivant IPv6. Le RFC 3879 décrit les problèmes liés à l'utilisation des adresses site-local. Contrairement à un lien facilement délimité par le support physique, la frontière du site est beaucoup plus vague. Il s'en suit des ambiguïtés qui rendent difficile l'utilisation de ce concept. En particulier, si un utilisateur est connecté à deux sites de deux companies différentes, l'adressage à plat offert par les adresses site-local rendent le routage difficile. Si le site dispose aussi d'adresses globales, l'ajout systématique d'adresses site-local rend également plus difficile le choix des adresses source et destination ainsi que la réponse aux requêtes DNS qui dépendent de la position de l'équipement demandeur.
+
−
 
+
−
De plus si le réseau de deux companies fusionnent, comme l'adressage des sous-réseaux ne se fait que dans la partie Subnet ID, il y a de fortes chances de trouver des collisions dans les valeurs choisies.
+
−
 
+
−
= Références =
+
−
 
+
−
= Tutoriaux/Etudes de cas =
+
−
 
+
−
 
+
−
 
+
−
==Notation==
+
−
 
+
−
 
+
−
== Adresses de test ==
+
−
 
+
−
Les expérimentations d'IPv6 sur un réseau devaient commencer avant que les règles d'attribution des préfixes soient complètement finalisées. La valeur 0x1FFE a été attribué par l'IANA au 6bone dans le plan d'adressage agrégé pour les expérimentations (RFC 3701). Il correspond au préfixe <tt>3FFE::/16</tt> pour l'ensemble du 6bone.
+
−
 
+
−
[[image:Fig3-4.jpg|thumb|right|350px|Figure 3-4 ''Adresse de test du plan agrégé'']]
+
−
 
+
−
Les 48 bits restant avant le champ Subnet ID recréent les niveaux hiérarchiques d'un réseau IPv6 défini dans le RFC 3587, d'où le terme pseudo accolé au nom du champ. La taille réduite n'étant pas un facteur limitant dans la phase expérimentale. Des pseudo-TLA d'une taille initialement de 8, mais portées à 12 bits par la suite, sont attribués à des opérateurs voulant expérimenter le protocole. Les 24 ou 20 bits suivants sont utilisés pour numéroter les sites.
+
−
 
+
−
Les pseudo-TLA ont été alloués jusqu'en décembre 2003 aux opérateurs qui en faisaient la demande. La liste complète est disponible sur le serveur Web http://www.6bone.net/6bone_pTLA_list.html. Le tableau Pseudo TLA attribués par le groupe ngtrans reprend quelques unes de ces valeurs.
+
−
 
+
−
{|
+
−
|+'''''Pseudo TLA attribués par le groupe ngtrans'''''
+
−
!Organismes/Pays!!Préfixe!! !!Organismes/Pays!!Préfixe
+
−
|-style="background:silver"
+
−
|ROOT66/US-CA||3FFE:0000::/24|| ||TRUMPET/AU||3FFE:8000::/28
+
−
|-
+
−
|TELEBIT/DK||3FFE:0100::/24|| ||ICM-PL/PL||3FFE:8010::/28
+
−
|-style="background:silver"
+
−
|SICS/SE||3FFE:0200::/24|| ||IIJ/JP||3FFE:8020::/28
+
−
|-
+
−
|G6/FR||3FFE:0300::/24|| ||QTPVSIX/EU||3FFE:8030::/28
+
−
|-style="background:silver"
+
−
|JOIN/DE||3FFE:0400::/24|| ||APAN-KR||3FFE:8040::/28
+
−
|-
+
−
|WIDE/JP||3FFE:0500::/24|| ||MIBH||3FFE:8050::/28
+
−
|-style="background:silver"
+
−
|SURFNET/NL||3FFE:0600::/24|| ||ATNET-AT||3FFE:8060::/28
+
−
|}
+
−
 
+
−
L'expérimentation lié au 6bone s'est terminée récemment; la date d'arrêt a été symboliquement choisie le mardi 6 juin 2006 RFC 3701. En effet, si ce réseau a servi palier à l'absence d'opérateurs officiels au début de l'introduction d'IPv6, il a vite montré ses limites. L'utilisation de tunnels pour créer la connectivité a conduit à un trop fort maillage, à des routes relativement longues et par conséquence à une faible qualité de service.
+
−
 
+
−
== Adresses gérées par les RIR ==
+
−
 
+
−
La valeur <tt>0x0001</tt> a été attribué par l'IANA pour un plan d'adressage où les autorités régionales attribuent les préfixes. Le préfixe initial est par conséquent <tt>2001::/16</tt>. Ce plan reproduit, en étendant la largeur des champs les principes de délégation et de gestion introduits en IPv4 par CIDR. Un site voulant se connecter reçoit de son fournisseur d'accès un préfixe global de longueur supérieure ou égale à 48 bits.
+
−
 
+
−
Les adresses de type lien-local (''link local use address'') sont des adresses dont la validité est restreinte à un lien, c'est-à-dire l'ensemble de interfaces directement connectées sans routeur intermédiaire : par exemple machines branchées sur un même Ethernet, machines reliées par une connexion PPP, ou extrémités d'un tunnel. Les adresses lien-local sont configurées automatiquement à l'initialisation de l'interface et permettent la communication entre noeuds voisins. L'adresse est obtenue en concaténant le préfixe <tt>FE80::/64</tt> aux 64 bits de l'[[Identifiant d'interface|identifiant d'interface]].
+
−
 
+
−
[[image:Fig3-5.jpg|thumb|right|400px|Figure 3-5 ''Adresse Lien_Local'']]
+
−
 
+
−
 
+
−
 
+
−
Ces adresses sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins (''neighbor discovery'') et de découverte de routeurs (''router discovery''). Ce sont de nouveaux dispositifs, le premier supplantant en particulier le protocole ARP (''Address Resolution Protocol''), qui permettent pas à un réseau local de se configurer automatiquement (voir [[Découverte de voisins]]).
+
−
 
+
−
Les adresses lien-local sont uniques à l'intérieur d'un lien. Le protocole de détection de duplication d'adresse (voir [[Configuration automatique#DAD|Détection d'adresse dupliquée]]) permet de s'en assurer. Par contre la duplication d'une adresse lien-local entre deux liens différents, ou entre deux interfaces d'un même noeud est autorisée.
+
−
 
+
−
Un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type lien-local.
+
−
 
+
−
Le fait que ces adresses aient une portée très faible les limite dans la pratique au cas où un démarrage automatique (''bootstrap'') est nécessaire. Leur usage ne doit pas être généralisé dans les applications classiques en régime stabilisé.
+
−
 
+
−
 
+
−
==Selection du type d'identifiant d'interface==
+
−
 
+
−
Si l'on sélectionne correctement le type d'identifiant d'interface, la gestion de l'adressage IPv6 est aussi facile (voire plus simple) qu'en IPv6. Ainsi, il est préférable de donner aux serveurs des identifiants d'inteface construit manuellement. Il sera ainsi beaucoup plus facile de se rappeler de leur adresse. De plus si l'équipement est remplacé et par conséquent que la carte réseau est différente, l'adresse IPv6 restera stable. Pour les clients, il est plus simple d'utiliser l'identifiant d'interface construit à partir de l'adresse MAC.
+
−
 
+
−
   
+
−
Les adresses site-local sont des adresses dont la validité était restreinte à un site. Par exemple, un site qui n'est pas encore connecté à l'Internet pouvait utiliser ces adresses, ce qui le dispensait de demander ou d'emprunter un préfixe. Ce système généralisait le concept d'adresse privée d'IPv4 (comme le réseau <tt>10.x.y.z</tt>). Un autre intérêt apparent des adresses site-local est qu'elles ne sont pas modifiées lors d'un changement de fournisseur de connectivité, qui ne perturbe donc pas les communications locales.
+
−
 
+
−
Une adresse site-local était construite en concaténant le préfixe <tt>FEC0::/48</tt>, un champ de 16 bits qui permet de définir plusieurs sous-réseaux, et les 64 bits de l'[[Identifiant d'interface|identifiant d'interface]].
+
−
 
+
−
[[image:Fig3-6.png|thumb|right|350px|Figure 3-6 ''Adresse Site_Local'']]
+
−
 
+
−
 
+
−
Malgré ces propriétés, les adresses site-local n'ont pas réussi à s'imposer durant la phase de standardisation d'IPv6. Suivant les règles de l'IETF, elle doivent donc être retirées des documents pour la version finale du RFC décrivant IPv6. Le RFC 3879 décrit les problèmes liés à l'utilisation des adresses site-local. Contrairement à un lien facilement délimité par le support physique, la frontière du site est beaucoup plus vague. Il s'en suit des ambiguïtés qui rendent difficile l'utilisation de ce concept. En particulier, si un utilisateur est connecté à deux sites de deux companies différentes, l'adressage à plat offert par les adresses site-local rendent le routage difficile. Si le site dispose aussi d'adresses globales, l'ajout systématique d'adresses site-local rend également plus difficile le choix des adresses source et destination ainsi que la réponse aux requêtes DNS qui dépendent de la position de l'équipement demandeur.
+
−
 
+
−
De plus si le réseau de deux companies fusionnent, comme l'adressage des sous-réseaux ne se fait que dans la partie Subnet ID, il y a de fortes chances de trouver des collisions dans les valeurs choisies.
+
−
 
+
−
 
+
−
 
+
−
 
+
−
 
+
−
=Recherche=
+
−
<!--
+
−
<font color=red>
+
−
 
+
−
 
+
−
'''''LT: Je ne suis pas certain qu'il faille mettre ici cette discussion trompeuse sur le nombre d'adresse par mm2 car il ne s'agit pas vraiment des plans d'adressage, plutot le mettre dans la partie format de paquet pour indiquer les raisons d'un adressage de taille fixe'''''
+
−
 
+
−
Une adresse IPv6 est un mot de 128 bits. La taille d'une adresse IPv6 est le quadruple de celle d'une adresse IPv4. En prenant en compte les estimations les plus pessimistes et les plus optimistes [[bibliographie#BM95|[BM95]]], on obtient l'encadrement suivant où l'unité est le nombre d'adresses par mètre carré de surface terrestre (océans compris) :
+
−
 
+
−
 
+
−
<math>1564 < adresses disponibles  < 3911873538269506102</math>
+
−
 
+
−
D'autres calculs indiquent que l'on pourrait potentiellement attribuer 60 000 milliards de milliards d'adresses par habitant.
+
−
 
+
−
Ces calculs sont bien entendu complètement arbitraires. Il est difficile de prévoir l'utilisation des adresses dans les années futures. Ainsi, par exemple, le plan d'adressage actuellement mis en oeuvre utilise un identifiant d'équipement sur 64 bits, c'est-à-dire la moitié de la taille de l'adresse. En fait ce genre de calcul sert de justification aux partisans des adresses de taille fixe (ce qui simplifie le traitement des paquets) en montrant que le nombre d'équipements adressables est colossal.
+
−
 
+
−
Il ne faut toutefois pas faire un contre-sens sur l'interprétation de ces calculs. Le but d'IPv6 n'est pas d'attribuer une fois pour toute une adresse IPv6 à un équipement (ou à un être humain). Une adresse IPv6 n'a de sens et d'utilité que lors que l'équipement est connecté sur le réseau. De plus si l'emplacement sur le réseau de cet équipement change, l'adresse devra également être modifiée pour refléter ce déplacement.
+
−
 
+
−
</font>
+
−
-->
+

Latest revision as of 06:49, 4 May 2022

> MOOC>Contenu>Ressources

Ressources bibliographiques

Articles

  • Bernstein, Daniel J. The IPv6 mess.
  • . Cui Y., Wu P., Xu M., et al., “4over6: Network Layer Virtualization for IPv4-IPv6 Coexistence,” IEEE Network, October 2012.

Livres

  • Graziani, R. (2012). Ed.: Cisco Press. BookOnLine IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6
  • liste sur la page de Pascal Anelli
  • Migrating to IPv6: A Practical Guide to Implementing IPv6 in Mobile and FIxed network Par Marc Blanchet

IETF WG

RFC

Référence barrée si reprise dans une séquence

  • RFC 8956 Dissemination of Flow Specification Rules for IPv6
  • RFC 8883 ICMPv6 Errors for Discarding Packets Due to Processing Limits
  • RFC 8781 Discovering PREF64 in Router Advertisements
  • RFC 8754 on IPv6 Segment Routing Header (SRH)
  • RFC 8504: IPv6 Node Requirements(Bortzmeyer)
  • RFC 8501: Reverse DNS in IPv6 for Internet Service Providers (Bortzmeyer)
  • RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Bortzmeyer)
  • RFC 8201 Path MTU Discovery for IP version 6 (Bortzmeyer)
  • RFC 8200 Internet Protocol, Version 6 (IPv6) Specification (Bortzmeyer)
  • RFC 8021: Generation of IPv6 Atomic Fragments Considered Harmful (Bortzmeyer)
  • RFC 7608 IPv6 Prefix Length Recommendation for Forwarding
  • RFC 7600 IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)
  • RFC 7599 Mapping of Address and Port using Translation (MAP-T)
  • RFC 7596 Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture
  • RFC 7421 Analysis of the 64-bit Boundary in IPv6 Addressing (Bortzmeyer)
  • RFC 7411 Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers
  • RFC 7404 Using Only Link-Local Addressing inside an IPv6 Network (Bortzmeyer)
  • RFC 7381 Enterprise IPv6 Deployment Guidelines (Bortzmeyer)
  • RFC 7368 IPv6 Home Networking Architecture Principles
  • RFC 7346 IPv6 Multicast Address Scopes
  • RFC 7269 NAT64 Deployment Options and Experience (Bortzmeyer)
  • RFC 7227 Guidelines for Creating New DHCPv6 Options
  • RFC 7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP) (Bortzmeyer)
  • RFC 7219 SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)
  • RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) (Bortzmeyer)
  • RFC 7148 Prefix Delegation Support for Proxy Mobile IPv6
  • RFC 7136 Significance of IPv6 Interface Identifiers (Bortzmeyer)
  • RFC 7123 Security Implications of IPv6 on IPv4 Networks (Bortzmeyer)
  • RFC 7112 Implications of Oversized IPv6 Header Chains
  • RFC 7098 Using the IPv6 Flow Label for Load Balancing in Server Farms
  • RFC 7084 Basic Requirements for IPv6 Customer Edge Routers
  • RFC 7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms (Bortzmeyer)
  • RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix
  • RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis (Bortzmeyer)
  • RFC 7048 Neighbor Unreachability Detection Is Too Impatient
  • RFC 7045 Transmission and Processing of IPv6 Extension Headers
  • RFC 7040 Public IPv4-over-IPv6 Access Network
  • RFC 7010 IPv6 Site Renumbering Gap Analysis (Bortzmeyer)
  • RFC 6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
  • RFC 6948 Some Measurements on World IPv6 Day from an End-User Perspective (Bortzmeyer)
  • RFC 6946 Processing of IPv6 "Atomic" Fragments
  • RFC 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
  • RFC 6935 IPv6 and UDP Checksums for Tunneled Packets (Bortzmeyer)
  • RFC 6908 Deployment Considerations for Dual-Stack Lite (Bortzmeyer)
  • RFC 6890 Special-Purpose IP Address Registries (Bortzmeyer)
  • RFC 6889 Analysis of Stateful 64 Translation
  • RFC 6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods (Bortzmeyer)
  • RFC 6877 464XLAT: Combination of Stateful and Stateless Translation
  • RFC 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers (Bortzmeyer)
  • RFC 6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks (Bortzmeyer)
  • RFC 6791 Stateless Source Address Mapping for ICMPv6 Packets
  • RFC 6782 Wireline Incremental IPv6 (Bortzmeyer)
  • RFC 6752 Issues with Private IP Addressing in the Internet
  • RFC 6732 6to4 Provider Managed Tunnels
  • RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6) (Bortzmeyer)
  • RFC 6611 Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario
  • RFC 6586 Experiences from an IPv6-Only Network (Bortzmeyer)
  • RFC 6654 Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd)
  • RFC 6589 Considerations for Transitioning Content to IPv6 (Bortzmeyer)
  • RFC 6586 Experiences from an IPv6-Only Network
  • RFC 6583 Operational Neighbor Discovery Problems
  • RFC 6564 A Uniform Format for IPv6 Extension Headers
  • RFC 6555 Happy Eyeballs: Success with Dual-Stack Hosts (Bortzmeyer)
  • RFC 6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6
  • RFC 6540 IPv6 Support Required for All IP-Capable Nodes
  • RFC 6496 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)
  • RFC 6437 IPv6 Flow Label Specification, voir aussi RFC 6438, RFC 6436
  • RFC 6434 IPv6 Node Requirements
  • RFC 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
  • RFC 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage (Bortzmeyer)
  • RFC 6343 Advisory Guidelines for 6to4 Deployment
  • RFC 6342 Mobile Networks Considerations for IPv6 Deployment, aussi RFC 6212
  • RFC 6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite (Bortzmeyer)
  • RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (Bortzmeyer)
  • RFC 6324 Routing Loop Attack Using IPv6 Automatic Tunnels
  • RFC 6301 A Survey of Mobility Support in the Internet
  • RFC 6294 Survey of Proposed Use Cases for the IPv6 Flow Label
  • RFC 6275 Mobility Support in IPv6
  • RFC 6221 Lightweight DHCPv6 Relay Agent
  • RFC 6204 Basic Requirements for IPv6 Customer Edge Routers
  • RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment (Bortzmeyer)
  • RFC 6177 IPv6 Address Assignment to End Sites (Bortzmeyer)
  • RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links (Bortzmeyer)
  • RFC 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers (Bortzmeyer)
  • RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (Bortzmeyer)
  • RFC 6145 IP/ICMP Translation Algorithm (Bortzmeyer)
  • RFC 6144 Framework for IPv4/IPv6 Translation (Bortzmeyer)
  • RFC 6127 IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios
  • RFC 6106 IPv6 Router Advertisement Options for DNS Configuration
  • RFC 6104: Rogue IPv6 Router Advertisement Problem Statement
  • RFC 6092: Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Bortzmeyer)
  • RFC 6085 Address Mapping of IPv6 Multicast Packets on Ethernet
  • RFC 6081 Teredo Extensions
  • RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators (Bortzmeyer)
  • RFC 6036 Emerging Service Provider Scenarios for IPv6 Deployment (Bortzmeyer)
  • RFC 5952 A Recommendation for IPv6 Address Text Representation (Bortzmeyer)
  • RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
  • RFC 5902 IAB Thoughts on IPv6 Network Address Translation (Bortzmeyer)
  • RFC 5722 Handling of Overlapping IPv6 Fragments
  • RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) (Bortzmeyer)
  • RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) (Bortzmeyer)
  • RFC 5453 Reserved IPv6 Interface Identifiers (Bortzmeyer)
  • RFC 5375 IPv6 Unicast Address Assignment Considerations (Bortzmeyer)
  • RFC 5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
  • RFC 5156 Special-Use IPv6 Addresses (Bortzmeyer)
  • RFC 4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status
  • RFC 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks
  • RFC 4925 Softwire Problem Statement (Bortzmeyer)
  • RFC 4864 Local Network Protection for IPv6 (Bortzmeyer)
  • RFC 4862 IPv6 Stateless Address Autoconfiguration
  • RFC 4821 Packetization Layer Path MTU Discovery ([Bortzmeyer])
  • RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
  • RFC 4213 Transition Mechanisms for IPv6 Hosts and Routers (Bortzmeyer)

Support du G6

Références générales

Adressage

vidéo

Presse. - rapport

Internet Usage

  • Baromètre annuel de la transition vers IPv6 en France (ARCEP - 2021) Lien

TP

  • JOOL [2] un code alternatif à Tayga (NAT64)
Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Ressources&oldid=20385"
Personal tools