Difference between revisions of "AdressageBis-Questions"
From Livre IPv6
(→Adresses Anycast) |
(→Adresses anycast sur un même lien) |
||
| (28 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| + | {{Suivi|AdressageBis-MeO|Mises en Oeuvre|AdressageBis-Recherches|Problèmes de Recherche}} | ||
| + | |||
=Adresses Anycast= | =Adresses Anycast= | ||
Le principe sous-jacent est relativement 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. | Le principe sous-jacent est relativement 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. | ||
| − | + | ==Préfixe virtuel== | |
| − | Il existe deux méthodes pour utiliser l'adressage | + | Il existe deux méthodes pour utiliser l'adressage anycast. La première consiste à définir un préfixe "virtuel" qui sera diffusé à plusieurs endroit dans l'Internet. Cette méthode est déjà très utilisée en IPv4 pour accéder à certains serveurs. Ainsi plusieurs serveurs de la racine du DNS (voir http://www.root-servers.org) partagent la même adresse et donc le même préfixe. Ce préfixe est annoncé par plusieurs réseaux. Pour le DNS, cela présente plusieurs avantages : |
| − | * | + | * la résolution se fait au plus près (au sens métrique du protocole de routage utilisé) de l'utilisateur, ce qui réduit les temps de réponse; |
| − | * | + | * les attaques par déni de service sont plus difficiles, car il faut que toutes les attaques viennent d'une même zone, sinon elles sont réparties sur plusieurs serveurs; |
| − | * | + | * le nombre d'adresses à connaître par les résolveurs est limité. |
| − | Le | + | Le mécanisme de transition [[6to4]] utilise également cette technique. Le préfixe <tt>192.88.99.0/24</tt> correspondant à des extremités de tunnels (<tt>192.88.99.1</tt>) et donnant accès à l'Internet v6 est annoncé a plusieurs endroits dans le réseau. Cela permet de préconfigurer les équipements avec cette adresse et d'offrir à l'utilisateur l'extrémité de tunnel la plus proche. En cas de disparition de celle-ci, le routage de l'Internet aiguillera automatiquement vers un autre équipement tunnelier. |
| − | Ce mécanisme fonctionne de la même manière avec les adresses IPv6. | + | Ce mécanisme fonctionne de la même manière avec les adresses IPv6. L'exemple suivant l'illustre avec les adresses IPv6 d'un serveur DNS. Vu depuis la France et le réseau de Renater, la route pour atteindre cette machine est la suivante : |
%'''traceroute6 2001:500:2f::f''' | %'''traceroute6 2001:500:2f::f''' | ||
| Line 25: | Line 27: | ||
8 f.root-servers.net 8.738 ms 9.171 ms 8.702 ms | 8 f.root-servers.net 8.738 ms 9.171 ms 8.702 ms | ||
| + | Comme l'indique ce traceroute, la machine est localisée au sfinx (nœud d'échange de trafic Internet situé en France). | ||
| − | <tikz title="Adresses Anycast"> | + | Un traceroute vers la même destination depuis une machine localisée aux États-Unis (Hawaï) donne le résultat suivant : |
| + | |||
| + | traceroute6 to 2001:500:2f::f (2001:500:2f::f) from 2001:1888:0:1:2d0:b7ff:fe7d:bed6, 64 hops max, 12 byte packets | ||
| + | 1 apapane-fe0-0-1 1.169 ms 0.970 ms 0.947 ms | ||
| + | 2 r1.mdtnj.ipv6.att.net 121.159 ms 121.737 ms 121.378 ms | ||
| + | 3 bbr01-p1-0.nwrk01.occaid.net 130.468 ms 129.640 ms 130.845 ms | ||
| + | 4 bbr01-g1-0.asbn01.occaid.net 131.372 ms 131.596 ms 131.421 ms | ||
| + | 5 bbr01-g1-0.atln01.occaid.net 144.937 ms 144.550 ms 144.834 ms | ||
| + | 6 bbr01-p1-0.dlls01.occaid.net 166.709 ms 196.177 ms 165.983 ms | ||
| + | 7 dcr01-p1-5.lsan01.occaid.net 138.437 ms 138.690 ms 138.544 ms | ||
| + | 8 bbr01-g0-2.irvn01.occaid.net 138.552 ms 137.956 ms 137.649 ms | ||
| + | 9 dcr01-g1-2.psdn01.occaid.net 137.629 ms 138.030 ms 141.332 ms | ||
| + | 10 bbr01-f1-5.snfc02.occaid.net 138.501 ms 138.511 ms 137.483 ms | ||
| + | 11 exit.sf-guest.sfo2.isc.org 147.941 ms 144.929 ms 145.956 ms | ||
| + | 12 f.root-servers.net 139.063 ms 139.715 ms 142.571 ms | ||
| + | |||
| + | Le serveur se trouve dans les locaux de l'ISC. | ||
| + | |||
| + | == Adresses anycast sur un même lien == | ||
| + | |||
| + | Le deuxième type d'adresses anycast correspond à l'allocation de plusieurs adresses identiques sur le même lien. Cette méthode est plus complexe à gérer, car normalement, IPv6 va tester qu'une adresse n'est pas déjà présente grâce au mécanisme de détection d'adresses dupliquées (DAD). Comme rien ne distingue une adresse anycast d'une adresse unicast, il faut désactiver la détection d'adresses dupliquées en précisant anycast lors de l'affectation de l'adresse à l'interface. Comme le montre l'exemple suivant : | ||
| + | |||
| + | # '''ifconfig en3''' | ||
| + | en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 | ||
| + | inet6 fe80::223:6cff:fe97:679c%en3 prefixlen 64 scopeid 0x5 | ||
| + | inet 192.168.103.177 netmask 0xffffff00 broadcast 192.168.103.255 | ||
| + | inet6 2001:660:7301:3103:223:65ff:fe97:679c prefixlen 64 autoconf | ||
| + | ether 00:23:6c:97:67:9c | ||
| + | media: autoselect status: active | ||
| + | supported media: autoselect | ||
| + | # '''ifconfig en3 inet6 2001:660:7301:3103:FF::FF anycast''' | ||
| + | # '''ifconfig''' | ||
| + | en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 | ||
| + | inet6 fe80::223:6cff:fe97:679c%en3 prefixlen 64 scopeid 0x5 | ||
| + | inet 192.168.103.177 netmask 0xffffff00 broadcast 192.168.103.255 | ||
| + | inet6 2001:660:7301:3103:223:65ff:fe97:679c prefixlen 64 autoconf | ||
| + | inet6 2001:660:7301:3103:ff::ff prefixlen 64 anycast | ||
| + | ether 00:23:6c:97:67:9c | ||
| + | media: autoselect status: active | ||
| + | supported media: autoselect | ||
| + | |||
| + | |||
| + | 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. Peut-être que les réseaux de capteurs pourraient permettre une utilisation à plus grande échelle de l'anycast. Ainsi, à une question comme « quelle est la température de la pièce ? » le premier capteur pouvant répondre à la question enverra la réponse tandis que les autres capteurs pourraient demeurer silencieux. | ||
| + | |||
| + | La figure « Adresses Anycast » 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 vues 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. | ||
| + | |||
| + | <tikz title="Adresses Anycast"> | ||
\clip (0, 0) rectangle (11,4); | \clip (0, 0) rectangle (11,4); | ||
% \draw[help lines] (0,0) grid (10,3); | % \draw[help lines] (0,0) grid (10,3); | ||
| − | + | ||
% \draw (0, 3.6) node [right] {Unique Local IPv6 Unicast Addresses:}; | % \draw (0, 3.6) node [right] {Unique Local IPv6 Unicast Addresses:}; | ||
| − | \draw (0,2) node [right, draw, shade, top color = | + | \draw (0,2) node [right, draw, shade, top color = gray!50, minimum width=5.5cm, minimum height=1cm] {Prefix}; |
\draw (5.5,2) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID}; | \draw (5.5,2) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID}; | ||
| Line 40: | Line 89: | ||
</tikz> | </tikz> | ||
| − | + | Comme les adresses de type anycast sont allouées dans le même espace d'adressage que l'unicast, elles sont créées en attribuant une même adresse unicast à des nœuds 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 unicast 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | 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 | + | |
| − | + | ||
| − | + | ||
{| | {| | ||
| Line 64: | Line 102: | ||
|} | |} | ||
| + | On peut remarquer que l'usage des l'anycast n'est pas généralisé puisqu'une seule valeur a été définie et correspond à l'agent mère pour IPv6 mobile. Cela pourrait changer avec l'introduction d'IPv6 dans les réseaux de capteurs. En effet, un des intérêts de l'adressage anycast est de désigner une fonction plus qu'une machine particulière. Avec les réseaux de capteur, on s'interesse plus à une information qu'à l'équipement qui a permis de l'obtenir, par exemple si des capteurs sont interrogés sur la température d'une pièce, le premier à donner l'information peut être suffisant. | ||
| + | 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 « Anycast sur le 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. | |
| − | = | + | <tikz title="Anycast sur le lien"> |
| − | + | \draw[line width=0.3cm,color=red!30,cap=round,join=round] (1,1)--(9,1); | |
| − | + | \foreach \i/\j in {1/1, 3/2, 5/3 } { | |
| − | + | \pgfputat{\pgfxy(\i,3)}{\pgfbox[left,base]{\pgfuseimage{compleftred}}} | |
| − | + | \draw[line width=0.15cm,color=red!30,cap=round,join=round] ([xshift=0.4cm]\i,1)--([xshift=0.4cm]\i,3); | |
| − | [[ | + | \draw ([xshift=0.5cm]\i,2.5) node {$\alpha$::\j}; |
| + | \draw ([xshift=0.5cm]\i,2.1) node {$\alpha$::FFF1}; | ||
| + | } | ||
| + | |||
| + | \draw (8, 2) node [right, color=blue]{\tiny{$\alpha$::FFF1 $\rightarrow$ MAC2}}; | ||
| + | |||
| + | \draw [->, thick] (8.3, 3) -- (8.3, 0.8) -- ([xshift=0.9cm]3, 0.8) -- ([xshift=0.9cm]3, 3); | ||
| + | |||
| + | \pgfputat{\pgfxy(7.5,3)}{\pgfbox[left,base]{\pgfuseimage{compleft}}} | ||
| + | \draw[line width=0.15cm,color=red!30,cap=round,join=round] (8,1)--(8,3); | ||
| + | |||
| + | </tikz> | ||
| − | == | + | ==Contraintes de l'Anycast== |
| − | + | Comme le correspondant peut varier soit en cas de modification du routage ou de la table de résolution d'adresse, il ne peut pas y avoir d'états. L'Anycast doit être limité à des requêtes simples de type question/réponse ou la gestion de tunnels (bien que cela puisse entraîner un déséquencement). De même les protocoles de niveau 4 orientés connexion comme TCP ne peuvent pas être utilisés. | |
| − | + | {{Suivi|AdressageBis-MeO|Mises en Oeuvre|AdressageBis-Recherches|Problèmes de Recherche}} | |
Latest revision as of 08:56, 6 March 2011
| |
Mises en Oeuvre | Table des matières | Problèmes de Recherche | |
Contents
Adresses Anycast
Le principe sous-jacent est relativement 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.
Préfixe virtuel
Il existe deux méthodes pour utiliser l'adressage anycast. La première consiste à définir un préfixe "virtuel" qui sera diffusé à plusieurs endroit dans l'Internet. Cette méthode est déjà très utilisée en IPv4 pour accéder à certains serveurs. Ainsi plusieurs serveurs de la racine du DNS (voir http://www.root-servers.org) partagent la même adresse et donc le même préfixe. Ce préfixe est annoncé par plusieurs réseaux. Pour le DNS, cela présente plusieurs avantages :
- la résolution se fait au plus près (au sens métrique du protocole de routage utilisé) de l'utilisateur, ce qui réduit les temps de réponse;
- les attaques par déni de service sont plus difficiles, car il faut que toutes les attaques viennent d'une même zone, sinon elles sont réparties sur plusieurs serveurs;
- le nombre d'adresses à connaître par les résolveurs est limité.
Le mécanisme de transition 6to4 utilise également cette technique. Le préfixe 192.88.99.0/24 correspondant à des extremités de tunnels (192.88.99.1) et donnant accès à l'Internet v6 est annoncé a plusieurs endroits dans le réseau. Cela permet de préconfigurer les équipements avec cette adresse et d'offrir à l'utilisateur l'extrémité de tunnel la plus proche. En cas de disparition de celle-ci, le routage de l'Internet aiguillera automatiquement vers un autre équipement tunnelier.
Ce mécanisme fonctionne de la même manière avec les adresses IPv6. L'exemple suivant l'illustre avec les adresses IPv6 d'un serveur DNS. Vu depuis la France et le réseau de Renater, la route pour atteindre cette machine est la suivante :
%traceroute6 2001:500:2f::f traceroute6 to 2001:500:2f::f (2001:500:2f::f) from 2001:660:7301:3103:223:6cff:fe97:679c, 30 hops max, 12 byte packets 1 2001:660:7301:3103::1 4.774 ms 1.198 ms 2.764 ms 2 2001:660:7301:3036::1 3.364 ms 2.215 ms 1.417 ms 3 vl856-gi9-9-rennes-rtr-021.noc.renater.fr 2.892 ms 6.794 ms 2.195 ms 4 te4-1-caen-rtr-021.noc.renater.fr 7.706 ms 5.1 ms 4.193 ms 5 te4-1-rouen-rtr-021.noc.renater.fr 6.527 ms 6.296 ms 6.661 ms 6 te0-0-0-1-paris1-rtr-001.noc.renater.fr 8.702 ms 10.26 ms 8.696 ms 7 F-root-server.sfinx.tm.fr 8.495 ms 8.607 ms 8.664 ms 8 f.root-servers.net 8.738 ms 9.171 ms 8.702 ms
Comme l'indique ce traceroute, la machine est localisée au sfinx (nœud d'échange de trafic Internet situé en France).
Un traceroute vers la même destination depuis une machine localisée aux États-Unis (Hawaï) donne le résultat suivant :
traceroute6 to 2001:500:2f::f (2001:500:2f::f) from 2001:1888:0:1:2d0:b7ff:fe7d:bed6, 64 hops max, 12 byte packets 1 apapane-fe0-0-1 1.169 ms 0.970 ms 0.947 ms 2 r1.mdtnj.ipv6.att.net 121.159 ms 121.737 ms 121.378 ms 3 bbr01-p1-0.nwrk01.occaid.net 130.468 ms 129.640 ms 130.845 ms 4 bbr01-g1-0.asbn01.occaid.net 131.372 ms 131.596 ms 131.421 ms 5 bbr01-g1-0.atln01.occaid.net 144.937 ms 144.550 ms 144.834 ms 6 bbr01-p1-0.dlls01.occaid.net 166.709 ms 196.177 ms 165.983 ms 7 dcr01-p1-5.lsan01.occaid.net 138.437 ms 138.690 ms 138.544 ms 8 bbr01-g0-2.irvn01.occaid.net 138.552 ms 137.956 ms 137.649 ms 9 dcr01-g1-2.psdn01.occaid.net 137.629 ms 138.030 ms 141.332 ms 10 bbr01-f1-5.snfc02.occaid.net 138.501 ms 138.511 ms 137.483 ms 11 exit.sf-guest.sfo2.isc.org 147.941 ms 144.929 ms 145.956 ms 12 f.root-servers.net 139.063 ms 139.715 ms 142.571 ms
Le serveur se trouve dans les locaux de l'ISC.
Adresses anycast sur un même lien
Le deuxième type d'adresses anycast correspond à l'allocation de plusieurs adresses identiques sur le même lien. Cette méthode est plus complexe à gérer, car normalement, IPv6 va tester qu'une adresse n'est pas déjà présente grâce au mécanisme de détection d'adresses dupliquées (DAD). Comme rien ne distingue une adresse anycast d'une adresse unicast, il faut désactiver la détection d'adresses dupliquées en précisant anycast lors de l'affectation de l'adresse à l'interface. Comme le montre l'exemple suivant :
# ifconfig en3 en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::223:6cff:fe97:679c%en3 prefixlen 64 scopeid 0x5 inet 192.168.103.177 netmask 0xffffff00 broadcast 192.168.103.255 inet6 2001:660:7301:3103:223:65ff:fe97:679c prefixlen 64 autoconf ether 00:23:6c:97:67:9c media: autoselect status: active supported media: autoselect # ifconfig en3 inet6 2001:660:7301:3103:FF::FF anycast # ifconfig en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::223:6cff:fe97:679c%en3 prefixlen 64 scopeid 0x5 inet 192.168.103.177 netmask 0xffffff00 broadcast 192.168.103.255 inet6 2001:660:7301:3103:223:65ff:fe97:679c prefixlen 64 autoconf inet6 2001:660:7301:3103:ff::ff prefixlen 64 anycast ether 00:23:6c:97:67:9c media: autoselect status: active supported media: autoselect
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. Peut-être que les réseaux de capteurs pourraient permettre une utilisation à plus grande échelle de l'anycast. Ainsi, à une question comme « quelle est la température de la pièce ? » le premier capteur pouvant répondre à la question enverra la réponse tandis que les autres capteurs pourraient demeurer silencieux.
La figure « Adresses Anycast » 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 vues 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.
Figure : Adresses Anycast
Comme les adresses de type anycast sont allouées dans le même espace d'adressage que l'unicast, elles sont créées en attribuant une même adresse unicast à des nœuds 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 unicast 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.
| Description | Valeur(hexadécimal) |
|---|---|
| Réservé | 0x7F |
| Adresse Anycast de l'agent mère (cf.Mobilité dans IPv6) | 0x7E |
| Réservé | 0x00 à 0x7D |
On peut remarquer que l'usage des l'anycast n'est pas généralisé puisqu'une seule valeur a été définie et correspond à l'agent mère pour IPv6 mobile. Cela pourrait changer avec l'introduction d'IPv6 dans les réseaux de capteurs. En effet, un des intérêts de l'adressage anycast est de désigner une fonction plus qu'une machine particulière. Avec les réseaux de capteur, on s'interesse plus à une information qu'à l'équipement qui a permis de l'obtenir, par exemple si des capteurs sont interrogés sur la température d'une pièce, le premier à donner l'information peut être suffisant.
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 « Anycast sur le 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.
Figure : Anycast sur le lien
Contraintes de l'Anycast
Comme le correspondant peut varier soit en cas de modification du routage ou de la table de résolution d'adresse, il ne peut pas y avoir d'états. L'Anycast doit être limité à des requêtes simples de type question/réponse ou la gestion de tunnels (bien que cela puisse entraîner un déséquencement). De même les protocoles de niveau 4 orientés connexion comme TCP ne peuvent pas être utilisés.
| |
Mises en Oeuvre | Table des matières | Problèmes de Recherche | |
