Auteur Sujet: Manque d'IPv4 chez Free: Une IPv4 est partagée par 4 clients avec 1/4 des ports  (Lu 427780 fois)

0 Membres et 1 Invité sur ce sujet

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 166
  • Delta S 10G-EPON sur Les Ulis (91)
Pourtant, j'y reviens, mais il n'y a pas de NAT en IPv6, donc pas de routage NAT, tout est bridge en IPv6, non ?

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Même tracertoute, hors du réseau de Free :
$ mtr -rwc100 2a01:0e35:8beb:ebe0::1
Start: Wed Dec  9 09:39:27 2015
HOST: lafibre.info               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- bgp1.adeli.biz            0.0%   100    0.2   1.5   0.2  41.1   4.6
  2.|-- cr5.rt.ielo.net           0.0%   100    7.7  10.7   7.6  62.2   8.0
  3.|-- frpar01-a9k1.rt.ielo.net  0.0%   100    8.2   8.2   7.8   8.6   0.0
  4.|-- proxad.ebgp.ielo.net      0.0%   100    8.2   8.1   8.0   8.5   0.0
  5.|-- ? ?                      100.0   100
  6.|-- ? ?                      100.0   100
  7.|-- ? ?                      100.0   100
  8.|-- ? ?                      100.0   100
  9.|-- ? ?                      100.0   100
 10.|-- ? ?                      100.0   100
 11.|-- 2a01:e35:8beb:ebe0::1     0.0%   100    8.4   8.4   8.2  10.2   0.2


bon bah Free cache bien son réseau IPv6 (a dessein?) ... c'est pas gagné.
il faudra utilisé un ping udp  ou tcp.

Par contre un test de pathmtu indique 1480 pour cette IPv6.
Je pensais qu'il y n'avait plus de 6rd sur les connexions Fibre Free ?

serge.31

  • Expert (serge.31.free.fr)
  • Abonné Free adsl
  • *
  • Messages: 204
  • Saint-Orens-de-Gameville (31)
Pourtant, j'y reviens, mais il n'y a pas de NAT en IPv6, donc pas de routage NAT, tout est bridge en IPv6, non ?
Oui, plus de NAT, tous les équipements sont directement accessibles depuis le WAN :-(

Dans l'exemple ci-dessus,
l'ip v6 correspond à la Freebox, les équipements derrière le switch, raccordés en RJ ou WiFi disposent de plusieurs ip v6, formées à partir de la même racine ip (en /64 ?), complétée par l'@ MAC de sa carte réseau par exemple.

le pc WXP qui scanne (du moins pour le moment encore) le réseau free :

Carte Ethernet Connexion au réseau local:

        Suffixe DNS propre à la connexion :
        Description . . . . . . . . . . . : Broadcom NetXtreme Gigabit Ethernet
        Adresse physique . . . . . . . . .: 00-11-0A-97-6E-06
               Adresse IP. . . . . . . . . . . . : 2a01:e34:ed59:XXX0:211:0aff:fe97:6e06 --> à partir de l'@ MAC, la racine ip v6 de la freebox en /64

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Citer
Oui, plus de NAT, tous les équipements sont directement accessibles depuis le WAN :-(
Cela n'a aucun rapport

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
bon bah Free cache bien son réseau IPv6 (a dessein?) ... c'est pas gagné.
il faudra utilisé un ping udp  ou tcp.
Sous linux traceroute (UDP par défaut), et traceroute -T vers une Freebox en 6rd ne donnent rien : on a exactement la même chose qu'en ICMP, sauf qu'il manque la dernière ligne car la Freebox ne répond pas.

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 804
  • 73
Pour rappel, le fait que le trafic IPv4 passe dans IPv6 serait corroboré par les données rapportées jusqu'à là par cyberjuls :

Sortie IPv4 :

1. 91-160-5-***.subs.proxad.net [Abonné, Montpellier]
2. 194.149.164.0 [CG-NAT ou A+P, Île-de-France]
3. cbv-crs8-1-be1005.routers.proxad.net [Backbone, Courbevoie]


Sortie IPv6 :

1. 2a01:***:*:****::* [Abonné, Montpellier]
2. ??​?
3. 2a01:e02:7:1715::ffff [Inconnu, proche 1ms]
4. 2a01:e02:3::1 [Inconnu, proche 3ms]
5. ??​?
6. 2a01:e00:18::2 [Backbone, Île-de-France]




Peut-être que la technologie employée pourrait être 4rd (IPv4 Residual Deployment), une technologie développée par Rémi Després (l'auteur de 6rd, la techno IPv6 que Free a été le premier à déployer) dont la RFC expérimentale a été publiée en juin dernier, et qui propose la translation ou encapsulation d'IPv4 dans IPv6 avec partage des numéros de ports entre clients ?

https://en.wikipedia.org/wiki/IPv4_Residual_Deployment

IPv4 Residual Deployment has three main features:
•  Mesh topology: between two endpoints, IPv4 packets take the same direct routes as IPv6 packets
•  Shared IPv4 addresses: to deal with the unavoidable IPv4-address shortage, several customers can be assigned a common IPv4 address, with disjoint TCP/UDP port sets assigned to each (an application of the general A+P model of RFC 6346).
•  Stateless operation: conversions of IPv4 packets into IPv6 packets at domain entry, and the reverse at domain exit, are stateless (i.e., one where no per-customer state is needed in domain edge nodes).


Différents mécanismes à travers l'histoire de la norme :

The first "4rd" specification, unlike the current one of RFC 7600, used IPv4 encapsulation in IPv6 packets, the only known tunneling approach at that time to ensure complete IPv4 preservation across IPv6-only domains. It was the first proposal that combined stateless address mapping, mesh topology, and A+P.

Another sateless-mesh-A+P approach was next proposed, called dIVI. Instead of encapsulation, it used two successive translations (from IPv4 to IPv6 and then conversely), based on the existing SIIT one-way translations of RFC 2765. Compared to encapsulation, it had the advantage of making IPv6 packet inspections applicable to translated UDP and TCP IPv4 packets, but, due to limitations of SIIT, lacked full compatibility with IPv4 fragmentation (and consequently, as mentioned above, compatibility with path MTU Discovery recommended in RFC 6349).




A+P model :
http://www.bortzmeyer.org/6346.html (août 2011)
Donc, quels sont les principes d'A+P ? Comme les miracles n'existent pas, l'idée de base est un compromis. On va sacrifier quelques bits du numéro de port pour les donner à l'adresse IP. Ce faisant, on réduit la capacité des applications à allouer beaucoup de connexions ouvertes (chacune nécessitant un port) mais il n'y a plus guère le choix. Comme le note le RFC, « the need for addresses is stronger than the need to be able to address thousands of applications on a single host » ou, en termes plus brutaux, « en cas de famine, on ne réclame pas d'assaisonnement sur tous les plats ».

Cette famine fait que le partage d'adresses IPv4, déjà largement réalisé au sein d'une même maison ou entreprise, va forcèment s'étendre et que des clients différents, sans lieu entre eux, partageront la même adresse IP. L'idée d'A+P est que, même si l'adresse ne sera plus unique, le couple {adresse, partie du port} restera unique par client. Avec 65536 ports possibles, on peut mettre 65536 clients sur une même adresse IP (si chacun se contente d'un seul port), 256 (avec 256 ports chacun), ou un seul (avec le système actuel où le client a 65536 ports)... L'un des intérêts d'A+P est qu'il limite (sans toutefois le supprimer) le recours au NAT et à tous ses inconvénients.

En effet, une alternative à A+P serait de déployer des gros routeurs NAT (CGN, pour Carrier-grade NAT) dans les réseaux des FAI, routeurs qui traduiraient pour plusieurs clients (au contraire du routeur NAT typique d'aujourd'hui, qui n'opère que pour un seul client). La section 1.1 explique pourquoi c'est une mauvaise idée : le CGN ne maintient pas la connectivité de bout en bout, qui est au cœur d'Internet. Par exemple, le déploiement d'une nouvelle application qui échange des adresses serait bloqué tant que le routeur CGN (qui est sous le contrôle du FAI) n'est pas mis à jour avec un nouvel ALG. Les techniques qui permettent de rendre les routeurs NAT actuels un peu moins insupportables (configuration manuelle de la redirection de port, UPnP) ne marchent en effet pas sur un CGN. Enfin, les routeurs CGN stockent un état considérable (des centaines ou des milliers de clients) et sont donc un point de faiblesse du réseau : si un routeur CGN redémarre, tout est perdu.



(Illustration Wikipédia)




http://c2.touta.in/?p=461 (juillet 2011, peut-être pas à jour !)
(je suis tombé sur cet article fortuitement en faisant des recherches sur des préfixes d'adresses Free :))

Une proposition alternative à CGN est en débat à l’IETF, elle garde la même architecture à base de tunnels sur un réseaux IPv6. Mais au lieu de placer le NAT dans un équipement central dans le cœur du réseau, 4rd conserve le NAT dans les box des utilisateurs, et restreint l’utilisation des ports publics à une plage déterminée. Plusieurs utilisateurs peuvent donc se partager la même adresse IPv4 sans risque de conflit. L’équipement central ne gère que l’encapsulation/décapsulation des paquets IPv4 en ajoutant/retirant un en-tête IPv6.

Le document 4rd décrit comment une adresse IPv4 (et un ensemble de port) peut être dérivé d’une adresse IPv6. La box est préalablement configurée avec un préfixe IPv4 publique et une longueur indiquant la partie index CE (Customer Edge) qui correspond aux bits les moins significatifs (ceux de droite) du préfixe global.

Les bits de poids fort de l’index CE va servir à la fois à compléter le préfixe IPv4 pour former une adresse IPv4 et les bits restants vont servir a restreindre les numéros de ports que le NAT de l’utilisateur peut utiliser en imposant les bits de poids fort (représentés xxxx sur le schéma suivant).



hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
S'il utilisent ce mécanisme (à confirmer avec les MTU peut-être, et éventuellement en faisant un grand nombre de connexions vers un serveur de test sur lequel on pourrait vérifier le port source), alors :
 - il faut de l'IPv6 natif à priori (ou du 6rd avec une adresse privée, mais ça ferait beaucoup d'encapsulation)
 - la limitation de vitesse en IPv4 pourrait provenir de la Freebox (cf https://lafibre.info/free-la-fibre/vrai-1gbps-sur-freebox-v6/msg281830/#msg281830, le checksum IPv6 doit être généré en software), plus que du réseau (où le A+P ne devrait pas être trop lourd à implèmenter)

mirtouf

  • Abonné Bbox fibre
  • *
  • Messages: 1 297
  • Chelles (77)
    • L'antre de la bête
Il a Free, il a intérêt à comprendre comment fonctionne le CGN maison pour ses trucs de geek.  ;D

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
Donc on peut vraiment s'assoir sur le mode bridge.

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
Donc on peut vraiment s'assoir sur le mode bridge.
Ou peut-être seulement en IPv6, avec une configuration assez complexe pour avoir l'IPv4 (exactement l'inverse de ce qu'on a aujourd'hui).

mirtouf

  • Abonné Bbox fibre
  • *
  • Messages: 1 297
  • Chelles (77)
    • L'antre de la bête
Il semblerait que le mode bridge devienne en effet de l'histoire ancienne ou alors soit plutôt délicat à configurer (encapsulation ?).
En ajoutant de possibles baisses de débit utile en IPv4, je remercie Free de mettre le paquet sur le déploiement IPv6.  :-X

underground78

  • Expert
  • Abonné Free fibre
  • *
  • Messages: 7 434
  • Orsay (91)
    • FreePON : suivi géographique du déploiement fibre EPON chez Free
En tout cas la RFC7600 (4rd) pointée par Marin semble être une supposition très valable. Peut-être que Darafaeli pourra confirmer ?