http://www.bortzmeyer.org/6540.html

----------------------------

Auteur(s) du RFC: W. George (Time Warner Cable), C. Donley (Cablelabs), C. 
Liljenstolpe (Telstra), L. Howard (Time Warner Cable)

Chemin des normes

----------------------------


Il y a plusieurs façons de présenter ce RFC qui décrète que toute 
machine IP doit être capable de faire de l'IPv6. Le meilleur angle, je 
trouve, est de dire que c'est un RFC contre la publicité mensongère : 
dans l'Internet d'aujourd'hui, IP ne veut plus seulement dire IPv4. 
Vendre une machine ou un logiciel comme étant capable de parler IP, 
alors qu'elle ou il ne fait pas d'IPv6 est mensonger.

Bien sûr, en pratique, il est peu probable que ce RFC change 
grand'chose : les vendeurs continueront à fourguer des produits 
incapables de parler IPv6, protocole pourtant normalisé depuis seize 
ans, avec la sortie du RFC 1883 (depuis remplacé par le RFC 2460). 
Mais, au moins, ils ne pourront plus dire qu'il y avait une ambiguité 
et que certains RFC anciens parlent de « IP » pour désigner IPv4. 
Désormais, il est clair que « IP » veut dire IPv6 et (bien que le RFC 
ne le spécifie pas), si on est seulement IPv4, cela doit être annoncé 
comme tel et non pas sous l'étiquette « IP ».

Le succès d'IPv4 est incontestable. Il est désormais déployé absolument 
partout, malgré les vigoureuses oppositions des telcos traditionnels, 
relayés par pas mal de gouvernements (souvenez-vous des ridicules 
campagnes de promotion de l'ATM, censé barrer la route à IP). Mais 
c'est ce succès même qui a condamné IPv4. Le stock d'adresses 
disponibles est désormais épuisé 
<http://www.bortzmeyer.org/epuisement-adresses-ipv4.html>. Un certain 
nombre de techniques ont été développées par acharnement 
thérapeuthique, pour essayer de gagner encore quelques années, comme le 
NAT444 <http://www.bortzmeyer.org/nats.html>. Toutes ont de sérieux 
inconvénients (cf. RFC 6269 pour un exemple).

La solution correcte, qui évite de fragiliser l'Internet par 
l'empilement de techniques de transition et/ou de coexistence 
<http://www.bortzmeyer.org/transition-ipv6-guilde.html> est donc de 
déployer IPv6. Mais cela ne s'est 
pas fait tout seul. L'absence, ou la mauvaise qualité, de mise en &#339;uvre 
d'IPv6 dans les logiciels a longtemps retardé ce protocole. Beaucoup de 
fournisseurs de logiciels se sont comportés comme si « IP » se 
réduisait à IPv4, IPv6 étant une addition possible mais facultative. 
Pendant de nombreuses années, Cisco exigeait une licence supplémentaire 
payante pour l'activation d'IPv6 dans IOS... Bref, des engins étaient 
vendus comme « IP » alors qu'ils n'étaient qu'« IPv4 ». Le problème 
continue aujourd'hui, empêchant la migration de progresser.

C'est particulièrement gênant dans le domaine des équipements proches 
du consommateur : ce dernier, à juste titre, ne se soucie pas de la 
version du protocole IP installé. IPv6 a été conçu justement pour ne 
pas changer le modèle de fonctionnement d'IP et il n'y a donc aucun 
avantage, pour M. Toutlemonde, à migrer vers IPv6. La migration, 
décision technique, ne devrait pas dépendre d'un choix explicite du 
consommateur, surtout si on le fait payer pour cela, comme le faisait 
Cisco. La migration devrait se faire au fur et à mesure que les 
vieilles machines et vieux logiciels sont remplacés, sans que M. 
Toutlemonde ne s'en rende compte.

À la décharge des vendeurs, il faut noter que tous les RFC, même ceux 
encore en vigueur, ne sont pas clairs là-dessus. Par exemple, le RFC 
1812, qui établit les règles pour les routeurs IPv4, utilise souvent le 
terme IP pour désigner IPv4. Même chose pour le RFC 1122, qui normalise 
les machines terminales et ne mentionne pas IPv6. Aujourd'hui, le terme 
« IP », dans un RFC, peut indiquer IPv4 seul, IPv6 seul ou bien les 
deux.

À noter qu'IPv6 a aussi ses RFC de résumé des exigences, comme les RFC 
4294 et RFC 6204.

La section 2 de notre RFC pose donc la règle : « IP implique IPv6 ». 
Plus précisément :
* Les nouvelles mises en &#339;uvre d'IP (ou les mises à jour majeures) 
doivent inclure IPv6.
* La qualité du support IPv6 doit être égale ou supérieure à celle 
d'IPv4. On en est très loin aujourd'hui : poussés par des cahiers des 
charges qui exigent IPv6, certains vendeurs ajoutent un support 
minimum, permettant de cocher la case « IPv6 » lors de la réponse à un 
appel d'offres, mais en fournissant du logiciel bogué et lent.
* L'activation ou la configuration d'IPv4 ne doit pas être nécessaire.
Évidemment, ce n'est qu'un RFC. Bien des vendeurs l'ignoreront. 
Espérons toutefois qu'il contribuera à une meilleure information des 
consommateurs.

Ce document était loin d'être consensuel à l'IETF. Beaucoup de gens 
critiquaient le principe même d'un document d'exhortation, qui risque 
fort de n'être qu'un rappel de plus. Toutefois, les partisans de ce 
document étaient actifs et les opposants ne voyaient pas 
d'inconvénients graves à la publication.

_______________________________________________
G6 -- Association Francophone pour la promotion d'IPv6 (http://www.g6.asso.fr)
Liste forumIPv6 forumIPv6@g6.asso.fr
Info : http://mail.g6.asso.fr/mailman/listinfo/forumipv6
Merci de rediriger les discussions techniques vers la liste ipv6tech.

Répondre à