Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

RFC 6918: Formally Deprecating Some ICMPv4 Message Types

Date de publication du RFC : Avril 2013
Auteur(s) du RFC : F. Gont (UTN-FRH / SI6 Networks), C. Pignataro (Cisco Systems)
Chemin des normes
Première rédaction de cet article le 18 avril 2013


Allez, encore un peu de nettoyage dans les registres IANA. Le protocole ICMP pour IPv4 a plein de types de messages différents. Beaucoup sont dépassés mais n'avaient pas été officiellement marqués comme tel. Ce RFC range le registre et reclasse quinze types de messages. En revoyant ces types, nous plongeons dans les essais ratés de TCP/IP...

La notion de type de message ICMP est normalisée dans le RFC 792. Les plus connus des types de message ICMPv4 sont le 8 (echo request) et le 0 (echo reply) à cause de leur utilisation dans ping. Mais il existe bien d'autres types, enregistrés à l'IANA et servant à de nombreuses fonctions discrètes, mais indispensables (comme l'indication qu'un paquet n'a pas pu être délivré, type 3). Le registre des types a aussi vu l'arrivée d'un certain nombre de types expérimentaux, qui n'ont guère eu de succès, et notre RFC s'occupe de les trier. (Rappelez-vous qu'IPv6 a un autre registre ICMP, complètement différent.)

Voici donc la liste des types abandonnés :

  • Type 6 Alternate Host Address : un cas amusant car il n'a jamais été documenté et personne ne semble savoir à quoi il devait servir.
  • Types 15 Information Request et 16 Information Reply : décrits dans le RFC 792, ils servaient à la configuration automatique des machines mais sont devenus inutiles depuis qu'on a DHCP.
  • Types 17 Address Mask Request et 18 Address Mask Reply : normalisés dans le RFC 950, ils devaient permettre à une machine de découvrir le masque de sous-réseau (qui, avant cela, avant le VLSM - Variable-Length Subnet Masking, dépendait de la classe d'adresses). Là encore, DHCP les a rendus inutiles.
  • Type 30 Traceroute : décrit par le RFC 1393, il devait servir à découvrir le chemin parcouru par un paquet. Au contraire de la technique utilisée par l'outil traceroute, il nécessitait du logiciel spécial dans tous les routeurs et n'a jamais été sérieusement déployé. Le RFC 6814 l'avait déjà déclaré inutile.
  • Type 31 Datagram Conversion Error : le RFC 1475 l'avait spécifié pour le protocole TP/IX, bien oublié depuis.
  • Type 32 Mobile Host Redirect : un premier essai (raté) d'un protocole permettant la mobilité des machines de réseau en réseau.
  • Types 33 IPv6 Where-Are-You et 34 IPv6 I-Am-Here : un essai, jamais déployé, pour permettre aux machines IPv4 de découvrir des voisins parlant IPv6.
  • Types 35 Mobile Registration Request et 36 Mobile Registration Reply : autre essai non suivi d'effet lié à la mobilité et à IPv6. (Il était documenté dans l'Internet-Draft draft-simpson-ipv6-mobility qui n'est jamais devenu un RFC.)
  • Types 37 Domain Name Request et 38 Domain Name Reply : normalisés dans le RFC 1788, l'idée était de permettre une traduction d'adresse IP en nom n'utilisant pas le DNS. On envoyait un paquet ICMP à une machine et elle répondait avec son nom. En pratique, cela n'a jamais été utilisé.
  • Type 39 SKIP : prévu pour un protocole qui n'a jamais été terminé.

Tous ces types sont désormais marqués Deprecated dans le registre IANA.


Téléchargez le RFC 6918

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)