Subject: [dhcwg] I-D draft-ietf-mif-dhcpv6-route-option-03 published

From: Tomasz Mrugalski <[email-masked]>
Date: Sun, 11 Sep 2011 00:42:07 +0200

On 11.09.2011 00:03, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Multiple Interfaces
> Working Group of the IETF.
> 
> 	Title           : DHCPv6 Route Options
> 	Author(s)       : Wojciech Dec
>                           Tomasz Mrugalski
>                           Tao Sun
>                           Behcet Sarikaya
> 	Filename        : draft-ietf-mif-dhcpv6-route-option-03.txt
> 	Pages           : 14
> 	Date            : 2011-09-10
> 
> This document describes DHCPv6 Route Options for provisioning IPv6 
> routes on DHCPv6 client nodes.  This is expected to improve the 
> ability of an operator to configure and influence a nodes&#39;
> ability to pick an appropriate route to a destination when this node
> is multi- homed and where other means of route configuration may be 
> impractical.
Dear MIF and DHC groups,

This draft was presented in DHC WG in Quebec. While the primary area of
review was from DHCP protocol perspective, there were quite a few
insightful comments received related to other aspects. I was also
presented again in MIF WG.

After a long discussion we reached consensus and solved concerns raised
during review by Routing Directorate.

Authors would like to thank Joel Halpern, Marcin Siodelski and Alexandru
Petrescu for their insightful comments and through review.

Significant changes since -03 version:
- added a route lifetime field. This provides a way to age and expire a
route
- route lifetime can be used to revoke a route during renewal
- IA_RT prefix removed. It was only a container option, so this removal
does not change the way this option works
- clarified that default route may be configured with this mechanism
- provided a way to configure default route in bandwidth-constrained
networks
- clarified that this mechanism may be used on routers (e.g. residential
gateways)
- added a way to configure on-link routes
- added a limitation section pointing out that using this mechanism in
networks that do dynamic routing is usually a bad idea

The only comment that we chose not to implement is a suggestion to
include MAC address information. We believe that would be wrong for
number of reasons. If reviewers still thinks this is useful, we would
like to point out a possible solution. As proposed options are designed
to be extensible, reviewers who proposed adding MAC address can simply
define a suboption that will provide necessary information in cases,
where such information cannot be obtained in the usual way. Such
approach is also better, because in most cases this information is not
needed and may even be harmful. This kind of information should be
requested only in those limited cases, where it is really needed. If
proponents choose to define such extensions, our belief is that extra
explanation why such information is needed would be very useful to
understand their use case.

There are no outstanding issues with this draft. This draft has been
reviewed by Routing Directorate, by DHC WG and was presented several
times in MIF meetings and in DHC meeting. As one of the authors (and I
believe I speak on behalf of all authors) I think this draft is ready
for last call. Therefore I would like to ask MIF chairs to announce WGLC.

Of course any additional comments are more than welcome.

Cheers,
Tomek Mrugalski

---

From: maximilien mouton <[email-masked]>
Date: Sun, 11 Sep 2011 12:36:58 +0200

Hello Tomasz and MIF wg,

I am pleased to see that you took in account our previous comments with 
Alexandru.

But reading this new version of your draft I still think a default route 
should be seen as a special route and thus not treated the same way than 
others.

Default route is an information taking part of what I call the "survival 
kit" for Internet i.e. the 3-tuple of IP address, DNS server address and 
default router address which is the minimum requirement for a client to 
access to Internet. This is why I think the default router configuration 
should have its own DHCPv6 option like default router list option 
described in 
http://tools.ietf.org/search/draft-mouton-mif-dhcpv6-drlo-00 (draft-mouton).

I thus think that a client should be able to require only a default 
route (and no other route). The problem with the options defined in your 
draft is that a client who wants to configure only a default route must 
include NEXT_HOP and RT_PREFIX options in ORO.
In this case the client will obtain unnecessary route information 
because the server will send back all route information it has in 
NEXT_HOP and RT_PREFIX options.

This is why I think the options described in your draft should not allow 
server to provide default router information.

I also think it could be good to share this discussion with dhcwg 
because it covers not only mif scenarios.

Maximilien

Le 11/09/2011 00:42, Tomasz Mrugalski a écrit :
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Simon Perreault <[email-masked]>
Date: Mon, 12 Sep 2011 09:12:27 -0400

On 2011-09-11 06:36, maximilien mouton wrote:
> route (and no other route).

Why? What's the use case?

Are you working with hosts that do not have a generic routing table and
only support a single default route?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 12 Sep 2011 15:56:35 +0200

Tomasz,

Thank you for this update.  I am happy our earlier email and f2f
discussion is taken into account.  Thanks.

I have some remarks though.

I wonder whether it is necessary to treat of default routes in
draft-ietf-mif-dhcpv6-route-option.  Remark: I do not oppose the use of
default routes in DHCPv6, but question the best place to do it.

Other remarks below.

> On 11.09.2011 00:03, [email-masked] wrote:
[...]
> Dear MIF and DHC groups,
>
> This draft was presented in DHC WG in Quebec. While the primary area
>  of review was from DHCP protocol perspective, there were quite a
> few insightful comments received related to other aspects. I was also

Thanks for the presentations that we have followed carefully.

> After a long discussion we reached consensus and solved concerns
> raised during review by Routing Directorate.
>
> Authors would like to thank Joel Halpern, Marcin Siodelski and
> Alexandru Petrescu for their insightful comments and through review.

I am interested about the review from the Routing Directorate - is it
public somewhere?

> Significant changes since -03 version: - added a route lifetime
> field. This provides a way to age and expire a route

Yes, lifetime is needed for default route, because the default route
needs to sit in the ND "default router list" structure, structure
described in RFC4861, pp. 34, last par.

> - route lifetime can be used to revoke a route during renewal

"revoke" sounds as if some server revokes the route from the client...
but I believe one means to simply have the Client delete that route, or
simply the route to disappear.  (?)  I agree.

> - IA_RT prefix removed. It was only a container option, so this
> removal does not change the way this option works

Yes, but it is much change in the way the draft is written, and the
implementation as well.

> networks - clarified that this mechanism may be used on routers (e.g.
> residential gateways)

It should be used on more than residential gateways.  The typical use
case is consider is about sensors, machines and cellular smartphones.
But there should be only one way to configure default routes with DHCP,
  I think (and not two different DHCP ways of configuring the default 
route).

> - added a way to configure on-link routes

I think as well that on-link routes ("Connected" routes by Cisco
terminology I believe) are useful for distribution with DHCP.

I would go even further about this, but not necessarily to request
addition in your draft.

There may exist a need to have default routes using prefix ::/0 and
next-hop the particular ::/0 as well (and not a generic IPv6 address
like e.g. 2001:db8::1/128); the only distinction among the default
routes would be the interface name.  The specification could be "a 3GPP
device receiving DHCP Advertise containing the specific
default-route-option needs to insert a routing table entry for the
special default route ::/0 ::/0 interface-name by identifying the
interface on which that Advertise was received".

This need may exist because currently some 3G+ implementations of client
handset (not using DHCP, not IPv6) have default routes of the form
"0.0.0.0 0.0.0.0 hso0"; specifying DHCP to accommodate this kind of
default route is not straightforward, but may be needed.

> - added a limitation section pointing out that using this mechanism
> in networks that do dynamic routing is usually a bad idea

I agree that dynamic routing and DHCP route option may come to be
contradictory.  But the existing recommendation "SHOULD NOT" DHCPv6 &&
rt protocol sounds a bit strong to me...

> number of reasons.

Please explain these reasons.

We believe in the advantage offered by MAC address present in the DHCP
messages - avoids additional NS/NA roundtrips of the Client.

> If reviewers still thinks this is useful, we would like to point out
>  a possible solution. As proposed options are designed to be
> extensible, reviewers who proposed adding MAC address can simply
> approach is also better, because in most cases this information is
> not needed and may even be harmful. This kind of information should
> be requested only in those limited cases, where it is really needed.
>  If proponents choose to define such extensions, our belief is that
> extra explanation why such information is needed would be very useful
> to understand their use case.

I understand.  We would like to add the MAC address in this DHCP
exchange about default route.  But we find it difficult to extend the
existing  draft-ietf-mif-dhcpv6-route-option-03 messages.  They continue
to be updated (new version of draft) and we are not consulted about the
way they are updated.  In this sense we think our ways of extending the
default route DHCP exhanges can be accommodated only if expressed in a
way we can influence.

> times in MIF meetings and in DHC meeting. As one of the authors (and
> I believe I speak on behalf of all authors) I think this draft is
> ready for last call. Therefore I would like to ask MIF chairs to
> announce WGLC.

I believe this draft is not ready for Last Call.  It is too early for
Last Call, because there exist a similar draft about the particular
aspect of default route (draft-mouton-mif-dhcpv6-drlo-00.txt "Default
Router List Option for DHCPv6 (DRLO)").

Alex

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