Subject: [mif] Issue: separate specific routes from default routes? draft-ietf-mif-dhcpv6-route-option-04

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

Dear participants in MIF WG,

Currently draft-ietf-mif-dhcpv6-route-option-04 specifies a way for the
DHCPv6 Server to communicate a set of routes to the DHCPv6 Client.  This
covers both specific routes and the particular case of default routes (a
default route is meant when the RT_PREFIX option is absent, or
alternatively by using 128 0 bits as RT_PREFIX).

I think this is an issue.

It's not good to have two different things to achieve the same
functionality.

Second, using default routes in the same option type of specific routes
means that they'd share the same faith - if specific routes are wrongly
configured in the same section of the config file, there is a risk that
the default route is wrongly configured too.  Or, the default route is
something of last resort, so it would be better to have it configured in
a different place, communicated with a different ORO type.

Third, if a single way of configuring default an specific routes with
DHCP then this means that a bigger software implementation would be
needed even for lightweight devices.  Or, lightweight devices only use a
single route - the default route.

I suggest we separate the default route ORO from the specific routes ORO.

I would like to request oppinion from the WG about this.

Yours,

Alex

---

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

> a different place, communicated with a different ORO type.

Operationally it is always better for things to completely fail than to partially fail, because you see the problem immediately.   In the case of a DHCP server configuration problem, it's hard to see why it would be easier to misconfigure a DHCP server when there is a single option than when there are two.

> single route - the default route.

Do you know of any specific devices that have this problem?

> I suggest we separate the default route ORO from the specific routes ORO.

I think this is a good way to solve the problem you have described, but I don't think the problem needs to be solved.   I'd be interested to hear a specific, concrete use case for this.

---

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

Le 27/03/2012 17:42, Ted Lemon a écrit :
>> Second, using default routes in the same option type of specific
>> routes means that they'd share the same faith - if specific routes
>> are wrongly configured in the same section of the config file,
>> there is a risk that the default route is wrongly configured too.
>> Or, the default route is something of last resort, so it would be
>> better to have it configured in a different place, communicated
>> with a different ORO type.
>
> Operationally it is always better for things to completely fail than
> to partially fail, because you see the problem immediately.   In the
> case of a DHCP server configuration problem, it's hard to see why it
> would be easier to misconfigure a DHCP server when there is a single
> option than when there are two.

If there are two options instead of one this encorages the implementer
to dedicate different sections in the dhcpd.conf file, and allocate a
specific keyword for _default_ route.  This is something  that strikes
the eye an makes him/her more cautious about what to put there in that
single place.

The specific routes are too generic and numerous to check one by one.

>> Third, if a single way of configuring default an specific routes
>> with DHCP then this means that a bigger software implementation
>> would be needed even for lightweight devices.  Or, lightweight
>> devices only use a single route - the default route.
>
> I think this is a good way to solve the problem you have described,
> but I don't think the problem needs to be solved.   I'd be
> interested to hear a specific, concrete use case for this.

Hm, use cases.  If I insist is that I believe there are some maybe under
development.

Also, if one simply checks the SDO that needs it one can see it easily.

What do the others think about this issue?

Alex

---

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

> the eye an makes him/her more cautious about what to put there in that

The usability problem you describe here is not a protocol issue, but a user interface issue.   It's entirely possible that if we should decide to use two options, some DHCP implementations will present both options using the same user interface.   So changing the underlying protocol does not address this issue, whether it is a serious issue or not.

Also, pink elephants may evolve in the future.   Such elephants could potentially step on hosts that are attempting to configure routes.   Should the IETF henceforth mandate the presence of a Pink Elephant Considerations section in all drafts?

> Hm, use cases.  If I insist is that I believe there are some maybe under

Okay, so name one.   

> What do the others think about this issue?

I can't speak for them, but I suspect they are wishing we would both shut up about this and work on something useful.

---

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

On 2012-03-28 06:51, Alexandru Petrescu wrote:
...
> What do the others think about this issue?

A default route is simply the route with the shortest prefix
that matches. I don't see any real value in treating it as special
in the route delivery mechanism.

    Brian

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 28 Mar 2012 08:47:43 +0200

> It's not good to have two different things to achieve the same
Agree. There used to be two ways of specifying default route (in -03),
but this capability was removed. The original reason for having two ways
of configuring the issue is well known to you as you suggested it in the
first place. It was an attempt to solve your concerns about sent
information being too big. As we modified prefix encoding to variable
prefix field size option size is no longer a concern.

Unfortunately, I missed one sentence that still suggest that. It will be
removed in -05. Just be clear: sending only NEXT_HOP option without
RT_PREFIX is not longer supported. Each NEXT_HOP MUST have at least one
RT_PREFIX option.

> a different place, communicated with a different ORO type.
That argument is bogus. If your network administrator can't type ::/0,
you should get a new admin. Some implementations may also accept word
"default" in its configuration.

> single route - the default route.
My understanding is that all nodes that claim to be IPv6 compatible,
must support ICMP Redirects, as defined in RFC4861. This implies
required support for more than just a default route.

> I suggest we separate the default route ORO from the specific routes ORO.
You meant option, I assume. ORO (Option Request Option) is for
requesting other options.

Cheers,
Tomek

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Mar 2012 13:24:49 +0200

Le 28/03/2012 08:47, Tomek Mrugalski a écrit :
>> Currently draft-ietf-mif-dhcpv6-route-option-04 specifies a way
>> for the DHCPv6 Server to communicate a set of routes to the DHCPv6
>> Client.  This covers both specific routes and the particular case
>> of default routes (a default route is meant when the RT_PREFIX
>> option is absent, or alternatively by using 128 0 bits as
>> RT_PREFIX).
>>
> Agree. There used to be two ways of specifying default route (in
> -03), but this capability was removed. The original reason for
> having two ways of configuring the issue is well known to you as you
> suggested it in the first place. It was an attempt to solve your
> concerns about sent information being too big. As we modified prefix
> encoding to variable prefix field size option size is no longer a
> concern.
>
> Unfortunately, I missed one sentence that still suggest that. It
> will be removed in -05.

Thanks for the clarification.  I will be following which sentence is to
be removed: the one implying long packets or the one imposing short
packets (i.e. in case of default route, transmit only router's address
and not additional 128 0 bits).

> Just be clear: sending only NEXT_HOP option without RT_PREFIX is not
> longer supported. Each NEXT_HOP MUST have at least one RT_PREFIX
> option.

I will look at the spec when it's written down and wonder whether this
implies long or short packets.

> That argument is bogus. If your network administrator can't type
> ::/0, you should get a new admin. Some implementations may also
> accept word "default" in its configuration.

I tend to agree.

If the conf file says s something like this:

option dhcp6.default-router 2002:c130:13c1:11f::ff 8400 ... ;

then this is good.  As implementer, when I read a spec, I tend to write
a "default-router" token only if the spec has a special type for it.
Otherwise I will write a token with the name "route" if that is what the
spec says.

On another hand if the spec says "route option" then I will write a
"dhcp6.route" token.  It would be more work to parse the route, decide
it's a default.

> required support for more than just a default route.

In a sense yes.  Several people mentioned this and we could discuss
separately.

> requesting other options.

To be more clear.  I meant both, as described below.

There should be an Option Request Option ORO to request a default route,
and another ORO number to request a route.

Also, in the reply, there should be an OPTION_DEFAULT_ROUTER_LIST to
communicate default routes, and a different OPTION number to communicate
the specific routes.

Yours,

Alex

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