Re: {SPAM?} Re: IPv6 Deployment for the LAN
The Wi-Fi MAC protocol has a pair of header bits that mean from AP and to AP. In ad-hoc mode, a designated station acts as an AP, so that's nothing special. There are a couple of non-AP modes for direct link exchanges and peer-to-peer exchances that probably don't set from AP but I'm not sure about that. Adrian Chadd wrote: On Sat, Nov 07, 2009, Bernhard Schmidt wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? Adrian -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Adrian Chadd adr...@creative.net.au wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? I'm not exactly a specialist for wireless, but as far as I remember my lectures the 802.11 has additional MAC fields for the wireless source/destination. Stations always send to the AP, the AP retransmits it to the station. IIRC WPA/WPA2 even has some protection against stations forging the AP MAC with the shared group key, but I don't remember any details. Bernhard
Re: {SPAM?} Re: IPv6 Deployment for the LAN
And of course, a rogue RA station would _NEVER_ mess with that bit in what it transmits... Uh, yeah. Owen On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote: The Wi-Fi MAC protocol has a pair of header bits that mean from AP and to AP. In ad-hoc mode, a designated station acts as an AP, so that's nothing special. There are a couple of non-AP modes for direct link exchanges and peer-to-peer exchances that probably don't set from AP but I'm not sure about that. Adrian Chadd wrote: On Sat, Nov 07, 2009, Bernhard Schmidt wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? Adrian -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC
Re: {SPAM?} Re: IPv6 Deployment for the LAN
It's not all that easy unless the dude has hacked the device driver. Owen DeLong wrote: And of course, a rogue RA station would _NEVER_ mess with that bit in what it transmits... Uh, yeah. Owen On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote: The Wi-Fi MAC protocol has a pair of header bits that mean from AP and to AP. In ad-hoc mode, a designated station acts as an AP, so that's nothing special. There are a couple of non-AP modes for direct link exchanges and peer-to-peer exchances that probably don't set from AP but I'm not sure about that. Adrian Chadd wrote: On Sat, Nov 07, 2009, Bernhard Schmidt wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? Adrian -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC
RE: {SPAM?} Re: IPv6 Deployment for the LAN
Device driver? Nah.
Just use a tool (like Scapy) to just arbitrarily, easily custom-craft any
packet he|she wants ... Yes, it is that easy.
Thanks!
/TJ
-Original Message-
From: Richard Bennett [mailto:rich...@bennett.com]
Sent: Saturday, November 07, 2009 15:37
To: Owen DeLong
Cc: Bernhard Schmidt; nanog@nanog.org
Subject: Re: {SPAM?} Re: IPv6 Deployment for the LAN
It's not all that easy unless the dude has hacked the device driver.
Owen DeLong wrote:
And of course, a rogue RA station would _NEVER_ mess with that bit
in what it transmits...
Uh, yeah.
Owen
On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote:
The Wi-Fi MAC protocol has a pair of header bits that mean from AP
and to AP. In ad-hoc mode, a designated station acts as an AP, so
that's nothing special. There are a couple of non-AP modes for direct
link exchanges and peer-to-peer exchances that probably don't set
from
AP but I'm not sure about that.
Adrian Chadd wrote:
On Sat, Nov 07, 2009, Bernhard Schmidt wrote:
As already said, wireless in infrastructure mode (with access points)
always sends traffic between clients through the access point, so a
decent AP can filter this.
How does the client determine that the traffic came from the AP versus
another client?
Adrian
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Sat, Oct 24, 2009 at 11:33 PM, Karl Auer ka...@biplane.com.au wrote: On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote: the mac address of the rouge server pedantic It's R-O-G-U-E - rogue. Rouge is French for red and English for red make-up. Also the name of the Ford assembly plant at which the Monday night social was held. I blame the repeated repetition of the plant name throughout the night for planting it so thoroughly in our collective subconscious. ;) /pedantic Regards, K.
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On wireless networks you can note the mac address of the rouge server and dissociate it from the wireless network, this is rather similar to what we did on switches prior to dhcp protection, it is reactive but it certainly can be automatic. Some controller based wireless systems have ips or nac functionality that does this already. joelja David W. Hankins wrote: On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. There are some wireless equipment that claim to have a setting that forces all packets through the wireless bridge (where all traffic is between clients and bridge, and never client to client), and so one can filter DHCPv6 and maybe RA, but I am kind of skeptical about how much of this is elective and dependent upon client implementation... In both cases there may still be some wireless adapters that receive bogus packets directly from attackers. And then you bring ND into the question and wonder why you bothered with either RA or DHCP filtering. DHCPv6 (and DHCPv4 with RFC 3118) has per-message cryptographic authentication. The problem however has been the key distribution model. Here it all falls down, and leads to poor deployment. But with DHCPv*, we have a hope that we can secure it if we can solve that last problem (and at least I think we can). So if you accept that as an outcome, one must ponder the question: How long will people accept that a secured DHCPv6 session must rely, in order to function to expectations, upon the unsecurable RA and/or questionably secure SEND?
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote: the mac address of the rouge server pedantic It's R-O-G-U-E - rogue. Rouge is French for red and English for red make-up. /pedantic Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Sun, 25 Oct 2009 17:33:34 +1100 Karl Auer ka...@biplane.com.au wrote: On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote: the mac address of the rouge server pedantic It's R-O-G-U-E - rogue. Rouge is French for red and English for red make-up. /pedantic Also the colour of the faces of angry net admins when they discover a rogue, possibly rouge coloured server. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Fri, Oct 23, 2009 at 12:50:47PM +1300, Perry Lorier wrote: I've implemented myself a system which firewalled all ARP within the AP and queried the DHCP server asking for the correct MAC for that lease then sent the ARP back (as well as firewalling DHCP servers and the like). It's quite easily doable, and quite reliable. If nodes were to send packets directly when associated to an AP then the 802.11 protocol would fall apart, I've never met an implementation that broke this requirement of the standard. It had not occurred to me to intercept ARP (or ND) as a transition mechanism, that is pretty clever, but the idea of using DHCPv* leasequery as a way to make IP-MAC resolution both secure and unicast is something I've heard many times. I don't know about my peers, but I would be very interested to see an RFC that describes and examines your results. You can of course pretend you're the AP and send a packet if you're wanting to be vicious enough. Yes, of course, that is much simpler. If the attacker can associate with the real wireless network, they can always bridge and provide a rogue AP to insert themselves in the middle. Sometimes in focusing on packet exchanges, we miss the forest for the trees. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpNQAGCnPio4.pgp Description: PGP signature
Re: {SPAM?} Re: IPv6 Deployment for the LAN
This to me is one of the least credible claims of the RA/SLAAC crowd. On the one hand we have carriers around the world with millions and millions of customers getting default routes and other config through DHCPv4 every day. And most of the time it actually works very well! On the other hand we have RA/SLAAC with a vastly smaller customer base, vastly less real life testing - but which is still claimed to be so much better that DHCPv6 is not *allowed* to get a default route option. If the argument against RA being used to provide gateway information is rogue RA, then announcing gateway information though the use of DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but you'll still have to deal with rogue DHCPv6. So what is gained? I guess I'm not really seeing the case here. Are people really making use of DHCP to provide hosts on the same network with different default gateway information? If so, why? Or is it that you want IPv6 to be a 128-bit version of IPv4? RA is a good idea and it works. You can add options to DHCPv6, but I don't see many vendors implementing default gateway support unless you can make a real case for it. My fear is that your goal is to do away with RA completely and turn to DHCPv6 for all configuration. RA is actually quite nice. You really need to stop fighting it, because it's not going away. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: {SPAM?} Re: IPv6 Deployment for the LAN
In a message written on Thu, Oct 22, 2009 at 03:23:13PM -0400, Ray Soucy wrote: If the argument against RA being used to provide gateway information is rogue RA, then announcing gateway information though the use of DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but you'll still have to deal with rogue DHCPv6. So what is gained? It's a huge difference, and any conference network shows it. Let's assume 400 people come into a room, get up and working (with DHCPv4, and IPv6 RA's). Someone now introduces a rogue IPv4 server. Who breaks? Anyone who requests a new lease. That is 400 people keep working just fine. Now, someone introduces a roge RA. Who breaks? All 400 users are instantly down. More importantly, there is another class of misconfigured device. I plugged in a Cisco router to download new code to it on our office network. It had a DHCP forward statement, and IPv6. It was from another site. The DHCP forward didn't work, it pointed to something non-existant that also was never configured for the local subnet. There was zero chance of IPv4 interfearance. The IPv6 network picked up the RA to a router with no routes though, and so simply plugging in the old router took down the entire office network. The operational threats of a DHCP based network and a RA based network are quite different. Try it on your own network. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgptlutTow2Rl.pgp Description: PGP signature
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Sorry, not buying it. The solution here, and one that is already being worked on by vendors, is RA gaurd, not changing DHCPv6 in an effort to bypass RA. What your proposing as a solution isn't much of a solution at all but just a (seemingly) lesser problem. On Thu, Oct 22, 2009 at 3:29 PM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Thu, Oct 22, 2009 at 03:23:13PM -0400, Ray Soucy wrote: If the argument against RA being used to provide gateway information is rogue RA, then announcing gateway information though the use of DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but you'll still have to deal with rogue DHCPv6. So what is gained? It's a huge difference, and any conference network shows it. Let's assume 400 people come into a room, get up and working (with DHCPv4, and IPv6 RA's). Someone now introduces a rogue IPv4 server. Who breaks? Anyone who requests a new lease. That is 400 people keep working just fine. Now, someone introduces a roge RA. Who breaks? All 400 users are instantly down. More importantly, there is another class of misconfigured device. I plugged in a Cisco router to download new code to it on our office network. It had a DHCP forward statement, and IPv6. It was from another site. The DHCP forward didn't work, it pointed to something non-existant that also was never configured for the local subnet. There was zero chance of IPv4 interfearance. The IPv6 network picked up the RA to a router with no routes though, and so simply plugging in the old router took down the entire office network. The operational threats of a DHCP based network and a RA based network are quite different. Try it on your own network. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: {SPAM?} Re: IPv6 Deployment for the LAN
In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Soucy wrote: The solution here, and one that is already being worked on by vendors, is RA gaurd, not changing DHCPv6 in an effort to bypass RA. Port based solutions don't work well on wireless networks and other mediums. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpdNPR62fPVP.pgp Description: PGP signature
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. On Thu, Oct 22, 2009 at 3:50 PM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Soucy wrote: The solution here, and one that is already being worked on by vendors, is RA gaurd, not changing DHCPv6 in an effort to bypass RA. Port based solutions don't work well on wireless networks and other mediums. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. Rogue DHCP doesn't immedately take down the entire subnet of machines with existing DHCP leases. It generally only affects new machines trying to get a lease, or RENEWing machines. The impact of a rogue RA is to immediately break connectivity for every machine on the subnet. Differing impacts leads to different risk assessments of which protocol to use. Regardless, modern wireless deployments use central controllers or smart APs that can filter DHCP. They could be extended to filter RA as well. And this whole point is rather moot because we have RAs and must deal with them. It is too late to get rid of the RA behavior of clients. Even if you don't want to use RAs, your hosts are going to still listen to them which means a Rogue RA is going to take down your network. We have this problem even on IPv4-only subnets, where a Rogue RA (usually a Windows box with routing turned on) breaks connectivity to dual-stack servers for machines on that subnet. Since the hosts prefer native IPv6 connectivity over IPv4, the hosts end up preferring the Rogue RA as the route towards the dual-stack server. We really just need to bug our vendors to implement Rogue RA protection for wired and wireless ASAP, wherever we are in our deployment of IPv6.
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Correct. Not sure if you got the sarcasm in that last reply... As far as I'm concerned, a rogue is a rogue. Knowing about it the instant it happens might even be better than slowly coming to the realization that you're dealing with one. The point is that we need to address rogues regardless of their type, not move from RA to DHCPv6 because the impact of a rogue is slower to disrupt service. On Thu, Oct 22, 2009 at 4:06 PM, Chuck Anderson c...@wpi.edu wrote: On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. Rogue DHCP doesn't immedately take down the entire subnet of machines with existing DHCP leases. It generally only affects new machines trying to get a lease, or RENEWing machines. The impact of a rogue RA is to immediately break connectivity for every machine on the subnet. Differing impacts leads to different risk assessments of which protocol to use. Regardless, modern wireless deployments use central controllers or smart APs that can filter DHCP. They could be extended to filter RA as well. And this whole point is rather moot because we have RAs and must deal with them. It is too late to get rid of the RA behavior of clients. Even if you don't want to use RAs, your hosts are going to still listen to them which means a Rogue RA is going to take down your network. We have this problem even on IPv4-only subnets, where a Rogue RA (usually a Windows box with routing turned on) breaks connectivity to dual-stack servers for machines on that subnet. Since the hosts prefer native IPv6 connectivity over IPv4, the hosts end up preferring the Rogue RA as the route towards the dual-stack server. We really just need to bug our vendors to implement Rogue RA protection for wired and wireless ASAP, wherever we are in our deployment of IPv6. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Oct 22, 2009, at 12:23 PM, Ray Soucy wrote: This to me is one of the least credible claims of the RA/SLAAC crowd. On the one hand we have carriers around the world with millions and millions of customers getting default routes and other config through DHCPv4 every day. And most of the time it actually works very well! On the other hand we have RA/SLAAC with a vastly smaller customer base, vastly less real life testing - but which is still claimed to be so much better that DHCPv6 is not *allowed* to get a default route option. If the argument against RA being used to provide gateway information is rogue RA, then announcing gateway information though the use of DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but you'll still have to deal with rogue DHCPv6. So what is gained? Apparently you missed the entire message he responded to about the number of things specified by DHCP and the differences between the groups in control of the routers vs control of the hosts/servers and the actual administrative groups in charge of each? I guess I'm not really seeing the case here. Are people really making use of DHCP to provide hosts on the same network with different default gateway information? If so, why? Yes. A number of different application and business requirements. Some I can go into easily (load balancing among different routers, routers owned by different departments, etc.), some are proprietary to my clients and I can't give enough details without violating NDA. Or is it that you want IPv6 to be a 128-bit version of IPv4? RA is a good idea and it works. You can add options to DHCPv6, but I don't see many vendors implementing default gateway support unless you can make a real case for it. The assignment of gateway information to the host belongs in the hands of the systems administrators and not in the hands of the people running the switches and routers in many organizations. With router information assigned through DHCP, this is preserved. With it being assigned by the router, it is not, and, in fact, the case. With DHCPv6 unable to assign router information you lose that administrative boundary and take away a systems administrators control over their hosts and hand it to the networking group. My fear is that your goal is to do away with RA completely and turn to DHCPv6 for all configuration. RA is actually quite nice. You really need to stop fighting it, because it's not going away. Not at all. People are not saying RA has to go away. They are saying we need the option of DHCPv6 doing the job where we do not feel that RA is the correct tool. More tools are good. Replacing one tool that works today with a new tool that is arguably inferior in many real world cases, on the other hand, is not so good. Owen
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Original Message From: Ray Soucy r...@maine.edu Or is it that you want IPv6 to be a 128-bit version of IPv4? Yes, this is in fact exactly what the network operators keep saying. RA is a good idea and it works. You can add options to DHCPv6, but I don't see many vendors implementing default gateway support unless you can make a real case for it. My fear is that your goal is to do away with RA completely and turn to DHCPv6 for all configuration. RA is actually quite nice. You really need to stop fighting it, because it's not going away. RA may be quite nice for some cases. However, several examples over this thread alone have been provided about some other cases where it is something other than nice. DHCPv4 is not a perfect protocol, but it's widely deployed and understood. It also is a one-stop-shop for centralized host configuration. IPv6 does not currently have a similar one-stop-shop protocol, and this is a major gap in functionality. There are a bunch of very large providers and enterprises which number their DHCP-managed end-sites in the hundreds of thousands or millions. The inability to provide the same centralized configuration management should not be considered a feature. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Owen DeLong wrote: Not at all. People are not saying RA has to go away. They are saying we need the option of DHCPv6 doing the job where we do not feel that RA is the correct tool. Then let me say it. RA needs to be able to be completely turned off. DHCPv6 needs to be able to completely configure all requesting hosts. DHCPv4 works everywhere and meets every networks needs, from the $50 linksys to the million dollar network. RA already does not. The answer to RA shortcomings is not to turn it into a clone of DHCP, only stateless and chained to the router. More tools are good. Replacing one tool that works today with a new tool that is arguably inferior in many real world cases, on the other hand, is not so good. Owen Sure, leave RA in the IPv6 stack. The market will decide, and we will see if it is still on by default on soho routers and in IOS 15.4T in 2015. Joe
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Port based solutions don't work well on wireless networks and other mediums. Something like PSPF then? (assuming it works properly on IPv6 multicast ... ) /TJ
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Then let me say it. RA needs to be able to be completely turned off. DHCPv6 needs to be able to completely configure all requesting hosts. Those two statements are not synonymous ... Sure, leave RA in the IPv6 stack. The market will decide, and we will see if it is still on by default on soho routers and in IOS 15.4T in 2015. That is a more sensible statement. And were I to be a gambling man I would say it will indeed be on by default ... we'll talk more about it then :). Also, I would like to add - there is a difference between the default gateway information and other things, such as NTP|DNS|SIP server information. The default gateway, by definition, is an on-link thing. IMHO, this makes the router a good source for information about the router. I am not saying use cases for fully spec'ed DHCPv6 don't exist or should be ignored. Making the router capable of sharing the missing piece that covers ~95% of use cases is also a Good Thing. Thinking out loud, we could also re-create the idea of an auto-magic DNS by creating a special use case within ULA-space - say FD00::/96, saving the last 32 bits for something like ::53 and using anycast. *(Could abstract same idea to any stateless and/or light-session-based service ... FD00::123 for Automagic ULA-based anycast NTP, etc. Need 32 bits if we don't want to hex convert the things, just in case ...)* /TJ
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Oct 22, 2009, at 4:32 PM, Ray Soucy wrote: Knowing about it the instant it happens might even be better than slowly coming to the realization that you're dealing with one. Might just be me, but I'm more worried about the rogue RA (or DHCPv4) server that does not disrupt communication at all...
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. There are some wireless equipment that claim to have a setting that forces all packets through the wireless bridge (where all traffic is between clients and bridge, and never client to client), and so one can filter DHCPv6 and maybe RA, but I am kind of skeptical about how much of this is elective and dependent upon client implementation... In both cases there may still be some wireless adapters that receive bogus packets directly from attackers. And then you bring ND into the question and wonder why you bothered with either RA or DHCP filtering. DHCPv6 (and DHCPv4 with RFC 3118) has per-message cryptographic authentication. The problem however has been the key distribution model. Here it all falls down, and leads to poor deployment. But with DHCPv*, we have a hope that we can secure it if we can solve that last problem (and at least I think we can). So if you accept that as an outcome, one must ponder the question: How long will people accept that a secured DHCPv6 session must rely, in order to function to expectations, upon the unsecurable RA and/or questionably secure SEND? -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpf4lygcPQdK.pgp Description: PGP signature
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Oct 22, 2009, at 2:31 PM, TJ wrote: Then let me say it. RA needs to be able to be completely turned off. DHCPv6 needs to be able to completely configure all requesting hosts. Those two statements are not synonymous ... They may not be synonymous, but, there is a set of operators for whom both are true. Sure, leave RA in the IPv6 stack. The market will decide, and we will see if it is still on by default on soho routers and in IOS 15.4T in 2015. That is a more sensible statement. And were I to be a gambling man I would say it will indeed be on by default ... we'll talk more about it then :). Also, I would like to add - there is a difference between the default gateway information and other things, such as NTP|DNS|SIP server information. Maybe. The default gateway, by definition, is an on-link thing. IMHO, this makes the router a good source for information about the router. It does in some cases. In other cases, it does not. I am not saying use cases for fully spec'ed DHCPv6 don't exist or should be ignored. Making the router capable of sharing the missing piece that covers ~95% of use cases is also a Good Thing. I don't think most people are arguing that it should not be possible to configure a network for RA/SLAAC with the RA providing the gateway information. In fact, I think most of us would like to see RA/SLAAC capable of providing the other needed pieces of the puzzle. That said, there is a group of operators for whom RA is a bad thing, SLAAC is also a bad thing, and, their current usage of DHCPv4 does not map to any existing IPv6 technology, so, they are crying foul and want their needs addressed. I think that is 100% legitimate, regardless of whether Iljitsch thinks we are old enough to play with power tools or not. Thinking out loud, we could also re-create the idea of an auto-magic DNS by creating a special use case within ULA-space - say FD00::/96, saving the last 32 bits for something like ::53 and using anycast. That's a fine solution for part of the problem space, but, moving the router assignment function for hosts to a device controlled by the host administrator is a necessary administrative boundary issue for a number of organizations. *(Could abstract same idea to any stateless and/or light-session-based service ... FD00::123 for Automagic ULA-based anycast NTP, etc. Need 32 bits if we don't want to hex convert the things, just in case ...)* NOOO... If you're going to do fd00:: for this, the 123 case really should be fd00::7b, not fd00::123 Owen
Re: {SPAM?} Re: IPv6 Deployment for the LAN
I generally agree with the design of RA and using DHPCv6 as a supplement to it. The problems here seem to be more along the lines of implementation in clients. I suspect it will take some time for the dust to settle and vendors to get their act together. I notice that Cisco has a prefix no-autoconfig statement in some releases in addition to no-advertise. The code I'm running doesn't seem to support this yet. I'll have to dig deeper to see what series support it and how it interacts with hosts. If hosts actually do respect it, it will likely lead to our migration to using /64s, though a lot will depend on the time tables we can set to move to code that will support this on our routers. I do remember seeing some notes about some implementations of IPv6 simply ignoring that flag for the prefix, though, so I'm still hesitant to endorse it until I've had a chance to test a wide variety of hosts in this configuration. Still, using a prefix other than a /64, but maintaining a migration path to /64 in the future, seems to be the best way to get IPv6 rolled out to the edge from a political standpoint. It's easier to make the case to extend IPv6 if you can be fairly certain that it won't cause hosts to suddenly start using IPv6 on their own. I have yet to run into an IPv6 implementation that will use SLAAC with a prefix other than a /64, thankfully. From what I've been told, Cisco is actively working on RA-gaurd for their managed switching platforms, which will be nice to see. Reading a bit of the discussions regarding IPv6 in the Apple world, it seems that they're after supporting DNS server information in RA using RFC 5006. I think RFC 5006 is a very bad idea personally. DHCPv6 was designed to work in harmony with RA, and providing host configuration is beyond the scope of RA. I hope that we don't start seeing implementations of this as it will lead to an environment where some clients support DHCPv6 and some do not. The SLAAC vs. DHCPv6 war all seems a bit silly. They're both tools that are designed to compliment one another, and both have their uses. DHCPv6 does complicate things with the DUID rather than using the physical address, but I can appreciate the problems they're trying to overcome. It just makes this a little more complicated for those of us who would like to maintain associations between a hosts IP and IPv6 information in a dual-stack environment. On Sun, Oct 18, 2009 at 11:45 AM, Kevin Loch kl...@kl.net wrote: Nathan Ward wrote: On 19/10/2009, at 1:10 AM, Owen DeLong wrote: On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote: On 18/10/2009, at 11:02 PM, Andy Davidson wrote: On 18 Oct 2009, at 09:29, Nathan Ward wrote: RA is needed to tell a host to use DHCPv6 This is not ideal. Why? Remember RA does not mean SLAAC, it just means RA. Because RA assumes that all routers are created equal. RFC4191 In some cases different devices on a segment need a different default router (for default). This is the fundamental problem with RA's, they shotgun the entire segment. Because RA is harder to filter. DHCP in IPv4 was hard to filter before vendors implemented it, too. Because the bifercated approach to giving a host router/mask information and address information creates a number of unnecessary new security concerns. Security concerns would be useful to explore. Can you expand on this? What would be useful would be having the option to give a default router to a dhcpv6 client, and having vrrpv6 work without RA's. Why can't we have those options in our toolbox in addition to this continuously evolving RA+hacks? - Kevin -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: {SPAM?} Re: IPv6 Deployment for the LAN
And not just Cisco, IIRC it is an open standard anyone can implement ... ? Here is the work being done on RA-Gaurd: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-03 -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
