<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>4.
La longueur de préfixe nécessaire au routage
</title>
<link rel="stylesheet" href="style.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.66.1">
<link rel="start" href="index.html" title="
HOWTO IPv6 Linux (fr)
">
<link rel="up" href="ch03.html" title="Chapitre 3.
Les types d'adresse
">
<link rel="prev" href="ch03s03.html" title="3.
Les types d'adresse (partie hôte)
">
<link rel="next" href="ch04.html" title="Chapitre 4.
La vérification d'un système prêt pour IPv6
">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">4.
La longueur de préfixe nécessaire au routage
</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="ch03s03.html">Précédent</a> </td>
<th width="60%" align="center">Chapitre 3.
Les types d'adresse
</th>
<td width="20%" align="right"> <a accesskey="n" href="ch04.html">Suivant</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1" lang="fr">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id2537187"></a>4.
La longueur de préfixe nécessaire au routage
</h2></div></div></div>
<p>
Dans les premières phases de la conception, il était prévu d'utiliser une approche intégrale de routage hiérarchique, et ce, afin de réduire au maximum la taille des tables de routage. A la base du raisonnement sous-tendu par cette approche, il y a la prise en compte du nombre grandissant des entrées de routage IPv4 au coeur des routeurs (supérieur à 104 000 en mai 2001), la nécessité de réduire ce nombre afin de diminuer le besoin en mémoire du matériel (piloté par Circuit Intégré d'Application Spécifique, <span class="emphasis"><em>Application Specified Integrated Circuit</em></span>, ou ASIC) maintenant les tables de routage, et, en conséquence, d'accroître la vitesse (dans l'espoir que moins d'entrées génèrent des recherches plus rapides).
</p>
<p>
Aujourd'hui, le point de vue est que le routage sera conçu quasi-hiérarchiquement pour les réseaux ayant seulement un fournisseur de service. Pour plus d'une connexion à un ISP, ce n'est pas possible, et cela relève du problème de la multi-résidence (des informations sur la multi-résidence: <a href="http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-isp-int-aggr-00.txt" target="_top">Procider-Internal Aggregation based on Geography to Support Multihoming in IPv6</a>; <a href="http://www.ietf.org/internet-drafts/draft-by-multi6-gapi-00.txt" target="_top">GAPI: A Geographically Aggregatable Provider Independent Address Space to Support Multihoming in IPv6</a>; <a href="http://www.ietf.org/internet-drafts/draft-bagnulo-multi6-mhexthdr-00.txt" target="_top">Extension Header for Site-Multi-homing support</a>; <a href="http://arneill-py.sacramento.ca.us/ipv6mh/" target="_top"> IPv6 Multihoming Solutions</a>)
</p>
<div class="sect2" lang="fr">
<div class="titlepage"><div><div><h3 class="title">
<a name="id2537261"></a>4.1.
La longueur du préfixe (aussi connue en tant que "masque de réseau")
</h3></div></div></div>
<p>
Comme pour IPv4, la notion de chemin de réseau routable nécessaire au routage a ici sa place. Parce que la notation standard d'un masque réseau n'est pas très agréable pour un adressage sur 128 bits, les concepteurs ont employé le schéma du Routage Inter-Domaines IPv4 Sans Classe (<span class="emphasis"><em>IPv4 Classless Inter Domain Routing</em></span>, ou CIDR, défini dans le <a href="http://www.faqs.org/rfcs/rfc1519.html" target="_top"> RFC 1519 / Classless Inter-Domain Routing</a>), dans lequel est spécifié le nombre de bits de l'adresse devant être utilisé pour le routage. Il est aussi connu comme notation “slash”.
</p>
<p>
Un exemple:
</p>
<pre class="programlisting">
3ffe:ffff:100:1:2:3:4:5/48
</pre>
<p>
De cette notation seront extraits:
</p>
<div class="itemizedlist"><ul type="disc"><li><p>
le réseau:
</p></li></ul></div>
<pre class="programlisting">
3ffe:ffff:0100:0000:0000:0000:0000:0000
</pre>
<div class="itemizedlist"><ul type="disc"><li><p>
le masque de réseau:
</p></li></ul></div>
<pre class="programlisting">
ffff:ffff:ffff:0000:0000:0000:0000:0000
</pre>
</div>
<div class="sect2" lang="fr">
<div class="titlepage"><div><div><h3 class="title">
<a name="id2537347"></a>4.2.
La correspondance à une route
</h3></div></div></div>
<p>
Dans des conditions normales (<span class="emphasis"><em>i.e.</em></span> sans QoS), de la recherche dans une table de routage résulte la route ayant le plus grand nombre de bits d'adresse significatifs; autrement dit, la route avec le plus grand préfixe correspond la première.
</p>
<p>
Par exemple, si une table de routage affiche les entrées suivantes (la liste est incomplète):
</p>
<pre class="programlisting">
3ffe:ffff:100::/48 :: U 1 0 0 sit1
2000::/3 ::192.88.99.1 UG 1 0 0 tun6to4
</pre>
<p>
Ci-dessous, les adresses de destination des paquets IPv6 dont le trafic sera routé au travers du périphérique désigné
</p>
<pre class="programlisting">
3ffe:ffff:100:1:2:3:4:5/48 -> trafic routé au travers du périphérique sit1
3ffe:ffff:200:1:2:3:4:5/48 -> trafic routé au travers du périphérique tun6to4
</pre>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="ch03s03.html">Précédent</a> </td>
<td width="20%" align="center"><a accesskey="u" href="ch03.html">Niveau supérieur</a></td>
<td width="40%" align="right"> <a accesskey="n" href="ch04.html">Suivant</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">3.
Les types d'adresse (partie hôte)
</td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Sommaire</a></td>
<td width="40%" align="right" valign="top"> Chapitre 4.
La vérification d'un système prêt pour IPv6
</td>
</tr>
</table>
</div>
</body>
</html>
