Si l'opérateur reste sur 1500 octets, il n'y a normalement pas de fragmentation IPv4 en TCP, car la MTU est négociée lors de la connexion : Négociation MTU MSS: comment ça fonctionne ?

Pour les flux UDP, généralement, on ne dépasse pas 1400 octets voir moins, car de nombreux réseaux ont une MTU vu de l'utilisateur plus faible à cause des encapsulations (par exemple sur un réseau mobile, il y a la aussi double en-tête sans parler de technologie de partage d'IPv4).

Je suis d'accord pour le cas non-VPN. Je parlais du traffic encapsulé (que ce soit dans IPSec ou de l'UDP), qui de surcroit est chiffré : la MTU côté LAN est vue à 1500, et si on encapsule dans du DSLite ou autre au niveau CPE, le CPE ne peut pas faire de MSS clamping. La MSS négociée à l'intérieur du VPN entre les deux endpoints n'entre pas en compte ici.

Certains opérateurs ont une MTU un peu au-dessus de 1500 pour ne pas effectuer la MUT vu de l'utilisateur, mais cela demande d'avoir tous ses équipements compatibles et configurés pour cette MTU plus importante.

Oui, c'est aussi ce que je dis: il peut y avoir des soucis en fonction des contraintes du matériel et de la mise en oeuvre par les opérateurs, mais que ce soit du MAP-T, MAP-E ou autre chose n'a pas grande importance in fine.

Et là, la barre n'est pas très haute.

c'est vite dit ça ...
Tous les fournisseurs d'accès gamme business n'offre pas IPv6.
Chez Orange Pro par exemple, impossible d'avoir des IPv6 Fixes. (je ne sais pas pour les autres)
j'ai un doute aussi sur le fait que le L2TP par exemple fonctionne avec IPv6.
Bref, c'est plus simple et fiables que Bouygues fournissent des IPv4 dédiés ..

Je n'ai rien contre IPv6, mais bon dans le milieu pro ce n'est pas si simple.

J'attends toujours un dualwan simple en IPv6, des équipements compatibles et surtout qu'on m'explique l’intérêt. Autant à la maison aucun soucis pour IPv6, autant au travail ...

Pour la MTU, si c'est elle qui bloque avec MAP-T de Bouygues, cela ne va pas fonctionner avec les autres technologies comme le MAP-E de Free ou le futur DS-Lite d'Orange : La MTU IPv4 baisse encore de 20 octets supplémentaire, il me semble avec ces autres technologies.

Taille du paquet maximum (avec les en-têtes) : 1500 octets
- En-tête IPv4 : 20 octets (s'il n'y a pas d'options, sachant que certains OS activent des options)
- Quand on passe les paquets IPv4 dans IPv6 avec uniquement une en-tête IPv6 : 40 octets (MAP-T).
- Quand on passe les paquets IPv4 dans IPv6 avec uniquement une en-tête IPv6 devant une autre IPv4 : 40+20 octets = 60 octets (MAP-E, DS-Lite, Lightweight 4over6).

J'ai tenté de faire un comparatif de ces solutions pour fournir une connectivité IPv4 derrière une box FTTH connectée à un réseau IPv6 only (IPv4 as a Service)

DS-Lite (Dual-Stack Lite) : ne demande pas de fonctions complexes dans la box internet. La box prend tout le trafic IPv4 local, l'encapsule dans de l'IPv6 et l'envoie à un Carrier-grade NAT chez l'opérateur. Le Carrier-grade NAT doit maintenir l'état de chaque connexion IPv4 TCP/UDP de chaque abonné (un NAT44 classique est réalisé).

• Avantage : Compatibilité avec un très grand nombre de box.

• Inconvénients : Le Carrier-grade NAT dans le réseau est très gourmand en ressources (obligation de garder des journaux) et est un point unique de défaillance. Le Carrier-grade NAT bloque la possibilité d’ouvrir les flux entrants IPv4 non sollicités pour permettre un auto-hébergèrent IPv4. Le passage par la plateforme qui héberge le Carrier-grade NAT peut, dans certaines architectures, rajouter de la latence. Enfin, un en-tête IPv6 de 40 octets est ajouté à chaque paquet IPv4.

Lightweight 4over6 (lw4o6) : garde l'architecture DS-Lite (tunnel IPv4 dans IPv6), mais on déplace la fonction NAT du cœur de réseau vers la box chez le client. Le routeur central ne fait plus que du routage de tunnels (stateless ou semi-stateless), il n'a plus besoin de suivre chaque connexion TCP. L'opérateur dit explicitement à chaque box : « Toi, tu as l'IP X et la plage de ports Y ».

• Cas d'usage : Idéal pour migrer une infra DS-Lite existante vers quelque chose de plus léger, en réutilisant en grande partie l’architecture existante.

• Inconvénients : Le mapping (IP et ports) n'est pas algorithmique, mais provisionné. Un en-tête IPv6 de 40 octets est ajouté à chaque paquet IPv4.

MAP-E (Mapping of Address and Port with Encapsulation) : Comme lw4o6, le NAT est sur la box du client. Mais ici, le cœur de réseau est totalement stateless. Il n'y a pas de table de correspondance chez l'opérateur. L'adresse IPv6 de la box contient mathématiquement (via un algorithme) l'adresse IPv4 et la plage de ports. Le routeur de bordure calcule simplement où envoyer le paquet en lisant l'adresse IP.

• Avantages : Stateless. Passage à l'échelle infini (pas de mémoire requise côté opérateur par utilisateur). Très robuste. Deux abonnés peuvent échanger en IPv4 sans passer par un élément central. Permet d’ouvrir les flux entrants IPv4 non sollicités sur la plage de ports attribuée à la box, pour permettre un auto-hébergèrent IPv4 (en plus de IPv6 pour lequel tous les ports sont disponibles).

• Inconvénient : Un en-tête IPv6 de 40 octets est ajouté à chaque paquet IPv4.

MAP-T (Mapping of Address and Port using Translation) : identique à MAP-E, mais l’encapsulation est remplacée par une traduction : Au lieu d'enfermer le paquet IPv4 dans un paquet IPv6 (ce qui ajoute 40 octets), MAP-T remplace l'en-tête IPv4 par un en-tête IPv6 (NAT46). Le routeur de bordure re-traduit en IPv4 vers Internet (NAT64).

• Avantages : Identiques à MAP-E avec en plus l’absence de double en-tête IP pour les paquets IPv4.

• Inconvénients : Perte de certaines infos de l'en-tête IPv4 original (checksums à recalculer, options IPv4 perdues : ce qui peut compliquer le traitement de certains champs tel que la fragmentation, géré différemment dans l’en-tête IPv6). C'est techniquement plus complexe à implémenter correctement pour ne rien casser.

4rd (IPv4 Residual Deployment) : 4rd était une technologie expérimentale, crée par un ingénieur français Rémi Després, qui a été déployé essentiellement par l’opérateur Free. Les concepts de 4rd ont essentiellement été absorbés et finalisés avec MAP-E et MAP-T. Il n’y a plus de nouveaux déploiements de 4rd. Free a basculé en MAP-E.

Ca dépend de la techno VPN utilisée (IPSec, OpenVPN, encapsulation propriétaire dans TLS, etc.), de la configuration des équipements (firewall qui drop les fragments et ICMP parce que le consultant en sécu a dit que c'était "dangereux") et du CG-NAT que tu traverses.

Un classique, c'est le CG-NAT qui ne NAT que TCP/UDP couplé aux concentrateurs IPSec qui ne font pas de nat-t (parce que la case est décochée, ils savent tous le faire): les paquets IPSec sont jetés, NATés que dans un sens, etc. et ca casse.

Un autre, c'est les soucis de MTU et les firewalls qui drop les fragments. Comme l'encapsulation MAP-T diminue la MTU, le CPE fragmente les paquets, les fragments sont NATés par le CG-NAT, mais le firewall de l'entreprise les drop. Comme le MSS clamping n'est pas applicable aux flux UDP, bien souvent, les VPN en font les frais.

Enfin, il y a les pertes de sessions dans les CG-NAT. Parfois parce qu'il reboot, parfois parce qu'il overflow, parce que les timers sont très courts pour, justement, libérer des entrées le plus rapidement possible, parce que le client est migré vers un autre CG-NAT en cours de session, etc. Si le VPN n'est pas configuré pour émettre un keepalive au moins toutes les 30s, ca créé des pertes de connectivité VPN aléatoires.

Ces soucis sont classiques sur le mobile, je ne serai pas étonné que ce soit la même chose sur le fixe (mais je n'ai pas fait de test avec l'implémentation MAP-T de Bouygues. Je le constate par contre fréquemment sur le mobile).

Beaucoup de soucis liés à la diminution de qualité de service d'IPv4 qui serait facilement évités en configurant les endpoints VPN d'entreprise en dual stack.
Et aussi en configurant correctement les firewalls et concentrateurs VPN, mais là... on en demande beaucoup

Ca reste rare. Mais en quoi l'ip partagée gênerait un flux sortant client => concentrateur vpn ?