From: ipv6-boun...@ietf.org On Behalf Of Roland Bless but there are similar reasons for using ULAs: - They are not intended to be routed in the Internet - They use a well-known prefix to allow for easy filtering at site boundaries.
WEG] from the below it sounds like the first item isn't always true. The second item is easily solved using proper address planning within the application and network design - eg allocate the block for this use out of a certain range of the RIR or LIR delegated space, and filter only that at the site boundary. I.e. if you know that the lower /56 of each block is by convention used for this purpose, you can filter accordingly much easier than if you have to filter randomly-chosen blocks. All it takes is a bit of prior planning when defining the addressing plan for the network. So there may be cases where these networks get connected to the Internet somehow, but usually only by using a security gateway/proxy, because they should stay isolated, i.e., direct global access to individual devices is usually not desired at all. WEG] A firewall/gateway can do this regardless of the address space that you are using. What you're proposing is a use case similar to the IPv4 model of using RFC1918 addresses + NAT/NAPT at the edge of the private network, and you will not find good support for extending that model to IPv6 because it breaks end to end connectivity and there are none of the address constraints that are present in IPv4 - everything that wants a globally unique address can get one. Even if there is a legitimate reason for not wanting that end to end connectivity in your case, if we make an IPv6 version of RFC1918+NAT available, there's nothing preventing it from being used by everyone that equates that implementation with "better security" today in IPv4, no matter how much we say "don't do that..." You can still use a single gateway to control how devices access the internet (and more importantly, how the internet accesses those devices) without pushing them into ULA space by filtering traffic as necessary at the ingress/egress point without using the addresses themselves as an obfuscation mechanism. That way you remove none of the flexibility if you end up needing connectivity later, but retain the desired security. You also note uniqueness as desirable to manage potential mergers and conflicts between manufacturers on networks that were previously not connected. I think that the solution here is to ensure that the gear in question supports a relatively straightforward renumbering procedure - divorce the network's prefix from the device ID in such a way that the network prefix can be altered on one or both networks should they be merged. Even if the device has a partially hard-coded address, it should be capable of accepting a different prefix should the situation dictate it. The 6renum working group is currently working on exactly this problem (making renumbering easier in IPv6 enterprise deployments), and would love to have input from you on specific considerations within the industries that are represented in this thread. (disclaimer, I am one of the 6renum WG chairs). Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
