Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.
Date de publication du RFC : Février 2010
Auteur(s) du RFC : M. Munakata, S. Schubert, T. Ohba (NTT)
Pour information
Première rédaction de cet article le 9 Février 2010
Le protocole SIP, surtout connu pour son rôle dans la téléphonie sur IP, dispose de plusieurs fonctions permettant de protéger la vie privée de ses utilisateurs. Spécifiées dans plusieurs RFC, ces fonctions ne sont pas forcément évidentes à utiliser, d'où ce RFC qui tente de guider les développeurs vers les bonnes pratiques.
SIP est normalisé dans le RFC 3261 et est certainement le premier protocole de téléphonie sur IP, d'autant plus que certains de ses concurrents, bâtis sur des protocoles fermés, ne respectent pas forcément la vie privée de leurs utilisateurs. Et SIP, qu'en fait-il ? Certaines de ces fonctions peuvent être excessivement intrusives, par exemple le fait que l'adresse de l'appelant soit fournie, et il existe donc des moyens de les débrayer.
Le cadre général est donné dans le RFC 3323. Il introduit
par exemple l'idée de mettre
sip:anonymous@anonymous.invalid comme adresse de
l'appelant, même le simple nom de domaine pouvant révéler des
informations (section 4.1.1.3 du RFC 3323 et section 5.1.4 de
notre RFC). Les RFC 3325 et RFC 4244 fournissent
des méthodes supplémentaires.
Qu'apporte notre RFC 5379 ? Il ne change aucun protocole,
il explique simplement comment mieux utiliser les extensions de
maintien de la vie privée décrites dans les RFC précédents. C'est donc
un bon point de départ si on écrit un logiciel SIP soucieux de vie
privée. Ainsi, le
tableau de la section 4.1 résume de manière simple les actions qui
doivent être menées (ou pas) par les différents agents, selon le
niveau de protection demandé par l'utilisateur (ces niveaux avaient
été définis dans la section 4.2 du RFC 3323). Par exemple,
les en-têtes Via: (section 8.1.1.7 du RFC 3261) indiquent l'endroit où envoyer des
réponses, donc où se trouve l'appelant. Au niveau
header de protection de la vie privée, ils doivent donc
être « anonymisés », c'est-à-dire remplacés par un en-tête
Via: d'un relais (section 5.1 du RFC 3323 et 5.1.15 de notre RFC).
De même, la section 4.3 rappelle nettement le rôle de l'option
critical dans un en-tête
Privacy:. Elle indique que l'appelant préfère que
l'appel avorte plutôt que de transmettre des informations privées
(certains appelés refusent les appels où certaines informations
manquent et critical sert à indiquer s'il faut
accepter leurs exigences ou pas). Le RFC 3323 était nettement
moins directif sur cette option.
La section 5 résume le traitement de chaque en-tête sensible,
lorsque l'utilisateur demande le service de protection de la vie
privée. Ainsi, Contact: (section 5.1.3) est un
cas délicat car il doit être un URI qui pointe
réellement sur quelque chose (il sert à contacter le logiciel de
l'utilisateur). S'il
est remplacé, il doit donc l'être
par un URI qui marche, par exemple un système de relais de courte
durée de vie.
Certains en-têtes, moins utiles au fonctionnement de SIP, sont
traités plus violemment. C'est ainsi que la section 5.1.13 recommande
d'éliminer l'en-tête Subject: car elle peut être
trop révélatrice. Même chose pour User-Agent:
(section 5.1.14) qui indique le type de logiciel utilisé et qui peut
donc révéler des choses sur son propriétaire.
Première rédaction de cet article le 5 Février 2010
Le 12 janvier, Marc Tessier a remis au Ministère de la Culture son très intéressant rapport sur « La numérisation du patrimoine écrit », rapport qui s'inscrit dans le vieil affrontement entre les propositions de Google de numériser le fonds des bibliothèques (tout en mettant la main dessus) et les projets nationaux comme Gallica, riches en proclamations martiales et pauvres en contenu accessible.
Le titulaire actuel du poste de ministre, qui avait signé la lettre de mission, est un abyssal zéro, qui s'est récemment fait connaître par des déclarations « à la chinoise » sur les dangers des blogs (tous anonymes, forcément anonymes) pour l'harmonie de la société. Mais cela n'enlève rien à l'intérêt du document.
Le rapport ménage la chèvre et le chou, comme souvent dans les rapports officiels mais c'est déjà un progrès par rapport à un certain discours « astérixien » où les français ont toujours raison et où tout le mal vient des États-Unis, patrie du profit (comme si les éditeurs français n'étaient pas également des capitalistes ne pensant qu'au profit). L'ancien directeur de la BNF, Jeanneney, s'était fait une spécialité de ce discours.
Ainsi, l'offre de Google de numérisation des bibliothèques n'est plus, dans ce rapport, diabolisée bêtement, mais analysée sérieusement, avec ses forces (les moyens matériels de Google) et ses faiblesses (un certain désintérêt pour les méta-données, puisque Google compte surtout sur son moteur de recherche plein texte). Comme pour tout partenariat avec une entreprise capitaliste, le rapport appelle à la prudence lors des négociations et demande que celles-ci se fassent sur une base d'égalité entre partenaires. Aujourd'hui, Google approche souvent les bibliothèques comme un donateur approche des SDF, alors que Marc Tessier insiste sur le fait que chacun des partenaires a une compétence spécifique à apporter. Il demande également que les fichiers résultant de la numérisation soient distribuables par d'autres que Google, et critique les accords secrets imposés par Google.
À noter qu'une très bonne annexe concrète du rapport, l'annexe 3, faite par Alban Cerisier, rappelle les points techniques essentiels liés à la numérisation et aide à comprendre certaines questions qui pourraient paraître byzantines.
Surtout, ce qui est la première fois dans un rapport officiel, la supériorité de Google sur des offres franco-françaises comme Gallica n'est plus simplement présentée comme injuste mais aussi analysée comme le résultat des faiblesses de l'offre françaises. Les grands projets pilotés de manière ultra-bureaucratique, avec profusion d'acteurs et de réunions, puis délégation du vrai travail à une SSII n'ont pas toujours engendré une offre de qualité... Le rapport cite Gallica qui n'a toujours pas d'URL stables et référençables.
C'est ainsi que le rapport note à juste titre que Europeana n'est qu'une page d'accueil, une étiquette qui s'applique à plusieurs projets existants mais qui n'a aucun contenu propre. Bref, les européens ont du pain sur la planche.
Date de publication du RFC : Février 2010
Auteur(s) du RFC : P. Srisuresh (Kazeon Systems), B. Ford (MPT-SWS)
Pour information
Première rédaction de cet article le 4 Février 2010
Le NAT est depuis longtemps une des plaies de l'Internet. Justifié au début par le manque d'adresses IPv4, il est désormais de plus en plus utilisé en raison de l'épuisement des adresses v4, mais aussi sur des sites qui croient qu'il leur simplifie la vie, voire qu'il améliore leur sécurité. Une des conséquences du NAT tel qu'il est déployé pour IPv4 est que les adresses privées sont prises dans une réserve d'assez petite taille et qu'on voit désormais des cas de recouvrement d'adresses IP entre deux réseaux utilisant cette technique. Ce RFC décrit deux cas de cette catégorie.
L'utilisation « canonique » du NAT est avec un réseau local qui utilise des adresses privées du RFC 1918 et une seule adresse IP publique, attribuée par le FAI et affectée au routeur qui connecte le réseau local à l'Internet. Dans cette configuration (section 3.2.1), les limites et les problèmes du NAT sont bien connus. (Voir les RFC 2993, RFC 3424, RFC 5218, etc.) Mais, en raison du succès du NAT, on voit de plus en plus apparaitre des configurations moins classiques, qui apportent de nouveaux problèmes.
L'Internet avait été prévu pour un espace d'adressage unique
(section 1 du RFC), où chaque machine avait une adresse unique au
monde. Le déploiement souvent irrefléchi du NAT a mené à une
séparation
Identificateur/Localisateur de fait (et mal faite) : désormais, il existe
plusieurs machines sur l'Internet qui ont l'adresse
192.168.1.1.
Parmi les causes de ce déploiement du NAT :
Les problèmes que pose le NAT sont décrits dans le RFC 3027. Notre RFC 5684, lui, détaille deux cas problématiques, liés au déploiement de NAT emboîtés (passage par au moins deux routeurs NAT). Il s'appuie sur la terminologie du RFC 2663.
Le réseau théorique utilisé pour notre RFC est dessiné dans la figure 1, section 3.Il représente ces deux cas de NAT emboîtés. La facilité apparente de déploiement du NAT a une conséquence néfaste : comme il n'y a pas besoin de se concerter avec d'autres personnes, on voit de plus en plus des NAT emboîtés apparaître sans que cela résulte d'un choix délibéré, mais simplement de l'addition de décisions individuelles.
Si vous lisez le RFC, gardez bien sous la main tout le temps cette figure 1, elle vous servira.
Public Internet
(Public IP addresses)
----+---------------+---------------+---------------+----
| | | |
| | | |
192.0.2.1 192.0.2.64 192.0.2.128 192.0.2.254
+-------+ Host A Host B +-------------+
| NAT-1 | (Alice) (Jim) | NAT-2 |
| (Bob) | | (CheapoISP) |
+-------+ +-------------+
10.1.1.1 10.1.1.1
| |
| |
Private Network 1 Private Network 2
(private IP addresses) (private IP addresses)
----+--------+---- ----+-----------------------+----
| | | | |
| | | | |
10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 10.1.1.12
Host C Host D +-------+ Host E +-------+
| NAT-3 | (Mary) | NAT-4 |
| (Ann) | | (Lex) |
+-------+ +-------+
10.1.1.1 10.1.1.1
| |
| |
Private Network 3 | Private Network 4
(private IP addresses)| (private IP addresses)
----+-----------+---+ ----+-----------+----
| | | |
| | | |
10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11
Host F Host G Host H Host I
Figure 1. Multi-level NAT topology with Overlapping Address Space
Les ennuis commencent avec le pair à pair (section 3.1.2). Comme plusieurs machines ont la même « identité », la même adresse IP, les communications pair-à-pair sont difficiles. D'abord, pour se trouver, les machines vont avoir besoin d'un serveur extérieur, qui va organiser les rendez-vous. Ensuite, même si les machines apprennent l'adresse IP d'une autre via ce serveur, elles ne pourront pas forcément la contacter, en raison de l'absence d'adresse unique. Par exemple, une machine pourra contacter, à la place du pair convoité, une autre machine de son réseau local, qui aura la même adresse IP que le pair qu'on veut joindre.
Ann et Lex ont même un problème supplémentaire, qui fait l'objet de la section 3.2.2 : il y a duplication des adresses IP. Plusieurs machines ont la même adresse, car l'allocation n'est pas coordonnée et l'espace du RFC 1918 étant très petit, les collisions sont inévitables. Si les routeurs d'Ann et de Lex tentent d'utiliser le classique ARP sur toutes leurs interfaces, ils peuvent obtenir des réponses différentes selon l'interface. Une telle configuration, qui marchera a priori (« Je peux voir YouTube », en raison du NAT) produira des phénomènes bizarres et difficilement explicables à première vue.
Le fait qu'il y aie plusieurs niveaux de NAT dans ces cas cause également d'autres surprises (section 3.2.3), comme le fait que les machines aux adresses privées peuvent communiquer avec l'Internet mais pas entre elles, même lorsqu'elles sont clientes du même FAI. Parfois, une communication est possible via le routeur NAT, si celui-ci permet les connexions « en épingle à cheveux » (où le paquet va au routeur de sortie puis tourne en épingle à cheveux pour revenir vers le réseau privé). Les RFC 4787 et RFC 5382 demandent qu'un tel routage soit possible.
Mais, même lorsque « ça marche », la configuration reste bancale. Ainsi, on ne peut plus utiliser l'adresse IP d'une machine, normalement unique, comme identité (section 3.2.4). Cela fait que les paquets peuvent être transmis à la mauvaise machine. Le RFC donne l'exemple d'un résolveur DNS. S'il utilise des adresses privées et qu'un des réseaux locaux connectés utilise des adresses de la même plage, les machines de ce réseau ne pourront pas joindre leur résolveur. Le RFC recommande donc que les serveurs vitaux, comme le résolveur DNS, reçoivent toujours des adresses globales.
Un autre cas où des recouvrements des plages d'adresses IP peut se produire est celui des VPN, dans la section 4. Quelle que soit la technologie utilisée pour les réaliser (IPsec, L2TP, etc), le VPN donne accès à un réseau dont les adresses sont souvent privées. Si, sur son réseau d'attachement physique, le client VPN utilise également des adresses privées, le risque de collision est important. Un exemple que cite le RFC en section 4.2.1 est celui où le serveur DHCP du réseau local de la machine cliente a la même adresse (privée...) qu'une machine du réseau distant. Au moment de renouveler le bail DHCP, les paquets iront sur le site distant et pas sur le réseau local... Le RFC recommande donc que les paquets à destination des adresses IP du serveur DHCP et du premier routeur ne soient jamais envoyées à travers le VPN, même dans le cas où celui-ci est configuré pour faire passer la totalité du trafic, ce qu'on nomme le non-split VPN, et qui est souvent préféré pour des raisons de sécurité. Le RFC conseille aussi de garder la possibilité du split VPN (où seul les paquets à destination du réseau de l'entreprise sont routés via le VPN), qui limite les risques de collision.
La section 5 reprend et résume les recommandations de notre RFC 5684. Elles viennent en sus de celles des RFC 4787, RFC 5382 et RFC 5508. Si elles sont suivies, les conséquences de l'adressage privé seront minimisées.
Si elles ne le sont pas, plusieurs accidents auront lieu, parfois avec des conséquences néfates pour la sécurité (section 7), comme l'envoi de paquets à une machine autre que celle à qui ils étaient normalement destinés. Le RFC conseille de toute façon d'avoir également une authentification forte et de ne pas se fier uniquement à l'adresse IP source.
Ah, un dernier conseil, personnel : pour limiter le risque de
collisions lorsque vous utilisez des adresses RFC 1918, n'utilisez pas le début des plages. Pour vous éloigner
des autres, numérotez avec un numéro « haut », choisi au hasard, par
exemple avec 10.198.200.0/22 ou
10.243.24.0/22 plutôt qu'avec le banal
10.1.0.0/24 que tout le monde utilise...
Première rédaction de cet article le 3 Février 2010
Dans le numéro de février 2010 des Communications of the ACM, un article de Michel Beaudoin-Lafon, « Viewpoint: Open Access to scientific Publications », discute du mouvement d'un grand nombre de publications scientifiques vers le modèle de l'OpenAccess et formule plusieurs critiques contre certains aspects de ce modèle. La principale critique est basée sur une curieuse estimation des coûts de ce modèle.
Traditionnellement, la publication d'articles scientifiques se fait dans des revues contrôlées par des éditeurs privés, dont le mastodonte Elsevier, qui est à la publication scientifique ce que Microsoft est au logiciel. Ces revues ne paient pas les auteurs, ni les relecteurs, les personnes qui relisent les articles. Par contre, les universités et centres de recherche paient l'abonnement à ces revues alors qu'elles ont fourni l'essentiel du contenu gratuitement. Comme le rappelle Beaudoin-Lafon, ce n'est pas une pure question financière, ce modèle a un autre problème, c'est la privation de droits qui fait qu'un scientifique ne peut pas faire circuler librement un article, même lorsqu'il en est l'auteur.
Ce modèle moyenâgeux s'est maintenu par conservatisme, par idéologie (permettre la publication directe par les scientifiques fait peur à certains habitués du contrôle) et parce que les institutions qui évaluent les scientifiques, par exemple pour leur avancement, ne prennent souvent en compte que les publications dudit scientifique dans ce genre de revues.
Néanmoins, le monde change, l'Internet supprime les obstacles matériels à la diffusion directe des résultats scientifiques, et de nombreux chercheurs se sont engagés dans la lutte contre cette oligarchie d'éditeurs, par exemple sous la bannière de l'OpenAccess.
Beaudoin-Lafon appelle à la prudence vis-à-vis de ce mouvement, notamment en invoquant un motif de coût. Publier n'est pas gratuit et des éditeurs OpenAccess comme PLOS font payer les auteurs pour cela, des sommes que je trouve astronomiques, de 1 000 à 2 000 $ US. Beaudoin-Lafon pointe à juste titre les risques associés à un tel modèle où l'auteur doit être riche pour publier. Mais il ne remet pas en question l'évaluation des coûts par exemple en citant sans critique le chiffre de plusieurs millions de dollards dépensés par l'ACM pour sa propre bibliothèque numérique.
Il y a là un curieux « point aveugle ». Voyons d'abord quels sont les coûts de la publication :
Aujourd'hui, où un particulier comme moi peut financer l'hébergement de son blog sur son seul salaire et le servir en n'utilisant quasiment que des logiciels libres, déjà développés et mis au point, ces coûts sont nettement plus bas qu'autrefois.
Mais Beaudoin-Lafon a l'air de dire que ces coûts sont obligatoires et incompressibles. Ce n'est pas le cas. Personne n'a demandé à l'ACM ou à toute autre institution scientifique de tout publier sur son propre budget, sur une plate-forme ultra-rapide, avec des logiciels très perfectionnés. Ce qui est demandé aux éditeurs est de permettre un accès libre (Beaudoin-Lafon suggère, à juste titre, des licences de type Creative Commons). Une fois que cet accès est fourni, même sur un petit serveur surchargé et avec zéro fonction de recherche intéressante dans les articles, le Web 2.0 fera le reste. Des centaines de gens dans le monde ne demandent pas mieux que d'héberger gratuitement des copies de telles bibliothèques numériques, de développer des outils de recherche perfectionnés, etc. Il y aura même une participation du secteur privé (Google et Bing fourniront un moteur de recherche gratuit, du moment que le contenu est accessible).
C'est le principal manque de l'article « Viewpoint: Open Access to scientific Publications » : il considère comme acquis que le public est un réceptacle passif d'information et que l'émetteur (ACM, PLOS, etc) doit donc lui fournir un système complètement fini et de qualité parfaite. L'Internet nous a appris le contraire : si on publie un travail brut, peu fini, des tas de gens ne demandent pas mieux, si la licence le permet, de le perfectionner et d'en faire un outil qui concurrence les services traditionnels.
L'émetteur devrait donc se concentrer sur ce qu'il fait bien (Beaudoin-Lafon cite la question cruciale de la permanence de l'accès, là où un blog individuel peut disparaître du jour au lendemain) et ne pas dépenser « des millions de dollars » dans des projets pharaoniques. Publier des données sous un format ouvert, structuré (pour le Web des données), sous une licence libre, et le reste se fera tout seul.
J'avais défendu une telle position à l'UIT des années avant que cette organisation dinosaurienne ne publie ses normes gratuitement et les « experts » de l'UIT avaient tous trouvé cette idée ridicule, donnant comme principal argument qu'on ne pouvait pas se contenter de publier les normes, il fallait forcément payer une SSII très cher pour développer une usine à gaz logicielle tout autour. À leur décharge, ils écrivaient cela avant le Web 2.0, Wikipédia et le Web des données. Aujourd'hui, on sait qu'on n'est pas tout seul, qu'on n'est pas obligés de tout faire et que la « communauté » peut aider.
Merci à Catherine Letondal pour m'avoir signalé cet intéressant article.
Auteur(s) du livre: Xavier Carcelle
Éditeur: Eyrolles
978-2-212-11930-5
Publié en 2006
Première rédaction de cet article le 2 Février 2010
Il existe peu de livres sur les CPL et je crois que celui-ci est le seul en français (une bibliographie des équivalents en anglais figure à la fin de l'ouvrage). Cette technique est en général sous-estimée et beaucoup de déploiements de réseaux locaux ou distants ne l'envisagent même pas. Pourtant, elle a de nombreuses propriétés intéressantes. (J'ai décrit mon utilisation dans « CPL (Courants porteurs en ligne) à la maison ».)
Comprendre les CPL nécessite des compétences
en électricité, en
informatique et en
réseaux. Ce livre a donc un vaste champ à
couvrir. Je vais commencer par ce qui est le moins bien couvert : la
partie sur la configuration d'IP est faible (chapitres 10 et 11), surtout composée de copies
d'écran (qui permettent de remplir les pages à bon marché). Même les
commandes tapées dans un xterm sont montrées
sous forme de copie d'écran, intéressant paradoxe. Cette
partie « réseaux »
contient des archaïsmes étonnants pour un livre récent (comme la
discussion des classes,
supprimées onze ans avant la parution du livre, ou comme la commande
ipchains de Linux,
complètement remplacée par iptables depuis belle
lurette). Par contre, IPv6, technologie stable
depuis longtemps, ne fait l'objet d'aucune mention, alors qu'elle est
particulièrement utile dans le cas des réseaux domestiques, où on a
plusieurs objets à connecter et jamais assez d'adresses IPv4.
D'un autre côté, j'ai apprécié que l'auteur fasse un effort pour ne pas parler uniquement de MS-Windows, comme tant de livres « pour les nuls ». Il y a même une discussion de la configuration d'un réseau sur FreeBSD, ce qui est rare pour un ouvrage destiné à un public assez large. Mais, globalement, toutes les parties du livres consacrées à IP donnent l'impression que l'éditeur a demandé qu'on en parle, mais que l'auteur n'était pas le plus à l'aise sur ce sujet.
Et sur l'électricité ? Étant plutôt rouillé sur ce sujet, mes cours de physique étant assez lointains, j'espérais une révision mais j'ai été un peu déçu. Le livre suppose qu'on s'y connait déjà en électricité et qu'on n'a pas besoin de se faire expliquer trop longuement l'impédance ou la capacité (chapitres 2 et 8).
Une des difficultés qui se dressent sur le chemin de l'auteur d'un livre sur les CPL est que le domaine est peu normalisé (chapitre 1). S'il existe un consortium industriel nommé Homeplug qui édicte des spécifications de base pour les CPL domestiques, il n'y a pour l'instant aucune norme réelle (produite par exemple par l'IEEE). Résultat, l'auteur est souvent obligé de présenter des techniques spécifiques à un constructeur. Mais il a fait l'effort de ne privilégier aucun constructeur et de bien préciser ce qui est « standard » et ce qui ne l'est pas.
Par exemple, même avec Homeplug, la configuration des adaptateurs est entièrement faite par des protocoles non-standard. Il existe toutefois des interfaces communes qui commencent à émerger et c'est dans ce livre (chapitre 9) que j'ai appris l'existence de l'excellent outil plconfig qui marche bien sur ma Debian :
% plconfig -r eth1 - Parameters and Statistics response from 00:0c:b9:09:b7:ed Tx ACK Counter: 45547 Tx NACK Counter: 18848 Tx FAIL Counter: 5 Tx Contention Loss Counter: 33611 Tx Collision Counter: 13485 Tx CA3 Latency Counter: 3463 Tx CA2 Latency Counter: 34789 Tx CA1 Latency Counter: 4109 Tx CA0 Latency Counter: 0 Rx Cumul. Bytes per 40-symbol Packet Counter: 13628962 ...
Pour les explications des compteurs, la meilleure source que j'ai trouvée en ligne est la MIB de Homeplug.
La partie « couche 2 » est bien meilleure (chapitres 3 et 5), avec une intéressante discussion des différents modes de communication entre adaptateurs CPL (du pair-à-pair de Homeplug au mode maître-esclave), et une présentation détaillée les mécanismes d'accès au réseau (CSMA/CA, dont il oublie toutefois de noter que c'est un terme marketing : il y a aussi des collisions en CSMA/CA).
J'ai aussi apprécié la section sur le rayonnement radio des CPL (chapitre 8) ou bien le chapitre 12 sur la création d'un réseau CPL pour une collectivité locale, même si ce dernier restera purement théorique pour moi.
Du fait de l'intérêt des technologies CPL, et du petit nombre de documents existants, je ne regrette pas d'avoir acheté ce livre et je remercie l'auteur pour l'effort qu'il a fait pour diffuser de l'information sur une technique peu connue. Mais je pense quand même qu'il reste de la place pour un livre plus pédagogique.
Première rédaction de cet article le 28 Janvier 2010
Pendant que les moutons fidèles de Steve Jobs se pressaient pour le voir présenter un nouvel engin ultra-fermé et contrôlé par Apple, un autre évenement suscitait de nombreux articles (moins nombreux, quand même), le début de diffusion des signatures par les serveurs racines du DNS. Ce processus avait été annoncé en octobre dernier et, jusqu'à présent, suit à peu près son cours.
Hier soir (heure française), un serveur racine a commencé à
diffuser des informations signées avec
DNSSEC. C'est
L.root-servers.net, géré par
l'ICANN qui s'y est collé pour être le
premier. Le déploiement progressif (jusqu'en juillet), permet aux
administrateurs réseaux de vérifier leur
configuration, même si eux-mêmes ne font pas de
DNSSEC. Ils doivent en effet s'assurer que leur réseau
laisse passer les réponses DNS de grande
taille.
Les autres serveurs racines suivront petit-à-petit, selon le plan publié sur le site officiel. En mai, certains des réseaux qui ont une configuration boguée (bloquant les résponses supérieures à 512 octets ou bien ne gérant pas la fragmentation) n'auront plus d'accès au DNS.
Quelques observations amusantes ou intéressantes. La réponse
envoyée par L.root-servers.net atteint désormais
dans les 600 octets pour une question typique (celle qui mène à une
référence vers un TLD, par exemple
dig AAAA www.bortzmeyer.fr), mais
1900 octets si on demande toutes les informations (dig ANY
.). À cause de la taille des enregistrements
NSEC, les demandes pour les TLD inexistants sont
un peu plus grosses que les références (dans les 650 octets). Et la
requête initiale des résolveurs (priming),
dig NS ., atteint maintenant 800 octets.
Comme annoncé, la clé publiée n'est pas celle de signature et on ne peut donc pas encore valider la racine :
% dig +dnssec +multi @L.root-servers.net DNSKEY . ; <<>> DiG 9.5.1-P3 <<>> +dnssec +multi @L.root-servers.net DNSKEY . ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47275 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN DNSKEY ;; ANSWER SECTION: . 86400 IN DNSKEY 256 3 8 ( AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/ KEY/AND/SHOULD/NOT/BE/USED/CONTACT/ROOTSIGN/ AT/ICANN/DOT/ORG/FOR/MORE/INFORMATION+++++++ +++++++++++++++++++++++++++++++++++++++++++8 ) ; key id = 23763 . 86400 IN DNSKEY 257 3 8 ( AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/ KEY/AND/SHOULD/NOT/BE/USED/CONTACT/ROOTSIGN/ AT/ICANN/DOT/ORG/FOR/MORE/INFORMATION+++++++ ++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++8= ) ; key id = 19324 . 86400 IN RRSIG DNSKEY 8 0 86400 20100204235959 ( 20100121000000 19324 . NO9bHgWYB3wQlVZXQKwDGUjTgIyfz1i8aWH8nBlT5isn Ybr6PTfR4fWlSx8+avFfR0fVekauaQelKOyiUav4H9Y1 AZ2OBguu7RjozQu1qErKboWd1NglIIOGar0Ol4Ur9+4b o2LSxjp/X4ESypW0lX04z5uB6DZZei1zafzRGUnLIMdV 9xdKEOJrm9UCKvYK5g8bjRq8KA8vT+pidexZMrBQ3ie8 R9daf/s6VK7zUJK0jF1vqhPbZFSQmBpJUlxh4VnOv7nn hcq4Moj49wqmNxKRqfvSwHAJBG6dEgShnlu/rfVsdxfF UCjIGX8YnSC7lYqODwgUGh+i/arAAK+bzg== ) ;; Query time: 135 msec ;; SERVER: 2001:500:3::42#53(2001:500:3::42) ;; WHEN: Thu Jan 28 09:31:22 2010 ;; MSG SIZE rcvd: 736
Plusieurs organisations ou personnes ont déjà publiées d'intéressantes statistiques. Par exemple, l'OARC a publié « L-Root now serving "DURZ" signed responses » avec des jolis graphiques qui montrent notamment :
L'ICANN rend aussi publiques les statistiques de son serveur racine et
on peut voir en http://stats.l.root-servers.org/
(attention, il y a trois sites
physiques, prg, mia
et lax3) que rien n'a cassé.
Première rédaction de cet article le 27 Janvier 2010
L'IETF vient de créer un groupe de travail sur le création d'un codec audio libre. Le groupe Internet Wideband Audio Codec (dit simplement codec) commence ainsi une existence qui sera certainement agitée.
Le projet de création de ce groupe avait été un des points chauds de la réunion IETF d'Hiroshima en novembre 2009. Suivant cette réunion, de très longs débats avaient eu lieu en ligne, et ont mené, le 26 janvier, à l'annonce par l'IESG de la création de ce groupe, membre du secteur « Applications et infrastructure temps-réel ». Ses présidents sont Michael Knappe et Peter Saint-Andre (M. XMPP).
Quel est le problème à résoudre ? Il existe un grand nombre de codecs pour le son. Aucun n'est particulièrement enthousiasmant pour l'IETF et cela rend plus difficile le fonctionnement d'applications sonores sur l'Internet. L'IESG pointe trois gros points qu'aucun des codecs existants ne satisfait complètement :
Résultat, bâtir une application ou un service utilisant le son sur l'Internet reste encore trop difficile. Les services les plus répandus sont en général fermés (comme l'ultra-contrôlé Skype).
La charte du groupe est donc la création d'un codec combinant ces trois qualités. Il est probable qu'il faudra le développer en partant de zéro, mais la charte n'exclut pas la possibilité d'adopter un codec existant, si on trouve le mouton à cinq pattes. (Je ne m'y connais pas assez pour déterminer si Vorbis ou Speex sont des bons candidats.)
Les exigences techniques impliquent notamment une bonne adaptation aux protocoles interactifs (avec, par exemple, adaptation dynamique de la qualité sonore à la capacité réseau disponible), et une bonne interaction avec les protocoles IETF existants comme RTP et SIP.
Le travail devra se faire en liaison avec l'UIT, notamment son Study Group 16, avec l'idée de tenter une publication commune de la future norme. Le résultat n'est pas garanti car les précedentes collaborations entre l'IETF et l'UIT ont parfois été orageuses (cf. RFC 5704).
Mais les brevets seront certainement le principal obstacle sur le chemin du futur codec, le monde de l'audio étant truffé de brevets futiles, acceptés par des offices des brevets paresseux, incompétents ou simplement intéressés à ce que le maximum de brevets soit déposé. La charte du groupe de travail prévoit, en cohérence avec les RFC 5378 et RFC 3979, de donner la priorité à un codec non encombré par des brevets.
Le calendrier de développement prévu est assez ambitieux, vue l'ampleur du projet (et l'IETF n'est pas connue pour le respect des calendriers...). Il est prévu que le gros du travail technique soit terminé à l'été 2011.
Quels étaient les problèmes qui ont suscité tant de discussions à l'IETF ? Il y avait la crainte que des codecs existants soient écartés d'avance au profit de la tâche lourde et complexe du développement d'un nouveau codec (d'où la mention dans la charte qu'un codec existant peut être utilisé, s'il correspond au cahier des charges, d'autant plus que la situation peut changer, par exemple sur la question de la politique de licence). Il y a eu aussi un gros débat sur la possibilité de produire un codec meilleur que tous les existants, tout en le gardant libre (cela parait irréaliste). Et, bien sûr, il y a eu de longues polémiques sur la politique de l'IETF par rapport aux brevets...
Première rédaction de cet article le 26 Janvier 2010
Le 12 janvier, discrètement, l'une des fonctions les plus anciennes de l'Internet, celle d'éditeur des RFC, a changé de main.
Depuis le début (le RFC 1 date de 1969), la fonction de « RFC editor », le relecteur, le publicateur et le gardien de ces textes sacrés de l'Internet était à l'ISI, d'abord sous la forme d'une personne, Jon Postel, puis sous celle d'un petit groupe (l'ISI a récemment publié un bilan de son action). Un mécanisme d'abord assez informel, assuré avec sérieux (et conservatisme) par des gens connus et jouissant de la confiance de l'IETF. Désormais, suite à un appel d'offres, la fonction est plus classiquement traitée par une organisation qui a reçu formellement la délégation : AMS, une organisation spécialisée dans la gestion de SDO dans le monde des réseaux informatiques (mais il y avait d'autres candidats).
Première rédaction de cet article le 26 Janvier 2010
Le 26 janvier à l'AFNIC, j'ai participé à un séminaire sur la « Veille sur l'Internet ». J'ai surtout insisté sur la distinction entre la source (la personne ou organisation qui émet l'information), le canal (le mécanisme par lequel l'information est transportée) et l'outil (le logiciel utilisé pour la visualisation). Comprendre les différences et les articulations entre ces trois concepts permettrait de mieux évaluer l'information reçue et éviterait de dire (comme je l'ai parfois entendu) « Je l'ai lu sur Internet », voire « Je l'ai lu sur Google ».
Mais j'ai aussi parlé des outils et il y a même eu la traditionnelle démo à la fin, avec Liferea et pidgin. Voici les transparents présentés :
veille-internet-transparents.tex.Première rédaction de cet article le 24 Janvier 2010
Dernière mise à jour le 1 Février 2010
Je cherche un moyen de trouver l'adresse IP avec laquelle mon serveur de noms interroge le monde extérieur. C'est bien plus compliqué que cela n'en a l'air.
Lorsque j'appelle www.example.org,
l'application que j'utilise (que ce soit
Firefox ou curl) fait
appel (en général via le sous-programme
getaddrinfo()) à un résolveur DNS ; sur Unix, son
adresse est trouvé dans /etc/resolv.conf. Il y a
des fois où j'aimerai bien savoir quelle adresse utilise ce résolveur
pour interroger les serveurs faisant autorité. On
ne peut pas simplement prendre l'adresse qui se trouve dans
/etc/resolv.conf pour au moins trois raisons :
Je vois trois façons possibles de trouver l'adresse utilisée par la résolution de noms :
forwarder et query-source sur
BIND. Cela ne marche que si on accès à cette
configuration, ce qui n'est pas le cas de tout le monde.nexistepas.MAZONE (il vaut mieux utiliser un nom
non existant pour ne pas risquer qu'il soit dans le
cache d'un résolveur). Cela oblige à avoir une
zone dont on contrôle tous les serveurs de noms et ce n'est pas très pratique.Mais un tel service existe t-il ? Aucun serveur de noms standard ne sait faire cela, il faut donc écrire un serveur adapté. Par manque de temps, je cherche un service déjà existant.
Le premier testé est celui créé par l'OARC pour un tout autre but,
replysizetest
et disponible en rs.dns-oarc.net et
rs.ripe.net. Ignorons le but principal de ce
service, ce qui m'intéresse ici est qu'il donne l'adresse IP de son
client DNS. Ainsi, depuis Free, j'obtiens :
% dig +short TXT rs.dns-oarc.net ... "213.228.63.32 sent EDNS buffer size 4096"
donc le résolveur de Free sort avec l'adresse IP
213.228.63.32. Et Google
DNS :
% dig +short TXT rs.dns-oarc.net ... "209.85.228.94 lacks EDNS, defaults to 512"
On voit qu'il n'utilise pas en sortie les fameuses
8.8.8.8 et 8.8.4.4.
À noter qu'il fonctionne également avec IPv6 (contrairement à ce que j'avais écrit dans une précédente version de l'article).
À noter également que l'OARC a un outil équivalent qui avait également été fait dans un autre but (détecter les résolveurs vulnérables à la faille Kaminsky) et qui peut également être « détourné » pour nos recherches :
% dig +short porttest.dns-oarc.net TXT porttest.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.134.4.162 is GREAT: 26 queries in 3.9 seconds from 8 ports with std dev 21270"
Même chose pour le service de test des résolveurs ouverts (merci à Nicolas Aupetit) :
% dig +short amiopen.openresolvers.org TXT "Your resolver at 192.134.7.248 is CLOSED"
Ce service est-il une solution parfaite ? Outre qu'il est un peu lent car il fait bien autre chose que renvoyer l'adresse IP, je regrette qu'il ne puisse pas renvoyer une adresse binaire (en réponse à une question de type A ou AAAA).
Les entreprises qui font du
load-balancing ont souvent
des noms qu'on peut résoudre dans le DNS pour obtenir l'adresse IP du
résolveur, à des fins de déboguage. C'est le cas de
whoami.ultradns.net et de
whoami.akamai.net. Ces deux services ont
l'avantage de renvoyer l'adresse IPv4 en binaire (il faut donc faire
une requête de type A et pas TXT), ce qui est pratique.
Celui d'UltraDNS a l'inconvénient de planter complètement avec des adresses IPv6
(renvoyant NXDOMAIN au lieu du normal
NODATA, ce qui est une bogue énorme
% dig AAAA whoami.ultradns.net ... ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51301 ...
mais celui d'Akamai semble bien marcher.
Encore mieux, le service de Cedexis (merci à Stéphane Enten),
1-01-2743-000d.cdx.cedexis.net. Si le nom est un
peu bizarre (le service ne semble pas encore stabilisé et plante parfois), le réflecteur
marche très bien, renvoyant un CNAME vers un nom qui code le client, indiquant même le numéro d'AS :
% dig +short A 1-01-2743-000d.cdx.cedexis.net client-ip-208.75.84.80--client-asn-23372.
Je continue à chercher. Si vous avez des idées...
Date de publication du RFC : Janvier 2010
Auteur(s) du RFC : R. Després
Pour information
Première rédaction de cet article le 24 Janvier 2010
Contrairement à ce que prétendent certains ignorants, la délicate question de la période de transition entre IPv4 et IPv6 n'a jamais été négligée à l'IETF. Bien au contraire, plusieurs mécanismes ont été normalisés pour assurer le passage d'un protocole à l'autre. Le mécanisme « RD », décrit dans ce RFC 5569, est un de ces mécanismes, modifiant le 6to4 du RFC 3056 pour garantir un chemin de retour symétrique aux paquets IP. RD permet à un FAI de vendre un service IPv6 alors que son réseau interne est essentiellement IPv4. Il est surtout connu pour être la technologie déployée par Free à partir de décembre 2007.
S'il existe plusieurs mécanismes de coexistence d'IPv4 et d'IPv6, c'est parce que les besoins sont différents. Certains FAI ont un réseau interne entièrement IPv6 depuis de nombreuses années comme Nerim. D'autres n'ont pas encore commencé le déploiement. Parfois, le FAI est en avance sur ses clients, parfois c'est le contraire comme c'était le cas pour Free où de nombreux utilisateurs réclamaient IPv6 depuis longtemps. Il existe donc une variété de techniques de coexistence v4/v6. RD se positionne pour le cas où le FAI :
La section 1 du RFC décrit ainsi comment Free a migré vers 6RD fin 2007 (un autre compte-rendu a été fait par Alexandre Cassen à la réunion RIPE-58 à Amsterdam). Il a fallu mettre à jour le logiciel de la Freebox et ajouter des serveurs relais 6RD en sortie mais il n'a pas été nécessaire de toucher aux DSLAM (qui ne gérent malheureusement pas IPv6).
La section 2 revient plus en détail sur le cahier des charges :
casser le cercle vicieux courant avec IPv6 où les FAI n'installent pas
IPv6 parce que leurs clients ne le demandent pas et où les clients ne
se mettent pas à IPv6 parce que peu de FAI le transmettent. Le
protocole « idéal » semblait être 6to4 du RFC 3056. Simple, déjà mis en œuvre, y compris en logiciel
libre et sans état (chaque paquet est traité indépendamment) donc
passe bien à l'échelle. Mais il a des limites, notamment le fait le
retour du paquet n'est pas garanti : la machine avec laquelle on
communique va chercher son propre relais 6to4 et ne va pas forcément
en trouver un. RD est une modification de 6to4 pour utiliser comme
préfixe, non plus le préfixe 6to4 commun à tous de
2002::/16 mais un préfixe par FAI. Ainsi, le FAI
doit désormais lui-même installer des relais, il ne peut plus se
reposer sur les relais existants mais, en contre partie, il contrôle
complètement le routage, y compris sur le chemin du retour et se
retrouve ainsi dans un cas plus classique où ses routeurs servent ses
clients (alors que, avec 6to4, tout le monde sert tout le monde, ce
qui est très bien lorsque cela marche).
On peut se poser la question de savoir s'il s'agit vraiment d'IPv6 « natif ». Sans doute pas (le paquet circule dans le réseau de Free encapsulé IPv4, ce qui réduit la MTU à 1480 octets).
Une fois ce principe posé, la section 3 spécifie le protocole, très proche du 6to4 du RFC 3056. Les acteurs sont :
6to4 soulève traditionnellement des gros problèmes de sécurité, documentés dans le RFC 3964. 6RD en supprime certains, si l'implémentation suit les recommandations de la section 5, et effectue les vérifications demandées, mais l'usurpation d'adresse IP demeure relativement facile.
Le déploiement de 6RD chez Free a permis à la France de faire un bond dans les statistiques IPv6 comme l'a montré le rapport de Lorenzo Colitti (Google), Global IPv6 Statistics - Measuring the Current State of IPv6 for Ordinary Users.
Mais la normalisation de 6RD est aussi l'occasion de voir le processus IETF en action, lorsque l'auteur de la proposition n'est pas un habitué de l'IETF et n'a pas la culture « maison », ce qui était le cas de Rémi Després, un des concepteurs de Transpac, et qui a eu le courage de se plonger dans un monde bien différent, ce qui est toujours plus difficile que de rester seul dans son coin à expliquer qu'on a raison. Comme avec n'importe quelle organisation humaine, l'intégration du « petit nouveau » ne s'est pas fait sans mal mais, finalement, le RFC a été publié.
(Petite note au passage: ce RFC n'a que le statut de « Pour information » et la « vraie » norme IETF sur ce protocole n'apparaitra que plus tard. Notre RFC 5569 décrit le déploiement actuel, un « meilleur » protocole est en préparation.)
Il est resté de nomnbreux mois dans la file d'attente du RFC Editor, en raison de son statut de « soumission indépendante », dont les droits n'ont pas été définis avant le RFC 5744. Mais l'approbation technique était ancienne, datant d'avril 2009. Comme l'avait signalé l'auteur, dans son coup de gueule en séance plénière de l'IETF à Hiroshima en novembre 2009, « Ce RFC décrit comment déployer IPv6 en cinq semaines et voilà cinq mois qu'il attend, pour des raisons non-techniques. »
Première rédaction de cet article le 22 Janvier 2010
En 2007 est paru l'article « Some thoughts on security after ten years of qmail 1.0 », de Dan Bernstein, sur la sécurité des logiciels. Comme toujours avec cet auteur, l'article mélange bonnes idées, mauvaises idées et franche mauvaise foi.
Bernstein n'a pas changé sur un point, la malhonnêteté intellectuelle. Ainsi, en discutant de la sécurité des MTA, il tape uniquement sur sendmail, qui n'est plus guère utilisé sur les nouveaux sites, et ne dit pas un mot de Postfix, Exim ou Courier. Et pour cause, cela démolirait sa thèse comme quoi qmail est le seul MTA sûr...
D'autre part Bernstein se vante lourdement et tout le temps du défi de sécurité qu'il avait lancé pour qmail en mars 1997 : le principe est d'offrir une récompense monétaire à celui qui trouvera une faille de sécurité dans qmail. La récompense attend toujours qu'on la réclame. Mais ce genre de défis ne vaut pas grand'chose. D'une part, l'absence de signalement peut indiquer l'absence d'intérêt et pas l'absence de bogue (c'est courant pour les logiciels peu utilisés). Mais, surtout, ce genre de défis est en général soumis à des règles fixées par l'auteur et soigneusement conçues pour qu'on ne puisse jamais s'y conformer. Ainsi, le défi de sécurité qmail exclut les attaques par déni de service, de loin les plus fréquentes. Cela me rappelle un contrat de maintenance d'une entreprise privée pour s'occuper d'un serveur Windows où le contrat excluait les dommages liés aux virus. Exclure les conséquences des virus de l'administration d'une machine Windows, c'est comme exclure les dégâts des eaux du contrat de maintenance d'un sous-marin...
Mais est-il possible d'inclure les attaques par déni de service dans les conditions d'un tel défi ? Ce n'est pas une question facile : il existe deux sortes d'attaques par déni de service, celles qui reposent sur la force brute (on a une ligne rapide et une grosse machine et on écrase la victime sous le poids, par exemple en envoyant des millions de paquets) et celles qui reposent sur l'amplification, où un trafic faible pour l'attaquant peut faire beaucoup de dégâts. Par exemple, la faille dynamic update de BIND en juillet 2009 était dans cette catégorie : un seul paquet DNS pouvait stopper complètement le serveur. S'il n'y a pas de méthode générale pour faire face aux attaques par force brute, en revanche, on peut éviter les amplifications, les attaques où l'assaillant peut obtenir des résultats sans disposer des dizaines de milliers de machines d'un botnet. Il n'y a donc pas de raison d'exclure toutes les attaques par déni de service. Mais on comprend mieux cette décision de Bernstein quand on voit qu'une telle faille de sécurité a déjà été trouvée pour qmail... et refusée par l'auteur. Bref, les défis de sécurité lancés par l'auteur d'un logiciel ne servent pas beaucoup, il rejetera toujours les bogues trouvées. (Une liste des bogues de qmail est disponible, plusieurs affectant la sécurité.)
Maintenant, quelles sont les idées intéressantes dans ce papier ? Parmi les principales, il y a l'idée que les bogues dans le code sont inévitables mais ne devraient pas forcément être des failles de sécurité. Si le code, par exemple le code d'analyse des en-têtes d'un message, a une bogue, elle va empêcher l'analyse correcte desdits en-têtes mais elle ne devrait pas pouvoir mener à une attaque du système. Bernstein ne les cite pas, mais c'est une des motivations derrière les langages purs, comme Haskell, où le code, par défaut, ne peut pas avoir d'effets de bord. L'idée de base est que le code d'analyse des en-têtes devrait avoir des entrées et des sorties limitées et aucun accès au système (ce qui est très difficile à assurer dans un langage comme C).
Bernstein s'attaque aussi à certaines idées fausses en sécurité comme le fait de corriger les bogues (alertes de sécurité accompagnées de patches) : cela revient à résoudre les attaques d'hier, alors qu'il faudrait plutôt travailler à rendre plus difficiles celles de demain.
Comme beaucoup de programmeurs expérimentés, Bernstein met en garde contre l'optimisation prématurée, cette tendance à se préoccuper de performance sans avoir mesuré (et c'est un des rares points où il fait une auto-critique, à propos de l'optimisation du mécanisme de stockage de la liste des domaines gérés par qmail). Il plaide donc fortement pour faire passer la sécurité avant la performance, surtout si on n'a pas réellement mesuré le coût en performance d'une mesure de sécurité.
Bernstein suggère aussi des pistes pour limiter le nombre de bogues. Un exemple serait un mécanisme dans le langage de programmation pour mettre à jour automatiquement les variables « de résumé » (comme « le nombre d'éléments non nuls de la liste », sans doute du genre de ce que permettent les triggers de SQL. De même, il appelle de ses vœux des mécanismes pour étendre automatiquement les tableaux (mais sans citer les langages qui font déjà cela depuis longtemps comme Perl).
Parmi les autres idées de Bernstein, concevoir systématiquement les
langages de programmation de façon à ce que les programmes bogués soient plus
durs à faire que les programmes corrects. Il cite l'exemple de
l'addition d'entiers. En
C, par défaut, l'addition se fait
modulo la taille de int et
il faut explicitement utiliser une bibliothèque de
bigint pour avoir l'addition courante. Cela
devrait être le contraire, les cas où on veut vraiment une addition
modulo étant rares. (Ce point a fait l'objet d'une bonne discussion
sur LWN.)
Bernstein pointe aussi du doigt les problèmes de sécurité posés par l'analyse, le fait de convertir des données non structurées en données structurées, avec ses conséquences comme le besoin d'échappement, source, par exemple, de tant d'injections SQL.
Première rédaction de cet article le 22 Janvier 2010
L'IANA vient d'allouer deux préfixes
IPv4 à l'APNIC, les
1.0.0.0/8 et
27.0.0.0/8. Comme l'a noté le
NRO, cela rapproche
dangereusement de la fin
des adresses IPv4. Mais un autre point a été moins traité : ces
adresses ne vont-elles pas poser des problèmes à leur titulaire ?
En théorie, une adresse IP n'est qu'une
série de chiffres. Elles devraient donc toutes être
équivalentes. Mais, en pratique, ce n'est pas le cas. Certaines adresses
valent plus que d'autres. Ici, le problème potentiel avec
1.0.0.0/8, comme discuté sur Nanog est que ces adresses sont simples et
jolies. Cela pourra permettre à leur titulaire de parader mais cela
augmente aussi le risque de collision : des tas de cours ont été
écrits où l'adresse IP d'exemple est 1.2.3.4 et
on ne sait pas combien d'équipements ont été configurés avec cette
adresse, ou combien de sites ont stupidement utilisé ce préfixe pour
la partie privée de leur réseau... (Cela a déjà été fait par des
incompétents comme les gens d'anoNet ou, pour un autre préfixe qui va
bientôt être distribué, par ceux, tout aussi stupides, de Hamachi.) Notez au passage
que le choix des deux préfixes qui viennent d'être alloués a été fait
au hasard, selon la méthode du RFC 2777,
justement pour tenir compte de cette inégalité des adresses.
Comme l'a dit Alain Durand dans la discussion Nanog « L'eau à la fin du tonneau (d'adresses IPv4) est moins propre »...
Sur le même sujet, un bon article d'Andree Toonk, « Issues with allocating from
1.0.0.0/8 » qui, en se basant sur l'analyse des
annonces BGP des
derniers mois, montre que le problème est réel, et une excellente étude du RIPE
montrant à quel point certaines parties de
1.0.0.0/8 sont polluées.
Date de publication du RFC : Janvier 2010
Auteur(s) du RFC : M. Shand, S. Bryant (Cisco)
Pour information
Réalisé dans le cadre du groupe de travail IETF rtgwg
Première rédaction de cet article le 19 Janvier 2010
IP a une propriété très utile : la route entre deux points n'est pas fixée à l'avance et peut être modifiée même en cours de conversation. Cela permet aux réseaux IP de continuer à fonctionner même lorsque des coupures surviennent, s'il existe un chemin alternatif. Par contre, trouver ce chemin alternatif et l'utiliser prend du temps et ce délai peut être fatal à certaines applications plus ou moins temps-réel. D'où la nécessité de développer une méthodologie et des mécanismes pour un reroutage rapide. Ce RFC 5714 est consacré à décrire le cadre général de ce reroutage rapide.
De tels mécanismes existent déjà pour certains protocoles de couche 2, comme SONET, ou de couche « 2,5 » comme MPLS. Mais le but du travail sur le reroutage rapide IP est d'avoir une solution générale pour tous les réseaux IP.
Donc, après une section 1 de terminologie, commençons par décrire le problème (section 2). Lorsqu'un lien physique tombe en panne, même si des liens alternatifs sont disponibles, il s'écoule une période non nulle pendant laquelle les paquets ne peuvent plus être transmis. Ces paquets sont alors souvent jetés par les routeurs. Traditionnellement, dans un réseau IP, les durées de ces périodes atteignaient facilement plusieurs secondes. Pour certains applications (par exemple SMTP) ce n'est pas un problème. Mais certains services récents ont davantage de mal à tolérer ces courtes coupures. Calculer de nouvelles routes, dans un environnement distribué comme l'Internet, ne peut pas être « temps-réel ». Mais il existe une autre solution : calculer à l'avance les routes de secours ce qui permettrait de remplacer la route passant par le lien en panne en un temps bien plus court. C'est l'approche utilisée par le mécanisme Fast Reroute de MPLS (RFC 4090) et le but du projet IP Fast Reroute est de spécifier des mécanismes analogues dans un environnement purement IP.
Ces mécanismes sont loin d'être complètement définis, notre RFC 5714 se contenant de définir un cadre général pour leur élaboration. D'autre part, le projet se limite pour l'instant aux IGP à état des liaisons (section 3), une extension aux autres IGP ou bien aux protocoles de routage externes comme BGP étant possible dans le futur.
La section 4 du RFC analyse le problème. D'où vient le délai avant que la route alternative soit utilisable ? Il y a plusieurs sources de retard :
Hello d'OSPF),
alors, des durées de plusieurs dizaines de secondes sont
possibles.Toutes ces opérations n'étant pas instantanées et devant être effectuées par plusieurs routeurs, le réseau sera dans un état incohérent pendant un moment et on verra des micro-boucles temporaires se former (une micro-boucle est le ping-pong entre deux routeurs, chacun croyant que l'autre est la meilleure route, cf. RFC 5715).
Quels sont les mécanismes disponibles pour faire mieux ? La section 5 les expose. Pour la détection de la panne (section 5.1), l'aide du matériel est bien pratique : si la fibre est coupée, la disparition de la lumière indique le problème immédiatement. Mais il existe aussi des protocoles indépendants du protocole de routage, et dédiés à la détection de pannes, comme BFD.
Pour réparer la panne, l'idée de base est de pré-calculer les chemins alternatifs, ce qui permettra de les installer rapidement (section 5.2). La plupart des pannes devraient pouvoir être réparées avec les techniques du RFC 5286, qui ne nécessitent pas de marquage spécial des paquets IP. Pour les autres, des techniques plus avancées sont nécessaires comme le calcul et le stockage à l'avance de plusieurs FIB dans les routeurs, combinés avec un mécanisme de signalisation permettant d'indiquer que le paquet doit prendre la route de secours. Des mécanismes reposant sur un routage explicite, par exemple avec des tunnels, sont également possibles.
Au fait, j'ai utilisé des termes vagues comme « la plupart ». Peut-on les quantifier ? La section 5.2.2 analyse le succès de chaque mécanisme en fonction de la topologie.
Enfin, pour la prévention des micro-boucles, la section 5.3 renvoie au RFC 5715 qui liste les possibilités.
Date de publication du RFC : Janvier 2010
Auteur(s) du RFC : M. Shand, S. Bryant
Pour information
Réalisé dans le cadre du groupe de travail IETF rtgwg
Première rédaction de cet article le 19 Janvier 2010
Le groupe de travail rtgwg de l'IETF travaille entre autre à définir des protocoles et des méthodes pour éliminer les micro-boucles lors d'un changement des routes dans un réseau IP. Une micro-boucle est la boucle temporaire qui se forme entre deux (parfois davantage) routeurs lorsqu'ils n'ont pas mis à jour leur table de routage pile en même temps. Pendant quelques secondes, le routeur A envoie les paquets à B, qui les envoie à A, qui les envoie à B... Notre RFC 5715 explique le problème, ses causes et ses effets, et expose les solutions existantes.
La section 1 rappelle le fonctionnement du routage IP. Les routeurs n'ont pas une vue commune du réseau. Lorsque celui-ci change, que ce soit suite à une « mauvaise nouvelle » (la rupture d'un câble) ou suite à une « bonne nouvelle » (l'ajout d'un nouveau lien), il faut un temps fini pour propager l'information à tous les routeurs et pour que ceux-ci mettent à jour leur FIB. Pendant ce temps de convergence, les routeurs ne fonctionnent pas sur une vision commune et les micro-boucles apparaissent. Les paquets vont alors tourner en rond, consommant de la capacité du réseau, avant d'être jetés lorsque leur TTL (Hop Count en IPv6) est terminé.
Ces micro-boucles sont-elles graves ? En général, les protocoles situés au dessus corrigent automatiquement. Mais de nouveaux services Internet pourraient être plus sensibles et souhaiteraient une transition sans douleur, sans délai et sans perte de paquets.
Cet idéal est évidemment utopique mais il existe quand même des méthodes pour améliorer les choses comme celles du RFC 4090 pour MPLS ou du RFC 5714 pour IP.
Parmi les voies possibles pour traiter le problème des micro-boucles, il y a des techniques de convergence suffisamment rapides pour que le problème soit minimal, ou bien des topologies du réseau qui rendent les micro-boucles rares ou impossibles.
La section 2 est consacrée à étudier plus en détail ce qu'est une micro-boucle et dans quelles conditions elles se forment. La micro-boucle est un phénomène temporaire, inévitable dans un paradigme de routage « saut après saut » qui est celui d'IP (chaque routeur ne se préoccupe que du saut suivant). Elle est « micro » par sa durée et par le petit nombre de routeurs en jeu (souvent seulement deux). La création d'une boucle nécessite au moins une des conditions suivantes :
Les micro-boucles ont deux conséquences :
Que peut-on faire contre les micro-boucles ? C'est un travail pour la section 4 et des suivantes. Il existe plusieurs stratégies, limiter les dégâts, empêcher les boucles de se former, les supprimer quand elles apparaissent ou bien minimiser le risque d'occurrence (par exemple par des réseaux avec davantage de maillage). Elles sont détaillées dans les sections suivantes. D'abord, la section 5 explique comment limiter les dégâts, soit en accélérant la convergence du réseau, soit avec la méthode PLSN (Path Locking with Safe Neighbors), non encore décrite dans un RFC (mais résumée en section 7), qui consiste à tenir compte de l'état du réseau avant et après le changement avant de choisir d'envoyer dorénavant du trafic à un voisin. La simulation montre que cette méthode est efficace mais elle ne fait que limiter les micro-boucles, pas les empêcher.
Et la prévention ? La section 6 est là pour ça. Elle ne liste pas moins de huit méthodes pouvant empêcher les micro-boucles de se former. Mais toutes ne sont pas réalistes. Parmi elles :
Et la suppression des boucles, une fois qu'elles sont formées ? Pour détecter la micro-boucle, La section 8 examine deux possibilités, une forme de mémoire des paquets déjà vus, dans le routeur (très consommatrice en ressources) et une méthode plus simple : détecter une boucle au fait qu'un paquet entre par l'interface où on le ferait sortir (mais cela ne marche que pour les boucles simples, symétriques).
Quel que soit le mécanisme adopté, il va falloir le déployer dans l'Internet existant et la section 9 rappelle donc l'importance de la compatibilité avec cet existant.
Enfin, une comparaison des différentes méthodes occupe la section 10. Plusieurs méthodes semblent réalistes pour les protocoles futurs.
Première rédaction de cet article le 17 Janvier 2010
Dernière mise à jour le 20 Janvier 2010
Le tremblement de terre qui a frappé
Haïti le 12 janvier 2010 a déjà fait l'objet de
beaucoup d'articles, notamment sur les mesures d'aide qui ont été
prises. Je voudrais ici détailler un aspect tout à fait secondaire,
mais qui illustre bien le fonctionnement actuel de
l'Internet : la reconfiguration du
domaine de premier niveau
.HT, pour lui garantir un
fonctionnement prolongé. (Cet article est conçu pour tous, des détails
techniques sur le DNS figurent à la fin.)
Comme tous les pays, Haïti a un
nom de domaine dit « de
tête » ou « de premier niveau », qui identifie le pays. En
l'occurrence, c'est
.HT. On peut donc avoir
des ressources Internet avec des noms comme
www.fds.edu.ht ou
rddh.org.ht. Les liaisons Internet ont toutes été
détruites lors du tremblement de terre mais les ressources (par
exemple les sites Web) accessibles via un nom
en .HT étaient parfois hebérgés à l'extérieur du
pays et pouvaient donc continuer à être accessibles... si les noms en
.HT marchaient toujours. Malheureusement,
beaucoup de domaines (y compris des domaines de tête) sont publiés par
un nombre de serveurs
très limités, tous situés en un seul endroit. En cas de panne
électrique ou de coupure de la liaison Internet, le service de noms ne
fonctionne plus et, même si le serveur Web est toujours là, les
clients ne peuvent plus trouver son adresse et donc le joindre.
Au contraire, .HT est
bien géré (et bravo à ce sujet à Stéphane Bruno et Max Larson Henry) :
il a six serveurs de noms, deux en Haïti, un en
France, un au Canada, un
aux États-Unis et un autre, géré depuis les
États-Unis mais physiquement distribué sur
toute la planète. .HT n'a donc jamais cessé de
fonctionner.
Par contre, cela ne pouvait pas durer éternellement : pour des
bonnes raisons techniques, les serveurs
secondaires, situés à l'étranger, arrêtent tout
service s'ils ne peuvent pas joindre le primaire
pendant un certain temps. Et, de toute façon, toute modification des
noms en .HT est gelée tant que le primaire n'est
pas joignable.
S'il n'y avait pas d'urgence immédiate, il fallait néanmoins
agir. En l'absence de toute communication avec les gérants du
.HT, dans la nuit du 14 au 15 janvier, les
responsables des serveurs secondaires, sous l'impulsion de Bill
Woodcock, de PCH, ont commencé à reconfigurer
.HT pour un fonctionnement plus durable. Une
copie de la base de données du registre se
trouvait en Australie, chez
Cocca. Un de leurs techniciens, Garth Miller, a configuré une machine
comme primaire, les gérants des secondaires ont changé à leur tour la
configuration de leurs machines (merci à Jean-Philippe Pick pour avoir
réagi particulièrement vite) et, le 16 janvier au soir, après
quelques problèmes techniques, .HT retrouvait un
fonctionnement normal, qui pourra durer jusqu'à ce que les liaisons
Internet avec les gérants de .HT et leurs
ordinateurs soient rétablies. (Nous avons appris depuis que l'immeuble
où se trouvait les serveurs a été réduit en poussière. Des organismes
comme l'AFNIC travaillent à remplacer ces
machines dès que les secours d'extrême urgence pourront laisser la
place à l'envoi de matériel informatique. Une partie de
l'infrastructure Internet sur place fonctionne encore, notamment le
point d'échange sur la colline de Boutilliers,
grâce à Reynold Guerrier.)
Le point important à noter est qu'aucun autorité n'a ordonné ou
même approuvé ce changement. Aucun comité ne s'est réuni. Aucune
signature n'a été donnée. Les seules personnes pouvant décider, à
Port-au-Prince, étant injoignables, le travail
de reconfiguration a été fait entièrement entre administrateurs
système des serveurs secondaires. La sécurité de l'Internet n'est en
effet pas celle de murs de béton défendus par des règlements et des
procédures. C'est celle
d'un organisme vivant, dont les leucocytes
sont intelligents et capables d'initiative. (Bien sûr, les
administrateurs de .HT ont été informés.)
Les leçons à en tirer ? La première est d'assurer la redondance des
serveurs de noms. Ils doivent être plusieurs, et répartis en des
endroits très différents, pour faire face aux différents types de
panne. On peut noter par exemple que
.BD n'a que deux serveurs
(un troisième est annoncé mais ne répond jamais),
tous les deux à Dhâkâ. En cas de problème
frappant cette ville, comme une inondation, tous les noms se terminant
par .BD disparaissent. De même,
.PF n'a que deux serveurs,
tous les deux à Papeete. N'importe quelle
carastrophe naturelle rendrait donc ce domaine inutilisable.
La redondance des serveurs est une chose, celle des données en est une autre. (Dans le cas d'un registre de noms de domaines, la base de données contient la liste des noms délégués.) S'il n'y avait pas eu une copie de la base de données à l'extérieur du pays, elle était peut-être perdue. Il faut donc aussi s'assurer que les données sont réparties.
Bien sûr par rapport au drame que viennent de vivre les habitants d'Haïti, c'est tout petit. Mais j'espère que les petites gouttes d'eau feront les grandes rivières : chaque problème réparé est un outil en plus pour les autres réparations. Au fait, depuis ce travail, Stéphane Bruno a pu être joint, il va bien et il a approuvé le changement. Même chose pour Max Larson Henry.
D'autres utilisations intelligentes de l'Internet ont été faites comme le moteur de recherche des disparus de Google (disponible en anglais, français et créole) ou comme le flux d'informations Twitter de Carel Perdre.
Comme promis, quelques détails techniques, pour ceux qui
connaissent le DNS. Ce protocole est très
résistant aux pannes et, si les serveurs sont bien répartis comme ils
doivent l'être, un domaine peut résister à n'importe quelle
catastrophe. Mais que se passe t-il ensuite ? Les serveurs secondaires
(le terme correct aujourd'hui est d'ailleurs « serveur esclave » pour
de bonnes raisons mais, dans le contexte
d'Haïti, j'ai préféré l'éviter) continuent à servir la
zone pendant une période qui est gouvernée par le champ
Expire de l'enregistrement
SOA (cf. RFC 1035,
section 3.1.3). Ce champ vaut actuellement pour
.HT 1296000 secondes soient deux semaines et, si
rien n'avait été fait, le domaine .HT aurait donc
disparu dans quinze jours (le but de ce champ est d'éviter qu'un ancien
esclave oublié continue à servir des données dépassées
éternellement). Il y a une seconde raison pour le travail de
reconfiguration qui a été fait : il permet de modifier la zone et
donc, si nécessaire, d'ajouter des nouveaux domaines ou bien de
changer les adresses IP des serveurs de noms des domaines existants,
pour assurer leur continuité (un serveur esclave, comme son nom
l'indique, ne peut pas modifier les données). Aujourd'hui, on voit que
les quatre serveurs extérieurs (dont le serveur
anycast de
PCH) sont bien à jour (ils ont tous le même
numéro de série, qui est postérieur au séisme) :
% check_soa ht There was no response from ns2.nic.ht There was no response from ns1.nic.ht dns.princeton.edu has serial number 2010011820 charles.cdec.polymtl.ca has serial number 2010011820 ht-ns.anycast.pch.net has serial number 2010011820 ns3.nic.fr has serial number 2010011820
À noter également que l'actuel serveur maître, chez Cocca, n'apparait pas dans les enregistrements NS : c'est un maître caché (en anglais, on dit un stealth).
Le domaine nic.ht a été à son tour reconfiguré
sur le même principe, avec l'idée de faire revivre le NIC à distance.
D'autres articles sur les technologies de l'information et Internet, dans le tremblement de terre :
.HT :
« Situation in Haiti and the DNS »Première rédaction de cet article le 17 Janvier 2010
Depuis le temps qu'on parle d'empoisonnement DNS, par exemple suite à la faille Kaminsky, je n'avais jamais eu l'occasion d'en observer un en vrai. Des essais, bien sûr, des résultats de tests, mais une vraie attaque menée dans le but de détourner du vrai trafic, j'en avais entendu parler mais jamais vu ça de mes propres digs. C'est désormais fait.
Tout a commencé sur Twitter :
(17:07:09) oneeyed: whois.com hacked
http://bit.ly/7IaCfm. Je regarde et http://whois.com/, service de recherche via
whois, semble normal. D'autres personnes le
voient normal. En fait, le site Web est intact, il n'a pas été
défiguré, c'est le DNS
du FAI
Free qui a des
problèmes. Je ne m'en étais pas aperçu car j'utilise mon propre
résolveur DNS. Mais, en interrogeant ceux de Free, on trouve des
données normales sur le serveur 212.27.40.241
mais pas sur l'autre résolveur que Free met à la disposition de ses
clients :
% dig +short @212.27.40.240 A whois.com 94.102.7.12
Cette adresse IP
94.102.7.12 n'a rien à voir avec
whois.com et la base du
RIPE-NCC la situe chez un opérateur turc (la vraie adresse IP de
whois.com est
67.225.139.191, aux
États-Unis). À l'adresse en question, un
serveur Web diffuse une image de défiguration
classique.
Donc, il semble bien qu'il y aie eu empoisonnement (par un moyen inconnu de moi) d'un des résolveurs DNS de Free. Pendant un certain temps (environ une heure, semble t-il), tous les clients de Free qui tombaient sur ce résolveur étaient envoyés au mauvais serveur. Le problème a ensuite disparu, probablement parce qu'un technicien de Free a redémarré le serveur.
Quelques leçons :
94.102.7.12 ne le sert apparemment plus, donc je
ne sais pas quel était le but poursuivi par l'attaquant.Merci à Samuel Tardieu pour m'avoir signalé le cas rigolo. Voir aussi la discussion sur Reddit.
Date de publication du RFC : Janvier 2010
Auteur(s) du RFC : J. Arkko (Ericsson), M. Cotton (ICANN), L. Vegoda (ICANN)
Pour information
Première rédaction de cet article le 15 Janvier 2010
Pendant longtemps, les documentations ou cours sur TCP/IP utilisaient dans les exemples des adresses IP prises un peu au hasard, par exemple sur le réseau de l'auteur. Cela entrainait des problèmes si un lecteur prenait ces exemples trop littéralement et réutilisait ces adresses, rentrant ainsi en conflit avec les adresses existantes. Le RFC 1166 avait donc commencé la bonne tradition de réserver des adresses pour la documentation, tradition que continue notre RFC 5737 (voir aussi le RFC 5735).
Comme le rappelle la section 1, la limite du préfixe
192.0.2.0/24 qui avait été réservé par le RFC 1166 était qu'il était tout seul : un cours sur
OSPF ou BGP était assez
difficile à faire avec des adresses commençant toutes par
192.0.2. Deux autres préfixes ont donc été
ajoutés, 198.51.100.0/24 et
203.0.113.0/24 (section
3). IPv6, lui, a le
2001:db8::/32 du RFC 3849
et les noms de domaine
ont les example.org et autres
example.net du RFC 2606.
Puisque ces trois préfixes IPv4 sont réservés à la documentation, ils ne devraient jamais apparaitre sur des vrais réseaux, par exemple via BGP (section 4). On peut donc les ajouter aux listes de bogons.
À noter enfin que, contrairement à ce qu'on lit parfois, le préfixe
128.66.0.0/16 n'est pas
réservé (section 5) pour la documentation et peut être utilisé pour de
vraies allocations.
Date de publication du RFC : Janvier 2010
Auteur(s) du RFC : M. Cotton (ICANN), Leo Vegoda (ICANN)
Première rédaction de cet article le 15 Janvier 2010
Un certain nombre de préfixes IPv4 ont une signification spéciale et ce RFC les documente, pour éviter aux lecteurs de devoir fouiller dans les nombreux RFC originaux.
Normalement, les préfixes des réseaux IPv4 sont attribués par l'IANA aux RIR qui les allouent ensuite aux LIR (qui sont en général des FAI). Ces allocations et les affectations aux utilisateurs finaux sont enregistrées par les RIR et sont publiquement accessibles via des protocoles comme whois. Le premier RFC sur le rôle de l'IANA est le RFC 1174 et la description actuelle du rôle de l'IANA est le RFC 2860.
Mais certains préfixes sont spéciaux et échappent à ce mécanisme. Ils ont été réservés par tel ou tel RFC et sont donc dispersés à plusieurs endroits. Notre RFC, successeur du RFC 3330, écrit par l'IANA, rassemble toutes ces réservations en un seul endroit.
Voici quelques exemples de préfixes ainsi documentés :
10.0.0.0/8, réservé pour les adresses
privées par le RFC 1918,169.254.0.0/16, réservé pour les adresses
locales au lien (cette réservation a été documentée dans
le RFC 3927),192.0.0.0/24, réservé pour les protocoles
qui ont besoin d'adresses IP spécifiques. Pour l'instant, aucune
affectation dans ce nouveau
registre n'a été faite, le RFC 5736 décrit les règles que ces affectations suivront,192.0.2.0/24, 198.51.100.0/24 et
203.0.113.0/24, réservés pour la documentation
(par exemple pour rédiger des manuels, sans craindre que les adresses
IP d'exemple soient utilisées). Les deux derniers préfixes sont une
nouveauté du RFC 5737. Le seul utilisé jusqu'à présent, le
192.0.2.0/24, était trop petit pour certains
usages (par exemple, pour un cours BGP, c'était
pénible de devoir distinguer 192.0.2.0/25 et,192.0.2.128/25),198.18.0.0/15, réservé pour les mesures, suivant le RFC 2544,Si vous avez une idée géniale qui nécessite de réserver un autre préfixe, la marche à suivre est expliquée dans la section 5. Au minimum, vous aurez à écrire un RFC.
Les fanas de la sécurité noteront la section 7, qui précise les
filtrages qui devraient faire les routeurs (par exemple,
169.254.0.0/16 ne devrait jamais être routé), et
avertit qu'il ne faut pas forcément compter sur ces filtres : tous les
routeurs ne sont pas forcément bien configurés. Donc, si vous recevez
un paquet IP avec une adresse source en
169.254.0.0/16, cela ne signifie pas forcément
qu'il vienne d'une machine locale.
L'annexe A liste les principaux changements par rapport au RFC
précédent, le RFC 3330. En raison de l'extrême pénurie d'adresses
IPv4, des préfixes ont été
définitivement remis dans le circuit normal d'allocation et
n'apparaissent donc plus comme spéciaux (par exemple le
24.0.0.0/8). Et deux nouveaux préfixes
apparaissent pour la documentation.
Date de publication du RFC : Janvier 2010
Auteur(s) du RFC : G. Huston (APNIC), M. Cotton (ICANN), Leo Vegoda (ICANN)
Pour information
Première rédaction de cet article le 15 Janvier 2010
Le RFC 5735 ayant réservé un préfixe
d'adresses IPv4,
192.0.0.0/24 pour des allocations « spéciales »,
ce RFC 5736 définit les règles que devra suivre
l'IANA pour la gestion du registre des allocations dans ce préfixe.
L'utilité principale de ce préfixe réservé est de permettre des allocations d'adresses IP pour certains protocoles qui ont besoin de coder en dur des adresses. (Il existe déjà un tel registre pour les adresses IPv6, registre décrit dans le RFC 4773.) La section 2 du RFC rappelle les généralités sur le rôle de l'IANA, ses relations avec l'IETF et l'accord qui les lie (RFC 2860).
La section 3 décrit le mécanisme d'allocation proprement
dit. Prendre une adresse dans le préfixe
192.0.0.0/24 nécessitera une IETF
review (le terme est défini dans le RFC 5226 et désigne une procédure relativement lourde,
impliquant l'écriture d'un RFC).
Le registre doit indiquer l'adresse IP réservée, le RFC où son usage est documenté, le caractère routable ou non de cette adresse, etc. À noter que, même si le registre dit qu'une adresse est prévue pour être routée mondialement, le RFC précise qu'on ne peut rien garantir à ce sujet, vue la décentralisation des politiques de routage.
Le registre est vide, pour l'instant. Patience...
Articles des différentes années : 2010 2009 2008 2007 2006 2005 2004 Précédentes années
Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu