Hi,
There was a meeting between proponents of this option, most vocal
opponets, MIF chairs, DHC chairs and two ADs and several other
knowledgeable people.

The conclusion of this meeting was that to proceed with route option
forward, specific use cases are needed. If you need this option, please
describe your use case. If you assume that others will raise support for
you, you may be in for a surprise.

If this does not get enough documented, valid use cases, it seems that
this option will not be standardized, at least not in IETF. Aternative
solution discussed was to convey this using vendor-specific option
(possibly within a body other than IETF); change the format to
explicitly disallow default route. From my perspective (DHCP vendor)
those approaches makes this solution much more difficult to deploy,
often even preventing it completely.

To have this list more organized, please assign a number to your support
voice. It will make it easier to explain if comments are made about
already mentioned use cases or new cases. If you have any specific
concerns, there's separate thread for that.

My understanding is that it helps if you are representing a large ISP, a
vendor or someone else who has non-trivial impact on the industry. Voice
of people, who express their personal opinions still count, but to a
lesser degree.

Here's the initial list of use cases.

1. http://www.ietf.org/mail-archive/web/mif/current/msg01412.html
On 11-11-16 08:59, Maglione Roberta wrote:
> Hello, during the meeting the chairs and many people asked about
> use cases and motivations for this work: as I quickly mentioned at the
> mic there is a draft in v6ops

2. http://www.ietf.org/mail-archive/web/mif/current/msg01428.html
On 11-11-17 19:14, teemu.savolainen@nokia.com wrote:
> +1
>
> I have to add I'm now quite confused why we are even having these
> motivation discussions, as the charter was already agreed quite some
> time ago. We are actually even late: -- Jun 2011 - Submit DHCPv6
> routing configuration option to IESG for publication as a Proposed
> Standard RFC --
>
> We should focus on technical issues to complete the spec, like the
> semantics. Not to spend time repeating old discussions.

3. Regarding motivation for real users, ISC is a DHCP vendor (client,
server, relay). Our software is installed as a default client and server
in many Linux and BSD distributions. Many of our customers and users
request this feature. I can't explain each deployment model, but the
commonly mentioned reason was simpler deployment and manageability. The
latest ISC code supports route-option-03, but I'm not sure if it does
matter or not.

4. I'm also author and developer of Dibbler, an open source DHCPv6
implementation (client, server, relay). This code works on Windows,
Linux, Mac OS X, and most types of BSDs. There are users, who request
this. Request for routing configuration (default route in particular) is
the number one question asked througout the years. There is at least one
ISP in Poland that wants (i.e. "already uses Dibbler and requests
routing configuration") to deploy this feature. The latest version of
Dibbler does support this route-option-03, but again I'm not sure if it
matters or not.

I admit that depending on your perspective this may be considered as a
valid vendor (Dibbler has been around for 8 years, existing community,
deployed in some production environments) or not (open source project
without any real money behind it).

I looked around and found the following other supporting voices. As I
don't have operational experience, it would be great if the original
proponents or commenters could go forward and explain their use cases.

- Previous attempt to introduce very similar was proposed by Thomas
Narten and Ralph Droms. Both were present during meeting and if I
understand correctly, their reason to drop this work was because there
was no substantial need for it last time (this was around 2009). Here's
a link to their presentation:
http://www.ietf.org/proceedings/74/slides/intarea-4.pdf It should be
noted that some open issues (slide 8) are now resolved.

- Wojciech Dec (Cisco) provided several usage models. I can't speak on
behalf of Cisco, but can only assume that they have reasonable need for
such feature. I'm sure Wojciech will provide detailed usage case soon.

- In previous versions of this draft, there were several more use cases
described:
http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-01
http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-02
They were removed based on MIF WG feedback.

- This draft is a result of a merge of 3 other drafts
(draft-sarikaya-mif-dhcpv6solution, draft-sun-mif-address-policy-dhcp6
and draft-dec-dhcpv6-route-option). Present and former authors represent
the following companies: Cisco, Huawei, China Mobile, Orange France
Telecom and NTT PF Labs. Previous attempt to introduce similar option
(draft-droms-dhc-dhcpv6-default-router-00) was undertaken by employees
of Cisco and IBM. If you are one of authors, it would be great if you
could step forward and explain your usage models and why you need this.
Also, if you decided that this work is no longer relevant or was
dropped, explaining the reasons would be very useful.

There is a draft "IPv6 Multihoming without Network Address Translation"
in v6ops (draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03). It
recommends use of this option. Again, if you are an author of this
draft, could you please explain why you need this.

We should also take into consideration people who were physically
attending in MIF meeting. Significant majority of people (around 20)
offered their support for this draft, while only 6 were against it.
Similar support was voiced during adoption of this document in MIF. If
you are one of those people, please express your support now.

To have a balanced discussion on this topic, I will create one more
thread regarding flaws and possible dangers of finishing this work, with
comments from two opponents. Feel free to contribute your concerns.

On a presonal note, my involvement in this work is on hold until this
issue is resolved.

Cheers,
Tomek Mrugalski
ISC