Tant qu'à faire un truc goret, autant faire un truc d'avenir : le nat64 sera probablement un plus dans un futur que j'espère très proche : cela permet à des particuliers IPv6 de continuer à contacter les inéluctables résistants IPv4

Avec une sorte de UPnP adapté au NAT64?

Est-ce que ça existe?

Quel est l'intérêt de toutes ces techno, comparés à du nat64 ?

A+P ressemble à NAT 1:1, il ne dépend d'aucun suivi de connexion(*) et aucun état conservé, d'où :
- simplicité conceptuelle, d'où facilité de raisonner sur les propriétés du système
- simplicité de l'implèmentation,
- efficacité
- facilité d'introduire de la redondance, robustesse

Oser comparer le A+P avec NAT64, qui est pire que le NAT44 puisqu'il change les adresses sources et destination, eux...

(*) module conntrack de linux et tout ce qui s'ensuit :

   nf_conntrack_acct.c   3103 bytes
   nf_conntrack_amanda.c   6125 bytes
   nf_conntrack_broadcast.c   2130 bytes
   nf_conntrack_core.c   49898 bytes
   nf_conntrack_ecache.c   7901 bytes
   nf_conntrack_expect.c   17954 bytes
   nf_conntrack_extend.c   5055 bytes
   nf_conntrack_ftp.c   17526 bytes
   nf_conntrack_h323_asn1.c   20165 bytes
   nf_conntrack_h323_main.c   55913 bytes
   nf_conntrack_h323_types.c   89907 bytes
   nf_conntrack_helper.c   13323 bytes
   nf_conntrack_irc.c   8169 bytes
   nf_conntrack_l3proto_generic.c   2094 bytes
   nf_conntrack_labels.c   3102 bytes
   nf_conntrack_netbios_ns.c   2254 bytes
   nf_conntrack_netlink.c   83120 bytes
   nf_conntrack_pptp.c   18656 bytes
   nf_conntrack_proto.c   12924 bytes
   nf_conntrack_proto_dccp.c   29451 bytes
   nf_conntrack_proto_generic.c   5998 bytes
   nf_conntrack_proto_gre.c   12533 bytes
   nf_conntrack_proto_sctp.c   29026 bytes
   nf_conntrack_proto_tcp.c   53908 bytes
   nf_conntrack_proto_udp.c   10222 bytes
   nf_conntrack_proto_udplite.c   11098 bytes
   nf_conntrack_sane.c   6257 bytes
   nf_conntrack_seqadj.c   6456 bytes
   nf_conntrack_sip.c   46405 bytes
   nf_conntrack_snmp.c   2272 bytes
   nf_conntrack_standalone.c   14797 bytes
   nf_conntrack_tftp.c   4235 bytes
   nf_conntrack_timeout.c   1508 bytes
   nf_conntrack_timestamp.c   2692 bytes

Si je ne m'abuse, le "A+P" permet une fonctionnement transparent du routeur client

Il faut juste qu'il connaisse les ports.

Transmis comment, par DHCP?

Pour les connexions entrantes il ne va rien recevoir.
Mais la question se pose pour les connexions sortantes. Je suppose que les plages de ports source non autorisées seront bloquées, sinon quand le routeur choisit un port source qui n'est pas dans sa plage, le serveur en face répondrait à un autre abonné.
Si le routeur ne sait pas limiter les ports source qu'il utilise, les abonnés n'ayant pas les ports 1-16383 risquent de n'avoir aucune connexion TCPv4/UDPv4 fonctionnelle...

C'est facile avec iptables mais encore faut-il avoir accès aux paramètres de cette de commande!

J'ai pas les mêmes échos que Vivien concernant le matériel mystère, donc Wait and See, comme on dit.

Tu peux préciser ?

Ah oui, tu peux expliquer?

Ben quand tu vas sur des sites comme mon-IP.com, il te montre toujours un port >1024, j'avais demandé à mon prof de l'époque et il m'avait parlé de plage dédiée pour TCP et UDP (j'en ai plus jamais entendu parler, y'a ou y'a pas ?)