Re: RA DHCP problem...
Thus wrote Tarko Tikan (ta...@lanparty.ee): complicated and prefer one over another. Let RA and DHCP work independently and configure interfaces/routing tables. Let kernel sort out which address/route to use based on weights or even ECMP over both RA and DHCP defaultroutes if one chooses to do so. In other words: create undefined behaviour that breaks in new and exciting ways for every operating system (version) around. Thus creating a situation where instead of DHCP and RA, you get an exclusive or to preserve your sanity. You might as well declare RA deprecated directly. regards, spz -- s...@serpens.de (S.P.Zeidler)
Re: RA DHCP problem...
On 30/12/2013 12:13, Mikael Abrahamsson wrote: I am not asking these questions to be mean, I'm asking them to bring out all the reasons so someone will document them so they can be presented in a coherent consise manner (for instance an I-D). I know I have to do this when I want things to change. Been there, done that. Disclaimer: although I think defgw-in-DHCPv6 would be useful, we run SLAAC+RA without too many issues, and my gut feeling is that the IETF will never allow standardisation of, nor will vendors engage in deployment of, such a protocol in any timescale I care about. So this discussion is interesting to me for academic reasons only. That said: I'll document a specific issue we face in a large-ish enterprise-style (UK University) network, which I think RA-less IPv6 might alleviate/solve. We run a layer2 edge, layer3 core, and use MAC-based or 802.1x-based VLAN assignment to put devices at the edge into different networks, which are mapped into different L3VPN. Our edge switches support something that's getting pretty common now - mutiple supplicant mode, where 1 untagged vlan can be present on a port. RX traffic is mapped to the right vlan based on source MAC, and TX traffic from all vlans is sent to the port, including broadcast/multicast. (You can probably see where this is going) This feature is pretty useful because it allows end users in, for example, student residences to use a dumb switch on their port, but still lets us map the devices into different VLANs, allowing us to catch new ones and force them to do a click-through registration, for example. Other use-cases are VoIP+PC on the same port without LLDP/CDP/other voice VLAN hassles, or VM guests on separate VLANs to the VM host on unmanaged or semi-managed machines. One problem we have with this setup: If two devices are on a port, in different IPv6-enabled VLANs, they both see both RAs, and IPv6 connectivity breaks. If however there were no RAs, that would not be a problem. Possibly DHCPv6 + defgw would solve that? Now I can anticipate a number of objections to this, so let me try and cover them up front: 1. That's a terrible architecture it's (insecure | non-standard | blah) To be blunt: shove it. That's not your call, it's mine. It works great for us (mutiple RAs aside) and has the cost/benefit tradeoff is smack bang in the middle of where we, as an organisation, want to be. We're aware of its limitations, and don't claim it as perfect. But I know lots of other places that run substantially similar setups. 2. The switch (could | should) intercept and unicast the RAs to the correct endpoint MAC Maybe; that's a possible solution. In our case, the vendor is IPv6-ignorant, and I hold no hope of them ever doing it. But it's certainly an option. It does imply a busy CPU on the edge device as the number of VLANs/RAs-per-second goes up, and there might be other problems I can't think of right now (are there cases where a device will process an RA even if it's to a different destination MAC?) 3. 802.1x-REV will solve this as each endpoint will have separate MACSEC associations, and not see each others traffic Yeeaah maybe, in about 15 years. Seems like it would be nice to solve it earlier than that... ;o) === Anyway, as I said above - I would have liked to have seen defgw in DHCPv6, but we run mostly OK on RA+SLAAC. Since people seem interested in having issues with RA documented, I thought I'd write this one up. Thanks all for the interesting discussion (though I see lamentably little use of the principle of charity ;o) Cheers, Phil
Re: RA DHCP problem...
On Mon, 30 Dec 2013, Roger Jørgensen wrote: What is wrong with having something else than our _current_ RAs to provide defaultgateway on a network if the operator wish so? Let that be DHCPv6 or dibbler? Because the current method is known to work and you haven't given convincing arguments why it doesn't or why doing what you want is superior enough to warrant having two (or more) ways to do this? When I first looked into IPv6 I was of your opinion, why not do it the same way it's done in IPv4. Then I got over it. Operationally, I don't see having default gateway in DHCPv6 as something that makes much sense, apart from the fact that it means people have to learn less to start using IPv6, which I don't consider a valid use-case. For me, RA/RS/ND is all one single thing, you can't make IPv6 function without ND, so there is little reason to try to avoid the RA/RS machinery. A more valid use-case would be if you were propagating for new functionality and said that this would be easier to implement in DHCPv6 than in ND, and then you would get default-gw for free. That is the path I would choose. Unfortunately, the use-case that comes to mind (having routers that shouldn't have ::/0 pointed to them) is already implemented in by means of RIO in RAs. There is just very little deployed support for it as far as I know. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: RA DHCP problem...
hey, If you have RA from more than one source on the cable you are much more likely to identify that after none too long debugging if all your IP configuration is by RA. You'll just have bignum users calling the helpdesk to complain that The Internet Is Broken (tm) or that they can't work. It's different in that you can do a change in one protocol expecting it to be picked up, and a fraction of well-configured hosts may not because they prefer the other information source. Deterministic faults are MUCH easier to debug and fix than Heisenbugs. I don't agree at all that multiple RAs are easier to debug than RA+DHCP. Normal enduser will not be able to debug it and when you start looking with packet sniffer you will find the problem in both cases pretty quickly. Ok, so? How long do you suppose vendors would continue to support RA if all their enterprise customers ran setups where RA was expressly switched off? How well would the code that supports RA be tested? are you familiar with the term bitrot? Sure I am. Why do you think RA will be switched off? Me and Nick have totally different use-cases. I'm interested in supporting default gw together with IA_PD (don't really care for IA_NA at all) for HGW provisioning. This is in the operator network between HGWs and PEs. As I already said, it's totally natural to run RA behind the HGW in the LAN or in the enterprise network, even more as RDNSS is now there. Let's imagine someone proposes to add IA_PD equivalent into RA, will you then say it must not be done because DHCPv6 is already there? Or must DHCPv6 deprecated alltogether because RA can then do everything DHCPv6 can (not really true but you get my point)? It's not exactly someone elses problem as someone else don't need to do work if default gw is added to DHCPv6. You misread me. If default gw is added and DHCP clients start adding it to routing table, kernel developers, for example, don't have to add code. If we would have protocol preference then API between RA implementation and DHCP implementation has to be added. -- tarko
Re: RA DHCP problem...
On 30/12/2013 15:13, Lorenzo Colitti wrote: No, I mean - from a *security* perspective there's actually no security, because if there existed a host implementation that always tried all source addresses every time it connected, then that implementation would always work with no issues, even if you tried to put it on a restricted VLAN. Er, no. Sorry, I don't understand why you'd think that. Perhaps I am misunderstanding you, or you me. You could also fix this on the network side. You can even do this while maintaining the architecture :-) - when we had this problem many years ago (on wifi), the vendor fixed it by converting all RAs to unicast. I did point this out in my original mail. As noted, our vendor is IPv6-ignorant, so on this current platform it's not going to happen, which is a shame as it's a moderately easy solution. If you want to solve it using DHCP, then yes, clients that don't support DHCP are out. But again, you can fix this in the network as well. From an architectural perspective, what you have is a hack that happens to work in IPv4 because nothing depends on true VLAN isolation. It doesn't happen to work in IPv6. Yes. If DHCPv6 were usable, and could carry gw/prefix info, perhaps the hack would work again, and maybe it's a hack that's common and useful to a number of people, hence my email. However, since that will never happen IMO, it is (to risk repeating myself) of solely academic interest to me. I feel like we're going in circles a bit, so given the above I'm going to shut up now. IMO this is the direction we should be going in. Not let's just use DHCPv6, because it works so well in IPv4 (not). Maybe. I guess we'll see in the medium term if those features become common enough (and operationally usable).
Re: RA DHCP problem...
Le 30 déc. 2013 à 16:10, S.P.Zeidler a écrit : Thus wrote Tarko Tikan (ta...@lanparty.ee): Agreed this wasn't the best example but it's valid for two default gw's as well. ... not if your operating system will flat out refuse to enter a second one (as eg a Linux if you don't run more than one routing table). *Except if you received it from RAs Best regards Emmanuel Thierry
Re: RA DHCP problem...
On Mon, Dec 30, 2013 at 04:51:59PM +0100, Emmanuel Thierry wrote: Le 30 déc. 2013 à 16:10, S.P.Zeidler a écrit : Thus wrote Tarko Tikan (ta...@lanparty.ee): Agreed this wasn't the best example but it's valid for two default gw's as well. ... not if your operating system will flat out refuse to enter a second one (as eg a Linux if you don't run more than one routing table). *Except if you received it from RAs ip -6 r c default via fe80::1 dev eth0 via fe80::2 dev eth0 ...will start ecmp with those two addresses. Currently route-pref nor non-rfc4191 mode is configurable from user space. But this is simple to support in case dhcp configuration would need that.
Re: RA DHCP problem...
Hi, On Mon, Dec 30, 2013 at 04:13:28PM +0100, Lorenzo Colitti wrote: No, I mean - from a *security* perspective there's actually no security, because if there existed a host implementation that always tried all source addresses every time it connected, then that implementation would always work with no issues, even if you tried to put it on a restricted VLAN. No :-) - incoming packets from the host will be put into the assigned VLAN *only*. So exactly one combination of src address + default gw will get anywhere (hitting all restrictions if it's a restricted VLAN), and all other combinations will get *nowhere* - at least nowhere off-link - because the source IP will be wrong. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: RA DHCP problem...
Thus wrote Phil Mayers (p.may...@imperial.ac.uk): One problem we have with this setup: If two devices are on a port, in different IPv6-enabled VLANs, they both see both RAs, and IPv6 connectivity breaks. I assume you have considered fixing the route part by using fe80::1 (f.e.) as router address on all relevant VLANs? What reason spoke against it? You'll still have the using wrong prefix to source packets problem though (which could be fixed using dhcpv6 if your equipment were inclined to support it). regards, spz -- s...@serpens.de (S.P.Zeidler)
Re: RA DHCP problem...
On 30/12/2013 21:40, S.P.Zeidler wrote: Thus wrote Phil Mayers (p.may...@imperial.ac.uk): One problem we have with this setup: If two devices are on a port, in different IPv6-enabled VLANs, they both see both RAs, and IPv6 connectivity breaks. I assume you have considered fixing the route part by using fe80::1 (f.e.) as router address on all relevant VLANs? In fact we use a consistent HSRPv2 config on all our subnets, so the gateway *is* always the same; not fe80::1 but fe80::5:73ff:fea0:1. So basically, yes we did this. What reason spoke against it? As above, none ;o) You'll still have the using wrong prefix to source packets problem though (which could be fixed using dhcpv6 if your equipment were inclined to support it). Sure. I guess I should re-check, now that we're on IOS 15SY; maybe they finally fixed the bug - I did eventually get them to acknowledge that looking up the DHCP server next-hop and getting an output interface of Null0 and a source IP of fe80::... was a bug, not a feature request :o/
Re: RA DHCP problem...
On 29/12/2013 11:18, Gert Doering wrote: which is total crap, as HSRP/VRRP work perfectly fine with RAs sourced from the virtual IP this is a vendor-specific thing which is not universally supported. Nick
Re: RA DHCP problem...
hey, 4. there is no way for RAs to deploy different gateways to different hosts: all hosts on the network must be configured in the same way. +1 for this. We are currently using multiple default gw's (backed by multiple VRRP groups). This is something we can't port to ipv6 and it'll hurt as all capacity is not available for sudden peaks. -- tarko
Re: RA DHCP problem...
On 29/12/2013 11:55, Gert Doering wrote: Uh. And you seriously claim getting vendors to implement *that* is harder than getting universal no-RA-but-DHCPv6 implementations into the client stacks? Time to delivery is not an argument that we shouldn't do something. I would much prefer to depend on something which took longer to deliver but was fully standards compliant across all vendors rather than depending on vendor hacks which might or might not be supported, depending on phase of moon / the specific FHRP used / etc. Separately, in terms of vendor support for this sort of thing, dibbler-dhcpd already supports a nonstandard default route mechanism. The ISC people appear enthusiastic to support it in their product (one of the authors of draft-ietf-mif-dhcpv6-route-option works with the ISC). And if you look at previous authorships for some of the previous IDs, you'll see other vendor names like Huawei and Cisco. I haven't talked to the microsoft people. Nick
Re: RA DHCP problem...
On 29/12/2013 13:12, Philipp Kern wrote: that's basically what I said. I added the additional point that the DHCP server gives out different gateways for load balancing reasons. Right, I just misunderstood what you were saying. No, you can't do tightly timed failover with RAs […] How would you make that work with DHCPv6? Isn't that also MAC failover which you refuse to consider for RAs? Let me be more specific: you can only do tightly timed failover with RAs if you announce a virtual IP address which is tied to a first-hop redundancy protocol like vrrp/hsrp/etc. This is a vendor specific thing and is not even supported by many vendors. You cannot depend on the built-in mechanisms in RA and NUD to perform fast failover because you end up with a choice of either 10+ second failover or else compromising your network structure due to excess icmpv6 NS packets. Neither of these are workable solutions in production networks. If you want fast failover, you need to use vrrp / hsrp / carp / etc, all of which provide mac failover at layer 2. In this situation, you need a mechanism to deliver the default gateway information to the client. At the moment, the only standardised option is manual configuration. This doesn't scale. You would still have ND. And it's all part of ICMPv6, so you don't avoid an entire protocol unless you specify a target MAC to send traffic to. icmpv6 is a large pot of protocols which do many different things. RA is one subsection which delivers a specific set of services, and I usually consider it to be a separate protocol in its own right. 3. there is no way of specifying a global unicast ipv6 address. You can only specify link-local addresses. True. But you are talking about large L2 domains, which have link-local addressing. What's wrong with that? I'm just saying it's not possible to deploy global unicast addresses using RA. Maybe this doesn't matter to you. It's not that important to me either, but it may be important to some people with different network structures. Personally, I don't like the idea of unreasonable restriction of options when it comes to configuring networks. 5. there is no way to specify anything other than a default gateway. RDNSS is there, but not arbitary data, that's true. Yes, the big iron no, I meant that there is no other way to specify routing information other than a default route. E.g. if you have a box with two NICs; management network on one NIC and production on the other, there is no way to get dhcpv6 to instruct the client to hand off management traffic to one network and everything else to the production side. RDNSS I don't care about. Nick
Re: RA DHCP problem...
On Sun, Dec 29, 2013 at 02:09:01PM +, Nick Hilliard wrote: On 29/12/2013 13:12, Philipp Kern wrote: that's basically what I said. I added the additional point that the DHCP server gives out different gateways for load balancing reasons. Right, I just misunderstood what you were saying. No, you can't do tightly timed failover with RAs […] How would you make that work with DHCPv6? Isn't that also MAC failover which you refuse to consider for RAs? Let me be more specific: you can only do tightly timed failover with RAs if you announce a virtual IP address which is tied to a first-hop redundancy protocol like vrrp/hsrp/etc. This is a vendor specific thing and is not even supported by many vendors. Or just specify the ipv6 subnet anycast router address in a route-info RA section. ;) Greetings, Hannes
RE: RA DHCP problem...
Is there a chance this discussion can be captured in http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00 , or in some other problem statement document for potential issues re configuring routing with RAs? There has been a few discussion recently on this topic, and hence it does seem there is pain, however it doesn't seem there is a consensus on what all the pain points exactly are, as well as that DHCP is necessarily the right cure for that pain. To me it seems that capturing pain points in a document, which by going through the standard IETF process would (or would not) gather consensus on the problem statement, could be a productive way to move forward toward a solution. From: ipv6-ops-bounces+dmitry.anipko=microsoft@lists.cluenet.de ipv6-ops-bounces+dmitry.anipko=microsoft@lists.cluenet.de on behalf of Lorenzo Colitti lore...@google.com Sent: Sunday, December 29, 2013 2:25 PM To: Nick Hilliard Cc: IPv6 Ops list Subject: Re: RA DHCP problem... On Sun, Dec 29, 2013 at 10:18 PM, Nick Hilliard n...@foobar.orgmailto:n...@foobar.org wrote: On 29/12/2013 20:48, Lorenzo Colitti wrote: Is the size an issue here? Is there something about having tens of thousands of IPv6 hosts that makes RAs unsuitable? yes, size is an issue: it means that tweaking ns-interval is not feasible as a mechanism for dropping failover times. Agreed, using NUD timers for failover (aka hammer the first-hop router) doesn't scale. and if your hosts miss a packet, you get traffic swinging to your other default. You may like to debug this sort of thing, but I operate in companies with non-telephone number cost constraints and have a strong need for operational simplicity and consistency. It depends on how much loss there is and how many hosts switch. But yes, you probably want some margin. The operator can drop a protocol, but the host implementer needs to handle yep, exactly, but please bear in mind that networks are provisioned by operators for end-users. Network stacks are not written by host implementers for their own gratification. True, but the party that pays the cost is always the end user. doesn't scale. Routers are routers, not policy management engines. DHCP is for policy management and there is just no scalable way of handling this on routers. There's nothing stopping the routers from getting this information via RADIUS. DHCP doesn't help there. If you want better than that, you need to use something like VRRP anyway. Yes, I know: DHCPv6 + a first-hop routing protocol. This is the scenario I am interested in deploying. You know what? It works really well in practice. Well, but so does RA + VRRPv3. In addition to working in practice, it's a standard.
RA DHCP problem...
Hi all, Here is my summary from an online discussion. We know this affect alot of different things, RFCs, documents, not to forget many religious views, but _try_ to put all that aside for a while... We all think it's time to address this reoccurring issue and discussion on RAs and DHCP. RA isn't perfect, neither is DHCP but sometime there is a need to use DHCP instead of RAs. In short - DHCP need to be able to supply default gateway independing of RAs or no RAs. That is a client should be able to get only in a IPv6 only network _if_ there is no RAs, only DHCP there. The core change we're suggesting are to change things so: Supporting RAs is mandatory so no change there. However it is recommended to have it on by default, but NOT mandatory. We're _only_ opening up so anything else can provide defaultroute. DHCP must support defaultroute and must be decoupled from RAs, no M-bit or whatever. If DHCP and RA shows up, all should be added to the routing table and the kernel should sort it out. That is the implementer have a choice here but that's a completely other discussion thread all together. (tons of options on how DHCP and RAs can live together, all with their own pitfalls. From the simple one that dhcpclient can disable the kernel from accepting RAs with it's own pitfalls, to let the kernel sorting them out, and over to preferring either one - RAs or DHCPs defaultroute) -- -- Roger Jorgensen | - ROJO9-RIPE - RJ1866P-NORID ro...@jorgensen.no | - The Future is IPv6 --- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Re: RA DHCP problem...
On Sat, 28 Dec 2013, Roger Jørgensen wrote: supply default gateway independing of RAs or no RAs. That is a client should be able to get only in a IPv6 only network _if_ there is no RAs, only DHCP there. Why? What problem are you solving by changing the current behavior? DHCP must support defaultroute and must be decoupled from RAs, no M-bit or whatever. M-bit is a hint, nothing in the standard says a host isn't allowed to use DHCP on a network. (tons of options on how DHCP and RAs can live together, all with their own pitfalls. From the simple one that dhcpclient can disable the kernel from accepting RAs with it's own pitfalls, to let the kernel sorting them out, and over to preferring either one - RAs or DHCPs defaultroute) Personally I think it's a huge mistake for an implementor to have the kernel process RAs, all this control plane should be done in userspace, not in the kernel. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: RA DHCP problem...
hey, Why? What problem are you solving by changing the current behavior? We propose to decouple DHCP from RA, view them as two different autoconfiguration protocols. Today you can't deploy DHCP without RA and this forces you to support/secure two protocols that mostly overlap. Personally I think it's a huge mistake for an implementor to have the kernel process RAs, all this control plane should be done in userspace, not in the kernel. Kernel, userspace, doesn't matter but we propose not to make it complicated and prefer one over another. Let RA and DHCP work independently and configure interfaces/routing tables. Let kernel sort out which address/route to use based on weights or even ECMP over both RA and DHCP defaultroutes if one chooses to do so. -- tarko
Re: RA DHCP problem...
On Sat, Dec 28, 2013 at 03:41:58PM +0100, Roger Jørgensen wrote: It should be possible to have a network running DHCP without any RA, if someone wants to do that. As far as I know, and you need RAs in todays world because DHCPv6 can not give out defaultroute. It break the standard if it (DHCPv6) does... DHCPv6 does not provide any on-link information. So you would have to include those, too. IIRC dibbler dhcp implementation has their own option to specificy prefix length and on-link information so I assume you can already use it standalone without RA. But I don't see any benefit in doing so. (dibbler already supports sending gateway and route informations in dhcpv6). Greetings, Hannes
Re: RA DHCP problem...
On 28/dic/2013, at 17:36, Hannes Frederic Sowa han...@stressinduktion.org wrote: On Sat, Dec 28, 2013 at 03:41:58PM +0100, Roger Jørgensen wrote: It should be possible to have a network running DHCP without any RA, if someone wants to do that. As far as I know, and you need RAs in todays world because DHCPv6 can not give out defaultroute. It break the standard if it (DHCPv6) does... DHCPv6 does not provide any on-link information. So you would have to include those, too. IIRC dibbler dhcp implementation has their own option to specificy prefix length and on-link information so I assume you can already use it standalone without RA. But I don't see any benefit in doing so. (dibbler already supports sending gateway and route informations in dhcpv6). Dibbler sends them, but no DHCPv6 client except dibbler's can use them. Non-standard solutions are useless in this case. -- Marco Sommani Consiglio Nazionale delle Ricerche Istituto di Informatica e Telematica Via Giuseppe Moruzzi 1 56124 Pisa - Italia work: +390506212127 mobile: +393487981019 fax: +390503158327 mailto:marco.somm...@iit.cnr.it smime.p7s Description: S/MIME cryptographic signature
Re: RA DHCP problem...
On Sat, Dec 28, 2013 at 05:57:14PM +0100, Marco Sommani wrote: On 28/dic/2013, at 17:36, Hannes Frederic Sowa han...@stressinduktion.org wrote: On Sat, Dec 28, 2013 at 03:41:58PM +0100, Roger Jørgensen wrote: It should be possible to have a network running DHCP without any RA, if someone wants to do that. As far as I know, and you need RAs in todays world because DHCPv6 can not give out defaultroute. It break the standard if it (DHCPv6) does... DHCPv6 does not provide any on-link information. So you would have to include those, too. IIRC dibbler dhcp implementation has their own option to specificy prefix length and on-link information so I assume you can already use it standalone without RA. But I don't see any benefit in doing so. (dibbler already supports sending gateway and route informations in dhcpv6). Dibbler sends them, but no DHCPv6 client except dibbler's can use them. Non-standard solutions are useless in this case. Sure, I just wanted to maybe give a starting point if OP wants to bring this ot the IETF 6man's table.
Re: RA DHCP problem...
On Sat, 28 Dec 2013, Roger Jørgensen wrote: did you see the start of my mail? Yes. It should be possible to have a network running DHCP without any RA, if someone wants to do that. Why? Because I want to isn't a good technical answer. -- Mikael Abrahamssonemail: swm...@swm.pp.se
