Stéphane Bortzmeyer a écrit 655 commentaires

Euh, non, Go, Ada ou Java, pour ne prendre que trois exemples de langages typés, n'accepteraient pas un booléen là où on attend un entier. (A fortiori, ils ne le convertiraient pas.)

Les vulnérabilités citées dans l'article ont évidemment été signalées aux auteurs de logiciels avant la publication de l'article et plusieurs sont donc aujourd'hui corrigées.

Coded TCP est une idée géniale : quand le lien est mauvais (perd des paquets), ajouter des données (ben oui, ya pas de miracles, les codes correcteurs d'erreurs fonctionnent en ajoutant de la redondance).

Tout à fait et c'est pour cela que la comparaison avec IPv6 Mobile est erronée. Mais c'est la faute de l'article original qui, curieusement, mettait davantage l'accent sur la résilience (que SCTP fournit déjà) plutôt que sur la répartition de trafic.

Le groupe de travail a déjà sorti un RFC d'architecture : http://www.bortzmeyer.org/6182.html

Il n'y a plus de recommandation officielle sur la longueur du préfixe à allouer aux utilisateurs finals depuis le RFC 6177 http://www.bortzmeyer.org/6177.html

Une bonne lecture sur la question de la rénumérotation est le RFC 5887 http://www.bortzmeyer.org/5887.html

Pourquoi est-ce que le PI est important ? Si on n'a qu'un FAI, pas trop, sauf si on veut héberger ses propres serveurs DNS (pour lesquels on ne peut pas faire appel au DNS pour trouver leur adresse).

Le PI devient beaucoup plus intéressant lorsqu'on est multi-homé (plusieurs FAI), ce qui est bien utile pour la résilience.

L'affirmation « il suffit » est quand même assez ridicule. D'abord, la plupart des chiffres qu'on trouve sur le Web au sujet des adresses IPv4 allouées mais non utilisées sont faux. Il ne faut pas se fier à ce qu'on trouve sur le Web. Les gens qui produisent ces chiffres confondent en général « non annoncé dans la DFZ - Default-Free Zone - BGP » avec « non utilisé ». Une entreprise a très bien pu utiliser son /8 en interne, sans l'annoncer à l'extérieur.

Ensuite, si vous pensez qu'Apple ou HP ont tort de faire cela et devraient rendre leur /8 (qui n'est pas inutilisé), prévoyez des frais d'avocats considérables… Les allocations des /8 ont été faites informellement et, pour prouver devant un tribunal qu'elles doivent être rendues, face aux avocats d'Apple, vous allez avoir du mal. La rénumérotation a un coût et Apple ne se laissera pas faire.

Mais c'est amusant de voir les efforts que les gens sont prêts à faire pour ne pas migrer vers IPv6…

Pour tester, c'est simple :

Site qui a v6 :

    % curl -v -6 http://www.afnic.fr/ > /dev/null
* About to connect() to www.afnic.fr port 80 (#0)
*   Trying 2001:67c:2218:2::4:20...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* connected
* Connected to www.afnic.fr (2001:67c:2218:2::4:20) port 80 (#0)

On voit les adresses v6, c'est bon.

Site qui n'a pas v6 (il a bien une adresse mais v4 seulement) :

% curl -v -6 http://www.fleurpellerin.fr/ > /dev/null     
* getaddrinfo(3) failed for www.fleurpellerin.fr:80
* Couldn't resolve host 'www.fleurpellerin.fr'
* Closing connection #0
curl: (6) Couldn't resolve host 'www.fleurpellerin.fr'

Bas niveau : getaddrinfo() en C

Haut niveau : libcurl ou libneon en C

Et tous les équivalents dans les autres langages (le problème est largement spécifique à C)

Ben, le NAT protège contre des attaques très rares (attaques par connexion directe, comme du temps de SQL Slammer) et ne protège pas contre les attaques qui sont de loin les plus fréquentes aujourd'hui (attaques par charge utile). Donc, il sert à quoi ?

Bof, cette sécurité est largement illusoire. http://www.bortzmeyer.org/nat-et-securite.html

Sur ce point, le RFC 6092 (recommandations aux auteurs de boxes) est une bonne lecture http://www.bortzmeyer.org/6092.html

Tous les pays sont dans ce cas. La plupart des entreprises états-uniennes ne cherchent même pas dans la base des brevets chinois pour voir s'ils n'en enfreignent pas un.

La licence choisie par les développeurs d'Opus n'a aucune importance. Les brevets sont détenus par des tiers (comme Microsoft) et ceux-ci n'ont aucune raison de se sentir liés par une licence qu'ils n'ont pas écrite.

D'abord, la plupart des ces brevets sont illégaux en Europe. Donc, il suffit de ne pas voyager ou vendre aux USA ou en Chine (l'autre pays du brevet futile) pour être tranquille.

Ensuite, même aux USA, rien ne dit que ces brevets tiennent le coup devant un tribunal. Il suffit donc d'embaucher plusieurs avocats et de faire annuler ces brevets. Fastoche.

Sérieusement, l'IETF publie les revendications de brevet, elle n'évalue pas leur mérite.

Dans l'image Debian que j'ai testée (qui était l'image officielle il y a deux semaines), pas du tout d'IPv6, même pas en module.

J'ai eu la flemme de recompiler et puis, avec l'image ArchLinux, IPv6 marchait très bien.

Les six ans, c'était à partir de la dissolution du groupe et de la publication des premiers RFC, en 2006. Deux ans étaient annoncés, cela en a pris six.

Si. C'était mieux avant la correction.

6686, pas 6696. Désolé mis j'ai l'impression qu'on ne peut pas modifier un journal, juste ajouter des commentaires.

Oui, elle peut être négative mais c'est peu probable : la Terre ne fait que ralentir, je ne vois pas bien quel phénomène physique la ferait accélerer d'une seconde…

Malheureusement, Unix ne donne accès qu'à UTC (et pas à TAI ni à une autre échelle strictement monotone) donc des applications qui n'ont pas besoin de l'heure « civile » sont quand même forcées de l'utiliser :

http://www.bortzmeyer.org/leap-second-or-not-leap-second.html

Encore faut-il qu'il y a des câbles alternatifs ! Comme cela coûte cher, ce n'est pas toujours le cas. En prime, lorsque les câbles alternatifs passent dans la même tranchée, une seule pelleteuse coupe tout (cas de la coupure « tramway » du datacenter de Prosodie dans les Yvelines).

Et cela ne couvre que les pannes matérielles. Mais les pannes logicielles peuvent potentiellement avoir des conséquences plus graves (pensez au nombre incroyable de zones DNS qui n'utilisent que BIND : en cas de bogue BIND, on peut planter beaucoup de domaines).

Désolé pour le lien, linuxfr a considéré que le guillemet fermant en faisait partie. Le bon lien est http://www.ssi.gouv.fr/fr/menu/actualites/l-anssi-et-l-afnic-publie-un-etat-des-lieux-de-l-internet-francais.html

Concernant la possibilité d'une panne majeure de l'Internet (qui ne touche pas qu'une ville ou un site Web mais une grande partie de l'Internet), je trouve très imprudent d'affirmer « du coup Internet ne me parait pas pouvoir être en panne ». Certes, cela ne s'est jamais produit. Mais, si on ne fait pas attention, cela pourrait arriver un jour. Si tout le monde utilise des Cisco et qu'une faille premier-jour d'IOS est exploitée par un méchant… il peut planter une bonne partie de l'Internet. Des alertes sérieuses ont déjà eu lieu. http://www.bortzmeyer.org/bgp-attribut-99.html

Cela ne me semble pas une bonne idée. Cela interdirait, lors de la normalisation d'un paramètre, de changer son nom (je prends X-billgates-est-un-con et ensute, je demande l'enregistrement officiel) ou de changer sa sémantique (ce qui est souvent le cas en pratique).

Sinon, pour savoir lesquels sont officiels, il ne faut surtout pas « compulser les RFC » (beaucoup de registres de paramètres n'exigent pas forcément un RFC, juste une doc stable) mais le registre pertinent sur le site de l'IANA http://www.iana.org/