Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01

One comment I would make regarding what you say below is that it isn't always possible to reverse engineer the EUI-64 link-local IPv6 address and obtain the Link Layer address. 

example: windows7 laptop I have beside me here... 

Link-local IPv6 Address...: fe80:fcf1:aac3:ab67:25a4%11 ( fe80::4cf1:aac3:ab67:25a4 as seen using show ipv6 neighbors on a juniper SRX) 
Pysical Address ..........: 00-15-C5-14-CE-B0 

Some of your other comments got me to thinking, however... On DHCPv4, the client may start communicating directly with the DHCP server ignoring the relay agent for renews (no idea if it is supposed to do that, but some do). Is this the case in DHCPv6? Is it possible for the client to ignore the relay agent and communicate directly with the DHCPv6 server on rebind? If so, then this solution will only sort of work... 
----- Original Message -----

> From: "A. Gregory Rabil" <greg.rabil@jagornet.com>
> To: "dhc WG" <dhcwg@ietf.org>, "Ted Lemon" <Ted.Lemon@nominum.com>
> Sent: Thursday, August 16, 2012 12:56:05 PM
> Subject: Re: [dhcwg] WGLC:
> draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01

> While I am generally in support of this draft, I have previously
> expressed that I believe that there are some clear benefits to
> having the client send its link layer address instead of the relay.
> I completely understand that from a deployment standpoint, it is
> much easier to upgrade relays and servers than to wait for clients
> to implement a new option.

> In any case, I believe this draft should clarify some items. For
> example,

> 1. As it stands, the draft talks only about networks where a relay
> agent is used. The draft should specify the expected behavior for
> networks without a relay.
> 2. Since the option will only appear in RELAY_FORWARD messages, what
> is the expected behavior for requests that are not forwarded by a
> relay? Are there any implications to the fact that the information
> will not be in every packet that the server receives from the
> client?
> 3. In section 4, how is the relay agent expected to obtain the
> client's link-layer address? Is the relay agent code required to be
> implemented at layer 2? Could it, for example, determine the LL
> address by reverse-engineering the client's EUI-64 link-local IPv6
> address?
> 4. If there is no relay, is the DHCPv6 server expected or required to
> obtain this information itself? If so, the same questions regarding
> the layer-2 implementation requirements are probably applicable.

> Regards,
> Greg

> On Thu, Aug 16, 2012 at 10:09 AM, Ted Lemon < Ted.Lemon@nominum.com >
> wrote:

> > The authors of this document have requested a working group last
> > call. There's already been some good review on the list, but more
> > is
> > always welcome. Please post comments if you have any, and also
> > indicate whether you support advancing the draft as written, or
> > oppose doing so. We will evaluate consensus on August 31.
> 

> > I should point out that despite its title, this document is about
> > the
> > relay agent forwarding the client link layer address. There has
> > been
> > discussion on the mailing list about other use cases that involve
> > the client sending its own link layer address; while these use
> > cases
> > may be of interest to the working group in a later draft, they are
> > out of scope for this draft, so please indicate the status of your
> > support for the draft as currently scoped. Once this work is done,
> > if someone wants to take up work on a new draft with a wider scope,
> > the working group will consider doing so.
> 

> > _______________________________________________
> 
> > dhcwg mailing list
> 
> > dhcwg@ietf.org
> 
> > https://www.ietf.org/mailman/listinfo/dhcwg
> 

> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg