IPv6: Pourquoi ne pas utiliser / 126 sur les liaisons P2P pour IPv6?


16

Dans IPv4, nous utilisons / 30 pour conserver les adresses. Alors pourquoi certaines personnes recommandent d'utiliser / 64 sur les liens P2P au lieu de / 126? J'utilise un / 64 sur des sous-réseaux réguliers mais n'utilise pas un / 64 alors qu'il n'y aura jamais que deux adresses en cours d'utilisation sur les liens P2P un énorme gaspillage d'adresses?


4
Bonjour, veuillez considérer les perspectives exprimées dans la RFC 6164
Mike Pennington

Réponses:


14

Beaucoup d'entre nous utilisent des / 126 sur les liens PTP. Personnellement, j'aime pouvoir identifier quelque chose comme un lien PTP d'infrastructure réseau basé uniquement sur les 64 premiers bits de l'adresse, donc je réserve un / 64 pour extraire les / 126. Différentes personnes ont des opinions différentes sur ce qui est important, alors ... hausser les épaules

Soit dit en passant (# 1), car IPv6 n'a pas le concept d'une adresse de diffusion ou d'une adresse réseau sur un réseau IP, vous pouvez réellement utiliser / 127 au lieu de / 126. Attention, bien que les masques de réseau de / 127 soient parfaitement valides, certains équipements de fournisseur ne les ont pas (à tort) autorisés, considérant les masques de réseau de / 127 comme "invalides", ce qui signifie que vous pouvez rencontrer des problèmes de support de fournisseur si vous décidez d'essayer de les utiliser. C'est pourquoi j'utilise des / 126.

Soit dit en passant (# 2), si vos liens sont vraiment définis comme des liens PTP, vous devriez pouvoir utiliser n'importe quelle adresse IP sans avoir à se trouver dans un réseau IP commun.


1
Pouvez-vous donner un exemple de fournisseur qui restreint l'utilisation des / 127?
Ryan Foley

4
À un moment donné, Brocade dans la ligne FastIron et peut-être dans la ligne NetIron ne l'a pas permis. Je n'ai pas vérifié les versions récentes du firmware, donc je ne sais pas si c'est toujours le cas ou non.
Jeff McAdams

1
Brocade n'est pas non plus une petite entreprise. Bon aperçu.
Ryan Foley

5

La réponse comporte deux parties.

Tout d'abord, pour répondre directement à votre question: la recommandation officielle sur ce sujet a changé. Dans le passé, la RFC 3627 est intitulée "Utilisation de la longueur de préfixe / 127 entre les routeurs considérés comme nuisibles". La recommandation actuelle est cependant différente: la RFC 6164 recommande d'utiliser un / 127 (et non un / 126!) Sur les liaisons point à point. Les deux RFC décrivent les raisons des recommandations respectives.

La deuxième partie de la réponse est que généralement, en dehors des liaisons point à point, IPv6 va rompre avec préfixe plus de / 64. Il ne s'agit en fait pas d'IPv6 lui-même, mais de nombreux protocoles qu'il utilise, tels que SLAAC, la découverte de voisins, etc. Puisqu'un lien point à point n'implique aucune forme de découverte, cette considération n'est pas pertinente et a / 127 marchera.


5
La RFC 6547 clarifie le fait que la RFC 3627 a été déplacée vers le statut historique et que la RFC 6164 le rend obsolète.
Ron Maupin

3

Parce que IPv6 recommande toujours d'utiliser / 64 pour tous les liens.

Pour la deuxième partie de la question, est-ce un gaspillage?

A / 64 a 18 446 744 073 709 551 615 , soit 18 quintillions d'adresses.

La plupart des sous-réseaux IPv4 comptent moins de 255 hôtes. Supposons que vous disposez d'un réseau avec 255 hôtes et qu'ils reçoivent un préfixe / 64. Cela signifie que 255 hôtes se voient attribuer une adresse v6, laissant 18 446 744 073 709 551 360 adresses inutilisées. C'est plus de 99,99%. Pour être plus précis, c'est seize 9, ou effectivement 100% de «déchets».

Même si vous disposiez d'un sous-réseau avec 1 000 000 d'hôtes, cela représente 18 446 744 073 708 551 616 adresses perdues, soit encore plus de 99,99%. Seulement treize 9 cette fois, mais toujours 100% de «déchets».

Ainsi, la différence en pourcentage entre l'utilisation d'un million d'adresses ou de deux adresses sur une seule liaison est négligeable.

Et juste pour que vous puissiez voir à quoi ressemblent ces chiffres.

* Two hosts is 99.9999999999999999891579782751449556599254719913005828857422% unused.
* 255 hosts is 99.9999999999999986176422300809818466404976788908243179321289% unused.
* 1M  hosts is 99.99999999999457898913757247782996273599565029144287109375% unused.
* 4B  hosts is 99.999999976716935634613037109375% unused.

Même l'intégralité de l'Internet IPv4 placé sur une seule liaison / 64 laisserait effectivement 100% des adresses inutilisées. Lorsque vous regardez des chiffres comme celui-ci, utiliser autre chose qu'un / 64 sur un lien est tout simplement stupide.


2
De nombreux FAI utilisent / 126 pour les liaisons point à point. Je suppose que les vieilles habitudes ont la vie dure ;-)
Ron Trunk

Ils le font, mais avec un peu de chance, réaliser qu'Internet IPv4 entier est toujours effectivement 0% de a / 64 peut apporter une perspective appropriée.
bahamat

1
Une raison possible (je ne suis pas un FAI) peut être qu'ils peuvent prendre un seul sous-réseau / 64 et y mettre tous leurs liens. Cela peut faciliter la gestion et le dépannage.
Ron Trunk

@bahamat Je ne pense pas que vous ayez pleinement répondu à votre question initiale. "Parce que IPv6 recommande toujours d'utiliser / 64 pour tous les liens" ne répond pas "Alors pourquoi certaines personnes recommandent-elles d'utiliser / 64 sur les liens P2P au lieu de / 126?" .
Ryan Foley

3
En plus de ma réponse complète, je voulais commenter celle-ci. L'affirmation selon laquelle IPv6 recommande toujours d'utiliser / 64 pour tous les liens n'est plus valide. tools.ietf.org/html/rfc6164
Jeff McAdams

2

Donc, en tant que FAI, je voulais ajouter un commentaire à cela. Plus précisément, nous utilisons à la fois des GUA et des ULA (adresses locales uniques) pour notre routage interne. Cela signifie que nous avons un bloc (/ 48) qui provient d'un pool GUA / 32, mais que nous filtrons à nos bords en les transformant en ULA. Le plus grand / 32 GUA est toujours annoncé, mais le / 48 ULA est filtré à nos bords. Nous utilisons cet ULA pour la plupart de nos besoins d'adressage interne (spécifiques à l'AS) ainsi que pour les liaisons PtP.

Tous nos liens PtP sont un bloc complet / 64, mais ils sont spécifiquement configurés en tant que / 127 sur les routeurs. Il s'agissait de traiter spécifiquement les attaques de ping-pong lorsque cela est possible dans l'espace IPv4 et IPv6. Vous le voyez rarement dans l'espace IPv4 car nous utilisons tous / 30s pour les liens PtP là-bas. Cependant, dans l'espace IPv6, l'utilisation de / 64 crée la possibilité de ces types d'attaques (voir https://tools.ietf.org/html/rfc6164#section-5.1 )

Comme mentionné précédemment, allouer un / 64 pour ces liens semble être un gaspillage, mais une fois que vous passez beaucoup de temps à faire votre plan d'adresse IPv6 (une bonne lecture est https://www.amazon.com/IPv6-Address-Planning- Designing-Future-ebook-dp-B00PCZMAOW / dp / B00PCZMAOW ) vous voyez qu'il est BEAUCOUP plus facile de ne jamais plonger au-delà de / 64 dans vos plans.

Comme mentionné précédemment, comme nous parlons uniquement de liaisons PtP, le / 127 ne souffre d'aucun des problèmes normaux liés au dépassement du / 64. Pourquoi n'utilisons-nous pas des adresses non numérotées pour les liens PtP? Surtout à des fins de débogage, de suivi, de surveillance, etc.

--- J'ai oublié de mentionner (après avoir relu certains des commentaires ci-dessus ...) Si vous utilisez un / 126 comme lien PtP, vous souffrez toujours du même problème de ping-pong que le / 64. Pourquoi? Parce que les 00 et 11 bits de votre / 126 sont des adresses IPv6 valides (alors que dans IPv4 ils ne le sont pas, ils ont un objectif différent). Ainsi, bien qu'un a / 32 (deux bits de / 32) fonctionne pour IPv4, un / 127 (1 bit de / 128) est ce dont vous avez besoin pour IPv6.


Malheureusement, les grands opérateurs (ATT, VzB, etc.) insistent sur le fait que les /127liens ne sont pas autorisés, et ils insistent pour que nous utilisions des /126liens avec eux. Nous devons tester soigneusement tout équipement que nous utilisons pour cela afin de nous assurer qu'il est immunisé contre les attaques de ping-pong.
Ron Maupin
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.