SiXXs Sunset

Le
Eric Masson
'Lut,

Je suppose que les intéressés ont vu passer cette annonce de SiXXs :
https://www.sixxs.net/sunset/

Leur service va donc s'arrêter le 6 juin 2017 et ils n'envisagent
absolument pas de passer la main à d'autres.

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 ?)

Merci d'avance.

--
>COIN !
Comment ça coin ?
Juste melangé 8.5 et X je suppose
-+- In : Guide du Neueu Usenet - Le canard se déchaine -+-
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Marc SCHAEFER
Le #26430691
Eric Masson
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 ?)

Oui, Hurricane Electric me semble bien (si le protocole 41 passe
ton routeur).
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 avec entre autres le fournisseur indépendant init7. Et
Swisscom fait du 6rd (tunneling efficace).
J'ajoute toutefois qu'un fournisseur Internet `neutre' est à l'étude
chez nous (http://www.swissneutral.net/), avec comme premier
objectif la fournitures de tunnels v4 et v6 en adresse fixe.
Pascal Hambourg
Le #26430717
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.
Erwan David
Le #26430750
Pascal Hambourg
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.
--
Les simplifications c'est trop compliqué
JKB
Le #26430754
Le Wed, 29 Mar 2017 08:19:13 +0200,
Erwan David
Pascal Hambourg
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...
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.

Et il faut encore qu'il soit stable :-P
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Erwan David
Le #26430788
JKB
Le Wed, 29 Mar 2017 08:19:13 +0200,
Erwan David
Pascal Hambourg
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...

IPv4 sans ICMP c'est rouler les yeux fermés sur départementale.
IPv6 sans ICMP6 c'est la même chose, mais sur autoroute.
--
Les simplifications c'est trop compliqué
Pascal Hambourg
Le #26430824
Le 29/03/2017 à 09:10, JKB a écrit :
Erwan David
Pascal Hambourg
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.
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.


Si c'est suffisamment transparent pour l'utilisateur final comme le 6rd
de Free, et aussi performant que du natif, c'est suffisant.
JKB
Le #26430842
Le Wed, 29 Mar 2017 21:30:05 +0200,
Pascal Hambourg
Le 29/03/2017 à 09:10, JKB a écrit :
Erwan David
Pascal Hambourg
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 ?

Oh oui...
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).
C'est moins pire. Certains jours, c'est PPPoE qui
fonctionne, puis cela ne fonctionne plus et il faut passer en
PPPoA... À l'heure où j'écris ces lignes, j'ai du PPPoE sur l'ADSL2+
et du PPPoA sur le VDSL2. Je n'ai de l'IPv6 que sur le VDSL2 ayant
gardé mon 3346 Netopia sur l'autre ligne. En cas de déconnexion trop
longue, j'ai des scripts qui basculent la configuration des modems,
l'an passé, je suis resté six semaines sans connexion à cause de
ça (!). Et le service technique était aux abonnés absents.
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.
Là encore, service technique complètement dépassé qui m'a sorti un
bateau de derrière les fagots comme explication. Je constate
simplement que vu de mon serveur, la signalisation IPv6 est absente.
Il paraît que dans la configuration du réseau IPv6 Nerim, c'est
parfaitement normal (sic service technique !). Personnellement,
j'aimerais bien savoir comment ça peut juste fonctionner sans ça.
Il n'y a pas à dire, la grande époque Raphaël Bouaziz est vraiment
du passé.
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.

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 ?
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pascal Hambourg
Le #26431036
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.
JKB
Le #26431187
Le Sat, 1 Apr 2017 11:11:15 +0200,
Pascal Hambourg
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.

Je ne suis plus en dégroupé SFR, mais en dégroupé Nerim...
Le dégroupage SFR, pour moi, c'était avant...
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 ?

Oui.
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).

C'est le comportement que j'observe aujourd'hui. Mais à l'époque (ça
commence à faire un peu vieux), je te prie de croire que ça ne
fonctionnait pas ou pas bien. J'avais dû passer la MTU de toutes les
machines sur le LAN à 1492.
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.

JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Publicité
Poster une réponse
Anonyme