RFC 89 (faux) F. Faraux (Très Experimental) 26 septembre 2025 Titre : NAT 69 et le routeur NAT64-69-46 — une proposition troll-friendly Statut : Informational (parodique) Résumé Ce document décrit, sur le ton de la plaisanterie technique, la "NAT 69" — un mode de traduction d'adresses réseau imaginé pour faciliter les connexions peer-to-peer avec une touche de romantisme réseau — et introduit l'idée farfelue d'un routeur triple-NAT nommé NAT64-69-46. Le texte se veut lisible par des ingénieurs sérieux et distrayants. 1. Contexte et motivation Les techniques classiques de NAT (statique, PAT, NAT64, NAT46, etc.) répondent à des besoins pratiques. Toutefois, en cas de session P2P où les deux extrémités sont timides et derrière des NATs symétriques, une solution "sympathique" peut faciliter l'établissement mutuel. NAT 69 est proposée comme réponse humoristique : établir des mappings réciproques, « consentants », entre peers. NAT64-69-46 est l'appareil fantasque qui implémente tous ces modes simultanément. 2. Définitions - A_priv, B_priv : adresses privées des peers A et B. - A_pub, B_pub : adresses publiques (NAT) correspondantes. - mapping69 : un mapping réciproque créé par le NAT qui autorise explicitement les paquets entrants du pair identifié. - NAT64-69-46 : routeur imaginaire qui supporte NAT64, NAT69 et NAT46, et offre des options de "flirt" réseau (debug level: flirt). 3. Principes de NAT 69 3.1 Comportement fondamental - Lorsqu'un hôte A_priv:pa initie un flux vers B_pub:pb, le NAT crée : A_pub:pa <-> A_priv:pa (mapping classique) mapping69(B_pub:pb -> A_priv:pa) (mapping réciproque) - Ce mapping69 demeure actif pendant un délai T69 par défaut (ex. 69 secondes, naturellement). - Si B répond depuis B_pub:pb → A_pub:pa, le NAT laisse passer et reverse-mappe vers A_priv:pa même si B n'a pas initialisé une session sortante identique. 3.2 Règles additionnelles de "galanterie" - Si B_initie sur un port différent (pb'), le NAT tente d'« aligner » pb' avec mapping69 existant, favorisant le port « romantique » observé précédemment. - Mécanisme de "consentement explicite" : un paquet avec la marque TCP optionnel "SYN+♡" peut demander au NAT de prolonger mapping69 pour la session. 4. NAT64-69-46 — architecture et modes 4.1 Vue d'ensemble NAT64-69-46 est présenté comme un routeur supportant : - NAT64 : traduction IPv6 → IPv4. - NAT46 : traduction IPv4 → IPv6. - NAT69 : traduction réciproque P2P (notion purement ludique). L'appareil expose un plan de contrôle simple pour activer/désactiver chaque mode et régler T69. 4.2 Table de translation composite La table interne contient des entrées du type : [af_in, af_out, pub_ip:port, priv_ip:port, mode_flags, ttl] Exemple : [IPv4, IPv4, 203.0.113.10:62000, 10.0.0.2:5000, NAT69, 69s] 5. Exemples de flux (ASCII) Scénario : A (10.0.0.2:5000) → B (198.51.100.20:4000), A initie. A_priv:5000 -> NAT(A_pub:62000) -> Internet -> B_pub:4000 NAT crée mapping69 : A_pub:62000 <-> 10.0.0.2:5000 mapping69(B_pub:4000 -> 10.0.0.2:5000) active pour 69s Si B envoie un paquet vers A_pub:62000 : B_pub:4000 -> NAT(A_pub:62000) -> NAT mappe vers 10.0.0.2:5000 6. Pseudo-configuration (CLI toy) # activer le mode nat69 router(config)# nat mode nat69 enable router(config)# nat69 timeout 69 router(config)# nat69 consent-option syn-heart enable # activer nat64/nat46 router(config)# nat64 enable router(config)# nat46 enable # créer une règle explicite pour un pair router(config)# nat69 peer 198.51.100.20 port 4000 allow (Note : commandes fictives. Ne pas envoyer en prod.) 7. Considérations de sécurité - Le mapping réciproque (NAT69) augmente la surface d'attaque : un attaquant peut forcer la création de mappings qui persistent et acheminer du trafic non désiré. Toujours valider l'adresse distante avant d'accorder mapping69 (ex. via ACL, auth, ou proxy). - NAT64/NAT46 combinés exigent une attention aux filtres d'adresses, logs et traçabilité : il est plus facile de « perdre » l'origine réelle des paquets. - Ne pas activer NAT69 dans des environnements multi-tenant sans isolation stricte (network policies, namespaces, cgroups). 8. Interopérabilité - NAT69 est rétrocompatible avec le NAT classique côté initiateur. - Les implémentations devraient documenter la durée T69 et la politique de création/élimination d'entrées. - Les middleboxes et firewalls doivent explicitement savoir interpréter les entrées NAT69 pour permettre un debugging correct. 9. Observabilité et debugging - Logs recommandés : création/suppression mapping69, adresse distante, durée restante. - Commandes utiles : show nat69 sessions clear nat69 session 10. Déploiement en environnement mutualisé - Recommandé de placer NAT64-69-46 derrière un reverse-proxy et d'utiliser des quotas/limites CPU et mémoire. En cas de saturation, T69 doit être baissé (par exemple 10s) pour éviter l'accumulation d'entrées. 11. Expériences de terrain (anecdotes) - Lors d'un test en laboratoire, la configuration "nat69 timeout 69" a rendu les ingénieurs inexplicablement plus amicaux. Coïncidence ? 12. Considérations IANA - Aucune assignation réelle demandée. Le document est humoristique. 13. Sécurité (remarque finale sérieuse) - Malgré le ton, toute fonctionnalité qui assouplit la politique par défaut de NAT (création automatique d'entrées acceptant des flux entrants) doit être évaluée sous l'angle de la sécurité réseau. Les recommandations de mitigation du §7 s'appliquent. Références - RFC 2663 (NAT Terminology) — pour contexte historique. - RFCs sur NAT64 / NAT46 — pour les principes de traduction d'addressage. - Documentation interne du routeur (fictive). Auteur Frédéric Faraux Note finale Document parodique — présentez-le avec un sourire et un gros disclaimer. Toute ressemblance avec des normes officielles est purement volontaire et potentiellement délicieusement incorrecte.