Résumé

  • RFC 3180 a fait d’une expérience d’un an une bonne pratique, BCP 53 : dans le bloc multicast IPv4 233/8, un numéro AS sur deux octets déterminait un /24, soit 256 adresses de groupe, sans seconde procédure d’enregistrement.
  • Cette simplicité héritait des limites du registre AS. Le format ne pouvait encoder les ASN sur quatre octets et un seul AS pouvait couvrir plusieurs sites ou organisations. RFC 6034 a ensuite ajouté une option fondée sur les préfixes sans abroger RFC 3180.

L’adresse devait donner un indice sur l’acteur qui pouvait l’attribuer. Dans 233/8, le premier octet restait fixe ; les deux suivants reproduisaient un AS sur 16 bits ; le dernier laissait 256 groupes multicast à cet AS. L’exemple de RFC 3180 transforme l’AS 5662 en 233.22.30.0/24. Un fournisseur pouvait déduire le bloc d’un numéro déjà attribué pour le routage, plutôt que demander une plage globale au moyen d’un mécanisme interdomaines distinct.

Cette astuce répondait à un problème précis. L’expérience RFC 2770 de février 2000 observait que certains agrégateurs de contenu avaient besoin d’adresses fixes, sur une durée qui ne convenait pas à une allocation dynamique de sessions. Les fournisseurs, agrégateurs et auteurs d’applications n’avaient pas non plus trouvé d’accord général sur un schéma cohérent. L’usage statique de 233/8 était donc initialement limité à un an, avec possibilité de renouvellement. En septembre 2001, RFC 3180 a remplacé cette expérience par la meilleure pratique BCP 53.

La cible annoncée était le sous-ensemble statique que le multicast spécifique à la source ne couvrait pas, et non toute allocation multicast.

La réutilisation d’un identifiant connu rendait la règle lisible, mais lui imposait une frontière. RFC 3180 limite explicitement la méthode aux AS sur deux octets. Lorsque le format ASN s’est étendu à quatre octets, GLOP n’avait pas de bits pour y placer la valeur supplémentaire. Et le bloc désignait un AS, pas nécessairement une seule organisation ou un seul site. Un grand AS comprenant plusieurs activités indépendantes exigeait toujours une coordination interne ; l’AS encodé ne révélait pas forcément l’organisation responsable.

RFC 6034 a abordé le problème autrement en 2010. Son mécanisme IPv4 dérive des plages multicast du préfixe unicast global d’une organisation, selon une logique proche du format multicast IPv6 fondé sur les préfixes. La granularité peut être plus fine et évite la limite des ASN sur quatre octets lorsque le préfixe est admissible. Ce n’est toutefois pas une succession nette : RFC 6034 précise qu’il ne met ni à jour ni n’abroge RFC 3180. Les organisations dont l’allocation unicast est plus spécifique qu’un /24 peuvent encore avoir besoin de GLOP ; les deux méthodes peuvent coexister.

Le registre IANA actuel désigne toujours 233.0.0.0 à 233.251.255.255 comme bloc GLOP, tout en traitant séparément les plages voisines. Cela établit une frontière d’allocation reconnue, pas le volume du trafic, l’existence d’une route ou la réception d’un flux. Les documents ne prouvent donc ni une adoption universelle ni la disparition de GLOP. Ils racontent une tentative de simplifier l’allocation de groupes statiques en l’intégrant à un autre système de numérotation, puis l’ajout d’un second mode lorsque sa largeur et sa granularité ne convenaient pas à tous.

Sources