wget et les adresses link-local
Bonjour, Je tente de faire aspirer une page sur un serveur en ipv6 avec mon wget. Le serveur n'a que du link-local, on est sur un même LAN. Mais pas moyen de lui enfiler l'adresse : $ wget http://[fe80::7827:c1ff:fe6c:a351] --2014-09-01 15:23:42-- http://[fe80::7827:c1ff:fe6c:a351]/ Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument. $ wget http://[fe80::7827:c1ff:fe6c:a351%eth1] http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address. $ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1 http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name. Une idée ? Pour donner le problème dans sa globalité : je cherche à mettre un upstream ipv6 à mon nginx. Ca semble supporté depuis 1.3 environ donc largement. Mais encore une fois, avec le link-local pour lequel il faut préciser l'interface quand on fait un ping6 par exemple, ça ne passe pas ... Merci, Julien
Le 1 sept. 2014 à 15:33, Julien Escario a écrit :
Bonjour, Je tente de faire aspirer une page sur un serveur en ipv6 avec mon wget. Le serveur n'a que du link-local, on est sur un même LAN.
Mais pas moyen de lui enfiler l'adresse : $ wget http://[fe80::7827:c1ff:fe6c:a351] --2014-09-01 15:23:42-- http://[fe80::7827:c1ff:fe6c:a351]/ Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument.
$ wget http://[fe80::7827:c1ff:fe6c:a351%eth1] http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address.
$ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1 http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name.
Une idée ?
Si tu peux utiliser curl, oui. ;) $ curl "http://fe80::dead:beef:cafe:1234%virbr0/"
http://lists.gnu.org/archive/html/bug-wget/2009-06/msg00000.html btw pourquoi ne pas utiliser l'IPv4 entre ton RP et ton upstream ? tu compte faire disparaitre IPv4 totalement de ton réseau ? Sinon autre question, pourquoi te cantonner a ton linklocal ? tes hosts IPv6 n'ont pas de global ? Le 01/09/2014 15:46, Emmanuel Thierry a écrit :
Le 1 sept. 2014 à 15:33, Julien Escario a écrit :
Bonjour, Je tente de faire aspirer une page sur un serveur en ipv6 avec mon wget. Le serveur n'a que du link-local, on est sur un même LAN.
Mais pas moyen de lui enfiler l'adresse : $ wget http://[fe80::7827:c1ff:fe6c:a351] --2014-09-01 15:23:42-- http://[fe80::7827:c1ff:fe6c:a351]/ Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument.
$ wget http://[fe80::7827:c1ff:fe6c:a351%eth1] http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address.
$ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1 http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name.
Une idée ? Si tu peux utiliser curl, oui. ;)
$ curl "http://fe80::dead:beef:cafe:1234%virbr0/"
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
J'ai rien vérifié mais je pense que c'est un problème lié au parseur de l'url, vu que le ":" sert habituellement à specifier le port. essaie avec un nom dns éventuellement renseigne le dans /etc/hosts, si wget emploie getaddrinfo() pour ouvrir la connexion, ça devrait fonctionner. Le 01/09/2014 15:33, Julien Escario a écrit :
Bonjour, Je tente de faire aspirer une page sur un serveur en ipv6 avec mon wget. Le serveur n'a que du link-local, on est sur un même LAN.
Mais pas moyen de lui enfiler l'adresse : $ wget http://[fe80::7827:c1ff:fe6c:a351] --2014-09-01 15:23:42-- http://[fe80::7827:c1ff:fe6c:a351]/ Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument.
$ wget http://[fe80::7827:c1ff:fe6c:a351%eth1] http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address.
$ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1 http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name.
Une idée ?
Pour donner le problème dans sa globalité : je cherche à mettre un upstream ipv6 à mon nginx. Ca semble supporté depuis 1.3 environ donc largement. Mais encore une fois, avec le link-local pour lequel il faut préciser l'interface quand on fait un ping6 par exemple, ça ne passe pas ...
Merci, Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Pour revenir sur les différents propositions : * Echapper les [] ne change rien : c'est la partie interface qui est gênante dans le link-local. Typiquement, avec une vraie adresse ipv6 (bon là du 6to4), ca marche bien : $ wget http://[2002:c3c8:d907::1] --2014-09-01 17:13:49-- http://[2002:c3c8:d907::1]/ Connexion vers 2002:c3c8:d907::1:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 1522 (1,5K) [text/html] Sauvegarde en : «index.html» * Curl se comporte correctement, un point pour lui mais du coup ça ne résoud pas le soucis avec nginx. * Mon idée est effectivement de faire disparaître totalement ipv4 de mon réseau pour les services 'non frontaux' qui n'ont absolument aucun besoin de me bouffer des IPv4. Et RFC1918 + vlan, bof, c'est lourd à maintenir dans le temps. * Utiliser 6to4 : ben c'est encore de l'ipv4 déguisée et ca me rajoute de la latence de 8ms entre deux machines branchées sur le même swtich. Du coup, avoir posé la question m'a fait reformuler ma demande à Google : il semblerait que l'utilisation du link-local soit la mauvaise façon de faire ça. ULA semblant (d'après ce que j'ai lu ici et là) en voie de deprecated, il ne me reste qu'à me faire attribuer un subnet natif que je vais firewaller et n'utiliser qu'en local. C'est particulièrement foireux d'un point de vue ipv4 mais commence à prendre du sens quand on se place d'un point de vue ipv6. Je n'ai pas encore tous les réflexes. Faut déjà revenir à une logique de gaspillage, j'ai du mal. Julien Le 01/09/2014 15:33, Julien Escario a écrit :
Bonjour, Je tente de faire aspirer une page sur un serveur en ipv6 avec mon wget. Le serveur n'a que du link-local, on est sur un même LAN.
Mais pas moyen de lui enfiler l'adresse : $ wget http://[fe80::7827:c1ff:fe6c:a351] --2014-09-01 15:23:42-- http://[fe80::7827:c1ff:fe6c:a351]/ Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument.
$ wget http://[fe80::7827:c1ff:fe6c:a351%eth1] http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address.
$ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1 http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name.
Une idée ?
Pour donner le problème dans sa globalité : je cherche à mettre un upstream ipv6 à mon nginx. Ca semble supporté depuis 1.3 environ donc largement. Mais encore une fois, avec le link-local pour lequel il faut préciser l'interface quand on fait un ping6 par exemple, ça ne passe pas ...
Merci, Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 01/09/2014 17:19, Julien Escario a écrit :
Pour revenir sur les différents propositions : * Echapper les [] ne change rien : c'est la partie interface qui est gênante dans le link-local. Typiquement, avec une vraie adresse ipv6 (bon là du 6to4), ca marche bien : $ wget http://[2002:c3c8:d907::1] --2014-09-01 17:13:49-- http://[2002:c3c8:d907::1]/ Connexion vers 2002:c3c8:d907::1:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 1522 (1,5K) [text/html] Sauvegarde en : «index.html»
* Curl se comporte correctement, un point pour lui mais du coup ça ne résoud pas le soucis avec nginx.
* Mon idée est effectivement de faire disparaître totalement ipv4 de mon réseau pour les services 'non frontaux' qui n'ont absolument aucun besoin de me bouffer des IPv4.
la RFC1918 est si petite que ça pour parler de "bouffer des IPv4" ??? (et je comprends pas la nécessité de faire disparaitre IPv4 d'un réseau de BACK).
Et RFC1918 + vlan, bof, c'est lourd à maintenir dans le temps.
Mettre tout le monde dans le même subnet sans aucun compartiment c'est bien pire d'un point de vue topologie. Alors oui ça exige un peu de rigueur et de réf, mais c'est bien plus propre a l'entretient c'est ça devient pas la cacophonie sur ton vlan par défaut...
* Utiliser 6to4 : ben c'est encore de l'ipv4 déguisée et ca me rajoute de la latence de 8ms entre deux machines branchées sur le même swtich.
Du coup, avoir posé la question m'a fait reformuler ma demande à Google : il semblerait que l'utilisation du link-local soit la mauvaise façon de faire ça.
ULA semblant (d'après ce que j'ai lu ici et là) en voie de deprecated, il ne me reste qu'à me faire attribuer un subnet natif que je vais firewaller et n'utiliser qu'en local.
C'est particulièrement foireux d'un point de vue ipv4 mais commence à prendre du sens quand on se place d'un point de vue ipv6. Je n'ai pas encore tous les réflexes. Faut déjà revenir à une logique de gaspillage, j'ai du mal.
Julien
Le 01/09/2014 15:33, Julien Escario a écrit :
Bonjour, Je tente de faire aspirer une page sur un serveur en ipv6 avec mon wget. Le serveur n'a que du link-local, on est sur un même LAN.
Mais pas moyen de lui enfiler l'adresse : $ wget http://[fe80::7827:c1ff:fe6c:a351] --2014-09-01 15:23:42-- http://[fe80::7827:c1ff:fe6c:a351]/ Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument.
$ wget http://[fe80::7827:c1ff:fe6c:a351%eth1] http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address.
$ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1 http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name.
Une idée ?
Pour donner le problème dans sa globalité : je cherche à mettre un upstream ipv6 à mon nginx. Ca semble supporté depuis 1.3 environ donc largement. Mais encore une fois, avec le link-local pour lequel il faut préciser l'interface quand on fait un ping6 par exemple, ça ne passe pas ...
Merci, Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 01/09/2014 17:58, Pierre DOLIDON a écrit :
* Mon idée est effectivement de faire disparaître totalement ipv4 de mon réseau pour les services 'non frontaux' qui n'ont absolument aucun besoin de me bouffer des IPv4.
la RFC1918 est si petite que ça pour parler de "bouffer des IPv4" ??? (et je comprends pas la nécessité de faire disparaitre IPv4 d'un réseau de BACK).
Je parlais de bouffer des IP publiques.
Et RFC1918 + vlan, bof, c'est lourd à maintenir dans le temps.
Mettre tout le monde dans le même subnet sans aucun compartiment c'est bien pire d'un point de vue topologie. Alors oui ça exige un peu de rigueur et de réf, mais c'est bien plus propre a l'entretient c'est ça devient pas la cacophonie sur ton vlan par défaut...
Ah, ca y est, on est déjà au moment où on va m'expliquer comment gérer mon cœur de réseau ? Julien
Le 1 sept. 2014 à 17:19, Julien Escario a écrit :
Pour revenir sur les différents propositions : * Echapper les [] ne change rien : c'est la partie interface qui est gênante dans le link-local. Typiquement, avec une vraie adresse ipv6 (bon là du 6to4), ca marche bien : $ wget http://[2002:c3c8:d907::1] --2014-09-01 17:13:49-- http://[2002:c3c8:d907::1]/ Connexion vers 2002:c3c8:d907::1:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 1522 (1,5K) [text/html] Sauvegarde en : «index.html»
* Curl se comporte correctement, un point pour lui mais du coup ça ne résoud pas le soucis avec nginx.
* Mon idée est effectivement de faire disparaître totalement ipv4 de mon réseau pour les services 'non frontaux' qui n'ont absolument aucun besoin de me bouffer des IPv4. Et RFC1918 + vlan, bof, c'est lourd à maintenir dans le temps.
* Utiliser 6to4 : ben c'est encore de l'ipv4 déguisée et ca me rajoute de la latence de 8ms entre deux machines branchées sur le même swtich.
Du coup, avoir posé la question m'a fait reformuler ma demande à Google : il semblerait que l'utilisation du link-local soit la mauvaise façon de faire ça.
ULA semblant (d'après ce que j'ai lu ici et là) en voie de deprecated, il ne me reste qu'à me faire attribuer un subnet natif que je vais firewaller et n'utiliser qu'en local.
Là il va falloir citer parce que ça me parait violemment faux. Et si c'était le cas, il n'y aurait pas des drafts en discussion dans le groupe IETF v6ops : http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-03 L'ULA est tout à fait valide. Si tu peux l'utiliser, alors c'est *la* solution à ce problème. Cordialement Emmanuel Thierry
C'est particulièrement foireux d'un point de vue ipv4 mais commence à prendre du sens quand on se place d'un point de vue ipv6. Je n'ai pas encore tous les réflexes. Faut déjà revenir à une logique de gaspillage, j'ai du mal.
Julien
Le 01/09/2014 15:33, Julien Escario a écrit :
Bonjour, Je tente de faire aspirer une page sur un serveur en ipv6 avec mon wget. Le serveur n'a que du link-local, on est sur un même LAN.
Mais pas moyen de lui enfiler l'adresse : $ wget http://[fe80::7827:c1ff:fe6c:a351] --2014-09-01 15:23:42-- http://[fe80::7827:c1ff:fe6c:a351]/ Connecting to fe80::7827:c1ff:fe6c:a351:80... failed: Invalid argument.
$ wget http://[fe80::7827:c1ff:fe6c:a351%eth1] http://[fe80::7827:c1ff:fe6c:a351%eth1]: Invalid IPv6 numeric address.
$ wget http://[fe80::7827:c1ff:fe6c:a351]%eth1 http://[fe80::7827:c1ff:fe6c:a351]%eth1: Invalid host name.
Une idée ?
Pour donner le problème dans sa globalité : je cherche à mettre un upstream ipv6 à mon nginx. Ca semble supporté depuis 1.3 environ donc largement. Mais encore une fois, avec le link-local pour lequel il faut préciser l'interface quand on fait un ping6 par exemple, ça ne passe pas ...
Merci, Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 01/09/2014 18:17, Emmanuel Thierry a écrit :
ULA semblant (d'après ce que j'ai lu ici et là) en voie de deprecated, il ne me reste qu'à me faire attribuer un subnet natif que je vais firewaller et n'utiliser qu'en local.
Là il va falloir citer parce que ça me parait violemment faux. Et si c'était le cas, il n'y aurait pas des drafts en discussion dans le groupe IETF v6ops : http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-03
L'ULA est tout à fait valide. Si tu peux l'utiliser, alors c'est *la* solution à ce problème.
Ok, my bad, j'ai dû mal comprendre. Je vais me rencarder encore un peu sur ce mécanisme qui est effectivement présenté comme le penchant ipv6 du RFC1918 (j'ai bien 'penchant' hein, pas équivalent). Julien
Le 1 sept. 2014 à 18:37, Julien Escario a écrit :
Le 01/09/2014 18:17, Emmanuel Thierry a écrit :
ULA semblant (d'après ce que j'ai lu ici et là) en voie de deprecated, il ne me reste qu'à me faire attribuer un subnet natif que je vais firewaller et n'utiliser qu'en local.
Là il va falloir citer parce que ça me parait violemment faux. Et si c'était le cas, il n'y aurait pas des drafts en discussion dans le groupe IETF v6ops : http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-03
L'ULA est tout à fait valide. Si tu peux l'utiliser, alors c'est *la* solution à ce problème.
Ok, my bad, j'ai dû mal comprendre. Je vais me rencarder encore un peu sur ce mécanisme qui est effectivement présenté comme le penchant ipv6 du RFC1918 (j'ai bien 'penchant' hein, pas équivalent).
Au passage si tu veux vraiment respecter stricto-sensus les RFC, il faut que l'adresse soit générée aléatoirement : * http://unique-local-ipv6.com/ (vrai aléatoire) * https://www.sixxs.net/tools/grh/ula/ (basé sur une adresse MAC, mais bon, c'est mieux que rien) Bon, ça c'est surtout utile si tu comptes un jour fusionner ton réseau ULA avec un autre réseau ULA au cours d'une opération de fusion-acquisition ! ;) Cordialement Emmanuel Thierry
participants (4)
-
Emmanuel Thierry -
Julien Escario -
Pierre Colombier -
Pierre DOLIDON