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.