Subject: [mif] Concerns regarding draft-ietf-mif-dhcpv6-route-option

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 17 Nov 2011 21:59:25 +0800

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 18 Nov 2011 11:50:46 +0100

Le 17/11/2011 14:59, Tomek Mrugalski a écrit :
> Hi, This thread is about concerns regarding
> 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.
>
> 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.
>
>> 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
>> 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

There should be a 4th possible way:
- use DHCPv6 and not use RA.

> think that vendors suddenly jump to route option, start producing
> CPEs that use DHCP only and stop announcing RA. (therefore I haven't
> 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.

In this particular case, I believe a number of vendors currently deploy
both DHCPv6 and RA in some devices.  I do not see conflict shaping up
until we mention default route.  In the past, similar conflict shaped up
with DNS server (provide with DHCP vs RA), and solved with lists of
preferences.

> 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.
>
> 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.
>
> 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?

Sorry for interfering - I would like to if possible.

>> 3. Rather than overriding RA, DHCPv6 route option data should
>> merge in with other RA data.

Tomek, this may sound too strong.  DHCPv6 default route is a new thing;
text recognizing the reality of existing (RA default route) base should
prevail now.  Indicating otherwise provokes negative reaction.  As time
goes, implementations may head towards DHCPv6 default route, or not.
Standards Track, Draft Standard, BCP - are much recognition of existing
reality at their respective time.

> 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.
>
> provisioning over DHCP could be roughly perceived as reception of
> yet another RA, with equal treating.

YEs, I agree with this, implementation at hand.  Our implementation of
DHCP default route merges DHCP data into ND data structures.

>> 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.
> 5. (new point). There is another problem raised by Lorenzo 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. Lorenzo 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.

DHCPv4 is probably the only widespread auto-configuration mechanism used
to manage large networks, thanks to its centralized database and
distributed relays.

For IPv6, I am not aware of such widespread auto-configuration mechanism
(free IPv6 doesn't use DHCPv6 but some different 6rd relying on IPv4).
It may be possible that DHCPv6 will be grown to manage large IPv6
networks as well.

Alex

> 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-masked] https://www.ietf.org/mailman/listinfo/mif
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Nov 2011 21:36:34 +0000

Alexandru, was there a use case in there that I missed?