Auteur Sujet: Orange / Bouygues: IPv6 arrive sur les iPhone le 19 septembre 2019 (Lu 41835 fois)

JCLB · « **Réponse #72 le:** 27 septembre 2019 à 17:36:52 »

Intéressant, un abo Bouygues IOS 13 peut-il tester le https://1.1.1.1 depuis son pc en partage de co pour voir le résultat ?

Et effectuer la résolution dns d'un site v4 pour voir quel préfixe nat64 est utilisé le cas échéant ?

Antoinel · « **Réponse #73 le:** 27 septembre 2019 à 17:42:23 »

Bouygues iOS 13.1 en tethering wifi

Code: [Sélectionner]

nslookup ip4.me
Server:  UnKnown
Address:  172.20.10.1

Non-authoritative answer:
Name:    ip4.me
Addresses:  64:ff9b::a92d:c980
          169.45.201.128

Sur ip.lafibre.info, j'ai

Connectivité IPv4 (via requête DNS) OK : IPv4 publique = 80.215.172.138
Connectivité IPv4 (via IPv4 littérale) OK : IPv4 publique = 80.215.38.98

Le site https://1.1.1.1 s'affiche.

Bizarrement, si je consulte depuis mon iPhone le site ip.lafibre.info, j'obtiens des IPv4 identiques (DNS et littérale)

JCLB · « **Réponse #74 le:** 27 septembre 2019 à 18:20:23 »

pas d'alerte SSL sur 1.1.1.1 ? ça veut donc dire qu'il y'a fourniture soit via tunnel IPv4, soit via XLAT464.
Le nslookup retourne bien le WKP NAT64.

Pour l'adresse qui varie en tethering entre DNS et littéral, c'est car la connectivité v4 est fournie différemment.

Sur l'iPhone il n'y a pas de v4 pour les app, donc DNS64 envoie le WKP NAT64, et si tu fais du littéral IOS synthétise tout seul avec ce même préfixe RFCisé. Tu termines ta course sur le même CG-NAT et probablement avec la même IP publique

En tethering, le poste a son stack v4 up grâce au 172, ensuite le paquet est traduit OU encapsulé (selon la techno) en 6 sur le téléphone, et inversement en 4 chez Bouygues.

Probablement via 464XLAT même si je ne trouve toujours pas de trace de cette techno dans IOS, soit via un tunnel DS-LITE.
Si c'est du 464XLAT il renvoie peut-être vers une passerelle dédiée, si c'est un tunnel ça termine forcèment vers une passerelle dédiée, à cette échelle on ne mutualise pas les rôles.

Bouygues est gagnant en terme de session par rapport à Orange, car un abonné utilisant le tethering avec du v6 exploitera moins les équipements de CG-NAT puisque tout son trafic n'est pas v4, donc à l'échelle des millions de clients moins d'équipements à acquérir.

Antoinel · « **Réponse #75 le:** 27 septembre 2019 à 18:23:27 »

Pas d’alerte sur 1.1.1.1

vivien · « **Réponse #76 le:** 27 septembre 2019 à 18:26:46 »

Citation de: Antoinel le 27 septembre 2019 à 17:42:23

Bizarrement, si je consulte depuis mon iPhone le site ip.lafibre.info, j'obtiens des IPv4 identiques (DNS et littérale)

A priori sur iPhone le mécanisme permet d'avoir des IP identiques.

C'est bien de l'IPv6 only avec du DNS64+NAT64 et en cas d'IP littérale du 464XLAT chez Orange comme chez Bouygues Telecom.

JCLB · « **Réponse #77 le:** 29 septembre 2019 à 17:08:10 »

Citation de: vivien le 27 septembre 2019 à 18:26:46

A priori sur iPhone le mécanisme permet d'avoir des IP identiques.

C'est bien de l'IPv6 only avec du DNS64+NAT64 et en cas d'IP littérale du 464XLAT chez Orange comme chez Bouygues Telecom.

C'est du NAT64 forcé en littéral, pas du XLAT464, sinon un stack IPv4 serait exposé et https://1.1.1.1 n'afficherait pas d'erreur TLS dans safari ou autre. Ce qui est marche justement en tethering mais pas depuis le phone.

vivien · « **Réponse #78 le:** 29 septembre 2019 à 17:20:15 »

Comment cela se fait que pour certains, https://1.1.1.1/ fonctionne ?

Tu as trouvé de la documentation sur ce mode ?

Ce n'est pas du CLAT ?

https://mailarchive.ietf.org/arch/msg/v6ops/Xs5cqNa1mBMZkDPLNS5yWlrQN9U mentionne du 464xlat for tethering

=> Il y aurait un comportement différent quand on est sur son iPhone ou en partage de connexion ?

JCLB · « **Réponse #79 le:** 29 septembre 2019 à 17:48:10 »

IOS change à la volée l'adresse littérale v4
https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html

Concrètement, je prends iNetTools, je fais un traceroute de 1.1.1.1, l'app affiche 64:ff9b::101:101
Pareil dans le navigateur, la sous-couche software remplace ça à la volée. D'où le test de https://1.1.1.1

Par contre en partage de co (tethering) il faut exposer une (pseudo) continuité IPv4, sinon l'utilisateur risquerait d'avoir des soucis.

decalage · « **Réponse #80 le:** 29 septembre 2019 à 18:03:21 »

En page 7 : https://www.ipv6.org.uk/wp-content/uploads/2018/11/Nick-Heatley_BT_EE_464xlat_UKv6Council_20180925.pdf

JCLB · « **Réponse #81 le:** 29 septembre 2019 à 18:07:26 »

c'est bien ce qui est écrit
IOS: XLAT464 pour le tethering, NAT64 pour le tel (via DNS64 et forcé avec le préfixe pour le litéral)
Android: XLAT464 pour le tethering ET pour les apps qui font du v4 littéral

vivien · « **Réponse #82 le:** 29 septembre 2019 à 18:28:13 »

Donc cela explique que sur http://ip.lafibre.info les deux IPv4 soient identiques sur iOS.

En tethering, que donne http://ip.lafibre.info ? IPv4 via requête DNS différente de l'IPv4, via littérale ?

JCLB · « **Réponse #83 le:** 29 septembre 2019 à 18:42:09 »

Citation de: vivien le 29 septembre 2019 à 18:28:13

Donc cela explique que sur http://ip.lafibre.info les deux IPv4 soient identiques sur iOS.

En tethering, que donne http://ip.lafibre.info ? IPv4 via requête DNS différente de l'IPv4, via littérale ?

Exactement, d'autant que le préfixe NAT64 est à la discrétion de l'opérateur dans le paramétrage APN.
J'ai l'impression qu'orange utilise toujours le WKP, mais rien ne l'empêche demain de fournir d'autres passerelles avec des préfixes custom, notamment pour le mode modem.
Pour le téléphone il vaut mieux garder le même pour avoir un maintien de session dans le cas peu probable ou un site mixerait URL DNS et URL littérale, histoire que ça passe par le même CG-NAT...

Ce CG-NAT en adresse WKP doit probablement être porté par des load-balancers et centralisé ou anycasté.