Re: IPv6 Confusion
For me the bigger problem is how do I enable IPv6 on my assorted CE-facing edges when management is still buying edge hardware that can not and will not ever support IPv6. Find out if Randy Bush's companies are still buying non-IPv6-capable gear, and ask if you're a competitor to those companies... :) lol. fwiw, iij makes our own cpe which does dual stack, ipsec, ... see http://www.seil.jp/download/eng/ for the high end of the seil line. and there is an assortment of dual stack cpe available here, china, ... randy
Re: IPv6 Confusion
It's a 128 bit address. Routing is done on VLSM, but, generally for DNS purposes, these are expected to be at least on nibble boundaries. There is an intent to support what is known as EUI-64, which means every subnet should be a /64, however, there are people who number smaller subnets and that is supposed to work, but, it will break certain IPv6 things like stateless autoconfiguration (which is optional). We are one of these people who opted to use smaller subnet sizes for point-to-point networks (i.e router transfer nets), If you are interested in what we did and want to see some examples of what other people are doing check out a presentation that I gave some time ago about our deployment http://www.convergence.cx/ipv6clara.ppt (apologies for the lack of PDF) Slides 2-15 Dave.
Re: IPv6 Confusion
Nathan Ward wrote: Sort of - except it is only for IPv6 clients to connect to named IPv4 servers. NAT-PT allowed for the opposite direction, IPv4 clients connecting to IPv6 servers - NAT64 does not. Which is a serious mistake in my opinion. Corporate world will not or can not shift out of IPv4 for many years. They will use firewalls to handle conversions (4 inside, 6 outside). The legacy software that runs within corporations always astounds me, but it is what it is. I honestly doubt that a single vendor out there cares one lick about the IETF, and they will provide whatever their customers demand; or lose the customer. -Jack
Re: Cisco NOS
On Wed, Feb 18, 2009 at 3:51 PM, Bryant Valencia bvl...@gmail.com wrote: Has anybody hired Cisco for their NOS (Network Optimization Services)? I would like to hear about your experience (good or bad). I'm particularly interested in their CNC box. Either this is merely exquisite acronym collision, or someone from marketing was been slamming too much www.drinknos.com and reading about botnets on the FUNSEC list. As for the service, one of my old clients has been engaging Cisco for some years now for a variety of needs. The reports are, in their subjective use, basically positive. My opinion is simply that it's a formalization of stuff Cisco has been doing for years. That is, doing the good engineering and planning work that many organizations are not (for any number of reasons) doing themselves. When it comes to the sale of box A, B, and C, (where the value of the set is not obvious to, say, a rural co-op ILEC management team) a vendor providing 'staff embedded' engineering can easily be a determining factor in winning or losing. -Tk
Re: IPv6 Confusion
Mikael, On Feb 17, 2009, at 9:18 PM, Mikael Abrahamsson wrote: Suggestion: next time you buy equipment from competing vendors, tell the sales folk from the losing vendors that one deciding factor was (vendor or product) IPv6 support. That (and perhaps only that) will get their attention... :-) Well, considering how very few vendors actually support IPv6, it's hard to find proper competition. You don't have to tell the truth to the losing sales folk... :-) Regards, -drc
McAfee/ATT Issue
We are seeing intermittent connectivity issues via ATT to McAfee's Update service network (208.69.152.0/21). Attempts to contact McAfee Support and ATT support have gotten standard responses. If there is a McAfee Net Admin on list, maybe you can initiate a ticket with ATT? We've got several downstream customers that are being affected by the issue. 3 3 ms 3 ms 2 ms iodc-69-71-48-2.ioconnect.net [69.71.48.2] 4 3 ms 3 ms 3 ms 12.89.121.177 526 ms25 ms25 ms cr1.phmaz.ip.att.net [12.123.206.138] 626 ms25 ms25 ms cr1.dlstx.ip.att.net [12.122.28.181] 726 ms26 ms27 ms tbr1.dlstx.ip.att.net [12.122.18.138] 825 ms25 ms25 ms gar4.dlstx.ip.att.net [12.123.16.97] 9 212 ms 200 ms * 12.118.225.22 Problem occurring here. Sometimes traffic gets through, sometimes it doesn't 10 29 ms26 ms26 ms 216.143.71.219 11 26 ms26 ms26 ms www.mcafeeasap.com [208.69.153.135] Thanks, Matt Calhoun i/o Data Centers
Re: McAfee/ATT Issue
Calhoun, Matthew wrote: 9 212 ms 200 ms * 12.118.225.22 Problem occurring here. Sometimes traffic gets through, sometimes it doesn't 10 29 ms26 ms26 ms 216.143.71.219 11 26 ms26 ms26 ms www.mcafeeasap.com [208.69.153.135] Looks a lot like that hop is rate-limiting ICMP to itself. Everything beyond it seems to be good from the looks of it. -Kam
RE: McAfee/ATT Issue
We've also seen that busy routers are slower to respond to requests directed at them as opposed to traffic routing thru them which can continue to work without issue or performance loss. -Original Message- From: Kameron Gasso [mailto:kgasso-li...@visp.net] Sent: Wednesday, February 18, 2009 12:03 PM To: Calhoun, Matthew Cc: NANOG list Subject: Re: McAfee/ATT Issue Calhoun, Matthew wrote: 9 212 ms 200 ms * 12.118.225.22 Problem occurring here. Sometimes traffic gets through, sometimes it doesn't 10 29 ms26 ms26 ms 216.143.71.219 11 26 ms26 ms26 ms www.mcafeeasap.com [208.69.153.135] Looks a lot like that hop is rate-limiting ICMP to itself. Everything beyond it seems to be good from the looks of it. -Kam
Re: IPv6 Confusion
From: David Conrad d...@virtualized.org Date: Wed, 18 Feb 2009 07:57:12 -1000 Mikael, On Feb 17, 2009, at 9:18 PM, Mikael Abrahamsson wrote: Suggestion: next time you buy equipment from competing vendors, tell the sales folk from the losing vendors that one deciding factor was (vendor or product) IPv6 support. That (and perhaps only that) will get their attention... :-) Well, considering how very few vendors actually support IPv6, it's hard to find proper competition. You don't have to tell the truth to the losing sales folk... :-) Yes, I saw the smiley, but what you suggested could cause a lot of suffering if it is a formal bid. (If a mom-n-pop buys a 2960, probably not an issue.) Ethical issues aside, giving incorrect information to a losing vendor is fraud and, at least in the public sector, can get you in more trouble than you would ever want to think about being in. Our procurement officers are scrupulous in detailing the required information for the losing bidder's debrief on contracts of any size. This means putting in just as much information as is required and nothing more and making sure that what is included is correct. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
RE: McAfee/ATT Issue
While I agree with all of your assessments, this traceroute was being provided to illustrate where traffic *appears* to be stopping when we are seeing the issue. It's intermittent, so some times we can reach the destination hosts (via HTTP, HTTPS, etc.) and sometimes we can't. When we can reach the destination hosts (via HTTP), the traceroute completes When we can't reach the destination hosts (via HTTP), the traceroute won't complete and the last hop is the host that I indicated in my previous post (12.118.225.22) Thanks, Matt -Original Message- From: Justin Krejci [mailto:jkre...@usinternet.com] Sent: Wednesday, February 18, 2009 11:15 AM To: kga...@visp.net; Calhoun, Matthew Cc: 'NANOG list' Subject: RE: McAfee/ATT Issue We've also seen that busy routers are slower to respond to requests directed at them as opposed to traffic routing thru them which can continue to work without issue or performance loss. -Original Message- From: Kameron Gasso [mailto:kgasso-li...@visp.net] Sent: Wednesday, February 18, 2009 12:03 PM To: Calhoun, Matthew Cc: NANOG list Subject: Re: McAfee/ATT Issue Calhoun, Matthew wrote: 9 212 ms 200 ms * 12.118.225.22 Problem occurring here. Sometimes traffic gets through, sometimes it doesn't 10 29 ms26 ms26 ms 216.143.71.219 11 26 ms26 ms26 ms www.mcafeeasap.com [208.69.153.135] Looks a lot like that hop is rate-limiting ICMP to itself. Everything beyond it seems to be good from the looks of it. -Kam
Re: IPv6 Confusion
Well, considering how very few vendors actually support IPv6, it's hard to find proper competition. You don't have to tell the truth to the losing sales folk... : Or you could be truthful and say we decided to go with the XYZ product, despite the fact that they don't support IPv6; if your product HAD supported IPv6 you would have been in a much stronger position when the contract was awarded. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Re: IPv6 Confusion
Kevin, On Feb 18, 2009, at 8:19 AM, Kevin Oberman wrote: You don't have to tell the truth to the losing sales folk... :-) Yes, I saw the smiley, but Sigh. Perhaps there needs to be an emoticon for really joking, really. no, really.. Ethical issues aside, giving incorrect information to a losing vendor is fraud and, at least in the public sector, can get you in more trouble than you would ever want to think about being in. If a vendor sales person indicates they are getting no requests for IPv6 support in their products (which would clearly be false since presumably you are requesting IPv6 support), then stating one reason the vendor did not win a bid was because of that vendor's stance on IPv6 may be accurate (YMMV). I have some skepticism such a claim would be considered unethical or fraud, even in the squeaky clean world of US government procurement. Regards, -drc
Re: IPv6 Confusion
David Conrad wrote: Yeah. Rants about the IETF should probably be directed elsewhere. Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? - Kevin
Re: IPv6 Confusion
On 18/02/2009 19:39, Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? Easy. Disable all ipv4 at ietf meetings and change the address of the DNS server on the LAN every couple of minutes. Eating one's own dog food can concentrate the mind like nothing else. Nick
Re: IPv6 Confusion
Humor aside, the only practical answer is to show up at meetings and and on mailing lists and express your technical reasons. There are people there (in addition to me) who want the perspective of network operators. John On 2009Feb18, at 2:45 PM, Nick Hilliard wrote: On 18/02/2009 19:39, Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? Easy. Disable all ipv4 at ietf meetings and change the address of the DNS server on the LAN every couple of minutes. Eating one's own dog food can concentrate the mind like nothing else.
Re: IPv6 Confusion
Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? You don't, because there isn't really a technical reason for turning off RA. RA is used as a starting point. It can push you to DHCPv6 or any number of other options (such as SLAAC). The same argument goes for multicast versus broadcast. The idea is to add an extra level that allows for better manipulation and versatility. Of course, better support and vendor implementation of all the different options would be nice. Most networks have broadcast controls that are mostly vendor specific hacks. Now they'll have multicast controls, which is good to have anyways. If you want to get into something irksome, please point out that looking at a much of link local addresses/interfaces for next hopes in IGP's is rather annoying. Only reason to even have global routed IP's on the router is for traceroutes, but you can't just look up route, ping next hop IP from remote location to verify next hop was reachable. -Jack
Re: IPv6 Confusion
On 18/02/2009 19:39, Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? What operational reasons are there for working with RA turned off? Aria Stewart aredri...@nbtsc.org smime.p7s Description: S/MIME cryptographic signature
Re: IPv6 Confusion
On Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart wrote: On 18/02/2009 19:39, Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? What operational reasons are there for working with RA turned off? I don't want any system to be able to get IPv6 addressing information until the system has been identified in our central management system. I also want the IPv6 address assignment to be made centrally.
Re: IPv6 Confusion
Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? You don't, because there isn't really a technical reason for turning off RA. I'm glad to see that several of the big vendors seem to disagree with you. - Cisco does RA as soon as an interface has an IPv6 address, but has a knob to disable RA (ipv6 nd ra suppress). - Juniper does *not* do RA as soon as an interface has an IPv6 address, it must be explicitly configured. So we are part way there - IPv6 can be used without RA. We just need DHCPv6 to work properly without RA. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: IPv6 Confusion
What operational reasons are there for working with RA turned off? networks with visitors have shown a serious problem with rouge RAs randy
Re: IPv6 Confusion
On Wed, 18 Feb 2009 12:55:19 MST, Aria Stewart said: What operational reasons are there for working with RA turned off? If the intent is to feed the just-booted box all its network config via DHCPv6, including the network/netmask/default router, the *last* thing you want is a second box blabbing a packet in the middle and potentially confusing things in one of two ways: 1) Some chuckleheaded banana-eater made a typo and the RA bits don't match the bits supplied by DHCP, resulting in a non-deterministic bug depending which packet gets there first (at least with DHCPv4 or standalone RA, a misconfigure busts *everything* on the subnet and makes debugging easier). 2) Some end-node box with a IPv6 stack from Joe's Software Emporium and Bait-n-Tackle sees an RA packet, and concludes that since RA and DHCPv6 are mutually exclusive, to ignore any DHCPv6 packets it sees, and hilarity ensues. (Yes, both sorts of errors happen all the time, and people who have been burnt once usually want to avoid a second one...) pgp1p8geIeLKW.pgp Description: PGP signature
Re: IPv6 Confusion
On Wed, Feb 18, 2009, Jack Bates wrote: Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? You don't, because there isn't really a technical reason for turning off RA. RA is used as a starting point. It can push you to DHCPv6 or any Welcome to the 2009 internet. I hate to say it, but the technical only argument belongs back in the era I got involved in this junk, mid-1990's. If the things stopping corporate adoption are A, B, and C (eg, DHCPv6 style host management, firewall and l2/l3 filter set parity (eg, cisco port lockdown features, I forget all of the crap involved there), and lack of parity in various application support) and the academic community keeps shouting out but damnit, our dogfood is better!, then you're going to lose. Being told by a group of network-y people that our dogfood is better sounds to me like the days where telco's kept saying this IP stuff is crap, our ATM/FR dogfood is better, why would you deploy IP end to end? Its amusing. Seriously. Someone needs to draw up some parallels between IPv6 adoption/advocacy and ATM/FR/ISDN stuff versus IP(v4) adoption back in the mid to late 1990's. I'd certainly have a laugh. my 2c, or 1.24c AUD; Adrian
Re: IPv6 Confusion
On Feb 18, 2009, at 1:15 PM, Randy Bush wrote: What operational reasons are there for working with RA turned off? networks with visitors have shown a serious problem with rouge RAs Does that get better with RAs from the good routers turned off? Aria Stewart aredri...@nbtsc.org smime.p7s Description: S/MIME cryptographic signature
Re: IPv6 Confusion
On Feb 18, 2009, at 11:53 AM, Jack Bates wrote: Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? You don't, because there isn't really a technical reason for turning off RA. RA is used as a starting point. It can push you to DHCPv6 or any number of other options (such as SLAAC). The same argument goes for multicast versus broadcast. The idea is to add an extra level that allows for better manipulation and versatility. There is a reason for turning off RA and the IETF (and you) just don't seem to get it. There are real world situations in which not all routers are created equal and it is important for the DHCP server to tell the correct host which router to use for default. There are also a number of security issues available in the Just trust some unsolicited broadcast about where to send all your network traffic. approach to host bootstrapping that bother some people. We can argue all you want about how pathological these cases are, but, the fact remains that trusting some unsolicited broadcast from a device claiming to be a router as your starting point isn't viable in a number of real world installations and an alternative needs to be made available. Of course, better support and vendor implementation of all the different options would be nice. Sure, but, so would DHCP functionality equivalent to what we have in IPv4. If you want SLAAC or RA or whatever, more power to you. Some installations do not. They want DHCP equivalent functionality with the same security model. Most networks have broadcast controls that are mostly vendor specific hacks. Now they'll have multicast controls, which is good to have anyways. This assumes a lot, but, even if it's true, it doesn't change the fact that some organizations like the existing DHCP model and there's no reason not to provide equivalent functionality in IPv6. Owen
Re: IPv6 Confusion
On 19/02/2009, at 9:08 AM, Chuck Anderson wrote: On Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart wrote: On 18/02/2009 19:39, Kevin Loch wrote: Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? What operational reasons are there for working with RA turned off? I don't want any system to be able to get IPv6 addressing information until the system has been identified in our central management system. I also want the IPv6 address assignment to be made centrally. You must have missed my post asking people to be clear in their distinction between RA and SLAAC. I will re-cap: - RA does NOT give your host IPv6 addressing information. - SLAAC gives your host IPv6 addressing information. SLAAC data is carried in RA messages, as an OPTION. - Another RA OPTION is use DHCPv6 to get addressing information. DHCPv6 can operate without RA now. You can send DHCPv6 requests to your local LAN before you get an RA message telling you to do so. This requires you to manually configure your host to do that. That sounds like a waste of time, when you can use RA messages to tell your hosts to use DHCPv6 to get addressing information. Of course, you DHCPv6 does not currently have an option for default router, so your need RA for that. Again, RA is not giving out addressing information, only Hi, I am a router. I suspect this removes the desire for getting VRRP without RA as well for those of you wanting to use DHCPv6 for addressing - RA is not giving out addressing information, and is only giving out Use DHCPv6 bits and a router address. -- Nathan Ward
Re: IPv6 Confusion
On 19/02/2009, at 9:17 AM, valdis.kletni...@vt.edu wrote: 2) Some end-node box with a IPv6 stack from Joe's Software Emporium and Bait-n-Tackle sees an RA packet, and concludes that since RA and DHCPv6 are mutually exclusive, to ignore any DHCPv6 packets it sees, and hilarity ensues. They are not mutually exclusive, DHCPv6 *requires* RA. Or did you mean SLAAC? If you did, I am not sure that they are mutually exclusive - I see no reason for telling hosts a prefix to number out of (SLAAC), and also telling hosts to use DHCPv6. That actually seems like a good solution to a number of problems. -- Nathan Ward
Re: IPv6 Confusion
Hi! networks with visitors have shown a serious problem with rouge RAs Does that get better with RAs from the good routers turned off? Aria Stewart aredri...@nbtsc.org Is there something like RA filtering on switches yet, so end users can be filtered? Just like the dhcp stuff thats available on most switches nowdays... ? Its as annoying as fake DHCP servers... Bye, Raymond.
Re: IPv6 Confusion
In a message written on Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart wrote: What operational reasons are there for working with RA turned off? Not picking on the original poster, as I have no idea if they would have any personal experience with this or not. There was a kinder, gentler time when your Cisco IGS would run RIPv1 and spew forth a default route. Your SunOS boxes all ran routed by default, and received the default route. Which, quite frankly, looks a lot like how RA's work. After many people had entire campus networks brought down by misconfigured boxes, prankster students, rogue network intruders and boxes plugged into the wrong ports the operators of the world universally turned this junk off. It appears the IETF did not study these history lessons when designing IPv6 RA's. Now, even with our limited IPv6 deployment we find plenty of stories where the NANOG and IETF test networks are unusable for hours at a time due to misconfigured boxes, prankster students, rogue network intruders and boxes plugged into the wrong port. Allowing an UNAUTHENTICATED BROADCAST packet to determine where you send your traffic is insane. Rather than moving forward, this is a giantantic step backwards for security and reliability. It wouldn't be so bad if we could just turn it off. Indeed, in part you can. On a static LAN there is no need for RA's. Static IP the box, static default route, done and done. But, when DHCPv6 was developed the great minds of the world decided less functionality was better. There /IS NO OPTION/ to send a default route in DHCPv6, making DHCPv6 fully dependant on RA's being turned on! So the IETF and other great minds have totally removed the capability for operators to work around this problem. Thus we are doomed, for now, to IPv6 networks that regularly become unworkable for hours at a time. Brilliant design! -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp0fzABTpkYX.pgp Description: PGP signature
Re: IPv6 Confusion
On 19/02/2009, at 9:15 AM, Randy Bush wrote: What operational reasons are there for working with RA turned off? networks with visitors have shown a serious problem with rouge RAs Networks with visitors have shown a serious problem with rogue DHCP servers. Networks with visitors that use DHCPv6 for address assignment will have the exact same problem if someone comes along with a rogue DHCPv6 server. You need to push your vendors for features to limit where RA messages and DHCPv6 messages can be sent from. Coming up with new ways to solve a problem with an already obvious solution (a solution that we have for an identical problem in IPv4) sounds like it would take longer to solve, and sounds like it would introduce even more confusion in to this space. If your ethernet equipment has the ability to filter on ethernet source/destination then you should be able to do this a little bit now. - Only allow messages to the all routers multicast address to go to the switch interfaces that have routers on them. - Only allow messages to the all DHCPv6 servers multicast address to go to the switch interfaces that have DHCPv6 servers or relays on them. If your ethernet equipment can do IPv6 L4 ACLs then that is even better, you can allow RA messages only from routers, and DHCPv6 responses only from DHCPv6 servers. Again, this is the same problem we have with DHCP in IPv4. The only difference is switch vendor support for filtering these messages. -- Nathan Ward
Re: IPv6 Confusion
Mikael Abrahamsson wrote: On Tue, 17 Feb 2009, Justin Shore wrote: different vendors, I asked each of them about their IPv6 support and they all unanimously claimed that there was no demand for it from their customers. Well, this is just ignorance or a kind of a lie. There might be few customers who are willing to treat IPv6 support as a showstopper, but saying that there is no demand simply isn't true, it's just that they can get away without IPv6 support right now. We all hear the same thing when we ask for IPv6 support. From my experience in the v6 wars, the express aversion to No Flag Day for Operators makes an implicit Flag Day for Vendors Instead. That is, the ipv4/networking world doesn't stop, so even a well intentioned business unit/group/whatever of pick-your-network-vendor is constantly treading the v6 water furiously and usually sinking. And of course, most BU's are at best sort of ambivalent about v6 unless it translates to $$$ the next quarter. Also: the operators from what I've seen are also sort of ambivalent too, so there's a catch-22: the operators don't want to deploy something that they can't deploy or manage, and vendors don't want to drop everything to get parity for something that isn't going to make next quarter's numbers. And as if it were just one quarter; you'd really be talking about a year of quarters to get to real parity. So, round it goes. As far as I can tell, we're pretty much destined to drive right over the address depletion cliff. It should make for great theater for those of us not in the vendor/operator community anymore, in that train-wreck kind of way. Has somebody made an IPv4 address depletion marque? Maybe we could put it next to the National Debt counter in Times Square. Mike
Re: IPv6 Confusion
2) Some end-node box with a IPv6 stack from Joe's Software Emporium and Bait-n-Tackle sees an RA packet, and concludes that since RA and DHCPv6 are mutually exclusive, to ignore any DHCPv6 packets it sees, and hilarity ensues. They are not mutually exclusive, DHCPv6 *requires* RA. In your previous Nanog message you said: DHCPv6 can operate without RA now. Please make up your mind. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: IPv6 Confusion
On 19/02/2009, at 9:34 AM, Leo Bicknell wrote: Allowing an UNAUTHENTICATED BROADCAST packet to determine where you send your traffic is insane. Rather than moving forward, this is a giantantic step backwards for security and reliability. I guess you don't use DHCP in IPv4 then. It seems there are lots of people who want auto configuration in IPv6 but who clearly do not do this in IPv4. That seems strange, to me. -- Nathan Ward
Re: IPv6 Confusion
On Thu, 19 Feb 2009, Nathan Ward wrote: It seems there are lots of people who want auto configuration in IPv6 but who clearly do not do this in IPv4. That seems strange, to me. Everybody uses DHCP in IPv4, it's just that there is functionality in the equipment we use to make sure it can only be received from certain places and we apply security based on snooping the DHCP traffic. So, the fact that RA guard isn't widely available is a showstopper for deploying native IPv6 in a lot of environments because it just can't be done in a secure manner. I am sure the equivalent measures can be implemented for IPv6, it's just that someone needs to do it, and it's a mystery to me how all these security functions aren't available from the IETF already. As said before, a lot of the security mechanisms involved in securing IPv4 hasn't been implemented in IPv6. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 Confusion
In a message written on Thu, Feb 19, 2009 at 09:44:38AM +1300, Nathan Ward wrote: I guess you don't use DHCP in IPv4 then. No, you seem to think the failure mode is the same, and it is not. Let's walk through this: 1) 400 people get on the NANOG wireless network. 2) Mr 31337 comes along and puts up a rogue DHCP server. 3) All 400 people continue working just fine until their lease expires, which is likely after the conference ends. The 10 people who came in late get info from the rogue server, and troubleshooting ensues. Let's try with IPv6. 1) 400 people get on the NANOG wireless network. 2) Mr 31337 sends a rouge RA. 3) 400 people instantly loose network access. The 10 who come in late don't even bother to try and get on. So, with DHCP handing out a default route we have 10/400 down, with RA's we have 410/410 down. Bravo! Let me clear up something from the start; this is not security. If security is what you are after none of the solutions proffered so far work. Rather this is robust network design. A working device shouldn't run off and follow a new router in miliseconds like a lost puppy looking for a treat. This actually offers a lot of protection from stupidity though. Ever plug an IPv4 router into the wrong switch port accidently? What happened? Probably nothing; no one on the LAN used the port IP'ed in the wrong subnet. They ignored it. Try that with an IPv6 router. About 10 ms after you plug into the wrong port out goes an RA, the entire subnet ceases to function, and your phone lights up like a christmas tree. Let me repeat, none of these solutions are secure. The IPv4/DHCP model is ROBUST, the RA/DHCPv6 model is NOT. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpMhUyGThgf5.pgp Description: PGP signature
Re: IPv6 Confusion
On 19/02/2009, at 9:42 AM, sth...@nethelp.no wrote: 2) Some end-node box with a IPv6 stack from Joe's Software Emporium and Bait-n-Tackle sees an RA packet, and concludes that since RA and DHCPv6 are mutually exclusive, to ignore any DHCPv6 packets it sees, and hilarity ensues. They are not mutually exclusive, DHCPv6 *requires* RA. In your previous Nanog message you said: DHCPv6 can operate without RA now. Please make up your mind. You are right, sorry for any confusion, I will clarify my comments. DHCPv6 can operate without RA, but you cannot get default route information right now. I believe there is a draft to add this option though. In most networks this is not practical, as many hosts with a DHCPv6 stack will send DHCPv6 requests only when RA messages tell them to us a DHCPv6 server. The DHCPv6 protocol does not require RA, however practical implementation of DHCPv6 for address assignment does. Better? :-) -- Nathan Ward
Re: IPv6 Confusion
networks with visitors have shown a serious problem with rogue RAs Does that get better with RAs from the good routers turned off? no, need to turn off listeners in this case the problems in the discovery space are sufficient to be causing a bit of effort to go into painting security on ex post facto. randy
Re: IPv6 Confusion
On 19/02/2009, at 9:53 AM, Leo Bicknell wrote: In a message written on Thu, Feb 19, 2009 at 09:44:38AM +1300, Nathan Ward wrote: I guess you don't use DHCP in IPv4 then. No, you seem to think the failure mode is the same, and it is not. Let's walk through this: 1) 400 people get on the NANOG wireless network. 2) Mr 31337 comes along and puts up a rogue DHCP server. 3) All 400 people continue working just fine until their lease expires, which is likely after the conference ends. The 10 people who came in late get info from the rogue server, and troubleshooting ensues. Let's try with IPv6. 1) 400 people get on the NANOG wireless network. 2) Mr 31337 sends a rouge RA. 3) 400 people instantly loose network access. The 10 who come in late don't even bother to try and get on. So, with DHCP handing out a default route we have 10/400 down, with RA's we have 410/410 down. Bravo! Let me clear up something from the start; this is not security. If security is what you are after none of the solutions proffered so far work. Rather this is robust network design. A working device shouldn't run off and follow a new router in miliseconds like a lost puppy looking for a treat. This actually offers a lot of protection from stupidity though. Ever plug an IPv4 router into the wrong switch port accidently? What happened? Probably nothing; no one on the LAN used the port IP'ed in the wrong subnet. They ignored it. Try that with an IPv6 router. About 10 ms after you plug into the wrong port out goes an RA, the entire subnet ceases to function, and your phone lights up like a christmas tree. Let me repeat, none of these solutions are secure. The IPv4/DHCP model is ROBUST, the RA/DHCPv6 model is NOT. Yup, understood. The point I am making is that the solution is still the same - filtering in ethernet devices. Perhaps there needs to be something written about detailed requirements for this so that people have something to point their switch/etc. vendors at when asking for compliance. I will write this up in the next day or two. I guess IETF is the right forum for publication of that. Is there something like this already that anyone knows of? -- Nathan Ward
Re: IPv6 Confusion
On Feb 18, 2009, at 3:00 PM, Nathan Ward wrote: On 19/02/2009, at 9:53 AM, Leo Bicknell wrote: Let me repeat, none of these solutions are secure. The IPv4/DHCP model is ROBUST, the RA/DHCPv6 model is NOT. The point I am making is that the solution is still the same - filtering in ethernet devices. Perhaps there needs to be something written about detailed requirements for this so that people have something to point their switch/etc. vendors at when asking for compliance. I will write this up in the next day or two. I guess IETF is the right forum for publication of that. Is there something like this already that anyone knows of? http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-02.txt This is the last message I recall seeing in v6ops about it: It seems to me that the L2 devices are welcome to perform whatever filtering they like regardless of any documents that might come from the IETF. Therefore, I'd like to see more pros/cons on this. http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01733.html Cheers, Dale
Re: IPv6 Confusion
In a message written on Thu, Feb 19, 2009 at 10:00:48AM +1300, Nathan Ward wrote: The point I am making is that the solution is still the same - filtering in ethernet devices. No. I agree that in some enviornments DHCPv4/DHCPv6/RA filtering are going to be a requirement. If I was running the NANOG network, or a campus network for college students I would insist on such. However, there are many enviornments where that is not a justified expense. At home I have a dumb, unmanaged switch which serves my family just fine. I'd rather like it that if I plug in an unconfigured router to configure it for something that it not take my wife offline. The DHCPv4 model works great for this, there are no issues and I don't need a managed switch. IPv6 takes that option away from me. My only option is an expensive upgrade to the switch and a bunch of manual configuration. DHCPv6 needs to be fixed before it is deployed. Dependance on RA's needs to be removed, and a standard option for a default route needs to be added. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpSJGwBKXoPR.pgp Description: PGP signature
Re: IPv6 Confusion
Raymond Dijkxhoorn wrote: Hi! Hi, networks with visitors have shown a serious problem with rouge RAs Does that get better with RAs from the good routers turned off? Aria Stewart aredri...@nbtsc.org Is there something like RA filtering on switches yet, so end users can be filtered? Just like the dhcp stuff thats available on most switches nowdays... ? Its as annoying as fake DHCP servers... When I asked about this on an other list someone suggested RA-guard is what is supposed to be the solution: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 ? Not sure about implementations though, haven't had the time to check yet. Bye, Raymond. See you again, Leen.
Re: IPv6 Confusion
Leo Bicknell wrote: It wouldn't be so bad if we could just turn it off. Indeed, in part you can. On a static LAN there is no need for RA's. Static IP the box, static default route, done and done. VRRPv6 however is relevant to static environments and also needs to (optionally) work with RA turned off. - Kevin
Re: IPv6 Confusion
Dale W. Carder wrote: On Feb 18, 2009, at 3:00 PM, Nathan Ward wrote: On 19/02/2009, at 9:53 AM, Leo Bicknell wrote: Let me repeat, none of these solutions are secure. The IPv4/DHCP model is ROBUST, the RA/DHCPv6 model is NOT. The point I am making is that the solution is still the same - filtering in ethernet devices. Perhaps there needs to be something written about detailed requirements for this so that people have something to point their switch/etc. vendors at when asking for compliance. I will write this up in the next day or two. I guess IETF is the right forum for publication of that. Is there something like this already that anyone knows of? http://tools.ietf.org/id/draft-chown-v6ops-rogue-ra-02.txt This is the last message I recall seeing in v6ops about it: It seems to me that the L2 devices are welcome to perform whatever filtering they like regardless of any documents that might come from the IETF. Therefore, I'd like to see more pros/cons on this. http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01733.html There is also: http://tools.ietf.org/html/draft-vandevelde-v6ops-ra-guard-01 Cheers, Dale
RE: IPv6 Confusion
David Conrad wrote: Tony, On Feb 17, 2009, at 12:17 PM, Tony Hain wrote: This being a list of network engineers, there is a strong bias toward tools that allow explicit management of the network. This is a fine position, and those tools need to exist. There are others that don't want, or need to know about every bit on the wire, where 'as much automation as possible' is the right set of tools. No question. However, as this is a list of network engineers who are the folks who need to deploy IPv6 in order for others who may not care about every bit on the wire to make (non-internal) use of it, I'd think the bias displayed here something that might carry some weight. Automated tunneling works around those who choose not to deploy native support. Infighting at the IETF kept the RA from informing the end systems about DNS, and kept DHCPv6 from informing them about their router. The result is that you have to do both DHCP RA, when each should be capable of working without the other. Yeah. Rants about the IETF should probably be directed elsewhere. That was not a rant, just an informational observation. As far as dnssec, while the question is valid, blaming the IPv6 design for not considering something that 10+ years later is still not deployed/deployable, is a bit of a stretch. Uh, no. That's not what I was saying. I was saying that stateless auto-configuration made certain assumptions about how naming and addressing worked that weren't necessarily well thought out (clients updating the reverse directly in a DNSSEC-signed environment was just an example). Perhaps it's just me, but it feels like there was a massive case of NIH syndrome in the IPv6 working groups that network operators are now paying the price for. However, as I said, rants about the IETF should probably be directed elsewhere. Actually this should be flipped as a rant against the *nog community. If you didn't participate in defining it, you can't complain about the outcome. The only way the IETF works well is with an active feedback loop that injects operational reality into the process. That used to exist in the joman WG, but stopped when the *nogs splintered off and stopped participating. I can already hear Randy complaining about being shouted down, and yes that happens, but that is really a call for -more- active voices, not disengagement. The bottom line is, if you want something to be defined in a way that works for you, you have to participate in the definition. Or, we simply continue down the path of more NATv4. While this is the popular position, those that have thought about it realize that what works for natv4 at the edge, does not work when that nat is moved toward the core. Yeah, multi-layer NAT sucks. I was amazed when I was speaking with some African ISPs that had to go this way today because their telecoms regulatory regime required them to obtain addresses from the national PTT and that PTT only gave them a single address. I would argue that if we want to avoid this outcome (and make no mistake, there are those who like this outcome as it means end users are only content consumers, which fits into their desired business models much more nicely), we need to make IPv6 look more like IPv4 so that network operators, end users, content providers, network application developers, etc., have minimal change in what they do, how they do it, or how they pay for it. Part of that is getting familiar tools (e.g., DHCP, customer provisioning, management, etc.) working the way it works in IPv4. Taking advantage of all the neato features IPv6 might provide can come later. People have to stand up and put money on the table if they expect things to get fixed. The working parts of IPv6 that exist are due to the ISPs in Japan and the US DoD putting their money where their mouth is, and they got what they needed. The *nog community appears to be holding their breath waiting for 1:1 parity before they start, which will never happen. However, I have a sneaking suspicion it might already be too late... CGN will be deployed, but can be used as a tool to wean customers off of IPv4. If the world goes the way of current-price==IPv6+CGN, with IPv6+publicIPv4 costing substantially more, there will be a drop off in use of IPv4 because the CGN breaks lots of stuff and people won't pay extra to work around it for any longer than they need to. Tony
Re: IPv6 Confusion
In a message written on Wed, Feb 18, 2009 at 04:11:40PM -0500, Kevin Loch wrote: Leo Bicknell wrote: It wouldn't be so bad if we could just turn it off. Indeed, in part you can. On a static LAN there is no need for RA's. Static IP the box, static default route, done and done. VRRPv6 however is relevant to static environments and also needs to (optionally) work with RA turned off. Ah yes, another tagent, but absolutely. VRRPv6 is needed not only because you may want to go 100% static, but also because VRRP can do things like tracking upstream interfaces that RA cannot do. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpNnNvCYEvW4.pgp Description: PGP signature
RE: IPv6 Confusion
Justin Shore wrote: ... At this point I'm looking at doing 6to4 tunnels far into the future. You can forget that, as CGN will break 6to4. Get used to teredo (miredo), and if that is impeded don't be surprised when IPv6 over SOAP shows up. Tony
Re: IPv6 Confusion
Raymond Dijkxhoorn wrote: Is there something like RA filtering on switches yet, so end users can be filtered? Just like the dhcp stuff thats available on most switches nowdays... ? Its as annoying as fake DHCP servers... Per customer VLAN isolation (common to solve DHCP server issues). You can also perform *some* filtering today for multicast addresses, but not the specific packets themselves from what I've seen. This is a big implementation change. I've had lengthy discussions with the DSLAM vendors who said, VLANs are stupid and as bad as PVCs, about their ability to filter RAs and DHCPv6. -Jack
RE: IPv6 Confusion
Owen DeLong wrote: ... If you want SLAAC or RA or whatever, more power to you. Some installations do not. They want DHCP equivalent functionality with the same security model. It is always amusing when people equate DHCP with security... Outside of that, I do agree with you that the operational model around DHCP needs to be complete and stand-alone, just as the RA model needs to be. Right now neither works stand-alone. FWIW: there is SEND (RFC 3971) to deal with rouge RA's and other miscreant behavior. Implementations have been slow to come to market because network operators are not demanding it from their vendors. Tony
RE: IPv6 Confusion
Leo Bicknell wrote: ... But, when DHCPv6 was developed the great minds of the world decided less functionality was better. There /IS NO OPTION/ to send a default route in DHCPv6, making DHCPv6 fully dependant on RA's being turned on! So the IETF and other great minds have totally removed the capability for operators to work around this problem. No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. Tony
Re: IPv6 Confusion
On Wed, Feb 18, 2009, Tony Hain wrote: No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. Please explain where you think *nog community is today representative at all of the wider scale IPv6 deployment issues across the world? I'm assuming IETF and ARIN/RIPE/APNIC/etc are busy talking to end-users rather than just ISPs about the issues facing IPv6 adoption. Am I mistaken or not? Adrian
Re: IPv6 Confusion
Adrian Chadd wrote: On Wed, Feb 18, 2009, Tony Hain wrote: No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. Please explain where you think *nog community is today representative at all of the wider scale IPv6 deployment issues across the world? I'm assuming IETF and ARIN/RIPE/APNIC/etc are busy talking to end-users rather than just ISPs about the issues facing IPv6 adoption. Am I mistaken or not? The end-users who come too three meetings a year and pay $635 to attend are a small and self-selecting bunch (there are some I would note)... The IETF is not in the business of product development of the sort that end-users would normally relate to. The RIRs have there respective stakeholders, some are end-users most are not. Adrian
Re: IPv6 Confusion
On 19/02/2009, at 9:22 AM, Owen DeLong wrote: There are also a number of security issues available in the Just trust some unsolicited broadcast about where to send all your network traffic. approach to host bootstrapping that bother some people. So, those people don't use DHCP in IPv4 if this is a concern, so I'm guessing they are not hoping to use DHCPv6 either. Static configuration of IP addressing information and other configuration will work just fine for them. I wonder, do they use ARP? The things you are talking about are about protecting against misconfiguration, not about protecting against malicious people. We can argue all you want about how pathological these cases are, but, the fact remains that trusting some unsolicited broadcast from a device claiming to be a router as your starting point isn't viable in a number of real world installations and an alternative needs to be made available. Of course, better support and vendor implementation of all the different options would be nice. Sure, but, so would DHCP functionality equivalent to what we have in IPv4. If you want SLAAC or RA or whatever, more power to you. Some installations do not. They want DHCP equivalent functionality with the same security model. SLAAC and DHCPv6 do not have different security models in the host trusting the network area. In terms of network trusting the host, there is a bit I suppose, assuming you trust whatever MAC address and client identifier the host uses. Most networks have broadcast controls that are mostly vendor specific hacks. Now they'll have multicast controls, which is good to have anyways. This assumes a lot, but, even if it's true, it doesn't change the fact that some organizations like the existing DHCP model and there's no reason not to provide equivalent functionality in IPv6. I would agree, if we did not have SLAAC. RA is needed to tell hosts which of SLAAC and DHCPv6 to use though. Perhaps a solution here is a DHCPv6 option that says do not listen to RAs any more, so that once a host is on a network and has an address from DHCPv6, it does not get affected by devices sending rogue RAs. Perhaps there is an additional option that says send an RS message and listen to RA when your renewing your DHCPv6 lease to allow transition from DHCPv6 to SLAAC if the network wants to do that. That way, we get DHCPv6 vs. SLAAC selection when a host connects to the network without having to manually configure, and we get IPv4 DHCP-like behaviour. -- Nathan Ward
RE: McAfee/ATT Issue
--- mcalh...@iodatacenters.com wrote: From: Calhoun, Matthew mcalh...@iodatacenters.com While I agree with all of your assessments, this traceroute was being provided to illustrate where traffic *appears* to be stopping when we are seeing the issue. It's intermittent, so some times we can reach the destination hosts (via HTTP, HTTPS, etc.) and sometimes we can't. When we can reach the destination hosts (via HTTP), the traceroute completes When we can't reach the destination hosts (via HTTP), the traceroute won't complete and the last hop is the host that I indicated in my previous post (12.118.225.22) - It may be best to use tcptraceroute when it is and when it isn't working. It may help you evaluate where the trouble is occurring more efficiently. scott
Re: IPv6 Confusion
On 19/02/2009, at 10:07 AM, Leo Bicknell wrote: In a message written on Thu, Feb 19, 2009 at 10:00:48AM +1300, Nathan Ward wrote: The point I am making is that the solution is still the same - filtering in ethernet devices. No. I agree that in some enviornments DHCPv4/DHCPv6/RA filtering are going to be a requirement. If I was running the NANOG network, or a campus network for college students I would insist on such. However, there are many enviornments where that is not a justified expense. At home I have a dumb, unmanaged switch which serves my family just fine. I'd rather like it that if I plug in an unconfigured router to configure it for something that it not take my wife offline. The DHCPv4 model works great for this, there are no issues and I don't need a managed switch. Perhaps, and I am thinking out loud here, SOHO switches could include code to allow RA messages only from their uplink port, and wireless APs only from their Ethernet port. That doesn't require full understanding of IPv6, it would be trivial to code matching about 6 different bytes. Maybe throw a physical switch labelled Router this way on the side of the box just like the crossover toggle switches. Sure, this would not work for every situation, but it would do fine for a large number of home networking environments. Also perhaps the DHCPv6 thing I talked about in my message I just sent - the ignore RA option. IPv6 takes that option away from me. My only option is an expensive upgrade to the switch and a bunch of manual configuration. DHCPv6 needs to be fixed before it is deployed. Dependance on RA's needs to be removed, and a standard option for a default route needs to be added. It will be good to see your support in IETF for drafts that are proposing this! -- Nathan Ward
Re: IPv6 Confusion
In a message written on Wed, Feb 18, 2009 at 01:39:57PM -0800, Tony Hain wrote: No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. The last time I participated a working group chair told me operators don't know what they are talking about and went on to say they should be ignored. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpJJzA3yxE1T.pgp Description: PGP signature
Greedy Routing
http://www.physorg.com/news154093231.html Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com
Re: IPv6 Confusion
Tony Hain wrote: Leo Bicknell wrote: ... But, when DHCPv6 was developed the great minds of the world decided less functionality was better. There /IS NO OPTION/ to send a default route in DHCPv6, making DHCPv6 fully dependant on RA's being turned on! So the IETF and other great minds have totally removed the capability for operators to work around this problem. No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. Because clearly everything done in IPv4 space was crap, or should be assumed to be crap. Therefore, everything that's been worked out and made to function well in the last 25+ years in IPv4 space should be tossed and re-engineered. OSI anyone? The point, which seems to elude many, is that rightly or wrongly there is an assumption that going from IPv4 to IPv6 should not involve a step back in time, not on security, not on central configuration capability, not on the ability to multihome, and so forth. The rude awakening is that the IPv6 evangelists insisting everyone should get with the program failed to understand that the community at large would expect equivalent or better functionality. Ultimately the only bit of light emerging above all the heat generated by this thread is a simple observation: Engineers make lousy salespeople. -- - Daniel Senied...@senie.com Amaranth Networks Inc.http://www.amaranth.com Kindness in words creates confidence. Kindness in thinking creates profoundness. Kindness in giving creates love. -- Lao Tsu
Re: IPv6 Confusion
On Thu, Feb 19, 2009, Nathan Ward wrote: So, those people don't use DHCP in IPv4 if this is a concern, so I'm guessing they are not hoping to use DHCPv6 either. Static configuration of IP addressing information and other configuration will work just fine for them. I wonder, do they use ARP? In the corporate world, you get wonderful L2/L3 features in switches, such as: * helper address stuff, to run centralised DHCP servers * dhcp sniffing/filtering * per port L2/L3 filters * dynamic arp inspection which are used on corporate LANs to both build out scalable address management platforms (ie, no need to run a DHCP server on each subnet, nor one DHCP server with seperate vlan if's to provide service), control access and mitigate security risks. I don't know what the IPv6 LAN snooping functionality is across vendors but the last time I checked this out (say, 2-3 years ago) it was pretty lacking. The things you are talking about are about protecting against misconfiguration, not about protecting against malicious people. See above. Adrian
RE: IPv6 Confusion
Daniel Senie wrote: ... No, the decision was to not blindly import all the excess crap from IPv4. If anyone has a reason to have a DHCPv6 option, all they need to do is specify it. The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. Because clearly everything done in IPv4 space was crap, or should be assumed to be crap. Therefore, everything that's been worked out and made to function well in the last 25+ years in IPv4 space should be tossed and re-engineered. OSI anyone? That is not what the decision said. The point was that the DHCP WG was not going to decide for you what was necessary or appropriate to carry forward. Rather than add baggage that nobody actually uses, there is nothing until someone says 'I need that'. Never mind that DHCP wasn't defined when the IPng work started, and wasn't in widespread use yet when DHCPv6 was being started ... The point, which seems to elude many, is that rightly or wrongly there is an assumption that going from IPv4 to IPv6 should not involve a step back in time, not on security, not on central configuration capability, not on the ability to multihome, and so forth. The rude awakening is that the IPv6 evangelists insisting everyone should get with the program failed to understand that the community at large would expect equivalent or better functionality. Yes people expect 1:1 functionality, but how many of them are stepping up to the table with $$$ to make that happen... In the US, it is only the DoD. In the ISP space, most of it comes from Japan. If you are not finding what you want, put money in front of a vendor and see what happens... ;) Ultimately the only bit of light emerging above all the heat generated by this thread is a simple observation: Engineers make lousy salespeople. ;) Tony
RE: IPv6 Confusion
Leo Bicknell wrote: ... The last time I participated a working group chair told me operators don't know what they are talking about and went on to say they should be ignored. So did you believe him and stop participating? Seriously, the -ONLY- way the IETF can be effective is for the ops community to provide active feedback. If you don't provide input, don't be surprised when the output is not what you want. Tony
Re: Greedy Routing
On Wed, 18 Feb 2009 22:12:02 GMT, Rod Beck said: http://www.physorg.com/news154093231.html From the fine article: In greedy routing, a node passes information to the neighboring node that is closest to the final destination in an abstract space called hidden metric space. Sounds suspiciously like throw the packet at the router that's got the shortest AS path to the destination doesn't it? You don't need to know the entire topology to know router X is 2 AS's closer to the dest than router Y once X and Y have been loaded with the hidden metric space known as a BGP update ;) I'm not sure this article is actually telling us anything we didn't already know. Now if there was a way to compute those distance metrics without global knowledge - if there was only an algorithm that only cared about what was upstream from a locally connected link and whether it was connected. Say, we could call it a link-state routing protocol Now if they were able to actually develop a link-state protocol that involved *only* local adjacency announcements and not flooded announcements, *that* would be something... But what I see here is if somebody developed that, we'd be able to route more efficiently. Maybe there's some critical insight in the paper that Physorg managed to totally not mention, I dunno. pgph2MsWsbdwH.pgp Description: PGP signature
Re: IPv6 Confusion
In a message written on Wed, Feb 18, 2009 at 02:32:24PM -0800, Tony Hain wrote: So did you believe him and stop participating? Seriously, the -ONLY- way the IETF can be effective is for the ops community to provide active feedback. If you don't provide input, don't be surprised when the output is not what you want. Oh yes, because he's not the only one who's said that to me (although he was the most direct), and because others I know in the operator community have gotten the same response. The sad fact is for most operators it is easier to convince your vendor to generate a propretary feature and solve your problem; hoping they will back port it through the IETF so it is a standard. How many years did HSRP have to exist before VRRP was defined? And let me ask you this question, why do the operators have to go to the IETF? Many of us have, and tried. I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. If the IETF wants this to be a two way street actions would speak louder than words. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpOrQvkrHXXz.pgp Description: PGP signature
Re: IPv6 Confusion
David Conrad wrote: If a vendor sales person indicates they are getting no requests for IPv6 support in their products (which would clearly be false since presumably you are requesting IPv6 support), It's hard to imagine a vendor that is getting _no_ requests for IPv6 support these days; every RFP I see has it listed as an optional requirement. However, development priorities are set not by requests but by the amount of business they'll lose if they /don't/ do something. Since IPv6 is not _mandatory_ to win deals in most cases, it's simply not getting done. And, of course, customers can't make it mandatory in an RFP until at least one vendor has implemented it, or they risk getting no qualified responses... I bet the latter is why the US DoD gave up on their hard IPv6 requirements and now simply mandates that products be software upgradeable to support IPv6... S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: IPv6 Confusion
On Thu, Feb 19, 2009, Nathan Ward wrote: Yep. You asked your vendors to support equivalent IPv6 things at the time though, so when you roll out IPv6 the support is ready, right? The point is that these deficiencies exist in IPv4, and I'm not sure how you would solve them in IPv6 (assuming you can make all the changes you want, and get instant industry-wide support) any better than you solve them in IPv4. Who says the IPv6 solutions need to be better than IPv4? Adrian
Re: IPv6 Confusion
Leo Bicknell wrote: I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. Then were busy staring at your laptop and not watching the program. If the IETF wants this to be a two way street actions would speak louder than words. In that I could not agree more.
Re: IPv6 Confusion
On Wed, 18 Feb 2009 17:40:02 -0500 Leo Bicknell bickn...@ufp.org wrote: And let me ask you this question, why do the operators have to go to the IETF? Many of us have, and tried. I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. If the IETF wants this to be a two way street actions would speak louder than words. Without going into details, I have spoken at NANOG, and I've been a WG chair, an IAB member, and an AD. Randy has been an AD. I can think of several other ADs and IAB members who have frequently attended NANOG. I'm not saying it's perfect -- far from it! -- but the issue isn't nearly that one-sided. --Steve Bellovin, http://www.cs.columbia.edu/~smb
RE: Greedy Routing
Maybe there's some critical insight in the paper that Physorg managed to totally not mention, I dunno. I saw it the same way... As the researchers explain, some types of networks are not navigable. For instance, if the probability that two nodes are linked doesn't depend on the metric distance between them, then such networks are difficult to navigate, as there is no way to choose one node over another based on distance. But when there is a connection between the link existence probability and the hidden distance between nodes, metric distances can help to navigate the network, i.e., such networks are navigable. If your network doesn't calculate or use metrics or weights, or AS path lengths... then you are not able to throw packets like fairy dust to their intended destination. Worse, if you use metrics unrelated to distance (like link cost) you could actually send your packets the wrong way. It's funny, but I think they said that their math shows that the Internet works to generally route packets (to a shorter path) than other possible paths. I'm sure that will come as a surprise to all of us. Deepak Jain AiNET
Re: IPv6 Confusion
On Wed, 2009-02-18 at 16:45 -0600, Stephen Sprunk wrote: I bet the latter is why the US DoD gave up on their hard IPv6 requirements and now simply mandates that products be software upgradeable to support IPv6... I think you will agree that vendor support for IPv6 has come a long way in the past few years. Even Force10 is shipping v6 capable hardware! ;) The price of software licenses for v6 (when required) is now a figure we think about when proposing new equipment. Even customers who do not have a v6 strategy are at least conscious of the fact that they will need it eventually, and may rather pay a little more for a box that includes the feature now, than spend more on a license that includes things they don't need later on. I think, for example, that Juniper is making a mistake by rolling v6 capability into a license that also includes BGP and ISIS on some platforms. Cisco is guilty of this as well. I am not necessarily advocating that v6 must be a basic feature on every new box; but I don't think it is correct to force customers to buy a license that includes a lot of other bells and whistles just to get v6. It could be a separate cost. - j
Re: IPv6 Confusion
On Feb 18, 2009, at 5:57 PM, Joel Jaeggli wrote: Leo Bicknell wrote: I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. Then were busy staring at your laptop and not watching the program. If the IETF wants this to be a two way street actions would speak louder than words. In that I could not agree more. I am co-chair of Mboned, L3VPN and FecFrame and would be glad to present on any or all of these if there a desire for a status report or to provide feedback on these areas. Regards Marshall
Re: IPv6 Confusion
On 19/02/2009, at 9:20 AM, Adrian Chadd wrote: Who says the IPv6 solutions need to be better than IPv4? Actually, with IPv6 I'd like _a_ solution that at least is viable and works - it's doesn't have to be the final one, it doesn't have to even be as good as IPv4, it just has to be able to be productized for delivery to real customers like my mum and dad and not the 1337-g33ks from Planet Geekdom. Given it's 2009 and IPv6 has been around, for, well, sometime, I find it as someone trying to implement IPv6 on a large general scale for broadband that there's still a lot of proposals, drafts, general misunderstanding and turf wars over basic stuff like how the heck we're going to give IPv6 addresses to broadband customers. I understand that there are lot of people reading this who've spent time and effort trying to make forward progress and I salute you all, but come on - let's try and make this work so that all the lovely IPv6 stuff can be given to the masses rather than forcing us to spend our lives squabbling about how evil NAT is at an SP level. Does anyone here _really_ want Geoff Houston to be right about deploying IPv6? MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks
RE: Greedy Routing
I had to laugh when reading... This is how I think someone who doesn't get how the Internet works may try to re-explain what a researcher explained to them about how metrics influence the flow of traffic in BGP path selection. Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -Original Message- From: Deepak Jain [mailto:dee...@ai.net] Sent: Wednesday, February 18, 2009 5:01 PM To: valdis.kletni...@vt.edu; Rod Beck Cc: nanog list Subject: RE: Greedy Routing Maybe there's some critical insight in the paper that Physorg managed to totally not mention, I dunno. I saw it the same way... As the researchers explain, some types of networks are not navigable. For instance, if the probability that two nodes are linked doesn't depend on the metric distance between them, then such networks are difficult to navigate, as there is no way to choose one node over another based on distance. But when there is a connection between the link existence probability and the hidden distance between nodes, metric distances can help to navigate the network, i.e., such networks are navigable. If your network doesn't calculate or use metrics or weights, or AS path lengths... then you are not able to throw packets like fairy dust to their intended destination. Worse, if you use metrics unrelated to distance (like link cost) you could actually send your packets the wrong way. It's funny, but I think they said that their math shows that the Internet works to generally route packets (to a shorter path) than other possible paths. I'm sure that will come as a surprise to all of us. Deepak Jain AiNET
Re: IPv6 Confusion
Adrian Chadd wrote: Who says the IPv6 solutions need to be better than IPv4? I think that IPv6 solutions will automatically be better than IPv4 based on the switch to multicast for handling things. That being said, I haven't seen the normal IPv4 solutions migrated to IPv6 as of yet in the products I currently use. I honestly believe that a majority of the debate is mute, in that IPv6 *has* some L2 security stuff written up (which I don't believe they did with IPv4). Once vendors implement them, things will be on par. The only issue I've heard of is that DHCPv6 doesn't support handing out a router, which is in draft (and DHCPv6 is very clear that it only covers a base set and additional RFCs will be necessary for more options). RA should still be the switch that says SLAAC or DHCPv6, even if it isn't used for the option of routing. As said elsewhere in the thread, vendors will do what they feel they need to do, with or without an RFC. IOS, for example, doesn't support IA_TA or IA_NA at this time. It's in the DHCPv6 spec, though. -Jack
Re: IPv6 Confusion
On Feb 18, 2009, at 1:53 PM, Leo Bicknell wrote: Try that with an IPv6 router. About 10 ms after you plug into the wrong port out goes an RA, the entire subnet ceases to function, and your phone lights up like a christmas tree. Let me repeat, none of these solutions are secure. The IPv4/DHCP model is ROBUST, the RA/DHCPv6 model is NOT. Depends -- the DHCP model also ceases to work, and some time later, when there's no cause and effect. When I've added a misconfigured router to my IPv6 network, I added a few prefixes, but since it never worked, it never got used. Multihoming and good address selection seems to be a real win there. Good router authentication would be a nice thing to have in both cases, though. Aria Stewart aredri...@nbtsc.org smime.p7s Description: S/MIME cryptographic signature
Re: IPv6 Confusion
If the IPv6 solutions are not going to be #39;better#39; than v4, how about simply making sure that they are #39;as good as#39; ipv4? Right now, I#39;d be hard pressed to think of a v6 function which is #39;better#39; and I can think of a lot which are #39;not as good as.#39; -David Barak Adrian Chadd wrote: On Thu, Feb 19, 2009, Nathan Ward wrote: Yep. You asked your vendors to support equivalent IPv6 things at the time though, so when you roll out IPv6 the support is ready, right? The point is that these deficiencies exist in IPv4, and I'm not sure how you would solve them in IPv6 (assuming you can make all the changes you want, and get instant industry-wide support) any better than you solve them in IPv4. Who says the IPv6 solutions need to be better than IPv4? Adrian
Re: IPv6 Confusion
Mikael Abrahamsson wrote: Well, considering how very few vendors actually support IPv6, it's hard to find proper competition. Even the companies who do support IPv6 very well in some products, not all their BUs do on their own products (you know who you are :P ). Even worse is when the BU charges an insane price ($40k for 20 GigE ports for example) for a license to give a piece of their equipment IPv6 capabilities. I'm looking at you ES20 linecards. Adoption of IPv6 would be better in my opinion if vendors didn't force us to pay a premium to use IPv6. It's hard enough to convince management that there is a need to implement IPv6. It's even harder when you tell them how much it costs. And when they ask what they're getting for their dollars, they are none to pleased to hear that the bulk of it is going to a damn license. Justin
more AS prepend antics?
Why so many prepends from these folks? Feb 18 20:02:35.649 CST: %BGP-6-ASPATH: Long AS path 1785 1273 9035 1267 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 received from 209.253.101.9: More than configured MAXAS-LIMIT Feb 18 20:03:07.361 CST: %BGP-6-ASPATH: Long AS path 1785 2516 2516 2516 2516 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 9597 9597 9597 9597 received from 209.253.101.9: More than configured MAXAS-LIMIT Feb 18 20:04:07.849 CST: %BGP-6-ASPATH: Long AS path 1785 3549 8966 8961 38193 38264 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 received from 209.253.101.9: More than configured MAXAS-LIMIT -- mailto:n...@layer3arts.com // GoogleTalk: nrauhau...@gmail.com IM: nealrauhauser
Re: IPv6 Confusion
The fact that the *nog community stopped participating in the IETF has resulted in the situation where functionality is missing, because nobody stood up and did the work to make it happen. the ops gave up on the ietf because it did no good to participate. so the choice was spend the time accomplishing nothing or do something else with one's time. this is a slight exaggeration. it took me less than five years to get rid of NLAs, TLAs, ... wooo wooo! randy
Re: IPv6 Confusion
I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. i did a number of times. so have others. otoh, all that gets pretty destroyed by a few self-inflated ietf wannabes presenting org charts of the ietf and explaining what the grown-ups do for the benefit of us poor peons. randy
Re: IPv6 Confusion
Opsec wg alsoabout 2 years ago Ross Callon went to most NOGs to solicit input and I suppose now with Joel it'll be ongoing :) - merike On Feb 18, 2009, at 3:00 PM, Steven M. Bellovin wrote: On Wed, 18 Feb 2009 17:40:02 -0500 Leo Bicknell bickn...@ufp.org wrote: And let me ask you this question, why do the operators have to go to the IETF? Many of us have, and tried. I can't think of a single working group chair/co-chair that's ever presented at NANOG and asked for feedback. If the IETF wants this to be a two way street actions would speak louder than words. Without going into details, I have spoken at NANOG, and I've been a WG chair, an IAB member, and an AD. Randy has been an AD. I can think of several other ADs and IAB members who have frequently attended NANOG. I'm not saying it's perfect -- far from it! -- but the issue isn't nearly that one-sided. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Greedy routing
On Wed, 18 Feb 2009 22:12:02 GMT, Rod Beck said: http://www.physorg.com/news154093231.html From the fine article: In greedy routing, a node passes information to the neighboring node that is closest to the final destination in an abstract space called hidden metric space. Sounds suspiciously like throw the packet at the router that's got the shortest AS path to the destination doesn't it? You don't need to know the entire topology to know router X is 2 AS's closer to the dest than router Y once X and Y have been loaded with the hidden metric space known as a BGP update ;) No, it's quite different from BGP. The high level point is that BGP needs to know a lot of information about the network in order to route, while greedy routing (when it works) requires very little state. To make it concrete: You're right that BGP doesn't need to know the entire topology, but it comes quite close, in terms of the total amount of information it has. To throw the packet at the router that's got the shortest AS path to the destination, you need to have information from every neighbor about every destination. A BGP router in general needs one FIB entry for every destination (IP prefix) in the Internet, i.e., about 300,000 entries, and in the RIB it has potentially 300K from every BGP neighbor potentially, millions of entries. In contrast, greedy routing would require probably less than a dozen entries for the average router. This is because the router only needs to know its own identifier, and those of its immediate neighbors. The routing algorithm has some distance function dist (ID1, ID2). A packet comes with some destination identifier D, and the router compares the distance dist(N, D) for each neighbor N, and forwards the packet to the neighbor with smallest distance. For example, suppose you know the topology is a two-dimensional grid. Then the identifier is the router's (X,Y) coordinates and the distance function can be Euclidean distance. The main catch is of course that most networks don't have such nice regular structure like the grid. Essentially, greedy routing tries to summarize the structure of the network using a very small amount of information. And there are topologies whose pattern of links is too complicated (in a certain sense) for greedy routing to be able to summarize it. Therefore it is interesting when you find a network in which greedy routing works, especially if that network is vaguely realistic. The most well-known example is Jon Kleinberg's work on small world networks (http://tinyurl.com/dye7ub), which gives some theoretical backing to Milgram's six degrees of separation experiment from the 1960s (which basically used a kind of greedy routing). This physorg paper seems to be very much in the same style, showing that greedy routing works on an Internet-like graph. (Disclaimer: I have only read the above article, not the paper.) Of course there are plenty of reasons you would not use this in practice, e.g., it gives the router little control over routing policy, traffic engineering, etc. I'm not sure this article is actually telling us anything we didn't already know. Now if there was a way to compute those distance metrics without global knowledge - if there was only an algorithm that only cared about what was upstream from a locally connected link and whether it was connected. Say, we could call it a link-state routing protocol Now if they were able to actually develop a link-state protocol that involved *only* local adjacency announcements and not flooded announcements, *that* would be something... But what I see here is if somebody developed that, we'd be able to route more efficiently. This is essentially what they are doing. The distance is computed based on only local knowledge, not global knowledge. Each router needs to know only local adjacencies. Caveat: I haven't read the paper and don't know how they assign the router identifiers, so I am answering only about greedy routing in general. ~Brighten Godfrey
Re: IPv6 Confusion
On 19/02/2009, at 12:27 PM, Nathan Ward wrote: From other discussion with you, your main concern is vendor support for a few things, right? The issue is that the vendors aren't actually sure what to implement because there's a distinct lack of standards as opposed to competing drafts, p***ing contests, turf wars etc. What exactly do I ask vendors (as a group) to implement so that when I do, it's what everyone else is going to be following the same path? Is there actually a set of things that can be put together to work so that customer can experience hassle free internet in the same way as they do with IPv4? My discussions with people in the last few weeks regarding where it's all at and how I might do IPv6 broadband have made me feel despair not happiness about the future with this. It's people inside the standards bodies that also seem frustrated with this situation. MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Re: more AS prepend antics?
At 08:06 PM 18-02-09 -0600, neal rauhauser wrote: Why so many prepends from these folks? Cuz you set maxas=20? Just plain noise. -Hank Feb 18 20:02:35.649 CST: %BGP-6-ASPATH: Long AS path 1785 1273 9035 1267 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 41827 received from 209.253.101.9: More than configured MAXAS-LIMIT Feb 18 20:03:07.361 CST: %BGP-6-ASPATH: Long AS path 1785 2516 2516 2516 2516 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 17697 9597 9597 9597 9597 received from 209.253.101.9: More than configured MAXAS-LIMIT Feb 18 20:04:07.849 CST: %BGP-6-ASPATH: Long AS path 1785 3549 8966 8961 38193 38264 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 45127 received from 209.253.101.9: More than configured MAXAS-LIMIT -- mailto:n...@layer3arts.com // GoogleTalk: nrauhau...@gmail.com IM: nealrauhauser
issues with msn
Hey guys any of you guys seeing some issues getting to msn on the west coast here? I seem to be having issues via level3 abovenet and Comcast. -carlos
