Subject: Re: [dhcwg] I-D Action: draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 26 Sep 2011 13:12:51 +0530

Hello All,

We have submitted this draft to define hardware address option in DHCPv6
messages. Please review the same and provide us with your feedback.

We would also request dhc wg to consider adoption of this draft as a wg
draft.

Thanks,
Gaurav

From: <[email-masked]>
Reply-To: <[email-masked]>
Date: Sun, 25 Sep 2011 23:07:05 -0700
To: <[email-masked]>
Subject: I-D Action: draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

 Title           : Client Hardware Address Option in DHCPv6
 Author(s)       : Gaurav Halwasia
                          Shwetha Bhandari
                          Wojciech Dec
 Filename        : draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt
 Pages           : 6
 Date            : 2011-09-25

   This document specifies the format and mechanism that is to be used
   for encoding client hardware address in DHCPv6 messages by defining a
   new DHCPv6 Client Hardware Address option.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-halwasia-dhc-dhcpv6-hardware-a
ddr-opt-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-halwasia-dhc-dhcpv6-hardware-ad
dr-opt-00.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Chuck Anderson <[email-masked]>
Date: Mon, 26 Sep 2011 08:06:53 -0400

I've read and support this draft for adoption by the wg.

Thanks,
Chuck

---

From: "Prashant Jhingran (pjhingra)" <[email-masked]>
Date: Mon, 26 Sep 2011 20:48:31 +0530

+1 ...very useful from both BB & Enterprise perspective.

PS: Perhaps can be elaborated by few topology diagrams

-
Regards,
Prashant Jhingran

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Chuck Anderson
Sent: Monday, September 26, 2011 5:37 PM
To: Gaurav Halwasia (ghalwasi)
Cc: [email-masked]; Wojciech Dec (wdec)
Subject: Re: [dhcwg] I-DAction:
draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt

Thanks,
Chuck

On Mon, Sep 26, 2011 at 01:12:51PM +0530, Gaurav Halwasia (ghalwasi)
wrote:
> Subject: I-D Action:
draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Andre Kostur <[email-masked]>
Date: Mon, 26 Sep 2011 08:26:24 -0700

I've read the draft and I think it could be useful on the
client-initated messages.   How does this interact with the Remote ID
(RFC 4580).  Does it make sense that the option means "this device's
MAC addr" when in everything but a Relay-Forward, and "the relayed
devices's MAC addr" when in a Relay-Forward?   Why not leave this
option as the device's MAC address (which could theoretically allow
the relay agent to mention its own MAC addr for whatever reason), and
let the Remote ID continue to be used to identify the downstream
device.  Which could be the client's MAC address.  Configurable on the
relay agent as to what it wants to populate the remote ID with.

--
Andre Kostur
Senior Product Design Engineer
P: 604-678-2864
E: [email-masked]
Toll-Free: 1-800-877-1856

F: 604-678-2864
VoIP: sip:[email-masked]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 26 Sep 2011 14:10:00 -0500

Had just sent this to the authors but probably best I include the DHC WG too ...

FYI - You include a reference for RFC 4580 and RFC 4361 but never use either of these.

Regarding Section 6, I wonder whether it is wise to recommend that the server first look at the client's message and then the relay's. Which do you think is more trustworthy? I certainly would at least change the "it MUST first" to a SHOULD. You could always add a discussion that indicates that in some situations it may be preferable to use the Relay's information over the client's. For example, with DOCSIS 3.0, we really trust the relay's information (if the client's matches, the client is considered a Cable Modem (CM) - if not, it probably isn't a 'valid' CM).

Why the prohibition against a "DHCPv6 LDRA" adding this information? Seems that in that environment the relay could never provide it as the 2nd hop relay would likely not have the information and it isn't the first hop either.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andre Kostur
Sent: Monday, September 26, 2011 11:26 AM
To: Prashant Jhingran (pjhingra)
Cc: [email-masked]
Subject: Re: [dhcwg] I-DAction:draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt

F: 604-678-2864

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 26 Sep 2011 14:12:11 -0500

Ignore the comment:

"Why the prohibition against a "DHCPv6 LDRA" adding this information? Seems that in that environment the relay could never provide it as the 2nd hop relay would likely not have the information and it isn't the first hop either."

I had misread this part.

- Bernie

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Monday, September 26, 2011 3:10 PM
To: 'Andre Kostur'; Prashant Jhingran (pjhingra)
Cc: [email-masked]
Subject: RE: [dhcwg] I-DAction:draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andre Kostur
Sent: Monday, September 26, 2011 11:26 AM
To: Prashant Jhingran (pjhingra)
Cc: [email-masked]
Subject: Re: [dhcwg] I-DAction:draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt

F: 604-678-2864

---

From: Shwetha <[email-masked]>
Date: Tue, 27 Sep 2011 07:59:08 +0530

Thanks for the review.

> Regarding Section 6, I wonder whether it is wise to recommend that the server
> first look at the client's message and then the relay's. Which do you think is
> more trustworthy? I certainly would at least change the "it MUST first" to a
> SHOULD. You could always add a discussion that indicates that in some
> situations it may be preferable to use the Relay's information over the
> client's. For example, with DOCSIS 3.0, we really trust the relay's
> information (if the client's matches, the client is considered a Cable Modem
> (CM) - if not, it probably isn't a 'valid' CM).

Yes, it makes sense, we will update the draft.

Thanks,
Shwetha 

On 9/27/11 12:42 AM, "Bernie Volz (volz)" <[email-masked]> wrote:

> Ignore the comment:
> 
> "Why the prohibition against a "DHCPv6 LDRA" adding this information? Seems
> that in that environment the relay could never provide it as the 2nd hop relay
> would likely not have the information and it isn't the first hop either."
> 
> I had misread this part.
> 
> - Bernie
> 
> Subject: RE: [dhcwg]
> I-DAction:draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt
> 
> Regarding Section 6, I wonder whether it is wise to recommend that the server
> first look at the client's message and then the relay's. Which do you think is
> more trustworthy? I certainly would at least change the "it MUST first" to a
> SHOULD. You could always add a discussion that indicates that in some
> situations it may be preferable to use the Relay's information over the
> client's. For example, with DOCSIS 3.0, we really trust the relay's
> information (if the client's matches, the client is considered a Cable Modem
> (CM) - if not, it probably isn't a 'valid' CM).
> 
> Why the prohibition against a "DHCPv6 LDRA" adding this information? Seems
> that in that environment the relay could never provide it as the 2nd hop relay
> would likely not have the information and it isn't the first hop either.
> 
> - Bernie
> 
> Subject: Re: [dhcwg]
> I-DAction:draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt
>

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Fri, 30 Sep 2011 13:54:49 +0530

Hi Andre,

Thanks for reading this draft.

Remote-id option RFC clearly states that remote-id SHOULD be considered an opaque value and SHOULD NOT be internally parsed by server or interpreted. As explained in the draft-halwasia-dhc-dhcpv6-hardware-addr-opt, there is no certain way as of today to get the client's hardware address and the proposed option tries to solve that problem by having a deterministic and certain way to export client's hardware address to server/relay. We think that having a dedicated option would be useful. Also by providing a provision for first hop relays to insert client's hardware address, it is possible to glean this information without having to modify client DHCP stack and also adds additional security if server trusts relay added information Vs client added option. 

Thanks,
Gaurav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andre Kostur
Sent: Monday, September 26, 2011 8:56 PM
To: Prashant Jhingran (pjhingra)
Cc: [email-masked]
Subject: Re: [dhcwg] I-DAction:draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt

F: 604-678-2864