Re: Why ULA: low collision chance (Was: IPv6 fc00::/7 — Unique local addresses)
On Oct 22, 2010, at 6:10 PM, William Herrin wrote: On Fri, Oct 22, 2010 at 11:40 AM, Owen DeLong o...@delong.com wrote: On Oct 22, 2010, at 5:25 AM, William Herrin wrote: On Fri, Oct 22, 2010 at 1:20 AM, Joel Jaeggli joe...@bogus.com wrote: On 10/21/10 6:38 PM, Owen DeLong wrote: On Oct 21, 2010, at 3:42 PM, Jack Bates wrote: On 10/21/2010 5:27 PM, Joel Jaeggli wrote: Announce your gua and then blackhole it and monitor your prefix. you can tell if you're leaking. it's generally pretty hard to tell if you're leaking rfc 1918 since your advertisement may well work depending on the filters of your peers but not very far. This is always the argument I hear from corporate customers concerning wanting NAT. If mistake is made, the RFC 1918 space isn't routable. They often desire the same out of v6 for that reason alone. the rfc 1918 space is being routed inside almost all your adjacent networks, so if their ingress filtering is working as expected, great, but you're only a filter away from leaking. A filter away from leaking to -one- of the millions of entities on the internet. Two filters away from leaking to two. This underestimates the transitive property of leakage. Owen, Just for grins, let's put some rough math to that assertion. The average percentage of the Internet reached by a ULA or RFC1918 leak will be close to: (1-A)^C A = the probability of any given organization filtering private address announcements and/or private address packets at their borders B = the average width of the Internet in organizations (which should be slightly higher than the width in ASes) I'll note that you don't have a B in your equation and didn't define C, so, I'll presume that C= the average width... So filling in example numbers for the equation, if 50% filter announcements or packets and the Internet is an average of 10 organizations wide then the scope of an address leak is: (1-0.5)^10 = 0.5 ^ 10 = 0.1% of the Internet reached by the leak. I think your estimation of 50% is highly optimistic. I also think you underestimate the diameter of the internet, being much closer to 25 than 10 from what I can see. Filling in more realistic (based on my observations) numbers of 5% and 25, my numbers come out as: (1-0.05)^25 = 0.95 ^ 25 = 0.27 = a little more than 1/4 of the internet. In that scenario, the leak is in a very real sense one thousandth as serious as if the leak had been from GUA space which all of the organizations make an effort to carry. And that's assuming that fully half the organizations on the Internet just don't bother trying to filter RFC1918 or ULA use from their public networks. With more realistic numbers, it's closer to 1/4 of the impact of a leak from GUA where you both leaked the route and failed your IP filter and didn't null-route the prefix at your border. (Gee, that seems like three mistakes you need to make for the GUA problem to take effect instead of just the two you claimed for ULA). If 75% filter then a whopping 0.0001% of the Internet is reached by the leak. ROFLMAO... Yeah, and if Ostriches had 15 times the wing surface area they could probably fly. Now, if only 10% filter then your leak reaches a largish 6% of the Internet. That's a worry for someone hoping for some security benefits to not using GUA space but it's far too little to support this bizarre concern that ULA space would somehow supplant GUA space on the public Internet and explode the routers. ULA won't supplant GUA, it will be much more insidious than that. Most people will still use GUA for GUA purposes. However, deliberate routing of ULA will start small and slowly spread over time like a slow-growing cancer. You won't even really detect it until it has metastasized to such an extent that nothing can be done about it. You can't talk about the impact of an accidental leak and compare that to the impact of a deliberate choice to do something. They are two entirely different effects. Of course, I make no claim to know what the correct two constants are in that equation. Perhaps the Internet is thinner. Perhaps nobody filters egress packets despite years of proselytizing. Perhaps the ISP peering interconnectedness corrupts the combinatorics I used to derive the equation in a more substantial fashion than is obvious. I think that the internet is actually much wider and that the actual filtration rate is much closer to 5%. I also think that the peering combinatorics do probably corrupt your equation, but, I'm not sure in which direction or to what extent. It would be pretty hard to estimate, so, I'm willing to go with it for now. Or perhaps your worry about route leakage from non-GUA space really is as overblown as the math suggests. I'm not worried about leakage. You're claiming that a low probability of leakage provides a security benefit, I'm claiming that your security benefit is actually a false sense of security. (i.e. The benefit
Re: Why ULA: low collision chance (Was: IPv6 fc00::/7 — Unique loc al addresses)
On 10/23/2010 2:07 AM, Owen DeLong wrote: However, deliberate routing of ULA will start small and slowly spread over time like a slow-growing cancer. You won't even really detect it until it has metastasized to such an extent that nothing can be done about it. Which is why all v6 templates really need to get this in as a discard/filter/etc, just as we do with RFC-1918. I'm not saying it is perfect, but based on how much bogon lists have hurt legitimate traffic, we know the templates are at least used. Jack
Re: IPv6 fc00::/7 — Unique local addresses
On Fri, 22 Oct 2010 15:42:41 -0700 Owen DeLong o...@delong.com wrote: Actually, it's not pointless at all. The RA system assumes that all routers capable of announcing RAs are default routers and that virtually all routers are created equal (yes, you have high/medium/low, but, really, since you have to use high for everything in any reasonable deployment...) No it doesn't. You can set the router lifetime to zero, which indicates to the end-node that the RA isn't announcing a default router. In this case, it may be announcing M/O bit, prefix or other parameters. DHCPv6 can selectively give different information to different hosts on the same wire segment. RA cannot. That was not the assertion you made. You said that The RA system assumes that all routers capable of announcing RAs are default routers and I said, no, that is not the case if you set the RA lifetime to zero. To cite explicitly, RFC4861 says, Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in Section 6 limit the lifetime to 9000 seconds. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default Narten, et al. Standards Track[Page 20] ^L RFC 4861 Neighbor Discovery in IPv6 September 2007 router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields. I was not making any statements about whether DHCPv6 could be selective about providing certain options to selected end-nodes. You might think I'm being overlay pedantic, however changing the question to then disagree with answer that doesn't agree with yours is being disingenuous. There are real environments where it's desirable to have a way to tell different clients on a network to use different default gateways or default gateway sets. I wouldn't necessarily disagree, although in my experience they're really quite rare, to the point where segmenting them into a separate subnet, via e.g. a different VLAN, becomes a somewhat better and easier option. Regards, Mark.
Re: IPv6 fc00::/7 — Unique local addresses
On Oct 23, 2010, at 7:26 AM, Mark Smith wrote: On Fri, 22 Oct 2010 15:42:41 -0700 Owen DeLong o...@delong.com wrote: Actually, it's not pointless at all. The RA system assumes that all routers capable of announcing RAs are default routers and that virtually all routers are created equal (yes, you have high/medium/low, but, really, since you have to use high for everything in any reasonable deployment...) No it doesn't. You can set the router lifetime to zero, which indicates to the end-node that the RA isn't announcing a default router. In this case, it may be announcing M/O bit, prefix or other parameters. DHCPv6 can selectively give different information to different hosts on the same wire segment. RA cannot. That was not the assertion you made. You said that The RA system assumes that all routers capable of announcing RAs are default routers and I said, no, that is not the case if you set the RA lifetime to zero. To cite explicitly, RFC4861 says, Right... I oversimplified the point I was attempting to make and you called me on it... Move on. Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in Section 6 limit the lifetime to 9000 seconds. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default Narten, et al. Standards Track[Page 20] ^L RFC 4861 Neighbor Discovery in IPv6 September 2007 router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields. I was not making any statements about whether DHCPv6 could be selective about providing certain options to selected end-nodes. You might think I'm being overlay pedantic, however changing the question to then disagree with answer that doesn't agree with yours is being disingenuous. There are real environments where it's desirable to have a way to tell different clients on a network to use different default gateways or default gateway sets. I wouldn't necessarily disagree, although in my experience they're really quite rare, to the point where segmenting them into a separate subnet, via e.g. a different VLAN, becomes a somewhat better and easier option. While I would agree with you operationally, sometimes they involve software that discovers other devices by broadcast and does not permit other mechanisms. I've seen environments where they're able to deal with this in IPv4 because of this flexibility in DHCPv4 and would be limited to static addressing in IPv6 because it lacks this ability. Owen
Re: ipv6 vs. LAMP
Hi all, the replication point is a good one, I did not think about that. However, I still believe that on the road to v6 adoption, databases are far from being our most pressing roadblock. Thanks all! Carlos On Fri, Oct 22, 2010 at 4:52 PM, Jerry B. Altzman jba...@altzman.comwrote: Only to you. on 10/22/2010 10:02 AM Carlos Martinez-Cagnazzo said the following: IMHO you should never, ever make your MySQL accesible over the public Internet, which renders the issue of MySQL not supporting IPv6 correctly mostly irrelevant. You could even run your MySQL behind your web backend using RFC1918 space (something I do recommend). Except for those of us who have to support applications based upon MySQL replication...in that case, we use IP-based access rules on a firewall in front, and on the host, and on the MySQL server itself. But we still need IP access to it. We could shade it all by using IPSec or VPN tunnels, but that's more administrative overhead, and MySQL replication is fragile enough without adding that. Moreover, if you need direct access to the engine, you can trivially create an SSH tunnel (You can even do this in a point-and-click way using the latest MySQL Workbench). SSH works over IPv6 just fine. See above about replication. Carlos //jbaltz -- jerry b. altzmanjba...@altzman.com www.jbaltz.com thank you for contributing to the heat death of the universe. -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
nocproject.org
Hello, For your information : http://www.nocproject.org NOC is an Operation Support System (OSS) for the Telco, Service provider and Enterprise Network Operation Centers (NOC). Written using Python language and utilizing the power of Django framework and PosgtreSQL database. NOC is open source and released under the terms of BSD LICENSE. Mail : pica8@gmail.com
Re: IPv6 fc00::/7 ??? Unique local addresses
Amen! On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell bickn...@ufp.org wrote: There are some folks (like me) who advocate a DHCPv6 that can convey a default gateway AND the ability to turn off RA's entirely. That is make it work like IPv4. I'd also love to turn off stateless autoconfig altogether and not be coerced to assign /64s to single LANs, which I am becoming convinced that it was a poor decision on the IETFs part. Stateless autoconfig works very well, It would be just perfect if the network boundary was configurable (like say /64 if you really want it, or /80 - /96 for the rest of us) cheers Carlos -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
Re: IPv4 sunset date revised : 2009-02-05
The idea was to observe and measure an (almost) all IPv4 network and its management/infrastructure costs, namely the one we got, not an IPv6 one, before the transition starts to muddy the waters significantly. -b On October 22, 2010 at 18:03 bmann...@vacation.karoshi.com (bmann...@vacation.karoshi.com) wrote: On Fri, Oct 22, 2010 at 01:28:24PM -0400, Barry Shein wrote: It occurs to me that there is some pressing need to investigate this all-IPv6 internet -- motivated by the cost of (not) maintaining IPv4 forever. Right now we can observe essentially an all-IPv4 internet (99%, whatever.) -- -Barry Shein For this, you need to leave the comfort of NANOG and look at the CERNnet network over the past ten years. They have been running a large, all IPv6 network for some time now. http://www.authorstream.com/Presentation/Cannes-19148-IPv6-development-China-Outline-Efforts-CERNET-History-Testbed-1-2-3-4-5-Next-Generation-Inter-in-as-Entertainment-ppt-powerpoint/ www.cs.princeton.edu/~yiwang/papers/iscc05.pdf http://www.cernet2.edu.cn/en/char.htm --bill -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
RE: IPv6 fc00::/7 ??? Unique local addresses
Stateless autoconfig works very well, It would be just perfect if the network boundary was configurable (like say /64 if you really want it, or /80 - /96 for the rest of us) Why do you feel it's a poor decision to assign /64's to individual LANs? Best Regards, Nathan Eisenberg
Re: IPv6 fc00::/7 ??? Unique local addresses
On Oct 23, 2010, at 8:03 AM, Carlos Martinez-Cagnazzo wrote: Amen! On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell bickn...@ufp.org wrote: There are some folks (like me) who advocate a DHCPv6 that can convey a default gateway AND the ability to turn off RA's entirely. That is make it work like IPv4. I'd also love to turn off stateless autoconfig altogether and not be coerced to assign /64s to single LANs, which I am becoming convinced that it was a poor decision on the IETFs part. Nah... The /64 thing is fine. If they hadn't done that, we likely would have only a 64-bit address space total. 64-bit lans with 64-bit routing identifiers are fine. What would be nice would be if we changed the semantics a bit and made it 16+48+64 where the first 16 of the dest+source could be re-assembled into the destination ASN for the packet and the remaining 48 identified a particular subnet globally with 64 for the host. Unfortunately, that ship has probably sailed. Stateless autoconfig works very well, It would be just perfect if the network boundary was configurable (like say /64 if you really want it, or /80 - /96 for the rest of us) There really is no need for anything smaller than /64. What, exactly, do you think you gain from a smaller netmask? Owen
