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

[perl-list <[e-mail]>]

Does not section 2 paragraph 4 scope the draft to relay forward messages? 
" Providing an option in DHCPv6 relay forward messages to carry client
   link-layer address explicitly will help above mentioned scenarios. " 
----- Original Message -----

> From: "A. Gregory Rabil" <[e-mail]>
> To: "Ted Lemon" <[e-mail]>
> Cc: "perl-list" <[e-mail]>, "dhc WG" <[e-mail]>
> Sent: Thursday, August 16, 2012 2:08:29 PM
> Subject: Re: [dhcwg] WGLC:
> draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01

> Good point, Ted. Maybe some text should be added to the draft to
> explain that this is the expected configuration?

> Greg

> On Thu, Aug 16, 2012 at 1:53 PM, Ted Lemon < [e-mail] >
> wrote:

> > On Aug 16, 2012, at 1:51 PM, perl-list wrote:
> 
> > > 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...
> > 
> 
> > The client isn't allowed to do this unless it negotiates it with
> > the
> > server, which presumably would say no in any environment where the
> > client-link-layer-address option was used. This was a deliberate
> > design decision in RFC3315, to deal with the exact problem you are
> > talking about.
>