Subject: [mif] Motivations for draft-ietf-mif-dhcpv6-route-option

From: Maglione Roberta <[email-masked]>
Date: Wed, 16 Nov 2011 01:59:42 +0100

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 (draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat) that clearly explains the use cases and the requirements, coming from a Service Provider, for  this work.
In Broadband network environment where the CPE is multi-homed to two upstream edge routers and each router provides connectivity for different types of services for example internet access and Video on Demand (restricted inside a walled garden,) and the Service Provide would like to avoid routing on the CPE, there is a need to provision static route entries on RGs/CPEs.

 As a Service Provider we believe DHCPv6 is the right tool to that because we need a centralized control/management point for storing the customer’s related info  (ipv6 prefix, ipv6 routes, …) and DHCPv6 is a good place for that. Using RA’s would require to manually provision the edge router and this operation is not always possible, for example when router is operated by 3rd party.

Regarding the issues raised about the potential need for VRRP on the CPE to protect against failure, in my opinion in the scenario described above VRRP is not needed because if the connection to the edge router providing internet service is down I don’t want the user traffic using the other link because the other edge router only provides limited connectivity  to a restricted walled garden. As far as DHCPv6 failure, as many of you know there is ongoing work on dhc WG in order to provide DHCPv6 redundancy.

I really would like to see this work progressing because it is needed as many Service Providers said not only draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat, but also in Broadband Forum documents, if you take a look at WT-124i3 you can find requirements calling exactly for this draft to solve the problem described above, this means a community of Service Providers’ recognized the need for this work.

Thanks
Regards,
Roberta

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: <[email-masked]>
Date: Thu, 17 Nov 2011 11:14:44 +0000

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

Best regards, 

	Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
> Maglione Roberta
> Sent: 16. marraskuuta 2011 09:00
> To: mif
> Subject: [mif] Motivations for draft-ietf-mif-dhcpv6-route-option
> 
> Hello,
> as I quickly mentioned at the mic there is a draft in v6ops (draft-ietf-v6ops-
> ipv6-multihoming-without-ipv6nat) that clearly explains the use cases and the
> requirements, coming from a Service Provider, for  this work.
> In Broadband network environment where the CPE is multi-homed to two
> upstream edge routers and each router provides connectivity for different
> types of services for example internet access and Video on Demand (restricted
> inside a walled garden,) and the Service Provide would like to avoid routing
> on the CPE, there is a need to provision static route entries on RGs/CPEs.
> 
>  As a Service Provider we believe DHCPv6 is the right tool to that because we
> need a centralized control/management point for storing the customer's
> related info  (ipv6 prefix, ipv6 routes, ...) and DHCPv6 is a good place for that.
> Using RA's would require to manually provision the edge router and this
> operation is not always possible, for example when router is operated by 3rd
> party.
> 
> Regarding the issues raised about the potential need for VRRP on the CPE to
> protect against failure, in my opinion in the scenario described above VRRP is
> not needed because if the connection to the edge router providing internet
> service is down I don't want the user traffic using the other link because the
> other edge router only provides limited connectivity  to a restricted walled
> garden. As far as DHCPv6 failure, as many of you know there is ongoing work
> on dhc WG in order to provide DHCPv6 redundancy.
> 
> I really would like to see this work progressing because it is needed as many
> Service Providers said not only draft-ietf-v6ops-ipv6-multihoming-without-
> ipv6nat, but also in Broadband Forum documents, if you take a look at WT-
> 124i3 you can find requirements calling exactly for this draft to solve the
> problem described above, this means a community of Service Providers'
> recognized the need for this work.
> 
> Thanks
> Regards,
> Roberta
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
> indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
> conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2011 12:28:58 +0000

> 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:

The fact that this is in the MIF charter does not mean that there is consensus within the IETF to proceed with it.   That is why we are having this conversation now.

---

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

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, [email-masked] 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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2011 20:04:49 +0000

> of people, who express their personal opinions still count, but to a

To be clear, a use case is not "I want it because I think it would be nice."   It's "Router Advertisements don't work for me for the following specific reason in my actual deployment."  

The fact that it is the most requested feature isn't the point.   The question is, *why* is it the most requested feature?   Is it because people have zero operational experience with IPv6, and are just trying to do the same thing they did in IPv4, and once you explain RAs to them they say "oh, okay" and stop asking for it?   Or is it the case that there is some genuine deployment problem that RAs don't properly address?

The reason why the vendor option solution was proposed is that the only use cases that anybody could actually come up with in the meeting yesterday were use cases that were specific to particular ISP deployment models, and it seemed clear that these use cases could be adequately addressed with 3GPP- and BBF-specific extensions.   There is genuine need in these two cases for this functionality.

The reason why this isn't a no-brainer is that if it were added as a standard IETF solution, it would change what end nodes have to do to get routes, making end node software more complicated, and also more difficult to specify.   As one of the authors of the MIF API document, I've had to think a lot about this problem, and I do not like having to have two different ways of configuring routes.   The MIF problem is hard enough already; adding this to the problem seems to me to make it worse, not better.

I'm also pragmatic.   If we have to make this problem a little bit worse to solve some real world problem, fine, let's make the problem a little bit worse.   But if we're doing it because people think they have to have feature parity with DHCPv4, that's just not a good enough reason.

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Nov 2011 15:37:31 -0500

> of people, who express their personal opinions still count, but to a

That is a misunderstanding.  

We are all supposed to be acting as individuals here, voicing our own opinions as to what is best for the Internet.    Nobody's opinion counts more than any one else's when it comes to determining consensus.

That said, many individuals (hopefully most of us) do care about the degree of impact that a design choice would have, so    if an employee of a major vendor says that a choice will have a significant impact on that vendor's customers, that input tends to be taken seriously.   Actually, input of that kind tends to be taken seriously even if it doesn't come from a vendor's employee, but it might be taken as more credible if it comes from someone who is presumed to have first-hand knowledge.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2011 14:38:40 +1300

On 2011-11-18 09:04, Ted Lemon wrote:
>> 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.

In terms of IETF process, that is not OK. We are individuals
here, expressing individual engineering arguments.

Nevertheless it is important to hear from practitioners and,
excuse me for saying it, they are not here because they are fed
up with waiting for the IETF.

> To be clear, a use case is not "I want it because I think it
> would be nice."   It's "Router Advertisements don't work for
> me for the following specific reason in my actual
> deployment."
> 
> The fact that it is the most requested feature isn't the
> point.   The question is, *why* is it the most requested
> feature?   Is it because people have zero operational
> experience with IPv6, and are just trying to do the same
> thing they did in IPv4, and once you explain RAs to them they
> say "oh, okay" and stop asking for it?   Or is it the case
> that there is some genuine deployment problem that RAs don't
> properly address?

The people on the *real* IPv6 ops list who are asking for this
are not beginners. But they *are* trying to do the same thing
they did for IPv4, for a reason...

<snip>

> I'm also pragmatic.   If we have to make this problem a
> little bit worse to solve some real world problem, fine,
> let's make the problem a little bit worse.   But if we're
> doing it because people think they have to have feature
> parity with DHCPv4, that's just not a good enough reason.

Tomek didn't define a way of assigning use case numbers, so I'll
call this use case #42:

Operators say that they want (approximate) feature parity so
that they can have (approximate) alignment between their
operational procedures for v4 and v6, especially in a dual stack
network. I assert that this is a very good engineering reason,
and it isn't for the IETF to get on its high horse and say that
experienced operators don't know how to manage OPEX.

I don't know whether my final comment belongs on this thread or
the drawbacks thread, but it's clear that a strong constraint on
any DHCPv6 option that overlaps in functionality with RA is that
it must convey exactly the same semantics or a proper superset
of the same semantics. If we do that, DHCPv6 will not undercut
RA and a special algorithm for RA vs DHCPv6 conflict resolution
will not be needed.

   Brian

---

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

> experienced operators don't know how to manage OPEX.

This is the exact use case Tomek cited, and is (some of us think) adequately satisfied by a vendor-specific route option in the BBF and/or 3GPP vendor option spaces.   John was pretty sure that there was no demand for this from Cablelabs, although I'd certainly be interested in hearing other opinions on this question.

The question is whether there is some use case that justifies a general-purpose DHCPv6 option that would wind up being widely deployed and likely used *instead* of RA in some network to which arbitrary nodes might need to connect.

> RA and a special algorithm for RA vs DHCPv6 conflict resolution

It's difficult to see how we could ensure that this was true, since the DHCPv6 server and router might actually be operated by independent entities with no coordination.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2011 16:20:00 +1300

> This is the exact use case Tomek cited, and is (some of us think) adequately satisfied by a vendor-specific route option in the BBF and/or 3GPP vendor option spaces.   John was pretty sure that the…

I didn't read it as the same, and in any case I fail to see how
a solution with some special features for CATV or ADSL or UMTS
can solve the general problem of distributing routing info to
hosts in an arbitary network, very possibly connected by none of
those specific technologies. In any case, three layers of subnet
down from the WAN connection, I hope there will be nothing that
is specific to the tye of WAN connection.

This is not a technology-specfic requirement.

> The question is whether there is some use case that justifies a general-purpose DHCPv6 option that would wind up being widely deployed and likely used *instead* of RA in some network to which arbit…

I don't know how to say it clearer: the use case is any IPv6
network, such as an enterprise network, whose operator *chooses*
to manage it using DHCPv6. It isn't for the IETF to decide for
these operators, and a technology-specific "vendor" option is
not going to solve the general purpose requirement.

> It's difficult to see how we could ensure that this was true, since the DHCPv6 server and router might actually be operated by independent entities with no coordination.

Sorry, I wasn't quite clear then. I mean semantics in the sense
that Dave Thaler raised - two different ways of conveying route
preferences is a Bad Thing. Obvious, in a situation such as a
homenet where you have uncoordinated sources of configuration,
their actual contents may be inconsistent, which is why you need
an overarching method of resolving inconsistency. But we need
that anyway, regardless of RA vs DHCP.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Nov 2011 22:25:43 -0500

> experienced operators don't know how to manage OPEX.

I agree that it's a good engineering reason, but it's not the only factor that should be considered.   A number of things were broken in IPv4, and we'd like to not have those things become permanently a part of the architecture.

On the other hand, second-system effect is arguably one of the factors that has delayed adoption of IPv6.   We need to be aware that change comes with a cost, even if it seems like a change for the better.   That doesn't mean to never make changes, it means consider the cost when considering whether to make a change.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Nov 2011 05:11:05 +0000

On Nov 18, 2011, at 11:20 AM, "Brian E Carpenter" <[email-masked]> wrote:
> those specific technologies.

This is true.   However, since the general problem is already nicely solved by RAs, I don't see how it supports your position.

> not going to solve the general purpose requirement.

It most certainly _is_ up to the IETF to decide whether we will standardize some mechanism for doing this. Of course we can't stop them engineering around us, but I think they would have to be motivated by some use case that RA *really doesn't address* before they'd go to that trouble.   So what's that use case?

---

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

Le 17/11/2011 14:56, Tomek Mrugalski a écrit :
> Hi, There was a meeting between proponents of this option, most vocal
>  forward, specific use cases are needed. If you need this option,
> please describe your use case.

I pick one use-case I am particularly concerned with: router device with
limited memory and CPU MHz connected to low-rate cellular forced into
using both DHCP and RA software.  It would better use only one software
implementation (not 2), and do a short exchanges of messages (4 messages
instead of 6) to obtain: default route, prefix, address, DNS server.

In this sense, it would be advantageous if DHCP provided a default route
and optionally with a MAC address.

Other use-cases relate to Mobile Routers in vehicular environments, that
one could describe when necessary.

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

I would support a decision where the default route is stripped off of
the route-option draft and where it is given focused consideration in a
single draft.

The reason for this is that default route has a number of particular
characteristics different than a specific (or generic) route: it is
all-zeros prefix 0, its metric in table is typically 1, its lifetime
treatment depends largely on ND, its reliability needs to be properly
ensured by re-requesting coherently with ND, and more.

> To have this list more organized, please assign a number to your
> support voice.

Sorry, please explain?  What number should I assign to my voice?  Do you
want to assign a preference number between:
- vendor-specific option
- document use-cases?

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

I count my voice to count to a lesser degree.

> 1. http://www.ietf.org/mail-archive/web/mif/current/msg01412.html On
> 11-11-16 08:59, Maglione Roberta wrote:
>> 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, [email-masked] wrote:
>> +1
>>
>> 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 --
>>
> 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.
>
> 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).
>
> 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:
> - 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-02 They
> were removed based on MIF WG feedback.
>
> (draft-sarikaya-mif-dhcpv6solution,
> draft-sun-mif-address-policy-dhcp6 and
> draft-dec-dhcpv6-route-option). Present and former authors represent
>  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.

I am not an author of these drafts.  I am a co-author of 
draft-mouton-mif-dhcpv6-drlo-00.

> There is a draft "IPv6 Multihoming without Network Address
> Translation" in v6ops
> (draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03). It
>  Similar support was voiced during adoption of this document in MIF.
> If you are one of those people, please express your support now.
>
> thread regarding flaws and possible dangers of finishing this work,
> with comments from two opponents. Feel free to contribute your
> concerns.
>

Sorry, which issue?  They seem a list of issues?

Alex

>
> Cheers, Tomek Mrugalski ISC
> _______________________________________________ mif mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mif
>

---

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

Le 17/11/2011 21:04, Ted Lemon a écrit :
> On Nov 17, 2011, at 9:57 PM, "Tomek
> Mrugalski"<[email-masked]>  wrote:
>> 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.
>>
>> industry. Voice of people, who express their personal opinions
>> still count, but to a lesser degree.
>
> To be clear, a use case is not "I want it because I think it would be
> nice."   It's "Router Advertisements don't work for me for the
> following specific reason in my actual deployment."

I agree with the clarification.

But don't scare people away with the word "deployment".  Initial
deployments are often just lab settings, a desk, a pocket sometimes.

RA defroutes don't work for me because there may be not enough memory
space next to the DHCP daemon on a 400MHz ARM processor of mobile router.

Would something like this qualify?

> The fact that it is the most requested feature isn't the point. The
> question is, *why* is it the most requested feature?   Is it because
> people have zero operational experience with IPv6, and are just
> trying to do the same thing they did in IPv4, and once you explain
> RAs to them they say "oh, okay" and stop asking for it?

No, it is not this reason for me.  In my particular case I am fully
aware of RAs offering defroute, and aware of DHCPv4 and DHCPv6 Relays.
In my lab setting it is easier to maintain de conf files centrally on a
unique machine rather than on 5-like Access Routers.  I do not have a
std mechanism to remotely update the RA information these Access Routers
offer.  But for DHCP I have this central conf file.

> Or is it the case that there is some genuine deployment problem that
> RAs don't properly address?
>
> The reason why the vendor option solution was proposed is that the
> only use cases that anybody could actually come up with in the
> meeting yesterday were use cases that were specific to particular ISP
> deployment models, and it seemed clear that these use cases could be
> adequately addressed with 3GPP- and BBF-specific extensions. There is
> genuine need in these two cases for this functionality.

I do not work for a vendor.  I don't see why calling the DHCP defroute a
"vendor" option.  On another hand I could agree with it being
EXPERIMENTAL at this point in time.

> The reason why this isn't a no-brainer is that if it were added as a
>  standard IETF solution, it would change what end nodes have to do to
>  get routes, making end node software more complicated, and also more
>  difficult to specify.   As one of the authors of the MIF API
> document, I've had to think a lot about this problem, and I do not
> like having to have two different ways of configuring routes.   The
> MIF problem is hard enough already; adding this to the problem seems
>  to me to make it worse, not better.
>
> I'm also pragmatic.   If we have to make this problem a little bit
> worse to solve some real world problem, fine, let's make the problem
>  a little bit worse.   But if we're doing it because people think
> they have to have feature parity with DHCPv4, that's just not a good
>  enough reason.

In my particular case parity with DHCPv4 is not the need.  I am fully
aware of RA having already implemented a number of features of it.

Yours,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 18 Nov 2011 12:17:32 +0100

Le 18/11/2011 03:21, Ted Lemon a écrit :
> On Nov 18, 2011, at 9:38 AM, "Brian E
> Carpenter"<[email-masked]>  wrote:
>> Operators say that they want (approximate) feature parity so that
>> they can have (approximate) alignment between their operational
>> procedures for v4 and v6, especially in a dual stack network. I
>> assert that this is a very good engineering reason, and it isn't
>> for the IETF to get on its high horse and say that experienced
>> operators don't know how to manage OPEX.
>
> This is the exact use case Tomek cited, and is (some of us think)
> adequately satisfied by a vendor-specific route option in the BBF
> and/or 3GPP vendor option spaces.   John was pretty sure that there
> was no demand for this from Cablelabs, although I'd certainly be
> interested in hearing other opinions on this question.
>
> The question is whether there is some use case that justifies a
> general-purpose DHCPv6 option that would wind up being widely
> deployed and likely used *instead* of RA in some network to which
> arbitrary nodes might need to connect.

MAchine-type router devices do need DHCP software for its prefix 
delegation feature and are forced to use RA for its defroute feature. 
Yet they're constrained devices preferring to send less messages.

Alex

>
>> I don't know whether my final comment belongs on this thread or the
>> drawbacks thread, but it's clear that a strong constraint on any
>> DHCPv6 option that overlaps in functionality with RA is that it
>> must convey exactly the same semantics or a proper superset of the
>> same semantics. If we do that, DHCPv6 will not undercut RA and a
>> special algorithm for RA vs DHCPv6 conflict resolution will not be
>> needed.
>
> It's difficult to see how we could ensure that this was true, since
> the DHCPv6 server and router might actually be operated by
> independent entities with no coordination.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 18 Nov 2011 12:38:06 -0800

Hi,

A new routing and addressing system known as the
Internet Routing Overlay Network (IRON) is available
that (among many other things) supports hosts with
multiple interfaces. IRON (along with its associated
mechanisms VET and SEAL) uses a tunnel virtul interface
to harness the host's ISP interfaces into a "bundle"
that is represented to a server in the Internet. The
tunnel interface assigns a single, stable IP address
that host applications can use regardless of the ISP
connection or connections used to carry traffic.

The server is responsible for representing the host's
stable IP address into the Internet routing system. The
host is responsible for selecting ISP interfaces for
outbound packets, and for providing directions to the
server as to ISP interfaces to use for inbound packets.
Traffic engineering, load balancing, fault tolerance,
asymmetric routing, etc. are all therefore naturally
supported. Mobility and NAT traversal are also naturally
supported. The solution also supports the case of the
host receiving an IP prefix instead of just a singleton
IP address and then beginning to function as a router.

Please see below for the documents and send comments:

http://www.ietf.org/internet-drafts/draft-templin-ironbis-08.txt
http://www.ietf.org/internet-drafts/draft-templin-intarea-vet-31.txt
http://www.ietf.org/internet-drafts/draft-templin-intarea-seal-39.txt

Thanks - Fred
[email-masked]

---

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

> instead of 6) to obtain: default route, prefix, address, DNS server.

Can you tell us more about this device?   I didn't know people made devices this small anymore other than in the distributed sensor network environment (e.g., lowpan).

---

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

> deployments are often just lab settings, a desk, a pocket sometimes.

Sure, but the question is whether you have a real situation where you are forced to use DHCP and not RA, or just a hypothetical situation.

> space next to the DHCP daemon on a 400MHz ARM processor of mobile router.

Huh, I have a 400MHz ARM system that runs a full Linux kernel including DHCPv4 client and RA (which is in the kernel).   It's a Sheeva CPU, so it's a little slow, but I haven't had any problems at all with this: where I've had problems is compiling kernels in reasonable amounts of time.   So I really, really have trouble believing that this device can't do RA.

> offer.  But for DHCP I have this central conf file.

Okay, so why do you want this?   I don't mean to say you shouldn't want it, but can you explain why you want it?

> EXPERIMENTAL at this point in time.

As Lorenzo said in the meeting, if you give it an option code, it will see wide implementation, regardless of whether it's standard, informational or experimental, because lots of people say they want it.   So from an architectural standpoint, we can't punt on the question of whether we need it.

---

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

> Internet Routing Overlay Network (IRON) is available

Correct me if I am wrong, but doesn't this depend on all provisioning domains being in the same administrative domain?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 18 Nov 2011 14:19:39 -0800

Hi Ted, 

> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Friday, November 18, 2011 2:00 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [mif] IRON as a multiple interface solution
> 
> Correct me if I am wrong, but doesn't this depend on all 
> provisioning domains being in the same administrative domain?

If you consider "the Internet" as a singe administrative
domain then, yes, the IRON tunnel virtual interface is
configured over a single administrative domain. So, the
tunnel virtual interface is configured over all of the
host's ISP interfaces.

If the host also connects to a home enterprise network
via a VPN, then that would be a separate administrative
domain and a separate tunnel virtual interface. Does
this help?

Thanks - Fred

---

From: Arifumi Matsumoto <[email-masked]>
Date: Sun, 20 Nov 2011 04:53:35 +0900

Hi,

here are our reasons why we need DHCPv6 route option.

* Relaying function is needed.
  We've already deployed lots of IPv6 edge routers that do not have
  RFC 4191 more specific routes function in them. Upgrading them
  or configuring each of them for each customer may not be possible
  or at least really painful. Central control brought by DHCP relaying
  function is really helpful here.

* Performance problem in aggregating routers.
  Alexandru pointed out the resource limit on user devices. The similar
  situation occurs on the network side, such as aggregation routers.
  As a lot of people pointed out at 6man or v6ops session in Taipei,
  RA consumes a lot of resources on a user device, and also on the
  aggregating routers. If we can use DHCP for delegating prefixes,
  routes, and DNS server addresses, then we can completely move
  to DHCP.

* Host based control is needed.
  When multiple users are on the same link, such as public wifi services,
  we want to deliver information, such as prefix, route, and DNS,
  dependent on the service the user subscribes.
  The user specific route info is needed, because some users just 
  subscribes to walled garden services, and don't need default route.
  Some others subscribes to both Internet access and walled garden
  services.

* Why BBF std doesn't work.
  In one type of access service, we allow directly attaching user's PC
  to the uplink, as well as attaching a router. So, in this case, PCs have
  to support DHCPv6 route, address, DNS options, not just the routers.

Best regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 19 Nov 2011 17:03:56 -0500

> domain and a separate tunnel virtual interface. Does

It does, in that it seems to make it pretty hard to solve the multiple
resolution context problem that the DNS server selection draft is
trying to solve.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Nov 2011 09:17:37 +1300

Please look at the thread "Why not RIO?" starting at
http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006539.html

There are various operational scenarios mentioned in the replies so far
for which RA/RIO does not appear sufficient. In particular see

http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006540.html (1 use case)
http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006545.html (7 use cases)

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Nov 2011 09:20:48 +1300

And this one also describes another use case:

http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006543.html

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Nov 2011 00:17:37 +0000

> http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006543.html

DHCP is actually very poorly suited for many of these cases.  E.g., using it to control access to a captive portal is a terrible idea. These are definitely things you /could/ do with dhcp, if you didn't have RA on your network, and if your devices supported this configuration, but these documents really read as "throw out RA," not "use DHCP," and seem really to be statements of preference, not cases where you can't do it with RA and must have some other solution.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Nov 2011 13:54:34 +1300

Ted,

> DHCP is actually very poorly suited for many of these cases.  E.g., using it to control access to a captive portal is a terrible idea. These are definitely things you /could/ do with dhcp, if you d…

I can't speak for the operators. I'm guessing a few things they might say though, if
you were to answer in this way on the cluenet list.

Where is it documented how to use unicast RA/RIO messages to configure
individual hosts? Including, which products provide some sort of database-driven
mechanism to generate individual RA/RIO (or other) options for a few thousand
hosts, like many sites generate a few thousand DHCP(v4) entries today? Which
off the shelf IPAM (address management) products support RA/RIO? What's the
mechanism for configuring all this host-related data into the individual routers,
especially when a given host (i.e. MAC address) may appear arbitrarily on
any subnet at any time?

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Nov 2011 08:17:21 -0800

Hi Andrew, 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Andrew Sullivan
> Sent: Saturday, November 19, 2011 2:04 PM
> To: [email-masked]

What I was describing was what is sometimes called a
"Split Tunnel" scenario. AFAICT, any solution that
would address that scenario would be applicable also
to IRON, and not in any way made more difficult by IRON.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 Nov 2011 10:19:03 +0100

Le 18/11/2011 22:53, Ted Lemon a écrit :
> On Nov 18, 2011, at 6:37 PM, "Alexandru
> Petrescu"<[email-masked]>  wrote:
>> I pick one use-case I am particularly concerned with: router device
>> with limited memory and CPU MHz connected to low-rate cellular
>> forced into using both DHCP and RA software.  It would better use
>> only one software implementation (not 2), and do a short exchanges
>> of messages (4 messages instead of 6) to obtain: default route,
>> prefix, address, DNS server.
>
> Can you tell us more about this device?   I didn't know people made
> devices this small anymore other than in the distributed sensor
> network environment (e.g., lowpan).

Well, there exist machine-class devices which are that small and don't 
aren't necessarily lowpan ("p" would be replaced by a "w").  For example 
"M2M" devices.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 Nov 2011 10:43:10 +0100

Le 18/11/2011 22:58, Ted Lemon a écrit :
> On Nov 18, 2011, at 7:14 PM, "Alexandru
> Sure, but the question is whether you have a real situation where you
> are forced to use DHCP and not RA, or just a hypothetical situation.
>
>> RA defroutes don't work for me because there may be not enough
>> memory space next to the DHCP daemon on a 400MHz ARM processor of
>> mobile router.
>
> Huh, I have a 400MHz ARM system that runs a full Linux kernel
> including DHCPv4 client and RA (which is in the kernel).   It's a
> Sheeva CPU, so it's a little slow, but I haven't had any problems at
> all with this: where I've had problems is compiling kernels in
> reasonable amounts of time.   So I really, really have trouble
> believing that this device can't do RA.

Sure, a 400MHz device could have large enough memory to hold both DHCP 
and ND implementations.  However, if one tries to reduce the software to 
a bare minimum then one would eliminate as many components as possible - 
and RA vs DHCP is obvious duplicate functionality, double code line 
counts.  This would give place for other necessary components like a 
route exchange software.

When memory is limited there is compromise to be made, and software 
components to be traded off.

>> No, it is not this reason for me.  In my particular case I am
>> fully aware of RAs offering defroute, and aware of DHCPv4 and
>> DHCPv6 Relays. In my lab setting it is easier to maintain de conf
>> files centrally on a unique machine rather than on 5-like Access
>> Routers.  I do not have a std mechanism to remotely update the RA
>> information these Access Routers offer.  But for DHCP I have this
>> central conf file.
>
> Okay, so why do you want this?   I don't mean to say you shouldn't
> want it, but can you explain why you want it?

I emulate a wifi operator network: several Access Routers and a single 
point maintaining the dhcp conf files.  Some AR may offer the Default 
Route of another router on the same link (hence the need to have conf 
files).

Alex

>> I do not work for a vendor.  I don't see why calling the DHCP
>> defroute a "vendor" option.  On another hand I could agree with it
>> being EXPERIMENTAL at this point in time.
>
> As Lorenzo said in the meeting, if you give it an option code, it
> will see wide implementation, regardless of whether it's standard,
> informational or experimental, because lots of people say they want
> it.   So from an architectural standpoint, we can't punt on the
> question of whether we need it.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2011 15:20:45 +0000

On Nov 22, 2011, at 4:19 AM, Alexandru Petrescu wrote:
Well, there exist machine-class devices which are that small and don't aren't necessarily lowpan ("p" would be replaced by a "w").  For example "M2M" devices.

I don't see anything about m2m that precludes implementing RA.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2011 15:25:46 +0000

On Nov 22, 2011, at 4:43 AM, Alexandru Petrescu wrote:
Sure, a 400MHz device could have large enough memory to hold both DHCP and ND implementations.  However, if one tries to reduce the software to a bare minimum then one would eliminate as many components as possible - and RA vs DHCP is obvious duplicate functionality, double code line counts.  This would give place for other necessary components like a route exchange software.

When memory is limited there is compromise to be made, and software components to be traded off.

Look, I'm sorry, but this is just not convincing.  RA is trivial.   DHCPv6 clients are trivial.   If you can't cram both of these into your ARM stack, you are doing something wrong.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 22 Nov 2011 19:02:38 +0100

Le 22/11/2011 16:25, Ted Lemon a écrit :
>> Sure, a 400MHz device could have large enough memory to hold both
>> DHCP and ND implementations. However, if one tries to reduce the
>> software to a bare minimum then one would eliminate as many
>> components as possible - and RA vs DHCP is obvious duplicate
>> functionality, double code line counts. This would give place for
>> other necessary components like a route exchange software.
>>
> Look, I'm sorry, but this is just not convincing. RA is trivial.
> DHCPv6 clients are trivial. If you can't cram both of these into
> your ARM stack, you are doing something wrong.

The similar userland-vs-kernel (read DHCP vs RA) discussion has it that
it is easier to do one not both.

(also relating to your earlier mentioning compiling being lengthy for 
ARM kernel - yes it is quicker to compile userland DHCP than kernel RA).

Alex

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2011 18:33:41 +0000

On Nov 22, 2011, at 1:02 PM, Alexandru Petrescu wrote:
The similar userland-vs-kernel (read DHCP vs RA) discussion has it that
it is easier to do one not both.

Of course it is easier to do one, not both.   But it's no problem to do both.

(also relating to your earlier mentioning compiling being lengthy for ARM kernel - yes it is quicker to compile userland DHCP than kernel RA).

This is easily solved by cross-compiling.

---

From: Hui Deng <[email-masked]>
Date: Fri, 25 Nov 2011 08:47:21 +0800

Hi Fred,

MIF is not proposing any new solution for administative domain to solve
fundamental problem like mobility by harness virtual interface /tunnel at
this moment. Today it is just solveing basic problem existed in multiple
administrative domains.

For DNS selection problem, what I understand is IRON DNS can provide
sub-domain information with only one DNS server, but here is assuming that
there exists two different administrative domain where two different DNS
server may reply different information each.

Regards,

-Hui

2011/11/22 Templin, Fred L <[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 28 Nov 2011 09:22:45 -0800

Hi Hui,

IRON expects that the host will have multiple ISP
connections - each with its own address that is
delegated from within its own administrative domain.
The host will also get a different DNS server for
each ISP connection, yes.

Over each ISP connection, the host should be able to
access services not only in the Internet but also within
the ISP network. I think perhaps the latter are what you
are referring to as "different DNS server may reply
different information" - right?

With IRON, the host registers each of its ISP connections
with a Virtual Service Provider (VSP) network and is
delegated an address from the VSP administrative domain.
The host can then use the VSP-delegated address over any
of its ISP connections via tunneling.

The difference with IRON is that the IRON VSP will always
provide the host with a public IP address, and the IRON
DNS will always provide the host with public IP addresses
of services in the Internet - even if some of those
services are controlled by the VSP. So, the IRON
administrative domain is really "the Internet", and
not an ISP network that may use private addressing
and/or give different answers for DNS name resolutions
than different ISP networks would.

That said, IRON does not preclude the host from accessing
services within the underlying ISP networks. To do so,
however, the host would have to use its ISP-delegated
address(es) and not the VSP-delegated address.

Does this match your understanding?

Thanks - Fred

________________________________

	From: Hui Deng [mailto:[email-masked]] 
	Sent: Thursday, November 24, 2011 4:47 PM
	To: Templin, Fred L
	Cc: Andrew Sullivan; [email-masked]
	Subject: Re: [mif] IRON as a multiple interface solution

	Hi Fred,
	 
	MIF is not proposing any new solution for administative domain to solve fundamental problem like mobility by harness virtual interface /tunnel at this moment. Today it is just solveing basic problem existed in multiple administrative domains.
	 
	For DNS selection problem, what I understand is IRON DNS can provide sub-domain information with only one DNS server, but here is assuming that there exists two different administrative domain where two different DNS server may reply different information each.
	 
	Regards,
	 
	-Hui

		Hi Andrew,

		

		Thanks - Fred

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Nov 2011 13:11:15 -0500

> Does this match your understanding?

The central problem, however, is that if you are looking up the
address for a name, you don't obviously know where it is (i.e. you
don't know what network you need to go to).  What I don't get in the
IRON approach is how you cope with the fact that a user simply types
some name into an application.  We can't hardly ask them which network
they want to use to look up the name.  The MIF approach, as much as it
makes me airsick, does address that issue.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tao Sun <[email-masked]>
Date: Thu, 1 Dec 2011 02:13:22 +0800

Hi All,

Thanks for the discussion. As one of the author of the draft, I would like
to share our view on DHCPv6 used case in three aspects.

*Network management and configuration.

1. It is efficient for the network to configure this in a central DHCPv6
server to do unified routing policy configuration. The gateways (e.g., GGSN
in cellular network) only need to perform DHCPv6 relay.

2. The Option Code in the DHCPv6 Request message can be used as an
indication that the host is MIF capable so that the network need not to do
such configuration to host without MIF feature

**Cellular network

1.       In cellular network, DHCPv6 is used for IPv6 parameter
configuration and RA is used for SLAAC of handset. This is start from 3GPP
release 8 (or earlier).

2.       The network gateway in cellular network (e.g., GGSN) can naturally
support DHCPv6 extension since the gateway acts as a DHCPv6 relay. However,
it is very hard to update those gateways to use RA announcing the route
information.

3.       The handsets with MIF feature need to visit subscribed/operator
provided service. Some traffic is routed to the operator’s network through
3G interface instead of to Internet through WiFi.  DHCPv6 will be used to
configure these specific routes.

You can refer to the following report on more description of MIF use case
in cellular network.

***Broadband network

1.       WiFi network. Some WiFi hotspots provide local services. The route
configuration on RG is needed to direct some traffic to local network while
other traffic to the Internet.

2.       VPN network. When a user connect to enterprise VPN network, the
routing of VPN traffic need to be configured. Due to the large number of
such VPN network, we cannot assume all the VPN network only use RA. DHCPv6
provides another choice which may be preferred by the VPN network.

We summarize the requirements and the use cases as the following: 1) In
view of the DHCPv6 requirements in several fields, vendor-specific options
lead to several segmented definitions. An IETF defined general option is a
better choice. 2) Per user/host configuration makes DHCPv6 be used for the
on-demand configuration. 3) The centralized relay architecture is a widely
used way at present for IPv4 and it will also be used for IPv6. That is
IETF’s responsibility to support such requirement.

Regards,
Tao Sun

On Wed, Nov 23, 2011 at 2:33 AM, Ted Lemon <[email-masked]> wrote:

> (also relating to your earlier mentioning compiling being lengthy for ARM
> kernel - yes it is quicker to compile userland DHCP than kernel RA).
>
>

---

From: Tao Sun <[email-masked]>
Date: Thu, 1 Dec 2011 02:18:00 +0800

Forgot to include a website link in the previous email. Now I included it.

Regards,

Tao Sun

On Thu, Dec 1, 2011 at 2:13 AM, Tao Sun <[email-masked]> wrote:

> 2.       The network gateway in cellular network (e.g., GGSN) can
> naturally support DHCPv6 extension since the gateway acts as a DHCPv6
> relay. However, it is very hard to update those gateways to use RA
> announcing the route information.
>
http://www.3gpp.org/ftp/Specs/html-info/23853.htm

>
>
> ***Broadband network
>
> 1.       WiFi network. Some WiFi hotspots provide local services. The
> route configuration on RG is needed to direct some traffic to local network
> while other traffic to the Internet.
>
>   On Wed, Nov 23, 2011 at 2:33 AM, Ted Lemon <[email-masked]>wrote:
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Nov 2011 10:48:40 -0800

> configure these specific routes.

You can already do this today with RIOs, and I don't see why there need to
be two ways of doing the same thing. Adding a different method to configure
the same information is twice the code and more than twice the complexity,
since when you have two sources of information with different semantics you
need to figure out how to merge them, what happens if they disagree, what
to do if one is wrong, what to do if one expires, and so on.

Also, in the mobile case I don't understand how you would use a different
gateway anyway. The mobile network is a point-to-point link, so there's no
way to distinguish multiple gateways. How would you use this?

> while other traffic to the Internet.

I don't understand why you need host changes to do this. Since the hotspot
router is a router, it can simply forward the packets the right way by
itself.

> provides another choice which may be preferred by the VPN network.

The rationale here seems to be that "if we create a new option, some
networks might use it". That's certainly true, but it doesn't provide a
compelling reason why we need the option in the first place.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Dec 2011 10:30:53 +1300

On 2011-12-01 07:18, Tao Sun wrote:
...

>> better choice. 

To me this is a killer argument. A general solution that is applicable
to all deployment scenarios is vastly better than a free-for all of
vendor options, which will increase the implementation burden for
everybody and reduce the chances of smooth zero-conf operation.

>> 2) Per user/host configuration makes DHCPv6 be used for the
>> on-demand configuration. 

RA/RIO does not meet this requirement, which is a real requirement
in networks with heterogeneous types of host. DHCPv6 does meet this
requirement.

>> 3) The centralized relay architecture is a widely
>> used way at present for IPv4 and it will also be used for IPv6. 

That's the wrong way to say it IMHO. There are sound reasons why
operators want a centralised host management system with distributed
relays. The fact that the solution for IPv4 is called DHCP doesn't
imply that the best solution for IPv6 is called DHCPv6. However, until
there is a well-defined central management system for prefix delegation
and routing options via RA, it seems that DHCPv6 *is* the only available
solution. And then we loop back to point 1): it's better to have a generic
option than a bunch of competing vendor options.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Nov 2011 15:23:28 -0800

> everybody and reduce the chances of smooth zero-conf operation.

Actually, what decreases the implementation burden is not having the option
at all. The use cases I've heard so far for this option are all a bit
specious and I think they are outweighed by the harm that would be caused
if this option were to get into general use.

The reasoning goes something like this:

1. The option is defined.
2. OS foo implements it.
3. Some network, somewhere, decides that they're only going to use DHCPv6
for routing, because they only support OS foo.
4. Other OSes are forced to implement the option because if they don't,
they are at a disadvantage compared to OS foo
5. Once all OSes implement it, some other network, somewhere else, decides
that they're only going to support DHCPv6 for routing because it's easier
and because it matches what they do in IPv4, so they turn off RAs.

Then we have a problem, because DHCPv6 has much less rich semantics than
RAs in the general case. A few examples:

- DHCPv6 is static. A lease is a promise and it can't be deprecated except
by the server that originally made the promise. If that server is not
around any more, or if clients don't support reconfigure, it can't be
deprecated at all. You can work around this with short lease times, but
that creates a scaling problem on the DHCPv6 server, because it's
centralized.
- The way the standards and the clients are written, clients pick one
DHCPv6 advertise and stick to it. So they can't merge multiple sources of
information.
- DHCPv6 does not share fate with routing; in fact, it has no knowledge of
routing.
- The combination of the fact that you can't merge multiple sources of
information and the fact that you can only provide static information means
that you're basically forced to hand out stuff that doesn't change. If
you're using DHCPv6 to set the default router, that basically means you're
forced to use VRRP or NAT if you want any sort of redundancy.

To me, the lack of functionality that will result if we take the path of
least resistance described above far outweighs the benefits of being able
to configure [default] routes and on-link prefixes on a per-host basis. You
can do this in lots of other ways, for example assigning the hosts you want
to treat differently to different VLANs.

> in networks with heterogeneous types of host. DHCPv6 does meet this

You can use selective unicast router advertisements for this if you want.
There's no reason you can't look the RA properties in RADIUS. And of
course, you can put the separate hosts on separate VLANs (which is probably
the right thing to do in general).

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Nov 2011 18:41:53 -0500

+1.

Keith

On Nov 30, 2011, at 6:23 PM, Lorenzo Colitti wrote:

> Actually, what decreases the implementation burden is not having the option at all. The use cases I've heard so far for this option are all a bit specious and I think they are outweighed by the harm that would be caused if this option were to get into general use.
> 
> 3. Some network, somewhere, decides that they're only going to use DHCPv6 for routing, because they only support OS foo.
> 4. Other OSes are forced to implement the option because if they don't, they are at a disadvantage compared to OS foo
> 5. Once all OSes implement it, some other network, somewhere else, decides that they're only going to support DHCPv6 for routing because it's easier and because it matches what they do in IPv4, so they turn off RAs.
> 
> Then we have a problem, because DHCPv6 has much less rich semantics than RAs in the general case. A few examples:
> 
> - DHCPv6 is static. A lease is a promise and it can't be deprecated except by the server that originally made the promise. If that server is not around any more, or if clients don't support reconfigure, it can't be deprecated at all. You can work around this with short lease times, but that creates a scaling problem on the DHCPv6 server, because it's centralized.
> - The way the standards and the clients are written, clients pick one DHCPv6 advertise and stick to it. So they can't merge multiple sources of information.
> - DHCPv6 does not share fate with routing; in fact, it has no knowledge of routing.
> - The combination of the fact that you can't merge multiple sources of information and the fact that you can only provide static information means that you're basically forced to hand out stuff that doesn't change. If you're using DHCPv6 to set the default router, that basically means you're forced to use VRRP or NAT if you want any sort of redundancy.
> 
> To me, the lack of functionality that will result if we take the path of least resistance described above far outweighs the benefits of being able to configure [default] routes and on-link prefixes on a per-host basis. You can do this in lots of other ways, for example assigning the hosts you want to treat differently to different VLANs.