Le NAT44 permet aussi de faire de la correspondance m à n, mais l'usage est d'avoir m=1 (car le problème résolu avec NAT est le nombre d'adresses disponibles).
Le NAT64 permet de réduire la taille du n de manière plus raisonnable, puisque tu souhaites cacher ton réseau interne et surtout que le principal avantage de l'IPv6 n'est pas maintenu (le end to end).
La RFC propose en effet que la durée d'utilisation de l'adresse temporaire par la machine soit de 1 jour, mais c'est configurable.
Je pense que l'on se bat contre une chimère : vouloir des connexions end to end avec de la confidentialité de la structure réseau à chaque point. De plus, une écoute active du réseau permettra toujours de pouvoir tirer des informations avec les statistiques avec plus ou moins d'incertitudes.
Ce qui me plaît avec ces RFCs, c'est que ça garde possible l'utilisation du end to end tout en améliorant la confidentialité des activités de la machine à postériori. La RFC propose de créer des plages d'adresse temporaire, donc les logs du serveur X générés par le client A à l'instant T peuvent être différents des logs du serveur Z au même instant T. Ça dépend uniquement de la gestion des adresses par le client et c'est déjà disponible en pratique.
[^] # Re: NAT66 ou masquarade66
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Protéger sa vie privée avec l’IPv6. Évalué à 4.
Le end to end ne peux pas être maintenu avec des NATs: il faut pouvoir répondre au cas d'usage du commentaire de Xavier Claude, plus haut.
Le NAT44 permet aussi de faire de la correspondance m à n, mais l'usage est d'avoir m=1 (car le problème résolu avec NAT est le nombre d'adresses disponibles).
Le NAT64 permet de réduire la taille du n de manière plus raisonnable, puisque tu souhaites cacher ton réseau interne et surtout que le principal avantage de l'IPv6 n'est pas maintenu (le end to end).
La RFC propose en effet que la durée d'utilisation de l'adresse temporaire par la machine soit de 1 jour, mais c'est configurable.
Je pense que l'on se bat contre une chimère : vouloir des connexions end to end avec de la confidentialité de la structure réseau à chaque point. De plus, une écoute active du réseau permettra toujours de pouvoir tirer des informations avec les statistiques avec plus ou moins d'incertitudes.
Ce qui me plaît avec ces RFCs, c'est que ça garde possible l'utilisation du end to end tout en améliorant la confidentialité des activités de la machine à postériori. La RFC propose de créer des plages d'adresse temporaire, donc les logs du serveur X générés par le client A à l'instant T peuvent être différents des logs du serveur Z au même instant T. Ça dépend uniquement de la gestion des adresses par le client et c'est déjà disponible en pratique.