<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>3.
Les types d'adresse (partie hôte)
</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="ch03s02.html" title="2.
La partie réseau, aussi appelée préfixe
">
<link rel="next" href="ch03s04.html" title="4.
La longueur de préfixe nécessaire au routage
">
</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">3.
Les types d'adresse (partie hôte)
</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="ch03s02.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="ch03s04.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="id2536989"></a>3.
Les types d'adresse (partie hôte)
</h2></div></div></div>
<p>
En ce qui concerne les questions d'auto-configuration et de mobilité, Il a été décidé d'utiliser les 64 bits inférieurs de la partie hôte de l'adresse pour la plupart des types d'adresse actuels. Conséquemment, chaque sous-réseau détient une grande quantité d'adresses.
</p>
<p>
Cette partie hôte peut être différemment considérée:
</p>
<div class="sect2" lang="fr">
<div class="titlepage"><div><div><h3 class="title">
<a name="id2537014"></a>3.1.
L'adresse calculée automatiquement (dite aussi “sans état”)
</h3></div></div></div>
<p>
Avec l'auto-configuration, la partie hôte de l'adresse est calculée en convertissant l'adresse MAC d'une interface (si disponible), avec la méthode EUI-64, en une adresse IPv6 unique. Si aucune adresse MAC n'est disponible pour le périphérique en question (ce qui arrive par exemple sur les périphériques virtuels), quelque chose d'autre (comme l'adresse IPv4 ou l'adresse MAC d'une interface physique) est utilisée à la place.
</p>
<p>
Considérons à nouveau le premier exemple:
</p>
<pre class="programlisting">
3ffe:ffff:100:f101:210:a4ff:fee3:9566
</pre>
<p>
ici,
</p>
<pre class="programlisting">
210:a4ff:fee3:9566
</pre>
<p>
est la partie hôte calculée à partir de l'adresse MAC de la NIC
</p>
<pre class="programlisting">
00:10:A4:E3:95:66
</pre>
<p>
en utilisant <a href="http://standards.ieee.org/regauth/oui/tutorials/EUI64.html" target="_top">IEEE EUI-64</a> conçue pour les identifiants EUI-48.
</p>
<div class="sect3" lang="fr">
<div class="titlepage"><div><div><h4 class="title">
<a name="id2537083"></a>3.1.1.
Le problème d'incursion possible dans la sphère privée (<span class="emphasis"><em>privacy problem</em></span>) avec les adresses automatiquement calculées, et une solution
</h4></div></div></div>
<p>
Parce que la partie hôte "automatiquement calculée” est globalement unique (sauf lorsqu'un fabriquant de NIC utilise la même adresse MAC sur plus d'une NIC), la traque grâce à un client (<span class="emphasis"><em>client tracking</em></span>) est possible sur l'hôte, dès lors qu'aucun proxy d'aucune sorte n'est utilisé.
</p>
<p>
C'est un problème connu, et une solution a été apportée: l'extension “sphère privée”, définie dans le RFC 3041 (<a href="http://www.faqs.org/rfcs/rfc3041.html" target="_top">RFC 3041 / Privacy Extensions for Stateless Address</a>; il y a déjà aussi un brouillon plus récent disponible: <a href="ftp://ftp.ietf.org/internet-drafts/" target="_top">draft-ietf-ipngwg-temp-addresses-*.txt</a>). Le principe est d'utiliser une valeur aléatoire et une valeur statique à partir desquelles un nouveau suffixe est généré à intervalle régulier. Note: ce n'est raisonnable que pour des connexions client sortantes, et n'est pas vraiment utile pour des machines réputées être des serveurs.
</p>
</div>
</div>
<div class="sect2" lang="fr">
<div class="titlepage"><div><div><h3 class="title">
<a name="id2537147"></a>3.2.
La configuration manuelle
</h3></div></div></div>
<p>
Pour les serveurs, il est probablement plus aisé de se rappeler d'adresses plus simples; cela peut aussi se faire. Il est possible d'assigner une adresse IPv6 additionnelle à une interface, par exemple
</p>
<pre class="programlisting">
3ffe:ffff:100:f101::1
</pre>
<p>
Pour les suffixes tels que “::1”, montré dans l'exemple ci-dessus, il est requis que le septième bit le plus significatif soit positionné à 0 (le bit universel/local d'un identifiant automatiquement généré). Certaines autres (à part celles qui n'ont pas étaient choisies) combinaisons de bits sont réservées aux adresses anycast.
</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="ch03s02.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="ch03s04.html">Suivant</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">2.
La partie réseau, aussi appelée préfixe
</td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Sommaire</a></td>
<td width="40%" align="right" valign="top"> 4.
La longueur de préfixe nécessaire au routage
</td>
</tr>
</table>
</div>
</body>
</html>
