Subject: [mif] Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04

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

Dear participants in MIF WG,

Currently draft-ietf-mif-dhcpv6-route-option-04 specifies the DHCPv6
Server to communicate some route to the DHCPv6 Client.

In the particular case of default route, the existing mechanism to
achieve this is ND.  This has the optional feature to communicate the
MAC address of the default router at the same time.  This saves on the
number of messages exchanged (instead of 4 messages, only 2 are used).

In the same manner, it would be useful to have DHCPv6 way of
communicating the default route to add the MAC address of the IP address
of the default router.  This would save on the number of messages exchanged.

I wanted to ask the oppinion of the WG on this particular topic, thank you.

Yours,

Alex

---

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

> number of messages exchanged (instead of 4 messages, only 2 are used).

In environments where this is a significant amount of additional traffic, presumably ND will be the preferred mechanism for delivering the default route.

> of the default router.  This would save on the number of messages exchanged.

I think this is an unnecessary optimization.   What's the use case where both ND is not preferred, and bandwidth is so constrained as to make this a problem?

---

From: William Herrin <[email-masked]>
Date: Tue, 27 Mar 2012 11:52:43 -0400

> I wanted to ask the oppinion of the WG on this particular topic, thank you.

Hi Alexandru,

If added, I think it should be non-authoritative. That is, the
receiving host can use it briefly to get a jump start on communication
but is expected to promptly perform an ND request for the
authoritative MAC. This would allow a host to recover gracefully in
the inevitable event that the DHCP server and router get out of sync
about the router's MAC address.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

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

Le 27/03/2012 17:31, Ted Lemon a écrit :
>>  achieve this is ND.  This has the optional feature to communicate
>> the MAC address of the default router at the same time.  This
>> saves on the number of messages exchanged (instead of 4 messages,
>> only 2 are used).
>
> In environments where this is a significant amount of additional
> traffic, presumably ND will be the preferred mechanism for
> delivering the default route.

In lightweight environments, and this is a MIF-ed router not host, it
would only run DHCP and maybe no ND (only use its data structures).
This is so to have only one software and protocol to obtain route,
address, prefix and prefix for further away.  ND would be superfluous.

Similarly, work was and still is ongoing about doing same with ND not DHCP.

>> communicating the default route to add the MAC address of the IP
>> address of the default router.  This would save on the number of
>> messages exchanged.
>
> I think this is an unnecessary optimization.   What's the use case
> where both ND is not preferred, and bandwidth is so constrained as
> to make this a problem?

As above.

Alex

---

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

Le 27/03/2012 17:52, William Herrin a écrit :
> receiving host can use it briefly to get a jump start on
> communication but is expected to promptly perform an ND request for
> the authoritative MAC. This would allow a host to recover gracefully
> in the inevitable event that the DHCP server and router get out of
> sync about the router's MAC address.

In most senses I agree.  First, if added, I would think it would be
optional - just send the MAC address if the admin puts it in the
dhcpd.conf file.  Second, I think indeed it should be non-authoritative,
and be superseded by the ND operation.  If ND implementation exists and
is there, it should have authority over the information coming from
DHCP, including the IP of the default router and its MAC.

Alex

> Regards, Bill Herrin

---

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

On 2012-03-28 06:46, Alexandru Petrescu wrote:
...
> would only run DHCP and maybe no ND 

You can't conform to IPv6 and not run ND.

In answer to your original question: no. KISS. Don't overload DHCPv6
with a function that is part of IPv6's basic mechanism (i.e. ND).

   Brian

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 28 Mar 2012 09:18:24 +0200

> with a function that is part of IPv6's basic mechanism (i.e. ND).
+1

(Actually, all co-authors agree, so theoretically that is +4, but please
count it as my personal opinion only).

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 28 Mar 2012 09:21:21 +0200

> about the router's MAC address.
No, we do not plan adding MAC field. That would give us nothing, but
would bring a lot of troubles. In particular, the problem of MAC being
mis-configured or becoming out of sync. ND is a good protocol for that
purpose and is supported by all devices that claim IPv6 compatibility,
so we plan to use it.

Tomek

---

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

Le 28/03/2012 00:24, Brian E Carpenter a écrit :
> On 2012-03-28 06:46, Alexandru Petrescu wrote: ...
>> In lightweight environments, and this is a MIF-ed router not host,
>>  it would only run DHCP and maybe no ND
>

Brian,

Allow me a quick reply here.  There are several active RFC proposals
recent at IETF that simply don't run ND.  Or, how to better say - if ND
is present it is completely ignored, being replaced by something else
claimed better than ND for some issue at hand.

This is the case for example in the RoLL (RPL protocol), 6lowpan (IPv6
over header compression) and more.  If I understand correctly, CoAP
considers the sensor node to be an 'IPv6 node' but not necessarily run
ND.  If it did, then ICMP could be used without intermediary, instead of
CoAP.

ND relies on a very good notion of a link, subnet, whereas in these
spaces this notion is totally absent, routers have only one interface
and so forth.

Somebody said that if node is not implementing ICMPv6
Redirect then it wouldnt't be accepted as an IPv6 node.

These are points about which I could agree.  At the same time the
protocols that appear to be ignoring ND makes wonder about this
IPv6 conformity aspect.

Alex

---

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

Le 28/03/2012 09:21, Tomek Mrugalski a écrit :
>> On Tue, Mar 27, 2012 at 8:10 AM, Alexandru Petrescu If added, I
>> think it should be non-authoritative. That is, the receiving host
>> can use it briefly to get a jump start on communication but is
>> expected to promptly perform an ND request for the authoritative
>> MAC. This would allow a host to recover gracefully in the
>> inevitable event that the DHCP server and router get out of sync
> would bring a lot of troubles. In particular, the problem of MAC
> being mis-configured or becoming out of sync. ND is a good protocol
> for that purpose and is supported by all devices that claim IPv6
> compatibility, so we plan to use it.

In a sense yes, the MAC is something with link scope and ND is link
scope and ND may have the best local information about MAC.  This would
not prevent this information to be stored centrally, with all advantages
centralized management brings, and inconvenients.

Alex

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

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 14:29:55 +0200

> ND.  If it did, then ICMP could be used without intermediary, instead of

There are several parts of ND used for different purposes, and I think that might be the source of some confusion here...

6lowpan does include a definition for how ND works over IEEE 802.15.14 networks.

There are some environments where ND is not used for address autoconfiguration, where duplicate address detection (DAD) is unnecessary, or where there are other means of determining whether neighbors are reachable or not.   In those environments, those parts of ND are sometimes unnecessary.  That doesn't mean that it is okay for a general purpose IPv6 implementation to omit ND.

I don't understand what it would even mean for ROLL (which is routing protocol) or COAP (which is an HTTP compression protocol) to "use ND", so I don't know how to comment on those.

> Redirect then it wouldnt't be accepted as an IPv6 node.

I think this is something you may have taken away from a conversation with me...

You said that you have an IPv6 implementation that can only store one default route (no default router list) and cannot store any other routes.  I told you that if you shipped that stack in a commercial product, customers would be very unhappy with you because:  (1) is not acceptable (in the market) to ship and IPv6 node that can't fall back to a second default router if the preferred one goes down, and (2) it is not acceptable to ship an IP node that can't create a new route in response to an ICMP redirect.

That said, I believe it is also true that such a node would not be RFC compliant, because IPv6 nodes are required to implement ICMPv6.

Margaret

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Mar 2012 14:57:15 +0200

Le 29/03/2012 14:29, Margaret Wasserman a écrit :
>> Allow me a quick reply here.  There are several active RFC
>> proposals recent at IETF that simply don't run ND.  Or, how to
>> better say - if ND is present it is completely ignored, being
>> replaced by something else claimed better than ND for some issue
>> at hand.
>>
>> This is the case for example in the RoLL (RPL protocol), 6lowpan
>> (IPv6 over header compression) and more.  If I understand
>> correctly, CoAP considers the sensor node to be an 'IPv6 node' but
>> not necessarily run ND.  If it did, then ICMP could be used without
>> intermediary, instead of CoAP.
>
> There are several parts of ND used for different purposes, and I
> think that might be the source of some confusion here...
>
> There are some environments where ND is not used for address
> autoconfiguration, where duplicate address detection (DAD) is
> unnecessary, or where there are other means of determining whether
> neighbors are reachable or not.   In those environments, those parts
> of ND are sometimes unnecessary.  That doesn't mean that it is okay
> for a general purpose IPv6 implementation to omit ND.
>
> I don't understand what it would even mean for ROLL (which is
> routing protocol)

Well yes RPL is a routing protocol and uses ICMP message types.  There
are number of ND incompatibility issues about it.

> or COAP (which is an HTTP compression protocol) to "use ND", so I
> don't know how to comment on those.

Sorry, I dont know either.

>> Somebody said that if node is not implementing ICMPv6 Redirect
>> then it wouldnt't be accepted as an IPv6 node.
>
> You said that you have an IPv6 implementation that can only store
> one default route (no default router list) and cannot store any
> other routes.

I said that if I were to store only one route that would be the default
and not a specific route, because the default route is the only way to
use a single routing entry table and reach the maximum number of
destinations.  The draft I am proposing proposes a list of default
routers, not only one.

> I told you that if you shipped that stack in a commercial product,
> customers would be very unhappy with you because:  (1) is not
> acceptable (in the market) to ship and IPv6 node that can't fall back
> to a second default router if the preferred one goes down,

I agree.

> and (2) it is not acceptable to ship an IP node that can't create a
> new route in response to an ICMP redirect.

This I am not sure.  The point-to-point links (as in cellular) never use
Redirects because there are no alternative routers on the link.  I do
agree though that Redirect is a necessary useful message on shared links.

> That said, I believe it is also true that such a node would not be
> RFC compliant, because IPv6 nodes are required to implement ICMPv6.

In general I tend to agree.  Just I am not sure how far this requirement
goes when it comes to CoAP, RPL most header compression protocols.  It
may be just me.

Yours,

Alex