XMLfr : l'espace XML francophone

Le 8 février, l'avis VU#800113 du CERT a révélé publiquement une faille du protocole DNS. Cette faille permet un empoisonnement relativement facile des caches DNS.

On peut trouver un bon résumé dans l'article Fixes Released for Massive Internet Security Issue. L'attaque a été découverte par Dan Kaminsky et repose sur une vulnérabilité classique du DNS. Le résolveur DNS (serveur récursif) accepte en effet une réponse si la question posée, le Query ID (RFC 1035, section 4.1.1) et le port UDP où arrive la réponse coïncident avec une question en attente. Mais Kaminsky a découvert un mécanisme pour envoyer une fausse réponse ayant de très bonnes chances d'être acceptée. (Le mécanisme détaillé n'est pas encore publié, il le sera en août.) Indépendamment de cette atatque spécifique, il faut noter que la vulnérabilité est connue depuis longtemps (voir par exemple l'article DNS and BIND Security Issues de Paul Vixie qui dit With only 16 bits worth of query ID and 16 bits worth of UDP port number, it's hard not to be predictable. A determined attacker can try all the numbers in a very short time and can use patterns derived from examination of the freely available BIND code. Even if we had a white noise generator to help randomize our numbers, it's just too easy to try them all.) C'est pour cela que certains résolveurs ne sont pas vulnérables (ils mettaient en œuvre des mécanismes de défense depuis longtemps).

Depuis le site Web de l'auteur de la découverte, on peut tester la vulnérabilité de son résolveur. Mais ledit site Web est très chargé et le code Javascript bogué. Si on veut tester via le Web, il faut mieux utiliser https://www.dns-oarc.net/oarc/services/dnsentropy. Si on préfère tester en local, une bonne solution est le script de Michael C. Toren :

%  perl noclicky-1.00.pl 192.0.2.225
Looking up zqq0wi2odh5x.toorrr.com against 192.0.2.225
Fetching http://209.200.168.66/fprint/zqq0wi2odh5x
Requests seen for zqq0wi2odh5x.toorrr.com:
  192.0.2.225:32769 TXID=2234
  192.0.2.225:32769 TXID=22512
  192.0.2.225:32769 TXID=17521
  192.0.2.225:32769 TXID=32880
  192.0.2.225:32769 TXID=40914
Your nameserver appears vulnerable; all requests came from the same port.

Et une autre solution pour tester la vulnérabilité de son serveur récursif, ne nécessitant que le traditionnel dig, est de demander à  :

%  dig +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"192.0.2.248 is POOR: 26 queries in 4.5 seconds from 1 ports with std dev 0.00                 "

Les logiciels peuvent diminuer leur vulnérabilité en utilisant un port source UDP aléatoire. C'est ce que font toutes les mises à jour qui viennent d'être publiées (voir par exemple communiqué de l'ISC). Le seul fait de choisir le Query ID au hasard est nécessaire mais pas suffisant (il ne fait que 16 bits de large). Certains résolveurs comme PowerDNS ou bien Unbound avaient déjà ce mécanisme et n'étaient donc pas vulnérables (pour Unbound, voir leur analyse complète et aussi celle de PowerDNS).

Attention : il ne suffit pas de faire la mise à jour du logiciel, encore faut-il tester que la configuration du serveur de noms ne force pas l'usage d'un port unique. C'est par exemple un problème possible avec BIND si le fichier named.conf contient une ligne du genre query-source port 53;. Cette ligne, qui force l'usage d'un port unique annule tout l'effet du patch correctif ! (Et c'est détecté par les tests ci-dessus.)

Ces méthodes sont décrites dans un Internet-Draft nommé Measures for making DNS more resilient against forged answers.

Les systèmes comme Debian ou Gentoo ont très vite intégré les patches et la mise à jour normale suffit donc.

On peut noter que ce patch peut perturber certains coupe-feux, qui s'étonneraient des réponses arrivant à un grand nombre de ports. Par exemple, il semble que Zone Alarm sur Windows XP proteste et qu'il faille passer son niveau de sécurité à Medium si la machine fait tourner un BIND sécurisé (voir http://www.pcinpact.com/actu/news/44747-zonealarm-windows-dns-internet-probleme.htm et http://www.zdnet.fr/actualites/informatique/0,39040745,39382271,00.htm.

Comme le rappelle le communiqué de l'ISC cité plus haut, la solution idéale est de passer à DNSSEC (RFC 4033, RFC 4034 et RFC 4035). Mais c'est une opération très lourde, nécessitant des mise à jour des logiciels, l'action des registres, celle des gérants de résolveurs, etc. Et DNSSEC apporte ses propres vulnérabilités et la complication de gestion qui est associé aux systèmes utilisant la cryptographie. Réclamer son déploiement est donc assez yakafokon.

Parmi les bonnes lectures sur le sujet, citons http://sid.rstack.org/blog/index.php/283-dns-dns-dns, http://bruno.kerouanton.net/blog/2008/07/10/vous-avez-fini-de-patcher-ssh-patchez-vos-dns/ ou http://david.monniaux.free.fr/dotclear/index.php/2008/07/13/229-trou-du-dns.

Lorsqu'un système connecté à Internet a plusieurs adresses IP, la question de savoir laquelle utiliser comme source se pose. Si ce système dispose d'adresses IP de familles différentes, par exemple IPv4 et IPv6, la question de la sélection de l'adresse de destination peut également survenir. Le RFC 3484 décrivait un mécanisme pour cette sélection, mais qui a posé des problèmes en pratique, problèmes que décrit notre RFC.

Le RFC 3484 est par exemple mis en œuvre dans le système GAI (à noter que ce système est très peu documenté) de la GNU libc (utilisée dans des systèmes comme Gentoo ou Debian). Ce système se configure via le fichier /etc/gai.conf et permet d'avoir des politiques comme « Privilégier systématiquement les adresses IPv6 » ou bien « Préferer IPv4 sauf pour tels préfixes ». C'est l'expérience avec des systèmes analogues (sur FreeBSD, c'est /etc/ip6addrctl.conf) qui a donné naissance au travail actuel sur le successeur du RFC 3484, travail dont notre RFC 5220 décrit les motivations et dont le RFC 5221 donne le cahier des charges pour le prochain mécanisme.

La section 2 forme l'essentiel de notre RFC, en listant successivement plusieurs cas concrets et les solutions - ou l'absence de solution - que leur apporte le RFC 3484. La section 2.1.1, par exemple, analyse le cas où il y a deux routeurs sur le même lien. La sélection du premier routeur à utiliser ne dépendant typiquement pas de l'adresse IP source, un site connecté à deux FAI va avoir des problèmes puisque les paquets pourront être envoyés au « mauvais » routeur, celui connecté à un autre FAI que celui qui a attribué l'adresse source choisie (le cas de la section 2.1.2 est similaire et montre un FAI qui met en œuvre le RFC 2317, éliminant ainsi les paquets IP malchanceux).

La section 2.1.3 décrit par contre un cas qui peut être résolu par le RFC 3484, contrairement aux deux précédents. La machine y est connectéé à l'Internet via un FAI et à un réseau privé, utilisant par exemple des adresses IP locales (RFC 4193). Dans ce cas, il suffit de donner la priorité aux adresses globales. Si le préfixe global est 2001:db8:1000::/48 et que le préfixe du réseau privé est 2001:db8:8000::/48, les règles suivantes dans gai.conf donneront le résultat attendu :

# Tout l'Internet
precedence  ::/0          40
# Le réseau privé, à n'utiliser que si le destinataire est dans ce réseau privé,
# grâce à la règle "longest matching rule" du RFC 3484, section 5,
# règle 8. On lui met une précédence plus faible.
precedence 2001:db8:8000::/48    20

La section 2.1.5 décrit le cas où le site change son préfixe (cf. RFC 4192) et où les machines doivent, pendant la transition, utiliser la bonne adresse source. Ce problème se résoud également dans le cadre du RFC 3484. Mais il faut noter que, le RFC en question ne spécifiant pas de mécanisme d'auto-configuration, cela nécessitera d'aller éditer le gai.conf (ou équivalent) sur toutes les machines du site, ce qui rendra le renumérotage très pénible !

La section 2.1.7 étudie le cas des adresses « vie privée » du RFC 4941. Ces adresses ayant des propriétés spécifiques, il serait préférable de choisir ou non leur utilisation par service et pas globalement et le RFC 3484 ne permet pas cela (le RFC 5014 fournit une solution possible).

La section 2.2 couvre le cas de la sélection de l'adresse destination. Par exemple, 2.2.1 étudie le cas très courant où un site est connecté nativement en IPv4 mais, compte tenu du manque de FAI IPv6, utilise un tunnel lent et peu fiable pour se connecter en IPv6. La table par défaut du RFC 3484, section 2.1, prioritise IPv6, ce qui n'est pas une bonne idée dans ce cas. Il est donc préférable de pouvoir choisir IPv4, ce qui se fait par exemple avec la ligne suivante dans /etc/gai.conf :

# Always prefer IPv4
precedence ::ffff:0:0/96  100

signalement via Lambda the Ultimate Un récent article de Mark van Atten: The Development of Intuitionistic Logic... Lire Le développement de la logique intuitionniste

Comme toute personne qui s’expose via un blog, et dont les publications ont parfois un rapport avec son activité professionnelle, je reçois des sollicitations professionnelles de toutes natures (intéressantes aussi bien que farfelues).

Comme ces sollicitations vont croissantes, je me suis dit qu’il fallait gérer tout cela. Aussitôt dit, aussitôt fait : j’ai créé un formulaire web sous Google Doc que j’ai inséré sans une page de ce blog au titre explicite : Me recruter.

Le tout m’a pris cinq petites minutes et me permettra d’éviter, je l’espère, des échanges de mail, des discussions téléphoniques et des rendez-vous parfois fastidieux. De plus, la fonction de notification de Google me permet d’être informé dès qu’une personne soumet le formulaire. Mais les recruteurs et les chasseurs de tête feront-ils l’effort de le remplir ?

On se demandait quand et comment Google offrirait des templates pour ses solutions bureautiques en ligne. C’est désormais chose faite et il y en a pour tout les goûts et pour tous les types de documents : doc, tableur, et présentation.

C’est une des stratégies plébiscitée par Apple, notamment avec sa suite bureautique iWork, de proposer et de mettre en avant des styles de documents préexistants pour facilter l’utilisation et l’adoption de ses solutions. Google a mis du temps, mais a réussi à le faire à sa sauce, c’est à dire avec une logique participative qui va commencer à se mettre en place autour de ce qui sera surement une place de marché ouverte des templates pour documents en ligne.

[Update] Par contre j’ai accès à cette fonctionnalité depuis mon compte Google gratuit mais pas dans mon compte Google Enterprise…

L'ancien modèle d'IP prévoyait seulement une adresse IP par interface réseau donc, pour la plupart des machines, une seule adresse IP tout court. Le choix de l'adresse IP à utiliser lorsque cette machine initiait une communication avec une autre machine était donc trivial. Mais ce modèle a changé, notamment avec l'arrivée d'IPv6, où la multiplicité des adresses devient la règle. Quelles adresses source et destination utiliser, dans ces conditions ? Le RFC 3484 exposait un mécanisme, qui a prouvé quelques limitations, menant à la conception d'un système amélioré dont notre RFC 5221 est le cahier des charges.

Le système du RFC 3484 a été mis en œuvre dans plusieurs systèmes d'exploitations. Par exemple, ceux utilisant la GNU libc disposent de la méthode de ce RFC et, en prime, ont /etc/gai.conf à leur disposition pour configurer manuellement le choix des adresses. Mais ce mécanisme n'est pas parfait et le RFC 5220 décrit les problèmes qu'il pose.

Le nouveau mécanisme va tenter de traiter ces problèmes, tout en gardant la possibilité d'un mécanisme totalement automatique (section 1).

La section 2 liste les onze exigences du nouveau système (je ne les cite pas toutes ci-dessous). Par exemple, 2.2 pose comme principe qu'il ne doit pas rendre la machine plus pénible à utiliser : le processus de sélection ne doit pas être long et il ne doit pas imposer une action manuelle. 2.5 exige que le mécanisme puisse être spécifique à chaque application, permettant à Firefox d'utiliser des règles différentes de celles de Thunderbird (via par exemple une API qui reste à définir). 2.7 insiste sur la nécessité pour l'administrateur système de pouvoir contrôler ce mécanisme, depuis un point central (comme /etc/gai.conf sur Debian ou Gentoo).

La sélection d'adresses IP source et destination a évidemment un impact sur la sélection du premier routeur à utiliser et ce point faisait l'objet du RFC 4191, et désormais de la section 2.8 de notre RFC.

Comme il n'est pas question de réécrire toutes les applications, le mécanisme envisagé doit évidemment être compatible avec l'API socket du RFC 3493 (section 2.9). Et, toujours sur la question de compatibilité, ce mécanisme doit marcher avec celui du RFC 3484.

Excellent résumé qui explique nombre de problèmes de performances actuels. Les applications web que l'on utilise au quotidien sont rarement critiques, il vaut mieux se concentrer sur le message (instantané lui) retourné à l'utilisateur et faire les traitements couteux en tâche de fond. Savoir gérer intelligemment ensuite les priorités est une autre histoire.

Je suis longtemps resté assis sur mon siège après la dernière image du film “Valse avec Bachir”. Les jambes coupées, l’esprit ailleurs, il m’aura fallu faire un effort pour sortir de ce voyage hypnotique. Une fois sorti de la salle de projection, il m’était impossible de parler, d’échanger quelque mot que ce soit.

Muet, comme si j’avais déjà perdu la mémoire des images que je venais de voir, tout comme le réalisateur, Ari Folman, qui se met lui même en scène dans cette oeuvre en cherchant à retrouver la mémoire des événements qu’il a vécu, il y a une vingtaine d’années, dans l’armée israélienne, pendant la guerre du Liban.

Interrogeant d’anciens camarades, des psychologues, des journalistes, l’auteur va petit à petit reconstituer le puzzle de la mémoire des événements qu’il a oublié en mettant en scène la mémoire des autres.

Car c’est par la constitution d’une mémoire collective, que l’auteur va retrouver la sienne. Magie du cinéma, ces puzzles mémoriels seront les nôtres à la fin du film. C’est aussi pour çà que l’on sort grogis de la projection, comme si nous même nous sortions d’une guerre, avec les mêmes symptômes que l’auteur au début du film. En ce sens, c’est un film qu’il est très facile d’oublier, comme l’auteur qui a oublié la guerre qu’il a fait, parce que c’est un film dont il est difficile de parler. J’ai ainsi remarqué que ceux qui étaient à la même séance que moi restaient pour la plupart silencieux, plongés dans leurs nouveaux souvenirs par procuration.

Point de discussion ni ne socialisation après le film donc, comme lorsqu’on se réveille avec un rêve qui flotte encore dans notre esprit mais dont on n’arrive pas à trouver les mots pour l’évoquer. Alors on se tait car on se sait affecté au plus profond de soi-même, dans un lieu où le langage à du mal à se frayer un chemin.

Avec une magie technologique portée par le mélange de l’image et du dessin, Ari Folman a réussi à dialoguer avec l’imagination du spectateur. L’irréel et l’hyper-réel arrivent à fusionner dans une expérience où l’on a la sensation de voir non pas la réalité mais une réalité-mémorielle. C’est des shoots de mémoire et d’expérience vécue qui nous sont assénés durant tout le film, mené comme une enquête à la manière d’une recherche du temps perdu moderne, grâce à une écriture cinématographique renouvelée.

Chaque minute du film nous place un peu plus dans une sensation d’hypnose, jusqu’à la dernière image où, tel un réveil brutal, des images video, bien réelles, nous plongent dans le cauchemar de la réalité. Et c’est avec cette sensation de stupeur qu’il faut trouver le courage de se lever de son siège et sortir de la salle la gorge encore nouée de la honte d’être un homme.

Voilà une oeuvre qui explose les taxinomies et les plans de classement traditionnel du cinéma : drame ? Film de guerre ? Documentaire ? Dessin animé ? Une oeuvre majeure en tous cas, puisqu’elle ouvre un monde et nous ouvre un monde en nous inscrivant dans une mémoire collective.


Ce soir, c’est comme si je l’avais fait, cette putain de guerre.

Le DNS est à la fois un des protocoles de base de l'Internet, dont presque toutes les transactions dépendent, et un des protocoles les plus mal spécifiés. Les RFC de référence, les RFC 1034 et RFC 1035, sont toujours en service mais, écrits il y a plus de vingt ans, ils accusent leur âge. Ils sont souvent ambigus et ont été mis à jour par de nombreux RFC ultérieurs. Ainsi, celui qui développe une nouvelle mise en œuvre du DNS doit lire plusieurs RFC successifs. L'un des plus importants est notre RFC 2181 qui avait clarifié plusieurs points particulièrement importants de la norme originelle.

On ne peut rien faire avec le DNS si on ne lit pas ce RFC 2181. Il est une sorte de FAQ des erreurs les plus souvent commises en lisant trop vite les RFC 1034 et RFC 1035. Mais il corrige aussi ces RFC, qui comportaient parfois de réelles erreurs (sections 1, 2 et 3).

Les consignes de notre RFC 2181 sont très variées.

Ainsi, la section 4 rappelle que le serveur DNS doit répondre depuis l'adresse IP à laquelle la question a été posée (pour un serveur qui a plusieurs adresses). La section 4.2 pose le même principe pour le numéro de port.

La section 5 introduit un concept nouveau, celui de RRSet (Resource Record Set ou « ensemble d'enregistrements de données »). Ce concept n'existait pas dans les RFC 1034 et RFC 1035. Un RRSet est un ensemble d'enregistrements DNS pour le même nom de domaine, et le même type. Ainsi, ce groupe forme un RRSet :

foobar.example.com.    IN    AAAA      2001:DB8:123:456::1
foobar.example.com.    IN    AAAA      2001:DB8:CAFE:645::1:2

foobar.example.com.    IN    AAAA      2001:DB8:123:456::1
baz.example.com.       IN    AAAA      2001:DB8:CAFE:645::1:2

foobar.example.com.    IN    AAAA      2001:DB8:123:456::1
foobar.example.com.    IN    A         192.0.2.34

Le RFC impose ensuite (section 5.1) que les enregistrements d'un RRSet soient tous envoyés dans une réponse (ou bien que le bit TC - indiquant la troncation - soit positionné, ce que détaille la section 9). Pas question de n'envoyer qu'une partie d'un RRSet. Il impose également que les différents enregistrements d'un RRSet aient le même TTL (section 5.2). Il existe également des règles pour DNSSEC (section 5.3) mais elles concernent l'ancienne version de DNSSEC, qui a depuis été remplacée par DNSSEC-bis (RFC 4033 et suivants).

De même qu'un serveur ne peut pas n'envoyer qu'une partie des enregistrements d'un RRSet, il ne doit pas fusionner un RRSet reçu en réponse avec des données du même RRSet qui seraient dans son cache (section 5.4). Le reste de la section 5.4 est d'ailleurs consacré à la nécessaire paranoïa d'un serveur de noms récursif. En effet, le RFC 2181 lui impose de ne pas accepter aveuglément n'importe quelle donnée mais de juger de la confiance qu'on peut lui accorder (section 5.4.1). Ainsi, les données présentes dans la section additional d'une réponse DNS sont moins fiables que celles de la section answer. Le déploiement de notre RFC a ainsi résolu un gros problème de sécurité du DNS : les serveurs de noms récursifs avalaient tout le contenu de la réponse, sans juger de sa valeur, et étaient donc faciles à empoisonner avec de fausses données. Ainsi, avant le RFC 2181, un serveur qui demandait les enregistrements de type A pour www.example.org et qui recevait une réponse :

;; QUESTION SECTION:
;www.example.org.                            IN      A

;; ANSWER SECTION:
www.example.org.                       IN   A    192.0.2.1

;; ADDITIONAL SECTION:
www.google.example.                       IN   A   192.0.2.178

La section 6 du RFC traite des frontières de zones DNS (zone cuts). L'arbre des noms de domaine est découpé en zones (RFC 1034, section 2.4 et 4.2), chaque zone étant traditionnellement décrite dans un fichier de zone spécifique. Pour connecter une zone parente à la fille, la parente ajoute des enregistrements de type NS. Il faut se rappeller que les frontières de zone ne se voient pas dans le nom de domaine. Est-ce que org.uk est géré par la même organisation que co.uk ? Vous ne pouvez pas le savoir juste en regardant ces noms. D'autre part, les zones ne correspondent pas forcément à des frontières organisationnelles. Pendant longtemps, nom.fr était dans une zone différente de fr alors que les deux domaines étaient gérés par le même organisme, l'AFNIC. En sens inverse, le futur domaine n'aura qu'une seule zone, tout en permettant aux utilisateurs de mettre leurs propres données.

Bref, la zone est une notion complexe. Notre RFC rappelle juste que les données de délégation (les enregistrements NS) ne font pas autorité dans la zone parente (section 6.1). En dehors des enregistrements indispensables à la délégation (NS et peut-être A et AAAA de colle), les serveurs ne doivent pas envoyer de données qui sont au delà d'une frontière de zone.

La section 8 corrige légèrement la définition du TTL qui se trouve section 3.6 du RFC 1034 en imposant que ce soit un entier non signé.

La section 10 s'attaque à des question plus délicates car plus visibles par l'utilisateur humain, les questions de nommage. Au contraire des règles des sections précédentes, qui ne seront guère vues que par les programmeurs qui écrivent des serveurs de noms, les règles des sections 10 et 11 concernent tous les gérants de zones DNS.

D'abord, un rappel en début de section 10 : dire que telle machine « a pour nom de domaine gandalf.example.net » est un net abus de langage. Une machine n'a pas un nom qui serait le « vrai » ou l'« authentique ». Il faut plutôt dire que des tas de noms dans le DNS peuvent pointer sur une machine donnée. Ainsi, il n'y a aucune obligation d'avoir un seul enregistrement de type PTR (section 10.2) pour une adresse IP donnée.

La section 10.1 clarifie les enregistrements de type CNAME. Leur noms peut être trompeur car il veut dire Canonical Name (« nom canonique ») alors que le CNAME sert plutôt à enregistrer des alias (section 10.1.1). Si le DNS contient :

www.example.org.    IN    CNAME    www.example.net.

La section 10.2 rappelle qu'on peut avoir plusieurs enregistrements de type PTR et surtout qu'un PTR peut mener à un alias, et pas directement au nom de domaine désiré. Cette propriété est d'ailleurs à la base de la délégation sans classe de in-addr.arpa décrite dans le RFC 2317.

Par contre, les enregistrements NS et MX ne peuvent pas mener à un alias (section 10.3). Un logiciel comme Zonecheck teste d'ailleurs cela.

Enfin, la section 11 est peut-être la plus ignorée de tout le RFC. Consacrée à la syntaxe des noms de domaines, elle rappelle (c'est juste un rappel, les RFC 1034 et RFC 1035 étaient déjà clairs à ce sujet) qu'un nom de domaine peut prendre n'importe quelle valeur binaire. Si vous entendez quelqu'un dire que « le DNS est limité aux caractères ASCII » ou bien « le DNS est limité aux lettres, chiffres et tiret », vous pouvez être sûr que la personne en question est profondément ignorante du DNS. Le DNS a toujours permis de stocker n'importe quels caractères, même non-ASCII et, s'il a fallu inventer les IDN du RFC 3490, c'est pour de tout autres raisons.

La section 11 souligne juste que les applications qui utilisent le DNS peuvent avoir des restrictions. Ainsi, avant les IRI du RFC 3987, les adresses du Web étaient en effet limitées à ASCII.

Il y a déjà eu des tas de plans pour réaliser la transition depuis l'actuel IPv4 vers le futur protocole IPv6. Ce très court RFC, qui est une contribution individuelle, expose sommairement un tel plan, dont rien ne garantit qu'il sera d'avantage suivi que les autres.

Comment passer d'un Internet très majoritairement IPv4 à un Internet où IPv6 représenterait l'essentiel des adresses et du trafic, ne laissant que des îlots attardés avec l'ancien protocole ? Le problème est d'autant plus difficile que les premiers à migrer n'ont aucun intérêt à le faire puisqu'ils ne peuvent joindre personne en IPv6 ; aujourd'hui, il n'y a pratiquement aucun « gros » site Web accessible en IPv6, et ce n'est pas différent pour les autres services. Il y a peu de chances que les seules lois du marché suffisent à effectuer ce changement (voir aussi le RFC 1669).

Notre RFC décrit un plan possible, en notant bien qu'il n'est pas obligatoire. J'ajoute qu'il ne semble pas plus réaliste que les autres, qu'on trouve par exemple dans les RFC 3750 ou RFC 4057. Il part d'une prémisse optimiste, que les acteurs voudront la connectivité IPv6 pour elle-même.

L'idée est de décrire la transition en plusieurs étapes (section 2). Trois étapes sont prévues, chacune permettant de tirer d'avantage de bénéfices de la transition. Dans l'étape de Préparation (section 2.1, prévue pour durer jusqu'en décembre 2009, c'est-à-dire quasiment demain), on dote certains serveurs accessibles de l'extérieur de capacités IPv6 (sans forcément mettre IPv6 sur tous les réseaux locaux). Pour limiter les risques, ces serveurs sont accessibles avec un nom spécial, comme expliqué en section 2.1.1 (c'est ce que fait Google en ce moment où son service phare, le moteur de recherche, est accessible sous le nom ). Notons que la grande majorité des organisations connectées à Internet n'a toujours pas commencé cette étape, prévue pour se terminer dans un an et demi. Notons aussi que cette étape ne permet pas encore d'abandonner IPv4, toute machine devant rester « double-pile » (v4 et v6).

Dans la seconde étape (section 2.2), prévue de janvier 2010 à décembre 2011, tous les serveurs ont IPv6, et on déploie IPv6 sur les réseaux internes. Idéalement, à la fin de cette étape, un accès Internet en IPv6 seul serait possible. Notons que, même si ce calendrier était respecté, il suffirait à peine à éviter l'épuisement des adresses IPv4, qui devrait survenir en 2011.

Enfin, la troisième étape (section 2.3), prévue à partir de janvier 2012, sera consacrée au démantèlement progressif des services IPv4 et à la stabilisation des services IPv6.

Évidemment, ce calendrier devrait être suivi, vu l'approche de la date où la dernière adresse IPv4 sera allouée. Mais le sera t-il ? Compte-tenu de l'actuelle situation de déni de la réalité, c'est peu probable.

Un mot en passant : ce blog n'est pas accessible en IPv6, le fournisseur d'hébergement actuel ne le proposant pas. Un tunnel existe mais il est bien trop lent et surtout trop peu fiable pour que j'annonce une adresse IPv6 dans le DNS.

Après le billet de Sunny, on a décidé avec mixin d'utiliser OAuth pour autoriser l'accès aux données privées de l'API. Rien n'avait encore été fait avec Django alors c'était l'occasion de faire une application réutilisable : django-oauth.

Avez-vous les clefs ?

À première vue, le diagramme peut sembler assez complexe :

Rassurez-vous, l'utilisateur ne suit que les flèche en trait plein, ce qui constitue tout de même un aller-retour entre le service souhaitant accéder aux données (Consumer) et celui hébergeant les données (Provider).

Prenons un exemple simple et d'actualité : vous souhaitez développer un widget qui permette de créer/consulter/éditer des événements sur mixin.

Il faut distinguer deux étapes :

• l'initialisation : le moment où l'utilisateur donne l'accès à ses données
• l'interaction : la manipulation des données par le service grâce à cet accès

Initialisation

Avant toute chose, il faut créer un accès consumer pour votre widget à partir de la partie Développeurs des paramètres de votre profil mixin. Ces informations vont vous permettre d'effectuer des requêtes signées de votre service vers mixin.

Grâce à vos identifiants, vous allez pouvoir récupérer des tokens de requête lorsqu'un utilisateur souhaite procéder à une autorisation d'accès, cette opération se fait de serveur à serveur et ne requiert pas d'action de la part de l'utilisateur.

Avec ce token de requête vous pouvez maintenant rediriger l'utilisateur sur mixin qui va être confronté à une question existentielle : voulez-vous autoriser l'accès à vos ressources personnelles ? Si oui, le token de requête est validé et l'utilisateur est redirigé vers le service, si non, l'utilisateur est redirigé sur le service.

Le service va finalement échanger son token de requête, limité en temps, avec un token d'accès. Ce dernier n'est délivré que si le token de requête a été validé préalablement par l'utilisateur bien entendu.

Interaction

Une fois ce token d'accès en sa possession, le service va pouvoir interagir avec l'API RESTful de mixin en transmettant les arguments relatifs au token.

Ces actions ne requièrent aucune action supplémentaire de la part de l'utilisateur (bon ok ça dépend de votre widget, sinon ça perd son intérêt...).

Le gros avantage d'OAuth, c'est qu'il n'est pas nécessaire de donner son mot de passe et vous pouvez à tout moment supprimer l'accès à un service tiers depuis mixin sans impacter les autres services accédant à vos données.

Un autre avantage qui n'a pas été mis en pratique afin de faciliter le cheminement de l'utilisateur est de pouvoir limiter l'accès à certaines ressources, voire de régler finement le type d'accès (lecture/écriture).

Utilisation avec Django

Pour l'instant seule la partie Provider a été rendue publique, elle permet de gérer les consumers, les tokens, les resources et les nonces. Vous pouvez directement consulter la documentation de django-oauth provider qui constitue aussi les tests dans la plus pure tradition python.

Il vous suffit d'ajouter l'application dans vos settings et de lancer un syncdb. La vue à afficher à l'utilisateur est personnalisable en spécifiant le setting OAUTH_AUTHORIZE_VIEW, normalement tout est bien documenté donc je ne vais pas me répéter, n'hésitez pas à demander au besoin, il y a un exemple détaillé présent du le dépôt.

Limites inévitables

Complexité

Il m'a fallu un bon moment pour comprendre le protocole, même si maintenant ça me semble évident c'est toujours rebutant d'avoir à passer du temps là-dessus. Bon d'un autre côté c'est aussi ce qui est intéressant, aller explorer des contrées inconnues, ça dépend de votre point de vue :-).

Ergonomie

L'aller-retour entre les deux sites peut destabiliser l'utilisateur qui se demande pourquoi ces étapes sont nécessaires. Le problème est le même avec OpenID, mais je préfère que ce cheminement soit généralisé au lieu de donner son mot de passe à tout va !

Phishing

Dès qu'il y a redirection, il est possible de faire du phishing très facilement : vous redirigez sur une page de login du site distant hébergée sur votre serveur pour récupérer les identifiants/mot de passe. Il y a du boulot de ce côté là...

Maturité

Le protocole souffre de certaines erreurs de jeunesse, il est par exemple assez hallucinant qu'il n'y ait rien de standardisé au niveau de la gestion des erreurs, de la langue de l'utilisateur ou de la ressource à laquelle souhaite accéder le service ! Heureusement, certaines de ces limites seront corrigées dans la prochaine version d'OAuth.

Conclusion

Au final, c'est une bonne avancée (on ne demande plus le mot de passe à l'utilisateur) mais elle se fait pour l'instant au détriment d'une certaine simplicité apparente due aux mauvaises habitudes enseignées aux utilisateurs et c'est bien dommage. C'est un peu comme envoyer un code par email, c'est pratique lorsqu'on sait que son provider et son accès sont sécurisés mais ça concerne une minorité d'internautes et ça laisse une faille de sécurité énorme par ailleurs...

Pownce.app est la première application pour iPhone à utiliser OAuth à ma connaissance, ce qui est logique compte tenu de l'implication de Leah Culver (elle a écrit la lib Python et une partie de la spec) mais c'est toujours intéressant de voir une utilisation combinant mobile+web. Google aussi a beaucoup investi dans ce protocole et leurs réflexions sur OAuth et les interactions possibles sont vraiment pertinentes.

Maintenant que mixin dispose d'une API, il ne reste plus qu'à s'en servir ! Outre le site internet, mixin devient vraiment intéressant avec toutes les applications qui gravitent autour et les interactions avec les autres services. Certaines intégrations sont en préparation mais vous pouvez devenir acteur et développer votre propre outil. N'hésitez pas à me contacter si vous souhaitez développer quelque chose ou si vous avez des soucis avec OAuth, les idées révolutionnaires sont les bienvenues aussi ;-).

J’ai été invité à la Journée professionnelle sur la coopération culturelle européenne, organisée par l’association Relais Culture Europe avec notamment le concours du Festival d’Avignon, et à laquelle était invitée Ars Industrialis.
En faisant une synthèse des interventions de la journée, Bernard Stiegler à souligné à juste titre l’épuisement comme thème récurrent des interventions de la journée.
Épuisé, je l’étais aussi, et pas seulement pas par la chaleur caniculaire qui frappait Avignon ce jour là, ni par les aléas logistiques inhérents à la coordination et aux déplacements de tous ces participants venus de toute l’Europe dans une ville grouillante d’activités artistiques.

Non, l’épuisement était partout ailleurs  : épuisement des ressources et nécessité d’un développement durable, épuisement des budgets pour soutenir la culture, épuisement des politiques qui ne perçoivent pas les enjeux portés par la culture, épuisement des argumentations qui tournent en rond.

La journée avait pourtant bien commencé avec la table ronde initiée par Alain Giffard qui, avec la verve qu’on lui connaît, a brossé en dix minutes une magistrale présentation des travaux et des thèses soutenues par Ars Industrialis. Il était donc acquis que la question culturelle devait se poser selon l’axe des industries culturelles et des technologies de l’esprit. Vincent PUIG, le directeur de l’Institut de Recherche et d’Innovation, a enfoncé le clou en faisant une démonstration de l’outil Lignes de temps, développé à l’IRI.

Et puis, malgré quelques moments lumineux, l’épuisement a repris le dessus, comme si ce qui avait été dit en début de journée s’était évaporée sous l’effet de la chaleur. Alors j’ai pensé à une phrase de Godard, prononcée dans un autre festival, celui de Cannes en 1968, et que j’aurai modifié de la sorte :

“Mais je vous parle industries culturelles et technologies de l’esprit et vous me répondez danse, théâtre, et spectacle vivant !! “

Les artistes, les technocrates de la culture et les politiques me donnent la sensation tourner en rond : les artistes demandent de l’argent, les technocrates leur expliquent qu’il n’en n’ont pas ( mais qu’il faut continuer quand même d’en demander car sinon ils ne pourraient plus exercer leur pouvoir ), et les politiques ne jurent que par le spectacle et l’événementiel (et on fait quoi entre? ).

Bien sûr il y a des artistes et des institutions qui comprennent les enjeux des industries culturelles et des technologies de l’esprit, et même nombreux parmi les jeunes talents sont très immergés dans des pratiques et des activités numériques. Mais seuls, il ne peuvent pas faire une politique européenne des technologies de l’esprit, il ont besoins des puissances publiques, sous toutes leurs formes : territoriales, régionales, nationales et européennes. Il faut que toute la chaîne des acteurs de la culture, et jusqu’aux publics qui ne demandent qu’à participer, soit impliquée.

Le web est précisément le lieu où il est possible que les logiques de l’épuisement trouvent des alternatives, là où l’intelligence collective peut émerger, et où des logiques participatives peuvent inscrire la culture dans autre chose qu’un lieu protégé, sous perfusion, qui ne peut offrir que des rhétoriques de la résistance et des politiques de l’exception culturelle.

Les puissances publiques européennes sont coupables, malgré leurs beaux discours et leurs belles convictions, d’étouffer la question culturelle comme une mère qui étoufferait son enfant à trop vouloir l’étreindre et le protéger.

Le web donc, change la donne comme il change et re-configure toutes les industries et les institutions, y compris et surtout les industries culturelles. Mais comment espérer que des décisions éclairées soient prises quand ceux qui peuvent prendre ces décisions ne pratiquent pas ce nouveau milieu technologique ? C’est comme espérer qu’un analphabète apprenne à quiconque à écrire.

Qu’il faille placer la culture au coeur de la politique européenne, chaque nouveau référendum sur la constitution européenne le rappelle avec urgence. Mais l’Europe a du mal à penser et à théoriser comment le faire, précisément parce que les enjeux industriels lui échappent systématiquement, à l’image de Michel Rocard qui affirmait de manière ahurissante qu’il fallait laisser la culture aux pays membres, afin qu’ils aient au moins cela en propre. En clair : ne pas avoir de politique culturelle européenne.

Il s’est dit lors de cette journée que Michel Rocard avait changé, et qu’à présent il comprenait mieux les enjeux de la culture, et je veux bien le croire en voyant le rapport sur la république 2.0 qu’il avait sorti au printemps 2007. Mais combien faudra-t-il de révélations rocardiennes parmi nos politiques et les membres de la commission européenne avant que l’Europe fasse sa révolution copernicienne de la question culturelle ?

Toujours est-il que ce n’est pas un hasard si le web a été inventé en Europe, et ce ne sera pas un hasard si l’Europe saisi à nouveau l’opportunité du web pour se ré-inventer et instancier sa devise officielle : “Unité dans la diversité”.

Merci à tous les testeurs de la première heure, j'ai pas vraiment le temps de m'attarder pour l'instant mais vous pouvez retrouver mon profil sur mixin. Les retours sont très appréciés et je ne désespère pas d'arriver à bout de la montagne de mails qui m'attend dans mon inbox depuis une semaine au moins.

Let the buzz goes on!

ps : pour les nouveaux venus, j'en avais parlé il y a quelques mois.

Alors qu'on a déjà mieux avec du décentralisé et performant... que demande le peuple ?

Le protocole de routage OSPF fonctionne en distribuant de l'information sur les interfaces du routeur, informations qui sont transmises par inondation à tous les routeurs de la zone. Cette information est structurée en LSA (Link State Advertisment) et ces LSA appartiennent à différents types, les premiers ayant été décrits dans le RFC 2328. Comme tous les routeurs de la même zone (area) doivent comprendre tous ces types, ajouter un nouveau type de LSA n'est pas facile. D'où l'idée, qui avait fait l'objet du RFC 2370, de créer un type « opaque » qui pourrait stocker de l'information spécifique à une application, sans que les routeurs aient besoin de connaitre autre chose que le fait qu'il soit opaque. C'est l'objet de notre RFC, qui remplace le 2370.

Ainsi, il sera plus facile d'étendre OSPF, comme l'avaient fait les RFC 3623 ou RFC 3630. Il suffit désormais d'enregistrer un « type de LSA opaque » auprès de l'IANA. Les routeurs qui ne connaissent pas ce type passeront les LSA sans les comprendre et sans être affectés. Le RFC 5250 ne spécifie d'ailleurs pas comment utiliser les LSA opaques, cela dépend complètement de l'application envisagée (section 2).

La section 3 décrit en détail ces nouveaux LSA. Il en existe de trois types :

• Le type OSPF 9 est réservé aux LSA opaques locaux à un segment de réseau et ne sont pas transmis aux routeurs qui sont sur d'autres segments,
• Le type OSPF 10 sert aux LSA opaques locaux à une zone OSPF,
• Et le type 11 est pour les LSA opaques diffusés dans tout un AS (à l'exception des zones « terminales » par exemple les NSSA du RFC 3101).

Le LSA opaque est composé d'un en-tête LSA normal (section 12.1 du RFC 2328) suivi de 32 bits d'information qui sont divisés en un sous-type de 8 bits (le registre IANA les nomme opaque LSA option types) et 24 bits pour les informations spécifiques à l'application. Ainsi, le sous-type 1 désigne l'application traffic engineering du RFC 3630, alors que le 4 est la router information du RFC 4970. Le reste du LSA contient les données (de longueur variable, voir l'annexe A.2).

La section 3.1 gouverne la diffusion de ces LSA opaques, par inondation (section 13 du RFC 2328). Un routeur sait que son voisin OSPF est capable de gérer des LSA opaques en regardant le bit O (comme Opaque, valeur 0x40) lu dans les paquets Database Description que les deux routeurs s'échangent.

Justement, la section 4 décrit les changements dans les structures de données du protocole. En raison de l'option O citée plus haut, la description d'un voisin OSPF doit avoir un champ de plus pour stocker cette information sur les capacités du voisin.

La section 5 est la grosse nouveauté par rapport au RFC 2370, qui avait normalisé le protocole à l'origine. Elle décrit la diffusion des LSA opaques entre différentes zones OSPF. Enfin, la section 7 décrit les questions de compatibilité avec les vieux routeurs qui ne mettent pas en œuvre les LSA opaques (ils les ignorent, et ne peuvent donc pas les transmettre à leurs voisins).

La plupart des mises en œuvre d'OSPF supportent ces LSA opaques. Avec Quagga, il faut s'assurer que le logiciel a été configuré avant la compilation avec --enable-opaque-lsa. Il suffit ensuite de mettre ospf opaque-lsa dans le fichier de configuration OSPF. IOS et JunOS disposent également de ces LSA opaques.

Ce RFC est entièrement consacré à un problème qui a causé des cheveux blancs à beaucoup d'administrateurs de réseaux informatiques : la détection d'une duplication d'adresses IP.

Que la duplication soit un phénomène normal (cas des réseaux non gérés, ceux dont personne ne s'occupe, où il n'y a pas de liste des adresses allouées), le résultat d'une erreur humaine, ou une incivilité (« Je prends une adresse IP au hasard, on verra bien »), elle est quasiment impossible à empêcher. Une machine peut toujours émettre avec l'adresse qu'elle veut, le protocole ARP (RFC 826) ne peut fournir aucune sécurité (section 6 du RFC). Peut-on au moins la détecter ? C'est ce que propose notre RFC, après avoir expliqué (section 1) pourquoi le mécanisme proposé par le RFC 2131 n'est pas suffisant (cette section 1, comme souvent avec Stuart Cheshire, tourne d'ailleurs souvent au réglement de comptes, comme lorsque l'auteur souligne que Mac OS avait déjà résolu le problème en 1998).

Le nouveau protocole, ACD, repose sur ARP. La section 1.2 commence en listant les nouveautés. Le principe d'ACD est d'utiliser ARP, non pas pour poser sincèrement la question « Qui utilise telle adresse IP ? » mais pour détecter ceux qui répondraient à une requête pour l'adresse IP de la machine émettrice. Comme le note la section 1.2, de telles questions « orientées » sont courantes dans la vie. Si on demande au café « Est-ce que cette table est libre ? » c'est en général avec l'intention de s'y asseoir si elle l'est. De même, avec ACD, la machine qui veut vérifier l'unicité de son adresse IP, mettons 192.0.2.48 va demander à tout le monde « Qui utilise 192.0.2.48 ? » et confirmer cette adresse si personne ne réagit. ACD est utilisable sur tout réseau où ARP fonctionne.

La section 2 est la description détaillée du protocole. Lors du démarrage ou redémarrage d'une interface réseau, la machine ACD envoie une requête ARP pour sa propre adresse, avec sa propre adresse MAC comme adresse MAC source et 0.0.0.0 comme adresse IP source (section 2.1.1 : cette surprenante précaution est nécessaire pour éviter de polluer les caches ARP si quelqu'un utilise déjà cette adresse).

Après une attente suffisante (les détails se trouvent dans le RFC), si personne n'a répondu, la machine considère qu'il n'y a pas de duplication d'adresse et envoie une deuxième requête ARP, cette fois-ci avec son adresse IP en source, pour prévenir qu'elle va désormais utiliser cette adresse.

La réponse ARP est normalement acheminée en unicast mais la section 2.6 explique qu'ACD peut aussi utiliser la diffusion générale.

Et si ça va mal ? Si quelqu'un utilise cette adresse ? La section 2.4 couvre ce cas, en notant également que la détection de conflit doit être continue, puisqu'une autre machine peut arriver à tout moment en voulant utiliser la même adresse. La section détaille donc le concept de « défendre son adresse », comment et dans quelles conditions.

La section 3 contient l'explication d'un choix de conception qui fut très discuté, l'utilisation, pour tester la duplication, de requêtes ARP au lieu de réponses ARP, a priori plus adaptées. La principale raison est la crainte que certaines implémentations ne gèrent pas correctement des réponses qui n'ont été précédées d'aucune requête. Notons aussi qu'il est malheureusement rare dans les RFC de voir une discussion des choix alternatifs : la spécification est en général annoncée telle quelle, sans justification des choix, contrairement à ce que fait ce RFC.

La section 4, historique, rappelle l'ancienne technique des « ARP gratuits » (au sens de « meurtres gratuits »), qui avait été proposée par Stevens dans son TCP/IP illustrated et explique en quoi ACD est préférable (l'ARP gratuit est l'équivalent de crier « Je vais prendre cette table » sans vérifier si elle est déjà occupée).

De bons conseils pour réussir la mini-réunion quotidienne chère à tout projet agile. C'est finalement assez proche de la pause clope/café qui tend à être supprimée par ailleurs...

L’enfant est un être mineur, au sens où il n’est pas majeur et responsable.
Il faut donc être clair, quand le marketing s’adresse aux enfants, à ceux qui ne sont pas encore majeurs, il a un comportement de criminel. Le moment est proche où certains medias visant les enfants seront mis en procès.

On fait bien des procès aux industries polluantes, alors à quand des procès qui condamnent la nocivité de ces industries de l’esprit ? Surtout quand elles n’ont d’autres fin que d’utiliser les enfants comme agents pulsionnels programmés pour influencer leur parents dans leur acte d’achat.

Un ancien billet sur Identity Corner fait un résumé très pertinent des problèmes soulevés par OpenID :

• sécurité : problème de phishing dont j'ai eu l'occasion de parler ici ;
• confidentialité : peut-on faire confiance aux providers OpenID qui peuvent tout savoir de votre navigation en ligne ? Qui peuvent même utiliser votre identité ;
• confiance : aucun moyen de savoir qui est derrière un identifiant OpenID (l'état aurait un rôle à jouer à ce niveau...) ;
• usabilité : le processus n'est pas évident pour un néophyte ;
• adoption : sur ce point, et avec le recul d'une année, je pense que les prédictions étaient fausses. Par contre la monétisation des identités ne fait que commencer...
• disponibilité : il faut que les deux sites soient accessibles pour pouvoir accéder à une seule ressource ;
• brevets : je sais pas où ça en est ça.

En conclusion, il n'y a pas (encore) de solution miracle mais ça reste à mon avis utile. Après c'est sûr qu'il vaut mieux avoir confiance en son provider... ou créer le sien. Je suis surpris qu'il n'y ait pas encore (à ma connaissance) de provider éthique comme l'APINC pour pouvoir naviguer sereinement.

Le protocole SMTP de transport du courrier électronique, normalisé dans le RFC 2821, prévoit depuis le RFC 3463 des codes d'erreur à trois nombres très détaillés. Mais il n'existait pas de registre de ces codes et des doublons commençaient à apparaître. Ce RFC spécifie donc un registre des codes de retour SMTP, où tout le monde pourra vérifier que 4.3.1 signifie « Mail system full ».

Parmi les scénarios que résolvent ces codes de retour figure celui de l'internationalisation. SMTP est asynchrone et indirect. L'expéditeur du message n'a pas de contact direct avec les serveurs SMTP sur le trajet. Cela rend donc difficile des problèmes comme celui de la génération de messages d'erreur dans la langue de l'expéditeur. Actuellement, le serveur SMTP typique génère des messages d'erreur dans sa langue à lui (en général de l'anglais), pas dans celle de l'expéditeur qui va le recevoir. Plusieurs approches complémentaires ont été tentées pour résoudre ce problème, celle permise par notre RFC 5248 étant d'envoyer un code de statut numérique, que le MUA de l'expéditeur aura la charge de traduire. Ainsi, recevant « 5.2.2 - User's mailbox is too large - over ten gigabytes », le MUA pourra afficher « Pas assez de place dans la boîte aux lettres du destinataire » (et ignorer les détails en anglais).

Les codes SMTP (RFC 2821, section 4.2.1) originaux, dits « de base » sont composés de trois chiffres écrits sans séparateur (par exemple 554 pour Transaction failed). Les codes « améliorés » du RFC 3463 comportent, eux, trois nombres, la classe (2 : tout va bien, 4 : erreur temporaire, 5 : erreur définitive, etc), le second le sujet (6 : problème avec le contenu du message, 7 : problème avec la politique de sécurité, etc) et le troisième le détail. Ils s'écrivent avec un point comme séparateur. Ainsi, 5.5.2 signifie « Commande non reconnue » (erreur de classe 5, permanente, puisque le serveur SMTP ne va pas spontanément accepter de nouvelles commandes, erreur de sujet 5, problème de protocole). Dans cette session SMTP, on voit le code de base, 502 et le code amélioré 5.5.2 :

 % telnet MYSERVER smtp
220 myserver.example.com ESMTP Postfix (Ubuntu)
XMPA <me@foobarfr>
502 5.5.2 Error: command not recognized

RCPT TO:<foobar@langtag.net>
450 4.7.1 <foobar@langtag.net>: Recipient address rejected: Greylisted by greyfix 0.3.2,\
    try again in 3480 seconds.\
    See http://projects.puremagic.com/greylisting/ for more information.

Notre RFC demande donc à l'IANA (section 2) de créer un registre, le SMTP Enhanced Status Codes, précisant les codes et leur signification.

Ce registre, dit la section 2.3, sera rempli, en suivant les règles du RFC 5226, selon la règle « Specification required » qui impose l'existence d'un texte écrit (pas forcément un RFC). La section 2.4 décrit les valeurs initiales contenues dans ce registre.

Si IPv4 est normalisé dans un seul document, le RFC 791, le candidat à sa succession IPv6 est décrit de manière plus modulaire, dans plusieurs RFC dont notre RFC 2460, essentiellement consacré au format des paquets.

Remplaçant le premier RFC sur le format des paquets IPv6, le RFC 1883, notre RFC 2460 est resté stable depuis bientôt dix ans, alors que la plupart des RFC sur IPv6 ont connu des révisions ; les autres RFC importants pour IPv6 sont le RFC 4291 sur l'adressage - certainement le moins stable -, le RFC 4861 sur le protocole de découverte des voisins, le RFC 4862 sur l'autoconfiguration des adresses et le RFC 4443 sur ICMP.

À l'heure actuelle, le déploiement de ce RFC est très limité : peu de paquets IPv6 circulent sur Internet et il est loin d'avoir succédé à IPv4. Le fait d'avoir un numéro de version plus élevé ne suffit pas ! Notre RFC 2460 présente sans hésiter IPv6 comme le successeur d'IPv4, ce qui reste pour l'instant un vœu pieux.

IPv6 reprend largement le modèle qui a fait le succès d'IPv4 : un protocole de datagrammes, un routage jusqu'au prochain saut (peu ou pas de routage de bout en bout), des datagrammes acheminés « au mieux possible », un en-tête de paquet simple et où les champs sont de taille fixe. La section 1 du RFC résume les différences entre les formats de paquets IPv4 et IPv6.

La plus spectaculaire des différences est bien sûr l'augmentation de la taille des adresses. Toujours fixe (contrairement à des concurrents où les adresses étaient de tailles variables), cette taille passe de 32 bits à 128. Le maximum théorique d'adresses (en supposant une allocation parfaite) passe donc de quatre milliards (ce qui ne permet même pas d'allouer une adresse à chaque personne sur Terre) à plus de 10^40, un nombre qui défie l'imagination.

Compte-tenu de l'épuisement rapide des adresses IPv4, cette augmentation est à elle seule une bonne raison de migrer vers IPv6. Elle reflète les changements de paradigme successifs en informatique, de « un ordinateur par entreprise » au début des années 70, lorsque IPv4 a été conçu, à « un ordinateur par département » au cours des années 80 puis à « un ordinateur par personne » avec l'explosion de la micro-informatique et à « plusieurs ordinateurs par personne » de nos jours lorsque le cadre dynamique et branché se promène avec d'avantage d'appareils électroniques sur lui que n'en portait James Bond dans ses premiers films. Les quatre milliards d'adresses d'IPv4 sont donc aujourd'hui bien insuffisantes.

Mais ce changement de format des adresses est également la faiblesse d'IPv6 : il ne permet en effet pas à des machines v4 et v6 de communiquer directement et les premiers adopteurs du nouveau protocole ne peuvent donc pas parler aux anciens, ce qui a puissamment freiné le déploiement d'IPv6.

Les autres changements apportés par IPv6 sont moins connus mais semblaient à l'époque justifier le nouveau protocole :

• Le format de l'en-tête est simplifié, facilitant la tâche des routeurs (en pratique, IPv4 garde son avantage, la complexité de son format étant compensée par l'expérience des développeurs et la quantité de main d'œuvre qui a travaillé à optimiser les routeurs IPv4).
• Les options sont à la fois plus libres, notamment en taille, et moins contraignantes à gérer pour les routeurs,
• Les services d'authentification et de confidentialité ont été inclus (cet argument est souvent cité en faveur d'IPv6 mais il est largement bidon, IPv4 ayant désormais les mêmes capacités, et elles n'ont pas souvent été intégrées dans les implémentations IPv6).

La section 3 détaille le format du nouvel en-tête de paquet.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le champ Next header indique le type de l'en-tête suivant. La plupart du temps, c'est l'en-tête d'un protocole de transport comme TCP (numéro 6) ou DCCP (numéro 33), dont les numéros sont stockés dans un registre IANA. Mais cela peut être aussi un en-tête d'extension de la couche réseau par exemple 44 pour les fragments (ces numéros sont stockés dans le même registre IANA).

Vu avec tshark, la version texte de l'analyseur Wireshark, et son option -V, voici un paquet IPv6 contenant lui-même du TCP :

Internet Protocol Version 6
    0110 .... = Version: 6
        [0110 .... = This field makes the filter "ip.version == 6" possible: 6]
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 40
    Next header: TCP (0x06)
    Hop limit: 64
    Source: 2a01:e35:8bd9:8bb0:21e:8cff:fe76:29b6 (2a01:e35:8bd9:8bb0:21e:8cff:fe76:29b6)
    Destination: 2a01:e35:8bd9:8bb0:21c:23ff:fe00:6b7f (2a01:e35:8bd9:8bb0:21c:23ff:fe00:6b7f)

La section 4 présente les en-têtes d'extension. Grande nouveauté d'IPv6, ils sont situés entre l'en-tête IP normal et l'en-tête de la couche transport. La plupart d'entre eux sont ignorés par les routeurs situés sur le trajet et traités seulement à l'arrivée (alors qu'un routeur IPv4 devait, en théorie, toujours examiner les options). Notre RFC normalise certaines de ces extensions, mais d'autres peuvent être ajoutées par des RFC ultérieurs comme par exemple le RFC 3775 qui normalise le Mobility Header (numéro 135, section 6.1 du RFC).

C'est ainsi que la section 4.3 décrit l'en-tête d'extension « Hop-by-hop », une de celles qui doivent être examinées par tous les routeurs sur le trajet. Elle contient des options (décrites en section 4.2), qui sont stockées sous forme de tuples TLV. Le type de chaque option indique, dans ses deux premiers bits, si l'option peut être ignorée ou non.

Le symétrique de cet en-tête est le « Destination », section 4.6, qui stocke, de la même façon, les options qui ne doivent être traitées que par le destinataire.

La section 4.4 décrit l'en-tête « Routing » qui permet d'indiquer la route qu'on souhaite voir le paquet prendre, ou bien d'enregistrer la route effectivement suivie. Notons qu'un champ, le « Routing Type », indique le type de routage souhaité et que sa valeur 0 ne doit plus être utilisée : en raison de problèmes de sécurité serieux, le Type 0 Routing Header a été abandonné dans le RFC 5095.

La section 4.5 décrit l'en-tête « Fragment » qui permet de représenter des paquets IP qui, trop longs, ont été fragmentés par l'émetteur (contrairement à IPv4, les routeurs IPv6 n'ont pas le droit de fragmenter).

La section 5 décrit les questions liées à la taille des paquets. IPv6 impose une MTU minimale de 1280 octets et, en théorie, une machine qu n'enverrait que des paquets de cette taille (ou plus petits) n'aurait jamais de problème. Au delà, on doit utiliser la découverte de la MTU du chemin, spécifiée dans le RFC 1981 mais dont le moins qu'on puisse dire est qu'elle n'est pas très fiable (cf. RFC 4821).

Les différences avec le RFC 1883 sont décrites après la bibliographie. Elles sont en général de peu d'importance. Par exemple, la MTU minimale passe à 1280 octets (après des débats enfiévrés, à une époque où LocalTalk était une technologie assez courante, le RFC 1883 utilisait 576 octets). Outre changement, la possibilité d'envoyer des très grands paquets, les jumbograms, a disparu du RFC de base et figure désormais dans un RFC dédié, le RFC 2675.

Sébastien Douche m'avait conseillé le livre Presentation Zen de Garr Reynolds la veille de