Ah ben tiens, après avoir déterminé aue les erreurs au lancement en v6
venant des déclarations v4, et réciproquement, je me suis dit que je
n'aurait plus du tout d'erreurs en lançant BIND (ISC, v4.1.1) avec les
options -4 -6
Raté, ça marche pas :
> Starting dhcpd.
> Server cannot run in both IPv4 and IPv6 mode at the same time.
Ca veut dire qu'il faut que je lance deux instances de BIND, une en v4
l'autre en v6 ? Si oui, pourquoi cela n'est-il pas pris en compte dans
le rc-script de FreeBSD, c'est pas compliqué à faire si on rencontre les
options -4 et -6 simultanément.
Ou bien je pars complètement dans une mauvaise direction ?
Ou bien je pars complètement dans une mauvaise direction ?
Non, c'était bien ça *sauf que* : les deux principaux OS grand public, en terme de parc installé (MacOSX et Windows XP) qui intègrent IPv6 -et encore, inactif par défaut sous XP- n'ont pas de client dhcp6 (cf http://ipv6int.net/systems/ )
Ingérable en pratique sur de grands réseaux, donc.
La seule chose positive est que ces deux OS utilisent en priorité v6 lorsqu'ils reçoivent une réponse AAAA à une requête DNS. Bien peu de choses, en vérité.
Qui se plaignait que le protocole IPv6 ne se déployait pas assez vite ?
-- XAv - recasé
Xavier <xavier@groumpf.org> wrote:
Ou bien je pars complètement dans une mauvaise direction ?
Non, c'était bien ça *sauf que* : les deux principaux OS grand public,
en terme de parc installé (MacOSX et Windows XP) qui intègrent IPv6 -et
encore, inactif par défaut sous XP- n'ont pas de client dhcp6 (cf
http://ipv6int.net/systems/ )
Ingérable en pratique sur de grands réseaux, donc.
La seule chose positive est que ces deux OS utilisent en priorité v6
lorsqu'ils reçoivent une réponse AAAA à une requête DNS. Bien peu de
choses, en vérité.
Qui se plaignait que le protocole IPv6 ne se déployait pas assez vite ?
Ou bien je pars complètement dans une mauvaise direction ?
Non, c'était bien ça *sauf que* : les deux principaux OS grand public, en terme de parc installé (MacOSX et Windows XP) qui intègrent IPv6 -et encore, inactif par défaut sous XP- n'ont pas de client dhcp6 (cf http://ipv6int.net/systems/ )
Ingérable en pratique sur de grands réseaux, donc.
La seule chose positive est que ces deux OS utilisent en priorité v6 lorsqu'ils reçoivent une réponse AAAA à une requête DNS. Bien peu de choses, en vérité.
Qui se plaignait que le protocole IPv6 ne se déployait pas assez vite ?
-- XAv - recasé
Erwan David
(Xavier) écrivait :
Ah ben tiens, après avoir déterminé aue les erreurs au lancement en v6 venant des déclarations v4, et réciproquement, je me suis dit que je n'aurait plus du tout d'erreurs en lançant BIND (ISC, v4.1.1) avec les options -4 -6
Raté, ça marche pas :
Starting dhcpd. Server cannot run in both IPv4 and IPv6 mode at the same time.
Ca veut dire qu'il faut que je lance deux instances de BIND, une en v4 l'autre en v6 ? Si oui, pourquoi cela n'est-il pas pris en compte dans le rc-script de FreeBSD, c'est pas compliqué à faire si on rencontre les options -4 et -6 simultanément.
Ou bien je pars complètement dans une mauvaise direction ?
tu lances bind ou dhcpd ?
Pour bind il suffit d'avoir listen-on pour les interfaces en v4, listen-on-v6 pour les interfaces en v6.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
xavier@groumpf.org (Xavier) écrivait :
Ah ben tiens, après avoir déterminé aue les erreurs au lancement en v6
venant des déclarations v4, et réciproquement, je me suis dit que je
n'aurait plus du tout d'erreurs en lançant BIND (ISC, v4.1.1) avec les
options -4 -6
Raté, ça marche pas :
Starting dhcpd.
Server cannot run in both IPv4 and IPv6 mode at the same time.
Ca veut dire qu'il faut que je lance deux instances de BIND, une en v4
l'autre en v6 ? Si oui, pourquoi cela n'est-il pas pris en compte dans
le rc-script de FreeBSD, c'est pas compliqué à faire si on rencontre les
options -4 et -6 simultanément.
Ou bien je pars complètement dans une mauvaise direction ?
tu lances bind ou dhcpd ?
Pour bind il suffit d'avoir
listen-on pour les interfaces en v4, listen-on-v6 pour les interfaces en v6.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Ah ben tiens, après avoir déterminé aue les erreurs au lancement en v6 venant des déclarations v4, et réciproquement, je me suis dit que je n'aurait plus du tout d'erreurs en lançant BIND (ISC, v4.1.1) avec les options -4 -6
Raté, ça marche pas :
Starting dhcpd. Server cannot run in both IPv4 and IPv6 mode at the same time.
Ca veut dire qu'il faut que je lance deux instances de BIND, une en v4 l'autre en v6 ? Si oui, pourquoi cela n'est-il pas pris en compte dans le rc-script de FreeBSD, c'est pas compliqué à faire si on rencontre les options -4 et -6 simultanément.
Ou bien je pars complètement dans une mauvaise direction ?
tu lances bind ou dhcpd ?
Pour bind il suffit d'avoir listen-on pour les interfaces en v4, listen-on-v6 pour les interfaces en v6.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Xavier Roche
Xavier a écrit :
Non, c'était bien ça *sauf que* : les deux principaux OS grand public, en terme de parc installé (MacOSX et Windows XP) qui intègrent IPv6 -et encore, inactif par défaut sous XP- n'ont pas de client dhcp6 (cf http://ipv6int.net/systems/ )
Il faut dire que ça a été pendant longtemps un vrai bordel. Entre RADV qui annonçait que les routes et le préfixe mais pas le DNS (c'est désormais corrigé avec une extension RFC magique supportée par.. humm..) et DHCPv6 dont on avait beaucoup de mal à trouver les clients.. et les serveurs, une conf réseau zen se révélait à peu près aussi facile qu'une installation Linux en 1994.
Je n'ai toujours pas compris comment faire de manière zen un reverse en v6 avec tout ça - comment le client envoi-t-il un feedback sur le, ou les adresses sélectionnées ? Comment sont rafraîchies toutes ces infos ?
Xavier a écrit :
Non, c'était bien ça *sauf que* : les deux principaux OS grand public,
en terme de parc installé (MacOSX et Windows XP) qui intègrent IPv6 -et
encore, inactif par défaut sous XP- n'ont pas de client dhcp6 (cf
http://ipv6int.net/systems/ )
Il faut dire que ça a été pendant longtemps un vrai bordel. Entre RADV
qui annonçait que les routes et le préfixe mais pas le DNS (c'est
désormais corrigé avec une extension RFC magique supportée par.. humm..)
et DHCPv6 dont on avait beaucoup de mal à trouver les clients.. et les
serveurs, une conf réseau zen se révélait à peu près aussi facile qu'une
installation Linux en 1994.
Je n'ai toujours pas compris comment faire de manière zen un reverse en
v6 avec tout ça - comment le client envoi-t-il un feedback sur le, ou
les adresses sélectionnées ? Comment sont rafraîchies toutes ces infos ?
Non, c'était bien ça *sauf que* : les deux principaux OS grand public, en terme de parc installé (MacOSX et Windows XP) qui intègrent IPv6 -et encore, inactif par défaut sous XP- n'ont pas de client dhcp6 (cf http://ipv6int.net/systems/ )
Il faut dire que ça a été pendant longtemps un vrai bordel. Entre RADV qui annonçait que les routes et le préfixe mais pas le DNS (c'est désormais corrigé avec une extension RFC magique supportée par.. humm..) et DHCPv6 dont on avait beaucoup de mal à trouver les clients.. et les serveurs, une conf réseau zen se révélait à peu près aussi facile qu'une installation Linux en 1994.
Je n'ai toujours pas compris comment faire de manière zen un reverse en v6 avec tout ça - comment le client envoi-t-il un feedback sur le, ou les adresses sélectionnées ? Comment sont rafraîchies toutes ces infos ?
Erwan David
(Xavier) écrivait :
Xavier wrote:
Ou bien je pars complètement dans une mauvaise direction ?
Non, c'était bien ça *sauf que* : les deux principaux OS grand public, en terme de parc installé (MacOSX et Windows XP) qui intègrent IPv6 -et encore, inactif par défaut sous XP- n'ont pas de client dhcp6 (cf http://ipv6int.net/systems/ )
Ingérable en pratique sur de grands réseaux, donc.
La seule chose positive est que ces deux OS utilisent en priorité v6 lorsqu'ils reçoivent une réponse AAAA à une requête DNS. Bien peu de choses, en vérité.
Qui se plaignait que le protocole IPv6 ne se déployait pas assez vite ?
DHCP6 n'est pas a méthode cannonnique, c'est RADV le standard. Dommage que ça ne donne pas le DNS et quelques autres infos intéressantes que les options du DHCP peuvent donner...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
xavier@groumpf.org (Xavier) écrivait :
Xavier <xavier@groumpf.org> wrote:
Ou bien je pars complètement dans une mauvaise direction ?
Non, c'était bien ça *sauf que* : les deux principaux OS grand public,
en terme de parc installé (MacOSX et Windows XP) qui intègrent IPv6 -et
encore, inactif par défaut sous XP- n'ont pas de client dhcp6 (cf
http://ipv6int.net/systems/ )
Ingérable en pratique sur de grands réseaux, donc.
La seule chose positive est que ces deux OS utilisent en priorité v6
lorsqu'ils reçoivent une réponse AAAA à une requête DNS. Bien peu de
choses, en vérité.
Qui se plaignait que le protocole IPv6 ne se déployait pas assez vite ?
DHCP6 n'est pas a méthode cannonnique, c'est RADV le standard. Dommage
que ça ne donne pas le DNS et quelques autres infos intéressantes que
les options du DHCP peuvent donner...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Ou bien je pars complètement dans une mauvaise direction ?
Non, c'était bien ça *sauf que* : les deux principaux OS grand public, en terme de parc installé (MacOSX et Windows XP) qui intègrent IPv6 -et encore, inactif par défaut sous XP- n'ont pas de client dhcp6 (cf http://ipv6int.net/systems/ )
Ingérable en pratique sur de grands réseaux, donc.
La seule chose positive est que ces deux OS utilisent en priorité v6 lorsqu'ils reçoivent une réponse AAAA à une requête DNS. Bien peu de choses, en vérité.
Qui se plaignait que le protocole IPv6 ne se déployait pas assez vite ?
DHCP6 n'est pas a méthode cannonnique, c'est RADV le standard. Dommage que ça ne donne pas le DNS et quelques autres infos intéressantes que les options du DHCP peuvent donner...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Ooops ! Faute de frappe (et j'avais la conf BIND ouverte dans une autre fenêtre. Il marche sans soucis, lui -:)
-- XAv - recasé
Pascal Hambourg
Salut,
Xavier Roche a écrit :
Il faut dire que ça a été pendant longtemps un vrai bordel. Entre RADV qui annonçait que les routes et le préfixe mais pas le DNS (c'est désormais corrigé avec une extension RFC magique supportée par.. humm..)
Par radvd en ce qui concerne l'émission, par les noyaux Linux 2.6 pas trop anciens avec l'aide du démon rdnssd en ce qui concerne la réception.
Je n'ai toujours pas compris comment faire de manière zen un reverse en v6 avec tout ça - comment le client envoi-t-il un feedback sur le, ou les adresses sélectionnées ? Comment sont rafraîchies toutes ces infos ?
En autoconfiguration sans état par RA ? A ma connaissance ce n'est pas prévu, la transmission d'information du routeur vers l'hôte est à sens unique. Il faudrait que quelque chose du style de rdnssd fasse la demande de mise à jour DNS.
J'ai besoin d'un rafraîchissement : en DHCP, c'est le serveur qui fait la demande de mise à jour DNS à partir du nom d'hôte communiqué par le client ou bien c'est le client qui la fait directement ?
Salut,
Xavier Roche a écrit :
Il faut dire que ça a été pendant longtemps un vrai bordel. Entre RADV
qui annonçait que les routes et le préfixe mais pas le DNS (c'est
désormais corrigé avec une extension RFC magique supportée par.. humm..)
Par radvd en ce qui concerne l'émission, par les noyaux Linux 2.6 pas
trop anciens avec l'aide du démon rdnssd en ce qui concerne la réception.
Je n'ai toujours pas compris comment faire de manière zen un reverse en
v6 avec tout ça - comment le client envoi-t-il un feedback sur le, ou
les adresses sélectionnées ? Comment sont rafraîchies toutes ces infos ?
En autoconfiguration sans état par RA ? A ma connaissance ce n'est pas
prévu, la transmission d'information du routeur vers l'hôte est à sens
unique. Il faudrait que quelque chose du style de rdnssd fasse la
demande de mise à jour DNS.
J'ai besoin d'un rafraîchissement : en DHCP, c'est le serveur qui fait
la demande de mise à jour DNS à partir du nom d'hôte communiqué par le
client ou bien c'est le client qui la fait directement ?
Il faut dire que ça a été pendant longtemps un vrai bordel. Entre RADV qui annonçait que les routes et le préfixe mais pas le DNS (c'est désormais corrigé avec une extension RFC magique supportée par.. humm..)
Par radvd en ce qui concerne l'émission, par les noyaux Linux 2.6 pas trop anciens avec l'aide du démon rdnssd en ce qui concerne la réception.
Je n'ai toujours pas compris comment faire de manière zen un reverse en v6 avec tout ça - comment le client envoi-t-il un feedback sur le, ou les adresses sélectionnées ? Comment sont rafraîchies toutes ces infos ?
En autoconfiguration sans état par RA ? A ma connaissance ce n'est pas prévu, la transmission d'information du routeur vers l'hôte est à sens unique. Il faudrait que quelque chose du style de rdnssd fasse la demande de mise à jour DNS.
J'ai besoin d'un rafraîchissement : en DHCP, c'est le serveur qui fait la demande de mise à jour DNS à partir du nom d'hôte communiqué par le client ou bien c'est le client qui la fait directement ?
Erwan David
Pascal Hambourg écrivait :
Salut,
Xavier Roche a écrit :
Il faut dire que ça a été pendant longtemps un vrai bordel. Entre RADV qui annonçait que les routes et le préfixe mais pas le DNS (c'est désormais corrigé avec une extension RFC magique supportée par.. humm..)
Par radvd en ce qui concerne l'émission, par les noyaux Linux 2.6 pas trop anciens avec l'aide du démon rdnssd en ce qui concerne la réception.
Si ça n'est pas supporté par windows et mac, ça ne marchera pas. Regarde tout ce qu'on peut passer dans les options DHCP (serveur smtp, serveur ntp, etc..) qui en fait ne sosnt jamais configurés parceque rares sont les systèmes qui peuvent utiliser.
Je n'ai toujours pas compris comment faire de manière zen un reverse en v6 avec tout ça - comment le client envoi-t-il un feedback sur le, ou les adresses sélectionnées ? Comment sont rafraîchies toutes ces infos ?
En autoconfiguration sans état par RA ? A ma connaissance ce n'est pas prévu, la transmission d'information du routeur vers l'hôte est à sens unique. Il faudrait que quelque chose du style de rdnssd fasse la demande de mise à jour DNS.
J'ai besoin d'un rafraîchissement : en DHCP, c'est le serveur qui fait la demande de mise à jour DNS à partir du nom d'hôte communiqué par le client ou bien c'est le client qui la fait directement ?
C'est le serveur qui la fait (en s'authentifiant).
Du moins avec le DHCP ISC.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Il faut dire que ça a été pendant longtemps un vrai bordel. Entre RADV
qui annonçait que les routes et le préfixe mais pas le DNS (c'est
désormais corrigé avec une extension RFC magique supportée par.. humm..)
Par radvd en ce qui concerne l'émission, par les noyaux Linux 2.6 pas
trop anciens avec l'aide du démon rdnssd en ce qui concerne la réception.
Si ça n'est pas supporté par windows et mac, ça ne marchera pas. Regarde
tout ce qu'on peut passer dans les options DHCP (serveur smtp, serveur
ntp, etc..) qui en fait ne sosnt jamais configurés parceque rares sont
les systèmes qui peuvent utiliser.
Je n'ai toujours pas compris comment faire de manière zen un reverse en
v6 avec tout ça - comment le client envoi-t-il un feedback sur le, ou
les adresses sélectionnées ? Comment sont rafraîchies toutes ces infos ?
En autoconfiguration sans état par RA ? A ma connaissance ce n'est pas
prévu, la transmission d'information du routeur vers l'hôte est à sens
unique. Il faudrait que quelque chose du style de rdnssd fasse la
demande de mise à jour DNS.
J'ai besoin d'un rafraîchissement : en DHCP, c'est le serveur qui fait
la demande de mise à jour DNS à partir du nom d'hôte communiqué par le
client ou bien c'est le client qui la fait directement ?
C'est le serveur qui la fait (en s'authentifiant).
Du moins avec le DHCP ISC.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Il faut dire que ça a été pendant longtemps un vrai bordel. Entre RADV qui annonçait que les routes et le préfixe mais pas le DNS (c'est désormais corrigé avec une extension RFC magique supportée par.. humm..)
Par radvd en ce qui concerne l'émission, par les noyaux Linux 2.6 pas trop anciens avec l'aide du démon rdnssd en ce qui concerne la réception.
Si ça n'est pas supporté par windows et mac, ça ne marchera pas. Regarde tout ce qu'on peut passer dans les options DHCP (serveur smtp, serveur ntp, etc..) qui en fait ne sosnt jamais configurés parceque rares sont les systèmes qui peuvent utiliser.
Je n'ai toujours pas compris comment faire de manière zen un reverse en v6 avec tout ça - comment le client envoi-t-il un feedback sur le, ou les adresses sélectionnées ? Comment sont rafraîchies toutes ces infos ?
En autoconfiguration sans état par RA ? A ma connaissance ce n'est pas prévu, la transmission d'information du routeur vers l'hôte est à sens unique. Il faudrait que quelque chose du style de rdnssd fasse la demande de mise à jour DNS.
J'ai besoin d'un rafraîchissement : en DHCP, c'est le serveur qui fait la demande de mise à jour DNS à partir du nom d'hôte communiqué par le client ou bien c'est le client qui la fait directement ?
C'est le serveur qui la fait (en s'authentifiant).
Du moins avec le DHCP ISC.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Eric Masson
Erwan David writes:
'Lut,
C'est le serveur qui la fait (en s'authentifiant).
Du moins avec le DHCP ISC.
Sjsmb, c'est la solution la plus simple, mais tu peux aussi faire en sorte que le client fasse sa demande de mise à jour lui même via nsupdate(8).
-- JA> nous invitons chacun d'entre vous à découvrir notre site afin de JA> vous faire une idée de notre raison d'être et de nos valeurs... Et en plus, ils racolent! Allez donc attendre vos soucoupes ailleurs. -+-GLM in:<http://www.le-gnu.net>- Neuneu bêlant bien identifié -+-
Erwan David <erwan@rail.eu.org> writes:
'Lut,
C'est le serveur qui la fait (en s'authentifiant).
Du moins avec le DHCP ISC.
Sjsmb, c'est la solution la plus simple, mais tu peux aussi faire en
sorte que le client fasse sa demande de mise à jour lui même via
nsupdate(8).
--
JA> nous invitons chacun d'entre vous à découvrir notre site afin de
JA> vous faire une idée de notre raison d'être et de nos valeurs...
Et en plus, ils racolent! Allez donc attendre vos soucoupes ailleurs.
-+-GLM in:<http://www.le-gnu.net>- Neuneu bêlant bien identifié -+-
C'est le serveur qui la fait (en s'authentifiant).
Du moins avec le DHCP ISC.
Sjsmb, c'est la solution la plus simple, mais tu peux aussi faire en sorte que le client fasse sa demande de mise à jour lui même via nsupdate(8).
-- JA> nous invitons chacun d'entre vous à découvrir notre site afin de JA> vous faire une idée de notre raison d'être et de nos valeurs... Et en plus, ils racolent! Allez donc attendre vos soucoupes ailleurs. -+-GLM in:<http://www.le-gnu.net>- Neuneu bêlant bien identifié -+-
