Hi, This thread is about concerns regarding draft-ietf-mif-dhcpv6-route-option. At the moment this thead was started, the latest version is -03. See response to concern 3 below for proposed changes planned for -04. They will be implemented if the decision is made to continue this work. The latest presentation about this work was presented in DHC. It differs significantly compared to what was presnted in MIF. The major changes are: - option format to be unified to match RA - options from RA and DHCP do not override each other, but are merged instead (data delivered over DHCP are functional equivalent of receiving yet another RA).
The goal of this thread and its "in favor" counter-part is to get input for chairs, ADs and possibly whole IESG whether work on route option should continue or not. There was substantial discussion during last MIF meeting, with follow-ups off the list. I tried to assemble major concerns raised. I'm sorry if I missed anything. If you want to expand this list, please add a number for easier reference. On 11-11-16 17:14, Stuart Cheshire wrote: > Some of my concerns with the DHCPv6 route option are: > > 1. It duplicates what RA already does. I do not like duplication. It > is *more* than double the work, because not only do you have to > implement two things, you also have to worry about how those two > things interact. Testing is more than twice as hard. Instead of just > testing RA, now you have to test RA alone, DHCPv6 route option alone, > and RA + DHCPv6 together. Tomek's comment: You can choose to: - not support DHCPv6 at all (using RA-only) - use DHCPv6, but not request route options (and keep using RA) - use DHCPv6, request route options and use RA Only the third option has the properties that you describe. I do not think that vendors suddenly jump to route option, start producing CPEs that use DHCP only and stop announcing RA. (therefore I haven't mentioned 4th option: use DHCPv6 exclusively and do not support RA) Stuart's answer: This sounds intentionally naïve about how standards evolve. The existence of two different sanctioned ways of doing things means that some vendors (and network operators) will do things one way and other vendors (and network operators) will do things the other way, and user pain will result. Wojciech's answer: Fair point, but the alternatives cause pain for the network operator. A balance needs to be found, and that balance does not appear to involve "loose DHCP" or "loose RAs". Developing towards an eco-system of "user and his device" and "no-one-else-matters" is also sounding intentionally naive. Stuart's comment #2: That sounds suspiciously like an attempt to bully and blackmail client vendors into having to do extra development, testing and support work that they did not willingly consent to, for someone else's convenience. Wojciech's response to #2: That plays both ways: Having a client vendor's convenience that forces network operators to change how they run their business, and support also looks like bullying. The balance appears to be in the middle. > 2. Its syntax and semantics are different to RA. If we're going to > duplicate RA, at least keep it as similar as possible. Tomek's answer: Agree. If we decide to continue work on this, I'll work with Dave Thaler on unifying format and conveyed information between RA and route option. Would you like to review a draft version before we publish it as -04? > 3. Rather than overriding RA, DHCPv6 route option data should merge > in with other RA data. Tomek's answer: I wasn't very clear in my presentation. My proposal about favoring DHCP was only in case of conflicting route entries. Discussion during presentation and many follow-ups showed that this approach would work in some cases, but not in all. I think we should consider following changes to -03: a. explain in which conditions this will not work, describe them and keep the preference as was proposed. Note that the approach of delivering RA to all hosts and then override for some hosts on a per hosts basis is a valid argument in favor of this approach. It seems that at this stage this would exclude homenet from deploying this mechanism (but please see point 5. below). Lorenzo Colitti (Google) noted that applicability statements do not prevent anything and are often ignored. b. merge data between DHCP and RA. From OS perspective the route provisioning over DHCP could be roughly perceived as reception of yet another RA, with equal treating. > 4. Speaking as an employee of one of the client vendors, I have not > seen any compelling argument why we should have to do a bunch of > extra work to satisfy some other unspecified people. There is dedicated thread for support voices. 5. (new point). There is another problem raised by Lorezno and further expanded by Ted Lemon that manifests itself in homenet deployment (but possibly could affect other deployments as well). In homenet architecture, one of the deployment models is one LAN network with 2 CPEs that connect to 2 different ISPs. If those CPE also offer DHCP, client will choose only one advertise and completely ignore the second. In case of failure of this CPE, client doesn't have any ability to learn the other set of parameter that the second DHCP server would have provided. That is general problem of DHCP protocol and affects all other options that DHCP can provide (including addresses, delegated prefixes, and options like DNS or routing). Ted Lemon started working on this problem. See presentation about DHCPv6 and Multihoming problem statement in DHC WG. Presentation is not up yet, but hopefully it will appear here: http://tools.ietf.org/agenda/82/dhc.html 6. Doom of RA. Lorezno Colitti described set of events that he predicts will happen that will eventually lead to a collapse of the whole RA model. As a vendor of mobile devices, he afraids that once route option is defined, some CPE vendors will adopt it. This will force mobile device vendors to support route option. Once it becomes more popular, some CPE vendors may decide to stop announcing RA. This will enable operation without RA. Not needing it, RA will become essentially obsolete. This in turn will make the benefits of dynamic configuration offered by RA and put us back with static configuration that is known from IPv4. I can't comment on feasibility of this scenario as I don't have operational experience. During follow up discussions, several people pointed out that this is an excessively pessimistic scenario. Please add your favourite reason, why this option should not be deployed here. On the other hand, if you are supporter of this option, there is a separate thread for this as well. On a presonal note, my involvement in this work is on hold until this issue is resolved. Cheers, Tomek Mrugalski ISC _______________________________________________ mif mailing list [email protected] https://www.ietf.org/mailman/listinfo/mif
