Subject: [mif] #8: absent MAC address of default route?

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

#8: absent MAC address of default route?

 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.

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

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

---

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

 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?

  -route-option          |  Resolution:
 Keywords:               |

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

---

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

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

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

---

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

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

 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

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

---

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

> 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

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

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

---

From: "mif issue tracker" <[email-masked]>
Date: Thu, 02 Aug 2012 01:16:41 -0000

In a private discussion with draft author 1aug2012 I am told that the MAC
 address should maybe be an option to the nexthop.  In order to achieve
 that, one would look at a link layer address option for DHCPv6 as
 specified elsewhere.  I believe it may be in draft-halwasia-dhc-dhcpv6
 -hardware-addr-opt-01 of March 2012.

 If I were to design an extension with the MAC address I think I would try
 to make it as short as possible, because my use case is for M2M Gateway.
 For example, the link-layer address option of ND uses only two bytes
 (type, length) of overhead, compared to 6 bytes of draft-halwasia.  This
 overhead could be reduced to 0 if the link-layer address option length
 were implied by the option-len field of the Next Hop Option of draft-ietf-
 mif-dhcpv6-route-option-04.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Aug 2012 18:19:38 -0700

Tomek, list,

Just for my clarification - do you mean that a MAC address could be used 
as an option NEXT_HOP options of Next Hop Option format?

And this option could be something new that one could design, or is it 
something recommended to follow 
draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01?

Yours,

Alex