Meilleures pratiques en matière de disposition d'espace d'adressage IPv6


91

Je suis à l'aise avec les allocations d'espace d'adressage IPv4. Je veux dire par là: Étant donné les services à planifier, ou une organisation à mettre en réseau, je sais très bien comment planifier l'utilisation de l'espace d'adressage IP. (ou du moins, je pense que je le fais. :)

Existe-t-il des directives ou des études de cas sur les meilleures pratiques pour la disposition de l'espace d'adressage IPv6?


Réponses:


73

La mise en page que nous utilisons pour notre déploiement est la suivante:

  • / 48 par client
  • / 56 par site client (en tant que sous-réseau de l'autre / 48)
  • / 126 pour toutes les liaisons point à point du noyau, il s’agit de tous les sous-réseaux de / 48 utilisés pour toutes les liaisons principales

Ces tailles sont principalement extraites de l’avis RIPE ici .


4
Bien que cela ne descende que sur un site. Que diriez-vous des réseaux locaux internes, étages, bâtiments, services, LAN vocal, convention du codage du VLAN en adresse réseau, etc.?
nos

1
Je voudrais ensuite utiliser un / 64 pour chaque VLAN / étage / bâtiment (ou quelle que soit votre allocation fonctionne).
David Rothera

ARIN (le RIR à propos pour moi) a-t-il des recommandations / avis?
Craig Constantine

Je suppose que vous avez des moyens de surveiller les abus de la part de spammeurs qui aiment graver leurs adresses IP attribuées?
Frogstarr78

3
ripe.net/lir-services/training/material/… a une très bonne lecture (merci à Marco Hogewoning de m'avoir signalé le problème).
Andrew Y

26

L'ancienne recommandation était d'utiliser / 64 partout, même sur des liens P2P, et d'attribuer un / 48 par site.

L'utilisation de grands sous-réseaux vides sur des liaisons point à point peut entraîner un certain nombre de problèmes de sécurité potentiels (voir RFC6164 ). Il est donc désormais recommandé d'utiliser un / 127 pour les liens P2P et / 128 pour les bouclages.

Il n'est pas nécessaire de donner un / 48 à un petit client bien que vous ayez beaucoup d'adresses à faire si vous le souhaitez.

Les interfaces auxquelles sont confrontés les clients doivent être / 64 si vous souhaitez utiliser SLAAC. Si vous n'avez pas l'intention de l'utiliser, vous pouvez utiliser un autre masque.

Voici quelques bons liens à parcourir:

BRKRST-2301 de ciscolive365.com (créer un compte gratuit) http://www.cisco.com/web/strategy/docs/gov/IPv6_WP.pdf
http://tools.ietf.org/html/rfc5375.html
http: //tools.ietf.org/html/rfc6177

Certaines personnes prennent leurs assignations v4 actuelles et convertissent les deuxième et troisième octets en hex et l'utilisent pour la v6. Il existe de nombreuses façons de le faire, vous devez donc choisir ce qui vous convient le mieux.


5
Je soutiens que tout schéma d'adressage IPv6 basé sur un schéma d'adressage IPv4 existant devrait être soumis à un contrôle supplémentaire. C’est une occasion de se libérer des chaînes du passé et non une corvée par cœur pour les reproduire fidèlement.
neirbowj

2
Je crois comprendre que le plus petit sous-réseau qu'il est conseillé de créer (liens P2P mis à part) est un / 64. Si je suis un client à domicile et que je souhaite avoir plusieurs sous-réseaux sur mon réseau local, sans utiliser NAT6, je veux plus que / 64. En tant que personne intéressée par le fait d’avoir IPv6 chez moi et qui sait combien il y a de quadrillions de / 64 ans, je veux au moins un / 60.
Luke n'a pas de nom.

22

Avec IPv6, vous n'avez plus à vous soucier d'allouer de l'espace pour un nombre donné d'hôtes. Tous les sous-réseaux (autres que les liens P2P) doivent être affectés en tant que / 64, ce qui vous donne un nombre ridicule d'adresses hôtes. Cela vous permet de vous concentrer sur d'autres sujets tels que la bonne conception et la disposition du réseau. (A / 48 vous donnerait 65 536/64 réseaux)

Il y a (bien sûr) plusieurs écoles de pensée à ce sujet. Si vous êtes déjà assez satisfait de votre conception IPv4, alors faire une superposition IPv6 qui reflète les choses est probablement une bonne option et facilite la transition pour tout le monde.

  • 2001: 0DB8: 1: 1 :: / 64 -> 10.1.1.0 / 24
  • 2001: 0DB8: 1: 2 :: / 64 -> 10.1.2.0 / 24
  • ...
  • 2001: 0DB8: 1: 254 :: / 64 -> 10.1.254.0 / 24

Jouez avec certaines des calculatrices IPv6 pour vous aider à comprendre tout cela. Voici un exemple: GestioIP Online IPv4 / v6 Calculator

C’était la chose la plus difficile à surmonter pour moi. Ne vous inquiétez pas de l’allocation d’espace aux hôtes! Planifiez votre réseau - concentrez-vous sur l'emplacement des limites de la couche 3, des services offerts, de l'emplacement physique des périphériques, etc. Il faudra probablement des années avant qu'un réseau IPv6 pur ne se crée, mais vous allez commencer à jeter les bases d'une bonne conception de réseau. maintenant.


19

Un peu de précision par rapport aux réponses précédentes, basée sur la session de formation RIPE IPv6 que j’avais eue il ya un an. Fondamentalement, leur recommandation est de se concentrer sur l’ agrégation plutôt que sur la préservation de l’espace .

C'est-à-dire: ne vous inquiétez pas de réserver un grand nombre d'adresses IP pour un point de présence, même si vous ne disposez que d'un petit nombre de sous-réseaux ici (pour l'instant). Mais vous devez regrouper chaque sous-réseau "vivant" dans un POP sous le même préfixe.

Leur principale préoccupation, maintenant que nous disposons d’une très grande quantité d’IP, est que si tout le monde annonce de petits préfixes avec une granularité fine, la taille de la table de routage DFZ risque d’exploser.

Voici le matériel de formation utilisé dans la présentation. En particulier, le premier PDF "Exercice de formation" donne quelques exemples de plan d’adressage.


12

Utilisez moi-même la mise en page suivante (centre de données pov)

Colocation clients: un / 48.

Serveurs dédiés: un / 64 par serveur par défaut.

Liens P2P (liens bgp, etc.): / 126

En ce qui concerne la transition IPv4 -> IPv6 vers un environnement à double pile pour les réseaux locaux virtuels hébergés, je fais correspondre le sous-réseau ipv4 à un sous-réseau ipv6 suffisamment grand pour contenir un / 64 pour chaque adresse ipv4.

Par exemple:

Vlan contenant un / 24 ipv4 (256 ip), je fais correspondre celui avec un / 56 Ipv6 (256 uniques / 64 sous-réseaux)

Vlan contenant un / 23 ipv4 (512 ip), je fais correspondre celui avec un / 55 ipv6 (512 uniques / 64 sous-réseaux)


11

SURFnet a écrit un bon manuel de plan de réseau IPv6 qui pourrait être utile


Ce lien est maintenant mort. c'est aussi une réponse assez superficielle. Peut-être pourriez-vous inclure quelques faits saillants de la source originale?
Ryan Foley

J'ai remplacé le lien par un hébergé chez RIPE (qui a sponsorisé la traduction). Il est assez difficile de donner un bon résumé du document car il aborde de nombreux scénarios différents, mais il correspond généralement à ce que d'autres ont mentionné ici. C'est un bon document pour vous aider à prendre des décisions sur la façon de choisir les adresses.
Teun Vink

La question concerne l'existence de meilleures pratiques en général, sans enquête spécifique. Cette réponse satisfait succinctement cette question. Upvote.
StockB

Comment afficher cette réponse sur Android? Quelle application fonctionne avec le fichier?
Ferrybig

4

C'est un peu intimidant de voir l'énorme espace d'adresse disponible, mais en pratique, ce n'est pas difficile à gérer.

Disons que vous êtes attribué a / 48. Cela vous donne 65K / 64 à jouer avec, chacun capable de contenir plutôt beaucoup d'adresses. De plus, l’erreur d’arrondi en 65K vous donne une poignée d’autres / <64 pour d’autres utilisations.

Personnellement, j'appelle / 64 sous-réseaux à partir de / 48 par VLAN. Je règle l’adresse du routeur sur :: 1 pour chaque VLAN. J'utilise :: xxxx pour DNS (où xxxx est un chiffre répété) et similaire pour quelques autres services. C'est plus facile à retenir.

Chaque boîte reçoit une adresse attribuée par SLAAC et tous les hôtes sont encouragés à définir également une adresse temporaire. De cette façon, nous pouvons trouver un système utilisant l’adresse SLAAC mais le système conserve un peu de confidentialité sur Internet - ou il le ferait, mais nous utilisons généralement un proxy Web - ahh mais cela a aussi une adresse temporaire! Pourtant, l'omniprésence d'IPv4 rend tout cela discutable.

Si vous avez plusieurs sites, divisez le / 48 en bits plus petits mais plus grands que / 64 - suffisamment pour couvrir toutes les éventualités. Cela vous permettra d'agréger quelque peu les tables de routage.

Franchement, en supposant que vous ayez un / 48 (j'en ai un pour moi, alors je n’en doute pas), alors vous devriez avoir assez d’espace pour couvrir la plupart des éventualités et des stratagèmes.

Maintenant, si votre configuration est plus grande - par exemple multinationale et multisite, je vous suggère d’enquêter sur PI puis de la diviser par pays / site / VLAN ou pays / localité / site / bâtiment / VLAN ou autre. Vous avez toujours beaucoup d’adresses dans un / 48 pour toutes les configurations, sauf la plus grande.



2

La plus grande préoccupation est probablement d'identifier vos goulots d'étranglement vont être, en termes d'agrégation de route. Les paramètres de base vont probablement être: chaque sous-réseau doit être un / 64 (dicté par IPv6), et vous avez un / 60, / 56 ou / 48 pour jouer.

Comme d'autres l'ont déjà dit, a / 48 vous donne 64 000 sous-réseaux, mais il est toujours facile de se peindre dans un coin si vous les attribuez simplement au hasard. Supposons que vous avez 1 000 magasins et attribuez-les séquentiellement à chacun d’entre eux dès le début. Ensuite, vous découvrez que le 43ème magasin a besoin d'un deuxième sous-réseau, ce qui signifie qu'il faut renuméroter ce réseau ou lui donner deux sous-réseaux distincts qui ne peuvent pas être agrégés.

Incidemment, dans le monde IPv4, vous obtenez également 64 000 sous-réseaux si vous utilisez le réseau 10.xxx et le sous-réseau vers / 24s. Certaines des pratiques que vous utilisez dans ce scénario peuvent bien traduire.

Une entreprise pour laquelle je travaille utilise 10.xxx en interne pour environ 150 succursales (avec entre 100 et 500 ordinateurs à chaque emplacement). Le deuxième octet est le numéro de branche et ils utilisent / 22 au lieu de / 24 pour leurs sous-réseaux. Ainsi, chaque succursale peut avoir jusqu'à 64 sous-réseaux, ce qui leur convient parfaitement.


Oui, la meilleure pratique consiste à attribuer à chaque site une longueur de masque inférieure ou égale à 56. En outre, il est recommandé de ne pas diviser les petits bouts lors de l'attribution d'objets (chaque longueur de masque attribuée doit être divisible par 4). Les opérateurs ne feront pas la publicité d’un préfixe plus long que / 48; ainsi, si les sites individuels doivent être annoncés séparément, ils ont chacun besoin d’un / 48.
Ron Maupin

Cette meilleure pratique (comme la plupart des meilleures pratiques) est généralement une bonne idée, mais ne convient pas toujours. Par exemple, si vous êtes un Starbucks ou un McDonalds, il se peut que vous n’en ayez pas assez / 56s pour tous vos magasins. C'est en fait la raison pour laquelle des organisations telles que les forces armées de plusieurs pays, et même une librairie à la chaîne, souhaitaient un préfixe / 29 ou même plus court.
Kevin Keane

1
Mon entreprise a eu un masque beaucoup plus court. Vous pouvez facilement obtenir une longueur de masque beaucoup plus courte afin d'affecter un / 56 (ou plus court) à chaque site. Tout ce que je dis, c'est que si vous souhaitez annoncer un préfixe sur Internet, vous devez utiliser une longueur de masque inférieure ou égale à 48. Obtenez un / 32 ou / 24, ce n'est pas difficile si vous en avez le besoin.
Ron Maupin

1

Meilleures pratiques en matière de disposition d'espace d'adressage IPv6

Je suis à l'aise avec les allocations d'espace d'adressage IPv4. Je veux dire par là: Étant donné les services à planifier, ou une organisation à mettre en réseau, je sais très bien comment planifier l'utilisation de l'espace d'adressage IP. (ou du moins, je pense que je le fais. :)

Existe-t-il des directives ou des études de cas sur les meilleures pratiques pour la disposition de l'espace d'adressage IPv6 ?

Réponse très courte: à partir de / 56, essayez de projeter ce qui sera utilisé dans les prochaines années et ajustez-le en conséquence. Les personnes qui demandent une adresse unique doivent encore disposer de quelques ressources pour une expansion future. Il est important d’éviter la fragmentation de l’attribution, bien au-delà d’une légère sur-allocation.


Une réponse plus longue:

Groupe de travail d'ingénierie Internet (IETF) - Meilleures pratiques actuelles :

  • Les RFC 6177 et BCP 157 - "Affectation d'adresses IPv6 aux sites finaux" précisent qu'une recommandation unique de / 48 n'est pas suffisamment nuancée pour la vaste gamme de sites finaux et n'est plus recommandée par défaut.

    1. Introduction - Plusieurs facteurs entrent en ligne de compte dans les stratégies d’attribution d’adresses. Par exemple, pour assurer la santé et l'évolutivité à long terme de l'infrastructure de routage publique, il est important que les adresses soient bien agrégées [ ROUTE-SCALING ]. De même, la distribution d'une quantité excessive d'espace d'adressage pourrait entraîner un épuisement prématuré de cet espace. Ce document se concentre sur la question (plus étroite) de la question de savoir quelle est la taille appropriée d'attribution d'adresses IPv6 pour les sites finaux. C'est-à-dire que, lorsque les sites d'extrémité demandent un espace d'adressage IPv6 aux fournisseurs de services Internet, quelle est la taille d'attribution appropriée.

    ...

    Ce document se concentre sur la question (plus étroite) de la question de savoir quelle est la taille appropriée d'attribution d'adresses IPv6 pour les sites finaux. En d’autres termes, lorsque les sites finaux demandent un espace d’adresse IPv6 aux fournisseurs d’accès Internet, quelle est la taille d’attribution appropriée.

    ...

    Ce document ne fait pas de recommandation formelle sur la taille exacte de l’affectation. Le choix exact de la quantité d'espace d'adressage à affecter aux sites finaux est un problème pour la communauté opérationnelle. Le rôle de l'IETF dans ce cas se limite à fournir des indications sur les considérations architecturales et opérationnelles d'IPv6. Ce document contribue à ces discussions.

    ...

    2. Affectations sur / 48 aux sites finaux - Si l’on revient sur certaines des motivations initiales de la recommandation / 48 [RFC3177], il existait trois préoccupations principales. La première motivation était de faire en sorte que les sites d'extrémité puissent facilement obtenir un espace d'adressage suffisant sans avoir à "sauter à travers des cerceaux" pour le faire. Par exemple, si quelqu'un estimait avoir besoin de plus d'espace, le simple fait de demander serait à un certain niveau une justification suffisante.

    À titre de comparaison, dans IPv4, les utilisateurs à domicile typiques se voient attribuer une seule adresse IP publique (même si cela n’est pas toujours garanti), mais il est souvent difficile, voire impossible, d’obtenir plusieurs adresses - à moins de vouloir payer augmentation (significative) des frais pour ce qui est souvent considéré comme un "niveau supérieur" de service. (Il convient de noter que l’augmentation des tarifs des FAI pour obtenir un petit nombre d’adresses supplémentaires ne peut généralement pas être justifiée par le coût réel par adresse facturé par les RIR, mais que des adresses supplémentaires ne sont souvent disponibles que pour les utilisateurs finaux dans le cadre d’un type différent ou ". niveau de service supérieur ", pour lequel des frais supplémentaires sont prélevés. Le fait est que les coûts supplémentaires ne sont pas dus aux structures tarifaires du RIR, mais aux choix commerciaux que font les fournisseurs de services Internet.)

    Un objectif important d’IPv6 consiste à modifier de manière significative l’attribution par défaut et minimale du site final, passant d’une "adresse unique" à "plusieurs réseaux" et à garantir que les sites finaux puissent facilement obtenir un espace d’adresse.

    ...

    Un changement de politique (comme ci-dessus) aurait un impact significatif sur les prévisions de consommation et la longévité attendue pour IPv6. Par exemple, changer l'affectation par défaut de / 48 à / 56 (pour la grande majorité des sites finaux, tels que les sites de rattachement) entraînerait des économies pouvant aller jusqu'à 8 bits, ce qui réduirait la "consommation totale d'adresses projetée" de to) 8 bits ou deux ordres de grandeur. (Le montant exact des économies dépend du nombre relatif d'utilisateurs à domicile comparé au nombre de sites plus grands.)

    ...

    3. Autres considérations de la RFC 3177 - ... Compte tenu de la grande quantité d'adresses dans IPv6, il y a suffisamment d'espace pour accorder aux sites finaux suffisamment d'espace pour être cohérent avec les prévisions de croissance raisonnables sur des périodes pluriannuelles. Il reste donc hautement souhaitable de fournir aux sites finaux suffisamment d’espace (tant pour les affectations initiales que pour les suivantes) pour durer plusieurs années. Heureusement, cet objectif peut être atteint de différentes manières et ne nécessite pas que tous les sites finaux reçoivent la même affectation de taille par défaut. ".

  • RFC 7608 et BCP 198 - "Recommandation de longueur de préfixe IPv6 pour le transfert"

    Résumé - La longueur du préfixe IPv6, comme dans IPv4, est un paramètre transmis et utilisé dans les processus de routage et de transfert IPv6 conformément à l'architecture de routage interdomaine (CIDR). La longueur d'un préfixe IPv6 peut être un nombre quelconque compris entre zéro et 128, bien que les sous-réseaux utilisant une configuration automatique d'adresse sans état (SLAAC) pour l'attribution d'adresses utilisent classiquement un préfixe / 64. Les implémentations matérielles et logicielles du routage et du transfert ne doivent donc imposer aucune règle sur la longueur du préfixe, mais implémenter la correspondance la plus longue en premier sur les préfixes de longueur valide.

  • Les RFC 7934 et BCP 204 - "Recommandations pour la disponibilité des adresses d'hôte" recommandent aux réseaux de fournir aux hôtes finaux à usage général plusieurs adresses IPv6 globales lors de leur connexion, et décrit les avantages et les options associés.

    Introduction - "Contrairement à IPv4, les réseaux IPv6 ne sont pas obligés de ne fournir qu'une seule adresse par hôte. ... De plus, la fourniture d'adresses multiples présente de nombreux avantages, notamment la fonctionnalité et la simplicité des applications, la confidentialité et la flexibilité permettant de s'adapter aux applications futures. Un autre avantage important est la possibilité de fournir un accès Internet sans utiliser la traduction d’adresses réseau (NAT): fournir une seule adresse IPv6 par hôte annule ces avantages.

    2. Modèle de déploiement IPv6 commun - IPv6 est conçu pour prendre en charge plusieurs adresses, y compris plusieurs adresses globales, par interface (voir les sections 2.1 de [RFC4291] et 5.9.4 de [RFC6434] ). Aujourd'hui, de nombreux hôtes IPv6 à usage général sont configurés avec trois adresses ou plus par interface: une adresse de lien local, une adresse stable (par exemple, à l'aide d'identificateurs uniques étendus (EUI-64) à 64 bits ou d'identificateurs d'interface opaques [ RFC7217 ]). , une ou plusieurs adresses de confidentialité [ RFC4941 ], et éventuellement une ou plusieurs adresses temporaires ou non temporaires obtenues à l'aide du protocole de configuration d'hôte dynamique pour IPv6 (DHCPv6) [ RFC3315 ].

    Dans la plupart des réseaux IPv6 à usage général, les hôtes ont la possibilité de configurer des adresses IPv6 supplémentaires à partir du ou des préfixes de liaison sans demander explicitement au réseau. De tels réseaux incluent tous les réseaux 3GPP ( [RFC6459], Section 5.2 ), ainsi que les réseaux Ethernet et Wi-Fi utilisant la configuration automatique d'adresse sans état (SLAAC) [ RFC4862 ]. ".

  • La RFC 4862 - "Configuration automatique d'adresse sans état IPv6" explique:

    3. Objectifs de conception

     

    • La configuration automatique sans état est conçue avec les objectifs suivants: o La configuration manuelle de machines individuelles avant de les connecter au réseau ne devrait pas être nécessaire. ... La configuration automatique d'adresse suppose que chaque interface peut fournir un identifiant unique pour cette interface (c'est-à-dire un "identifiant d'interface"). ...

    • Les sites de petite taille constitués d'un ensemble de machines connectées à une liaison unique ne doivent pas nécessiter la présence d'un serveur ou d'un routeur DHCPv6 en tant que condition préalable à la communication. La communication plug-and-play est réalisée grâce à l'utilisation d'adresses de liens locaux. Les adresses locales aux liens ont un préfixe connu qui identifie le lien (unique) partagé auquel un ensemble de nœuds est associé. Un hôte forme une adresse link-local en ajoutant un identifiant d'interface au préfixe link-local.

    • Un grand site avec plusieurs réseaux et routeurs ne devrait pas nécessiter la présence d'un serveur DHCPv6 pour la configuration des adresses. Pour générer des adresses globales, les hôtes doivent déterminer les préfixes identifiant les sous-réseaux auxquels ils se rattachent. Les routeurs génèrent des annonces de routeur périodiques comprenant des options répertoriant l'ensemble des préfixes actifs d'un lien.

    • La configuration de l'adresse devrait faciliter la renumérotation progressive des machines d'un site. Par exemple, un site peut souhaiter renuméroter tous ses nœuds lorsqu'il passe à un nouveau fournisseur de services réseau. La renumérotation est obtenue par la location d’adresses à des interfaces et l’attribution de plusieurs adresses à la même interface. La durée de vie du bail fournit le mécanisme par lequel un site élimine les anciens préfixes. L'affectation de plusieurs adresses à une interface fournit une période de transition au cours de laquelle une nouvelle adresse et celle en cours de suppression fonctionnent simultanément.

Considérations de sécurité :

  • OPSEC - " Considérations sur la sécurité opérationnelle des réseaux IPv6 - draft-ietf-opsec-v6-12 ":

    1. Considérations de sécurité génériques

     

             2.1. Adressage de l'architecture

                    L'attribution d'adresses IPv6 et l'architecture globale sont des éléments importants de la sécurisation d'IPv6. Les conceptions initiales, même si elles sont destinées à être temporaires, ont tendance à durer beaucoup plus longtemps que prévu. Bien qu'initialement pensé qu'IPv6 facilite la renumérotation, il peut s'avérer extrêmement difficile en pratique de renuméroter sans un bon système de gestion des adresses IP (IPAM).

                    Une fois l’attribution d’adresses attribuée, il convient de réfléchir à un plan global d’attribution d’adresses. Avec l'abondance d'espace d'adressage disponible, une allocation d'adresses peut être structurée autour de services avec des emplacements géographiques, ce qui peut ensuite servir de base à des politiques de sécurité plus structurées pour autoriser ou refuser des services entre régions géographiques.

                    Une question récurrente est de savoir si les entreprises doivent utiliser l’application PI vs PA space RFC7381 ], mais du point de vue de la sécurité, il y a peu de différence. Cependant, il convient de garder à l'esprit le fait de savoir qui est le propriétaire administratif de l'espace d'adressage et qui est techniquement responsable s'il est nécessaire d'appliquer des restrictions à la routabilité de l'espace en raison d'activités criminelles malveillantes. L'utilisation de l'espace PA expose l'organisation à une renumérotation du réseau complet, y compris des politiques de sécurité (basées sur les ACL), du système d'audit, etc. En bref, une tâche complexe pouvant entraîner un risque de sécurité si elle est effectuée pour un réseau étendu et sans automatisation; par conséquent, pour les grands réseaux, l'espace PI devrait être préféré.

Autres références :

ARIN - " Projet de politique recommandé ARIN-2015-1: Modification des critères pour les assignations d'utilisateur final IPv6 ".

ARIN - " Projet de politique ARIN-2011-3: Meilleures allocations IPv6 pour les FAI ".

Toutes les politiques ARIN .

IANA - Page principale - Registres de protocoles - Domaines réservés gérés par IANA .

IETF - " Considérations sur la métrique de densité d'hôte IPv6 - draft-huston-hd-metric-00.txt ".

Tous les BCP IETF . ( Archives ).

Meilleures pratiques actuelles de Wikipédia (actuellement non actualisées).

AP NIC - " Meilleures pratiques IPv6 actuelles ".

Livre blanc de Cloudmark: " BCP pour les déploiements SMTP à court terme dans les réseaux IPv6 ".

NSRC.org - " Laboratoire de filtrage des entrées et des sorties - Atelier de conception et d'exploitation du réseau de campus ".

RIPE - " La stratégie d'attribution et d'attribution d'adresses IPv6 " indique entre autres: "La taille d'allocation minimale pour l'espace d'adressage IPv6 est / 32. (Pour les LIR)", "Pour pouvoir bénéficier d'une attribution initiale d'espace d'adressage IPv6, une La RIL doit avoir un plan pour effectuer des sous-allocations à d'autres organisations et / ou affectations de sites finaux d'ici deux ans. "," Les LIR qui répondent aux critères d'attribution initiaux sont éligibles pour recevoir une allocation initiale de / 32 jusqu'à / 29 sans avoir à fournir des informations supplémentaires. ", ...

RIPE - " Comprendre les graphiques d'adressage IP et CIDR " (voir également ci-dessous) offre ces graphiques utiles:

IPv4 et IPv6


L'architecture initiale d'Internet consistait principalement en de grands réseaux se connectant directement les uns aux autres et ne ressemblait pas beaucoup à la conception hiérarchique utilisée aujourd'hui. Il était facile de donner une énorme adresse à l’armée et une autre à l’Université de Stanford. Dans ce modèle, les routeurs ne devaient mémoriser qu'une seule adresse IP pour chaque réseau et pouvaient atteindre des millions d'hôtes par chacune de ces routes.

  • Les périphériques IPv6 ont tous une adresse unique par défaut, tandis que les périphériques IPv4 utilisent un réseau de classe et ne possèdent pas d'adresse unique en raison d'un épuisement des adresses entre le 31 janvier 2011 et le 24 septembre 2015.

Voici une ancienne carte de l’ensemble de l’Internet de février 1982 comparée à Internet d’aujourd’hui, StackExchange.com étant le tout petit point au centre de l’image de droite, cliquez pour agrandir.

Internet 1984 contre aujourd'hui

La RFC 3484 - "La sélection d'adresse par défaut pour le protocole Internet version 6 (IPv6)" était obsolète par la RFC 6724 (sept. 2012). La nouvelle mise à jour est la suivante:

"Les sections 2.1.4 , 2.2.2 et 2.2.3 de la RFC 5220 décrivent les problèmes de sélection d'adresses liés aux adresses locales uniques (ULA) [RFC4193]. Par défaut, les destinations IPv6 globales sont préférées aux destinations ULA, car une ULA arbitraire est pas nécessairement accessible. ".

  • Une recommandation unique de / 48 n'est pas assez nuancée pour la vaste gamme de sites d'extrémité et n'est plus recommandée comme paramètre par défaut.

Voir: RIPE - " Comprendre l'adressage IP et les graphiques CIDR ":

"Chaque appareil connecté à Internet doit avoir un identifiant. Les adresses IP (Internet Protocol) sont les adresses numériques permettant d’identifier un matériel particulier connecté à Internet.

Les deux versions les plus courantes de l'IP actuellement utilisées sont Internet Protocol version 4 (IPv4) et Internet Protocol version 6 (IPv6). Les adresses IPv4 et IPv6 proviennent de pools de nombres finis.

  • Pour IPv4, ce pool a une taille de 32 bits (2 ^ 32) et contient 4 294 967 296 adresses IPv4.

  • L'espace d'adressage IPv6 a une taille de 128 bits (2 ^ 128), contenant 340 282 326 920 938 463 473 473 374 367 431, 768,211,456 adresses IPv6.

Modèle d'allocation d'adresses

Actuellement, l'IANA attribue des blocs d'adresses aux registres régionaux. Les registres attribuent à leur tour des blocs d’adresses aux fournisseurs de services. Il incombe au fournisseur de services de distribuer les adresses à leurs clients respectifs.

La stratégie actuelle varie selon les régions et dans le cas le plus prudent, un utilisateur final doit passer par son fournisseur de services pour obtenir un espace d'adressage IPv6 plutôt que d'approcher directement le registre régional pour cet espace d'adressage.

Politique dépendante du fournisseur

La figure représente graphiquement comment cette politique initiale est adoptée. Ce modèle d'affectation est communément appelé affectation de fournisseur (PA) ou dépendante du fournisseur (PD). Les longueurs de préfixe indiquées dans la figure sont des recommandations. Les registres et les fournisseurs de services peuvent attribuer des blocs en utilisant les processus et les procédures qu’ils ont établis pour leurs régions et leurs clients. Ceci est expliqué dans la RFC 6177.

RFC 6177 - "Attribution d'adresses IPv6 aux sites finaux".

À titre d'exemple de la politique, l'IANA a attribué l'ARIN 2600: 0000 :: / 12 à l'attribution. Cela s'aligne sur la couche supérieure du modèle. Par la suite, ARIN a attribué le bloc 2600 :: / 29 à Sprint, 2600: 300 :: / 24 à AT & T Mobility, 2600: 7000 :: / 24 à Hurricane Electric, etc.

Ces affectations de blocs ne suivent pas le modèle d'origine défini dans la RFC 3177. Les fournisseurs de services attribuent ensuite des blocs à leurs clients en fonction de leurs besoins. Le fournisseur de services Internet (FAI) a la possibilité d’attribuer une large gamme d’adresses à ses clients.

Par exemple, un client de grande entreprise FAI peut avoir besoin d'une affectation / 40, tandis qu'un client résidentiel n'a besoin que d'une affectation / 60.

Il existe une exception à cette politique adoptée par les registres régionaux qui permet aux clients finaux d'approcher directement les registres et de demander un espace d'adressage IPv6. Cette exception est appelée adressage indépendant du fournisseur (PI).

La RFC 5375 - "Considérations d'attribution d'adresses IPv6 en monodiffusion" décrit certains problèmes à prendre en compte lors de la création d'un plan d'adressage.

Vous devez d’abord décider si vous souhaitez des blocs d’adresses indépendants du fournisseur ou si l’adressage attribué par le fournisseur est-il acceptable?

Si le client a des adresses PI, l'affectation restera valide à condition que les critères de l'affectation d'origine soient remplis.

Il est recommandé aux clients possédant une adresse PA d'obtenir une nouvelle affectation d'espace adresse à partir d'une autre LIR et de renvoyer l'espace adresse PA attribué par leur LIR d'origine. Dans ce

Il y a plus, consulter les liens IANA et IETF ci-dessus est le meilleur moyen de rester au top des meilleures pratiques.


0

Le meilleur moyen de diviser ipv6 consiste à utiliser / 64 sous-réseaux. car l'adresse / 64 peut être facilement mappée manuellement vers IPV4


1
Comment le diviser en / 64 le rend-il plus facile que de le diviser en / 48 par exemple. Pouvez-vous préciser comment vous feriez cette cartographie?
Teun Vink

1
Et pourquoi devrions-nous nous préoccuper de «facilement mappé sur IPV4»?
Michael Hampton

0

Les principales différences entre v4 et v6

  1. il ne devrait pas y avoir de microgestion. L'espace d'adressage est relativement abondant.
  2. L'attente est que tous les sous-réseaux seront / 64s
  3. Le NAT est fortement déconseillé. Pour les grandes entreprises, ce n'est pas un problème, ils obtiennent simplement un espace PI ou s'enregistrent même en tant que LIR et annoncent leur espace via BGP. Cependant, pour les petites entreprises, le choix est difficile: demandent-elles de l'espace PI et achètent-elles des connexions Internet plus coûteuses qui leur permettront de l'utiliser? Exécutent-ils en parallèle des adresses privées et des adresses publiques attribuées par un fournisseur de services Internet et espèrent qu'aucune adresse attribuée par un fournisseur de services Internet ne se retrouvent dans des fichiers de configuration à long terme? ignorent-ils l'IETF et utilisent-ils le NAT de toute façon?
  4. La notation hexadécimale rend les limites de nibble convaincantes pour les niveaux d'adressage.

Au-delà, cela ne devrait pas être très différent de la v4, déterminez les sous-réseaux dont vous avez besoin, déterminez les groupes logiques dans lesquels ils se situent, la marge de développement que vous souhaitez pour chaque niveau et commencez à élaborer un plan.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.