Auteur Sujet: Actualités IPV6 Orange (Lu 364611 fois)

corrector · « **Réponse #204 le:** 26 novembre 2015 à 12:56:57 »

Quelle différence entre Windows et linux?

Marin · « **Réponse #205 le:** 26 novembre 2015 à 13:13:42 »

Citation de: corrector le 26 novembre 2015 à 12:56:57

Quelle différence entre Windows et linux?

Par « autoconfiguration » je voulais dire SLAAC avec EUI-64 (=> l'adresse MAC est encapsulée dans les 64 derniers bits de l'IPv6 avec « ff:fe » au milieu).

Windows depuis Vista ne suit pas ce comportement et préfère attribuer des suites d'octets aléatoires.

Une explication sur le sujet :

Citation de: kgersen le 14 juillet 2014 à 16:03:14

L'idée a la base c'était surtout de garder une IP réelle basée sur : Prefix réseau:@MAC (EUI-64) tout en ayant en plus une IP public dynamique et temporaire pour éviter le pistage, surtout qu'avec la MAC dans l'IP public on est encore plus "pistable" qu'avant.
L'idée est donc bonne a la base: d'un coté on a un truc connu par les admins: @MAC et préfix qui vont dans le DNS et servent a plein de truc pratiques pour les admins et d'autre coté on a une IP random et temporaire pour aller sur Internet.

sauf que Microsoft comme a son habitude a décider de tout saloper

Par défaut, en plus de l'IP temporaire, Windows n'utilise pas l' @MAC en EUI-64 pour les IP réelles mais un truc complètement aléatoire. Donc on se retrouve avec un double random (l'IP réelle et l'IP temporaire) et les admins locaux ne peuvent plus se baser sur l'@MAC pour trouver une machine ou la filtrer ou autre traitement utile. Et meme l'@ link-local est impactée par ca.

bref du Microsoft tout craché ca.

Certes on peut désactiver ce comportement et retrouver l'@MAC dans les IPv6 avec la commande suivante:
Code: [Sélectionner]
netsh interface ipv6 set global randomizeidentifiers=disabledMais ca aurait du être par défaut comme la norme le recommande et ça aurait faciliter la vie des admins, d'autant qu'on ne peut pas utiliser de stratégie de groupe simple dans l'AD pour 'disabled' ce truc. bref emmerdons les admins jusqu'au bout.

Je@nb · « **Réponse #206 le:** 26 novembre 2015 à 13:16:36 »

La machine a toujours l'"ip réelle" hein. Elle en a juste d'autres en plus pour les connexions sortantes.

Mac OS aussi par défaut il me semble (de mémoire mais ça fait un bail que j'en ai pas touché).
Linux en effet pas par défaut sur les distributions majeures, mais activables.

Je@nb · « **Réponse #207 le:** 26 novembre 2015 à 13:18:01 »

D'après le guide Debian :
https://debian-handbook.info/browse/stable/sect.ipv6.html

Citer

This behavior may have privacy implications. If you switch networks frequently, e.g. with a laptop, you might not want your MAC address being a part of your public IPv6 address. This makes it easy to identify the same device across networks. A solution to this are IPv6 privacy extensions (which Debian enables by default if IPv6 connectivity is detected during initial installation), which will assign an additional randomly generated address to the interface, periodically change them and prefer them for outgoing connections. Incoming connections can still use the address generated by SLAAC.

corrector · « **Réponse #208 le:** 26 novembre 2015 à 13:31:09 »

Sinon, pour le souci de traçage par l'adresse Ethernet, il y a aussi la solution complèmentaire de changer l'adresse Ethernet en fonction du réseau ou du moins à chaque reboot.

Mais pour le Wifi, je ne sais pas si c'est parfaitement supporté.

tit91 · « **Réponse #209 le:** 26 novembre 2015 à 19:34:26 »

<troll>
Comme c'est calme quand Turold n'a plus d'Internet :p
</troll>

Edit: pour lever toute ambiguïté, ce message était une taquinerie suite à un incident fibre ayant touché Palaiseau ce soir.

turold · « **Réponse #210 le:** 26 novembre 2015 à 22:01:18 »

En effet, je suis passé à côté du sens de cette taquinerie, car je n'étais pas concerné par cette panne.

On a donc vu cela en privé.
La panne a duré 2h30. J'aurai pu tester le bail IP. Tant pis, c'est partie remise.^^

Edit: j'étais fatigué au moment d'écrire ce message, la durée était de 2h30, et non de 1h30.

Breizh 29 · « **Réponse #211 le:** 26 novembre 2015 à 23:15:54 »

Citation de: turold le 26 novembre 2015 à 22:01:18

En effet, je suis passé à côté du sens de cette taquinerie, car je n'étais pas concerné par cette panne.

On a donc vu cela en privé.
La panne a duré 1h30. J'aurai pu tester le bail IP. Tant pis, c'est partie remise.^^

On a loupé qq chose, des fiançailles , un mariage ?

turold · « **Réponse #212 le:** 27 novembre 2015 à 06:41:55 »

J'ai édité.
C'était 2h30 de panne, j'étais fatigué au moment d'écrire le message.
Enfin, cela ne change pas grand chose. Surtout que je n'étais pas concerné.

Citation de: Breizh 29 le 26 novembre 2015 à 23:15:54

On a loupé qq chose, des fiançailles , un mariage ?

Mais lol.

On s'échange quelques données sur le NRO et sur Palaiseau.
Je mettrai peut être une ou deux données intéressantes sur le sujet adéquat. Mais pour le moment, je suis en attente de réponse complèmentaire.

J'en profite pour demander publiquement (pas fait en privé). Est-ce que il y a un lien entre cette panne et la fameuse mise à jour IPv6?
D'un côté, je pense que non, vu que ce n'est qu'une partie du NRO qui a été concernée par cette panne. J'ai IPv6 et pas eu cette panne. De l'autre côté, le planning entre l'arrivée de l'IPv6 et cette panne me fait poser cette question, notamment vu la nature technique de la panne aussi...

vivien · « **Réponse #213 le:** 27 novembre 2015 à 09:10:44 »

Un abonné Orange avec de l'IPv6 pourrait faire tourner le Test de débit et de neutralité de l'Internet IPv4 + IPv6 ?

Orange sera le premier FAI a proposer plus de 200 Mb/s en IPv6 ?

Pour rappel Free et SFR sont bloqués à moins de 200 Mb/s car l'IPv6 n'est pas natif mais encapsulé dans de l'IPv4 et que le processeur broadcom n'a pas d’accélérateur pour gérer ça (et qu'il est relativement peu puissant quand il n'y a pas d'accélération matérielle)

turold · « **Réponse #214 le:** 27 novembre 2015 à 09:15:39 »

Oui pour le débit, on a plus de 200Mb/s en IPv6 par défaut, au moins sur un port.

Sinon, côté ports, je te ferais 2 tests.
On a des ports bloqués par défauts, quelque soit la techno d'IP.

Là, j'ai tout ouvert pour moi dans la LiveBox.^^
Laisse-moi le temps de retirer mes ouvertures de ports.

vivien · « **Réponse #215 le:** 27 novembre 2015 à 09:19:22 »

Le trafic est initié par le client aussi bien en download qu'en upload, donc il n'est pas nécessaire d'ouvrir des ports pour le trafic entrant.