Groupe de travail Réseau	A. Retana, Cisco Systems	
Request for Comments : 3021	R. White, Cisco Systems	
Catégorie : En cours de normalisation	V. Fuller, GTE Internetworking	
	D. McPherson, Amber Networks	
Traduction Claude Brière de L'Isle	décembre 2000	

Utilisation de préfixes de 31 bits sur des liaisons IPv4 point à point

Statut de ce mémoire
Ce document spécifie un protocole de suivi des normes Internet pour la communauté Internet, et nécessite des discussions et suggestions pour son amélioration. Veuillez vous référer à l'édition courante du "Internet Official Protocol Standards" (STD 1) pour l'état de normalisation et le statut de ce protocole. La distribution de cette note est illimitée.

Copyright
Copyright (C) The Internet Society (2000). Tous droits réservés.

Résumé
Avec la pression sans cesse croissante pour préserver l’espace d’adresses IP sur l’Internet, il y a intérêt à examiner où des changements relativement mineurs peuvent être faits aux pratiques de chacun pour améliorer l’efficacité de la numérotation. Un de ces changements, proposé par le présent document, est de diminuer de moitié la quantité d’espace d’adresses alloué aux liaisons point à point (courantes à travers l’infrastructure de l’Internet) en permettant l’utilisation de gabarits de sous-réseaux de 31 bits d’une façon très limitée.

1.	Introduction et motifs

La perception du problème du manque d’adresses Internet a conduit à un certain nombre de changements dans l’usage de l’espace d’adresses et un certain nombre d’approches différentes pour résoudre le problème :
-	Des lignes directrices plus strictes pour l’allocation de l’espace d’adresses, mises en application par l’IANA et les autorités régionales d’allocation d’adresses [RFC2050].
-	Utilisation de traducteurs d’adresse réseau (NAT, Network Address Translator) où un petit nombre d’adresses conformes à l’IANA sont partagées par un plus grand réservoir d’adresses privées, sans acheminement mondial, placées topologiquement derrière une boîte de NAT [RFC1631].
-	Déploiement d’un nouveau protocole Internet pour augmenter la taille de l’espace d’adresses. Ce protocole, IPv6 [RFC2460], est passé par le processus de l’IETF mais doit encore faire face au déploiement en production. Si il devait être déployé, il y aurait encore à faire face à de nombreuses années de période de transition.

Avant que soit disponible un plus large espace d’adresses, il semble prudent de considérer les opportunités de faire une utilisation plus efficace de l’espace d’adresses existant.

Une de ces opportunités (petite) est de changer la façon dont sont numérotées les liaisons point à point. Une option, qui est aujourd’hui utilisée dans certaines parties de l’Internet, est de simplement ne pas numéroter les liaisons point à point entre les routeurs. Bien que cette pratique puisse sembler, à première vue, résoudre habilement le problème, elle en pose un certain nombre par elle-même, parmi lesquels l’incapacité à gérer de façon cohérente la liaison non numérotée ou à atteindre un routeur à travers elle, la difficulté de gérer et déboguer ces liaisons, et l’absence de normalisation [RFC1812].

Dans la pratique courante, les sous-réseaux Internet numérotés n’utilisent pas de gabarit de sous-réseau de plus de 30 bits (dans la plupart des cas) qui exigent quatre adresses par liaison – deux adresses d’hôte, une de réseau toute à zéro, et une de diffusion toute à un. C’est malheureux pour les liaisons point à point, car elles ne peuvent avoir que deux points d’extrémité pour les identifier et elles ne prennent pas en charge la notion de diffusion – tout paquet qui est transmis par une extrémité d’une liaison est toujours reçu par l’autre.

Une troisième option est d’utiliser des adresses d’hôte sur les deux extrémités d’une liaison point à point. Cette option fournit les mêmes économies d’espace d’adresses que d’utiliser un gabarit de sous-réseau de 31 bits, mais ne peut être utilisé que dans les liaisons qui utilisent l’encapsulation PPP [RFC1332]. L’utilisation des adresses d’hôte permet l’allocation d’adresses IP qui appartiennent à des réseaux différents de chaque côté de la liaison, ce qui fait que la gestion de liaison et de réseau ne sont plus aussi simples.

Le présent document se fonde sur l’idée qu’il est possible de conserver des adresses IP sur les liaisons point à point (en utilisant un gabarit de sous-réseau de plus de 30 bits) tout en conservant la facilité de gestion et une interaction standard. La documentation existante [RFC0950] a déjà donné des conseils sur l’utilisation possible d’un champ de numéro d’hôte sur un seul bit.

L’économie en espace d’adresses résultant de ce changement est facile à voir – chaque liaison point à point dans un grand réseau va consommer deux adresses au lieu de quatre. Dans un réseau de 500 liaisons point à point, par exemple, cette pratique reviendrait à économiser 1000 adresses (l’équivalent de quatre espaces d’adresse de classe C).

2.	Considérations sur les préfixes de 31 bits

Cette section discute des effets possibles, sur l’acheminement et le fonctionnement de l’Internet, de l’utilisation de préfixes de 31 bits sur les liaisons point à point. Les considérations mentionnées ici sont aussi reflétées dans la Section 3.

Tout au long de ce document, uneadresse IP sera interprétée comme :

<Numéro de réseau><Numéro d’hôte>

où le <Numéro d’hôte> représente la portion hors gabarit de l’adresse et elle DEVRAIT avoir au moins 1 bit. 
La notation "-1" est utilisée pour signifier que le champ est tout de bits 1. Pour les besoins de cet exposé, le système d’acheminement est considéré capable d’acheminement sans classe (CIDR, Classless Interdomain Routing) [RFC1519].

2.1	Adressage

Si un gabarit de sous-réseau de 31 bits est alloué à une liaison point à point, cela laisse le <Numéro d’hôte> avec seulement 1 bit. Par conséquent, seules deux adresses peuvent en résulter :

{<Numéro de réseau>, 0} et {<Numéro de réseau>, -1}

Ces adresses ont historiquement été associées à des adresses de réseau et de diffusion (voir le paragraphe 2.2). Dans une liaison point à point avec un gabarit de sous-réseau de 31 bits, les deux adresses ci-dessus DOIVENT être interprétées comme des adresses d’hôte.

2.2	Adresses de diffusion et de réseau

Il y a plusieurs adresse de diffusion reconnues historiquement [RFC1812] sur les segments IP :

(a)	la diffusion dirigée

{<Numéro de réseau>, -1}

{<Numéro de réseau>, 0}

L’adresse réseau elle-même {<Numéro de réseau>, 0} est une forme obsolète de diffusion dirigée, mais elle peut encore être utilisée par des hôtes anciens.

(b)	la diffusion de liaison locale (ou limitée)

{-1, -1}

{0, 0}

La forme {0, 0} d’une diffusion limitée est obsolète, mais peut encore être présente dans un réseau.

Utiliser une longueur de préfixe de 31 bits ne laisse que deux possibilités de numérotation (voir le paragraphe 2.1) éliminant l’utilisation d’une diffusion dirigée vers la liaison (voir le paragraphe 2.2.1). La diffusion limitée DOIT être utilisée pour tout le trafic en diffusion sur une liaison point à point en lui allouant un gabarit de sous-réseau de 31 bits.

Le <Numéro de réseau> est alloué par l’administrateur de réseau comme unique au domaine d’acheminement local. La décision qu’une adresse de destination IP devrait être ou non une diffusion dirigée est prise par le routeur directement connecté au segment de destination. Les schémas et algorithmes d’acheminement courants ne sont pas affectés dans les routeurs distants.

L’intention du présent document est de discuter l’applicabilité et le fonctionnement des préfixes de 31 bits sur les liaisons point à point. Les effets (si il y en a) sur d’autres types d’interfaces ne sont pas considérés.

2.2.1	Diffusion dirigée
Lorsque un appareil veut atteindre tous les hôtes sur un certain sous-réseau (distant, plutôt que directement connecté) il peut régler l’adresse de destination du paquet à l’adresse de diffusion de sous-réseau de la liaison. Cette opération n’est pas possible pour les liaisons point à point avec un préfixe de 31 bits.

Comme exposé à la Section 6, la perte de fonctionnalité d’une diffusion dirigée peut en fait être vue comme un effet collatéral bénéfique, car elle améliore légèrement la résistance du réseau à une certaine classe d’attaques de déni de service [RFC2644], [SMURF].

2.3	Impact sur les protocoles d’acheminement courants

Les réseaux qui ont des préfixes de 31 bits n’ont pas d’impact sur les protocoles d’acheminement actuels. La plupart des protocoles d’acheminement actuellement déployés ont été conçus pour fournir un acheminement sans classe. De plus, la communication entre les homologues est faite en utilisant des adresses de diffusion groupée, de diffusion limitée, ou d’envoi individuel (toutes sur le réseau local) dont aucune n’est affectée par l’utilisation de gabarits de sous-réseau de 31  bits.

3.	Recommandations

Les considérations présentées à la Section 2 affectent d’autres travaux publiés. La présent section détaille les mises à jour faites aux autres documents.

3.1	"Exigences pour les hôtes Internet – couches de communication" [RFC1122]

Le paragraphe 3.2.1.3 (e) est remplacé par :
(e)	{ <Numéro de réseau>, <Numéro de sous-réseau>, -1 }

Diffusion dirigée au sous-réseau spécifié. Il NE DOIT PAS être utilisé comme adresse de source, sauf lorsque l’origine est un des points d’extrémité d’une liaison point à point avec un gabarit de 31 bits.

Un nouveau paragraphe (3.2.1.3 (h)) est ajouté :

(h)	{ <Numéro de réseau>, <Numéro de sous-réseau>, 0 }

Numéro de sous-réseau. Il NE DEVRAIT PAS être utilisé comme adresse de source, sauf lorsque l’origine est un des points d’extrémité d’une liaison point à point avec un gabarit de 31 bits. Pour les autres types de liaisons, un paquet avec une telle destination DEVRAIT être éliminé en silence. Si ces paquets ne sont pas éliminés en silence, ils DOIVENT être traités comme de la diffusion IP [RFC1812].

3.2	"Numéros alloués" [RFC1700]

La sous-section (e) de la section "Adresses spéciales" dans "Introduction" est remplacée par :

(e)	{<Numéro de réseau>, <Numéro de sous-réseau>, -1}
Diffusion dirigée au sous-réseau spécifié. Ne peut être utilisé que comme adresse de destination. Cependant, dans le cas où l’origine est un des points d’extrémité d’une liaison point à point avec un gabarit de 31 bits, elle peut aussi être utilisée comme adresse de source.

3.3	"Exigences pour les routeurs IP version 4" [RFC1812]

Le paragraphe 4.2.2.11 (d) est remplacé par :

(d) { <Préfixe de réseau>, -1 }
Diffusion dirigée – une diffusion dirigée vers le préfixe de réseau spécifié. Il NE DOIT PAS être utilisé comme adresse de source, sauf lorsque l’origine est un des points d’extrémité d’une liaison point à point avec un gabarit de 31 bits. Un routeur PEUT générer des paquets en diffusion dirigée réseau. Un routeur PEUT avoir une option de configuration pour lui permettre de recevoir des paquets en diffusion dirigée, cependant, cette option DOIT être désactivable par défaut, et donc, le routeur NE DOIT PAS recevoir des paquets en diffusion dirigée réseau sauf si il est spécifiquement configuré par l’utilisateur final.

Le texte ci-dessus inclut la mise à jour faite par la [RFC2644].

Un nouveau paragraphe (4.2.2.11 (f)) est ajouté :

(f)	{ <Numéro de réseau>, <Numéro de sous-réseau>, 0 }
Numéro de sous-réseau. NE DEVRAIT PAS être utilisé comme adresse de source, sauf lorsque l’origine est un des points d’extrémité d’une liaison point à point avec un gabarit de 31 bits. Pour les autres types de liaisons, un paquet avec une telle destination DEVRAIT être éliminé en silence. Si ces paquets ne sont pas éliminés en silence, ils DOIVENT être traités comme des diffusions IP.

Les paragraphes 4.2.3.1 (1), (2) et (4) sont remplacés par :

(1)	DOIVENT être traités comme des paquets en diffusion IP adressés à 255.255.255.255 ou { <Préfixe réseau>, -1 }.
Dans une liaison point à point avec un gabarit de 31 bits, un paquet adressé au { <Préfixe-réseau>, -1 } correspond à un des points d’extrémité d’une telle liaison, il DOIT être traité comme dirigé sur le routeur sur lequel l’adresse est appliquée.

(2)	DEVRAIT être éliminé en silence à réception (c’est-à-dire, même pas livré aux applications dans le routeur) tout paquet adressé à 0.0.0.0 ou { <Préfixe-réseau>, 0 }. Si ces paquets ne sont pas éliminés en silence, ils DOIVENT être traités comme des diffusions IP (voir le paragraphe 5.3.5). Il PEUT y avoir une option de configuration pour permettre la réception de ces paquets. Cette option DEVRAIT être l’élimination par défaut.
Dans une liaison point à point avec un gabarit de 31 bits, un paquet adressé à { <Préfixe-réseau>, 0 } correspond à un des points d’extrémité d’une telle liaison, il DOIT être traité comme dirigé sur le routeur sur lequel l’adresse est appliquée.

(4)	NE DEVRAIT PAS générer de datagramme adressé à 0.0.0.0 ou { <Préfixe-réseau>, 0 }. Il PEUT y avoir une option de configuration pour permettre de générer de tels paquets (au lieu d’utiliser le format pertinent de diffusion 1s). Cette option DEVRAIT être par défaut de ne pas les générer.
Dans une liaison point à point avec un gabarit de 31 bits, la configuration d’un tel gabarit DEVRAIT permettre la génération de datagrammes adressés à { <Préfixe-réseau>, 0 }.

Le texte suivant est ajouté au paragraphe 4.3.3.9 :
L’adresse de diffusion IP 255.255.255.255 DOIT être utilisée pour les réponses de gabarit d’adresse de diffusion dans les liaisons point à point avec des gabarits de sous-réseau de 31 bits.

4.	Expérience du fonctionnement

Les recommandations présentées dans le présent document ont été mises en œuvre par plusieurs fabricants de routeurs en code beta. La mise en œuvre a été testée par au moins trois FAI avec des résultats positifs (c’est-à-dire qu’aucun problème n’a été découvert). Parmi les protocoles d’acheminement essayés avec succès figurent OSPF, IS-IS, BGP et EIGRP.

On s’attend à ce que la mise en œuvre soit officialisée dans les prochains mois et que d’autres fabricants l’adoptent.

5.	Considérations de déploiement

L’intention du présent document est de discuter de l’applicabilité et du fonctionnement des préfixes de 31 bits sur les liaisons point à point. Les effets (si il en est) sur les autres types d’interfaces ne sont pas considérés. Noter qu’une liaison point à point dans laquelle une seule extrémité prend en charge l’utilisation de préfixes de 31 bits peut ne pas fonctionner correctement.

6.	Considérations sur la sécurité

À la lumière de diverses attaques de déni de service (DoS) sur divers réseaux au sein de l’Internet, la sécurité est devenue un souci majeur. L’utilisation de gabarits de sous-réseau de 31 bits au sein du cœur de l’Internet va réduire le nombre de liaisons physiques contre lesquelles peut être lancée une attaque de DoS s’appuyant sur la duplication de paquet par l’utilisation de diffusions dirigées [RFC2644], [SMURF].

D’un façon générale, la mise en œuvre de la recommandation du présent document va améliorer la résilience de l’Internet à ces types d’attaques de déni de service.

7.	Remerciements

Les auteurs du présent document ne prétendent aucunement à l’originalité des idées décrites. Entre autres personnes, nous tenons à remercier Alex Zinin de ses commentaires, et les nombreuses personnes qui ont essayé les gabarits de sous-réseau de 31 bits dans leurs laboratoires et réseaux.

8.	Références

[RFC0950]	J. Mogul et J. Postel, "Procédure standard de sous-réseautage Internet", (STD 5) août 1985.

[RFC1122]	R. Braden, "Exigences pour les hôtes Internet – couches de communication", STD 3, octobre   1989. (MàJ par la RFC6633) 

[RFC1332]	G. McGregor, "Protocole de contrôle de protocole Internet point à point (IPCP)", mai 1992. (MàJ 3241)

[RFC1519]	V. Fuller, T. Li, J. Yu et K. Varadhan, "Acheminement inter domaine sans classe (CIDR) : stratégie d'allocation et d'agrégation d'adresses", septembre 1993. (D.S., rendue obsolète par la RFC4632)

[RFC1631]	K. Egevang, P. Francis, "Traduction d'adresse réseau IP traditionnelle (NAT)", juin 1994. (Info)

[RFC1700]	J. Reynolds et J. Postel, "Numéros alloués", STD 2, octobre 1994. (Historique, voir www.iana.org))

[RFC1812]	F. Baker, "Exigences pour les routeurs IP version 4", juin 1995. ( (MàJ par les RFC2644, RFC6633)

[RFC2050]	K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel, "Lignes directrices pour l'allocation des adresses IP par les registraires Internet", novembre   1996. (Remplace RFC1466) (BCP0012) (Remplacée par RFC7020) 

[RFC2460]	S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6) ", décembre   1998. (MàJ par 5095, 6564   ; D.S)

[RFC2644]	D. Senie, "Changer la valeur par défaut en diffusion dirigée dans les routeurs", août 1999. (BCP0034)  

[SMURF]	Huegen, C., "The Latest in Denial of Service Attacks: 'Smurfing': Description and Information to Minimize Effects", URL : http://users.quadrunner.com/chuegen/smurf.cgi 

9.	Adresse des auteurs

Alvaro Retana	Russ White	Vince Fuller	Danny McPherson	
Cisco Systems, Inc.	Cisco Systems, Inc.	GTE Internetworking	Amber Networks	
7025 Kit Creek Rd.	7025 Kit Creek Rd.	3801 E. Bayshore Rd.	2465 Augustine Drive	
Research Triangle Park,	Research Triangle Park,	Palo Alto, CA, 94303	Santa Clara, CA  95054	
NC 27709	NC 27709	USA	USA	
mél : aretana@cisco.com 	mél : riw@cisco.com 	mél : vaf@valinor.barrnet.net 	mél : danny@ambernetworks.com 	

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2000). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.