On Jan 26, 2012, at 2:00 AM, George Bonser wrote: >> Use different GUA ranges for internal and external. It's easy enough to >> get an additional prefix. >> >>> As others have mentioned, things like management interfaces on access >> switches, printers, and IP phones would be good candidates to hide with >> ULA. >> >> Or non-advertised, filtered GUA. Works just as well either way. >> >> Owen >> > > If one is obtaining "another" prefix for local addressing, I see no benefit. > I am assuming that anyone that is using ULA is using it for things that don't > communicate off the site such as management interfaces of things, etc. This > won't be a subnet you are connecting by VPN to another organization, usually, > but even if you do the chances of collision is pretty low if you select your > nets properly. But for the most absolutely paranoid site, I can see some > appeal in using ULA in conjunction with DNS64/NAT64 and see them giving the > devices internet access via v4. Not that I agree with the notion, mind you, > just that I can see someone looking at that as an appealing solution for some > things. Even if someone managed to get through the NAT device via v4, they > would have nothing to talk to on the other side as the other side is all v6. >
Even if you don't see an advantage to GUA, can you point to a disadvantage? IMHO, it would be far less wasteful of addressing overall to deprecate fc00::/7 and use unique secondary GUA prefixes for this purpose than to use ULA. 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. 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. Owen
