Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00

["Bernie Volz (volz)" <[e-mail]>]

>I do see the argument that the option
>should probably go into an IA options field instead of the top-level
>options field as each IA may have different link addresses to talk
>about.

No. Each DHCPv6 exchange by a client is for ONE interface and can have many IAs associated with that interface (an IA must be associated with a single interface, an interface can have many IAs).

If a client has multiple interfaces, it MUST use separate transactions for each of the interfaces.

(Sadly there is no direct text in RFC 3315 that probably says this; there's a lot of reading between the lines and some text in Section 16.)

This option should be a 'top' level option (as it is currently defined) - one for a message (note that if relayed, there are multiple messages so multiple options are possible in the 'overall' message).


While the reference to the DOCSIS CableLabs Vendor Specific Options is an interesting one, it is a bit different. They relay is adding the CM's mac address to all messages; not the actual mac address of the device doing DHCPv6. And, the CM does add its own mac address to the client portion of the message (in the CableLabs Vendor Specific Options) - which is what this option could replace. For DOCSIS, the relay version of this option would not do what is needed and therefore would not be used.


-          Bernie

From: [e-mail] [mailto:[e-mail]] On Behalf Of A. Gregory Rabil
Sent: Monday, July 09, 2012 9:04 PM
To: Andre Kostur
Cc: [e-mail]; Ted Lemon
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

I believe the argument for having the the option in the IA options field instead of top-level options suggests that the option should/must be done by the client, because I'm not sure how the relay could glean that information.

Greg
On Mon, Jul 9, 2012 at 8:55 PM, Andre Kostur <[e-mail]<mailto:[e-mail]>> wrote:
Note that my suggestion is that clients MAY add this field as well as
relays, not one or the other.  I do see the argument that the option
should probably go into an IA options field instead of the top-level
options field as each IA may have different link addresses to talk
about.   The client may add the option as it may be operating in an
environment where there are no relays, and the relay may add the
option as it may be operating in an environment where the dhcp server
may not be entirely trusting the client device, but trusts the relay
more.   As an example, in the cable world, the CMTS (playing the
DHCPv6 relay) adds on the MAC address of the cable modem into its
relayed options (currently a sub-option of option 17).



On Mon, Jul 9, 2012 at 4:41 PM, A. Gregory Rabil
<[e-mail]<mailto:[e-mail]>> wrote:
> I don't believe the information would be the same in the case where the
> client is requesting an address for a different interface (which is possible
> in DHCPv6, but not in DHCPv4).  That's what I was trying to explain with the
> rest of my post.
>
> Greg
>
>
> On Mon, Jul 9, 2012 at 7:20 PM, Ted Lemon <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> On Jul 9, 2012, at 7:04 PM, A. Gregory Rabil wrote:
>>
>> I think this would severely limit the usefulness of this option.  I would
>> much prefer Andre's suggestion that this option be filled with the link
>> layer address of the interface being configured.  This would mean that the
>> client would be responsible for adding this option, not the relay.  I
>> understand the motivation for the option is to help correlate the client to
>> the IPv4 chaddr field.
>>
>>
>> Why would having the relay add the option limit its usefulness?   The
>> information is the same in either case.   The difference is that you don't
>> have to update all your DHCPv6 clients, and you don't have to worry that
>> some DHCPv6 client vendors won't ever implement this option.
>>
>


--
Andre Kostur
Senior Product Design Engineer
P: 604-678-2864<tel:[phone]>
E: [e-mail]<mailto:[e-mail]>
Toll-Free: 1-800-877-1856<tel:[phone]>


F: 604-678-2864<tel:[phone]>
VoIP: sip:[e-mail]<mailto:[e-mail]>