On 04/16/2013 03:50 PM, lux-integ wrote: > On Tuesday 16 April 2013 19:57:24 Bruce Dubbs wrote: >> Whether to use ipv4 or ipv6 really depends on the ISP. Generally an >> office only needs one address and then uses NAT (network address >> translation) internally. NAT multiplexes a single address into many. >> Any office can use private IP addresses internally (192.168.x.x, >> 10.x.x.x, 172.16,x,x) and one ipv4 (or ipv6) externally. > > the problem is some useful applications such as IPsec and VoIP do not like > NAT .
Who says? Only poor implementations don't deal well with it, but single NAT should work fine for almost everything now days. > Also one NAT-router behind another and NAT becomes problematic. > AND one has to resort to all sorts of convolutions such as stun-servers, > nat-traversal, port-forwarding etc to attempt to use these. > This is referred to as double NAT and is likely to be really supported or supportable in very few scenarios. Don't double NAT! > here is a far better ( than the one I posted previously ) utube video on ipv6 > http://www.youtube.com/watch?v=9UHZ7eX_f30 > Many of the people who were conscious of networking in the early '90s still consider NAT a poor hack at best. The security provided by NAT is only a side effect of having broken everything. Double NAT is broken in the same way that NAT is, only doubly, because IPv4 in its inception was not intended to be used as it is today. Though I've not inadvertently dealt with double-NAT in several years, it was my experience that it never worked exactly as intended (at least not with the cheaper devices that I could afford at the time). With that said, NAT has made us quite lazy WRT security. It was quite a shock at fist, but my traffic rules increased 4 fold on the v6 side compared to my v4 rules when I handed my previously internal only home boxes routable v6 addresses (my take was that I had better do it on my overly complex home network before tackling it in the field). Now, I must state that everything _is_ dual stack, and was from the very beginning, because I can only actually use v6 at a handful of places. Auto-IP works flawlessly with Linux (and has for at least the past few years)-- IOW, no need for an IPv6 DHCP server as long as your router supports router advertisement, but you must still provide static DNS entries manually if you should want to address your DNS servers via v6 (your v4 DNS servers will happily return AAAA addresses if requested so just handle it via DHCP). Windows and Android devices also work flawlessly (preferring v6 to v4 when possible), no idea about OS X and iOS (not to be confused with IOS which has worked just fine with v6 for several years), though I suspect they too should be fine at this point in time. If you do intend to implement v6, the big thing is that you must be conscious of the fact that you are exposing your entire internal network to the live internet (if that term still means anything). Don't be afraid to be overly cautious. Basically begin by denying everything in and out, then add to the top of the stack and work from least traffic to most traffic, then most restrictive to least restrictive as you go up the chain, being as explicit with your traffic rules as is possible. For instance, IP/proto:port in->out goes at the very top, followed by ICMP and ICMPv6 rules in the middle, then IP/proto:port out->in near the bottom, then deny everything else at the very bottom. You can always insert rules to allow more traffic, but if you leave a gaping hole from the very beginning...well, you are likely to have a gaping hole when you think you are finished. You will also likely need to run dual stack for quite some time because v6 adoption is moving very slowly. My advice, having done it myself: Don't do it yet! At least, not until you have a real world need to do so. Unless you are doing it for training, or have a real need that cannot be addressed with existing v4, is just a headache for very little benefit at the moment. HTH --DJ -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
