Subject: [mif] Comments about default route and draft-ietf-mif-dhcpv6-route-option-02

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Aug 2011 17:22:19 +0200

Hello MIF WG,

Recently, there were comments on the mailing list about default route,
source address and draft-ietf-mif-dhcpv6-route-option "DHCPv6 Route
Options" (subsequently called "route-option" draft).  Moreover, I
commented on the microphone during the MIF WG meeting in Québec, IETF81.

I would like to further detail these comments by email.

- I need a means to communicate the default route to a Host by using
   DHCPv6 (instead of RA).

- the route-option draft specifies to use DHCPv6 to communicate routes
   (tuples prefix-nexthop) to a Client.  This can indeed be used to
   communicate a default route as a particular kind of route (i.e. use
   "::/0" as prefix and the IP  address of a default router as
   "nexthop".)

   The encoding used by the route-option draft is of the form:
   nexthop-prefix, nexthop-prefix-prefix-prefix, etc.

   Whereas this use of this route-option mechanism to communicate
   default routes is possible, and is extensible, it currently lacks a
   number of features necessary to communicate default routes.

- it is a waste of memory and bandwidth to communicate 136bits of
   prefix, as the route-option draft does, when it is known that that
   prefix is ::/0 in the case of default route (RFC).  We don't see a
   simple means to optimize the format of the Route Prefix Option
   (including the mandatory 136bits) of the current route-option draft.

- the default route is special ("when everything else fails"), it is
   not a simple prefix-nexthop route, because:

- the default route appears in a linux routing table as another typical
   route but it appears as well in the mandatory ND Default Router List
   associated with more parameters (actually dereferenced pointers to
   the Neighbor Cache).

- the default route is better if it uses a Lifetime.  It is assumed ND
   is already implemented by the vast majority of IPv6 Hosts.  (1) The
   current route-option draft mentions Lifetime to be managed according
   to general events of DHCP (and not of ND) - this may lead to
   incoherent behaviour when both DHCP and ND are run on same Host.  (2)
   The Lifetime of DHCP is on 32bits whereas of ND is on 16bit.

- it may be advantageous to communicate the MAC address of the gw of
   the default route, with DHCP.  This may speed up implementation,
   because it avoids the Host to need to perform NS/NA for the IP
   address of the gw of the default route.  The draft route-option does
   not communicate a MAC address.

- the route-option draft can communicate several default routes as
   follows: nexthop-prefix, nexthop-prefix,...  However, a more
   efficient scheme is possible as follows: 1bit, nexthop, nexthop,...

- the scope of the route-option draft reads as environments where
   routing protocols are more appropriate, whereas a more reduced scope
   could be to focus exclusively on the obtention of the default route
   as part of basic IP connectivity (not necessarily the complex
   topologies afforded by routing protocols).

We believe a better technique is possible to communicate default route
with DHCPv6.

What do people think about these comments?

Yours,

Alex

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 02 Aug 2011 11:30:26 -0400

> (including the mandatory 136bits) of the current route-option draft.

I don't agree with your assessment of waste of memory and bandwidth.

This usage of bandwidth is completly noise compared to a single http 
request on the wire.

For implementations, simplicity has benefits, including memory usage. 
(i.e. all routes are from a single DHCPv6 codepoint makes the 
implementation simpler, therefore most likely will consume ->less<- 
memory by combining the default route with other routes into a single 
dhcpv6 codepoint.)

Therefore, I don't agree with your assessment about memory and bandwidth.

Marc.

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

-- 
=========
IETF81 Quebec city: http://ietf81.ca
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca
Space Assigned Number Authority: http://sanaregistry.org

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Aug 2011 15:43:23 +0000

On Aug 2, 2011, at 11:30 AM, Marc Blanchet wrote:
I don't agree with your assessment of waste of memory and bandwidth.
This usage of bandwidth is completly noise compared to a single http request on the wire.

Calling this a bandwidth issue is kind of a misnomer.   This is really an issue of space in the DHCPv6 packet.   It's a UDP packet, of limited size, and it's not completely unreasonable to want to save 9 bytes in it.

Having said that, I find this argument unconvincing, for the simple reason that when you count the additional overhead of sending two options, you've already lost four of those nine bytes.

The other argument is about lifetimes.   But DHCP already has lifetimes; if this is unclear in the draft, perhaps the draft needs to be made more clear.   I haven't read it with this question in mind (indeed, I haven't read it in over a year) so I can at least imagine that this is a valid criticism, but if it is an accurate criticism, it is valid not only for the default route, but for all other routes as well, and so it needs to be addressed in the current draft.

---

From: MOUTON Maximilien <[email-masked]>
Date: Wed, 3 Aug 2011 16:25:23 +0000

Hello MIF working group, Marc and Ted,

>> I don't agree with your assessment of waste of memory and
>> bandwidth. This usage of bandwidth is completly noise compared to
>> a single http request on the wire.

I agree a single http request is quite bigger than these 136 bits. But
for some deployment scenarios, economizing the sending of 136 bits is
useful (think resource limited sensor networks, no http traffic, but
single heartbeat temperature samples every 10s.)

Ted Lemon wrote:
> Calling this a bandwidth issue is kind of a misnomer.   This is
> really an issue of space in the DHCPv6 packet. It's a UDP packet, of
>  limited size, and it's not completely unreasonable to want to save 9
>  bytes in it.

We grant we should not have called this issue a waste of memory and
bandwidth but rather a waste of place in DHCPv6 packet.
(one would also notice that since a default router doesn't need a
metric, the metric 1byte field could be saved as well, thus the total
unnecessary place is 10 bytes for a default router.)

> Having said that, I find this argument unconvincing, for the simple
> reason that when you count the additional overhead of sending two
> options, you've already lost four of those nine bytes.

In a sense yes, two options rather than one is consuming additional header.

But not necessarily.

We save at least 6bytes for each default router encoded, if we use
default router list option (draft-mouton), and often even more.

Here is why: imagine the route option contains only one default
router and compare the route-option encoding with using default router
list option we propose.

The route-option encoding is 46 bytes, whereas draft-mouton is 23 bytes
(half of it).

route option

route option header =  4 bytes
next hop sub option header =  4 bytes
next hop addr = 16 bytes
route prefix sub option header =  4 bytes
prefix length + metric + prefix = 18 bytes
total = 46 bytes

default router list option

default router list option header =  4 bytes
default router address = 16 bytes
router lifetime + link layer address length =  3 bytes
total = 23 bytes

The difference draft-mouton vs route-option for encoding one default
route is not just 9/10 bytes but 23.

And, while saving these 23 bytes the draft-mouton still communicates the
lifetime too.

> The other argument is about lifetimes.   But DHCP already has
> lifetimes;

Yes, actually DHCPv6 defines 4-byte lifetimes used in IA address option
and T1/T2 mechanism of IA_NA in the same manner than neighbor discovery
protocol defines valid and preferred lifetime in
prefix information option.

> if this is unclear in the draft, perhaps the draft needs to be made
> more clear.

Actually the draft is relatively clear.

One aspect is this.  route-option draft says:
> One notable exception with respect to [RFC4191] is however that a
> Route Lifetime element is not defined.

I do not agree with this.

route-option draft says:
> The information conveyed by the DHCPv6 Route Option is considered
> valid until changed or refreshed by general events that trigger
> DHCPv6 or route table state changes on a node, thus not requiring a
> specific route lifetime.

Yes, this makes sense, but does not work consistently with ND.

> I haven't read it with this question in mind (indeed, I haven't read
> it in over a year) so I can at least imagine that this is a valid
> criticism, but if it is an accurate criticism, it is valid not only
> for the default route, but for all other routes as well, and so it
> needs to be addressed in the current draft.

Yes and no, the lifetime format mentioned above fits for route lifetime.
But the default router lifetime corresponds to the router lifetime
defined in rfc 4861 section 4.2, a 2-byte field which maximum
value defined in section 6 is 9000 seconds (not for other routes).

Thank you for your comments.

I would like to ask you and the group about the other comments Alex and
myself raised about route-option draft (MAC address, scope generic vs
basic connectivity)?

Maximilien