martedì 6 dicembre 2011

DOBBIAMO SOLO AVER BISOGNO NAT66

Il mio amico Tom Hollingsworth ha scritto un altro NAT66-è-male post sul blog. Pur essendo d'accordo con lui in linea di principio, e la maggior parte tutti sono d'accordo NAT come lo conosciamo da IPv4 mondo è semplicemente stupido mondo in IPv6 (NAPT più che NAT), dobbiamo solo aver bisogno NPT66 ( Traduzione prefisso di rete; RFC 6296 ) per sostenere piccole sito multihoming ... e ancora una volta, sembra che molti esperti IPv6 a malincuore d'accordo con me.

Qual è il problema

C'è un sacco di multihoming succedendo in Internet corrente senza che nessuno se ne accorga. Chiunque utilizzi Internet per applicazioni mission-critical (o business-grade accesso cloud) possono ottenere due connessioni a Internet da due fornitori a monte el'uso molto semplice NAT trucchi da utilizzare quelle connessioni in modalità active-standby o active-active. Personalmente sono a conoscenza di alcune grandi organizzazioni multinazionali con disegni simili per uffici remoti o di accesso al dettaglio.
Utilizzando attualmente disponibili router di fascia bassa ed esistenti stack host IPv6 (con stack TCP senza un livello di sessione e API presa rotto ) si può risolvere lo stesso problema in due modi nel mondo IPv6:
BGP-based multihoming . Prendi un grande pezzo di provider indipendenti (PI) spazio di indirizzo e un numero AS, assegnare un / 48 per ogni luogo, ed eseguire BGP con due monte ISP da ogni posizione.
Con pochi accorgimenti di routing non è necessario più di un numero AS, è possibile utilizzare routing di default o allowas-in per ottenere la connettività tra i vostri siti.
Con questo chiunque approccio in Elbonia chi è disposto a pagare ASN e fiscali prefisso PI (poche decine o centinaia € o $ all'anno) e un business-grade connessione ISP a due fornitori di servizi ottiene il cambio di inquinare di routing e di inoltro tabelle in ogni router nel default-free zone ... in tutto il mondo. Non è una cosa che vedo l'ora di.
VPN basate multihoming . Utilizzate il vostro spazio di indirizzi all'interno del sito degli uffici remoti, lo spazio di indirizzamento pubblico assegnato dagli ISP viene utilizzato solo per affrontare endpoint del tunnel. Questo progetto non permette l'uscita di servizio Internet locale (tutto il traffico Internet deve essere mischiato in un tunnel VPN per un sito hub centrale) - spesso un showstopper per le aziende che hanno diffuso gli uffici remoti.
Multihoming NPT66 basato . Funziona esattamente allo stesso modo NAT basato multihoming in IPv4, ma si traduce solo in alto a 64 bit del prefisso IPv6. E 'NAT (quindi è male), ma almeno è apolide.
E 'incredibile quanto il nastro adesivo in grado di portare

Lacrime Unicorn e altre soluzioni

Ci sono una serie di altre soluzioni si potrebbero usare, ma tutti richiedono modifiche allo stack host IPv6, quindi non è probabile che vedremo quali vengono attuate in tempi brevi.
SCTP e Shim6 sono piuttosto vecchi e ben noti. SCTP richiede cambiamenti a livello di applicazione (a causa della presa di API rotto), Shim6 richiede cambiamenti nello stack IPv6.
IPv6 IPv6 multihoming senza NAT è uno dei progetti emergenti IETF che cercano di risolvere il problema (si dovrebbe leggere almeno le prime sezioni poche, dove è necessario ammettere NPT66) ... ma ancora richiede ancora modifiche alla pila host IPv6 per funzionare correttamente (ma solo nel codice l'indirizzo IP di origine politica di selezione).
LISP dovrebbe sostituire BGP-based multihoming con LISP basato multihoming (spostando i prefissi cliente in LISP + ALT topologia, che ancora una volta utilizza BGP).Questo approccio sarà probabilmente funziona bene una volta che tutti distribuisce LISP.Nel frattempo, avrete bisogno di router proxy-ITR/ETR (6to4 chiunque relè?), Determinando i flussi di traffico ottimale e centrale punti di soffocare.

Riassunto

Per quanto mi dispiace ammetterlo, NPT66 sembra essere la soluzione più flessibile per le piccole-site IPv6 multihoming problema che abbiamo oggi. Mi piacerebbe vedere gli stack IPv6 ospite fisso, ma ho imparato una lezione triste della storia del NAT: una volta che la rete McGyvers risolvere i problemi di altre persone con strati di nastro adesivo, ognuno inizia a far finta che il problema è andato e va a caccia un altro scoiattolo.

Nessun commento:

Posta un commento

Nota. Solo i membri di questo blog possono postare un commento.