Re: using reserved IPv6 space
Hi, On Sat, 2012-07-14 at 17:02 -0700, Owen DeLong wrote: Hi, We use LLA to virtualize interconnection to our users: their network configuration is always static default via fe80:: and we route their /56 prefix to fe80::: where : is unique per user - if our user want to do some routing of course. Since we don't have GUA interconnections we don't have to manage them inside our AS and we can move user stuff around without having them changing anything to their static configuration. We give a /56 IPv6 per /32 IPv4 to our user which does /48 = /24 = 256 IP, it's nice to have more than one /64 around for some uses. Is there any mass hoster around that does provide by default a pefix larger than /64 and that does route it to the user? It's quite simple to do in IPv6 and we have the address space for it. Why not just give each end-site a /48? We give a /48 on request, a /56 by default (and we never give a /64). An end-site with a /24 may only need a single or a few subnets while an end-site with a /32 may have a host of subnets behind their IPv4 NAT gateway. Making IPv6 topological assumptions for your end-users based on their IPv4 presentation makes little sense to me and is likely a disservice to your end users. The /56 subnets we give are for single machine in a rack, virtual machine in a cluster or home router. http://www.tunnelbroker.net/ gives by default /64 to a home router and /48 on request we just decided to give /56 by default and /48 on request. Sorry if I wasn't clear in my first message. Is there an agreed upon definition of end site? Sincerely, Laurent
Re: using reserved IPv6 space
On Sun, Jul 15, 2012 at 09:50:39AM +0200, Laurent GUERBY wrote: Sorry if I wasn't clear in my first message. Is there an agreed upon definition of end site? Sincerely, Laurent this might help. seems like these folks have general agreement on terms. NANOG-critters might have different points of view. http://www.cio.gov/documents/2012_IPv6_Roadmap_FINAL_20120712.pdf /bill
Re: using reserved IPv6 space
On 2012-07-15 00:45, Tony Hain wrote: There is no difference in the local filtering function, but *IF* all transit providers put FC00::/7 in bogon space and filter it at every border, there is a clear benefit when someone fat-fingers the config script and announces what should be a locally filtered prefix (don't we routinely see unintended announcements in the global BGP table). I realize that is a big IF, but There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6. -- Grzegorz Janoszka
Re: using reserved IPv6 space
On Jul 15, 2012, at 12:50 AM, Laurent GUERBY wrote: Hi, On Sat, 2012-07-14 at 17:02 -0700, Owen DeLong wrote: Hi, We use LLA to virtualize interconnection to our users: their network configuration is always static default via fe80:: and we route their /56 prefix to fe80::: where : is unique per user - if our user want to do some routing of course. Since we don't have GUA interconnections we don't have to manage them inside our AS and we can move user stuff around without having them changing anything to their static configuration. We give a /56 IPv6 per /32 IPv4 to our user which does /48 = /24 = 256 IP, it's nice to have more than one /64 around for some uses. Is there any mass hoster around that does provide by default a pefix larger than /64 and that does route it to the user? It's quite simple to do in IPv6 and we have the address space for it. Why not just give each end-site a /48? We give a /48 on request, a /56 by default (and we never give a /64). An end-site with a /24 may only need a single or a few subnets while an end-site with a /32 may have a host of subnets behind their IPv4 NAT gateway. Making IPv6 topological assumptions for your end-users based on their IPv4 presentation makes little sense to me and is likely a disservice to your end users. The /56 subnets we give are for single machine in a rack, virtual machine in a cluster or home router. http://www.tunnelbroker.net/ gives by default /64 to a home router and /48 on request we just decided to give /56 by default and /48 on request. Sorry if I wasn't clear in my first message. Is there an agreed upon definition of end site? Not exactly, but, there is now an ARIN definition for ARIN address policy. An end site (IIRC since I wrote the ARIN definition) is a single building or structure or a single tenant in a multi-tenant building or structure. So, if you have a university campus with 23 buildings, that might be 23 end sites. However, if one of them is a dormitory which has 100 rental units, that would up the end-site count to 122. If one of those buildings houses the math department, the physics department, and the science department, that might bring the total up as high as 124. Make sense? Owen
Re: Real world sflow vs netflow?
On Sat, Jul 14, 2012 at 10:30:25AM +0200, ?ukasz Bromirski wrote: NetFlow supports [ .. ] As well as L2 traffic (v9) [ .. ] Let's be real and speak implementations: where is L2 information in NetFlow for routed traffic on bigger platforms typically thrown for peering at internet exchanges - ASR9K, C7600 (ie. hopefully without get to invest more money in such platform to upgrade to Sup2T), MX, CRS? Cheers, Paolo PS: Let's not return on the point of availability of MAC accounting, since that is not the solution.
Re: using reserved IPv6 space
On 7/15/12 5:38 AM, Grzegorz Janoszka wrote: On 2012-07-15 00:45, Tony Hain wrote: There is no difference in the local filtering function, but *IF* all transit providers put FC00::/7 in bogon space and filter it at every border, there is a clear benefit when someone fat-fingers the config script and announces what should be a locally filtered prefix (don't we routinely see unintended announcements in the global BGP table). I realize that is a big IF, but There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6. Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So while FE00::/7 may yet be unallocated, I don't think I'd set filters in that fashion. Reasonably, wouldn't it be more likely to permit BGP advertisements within the 2000::/3 range as that's the active space currently? Scott
Re: using reserved IPv6 space
On Jul 15, 2012 9:30 AM, Scott Morris s...@emanon.com wrote: On 7/15/12 5:38 AM, Grzegorz Janoszka wrote: On 2012-07-15 00:45, Tony Hain wrote: There is no difference in the local filtering function, but *IF* all transit providers put FC00::/7 in bogon space and filter it at every border, there is a clear benefit when someone fat-fingers the config script and announces what should be a locally filtered prefix (don't we routinely see unintended announcements in the global BGP table). I realize that is a big IF, but There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6. Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So while FE00::/7 may yet be unallocated, I don't think I'd set filters in that fashion. Reasonably, wouldn't it be more likely to permit BGP advertisements within the 2000::/3 range as that's the active space currently? Scott Yep. That's what we do, permit 2000::/3, with a deny statement for the documentation range and small prefixes. CB
IPv6 Toolkit v1.2: Latest snapshot, and git repo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, I've posted a snapshot (tarball) of my working copy of the IPv6 toolkit. The tarball is available at: http://www.si6networks.com/research/ipv6-toolkit-v1.2.tar.gz Additionally, I've created a git repository for the toolkit, such that collaboration is improved. The git repo is available at: https://github.com/fgont/ipv6-toolkit.git If you have access to a Mac OS box, please try to compile the tools, and let me know if you find any errors (or let me know if they compiled cleanly). If you can also run the tools according to some of the examples in the manuals (and report any problems), that would be great, too. P.S.: If you've sent patches and your patches have not yet been applied, most likely it just means that I'm catching-up with them (feel free to resend!). Thanks! Best regards,-- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQAtn3AAoJEJbuqe/Qdv/xYIgH+wTQXJ3iNEnGnA0cMazS32py 3HfTdcMaEphnfF2a15dq1h/uqF05g3t9KqU744A1XmMtDlChvQ2I77uj2amqaeKi dED6e/NTuVAxTAI0ZTPIEn7BkDgtqvhuaoth+E4SX73lJC9eJR7e3T3BAtbESZaQ Sp67lvtgYmqogDc0IQALGNucyhHmacfUBocVLVgmVPn8BwdFxHI80W+Vc6TnKfjm Yc9ijgUPLTu0hOGD4bpOeQ2V3Dzw9PW17PyJlPr3TzWLzb8g64/zZROtHjXl/V4s 0JNAZVrHNDvA7kfEujzsoLcnQLCfq3+jzecvXcGwgsYMDXRBL8Lv628OAhrVglY= =Z3+1 -END PGP SIGNATURE-
Re: using reserved IPv6 space
On Sat, Jul 14, 2012 at 09:48:49PM -0400, Robert E. Seastrom wrote: Actually, that's one of the most insightful meta-points I've seen on NANOG in a long time. There is a HUGE difference between IPv4 and IPv6 thinking. We've all been living in an austerity regime for so long that we've completely forgotten how to leave parsimony behind. Even those of us who worked at companies that were summarily handed a Class B when we mumbled something about internal subnetting have a really hard time remembering how to act when we suddenly don't have to answer for every single host address and can design a network to conserve other things (like our brain cells). Addresses no longer being scarce is a significant shift, but this thread is about a lot more than that. I didn't get the feeling that the original poster was wanting to use non-global addresses on his internal links because he was concerned about running out. He also wanted to do so for purposes of security. And that's not a paradigm shift between v4 and v6. Obscurity / non-global address magic was pretend security in v4 and it's pretend security in v6. People who used RFC1918 space where they didn't need global uniqueness in v4 often did so initially because of scarcity (and were often making a completely reasonable decision in doing so), but they then falsly imputed a security benefit to that. If we can leverage the v6 migraton to get out of the thinking that some addresses are magically more secure than others, then that's probably a win, but it's not a fundamental difference between v4 and v6. It's not that correct IPv4 thinking is 1918 is more secure but the security model of v6 is different. 1918 was never more secure. -- Brett
Re: using reserved IPv6 space
On Sat, 14 Jul 2012 17:37:37 -0500, Jimmy Hess said: The good news is one 'ifconfig' just tells them what network address you're in. Unless the attacker can gain access to your host's NDP table or ARP table, they can't see what IPs are in use. All it takes is one USB stick left out in the parking lot for an employee.. By the time they get enough access to do an 'ifconfig', rest assured that they can see the NDP/ARP tables and all the traffic on that network segment as well. (OK.. maybe for some reason they can't - but if you're betting your security model on somebody getting a beachhead on one of your machines and *not* having full access to the network segment, I'll be more than happy to take the other side of the bet). pgpcHrB5hxJD3.pgp Description: PGP signature
Re: using reserved IPv6 space
On 2012-07-15 15:30, Scott Morris wrote: There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6. Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So while FE00::/7 may yet be unallocated, I don't think I'd set filters in that fashion. Reasonably, wouldn't it be more likely to permit BGP advertisements within the 2000::/3 range as that's the active space currently? FF00::/8 are multicast, FE80::/10 are reserved for link-local. In the past you had FEC0::/10 as a kind of private addresses. Allowing 2000::/3 is fine as well. Btw - what are the estimates - how long are we going to be within 2000::/3? -- Grzegorz Janoszka
Re: using reserved IPv6 space
On 15 July 2012 16:58, Grzegorz Janoszka grzeg...@janoszka.pl wrote: Allowing 2000::/3 is fine as well. Btw - what are the estimates - how long are we going to be within 2000::/3? I expect it to be long enough that we can enjoy lots of discussions about how to deal with broken route filtering and broken software that assumes only 2000::/3 is valid, and we can talk about how we should have seen this coming and done something differently to prevent it. - Mike
Re: using reserved IPv6 space
On Jul 15, 2012, at 8:58 AM, Grzegorz Janoszka wrote: On 2012-07-15 15:30, Scott Morris wrote: There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6. Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So while FE00::/7 may yet be unallocated, I don't think I'd set filters in that fashion. Reasonably, wouldn't it be more likely to permit BGP advertisements within the 2000::/3 range as that's the active space currently? FF00::/8 are multicast, FE80::/10 are reserved for link-local. In the past you had FEC0::/10 as a kind of private addresses. Allowing 2000::/3 is fine as well. Btw - what are the estimates - how long are we going to be within 2000::/3? Quite probably longer than anyone now reading this message will be alive. So far, I believe IANA has allocated 6 or 7 of the /12s from 2000::/3 to RIRs. That leaves at least 500+ /12s still to go. Even with ARIN's extremely liberal policies, I expect ARIN will be able to number all of their service region in its current state from 3 or 4 /12s. Assuming this somewhat follows world population, APNIC should require =12 /12s, RIPE should need = 6 /12s, AfriNIC should require = 6 /12s, and LACNIC should require = 4 /12s. Adding that up, I get 4+12+6+6+4 = 32 /12s if the entire world were to adopt ARIN's extremely liberal (which I think is a good thing) IPv6 allocation policies. Assuming that the world population (and thus address need) continues on a 1.5% per year growth trajectory, that would double the population every 46+ years. With a lifespan of ~100 years and assuming that everyone reading this is now over the age of 10, that's 4*32 = 128 /12s in the next 92 years, leaving us with 384 /12s still sitting on the shelf after the last of us now reading this message is dead. So, even if I'm wrong and it's 3 times what I anticipate, we still won't use up 2000::/3 in any of our lifetimes. Owen
Re: Real world sflow vs netflow?
On 14/07/2012 09:30, Łukasz Bromirski wrote: And that's the biggest problem with sFlow. Packets are sampled, not flows. You may miss the big or important flow, you don't have visibility into every conversation going through the device. Unless you enable sampling, which is pretty much necessary for non-trivial traffic volumes. NetFlow supports IPv6. As well as L2 traffic (v9), MPLS, multicast and so on. It does, depending on hardware variety, but you need specific platform support for each packet variety (v4 / v6 / mpls / etc), and platform support for this can be very dodgy. You don't need this with sflow - it just punts 1 in N raw packets out to your collector, and the statistical assumptions which were made by the networking device are well documented. I've never seen documentation on the sampling technique used for each netflow implementation. The measurements provided by sFlow are only approximation of the real traffic and while it may be acceptable on LAN links where details don't matter as much, it's hardly good enough to present a real view on the WAN links. sFlow was built to work on switches and provide some accuracy, it's not good enough (unless you do sampling on a 1:5-1:10 basis) to do billing or some detailed analysis of traffic: Depends on how detailed your requirements are. For billing, most people don't classify by packet analysis, but rather by byte count which can be handled by snmp port counters. If you need to do something fancier, non-sampled netflow is indeed good enough for billing. http://www.inmon.com/pdf/sFlowBilling.pdf You can use it to *estimate* the traffic, detect DDoS, sure. But the data scaling used by sFlow (and additionally tricks used by ASIC vendors implementing it in the hardware) can't change the fundamental difference - sFlow is really sPacket, as it doesn't deal with flows. agreed, the name is wrong. NetFlow, jFlow, IPFIX deal with flows. You can discuss sampling accuracy and things like that, but working with flows is more accurate. Depends on your use case. For large traffic values, you run into the law of large numbers and you can get accurate visibility into what's happening on your network. Certainly, netflow _can_ offer amazingly precise visibility into your network. But the trade-off is that you need specialised hardware to do this on your line cards or your forwarding engine. This drives up both the capex (extra hardware) and the opex (tcam is power hungry) of your network. sflow is much cheaper to implement as you're not maintaining any state on your chassis. You're just picking out a packet every so often. The current generation of high end service provider hardware (juniper mx-3d, cisco sup2t / n7k / asr9k) is pretty much the first generation of hardware which doesn't have crippling netflow limitations, such as poor support for v6 / mpls, too small cache sizes, etc. This fact alone should provide a good indication of how difficult it is to implement it well on fast boxes. sflow is simpler, cheaper and in many cases is simply a better choice if you don't need drill-down into every single flow going through your networking. Nick
Re: using reserved IPv6 space
On 7/15/12 11:58 AM, Grzegorz Janoszka wrote: On 2012-07-15 15:30, Scott Morris wrote: There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6. Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So while FE00::/7 may yet be unallocated, I don't think I'd set filters in that fashion. Reasonably, wouldn't it be more likely to permit BGP advertisements within the 2000::/3 range as that's the active space currently? FF00::/8 are multicast, FE80::/10 are reserved for link-local. In the past you had FEC0::/10 as a kind of private addresses. Allowing 2000::/3 is fine as well. Btw - what are the estimates - how long are we going to be within 2000::/3? hehehhe.. Long enough for us to forget what prefix lists we put on to begin with and need to look them back up!
Re: using reserved IPv6 space
Ifconfig does not work on Windows. Are you saying that there are other operating systems brain-dead enough to just run any old arbitrary code from untrusted media? Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: [valdis.kletni...@vt.edu] Received: Sunday, 15 Jul 2012, 9:45 To: Jimmy Hess [mysi...@gmail.com] CC: [nanog@nanog.org]; Brandon Ross [br...@pobox.com] Subject: Re: using reserved IPv6 space On Sat, 14 Jul 2012 17:37:37 -0500, Jimmy Hess said: The good news is one 'ifconfig' just tells them what network address you're in. Unless the attacker can gain access to your host's NDP table or ARP table, they can't see what IPs are in use. All it takes is one USB stick left out in the parking lot for an employee.. By the time they get enough access to do an 'ifconfig', rest assured that they can see the NDP/ARP tables and all the traffic on that network segment as well. (OK.. maybe for some reason they can't - but if you're betting your security model on somebody getting a beachhead on one of your machines and *not* having full access to the network segment, I'll be more than happy to take the other side of the bet). Sent from my Android phone using TouchDown (www.nitrodesk.com)
Re: using reserved IPv6 space
Ifconfig does not work on Windows. i am about as far from a windows expert as you can get. but i believe it is ipconfig Are you saying that there are other operating systems brain-dead enough to just run any old arbitrary code from untrusted media? Sent from my Android phone ROFL! randy
Re: using reserved IPv6 space
On 7/15/12, Keith Medcalf kmedc...@dessus.com wrote: Ifconfig does not work on Windows. Who needs ifconfig with windows? any user who can open a cmd session can run IPCONFIG /ALL The same can be queried remotely using WMI Select * From Win32_NetworkAdapterConfiguration WHERE IPEnabled=true Are you saying that there are other operating systems brain-dead enough to just run any old arbitrary code from untrusted media? That depends... what do you mean by untrusted media? Many OSes, even certain versions of Linux that support Firewire can be coerced into running arbitrary code, by plugging in a malicious firewire device, unless there is an IOMMU or other measures protecting against malicious memory access when a DMA is requested Various hardware devices, and drivers have vulnerabilities, even without 'autoplay'. And some *ix distros do support 'autoplay-like' functionality. Sent from my Android phone using TouchDown (www.nitrodesk.com) -- -JH
Re: Re: using reserved IPv6 space
On Sun, 15 Jul 2012 17:55:44 -0600, Keith Medcalf said: Are you saying that there are other operating systems brain-dead enough to just run any old arbitrary code from untrusted media? As Vint Cerf pointed out, 140 million pwned boxes. How you think they got that way, and what are the chances that *none* of them are inside your net? pgpByZuyt6QZg.pgp Description: PGP signature
Re: using reserved IPv6 space
On 7/14/12, Robert E. Seastrom r...@seastrom.com wrote: Actually, that's one of the most insightful meta-points I've seen on NANOG in a long time. There is a HUGE difference between IPv4 and IPv6 thinking. We've all been living in an austerity regime for so long that we've completely forgotten how to leave parsimony behind. Even those of us who worked at companies that were summarily handed a Class B when we mumbled something about internal subnetting have a really hard time remembering how to act when we suddenly don't have to answer for every single host address and can design a network to conserve other things (like our brain cells). Suggestions? I feel like I should be able to do something really nice with an absurdly large address space. But lack of imagination or whatever.. I haven't come up with anything that really appeals to me. Thanks, Lee -Hammer- bhmc...@gmail.com writes: bashes head against wall Thank you all. It's not the protocol that hurts. It's rethinking the culture/philosophy around it. -Hammer- On 7/14/12 3:20 PM, Owen DeLong o...@delong.com wrote: They're a bad thing in IPv6. The only place for security through obscurity IMHO is a small round container that sits next to my desk. Besides, if you don't advertise it, a GUA prefix is just as obscure as a ULA prefix and provides a larger search space in which one has to hunt for it... Think /3 instead of /8. Owen On Jul 14, 2012, at 1:14 PM, -Hammer- wrote: Guys, The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6? On 7/13/12 8:41 PM, Brandon Ross br...@pobox.com wrote: On Fri, 13 Jul 2012, Owen DeLong wrote: On Jul 13, 2012, at 4:24 PM, Randy Bush wrote: keep life simple. use global ipv6 space. randy Though it is rare, this is one time when I absolutely agree with Randy. It's even more rare for me to agree with Randy AND Owen at the same time. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
Re: using reserved IPv6 space
I feel like I should be able to do something really nice with an absurdly large address space. But lack of imagination or whatever.. I haven't come up with anything that really appeals to me. Use a fresh IP for every HTTP request, email message, and IM. Just think of how well you can do error management. R's, John
