Difference between revisions of "MOOC:Compagnon Act16"

From Livre IPv6

Revision as of 13:23, 22 April 2015

Activité 16 : Construction d'un plan d'adressage

Nécessité d'organiser un plan d'adressage

Comme nous l'avons vu dans les activités précédentes, l'espace d'adressage IPv6 est « astronomiquement » grand. Le plan d'adressage unicast global agrégé adopté aujourd'hui sur l'Internet public est organisé hiérarchiquement. A l'instar du réseau téléphonique historique, où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), les réseaux IP sont bâtis selon une organisation hiérarchique. Cependant cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...), gérées par les registres Internet régionaux (RIR Regional Internet Registry). Cela permet d'acheminer efficacement les datagrammes. Les opérateurs du cœur de l'internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les registres régionaux leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi un utilisateur final : organisation, entreprise ou particulier se verra déléguer par son fournisseur d'accès Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. Cette zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (Subnet ID). En effet elle permet à l'administrateur, d'adresser entre 1'unique réseau (cas où le client à obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative, de son fournisseur d'accès, sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 63) pour numéroter 2 puissance 16 réseaux). C'est cet espace de l'adressage, dont l'administrateur réseau a la responsabilité, qu'il s'agit d'organiser pour déployer efficacement les réseaux de son organisation. Nous allons au cours de cette activité, présenter différents modes d'organisations possibles, que nous compléterons par un cas d'école simple.

Politique d'assignation des adresses

Les spécifications primitives, (RFC3177) de 2001, d'assignation des adresses aux utilisateurs finaux recommandaient d'allouer :

/48 (655536 sous réseaux) dans le cas général,
/64 (un sous réseau unique) lorsqu'un et un seul réseau était nécessaire
/128 (adresse unique) lorqu'il était absolument connu qu'un et un seul équipement était connecté

Le RFC6177, de 2011, également connu sous BCP157 (Best Current Practice), est venue remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi si un /48 est adapté pour un réseau de campus il est, clairement, surdimensionné dans le cadre d'un usage domestique. Inversement le réseau unique en /64 est notablement insuffisant, les besoins actuels et futurs de le plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia,...), réseau domotique (machine à laver, sèche linge, réfrigérateur, ...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium,...), sans parler des promesses médiatiques de « l'Internet des objets » (IoT Internet of things),… Pour les utilisateurs dits « grand public » ou les sites de taille modeste un préfixe /56 ou /60 semble donc plus approprié.

Préfixes de sous Réseaux

Cas général

Les sous réseaux IPv6 devraient s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problèmes pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.

Cas particulier des liaisons point à point

Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire,...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (Ip dans IP, VPN MPLS, tunnel IPSec, …) constituent un cas particulier. Comme dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi attribuer un /64, offrant la possibilité d'adresser 2 puissance 64 interfaces, à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées mais qui peuvent sur certains équipements, limités ou mal configurés, conduire à des situations de surcharge sous forme d'aller retour de datagrammes sur cette liaison (syndrome de la balle de ping pong), ou de tentatives de déni de service par attaque exhaustive de découverte de voisins. A défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?

/127 : serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de host tout à 1 dans le cas d'IPv4). Cependant l'adresse tout à zéro de chaque sous réseau est réservé comme l'adresse anycast des routeurs (« all routers anycast address »), ce qui signifie que le plupart des routeurs sont susceptibles recevoir des datagrammes de service sur cette adresse.
/126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous réseaux sont également réservées pour diverses adresses de anycast (RFC2526). Bien que dans la pratique cela ne semble pas poser.
/120 permet de s'affranchir des adresses anycast réservées.
/112 permet de s'affranchir des adresses anycast réservées et a en plus l'avantage d'être facilement lisibles par les opérateurs humains, car aligné sur le mot de 16 bits final, (celui affiché après le dernier séparateur :, cf activité 12 « Notation d'une adresse IPv6 »)

Représentation des subdivisions

Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.
Nous supposons que le préfixe obtenu soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast globale routable sur l'Internet public, soit par algorithme conforme RFC4193 dans la cadre d'un adressage privatif (ULA Unique Local Address) pour notre activité est 2001:db8:cafe::/64. Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous réseaux possibles en /64 (de 2001:db8:cafe:0000::/64 à 2001:db8:cafe:ffff::/64).
Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible). Dans cette présentation nous subdivisons les 16 bits en groupes distingués de la manière suivante :

B : bits non définis et assignables
L : bits assignés à la localisation du sous réseau
T : bits assignés au type de sous réseau

Nous utiliserons la représentation suivante dans nos différents cas d'étude

activite-16-img01

Chaque case du champ SID représente 1 bit. 4 cases successives représente un « nibble » (Un nibble (ou plus rarement nybble) est, en informatique, un agrégat de 4 bits, soit un demi octet. On trouve aussi les termes francisés semioctet ou quartet , source wikipédia). 1 nibble peut prendre une valeur entre 0 et 15 et peut se représenter par 1 chiffre héxadécimal (0..9, a..f). Ainsi dans l'exemple du schéma précédent produira des adresses du type 2001:db8:LTBB::/64 (inversement de type 2001:db8:TLBB::/64 si l'on choisit de positionner les bits de type de sous réseau sur le nibble de poids fort et les bits de localisation sur le nibble de poids faible du 1er octet SID).

Différentes stratégies pour la définition des sous réseaux

Réseau à plat

Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra à minima, affecter 1 identifiant de sous réseau par domaine. L'attribution de ces identifiants de sous réseaux pourra être simple, en numérotant éventuellement séquentiellement.
En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous réseaux est amené à croître, l'administration et le contrôle de l'infrastructure devient rapidement problématique. Il y a, également, nécessité de conserver dans une table les différents affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement, puisque les adresses sont peu signifiantes.

Correspondance directe entre les identifiants IPv4 et IPv6

Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous réseau IPv4 et de sous réseau IPv6. Deux cas peuvent être évalués :

Correspondance directe entre les sous réseaux IPv4 et IPv6

Si les réseaux IPv4 sont structurés uniquement en sous réseaux de préfixe /24 (exemple les réseaux privatifs de la RFC1918, un réseau de classe C 192.168.0.0/24 à 192.168.255.0/24 ou que l'on a « subnetté » en /24 le réseau de classe A 10.0.0.0 ou l'un des 16 classe B 172.16.0.0 à 172.31.0.0), une correspondance directe entre l'identifiant de sous réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.

activite-16-img02

Dans ce plan d'adressage, le lien direct entre les sous réseaux IPv4 et les sous réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs,...) on peut également transposer l'identifiant d'hôte (les 4ieme octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 192.168.2.123 peut être adressé 2001:db8:cafe:2::123 en IPv6.
Cependant cette stratégie ne peut s'envisager uniquement si les sous réseau IPv4 sont alignés sur 24 bits (/24). En effet des sous réseaux IPv4 de taille plus étendue (préfixe < à /24) ou plus réduite (préfixe > à/24) ne peuvent s'insérer dans le champs SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au delà du /64 posant de problème pour l'auto-configuration). Ainsi :

un préfixe IPv4 /28, par exemple les hôtes 172.16.5.14/28 et 172.16.5.18/28 sont dans des sous réseaux IPv4 distincts, le sous réseau 172.16.5.0/28 pour le premier et le sous réseau 172.16.5.16/28 pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous réseau : les hôtes 2001:db8:cafe:5::14/64 et 2001:db8:cafe:5::18/64 sont tous les deux dans le sous réseau 2001:db8:cafe:5::/64.
Un préfixe IPv4 /23, par exemple les hôtes 10.0.8.250/23 et 10.0.9.5/23 sont tous le deux dans le même sous réseau IPv4. Alors que la transposition simple les placera dans des sous réseaux IPv6 distincts : 2001:db8:cafe:8::250/64 et 2001:db8:cafe:9::5/64

On notera également que la transposition directe des identifiants décimaux des sous réseaux IPv4 dans le champ SID hexadécimal du sous réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous réseaux IPv6. Ainsi le sous réseau IPv4 10.0.23.0/24 est sélectionné (filtré / masqué) sur 1 octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)

Correspondance directe entre les adresses IPv4 et IPv6

Si le préfixe de sous réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous réseaux IPv4 et IPv6. Cependant, dans ce cas il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous réseau IPv4. Par exemple la machine d'adresse IPv4 192.168.1.234 pourrait être adressée en IPv6 2001:db8:café:deca::192.168.1.234. En effet pour les adresses IPv6 embarquant une adresse IPv4, si celle ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface) il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui ci l'affichera sous la forme 2001:db8:cafe:deca::c0a8:1ea, notamment dans les journaux et log diverses. . c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite 192.168.1.234 en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.

Plan d'adressage structuré

Lorsque que l'on définit un plan d'adressage, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.

(schéma d'architecture inspiré de la page 9)

Structuration basique du plan d'adressage

Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi nous pouvons choisir d'adresser d'abord par type localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages

ré-afficher activite-16-img01
2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64

Dans cet exemple , 4 bits sont assignés pour la localisation {L}, les 4 bits suivants sont assignés pour le type d'usage {T}, il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'addresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de-réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous réseaux différents pour chaque localisation et chaque type.

Routeur vs firewall : Localisation ou type d'usage d'abord ?

Nous devons dans un premier temps décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que, public(DMZ), employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc,) ou inversement type avant la localisation.

Localisation d'abord

Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. A l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général de opérateurs ou les entités chargés des réseaux d'interconnexion des grandes organisations.

Type d'usage d'abord

Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage. L'avantage de grouper les réseaux par catégorie d'usage, est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations,…) sont régis selon les types d'usage plutôt que sur la localisation des utilisateurs.

La plupart des organisations choisissent de privilégier les types d'usage sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés, de type pare feu, placés frontalement à l'entrée du réseau. Une fois contrôlés les flux sont ensuite acheminés en interne en fonction de leur localisation. (schéma générique du cas courant, réseau comprenant un DMZ et un ensemble de domaines fonctionnels)

Détermination de l'espace nécessaire au plan d'adressage

Nous devons déterminer, quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure en ne négligeant pas les évolutions.

Déterminer le nombre de localisations ou types de réseaux de votre organisation,
augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone,
augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que les l'infrastructure des tunnels VPN par exemple,
augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme,

Pour chacune des catégories déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.

Exemple 1 : sous réseaux basés sur la localisation

schéma

nombre de localisations : 3
backbone d'interconnexion : 1
réseaux non localisés (tunnels VPN) : 1
extension future : 2

total : 7 sous réseaux => 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements

2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64

Exemple 2 : sous réseaux basés sur le type d'usage

schéma

nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,
backbone et infrastructure ; 1 sous-réseau,
usages futurs : 4 sous-reseaux

total : 10 sous-réseaux => 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autre référencements au besoin

2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64

Hiérarchisation à 2 niveaux

Dans les deux exemples précédents les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être crées (par les réseaux internes réservés au personnel peuvent être décliné pas service ou fonction : comptabilité, RH, direction, production,...). Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire

2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64

Il reste alors 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant elle alourdira les politiques de sécurisation, en multipliant les filtres, si la fonction de sécurisation (firewal)l est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site entraînant des difficultés de cohérence de déploiement des politiques de sécurité. Inversement privilégier le type d'usage sur la localisation

2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64

réduira le nombre de filtres de la politique de sécurisation, au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenus des capacité des routeurs modernes.

Latitude

Dans le exemple précédent, 4 bits sont utilisés pour les types de sous-réseaux et 3 pour la localisation, laissant 9 bits soit 512 (2 puissance 9) sous réseaux possibles par type et par site. Cela sera suffisant dans la plupart des cas. Cependant, imaginons qu'il faille 2048 tunnels VPN par site pour accueillir les connexions sécurisées des personnels nomades. On pourrait envisager de modifier les tailles de champs de structuration primaire et secondaire, mais cela nécessiterait une reconfiguration globale de l'architecture. Une autre option consiste à répartir les tunnels sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette manière on conserve politique de sécurité simple et cohérente

0	Backbone, infrastructure
1	Serveurs
2	Réservé expansion future
3	Réservé expansion future
4	personnels
5	étudiants
6	invités
7	Réservé expansion future
8	VPNs
9	VPNs
A	VPNs
B	VPNs
C	Réservé expansion future
D	Réservé expansion future
E	Réservé expansion future
F	Réservé expansion future

Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act16&oldid=5986"

Association G6