Stéphane Bortzmeyer a écrit 675 commentaires

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/

J'ai l'impression que vous utilisez un vocabulaire non-standard. Vous voulez dire que vous avez plusieurs enregistrements MX (il y en a toujours au moins un), pointant vers des serveurs différents ? Si c'est le cas, c'est en général une mauvaise idée pour un petit site http://www.bortzmeyer.org/mx-secondaire.html

Et le fait que les spammeurs attaquent en premier le MX de plus faible priorité a été souvent observé.

Sinon, le cas de plusieurs MX est couvert dans les articles cités.

Ce problème est connu et longuement décrit dans les documents cités (avec les solutions).

Mais c'est justement une énorme limite. Combien de pare-feux autorisent l'UDP ?

Ce caratère n'est pas autorisé par la norme IDN (seules les lettres et les chiffres le sont et quelques rares autres). Alors, à part pour troller bêtement, à quoi bon le citer ?

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

Excellent document, oui. Mais il faut le lire jusqu'au bout, notamment dans la conclusion qui dit que le problème est très exagéré « It is also important to recognize that the use of visually confusable characters in spoofing is often overstated. Moreover, confusable characters account for a small proportion of phishing problems: most are cases like "secure-wellsfargo.com". » Et, pour revenir au vote, ce document approuve les IDN…