Re: using ULA for 'hidden' v6 devices?
Tim Chown t...@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
Re: using ULA for 'hidden' v6 devices?
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. signature.asc Description: This is a digitally signed message part.
RE: using ULA for 'hidden' v6 devices?
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.
Re: using ULA for 'hidden' v6 devices?
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
RE: using ULA for 'hidden' v6 devices?
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.
Re: using ULA for 'hidden' v6 devices?
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
RE: using ULA for 'hidden' v6 devices?
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.
RE: using ULA for 'hidden' v6 devices?
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.
Re: using ULA for 'hidden' v6 devices?
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 t...@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/
Re: using ULA for 'hidden' v6 devices?
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
Re: using ULA for 'hidden' v6 devices?
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
Re: using ULA for 'hidden' v6 devices?
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
Re: using ULA for 'hidden' v6 devices?
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
Re: using ULA for 'hidden' v6 devices?
On Jan 26, 2012 5:49 AM, Owen DeLong o...@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
Re: using ULA for 'hidden' v6 devices?
Inline On Thu, Jan 26, 2012 at 9:05 AM, Tim Chown t...@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/
Re: using ULA for 'hidden' v6 devices?
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
Re: using ULA for 'hidden' v6 devices?
On Jan 26, 2012, at 7:35 AM, Cameron Byrne wrote: On Jan 26, 2012 5:49 AM, Owen DeLong o...@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
Re: using ULA for 'hidden' v6 devices?
On Jan 26, 2012, at 8:14 AM, Ray Soucy wrote: Inline On Thu, Jan 26, 2012 at 9:05 AM, Tim Chown t...@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
Re: using ULA for 'hidden' v6 devices?
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
Re: using ULA for 'hidden' v6 devices?
On Jan 26, 2012 8:44 AM, Owen DeLong o...@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
Re: using ULA for 'hidden' v6 devices?
On Jan 26, 2012 8:49 AM, Owen DeLong o...@delong.com wrote: On Jan 26, 2012, at 7:35 AM, Cameron Byrne wrote: On Jan 26, 2012 5:49 AM, Owen DeLong o...@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? 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. Of course. The view from inside the system is different from outside the system. 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. Ymmv 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. 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
RE: using ULA for 'hidden' v6 devices?
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.
Re: using ULA for 'hidden' v6 devices?
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
Re: using ULA for 'hidden' v6 devices?
On Thu, Jan 26, 2012 at 07:53:18PM +, 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.
Re: using ULA for 'hidden' v6 devices?
In message 20120127015842.gh6...@angus.ind.wpi.edu, Chuck Anderson writes: On Thu, Jan 26, 2012 at 07:53:18PM +, 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 allocatio n 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 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: ma...@isc.org
Re: using ULA for 'hidden' v6 devices?
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
Re: using ULA for 'hidden' v6 devices?
On Thu, 26 Jan 2012 19:47:15 PST, Owen DeLong said: Where the definition of (efficient) is highly flexible and almost certainly does not refer to bit conservation. There's a reason we put 128 bits in there. :) pgpZa0WH9QExQ.pgp Description: PGP signature
Re: using ULA for 'hidden' v6 devices?
On Jan 25, 2012 7:52 AM, Justin M. Streiner strei...@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
Re: using ULA for 'hidden' v6 devices?
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-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
Re: using ULA for 'hidden' v6 devices?
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
Re: using ULA for 'hidden' v6 devices?
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 strei...@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/
Re: using ULA for 'hidden' v6 devices?
On 1/25/12 10:28 AM, Nick Hilliard n...@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 MA 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
Re: using ULA for 'hidden' v6 devices?
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
Re: using ULA for 'hidden' v6 devices?
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
Re: using ULA for 'hidden' v6 devices?
On Wed, Jan 25, 2012 at 12:55 PM, Justin M. Streiner strei...@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/
Re: using ULA for 'hidden' v6 devices?
In message pine.lnx.4.64.1201251037480.16...@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: ma...@isc.org
Re: using ULA for 'hidden' v6 devices?
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
