Is anyone using ULA (RFC 4193) address space for v6 infrastructure that does not need to be exposed to the outside world? I understand the concept of having fc00::/8 being doled out by the RIRs never went anywhere, and using space out of fd00::/8 can be a bit of a crap-shoot because of the likelihood of many organizations that do so not following the algorithm for picking a /48 that is outlined in the RFC. There would appear to be reasonable arguments for and against using ULA. I'm just curious about what people are doing in practice. jms
On Jan 25, 2012 7:52 AM, "Justin M. Streiner" <streiner@cluebyfour.org> wrote:
Is anyone using ULA (RFC 4193) address space for v6 infrastructure that
does not need to be exposed to the outside world? I understand the concept of having fc00::/8 being doled out by the RIRs never went anywhere, and using space out of fd00::/8 can be a bit of a crap-shoot because of the likelihood of many organizations that do so not following the algorithm for picking a /48 that is outlined in the RFC.
There would appear to be reasonable arguments for and against using ULA.
I'm just curious about what people are doing in practice.
Yes. Uses may include the DNS interface that you only want your customers to query.... or pretty much any service, as you said, that does not need to be connected to the internet. Beware of ULA haters. Cb
jms
On Wed, 25 Jan 2012, Justin M. Streiner wrote:
Is anyone using ULA (RFC 4193) address space for v6 infrastructure that does not need to be exposed to the outside world? I understand the concept of having fc00::/8 being doled out by the RIRs never went anywhere, and using space out of fd00::/8 can be a bit of a crap-shoot because of the likelihood of many organizations that do so not following the algorithm for picking a /48 that is outlined in the RFC.
There would appear to be reasonable arguments for and against using ULA. I'm just curious about what people are doing in practice.
Yep. It works great for strictly local devices which don't need Internet access. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951
On Jan 25, 2012, at 9:51 AM, Justin M. Streiner wrote:
Is anyone using ULA (RFC 4193) address space for v6 infrastructure that does not need to be exposed to the outside world? I understand the concept of having fc00::/8 being doled out by the RIRs never went anywhere, and using space out of fd00::/8 can be a bit of a crap-shoot because of the likelihood of many organizations that do so not following the algorithm for picking a /48 that is outlined in the RFC.
There would appear to be reasonable arguments for and against using ULA. I'm just curious about what people are doing in practice.
Our site would be in the against ULA camp. For that matter we had survived until very recently in the anti-1918 camp, too. So, take that as an inherent bias. We have one customer in particular with a substantial non-publicly reachable v6 deployment with globally assigned addresses. I believe there is no need to replicate the headaches of rfc1918 in the next address-family eternity. Dale
On 25/01/2012 16:15, Dale W. Carder wrote:
I believe there is no need to replicate the headaches of rfc1918 in the next address-family eternity.
I wish you luck selling this notion to enterprise network people, most of who appear to believe that rfc1918 address space is a feature, not a bug. Nick
On 1/25/12 10:28 AM, "Nick Hilliard" <nick@foobar.org> wrote:
I wish you luck selling this notion to enterprise network people, most of who appear to believe that rfc1918 address space is a feature, not a bug.
Until they've gone through an M&A where they had to connect multiple sites using overlapping RFC1918 space, of course. Then the idea of globally unique addressing, even if it's not globally routable, starts looking awfully useful. -- Dave Pooser Manager of Information Services Alford Media http://www.alfordmedia.com
On Wed, 25 Jan 2012, Dale W. Carder wrote:
We have one customer in particular with a substantial non-publicly reachable v6 deployment with globally assigned addresses. I believe there is no need to replicate the headaches of rfc1918 in the next address-family eternity.
The one big issue I could see with doing that is that the vulnerability exposure, particularly from the outside world, is larger if devices that don't need public addresses have them. For example, if a network engineer or NOC person accidentally removes a "hide my public infrastructure from the outside world" from an interface on a border router... As others have mentioned, things like management interfaces on access switches, printers, and IP phones would be good candidates to hide with ULA. jms
On Jan 25, 2012, at 10:03 AM, Justin M. Streiner wrote:
On Wed, 25 Jan 2012, Dale W. Carder wrote:
We have one customer in particular with a substantial non-publicly reachable v6 deployment with globally assigned addresses. I believe there is no need to replicate the headaches of rfc1918 in the next address-family eternity.
The one big issue I could see with doing that is that the vulnerability exposure, particularly from the outside world, is larger if devices that don't need public addresses have them. For example, if a network engineer or NOC person accidentally removes a "hide my public infrastructure from the outside world" from an interface on a border router...
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
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.
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
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.
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. Jima
On Jan 26, 2012 5:49 AM, "Owen DeLong" <owen@delong.com> wrote:
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.
1. You don't want to disclose what addresses you are using on your internal network, including to the rir 2. You require or desire an address plan that your rir may consider wasteful. 3. You don't want to talk to an rir for a variety of personal or business process reasons 4. When troubleshooting both with network engineers familiar with the network as well as tac engineers, seeing the network for the first time, ula sticks out like a sore thumb and can lead to some meaningful and clarifying discussions about the devices and flows. 5. Routes and packets leak. Filtering at the perimeter? Which perimeter? Mistakes happen. Ula provides a reasonable assumption that the ISP will not route the leaked packets. It is one of many possible layers of security and fail-safes. Cb
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
On Jan 26, 2012, at 7:35 AM, Cameron Byrne wrote:
On Jan 26, 2012 5:49 AM, "Owen DeLong" <owen@delong.com> wrote:
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.
1. You don't want to disclose what addresses you are using on your internal network, including to the rir
Seriously?
2. You require or desire an address plan that your rir may consider wasteful.
Have you looked at current IPv6 policies? It's pretty hard to imagine implementing one.
3. You don't want to talk to an rir for a variety of personal or business process reasons
Meh. I have little or no sympathy for this.
4. When troubleshooting both with network engineers familiar with the network as well as tac engineers, seeing the network for the first time, ula sticks out like a sore thumb and can lead to some meaningful and clarifying discussions about the devices and flows.
I can see this, but, to me it seems like a double edged sword. Most things that stick out like a sore thumb are inflamed and painful. I don't see this as an exception.
5. Routes and packets leak. Filtering at the perimeter? Which perimeter? Mistakes happen. Ula provides a reasonable assumption that the ISP will not route the leaked packets. It is one of many possible layers of security and fail-safes.
Routes only leak if the routes exist on the border routers in the first place. If I were using multiple GUA prefixes and one was intended not to cross the border, I wouldn't feed it to the border routers to begin with. You can't leak what you don't know. Owen
On Jan 26, 2012 8:49 AM, "Owen DeLong" <owen@delong.com> wrote:
On Jan 26, 2012, at 7:35 AM, Cameron Byrne wrote:
On Jan 26, 2012 5:49 AM, "Owen DeLong" <owen@delong.com> wrote:
On Jan 26, 2012, at 2:00 AM, George Bonser wrote:
Use different GUA ranges for internal and external. It's easy
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
enough to 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.
1. You don't want to disclose what addresses you are using on your internal network, including to the rir
Seriously?
Yes.
2. You require or desire an address plan that your rir may consider wasteful.
Have you looked at current IPv6 policies? It's pretty hard to imagine implementing one.
Yes. Think m2m as 1 example
3. You don't want to talk to an rir for a variety of personal or business process reasons
Meh. I have little or no sympathy for this.
4. When troubleshooting both with network engineers familiar with the network as well as tac engineers, seeing the network for the first time,
Of course. The view from inside the system is different from outside the system. ula sticks out like a sore thumb and can lead to some meaningful and clarifying discussions about the devices and flows.
I can see this, but, to me it seems like a double edged sword. Most
things that stick out like a sore thumb are inflamed and painful. I don't see this as an exception.
5. Routes and packets leak. Filtering at the perimeter? Which perimeter? Mistakes happen. Ula provides a reasonable assumption that the ISP will not route the leaked packets. It is one of many possible layers of security and fail-safes.
Routes only leak if the routes exist on the border routers in the first
Ymmv place. If I were using multiple GUA prefixes and one was intended not to cross the border, I wouldn't feed it to the border routers to begin with. You can't leak what you don't know.
Like many things, we can disagree on this too. Net net, folks need to consider their own requirements. Ula is a tool. If it has a place in your toolbox, great . Cb
Owen
On 1/26/12 7:35 AM, Cameron Byrne wrote:
1. You don't want to disclose what addresses you are using on your internal network, including to the rir
2. You require or desire an address plan that your rir may consider wasteful.
3. You don't want to talk to an rir for a variety of personal or business process reasons
4. When troubleshooting both with network engineers familiar with the network as well as tac engineers, seeing the network for the first time, ula sticks out like a sore thumb and can lead to some meaningful and clarifying discussions about the devices and flows.
5. Routes and packets leak. Filtering at the perimeter? Which perimeter? Mistakes happen. Ula provides a reasonable assumption that the ISP will not route the leaked packets. It is one of many possible layers of security and fail-safes.
Cb Dear Cameron,
For a reference to something taking advantage of ULAs per RFC4193 See: http://tools.ietf.org/html/rfc6281#page-11 Regards, Doug Otis
Even if you don't see an advantage to GUA, can you point to a disadvantage?
Just a matter of convenience. If you have a lot of management IPs or some other IP addresses that are never going to need internet access (an array of 10,000 sensors or something) you don't need to dip into your global allocation to address them. If it is routed within the organization but never goes to the Internet, ULA is ok. If it doesn't get routed at all, link local will do fine. It's good to keep in mind that more things than computers with web browsers are going to get an IP address.
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.
Possibly so. I do, however, see some utility in having a block of addresses that can't be reliably routed over the Internet. Heck, for traffic that might get routed within a site between local networks but not routed off the site (even within the organization's network between sites), there's some utility of having each site use the same subnet. That would ensure that traffic destined for that address range doesn't leave the site regardless of any configuration errors someone might make in filtration.
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.
The only advantage is using an address range that can't be reliably routed over the Internet and that is important in the minds of some. GUA addresses can be reliably routed, that's their purpose. While there is a possibility ULA could possibly be routed over the internet, the cascade of mistakes that it would take for that to happen makes it unlikely. I don't accept ULA routes at my peering/transit routers and I would imagine most other networks are configured the same. In addition, I have the entire block of space static routed to null0 so even if I do get traffic for it (in either direction, in or out), it just goes into the hole.
I'm not sure where DNS64/NAT64 comes into play here for v6 to v6 communication.
No, I wasn't intending that for v6 to v6. Let's say you have some devices that you want to give ULA but they *will* need Internet access infrequently for something such as software updates or statistics reporting or something. You could arrange to do that using NAT64/DNS64 to a v4 destination. Again, I am not advocating configuring such a thing, it's just a thought experiment where I'm trying to anticipate what some "clever" network might do at some point and the sorts of issues we might run into. For example, there are a lot of places that have policies that mandate certain systems may not use public address space. Those policies were developed by corporate bureaucrats, not engineers. The engineers don't make policy but are tasked to implement policy and there are probably many creative ways in which those policy goals will be met. If they use v6 ULA but infrequently need to reach someone offsite, they might be tempted to use NAT64 to reach it. It isn't so much about providing "security" as it is providing barriers to making unwanted traffic easy to route. If you pick an address range that isn't routable in a predictable fashion, it just adds another barrier of entry. It is like living in a town named "One Way Street". People see signs pointing toward it all over the place but following them leads you no closer to your destination. If you use GUA, one mistake could make something very reliably reachable by the entire world. That scares some people. The consensus should be that the contingency plan be, as someone else mentioned, "don't make mistakes". Well, people make em all the time. I would rather get a call from a peer complaining about receiving a ULA route than learning that someone accidently opened up an important internal FTP site to the world. Let me turn it around. What advantage does GUA give you for a subnet that is never going to communicate outside the organization? Configuring LUA is no more or less difficult than GUA.
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.
Agreed. For v4 to v4 that will likely be the case for years.
On Thu, Jan 26, 2012 at 07:53:18PM +0000, George Bonser wrote:
Even if you don't see an advantage to GUA, can you point to a disadvantage?
Just a matter of convenience. If you have a lot of management IPs or some other IP addresses that are never going to need internet access (an array of 10,000 sensors or something) you don't need to dip into your global allocation to address them. If it is routed within the organization but never goes to the Internet, ULA is ok. If it doesn't get routed at all, link local will do fine. It's good to keep in mind that more things than computers with web browsers are going to get an IP address.
Link-local won't do fine in many cases due to poor application compatibilty with address scopes.
In message <20120127015842.GH6332@angus.ind.WPI.EDU>, Chuck Anderson writes:
Even if you don't see an advantage to GUA, can you point to a disadvantage?
Just a matter of convenience. If you have a lot of management IPs or some other IP addresses that are never going to need internet access (an array of 10,000 sensors or something) you don't need to dip into your global allocatio n to address them. If it is routed within the organization but never goes to
On Thu, Jan 26, 2012 at 07:53:18PM +0000, George Bonser wrote: the Internet, ULA is ok. If it doesn't get routed at all, link local will d o fine. It's good to keep in mind that more things than computers with web browsers are going to get an IP address.
Link-local won't do fine in many cases due to poor application compatibilty with address scopes.
Link local is a right royal pain for applications. The DNS does not support it. It requires passing arount 150 bits of address information instead of 128. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
We've used RFC1918 space for years (without NAT) for non-routed device management (switches, printers, IP phones, etc). The same idea applies to ULA. Just another tool in the box. The idea behind the random bits was to avoid conflicts should organizations making use of ULA merge. Locally managed means locally manage, though. The RFC is more of a suggestion than a requirement at that point. Since it's unenforceable, and the standards require it to function regardless, I do suspect that many will opt for a "random" value of zero to keep the notation short and sweet, despite the RFC, or develop an internal addressing schema for ULA space that works for them operationally. On Wed, Jan 25, 2012 at 10:51 AM, Justin M. Streiner < streiner@cluebyfour.org> wrote:
Is anyone using ULA (RFC 4193) address space for v6 infrastructure that does not need to be exposed to the outside world? I understand the concept of having fc00::/8 being doled out by the RIRs never went anywhere, and using space out of fd00::/8 can be a bit of a crap-shoot because of the likelihood of many organizations that do so not following the algorithm for picking a /48 that is outlined in the RFC.
There would appear to be reasonable arguments for and against using ULA. I'm just curious about what people are doing in practice.
jms
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Wed, 25 Jan 2012, Ray Soucy wrote:
We've used RFC1918 space for years (without NAT) for non-routed device management (switches, printers, IP phones, etc).
And we've done the same.
The idea behind the random bits was to avoid conflicts should organizations making use of ULA merge.
I'm also thinking down the road to possible cases where an internal host needs to be able to communicate with an internal host at another organization over a VPN tunnel, and a convincing argument can't be made for using public addresses - something that's pretty common today in the v4 world. The thought of having to something equivalent to NAT-T for v6 doesn't fill my heart (or my VPN termination devices) with joy... Along somewhat similar lines, I don't know if any of the relevant regulatory bodies have made any specific comments related to securing networks that are interconnected using v6. Also being in the higher-ed world, I'm thinking along the lines of HIPAA, GLB, SOX, and friends. The answer might be out there - I just haven't looked into it yet.
Locally managed means locally manage, though. The RFC is more of a suggestion than a requirement at that point.
Right, though it's a shame that the registry-assigned ULA concept didn't take off.
Since it's unenforceable, and the standards require it to function regardless, I do suspect that many will opt for a "random" value of zero to keep the notation short and sweet, despite the RFC, or develop an internal addressing schema for ULA space that works for them operationally.
So it stands a good chance of turning into the wild west ;) jms
On Wed, Jan 25, 2012 at 12:55 PM, Justin M. Streiner <streiner@cluebyfour.org> wrote:
So it stands a good chance of turning into the wild west ;)
Isn't this what's made the Internet great? ;-) -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
So the issue of ULAs has come up in the IETF homenet WG. The homenet WG is considering routing, prefix delegation, security, naming and service discovery. ULA support is written into RFC6204 (basic IPv6 requirements for CPE routers) so home CPEs should have the capability, and should be able to generate "random" ULA prefixes. The potential advantage of ULAs is that you have a stable internal addressing scheme within the homenet, while your ISP-assigned prefix may change over time. You run ULAs alongside your PA prefix. ULAs are not used for host-based NAT. The implication is that all homenet devices carry a ULA, though whether some do not also have a global PA address is open for debate. There's a suggestion that ULAs could be used to assist security to some extent, allowing ULA to ULA communications as they are known to be within the homenet. The naming and service discovery elements should remove the need to ever manually enter a ULA prefix; thus the temptation to use 0 instead of random bits for the ULA prefix should be reduced (even if the CPE allows it). Prefix delegation of ULAs within a homenet would be done the same way as for the global PA prefix. There is a proposal (not from within the homenet WG) to use ULAs with NPT66 (RFC6296). That obviously has some architectural implications. Tim
The potential advantage of ULAs is that you have a stable internal addressing scheme within the homenet, while your ISP-assigned prefix may change over time. You run ULAs alongside your PA prefix. ULAs are not used for host-based NAT. The implication is that all homenet devices carry a ULA, though whether some do not also have a global PA address is open for debate.
Yeah, there's some advantage to that. Have a "corp.foo.com" domain that is the native domain for the internal machines while the foo.com domain that is visible to the outside world has outside accessible addressing.
There's a suggestion that ULAs could be used to assist security to some extent, allowing ULA to ULA communications as they are known to be within the homenet.
Not sure how that assists security unless you simply want to limit site-site communications to your ULA ranges only, then sure. In practice, sites often back each other up and you can have external traffic for site A using site B for its internet access, but that's not a big deal, just need to keep your internal and external traffic separated which any good admin will do as a matter of course, anyway.
On 26 Jan 2012, at 11:10, George Bonser wrote:
The potential advantage of ULAs is that you have a stable internal addressing scheme within the homenet, while your ISP-assigned prefix may change over time. You run ULAs alongside your PA prefix. ULAs are not used for host-based NAT. The implication is that all homenet devices carry a ULA, though whether some do not also have a global PA address is open for debate.
Yeah, there's some advantage to that. Have a "corp.foo.com" domain that is the native domain for the internal machines while the foo.com domain that is visible to the outside world has outside accessible addressing.
Perhaps host.local or host.home internally and host.foo.com externally, though the latter could/should work internally as well.
There's a suggestion that ULAs could be used to assist security to some extent, allowing ULA to ULA communications as they are known to be within the homenet.
Not sure how that assists security unless you simply want to limit site-site communications to your ULA ranges only, then sure. In practice, sites often back each other up and you can have external traffic for site A using site B for its internet access, but that's not a big deal, just need to keep your internal and external traffic separated which any good admin will do as a matter of course, anyway.
It was a suggestion a previous homenet session, but the security aspect of homenet is lagging rather behind the current focus of routing and prefix delegation. The usefulness of the suggestion does depend on ULA filtering at borders, and defining the borders. I'm interested in views as one of the editors of the homenet architecture text. Tim
It was a suggestion a previous homenet session, but the security aspect of homenet is lagging rather behind the current focus of routing and prefix delegation. The usefulness of the suggestion does depend on ULA filtering at borders, and defining the borders.
I'm interested in views as one of the editors of the homenet architecture text.
Tim
I filter the entire space at the borders. Besides, if someone leaks the space, most people won't accept it, certainly any provider worth their salt won't. But one of the problems with ULA and the U part. With RFC 1918 everyone is using the same space. So let's say 10 million networks are using 10/8 and 10,000 of them are leaking bits of it. IF their providers accept their leaks and IF their providers' peers accept it, that leaves only 10,000 different places a 10/8 destined packet could go. In other words, 1918 becomes a maze of twisty caverns each one looking the same as the other. The chances of being able to target any specific network is pretty darned low. With ULA and v6, if it leaks and the addresses were chosen properly, the chances of targeting a specific network are much better. I rather like the notion of everyone using the same v6 space for internal stuff and maybe using nat64/dns64 to talk to each other over VPN. That way if the space leaks in only .1% of cases, the chances of a packet ending up at its intended destination is pretty much random and not guaranteed to end up in the same network an hour from now as it is now. If you want LA, fine, assign ONE /32 for that and everyone uses it. It's like having a million people named "Bob". If you should "Bob", there's no guarantee you will be answered by the Bob you intended and 5 minutes from now you might be answered by a completely different Bob. In other words, you turn leakage into a feature. You make the fact that routes might leak add to the uncertainty by having everyone use the same nets. The more people that leak, the less likely you are to reach an intended destination. V6 ULA makes it MORE likely a leak will result in a security breach because it reduces the chances that two nets will leak the same routes.
In other words, you turn leakage into a feature. You make the fact that routes might leak add to the uncertainty by having everyone use the same nets. The more people that leak, the less likely you are to reach an intended destination. V6 ULA makes it MORE likely a leak will result in a security breach because it reduces the chances that two nets will leak the same routes.
To put it another way, if you mandated that EVERY network announce the entire ULA space, it would make reaching any particular network in a predictable manner impossible. Just as if every network announced RFC 1918 space and everyone accepted it, it would make that address space completely unusable for anything, particularly if everyone announced it and black holed it. That might even be more effective than filtering it. Everyone on the planet announces a route to 10/8 and everyone black holes it at their peering/transit points. So even if someone forgot to filter it, it wouldn't matter because it would be intercepted long before it ever gets to them or at least the chances of anyone being able to reliably reach them would be just about zero.
On Thursday, January 26, 2012 08:19:07 PM George Bonser wrote:
I filter the entire space at the borders. Besides, if someone leaks the space, most people won't accept it, certainly any provider worth their salt won't. But one of the problems with ULA and the U part. With RFC 1918 everyone is using the same space. So let's say 10 million networks are using 10/8 and 10,000 of them are leaking bits of it. IF their providers accept their leaks and IF their providers' peers accept it, that leaves only 10,000 different places a 10/8 destined packet could go.
Just on this subject, we're peering with networks some may call "worth their salt", and what we've been seeing since we started peering with them is interesting. This is an ACL applied on ingress across the peering interfaces (note that sequences 90 - 150 are our own APNIC allocations): router-in-asia-1#sh ip access-lists filter-incoming Extended IP access list filter-incoming 10 deny ip 10.0.0.0 0.255.255.255 any (13685079 matches) 20 deny ip 127.0.0.0 0.255.255.255 any (5380 matches) 30 deny ip 169.254.0.0 0.0.255.255 any (270500 matches) 40 deny ip 172.16.0.0 0.15.255.255 any (5367880 matches) 50 deny ip 192.0.2.0 0.0.0.255 any (3478 matches) 60 deny ip 192.42.172.0 0.0.0.255 any 70 deny ip 192.168.0.0 0.0.255.255 any (10780785 matches) 80 deny ip 198.18.0.0 0.1.255.255 any (1691 matches) 90 deny ip 61.11.208.0 0.0.15.255 any (35 matches) 100 deny ip 119.110.128.0 0.0.127.255 any (50 matches) 110 deny ip 124.158.224.0 0.0.31.255 any (4667 matches) 120 deny ip 202.76.224.0 0.0.15.255 any (7747449 matches) 130 deny ip 116.0.96.0 0.0.31.255 any (124 matches) 140 deny ip 119.110.0.0 0.0.63.255 any (67 matches) 150 deny ip 203.223.128.0 0.0.31.255 any (7665942 matches) 160 permit ip any any (3080575612 matches) router-in-asia-1# router-in-asia-2#sh ip access-lists filter-incoming Extended IP access list filter-incoming 10 deny ip 10.0.0.0 0.255.255.255 any (35529145 matches) 20 deny ip 127.0.0.0 0.255.255.255 any (45 matches) 30 deny ip 169.254.0.0 0.0.255.255 any (12950353 matches) 40 deny ip 172.16.0.0 0.15.255.255 any (8902750 matches) 50 deny ip 192.0.2.0 0.0.0.255 any (4495 matches) 60 deny ip 192.42.172.0 0.0.0.255 any (7 matches) 70 deny ip 192.168.0.0 0.0.255.255 any (8805796 matches) 80 deny ip 198.18.0.0 0.1.255.255 any (3269 matches) 90 deny ip 61.11.208.0 0.0.15.255 any (20 matches) 100 deny ip 119.110.128.0 0.0.127.255 any 110 deny ip 124.158.224.0 0.0.31.255 any (4436 matches) 120 deny ip 202.76.224.0 0.0.15.255 any (6325852 matches) 130 deny ip 116.0.96.0 0.0.31.255 any (857940 matches) 140 deny ip 119.110.0.0 0.0.63.255 any (659 matches) 150 deny ip 203.223.128.0 0.0.31.255 any (6618486 matches) 160 permit ip any any (284108624 matches) router-in-asia-2# router-in-america#sh ip access-lists filter-incoming Extended IP access list filter-incoming 10 deny ip 10.0.0.0 0.255.255.255 any (1226939 matches) 20 deny ip 127.0.0.0 0.255.255.255 any (36 matches) 30 deny ip 169.254.0.0 0.0.255.255 any (2464 matches) 40 deny ip 172.16.0.0 0.15.255.255 any (379730 matches) 50 deny ip 192.0.2.0 0.0.0.255 any (4 matches) 60 deny ip 192.42.172.0 0.0.0.255 any 70 deny ip 192.168.0.0 0.0.255.255 any (987273 matches) 80 deny ip 198.18.0.0 0.1.255.255 any (43 matches) 90 deny ip 61.11.208.0 0.0.15.255 any 100 deny ip 119.110.128.0 0.0.127.255 any (4 matches) 110 deny ip 124.158.224.0 0.0.31.255 any (2514 matches) 120 deny ip 202.76.224.0 0.0.15.255 any (644354 matches) 130 deny ip 116.0.96.0 0.0.31.255 any (11 matches) 140 deny ip 119.110.0.0 0.0.63.255 any (22 matches) 150 deny ip 203.223.128.0 0.0.31.255 any (641830 matches) 160 permit ip any any (84287716 matches) router-in-america# For our v6 ingress filters on the same interfaces, we're seeing some matches for '3ffe::/16' and '2001:db8::/32' from Asia and the U.S. Mark.
Local traffic shouldn't need to touch the CPE regardless of ULA or GUA. Also note that we already have the link local scope for traffic between hosts on the same link (which is all hosts in a typical home network); ULA only becomes useful if routing is involved which is not the typical deployment for the home. ULA is useful, on the other hand, if NPT is used. NPT is not NAT, and doesn't have any of the nastiness of NAT. Using NPT to maintain consistent addressing internally would keep things more simple for end-users, and would allow for things like CPE being able to perform flow-based load-balancing between multiple providers (which would fall more in line with the expectations of the SMB and power-user audience). I'm also not sure what the correct answer is to using a randomly generated prefix vs. a predictable prefix for home networks. ULA was an attempt to resolve address overlap for routed private networks in the event of mergers. The majority of home users will never have this concern. Having a predictable prefix for home environments (ambiguous local addressing?) might be useful for documentation, troubleshooting, and support. I think a lot of the question has to do with what the role of CPE will be going forward. As long as we're talking dual-stack, having operational consistency between IPv4 and IPv6 makes sense. If it's an IPv6-only environment, then things become a lot more flexible (do we even need CPE to include a firewall, or do we say host-based firewalls are sufficient, for example). Glad to see thoughtful consideration is being put into these topics, though. Thank you, Tim. On Thu, Jan 26, 2012 at 6:15 AM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
On 26 Jan 2012, at 11:10, George Bonser wrote:
The potential advantage of ULAs is that you have a stable internal addressing scheme within the homenet, while your ISP-assigned prefix may change over time. You run ULAs alongside your PA prefix. ULAs are not used for host-based NAT. The implication is that all homenet devices carry a ULA, though whether some do not also have a global PA address is open for debate.
Yeah, there's some advantage to that. Have a "corp.foo.com" domain that is the native domain for the internal machines while the foo.com domain that is visible to the outside world has outside accessible addressing.
Perhaps host.local or host.home internally and host.foo.com externally, though the latter could/should work internally as well.
There's a suggestion that ULAs could be used to assist security to some extent, allowing ULA to ULA communications as they are known to be within the homenet.
Not sure how that assists security unless you simply want to limit site-site communications to your ULA ranges only, then sure. In practice, sites often back each other up and you can have external traffic for site A using site B for its internet access, but that's not a big deal, just need to keep your internal and external traffic separated which any good admin will do as a matter of course, anyway.
It was a suggestion a previous homenet session, but the security aspect of homenet is lagging rather behind the current focus of routing and prefix delegation. The usefulness of the suggestion does depend on ULA filtering at borders, and defining the borders.
I'm interested in views as one of the editors of the homenet architecture text.
Tim
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On 2012-01-26 13:43 , Ray Soucy wrote:
Local traffic shouldn't need to touch the CPE regardless of ULA or GUA. Also note that we already have the link local scope for traffic between hosts on the same link (which is all hosts in a typical home network); ULA only becomes useful if routing is involved which is not the typical deployment for the home.
Lots of networks today already at home have separated wired and wireless prefixes in the same home... it is getting more and more typical. The thing is most home-kind-people tend to care that their devices can talk to each other, they do care that those devices talk to the Internet.
ULA is useful, on the other hand, if NPT is used. NPT is not NAT, and doesn't have any of the nastiness of NAT.
The "nastiness of NAT" comes in at least two parts: - state in the NAT for tracking incoming/outgoing packets - NAT 'helpers': rewriting IP addresses inside packets the latter is the worse of the two as when a protocol contains IP addresses inside packets, eg like FTP has as the standard NAT example or heck SIP for something more of today, then even with NPT where you just swap out prefixes you will have a need for a helper as that internal prefix is going to be embedded in those packets and will not be available on the $internet for them to connect to. As such, though the NPT trick sounds nice, it will not work and it is still a NAT and will require helper modules for protocols that embed addresses in their protocol. And those helper modules do squat when the protocol is being crypted end to end, eg using SSL/TLS or even IPSEC. [..]
I'm also not sure what the correct answer is to using a randomly generated prefix vs. a predictable prefix for home networks. ULA was an attempt to resolve address overlap for routed private networks in the event of mergers. The majority of home users will never have this concern.
I guess you never tried to play a LAN version of a multi-player game with friends that are still at home and then trying to route packets between 192.168.0.0/24 at your own home and at the friends home, times 4 others in the same segment? Indeed, that is why in ~1996 we where using 10.100.person.0/24 for the 100mbit segment and VPNd people together. Indeed, that is not a majority (far from ;), but there are definitely cases where this happens. Also, it is mostly a non-issue, as ULA allows to be automatically generated and various IPv6-enabled-router/IPv4-NAT boxes already do just that: generate the ULA on bootup and store it in their config for $lifetime. This works like a charm and is the way it was intended to work.
Having a predictable prefix for home environments (ambiguous local addressing?) might be useful for documentation, troubleshooting, and support.
Don't let people bother with addresses, they have this wonderful thing called Multicast DNS that gives them a nice router.local hostname etc. (M-DNS is not something you want to have in a datacenter but for a home network it is pretty nice) Greets, Jeroen
Thanks for the comments Ray, a couple of comments in-line. On 26 Jan 2012, at 12:43, Ray Soucy wrote:
Local traffic shouldn't need to touch the CPE regardless of ULA or GUA. Also note that we already have the link local scope for traffic between hosts on the same link (which is all hosts in a typical home network); ULA only becomes useful if routing is involved which is not the typical deployment for the home.
The assumption in homenet is that it will become so.
ULA is useful, on the other hand, if NPT is used. NPT is not NAT, and doesn't have any of the nastiness of NAT.
Well, you still have address rewriting, but prefix-based.
I think a lot of the question has to do with what the role of CPE will be going forward. As long as we're talking dual-stack, having operational consistency between IPv4 and IPv6 makes sense. If it's an IPv6-only environment, then things become a lot more flexible (do we even need CPE to include a firewall, or do we say host-based firewalls are sufficient, for example).
The initial assumption in homenet is a stateful firewall with hosts inside the homenet using PCP or something similar. Tim
Inline On Thu, Jan 26, 2012 at 9:05 AM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
Thanks for the comments Ray, a couple of comments in-line.
On 26 Jan 2012, at 12:43, Ray Soucy wrote:
Local traffic shouldn't need to touch the CPE regardless of ULA or GUA. Also note that we already have the link local scope for traffic between hosts on the same link (which is all hosts in a typical home network); ULA only becomes useful if routing is involved which is not the typical deployment for the home.
The assumption in homenet is that it will become so.
Does this mean we're also looking at residential allocations larger than a /64 as the norm?
ULA is useful, on the other hand, if NPT is used. NPT is not NAT, and doesn't have any of the nastiness of NAT.
Well, you still have address rewriting, but prefix-based.
I think that the port rewriting, and as a consequence not being able to map to specific hosts easily, was the bigger problem with NAT. As for the comments made by others regarding "helpers" for NAT, there really aren't many that are needed aside from older pre-NAT protocols like H.323 which decided it would be a good idea to use the IP in the packet payload for authentication. Thankfully, over a decade of NAT has helped end this practice.
I think a lot of the question has to do with what the role of CPE will be going forward. As long as we're talking dual-stack, having operational consistency between IPv4 and IPv6 makes sense. If it's an IPv6-only environment, then things become a lot more flexible (do we even need CPE to include a firewall, or do we say host-based firewalls are sufficient, for example).
The initial assumption in homenet is a stateful firewall with hosts inside the homenet using PCP or something similar.
Tim
So a CPE device with a stateful firewall that accepts a prefix via DHCPv6-PD and makes use of SLAAC for internal network(s) is the foundation, correct? Then use random a ULA allocation that exists to route internally (sounds a lot like a site-local scope; which I never understood the reason we abandoned). I'm just not seeing the value in adding ULA as a requirement unless bundled with NPT for a multi-homed environment, especially if a stateful firewall is already included. If anything, it might slow down adoption due to increased complexity. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Jan 26, 2012, at 8:14 AM, Ray Soucy wrote:
Inline
On Thu, Jan 26, 2012 at 9:05 AM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
Thanks for the comments Ray, a couple of comments in-line.
On 26 Jan 2012, at 12:43, Ray Soucy wrote:
Local traffic shouldn't need to touch the CPE regardless of ULA or GUA. Also note that we already have the link local scope for traffic between hosts on the same link (which is all hosts in a typical home network); ULA only becomes useful if routing is involved which is not the typical deployment for the home.
The assumption in homenet is that it will become so.
Does this mean we're also looking at residential allocations larger than a /64 as the norm?
We certainly should be. I still think that /48s for residential is the right answer. My /48 is working quite nicely in my house.
ULA is useful, on the other hand, if NPT is used. NPT is not NAT, and doesn't have any of the nastiness of NAT.
Well, you still have address rewriting, but prefix-based.
I think that the port rewriting, and as a consequence not being able to map to specific hosts easily, was the bigger problem with NAT.
No, the need for ALGs is the biggest problem with NAT. NPT does not resolve that issue. Yes, port rewriting and other issues are also problematic, but, they are less problematic than the need for ALGs.
As for the comments made by others regarding "helpers" for NAT, there really aren't many that are needed aside from older pre-NAT protocols like H.323 which decided it would be a good idea to use the IP in the packet payload for authentication. Thankfully, over a decade of NAT has helped end this practice.
Yes, it has blocked innovation in protocols that can't easily engineer around NAT. Hopefully we can stop doing that soon.
I think a lot of the question has to do with what the role of CPE will be going forward. As long as we're talking dual-stack, having operational consistency between IPv4 and IPv6 makes sense. If it's an IPv6-only environment, then things become a lot more flexible (do we even need CPE to include a firewall, or do we say host-based firewalls are sufficient, for example).
The initial assumption in homenet is a stateful firewall with hosts inside the homenet using PCP or something similar.
Tim
So a CPE device with a stateful firewall that accepts a prefix via DHCPv6-PD and makes use of SLAAC for internal network(s) is the foundation, correct?
I would expect it to be a combination of SLAAC, DHCPv6, and/or DHCPv6-PD. Which combination may be vendor dependent, but, hopefully the norm will include support for downstream routers and possibly chosen address style configuration (allowing the user to pick an address for their host and configure it at the CPE) which would require DHCP support.
Then use random a ULA allocation that exists to route internally (sounds a lot like a site-local scope; which I never understood the reason we abandoned).
I can actually see this as a reasonable use of ULA, but, I agree site-local scope would have been a better choice. The maybe you can maybe you cant route it nature of ULA is, IMHO it's only advantage over site-local and at the same time the greatest likelihood that it will be misused in a variety of harmful ways, not the least of which is to bring the brain-damage of NAT forward into the IPv6 enterprise.
I'm just not seeing the value in adding ULA as a requirement unless bundled with NPT for a multi-homed environment, especially if a stateful firewall is already included. If anything, it might slow down adoption due to increased complexity.
I don't believe it adds visible complexity. I think it should be relatively transparent to the end-user. Basically, you have one prefix for communications within the house (ULA) and another prefix for communications outside. The prefix for external sessions may not be stable (may change periodically for operational or German reasons), but, the internal prefix remains stable and you can depend on it for configuring access to (e.g. printers, etc.). Sure, service discovery (mDNS, et. al) should obviate the need for most such configuration, but, there will likely always be something that doesn't quite get SD right somehow. Also, the ULA addresses don't mysteriously stop working when your connection to your ISP goes down, so, at least your LAN stuff doesn't die from ISP death. Owen
On 26 Jan 2012, at 16:53, Owen DeLong wrote:
On Jan 26, 2012, at 8:14 AM, Ray Soucy wrote:
Does this mean we're also looking at residential allocations larger than a /64 as the norm?
We certainly should be. I still think that /48s for residential is the right answer.
My /48 is working quite nicely in my house.
There seems to be a lot of discussion happening around a /60 or /56. I wouldn't assume a /48 for residential networks, or a static prefix.
So a CPE device with a stateful firewall that accepts a prefix via DHCPv6-PD and makes use of SLAAC for internal network(s) is the foundation, correct?
I would expect it to be a combination of SLAAC, DHCPv6, and/or DHCPv6-PD. Which combination may be vendor dependent, but, hopefully the norm will include support for downstream routers and possibly chosen address style configuration (allowing the user to pick an address for their host and configure it at the CPE) which would require DHCP support.
Yes, the assumption is multi-subnet in the homenet, with a method for (efficient) prefix delegation internally.
Then use random a ULA allocation that exists to route internally (sounds a lot like a site-local scope; which I never understood the reason we abandoned).
I can actually see this as a reasonable use of ULA, but, I agree site-local scope would have been a better choice. The maybe you can maybe you cant route it nature of ULA is, IMHO it's only advantage over site-local and at the same time the greatest likelihood that it will be misused in a variety of harmful ways, not the least of which is to bring the brain-damage of NAT forward into the IPv6 enterprise.
Site-locals didn't include the "random" prefix element, thus increasing the chance of collision should two site-local sites communicate. See RFC3879 for the issues.
I'm just not seeing the value in adding ULA as a requirement unless bundled with NPT for a multi-homed environment, especially if a stateful firewall is already included. If anything, it might slow down adoption due to increased complexity.
I don't believe it adds visible complexity. I think it should be relatively transparent to the end-user.
Basically, you have one prefix for communications within the house (ULA) and another prefix for communications outside. The prefix for external sessions may not be stable (may change periodically for operational or German reasons), but, the internal prefix remains stable and you can depend on it for configuring access to (e.g. printers, etc.).
Sure, service discovery (mDNS, et. al) should obviate the need for most such configuration, but, there will likely always be something that doesn't quite get SD right somehow.
Also, the ULA addresses don't mysteriously stop working when your connection to your ISP goes down, so, at least your LAN stuff doesn't die from ISP death.
Consider also long-lived connections for example. I don't think there's a conclusion as yet in homenet about ULAs, nor will a conclusion prevent people doing as they please if they really want to. Tim
On Jan 26, 2012, at 3:31 PM, Tim Chown wrote:
On 26 Jan 2012, at 16:53, Owen DeLong wrote:
On Jan 26, 2012, at 8:14 AM, Ray Soucy wrote:
Does this mean we're also looking at residential allocations larger than a /64 as the norm?
We certainly should be. I still think that /48s for residential is the right answer.
My /48 is working quite nicely in my house.
There seems to be a lot of discussion happening around a /60 or /56. I wouldn't assume a /48 for residential networks, or a static prefix.
I wouldn't assume anything. That doesn't change the fact that it is, really, the best thing to do.
So a CPE device with a stateful firewall that accepts a prefix via DHCPv6-PD and makes use of SLAAC for internal network(s) is the foundation, correct?
I would expect it to be a combination of SLAAC, DHCPv6, and/or DHCPv6-PD. Which combination may be vendor dependent, but, hopefully the norm will include support for downstream routers and possibly chosen address style configuration (allowing the user to pick an address for their host and configure it at the CPE) which would require DHCP support.
Yes, the assumption is multi-subnet in the homenet, with a method for (efficient) prefix delegation internally.
Where the definition of (efficient) is highly flexible and almost certainly does not refer to bit conservation.
Then use random a ULA allocation that exists to route internally (sounds a lot like a site-local scope; which I never understood the reason we abandoned).
I can actually see this as a reasonable use of ULA, but, I agree site-local scope would have been a better choice. The maybe you can maybe you cant route it nature of ULA is, IMHO it's only advantage over site-local and at the same time the greatest likelihood that it will be misused in a variety of harmful ways, not the least of which is to bring the brain-damage of NAT forward into the IPv6 enterprise.
Site-locals didn't include the "random" prefix element, thus increasing the chance of collision should two site-local sites communicate. See RFC3879 for the issues.
True, but, it would have been easy enough to correct that or provide registered site-specific site local addressing if that was desired.
I'm just not seeing the value in adding ULA as a requirement unless bundled with NPT for a multi-homed environment, especially if a stateful firewall is already included. If anything, it might slow down adoption due to increased complexity.
I don't believe it adds visible complexity. I think it should be relatively transparent to the end-user.
Basically, you have one prefix for communications within the house (ULA) and another prefix for communications outside. The prefix for external sessions may not be stable (may change periodically for operational or German reasons), but, the internal prefix remains stable and you can depend on it for configuring access to (e.g. printers, etc.).
Sure, service discovery (mDNS, et. al) should obviate the need for most such configuration, but, there will likely always be something that doesn't quite get SD right somehow.
Also, the ULA addresses don't mysteriously stop working when your connection to your ISP goes down, so, at least your LAN stuff doesn't die from ISP death.
Consider also long-lived connections for example.
Long lived connections are still doomed unless you go to the complexity of BGP-based multihoming, LISP, or something similar to one of those two. Personally, I use BGP multihoming for my home and it's working pretty well. YMMV.
I don't think there's a conclusion as yet in homenet about ULAs, nor will a conclusion prevent people doing as they please if they really want to.
Sad, but true. Owen
Tim Chown <tjc@ecs.soton.ac.uk> writes:
On 26 Jan 2012, at 16:53, Owen DeLong wrote:
On Jan 26, 2012, at 8:14 AM, Ray Soucy wrote:
Does this mean we're also looking at residential allocations larger than a /64 as the norm?
We certainly should be. I still think that /48s for residential is the right answer.
My /48 is working quite nicely in my house.
There seems to be a lot of discussion happening around a /60 or /56. I wouldn't assume a /48 for residential networks, or a static prefix.
The big question is what constitutes an "end site" and do we want/need to have multiple classes of "end site" in the interests of conserving IPv6 space, or do we want to have only a single class in the interests of conserving technical person brain cells? Food for thought: There are approximately 7 billion people in the world right now. US billion, 10^9. If we defined an "end site" as an "Internet provider access device that could allow subsidiary devices to connect downstream... AND Every human on the face of the earth was Avi Freedman or Vijay Gill and had ten cell phones that would act as APs, each of which with its own /48... THEN... We would be using between 2^36 and 2^37 end site allocations (70 billion). OR between a /11 and a /12 OR right around 0.03% of the space, assuming 100% utilization efficiency. If the goal in putting small chunks of space at residences is to conserve space in order to fit within the RIR's policies, then it is the policies that ought to change. Stewardship is not the same as parsimony. -r
On 2012-01-25 18:55 , Justin M. Streiner wrote: [..]
Locally managed means locally manage, though. The RFC is more of a suggestion than a requirement at that point.
Right, though it's a shame that the registry-assigned ULA concept didn't take off.
From that POV the only reason one might not want RIR space is that one has to pay a wee bit of money for the RIR space, guess what, any kind of ULA-C space with guarantees for being global unique will have that same
What everybody calls "Registered ULA" or ULA-C(entral) is what the RIRs already provide. Also entities that have such a strict requirement are perfectly served with address space the RIRs provide. And from my POV unless one is deploying devices which set up ad-hoc networks, there is no real reason to use ULA at all. Just take a chunk from your RIR assigned space, firewall it off, or simply do not route it and presto, you got a globally registered unique block of address space. problem. But if you want to stick to ULA anyway and you want a bit more certainty that your ULA prefix does not clash, you can generate a random one as per the RFC and register it: https://www.sixxs.net/tools/grh/ula/ As long as everybody looks at that list, one will be clash free. And yes, ULA comes in chunks of /48 if you need more than that you can just register multiple disjunct ones or... what about that RIR space? Likely one site or another will start using that thing called the Internet anyway at one point. Greets, Jeroen
On Wed, Jan 25, 2012 at 8:08 AM, Jeroen Massar <jeroen@unfix.org> wrote:
On 2012-01-25 18:55 , Justin M. Streiner wrote: [..]
Locally managed means locally manage, though. The RFC is more of a suggestion than a requirement at that point.
Right, though it's a shame that the registry-assigned ULA concept didn't take off.
What everybody calls "Registered ULA" or ULA-C(entral) is what the RIRs already provide. Also entities that have such a strict requirement are perfectly served with address space the RIRs provide.
Jeroen, Not so. The registries provide GUA, not ULA. Not everybody considers the difference significant, but many if not most of the folks who want to use ULA for anything at all do.
But if you want to stick to ULA anyway and you want a bit more certainty that your ULA prefix does not clash, you can generate a random one as per the RFC and register it:
My "registration" was erased from that page. Don't know when. Don't know why. But it speaks poorly for its function as a registry. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 2012-01-25 19:51 , William Herrin wrote:
On Wed, Jan 25, 2012 at 8:08 AM, Jeroen Massar <jeroen@unfix.org> wrote:
On 2012-01-25 18:55 , Justin M. Streiner wrote: [..]
Locally managed means locally manage, though. The RFC is more of a suggestion than a requirement at that point.
Right, though it's a shame that the registry-assigned ULA concept didn't take off.
What everybody calls "Registered ULA" or ULA-C(entral) is what the RIRs already provide. Also entities that have such a strict requirement are perfectly served with address space the RIRs provide.
Jeroen,
Not so. The registries provide GUA, not ULA. Not everybody considers the difference significant, but many if not most of the folks who want to use ULA for anything at all do.
I think you misunderstood my terminology, which is afaik the one used by the relevant documents, but lets see where we go astray. ULA consists out of two portions inside fc00::/7 which are: fd00::/8 for ULA-L (local) as the one defined by RFC4193 fc00::/8 reserved for ULA-C which for instance is mentioned in http://tools.ietf.org/html/draft-hain-ipv6-ulac-02 ULA-L is the one everybody uses and what most people just call ULA. ULA-C is very close to GUA as they are both registered at some entity. ULA-C does not exist though, the prime reason for that being that nobody could come up with extensive reasons why it would be any different from GUA and thus why anyone would bother having a registry for it (well, apart from earning more money by registering numbers of course, like what the rest of the industry is doing). The only other reason would be that one can filter fc00::/7 away completely and be done with both of them in one go. But, the moment that one is using ULA space in one's network one is likely not applying that rule, also, it does not come per default in boxes. And as we all know, folks don't filter per BCP-38 either, thus it will be very unlikely that there will be a global fc00::/7 block (and if that was one's line of defense in their network then good luck with that ;)
But if you want to stick to ULA anyway and you want a bit more certainty that your ULA prefix does not clash, you can generate a random one as per the RFC and register it:
My "registration" was erased from that page. Don't know when. Don't know why. But it speaks poorly for its function as a registry.
This was likely caused by the little note at the bottom: "Prefixes which are not generated using the ULA generator will be silently removed; ULAs are not supposed to look pretty." Various folks are registering fd00::/48 or 'fun' stuff like fd00:b00b::/48 or whole series of /48s (fd01::/48, fd02::/48 etc) and then claim that they generated that prefix. For some obvious reason the system does not agree with those statements. Unfortunately there is no drop log, thus in case that the system did make a wrong decision, there is a contact page where one can notify to and we'll dig into it. Greets, Jeroen
On Wed, Jan 25, 2012 at 1:55 PM, Jeroen Massar <jeroen@unfix.org> wrote:
On 2012-01-25 19:51 , William Herrin wrote:
On Wed, Jan 25, 2012 at 8:08 AM, Jeroen Massar <jeroen@unfix.org> wrote:
What everybody calls "Registered ULA" or ULA-C(entral) is what the RIRs already provide. Also entities that have such a strict requirement are perfectly served with address space the RIRs provide.
Not so. The registries provide GUA, not ULA. Not everybody considers the difference significant, but many if not most of the folks who want to use ULA for anything at all do.
I think you misunderstood my terminology, which is afaik the one used by the relevant documents,
From what I've been able to determine, the folks who want Unique Local Addresses usually want a block of addresses which only function on
Jeroen, I knew I should have used the longer explanation. private networks. Should their packets ever leak on to the public Internet, the ULA users want them to fail. By contrast, the registries hand out Global Unicast Addresses. If packets with these addresses make it to the public Internet, they'll probably work. This is not a good thing if you're implementing a SCADA network whose hosts may need to talk to another company network, or even a remote monitoring company's network, but should never talk to hosts on the public Internet. I don't want to get into an argument over the security implications (or non-implications) of addresses which are or are not publicly routable. Suffice it to say there are networking professionals to whom a GUA address is not a satisfactory substitute for a ULA address. Hence, a registered ULA address IS NOT equivalent to what the RIRs provide.
My "registration" was erased from that page. Don't know when. Don't know why. But it speaks poorly for its function as a registry.
This was likely caused by the little note at the bottom:
"Prefixes which are not generated using the ULA generator will be silently removed; ULAs are not supposed to look pretty."
Various folks are registering fd00::/48 or 'fun' stuff like fd00:b00b::/48
Hey, do you realize how many tries it took me to randomly generate fd00:b00b::/48? In all seriousness, though, while protecting against someone blindly registering lots of naughts is probably reasonable, a registry isn't worth much if it won't record the address ranges folks actually choose to use. Regardless of how closely the RFC was followed in those ranges' selection. In a sense, such a registry makes a net negative contribution because its existence discourages the creation of another organized effort. Regards, Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 2012-01-26 02:21 , William Herrin wrote:
On Wed, Jan 25, 2012 at 1:55 PM, Jeroen Massar <jeroen@unfix.org> wrote:
On 2012-01-25 19:51 , William Herrin wrote:
On Wed, Jan 25, 2012 at 8:08 AM, Jeroen Massar <jeroen@unfix.org> wrote:
What everybody calls "Registered ULA" or ULA-C(entral) is what the RIRs already provide. Also entities that have such a strict requirement are perfectly served with address space the RIRs provide.
Not so. The registries provide GUA, not ULA. Not everybody considers the difference significant, but many if not most of the folks who want to use ULA for anything at all do.
I think you misunderstood my terminology, which is afaik the one used by the relevant documents,
Jeroen,
I knew I should have used the longer explanation.
From what I've been able to determine, the folks who want Unique Local Addresses usually want a block of addresses which only function on private networks.
You mean similar to the fact that the RFC1918 prefixes people use at home can be reached because they are using NAT-PMP or uPNP on their NAT box?
Should their packets ever leak on to the public Internet, the ULA users want them to fail.
If one does not want packets to get to the Internet then don't connect it to the Internet.
By contrast, the registries hand out Global Unicast Addresses. If packets with these addresses make it to the public Internet, they'll probably work.
Unless they are firewalled or the route is simply not announced at all. Please remember that there is no requirement for a RIR-provided prefix to be announced onto the Internet. [..]
I don't want to get into an argument over the security implications (or non-implications) of addresses which are or are not publicly routable. Suffice it to say there are networking professionals to whom a GUA address is not a satisfactory substitute for a ULA address. Hence, a registered ULA address IS NOT equivalent to what the RIRs provide.
Hmmm ah, yes, "Network professionals", they obviously know what they are doing as they call them self professional, it is at least a very nice imaginary line they have ;) But yes, there are people who bill their customers a lot for things that are not correct. People need to earn money one way or another.
My "registration" was erased from that page. Don't know when. Don't know why. But it speaks poorly for its function as a registry.
This was likely caused by the little note at the bottom:
"Prefixes which are not generated using the ULA generator will be silently removed; ULAs are not supposed to look pretty."
Various folks are registering fd00::/48 or 'fun' stuff like fd00:b00b::/48
Hey, do you realize how many tries it took me to randomly generate fd00:b00b::/48?
It is indeed possible, but it likely took you a lot of time on a very nice fat supercomputer. Better spend your resources on something else I would say.
In all seriousness, though, while protecting against someone blindly registering lots of naughts is probably reasonable, a registry isn't worth much if it won't record the address ranges folks actually choose to use.
It is a registry for ULA addresses, these are random, not hand-picked. If one cannot simply use the button which is located a bit above it, then well, that is not the purpose of it. We could have opted to allow only to register prefixes that where generated by that output, but we chose to allow people who have generated the prefixes locally to submit those too.
Regardless of how closely the RFC was followed in those ranges' selection. In a sense, such a registry makes a net negative contribution because its existence discourages the creation of another organized effort.
I don't see how it makes a negative contribution. The people registering non-ULA registered prefixes are doing so though, then again, they automatically disappear thus it is a non-issue. The script for generating the ULA is linked at the bottom of the page and I am sure that anybody with 30 minutes of time can fix up a way of storing prefixes into a file/db from a HTTP form... next to the complete list being downloadable so if people want to clone it, it would be quite easily done, note also that the offer for a RIR to take it over still stands as stated on the page. Greets, Jeroen
On Wed, Jan 25, 2012 at 3:38 PM, Jeroen Massar <jeroen@unfix.org> wrote:
On 2012-01-26 02:21 , William Herrin wrote:
Should their packets ever leak on to the public Internet, the ULA users want them to fail.
If one does not want packets to get to the Internet then don't connect it to the Internet.
Jeroen, I once worked with an otherwise brilliant gentleman who in his rigid mindset earnestly believed that the correct solution to contingency planning was: don't make mistakes. He gave notice when he figured out that hiring me was the owner's contingency plan. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
In message <Pine.LNX.4.64.1201251037480.16219@whammy.cluebyfour.org>, "Justin M . Streiner" writes:
Is anyone using ULA (RFC 4193) address space for v6 infrastructure that does not need to be exposed to the outside world? I understand the concept of having fc00::/8 being doled out by the RIRs never went anywhere, and using space out of fd00::/8 can be a bit of a crap-shoot because of the likelihood of many organizations that do so not following the algorithm for picking a /48 that is outlined in the RFC.
There would appear to be reasonable arguments for and against using ULA. I'm just curious about what people are doing in practice.
jms
A lot has to do with whether you have PA addresses of not. As for picking a random prefix I suspect most home CPE devices will do the right thing. It's also easy to do the right thing. I just did "dd if=/dev/random count=1 bs=5 | od -x" and pulled the hex dig digits out to construct the ULA I use at home. A little bit prettier version is below. #!/bin/sh dd bs=5 count=1 if=/dev/random 2> /dev/null | od -t x1 | awk 'NF == 6 { print "f8" $2 ":" $3 $4 ":" $5 $6 }' If you don't want to use /dev/random (ifconfig -a ; date ; netstat -na) | md5 | sed 's/\(..\)\(....\)\(....\).*/f8\1:\2:\3/' There are lots of ways to generate a suitable prefix. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
participants (19)
-
Cameron Byrne -
Chuck Anderson -
Dale W. Carder -
Dave Pooser -
Douglas Otis -
George Bonser -
Jay Ford -
Jeroen Massar -
Jima -
Justin M. Streiner -
Mark Andrews -
Mark Tinka -
Nick Hilliard -
Owen DeLong -
Ray Soucy -
Robert E. Seastrom -
Tim Chown -
Valdis.Kletnieks＠vt.edu -
William Herrin