Il y a des idées que l’on trouve géniales et que l’on regrette de ne pas avoir eu. Les NAT66 en font partie. Est-ce lié à un blocage vis-à-vis des NAT et au discours disant qu’IPv6 n’aura pas de NAT? Je le crois. En fait NAT66, c’est le bon coté des NAT sans en avoir tous les inconvénients. J’ai déjà longuement discuté de la multi-domiciliation et des problèmes posé en IPv6 par les adresses Provider Independant. Le NAT66 permet de resoudre une partie des problèmes sans trop de casse.
Qu’est-ce qu’à de plus le NAT66 par rapport à un NAT44, et bien, il ne demande pas à toucher au numéro de port du niveau 4 et est sans état. Le « miracle » est du à un changement simultané du préfixe et du Subnet ID. En interne je peux avoir un plan de numérotation privé du genre FD01:0203:0405:0001::/64 pour un lien. En traversant le NAT le préfixe /48 sera remplacé par celui alloué par mon opérateur et le SubnetID sera ajusté pour ne pas modifier le checksum des paquets (je n’ai pas le courage de faire le calcul, mais le draft nat66 donne un exemple complet).
Je peux donc publier l’adresse publique d’une machine dans le DNS. Si je suis multi-domicilié, je peux publier les deux valeurs vues de l’extérieur, mais en interne je garde une seule et même adresse. Par contre il reste quelques inconvénients :
– l’application ne connait pas son adresse externe, elle ne peut donc utilise que le DNS qui doit être double face pour rendre des résultats différents suivant qu’il est interrogé de l’interieur ou de l’extérieur.
– si le routage change, les connexions sont coupées.
Cela va aussi reduire l’intérêt pour des solutions comme LISP qui implique un double adressage (localisation et identification) avec les problèmes de performance et de sécurité liés à leur association.
Laurent