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
On Jan 26, 2012 8:44 AM, "Owen DeLong" <owen@delong.com> 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
participants (2)
-
Cameron Byrne
-
Owen DeLong