Summary

  • La section 4.2.3.6 du manuel en vigueur d’ARIN accepte le seul besoin de multihébergement comme justification d’un /24 pour un client en aval. Celui-ci fournit les coordonnées de tous ses opérateurs amont au FAI qui donne le bloc et utilise avec lui un protocole de routage de bordure. Un seul amont peut fournir un /24 sur ce motif sans justification supplémentaire.
  • La section 2.7 exige une connectivité permanente auprès de plusieurs FAI et au moins un préfixe annoncé par deux d’entre eux. La section 4.2.3.3 recommande qu’un client quittant son FAI rende les adresses et renumérote dans l’espace du nouveau fournisseur; l’ancien doit laisser assez de temps.
  • La politique ARIN 2001-2, adoptée puis appliquée en 2002, explique l’origine du compromis : le multihébergement justifiait un /24 indépendamment du nombre d’hôtes. Le manuel actuel reste la règle applicable.

Un deuxième fournisseur peut sauver un chemin défaillant. Il ne déplace pas par magie le bloc d’adresses chez un autre titulaire. La définition d’ARIN est précise : pour être multihébergée, une organisation reçoit une connectivité à temps plein de plus d’un FAI, et au moins un préfixe est annoncé par deux opérateurs amont. Une seconde liaison achetée mais jamais intégrée au routage ne remplit pas encore tout ce tableau.

Le bénéfice apparaît à la section 4.2.3.6. Un client peut invoquer son besoin de multihébergement comme raison suffisante d’obtenir un /24. Le texte se situe dans les règles encadrant les réattributions et réallocations par les FAI à leurs clients. Il parle d’adresses fournies par l’opérateur amont, pas d’un nouveau bloc indépendant remis directement par ARIN au client final. Le client communique au FAI fournisseur les contacts de tous ses autres amonts et utilise avec lui un protocole de routage de bordure.

La phrase suivante fixe le plafond de la faveur : le client peut recevoir un /24 d’un seul de ses amonts au titre de cette disposition sans apporter d’autre justification. Le second opérateur peut assurer la connectivité et annoncer le même préfixe, mais le client ne peut pas rejouer exactement le même argument pour obtenir automatiquement un deuxième /24. La politique facilite un plan de routage, elle ne distribue pas un bloc par circuit.

Le FAI fournisseur doit aussi conserver les pièces permettant d’expliquer le choix. Il peut présenter à ARIN les informations recueillies auprès du client ou identifier son numéro d’AS. La section 4.2.3.7 demande aux FAI de documenter l’usage efficace de leurs allocations, notamment par l’historique des attributions. La section 4.2.3.7.1 exige l’enregistrement des réattributions IPv4 d’au moins /29 dans SWIP ou un service d’annuaire conforme. Le /24 accordé pour multihébergement entre donc dans le registre et dans les comptes du fournisseur.

La version originelle de 2001 expose le motif. À l’époque, une demande d’adresses était ordinairement mesurée par les machines à desservir. La politique adoptée a permis au besoin de multihébergement de justifier un /24 même lorsque cette mesure n’y conduisait pas. Elle exigeait déjà la liste des amonts et limitait déjà la voie simplifiée à l’un d’eux. La réponse à un vrai problème technique contenait dès le départ une dépendance à un fournisseur.

Le coût de cette dépendance ressort au moment du départ. La section 4.2.3.3 du manuel actuel décourage la fragmentation des blocs contigus attribués aux FAI. Elle encourage les opérateurs à demander le retour des adresses lorsque le client change de FAI. Elle recommande au client de rendre l’ancien bloc et de renuméroter dans celui du nouveau fournisseur. L’opérateur initial doit laisser assez de temps pour cette opération. Aucun nombre universel de jours n’est donné. Le texte propose une manière de préserver l’agrégation, avec une facture d’ingénierie à planifier.

Un achat de résilience peut ainsi couvrir un risque et en laisser un autre. Deux opérateurs et un préfixe annoncé par les deux améliorent les options face à la panne d’un chemin. Le /24 obtenu auprès de l’un d’eux reste attaché à une relation de fourniture. En cas de rupture de cette relation, il faut inventorier DNS, points d’entrée applicatifs, listes d’autorisation, pare-feu, filtres de routage et équipements de clients qui portent ces adresses. La date à laquelle l’ancien FAI voudra les récupérer devient une question de contrat et de migration.

Les sources officielles ne donnent aucun dossier d’un client précis ayant utilisé cette clause puis chiffré une renumérotation. Une attribution datée et le calendrier d’un changement de fournisseur montreraient ce coût pour un cas. Le texte de politique fournit déjà la distinction décisive : plusieurs chemins, un seul amont pour le /24 facile.