What you could do is run dual stack initially on your routers and necessary system (dns, www, etc..), that way in case something goes wrong you still have v4 up and running. You could then create a 6to4 tunnel to someone who offers such services freely, like tunnelbroker, incase your ISP does not offer you v6. From there you could start testing v6 from within your network, don't just remove v4 because you might find you still need it.
Why you won't need NAT with v6: ISP Gets /32 from RIR /32 = 65536 /48 /48 = 65536 /64 /64 = 2^64 IPv6 IP addresses (they are too many for my simple calc) So if your ISP assigns you a /64 which I believe is Best Current Practices, you end up with more than enough IP's to assign to all your electronics in your home, or office or ...... :-) Regards, -- Markus On Jul 6, 2011, at 11:06 AM, Daniel Bwente wrote: > Douglas, > Broadly speaking your looking at the transition mechanisms from v4 to v6, > which include dual stack, translations, tunnels or cutting over straight to > v6 (native) across your network. > > When it comes to NAT, v6 was designed to do without NAT, to achieve end to > end seamless communication, due to the various problems NAT introduced into > networks, thus the Billions of addresses available to those using v6, seeing > as NAT was initialy meant as a Band Aid to v4 running out of addresses. > > Broadly speaking :) > > Cheers > > > > Sent from my iPhone > > On Jul 6, 2011, at 9:20, Douglas Musaazi <[email protected]> wrote: > >> IP v6 and 4, were some of the topics discussed at the recent Lug event, at >> jet Cafe in Namuwongo, i was among the atendees because i have a keen >> interest in open source, the community and am involved in mapping Uganda at >> www.mappingday.com. >> >> I want some explanation on how a network or organisation using IP v4 can >> integrate IPv6, and how IP v6 handles the NAT security scheme in v4: how the >> hidden addresses will be handled by v6..... >> _______________________________________________ >> The Uganda Linux User Group: http://linux.or.ug >> >> Send messages to this mailing list by addressing e-mails to: [email protected] >> Mailing list archives: http://www.mail-archive.com/[email protected]/ >> Mailing list settings: http://kym.net/mailman/listinfo/lug >> To unsubscribe: http://kym.net/mailman/options/lug >> >> The Uganda LUG mailing list is generously hosted by INFOCOM: >> http://www.infocom.co.ug/ >> >> The above comments and data are owned by whoever posted them (including >> attachments if any). The mailing list host is not responsible for them in >> any way. > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in any > way.
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ The Uganda Linux User Group: http://linux.or.ug Send messages to this mailing list by addressing e-mails to: [email protected] Mailing list archives: http://www.mail-archive.com/[email protected]/ Mailing list settings: http://kym.net/mailman/listinfo/lug To unsubscribe: http://kym.net/mailman/options/lug The Uganda LUG mailing list is generously hosted by INFOCOM: http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The mailing list host is not responsible for them in any way.
