Ou comment justifier un /24 en IPv4 pour un petit ISP.

Depuis que les adresses IPv4 sont devenues rares (et parfois chères), les /24 se comptent sur les doigts d'une main chez les LIR qui veulent bien encore les assigner au lieu de les garder pour eux, ou de les marchander.

Opdop propose encore des adresses IPv4 moyennant une cotisation forfaitaire, mais ne les routant pas refusera systématiquement d'en réserver moins qu'il est nécessaire pour que le demandeur puisse les router : autrement ce serait en pure perte.

Même si le sujet ici n'est pas de parler des tarifs d'Opdop ni de ce LIR en particulier, je mets ici un lien vers les tarifs pour que ça puisse servir de référence, et parce que quand plus loin on parlera de chercher une solution ensemble il faudra aussi qu'elle ait une cohérence avec ce qui existe.

Il faut néanmoins rappeler que toute assignation demande de monter un dossier justificatif (avec documents à l'appui), et de faire des déclarations dans «le Whois» (la base du Ripe) qui par la suite devront être maintenues. C'est donc un certain volume de travail. Aussi y a-t-il des frais pour le setup, et s'ils ne sont pas facturés par le LIR alors c'est qu'ils sont offerts par lui.

Une cotisation annuelle (qui dans Opdop dépend du statut social du demander et pour les sociétés, de leur taille) découle naturellement de la cotisation que le LIR verse, annuellement, au Ripe, et de ses propres frais de gestion.

Chez Opdop toutes les adresses étant par définition «non routées» (sous-entendu : par le LIR) il n'est pas fait de différence entre PA et PI, toutes font donc l'objet d'une convention qui établit les bons usages et le respect des termes qui ont justifié l'attribution des adresses. Cette convention est disponible sous ce lien.

Cette convention est aussi le seul et unique contrat par lequel le LIR se lie au demandeur (utilisateur final) des adresses, ce qui signifie qu'il n'y a pas besoin d'un autre contrat (hébergement, transit etc.) qui les lie et donc crée une dépendance en subordonnant l'attribution des IP à d'autres services. C'est donc l'instrument de l'indépendance du demandeur.

Mais la partie compliquée est de préparer une demande qui soit à la fois respectueuse des rares ressources publiques restantes, qui reflète les besoins avérés, mais qui ménage une marge de manoeuvre par la suite au FAI.

Autant dénoncer tout de suite le possessif de ce titre trop facile : les adresses IP sont des ressources publiques et donc elles n'appartiennent à personne. Une assignation n'est pas une vente, ni (chez Opdop) tout au plus un prêt.

Les mots «allocation», «assignation» et consors n'ont donc pas d'autre portée que administrative, voire technique. Donc l'objectif du FAI ne doit pas être spécifiquement de se faire assigner un /24, mais d'obtenir la meilleure assurance possible qu'il pourra en disposer et le router librement.

Pourtant ces mots ont des implications, car ils permettent de caractériser l'état des adresses concernées. En particulier une allocation est un conteneur d'assignations, c'est une branche dans l'arbre, qui correspond à une ramification. Alors qu'une assignation est «finale», c'est à dire qu'elle ne peut pas être encore partitionnée entre plusieurs utilisateurs finals : c'est la feuille de l'arbre. Ainsi un bloc d'adresses qui est assigné à un utilisateur ne peut pas encore assignée encore à un autre utilisateur, fut-il client du premier.

Une première difficulté est de raisonner sur un temps extrèmement cours : 3 mois. La demande d'assignation ne devra pas couvrir une période plus longue (il faudra faire une nouvelle demande d'assignation alors). Mais ceci n'interdit pas de résonner à plus long terme.

En effet si les besoins doivent être desservis au fur et à mesure de leur avènement, c'est à dire lorsqu'ils deviennent réels (et en correspondance avec les ressources encore disponibles, dans l'idée du Ripe), rien n'interdit d'avoir un plan préétabli qui garantisse une disponibilité et une organisation indispensables au FAI.

Le besoin du FAI se découpe généralement en plusieurs parties.

Il a des besoins propres, pour son infrastructure de routage, c'est généralement ce qu'on appelle le backbone, qui inclut pour l'essentiels des routeurs, chacun avec une adresse dans un réseau commun. Les switches peuvent avoir des adresses dans ce réseau s'ils ont une fonction de routage (interne) mais pas pour mettre une IP de maintenance. Les serveurs type collecte (L2TP) par exemple peuvent également se trouver en prise directe dans le backbone. Ce premier réseau est assez petit pour un petit ISP, par exemple un /28.

Il a des besoins pour ses services. Ceci regroupe les serveurs Web, FTP, DNS, radius, de backup, etc. Ces services sont communs et non dédiés à tel ou tel membre, donc plusieurs services peuvent partager la même IP, le besoin ne dépasse pas non plus à priori le /28.

Il a besoin d'adresses pour ses abonnés, et là on parle toujours d'une et une seule adresse IPv4 par abonné. Pourquoi seulement une ? Parce que ces adresses servent uniquement à fournir le service d'accès, et le Ripe considère que ces adresses ne sont pas assignées spécifiquement à un abonné mais qu'elles servent uniquement à livrer le service. Autrement dit elles font toujours partie de l'infrastructure du FAI. Le besoin ici dépend donc directement du nombre d'abonnés prévisible. Mettons un /26 (soit 64 adresses).

Il peut enfin (et toujours par exemple) avec des besoins type service dédié, comme des machines virtuelles dédiées ou des sites HTTPs pour ses abonnés. Ces cas correspondent eux aussi à des livraisons de services, et peuvent servir à justifier la mobilisation d'une adresse IPv4 et une seule par abonné. Disons un /27 (32 adresses).

On distingue donc jusqu'ici quatre grands types de besoins, qui seront chacun détaillés dans la demande, et dont l'évolution devra être réfléchie non seulement sur les trois mois de la demande d'assignation initiale, mais aussi plus loin afin de prévoir une organisation et un routage cohérents.

La somme de ces besoins va permettre de justifier la première assignation au FAI. On voit bien que pour un petit FAI la somme de ces besoins va rarement permettre de justifier 256 adresses à elle toute seule. Dans l'exemple ci-dessus, taillé à l'emporte-pièce, on totalise seulement 128 adresses donc la moitié d'un /24.

Mais la moitié d'un /24, ce n'est pas routable ! C'est un /24 qu'il fallait obtenir !

Oui et non, c'est un mal pour un bien, car le FAI n'est pas le seul à avoir des besoins et il doit avoir une vision plus globale et raisonner à la fois en FAI et en opérateur qui va devoir router ses adresses et celles de ses abonnés.

Dans un petit FAI moderne, local et dynamique les abonnés sont parfois un peu plus dégourdis que la moyenne. Certains aiment à monter des serveurs, voire à se multihomer. Il leur arrive aussi de monter des VPN et de vouloir faire router par leur FAI une petite plage d'adresses publiques qui leur sera réservée.

Mais qui va réserver cette plage et comme sera-t-elle routée ? Voilà la question que le FAI prévoyant fera bien de se poser avant de vouloir engloutir pour lui seul un /24 entier. Car des morceaux disponibles de ce /24 (c'est à dire des morceaux qui seront encore «disponibles» dans ce /24 lui seront fort utiles pour, d'une part, pouvoir être assignés à ces abonnés, et d'autres part se trouver très pratiquement routables dans un seul et unique /24 qui lui est réservé.

Mettons donc que Jospéhine ait besoin d'un /29 pour son petit réseau à la maison, monté sur un VPN de notre FAI. Ce /29 ne peut pas être pris dans l'assignation du FAI, il doit être assigné directement par le LIR à l'abonnée. Le fait que le FAI dispose encore d'espace disponible dans son /24 va lui permette de résoudre cette situation sans effort.

Si on traduit cette organisation dans le vocabulaire officiel les choses se disent ainsi :

• le /24 est sous-alloué par le LIR au FAI
• un /25 est assigné par le LIR au FAI
• un /29 est assigné par le FAI et le LIR, à Joséphine

Le fait que le LIR ait sous-alloué tout le /24 au FAI permet à ce dernier d'en avoir la maîtrise et de le router sur internet. Cela lui permet aussi de se faire déléguer les reverse DNS pour gérer à sa guise la résolution des adresses.

Pour autant il n'est pas possible d'assigner des adresses à la fois au FAI et à Joséphine, ce doivent donc nécessairement être deux assignations différentes, mais pour satisfaire au besoin de routage indépendant du FAI, dans le même /24.

La nature de la relation du LIR au FAI est double : il y a à la fois la sous-allocation et l'assignation. Avec Jospéhine c'est plus simple, une seule assignation.

Un FAI pouvait espérer obtenir son /24 et en disposer librement. Devoir faire une assignation séparée pour chaque petite réseau d'abonné peut sembler décourageant, mais le Ripe l'impose.

Devoir payer des frais à chaque assignation peut également représenter un frein. Mais ce coût s'explique d'une part par la réalité d'un travail à fournir, et d'autre part par une nécessité en quelque sorte dissuasive : les ressources IPv4 sont limitées et leur demande doit être un acte réfléchi, d'autant que maintenant le recours à des IPv6 doit être privilégié. Cependant cet aspect dissuasif peut aussi être géré par le FAI (qui sait qu'il a des ressources limitées à sa disposition) et lors de la justification du dossier.

Dans le contexte d'Opdop, pour chaque assignation il y a un dossier et une gestion, donc des frais. Mais la relation privilégiée qui est établie entre le LIR et le FAI permet de préparer le terrain et de faciliter les choses. Il leur revient donc de mettre en place un terrain favorable aux abonnés, le FAI pouvant servir d'intermédiaire et facilier le travail pour réduire les coûts induits par chaque besoin de ses abonnés.

Une convention spécifique peut donc être conclue entre les trois parties (LIR, FAI et abonné) et qui prévoie des modalités spécifiques. Ces modalités n'existent pas encore dans le document qui détaille les participations aux frais du LIR Opdop.

La logique d'Opdop n'est pas commerciale. Il s'agit avant tout de définir les modalités équitables qui permettent aux FAI de gérer leurs besoins et ceux de leurs membres. Elles doivent être raisonnables et faire sens pour tout le monde. Opdop invite donc les petits FAI à participer à cette réflexion aussi bien sur les tarifs que sur la convention tripartite à mettre en place.

Une proposition qui semble correcte consisterait à amender les tarifs publiés comme suit :

• pour le FAI associatif
  • frais d'assignation : préparation: 75, suivi: 75 (offerts si l'association a moins d'un an)
  • frais récurrents : inchangés

• pour leurs abonnés demandeurs de réseaux dédiés
  • frais d'assignation : préparation: 75, suivi: 75
  • frais récurrents : cotisation: 30, objet: 4

Si le FAI associatif prend en charge la préparation du dossier et la préparation des objets utiles pour renseigner la base Whois alors les frais d'assignations pour leurs abonnés sont ramenés à

• 25 pour la préparation et 25 pour le suivi.

Tous ces chiffres sont HT et la TVA à 19,6% est appliquée en sus.

Maintenant qu'on a vu le principe en IPv4, on peut transposer en IPv6.

L'idée est toujours d'avoir un subnet routable, assez vaste pour contenir à la fois les besoins en propre du FAI et ceux de ses membres. Mais les proportions sont assez différentes en IPv6, comme toujours.

Le Ripe permet à chaque entité de se voir attribuer, simplement (c'est à dire sans devoir remplir plein de paperasses), jusqu'à un /48 par « site ». Par « site » on entend un « point de présence », ou bien un lieu, la notion est assez floue et il convient de l'apprécier selon son besoin et son organisation.

Donc il se trouve que un abonné peut obtenir un /48 pour chez lui, aussi facilement que le FAI pour son infrastructure sur un site donné.

Il est rare que plus d'un /48 parsite soit réellement utile, donc partons là-dessus. Mais en fait cette partie sera souvent, dans le contexte d'un FAI, la portion congrue de l'espace utile total.

Ensuite pour les membres il y a une savante mutliplication à faire.

Quel espace attribuer à chaque membre : un /64, un /56, un /48 ? Jusqu'à cette taille de réseau, pas besoin de justification je le répète. Le /64 est réellement le strict minimum, il ne permettra à l'abonné que d'avoir un seul réseau chez lui, c'est très peu.

Mettons /x.

S'il y a plusieurs sites prévus, il faut prévoir le cas le plus gros : 16 abonnés (y=1) ? 256 (y=2), davantage ?

A chaque fois, c'est 4 bits qu'il faudra retirer du x du paragraphe précédent.

On en est donc à /x-y*4

S'il y a plus d'un site, on doit en principe et pour respecter les bonnes pratiques, encore griller 4 bits. Dans la pratique, si le nombre est très restreint, ça peut peut-être se négocier plus raisonnablement avec votre LIR.

Mais mettons z=1, pour l'exemple.

Et notons que pour chaque site, il faudra que le premier /48 soit pris par le FAI pour son infrastructure propre.

Le total à réserver à votre FAI serait donc un préfixe de longueur x-(y+z)*4.

Un exemple, pour 200 adhérents avec des /56, et en prévision de 3 à 5 sites : 56-4*(2+1) = /44.

• /44 le total utile
• un /40 par site, donc le premier /48 pour l'infrastructure du FAI
• des /56 pour les adhérents (255 disponibles par site)

Ensuite pour bien s'entendre avec son LIR, il faut utiliser les bons termes. Ils diffèrent un peu des termes utilisés en IPv4, mais les concepts permettent de nous y retrouver tout de même.

Voici ce qu'on avait retenu en IPv4 :

• un /29 est assigné par le FAI et le LIR, à Joséphine

En IPv6 c'est un /56 par exemple (x=56), et le terme est toujours une assignation, le statut dans la base est ASSIGNED.

• un /25 est assigné par le LIR au FAI

C'est ici un /48 par site. Assigné, aussi, donc encore un statut ASSIGNED.

• le /24 est sous-alloué par le LIR au FAI

Et là c'est par exemple un /40. Et le statut est ALLOCATED-BY-LIR.

Mais en IPv6 il y a une astuce, parce que en IPv4 les FAI ne s'embêtaient souvent pas à déclarer chaque abonné au Ripe (ils ne leur attribuaient qu'une seul adresse IP, c'était pas utile), mais en IPv6 comme ils attribuent forcément un subnet de à minima une taille /64, il faudrait en principe faire une déclaration à chaque fois.

Devant cet immense travail menaçant, le Ripe a prévu de simplifier la procédure, et de déclarer un bloc fourre-tout dans lequel le FAI aura le droit de prendre, pêle-mêle et sans déclarer le détail dans le Whois, des réseaux de même taille qu'il aura assigné à ses membres.

Ce fourre-tout a un statut AGGREGATED-BY-LIR, et dans notre cas (ci-dessus) ce seront des blocs contenus dans le /x+4*y réservé au site.

Sur chaque site on aura donc le /48 du FAI, et puis un bloc AGGREGATED-BY-LIR ou plusieurs, si le FAI a besoin d'assigner des /x de tailles différentes à certains membres il lui faudra un bloc fourre-tout pour chaque valeur de x, le tout étant compris dans le subnet du site.

Et tout ça, répliqué sur chaque site.

La manière de construire en IPv6 pour un FAI est une approche de bas en haut (les besoins des adhérents, fois leur nombre, fois le nombre de site). Le résultat est une organisation arborescente régulièrement répartie; en respectant les principes des best current operational practices.

• segmenter le découpage sur des frontières de 4 bits
• mettre ensemble ce qui est local pour avoir des ensembles routables
• garder le premier /48 de chaque site pour les besoins d'infrastructure

Il n'est pas rare pour un FAI local d'arriver ainsi à un /40 voire un /36 s'il prévoit de grossir un peu. Un équilibre peut se trouver entre le nombre de sites et le nombre d'adhérents rattachés à un site, par exemple si sur une résidence étudiante on compte qu'un site est un bâtiment, un étage ou toute une résidence.

L'important est de conserver partout une marge de manoeuvre suffisante (les IPv6 sont nombreuses, l'idée est de voir à long terme), et de ménager un plan lisible et cohérent.