Marco Ermini ha scritto:
2008/3/18 <[EMAIL PROTECTED]>:
[...]
Riguardo ai software posso darti ragione (anche se ci sono molti
documenti su come sviluppare AF-independent applications),
E secondo te a qualcuno interessano
mentre
i sistemi operativi direi che iniziano a supportare IPv6 in maniera
abbastanza estensiva.
Peccato che poi funzionino da schifo quando li usi :-)
Windows ha iniziato a supportare IPv6 quando? due anni fa, a dir
tanto? secondo te è affidabile? non ci scommetterei una scarpa bucata.
Non so te... se tu fossi un manager che dovesse prendere una decisione
su come orientare il budget della sua azienda... non credo che per ora
investiresti su IPv6. E avresti ragione.
Relativamente a questo, quoto e straquoto, ed aggiungo che in ambito
Microsoft la cosa è abbastanza triste, Windows XP ad esemepio ha un
supporto limitato su IPv6, e a parte l'installazione "manuale" dello
stack, non supporta pienamente DHCPv6, quindi su enviroments DHCP
enabled (il 90% delle reti Enterprise e non), non sarà possibile
configurare i client in modalità statefull a meno di non settare
attributi come DNS a manina su i client . L'assegnazione "dinamica"
degli indirizzi è ovviamente fattibile solo in stateless tramite IPv6
autoconfig magari con EUI-64. Di fatto i sistemi operativi in ambito
desktop, full compilant sono Vista, Linux e Mac OS X ma pur sempre con
implementazioni giovani.
> Io lavoro nel mondo della sicurezza. Secondo voi quanti Intrusion
> detection system e quanti firewall funzionano correttamente con IPv6?
> tirate a indovinare... :-)
ip6tables e ipfw di sicuro :-)
Che culo ;-) scusa il francesismo ma me ne faccio assai poco...
risposta sbagliata, la vera risposta è: zero :-) non ci sono soluzioni
commerciali utilizzabili in ambito security con un supporto IPv6
veramente funzionante.
Giusto Juniper ha un piano di supporto per IPv6 per il suo ScreenOS
per l'ultimo quarter del 2008... quindi per ora, IPv6? no grazie!
Ogni giorno leggo di nuovi vendor che annunciano supporto IPv6 nelle
prossime release delle loro appliance di sicurezza, è un momento questo
dove tutto comincia a convergere verso un nuovo standard, questo è tutto
sommato fisiologico.
Qui nessuno dice che bisogna immediatamente fare uno switch off di IPv4,
ma bisogna cominciare a far coesistenre entrambi gli stack ed analizare
per implementare poi.
L'implementazione non è molto differente dall'IPv4, i protocolli di
routing
(IS-IS, OSPFv3, RIPv3, BGP4+) sono pressochè identici.
Peccato che forse tu lavori unicamente sulle reti e ti manchino gli
altri layer OSI... E probabilmente ti manca la visione architetturale,
quella cambia drasticamente. L'implementazione è molto differente,
soprattutto a livello architetturale complessivo - d'altronde se così
non fosse non ci sarebbe vantaggio ad adottarlo, ma questo significa
anche che è un lavoro durissimo da portare avanti. Riorganizzare delle
reti complesse è un macello che non auguro a nessuno
a parte che RIPv3 non è correttissimo come termine, se parliamo del
supporto di RIP su IPv6 questo si chiama RIP-NG (Next Generation), cmq
la pila deve essere vista nella sua interezza in fase di coesistenza
prima e migrazione dopo, e a mio modo di vedere và fatta un'analisi
specifica anche e soprattuto delle applicazioni che supportano IPv6 in
quanto queste saranno le prime a sfruttare il nuovo protocollo, ed
eventualmente aggiornare a versioni nuove compatibili se sarà
strettamente necessario.
Conseguentemente a questo si potrà parlare di riorganizzazione
dell'architettura logica della rete.
Ovviamente aumentando esponenzialmente il numero di indirizzi occorre
una pianificazione più attenta della rete stessa.
Quello che tu risolvi con un colpo di spugna in due parole è un task
di *mesi* e budget di milioni di Euro all'interno di una grande
corporation - per non parlare delle guerre politiche tra dipartimenti
con competenze sovrapposte... Il che significa che finché non ci sarà
una necessità pressante ce ne fotteremo alla grande ;-)
Ciao
La necessità ci sarà con il passare del tempo, cominciare ad investire
in IPv6 oggi è una cosa assolutamente inteligente da fare, e che
diventerra necessaria e successivamente mandatoria quando gli ISP
comincieranno a vendere Prefix IPv6 a i propri clienti (cosa che non
tarderà ad arrivare vista la penuira di indirizzi e l'ostruzionismo dei
registry a rilasciare ancora IPv4).
Inoltre la necessità di migrare le proprie infrastruttura interne a
IPv6, lasciando da parte la RFC1918 (magari adottando quanto espresso
finalmente nella RFC4193) è ancora lontana dal venire anche in ambito
dual stack (tra l'altro ci sono state discussioni accese all'interno di
IETF se includere dei global unicast prefix privati o meno nei prefissi
ufficiali assegnati, vedi SLA), in quanto l'esigienza vera e propria non
esiste in quest'ambito motivo per cui già si pensa a soluzioni tipo
NAT-PT per fare presentare le reti definite in RFC1918 e quindi IPv4 con
indirizzi IPv6, dopo che i primi ISP rilascieranno i propri unicast
prefix alle utenze
Quello che mi sento di esprimenre, è la necessità di mantenere il focus
su IPv6 sia personalmente che aziendalmente, anche se per il momento è
ancora erroneamente definito da molti end-user come sperimentale (è NON
lo è per niente, anzi !! se questo fosse vero 6Bone non avrebbe avuto
senso). E' necessario in questa fase cominciare ad implementarlo per
conoscerlo, costrunendo eventualmente servizi di test da mettere
limitatamente in produzione.
Saluti
Marco Lombardo
Network Engineer & System Integrator
Certificazioni Personali:
Cisco CCNA Certified
Cisco CCDA Certified
Cisco CCNP Certified
Cisco CCDP Certified
Cisco CCIP Certified
Cisco CCVP Certified
Cisco CCSP Certified
Specializzazioni Personali:
Cisco CQS - Cisco Firewall Specialist
Cisco CQS - Cisco Intrusion Prevention System (IPS) Specialist
Cisco CQS - Cisco Information Security Specialist
Cisco CQS - IP Telephony Exress Specialist Certified
Cisco CQS - IP Telephony Operation Specialist Certified
Cisco CQS - Cisco IP Communications Support Specialist
Security Recognitions:
4011 Recognition
4013 Recognition
_______________________________________________
Cug mailing list
http://www.areanetworking.it/index_docs.php
[email protected]
http://ml.areanetworking.it/mailman/listinfo/cug
