Redundant multicast routing
Hi What's your recipe to implement redundant multicast (stub) routing? Let's think about the simplest scenario. We have 2 routers, R1 and R2 and 3 ip networks. All 3 networks are directly connected to both routers and the routers are performing unicast routing between networks using VRRP as the redundancy protocol. Let's disregard L2 redundancy here and assume it works. Same goes with igmp snoop. net1: 192.168.1.0/24, VRRP .254, R1 .1, R2 .2 net2: 192.168.2.0/24, VRRP .254, R1 .1, R2 .2 net3: 192.168.3.0/24, VRRP .254, R1 .1, R2 .2 Say multicast source is in net1 and receiver in net2. If I did not need redundancy in multicast, I would just configure all interfaces on R1 as pim passive and it would (probably) work. But if I want the multicast routing to be redundant, what should I do? If I add the R2 interfaces as pim passive, the multicast is forwarded to net2 (and net3) twice because R1 and R2 do not know about each other. I tested this. If I configure all R1 and R2 interfaces as pim dense, the destination receives multicast fine, but it is flooded between R1 and R3 2 or 3 times (because pim dense floods the multicast to all pim neighbors and R1 and R2 are pim neighbors in all 2 networks). So, core links are unnecessarily consumed. I tested this, too. One choice could be to use pim sparse and configure R1 and R2 to be anycast RPs using loopback interface and configure MSDP peering between them. But given the simplicity of the topology, this seems unnecessarily complex configuration. I have not tested this yet. Maybe MVR could be solution but I think it will cause stream multiplication too. I have not tested MVR yet either. I would like to keep the recipe as vendor agnostic as possible. Thanks for help :)
Re: HP A-series, H3C, Huawei and their capabilities in real-life
My apologies for using gmail. Company policy prohibits the use of corporate email and identity. Nobody has heard nothing? Hear no evil… ;) What we basically have at this point is vendor specifications, sales talk and rumors that big boys have built large networks using these boxes (or predecessors of them, i.e. Huawei) especially in Asia and former Soviet countries. There are also some western references such as BT. With BT the references only mention Huawei, not HP. Does Huawei still sell (wired) routers under their own brand? Or is the BT reference network consisting purely of mobile stuff, (UMTS etc) and does not include traditional wired infrastructure (IP/BGP/MPLS routers)? Or is the HP's acquisition so new that the references are only mentioning Huawei? This resembles detective's work :) The price of these boxes is quite attractive, but there are lots of buts. For example, how much do they have in common with Huawei boxes? Traditionally HP networking gear excluding basic pizzabox switches has not been very convincing. Even comment like they suck, stay away from them would be very valuable.
Re: quietly....
On Wed, 2 Feb 2011 15:18:55 -0500 John Payne j...@sackheads.org wrote: On Feb 2, 2011, at 3:12 PM, Iljitsch van Beijnum wrote: On 2 feb 2011, at 20:37, John Payne wrote: DHCP fails because you can't get a default router out of it. If you consider that wrong, I don't want to be right. Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong. I said the IETF wants input. In case you hadn't noticed, I'm not the IETF. I don't represent them in any way. I'm not even a working group chair. I've gone to a bunch of meetings, spent way too much time on IETF mailinglists and co-wrote all of one RFCs. You may not represent the IETF, but you are representative of the attitude of the IETF. And I'm afraid you're representative of the IPv4 thinking attitude, that seems to believe that the past IPv4 ways are not just the only ways of solving a problem but are also naturally the best. They also seem assume that the way IPv6 is going to be used is exactly the same as IPv4, so the IPv4 methods will be perfect in all IPv6 applications. It's a bit of a shame that people who've gotten into networking in the last 10 to 15 years haven't studied or worked with anything more than IPv4. They've missed out on seeing a variety of different ways to solve the same types of problems and therefore been exposed to the various benefits and trade-offs of the different methods. With that sort of exposure, people may find out that there are other better ways to solve problems, but IPv4's limitations and constraints prevented them being possible. I read some great writing advice once. It applies to much more than just writing. It goes like this: whenever a reader tells you that there's something wrong with your book, there is something wrong with your book. But if they tell you how to fix it, they're pretty much always wrong. There's something wrong with your attitude towards operators. There's a lot wrong with the IETF attitude towards operators, but you're here :) I'm not part of the DHC working group and I'm not a big DHCP user myself, so I don't claim to know the issues that exist with DHCPv6 in the operational community. But I'm sure there are some valid issues there. However, I'm equally sure that adding IPv4-DHCP-style router addresses to DHCPv6 is a big mistake that will create a lot of operational problems. Maybe not in the networks of the people that want this feature, but the problems will be there. Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems. Why do we need mommy-IETF telling us no for default routes in DHCP but letting RAs run wild? Why does the mere mention of NAT cause daddy-IETF to round up the troops and insist that everyone is wrong?
Re: quietly....
On Wed, 2 Feb 2011 07:04:13 -0800 Owen DeLong o...@delong.com wrote: On Feb 2, 2011, at 6:43 AM, Jack Bates wrote: On 2/2/2011 8:22 AM, Tony Finch wrote: Counterexample: rogue RAs from Windows boxes running 6to4 or Teredo and Internet Connection Sharing. This is a lot harder to fix than a misconfigured DHCP server. CounterCounterexample: rogue DHCPv6 servers from windows boxes or improperly connected CPEs. Both DHCP(4 or 6) and RA require careful filtering to keep rogues from jacking things up. Though M$ has a nice deployment for authorizing DHCP4 servers in corporate environments. It's a lot easier to find and eliminate a rogue DHCP server than a rogue RA. How is that the case? The next hop for the default gateway that the rogue RA installs is the link local address, you look up the neighbor cache if the link local address doesn't have a MAC address in it, and then use layer 2 information to identify where it is attached. That's also the usual technique for finding and disabling a rogue DHCP server, so how is it any harder? Mark
Re: /64 is enough until 2021 for 90% of users (was Re: Another v6 question)
On Thu, 27 Jan 2011 11:03:41 -0500 Jared Mauch ja...@puck.nether.net wrote: On Jan 27, 2011, at 10:04 AM, Owen DeLong wrote: On Jan 27, 2011, at 6:49 AM, Jared Mauch wrote: On Jan 26, 2011, at 8:33 PM, Owen DeLong wrote: I'd like to see IPv4 go away in ~3 years. Any faster would be too traumatic. I think 6 years is a perfectly reasonable time frame. I think if it takes 11 years it will be because of significant foot-dragging by some key organizations. I'm not convinced that foot-dragging is as likely as some people are, but, there's enough probability to provide some wiggle room in the numbers. I expect that in ~3 years, we will see dual-stack and /64's handed out in conjunction with an IPv4 address as common. The ipv6 zealots talking about anything but a /64 for end-site are talking about a business class service. Even with my static IPs at home, I have no need for more than a single /64 to be used in my wildest dreams. I could live with ~256 ips for the future. I consider my tech density above-average. - Jared As one of the IPv6 zealots talking about anything but a /64 for end sites, I can assure you that I am talking about it for residential class service not business class. Your tech density may be above average for today, but, you lack vision for the future. Imagine a future where devices form autonomous network segments and negotiate prefixes and routing for those segments in a semi- or fully- autonomous fashion. The appliance net in the kitchen will be managed by a router. The RFID tags on the products in your fridge and your pantries will form autnonous subnets with routers embedded in the fridge and pantries. Each of your home entertainment clusters will likely form its own subnet. Even today, it is not uncommon for a residential gateway to support at least five segments: 1. External WAN segment shared with ISP 2. Internal wired network 3. Internal wireless network 4. DMZ segment 5. Guest wireless network Seriously, it's important that we do not limit our IPv6 thinking by our IPv4 mindset. The future is not the present and we will see much more advanced capabilities in the residential world going forward if we allow it to happen. I'm not. There's certainly interesting use cases of this IP header type, independent of being v4 or v6. You're talking about the various segments, and I'm thinking about the folks from Toyota doing their ipv6 local networks integrated into vehicles. But many people are also stuck in thinking that these people need to be segmented in the first place. This security by obscurity mentality that being behind a VPN, being air-gapped, wired, wireless, that you are deserving of a variable class of service is part of the discussion. I could call out vendors that have highly sensitive data that is available if only you brought a cat5 cable to the office vs using their guest wireless. that segmentation ignores the authentication of end-stations, or person behind the keyboard. If you actually did that, you don't need to have a different 'guest' wireless vs the 'internal' wireless network. Now, I don't think that by reading this that an enterprise is going to clean up their act, (wired vs wireless), or stop any other silly practices using these packet eating firewall/nat/vpn devices. But tying those practices in to the equation can serve to validate the premise that these people actually need to be segmented vs solving the real security (trust) problem that exists on the end devices. You don't necessarily need to see my AppleTV on my home network, but as a guest at my home, (after authenticating to my local wireless network) you gain access to play music and control various elements of my network. I don't need to make these public, but if they are on a public-IP, the devices should be able to be properly secured (and can be). I don't think I need a public and private FridgeNet to determine the quantity and quality of the beverages and offer different SLAs based on if they are on the 'guestFridgeNet' vs 'privateFridgeNet'. This is taking it a step or three too far. Most people don't know or care what their IP subnet is. Even if every time I connected a device to my network (or re-connected after power saving, etc) I incremented the usable part of my /64, it would take me some time to consume that space fully. I do think we're closer together than apart, but for 90% of home users, (and you can quote me on this in 10 years) a /64 will be sufficient for their uses. Anyone needing more than a /64 for their home is either going to some impractical extreme or better defined as a prosumer that will want a higher SLA in the first place, and therefore should pay a modest amount more. ' I think you need to review what
Re: Another v6 question
On Thu, 27 Jan 2011 09:20:01 -0600 Max Pierson nmaxpier...@gmail.com wrote: I'm not missing your point. I'm saying that in IPv6, we've put enough addresses in to allow for things nobody has thought of in 30, 60, 90, even 100 years and then some. As Roland said, Possibly, as long as we don't blow through them via exercises in profligacy nobody has heretofore thought of, heh. If I knew, then, I'd be well on my way to much greater wealth. Whatever it is, I am only certain of the following things about it: 1. We have no idea what the requirements will be at this time. I believe it was Donald Rumsfeld that said... But there are also unknown unknowns – the ones we don't know we don't know. What if that unknown comes in the form of mass address consumption? But from your view, that's not possible, so i'll just move on. We know both what the IPv6 addressing architecture is and what the current IANA/RIR etc. addressing policies are - nothing is an unknown unknown. *Unexpected* mass address consumption is not possible unless and until the current addressing policies change. It is only those who wish to play thought games with how they could abuse 128 bit addresses that are pretending these architectural decisions and policies don't exist and won't be enforced. Mark
Re: Using IPv6 with prefixes shorter than a /64 on a LAN
On Tue, 25 Jan 2011 07:02:30 +0100 (CET) sth...@nethelp.no wrote: IPv6 is classless; routers cannot blindly make that assumption for performance optimization. Blindly, no. However, it's not impractical to implement fast path switching that handles things on /64s and push anything that requires something else to the slow path. Any vendor who was stupid enough to do *hardware* switching for up to /64 and punted the rest to software would certainly not get any sales from us. Actually, they'd most likely punt the rest to exact match rather than longest match cams. Exact match cams are cheaper because they're simpler, and have been made even more so because they've been for more than a decade layer 2 switches, and they're are far many more of them than there are routers. 128 bits. No magic. magic is another way of describing progress. Electric start cars would have been magic to owners of Motorwagens.
Re: Using IPv6 with prefixes shorter than a /64 on a LAN
On Tue, 25 Jan 2011 16:32:59 -0500 Ricky Beam jfb...@gmail.com wrote: On Tue, 25 Jan 2011 13:42:29 -0500, Owen DeLong o...@delong.com wrote: Seriously? Repetitively sweeping a /64? Let's do the math... ... We've had this discussion before... If the site is using SLAAC, then that 64bit target is effectively 48bits. And I can make a reasonable guess at 24 of those bits. (esp. if I've seen the address of even one of the machines.) All you're really pointing out is security is a relative term. A lot of these threads devolve in to a waste of time because they're discussing the pros and cons of a single, possible security mechanism without considering it in context (possible because if it ends up having no or very little security value it isn't really a security mechanism at all). The value of a security mechanism can only be judged in the context of both what threats they mitigate and whether those threats are ones that are common and likely in the context they might be used in. Security is a weakest link problem, so the first thing that needs to be done is to identify the weakest links, before worrying about how to fix them. So what threat are people trying to prevent? Address scanning is only a means to an end - so what is the end? Only once that is defined can it be worked out whether address scanning is a likely method attackers will use, and whether then preventing address scanning is an effective mitigation. Regards, Mark.
Re: Using IPv6 with prefixes shorter than a /64 on a LAN
On Wed, 26 Jan 2011 11:53:23 +0700 Roland Dobbins rdobb...@arbor.net wrote: On Jan 26, 2011, at 11:37 AM, Adrian Chadd wrote: But simply assuming that the IPv6 address space will forever remain that - only unique host identifiers - I think is disingenious at best. :-) I think 'disingenuous' is too strong a word - 'overly optimistic' better reflects the position, IMHO. ; In addition to all the extremely valid use-cases you outline, there's also the concept of one-time-use prefixes which likely will end up being used at the molecular level in manufacturing/supply-chain applications, lifetime assignments to individuals as a matter of citizenship which will be retired upon their deaths/disenfranchisement, nanite communications used to do things like clean plaque out of people's arteries in lieu of angioplasty, and a whole host of new applications we haven't even dreamed of, yet. The supreme irony of this situation is that folks who're convinced that there's no way we can even run out of addresses often accuse those of us who're plentitude-skeptics of old-fashioned thinking; whereas there's a strong case to be made that those very same vocal advocates of the plentitude position seem to be assuming that the assignment and consumption of IPv6 addresses (and networking technology and the Internet in general) will continue to be constrained by the current four-decade-old paradigm into the foreseeable future. The correct assumption is that most people will try and usually succeed at follow the specifications, as that is what is required to successfully participate in a protocol (any protocol, not just networking ones). IPv4 history has shown that most people will. People who argue against current Ipv6 address use projections are doing so with an unstated assumption that most people won't follow the specifications. Once you make that assumption, then anything at all can be used as an example to created FUD about running out of addresses, including the equally valid example that people will close their eyes and bash the number pad when entering IPv6 prefix or address information. The only way to prevent absolutely the misconfiguration of protocol parameters is to not make them configurable. Pretty much impossible to do with networking prefixes or addresses.
Re: Using IPv6 with prefixes shorter than a /64 on a LAN
On Wed, 26 Jan 2011 12:49:13 +0700 Roland Dobbins rdobb...@arbor.net wrote: On Jan 26, 2011, at 12:33 PM, Mark Smith wrote: The correct assumption is that most people will try and usually succeed at follow the specifications, as that is what is required to successfully participate in a protocol (any protocol, not just networking ones). IPv4 history has shown that most people will. Specification application, as in new applications. And, no, I don't think that 'most people will' - I've seen enough foolishness with regards to IPv4 misaddressing over the last quarter-century (pre- and post-CIDR) to share your optimism in that regard. The Internet works most of the time doesn't it? I think that is evidence that most people get it right most of the time, and that misaddressing has minimal if any effect because it is ignored as non-complaint with the Internet's protocols (both implementation and operational ones). Usually the consequences of misaddressing are limited to those who've performed it. Mark
Re: Is NAT can provide some kind of protection?
On Sun, 16 Jan 2011 00:12:26 -0500 Jim Gettys j...@freedesktop.org wrote: On 01/15/2011 06:30 PM, Mark Smith wrote: On Sat, 15 Jan 2011 18:06:06 -0500 (EST) Brandon Rossbr...@pobox.com wrote: On Sat, 15 Jan 2011, Brian Keefer wrote: Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6: You are neglecting the most important reason, much to my own disdain. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses. How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address? Can we *please* stop this pointless thread? I don't think it pointless to network operators - NAT or not has operational impacts on troubleshooting, network design, addressing plans etc. I understand you aren't a network operator, so if you're not interested perhaps you should unsubscribe. Thanks, Mark.
Re: Is NAT can provide some kind of protection?
On Sat, 15 Jan 2011 18:06:06 -0500 (EST) Brandon Ross br...@pobox.com wrote: On Sat, 15 Jan 2011, Brian Keefer wrote: Actually there are a couple very compelling reasons why PAT will probably be implemented for IPv6: You are neglecting the most important reason, much to my own disdain. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses. How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address? Since many residential users won't stand for an additional fee, pressure will be placed on CPE vendors to include v6 PAT in their devices. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
Re: Is NAT can provide some kind of protection?
On Sat, 15 Jan 2011 18:39:09 -0500 (EST) Brandon Ross br...@pobox.com wrote: On Sun, 16 Jan 2011, Mark Smith wrote: How do you know - have you asked 100% of the service providers out there and they've said unanimously that they're only going to supply a single IPv6 address? Huh? Who said anything about 100%? I think you did .. Service providers will continue to assign only a single IP address to residential users unless they pay an additional fee for additional addresses. It would take only a single reasonably sized provider that has a monopoly in a particular area (tell me that doesn't happen) or a pair of them that have a duopoly (almost everywhere in the US) and you instantly have huge incentive for someone to write some v6 PAT code. And that will create a huge incentive for people to acquire larger amounts of address space via other mechanisms, such as 6to4, tunnels, changing to another provider etc. Believe me, I'm the last person who wants to see this happen. It's a horrible, moronic, bone-headed situation. Unfortunately, I'm pretty sure it's going to happen because it's been the status quo for so long, and because some marketing dweeb will make the case that the provider is leaving revenue on the table because there will always be some customers who aren't clever enough to use NAT and will buy the upgraded 5 pack service. I'm confident the opposite will happen. People on this list and similar ones usually understand the value of more than one public address for a home, and commonly enough have routed subnets to their homes, courtesy of their employer, and have probably also been burnt by NAT. They'll be the ones who tell their management this is how IPv6 is deployed. If they're ignored, they should then say, and this is how our competitors will be deploying IPv6. Even though customers may not completely understand what they're getting, if one provider has a marketing bullet point of 1 IPv6 address, and another has a marketing bullet point of Millions of IPv6 addresses, people will just assume more is better and go with the latter. There is no point pretending IPv6 addresses are expensive or trying to make them artificially so.
Re: Is NAT can provide some kind of protection?
On Sat, 15 Jan 2011 18:21:52 -0600 Frank Bulk frnk...@iname.com wrote: I hope the engineers in the organization will just tell their marketing folk that it's not possible to hand out just one IPv6 address. Our hardware doesn't support it. I think there's still room for ISPs to charge $10/month for a static prefix, though. And that's technically possible. I think it is important to define what static means. My definition is that no matter where the customer's network attachment point moves to, the customer retains the same addressing while they have a continued commercial relationship with the SP - in effect PI address space within the SPs network. There is a fairly significant cost to preserving that, a guaranteed route table slot. This is typically a business product offering. The only other alternative people seem to think there is is dynamic, where every time the customer reconnects they may get different addressing. This is the typical residential product offering. I think there is a useful middle point of stable addressing, where as long as their point of attachment (or point of service delivery - i.e. their home) doesn't change, a customer would continue to get the same addressing. This idea wasn't as useful or as applicable in IPv4, but would be quite beneficial in IPv6 when DHPCv6-PD is being used. It wouldn't be an assured address assignment, however the SP would endeavour to try to ensure the addressing stays stable over quite long periods of time. It's common enough for LNS/BRASes to do this anyway if the customer's connection lands on the same one. The trick is to expand this stability over the group of all LNS/BRASes that customers can attach to when they reconnect, such that is a SP designed behaviour, rather than an implementation behaviour of each individual LNS/BRAS. Regards, Mark.
Re: World IPv6 Day
On Wed, 12 Jan 2011 11:10:03 -0800 Randy Bush ra...@psg.com wrote: the first global-scale trial of IPv6, the long-anticipated upgrade to the Internet's main communications protocol known as IPv4. this phrasing is both amusing and deeply sad. amusing because many folk have been running ipv6 globaly for over a decade. deeply sad because this is taken to be shiny and new as we approach the end of the iana ipv4 free pool. what have people been smoking? IPv4. Every now and then it is worth remembering that IPv4 was a protocol that was designed for a small experimental network that managed to escape into production. How long it has been usable is actually quite remarkable, and has only been achieved through a series of neat hacks like classes, subnets and CIDR. Regards, Mark.
Re: NIST IPv6 document
On Fri, 7 Jan 2011 14:53:02 -0800 Owen DeLong o...@delong.com wrote: On Jan 7, 2011, at 1:28 PM, Mark Smith wrote: On Fri, 7 Jan 2011 09:38:32 + Dobbins, Roland rdobb...@arbor.net wrote: On Jan 7, 2011, at 4:14 PM, Mark Smith wrote: Doesn't this risk already exist in IPv4? There are various vendor knobs/features to ameliorate ARP-level issues in switching gear. Those same knobs aren't viable in IPv6 due to the way ND/NS work, I was commenting on the mentality the OP seemed to be expressing, about *both* onlink and off link sources triggering address resolution for lots of non-existent destinations, and that this was a new and unacceptable threat. I think the offlink risk is a far more significant one. I think the onlink risk pretty much no worse than any of the other things that LAN attached devices can do if they choose to. and as you mention, the ND stuff is layer-3-routable. The issue isn't that ND is layer 3 routable - it isn't unless a router implementation is broken. The problem is that somebody on the Internet could send 1000s of UDP packets (i.e. an offlink traffic source) towards destinations that don't exist on the target subnet. The upstream router will then perform address resolution, sending ND NSes for those unknown destinations, and while waiting to see if ND NAs are returned, will maintain state for each outstanding ND NS. This state is what is exploitable remotely, unless the state table size is large enough to hold all possible outstanding ND NA entries for all possible addresses on the target subnet. I think this problem can be avoided by getting rid of this offlink traffic triggered address resolution state. The purpose of the state (from the Neighbor Discovery RFC) is two fold - - to allow the ND NS to be resent up to two times if no ND NA response is received to ND NSes. A number of triggering packets (e.g. UDP ones or TCP SYNs) are queued as well so that they can be resent if and when ND NS/NA completes. - to allow ICMP destination unreachables to be generated if the ND NS/NA transaction fails, even after resending. I think it is acceptable to compromise on these requirements. I'm inclined to agree with you, but... I think it might also make sense to eliminate the ND NS/NA transaction altogether for addresses that do not begin with ::::000x. In other words, for non SLAAC addresses, we need the ND NS/NA process (even if we do it stateless which isn't an entirely bad idea), but, for SLAAC addresses, the MAC is embedded in the IP address, so, why not just use that? I think then you'd only be able to avoid the issue by maintaining MAC/SLAAC only segments, with no stateful DHCPv6, privacy address or static addressed nodes, so that (stateful or stateless) ND NS/NA could be disabled. While it would work for those types of nodes, it wouldn't restore the properties we'd have to give up for the stateless ND NS/NA idea, as they need state to be performed, regardless of the destination address type. I think there are a variety of valid and legitimate reasons to preserve the ability to have different layer 3 and layer 2 node addresses, rather than 1-to-1 mapping them. Therefore I think an ideal solution to this problem solves it for all cases, rather than having different solutions or mitigations for different situations. With your suggestion, in theory a solution would now exist for point-to-point links via /127 configured prefix lengths and for MAC/SLAAC only LAN segments. Neither of those solutions can be used for stateful DHCPv6 segments, or segments where privacy addresses are useful and could be used - so we'd only be at 2 out of (at least) 4 situations to mitigate it. I think when you start going down the path of creating a number of different special cases with fairly different methods of addressing them, it is worth sitting back and saying is there a single general solution that will cover all cases. That is what has been done in IPv6 with ND address resolution, rather than having link specific methods of configuring and/or discovering IPv6 addresses (e.g. in IPv4 IPCP, ARP etc.), so if there is a solution that can be applied within ND address resolution, it automatically applies to all existing and future link types that IPv6 operates over. Regards, Mark.
Re: NIST IPv6 document
On Fri, 07 Jan 2011 07:11:42 -0500 Robert E. Seastrom r...@seastrom.com wrote: Kevin Oberman ober...@es.net writes: The next ship will be departing in a hundred years or so, advance registration for the IPv7 design committee are available over there. Sorry, but IPv7 has come and gone. It was assigned to the TUBA proposal, basically replacing IP with CLNP. IPv8 has also been assigned. (Don't ask as it involved he who must not be named.) In the grand tradition of list pedantry, I must correct both of these statements. :-) IPv7 was TP/IX, which I never really learned anything about (at least nothing that I can remember) at the time. IPv8 was PIP, which got merged with SIP to form SIPP which as I recall evolved into IPv6. It had nothing to do with he who must not be named, but you can't figure this out by googling IPv8 as all it returns is a series of links to flights of fancy. IPv9 was TUBA. Went down for political reasons, but in retrospect perhaps wouldn't have been such a bad thing compred to the second system syndrome design that we find ourselves with today (I know I'm gonna take it on the chin for making such a comment, but whatever). 10-14 are unassigned, guess we'd better get crackin, eh? If you define a new protocol version as one that means devices with older protocol generations of firmware/software may not interoperate reliably with devices with new protocol generations of firmware/software, then IPv4 as we know it today is probably at least IPv7 - address classes was a generational change requiring software/firmware updates (compare addressing in rfc760 verses rfc791), as was classful+subnets and then CIDR. Regards, Mark.
Re: NIST IPv6 document
On Thu, 6 Jan 2011 21:13:52 -0500 Jeff Wheeler j...@inconcepts.biz wrote: On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong o...@delong.com wrote: 1. Block packets destined for your point-to-point links at your borders. There's no legitimate reason someone should be Most networks do not do this today. Whether or not that is wise is questionable, but I don't think those networks want NDP to be the reason they choose to make this change. 2. For networks that aren't intended to receive inbound requests from the outside, limit such requests to the live hosts that exist on those networks with a stateful firewall. Again, this doesn't fix the problem of misconfigured hosts on the LAN. I can and shall say it over and over, as long as folks continue to miss the potential for one compromised machine to disable the entire LAN, and in many cases, the entire router. It is bad that NDP table overflow can be triggered externally, but even if you solve that problem (which again does not require a stateful firewall, why do you keep saying this?) you still haven't made sure one host machine can't disable the LAN/router. Doesn't this risk already exist in IPv4? Any device attached to a LAN can send any traffic it likes to any other device attached to a LAN, whether that be spoofed ARP updates, intentionally created duplicate IP addresses, or simple flat out traffic based denial of service attacks using valid IPv4 addresses. Just relying on ARP means you're trusting other LAN attached devices not be lying. If you really think a LAN attached device being malicious to another LAN attached device is an unacceptable risk, then you're going to need to abandon your peer-to-peer traffic forwarding topology provided by a multi-access LAN, and adopt a hub-and-spoke one, with the hub (router/firewall) acting as an inspection and quarantining device for all traffic originated by spokes. PPPoE or per-device VLANs would be the way to do that, while still gaining the price benefits of commodity Ethernet. I definitely think there is an issue with IPv6 ND cache state being exploitable from off-link sources e.g. the Internet. I think, however, targetting on-link devices on a LAN is far less of an issue - you've already accepted the risk that LAN other devices can send malicious traffic, and those LAN devices also have a vested interest in their default router being available, so they have far less of an incentive to maliciously disable it. 3. Police the ND issue rate on the router. Yes, it means that an ND attack could prevent some legitimate ND requests from getting through, but, at least it prevents ND overflow and the working hosts with existing ND entries continue to function. In most cases, this will be virtually all of the active hosts on the network. You must understand that policing will not stop the NDCache from becoming full almost instantly under an attack. Since the largest existing routers have about 100k entries at most, an attack can fill that up in *one second.* On some platforms, existing entries must be periodically refreshed by actual ARP/NDP exchange. If they are not refreshed, the entries go away, and traffic stops flowing. This is extremely bad because it can break even hosts with constant traffic flows, such as a server or infrastructure link to a neighboring router. Depending on the attack PPS and policer configuration, such hosts may remain broken for the duration of the attack. Implementations differ greatly in this regard. All of them break under an attack. Every single current implementation breaks in some fashion. It's just a question of how bad. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: NIST IPv6 document
On Fri, 7 Jan 2011 09:38:32 + Dobbins, Roland rdobb...@arbor.net wrote: On Jan 7, 2011, at 4:14 PM, Mark Smith wrote: Doesn't this risk already exist in IPv4? There are various vendor knobs/features to ameliorate ARP-level issues in switching gear. Those same knobs aren't viable in IPv6 due to the way ND/NS work, I was commenting on the mentality the OP seemed to be expressing, about *both* onlink and off link sources triggering address resolution for lots of non-existent destinations, and that this was a new and unacceptable threat. I think the offlink risk is a far more significant one. I think the onlink risk pretty much no worse than any of the other things that LAN attached devices can do if they choose to. and as you mention, the ND stuff is layer-3-routable. The issue isn't that ND is layer 3 routable - it isn't unless a router implementation is broken. The problem is that somebody on the Internet could send 1000s of UDP packets (i.e. an offlink traffic source) towards destinations that don't exist on the target subnet. The upstream router will then perform address resolution, sending ND NSes for those unknown destinations, and while waiting to see if ND NAs are returned, will maintain state for each outstanding ND NS. This state is what is exploitable remotely, unless the state table size is large enough to hold all possible outstanding ND NA entries for all possible addresses on the target subnet. I think this problem can be avoided by getting rid of this offlink traffic triggered address resolution state. The purpose of the state (from the Neighbor Discovery RFC) is two fold - - to allow the ND NS to be resent up to two times if no ND NA response is received to ND NSes. A number of triggering packets (e.g. UDP ones or TCP SYNs) are queued as well so that they can be resent if and when ND NS/NA completes. - to allow ICMP destination unreachables to be generated if the ND NS/NA transaction fails, even after resending. I think it is acceptable to compromise on these requirements. ND NS/NA transactions are going to be successful most of the time, so the ND NS/NA retransmit mechanism is going to be rarely used. Original traffic sources have to be prepared for it to fail anyway - the Internet is a best effort network, so if a source node wants to be sure a packet gets to the original destination it needs to be prepared to retransmit it. This has actually proved not to be a problem in IPv4 as Cisco routers have for many years dumped the data packet that triggers ARP, which I'm pretty sure is the reason why the ARP timeout is 4 hours, rather than the more common 5 minutes. Time outs are pretty much moot anyway, because active Neighbor Unreachability Detection is usually performed these days instead of using simple timeouts for existing ARP entries and is required to be performed by IPv6. If you don't maintain state for outstanding ND NS transactions, then that means that the ND NS issuing device will have to just blindly accept any ND NAs it receives at any time, and put them in the neighbor cache, assuming they are correct. That is an vulnerability, as a local node could fill up the neighbor cache with bogus entries, but one that is far less of a risk than the Internet sourced one we're talking about, as it is only onlink devices that can exploit it. As a LAN is already a trusted environment for basic protocol operations, and devices have a vested interest not disabling other devices that provide them with services e.g. default routers, I think it is a reasonable and acceptable risk given those we already accept in LANs, such as the IPv4 ones I mentioned. If it isn't, implement static address resolution entries, PPPoE, per-device VLANs, SEND etc. I doubt I need to go into much detail about whether ICMP destination unreachables need to be reliably received, the reality is that they aren't in IPv4 and I doubt that will change much in IPv6. I think they're a nice to have not a need to have. Regards, Mark.
Re: NIST IPv6 document
On Wed, 5 Jan 2011 18:57:50 +0100 Phil Regnauld regna...@nsrc.org wrote: Jeff Wheeler (jsw) writes: are badly needed. The largest current routing devices have room for about 100,000 ARP/NDP entries, which can be used up in a fraction of a second with a gigabit of malicious traffic flow. What happens after that is the problem, and we need to tell our vendors what knobs we want so we can choose our own failure mode and limit damage to one interface/LAN. Well there are *some* knobs: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-addrg_bsc_con.html#wp1369018 Not very smart, as it just controls how fast you run out of entries. I haven't read all entries in this thread yet, but I wonder if http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 has been mentioned ? The problem fundamentally is the outstanding state while the NS/NA transaction takes place. IPX had big subnets (i.e. /32s out of 80 bit addresses), but as it didn't use a layer 3 to layer 2 address resolution protocol (layer 2 addresses were the layer 3 node addresses), requiring transaction state, it didn't (or wouldn't have) had this issue. I think the answer is to go stateless for the NS/NA transaction, either blindly trusting the received NAs (initially compatible with current NS/NA mechanisms), which reduces the set of nodes that can exploit neighbor cache tables to those onlink, and then eventually moving towards a nonce based verification of received NAs, which in effect carries the NS/NA transaction state within the packet, rather than storing it within the NS'ing node's memory. Going stateless means losing ICMPv6 destination unreachables for non-existent neighbors however (a) vendors aren't implementing those on P2P links already because they switch off ND address resolution, (b) the /127 P2P proposal switches them off because it proposes switching off ND address resolution, and (c) firewalls commonly drop them inbound from the Internet anyway. Other possible options - http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html Seems also that this topic has been brought up here a year ago give or take a couple of weeks: http://www.mail-archive.com/nanog@nanog.org/msg18841.html Cheers, Phil
Re: The tale of a single MAC
Hi, On Sun, 2 Jan 2011 08:50:42 -0500 Steven Bellovin s...@cs.columbia.edu wrote: On Jan 1, 2011, at 11:33 24PM, Mark Smith wrote: On Sat, 01 Jan 2011 20:59:16 -0700 Brielle Bruns br...@2mbit.com wrote: On 1/1/11 8:33 PM, Graham Wooden wrote: snip Excellent example is, IIRC, the older sparc stuff, where the ethernet cards didn't have MAC addresses as part of the card, but were stored in non-volatile or battery backed memory. This was actually the intended way to use MAC addresses, to used as host addresses rather than as individual interface addresses, according to the following paper - 48-bit Absolute Internet and Ethernet Host Numbers Yogan K. Dalal and Robert S. Printis, July 1981 http://ethernethistory.typepad.com/papers/HostNumbers.pdf Yup. That paper also discusses why 48 bits were chosen as the size, despite Ethernet systems being limited to 1024 hosts. I think things evolved into MAC per NIC because when add-in NICs were invented there wasn't any appropriate non-volatile storage on the host to store the address. On really old Sun gear, the MAC address was stored on a separate ROM chip; if the motherboard was replaced, you'd just move the ROM chip to the new board. I'm not sure what you mean, though, when you say when add-in NICs were invented -- the Ethernet cards I used in 1982 plugged into Unibus slots on our VAXen, so that goes back quite a ways... More that as add-in cards supplied their own storage for the MAC address, rather than expecting it from the host (e.g. something like MAC addresses set by init scripts at boot or the ROM chip you mentioned on Suns), this has now evolved into an expected model of a MAC address tightly bound to an Ethernet interface and supplied by the Ethernet interface e.g. by an add-in board if one is added. Now that this model as been around for a long time, people find it a bit strange when MAC addresses aren't as tightly bound to a NIC/Ethernet interface. This is all speculation on my part though, I'd be curious if the reasons are different. When I first read that paper, it was really quite surprising that MAC addresses were designed to be more general host addresses/identifiers that were also to be used as Ethernet addresses. One example they talk about is using them as unique host identifiers when sharing files via floppy disk. Regards, mark.
Re: The tale of a single MAC
On Sat, 01 Jan 2011 20:59:16 -0700 Brielle Bruns br...@2mbit.com wrote: On 1/1/11 8:33 PM, Graham Wooden wrote: So here is the interesting part... Both servers are HP Proliant DL380 G4s, and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not spoofd and the OS drivers are not mucking with them ... They¹re burned-in I triple checked them in their respective BIOS screen. I acquired these two machines at different times and both were from the grey market. The ³What the ...² is sitting fresh in my mind ... How can this be? From the same grey market supplier? I know HP has a disc they put out which updates all the firmware/bios in a specific server model, its not too far fetched that a vendor might have a modified version that also either purposely or accidentally changes the MAC address. Off the top of my head, I'm not sure where the MAC is stored - maybe an eeprom or a portion of the bios flash. Or, it could be botched flashing that blew away the portion of memory where that was stored and the system defaulted to a built in value. Excellent example is, IIRC, the older sparc stuff, where the ethernet cards didn't have MAC addresses as part of the card, but were stored in non-volatile or battery backed memory. This was actually the intended way to use MAC addresses, to used as host addresses rather than as individual interface addresses, according to the following paper - 48-bit Absolute Internet and Ethernet Host Numbers Yogan K. Dalal and Robert S. Printis, July 1981 http://ethernethistory.typepad.com/papers/HostNumbers.pdf That paper also discusses why 48 bits were chosen as the size, despite Ethernet systems being limited to 1024 hosts. I think things evolved into MAC per NIC because when add-in NICs were invented there wasn't any appropriate non-volatile storage on the host to store the address. Regards, mark.
Re: Router only speaks IGP in BGP network
On Sat, 25 Dec 2010 08:52:42 -0500 ML m...@kenweb.org wrote: On 12/25/2010 3:36 AM, Mark Tinka wrote: On Friday, December 24, 2010 07:26:43 am Randy Bush wrote: and do NOT redistribute bgp into ospf. This is good truth. Don't redistribute your BGP into the IGP (or vice versa). I'm not even sure OSPF would handle it in this day - but you don't want to find out. Mark. If you're only redistributing 10 prefixes into OSPF? Problem? I've had to do it when transitioning between a legacy ISP routing domain and a BGP for everything model. The old routing domain had customer routes in both OSPF and BGP, while the new one used BGP for customer routes only. As I had to make the new network customer routes visible in the old network, and the legacy network didn't have a complete BGP mesh or RR setup (i.e. a broken BGP model), pushing routes from new BGP into old OSPF was the only choice. I liberally used the OSPF external route tag and BGP communities to classify routes and to control redistribution and avoid redistribution loops. So you can do it, as long as you're very careful, and make sure you keep reminding yourself that you're playing with a loaded gun with the safety off. Something definitely worth avoiding if you can. Regards, Mark.
Re: Pointer for documentation on actually delivering IPv6
On Sat, 04 Dec 2010 22:40:50 -0500 Mark Radabaugh m...@amplex.net wrote: Probably a case of something being blindingly obvious but... I have seen plenty of information on IPv6 from a internal network standpoint. I have seen very little with respect to how a ISP is supposed to handle routing to residential consumer networks. I have seen suggestions of running RIPng. The thought of letting Belkin routers (if you can call them that) into the routing table scares me no end. Is this way easier than I think it is? Did somebody already write the book that I can't find? Deploying IPv6 -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: Pointer for documentation on actually delivering IPv6
On Sat, 04 Dec 2010 22:40:50 -0500 Mark Radabaugh m...@amplex.net wrote: Probably a case of something being blindingly obvious but... I have seen plenty of information on IPv6 from a internal network standpoint. I have seen very little with respect to how a ISP is supposed to handle routing to residential consumer networks. I have seen suggestions of running RIPng. The thought of letting Belkin routers (if you can call them that) into the routing table scares me no end. Is this way easier than I think it is? Did somebody already write the book that I can't find? Make that Deploying IPv6 Networks http://www.ciscopress.com/bookstore/product.asp?isbn=1587052105 -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: mtu question
On Wed, 17 Nov 2010 16:23:54 -0500 Brandon Kim brandon@brandontek.com wrote: Jack brings up a good point. MTU is basically pointless since packets never traverse any real interface... So in theory the size can be anything... Not quite. You hit packet length field limits. IPv4 packets can't be larger than 65535, and IPv6 packets also can't be larger than 65 576 (40 byte IPv6 header + 2^16 payload), unless the jumbograms and the jumbo payload extension header is supported. Last time I checked, by setting the loopback MTU 65 576, Linux, for example, doesn't support the jumbo payload extension header (or if it does, I didn't spend enough time finding out how to switch it on - a very large MTU didn't trigger it). That being said, with a 64K MTU on loopback, you can legitimately claim to get 10Gbps at home, as long as you don't mention how you're doing it ;-) Regards, Mark.
Re: Migrating from PPP to DHCPo82
Hi Jack, On Mon, 08 Nov 2010 10:36:45 -0600 Jack Bates jba...@brightok.net wrote: On 11/8/2010 9:40 AM, MKS wrote: I work for an small ISP, which does traditional xDSL service with PPPoE. Currently we are in the process of migrating most of our customers to DHCP (some customers are getting new CPEs and some will be sw upgraded remotely ). It would be great if someone has the time to share their experience (on- or offline) from such a migration. Common pitfals and perhaps what whey would do differently next time. I know that every network is different but I believe that there are some general concerns, specially around security of DHCP and security features for vendors around DHCP and DHCP snooping etc. While I'm looking at running option-82 (have limited support in a few places), I generally run q-in-q providing 100% isolation of customer ports. This gives me the same protections and tracking that PPPoE or ATM give me. This also allows me to turn off the security of the DSLAM and handle all security at the router level. There are a few deployments we have where q-in-q isn't possible (poor dslam implementations), and we have utilized dslam security (dhcp snooping, but currently security breaks IPv6 til the DSLAM gets a future code update) + option 82 in those cases. A few don't support option-82 or q-in-q, and those generally are static assignments in a CPE. The only benefit I've ever seen for PPPoE/A is dslam agnostics and uniform support across all vendors. It has the downside of having to terminate PPPoE/A on a cpe device. DHCP requires a plan with DLSAM and router support. Cisco simple (ip unnumbered vlan feature w/ q-in-q, 1 subint per customer, snmp probe every 5 minutes for the routing table to store IP-MAC-subint in a database). The only reason I've considered adding option 82 is to reduce the waste caused by probing (ie, an IP won't change without the DHCP request, so option 82 lets me get more granular and not probe). Couple of questions if you don't mind. Firstly, is your customer base primarily residential or is it SOHO/SME business (or something else entirely) ? Secondly, would I be right if I assume that you pre-allocate and pre-configure the Q-in-Q id's per customer? Or are they some how dynamically allocated or configured (maybe just on the BRAS, not on the DSLAM), and reported via something like RADIUS? Something like the latter (if it exists) would make it easier to handle residential style/size customer bases. Thanks, Mark.
Re: RINA - scott whaps at the nanog hornets nest :-)
On Sun, 7 Nov 2010 01:07:17 -0700 George Bonser gbon...@seven.com wrote: Yes, I really don't understand that either. You would think that the investment in developing and deploying all that SONET infrastructure has been paid back by now and they can lower the prices dramatically. One would think the vendors would be practically giving it away, particularly if people understood the potential improvement in performance, though the difference between 1500 and 4000 is probably not all that much except on long distance ( 2000km ) paths. Careful, you're rapidly working your way up to nanog kook status with these absurd claims based on no logic whatsoever. My aploligies. It just seemed to me that the investment in SONET, particularly the lower data rates, should be pretty much paid back by now. How long has OC-12 been around? I can understand a certain amount of premium for something that doesn't sell as much but the difference in prices can be quite amazing in some markets. Some differential might be justified but why so much? An OC-12 SFP optic costs nearly $3,000 from one vendor, list. Their list price for a GigE SFP optical module is about 30% of that. What is it about the optic module that would cause it to be 3 times as expensive for an interface with half the bandwidth? A 4-port OC-12 module is 37,500 list. A 4-port 10G module is $10,000 less for 10x the bandwidth. In other words, what is the differential in the manufacturing costs of those? I don't believe it is as much as the differential in the selling price. Once the base manufacturing cost is covered, supply and demand dictate the price a.k.a. you charge what the market will bear. While at least one person/organisation continues to pay sonet/sdh pricing, that's what will be charged.
Re: RINA - scott whaps at the nanog hornets nest :-)
On Sun, 7 Nov 2010 01:49:20 -0600 Richard A Steenbergen r...@e-gerbil.net wrote: On Sun, Nov 07, 2010 at 08:02:28AM +0100, Mans Nilsson wrote: The only reason to use (10)GE for transmission in WAN is the completely baroque price difference in interface pricing. With todays line rates, the components and complexity of a line card are pretty much equal between SDH and GE. There is no reason to overcharge for the better interface except because they (all vendors do this) can. To be fair, there are SOME legitimate reasons for a cost difference. For example, ethernet has very high overhead on small packets and tops out at 14.8Mpps over 10GE, whereas SONET can do 7 bytes of overhead for your PPP/HDLC and FCS etc and easily end up doing well over 40Mpps of IP packets. The cost of the lookup ASIC that only has to support the Ethernet link is going to be a lot cheaper, or let you handle a lot more links on the same chip. At this point it's only half price gouging of the silly telco customers with money to blow. There really are significant cost savings for the vendors in using the more popular and commoditized technology, even though it may be technically inferior. Think of it like the old IDE vs SCSI wars, when enough people get onboard with the cheaper interior technology, eventually they start shoehorning on all the features and functionality that you wanted from the other one in the first place. :) That sounds a lot like the Worse is Better argument The Rise of ``Worse is Better'' http://www.jwz.org/doc/worse-is-better.html This quote would be quite applicable to Ethernet - The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing. I think ethernet gaining OAM would be an example of improving to 90% of the right thing (15 or so years after being invented and deployed), while those technologies that tried to be right from the outset (token ring, ATM etc.) have or are disappearing.
Re: RINA - scott whaps at the nanog hornets nest :-)
On Fri, 5 Nov 2010 21:40:30 -0400 Marshall Eubanks t...@americafree.tv wrote: On Nov 5, 2010, at 7:26 PM, Mark Smith wrote: On Fri, 5 Nov 2010 15:32:30 -0700 Scott Weeks sur...@mauigateway.com wrote: It's really quiet in here. So, for some Friday fun let me whap at the hornets nest and see what happens... ;-) http://www.ionary.com/PSOC-MovingBeyondTCP.pdf Who ever wrote that doesn't know what they're talking about. LISP is not the IETF's proposed solution (the IETF don't have one, the IRTF do), Um, I would not agree. The IRTF RRG considered and is documenting a lot of things, but did not come to any consensus as to which one should be a proposed solution. I probably got a bit keen, I've been reading through the IRTF RRG Recommendation for a Routing Architecture draft which, IIRC, makes a recommendation to pursue Identifier/Locator Network Protocol rather than LISP. Regards, Mark. Regards Marshall and streaming media was seen to be one of the early applications of the Internet - these types of applications is why TCP was split out of IP, why UDP was invented, and why UDP has has a significantly different protocol number to TCP. -- NAT is your friend IP doesn’t handle addressing or multi-homing well at all The IETF’s proposed solution to the multihoming problem is called LISP, for Locator/Identifier Separation Protocol. This is already running into scaling problems, and even when it works, it has a failover time on the order of thirty seconds. TCP and IP were split the wrong way IP lacks an addressing architecture Packet switching was designed to complement, not replace, the telephone network. IP was not optimized to support streaming media, such as voice, audio broadcasting, and video; it was designed to not be the telephone network. -- And so, ...the first principle of our proposed new network architecture: Layers are recursive. I can hear the angry hornets buzzing already. :-) scott
Re: RINA - scott whaps at the nanog hornets nest :-)
On Sat, 06 Nov 2010 11:45:01 -0500 Jack Bates jba...@brightok.net wrote: On 11/5/2010 5:32 PM, Scott Weeks wrote: It's really quiet in here. So, for some Friday fun let me whap at the hornets nest and see what happens...;-) http://www.ionary.com/PSOC-MovingBeyondTCP.pdf SCTP is a great protocol. It has already been implemented in a number of stacks. With these benefits over that theory, it still hasn't become mainstream yet. People are against change. They don't want to leave v4. They don't want to leave tcp/udp. Technology advances, but people will only change when they have to. Lock of SCTP availability is nothing to do with people's avoidance of change - it's likely that deployed Linux kernels in the last 3 to 5 years already have it complied in. IPv4 NAT is what has prevented it from being deployed, because NATs don't understand it and therefore can't NAT addresses carried within it. This is one of the reasons why NAT is bad for the Internet - it has prevented deployment and/or utilisation of new transport protocols, such as SCTP or DCCP, that provide benefits over UDP or TCP. Jack (lost brain cells actually reading that pdf) Glad I haven't then, just the quotes from it hurt. Regards, Mark.
Re: RINA - scott whaps at the nanog hornets nest :-)
On Fri, 5 Nov 2010 15:32:30 -0700 Scott Weeks sur...@mauigateway.com wrote: It's really quiet in here. So, for some Friday fun let me whap at the hornets nest and see what happens... ;-) http://www.ionary.com/PSOC-MovingBeyondTCP.pdf Who ever wrote that doesn't know what they're talking about. LISP is not the IETF's proposed solution (the IETF don't have one, the IRTF do), and streaming media was seen to be one of the early applications of the Internet - these types of applications is why TCP was split out of IP, why UDP was invented, and why UDP has has a significantly different protocol number to TCP. -- NAT is your friend IP doesn’t handle addressing or multi-homing well at all The IETF’s proposed solution to the multihoming problem is called LISP, for Locator/Identifier Separation Protocol. This is already running into scaling problems, and even when it works, it has a failover time on the order of thirty seconds. TCP and IP were split the wrong way IP lacks an addressing architecture Packet switching was designed to complement, not replace, the telephone network. IP was not optimized to support streaming media, such as voice, audio broadcasting, and video; it was designed to not be the telephone network. -- And so, ...the first principle of our proposed new network architecture: Layers are recursive. I can hear the angry hornets buzzing already. :-) scott
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Wed, 3 Nov 2010 04:14:51 + (UTC) Sven Olaf Kamphuis s...@cb3rob.net wrote: I've had a recent experience of this. Some IPv6 CPE I was testing had a fault where it dropped out and recovered every 2 minutes - a transient network fault. I was watching a youtube video over IPv6. Because of the amount of video buffering that took place, and because the same IPv6 prefixes were assigned to the connection once it recovered, the youtube video kept playing. That was a great end-user experience and it was somewhat addictive to watch the PPP light go off and come back on while the video kept playing faultlessly. thats primarily due to partial http downloads aka http status 206 rather than 202 where you can just specify at which offset in the file you want the httpd to start reading the file to you, most flash movie players, however, don't support this. connection lost = movie has to be fully reloaded. There's a whole lot of speculation and no evidence in that statement ... as it said, it was faultless, so I very strongly doubt there was any restarting the stream.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Mon, 1 Nov 2010 18:04:28 -0700 Owen DeLong o...@delong.com wrote: He may or may not be. I don't think it's such a bad idea. How about algorithmically generating these addresses, so that they're near unique, instead of having the overhead of a central registry, and a global routability expectation? Why not just keep a low-overhead central registry and start accepting that PI != global routability. Routability is a discussion between the resource holder and their ISP(s). ULA is the algorithmically generated problem and I think it's a generally bad idea. It's basically an expectation of uniqueness where it may or may not exist and the potential to fudge the level of routability into whatever strange definition long-term creativity may evolve. I think it's better to make GUA easy to get and remove the expectation that GUA == Routable. (Ideally, we'd restore that eventually with a scalable routing paradigm). Is it possible to get GUA from RIRs without making it globally visible? I think the only current exception is IXes. A couple of years back I'd have liked to have gotten a globally unique IPv4 allocation that wasn't being announced globally for use with customer facing DNS servers, reducing their DoS attack surface significantly. Wasn't able to. Recently we've seen somebody (on either nanog or ipv6-ops) proposing to set valid lifetimes of 24 hours on ISP GUA prefixes. While a 24 hour outage is unusual for a always connected broadband service, it isn't for intermittently connected nodes and networks. The upstream valid lifetime doesn't have a lot to do with what happens on the internal network if you're smart. Residential end-users aren't smart and aren't network engineers - they pay people like us so that they don't have to be. That still doesn't have a lot to do with enterprise failover which is what we were talking about. As to residential, residential end users mostly don't care if their network goes down when their provider goes away. However, for those that do, it still shouldn't be hard for the provider to uncouple circuit viability from address presence. In some markets, CPE are sold at the local electronics/white goods store. In effect people who suggest using PA GUAs or PI for all IPv6 addressing are saying you can't run IPv6 unless you have an available IPv6 ISP connection or you must be able to afford to be able to thrust upon the world occupation of a global route table slot. They're not realistic requirements for all potential users of IPv6. No...PI does not require an available IPv6 ISP connection at all. This is a misstatement that does not become any less false no matter how many times you repeat it. What if you don't have an IPv6 ISP connection? Where do you get your PA from? Link local isn't good enough, because it can't span more than a single link. Homes in the future are likely to have multiple networks - visitor segments, multicast segments for video, children segments, 6LowPAN for home sensor networks etc. It gets configured in your router. By whom? Why is that such a difficult concept? For me it isn't, but a lot of things are simple to people with the right expertise. For residential customers who don't know what an IP address, I'm sure it is not only difficult but probably for most an impossible concept. Your home gateway that talks to your internet connection can either get it via DHCP-PD or static configuration. Either way, it could (should?) be set up to hold the prefix until it gets told something different, possibly even past the advertised valid time. That breaks the IPv6 spec. Preferred and valid lifetimes are there for a reason. It can delegate subnets using DHCP-PD, but, the point is that the top level router at the site can easily be coded/configured to keep the prefix regardless of the state of the external link. You've stated you use link locals for this sort of thing, yet you'd be specifying the interface to use as well. That isn't much different to using a subnet number, embedded in the address, to specify either directly attached or remotely reachable subnets. The nice thing about doing it that way is that IPv6 applications are addressing scope agnostic - they just use the address supplied, and ask the underlying OS, which uses the local route table, to direct where the packets go and therefore select the outgoing interface. Link locals + interfaces is more complicated, because now socket options have to be invoked, and only in the case of when a link local address is specified, which also means performing an address type check for the interface option. This code has to be present in ever application, instead of letting the underlying OS taking care of how application packets are directed towards their destinations, and the applications not having to care. No, I've stated that you could. I have
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Tue, 2 Nov 2010 10:51:44 + (GMT) Tim Franklin t...@pelican.org wrote: Your home gateway that talks to your internet connection can either get it via DHCP-PD or static configuration. Either way, it could (should?) be set up to hold the prefix until it gets told something different, possibly even past the advertised valid time. That breaks the IPv6 spec. Preferred and valid lifetimes are there for a reason. And end-users want things to Just Work. And I want their networks to work so well that I don't even want them to rely in an ISPs addressing being available, valid, or even having an ISP - which could easily be the case if they go and sign up for a new broadband service, bring home brand new CPE, yet don't get ISP service connectivity for 5 to 10 business days. Surely they should be able to hook up their internal network and have their TV talking to their computer or NAS during this period without an Internet service. The ISP in question may not be prepared to give them a permanent GUA address at the time of sign up, because the ISP may wish to have static addressing as a product distinguisher for SOHO/SME products, or have the flexibility of phasing semi-dynamic addressing in and out over time to suit their IPv6 address management requirements. The CPE vendor that finds a hack that lets the LAN carry on working while the WAN goes away and manages to slap the With Home Network Resilience! label on the box correctly will presumably do quite nicely out of it. For this kind of site, I can't see what is *actually* going to break if the CPE keeps sending RAs for the prefix beyond the valid lifetime while the WAN is down. As long as it advertises a short valid lifetime itself, such that if the real prefix changes[0] when the WAN comes back up it can renumber everything on the LAN quickly, it looks a lot like a Just Works scenario to me... Prefix lifetimes don't work that way - there is no such thing as a flash renumbering. The goal was to be able to phase new addressing in, transition to it as either older communcations sessions cease (e.g. TCP connections), or new ones are established, then phase out the old addressing over a more significant time period than one measured in minutes or seconds. Regards, Mark. Regards, Tim. [0] Which it won't, of course, because residential users are going to get proper static connections by default, rather than another round of business class price-gouging :)
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Wed, 03 Nov 2010 00:25:34 +1100 Karl Auer ka...@biplane.com.au wrote: On Tue, 2010-11-02 at 23:23 +1030, Mark Smith wrote: Prefix lifetimes don't work that way - there is no such thing as a flash renumbering. The lifetimes are reset with every RA the nodes see. If I reconfigure my router to start sending out RAs every N seconds, it will take a a maximum of N seconds for a new preferred lifetime to be established on all active nodes on the link. If the new preferred lifetime is zero, any addresses in the prefix will be deprecated immediately, causing other prefixes on the link to be preferred. The new valid lifetime will be the remaining valid lifetime (if less than two hours), the newly advertised valid lifetime (if using SEND), or two hours in all other cases. That seems pretty close to flash renumbering... I consider flash renumbering to mean that addressing can be changed without disrupting established and ongoing communications sessions e.g. doesn't break TCP connection or UDP streams. I know that renumbering without disrupting transport protocols is fundamentally impossible to achieve regardless of what the IPv6 preferred and valid lifetimes are because transport protocols are using locators as identifiers. However, the goal should be to make transient network faults, such as a broadband service link flap, have as minimal impact as possible. Changing addresses every time that type of fault occurs makes the consequences higher for transient faults than they need to be. I've had a recent experience of this. Some IPv6 CPE I was testing had a fault where it dropped out and recovered every 2 minutes - a transient network fault. I was watching a youtube video over IPv6. Because of the amount of video buffering that took place, and because the same IPv6 prefixes were assigned to the connection once it recovered, the youtube video kept playing. That was a great end-user experience and it was somewhat addictive to watch the PPP light go off and come back on while the video kept playing faultlessly. Some people argue that applications should be built to deal with this type of situation. I think that is again asking application developers to expend effort overcoming what are networking layer faults, as it has been with NAT. I think problems are best solved where they're caused, not necessarily where their effects are worst felt. I think it's better to hide transient network faults from applications than have to make each and every application include code to deal with them. The time spent writing that code could be better spent on bug fixing, improving the application functions themselves, or writing a different one. Regards, Mark. at least for SLAAC. DHCPv6 needs more planning. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Mon, 1 Nov 2010 10:24:31 + (GMT) Tim Franklin t...@pelican.org wrote: Surely your not saying we ought to make getting PI easy, easy enough that the other options just don't make sense so that all residential users get PI so that if their ISP disappears their network doesn't break? I've seen this last point come up a few times, and I really don't get it. If you're multihomed with multiple PA GUAs, yes, you'd want each RA to track its corresponding WAN availability so your devices are using a prefix that has connectivity. If you're a single-homed leaf network, why on earth wouldn't you want to generate RAs for your statically-assigned prefix all the time, regardless of the state of your WAN connection? This isn't to do with anything low level like RAs. This is about people proposing every IPv6 end-site gets PI i.e. a default free zone with multiple billions of routes instead of using ULAs for internal, stable addressing. It's as though they're not aware that the majority of end-sites on the Internet are residential ones, and that PI can scale to that number of end-sites. I can't see any other way to interpret we ought to make getting PI easy, easy enough that the other options just don't make sense. Regards, Mark.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Mon, 1 Nov 2010 09:20:41 -0700 Owen DeLong o...@delong.com wrote: On Nov 1, 2010, at 2:28 AM, Mark Smith wrote: On Sun, 31 Oct 2010 21:32:39 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Sun, Oct 31, 2010 at 3:10 PM, David Conrad d...@virtualized.org wrote: On Oct 31, 2010, at 6:45 AM, Christopher Morrow wrote: If Woody had gone straight to a ULA prefix, this would never have happened... Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. ula really never should an option... except for a short lived lab, nothing permanent. Seems to me the options are: 1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no routing table bloat Folks appear to have voted with their feet that (2) isn't really viable -- they got that particular T-shirt with IPv4 and have been uniformly against getting the IPv6 version, at last as far as I can tell. My impression (which may be wrong) is that with respect to (1), a) most folks can't justify a PI request to the RIR, b) most folks don't want to deal with the RIR administrative hassle, c) most ISPs would prefer to not have to replace their routers. That would seem to leave (3). Am I missing an option? I don't think so, though I'd add 2 bits to your 1 and 3 options: 1) we ought to make getting PI easy, easy enough that the other options just don't make sense. Surely your not saying we ought to make getting PI easy, easy enough that the other options just don't make sense so that all residential users get PI so that if their ISP disappears their network doesn't break? He may or may not be. I don't think it's such a bad idea. How about algorithmically generating these addresses, so that they're near unique, instead of having the overhead of a central registry, and a global routability expectation? Recently we've seen somebody (on either nanog or ipv6-ops) proposing to set valid lifetimes of 24 hours on ISP GUA prefixes. While a 24 hour outage is unusual for a always connected broadband service, it isn't for intermittently connected nodes and networks. The upstream valid lifetime doesn't have a lot to do with what happens on the internal network if you're smart. Residential end-users aren't smart and aren't network engineers - they pay people like us so that they don't have to be. In effect people who suggest using PA GUAs or PI for all IPv6 addressing are saying you can't run IPv6 unless you have an available IPv6 ISP connection or you must be able to afford to be able to thrust upon the world occupation of a global route table slot. They're not realistic requirements for all potential users of IPv6. No...PI does not require an available IPv6 ISP connection at all. This is a misstatement that does not become any less false no matter how many times you repeat it. What if you don't have an IPv6 ISP connection? Where do you get your PA from? Link local isn't good enough, because it can't span more than a single link. Homes in the future are likely to have multiple networks - visitor segments, multicast segments for video, children segments, 6LowPAN for home sensor networks etc. You've stated you use link locals for this sort of thing, yet you'd be specifying the interface to use as well. That isn't much different to using a subnet number, embedded in the address, to specify either directly attached or remotely reachable subnets. The nice thing about doing it that way is that IPv6 applications are addressing scope agnostic - they just use the address supplied, and ask the underlying OS, which uses the local route table, to direct where the packets go and therefore select the outgoing interface. Link locals + interfaces is more complicated, because now socket options have to be invoked, and only in the case of when a link local address is specified, which also means performing an address type check for the interface option. This code has to be present in ever application, instead of letting the underlying OS taking care of how application packets are directed towards their destinations, and the applications not having to care. For the most common and scalable case of PA, external addressing dependencies reduce reliability, because you can't control them. Completely relying on external connectivity and addressing for your internal networks reduces their reliability and availability. This is also false if you use any form of sanity in applying the assigned PA prefix to your network. I suppose since they don't have the expertise, you could consider residential end-users insane. You can't make the insane sane just by telling them to be so. Preventing their insanity from breaking their Internet
Re: Odd cableone traceroute with 0.0.0.0 in path
On Thu, 28 Oct 2010 12:55:56 -0600 Brielle Bruns br...@2mbit.com wrote: Okay, so this has my head hurting a bit just trying to figure out just how this is possible and what kind of equipment would pull this stunt. My initial guess was that somebody put 0.0.0.0 text as the DNS PTR RR value for that hop, however that isn't the case as both the name and the IP address of the hop are 0.0.0.0. My guess is that the ICMP error that traceroute uses to detect hops is being sourced from 0.0.0.0 for some reason. Your cable modem wouldn't be performing any RPF on incoming traffic, so there is nothing to filter out 0.0.0.0 as an invalid source address (or it may actually be valid for these ICMP errors - it's the unspecified address.) Tracing from here (cableone cable modem) to the outside world, I end up with the following at the beginning of my traceroute. 1 192.168.1.1 (192.168.1.1) 2.759 ms 0.803 ms 0.769 ms 2 0.0.0.0 (0.0.0.0) 10.462 ms 9.543 ms 8.043 ms 3 192.168.32.65 (192.168.32.65) 9.984 ms 9.654 ms 9.570 ms 4 te-4-4.car2.seattle1.level3.net (4.53.146.117) 25.960 ms 21.798 ms 24.144 ms etc 0.0.0.0 as one of the hops.So, I pulled out LFT to make sure traceroute isn't going nuts. Layer Four Traceroute (LFT) version 3.1 Using device en1, 192.168.1.101:53 TTL LFT trace to 207.70.17.213:80/tcp 1 192.168.1.1 0.9/0.9ms 2 /9.8/10.3ms 3 192.168.32.65 9.7/8.3ms 4 10.255.255.1 9.1/8.4ms 5 te-4-4.car2.seattle1.level3.net (4.53.146.117) 29.0/20.2ms Fun, no entry for hop 2, plus there's an extra hop at #4. Lets use verbose. Layer Four Traceroute (LFT) version 3.1 ... (verbosity level 2) Using device en1, 192.168.1.101:53 SENT TCP TTL=1 SEQ=648736948 FLAGS=0x2 ( SYN ) SENT TCP TTL=2 SEQ=648736949 FLAGS=0x2 ( SYN ) RCVD ICMP SEQ=648736948 SRC=192.168.1.1 PTTL=1 PSEQ=648736948 SENT TCP TTL=3 SEQ=648736950 FLAGS=0x2 ( SYN ) SENT TCP TTL=4 SEQ=648736951 FLAGS=0x2 ( SYN ) SENT TCP TTL=5 SEQ=648736952 FLAGS=0x2 ( SYN ) SENT TCP TTL=6 SEQ=648736953 FLAGS=0x2 ( SYN ) RCVD ICMP SEQ=648736949 SRC=0.0.0.0 PTTL=2 PSEQ=648736949 SENT TCP TTL=7 SEQ=648736954 FLAGS=0x2 ( SYN ) RCVD ICMP SEQ=648736950 SRC=192.168.32.65 PTTL=3 PSEQ=648736950 RCVD ICMP SEQ=648736951 SRC=10.255.255.1 PTTL=4 PSEQ=648736951 RCVD ICMP SEQ=648736953 SRC=4.68.105.30 PTTL=6 PSEQ=648736953 Am I going nuts, or is something really messed up somewhere upstream from the cable modem? To quote someone from IRC who's just as confused, the null route just talked to me. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: IPv6 Routing table will be bloated?
On Tue, 26 Oct 2010 12:19:30 -0500 Jack Bates jba...@brightok.net wrote: On 10/26/2010 12:04 PM, Nick Hilliard wrote: In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. Except, if you are given bare minimums, and you are assigning out to subtending ISPs bare minimums, Why aren't those subtending ISPs getting their own PI (/32s)? those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space. ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if you get an initial allocation of /32, then find you need more, your subsequent allocations will be taken from the same /29, allowing aggregation up to /29. My minimum /30 allocation per ARIN met a /27 in HD-Ratio thresholds. To not be given the threshold space means no reservations for subtending ISPs, no room for subtending ISPs to grow, and multiple assignments. If ARIN only does /29 boundaries, I'll also be getting multiple /29's, and not just working within a /27 per the HD-Ratio guidelines. It's the mixed viewpoint that is the problem. HD-Ratio is useless as a justification and as a metric which promotes route conservation/aggregation if it is not used for initial allocations. Initial allocations (including those handed out to subtending ISPs) should all be as large as the immediate use HD Ratio permits. ie, If you are immediately assigning X /56 blocks, your assignment should have a length one less than the highest threshold you crossed. To assign any less is to constrain the assignments, not allow for growth, and to increase routing table size. It also circumvents and completely destroys the concept of HD Ratio (as the initial assignments all are well in excess of the thresholds for requesting much larger blocks). Jack
Re: IPv6 Routing table will be bloated?
On Tue, 26 Oct 2010 16:25:39 -0400 Scott Reed sr...@nwwnet.net wrote: Why would the assumption be the ISP = knowledgeable or even caring about RIRs, etc.? When I started my ISP 6 years ago I knew someone issued IP addresses to my upstream provider, but I really didn't care who that was. The upstream took care of everything related to getting and assigning addresses as far as I was concerned. Even when I changed upstream providers they took care of the addresses. It was at that time I realized I need to learn more about the whole IP address assignment process so I wouldn't have to renumber next time I changed providers. I dug far enough to find that my ISP was not big enough to get an assignment and the required fee was more than the cost to renumber, so I didn't look any farther. So, as a log of start-ups and small businesses do, I learned enough to make what I needed work, but not everything that may have been beneficial. So maybe to state the obvious, IPv4 != IPv6, and therefore in Jack's situation something different needs to be done, such as those ISPs learning about RIRs, LIRs etc. sooner rather than later. On 10/26/2010 3:20 PM, George Bonser wrote: -Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: Tuesday, October 26, 2010 11:23 AM To: Randy Carpenter Cc: nanog@nanog.org Subject: Re: IPv6 Routing table will be bloated? On 10/26/2010 1:01 PM, Randy Carpenter wrote: Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? Because they are my customer. They don't know much about RIRs, paying membership fees, etc. They just know they want address space, and I provide that. If they are ISPs and don't know much about RIRs, can you please name them and provide their ASNs ... oh, wait ... they won't have an ASN if they don't know about RIRs and fees and such. Something isn't passing the smell test here. -- Scott Reed Owner NewWays Networking, LLC Wireless Networking Network Design, Installation and Administration Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060
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: IPv4 sunset date set for 2019-12-31
On Thu, 21 Oct 2010 22:09:39 -0400 Jared Mauch ja...@puck.nether.net wrote: On Oct 21, 2010, at 9:51 PM, Barry Shein wrote: Anyhow, it might be an interesting topic to discuss in the appropriate venues, IETF, What is the cost of maintaining IPv4 forever? but it's getting a little ahead of ourselves in terms of any pressing need. This is an interesting question. In talking to your vendors with your checklist of capabilities a device CAN/SHOULD/MUST have, what if you no longer needed to carry 350k/512k routes of IPv4 and only needed 256k of IPv6 ? Instead of 6pe think of 4pe with ipv6 core. I've been reminding vendors that IPv6 should get new features *first* vs IPv4. The end of IPv4 is near, but that doesn't mean the end of the Internet is here. The next chapter gets a new page turned. Maybe we will determine that IPv6 needs to go the way of IPX/Decnet/AppleTalk and some new system (non-IP even) will take over the world. Either way, it's an interesting time to be an edge operator that worries about CPE stuff. those that think mostly about core this is a big fat *yawn* imho. Expect application developers to face some interesting challenges. me? I'm waiting until I see the NOW WITH IPv6 sticker on things at the store. If you go into the right store, you'll see one. http://forums.whirlpool.net.au/forum-replies.cfm?t=1470849p=5#r83 - Jared
Re: IPv6 fc00::/7 — Unique local addresses
On Fri, 22 Oct 2010 01:10:08 -0700 Owen DeLong o...@delong.com wrote: On Oct 22, 2010, at 12:55 AM, Mark Smith wrote: On Fri, 22 Oct 2010 15:52:08 +1100 Karl Auer ka...@biplane.com.au wrote: On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote: On 10/21/2010 8:39 PM, Ray Soucy wrote: How so? We still have RA (with a high priority) that's the only way DHCPv6 works. I guess there is a lot of misunderstanding about how DHCPv6 works, even among the experts... Actually, the last I checked, there are implementation of DHCPv6 without RA. I'll go out on a limb here and say that RA is not needed for DHCPv6. RAs are still needed to convey the M/O bit values, so that end-nodes know they need to use DHCPv6 if necessary. As there are two address configuration methods, there is always going to be a need to express a policy to end-nodes as to which one they need to use. You can actually force a client to assume the M bit if you cause it to launch a DHCPv6 client through other means. You don't have to have RA for that. Policy can be expressed by RA, or, it can be expressed by other means. We used to hand wind cars to start them. We don't have to anymore. An RA is single, periodic, in the order of 100s of seconds, multicast packet. If you're arguing against the cost of that, then I think you're being a bit too precious with your packets. Any argument for manual configuration is an argument for increasing complexity and opportunity for error. A DHCPv6 client multicasts all its messages to the well-known all-relays-and-servers address. A client needs only its link-local address to do this. The relay (or server if it happens to be on the same link) can thus talk to the client in the complete absence of RA. There isn't a method to specify a default gateway in DHCPv6. Some people want it, however it seems a bit pointless to me if you're going to have RAs announcing M/O bits anyway - you may as well use those RAs to announce a default router too. 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. 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. Owen
Re: IPv6 fc00::/7 — Unique local addresses
On Wed, 20 Oct 2010 14:48:47 -0700 Jeroen van Aart jer...@mompl.net wrote: IPv6 newbie According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an fc00::/7 address includes a 40-bit pseudo random number: fc00::/7 — Unique local addresses (ULA's) are intended for local communication. They are routable only within a set of cooperating sites (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing prefix intended to minimize the risk of conflicts if sites merge or packets are misrouted into the Internet. Despite the restricted, local usage of these addresses, their address scope is global, i.e. they are expected to be globally unique. I am trying to set up a local IPv6 network and am curious why all the examples I come accross do not seem to use the 40-bit pseudorandom number? What should I do? Use a pseudo random number, not follow bad examples. Where are these examples? I'd be curious as to what they say regarding why they haven't followed the pseudo random number requirement. Use something like fd00::1234, or incorporate something like the interface's MAC address into the address? It'd make the address quite unreadable though. DNS (including dynamic DNS, multicast DNS, and DNS service discovery) is intended to be used far more often in IPv6 than it was in IPv4. It was never going to be that possible to expand the size of the address space significantly without trading off 'rememberability'. The best way to understand ULAs is to read the RFC. It'd probably take about 15 to 20 minutes, and is quite readable (as are most if not all RFCs) Unique Local IPv6 Unicast Addresses http://tools.ietf.org/rfc/rfc4193.txt You may also wish to subscribe to the ipv6-ops mailing list for IPv6 focused operations discussions. http://lists.cluenet.de/mailman/listinfo/ipv6-ops Regards, Mark.
Re: IPv6 fc00::/7 — Unique local addresses
On Wed, 20 Oct 2010 19:39:19 -0400 Deepak Jain dee...@ai.net wrote: Use a pseudo random number, not follow bad examples. Where are these examples? I'd be curious as to what they say regarding why they haven't followed the pseudo random number requirement. Use something like fd00::1234, or incorporate something like the interface's MAC address into the address? It'd make the address quite unreadable though. Unique Local IPv6 Unicast Addresses http://tools.ietf.org/rfc/rfc4193.txt [snipped a bunch of stuff above]. According to the RFC: 3.2 The local assignments are self-generated and do not need any central coordination or assignment, but have an extremely high probability of being unique. 3.2.1. Locally Assigned Global IDs Locally assigned Global IDs MUST be generated with a pseudo-random algorithm consistent with [RANDOM]. Section 3.2.2 describes a suggested algorithm. It is important that all sites generating Global IDs use a functionally similar algorithm to ensure there is a high probability of uniqueness. The use of a pseudo-random algorithm to generate Global IDs in the locally assigned prefix gives an assurance that any network numbered using such a prefix is highly unlikely to have that address space clash with any other network that has another locally assigned prefix allocated to it. This is a particularly useful property when considering a number of scenarios including networks that merge, overlapping VPN address space, or hosts mobile between such networks. Global ID in this case means the 40 bit pseudo random thing. The point here is, we are all supposed to pick our own poison and pray that we are unique. The chance of collision is dependent on both the randomness of 40 bits *and* how interconnected the ULA domains are. You'll have to sin a lot to be that unlucky. Here's the table from the RFC showing the odds of collision based on interconnectedness - The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field. Connections Probability of Collision 21.81*10^-12 104.54*10^-11 1004.54*10^-09 10004.54*10^-07 14.54*10^-05 Based on this analysis, the uniqueness of locally generated Global IDs is adequate for sites planning a small to moderate amount of inter-site communication using locally generated Global IDs. Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick. One thing I'm not keen on that sixxs have done is to create a voluntary registry of the non-central ULAs. By creating a registry, I think some people who use it will then think that their ULA prefix is now guaranteed globally unique and is theirs forever. If there ever was a collision, those people are likely to point to that completely voluntary registry and say I had it first and are likely to refuse to accept that the voluntary registry has no status or authority over the random ULA address space. There also doesn't seem to be any limiting of the number of prefixes. In an isolated network, which is where ULAs are supposed to be used, it's far less of a problem, because the only time the chance of collision occurs is if you interconnect with somebody else's ULA domain. However, as this sixxs registry implies it is a global one, and therefore there is a single instance of the fd::/8 address space, limiting the number of prefixes that are assigned would seem to me to be good idea. When I see examples such as - fddd:7927:58e::/48 Steven SorelDeticon Networks http://deticon.net fd85:5d1d:c00b::/48 Steven SorelDeticon Networks http://deticon.net fda1:9347:699f::/48 Steven SorelDeticon Networks http://deticon.net fd41:eda2:4b7b::/48 Steven SorelDeticon Networks http://deticon.net fd58:fe0f:8706::/48 Steven SorelDeticon Networks http://deticon.net fd6a:3128:2a1d::/48 Steven SorelDeticon Networks http://deticon.net fdb0:8025:2463::/48 Steven SorelDeticon Networks http://deticon.net or 458 752 subnets, and http://deticon.net isn't reachable via IPv6 or IPv4 (and hasn't been for quite a while - I checked a few months ago when I discovered the registry), it seems to me that people have already misunderstood what it's purpose is, and that the database is already polluted with invalid entries that can't be verified for existence, and which also can't be expired via some invalidation mechanism, such as lack of payment of annual fees. Regards, Mark.
Re: IPv6 fc00::/7 — Unique local addresses
On Wed, 20 Oct 2010 19:07:57 -0500 James Hess mysi...@gmail.com wrote: On Wed, Oct 20, 2010 at 4:48 PM, Jeroen van Aart jer...@mompl.net wrote: IPv6 newbie these addresses, their address scope is global, i.e. they are expected to be globally unique. The ULA /48s are hoped to only be globally unique, but this only has a good chance of happening if all users pick good random numbers as required, which will often be 'hard to read'. should any two networks pick non-random numbers, they could easily conflict, breaking expectations. Do you realise that one of the reasons why the ID is random is to discourage global routing of them, so they don't aggregate well? They're for internal addressing. The only time some of your local ULA address space would be seen externally to your network is via a backdoor connection to e.g. a business partner via a VPN. ULAs should never and are prohibited from appearing in the global route table. The probably shouldn't also appear in a multilateral peering fabric. To make it clear, as it seems to be quite misunderstood, you'd have both ULA and global addressing in your network. For internal destinations ULA addresses are used. For global destinations, global addresses are used. ULAs serve the purpose of providing an internally stable address space independent of your upstream transit provider's global address space, assuming you have one. In IPv4, RFC1918 served this purpose, although not as well, as it couldn't be used concurrently with a global address space (one of the differences between IPv4 and IPv6 is proper, by-design, support for nodes having multiple valid addresses), and also required NAT when interconnecting two overlapping RFC1918 address domains. My suspicion is that in the future it is going to happen routinely, esp. if ULA becomes to IPv6 what RFC1918 space is to IPv4, with most end user networks implementing NAT66 to translate private /48 ULAs to their site's public/48assignment from their ISP. I can imagine generic $50 IPv6 broadband routers getting distributed en-masse that hardcode all bits 0 ULA NAT66 by default, and expect the user to change the LAN IP subnet / NAT config from the defaults, sometime while they're setting it up, probably at the same time they change the admin password. You know... the type of router a residential user plugs in, and they just work, and if the user forgets to follow any setup or config directions, just pulls an IP via DHCP and sticks with some insecure defaults. But it would still be a big improvement from what is available with V4. -- -Jh
Re: IPv6 fc00::/7 — Unique local addresses
Hi Owen, On Wed, 20 Oct 2010 17:51:11 -0700 Owen DeLong o...@delong.com wrote: On Oct 20, 2010, at 5:29 PM, Mark Smith wrote: On Wed, 20 Oct 2010 19:39:19 -0400 Deepak Jain dee...@ai.net wrote: Use a pseudo random number, not follow bad examples. Where are these examples? I'd be curious as to what they say regarding why they haven't followed the pseudo random number requirement. Use something like fd00::1234, or incorporate something like the interface's MAC address into the address? It'd make the address quite unreadable though. Unique Local IPv6 Unicast Addresses http://tools.ietf.org/rfc/rfc4193.txt [snipped a bunch of stuff above]. According to the RFC: 3.2 The local assignments are self-generated and do not need any central coordination or assignment, but have an extremely high probability of being unique. 3.2.1. Locally Assigned Global IDs Locally assigned Global IDs MUST be generated with a pseudo-random algorithm consistent with [RANDOM]. Section 3.2.2 describes a suggested algorithm. It is important that all sites generating Global IDs use a functionally similar algorithm to ensure there is a high probability of uniqueness. The use of a pseudo-random algorithm to generate Global IDs in the locally assigned prefix gives an assurance that any network numbered using such a prefix is highly unlikely to have that address space clash with any other network that has another locally assigned prefix allocated to it. This is a particularly useful property when considering a number of scenarios including networks that merge, overlapping VPN address space, or hosts mobile between such networks. Global ID in this case means the 40 bit pseudo random thing. The point here is, we are all supposed to pick our own poison and pray that we are unique. The chance of collision is dependent on both the randomness of 40 bits *and* how interconnected the ULA domains are. You'll have to sin a lot to be that unlucky. Here's the table from the RFC showing the odds of collision based on interconnectedness - The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field. Connections Probability of Collision 21.81*10^-12 104.54*10^-11 1004.54*10^-09 10004.54*10^-07 14.54*10^-05 Based on this analysis, the uniqueness of locally generated Global IDs is adequate for sites planning a small to moderate amount of inter-site communication using locally generated Global IDs. Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick. One thing I'm not keen on that sixxs have done is to create a voluntary registry of the non-central ULAs. By creating a registry, I think some people who use it will then think that their ULA prefix is now guaranteed globally unique and is theirs forever. If there ever was a collision, those people are likely to point to that completely voluntary registry and say I had it first and are likely to refuse to accept that the voluntary registry has no status or authority over the random ULA address space. Which is part one of the three things that have to happen to make ULA really bad for the internet. Part 2 will be when the first provider accepts a large sum of money to route it within their public network between multiple sites owned by the same customer. That same customer is also going to have enough global address space to be able to reach other global destinations, at least enough space for all nodes that are permitted to access the Internet, if not more. Proper global address space ensures that if a global destination is reachable, then there is a high probability of successfully reaching it. The scope of external ULA reachability, regardless of how much money is thrown at the problem, isn't going to be as good as proper global addresses. For private site interconnect, I'd think it more likely that the provider would isolate the customers traffic and ULA address space via something like a VPN service e.g. MPLS, IPsec. Part 3 will be when that same provider (or some other provider in the same boat) takes the next step and starts trading routes of ULA space with other provider(s). At that point, ULA = GUA without policy = very bad thing (tm). Since feature creep of this form is kind of a given in internet history, I have no reason to believe it won't happen eventually with ULA. So I'm not sure I can see much benefit would be of paying a huge amount of money to have ULA address space put in only a limited part/domain of the global route table. The only way to have ULA = GUA is to pay everybody
Re: IPv6 fc00::/7 — Unique local addresses
On Wed, 20 Oct 2010 18:46:34 -0700 Matthew Kaufman matt...@matthew.at wrote: On 10/20/2010 6:20 PM, Mark Smith wrote: To make it clear, as it seems to be quite misunderstood, you'd have both ULA and global addressing in your network. Right. Just like to multihome with IPv6 you would have both PA addresses from provider #1 and PA addresses from provider #2 in your network. Only nobody wants to do that either. So you speak for everybody? I can do that too. Nobody wants to run NAT anymore either.
Re: IPv6 fc00::/7 — Unique local addresses
On Wed, 20 Oct 2010 21:15:35 -0500 James Hess mysi...@gmail.com wrote: On Wed, Oct 20, 2010 at 8:46 PM, Matthew Kaufman matt...@matthew.at wrote: On 10/20/2010 6:20 PM, Mark Smith wrote: Right. Just like to multihome with IPv6 you would have both PA addresses from provider #1 and PA addresses from provider #2 in your network. Only nobody wants to do that either. A perfectly valid way to multihome, right?Setup each host with two IP addresses, one in each PA range. Use multiple DNS records, to indicate all the host's pairs of IPs. If an ISP link goes down, all the clients' should automatically try resend the unack'ed packets to the DNS name's other IPs in 10 or 11 seconds, and recover, without having to reconnect, right? right??[ No :( ] Automatic failover to other multihomed IPs seems to always have been left missing from the TCP protocols, for some reason or another. Probably good reasons, but that multihoming strategy isn't a very good one, for now, due to the disruption of active connections, and bad client programs that won't look for other DNS records, even when trying to establish a new connection. Perhaps one day, there will be a truly reliable transport protocol, and an API that allows a bind() against multiple IPs and a connect() * Stream Control Transport Protocol, first spec'd in 2000 (couldn't be deployed widely in IPv4 because of NATs) * TCP Extensions for Multipath Operation with Multiple Addresses https://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/ and Architectural Guidelines for Multipath TCP Development https://datatracker.ietf.org/doc/draft-ietf-mptcp-architecture/ to all a target host's IPs instead of just one, so both hosts can learn of each other's IP addresses that are offered to be used for that connection, then multiple PA IP addresses would be a technically viable multi-homing strategy. -- -Jh
Re: IPv6 fc00::/7 — Unique local addresses
On Wed, 20 Oct 2010 19:50:06 -0700 Matthew Kaufman matt...@matthew.at wrote: On 10/20/2010 7:27 PM, Mark Smith wrote: * Stream Control Transport Protocol, first spec'd in 2000 (couldn't be deployed widely in IPv4 because of NATs) because of NATs s/b because certain parties refused to acknowledge that encapsulation of SCTP in UDP would have operational advantages sufficient to outweigh the disadvantages. SCTP only gets you 90% of the way there, but it is a lot closer than today's TCP is. Which is why there is also work going on at the network layer, both on the end-hosts via HIP or Shim6, and in the network, such as LISP. Ultimately, this is a hard problem to solve. There is no easy solution, otherwise it'd already exist, and have existed at least 10 years ago - as that is at least how long people have been working on trying to solve it. As there is no easy and perfect solution, then we need to accept that we're going to have to make trade offs to be able to get closer to solving it. In other words, a better solution, even if it isn't perfect, is better. The question is what trade offs are acceptable to make? We know and have experienced the many drawbacks of NAT, including such things as restricting deployment of new and better transport protocols like SCTP, DCCP, and maybe multipath TCP if the NAT boxes inspect and drop unknown TCP options, and forcing the nature of Internet applications to be client-server, even when a peer-to-peer application communications architecture would be far more reliable, scalable and secure. As NAT ultimately was about conserving address space, and IPv6 solves that problem, it is worth exploring other options that weren't possible with IPv4 and/or IPv4 NAT. Regards, Mark.
Re: IPv6 fc00::/7 — Unique local addresses
On Thu, 21 Oct 2010 14:29:11 +1100 Mark Andrews ma...@isc.org wrote: In message 4cbfa9bb.9030...@matthew.at, Matthew Kaufman writes: ULA + PA can have the same problems, especially if your ULA is inter-organization ULA, which was one of the cases under discussion. Which still isn't a problem. Presumably you want your inter-organization traffic to use ULA addresses to talk to each other so you setup the address selection rules to do just that. That requires new rules being distributed to all nodes that need to talk to the other site. Presumable DHCPv6 could do this. If there isn't yet a DHCP option to request address selection rules we need to define one. One is being defined - https://datatracker.ietf.org/doc/draft-fujisaki-6man-addr-select-opt/ Use a VPN between the organisations so you fate share. If you have a private interconnect then the VPN becomes the backup. Matthew Kaufman -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 fc00::/7 — Unique local addresses
On Wed, 20 Oct 2010 20:12:11 -0700 George Bonser gbon...@seven.com wrote: * Stream Control Transport Protocol, first spec'd in 2000 (couldn't be deployed widely in IPv4 because of NATs) I would dearly love to see SCTP take off. There are so many great potential applications for that protocol that it can boggle. Any type of connection between two things that might have several different kinds of data going back and forth at the same time could greatly benefit. I agree. One application I'd though of was end-to-end Instant Messaging, where, when you wish to transfer a file to the other participant, a new SCTP stream is created for the file transfer within the existing SCTP connection. Not all that novel, but something that would be much easier to do with SCTP than TCP. Regards, Mark.
Re: IPv6 fc00::/7 — Unique local addresses
On Thu, 21 Oct 2010 06:38:33 +0200 Graham Beneke gra...@apolix.co.za wrote: On 21/10/2010 03:49, Matthew Kaufman wrote: On 10/20/2010 5:51 PM, Owen DeLong wrote: Part 2 will be when the first provider accepts a large sum of money to route it within their public network between multiple sites owned by the same customer. Is this happening now with RFC 1918 addresses and IPv4? I have seen this in some small providers. Doesn't last long since the chance of collision is high. It then becomes a VPN. Part 3 will be when that same provider (or some other provider in the same boat) takes the next step and starts trading routes of ULA space with other provider(s). Is this happening now with RFC 1918 addresses and IPv4? I've seen this too. Once again small providers who pretty quickly get caught out by collisions. The difference is that ULA could take years or even decades to catch someone out with a collision. By then we'll have a huge mess. I don't think there is a difference. The very small providers are the ones who make the stupid mistakes, it's the larger ones that do the right thing because it is in their operational interests. Operational competence, and the resulting increased reliability, is one of the attributes customers of ISPs value highly. If any of the Tier-1s don't route ULA address space, then it is useless compared to global addresses that *are* routed by *all* the Tier-1s. As the Tier-1s also hire competent networking people, they'll also understand the scaling issues of the ULA address space, and why it shouldn't be globally routed. Competent networking people also exist at the lower tiers as well. If operators just blindly accept and implement what sales people tell them to, then those operators aren't operators. They're mindless drones - and the rest of the people operating the Internet will protect the Internet from them. Darwin eventually gets rid of those operators and the ISP that employ them. Since ULAs could be used as DoS attack sources, they'll also likely be filtered out by most people as per BCP38. Regards, Mark.
Re: IPv6 fc00::/7 ? Unique local addresses
On Thu, 21 Oct 2010 12:44:40 +0800 Adrian Chadd adr...@creative.net.au wrote: On Thu, Oct 21, 2010, Graham Beneke wrote: I've seen this too. Once again small providers who pretty quickly get caught out by collisions. The difference is that ULA could take years or even decades to catch someone out with a collision. By then we'll have a huge mess. You assume that people simply select ULA prefixes randomly and don't start doing linear allocations from the beginning of the ULA range. Any time there is a parameter that can be configured, there is a possibility that people will misconfigure it. The only way to completely prevent that being a possibility is to eliminate the parameter. We can prevent people from getting addressing wrong by not putting addresses in the IP header - but I, and I suspect most people, would prefer their computers not to be a dumb terminal connected to a mainframe. Or we can make the network robust against misconfiguration, and put in place things like BCP38. This is all starting to sound a bit like Chicken Little. Regards, Mark.
Re: Only 5x IPv4 /8 remaining at IANA
On Tue, 19 Oct 2010 16:25:12 -0700 Zaid Ali z...@zaidali.com wrote: On 10/19/10 3:58 PM, Mark Andrews ma...@isc.org wrote: Adding is seperate IPv6 server is a work around and runs the risk of being overloaded. And what a wonderful problem to have! You can show a CFO a nice cacti graph of IPv6 growth so you can justify him/her to sign off on IPv6 expenses. A CFO will never act unless there is a real business problem. When did CFOs run the company? If you're taking this decision to C level management, the CIO, CTO or the CEO should be the ones making the decision. They direct where money goes, not the CFO. The easy business case for IPv6 is insurance. At some point in the relatively near future there may be content or services that are only available over IPv6. Investing in IPv6 deployment now is insurance against not being able to access that content when you may need to in the future. Do your management want to miss out on being able to access the next IPv6-only Google, Salesforce.com, etc., when it is critical to the business? Somebody in the organisation will have responsibility for ensuring continued and reliable access to services the company needs, and if that includes Internet access, then IPv6 is going to become an essential part of that continued and reliable Internet access. There are some of us here who have management with clue but there are many that don't, sadly this is the majority and a large contributor to the slow adoption of IPv6. Zaid
Re: Only 5x IPv4 /8 remaining at IANA
On Mon, 18 Oct 2010 11:41:09 -0700 George Bonser gbon...@seven.com wrote: You are confusing SI with Packet Filters. The technologies are different and it is, also, important to understand this distinction as well. I don't think I am confusing the two. I am saying that I have seen people use them and think they are secure when they aren't. IPv6 is going to make it a little harder for people to make this mistake (or easier to make it, I haven't decided yet which way it will go) and you will see more people purchasing equipment that does real state inspection which is my reason for predicting an increase in firewall sales. They won't have that dynamic NAT that lulls some into a false sense of security. Also, I believe the fire suit approach will become more important to people rather than the fire wall approach with IPv6. That's a great way of saying host based security. With mobile Internet devices (smart phones, laptops (which outsold desktops last year apparently) etc.) becoming the dominant Internet access device, I think host based firewalling will become the primary firewalling mechanism. Network located firewalls will perform a secondary and assistant role, because hosts can't be sure they're there when the hosts have wired, wifi, bluetooth etc. interfaces that can all be actively connected to the Internet at the same time. Regards, Mark.
Re: Pica8 - Open Source Cloud Switch
On Mon, 18 Oct 2010 13:21:29 +0100 Nick Hilliard n...@foobar.org wrote: On 18/10/2010 12:25, Lin Pica8 wrote: We are starting to distribute Pica8 Open Source Cloud Switches : Sounds interesting. What chipset does this run on? Also, what's a cloud switch? Is this a switch which forwards L2 traffic, or did I miss something? Cloud is the new mainframe i.e. it's running somewhere else ... And the Emperor is naked ... ;-)
Re: Only 5x IPv4 /8 remaining at IANA
On Mon, 18 Oct 2010 08:18:57 -0700 Owen DeLong o...@delong.com wrote: On Oct 18, 2010, at 5:28 AM, Curtis Maurand wrote: On 10/18/2010 8:16 AM, ML wrote: And +1 on the pioneers comment too. Paul. IPv6 Hipsters..Doing it before it was cool. IPV4 -easy(); IPV6-really().Really().Difficult(); Have you done IPv6? I have... It's not even difficult(), let alone really().Really().Difficult(). A lot of things are hard if you've never dealt with anything else. If, OTOH, you'd dealt with IPX or Appletalk before IPv4, then IPv4 was quite hard (why the complexity?! I do know now, but only after having looked into the history of IPv4 - it's a just series of neat hacks!) ... Regards, Mark.
Re: 12 years ago today...
On Mon, 18 Oct 2010 13:03:54 +0100 Will Hargrave w...@harg.net wrote: On 16/10/10 10:02, Warren Bailey wrote: While we are on the subject of the godfathers of the Internet, when is a documentary coming out that tells the story? There was a really long documentary done on the BBS, surely someone (myself included) would find it interesting. I can recommend Where Wizards Stay Up Late by Katie Hafner http://www.amazon.com/Where-Wizards-Stay-Up-Late/dp/0684832674 A really good read IMHO. As is RFC2468 (Who do we appreciate!) - I REMEMBER IANA Will
Re: Definitive Guide to IPv6 adoption
On Mon, 18 Oct 2010 14:39:19 -0700 (PDT) Doug Barton do...@dougbarton.us wrote: On Mon, 18 Oct 2010, Owen DeLong wrote: I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking. Q:Why are /48s everywhere a good idea? A:Because it's the design! Q:Why are /48s everywhere in the design? A?Because it's a good idea! This kind of crap is one of the reasons people get frustrated with IPv6 zealotry. If people are actually interested in deploying IPv6 then by all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the wrong allocation to end users are fixable, especially given that the vast majority of end user assignments are dynamic in the first place. The model I've been advocating is for ISPs (who have enough space) to start off reserving a /48 per customer and then assigning the first /56 from it. If after real operational experience it turns out /48 is the right answer, you're all set. If /56 turns out to be sufficient, when you use up all of the first /56s you can start on the first /56 in the second /49, etc. While I like the idea of /48s per customer (per-nearly everybody), I do think this approach is a good, slightly more conservative approach. Regards, Mark.
Re: Choice of network space when numbering interfaces with IPv6
On Sat, 16 Oct 2010 12:31:22 +0100 Randy Bush ra...@psg.com wrote: http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt Drafts are drafts, and nothing more, aren't they?
Re: Choice of network space when numbering interfaces with IPv6
On Sat, 16 Oct 2010 15:26:54 -0700 Kevin Oberman ober...@es.net wrote: Date: Sun, 17 Oct 2010 00:40:41 +1030 From: Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org On Sat, 16 Oct 2010 12:31:22 +0100 Randy Bush ra...@psg.com wrote: http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt Drafts are drafts, and nothing more, aren't they? Drafts are drafts. Even most RFCs are RFCs and nothing more. No, drafts are documents that can be submitted by anybody, and can say anything, where as RFCs have been through an IETF evaluation process. Only a handful have ever been designated as Standards. I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.) The point is to READ the draft arguments and see why /127s are the right way to address P2P circuits. I suggest you search the v6ops mailing list, as I've read it multiple times, including all revisions, and have pointed out multiple issues with it. Also, you might note the contributors to the draft. They are people well know on this list who have real, honest to goodness operational experience in running networks and really understand that a /64 on a P2P connection is a serious security problem. As do I. You can see my analysis of the issue, and how I think it should be fixed properly, not mitigated for one type of link at the following URLs. http://www.ops.ietf.org/lists/v6ops/v6ops.2010/msg00543.html http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html
Re: Choice of network space when numbering interfaces with IPv6
Hi Kevin, On Sat, 16 Oct 2010 20:13:22 -0700 Kevin Oberman ober...@es.net wrote: Date: Sun, 17 Oct 2010 10:24:41 +1030 From: Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org On Sat, 16 Oct 2010 15:26:54 -0700 Kevin Oberman ober...@es.net wrote: Date: Sun, 17 Oct 2010 00:40:41 +1030 From: Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org On Sat, 16 Oct 2010 12:31:22 +0100 Randy Bush ra...@psg.com wrote: http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt Drafts are drafts, and nothing more, aren't they? Drafts are drafts. Even most RFCs are RFCs and nothing more. No, drafts are documents that can be submitted by anybody, and can say anything, where as RFCs have been through an IETF evaluation process. Only a handful have ever been designated as Standards. I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.) The point is to READ the draft arguments and see why /127s are the right way to address P2P circuits. I suggest you search the v6ops mailing list, as I've read it multiple times, including all revisions, and have pointed out multiple issues with it. Also, you might note the contributors to the draft. They are people well know on this list who have real, honest to goodness operational experience in running networks and really understand that a /64 on a P2P connection is a serious security problem. As do I. You can see my analysis of the issue, and how I think it should be fixed properly, not mitigated for one type of link at the following URLs. http://www.ops.ietf.org/lists/v6ops/v6ops.2010/msg00543.html http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html I don't entirely agree with your arguments, but the approach looks, at first glance, to be quite interesting and could quite possibly fix the problem. I'll need to digest it a bit better. Have you or someone else authored a draft on this proposal? I've started writing one on the nonce solution, as it can be made to interoperate with existing deployed ND NS/NA mechanisms. Regards, Mark. In the meantime, I still support /127s for P2P links. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.netPhone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Choice of network space when numbering interfaces with IPv6
Hi, On Fri, 15 Oct 2010 12:26:13 -0700 Zaid Ali z...@zaidali.com wrote: SO I have been turning up v6 with multiple providers now and notice that some choose /64 for numbering interfaces but one I came across use a /126. A /126 is awfully large (for interface numbering) and I am curious if there is some rationale behind using a /126 instead of a /64. If you're not going to follow the IPv6 Addressing Architecture, which says /64s for everything, then the prefix length decision is pretty much arbitrary - there is nothing that special about /112s, /126s, /127s or /128s (or /120s or /80s) - they all break something in the existing IPv6 RFCs so once you've passed that threshold then you're really only choosing your poison. If you're going to go down that latter path, I'd suggest reserving a /64 for each link, and then using a longer prefix length out of that /64 when you configure the addressing, to make it easier if you decided to change back to /64s at a later time. Regards, Mark.
Re: router lifetime
On Sat, 2 Oct 2010 22:27:32 -0300 jim deleskie deles...@gmail.com wrote: If you can do a business case to support replacing routers every 3years you doing much better then most. IMO a router should last 5 yrs on the book, but I expect to get more life then then from it. You core today is tomorrow's edge. I've seen more then one network with 10 yo kit still being used. Agree. If you're large enough to have your own pool of replacement hardware for anything critical, then using it until it fails isn't a bad strategy. That being said, support for fixing of software security bugs has probably shortened the production life of a lot of perfectly useful hardware. One risk people haven't mentioned is the risk of leaving it in production so long that people think it is fake ;-) http://groups.google.com.au/group/comp.dcom.sys.cisco/browse_thread/thread/7f74397a10380a7a/66c3dfb0f280e830?hl=enBc3dfb0f280e830 -jim On Sat, Oct 2, 2010 at 10:22 PM, Brandon Kim brandon@brandontek.comwrote: Well a lot of routers even 3 years ago support IPv6. You can dual-stack pretty much any router today if you have the right IOS. But I do understand your concern, if you want to future proof your purchase, I'd think any modern router today with a good support contract will take care of you for quite some time. Make sure it's not close to EOL. What kind of router are you considering? Is this for a large network? What are the network needs? Date: Sat, 2 Oct 2010 17:09:20 -0700 From: fra...@genius.com To: nanog@nanog.org Subject: Re: router lifetime I'm looking at various scenario, but basically it is looking at IPv6 in fact. It seems to me, that using a router/network appliance today for IPv6 will need to be replaced in 3 years or less. Looking at past, anything older than 3 years is not a viable solution for deploying IPv6. So I feel that routing/network appliance equipment have a life cycle similar to a PC, despite the fact as someone pointed out, they will run fine for many many years. - Original Message - From: Heath Jones hj1...@gmail.com To: Franck Martin fra...@genius.com Cc: nanog@nanog.org Sent: Saturday, 2 October, 2010 4:34:40 PM Subject: Re: router lifetime How long do you keep a router in production? What is your cycle for replacement of equipment? Hi Franck It really depends on the type of network you are running, the rate at which new features bandwidth are required, and the availability of software and hardware upgrades. Also, in a lot of cases it is vendor driven - devices that are still very much in production are forced to be replaced because of vendor product lifecycle and the phasing out of support, even when serving their requirements well. Care to elaborate a little more on your planned scenario? Cheers Heath
Re: RIP Justification
On Wed, 29 Sep 2010 15:35:06 -0500 Christopher Gatlin ch...@travelingtech.net wrote: RIPv2 is a great dynamic routing protocol for exchanging routes with untrusted networks. RIPv2 has adjustable timers, filters, supports VLSM and MD5 authentication. Since it's distance vector it's much easier to filter than a protocol that uses a link state database that must be the same across an entire area. I think BGP is better for that job, ultimately because it was specifically designed for that job, but also because it's now available in commodity routers for commodity prices e.g. Cisco 800 series. Chris On Wed, Sep 29, 2010 at 3:29 PM, Gary Gladney glad...@stsci.edu wrote: I would think it would depend on the complexity of the network and how the network advertises routes to peer networks. I'm always in favor the simpler the better but with RIP you do lose the ability to use variable bit masks (CIDR) and faster routing algorithms like DUAL used in Cisco routers and I'm not a big fan of OSPF. Gary -Original Message- From: Jesse Loggins [mailto:jlogginsc...@gmail.com] Sent: Wednesday, September 29, 2010 4:21 PM To: nanog@nanog.org Subject: RIP Justification A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet never to be seen or heard from again. Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions. -- Jesse Loggins CCIE#14661 (RS, Service Provider)
Re: RIP Justification
On Wed, 29 Sep 2010 17:26:17 -0400 Craig cvulja...@gmail.com wrote: We have a design for our wan where we use rip v2 and it works very well, we were using ospf but it was additional config, so in our case simple was better, and it works well.. I'm don't really buy the extra config argument. It's literally differences measured in seconds or minutes between the configuration effort, and in the context of the operational benefits over time of link state verses distance vector, I think they're worth spending. However, if you want a really simple OSPF config, the following two lines will make OSPF just work everywhere it can on a Cisco router router ospf 64512 network 0.0.0.0 255.255.255.255 area 0 One of the large delays you see in OSPF is election of the designated router on multi-access links such as ethernets. As ethernet is being very commonly used for point-to-point non-edge links, you can eliminate that delay and also the corresponding network LSA by making OSPF treat the link as a point-to-point link e.g. int ethernet0 ip ospf network point-to-point If your implementation doesn't support point-to-point mode for an interface, point-to-multipoint mode on an ethernet would achieve something somewhat equivalent. I could discuss it more with you off-line if you like. On Sep 29, 2010, at 4:20 PM, Jesse Loggins jlogginsc...@gmail.com wrote: A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet never to be seen or heard from again. Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions. -- Jesse Loggins CCIE#14661 (RS, Service Provider)
Re: RIP Justification
On Wed, 29 Sep 2010 19:31:26 -0500 Christopher Gatlin ch...@travelingtech.net wrote: My point here is untrusted networks, such as business partners exchanging routes with each other. Not many hops and less than a 100 prefixes. Using BGP to exchange routes between these types of untrusted networks is like using a sledgehammer to crack a nut. BGP was designed for unique AS's to peer in large scale networks such as the internet. A far cry from business partners exchanging dynamic routes for fault tolerance. I've used BGP quite a fair bit, for both Internet scale and small scale routing scenarios such as the one I recommended. How do you prevent those business partners spoofing specific route announcements within the RIP update, intentionally or otherwise, such as a default route, causing either outages or attracting traffic towards their networks that shouldn't be? A shared RIP MD5 key between the routers doesn't validate the route information within the RIP update. All the routers within your business partner domain will blindly accept and trust the routing information in any and all of the RIP updates they receive. Do the businesses attached have a multilateral or bi-lateral routing relationship? If routing relationship is multilateral, which is likely because you're using RIP, are the business partners using IPsec to ensure that if the routing is subverted, their traffic isn't disclosed to partners it shouldn't be? The scenario you're describing sounds pretty much exactly like a internet/peering exchange is between ISPs. The routing security issues are similar if not the same. In either multilateral or bi-lateral routing scenarios, BGP will provide you with the mechanisms needed to provide more trustworthy routing in these peer exchange type scenarios. I've seen RIPv2 very successfully deployed in modern networks in this fashion. Popular doesn't always equal good. Britney Spear's music is a testament to that. The threshold of success isn't if something works. It's whether it continues to work in the face of adversity. I'd think your business partner customers would expect a highly available service that is resilient to predictable and preventable adverse events, with a fairly likely one to be accidental route injection. I advocate using an appropriate tool for the job. As do I, and therefore I don't worry to much about the specific scenarios the tool was designed for - if the chosen tool provides the most appropriate and relevant benefits for an acceptable cost, the original design scenario doesn't matter. Regards, Mark.
Re: RIP Justification
On Thu, 30 Sep 2010 14:13:11 +1000 Julien Goodwin na...@studio442.com.au wrote: On 30/09/10 13:42, Mark Smith wrote: One of the large delays you see in OSPF is election of the designated router on multi-access links such as ethernets. As ethernet is being very commonly used for point-to-point non-edge links, you can eliminate that delay and also the corresponding network LSA by making OSPF treat the link as a point-to-point link e.g. int ethernet0 ip ospf network point-to-point If your implementation doesn't support point-to-point mode for an interface, point-to-multipoint mode on an ethernet would achieve something somewhat equivalent. Do any implementations go point-to-point automatically if an ethernet has a /30 or /31 mask? Don't know. If you want to see what interface model OSPF is using, on a Cisco you use show ip ospf interface blah The interface type for loopback interfaces can be a bit surprising and the consequences a bit unexpected if you're intentionally or otherwise not using a /32 prefix length on one. Regards, Mark.
Re: Online games stealing your bandwidth
On Sat, 25 Sep 2010 16:56:21 -0400 (EDT) Jon Lewis jle...@lewis.org wrote: On Sat, 25 Sep 2010, Rodrick Brown wrote: If you follow the links in the article people are complaining that the LotR process has served 70gb in a week, others are complaining that the service is resulting in 300ms pings, and unusable connections. This is a very grey area it will be interesting how this issue unfolds in the long run. I haven't played any of these things, so I don't know what they put in the fine print, but unless LotR makes it clear that they're going to utilize your (i.e. players of the game) bandwidth to PTP distribute their software, I'd call that theft and unauthorized use of a computer network. Skype have been doing this for years to ISP users who have public IP addresses, which is how they get around NAT without having giant publicly addressed relay servers. I don't know how much effort they got to to notify users via the TCs. The only real difference here seems to be the volume of traffic involved. Are these companies not making enough in monthly subscriptions to afford Akamai or similar CDN services to distribute their software updates? -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
On Mon, 13 Sep 2010 08:06:03 -0700 Leo Bicknell bickn...@ufp.org wrote: In a message written on Mon, Sep 13, 2010 at 09:44:40AM -0500, Brian Johnson wrote: OK... so doesn't this speak to the commoditization of service providers? I'm against more regulation and for competition. Competition would be wonderful, but is simply not practical in many cases. Most people and companies don't want to hear this, but from a consumer perspective the Internet is a utility, and very closely resembles water/sewer/electric/gas service. That is, having 20 people run fiber past your home when you're only going to buy from one of them makes no economic sense. Indeed, we probably wouldn't have both cable and DSL service if those were both to the home for other reasons already. Explain how the provider of access is supposed to be able to control all of the systems outside it's control to get a specific speed from a content provider. If you are espousing contracts with each content provider, then you will quickly be destroying the Internet. That's not exactly what I am proposing; rather I'm proposing we (the industry) develop a set of technical specifications and testing where we can generally demonstrate this to be the case. Of course, things may happen at any time, this isn't about individual machines, or flash mobs. That's why there isn't much value in them. You can't predict when these sorts of events are going to happen, so why would you want to make any sort of illusionary statements about assurances of service. The Internet is a best effort, not perfect effort, network. It does it's best with what is available at the time. There seems to be a fair bit of confusion between access rate and committed rate - some customers think access rate is committed rate. As mentioned earlier, because an ISP doesn't control the Internet, they can't make any committed rate assurances. What they can control is the access rate, and try to ensure that the access rate, which is dependent on what the customer is paying, marginally exceeds the common rate they can deliver to the customer, so that most of the time the customer sees the value in the bandwidth they've purchased. If there is too big a gap i.e. the customer never sees their link fully utilised, rather than occasionally, and hopefully quite often, they'll feel they've been sold something that isn't being delivered. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: largest OSPF core
On Thu, 02 Sep 2010 15:20:05 +0300 lorddoskias lorddosk...@gmail.com wrote: I'm just curious - what is the largest OSPF core (in terms of number of routers) out there? Presuming OSPF and IS-IS SPF costs are fairly similar, the following page from The complete IS-IS routing protocol (really quite a good book, a bit of a shame that there are occasional minor errors that better technical editing would have picked up) shows that relatively modern (although a number of years old now) routers can perform SPF calcs on SPF databases with 1 routers and 25000 links in less than a second. From that, it would seem that areas / levels are obsolete for most networks for the purposes of reducing SPF calculation time. Still possibly useful for route aggregation, although if BGP is carrying nearly all your routes, that may not be that useful either. http://books.google.com.au/books?id=NxIadsCKZxMClpg=PP1dq=IS-ISpg=PA481#v=onepageqf=false
Re: ICMPv6 rate limits breaking PMTUD (and traceroute) [Re: Comcast enables 6to4 relays]
On Wed, 01 Sep 2010 23:18:55 +0200 Simon Leinen simon.lei...@switch.ch wrote: Jack Bates writes: 1) Your originating host may be breaking PMTU (so the packet you send is too large and doesn't make it, you never resend a smaller packet, but it works when tracerouting from the other side due to PMTU working in that direction and you are responding with the same size packet). Your mentioning PMTU discovery issues in connection with 6to4 prompts me to confess how our open 6to4 relay has probably contributed to the perception of brokenness of 6to4 for quite a while *blush*. The relay runs on a Cisco 7600 with PFC3 - btw. this is an excellent platform to run an 6to4 relay on, because it can do the encap/decap in hardware if configured correctly. At some point of the relay becoming popular (load currently fluctuates between 80 Mb/s and 200 Mb/s), I noticed that our router very often failed to send ICMPv6 messages such as packet too big. That potentially starts to explain why I haven't noticed PMTUD issues on my 6to4 tunnel that I've been running for a number of years, and have been quite surprised be and somewhat doubtful of people to say there are issues. I've pumped the MTU up to 1472 on it to suit my PPPoE 1492 MTU, instead of leaving it at 1280, and haven't had any issues that have made me suspect PMTUD. I'm in Asia Pacific so I've probably either been using 6to4 gateways that are lightly used, or ones that have had this parameter changed. First I suspected our control-plane rate-limit (CoPP) configuration, but couldn't find anything there. Finally I found that I had to configure a generous ipv6 icmp error-interval[1], because the (invisible) default configuration will only permit one such ICMPv6 message to be generated every 100 milliseconds, and that's WAY insufficient for a popular router. We currently use ipv6 icmp error-interval 2 100 (max. steady state rate 500 ICMPv6s/second - one every 2 milliseonds - with bursts up to 100) with no ill effects. Note that the same rate-limit will also cause stars in IPv6 traceroutes through popular routers if the default setting is used. The issue is probably not restricted to Cisco, as the ICMPv6 standard (RFC 4443) mandates that ICMPv6 error messages be rate limited. It even has good (if hand-wavy) guidance on how to arrive at defaults - the values used on our Cisco 7600 (and possibly all other IOS devices?) correspond to the RFC's suggestion for a small/mid-size device *hrmpf* (yes Randy, I know I should get real routers :-). Anybody knows which defaults are used by other devices/vendors? In general, rate limits are very useful for protecting routers' notoriously underpowered control planes, but (1) it's hard to come up with reasonable defaults, and (2) I suspect that not most people don't monitor them (because that's often hard), and thus won't notice when normal traffic levels trip these limits. -- Simon. [1] See http://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_06.html#wp2135326
Re: Should routers send redirects by default?
On Wed, 25 Aug 2010 01:18:15 -0400 Christopher Morrow christopher.mor...@gmail.com wrote: On Tue, Aug 24, 2010 at 4:32 PM, William Herrin b...@herrin.us wrote: On Fri, Aug 20, 2010 at 1:20 PM, Christopher Morrow christopher.mor...@gmail.com wrote: Polling a little bit here, there's an active discussion going on 6...@ietf about whether or not v6 routers should: o be required to implement ip redirect functions (icmpv6 redirect) o be sending these by default Hi Chris, If you don't mind, I'd like to ask a similar question whose answers might be instructive for the question you asked: sure :) (other folks should also chime in, or I thought that was the spirit of your question...) Forgetting all of the theoretical constructs for a moment, has anyone here personally encountered an operational scenario in which ICMP redirects solved a problem for you that you would otherwise have found difficult or intransigent? Without naming names, would you describe the scenario's details, explain the problem that would have existed absent redirects and explain how redirects solved it for you? I've never had redirects solve a problem for me. So how do you know? If redirects are enabled by default, then they may have fixed a problem for you that you didn't know existed and never realised existed. When your packets get there successfully you don't go and investigate why. You only troubleshoot failure, not success. I think the only way to know an absolute answer would be to have witnessed this sequence of events - have an environment where redirects are switched off - suffer from a problem that redirects are designed to solve - switch redirects on and have the problem not disappear Of course, the problem not disappearing when redirects are enabled might also mean a misdiagnosis of what the problem really is. Regards, Mark.
Re: Should routers send redirects by default?
On Tue, 24 Aug 2010 13:25:01 -0700 David W. Hankins david_hank...@isc.org wrote: On Sun, Aug 22, 2010 at 10:12:01AM +0930, Mark Smith wrote: o allow an IPv6 router to indicate to an end-node that the destination it is attempting to send to is onlink. This situation occurs when the router is more informed than the origin end-node about what prefixes are onlink. This shouldn't happen very often either, as multiple onlink IPv6 routers should be announcing the same Prefix Information Options in their RAs, and therefore end-nodes should be fully informed as to all the onlink prefixes. ICMPv6 redirects in this scenario would only occur during the introduction of that new prefix information i.e. the time gap between when the first and second onlink routers are configured with new prefix information. It may be true the situations where redirects are required for this are few in number, but I think it is not true that the use of redirects is limited solely to the configuration gap between introducing a new prefix. In NBMA networks, it is said that the nodes will have IPv6 addresses with no covering advertised prefixes (IPv6 Core Protocols Implementation, page 393, just spotted while reading today). Additionally, the typical use of /128 role addresses for services aliased onto lo0 mean the router has a /128 route for the role address to an on-link device, but a covering prefix advertisement would be both futile and inappropriate. I don't necessarily want to say that your conclusion is false, but rather that it seems to me there are more enumerations in the set. Before coming to any conclusions, we'd need to more strictly define what the NBMA topology is. Is it fully transitive i.e. all nodes can see all other nodes, and that the only property that makes it different from a conventional LAN is the absence of a broadcast/multicast capability? Or is there only partial visibility, such that end-nodes only have permanent visibility to a router i.e hub-and-spoke? In the latter case, another property is whether or not direct communcations paths can be set up between the spoke nodes on demand, such as in the case of Dynamic Multi-point VPNs. Whether ICMPv6 redirects are necessary or useful, or whether other somewhat similar mechanisms, such as Next Hop Resolution Protocol, are used in an NBMA subnet very much depends on the sort of connectivity it provides or can provide between the nodes on the subnet. Regards, Mark.
Re: PacketShader
On Mon, 23 Aug 2010 05:59:43 -0400 valdis.kletni...@vt.edu wrote: On Sun, 22 Aug 2010 22:23:19 -1000, Michael Painter said: Researchers in South Korea have built a networking router that transmits data at record speeds from components found in most high-end desktop computers http://www.technologyreview.com/communications/26096/?nlid=3423 Two great quotes from the article: That isn't fast enough to take advantage of the full speed of a typical network card, which operates at 10 gigabytes per second. Anybody got a network of PCs that have cards that run at 10GBytes/sec? ;) I missed that, and that answers the was it a GigaBytes verses Gigabits error question. Nothing new here by the looks of it - people in this thread were getting those sorts of speeds a year ago out of PC hardware under Linux - http://lkml.org/lkml/2009/7/15/234 I have achieved a collective throughput of 66.25 Gbit/s. We've achieved 70 Gbps aggregate unidirectional TCP performance from one P6T6 based system to another.
Re: Other NOGs around the world?
On Mon, 23 Aug 2010 05:51:53 +1000 Matthew Palmer mpal...@hezmatt.org wrote: On Mon, Aug 23, 2010 at 12:42:03AM +1000, Karl Auer wrote: On Sun, 2010-08-22 at 10:17 -0400, Marshall Eubanks wrote: On Aug 22, 2010, at 9:52 AM, Rogelio wrote: What other network operator groups are there around the world (besides NANOG)? AusNOG. At a bit of a low S:N right now. We have been leading up to a Federal election, with two big tech issues involved - a new national broadband network and Internet censorship. These two topics have rather dominated discussions of late. Politics on an operational list? NEVAH! Fighting off censorship means not having to find rack space and cooling for large amounts of gear, and trying to engineer to have gobs of bandwidth go through latency inducing single points of failure :-) Regards, Mark.
Re: end-user ipv6 deployment and concerns about privacy
On Thu, 19 Aug 2010 01:35:50 +0200 Hannes Frederic Sowa han...@mailcolloid.de wrote: On Wed, Aug 18, 2010 at 11:41 PM, Jack Bates wrote: Web portals work fine, and honestly, it's not like you need to switch subnets, either. PPPoE/A implementations work great, as they are already designed to utilize radius backends to quickly alter static/dynamic on a session. For bridging setups, you have a variety of implementations and it becomes messier. Cisco, while maintaining RBE did away with the concept of proxy-nd, and didn't provide a mechanism for dynamically allocating the prefixes to the unnumbered interface. If you use dslam level controls, you'll most likely being using DHCPv6 TA addressing with PD on top of it, which works well. Most of which can support quick static/dynamic capabilities as it does with v4. Thanks. I will have a deeper look in the standards. This sounds like a viable solution to me. Albeit, I wonder if there is a drive for the big ISPs to implement such features. Potentially it's a value add that small ISPs can use to distinguish their basic packet transport services from their larger competitors.
Re: Should routers send redirects by default?
On Sat, 21 Aug 2010 09:12:47 -0500 Jack Bates jba...@brightok.net wrote: Eric J. Katanich wrote: You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned some routers need to handle this in software instead of hardware, which is obviously slower. Most redirects are limited in their rate, so it generally is unnoticed on the router, but yes, to be fully optimized, turning it off isn't a bad idea. Here's a better one. Put the router's choice in the RA on a per prefix basis (and of course DHCPv6 for non-RA setups). I'm don't think that would work. In IPv6, redirects serve two purposes, where as in IPv4 they only served one - o allow an IPv6 router to indicate to an end-node that another onlink IPv6 router is a better path towards the destination (i.e. the IPv4 purpose). This situation doesn't seem to occur very often - when there are two routers on a link they're usually there for availability, rather than presenting a significantly different set of paths to potential offlink destinations. Usually they'll be hidden behind a single virtual router via HSRP or VRRP. o allow an IPv6 router to indicate to an end-node that the destination it is attempting to send to is onlink. This situation occurs when the router is more informed than the origin end-node about what prefixes are onlink. This shouldn't happen very often either, as multiple onlink IPv6 routers should be announcing the same Prefix Information Options in their RAs, and therefore end-nodes should be fully informed as to all the onlink prefixes. ICMPv6 redirects in this scenario would only occur during the introduction of that new prefix information i.e. the time gap between when the first and second onlink routers are configured with new prefix information. So a redirect status parameter isn't prefix specific. Any router/host communication agreements really should have a profile setup. If the router is acting in a certain way, it should be able to notify the host. If RA is disabled and a pure DHCPv6 setup was deployed, obviously the DHCPv6 server would need to provide the necessary router information (mtu, icmp unreachable support, etc). It bugs me that we setup automation support such as between routers and hosts and don't include all the different details that both really should agree on (such as icmp redirects, or even the ability to push routes to hosts, ie modify redirects to support prefix or host based redirects since we are starting over here). Jack
Re: end-user ipv6 deployment and concerns about privacy
On Thu, 19 Aug 2010 14:30:07 +0200 Joakim Aronius joa...@aronius.com wrote: * Hannes Frederic Sowa (han...@mailcolloid.de) wrote: But most people just don't care. My proposal is to have some kind of sane defaults for them e.g. changing their prefix every week or in the case of a reconnect. This would mitigate some of the many privacy concerns in the internet a little bit. Of course all the already known problems would still exist. And still people have to care about the technology to reach a higher level of anonymity. Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover). But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point. Constantly changing prefixes will ad another layer of complexity, things will break, and customers will be upset. (and quite frankly I don't think that you would gain that much privacy anyway) ULA - RFC4193. (People really need to stop thinking in IPv4 mode when discussing IPv6 ) just my $.02 /Joakim
Re: Should routers send redirects by default?
On Fri, 20 Aug 2010 19:49:43 -0400 Ricky Beam jfb...@gmail.com wrote: On Fri, 20 Aug 2010 13:20:58 -0400, Christopher Morrow christopher.mor...@gmail.com wrote: Polling a little bit here, there's an active discussion going on 6...@ietf about whether or not v6 routers should: o be required to implement ip redirect functions (icmpv6 redirect) o be sending these by default ... In ipv4 there's a relatively widely used practice of disabling ip redirects. I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.) In a perfectly run network, redirects should never be necessary, so I'd think IPv6 should avoid going down that road again. (support OPTIONAL, never enabled by default.) [It's another insecure mistake IPv6 doesn't need to repeat.] You're assuming the cost of always hair pinning traffic on an interface is cheaper than issuing a redirect. Sometimes it won't be. 1 ICMP redirect could result in potentially congestion inducing load being shifted off of a single router's interface. It seems that there might be a common and unstated assumption here that ever router uses hardware forwarding and has high speed 1Gbps+ interfaces that have 50% utilisation. The majority of routers - CPE - don't meet that assumption. As I recall from long long ago, Cisco IOS would deal with traffic differently depending on redirects... with redirects enabled, a redirect was sent and the packet dropped; with redirects disabled, the router hairpined the packets. I honestly don't know what today's versions do because I've never checked -- A can ping B, I move on. I turn redirects off on *outside* interfaces. Inside (trustable) interfaces vary -- I don't go out of my way to disable them. --Ricky
Re: Should routers send redirects by default?
On Fri, 20 Aug 2010 21:24:43 -0400 Ricky Beam jfb...@gmail.com wrote: On Fri, 20 Aug 2010 20:43:39 -0400, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: You're assuming the cost of always hair pinning traffic on an interface is cheaper than issuing a redirect. I am saying no such thing. (a single redirect packet is always more efficient.) I *am* saying ICMP redirects are a mistake that should not be replicated in IPv6. They are too easy to abuse, which is why they are almost universally ignored by IPv4 hosts. I thought we were talking about IPv6 redirects not IPv4 ones. How much do you know about their operation and purposes? In a *properly* configured network, redirects should not be necessary. (everything on the local LAN should know what's on the local LAN.) [For the record, my own networks don't follow that rule. :-) Coworkers throwing random crap on the wire doesn't help. *sigh* Don't go there.] IPv6 has more than enough mistakes glued into it. Redirects are a mess that does not need to be there. For the purests who insist on making ugly networks that are trival to subvert, make ICMPv6 redirects *OPTIONAL*, *REQUIRING* explicit configuration to enable. Without strong authentication/authorization mechanisms, it'll be the same mess that it is in IPv4. Know anything about IPv6 SeND? --Ricky
Re: end-user ipv6 deployment and concerns about privacy
On Wed, 18 Aug 2010 01:12:19 +0200 Hannes Frederic Sowa han...@mailcolloid.de wrote: Hello! As the first IPv6 deployments for end-users are in the planning stage in Germany, I realized I have not found any BCP for handling addressing in those scenarios. IPv6 will make it a lot easier for static address deployments but I wonder weather this is in the best sense for the customers. As I normally come from the technical side I prefer static addressing. But in the world of facebook and co. I wonder if it would be a better to let the user have the choice. A major provider of dsl here in Germany recently blogged about this [1]. Their proposal is to serve two subnets, one being a static one while the other one will be dynamically allocated. I have no clue how the user would switch between these subnets (without using some kind of command line tools). This is not about using privacy extensions as the subnet is sufficient for identification. Did you reach any conclusion on this matter? Haven't really thought about it before. One thing to consider is that unless the preferred and valid lifetimes of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic - they'll eventually expire unless they're refreshed. The preferred and valid lifetimes for prefixes that are delegated to customers could be something that they might be able to change via a web portal, bounded to within what you as an ISP are happy with e.g. 1 to 30 days, rather than the absolute range of lifetime values supported. CPE could also potentially do the same thing with the range of subnets it has been delegated, by phasing in and out subnets over time on it's downstream interfaces. (The more subnets the better, so a /48 would be ideal for this.) As you've mentioned, privacy addresses help. A related idea is described in Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host. [0], Peter M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64 addresses in a /64, and has different applications on the same host use different source IPv6 addresses. Pretending to be multiple hosts, or even just one with privacy addresses, moving around multiple subnets, on delegated prefixes that change fairly regularly would probably mitigate quite a lot of the privacy concerns people may have related to IPv6 addressing. Regards, Mark. [0] http://www.cs.columbia.edu/~smb/papers/tarp.pdf
Re: end-user ipv6 deployment and concerns about privacy
On Wed, 18 Aug 2010 16:18:00 +0200 Hannes Frederic Sowa han...@mailcolloid.de wrote: On Wed, Aug 18, 2010 at 12:34 PM, Mark Smith wrote: Haven't really thought about it before. One thing to consider is that unless the preferred and valid lifetimes of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic - they'll eventually expire unless they're refreshed. The preferred and valid lifetimes for prefixes that are delegated to customers could be something that they might be able to change via a web portal, bounded to within what you as an ISP are happy with e.g. 1 to 30 days, rather than the absolute range of lifetime values supported. CPE could also potentially do the same thing with the range of subnets it has been delegated, by phasing in and out subnets over time on it's downstream interfaces. (The more subnets the better, so a /48 would be ideal for this.) Yep, I am in favour of such setups. This will stress internal name services(eg. netbios) but would be a solvable problem, I think. As you've mentioned, privacy addresses help. A related idea is described in Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host. [0], Peter M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64 addresses in a /64, and has different applications on the same host use different source IPv6 addresses. Pretending to be multiple hosts, or even just one with privacy addresses, moving around multiple subnets, on delegated prefixes that change fairly regularly would probably mitigate quite a lot of the privacy concerns people may have related to IPv6 addressing. If your ipv6-geolocation-service tells you that all /48 prefixes behind this network are just static home-user networks, why not just ignore the lower 64 bits or even the lower 80 bits? Privacy extensions would be no help here. They help because you're concerned about privacy. You didn't qualify that you're only concerned about privacy from geolocation services, so I described a mechanism that would provide you as much privacy as possible, while also being automatic, and also continuing to provide IPv6 Internet connectivity. No where was cryto mentioned either (on both our parts), yet that is also a privacy mechanism. As a customer, it's relatively hard to hide from geolocation services because they use your IP address in combination with information that you don't have control over i.e. RIR / whois data. If a customer wants to hide from that, then they'll need to start tunnelling their traffic to another entry/exit point on the Internet. Much like security, privacy is relative. If you want to have bi-directional communications with another entity, you have to disclose your identity. How long you retain that identity is what makes one form of privacy more private than another. Customers who have high expectations of privacy won't trust their ISP at the time to preserve it - because, as the cliche goes, if you want something done properly, you need to do it yourself. So, as an ISP, you need to think about how much privacy you can provide, can afford to provide, and at what point it becomes irrelevant because your customer doesn't trust you to provide it at all. In IPv4-land I have the possibility to reconnect and get a new unrelated ip-address every time. They're issued by the same ISP, to they're related. Regards, Mark.
Re: end-user ipv6 deployment and concerns about privacy
On Wed, 18 Aug 2010 20:04:47 +0930 Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Wed, 18 Aug 2010 01:12:19 +0200 Hannes Frederic Sowa han...@mailcolloid.de wrote: Hello! As the first IPv6 deployments for end-users are in the planning stage in Germany, I realized I have not found any BCP for handling addressing in those scenarios. IPv6 will make it a lot easier for static address deployments but I wonder weather this is in the best sense for the customers. As I normally come from the technical side I prefer static addressing. But in the world of facebook and co. I wonder if it would be a better to let the user have the choice. A major provider of dsl here in Germany recently blogged about this [1]. Their proposal is to serve two subnets, one being a static one while the other one will be dynamically allocated. I have no clue how the user would switch between these subnets (without using some kind of command line tools). This is not about using privacy extensions as the subnet is sufficient for identification. Did you reach any conclusion on this matter? Haven't really thought about it before. One thing to consider is that unless the preferred and valid lifetimes of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic - they'll eventually expire unless they're refreshed. The preferred and valid lifetimes for prefixes that are delegated to customers could be something that they might be able to change via a web portal, bounded to within what you as an ISP are happy with e.g. 1 to 30 days, rather than the absolute range of lifetime values supported. In case it isn't clear, the customer would have multiple delegated IPv6 prefixes during the overlap period. New prefixes are phased in and old ones are phased out. Over what time period the phase in / phase out occurs is what the customer could have the ability to change. Changing addresses will disrupt ongoing communications. While IPv6 can't prevent that disruption, it does have mechanisms available to handle it far more gracefully than the customer having to bounce their PPP session to acquire new addressing. With the right parameters, I think an ISP could make phasing in/phasing out prefixes transparent for most cases. CPE could also potentially do the same thing with the range of subnets it has been delegated, by phasing in and out subnets over time on it's downstream interfaces. (The more subnets the better, so a /48 would be ideal for this.) As you've mentioned, privacy addresses help. A related idea is described in Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host. [0], Peter M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64 addresses in a /64, and has different applications on the same host use different source IPv6 addresses. Pretending to be multiple hosts, or even just one with privacy addresses, moving around multiple subnets, on delegated prefixes that change fairly regularly would probably mitigate quite a lot of the privacy concerns people may have related to IPv6 addressing. Regards, Mark. [0] http://www.cs.columbia.edu/~smb/papers/tarp.pdf
Re: net-neutrality
On Wed, 11 Aug 2010 10:52:53 + (UTC) Sven Olaf Kamphuis s...@cb3rob.net wrote: Hi, considering the fact that several organisations have been severely undermining net-neutrality over the past few months, What is your definition of violating net-neutrality? Is it (a) carriers ransoming content providers so that only then will the content providers receive fair, equal and unfettered access to the carriers' customers? or (b) applying QoS to customer traffic if necessary because TCP was designed to suck up all the bandwidth available (to try to achieve 100% return on investment in the network capex), based on an original assumption that there'd be short bursts of TCP traffic, and now some applications, particular P2P ones, which use TCP, now create constant rather than bursty load on the network, resulting in congestion and impacting latency sensitive applications such as VoIP and gaming? which they seem to see as less important than their copyright bullshit, we have decided to set an example: Should the following networks, to which list more will be added over the coming month, desire to exchange traffic with AS34109, they can obtain a traffic relay contract at sa...@cb3rob.net, the costs of which amount to 1 euros per month, excl. 19% VAT, if not, well, then it's simply no more internets for them... sorry peeps. 193.108.8.0/21#GEMA-NET 195.109.249.64/29#SONYMUSIC 195.143.92.160/27#SBMG1-NETS 212.123.224.240/29#Net-WEGENER-MEDIA-BV 212.123.227.64/29#BumaStemra2 212.136.193.216/29#BUMA 212.78.179.240/28#BUMA-STEMRA 213.208.242.160/29#NL-COLT-BUMA-STEMRA 217.148.80.112/28#NL-NXS-CUST-1004613 85.236.46.0/24#IX-UNIVERSAL-NET -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited.
Re: Addressing plan exercise for our IPv6 course
On Tue, 27 Jul 2010 12:34:40 -0700 Owen DeLong o...@delong.com wrote: On Jul 27, 2010, at 12:05 PM, Akyol, Bora A wrote: Please see comments inline. On 7/22/10 10:13 PM, Owen DeLong o...@delong.com wrote: In all reality: 1. NAT has nothing to do with security. Stateful inspection provides security, NAT just mangles addresses. Of course, the problem is that there are millions of customers that believe that NAT == security. This needs to change. 2. In the places where NAT works, it does so at a terrible cost. It breaks a number of things, and, applications like Skype are incredibly more complex pieces of code in order to solve NAT traversal. I look at this as water under the bridge. Yep, it was complicated code and now it works. I can run bittorrent just fine beyond an Apple wireless router and I did nothing to make that work. Micro-torrent just communicates with the router to make the port available. It's only water under the bridge for IPv4. If we start putting NAT66 into play, it will be the same thing all over again. Additionally, it's only water under the bridge for existing applications. Each new application seems to go through the same exercise because for some reason, no two NAT gateways seem to have exactly the same traversal requirements and no two applications seem to implement the same set of traversal code. What is worse about that is that we networking people have ended up shifting the cost of fixing our problem onto the application developers and onto the application users. Because we don't provide end-to-end visibility between peers on the Internet (Internet transparency - see RFC4924), application developers have to try to develop methods of doing that themselves. As you've said, this creates additional application complexity, additional bugs, and duplicate functionality between different applications, all at the application layer. (HTTP has become the de facto substrate protocol of the Internet because firewalls permit it, and client server communication has become the de facto communications method for applications that would truly benefit from peer-to-peer communications (i.e. more scalable, more available), because client server overcomes the lack of global reachability NAT creates)) Who pays this additional application development cost? Everybody, including us networking people, because we also use applications too. We get code that is possibly more buggy because it is more complex, written by people who are usually not networking code experts. We might miss out on better user interfaces or less buggy code that's there to do what the application's purpose is, because that time was instead spent on developing network layer work arounds. It seems to me that the best place to solve problems is whether they exist or where they're caused. Those solutions usually solve the problem properly, and commonly are also the cheapest way to solve it. The network layer is where these problems exist, and that's where they should be solved. We should use IPv6 to restore Internet transparency, so that application developers don't have to do it for us - again. We'll end up with a better and simpler Internet to operate, and better and/or cheaper applications. Regards, Mark. The elimination of NAT is one of the greatest features of IPv6. Most customers don't know or care what NAT is and wouldn't know the difference between a NAT firewall and a stateful inspection firewall. I do think that people will get rid of the NAT box by and large, or, at least in IPv6, the box won't be NATing. Whether or not they NAT it, it's still better to give the customer enough addresses that they don't HAVE to NAT. Owen Of course, no disagreement there. The real challenge is going to be education of customers so that they can actually configure a firewall policy to protect their now-suddenly-addressable-on-the-Internet home network. I would love to see how SOHO vendors are going to address this. Not so much... SOHO gateways should implement stateful inspection with the same default policy a NAT box provides today... 1.Outbound packets create a state table entry. 2.Inbound packets are only forwarded if they match an existing state table entry. Pretty simple, actually. Owen
Re: Addressing plan exercise for our IPv6 course
On Sun, 25 Jul 2010 03:56:52 +1000 Karl Auer ka...@biplane.com.au wrote: On Sat, 2010-07-24 at 10:42 -0700, Owen DeLong wrote: You do have to properly set up the rules for which addresses to use for what communication properly. It breaks less if you forego the ULA brokenness, but, some people insist for whatever reason. What is the ULA brokenness? If it is address selection policy distribution, then this Internet Draft is aiming to solve that - Distributing Address Selection Policy using DHCPv6 http://tools.ietf.org/html/draft-fujisaki-6man-addr-select-opt-00.html Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
Re: Addressing plan exercise for our IPv6 course
On Sun, 25 Jul 2010 09:01:33 +0200 David Conrad d...@virtualized.org wrote: On Jul 25, 2010, at 8:42 AM, Jack Bates wrote: Doug Barton wrote: having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) whois. http://whois.iana.org what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry). With the exception of a routing registry (which I wasn't aware was an address allocation requirement), these services are provided by ICANN as part of the IANA functions contract. Out of curiosity, why do you think providing whois, POC management/validity, and even a routing registry requires a large staff? I think IANA would be perfect for ULA identifier assignments. No whois/poc/routing registry needed. Send email, get an identifier in a week or 2. As you note, ICANN already provides something like this as part of the protocol parameter function of the IANA functions contract for private enterprise numbers (OIDs). This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds. I remember arguments like that about why Token Ring was going to win over Ethernet :-) +1 +1 +1 (Was quite happy when I was able to have an 10Mpbs ethernet pulled from the floor below when my gov dept. was merged with another gov dept. and I was moved to their IT section - and they were using 4Mbps token ring) Of course being in business is a gamble in itself. They gamble on future profits occurring when they spend on product or service development, government regulation staying stable, cost bases that aren't going to dramatically change, and possibly currency values staying fairly stable (GFC type events being the ones that out bad gamblers). I doubt businesses will be all that uncomfortable with IPv6 ULA collision odds that are worse than winning the lottery. Given no additional services are needed, the administration cost is the same as handing out snmp enterprise oids. The fact that the community isn't offering such due to politics is disheartening and just plain sad. Indeed. I have stories... Regards, -drc (who no longer works for ICANN)
Re: Addressing plan exercise for our IPv6 course
On Sun, 25 Jul 2010 11:40:19 +0300 Saku Ytti s...@ytti.fi wrote: On (2010-07-25 17:32 +1000), Karl Auer wrote: The risk of a ULA prefix conflict is for *all practical purposes* zero. http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^100+((2^40)-100)!)+ It wouldn't puke nice graph with 'n', it did try, but never finished. So if there are million assigned ULA's there is 36.5% chance of collision, if formula is right. That's duplication, not collision. Collision only occurs when two ULA domains want to interconnect, and have duplicate routes they would like to exchange. Here is what the RFC says about odds - 3.2.3. Analysis of the Uniqueness of Global IDs The selection of a pseudo random Global ID is similar to the selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of [RTP]. This analysis is adapted from that document. Since Global IDs are chosen randomly (and independently), it is possible that separate networks have chosen the same Global ID. For any given network, with one or more random Global IDs, that has inter-connections to other such networks, having a total of N such IDs, the probability that two or more of these IDs will collide can be approximated using the formula: P = 1 - exp(-N**2 / 2**(L+1)) where P is the probability of collision, N is the number of interconnected Global IDs, and L is the length of the Global ID. The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field. Connections Probability of Collision 21.81*10^-12 104.54*10^-11 1004.54*10^-09 10004.54*10^-07 14.54*10^-05 Based on this analysis, the uniqueness of locally generated Global IDs is adequate for sites planning a small to moderate amount of inter-site communication using locally generated Global IDs. If operator fscks-up their residential DSL product, lets say the assign all the /128 user could want, but from single shared /64 subnet, not routing dedicated /48 to each customer. Users who need to route, will want solution and some vendor will step in, providing router which will auto-assign ULA + NAT66, will that vendor sell million copies of said CPE? But I don't think it is interesting to discuss the random chance of collisions, as human factor will guarantee collisions, many people will assign fd::/48 to get short and memorable addresses in their network. (You've made your bed, now lie in it.) That bed was called site locals, and the prefix was fec0::/10. If two separate organisations choose to make ULAs effectively site locals, and then join their ULA domains, then they deserve the pain they'll get because they haven't followed the RFC4193 formula. At the end of the day you can't stop people doing stupid things unless you take away the variables that they can set. If people are arguing that ULA specs won't be followed correctly, then any other IPv6 spec variable may also not be set correctly by the same person. Ultimately that means that incompetent networking people are running the network. I don't think you can use that as a valid reason to dismiss ULAs, and then not use it to dismiss the whole of IPv6 *and* IPv4. If your IT staff includes personnel who've done painful renumbering due to MA, there is good chance they'll allocate random, otherwise they'll likely opt for short and memorable network, as they did with RFC1918. Just because we get IPv6, doesn't mean people will get sudden burst of insight in design and engineering. -- ++ytti
Re: Addressing plan exercise for our IPv6 course
On Sat, 24 Jul 2010 10:57:49 -0700 Owen DeLong o...@delong.com wrote: On Jul 24, 2010, at 9:40 AM, Brandon Butterworth wrote: Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better. Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. SIXXS already has such a registry with a pretty low adoption rate. And I think that is good news. The fd00::/8 range is not defined as guaranteed globally unique. I'm concerned that the SIXXS registry could imply to those people who have used it, that it is. They may think that because that registry exists, and that they've used it, that address space it now theirs, and nobody else is allowed to use it. Once somebody perceives ownership of something they believe is unique, I think they commonly won't listen to reason about their actual lack of global ownership. fc00::/8 is for guaranteed globally unique ULAs. I still fail to see any advantage whatsoever to this approach and I think that the limited number of sites that implement it is unlikely to get continued support from ISVs. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. I think that will be a common PI alternative. If people really don't want NAT then we shouldn't provide reasons for it to exist. RFC4193 seems to be the best enterprise plan. They can link to other enterprises and change ISPs easily or multihome. They are not beholden to any ISP or numbering authority. The global table doesn't explode. I agree that easier to get PI addresses is a better alternative. I will support policy initiatives to do that. RFC4193 remains an utterly horrible idea and NATing it to the public internet remains even worse. Well I think RFC4193 is a great idea. I don't want my home network addressing to be bound to having a commercial arrangement with an ISP, or having an active Internet connection. I can also use the ULA prefix as a simple designator of trusted verses untrusted traffic sources in firewall rules. I see those advantages equally applicable to enterprise or ISP networks. Then again, I'm happy with the idea of multiple addresses on an interface, and source address selection. They're not much different to those issues in IPv4, such as unnumbered interfaces on routers, designated source addresses for router SNMP traps etc., or source address selection for policy routing. Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. Enterprises tend to want only one identifier to manage per device and that it be unique and mostly permanent. That's IPv4 thinking showing though. People fundamentally don't want change when they don't know of or understand the benefits they will gain. ULAs are an overhead, but they also provide benefits that can't be achieved with global address space assigned by an ISP. (I don't accept the PI argument, because it isn't feasible for residential networks). Right... That identifier is the EUI-64 which is both permanent and unique. The prefix changes when you switch providers, but, that's mostly not particularly horrible since there are tools to make that easier for the bulk of internal hosts. With several PA and ULA on each device, links to ISPs and other enterprises, the combinations of addresses and paths to manage flows and security over become too hard (if it's not simple it's probably not secure). Every device becomes a router and firewall and the staff who manage those aren't cheap. Actually, if you set things up correctly, most of the security stuff to manage is about the same because you hairpin the stuff that doesn't need filtration at a point before it hits the packet filters. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? And changing all the ACLs based on the old providers addresses Mostly this is a pretty straight forward copy-search-replace problem with prefix changes that can be done with the equivalent of an s/x/y/g construct. And allowing for all the 5 - 15 year old kit that predates this and won't be upgraded (we have that problem with NT embedded in systems with
Re: Addressing plan exercise for our IPv6 course
On Sat, 24 Jul 2010 19:41:18 +0100 (BST) Brandon Butterworth bran...@rd.bbc.co.uk wrote: The RFC provides for two address ranges in fc00::/7, one for random prefixes (fc00::/8), the other reserved for later management (fd00::/8). Later, in some undefined way. A PI lacking enterprise considering doing v6 this way either waits or decides the available space will do as someone will fix the managment later. Sixxs demonstrated that some will see a need With low take up of v6 it's early to know what they will see important The more important it is to you that your allocation be unique, the more careful you will be to choose a truly random one. So a way to have really unique is reasonable. The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. People still play the lotteries. And those people, and some others by the looks of it, don't appear to understand statistics and chance ... brandon
Re: Looking for comments
On Fri, 23 Jul 2010 11:18:39 +0100 Nick Hilliard n...@foobar.org wrote: On 23/07/2010 01:17, Mark Smith wrote: Does this qualify? What the customer sees is delivered over IPv6, unlike the CPE management problem, where the ISP is the IPv6 customer. IPv6: The Future of IPTV? In Japan it isn't the future, it's now. http://www.internetnews.com/dev-news/article.php/3795086/IPv6-The-Future-of-IPTV.htm I understand that there are several networks doing this; the STB - like the CPE modem - is managed by the service provider and the customer has no management / control access over it. The customer stays on ipv4 for their regular access product. Someone offline pointed me at the Google IPv6 Implementors 2010 conference, at which: https://sites.google.com/site/ipv6implementors/2010/agenda/13_Byrne_T-Mobile_IPv6GoogleMeeting.pdf?attredirects=0d=1 This is genuinely interesting. Certainly is. I've generally classified mobile operators as people who are heavily on the side of walled gardens. It's refreshing to see one advocating e2e and global reachability. Nick
Re: Addressing plan exercise for our IPv6 course
On Fri, 23 Jul 2010 13:26:43 -0700 Matthew Kaufman matt...@matthew.at wrote: sth...@nethelp.no wrote: It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons. It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so. I have no problems with giving the customer several subnets. /56 is just fine for that. /56? How about /62? That certainly covers several... and if you're really worried they might have too many subnets for that to work, how about /60? I haven't seen any kind of realistic scenarios which require /48 for residential users *and* will actually use lots and lots of subnets - without requiring a similar amount of manual configuration on the part of the customer. So we end up with /56 for residential users. Only because people think that the boundaries need to happen at easy-to-type points given the textual representation. /56 is still overkill for a house. And there's several billion houses in the world to hook up. So you're also strongly against 48 bit Ethernet MAC addresses? Dropping the two bits for group and local addresses, that's 70 368 744 177 664 nodes per LAN. How ridiculous! What were those idiots+ thinking! 48-bit Absolute Internet and Ethernet Host Numbers, by Yogan K. Dalal, Robert S. Printis, *July 1981* http://ethernethistory.typepad.com/papers/HostNumbers.pdf + not actually idiots
Re: Looking for comments
On Thu, 22 Jul 2010 23:57:22 +0100 Nick Hilliard n...@foobar.org wrote: On 22/07/2010 22:38, Brian E Carpenter wrote: As for those two scenarios (IPv6-only ISPs and IPv6-only clients, to simplify them), the document doesn't place them as first preference solutions. However, the fact is that various *extremely* large operators find themselves more or less forced into these scenarios by IPv4 exhaustion. Some of the extremely large operators have found themselves having to deploy ipv6 extensively in order to manage CPE devices and their infrastructure networks. However, I'm not aware of any large provider which is deploying ipv6-only customer access products, either due to a shortage of ipv4 space or any other reason. If you can supply names of providers doing this, I'd be very interested to hear. Does this qualify? What the customer sees is delivered over IPv6, unlike the CPE management problem, where the ISP is the IPv6 customer. IPv6: The Future of IPTV? In Japan it isn't the future, it's now. http://www.internetnews.com/dev-news/article.php/3795086/IPv6-The-Future-of-IPTV.htm That's not to say that they won't start doing this relatively shortly. And you correctly point out that we need to create solutions _now_ so that access providers will have feature equivalence when they start deploying ipv6 in anger on access / hosted networks. This is a cue to get people on this list to shout at their vendors for ipv6 feature equivalence on their favourite kit. Nick
Re: Addressing plan exercise for our IPv6 course
On Fri, 23 Jul 2010 00:33:45 +0100 Matthew Walster matt...@walster.org wrote: On 22 July 2010 14:11, Alex Band al...@ripe.net wrote: There are more options, but these two are the most convenient weighing all the up and downsides. Does anyone disagree? I never saw the point of assigning a /48 to a DSL customer. Surely the better idea would be to assign your bog standard residential DSL customer a /64 and assign them a /56 or /48 if they request it, routed to an IP of their choosing. I estimate that an addressing request will cost the ISP at least 15 minutes of time to process. When a minimum allocation of a /32 contains 16 777 216 /56s, do you really need to create that artificial addressing cost, eventually passed onto the customer? With more address space than we need, the value we get is addressing convenience (just like we've had in Ethernet addressing since 1982). There is no need to make IPv6 addressing artificially precious and as costly as IPv4 addressing is. There are a variety of scenarios where customers, including residential, will benefit from having multiple subnets. They may wish to separate the wired and wireless segments, to prevent multicast IPTV from degrading wireless performance. They may wish to segregate the children/family PC from the adult PC network or SOHO network, allowing the subnet boundary to be an additional Internet access policy enforcement point. They'll need separate subnets if they wish to use a different link layer technology, such as LoWPAN. They may wish to setup a separate subnet to act as a DMZ for Internet facing devices, such as a local web server for sharing photos with relatives. Game consoles may be put in a separate subnet to ensure file transfers don't interfere with game traffic latency, using the subnet ID as a QoS classifier. For the rest of it, I largely agree, though. M
Re: Addressing plan exercise for our IPv6 course
On Thu, 22 Jul 2010 19:53:48 -0700 Akyol, Bora A b...@pnl.gov wrote: As long as customers believe that having a NAT router/firewall in place is a security feature, I don't think anyone is going to get rid of the NAT box. You need to separate the NAT function (or more specifically, Network Address Port Translation (NAPT)), and the side effect of that operation being a deny all for uninitiated inbound traffic. It is not a unique property to NAPT, and in fact, stateful firewalling using public addresses has been around as long as NAT (at least since 1995 IIRC). In all reality, NAT boxes do work for 99% of customers out there. So would a firewall with public addressing. It's worked for me for 10+ years with IPv4, and 4+ years with IPv6. Of course, it didn't protect me when I ran an email attachment that contained malware, or when I clicked on one of those PC check popups that installed an application. (well, not actually me, but a large number of people do this, helping the attacker completely bypass any NAT security. Inviting the attacker in as though they were a trusted guest makes the best locks in the world on the door a waste of time.) It seems you haven't done much with NAT to have encountered it's limitations, or experienced the benefits of end-to-end connectivity (ever had to stuff around with port forwarding, TURN, STUN etc. to get VoIP working at home? I haven't, and I got to spend that time on something else much more useful than fiddling with NAT work arounds.) Bora On 7/22/10 7:34 PM, Owen DeLong o...@delong.com wrote: Well, wouldn't it be better if the provider simply issued enough space to make NAT66 unnecessary? Owen
Re: Addressing plan exercise for our IPv6 course
On Wed, 21 Jul 2010 18:57:01 +0200 Alex Band al...@ripe.net wrote: We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan. Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ I'm curious to hear if you think it's clear and useful. You could add a reference to addressing related RFCs e.g. RFC 5375 IPv6 Unicast Address Assignment Considerations Cheers, Alex Band RIPE NCC Trainer (Big props go to Marco Hogewoning @XS4ALL)
Re: Addressing plan exercise for our IPv6 course
On Wed, 21 Jul 2010 18:57:01 +0200 Alex Band al...@ripe.net wrote: We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan. Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ And I'd also explicitly mention that 2001:db8 is the documentation/example prefix. I'm curious to hear if you think it's clear and useful. Cheers, Alex Band RIPE NCC Trainer (Big props go to Marco Hogewoning @XS4ALL)
