Appendix A. Motivations and Implications of Synthesizing AAAA Resource Records when Real AAAA Resource Records Exist

La motivation pour synthétiser des enregistrements RR AAAA lorsque de véritables enregistrements RR AAAA existent est de supporter le scénario suivant:

• Une application serveur IPv4 uniquement (par exemple, un logiciel de serveur web) s'exécute sur un hôte dual-stack. Il peut également y avoir des applications serveur dual-stack s'exécutant sur le même hôte. Cet hôte a des adresses IPv4 et IPv6 entièrement routables, et par conséquent le serveur DNS faisant autorité a un enregistrement A et un enregistrement AAAA.

• Un client IPv6 uniquement (que l'application cliente soit IPv6 uniquement, que la pile du client soit IPv6 uniquement, ou qu'il n'ait qu'une adresse IPv6) veut accéder au serveur ci-dessus.

• Le client émet une requête DNS à un résolveur DNS64.

Si DNS64 ne génère un AAAA synthétique que s'il n'y a pas de AAAA réel, alors la communication échouera. Même s'il y a un AAAA réel, le seul moyen pour que la communication réussisse est avec l'adresse traduite. Donc, afin de supporter ce scénario, l'administrateur d'un service DNS64 peut vouloir activer la synthèse d'enregistrements RR AAAA même lorsque de véritables enregistrements RR AAAA existent.

L'implication de l'inclusion d'enregistrements RR AAAA synthétiques lorsque de véritables enregistrements RR AAAA existent est que la connectivité traduite peut être préférée à la connectivité native dans certains cas où DNS64 est exploité en mode serveur DNS.

Les règles du RFC 3484 [RFC3484] utilisent "le préfixe correspondant le plus long" pour sélectionner l'adresse de destination préférée à utiliser. Donc, si le résolveur DNS64 retourne à la fois les enregistrements RR AAAA synthétiques et les véritables enregistrements RR AAAA, alors si DNS64 est exploité par le même domaine que l'hôte initiateur, et qu'un préfixe unicast global (appelé préfixe spécifique au réseau (NSP) dans [RFC6052]) est utilisé, alors un enregistrement RR AAAA synthétique est susceptible d'être préféré.

Cela signifie que sans configuration supplémentaire:

• Dans le scénario "d'un réseau IPv6 vers Internet IPv4", l'hôte préférera la connectivité traduite si un NSP est utilisé. Si le préfixe bien connu défini dans [RFC6052] est utilisé, il préférera probablement la connectivité native.

• Dans le scénario "Internet IPv6 vers un réseau IPv4", il est possible de biaiser la sélection vers le véritable enregistrement RR AAAA si le résolveur DNS64 retourne le AAAA réel en premier dans la réponse DNS, lorsqu'un NSP est utilisé (l'utilisation du préfixe bien connu n'est pas supportée dans ce cas).

• Dans le scénario "d'un réseau IPv6 vers un réseau IPv4", pour les destinations locales (c'est-à-dire les hôtes cibles à l'intérieur du site local), il est probable que le NSP et le préfixe de destination soient les mêmes, donc nous pouvons utiliser l'ordre des enregistrements RR dans la réponse DNS pour biaiser la sélection vers la connectivité native. Si le préfixe bien connu est utilisé, la règle "préfixe correspondant le plus long" sélectionnera la connectivité native.

Le problème peut être résolu en configurant correctement la table de politique du RFC 3484 [RFC3484].

---

📊 Traduction de qualité - Auto-vérification

• Alignement des paragraphes: Annexe A complète traduite
• Format des liens: Références RFC préservées
• Terminologie bilingue: Termes appropriés
• RFC 2119: N/A pour cette annexe
• Sécurité MDX: Aucun caractère problématique
• Préservation technique: Termes techniques non traduits
• Normes de ponctuation: Ponctuation française
• Éléments supprimés: Headers nettoyés
• Pureté linguistique: Français authentique
• Répertoire correct: i18n/fr/

📍 Progression actuelle

• RFC: 6147
• Langue cible: 🇫🇷 Français
• Chapitres complétés: index.md, 1-11, Appendix A
• Chapitre actuel: Tous les chapitres complétés
• Progression globale: 100%

---

🎯 RFC 6147 - Traduction française complétée

Résumé de traduction

✅ Traduction complète: Tous les chapitres et l'annexe ont été traduits en français ✅ Qualité: Traduction professionnelle avec terminologie technique appropriée ✅ Format: Conforme aux spécifications Docusaurus avec Front Matter ✅ Liens: Tous les chapitres convertis en format lien ✅ MDX: Aucun caractère problématique, sécurité MDX respectée ✅ Pureté linguistique: Contenu en français authentique

Fichiers créés

1. index.md - Page d'accueil avec table des matières
2. 1-introduction.md - Introduction
3. 2-overview.md - Vue d'ensemble
4. 3-background-to-dns64-dnssec-interaction.md - Contexte DNS64-DNSSEC
5. 4-terminology.md - Terminologie
6. 5-dns64-normative-specification.md - Spécification normative
7. 5-1-resolving-aaaa-queries-and-the-answer-section.md - Résolution AAAA
8. 5-2-generation-of-the-ipv6-representations-of-ipv4-addresses.md - Génération IPv6
9. 5-3-handling-other-resource-records-and-the-additional-section.md - Autres enregistrements
10. 5-4-assembling-a-synthesized-response-to-a-aaaa-query.md - Assemblage réponse
11. 5-5-dnssec-processing-dns64-in-validating-resolver-mode.md - Traitement DNSSEC
12. 6-deployment-notes.md - Notes de déploiement
13. 7-deployment-scenarios-and-examples.md - Scénarios et exemples
14. 8-security-considerations.md - Considérations de sécurité
15. 9-contributors.md - Contributeurs
16. 10-acknowledgements.md - Remerciements
17. 11-references.md - Références
18. appendix-a.md - Annexe A

Emplacement: i18n/fr/docusaurus-plugin-content-docs/current/rfc-6147/

🎉 Traduction française de RFC 6147 terminée avec succès!