Toute machine faisant partie d'Internet doit avoir une ou plusieurs adresses IP publiques. Les adresses IP publiques font partie des ressources qui doivent être uniques au niveau mondial : il ne peut y avoir deux adresses IP publiques utilisées au même moment par deux machines, de la même manière qu'un numéro de téléphone est attribué une et une seule fois à une seule et même personne. Il y a évidemment des exceptions qui confirment la règle, comme l'anycast.

Les adresses IP sont limitées en nombre : il y a 2^32 IPv4 et 2^128 IPv6 différentes. Il faut donc distribuer ces ressources de manière cohérente au niveau mondial pour éviter les doublons et aussi, soyons réalistes, pour déterminer des responsabilités (exemple : une attaque informatique vient de telle IP, qui en est le propriétaire ?).

La meilleure façon de réaliser une distribution cohérente de ressources c'est de tenir un annuaire (telle adresse, je l'ai attribué à telle personne). On se rend compte que ce modèle centralisé ne passe pas à l'échelle du monde.

Depuis la fin des années 1990, l'IANA (bras droit de l'ICANN pour la technique) est au sommet de la pyramide de distribution. Cette organisation de droit état-unien distribue des blocs d'adresses IP à des entités dites régionales, les RIR (Regional Internet Registry). Il existe 5 RIR :

• RIPE-NCC (Réseaux IP Européens) pour l'Europe et le Moyen-Orient ;
• ARIN (American Registry for Internet Numbers) pour l'Amérique du Nord ;
• APNIC (Asia Pacific Network Information Center) pour l'Asie et le Pacifique ;
• LACNIC (Latin American and Caribbean IP address Regional Registry) pour l'Amérique latine et les îles des Caraïbes ;
• AfriNIC (African Network Information Center) pour l'Afrique.

Les RIR découpent les blocs d'adresses qu'ils reçoivent et les attribuent à leurs membres qui sont nommés LIR (Local Internet Registry) et qui partagent les coûts de gestion de cet annuaire et les coûts de fonctionnement des structures comme les RIR.

Ces LIR (qui sont généralement des opérateurs réseaux) peuvent utiliser les blocs d'adresses qu'ils obtiennent pour leur usage propre et/ou en distribuer une partie à d'autres entités finales : des opérateurs réseau.

Selon la législation locale, les opérateurs réseau peuvent être tenus de tenir un journal indiquant à qui ils ont attribués telle adresse IP entre telle heure et telle heure. C'est le cas en France.

Une ressource dite « Provider Independent » (PI) est attribuée à une entité finale. Même si cette entité décide de changer de LIR, elle conserve les ressources qui lui ont été attribuées. Une ressource dite « Provider Aggregatable » (PA) “appartient” au LIR qui la sous-loue. Changer de LIR dans ce cas-là revient à perdre ses ressources.

Il n'est plus possible d'avoir des blocs IPv4 PI à cause de la pénurie sauf à acheter des adresses sur le marché gris… Ce qui n'est pas cool ni ne doit être encouragé : les adresses IP, c'est comme l'air, une ressource commune que l'humanité se doit de gérer en commun sans la facturer (mais facturer sa bonne gestion commune n'est pas exclu).

Il est possible d'avoir des blocs IPv6 PI et des numéros d'AS PI. Sous l'égide du RIPE, il faut néanmoins contracter avec un LIR qui sera sponsor LIR, c'est-à-dire référant administratif auprès du RIPE pour le maintient d'un contact, le RIPE cherchant à éviter les erreurs du passé (des blocs attribués à on ne sait plus vraiment qui dont la récupération pour les remettre dans le pot commun est extrêmement difficile). Les ressources appartiennent néanmoins à l'entité finale, pas au LIR, qui peut donc changer de sponsor LIR à tout moment sans perdre ses ressources.

Il y a des LIR associatifs (Gitoyen, Tetaneutral.net,…) et des LIR commerciaux mais avec une forme juridique sympathique (OpDop (SCIC), Absolight (SCOP)) en France ou en Europe.

En février 2013, nous avons choisi OpDop. Pour quelles raisons ?

• Gitoyen était alors trop central dans la Fédération FDN, Tetaneutral.net n'était pas encore LIR. Il fallait donc diversifier afin de renforcer le réseau (tous les FAI de la FFDN ne doivent pas tomber si Gitoyen met la clé sous la porte) ;

• Travailler avec une SARL au lieu d'une association nous gênait mais OpDop allait devenir une SCIC sous peu dans laquelle ARN pourrait prendre des parts de capital à la manière d'une cotisation dans une association. La forme juridique SCIC introduit une notion de contrôle de la structure par les membres et une certaine notion d'éthique qui, même si elle est moins centrale que dans une association, a le mérite d'exister ;

• En 2012, un des gérants d'OpDop a formé (pro-bono, ça va de soi) les techs ARN sur les notions de plan d'adressage, de distribution des adresses au niveau mondial et des politiques du RIPE. Bref, un très bon contact humain ;

• Enfin, OpDop fournit des blocs d'adresses PA non-routés. Et ça, c'est plutôt capital pour nous.

De la PA non-routée ?

En très grande majorité, les LIR sont des opérateurs réseau qui deviennent LIR car ils proposent des services sur IP (transit IP, hébergement,…) ce qui fait qu'ils ont besoin d'attribuer des adresses IP à leurs clients. On note donc une dépendance entre un service sur IP et le service de fourniture d'adresses en lui-même : rompez le contrat de service et vous perdez vos adresses.

Comme ces entités sont des opérateurs, les RIR leur impose d'annoncer l'intégralité du bloc qu'ils ont reçus. Les différentes normes techniques et bonnes pratiques imposent à un opérateur qui annonce un bloc sur Internet de savoir joindre chaque adresse de ce bloc. C'est ainsi que, même si vous choisissez un autre transitaire, vous devez quand même monter une liaison physique (ou logique si le LIR est arrangeant) avec votre LIR pour ce besoin précis. Cette liaison sert également à récupérer le trafic résiduel émis par les opérateurs qui ignoreraient ou ne recevraient pas votre annonce BGP plus spécifique et enverraient donc le trafic qui vous est destiné à votre LIR. Vu les coûts (de mise en place puis récurrents) de ces liaisons physiques, ce n'est pas rien.

OpDop fournit des services à destination des opérateurs (OpDop = opérateur d'opérateurs ;) ). OpDop s'interdit de mélanger service sur IP et fourniture d'adresses. OpDop n'a aucune infrastructure technique et n'est donc pas opérateur. Donc OpDop n'annonce pas le bloc d'adresses qu'il a reçu du RIPE. Donc il n'est pas nécessaire d'avoir une liaison vers OpDop. Chaque client d'OpDop annonce le bloc d'adresses qu'il a reçu et c'est tout. Si le client quitte OpDop, c'est que le litige porte forcément sur la manière d'attribuer les adresses puisque cette prestation n'est liée à aucun service donc le fait de perdre ses ressources (principe du PA) est légitime.

La critique négative adressée envers la pratique d'OpDop est qu'elle contribuerait à faire grossir inutilement la table de routage globale d'Internet. En effet, puisque chaque client d'OpDop annonce lui-même son bloc, cela ajoute autant de lignes dans la table de routage alors qu'il y aurait une seule ligne si OpDop annonçait l'intégralité de son bloc d'adresses. La conséquence de cela est que ça forcerait les opérateurs à investir toujours plus dans des routeurs capables de gérer une table de routage toujours plus grosse : les cartes à l'intérieur des routeurs qui se chargent de transférer les paquets ont une capacité mémoire (TCAM) limitée car ce type de mémoire coûte cher. La pratique d'OpDop irait donc à l'encontre du principe du type « Provider Aggregatable » qui visait à ne pas faire exploser la taille de la table de routage mondiale.

Cette critique ne nous atteint pas :

• Chez ARN, nous avons voulu avoir un deuxième transitaire dès le premier jour. Cela signifie que nous ajouterions forcément une ligne supplémentaire à la table de routage, PA routée ou non-routée.

• L'équipe tech actuelle est composée de libristes convaincus qui râlent contre la vente liée “ordinateur + système d'exploitation” donc ces mêmes personnes ne vont pas cautionner un principe de vente liée similaire “service IP + fourniture d'adresses”.

• Taper sur la PA non-routée, c'est bien mignon mais quid de la revente de blocs d'adresses IPv4 qui fait forcément augmenter la taille de la table de routage au profit du business ?

• Le débit consommé nous semble être facturé bien au-dessus du coût réel de production par les transitaires. À ce prix-là, on espère bien qu'ils provisionnent l'achat de futurs routeurs à même de gérer une table de routage mondiale toujours plus grosse et des débits toujours plus importants.

Cette partie n'est pas un encart publicitaire inséré par notre LIR, juste un retour d'expérience et une documentation de ce que nous avons retenus et compris après avoir écoutés plusieurs personnes / LIR.

Nous utilisons chaque IP individuellement : il n'y a pas de notions de network/broadcast. Le plan d'adressage ci-dessous est indicatif : nous n'avons pas réellement un /27 dédié à notre infra propre ni une route /27 : juste des /32 contiguës. L'indication « /27 » permet de communiquer facilement entre admins (on sait à partir de quelle adresse commence et termine la partie infra, par exemple). Cela permettrait également d'agréger les routes en réseau pour une diffusion plus aisée dans un protocole de routage interne. Chose que nous ne faisons pas. Seule exception qui confirme cette règle : notre serveur OpenVPN vers lequel est bien routé le /26 indiqué ci-dessous.

Toutes les interconnexions (entre une machine virtuelle et son hyperviseur, entre une machine d'un-e abonné-e hébergée dans notre baie et nos routeurs, entre nos deux routeurs/hyperviseurs, entre les hyperviseurs et les PDUs,…) sont adressées avec des adresses IP locales au lien (voir ci-dessus) afin d'économiser nos IP publiques. Cela permet aussi de s'abstraire des contraintes matérielles : une machine virtuelle ne sait pas sur quel hyperviseur elle est exécutée à un instant T : il faudrait donc modifier son routeur de sortie à chaque migration d'un hyperviseur à un autre ? C'est ingérable. De par leur nature même, une adresse IP locale au lien peut être utilisée sur autant d'interconnexions que désiré. Donc la TAP de chaque machine virtuelle est adressée avec une IP locale au lien, toujours la même et zooout : une seule et même adresse à indiquer comme routeur de sortie dans chaque machine virtuelle. Seule exception : notre service de VPN utilise une interconnexion adressée avec des IP publiques car OpenVPN ne semble pas pouvoir faire autrement simplement.

Un IP Address Management est un logiciel qui permet de savoir à quel-le abonné-e à un service on a assigné telles adresses/blocs IP (v4 et v6), sur telle période de temps. Ce type de logiciels permet aussi de faire des stats sur le taux d'utilisation d'un bloc IP, Enfin, ils permettent de créer facilement / automatiquement des reverses DNS.

Nous n'avons pas de gros besoins : nous ne faisons pas d'adressage dynamique, nous savons gérer nous-même les reverse (ou les calculer avec sipcalc), nous savons faire des stats d'utilisation nous même. Toutefois, nous avons finalement opté pour gérer les IPs avec COIN.

Pour apprendre comment concevoir un plan d'adressage qui tienne la route c'est-à-dire qui corresponde aux besoins que vous vous fixez tout en permettant une évolution future aisée, la vidéo de LDN est une très bonne source d'infos : Adressage IPv6/IPv4. Voir aussi les documents du RIPE (qui permet de prendre connaissance des contraintes comme un /36 par site, un seul /48 pour l'infra par site, etc.) : https://www.ripe.net/support/training/material/ripe-ncc-training-material#IPV6

Le backbone sert à adresser tout ce qui est routage interne (routeurs, transit/peering, sondes, etc.).

89.234.141.0/24 (89.234.141.0 - 89.234.141.254)

/26 ADSL & VPN        -- 64:0-63

/27 INFRA             -- 32:64-95
    
/27 VPS & housing     -- 32:96-127
      (attention, ce découpage pourra varier en fonction du nb d'abonnés à chaque service)
    96/28 - VPS       -- 16:96-111
    111/28 - housing  -- 16:112-127
    
/28 BACKBONE          -- 16:128-143
/28 VPS               -- 16:144-159

2a00:5881:8100::/40

2a00:5881:8100::/40

2a00:5881:8100::/44
  2a00:5881:8100::/48 : Infra
    2a00:5881:8100:0000::/56 : routage (en /112 par interco, 2a00:5881:8100::<ID>:[12])
    2a00:5881:8100:0100::/56 : intercos VPN
      2a00:5881:8100:0100::/64 : interco VPN - utilisé
    2a00:5881:8100:0200::/56 : collecte ADSL
    2a00:5881:8100:0300::/56 : sondes
    [gap]
    2a00:5881:8100:1000::/52 VMs d'infra (services) en /56
      2a00:5881:8100:1000::/56 VMs simples sans subnet (/64)
       
      2a00:5881:8100:1100:0000::/56 VMs avec subnet
    [gap]
    2a00:5881:8100:ff00::/56 : Intercos externes
  2a00:5881:8102:: - 2a00:5881:810F:: Réserves

2a00:5881:8110::/44 -> déclaré en fourre-tout  de /56 au RIPE
  2a00:5881:8110::/48 VPS = 256 VPS
  2a00:5881:8110:0000::/48 VPS 0
    Réserve 3* /48 (8111 + 8112 + 8113)
  2a00:5881:8113:ff00::/48 VPS X
  
  2a00:5881:8114::/48 housing = 256 réseaux d'hébergés
    2a00:5881:8114:0000::/56 : hébergé 0
    Réserve 3 * /48 (8115 + 8116 + 8117)
  2a00:5881:8117:ff00:/48 hébergé X
  
  2a00:5881:8118::/48 VPN = 256 VPN
  2a00:5881:8118::0000::/56 : VPN 0
    Réserve 3 * /48 (8119, 811a, 811b)
  2a00:5881:811b::ff00::/48 : VPN X 
  
  2a00:5881:811c::/48 ADSL/FO = 256 ADSL/FO
  2a00:5881:811c::0000::/56 : ADSL/FO 0
    Réserve 3 * /48 (811d, 811e, 811f)
  2a00:5881:811f::ff00::/48 : ADSL/FO X
  
-> fin du fourre-tout
  
2a00:5881:8120::
    Futurs nouveaux services innovants d'ARN (14 * /44)
2a00:5881:81ff::

89.234.141.0/24 (89.234.141.0 - 89.234.141.254)

0/26 ADSL & VPN        -- 64:0-63
     .1      serveur VPN      -> IP de la passerelle sur tun0
     .63     IP qu'openvpn n'utilise pas
  
64/27 INFRA             -- 32:64-95
  
    .64      ext (VM 0)     -> 
    .65        ns0 (LXC)      -> Serveur DNS qui fait autorité pour la arn-fai.net, sans-nuage.fr et netlib.re
    .66        recursif (LXC) -> Serveur DNS pour la résolution
    .67        mail (LXC)     -> Serveur mail arn-fai.net
    .68        web (LXC)      -> Site arn-fai.net
 
    .69      int (VM 1)
    .70        puppet (LXC)   -> Gestionnaire de configuration des machines
    .71        radius (LXC)   -> Serveur d'authentification
    .72        zabbix (LXC)   -> Serveur de monitoring
 
    .73      VPN (VM 2)     -> Serveur openVPN
    .74      Forum Discourse (VM)
    .75      adh (sur int)  -> COIN
    .76      lineageos      -> Machine virtuelle pour le bridge Whatsapp
    .77      servicesadh (VM 4) -> sans-nuage.fr
    .94      AES-VPN (VPN temporaire, routé sur la VM VPN)
      
96/27 VPS & housing     -- 32:96-127
   96/28 - VPS       -- 16:96-111
   111/28 - housing  -- 16:112-127
      
129/28 BACKBONE          -- 16:128-143
  
  .129    Laptop d'un admin dans le DC
  .130    master ganeti
  .131    hwhost-1
  .132    hwhost-2
    
144/28 VPS               -- 16:144-159

160... Non utilisé

TODO

• 89.234.141.0/24 (en sous-allocation, 89.234.141.0 - 89.234.141.143)
  1. un /29 pour backbone (routeurs) – 8:.0-.7
     • VM de routage
     • sorties transit + peering (normalement fourni par le transitaire / GIX)
     • entrée collecte
     • routeur interne, sondes
  2. un /29 pour les services de base – 8:.8-.15
     • VM DNS, DB, backup, Mailing ARN, etc
     • VM d'infra web / VM d'infra mail pour les adhérents ?
  3. un /27 pour les VM – 32:.16-.47
     • VM pour adhérents
  4. une cinquantaine d'adresses pour les accès, donc un /26 – 64:.48-.111
  5. encore une vingtaine pour les VPN, donc un /27 – 32:.112-.143
  6. Donc un /25 et un /28 assignés à ARN, le reste du /24 pour assignations ultérieures (nous ou abonnés).

Découpage correspondant (abandonné car trop peu flexible) :

/26 accès  -- 64:0-63
/27 VPS    -- 32:64-95
/27 VPN    -- 32:96-127
/29 infra  -- 8:128-135
/29 back   -- 8:136-143

Source de toute cette partie : lulu (pseudo d'un des gérants d'OpDop), IRC, 27/07/2013.

2a00:5881:8100::/40

• Le /40 est pour un POP et tout ce qui est rattaché à ce POP (blocs ADSL, blocs VPN, blocs VPS, …). On demandera un autre /40 si on a un jour un autre POP. Lulu a de l'espace contiguë après notre /40.

• Le premier /48 pour nous, après pour les adhérents

• Plus précisément, pour la partie adhérent. Comme on distribue des subnets, il faudrait normalement faire les déclarations qui vont bien à notre LIR et au RIPE : on a distribué quel subnet à qui (comme quand on refile un subnet en v4). Pour éviter la galère, on utilise des fourre-tout : un ou plusieurs blocs qu'on subnettera pour les adhérents sans donner le détail « tel bloc je l'ai attribué à lui » à notre LIR et au RIPE. Les fourre-tout doivent être subnettés en subnet de taille égale. Cela veut dire que si l'on attribue un /x pour un ADSL et un /y pour un VPN, les blocs ne seront pas dans le même fourre-tout. Si l'on attribue la même taille pour tous nos services, ce n'est pas forcement mieux de faire des fourre-tout différenciés par l'usage car perte de souplesse et d'espace. Pour plus d'infos, voir : http://wikilulu.net/doku.php?id=tech:petit-isp-routable#le-fourre-tout

• Une fois le découpage choisi, il faudra donc le signaler à lulu pour qu'il déclare les fourre-tout qui-vont-bien : les fourre-tout ne sont que des objets dans la DB du RIPE, des inetnum de type AGGREGATED-BY-LIR dans la définition duquel la taille des subnets qu'il contient est définie par un champ “assignment-size”.

• Lulu pense que garder un deuxième /48 d'infra “au cas où” n'est pas pertinent (exploser un /48 entier en infras …).

• Lulu conseille de garder de la marge (ie : ne pas utiliser plus d'un quart du /40) pour voir comment ça va évoluer.

On utilise des IPs locales au lien (voir https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml et https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml) pour plusieurs choses :

• Lien direct entre les deux machines physiques (pour iBGP et DRBD) : 169.254.69.0/24 et fe80::69:0/112

• Interface TAP d'une machine virtuelle (utile pour forwarder les paquets à un routeur depuis une machine virtuelle sachant qu'on ne connaît pas l'hyperviseur/routeur sur lequel la VM est exécutée + économie d'IPs publiques) : 169.254.42.0/24 et fe80::42:0/112

• 169.254.43.0/24 et fe80::43:0/112 sont aussi utilisés pour l'hébergement des machines physiques dans notre baie, pour les mêmes raisons car nous utilisons CARP.

• Réseau contenant les PDU : 169.254.12.0/24 et fe80::12:0/112 (réservé en avance mais nos PDUs actuels ne prennent pas en charge IPv6)

Attention : bien que 169.254.0.0/16 est réservé à l'IANA pour cet usage, Linux ne les considère pas comme des adresses link-local : il faut donc préciser « scope link » dans /etc/network/interfaces ou ip addr add.

Pourquoi le troisième octet IPv4 est 12, 42 ou 69 ? Aucune raison, c'est choisi au pif. ;)