|
Le 12/12/2010 22:11, Stephane Bortzmeyer a écrit : On Sun, Dec 12, 2010 at 08:54:55PM +0100, Pierre Lagoutte <pie...@dratech.com> 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 ?) 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)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. - 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) Je ne trouve effectivement pas judicieux que dans v6 (encore plus que dans v4) tout repose encore sur les hostsQuand 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 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/ |
<<attachment: pierre.vcf>>
