On Jan 26, 2012, at 6:39 AM, Jima wrote: > On 2012-01-26, Owen DeLong wrote: >> If you can't point to some specific advantage of ULA over secondary >> non-routed GUA prefixes, then, ULA doesn't have a reason to live. > > My biggest concern with secondary non-routed GUA would be source address > selection. If you're trying to talk to something in 2000::/3, it's > obvious to the OS that it should be using its address in 2000::/3 rather > than the one in fc00::/7. When both the "external" and "internal" > addresses live in 2000::/3, more care has to be taken to ensure the > system DTRT. >
It's very easy to configure SAS to handle this. Frankly, you have the same challenge with ULA in many scenarios. >> I'm not sure where DNS64/NAT64 comes into play here for v6 to v6 >> communication. For IPv4, I don't see any advantage in ULA+NAT64 vs. the >> more reliable and easier RFC-1918 with NAT44 possibilities, even if you >> have to run multiple RFC-1918 domains to get enough addresses, that will >> generally be less complicated and break fewer things than a NAT64 >> implementation. > > My best guess there is the ability to a) only manage a single-stack > network (I really wish more software supported IPv6 so this could be a > more feasible reality), and b) use the same NAT64 prefix across various > NAT64 instances (64:ff9b::/96 is a blocker if you actually want to allow > NAT64 to RFC1918 space). While I can see the potential appeal of the > second point, I'm not sure I'd agree with it myself. > But with NAT64, you're supporting both stacks, you just move the problem around. Having done experiments with both methods, I assure you it is a true statement based on experience. NAT64 really offers more problems than it solves, not the least of which is the stateful DNS interaction problem. Owen
