Tous ces points à part le dernier (et encore) sont des problèmes liés à l'UPNP qui est lui même lié au fait que le grand public n'est pas capable de configurer un pare feu. Ce n'est pas un problème de NAT.
Pas vraiment.
L'UPNP est le propre du PAT. Principalement du au fait qu'ouvrir une connection Pt2Pt entre deux machines derrière PATs est une sinécure. Faire du hole punching dans une config "ipv6 + pare-feu" est beaucoup plus simple: tu n'as même pas besoin de machine type intermédiaire externe type STUN/TURN et donc pas besoin d'UPNP.
Le NAT est un parasite réseau d'un point de vue L3 et l'UPNP/ PMP a juste été inventé pour le rendre un peu plus gérable.
Dans une architecture fully V6, Tu as besoin d'ouvrir un port réseau uniquement si tu veux exposer un serveur interne.
Dans une architecture à PAT, la moindre connexion P2P, même sans exposition de service est une expérience de magie noire, et l'UPNP est là pour rendre l'expérience un peu meilleur (et parfois pire)
[^] # Re: Modèle d’attaque
Posté par Firwen (site web personnel) . En réponse au journal free et ipv6. Évalué à 2.
Réponse tardive.
Pas vraiment.
L'UPNP est le propre du PAT. Principalement du au fait qu'ouvrir une connection Pt2Pt entre deux machines derrière PATs est une sinécure. Faire du hole punching dans une config "ipv6 + pare-feu" est beaucoup plus simple: tu n'as même pas besoin de machine type intermédiaire externe type STUN/TURN et donc pas besoin d'UPNP.
Le NAT est un parasite réseau d'un point de vue L3 et l'UPNP/ PMP a juste été inventé pour le rendre un peu plus gérable.
Dans une architecture fully V6, Tu as besoin d'ouvrir un port réseau uniquement si tu veux exposer un serveur interne.
Dans une architecture à PAT, la moindre connexion P2P, même sans exposition de service est une expérience de magie noire, et l'UPNP est là pour rendre l'expérience un peu meilleur (et parfois pire)