On Jan 26, 2012 8:44 AM, "Owen DeLong" <[email protected]> wrote: > > > 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. >
I have a very different opinion. Nat64/ dns64 fits my needs great Horses for courses. Cb > > Owen > >
