Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt

From: [email-masked]
Date: Fri, 21 Sep 2012 03:34:03 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title           : Client Link-layer Address Option in DHCPv6
	Author(s)       : Gaurav Halwasia
                          Shwetha Bhandari
                          Wojciech Dec
	Filename        : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt
	Pages           : 6
	Date            : 2012-09-21

Abstract:
   This document specifies the format and mechanism that is to be used
   for encoding client link-layer address in DHCPv6 relay forward
   messages by defining a new DHCPv6 Client Link-layer Address option.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02

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

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Fri, 21 Sep 2012 11:12:57 +0000

Hi DHC WG Members,

Thanks for your support/comments on this document. We have published a new version after taking care of the review comments from the last WGLC. Following are the main points which are clarified in this document:-

1.) Explicitly mentioned what Relay Agents are going to include in Client Link-layer Address option based upon the text suggested by Ted and other WG members.

2.) Also added some text on the behavior of the DHCPv6 server in case of directly connected clients.

Thanks,
Gaurav
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, September 21, 2012 4:04 PM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt

Abstract:

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

---

From: Simon Hobson <[email-masked]>
Date: Fri, 21 Sep 2012 13:20:07 +0100

Looks good to me.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

---

From: perl-list <[email-masked]>
Date: Fri, 21 Sep 2012 08:58:05 -0400 (EDT)

> Filename : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt

This looks good to me as well... Hoping this hits standard soon so that we will start seeing implementation in relay agents.

---

From: Chuck Anderson <[email-masked]>
Date: Fri, 21 Sep 2012 09:05:03 -0400

> 	Filename        : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt

I support advancing this draft as-is.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Sep 2012 13:08:58 +0000

Folks, if you want your responses to be included in the consensus evaluation, please reply to the WGLC message, not to Guarav's message.   Otherwise when the time comes in two weeks, your response will be difficult to track down and will probably be ignored.

---

From: Bud Millwood <[email-masked]>
Date: Fri, 21 Sep 2012 15:55:25 +0200

5.  DHCPv6 Server Behavior

> If DHCPv6 Server is configured to store or use client link-layer address, it SHOULD look for the client link-layer address option in the RELAY-FORW DHCP message of the DHCPv6 Relay agent closest to the client.

Although I understand what "closest to the client" means (I use that
term myself), is that the correct terminology? It could also be
referred to as the inner-most RELAY-FORW message, or the first
RELAY-FORW message. Is there even a standard terminology for this? I
just glanced through 3315 and don't see anything.

Also, the server "SHOULD" look for the link-layer address in the
closest RELAY-FORW message. What are the ramifications of changing
this to MUST? Is there any scenario where a second-hop relay would
know the link-layer address, but the first hop wouldn't know it or
support this RFC? Do we gain anything by enforcing that a conveyed
link-layer address is only valid or to be trusted if it's from the
first-hop relay?

- Bud

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Fri, 21 Sep 2012 14:35:10 +0000

Hi Bud,

>Although I understand what "closest to the client" means (I use that term myself), is that the correct terminology? It could also be referred to as the inner-most RELAY-FORW message, or the first RELAY-FORW message. Is there even a standard terminology for this? I just glanced through 3315 and don't see anything.

[Gaurav] We could change that to "inner-most RELAY-FORW".

>Also, the server "SHOULD" look for the link-layer address in the closest RELAY-FORW message. What are the ramifications of changing this to MUST? Is there any scenario where a second-hop relay would know the link-layer address, but the first hop wouldn't know it or support this RFC? Do we gain anything by enforcing that a conveyed link-layer address is only valid or to be trusted if it's from the first-hop relay?

[Gaurav] Well the purpose of this spec is to enforce relay agent to add client link-layer address option in the relay forward message. Whereas we don't really want to enforce anything on the server on how it should extract/use this option. 

Thanks,
Gaurav

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 21 Sep 2012 14:46:38 +0000

I do like "inner-most Relay-Forw" (i.e. the relay that received the client's packet [msg-type != Relay-Forw]).

While in theory a MUST is probably correct, there might be cases where that doesn't work? So, I would lean towards SHOULD to potentially support cases where there might be a second (the next) relay that has this information [and the first does not]? Certainly the MUST is correct for traditional applications (i.e. corporate Ethernet based networks or CableLabs DOCSIS).

I can't give you a specific example, but perhaps there are some from networks that don't support multicast or where a relay proxy is needed on the device itself (as then you'd have the client providing this information)?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bud Millwood
Sent: Friday, September 21, 2012 9:55 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt

- Bud

---

From: Bud Millwood <[email-masked]>
Date: Fri, 21 Sep 2012 17:03:48 +0200

> I do like "inner-most Relay-Forw" (i.e. the relay that received the client's packet [msg-type != Relay-Forw]).

Sounds fine to me.

> I can't give you a specific example, but perhaps there are some from networks that don't support multicast or where a relay proxy is needed on the device itself (as then you'd have the client provi…

Put in reverse, the question is basically "What could go wrong"? I
can't see spoofing being an issue, so I suppose we can't think of any
downside. I'm ok with SHOULD.

- Bud