Pour ceux coincés chez un ISP français qui ne fournit pas ipv6 (et
n'envisage pas de le faire au vu de l'absence de retour sur les enquêtes
clients), quelles options va-t-il rester (HE ?)
Pour ceux coincés chez un ISP français qui ne fournit pas ipv6 (et
n'envisage pas de le faire au vu de l'absence de retour sur les enquêtes
clients), quelles options va-t-il rester (HE ?)
Pour ceux coincés chez un ISP français qui ne fournit pas ipv6 (et
n'envisage pas de le faire au vu de l'absence de retour sur les enquêtes
clients), quelles options va-t-il rester (HE ?)
Sinon, tu peux aussi prendre un hébergement bon marché (hetzner,
OVH) et bridger le /64 ou plus via OpenVPN tap ou évt.
du routage tun ou un tunnel ipip si tu as plus qu'un /64. Si
le fournisseur n'est pas trop loin, la performance ne sera pas
trop dégradée. En plus, il y aura une petite baisse du MTU,
qui ne devrait pas poser de problème, en particulier si tu
ajoutes une option de MSS clamping.
En Suisse, on a de la chance: même en ADSL tu peux avoir de l'IPv6
natif
Sinon, tu peux aussi prendre un hébergement bon marché (hetzner,
OVH) et bridger le /64 ou plus via OpenVPN tap ou évt.
du routage tun ou un tunnel ipip si tu as plus qu'un /64. Si
le fournisseur n'est pas trop loin, la performance ne sera pas
trop dégradée. En plus, il y aura une petite baisse du MTU,
qui ne devrait pas poser de problème, en particulier si tu
ajoutes une option de MSS clamping.
En Suisse, on a de la chance: même en ADSL tu peux avoir de l'IPv6
natif
Sinon, tu peux aussi prendre un hébergement bon marché (hetzner,
OVH) et bridger le /64 ou plus via OpenVPN tap ou évt.
du routage tun ou un tunnel ipip si tu as plus qu'un /64. Si
le fournisseur n'est pas trop loin, la performance ne sera pas
trop dégradée. En plus, il y aura une petite baisse du MTU,
qui ne devrait pas poser de problème, en particulier si tu
ajoutes une option de MSS clamping.
En Suisse, on a de la chance: même en ADSL tu peux avoir de l'IPv6
natif
Le 28/03/2017 à 21:40, Marc SCHAEFER a écrit :Sinon, tu peux aussi prendre un hébergement bon marché (hetzner,
OVH) et bridger le /64 ou plus via OpenVPN tap ou évt.
du routage tun ou un tunnel ipip si tu as plus qu'un /64. Si
le fournisseur n'est pas trop loin, la performance ne sera pas
trop dégradée. En plus, il y aura une petite baisse du MTU,
qui ne devrait pas poser de problème, en particulier si tu
ajoutes une option de MSS clamping.
Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
En Suisse, on a de la chance: même en ADSL tu peux avoir de l'IPv6
natif
En France aussi. Ce n'est pas de la chance, c'est normal. C'est
l'inverse qui devrait être considéré comme anormal de nos jours.
Le 28/03/2017 à 21:40, Marc SCHAEFER a écrit :
Sinon, tu peux aussi prendre un hébergement bon marché (hetzner,
OVH) et bridger le /64 ou plus via OpenVPN tap ou évt.
du routage tun ou un tunnel ipip si tu as plus qu'un /64. Si
le fournisseur n'est pas trop loin, la performance ne sera pas
trop dégradée. En plus, il y aura une petite baisse du MTU,
qui ne devrait pas poser de problème, en particulier si tu
ajoutes une option de MSS clamping.
Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
En Suisse, on a de la chance: même en ADSL tu peux avoir de l'IPv6
natif
En France aussi. Ce n'est pas de la chance, c'est normal. C'est
l'inverse qui devrait être considéré comme anormal de nos jours.
Le 28/03/2017 à 21:40, Marc SCHAEFER a écrit :Sinon, tu peux aussi prendre un hébergement bon marché (hetzner,
OVH) et bridger le /64 ou plus via OpenVPN tap ou évt.
du routage tun ou un tunnel ipip si tu as plus qu'un /64. Si
le fournisseur n'est pas trop loin, la performance ne sera pas
trop dégradée. En plus, il y aura une petite baisse du MTU,
qui ne devrait pas poser de problème, en particulier si tu
ajoutes une option de MSS clamping.
Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
En Suisse, on a de la chance: même en ADSL tu peux avoir de l'IPv6
natif
En France aussi. Ce n'est pas de la chance, c'est normal. C'est
l'inverse qui devrait être considéré comme anormal de nos jours.
Pascal Hambourg écrivait :Le 28/03/2017 à 21:40, Marc SCHAEFER a écrit :Sinon, tu peux aussi prendre un hébergement bon marché (hetzner,
OVH) et bridger le /64 ou plus via OpenVPN tap ou évt.
du routage tun ou un tunnel ipip si tu as plus qu'un /64. Si
le fournisseur n'est pas trop loin, la performance ne sera pas
trop dégradée. En plus, il y aura une petite baisse du MTU,
qui ne devrait pas poser de problème, en particulier si tu
ajoutes une option de MSS clamping.
Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
Comment tu modifies le MTU IPv6 sans modifier celui de l'IPv4 ? De plus
si tu dépends de tunnels chez ton fournisseur tu ne sais pas comment ça
doit marcher.
En Suisse, on a de la chance: même en ADSL tu peux avoir de l'IPv6
natif
En France aussi. Ce n'est pas de la chance, c'est normal. C'est
l'inverse qui devrait être considéré comme anormal de nos jours.
On a de l'IPv6. Natif c'est pas toujours le cas.
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Le 28/03/2017 à 21:40, Marc SCHAEFER a écrit :
Sinon, tu peux aussi prendre un hébergement bon marché (hetzner,
OVH) et bridger le /64 ou plus via OpenVPN tap ou évt.
du routage tun ou un tunnel ipip si tu as plus qu'un /64. Si
le fournisseur n'est pas trop loin, la performance ne sera pas
trop dégradée. En plus, il y aura une petite baisse du MTU,
qui ne devrait pas poser de problème, en particulier si tu
ajoutes une option de MSS clamping.
Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
Comment tu modifies le MTU IPv6 sans modifier celui de l'IPv4 ? De plus
si tu dépends de tunnels chez ton fournisseur tu ne sais pas comment ça
doit marcher.
En Suisse, on a de la chance: même en ADSL tu peux avoir de l'IPv6
natif
En France aussi. Ce n'est pas de la chance, c'est normal. C'est
l'inverse qui devrait être considéré comme anormal de nos jours.
On a de l'IPv6. Natif c'est pas toujours le cas.
Pascal Hambourg écrivait :Le 28/03/2017 à 21:40, Marc SCHAEFER a écrit :Sinon, tu peux aussi prendre un hébergement bon marché (hetzner,
OVH) et bridger le /64 ou plus via OpenVPN tap ou évt.
du routage tun ou un tunnel ipip si tu as plus qu'un /64. Si
le fournisseur n'est pas trop loin, la performance ne sera pas
trop dégradée. En plus, il y aura une petite baisse du MTU,
qui ne devrait pas poser de problème, en particulier si tu
ajoutes une option de MSS clamping.
Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
Comment tu modifies le MTU IPv6 sans modifier celui de l'IPv4 ? De plus
si tu dépends de tunnels chez ton fournisseur tu ne sais pas comment ça
doit marcher.
En Suisse, on a de la chance: même en ADSL tu peux avoir de l'IPv6
natif
En France aussi. Ce n'est pas de la chance, c'est normal. C'est
l'inverse qui devrait être considéré comme anormal de nos jours.
On a de l'IPv6. Natif c'est pas toujours le cas.
Le Wed, 29 Mar 2017 08:19:13 +0200,
Erwan David écrivait :Pascal Hambourg écrivait :Le 28/03/2017 à 21:40, Marc SCHAEFER a écrit :Sinon, tu peux aussi prendre un hébergement bon marché (hetzner,
OVH) et bridger le /64 ou plus via OpenVPN tap ou évt.
du routage tun ou un tunnel ipip si tu as plus qu'un /64. Si
le fournisseur n'est pas trop loin, la performance ne sera pas
trop dégradée. En plus, il y aura une petite baisse du MTU,
qui ne devrait pas poser de problème, en particulier si tu
ajoutes une option de MSS clamping.
Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
Comment tu modifies le MTU IPv6 sans modifier celui de l'IPv4 ? De plus
si tu dépends de tunnels chez ton fournisseur tu ne sais pas comment ça
doit marcher.
Et certains fournisseurs (coucou Nerim) utilisent des MTU
folkloriques sans permettre à l'ICMP6 de passer. Trous noirs de MTU
en perspective...
Le Wed, 29 Mar 2017 08:19:13 +0200,
Erwan David <erwan@rail.eu.org> écrivait :
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Le 28/03/2017 à 21:40, Marc SCHAEFER a écrit :
Sinon, tu peux aussi prendre un hébergement bon marché (hetzner,
OVH) et bridger le /64 ou plus via OpenVPN tap ou évt.
du routage tun ou un tunnel ipip si tu as plus qu'un /64. Si
le fournisseur n'est pas trop loin, la performance ne sera pas
trop dégradée. En plus, il y aura une petite baisse du MTU,
qui ne devrait pas poser de problème, en particulier si tu
ajoutes une option de MSS clamping.
Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
Comment tu modifies le MTU IPv6 sans modifier celui de l'IPv4 ? De plus
si tu dépends de tunnels chez ton fournisseur tu ne sais pas comment ça
doit marcher.
Et certains fournisseurs (coucou Nerim) utilisent des MTU
folkloriques sans permettre à l'ICMP6 de passer. Trous noirs de MTU
en perspective...
Le Wed, 29 Mar 2017 08:19:13 +0200,
Erwan David écrivait :Pascal Hambourg écrivait :Le 28/03/2017 à 21:40, Marc SCHAEFER a écrit :Sinon, tu peux aussi prendre un hébergement bon marché (hetzner,
OVH) et bridger le /64 ou plus via OpenVPN tap ou évt.
du routage tun ou un tunnel ipip si tu as plus qu'un /64. Si
le fournisseur n'est pas trop loin, la performance ne sera pas
trop dégradée. En plus, il y aura une petite baisse du MTU,
qui ne devrait pas poser de problème, en particulier si tu
ajoutes une option de MSS clamping.
Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
Comment tu modifies le MTU IPv6 sans modifier celui de l'IPv4 ? De plus
si tu dépends de tunnels chez ton fournisseur tu ne sais pas comment ça
doit marcher.
Et certains fournisseurs (coucou Nerim) utilisent des MTU
folkloriques sans permettre à l'ICMP6 de passer. Trous noirs de MTU
en perspective...
Erwan David écrivait :Pascal Hambourg écrivait :Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
Comment tu modifies le MTU IPv6 sans modifier celui de l'IPv4 ?
si tu dépends de tunnels chez ton fournisseur tu ne sais pas comment ça
doit marcher.
Et certains fournisseurs (coucou Nerim) utilisent des MTU
folkloriques sans permettre à l'ICMP6 de passer. Trous noirs de MTU
en perspective...
En Suisse, on a de la chance: même en ADSL tu peux avoir de l'IPv6
natif
En France aussi. Ce n'est pas de la chance, c'est normal. C'est
l'inverse qui devrait être considéré comme anormal de nos jours.
On a de l'IPv6. Natif c'est pas toujours le cas.
Erwan David <erwan@rail.eu.org> écrivait :
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
Comment tu modifies le MTU IPv6 sans modifier celui de l'IPv4 ?
si tu dépends de tunnels chez ton fournisseur tu ne sais pas comment ça
doit marcher.
Et certains fournisseurs (coucou Nerim) utilisent des MTU
folkloriques sans permettre à l'ICMP6 de passer. Trous noirs de MTU
en perspective...
En Suisse, on a de la chance: même en ADSL tu peux avoir de l'IPv6
natif
En France aussi. Ce n'est pas de la chance, c'est normal. C'est
l'inverse qui devrait être considéré comme anormal de nos jours.
On a de l'IPv6. Natif c'est pas toujours le cas.
Erwan David écrivait :Pascal Hambourg écrivait :Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
Comment tu modifies le MTU IPv6 sans modifier celui de l'IPv4 ?
si tu dépends de tunnels chez ton fournisseur tu ne sais pas comment ça
doit marcher.
Et certains fournisseurs (coucou Nerim) utilisent des MTU
folkloriques sans permettre à l'ICMP6 de passer. Trous noirs de MTU
en perspective...
En Suisse, on a de la chance: même en ADSL tu peux avoir de l'IPv6
natif
En France aussi. Ce n'est pas de la chance, c'est normal. C'est
l'inverse qui devrait être considéré comme anormal de nos jours.
On a de l'IPv6. Natif c'est pas toujours le cas.
Le 29/03/2017 à 09:10, JKB a écrit :Erwan David écrivait :Pascal Hambourg écrivait :Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
Comment tu modifies le MTU IPv6 sans modifier celui de l'IPv4 ?
Linux a un paramètre (sysctl) MTU spécifique pour l'IPv6.
net.ipv6.conf.<interface>.mtu
Exemple sur cette machine :
$ ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 (...)
$ /sbin/sysctl net.ipv6.conf.eth0.mtu
net.ipv6.conf.eth0.mtu = 1446si tu dépends de tunnels chez ton fournisseur tu ne sais pas comment ça
doit marcher.
Tu peux définir une valeur de MTU sur le LAN assez basse pour que ça
passe partout sans fragmenter.Et certains fournisseurs (coucou Nerim) utilisent des MTU
folkloriques sans permettre à l'ICMP6 de passer. Trous noirs de MTU
en perspective...
Peux-tu expliciter ?
Ici les paquets IPv6 (ICMPv6 et autres) de 1500 octets passent.
Il y a bien un trou noir de MTU, mais ce n'est pas lié à l'IPv6 ; c'est
dû à l'encapsulation PPPoE avec les paquets de plus de 1492 octets quand
on ne peut pas utiliser des trames ethernet de 1500 octets. Je viens de
me faire suer à bidouiller le firmware d'une vieille Neufbox et les
drivers ethernet du routeur Linux pour gérer les trames ethernet de 1508
octets, ainsi je peux avoir une MTU à 1500 sur le lien PPP et pas de
trou noir avec PPPoE.
Pas trou noir de MTU quand on utilise une encapsulation PPPoA.
Le 29/03/2017 à 09:10, JKB a écrit :
Erwan David <erwan@rail.eu.org> écrivait :
Pascal Hambourg <pascal@plouf.fr.eu.org> écrivait :
Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
Comment tu modifies le MTU IPv6 sans modifier celui de l'IPv4 ?
Linux a un paramètre (sysctl) MTU spécifique pour l'IPv6.
net.ipv6.conf.<interface>.mtu
Exemple sur cette machine :
$ ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 (...)
$ /sbin/sysctl net.ipv6.conf.eth0.mtu
net.ipv6.conf.eth0.mtu = 1446
si tu dépends de tunnels chez ton fournisseur tu ne sais pas comment ça
doit marcher.
Tu peux définir une valeur de MTU sur le LAN assez basse pour que ça
passe partout sans fragmenter.
Et certains fournisseurs (coucou Nerim) utilisent des MTU
folkloriques sans permettre à l'ICMP6 de passer. Trous noirs de MTU
en perspective...
Peux-tu expliciter ?
Ici les paquets IPv6 (ICMPv6 et autres) de 1500 octets passent.
Il y a bien un trou noir de MTU, mais ce n'est pas lié à l'IPv6 ; c'est
dû à l'encapsulation PPPoE avec les paquets de plus de 1492 octets quand
on ne peut pas utiliser des trames ethernet de 1500 octets. Je viens de
me faire suer à bidouiller le firmware d'une vieille Neufbox et les
drivers ethernet du routeur Linux pour gérer les trames ethernet de 1508
octets, ainsi je peux avoir une MTU à 1500 sur le lien PPP et pas de
trou noir avec PPPoE.
Pas trou noir de MTU quand on utilise une encapsulation PPPoA.
Le 29/03/2017 à 09:10, JKB a écrit :Erwan David écrivait :Pascal Hambourg écrivait :Le clamping de MSS ne marche que sur TCP, par définition. De plus il
est facile de limiter la MTU IPv6 sur le réseau local, donc le
clamping n'est pas franchement utile.
Comment tu modifies le MTU IPv6 sans modifier celui de l'IPv4 ?
Linux a un paramètre (sysctl) MTU spécifique pour l'IPv6.
net.ipv6.conf.<interface>.mtu
Exemple sur cette machine :
$ ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 (...)
$ /sbin/sysctl net.ipv6.conf.eth0.mtu
net.ipv6.conf.eth0.mtu = 1446si tu dépends de tunnels chez ton fournisseur tu ne sais pas comment ça
doit marcher.
Tu peux définir une valeur de MTU sur le LAN assez basse pour que ça
passe partout sans fragmenter.Et certains fournisseurs (coucou Nerim) utilisent des MTU
folkloriques sans permettre à l'ICMP6 de passer. Trous noirs de MTU
en perspective...
Peux-tu expliciter ?
Ici les paquets IPv6 (ICMPv6 et autres) de 1500 octets passent.
Il y a bien un trou noir de MTU, mais ce n'est pas lié à l'IPv6 ; c'est
dû à l'encapsulation PPPoE avec les paquets de plus de 1492 octets quand
on ne peut pas utiliser des trames ethernet de 1500 octets. Je viens de
me faire suer à bidouiller le firmware d'une vieille Neufbox et les
drivers ethernet du routeur Linux pour gérer les trames ethernet de 1508
octets, ainsi je peux avoir une MTU à 1500 sur le lien PPP et pas de
trou noir avec PPPoE.
Pas trou noir de MTU quand on utilise une encapsulation PPPoA.
Chez Nerim, ils jouent avec PPPoE et PPPoA selon les humeurs du jour
(je suis en dégroupé Nerim, c'est moins pire que le dégroupage SFR).
Bref, côté PPPoA, j'ai une MTU classique de 1500 pour l'IPv4.
Mais
attention, en IPv6, ça ne passe pas. Pas d'ICMP6 en réponse, rien.
Bizarrement, avec une MTU de 1492, ça passe. Mon modem est un ZyXEL.
Tiens, tant qu'on parle de cela. Est-ce que tu as vu une évolution
récente dans le noyau Linux ? Il y a longtemps, lorsque toutes
les lignes étaient en PPPoE sur mon vieil Alcatel plafonnant à 512 kbps,
j'étais obligé de coller sur toutes les
machines du LAN des MTU à 1492 pour que ça fonctionne normalement.
Puis toutes mes lignes ayant été passées en PPPoA et j'ai laissé partout
les MTU à 1500. Aujourd'hui, j'ai dû repasser une ligne en PPPoE,
donc avec une MTU de 1492 et cela fonctionne parfaitement avec une MTU de
1500 côté LAN. Le noyau a-t-il enfin le droit de fragmenter les paquets ?
Chez Nerim, ils jouent avec PPPoE et PPPoA selon les humeurs du jour
(je suis en dégroupé Nerim, c'est moins pire que le dégroupage SFR).
Bref, côté PPPoA, j'ai une MTU classique de 1500 pour l'IPv4.
Mais
attention, en IPv6, ça ne passe pas. Pas d'ICMP6 en réponse, rien.
Bizarrement, avec une MTU de 1492, ça passe. Mon modem est un ZyXEL.
Tiens, tant qu'on parle de cela. Est-ce que tu as vu une évolution
récente dans le noyau Linux ? Il y a longtemps, lorsque toutes
les lignes étaient en PPPoE sur mon vieil Alcatel plafonnant à 512 kbps,
j'étais obligé de coller sur toutes les
machines du LAN des MTU à 1492 pour que ça fonctionne normalement.
Puis toutes mes lignes ayant été passées en PPPoA et j'ai laissé partout
les MTU à 1500. Aujourd'hui, j'ai dû repasser une ligne en PPPoE,
donc avec une MTU de 1492 et cela fonctionne parfaitement avec une MTU de
1500 côté LAN. Le noyau a-t-il enfin le droit de fragmenter les paquets ?
Chez Nerim, ils jouent avec PPPoE et PPPoA selon les humeurs du jour
(je suis en dégroupé Nerim, c'est moins pire que le dégroupage SFR).
Bref, côté PPPoA, j'ai une MTU classique de 1500 pour l'IPv4.
Mais
attention, en IPv6, ça ne passe pas. Pas d'ICMP6 en réponse, rien.
Bizarrement, avec une MTU de 1492, ça passe. Mon modem est un ZyXEL.
Tiens, tant qu'on parle de cela. Est-ce que tu as vu une évolution
récente dans le noyau Linux ? Il y a longtemps, lorsque toutes
les lignes étaient en PPPoE sur mon vieil Alcatel plafonnant à 512 kbps,
j'étais obligé de coller sur toutes les
machines du LAN des MTU à 1492 pour que ça fonctionne normalement.
Puis toutes mes lignes ayant été passées en PPPoA et j'ai laissé partout
les MTU à 1500. Aujourd'hui, j'ai dû repasser une ligne en PPPoE,
donc avec une MTU de 1492 et cela fonctionne parfaitement avec une MTU de
1500 côté LAN. Le noyau a-t-il enfin le droit de fragmenter les paquets ?
Le 30/03/2017 à 00:03, JKB a écrit :Chez Nerim, ils jouent avec PPPoE et PPPoA selon les humeurs du jour
(je suis en dégroupé Nerim, c'est moins pire que le dégroupage SFR).
Je suis en dégroupé SFR. La latence est abominable, mais je n'ai pas de
problème autre que le trou noir de MTU auquel je sais devoir m'attendre
si j'utilise PPPoE.
Bref, côté PPPoA, j'ai une MTU classique de 1500 pour l'IPv4.
Pareil, via un antique modem Alcatel en mode relais PPTP.Mais
attention, en IPv6, ça ne passe pas. Pas d'ICMP6 en réponse, rien.
Bizarrement, avec une MTU de 1492, ça passe. Mon modem est un ZyXEL.
Par "pas d'ICMP6 en réponse", je suppose que tu veux dire pas de message
ICMPv6 de type "packet too big" renvoyé par un routeur de Nerim en
réponse à l'envoi d'un paquet de plus de 1492 octets ?
Si je me souviens bien des explications de Raphaël Bouaziz sur les
forums nerim.* (ça doit encore y être), les DSLAM mis en place pour le
dégroupage Nerim sont de type ethernet (contrairement aux DSLAM
traditionnels de type ATM), et font une conversion PPPoA -> PPPoE pour
transporter la session PPP sur le lien ethernet vers le concentrateur
d'accès (AC) PPPoE lorsqu'un client utilise PPPoA.
On retombe donc sur le classique problème de MTU de PPPoE. Pour
l'éviter, il faut que :
- le lien ethernet entre le DSLAM et le concentrateur ait une MTU
supérieure ou égale à 1508
- le DSLAM et le concentrateur PPPoE supportent et utilisent l'option
PPP-Max-Payload de PPPoE autorisant les trames de plus de 1500 octets.
(A ma grande satisfaction, le concentrateur d'accès du BAS SFR dont je
dépends supporte et honore cette option, ce qui me permet d'utiliser une
MTU de 1508 en ethernet et une MTU de 1500 en PPP avec PPPoE)
A défaut, les paquets IP/PPP de plus de 1492 octets ne passent pas.
Ce ne serait pas si gênant s'il y avait fragmentation des paquets trop
gros ou des messages "fragmentation needed/packet too big" pour prévenir
les sources des deux côtés. Mais voilà : dans cette architecture, ni le
DSLAM ni le concentrateur PPPoE ne sont des routeurs, seuls capable
d'émettre ces messages ou de fragmenter les paquets IP. Le routeur est
le LNS, et il ne sait rien de cette cuisine PPPoE/PPPoA, ne gérant
qu'une session L2TP dans les deux cas.
Dans le temps, j'avais constaté que les LNS de Nerim faisaient du
clamping de MSS pour les connexions TCP en IPv4, mais pas en IPv6, ne
contournant que partiellement le problème. Je ne me souviens plus si
cela avait évolué ensuite.
C'est une des raisons pour lesquelles j'avais opté pour une MTU IPv6
diminuée sur tout mon LAN, annoncée par RA. A l'époque où j'avais mis
cela en place, il me semble que la cible TCPMSS n'était pas encore
disponible pour ip6tables.Tiens, tant qu'on parle de cela. Est-ce que tu as vu une évolution
récente dans le noyau Linux ? Il y a longtemps, lorsque toutes
les lignes étaient en PPPoE sur mon vieil Alcatel plafonnant à 512 kbps,
j'étais obligé de coller sur toutes les
machines du LAN des MTU à 1492 pour que ça fonctionne normalement.
Puis toutes mes lignes ayant été passées en PPPoA et j'ai laissé partout
les MTU à 1500. Aujourd'hui, j'ai dû repasser une ligne en PPPoE,
donc avec une MTU de 1492 et cela fonctionne parfaitement avec une MTU de
1500 côté LAN. Le noyau a-t-il enfin le droit de fragmenter les paquets ?
Je ne suis pas sûr de comprendre de quoi tu parles exactement.
Tu parles du fonctionnement du noyau Linux en routeur IP, lorsqu'il doit
retransmettre un paquet reçu qui ne lui est pas destiné ?
En IPv4, le noyau a toujours eu le droit de fragmenter les paquets qui
n'ont pas le drapeau "DF" (Don't Fragment).
En IPv6, les RFC proscrivent la fragmentation par un routeur
intermédiaire et le noyau Linux respectait cette interdiction. Néanmoins
il me semble vaguement me souvenir que cette restriction a été levée
lors de l'implémentation du NAT IPv6 "stateful". Mais mes souvenirs sont
flous et mes notes sont sur un autre ordinateur.
Le 30/03/2017 à 00:03, JKB a écrit :
Chez Nerim, ils jouent avec PPPoE et PPPoA selon les humeurs du jour
(je suis en dégroupé Nerim, c'est moins pire que le dégroupage SFR).
Je suis en dégroupé SFR. La latence est abominable, mais je n'ai pas de
problème autre que le trou noir de MTU auquel je sais devoir m'attendre
si j'utilise PPPoE.
Bref, côté PPPoA, j'ai une MTU classique de 1500 pour l'IPv4.
Pareil, via un antique modem Alcatel en mode relais PPTP.
Mais
attention, en IPv6, ça ne passe pas. Pas d'ICMP6 en réponse, rien.
Bizarrement, avec une MTU de 1492, ça passe. Mon modem est un ZyXEL.
Par "pas d'ICMP6 en réponse", je suppose que tu veux dire pas de message
ICMPv6 de type "packet too big" renvoyé par un routeur de Nerim en
réponse à l'envoi d'un paquet de plus de 1492 octets ?
Si je me souviens bien des explications de Raphaël Bouaziz sur les
forums nerim.* (ça doit encore y être), les DSLAM mis en place pour le
dégroupage Nerim sont de type ethernet (contrairement aux DSLAM
traditionnels de type ATM), et font une conversion PPPoA -> PPPoE pour
transporter la session PPP sur le lien ethernet vers le concentrateur
d'accès (AC) PPPoE lorsqu'un client utilise PPPoA.
On retombe donc sur le classique problème de MTU de PPPoE. Pour
l'éviter, il faut que :
- le lien ethernet entre le DSLAM et le concentrateur ait une MTU
supérieure ou égale à 1508
- le DSLAM et le concentrateur PPPoE supportent et utilisent l'option
PPP-Max-Payload de PPPoE autorisant les trames de plus de 1500 octets.
(A ma grande satisfaction, le concentrateur d'accès du BAS SFR dont je
dépends supporte et honore cette option, ce qui me permet d'utiliser une
MTU de 1508 en ethernet et une MTU de 1500 en PPP avec PPPoE)
A défaut, les paquets IP/PPP de plus de 1492 octets ne passent pas.
Ce ne serait pas si gênant s'il y avait fragmentation des paquets trop
gros ou des messages "fragmentation needed/packet too big" pour prévenir
les sources des deux côtés. Mais voilà : dans cette architecture, ni le
DSLAM ni le concentrateur PPPoE ne sont des routeurs, seuls capable
d'émettre ces messages ou de fragmenter les paquets IP. Le routeur est
le LNS, et il ne sait rien de cette cuisine PPPoE/PPPoA, ne gérant
qu'une session L2TP dans les deux cas.
Dans le temps, j'avais constaté que les LNS de Nerim faisaient du
clamping de MSS pour les connexions TCP en IPv4, mais pas en IPv6, ne
contournant que partiellement le problème. Je ne me souviens plus si
cela avait évolué ensuite.
C'est une des raisons pour lesquelles j'avais opté pour une MTU IPv6
diminuée sur tout mon LAN, annoncée par RA. A l'époque où j'avais mis
cela en place, il me semble que la cible TCPMSS n'était pas encore
disponible pour ip6tables.
Tiens, tant qu'on parle de cela. Est-ce que tu as vu une évolution
récente dans le noyau Linux ? Il y a longtemps, lorsque toutes
les lignes étaient en PPPoE sur mon vieil Alcatel plafonnant à 512 kbps,
j'étais obligé de coller sur toutes les
machines du LAN des MTU à 1492 pour que ça fonctionne normalement.
Puis toutes mes lignes ayant été passées en PPPoA et j'ai laissé partout
les MTU à 1500. Aujourd'hui, j'ai dû repasser une ligne en PPPoE,
donc avec une MTU de 1492 et cela fonctionne parfaitement avec une MTU de
1500 côté LAN. Le noyau a-t-il enfin le droit de fragmenter les paquets ?
Je ne suis pas sûr de comprendre de quoi tu parles exactement.
Tu parles du fonctionnement du noyau Linux en routeur IP, lorsqu'il doit
retransmettre un paquet reçu qui ne lui est pas destiné ?
En IPv4, le noyau a toujours eu le droit de fragmenter les paquets qui
n'ont pas le drapeau "DF" (Don't Fragment).
En IPv6, les RFC proscrivent la fragmentation par un routeur
intermédiaire et le noyau Linux respectait cette interdiction. Néanmoins
il me semble vaguement me souvenir que cette restriction a été levée
lors de l'implémentation du NAT IPv6 "stateful". Mais mes souvenirs sont
flous et mes notes sont sur un autre ordinateur.
Le 30/03/2017 à 00:03, JKB a écrit :Chez Nerim, ils jouent avec PPPoE et PPPoA selon les humeurs du jour
(je suis en dégroupé Nerim, c'est moins pire que le dégroupage SFR).
Je suis en dégroupé SFR. La latence est abominable, mais je n'ai pas de
problème autre que le trou noir de MTU auquel je sais devoir m'attendre
si j'utilise PPPoE.
Bref, côté PPPoA, j'ai une MTU classique de 1500 pour l'IPv4.
Pareil, via un antique modem Alcatel en mode relais PPTP.Mais
attention, en IPv6, ça ne passe pas. Pas d'ICMP6 en réponse, rien.
Bizarrement, avec une MTU de 1492, ça passe. Mon modem est un ZyXEL.
Par "pas d'ICMP6 en réponse", je suppose que tu veux dire pas de message
ICMPv6 de type "packet too big" renvoyé par un routeur de Nerim en
réponse à l'envoi d'un paquet de plus de 1492 octets ?
Si je me souviens bien des explications de Raphaël Bouaziz sur les
forums nerim.* (ça doit encore y être), les DSLAM mis en place pour le
dégroupage Nerim sont de type ethernet (contrairement aux DSLAM
traditionnels de type ATM), et font une conversion PPPoA -> PPPoE pour
transporter la session PPP sur le lien ethernet vers le concentrateur
d'accès (AC) PPPoE lorsqu'un client utilise PPPoA.
On retombe donc sur le classique problème de MTU de PPPoE. Pour
l'éviter, il faut que :
- le lien ethernet entre le DSLAM et le concentrateur ait une MTU
supérieure ou égale à 1508
- le DSLAM et le concentrateur PPPoE supportent et utilisent l'option
PPP-Max-Payload de PPPoE autorisant les trames de plus de 1500 octets.
(A ma grande satisfaction, le concentrateur d'accès du BAS SFR dont je
dépends supporte et honore cette option, ce qui me permet d'utiliser une
MTU de 1508 en ethernet et une MTU de 1500 en PPP avec PPPoE)
A défaut, les paquets IP/PPP de plus de 1492 octets ne passent pas.
Ce ne serait pas si gênant s'il y avait fragmentation des paquets trop
gros ou des messages "fragmentation needed/packet too big" pour prévenir
les sources des deux côtés. Mais voilà : dans cette architecture, ni le
DSLAM ni le concentrateur PPPoE ne sont des routeurs, seuls capable
d'émettre ces messages ou de fragmenter les paquets IP. Le routeur est
le LNS, et il ne sait rien de cette cuisine PPPoE/PPPoA, ne gérant
qu'une session L2TP dans les deux cas.
Dans le temps, j'avais constaté que les LNS de Nerim faisaient du
clamping de MSS pour les connexions TCP en IPv4, mais pas en IPv6, ne
contournant que partiellement le problème. Je ne me souviens plus si
cela avait évolué ensuite.
C'est une des raisons pour lesquelles j'avais opté pour une MTU IPv6
diminuée sur tout mon LAN, annoncée par RA. A l'époque où j'avais mis
cela en place, il me semble que la cible TCPMSS n'était pas encore
disponible pour ip6tables.Tiens, tant qu'on parle de cela. Est-ce que tu as vu une évolution
récente dans le noyau Linux ? Il y a longtemps, lorsque toutes
les lignes étaient en PPPoE sur mon vieil Alcatel plafonnant à 512 kbps,
j'étais obligé de coller sur toutes les
machines du LAN des MTU à 1492 pour que ça fonctionne normalement.
Puis toutes mes lignes ayant été passées en PPPoA et j'ai laissé partout
les MTU à 1500. Aujourd'hui, j'ai dû repasser une ligne en PPPoE,
donc avec une MTU de 1492 et cela fonctionne parfaitement avec une MTU de
1500 côté LAN. Le noyau a-t-il enfin le droit de fragmenter les paquets ?
Je ne suis pas sûr de comprendre de quoi tu parles exactement.
Tu parles du fonctionnement du noyau Linux en routeur IP, lorsqu'il doit
retransmettre un paquet reçu qui ne lui est pas destiné ?
En IPv4, le noyau a toujours eu le droit de fragmenter les paquets qui
n'ont pas le drapeau "DF" (Don't Fragment).
En IPv6, les RFC proscrivent la fragmentation par un routeur
intermédiaire et le noyau Linux respectait cette interdiction. Néanmoins
il me semble vaguement me souvenir que cette restriction a été levée
lors de l'implémentation du NAT IPv6 "stateful". Mais mes souvenirs sont
flous et mes notes sont sur un autre ordinateur.