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

From: "mif issue tracker" <[email-masked]>
Date: Wed, 01 Aug 2012 21:04:45 -0000

#7: separate specific routes from default routes? draft-ietf-mif-dhcpv6-route-
option-04

 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.

-- 
----------------------------------+--------------------------------
 Reporter:  alexandru.petrescu@…  |      Owner:  Alexandru Petrescu
     Type:  enhancement           |     Status:  new
 Priority:  trivial               |  Milestone:
Component:  dhcpv6-route-option   |    Version:
 Severity:  In WG Last Call       |   Keywords:
----------------------------------+--------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/mif/trac/ticket/7>
mif <http://tools.ietf.org/mif/>

---

From: "mif issue tracker" <[email-masked]>
Date: Wed, 01 Aug 2012 21:09:05 -0000

Changes (by alexandru.petrescu@…):

 * cc: alexandru.petrescu@… (added)

-- 
----------------------------------+---------------------------------
 Reporter:  alexandru.petrescu@…  |       Owner:  Alexandru Petrescu
     Type:  enhancement           |      Status:  new
 Priority:  trivial               |   Milestone:
Component:  dhcpv6-route-option   |     Version:
 Severity:  In WG Last Call       |  Resolution:
 Keywords:                        |
----------------------------------+---------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/mif/trac/ticket/7#comment:1>
mif <http://tools.ietf.org/mif/>

---

From: "mif issue tracker" <[email-masked]>
Date: Wed, 01 Aug 2012 21:23:50 -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.

Ticket URL: <https://trac.tools.ietf.org/wg/mif/trac/ticket/7#comment:2>
mif <http://tools.ietf.org/mif/>

---

From: "mif issue tracker" <[email-masked]>
Date: Wed, 01 Aug 2012 21:24:12 -0000

Comment (by alexandru.petrescu@…):

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

 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.

Ticket URL: <https://trac.tools.ietf.org/wg/mif/trac/ticket/7#comment:3>
mif <http://tools.ietf.org/mif/>

---

From: "mif issue tracker" <[email-masked]>
Date: Wed, 01 Aug 2012 21:24:28 -0000

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

Ticket URL: <https://trac.tools.ietf.org/wg/mif/trac/ticket/7#comment:4>
mif <http://tools.ietf.org/mif/>

---

From: "mif issue tracker" <[email-masked]>
Date: Wed, 01 Aug 2012 21:24:37 -0000

On 12-03-27 13:56, Alexandru Petrescu wrote:
 > Dear participants in MIF WG,
 >
 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
 _______________________________________________
 mif mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/mif

Ticket URL: <http://trac.tools.ietf.org/wg/mif/trac/ticket/7#comment:5>
mif <http://tools.ietf.org/mif/>