2. Couche de liaison (LINK LAYER)

2.1 Introduction (INTRODUCTION)

Tous les systèmes Internet, qu'ils soient des hôtes ou des passerelles, ont les mêmes exigences pour les protocoles de la couche de liaison. Ces exigences sont données dans le chapitre 3 de « Exigences pour les passerelles Internet » [INTRO:2], et elles sont complétées par cette section.

2.2 Analyse du protocole (PROTOCOL WALK-THROUGH)

Aucune (None).

2.3 Problèmes spécifiques (SPECIFIC ISSUES)

2.3.1 Négociation du protocole Trailer (Trailer Protocol Negotiation)

Le protocole Trailer de l'encapsulation de la couche de liaison [LINK:1] PEUT (MAY) être utilisé, mais uniquement si les deux systèmes (hôtes ou passerelles) participant à la communication de la couche de liaison ont été vérifiés comme implémentant le trailer. Si le système ne négocie pas dynamiquement l'utilisation du protocole Trailer sur une base par adresse de destination, la configuration par défaut DOIT (MUST) désactiver le protocole.

DISCUSSION :

Le protocole Trailer est une technique d'encapsulation de la couche de liaison qui réarrange le contenu de données des paquets envoyés sur le réseau physique. Dans certains cas, le trailer améliore le débit des protocoles de couche supérieure en réduisant la quantité de copie de données à l'intérieur du système d'exploitation. Les protocoles de couche supérieure ne connaissent pas l'utilisation du trailer, mais si le protocole est utilisé, les hôtes émetteur et récepteur DOIVENT (MUST) tous deux comprendre le protocole.

Une utilisation inappropriée des trailers provoque des symptômes très confus. Seuls les paquets ayant certaines propriétés de taille utilisent l'encapsulation trailer, et généralement seule une petite fraction des paquets échangés ont ces propriétés. Par conséquent, si un système utilisant des trailers échange des paquets avec un système qui n'en utilise pas, certains paquets disparaissent dans un trou noir, tandis que d'autres sont livrés avec succès.

IMPLEMENTATION :

Sur Ethernet, les paquets encapsulés avec trailer utilisent un type Ethernet différent [LINK:1], et la négociation trailer est effectuée lors de la découverte de l'adresse de liaison de la destination système en utilisant ARP.

Plus précisément, l'échange ARP est effectué de la manière habituelle en utilisant le type de protocole IP normal, mais l'hôte souhaitant utiliser des trailers envoie une « réponse ARP trailer (trailer ARP reply) » supplémentaire, c'est-à-dire une réponse ARP spécifiant le type de protocole d'encapsulation trailer mais qui est autrement au format d'une réponse ARP normale. Si un hôte configuré pour utiliser des trailers reçoit un message de réponse ARP trailer d'une machine distante, il peut ajouter cette machine à la liste des machines comprenant les trailers, par exemple en marquant l'entrée correspondante dans le cache ARP.

L'hôte souhaitant recevoir des paquets encapsulés en trailer envoie une réponse ARP trailer chaque fois qu'il complète un échange de messages ARP IP normal. Par conséquent, un hôte recevant une requête ARP pour son adresse de protocole IP envoie une réponse ARP trailer en plus de la réponse ARP IP normale ; l'hôte ayant envoyé une requête ARP IP envoie une réponse ARP trailer lorsqu'il reçoit la réponse ARP IP correspondante. De cette façon, que l'hôte demandeur ou l'hôte répondeur de l'échange ARP IP puisse demander la réception d'encapsulation trailer.

Ce schéma utilise des messages de réponse ARP trailer supplémentaires au lieu d'envoyer une requête ARP pour le type de protocole trailer, afin d'éviter l'échange continu de paquets ARP avec un hôte se comportant de manière contraire à toute spécification ou au bon sens (behaving contrary to any specification or common sense), qui répondrait à une réponse ARP trailer par une autre réponse ARP IP. Ce problème est évité en n'envoyant une réponse ARP trailer que lors de la réception d'une réponse ARP IP en réponse à une requête en attente ; c'est le cas lorsque l'adresse matérielle de l'hôte est encore inconnue lors de la réception de la réponse ARP IP. La réponse ARP trailer peut toujours être envoyée avec la réponse ARP IP répondant à une requête ARP IP.

2.3.2 Address Resolution Protocol -- ARP (Address Resolution Protocol -- ARP)

2.3.2.1 Validation du cache ARP (ARP Cache Validation)

L'implémentation du protocole de résolution d'adresse (ARP) [LINK:2] DOIT (MUST) fournir un mécanisme pour effacer les entrées de cache obsolètes. Si ce mécanisme implique un délai d'attente, la valeur de délai DEVRAIT (SHOULD) être configurable.

Un mécanisme empêchant l'inondation ARP (envoi répété de requêtes ARP à haute vitesse pour la même adresse IP) DOIT (MUST) être inclus. Le débit maximal recommandé par adresse de destination est de 1 par seconde.

DISCUSSION :

La spécification ARP [LINK:2] suggère mais n'exige pas un mécanisme de délai d'attente pour invalider les entrées de cache lorsqu'un hôte change son adresse Ethernet. L'omniprésence du proxy ARP (voir section 2.4 de [INTRO:2]) augmente considérablement la probabilité que les entrées de cache sur un hôte deviennent non valides, donc un mécanisme d'invalidation du cache ARP est maintenant nécessaire sur les hôtes. Même sans proxy ARP, un cycle de délai d'attente de cache long est utile pour corriger automatiquement toute donnée ARP erronée qui aurait pu être mise en cache.

IMPLEMENTATION :

Quatre mécanismes ont été utilisés, parfois en combinaison, pour effacer les entrées de cache obsolètes.

(1) Délai d'attente (Timeout) —— expire périodiquement les entrées de cache, même si elles sont utilisées. Notez que lorsqu'une entrée de cache est « rafraîchie » (en observant le champ source des diffusions ARP des systèmes concernés, indépendamment de l'adresse de destination), ce délai devrait être redémarré. Pour le cas du proxy ARP, le délai d'attente doit être de l'ordre d'une minute.

(2) Sondage unicast (Unicast Poll) —— sonde activement l'hôte distant en lui envoyant une requête ARP point à point, et supprime l'entrée si aucune réponse ARP n'est reçue lors de N sondages consécutifs. De même, le délai d'attente doit être de l'ordre d'une minute, et généralement N est 2.

(3) Conseil de la couche de liaison (Link-Layer Advice) —— si le pilote de la couche de liaison détecte un problème de livraison, efface l'entrée de cache ARP correspondante.

(4) Conseil de la couche supérieure (Higher-layer Advice) —— fournit un appel de la couche Internet à la couche de liaison pour indiquer un problème de livraison. Cet appel a pour effet d'invalider l'entrée de cache correspondante. Cet appel est similaire à l'appel « ADVISE_DELIVPROB() » de la couche de transport à la couche Internet (voir section 3.4), et en effet la routine ADVISE_DELIVPROB peut à son tour appeler la routine de conseil de la couche de liaison pour invalider l'entrée de cache ARP.

Les méthodes (1) et (2) impliquent un délai d'attente du cache ARP d'environ une minute ou moins. Sans proxy ARP, un délai d'attente aussi court peut générer un trafic de surcharge significatif sur de très grands Ethernet. Par conséquent, il peut être nécessaire de configurer l'hôte pour prolonger le délai d'attente du cache ARP.

2.3.2.2 File d'attente des paquets ARP (ARP Packet Queue)

La couche de liaison DEVRAIT (SHOULD) sauvegarder (plutôt que supprimer) au moins un (le plus récent) des paquets de chaque groupe envoyé à la même adresse IP non résolue, et transmettre le paquet sauvegardé une fois l'adresse résolue.

DISCUSSION :

Le non-respect de cette recommandation entraîne la perte du premier paquet de chaque échange. Bien que les protocoles de couche supérieure puissent généralement faire face à la perte de paquets par retransmission, la perte de paquets affecte les performances. Par exemple, la perte d'une requête d'ouverture TCP exagère l'estimation du temps d'aller-retour initial. Les applications basées sur UDP (comme le système de noms de domaine) sont plus gravement affectées.

2.3.3 Encapsulation Ethernet et IEEE 802 (Ethernet and IEEE 802 Encapsulation)

L'encapsulation IP sur Ethernet est décrite dans RFC-894 [LINK:3], et RFC-1042 [LINK:4] décrit l'encapsulation IP sur les réseaux IEEE 802. RFC-1042 détaille et remplace la discussion de la section 3.4 de [INTRO:2].

Chaque hôte Internet connecté à un câble Ethernet 10Mbps :

• DOIT (MUST) être capable d'envoyer et de recevoir des paquets en utilisant l'encapsulation RFC-894 ;
• DEVRAIT (SHOULD) être capable de recevoir des paquets RFC-1042, en les mélangeant avec des paquets RFC-894 ; et
• PEUT (MAY) être capable d'envoyer des paquets en utilisant l'encapsulation RFC-1042.

Un hôte Internet implémentant l'envoi des deux encapsulations RFC-894 et RFC-1042 DOIT (MUST) fournir un commutateur de configuration pour sélectionner laquelle envoyer, et ce commutateur DOIT (MUST) avoir RFC-894 comme défaut.

Notez que l'encapsulation IP standard de RFC-1042 n'utilise pas la valeur d'identifiant de protocole IEEE réservée à IP (K1=6) ; au contraire, elle utilise une valeur (K1=170) impliquant une extension (« SNAP ») qui peut contenir le champ Ether-Type. Les systèmes Internet NE DOIVENT PAS (MUST NOT) envoyer de paquets 802 utilisant K1=6.

La traduction d'adresse Internet en adresse de couche de liaison sur les réseaux Ethernet et IEEE 802 DOIT (MUST) être gérée par le protocole de résolution d'adresse (ARP).

Le MTU d'Ethernet est de 1500, et le MTU de 802.3 est de 1492.

DISCUSSION :

La spécification IEEE 802.3 fournit un fonctionnement sur un câble Ethernet 10Mbps, auquel cas les trames Ethernet et 802.3 peuvent être physiquement mélangées. Le récepteur peut distinguer les trames Ethernet et 802.3 par la valeur du champ de longueur 802.3 ; ce champ de deux octets se trouve dans l'en-tête à la même position que le champ Ether-Type des trames Ethernet. En particulier, le champ de longueur 802.3 doit être inférieur ou égal à 1500, tandis que toutes les valeurs Ether-Type valides sont supérieures à 1500.

Un autre problème de compatibilité survient avec la diffusion de la couche de liaison. Une diffusion envoyée dans un format de trame n'est pas vue par les hôtes ne pouvant recevoir que l'autre format de trame.

Les dispositions de cette section visent à permettre, dans la mesure du possible, l'interopérabilité directe sur le même câble entre les systèmes prenant en charge 894 et ceux prenant en charge 1042. L'objectif est de prendre en charge la situation actuelle dominée par les systèmes 894 uniquement, tout en fournissant une transition en douceur vers un avenir où les systèmes 1042 pourraient devenir courants.

Notez qu'un système 894 uniquement ne peut pas interopérer directement avec un système 1042 uniquement. Si ces deux types de systèmes sont configurés comme deux réseaux logiques différents sur le même câble, ils ne peuvent communiquer que via une passerelle IP. De plus, en raison du problème de diffusion de la couche de liaison, il est inutile et impossible pour un hôte à double format de découvrir automatiquement quel format envoyer.

2.4 Interface liaison/Internet (LINK/INTERNET LAYER INTERFACE)

L'interface de réception de paquets entre la couche IP et la couche de liaison DOIT (MUST) inclure un drapeau indiquant si le paquet entrant est adressé à une adresse de diffusion de la couche de liaison.

DISCUSSION :

Bien que la couche IP ne connaisse généralement pas les adresses de la couche de liaison (car chaque support réseau différent a généralement un format d'adresse différent), l'adresse de diffusion sur un support à capacité de diffusion est un cas particulier important. Voir la section 2.4, en particulier la discussion sur les tempêtes de diffusion.

L'interface d'envoi de paquets entre IP et la couche de liaison DOIT (MUST) inclure le champ TOS de 5 bits (voir section 3.2.1.6).

La couche de liaison NE DOIT PAS (MUST NOT) signaler une erreur « destination inaccessible (Destination Unreachable) » à IP simplement parce qu'aucune entrée de cache ARP n'existe pour une adresse de destination.

2.5 Résumé des exigences de la couche de liaison (LINK LAYER REQUIREMENTS SUMMARY)

Caractéristique (Feature)	Section	MUST	SHOULD	MAY	SHOULD NOT	MUST NOT
Encapsulation Trailer (Trailer encapsulation)	2.3.1			x
Envoyer des Trailers par défaut sans négociation (Send Trailers by default without negotiation)	2.3.1					x
ARP	2.3.2
Effacer les entrées de cache ARP obsolètes (Flush out-of-date ARP cache entries)	2.3.2.1	x
Empêcher les inondations ARP (Prevent ARP floods)	2.3.2.1	x
Délai de cache configurable (Cache timeout configurable)	2.3.2.1		x
Sauvegarder au moins un (le plus récent) paquet non résolu (Save at least one (latest) unresolved pkt)	2.3.2.2		x
Encapsulation Ethernet et IEEE 802 (Ethernet and IEEE 802 Encapsulation)	2.3.3
Hôte capable : (Host able to:)	2.3.3
- Envoyer et recevoir l'encapsulation RFC-894 (- Send & receive RFC-894 encapsulation)	2.3.3	x
- Recevoir l'encapsulation RFC-1042 (- Receive RFC-1042 encapsulation)	2.3.3		x
- Envoyer l'encapsulation RFC-1042 (- Send RFC-1042 encapsulation)	2.3.3			x
Commutateur de configuration pour sélectionner, défaut RFC-894 (Then config. sw. to select, RFC-894 dflt)	2.3.3	x
Envoyer l'encapsulation K1=6 (Send K1=6 encapsulation)	2.3.3					x
Utiliser ARP sur Ethernet et réseaux IEEE 802 (Use ARP on Ethernet and IEEE 802 nets)	2.3.3	x
Interface liaison/Internet (Link/Internet Layer Interface)	2.4
La couche liaison signale les diffusions à la couche IP (Link layer report b'casts to IP layer)	2.4	x
La couche IP transmet le TOS à la couche liaison (IP layer pass TOS to link layer)	2.4	x
Entrée de cache ARP absente traitée comme Dest. Inaccessible (No ARP cache entry treated as Dest. Unreach.)	2.4					x

---

Références (References) :

• [LINK:1] Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893, Univ. of California at Berkeley, April 1984.
• [LINK:2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826, November 1982.
• [LINK:3] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", RFC-894, April 1984.
• [LINK:4] Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC-1042, February 1988.