Le 12/12/2010 22:11, Stephane Bortzmeyer a écrit :
On Sun, Dec 12, 2010 at 08:54:55PM +0100,
Pierre Lagoutte wrote
a message of 119 lines which said:
J'hallucine franchement que le cas (trivial) cité par Yohann
suscite suscite un thread aussi lourd (ce cas n'aurait-il pas été
prévu ?)
Il n'est pas davantage prévu en IPv4, où le problème est exactement le
même. Le multihoming des petits sites (i.e. BGPless) a toujours été un
cauchemar.
On trouve pourtant des solutions multihoming v4 stateful partielles
sur les routeurs de bordure d'entrée de gamme depuis plusieurs
années (genre Netgear FVX538 ou autres)
- sur un site stand-alone, on choisit la meilleure interface WAN
pour les flux entrants en lui attribuant une URL dynamique (genre
DynDns ou autre), et en reconfigurant rapidement à la main en cas de
pb majeur sur cette interface
- si on dispose d'un hub distant, on y localise le point d'arrivée
des sessions entrantes, et on lui renvoie la fonction d'équilibrage
de charge via deux tunnels IPsec.
- les flux sortants sont NATés v4 localement en équilibrant les
sessions entre les deux interfaces WAN (tout en prioritisant
légèrement l'usage de la moins bonne interface)
Je sais que ça ne résout qu'une partie du pb. Cette solution
convient bien quand il n'y a pas de sessions entrantes stratégiques
sur le site (les cibles de ces sessions sont externalisées vers des
hosts hors site), mais elle couvre 99.x% du besoin et est déployable
à coût nul.
Je ne comprends pas très bien pourquoi il serait impossible de faire
ça (pour commencer) en v6 (sinon que pour adresser ce marché, il
faudrait qu'il existe)
Quand un flux sortant utilise un préfixe local (fe80:: - c'est
le plus simple: pourquoi connaîtrait-il la part publique de son
adresse v6) sur son adresse source, le routeur de bordure (après
sélection - load balancing - de l'interface WAN de sortie) ne
peut-il pas lui substituer le préfixe public de cette interface ?
plutôt que d'asséner la non-routabilité native de ce flux sur
l'Internet. ... je sais c'est du NAT, et donc quelque part
Kriminel pour la communauté v6.
Ce serait du NAT, mais qui préserverait la connectivité de bout en
bout (contrairement au truc le plus courant dans le monde v4 qui n'est
même pas du vrai NAT mais du NAPT). Cela me semble une idée
tentante. Notez toutefois que c'est un gros changement du modèle de
TCP/IP. Si un softphone SIP ne connait pas son adresse publique,
comment pourra t-il dire à son pair où envoyer le flux RTP ?
Je ne trouve effectivement pas judicieux que dans v6 (encore plus
que dans v4) tout repose encore sur les hosts
Je ne parle évidemment pas de transférer l'interfonctionnement IP
sur les NE du core-network
mais la configuration des domaines privés a quand même évolué depuis
la préhistoire.
Avec v6 les pbs y deviennent compliqués à régler, et instables du
fait de la faible pérennité des logiciels hosts
Je ne vois pas bien comment on évitera de "remonter d'un cran vers
le coeur du réseau"
en s'appuyant davantage sur les routeurs de bordure (qui se sont
généralisés depuis l'invention d'IPng)
et pourraient résoudre bien plus facilement l'intégralité des pbs
d'interfonctionnement IP et de migration v4/v6
en évitant d'ennuyer madame Michu.
çe qui rendrait de plus possible une certification fonctionnelle des
équipements. Bon, mais là je rêve franchement...
Visiblement l'intégration de v6 aux installations du quotidien n'a
pas encore de modèle compréhensible
Il serait temps de lister et rendre lisible les pbs à résoudre, et
d'en proposer des solutions simples
(ou bien de les traiter complètement dans la plus stricte opacité)
Pierre
---
Liste de diffusion du FRnOG
http://www.frnog.org/
<>
