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
prvu ?)
Il n'est pas davantage prvu en IPv4, o le problme est exactement le
mme. 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'entre de gamme depuis plusieurs
annes (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'arrive
des sessions entrantes, et on lui renvoie la fonction d'quilibrage
de charge via deux tunnels IPsec.
- les flux sortants sont NATs v4 localement en quilibrant les
sessions entre les deux interfaces WAN (tout en prioritisant
lgrement l'usage de la moins bonne interface)
Je sais que a ne rsout qu'une partie du pb. Cette solution
convient bien quand il n'y a pas de sessions entrantes stratgiques
sur le site (les cibles de ces sessions sont externalises vers des
hosts hors site), mais elle couvre 99.x% du besoin et est dployable
cot nul.
Je ne comprends pas trs 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 prfixe local (fe80:: - c'est
le plus simple: pourquoi connatrait-il la part publique de son
adresse v6) sur son adresse source, le routeur de bordure (aprs
slection - load balancing - de l'interface WAN de sortie) ne
peut-il pas lui substituer le prfixe public de cette interface ?
plutt que d'assner 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 prserverait la connectivit de bout en
bout (contrairement au truc le plus courant dans le monde v4 qui n'est
mme pas du vrai NAT mais du NAPT). Cela me semble une ide
tentante. Notez toutefois que c'est un gros changement du modle 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 transfrer l'interfonctionnement IP
sur les NE du core-network
mais la configuration des domaines privs a quand mme volu depuis
la prhistoire.
Avec v6 les pbs y deviennent compliqus rgler, et instables du
fait de la faible prennit des logiciels hosts
Je ne vois pas bien comment on vitera de "remonter d'un cran vers
le coeur du rseau"
en s'appuyant davantage sur les routeurs de bordure (qui se sont
gnraliss depuis l'invention d'IPng)
et pourraient rsoudre bien plus facilement l'intgralit 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 rve franchement...
Visiblement l'intgration de v6 aux installations du quotidien n'a
pas encore de modle comprhensible
Il serait temps de lister et rendre lisible les pbs rsoudre, et
d'en proposer des solutions simples
(ou bien de les traiter compltement dans la plus stricte opacit)
Pierre
---
Liste de diffusion du FRnOG
http://www.frnog.org/
attachment: pierre.vcf
