Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 12 Mar 2012 18:16:17 +0100

Le 24/02/2012 11:38, Tomek Mrugalski a écrit :
[...]
> - DHCP vs RA conflict. Previously it was proposed that generally
> DHCP should override RA. That is no longer the case. DHCP option
> format was updated to closer follow RA format.

But still RA uses 16bit lifetimes for default routes whereas this draft
uses 32bit lifetimes, right?

Alex

> Although on-wire representation is different, conveyed information is
> mostly the same. From a host perspective, route information received
> over DHCP may be processed as if yet another RA was received.
>
> - There were several alternative solutions proposed, like RA used in
> stateful manner or segregate hosts to different VLANs. I tried to
> explain, why those proposals wouldn't work or are not desirable.
>
> Motivation and uses cases are now significant part of this draft
> itself. If the group believes that it would be cleaner, it may be
> split into separate draft. But please, don't use this possibility as
> a way to delay this work. There are many networks that want this
> option deployed asap.
>
> Please comment.
>
> Cheers, Tomek _______________________________________________ mif
> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/mif
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Mar 2012 17:23:41 +0000

On Mar 12, 2012, at 1:16 PM, Alexandru Petrescu <[email-masked]<mailto:[email-masked]>> wrote:
But still RA uses 16bit lifetimes for default routes whereas this draft
uses 32bit lifetimes, right?

Since the 16-bit lifetimes can be represented as 32-bit lifetimes, I don't think it's an issue.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Mar 2012 13:27:59 +0100

Le 12/03/2012 18:23, Ted Lemon a écrit :
> On Mar 12, 2012, at 1:16 PM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>> But still RA uses 16bit lifetimes for default routes whereas this
>> draft uses 32bit lifetimes, right?
>

It may be an issue if DHCP Server sends a 32bit lifetime of a default
route and the Client stores this in its ND default router list
structures lifetime 16bit, no?

Alex

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Mar 2012 19:10:08 +0000

On Mar 15, 2012, at 8:27 AM, Alexandru Petrescu <[email-masked]<mailto:[email-masked]>> wrote:
It may be an issue if DHCP Server sends a 32bit lifetime of a default
route and the Client stores this in its ND default router list
structures lifetime 16bit, no?

I think this is a non-problem.   The RA lifetime may be represented as a 16-bit offset in transit, but when it is stored in a table on the node, the node has to know when the lifetime ends, not how long it is.   So the implementation must necessarily convert the 16-bit offset to something like a time_t, which is either 32 or 64 bits, and represents an absolute time, not a relative time.

Consequently, there will be no problem with receiving a 32-bit offset from the DHCP server, other than that if the sum of the current absolute time and offset overflows, the implementation needs to truncate the result to the maximum time value.   This same behavior is necessary for 16-bit offsets; it's just that the range of dates during which it might occur is smaller.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Mar 2012 16:56:01 +0100

Le 15/03/2012 20:10, Ted Lemon a écrit :
> On Mar 15, 2012, at 8:27 AM, Alexandru Petrescu
>> It may be an issue if DHCP Server sends a 32bit lifetime of a
>> default route and the Client stores this in its ND default router
>> list structures lifetime 16bit, no?
>
> I think this is a non-problem. The RA lifetime may be represented as
> a 16-bit offset in transit, but when it is stored in a table on the
> node, the node has to know when the lifetime ends, not how long it
> is.

I guess in some cases yes, and others no.

Not all plaforms benefit from the typical timer implementation as a
PC-class monolithic kernel offers.

> So the implementation must necessarily convert the 16-bit offset to
> something like a time_t, which is either 32 or 64 bits, and
> represents an absolute time, not a relative time.

Again depends on the implementaiton.  Then all time is relative to
something anyways, be it 1970 earlier or later.

> Consequently, there will be no problem with receiving a 32-bit
> offset from the DHCP server, other than that if the sum of the
> current absolute time and offset overflows, the implementation needs
> to truncate the result to the maximum time value. This same behavior
> is necessary for 16-bit offsets; it's just that the range of dates
> during which it might occur is smaller.

SO there would _be_ a conversion needed, right?  This may need to be
specified.  Wouldn't be easier to specify that both lifetimes (from ND
and from DHCP) are represented in the same manner, thus no conversion?

Alex

---

From: Erik Kline <[email-masked]>
Date: Mon, 26 Mar 2012 03:31:31 +0900

>> a way to delay this work. There are many networks that want this

With respect to motivations...I think we need to weed out all the
specious ones first, to what's really left and worthy of interest.
IMHO, most, if not all, are specious.  (And I suspect that Suresh's
Line-ID may be useful to address whatever else is left.)

[3.1-1]

"and the Service Provide would like to avoid routing on the CPE, there
is a need to provision static route entries on RGs/CPEs"

I read this as "we don't want to do routing so here's how we're going
to do routing".  If it's dynamic versus static, then saying that might
be more clear.

[3.1-2]

Is there an external source for this claim?  It is not at all the case
for the two large IPv6 deployments with which I've been directly
involved. Furthermore, the current deployments to O(millions) of
existing IPv6 users make it seem like this isn't actually an issue.

[3.1-4]

Perhaps this has been discussed elsewhere, and I'm out of my depth,
but I thought DHCPv6 wasn't really spec'd until R10, and even then
only DHCPv6-PD.

It looks to me like the 3GPP link goes to a draft for R11.
Additionally, this 3GPP draft seems to reference this MIF draft.  This
makes it look like the references are circular (you can't cite IDs),
which is a bad justification.

[3.1-6]

The thing about these walled-garden arguments is that they seem to
imply that deployments don't want to give a route to a walled-garden
network to non-customers.  But surely the existence of a route is not
alone sufficient for valid access?

IOW, is there harm if a non-customer has a route a walled-garden
network of which they are not a customer?  Unless the walled-garden is
advertising a default route, I wonder what the real harm is.

But a potentially more important consideration is why walled garden
arguments appear anywhere within a Motivation section.  Quoting from
the IAB in 2000, section 4.2.1 of RFC3002
(http://tools.ietf.org/html/rfc3002#section-4.2):

"""
   It was strongly recommended that independent of the ubiquity of the
   "walled garden" deployment scenario that protocols and architectural
   decisions should not target this model.  To continue the success of
   Internet protocols at operating across a highly diverse and
   heterogeneous environment the IETF must continue to foster the
   adoption of an "open model".  IETF protocol design must address
   seamless, secure, and scalable access.
"""

In the spirit of the above, I would like to see all discussion
pertaining to walled gardens unequivocally removed. This removes at
least use cases 1, 6, and 8.

[3.1-7]

Do you have any metrics on the support situation WRT 4191?  Both
DHCPv6 and RIOs are SHOULDs in the IPv6 Node Requirements RFC (6434),
and both are pretty old by now (from 2005?).

[3.1-10]

s/home network with/home networks/, I think

I think the "solve the rogue RA problem" is not a valid argument.
You're just trading a rogue RA problem for a rogue DHCPv6 server
problem.  You can claim some security association with the DHCPv6
server, but you can equally claim some security association with the
router(s) (e.g., SEND).

Also, I think this is specious:

    "forced to run two protocols increasing complexity and
troubleshooting, where we have proof of concept in IPv4 that only one
protocol (DHCP) should be needed."

In networks where you want run reliable IPv4, you still need 2
protocols: DHCPv4 and VRRP.  Just because they're operated by two
different groups doesn't mean you don't need them both.

[3.1-11]

If this is a use case that is not "investigated further" then I would
question why it's needed at all in what is fundamentally a
"Motivation" discussion.  It also seems circular to propose as a
motivation that the option be used to break a tie when the option is
coexisting with RAs.

[3.1-12]

I'm not sure that a "different failure mode" is much of a motivation.

I would take exception with a claim like a "rogue DHCP server will
cause no immediate harm".  If someone gives me different DNS servers
they can still hijack all my traffic.  Only in this case I think it's
even worse: I am aware of no provision in DHCP for the real server to
send out messages that can nullify the bad information.  Once a host
is misconfigured that's pretty much it until the lease lifetime is up
or a network change event happens.

[3.1-concluding paragraphs]

I disagree with the assertion "It is better to have a generic option
then [sic] a bunch of competing vendor options".  *IF* the decision of
the IETF is that this constitutes a "You're Doing It Wrong (TM)"
situation, then NO, a standardized option is not better; it would in
fact send the opposite message.  Also, like Microsoft's RADIUS
extension for DNS servers, I don't think you would see multiple
competing definitionsーthe first to publish would become the de facto
standard.

Fundamentally, I think the core issue to be decided is whether there
should be a standardized way for hosts on the same network to learn
different routes from their neighbors.  I would think this constitutes
a fundamental architectural change, and therefore ought to be
considered in 6man (regardless of history and charters).

---

From: Tao Sun <[email-masked]>
Date: Mon, 26 Mar 2012 20:22:56 +0800

Hi Erik,

Thanks for the review. I would like to clarify for your comments on [3.1-4].

The link to 3GPP TR23.853 is a technical report for a R11 work item. The
work item is not finished due to time limits of R11 in 3GPP.

You may see that there are 3 scenarios agreed and documented in the TR.
This draft refers the TR for the *Scenario* justification. On the *solution
mechanism*, the TR listed some related work which includes this draft.

The references are not circular since they are from different aspects.

Regards,

Tao

On Mon, Mar 26, 2012 at 2:31 AM, Erik Kline <[email-masked]> wrote:

>  _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Erik Kline <[email-masked]>
Date: Tue, 27 Mar 2012 08:50:15 +0000

> The references are not circular since they are from different aspects.

For me personally that still sounds circular, though more like it's
trying to claim it's not based solely on a technicality.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Mar 2012 13:29:00 +0200

Le 16/03/2012 18:23, Ted Lemon a écrit :
> On Mar 16, 2012, at 11:56 AM, Alexandru
> Petrescu<[email-masked]>  wrote:
>> Not all plaforms benefit from the typical timer implementation as
>> a PC-class monolithic kernel offers.
>
> Platforms that cannot determine that time has passed won't be able to
> know that a prefix is deprecated, or no longer valid, correct.
>
>> SO there would _be_ a conversion needed, right?  This may need to
>> be specified.  Wouldn't be easier to specify that both lifetimes
>> (from ND and from DHCP) are represented in the same manner, thus no
>> conversion?
>
> The point is that neither the DHCP time nor the RA time is in the
> form needed to notice when a prefix has stopped being preferred, or
> has become invalid.   So in both cases, a conversion to absolute time
> will be necessary.   There is simply no way in which we can make the
> implementor's life easier by having the DHCP offset be 16 bits.

Well maybe there is.

A conversion in absolute time may indeed be necessary, provided systems
keep same time, that being another matter.

But the other conversion - between DHCP's way of representing lifetime
and ND's way of same could be avoided, simply by representing them in
the same manner (16bit length as ND does).  A single unique C function
could be used the same to convert the lifetime field from a DHCP message
to absolute time, and fro, ND message field to absolute time.  Otherwise
one would have to write two functions.

I find it strange that you oppose such an obvious thing to do -
represent lifetimes in the same manner across protocols.

What is the reason of _not_ representing lifetimes in the same manner
across protocols?  We do represent Types and other things in the same
manner, why not lifetimes?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Mar 2012 13:47:29 +0200

Le 25/03/2012 20:31, Erik Kline a écrit :
>>>  itself. If the group believes that it would be cleaner, it may
>>> be split into separate draft. But please, don't use this
>>> possibility as a way to delay this work. There are many networks
>>> that want this option deployed asap.
>
> "and the Service Provide would like to avoid routing on the CPE,
> there is a need to provision static route entries on RGs/CPEs"
>
> to do routing".  If it's dynamic versus static, then saying that
> might be more clear.
>
> [3.1-2]
>
> Is there an external source for this claim?  It is not at all the
> case for the two large IPv6 deployments with which I've been directly
>  network to non-customers.  But surely the existence of a route is
> not alone sufficient for valid access?
>
> network of which they are not a customer?  Unless the walled-garden
> is advertising a default route, I wonder what the real harm is.

Allow me to take advantage of this conversation to mention that this
brings up another issue.

When setting up routes one would like to make sure they're right and
they lead somewhere at least most of the time.  At the smart end node
and dumb network, there should always exist a fallback and that fallback
is typically the default route ("when everything else fails").

In this sense, if the end node sets up its routes with DHCP, it would
like to be sure they're right most of the time, otherwise use the
default route.

But when the default route _and_ the other more specific routes are
provided by DHCP, and if failing, then there is a risk of misconfiguration.

Something that could be done about this is the use of different Types in
DHCP (ORO) for specific routes and a different Type for default routes.
  This would mean not only that the config file owuld have different
sections for default routes vs specific routes (thus guide  the Server's
administrator to double check the default part) but also the DHCP Client
implementation to have separate software sections for specific routes vs
default routes.  Some lighter DHCP Clients may choose to implement
_only_ the default route option part (and not the specific route part).

With respect to this there was also a question about compliance with
specs - if a stack doesn implement eg ICMP Redirect then it's not
compliant.  Do we want to ensure the same level of strength in
compliance with DHCP?   Even for low end devices?

Alex

> """ It was strongly recommended that independent of the ubiquity of
> the "walled garden" deployment scenario that protocols and
> architectural decisions should not target this model.  To continue
> the success of Internet protocols at operating across a highly
> diverse and heterogeneous environment the IETF must continue to
> foster the adoption of an "open model".  IETF protocol design must
> address seamless, secure, and scalable access. """
>
>  they can still hijack all my traffic.  Only in this case I think
> it's even worse: I am aware of no provision in DHCP for the real
> server to send out messages that can nullify the bad information.
> Once a host is misconfigured that's pretty much it until the lease
> lifetime is up or a network change event happens.
>
>  then [sic] a bunch of competing vendor options".  *IF* the decision
> of the IETF is that this constitutes a "You're Doing It Wrong (TM)"
>  different routes from their neighbors.  I would think this
> constitutes a fundamental architectural change, and therefore ought
> to be considered in 6man (regardless of history and charters).
>

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 27 Mar 2012 14:05:54 +0200

> provided by DHCP, and if failing, then there is a risk of misconfiguration.

yes and no.  ipv6 stack is pretty good in actively tracking if routers are up. 

in fact, having the default route or not does not change the basic issue, which is, to me, a trust issue.

say for example that you have two different types as you suggest: one for more specific routes and one for default route.
well, if the dhcpv6 server sends you a specific route such as 2000::/3, it is almost a default route, and moreover, it will be preferred over the (good,appropriate) default routes. 
Therefore, a specific type does not help the problem.

So your proposal does not help the root issue which is, to me, does the node trust the dhcpv6 server for routes insertions.

Marc.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Mar 2012 14:38:23 +0200

Le 27/03/2012 14:05, Marc Blanchet a écrit :
>> When setting up routes one would like to make sure they're right
>> and they lead somewhere at least most of the time. At the smart end
>> node and dumb network, there should always exist a fallback and
>> that fallback is typically the default route ("when everything else
>> fails").
>>
>> In this sense, if the end node sets up its routes with DHCP, it
>> would like to be sure they're right most of the time, otherwise use
>> the default route.
>>
>> But when the default route _and_ the other more specific routes
>> are provided by DHCP, and if failing, then there is a risk of
>> misconfiguration.
>
> say for example that you have two different types as you suggest: one
>  for more specific routes and one for default route. well, if the
> dhcpv6 server sends you a specific route such as 2000::/3, it is
> almost a default route, and moreover, it will be preferred over the
> (good,appropriate) default routes.

We could specify the specific routes part to MUST NOT send 2000::/3 as
route.  Would this solve that?

> So your proposal does not help the root issue which is, to me, does
> the node trust the dhcpv6 server for routes insertions.

In a sense yes.  But this seems to me you mention a security (trust)
issue, not necessarily a misconfiguration.

I think protocol specification may guide the way the dhcpd.conf is
written and, if there are different types for specific routes vs default
routes, then there could be different sections in that file as well,
helping a bit to set aside the default routes.

Alex

>
> Marc.
>
>
>>
>> Something that could be done about this is the use of different
>> Types in DHCP (ORO) for specific routes and a different Type for
>> default routes. This would mean not only that the config file owuld
>> have different sections for default routes vs specific routes (thus
>> guide the Server's administrator to double check the default part)
>> but also the DHCP Client implementation to have separate software
>> sections for specific routes vs default routes. Some lighter DHCP
>> Clients may choose to implement _only_ the default route option
>> part (and not the specific route part).
>>
>> With respect to this there was also a question about compliance
>> with specs - if a stack doesn implement eg ICMP Redirect then it's
>> not compliant. Do we want to ensure the same level of strength in
>> _______________________________________________ mif mailing list
>> [email-masked] <mailto:[email-masked]>

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 27 Mar 2012 15:17:53 +0200

> route.  Would this solve that?

no. what about 2000::/4, 2000::/5 … 

Marc.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Mar 2012 15:32:47 +0200

Le 27/03/2012 15:17, Marc Blanchet a écrit :
>>>> When setting up routes one would like to make sure they're
>>>> right and they lead somewhere at least most of the time. At the
>>>> smart end node and dumb network, there should always exist a
>>>> fallback and that fallback is typically the default route
>>>> ("when everything else fails").
>>>>
>>>> In this sense, if the end node sets up its routes with DHCP,
>>>> it would like to be sure they're right most of the time,
>>>> otherwise use the default route.
>>>>
>>>> But when the default route _and_ the other more specific
>>>> routes are provided by DHCP, and if failing, then there is a
>>>> risk of misconfiguration.
>>>
>>> in fact, having the default route or not does not change the
>>> basic issue, which is, to me, a trust issue.
>>>
>>> say for example that you have two different types as you suggest:
>>> one for more specific routes and one for default route. well, if
>>> the dhcpv6 server sends you a specific route such as 2000::/3, it
>>> is almost a default route, and moreover, it will be preferred
>>> over the (good,appropriate) default routes.
>>
>> We could specify the specific routes part to MUST NOT send 2000::/3
>> as route.  Would this solve that?
>

Well, one one hand there should exist a means to write English
about 4, 5 ... 128 prefix lengths.

On another hand, the RFCs say that only ::/0 is a default route, so we
may care more about this.

No?

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 27 Mar 2012 17:43:43 +0200

On Fri, Feb 24, 2012 at 19:38, Tomek Mrugalski wrote:
>
> >       Title           : DHCPv6 Route Options
> >       Author(s)       : Wojciech Dec
> >                         Tomasz Mrugalski
> >                         Tao Sun
> >                         Behcet Sarikaya
> >       Filename        : draft-ietf-mif-dhcpv6-route-option-04.txt
> >       Pages           : 22
> >       Date            : 2012-02-24
>

[CCing a few of the folks we had a chat with about this in Taipei]

Hi,

I believe this document is not appropriate to be discussed in this working
group, for two reasons:

1. It has almost nothing to do with multiple interfaces. Section 2 contains
text on why this document applies to "multi-homed scenarios". However,
there is nothing in this option that makes it any more applicable to a
multi-homed scenario than to a single-homed scenario.

At least 11 out of the 14 use cases cited (#1, #2, #3, #5, #6, #7, #10,#11,
#12, #13, and #14) are equally applicable to hosts with only one interface.

Further: a host needs to obtain routing information in both single and
multi-homed scenarios, and how the information is obtained (DHCPv6, RA,
HTTP, carrier pigeon) is completely orthogonal to whether the host has one
or more interfaces.

2. This option provides a complete replacement for the ND functionality
specified by RFC 4862 and RFC 4191, including default routes, more-specific
routes, and on-link determination. This is all in 6man's domain. So this
option should be taken to 6man.

I have a number other issues with the document as well. The use cases do
not seem particularly convincing; it seems to me that some of them are
niche use cases, some are circular arguments, and some are specious. The
long-term implications of configuring routing via DHCP, which is a static
protocol mediated by servers and suited to making promises, instead of
using dynamic information originated by routers, does not seem to be worth
it.

But most importantly this document should be moved to 6man so that the
people who are responsible for the architecture can see it, comment on it,
and possibly reach consensus on it.

Regards,
Lorenzo

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Mar 2012 15:52:14 +0000

> manner, why not lifetimes?

2^16 seconds is 18 hours.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Mar 2012 19:54:49 +0200

Le 27/03/2012 17:52, Ted Lemon a écrit :
>> What is the reason of _not_ representing lifetimes in the same
>> manner across protocols?  We do represent Types and other things in
>> the same manner, why not lifetimes?
>

You seem to be saying that is too short?  I believe it is way too long
for a device that moves constantly.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Mar 2012 20:20:24 +0200

Lorenzo,

Let me take advantage of this.

With respect to the main point you make about dealing with the draft in
6man rather than mif - to me as a commenter it makes no difference as
long as it is in the Internet Area, the expertise be there, and the WG
works by rules typical in that area.  If 6man has cycles to take on this
then why not.

Some spare comments inserted below.

Le 27/03/2012 17:43, Lorenzo Colitti a écrit :
>> Title           : DHCPv6 Route Options Author(s)       : Wojciech
>> Dec Tomasz Mrugalski Tao Sun Behcet Sarikaya Filename        :
>> draft-ietf-mif-dhcpv6-route-option-04.txt Pages           : 22 Date
>> : 2012-02-24
>
>
> I believe this document is not appropriate to be discussed in this
> working group, for two reasons:
>
> 1. It has almost nothing to do with multiple interfaces. Section 2
> contains text on why this document applies to "multi-homed
> scenarios". However, there is nothing in this option that makes it
> any more applicable to a multi-homed scenario than to a single-homed
>  scenario.
>
> At least 11 out of the 14 use cases cited (#1, #2, #3, #5, #6, #7,
> #10,#11, #12, #13, and #14) are equally applicable to hosts with only
> one interface.
>
> Further: a host needs to obtain routing information in both single
> and multi-homed scenarios, and how the information is obtained
> (DHCPv6, RA, HTTP, carrier pigeon) is completely orthogonal to
> whether the host has one or more interfaces.

In a sense I agree.  Moreover, the same would be the case for a router
as well.

> 2. This option provides a complete replacement for the ND
> functionality specified by RFC 4862 and RFC 4191, including default
> routes, more-specific routes, and on-link determination. This is all
>  in 6man's domain. So this option should be taken to 6man.

Well not quite a complete replacement.  There still are a number of RA
parameters absent from DHCP.  MTU comes to mind but there are more when
one considers the huge list of parameters and Flags in RA extensions
used in other protocols.

> I have a number other issues with the document as well. The use cases
> do not seem particularly convincing; it seems to me that some of them
> are niche use cases, some are circular arguments, and some are
> specious. The long-term implications of configuring routing via DHCP,
> which is a static protocol mediated by servers and suited to making
> promises, instead of using dynamic information originated by routers,
> does not seem to be worth it.
>
> But most importantly this document should be moved to 6man so that
> the people who are responsible for the architecture can see it,
> comment on it, and possibly reach consensus on it.

In the past 30 oct 2011 the document was ran through 6man by Chairs
asking for review.  IIRC, one comment was on who supersedes whom (ND or
DHCP) with respect to aspects like default route.  I believe that
comment was addressed by Authors in next versions (old versions said
DHCP supersedes, new versions give advice close to what 6man wanted) -
did that new version satisfy 6man commenters?

Also, if more comments can come from 6man, I think it would be a good
idea to run it again through it.

Moving to 6man - do you mean having a Charter item in it?  New
presentations in subsequent meetings?  Similar?

Alex

> Regards, Lorenzo
> [email-masked] https://www.ietf.org/mailman/listinfo/mif

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Mar 2012 20:34:12 +0000

> for a device that moves constantly.

No, for a device that moves constantly, depending on route lifetimes to expire will result in unhappy eyeballs.   For such devices, a route might as well not have an expiry time, unless it is soon, because network transition events will invalidate the route before its lifetime expires.

But of course there are devices that do not move constantly; for such devices, route lifetimes longer than 18 hours are reasonable, and should be supported.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2012 11:07:53 +1300

On 2012-03-28 04:43, Lorenzo Colitti wrote:
...
> and possibly reach consensus on it.

On balance I agree. MIF is a potential *customer* for this mechanism, and
the same applies to homenet and probably others.

    Brian

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 28 Mar 2012 19:22:57 +0200

I have seen a reasonable number of sites that have multiple clients on
the same wire (one broadcast domain) who want to be able to
differentiate those clients into different groups, with different
configurations.

This may be for different classes of services, billing to different
departments, different security zones, etc. but they want to be able to
have different prefixes and different routes based on this. While we can
argue that using IP address as a way of differentiating is error prone,
it does work well for a number of companies.

This is not to avoid using an RA. However, an RA can't give different
answers to different clients on the same wire, nor do I think it
should. Current RA design is still clean and simple and we should try to
keep it that way.

DHCP is designed to handle lots of complex configuration information,
with a broad range of different clients having different needs, so it
seems much more appropriate to have DHCP be able to hand out these
configurations, including a default route.

As to whether or not this draft should be in the mif WG, I have been
away from the IETF process long enough that I am not as clear on
standard protocol. I do agree that being able to have different clients
have different answers for default route would be useful to more than
multi-interface hosts (single interface, homenet, etc.). But this draft
seems to have been in mif for quite a while. It does seem that suddenly
changing its working group now is a bit odd; I'd be inclined to keep it
here just so we can keep the draft moving.