La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Actus fibre Free => Discussion démarrée par: cyberjuls le 22 juin 2016 à 14:57:40
-
C'est dispo !
(https://lafibre.info/images/free/201606_ipv4_full-stack_1.png)
-
Cool ! C'est la seule option disponible pour l'instant (rani parlait d'une option payante pour avoir plusieurs IPv4) ? Tiens nous au courant si tu l'actives en tout cas.
-
Pas le temps en ce moment, et je ne fais pas dans le plâtre ;)
Mais je le ferais c'est sûr.
-
Bon ben voilà...
C'est dispo depuis l'espace client.
L'attribution de l'IP est immédiate !
(https://lafibre.info/images/free/201606_ipv4_full-stack_1.png)
(https://lafibre.info/images/free/201606_ipv4_full-stack_2.png)
(https://lafibre.info/images/free/201606_ipv4_full-stack_3.jpg)
-
Je viens de faire la demande (installation pto que jeudi 30 mais je prends les devants).
Je passe de 91.160.29.xxx (ports 32768 à 49151) à 82.64.0.xxx
L'ipv6 ne change pas.
Pas de changement noté non plus au niveau de mon ip adsl (ouf ;))
-
C'est dispo !
Bon, bah tant mieux, il n'y a pas eu trop de retard. A voir maintenant si cela arrange quelques problèmes apparus à droite ou à gauche (ftp, connexion freewifi).
-
On peut dire que le ton est plutôt dissuasif, et fait pour qu'un minimum de personnes prennent l'option. On constate aussi que ce n'est pas une adresse IP dans le range 90.160, mais dans l'ancien 82.x.y.z, qui ne devrait pas poser de problème d'accès à Freewifi par exemple.
-
Je ne sais pas trop d'où sort cette plage, quand j'ai voulu faire un traceroute depuis mon serveur chez Online le routage était étrange donc rien ne dit qu'elle va fonctionner pour le Free Wifi immédiatement.
-
Tu as probablement eu accès à une adresse complète pour faire un traceroute ? Les plages commençant par 82 étaient me semble-t-il déjà utilisées ?
P.S : voir :
https://lafibre.info/ipv6/plages-ip-par-fai/
Free (AS12322) => 11 141 114 IPv4
...
82.64.0.0/14 AS12322 : Cogent, Tata (2) => 262 144 IPv4
82.224.0.0/11 AS12322 : Cogent (1) ! => 2 097 152 IPv4
-
Oui, oui, Free a beaucoup d'adresses IP en 82. mais la plage utilisée pour les IPs non partagées (82.64.0.0/14 à priori) provient probablement de la réutilisation d'IPs destinées aux non dégroupés voir même aux abonnés 56k. Il n'est pas évident qu'elles fassent partie des IPs déjà acceptées pour Free Wifi.
-
On peut dire que le ton est plutôt dissuasif, et fait pour qu'un minimum de personnes prennent l'option. On constate aussi que ce n'est pas une adresse IP dans le range 90.160, mais dans l'ancien 82.x.y.z, qui ne devrait pas poser de problème d'accès à Freewifi par exemple.
ben le systeme est clairement fait pour economiser des IP v4 et pousser un peu plus fort sur l'ipv6. La plupart des gens n'auront pas besoin de cette option, mais si tout le monde l'active comme un bennet, ca ruine un peu les efforts, donc oui faut l'activer si on en a le besoin.
-
On peut dire que le ton est plutôt dissuasif, et fait pour qu'un minimum de personnes prennent l'option. On constate aussi que ce n'est pas une adresse IP dans le range 90.160, mais dans l'ancien 82.x.y.z, qui ne devrait pas poser de problème d'accès à Freewifi par exemple.
Ils auraient mieux fait de parler de l'HADOPI, lol
-
Oui, oui, Free a beaucoup d'adresses IP en 82. mais la plage utilisée pour les IPs non partagées (82.64.0.0/14 à priori) provient probablement de la réutilisation d'IPs destinées aux non dégroupés voir même aux abonnés 56k. Il n'est pas évident qu'elles fassent partie des IPs déjà acceptées pour Free Wifi.
Du moment que l'IP permet d'identifier une Freebox, ça doit marcher.
Même pour ceux qui ont une IP partagée, ça devrait marcher si le site passait en IPv6.
-
Bonsoir, je me suis inscris sur ce forum pour bien comprendre l'intérêt d'obtenir une IP Fixe à usage unique dans ce contexte (Fibre en zone ZMD).
Je comprends, peut-être à tort, qu'avec mon ip actuelle (et donc partagée avec plusieurs clients Free) je m'expose à un risque potentiel si par exemple un de ses même clients télécharge des fichiers avec des méthodologies reconnues comme étant douteuses ?
Merci de vos éclaircissements.
Note : juste pour corroboer avec certains messages postés, je n'ai également pas accès à Freewifi via Freebox OS : adresse ip non reconnue
-
Non avec une IP partagée tu ne risque rien niveau HADOPI ou autre, car pour t'identifier en plus de ton IP le port est utilisé et ce port ne peut être utiliser par un des trois autres client Free qui partage ton IP.
Donc a moins d'avoir un serveur chez toi ou un usage bien spécifique il n'y a pas d'intérêt majeur à avoir une IP dédié pour toi.
-
Je comprends, peut-être à tort, qu'avec mon ip actuelle (et donc partagée avec plusieurs clients Free) je m'expose à un risque potentiel si par exemple un de ses même clients télécharge des fichiers avec des méthodologies reconnues comme étant douteuses ?
de ce que j'ai compris du fonctionnement d'Hadopi, justement avec l'ip partagée tu es protegé car Hadopi n'est pas capable a l'heure actuelle de savoir qui est le vilain telechargeur derriere l'ip en question....
-
Ok merci pour toutes vos réponses :)
-
Techniquement l'IP et le port ont été collectés lors de le détection d'un tipiaquage... mais juridiquement le port ne peut pas être utilisé!
C'est une situation juridique absurde qui sera probablement corrigée à l'avenir.
-
ben le systeme est clairement fait pour economiser des IP v4 et pousser un peu plus fort sur l'ipv6. La plupart des gens n'auront pas besoin de cette option, mais si tout le monde l'active comme un bennet, ca ruine un peu les efforts, donc oui faut l'activer si on en a le besoin.
Je le vois comme ça aussi. Un truc comme ça, ma mère qui n'en a pas besoin ne l'activera pas. Donc tout le monde est gagnant.
-
"full-stack" c'est plutôt curieux comme appellation même si je vois d'ou ca vient ca n'est pas très parlant quand même et pas un terme communèment utilisé quand on parle d'une adresse IP.
-
C'est pour que ça fasse un peu plus peur ! :P
-
Voilà, l'idée est d'être incompréhensible pour les non "geek".
-
Il serait intéressant de tester deux trucs avec ces IP "Full stack" :
Est-ce qu'on est toujours en collecte à Courbevoie ou est-ce du routage standard comme pour les clients en ZTD et a-t-on accès à tous les protocoles ou juste TCP/UDP mais avec tous les ports.
-
Est-ce qu'on est toujours en collecte à Courbevoie ou est-ce du routage standard comme pour les clients en ZTD et a-t-on accès à tous les protocoles ou juste TCP/UDP mais avec tous les ports.
Oui, actuellement le trafic entre 2 abonnés "ipfixe ZMD" va passer par un noeud central (Courbevoie) mais on va rajouter par la
suite d'autre passerelle s'il y a vraiment assez de trafic pour le justifier.
Et si vous envoyez assez de M&M, peut-être que les dev freebox se motiveront pour rajouter un cache de résolution
direct dans les boxes (pour que le trafic aille direct d'une box à une autre).
Pour ce qui est des protocoles, c'est openbar. C'est exactement pareil à l'usage qu'une IP fixe comme c'est le cas actuellement sur l'ADSL.
-
Tient, la plage n'est pas annoncé à Orange sur le PNI.
Donc elle n'est pas annoncé sur Hopus.
La plage Full-Stack: Toile-Libre => Liazo => Tata => Cogent => Free
noc0% mtr -rwc10 82.64.0.1
HOST: noc0.toile-libre.net Loss% Snt Last Avg Best Wrst StDev
1. ge-0-1-gw1-v501-cbv.toile-libre.net 0.0% 10 4.6 7.5 0.9 20.6 7.2
2. ge-0-1-cr2-v601-par.toile-libre.net 0.0% 10 5.0 8.6 1.8 20.6 5.8
3. 6k-1-v350-bourse-paris.infr.liazo.net 0.0% 10 1.8 4.1 1.5 7.0 2.0
4. ix-xe-5-0-1-320.thar1.PV0-Paris.as6453.net 0.0% 10 5.1 11.5 1.1 45.9 14.2
5. if-ae-6-4.tcore1.PG1-Paris.as6453.net 0.0% 10 2.2 13.3 1.9 38.6 12.8
6. if-ae-7-3.tcore1.PVU-Paris.as6453.net 0.0% 10 10.3 13.9 2.0 32.0 11.9
7. be6453.ccr21.par04.atlas.cogentco.com 0.0% 10 7.3 15.8 4.2 40.7 11.5
8. be12308.ccr41.par01.atlas.cogentco.com 10.0% 10 12.2 21.5 7.0 45.2 14.1
9. be2044.agr21.par01.atlas.cogentco.com 10.0% 10 45.7 28.0 2.5 48.1 18.6
10. oxeva.demarc.cogentco.com 0.0% 10 41.4 27.5 4.6 43.7 16.2
11. p11-crs16-1-be1000.intf.routers.proxad.net 10.0% 10 10.2 23.8 8.0 55.5 18.1
12. cbv-crs8-1.intf.routers.proxad.net 0.0% 10 35.0 17.9 2.6 53.6 17.0
13. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
18. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
19. lns-bzn-20-82-64-0-1.adsl.proxad.net 0.0% 9 48.1 26.3 15.4 48.1 11.3
noc0%
Une plage en IP4rd: Toile-Libre => Liazo => Hopus => Orange => Free:
noc0% mtr -rwc10 91.160.29.1
HOST: noc0.toile-libre.net Loss% Snt Last Avg Best Wrst StDev
1. ge-0-1-gw1-v501-cbv.toile-libre.net 0.0% 10 1.4 17.6 0.9 37.5 13.8
2. ge-0-1-cr2-v601-par.toile-libre.net 0.0% 10 24.4 28.8 4.8 86.9 24.0
3. liazo.th2-1.rt.hopus.net 0.0% 10 1.1 13.9 1.1 39.8 15.3
4. 193.253.13.205 10.0% 10 2.9 11.1 2.1 31.0 10.8
5. 193.253.13.66 0.0% 10 27.6 21.5 1.6 39.9 11.8
6. p11-crs16-1-be1012.intf.routers.proxad.net 0.0% 10 49.0 16.0 4.3 49.0 14.0
7. cbv-crs8-1.intf.routers.proxad.net 0.0% 10 23.8 14.2 2.2 25.8 8.9
8. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
noc0%
C'est la même histoire en partant d'Orange:
02:30:41 [nico@Lyoko:~] $ mtr -rwc10 82.64.0.1
Start: Thu Jun 23 02:32:22 2016
HOST: Lyoko.in.ByMe.at Loss% Snt Last Avg Best Wrst StDev
1.|-- Styx.WiFi.mrs.in.byme.at 0.0% 10 0.7 0.9 0.7 1.4 0.0
2.|-- AstriaPorta.vl100.mrs.in.byme.at 0.0% 10 0.9 1.1 0.9 1.8 0.0
3.|-- 80.10.121.143 0.0% 10 1.7 1.9 1.6 2.4 0.0
4.|-- 10.125.241.74 0.0% 10 1.7 2.0 1.4 3.5 0.3
5.|-- 193.252.161.29 0.0% 10 2.7 2.2 1.7 3.1 0.0
6.|-- 193.252.137.54 0.0% 10 18.8 15.1 11.1 19.1 2.6
7.|-- tengige0-4-0-13.auvtr1.Aubervilliers.opentransit.net 0.0% 10 15.6 14.0 11.3 15.9 1.3
8.|-- te0-0-0-19.rcr21.par05.atlas.cogentco.com 0.0% 10 11.6 11.9 11.5 12.6 0.0
9.|-- be2425.ccr42.par01.atlas.cogentco.com 0.0% 10 12.0 12.5 12.0 13.5 0.3
10.|-- be2140.agr21.par01.atlas.cogentco.com 0.0% 10 13.0 12.7 12.3 13.3 0.0
11.|-- oxeva.demarc.cogentco.com 0.0% 10 12.7 12.6 12.2 13.7 0.3
12.|-- p11-crs16-1-be1000.intf.routers.proxad.net 0.0% 10 19.4 16.0 11.6 19.4 2.5
13.|-- cbv-crs8-1.intf.routers.proxad.net 0.0% 10 12.3 12.8 12.2 14.0 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
18.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
19.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
20.|-- lns-bzn-20-82-64-0-1.adsl.proxad.net 0.0% 10 25.8 25.6 24.9 26.3 0.0
02:33:58 [nico@Lyoko:~] $ mtr -rwc10 91.160.29.1
Start: Thu Jun 23 02:35:35 2016
HOST: Lyoko.in.ByMe.at Loss% Snt Last Avg Best Wrst StDev
1.|-- Styx.WiFi.mrs.in.byme.at 0.0% 10 1.7 1.0 0.7 1.7 0.0
2.|-- AstriaPorta.vl100.mrs.in.byme.at 0.0% 10 1.0 1.1 0.9 1.3 0.0
3.|-- 80.10.121.143 0.0% 10 1.8 1.9 1.6 2.3 0.0
4.|-- 10.125.241.74 0.0% 10 2.2 2.1 1.5 3.0 0.0
5.|-- 193.252.101.122 0.0% 10 2.5 2.3 1.8 3.1 0.0
6.|-- 193.252.161.9 0.0% 10 11.6 11.4 10.7 12.2 0.0
7.|-- 193.252.99.106 0.0% 10 11.6 11.6 11.1 12.3 0.0
8.|-- 193.253.13.70 0.0% 10 12.3 12.4 12.0 13.1 0.0
9.|-- bzn-crs16-2-be1013.intf.routers.proxad.net 0.0% 10 13.6 16.6 13.5 19.5 2.1
10.|-- bzn-crs16-2-be1005.routers.proxad.net 0.0% 10 12.5 12.6 12.0 13.5 0.0
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
02:37:51 [nico@Lyoko:~] $
-
Oui, actuellement le trafic entre 2 abonnés "ipfixe ZMD" va passer par un noeud central (Courbevoie) mais on va rajouter par la
suite d'autre passerelle s'il y a vraiment assez de trafic pour le justifier.
Donc malgré l'utilisation du terme "full stack", ça reste de l'IPv4 au dessus d'IPv6, et pas du dual stack ?
Ce n'est peut-être plus un problème maintenant, mais il me semble que les tests des premiers connectés mettaient en évidence quelques problèmes de performance.
-
@thenico : J'ai signalé le même genre de soucis à mikmak, l'admin réseau d'Online, ça ne passe pas par le PNI entre Online et Free mais par Cogent.
@hwti : Il ne me semble pas que des problèmes de performance persistent (en fait je ne suis pas complètement sûr que des problèmes liés de performance dus au 4rd aient existé).
-
Donc malgré l'utilisation du terme "full stack", ça reste de l'IPv4 au dessus d'IPv6, et pas du dual stack ?
Ce n'est peut-être plus un problème maintenant, mais il me semble que les tests des premiers connectés mettaient en évidence quelques problèmes de performance.
Une baisse du MTU également qui dois toujours être présent.
Maintenant baisser la MTU, si les MSS de chaque paquet [SYN] est modifié à la volée par la box, cela ne devrait pas poser de problème.
Dans le passé, les clients non dégroupés avaient eux aussi un MTU plus faible (il me semble que les clients non dégroupés sont passés sur une collecte Ethernet, donc la MTU en non dégroupé devrait être maintenant à 1500, chez les FAI qui ont suivit les reco d'Orange)
Oui, actuellement le trafic entre 2 abonnés "ipfixe ZMD" va passer par un noeud central (Courbevoie) mais on va rajouter par la
suite d'autre passerelle s'il y a vraiment assez de trafic pour le justifier.
Des passerelles en région seraient un plus, pour bénéficier des peering de Free en région (cela concerne surtout les abonnés du sud-est de la France qui pourront joindre les clients Free / Orange / SFR du sud-est directement via Lyon, sans passer par Paris).
-
Il ne me semble pas que des problèmes de performance persistent (en fait je ne suis pas complètement sûr que des problèmes liés de performance dus au 4rd aient existé).
Il me semble que cyberjuls avait des débits IPv4 bien inférieurs à l'IPv6.
-
Une baisse du MTU également qui dois toujours être présent.
Il n'y a pas de baisse de MTU normalement, Free utilise des jumbo frames sur son architecture 4rd pour conserver la même MTU en IPv4.
-
Si un abonné pouvais comparer le débit entre :
- http://ping.online.net/5000Mo.dat (IPv4)
- http://ping6.online.net/5000Mo.dat (IPv6)
Ligne de commande sous Linux pour ne pas utiliser le disque dur :
- wget -O /dev/null http://ping.online.net/5000Mo.dat
- wget -O /dev/null http://ping6.online.net/5000Mo.dat
-
Si un abonné pouvais comparer le débit entre :
- http://ping.online.net/5000Mo.dat (IPv4)
- http://ping6.online.net/5000Mo.dat (IPv6)
Ligne de commande sous Linux pour ne pas utiliser le disque dur :
- wget -O /dev/null http://ping.online.net/5000Mo.dat
- wget -O /dev/null http://ping6.online.net/5000Mo.dat
Débit quasi équivalent :
$ wget -O /dev/null http://ping.online.net/5000Mo.dat => 105MB/s
$ wget -O /dev/null http://ping6.online.net/5000Mo.dat => 107MB/s
-
Maintenant que ça fait quelques heures que tu as validé la demande d'une IP V4 full-stack, tu peux me confirmer que ça n'a eu aucun impact sur ta connexion ADSL ? Sait-on jamais...
Je viens de faire la demande (installation pto que jeudi 30 mais je prends les devants).
Je passe de 91.160.29.xxx (ports 32768 à 49151) à 82.64.0.xxx
L'ipv6 ne change pas.
Pas de changement noté non plus au niveau de mon ip adsl (ouf ;))
-
Aucune chance que ça ne fasse quoi que ce soit.
-
Enfin, en voilà une bonne nouvelle (je parle de l'option IP fixe) !
Cela n’empêche, je me demande toujours s'il est possible d'utiliser IPsec si on est en port partagé avec des ports > 16K. En gros si les routeurs qui gèrent le partage de port sont suffisamment "intelligent" pour rediriger l'ESP en fonction des requêtes initiaux sur les ports UDP 500/4500. Pour le coup si le télétravail est amené à se développer et que l'entreprise utilise IPsec en IPv4, cela peut être problématique si beaucoup d'utilisateurs (pas forcement technique) n'arrivent pas à se connecter à leur boite. Et pour le coup des boites qui bannissent IPv6 cela existe.
Même question pour GRE et tout autre protocole IP. Les routeurs arrivent t'ils à rediriger le flux en fonction uniquement des IP src/dest si une connexion part de la box ?
-
Oui, cf le message de Rani :)
-
Oui, ça j'ai compris qu'en IP fixe ça fonctionne, merci.
Je suis plutôt curieux de savoir si ça fonctionne dans le cas inverse, avec 1/4 des ports et même ports > 16k..
-
ça ne marche pas. GRE et autres consorts sont bloqués
-
Tient, la plage n'est pas annoncé à Orange sur le PNI.
Donc elle n'est pas annoncé sur Hopus.
Chez Online ça passe par le PNI maintenant, à voir si c'est réglé pour le Orange aussi.
-
Maintenant que ça fait quelques heures que tu as validé la demande d'une IP V4 full-stack, tu peux me confirmer que ça n'a eu aucun impact sur ta connexion ADSL ? Sait-on jamais...
Aucun impact mais j'ai aussi pris les devant en autorisant ma nouvelle ip sur les machines sur lesquelles je me connecte et qui verrouillées sur l'ip. En entrée mon ftp est toujours ok.
-
Chez Online ça passe par le PNI maintenant, à voir si c'est réglé pour le Orange aussi.
noc0% mtr -rwc10 82.64.0.1
HOST: noc0.toile-libre.net Loss% Snt Last Avg Best Wrst StDev
1. ge-0-1-gw1-v501-cbv.toile-libre.net 0.0% 10 2.0 1.5 0.7 4.6 1.3
2. ge-0-1-cr2-v601-par.toile-libre.net 0.0% 10 8.1 3.0 1.2 8.1 1.9
3. liazo.th2-1.rt.hopus.net 0.0% 10 1.9 4.1 1.3 11.0 3.7
4. 193.253.13.205 0.0% 10 3.9 2.0 1.2 3.9 1.0
5. 193.253.13.66 0.0% 10 1.6 2.3 1.4 7.5 1.8
6. p11-crs16-1-be1012.intf.routers.proxad.net 0.0% 10 3.4 5.6 2.0 9.7 2.7
7. cbv-crs8-1.intf.routers.proxad.net 0.0% 10 2.0 2.1 1.8 3.0 0.4
8. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14. lns-bzn-20-82-64-0-1.adsl.proxad.net 0.0% 10 15.3 15.2 14.5 19.0 1.3
C'est corrigé.
-
ça ne marche pas. GRE et autres consorts sont bloqués
Si, le GRE est censé passer quand il est établi derrière une v6 en mode NAT.
-
Une baisse du MTU également qui dois toujours être présent.
Non, la MTU est à 1500 côté client. Comme dit précédemment, on transporte en jumbo.
-
Si, le GRE est censé passer quand il est établi derrière une v6 en mode NAT.
Euh, avec une IP partagée en 4Rd, GRE ne marche pas, un client avait testé ici même, mais à l'époque, l'option pour l'IPv4 Full Stack n'existait pas.
Je suis plutôt curieux de savoir si ça fonctionne dans le cas inverse, avec 1/4 des ports et même ports > 16k..
-
Si, le GRE est censé passer quand il est établi derrière une v6 en mode NAT.
C'est bien ce que je pensais. Je suppose qu'il en est de même pour tout autre protocole (ESP par exemple, avec l'aide d'un module qui track les ports UDP 500 & 4500).
Cela semble complètement logique et cohérent.
Bref, en gros à part pour l'auto-hébergement et pour les systèmes "bizarres" qui nécessitent que de l'IPv4 et des redirections de ports fixes comme des .... porcs (PS4 ? Xbox ? je connais pas mais au vu des forums le partage de ports semble problématique avec ces trucs là) il n'y a pas grand intérêt.
A voir après s'il n'y a pas aussi possibilité d'avoir une option pour simplement demander le premier quart de ports en mode "premier demandé, premier servis". Genre si quelqu'un demande le premier quart, et que personne d'autre sur son IP ne le demande, il récupère et garde son premier quart ad-vitaem (quitte à ce qu'une autre personne sur la même IP récupère le quart de ports abandonné). Et si quelqu'un demande le premier quart mais qu'un autre avec la même IP a déjà activé sa demande, option 1: l'option est grisée et impossible à activer et donc il reste le full-stack only, option 2: on propose une nouvelle IP partagée, mais avec le premier quart de port.
Voir même étendre la demande au quart de son choix... Ceux n'ayant cure de leurs ports se retrouvant avec le quart de libre.
Perso je pense que cela permettrait d'économiser des IPv4 ET cela serait suffisant si on se contente d'auto-héberger des services avec ports < 16k.
Bon OK, maintenant que l'option IP full-range est dispo, cela reviendrait à chacun de prendre ses responsabilités envers cette ressource rare qu'est l'IPv4. Mais bon...
-
Bref, en gros à part pour l'auto-hébergement et pour les systèmes "bizarres" qui nécessitent que de l'IPv4 et des redirections de ports fixes comme des .... porcs (PS4 ? Xbox ? je connais pas mais au vu des forums le partage de ports semble problématique avec ces trucs là) il n'y a pas grand intérêt.
[....]
Bon OK, maintenant que l'option IP full-range est dispo, cela reviendrait à chacun de prendre ses responsabilités envers cette ressource rare qu'est l'IPv4. Mais bon...
Oui. C'est surtout avec la Xbox qu'il semble y avoir pas mal de soucis. Et çà risque de faire pas mal de personnes à court terme en ZMD FTTH Free avec une xbox.
Pour Free, ils en ont des IPs, je pense que même si ils en économisent que "modérèment" et pas au maximum, çà leur suffira amplement.
Les DSLAMs vont se vider au fur et à mesure. c'est "critique" quand les DSLAM commencent à peine à se vider, mais par la suite, çà ira.
-
C'est bien ce que je pensais. Je suppose qu'il en est de même pour tout autre protocole (ESP par exemple, avec l'aide d'un module qui track les ports UDP 500 & 4500).
Cela semble complètement logique et cohérent.
Si vous avez suivi on "partage" une ipv4 avec plusieurs freebox, mais en mode bridge la freebox envoie cette ipv4 global unicast (publique pour simplifier) et rien d'autre. Donc pour NATer sans savoir les ports => pas possible, faire du GRE, IPSEC, etc... impossible.
=> FTTH Free et partage d'ip + mode bridge = c'est la war (https://lafibre.info/installation-free/ftth-free-et-partage-dip-mode-bridge-cest-la-war/)
-
C'est bien ce que je pensais. Je suppose qu'il en est de même pour tout autre protocole (ESP par exemple, avec l'aide d'un module qui track les ports UDP 500 & 4500).
Cela semble complètement logique et cohérent.
Non, non, j'ai parlé que du GRE. L'ipsec c'est une autre paire de manches. Ca marche déjà de justesse derrière un NAT normal; ça a bcps de mal si on essaie
de monter plus de 2 tunnels à la fois...
Actuellement, les seuls "helpers" qui existent avec notre solution sont pour certains messages ICMP + tunnels GRE (et donc pour PPTP aussi ça marche).
Il reste aussi à gérer les paquets IP fragmentés, c'est sur la todo liste car je vois quand même un peu de trafic de ce style...
-
On constate aussi que ce n'est pas une adresse IP dans le range 90.160, mais dans l'ancien 82.x.y.z, qui ne devrait pas poser de problème d'accès à Freewifi par exemple.
Comme prévu ça ne change rien pour FreeWifi : https://lafibre.info/free-10g-epon/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg350387/#msg350387.
-
J'ai testé, le VPN intégré à la Freebox est de nouveau fonctionnel avec une IP complète. Même plage IP que les autres.
-
Oui. C'est surtout avec la Xbox qu'il semble y avoir pas mal de soucis. Et çà risque de faire pas mal de personnes à court terme en ZMD FTTH Free avec une xbox.
Pour Free, ils en ont des IPs, je pense que même si ils en économisent que "modérèment" et pas au maximum, çà leur suffira amplement.
Les DSLAMs vont se vider au fur et à mesure. c'est "critique" quand les DSLAM commencent à peine à se vider, mais par la suite, çà ira.
Bonjour, justement moi mon soucis est que depuis que j'ai mis mon ip fixe en full stack ma xbox one a un ping trop elevé pour que je puisse jouer en ligne correctement. Quelqu'un aurait la solution ?
-
C'est combien de plus qu'en IPv6?
-
C'est une info intéressante ça. Est-ce que cela signifiait qu'en IPv4 full-stack, le traffic IPv4 serait routé (via 4in6) depuis un routeur plus "éloigné" que ceux qui font du quart d'IP ?
-
En supposant que ça ne soit pas une coïncidence (par exemple panne temporaire sur une interconnexion avec Microsoft), on pourrait supposer que la plage d'adresses IP utilisée pour les IP "full stack" n'est pas routée pareille que la plage des IP partagées. Pour savoir si c'est réellement ça il faudrait comparer un traceroute fait par une personne en IP "full stack" avec celui fait par une personne en IP partagée.
-
+1
Idéalement, il faudrait même un traceroute de la même personne vers la même IP avant et après son passage en full-stack, vu que les points de sortie de l'IPv4 peuvent être très différent suivant le lieu/secteur ou l'on habite.
Après, rien n’empêche de trouver un tunnel broker supportant le 4in6 (pfffff, que je déteste les couches d'encapsulation...).
-
+1
Idéalement, il faudrait même un traceroute de la même personne vers la même IP avant et après son passage en full-stack, vu que les points de sortie de l'IPv4 peuvent être très différent suivant le lieu/secteur ou l'on habite.
Non, dans tous les cas tu sors à CBV.
Et le traceroute est identique dans le réseau Free, par contre côté routage chez les transitaires c'est pas annoncé pareil et c'est de là que viennent les différences.