Lancement officiel d'ipv6 le 6 juin 2012

[quote=“tetrix”]@ricardo, j’ai cherché à en savoir un peu plus sur la question :wink:
L’article que j’ai trouvé (il date un peu), me semble assez complet, parmi les avantages, ils indiqueraient la disparirion des vers…
certa.ssi.gouv.fr/site/CERTA … F-004.html
[/quote]
Merci, je lirai ça à tête reposée

Salut,

[quote=“Pourquoi IPv6 ?”]IP v4 montre ses limites devant l’accroissement énorme de la demande d’adresses sur l’internet :

Le gaspillage d'adresses induit par la notion de classes a déjà été en partie résolu avec CIDR, mais ne répond pas à l'accroissement prévisible de la demande ;

l'historique de la distribution des adresses a créé une parcellisation des blocs d'adressages qui contraint les routeurs à avaler des tables de routage interminables, ce qui ralentit leurs performances et nécessite des ressources matérielles sans cesse croissantes.

Alors qu’aujourd’hui, en France, environ 50% des foyers sont connectés et disposent d’une seule adresse IPv4, l’avenir laisse imaginer qu’un jour plus ou moins proche, chaque foyer disposera de plusieurs dizaines d’objets potentiellement connectables à l’internet et que les technologies palliatives telles que NAT ne répondront plus au besoin.

Les pays « émergeants » sont de plus en plus demandeurs, non seulement de ressources énergétiques fossiles, mais aussi d’adresses IP. Pour l’énergie fossile, le problème est délicat. Il l’est aussi pour les adresses IP, mais un protocole est plus facile et surtout plus rapide à élaborer que du pétrole, du gaz ou du charbon.

Une recherche de solution a été initiée en 1990 et a débouché en 1994 sur le choix d’IPv6. Ce n’est donc pas à proprement parler une nouveauté, bien que ce protocole soit encore en phase d’expérimentation.[/quote]

[quote=“Comment IPv6 ?”]Nous allons nous donner comme objectif de réaliser un réseau local connecté à l’internet, utilisant IPv6 tel que mis à disposition par le fournisseur Free. D’autres solutions sont possibles bien sûr.

Ce réseau local est constitué de postes de travail équipés de GNU/Linux (Ubuntu « Hardy Heron », Debian « Etch » ou « Lenny »). Une passerelle (Debian Etch) assure le routage NAT en IPv4 vers l’internet via une « FreeBox » dont les fonctions de routeur ne sont pas activées. Nous aurions pu bien évidemment choisir l’option de la simplicité, en utilisant tout bonnement les fonctions de routeur IPv4 de la Freebox, mais où aurait été le plaisir ?

L’objectif est d’arriver à ce que chaque station du LAN puisse disposer d’une adresse IPv6 « publique » et que donc, chaque station puisse accéder et être jointe directement par d’autres nœuds de l’internet.

Comme nous sommes encore loin de disposer d’un internet « full IPv6 », il nous faudra fonctionner en mode hybride, IPv4 avec NAT et IPv6.
[/quote]
Source.

[code]$ host -t aaaa www.isalo.org
www.isalo.org is an alias for isalo.org.
isalo.org has IPv6 address 2001:41d0:8:a6d::

$ ping6 www.isalo.org
PING www.isalo.org(2001:41d0:8:a6d::slight_smile: 56 data bytes
From vss-6a-6k.fr.eu icmp_seq=1 Destination unreachable: Address unreachable
[/code]
Address unreachable = cette adresse ne répond pas sur le réseau

  1. Tu es sûr que le préfixe IPv6 alloué à ton serveur est bien 2001:41d0:8:a6d::/64 ?
  2. Tu as configuré l’interface de ton serveur avec cette adresse (et mis l’adresse de passerelle qui va bien) ?
  3. La première adresse d’un préfixe <préfixe>:: est réservée comme l’adresse anycast du réseau (gérée de façon particulière par les routeurs IPv6 de ce réseau), il vaut mieux éviter de l’affecter à une machine et utiliser une autre adresse comme <préfixe>::1.

[code]$ host -t aaaa www.isalo.org
www.isalo.org is an alias for isalo.org.
isalo.org has IPv6 address 2001:41d0:8:a6d::

$ ping6 www.isalo.org
PING www.isalo.org(2001:41d0:8:a6d::slight_smile: 56 data bytes
From vss-6a-6k.fr.eu icmp_seq=1 Destination unreachable: Address unreachable
[/code]
Address unreachable = cette adresse ne répond pas sur le réseau

  1. Tu es sûr que le préfixe IPv6 alloué à ton serveur est bien 2001:41d0:8:a6d::/64 ?
  2. Tu as configuré l’interface de ton serveur avec cette adresse (et mis l’adresse de passerelle qui va bien) ?
  3. La première adresse d’un préfixe <préfixe>:: est réservée comme l’adresse anycast du réseau (gérée de façon particulière par les routeurs IPv6 de ce réseau), il vaut mieux éviter de l’affecter à une machine et utiliser une autre adresse comme <préfixe>::1.[/quote]

Salut,
Oui, c’est l’adresse donnée par OVH dans le “manager”.
Concernant le point 3, oui je m’étais trompé et j’avais utilisé cette adresse. Je ne savais pas qu’un ipv6 se “déclinait” à partir de l’anycast.

J’ai configuré mon interface comme suit:

iface eth0 inet6 static address 2001:41d0:8:a6d::1 netmask 64 gateway 2001:41d0:8:aFF:FF:FF:FF:FF post-up /sbin/ifconfig eth0 inet6 add 2001:41d0:8:a6d::1 pre-down /sbin/ifconfig eth0 inet6 del 2001:41d0:8:a6d::1
Par contre le ping était désactivé hier soir… Je viens de l’autoriser.

# ip6tables -S -P INPUT DROP -P FORWARD DROP -P OUTPUT ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p ipv6-icmp -m limit --limit 1/sec --limit-burst 1 -j ACCEPT -A INPUT -p ipv6-icmp -j DROP -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -j LOG

Dans le DNS j’ai ça:
.isalo.org AAAA 2001:41d0:8:a6d::1

Apache2 écoute bien:

netstat -6tlnp Connexions Internet actives (seulement serveurs) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name tcp6 0 0 :::80 :::* LISTEN 9999/apache2 ... tcp6 0 0 :::443 :::* LISTEN 9999/apache2
J’ai configuré le vhost:

<VirtualHost [2001:41d0:8:a6d::1]:80>

Par contre je ne comprend pas pourquoi sur certaine machine j’obtient avec un nslookup:
isalo.org has AAAA address 2001:41d0:8:a6d::1
et sur une autre (pas le même serveur DNS)
isalo.org has AAAA address 2001:41d0:8:a6d::

J’ai ajouté le “1” hier soir. Ça devrait être pris en compte maintenant. :017

Je ne comprends pas ce que tu veux dire par “se déclinait”. Simplement la première adresse d’un réseau IPv6 (avec des zéros dans la partie hôte à droite du préfixe) est particulière. On peut la comparer à l’adresse de réseau en IPv4 qui est aussi réservée, bien que leur rôle soit différent. Mais je ne suis pas certain que le problème venait de là.

Note : les options post-up et pre-down pour configurer l’adresse IPv6 d’eth0 ne devraient pas être nécessaires, elles font doublon avec l’option address.

Et le ping6 fonctionne, le site est accessible en IPv6.
En fait tu as autorisé tout l’ICMPv6 et pas seulement le ping, et avec limite.
Si tu avais auparavant interdit tout l’ICMPv6, alors cela explique l’erreur que j’avais rapportée : elle ne concerne pas le ping mais le sous-ensemble de types ICMPv6 indispensables qui remplacent le protocole ARP en IPv6 et constituent le protocole “neighbour discovery” (et ne sont pas gérés par le suivi de connexion car c’est du multicast) : neighbour solicitation, neighbour advertisement, router solicitation, router advertisement. Par contre la limitation à 1 par seconde est à mon avis beaucoup trop restrictive. Tu limiterais les paquets ARP à 1 par seconde ?

L’enregistrement DNS est défini avec un TTL de 24 heures. Cela veut dire que l’ancienne valeur dans les caches des serveurs DNS récursifs qui avaient fait la requête avant ton changement expire au bout de 24 heures. Chez moi, le TTL restant est de plus de 6 heures, je devrai donc attendre ce délai avant de voir la nouvelle adresse.

Salut. Oui, enfin!!! :smiley:

IPv6 validation for isalo.org
IPv6 validation for wiki.debian-fr.org (redirection faite par Ed)

Je ne comprends pas ce que tu veux dire par “se déclinait”[/quote]

[quote=“OVH”]Une IPv4 :
213.186.35.9/24

devient l’ IPv6 suivant:
2001:41d0:1:209::/64

Voici des exemples d’IPv6 que l’on peut configurer sur ce serveur dédié :

2001:41d0:1:209::1/64
2001:41d0:1:209:FF:FF:FF:FF/64
2001:41d0:1:209:A::1:1/64
2001:41d0:1:209::1:B:F/64
2001:41d0:1:209:1:1:1:1/64[/quote]

J’ai ajouté le 1, sans ça ça ne fonctionnait pas. Si j’ai bien compris, je peux avoir 2, 4…

Pareil, j’ai aapliqué ce que préconise OVH. Je vais virer ces lignes si ça ne sert à rien.

Et le ping6 fonctionne, le site est accessible en IPv6.
En fait tu as autorisé tout l’ICMPv6 et pas seulement le ping, et avec limite.
Si tu avais auparavant interdit tout l’ICMPv6, alors cela explique l’erreur que j’avais rapportée : elle ne concerne pas le ping mais le sous-ensemble de types ICMPv6 indispensables qui remplacent le protocole ARP en IPv6 et constituent le protocole “neighbour discovery” (et ne sont pas gérés par le suivi de connexion car c’est du multicast) : neighbour solicitation, neighbour advertisement, router solicitation, router advertisement. Par contre la limitation à 1 par seconde est à mon avis beaucoup trop restrictive. Tu limiterais les paquets ARP à 1 par seconde ?[/quote]Non évidemment, je rectifie aussi.

Merci beaucoup!
Le Wiki est accessible en ipv6… Je vais basculer tous mes autres sites.

Il y a quand même un détail qui me chiffonne dans ta configuration IPv6 : l’adresse de passerelle par défaut 2001:41d0:8:aFF:FF:FF:FF:FF dans l’option “gateway” est en dehors du préfixe 2001:41d0:8:a6d::/64 de l’interface. Tu pourrais donner la sortie de “ip -6 addr” et “ip -6 route” stp ?

Salut,

J’ai suivi les recommendation de OVH pour la passerelle. J’avoue ne pas comprendre comment ipv6 fonctionne…

[quote]Le routeur (gateway par défaut) pour chaque IPv6 se trouve toujours sur IP:v:6:FF:FF:FF:FF:FF
Un exemple:

L’ IPv6 du serveur: 2001:41D0:1:46e::/64 devient 2001:41D0:1:4 + 5 fois FF.
Gateway ipv6: 2001:41D0:1:4FF:FF:FF:FF:FF

L’ IPv6 du serveur: 2001:41d0:1:209::/64 devient donc 2001:41d0:1:2 + 5 fois FF.
Gateway ipv6: 2001:41d0:1:2FF:FF:FF:FF:FF[/quote]

Voici les sorties des commandes:

ip -6 addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2001:41d0:8:a6d::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::3a60:77ff:fe2f:d653/64 scope link valid_lft forever preferred_lft forever ip -6 route 2001:41d0:8:a6d::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 2001:41d0:8:a00::/56 dev eth0 proto kernel metric 256 expires 0sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 default via fe80::5:73ff:fea0:0 dev eth0 proto kernel metric 1024 expires 0sec mtu 1500 advmss 1440 hoplimit 64

Je m’en doutais. Le routeur envoie des messages ICPMv6 RA (router advertisement) pour annoncer son adresse link local (fe80::5:73ff:fea0:0) avec laquelle ton serveur crée la route par défaut, ainsi que le préfixe 2001:41d0:8:a00::/56, qui contient bien l’adresse 2001:41d0:8:aFF:FF:FF:FF:FF. C’est donc grâce à l’autoconfiguration sans état à partir des RA (activée par défaut sur Linux s’il n’est pas configuré en routeur IPv6) que la connectivité IPv6 de ton serveur fonctionne. Sans cela, en configuration totalement statique, il manquerait la création de la route vers 2001:41d0:8:a00::/56 dans les instructions d’OVH. D’ailleurs on peut voir dans la table de routage que l’option gateway du fichier interfaces n’a pas été prise en compte puisqu’on n’y retrouve pas l’adresse 2001:41d0:8:aFF:FF:FF:FF:FF en tant que passerelle, la seule route par défaut est celle apprise par autoconfiguration.

PS : comme prévu l’ancienne adresse IPv6 d’isalo.org a expiré du cache de mon serveur DNS, je vois la nouvelle adresse maintenant (et le site en IPv6).

Re,
Merci de l’explication. Très belle démonstration… Un des nombreux avantages de l’ipv6 ?
Je laisse le “gateway” tel qu’il est ou je met le réel qui s’est autoconfiguré (fe80::5:73ff:fea0:0) ?

L’option gateway telle qu’elle est ne sert à rien puisqu’il n’y a pas (encore) la route vers le préfixe /56 correspondant. Pour le coup il faudrait utiliser des options post-up pour créer la route vers le /56 et la route par défaut avec l’adresse de la passerelle dans le /56.

Par contre j’éviterais de mettre des adresses link-local unicast (en fe80::slight_smile: dans une configuration en dur car ces adresses sont calculées à partir de l’adresse MAC de l’interface sur laquelle elles sont configurées et sont susceptibles de varier en cas de changement dudit matériel (en clair si OVH change son routeur).

Autant laisser l’autoconfiguration faire le travail puiqu’elle le fait bien.
Risque : si un serveur dans le même réseau que le tien s’amuse à envoyer des RA sauvages, cela peut perturber la connectivité IPv6 de tous les autres serveurs en autoconf du réseau.

Bien,
Merci pour les précisions. Je crois qu’il va falloir que je potasse sérieusement…
Je laisse donc l’autoconfiguration, je fais confiance à OVH pour l’instant pour surveiller leur réseau.
Quand je serais plus a l’aise avec ces histoires je configurerais moi même le gateway avec post-up ip route add default.

Tu as un lien qui serait accessible pour essayer de comprendre un peu mieux ipv6 ?
Je commence par wikipedia… :blush:

[quote]ipv6 = 667 millions de milliards d’adresses IP disponibles par mm2 de la surface de la Terre[/quote]Ça fait une chiée quand même… :005

La question qui tue…
J’utilise IPv6 depuis si longtemps, 2004 de mémoire, j’ai beaucoup lu (y compris des RFC) et expérimenté (merci Linux), au point qu’IPv6 m’est devenu aussi familier et naturel qu’IPv4, et j’ai peur de ne pas être capable d’avoir conscience des difficultés qu’éprouvent ceux qui s’y confrontent pour la première fois. En tout cas il n’y a pas une documentation particulière qui m’aurait marqué au point que je m’en souvienne.

Allez, j’ai quand même retrouvé http://livre.g6.asso.fr/ dans mes signets.
Et pour les aspects plus spécifiques à GNU/linux, le Linux IPv6 Howto sur TLDP
http://tldp.org/HOWTO/Linux+IPv6-HOWTO/index.html

[quote=“PascalHambourg”]La question qui tue…[/quote] :064

Merci pour les liens.
C’est vrai que ça aurait mérité notre attention plus tôt, nous ne serions pas des tanches aujourd’hui, mais il n’y avait pas urgence…
Aujourd’hui, si j’ai bien compris, ça va devenir critique (plus d’ipv4 d’ici la fin de l’année); Il n’y a donc pas d’autre choix que de s’y mettre.

Par contre je suis un peu étonné, toutes les applications (je pense par exemple à fail2ban) ne supportent pas ipv6…
Il va falloir faire rapidement un inventaire de ce qui tourne sur nos machines et faire le ménage.

Je crois qu’il conviendrait d’ajouter “plus d’IPv4 … pour les nouvelles connexions”, non ?
Les anciennes vont continuer de tourner, il me semble ???

Surtout, pas facile de s’y intéresser tant qu’on n’a pas de connexion IPv6 chez soi ou au travail. J’ai bénéficié du fait que mon FAI le propose depuis longtemps pour m’y intéresser. Mais ce n’était pas le cas des FAI grand public pendant longtemps, et d’un grand nombre d’entreprises encore.

Quant à l’urgence, je ne sais pas si elle est vraiment plus grande qu’il y a un an. Certes les derniers blocs /8 ont été distribués aux RIR, mais ceux-ci n’ont pas encore tout alloué, et les bénéficiaires de ces allocations (dont les FAI) n’ont pas encore attribué toutes leurs adresses non plus.

Je le redis encore et toujours : pour moi la pénurie d’adresses IPv4 a commencé lorsque des gens ont eu plus de machines à connecter à internet (en pratique : plus d’une) que d’adresses IP publiques attribuées par leur FAI (en pratique : une seule). Or la plupart d’entre nous, moi y compris, ont toujours connu cette situation.

S’il n’y avait pas eu pénurie, les adresses IPv4 publiques n’auraient pas été considérées comme une ressources précieuse (car virtuellement ça ne coûte rien, ce n’est pas comme le pétrole qu’il faut extraire et raffiner) à économiser et on en aurait distribué autant que nécessaire comme actuellement les adresses IPv6 globables qu’on distribue par milliards.

[quote=“ricardo”]Je crois qu’il conviendrait d’ajouter “plus d’IPv4 … pour les nouvelles connexions”, non ?
Les anciennes vont continuer de tourner, il me semble ???[/quote]
Te fais pas de billes. Les FAI on des pools d’adresses IPv4 publiques pour pouvoir en donner et au pire, elles peuvent faire du nat444, c’est à dire que l’adresse ipv4 qui sort de ta boxe est encore une adresse ipv4 privée. Ils peuvent même faire du nat46 c’est à dire que tu utilise de l’IPv4 partout et eux te file une IPv6 juste avant que tu quitte leur réseau (par contre si ce genre de solution sont utilisé (en dernier recours donc pas en fin d’année)), ton autohébergement deviendras compliqué (s’il reste possible ce qui n’est pas certain).

Pour l’instant, je pense que je ne vais toucher à rien car aucun des avantages ne m’a convaincu.
Maintenant, si je ne peux plus m’autohéberger, je tranférerai tout sur mon ancien site Free.