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

["Shwetha Bhandari (shwethab)" <[e-mail]>]

Thanks for the review.
Earlier discussion on the alias inclined towards setting the link-address
to the hardware address of the interface facing the relay (Approach 1).
Your comments regarding link-address set as the hardware address of the
interface that is being configured (approach 2) are also valid.

As per Ted's comments:
<snip>
I think the section about clients including link-layer addresses should
just be removed.   This option ought to be for relay agents only, because
that's the only way it will be ubiquitous.   We shouldn't confuse the
issue by proposing that it apply to clients as well‹if we do, it will see
really spotty adoption, and probably not be of much use.
</snip>
If we modify the draft so that the hardware address is inserted by the
first hop relay only, then it will be of the interface facing the
relay/network(approach 1).

Since one of the uses of learning link layer address was to correlate
DHCPv4 and DHCPv6 messages from the same client interface ( as described
in Section 2 Problem Background and Scenario of the draft), the link layer
address should match 'chaddr' field of DHCPv4 messages sent for
configuring the same interface. RFC 2131 text about content of chaddr does
not clearly state which interface's link layer address is to be used.
However the 'chaddr' field in DHCPv4 is the hardware address that is used
by the first hop relay/server to send DHCP Reply message to the client,
and hence would be hardware address of the interface that is facing the
relay/server. With this reasoning will it be fair to go with Approach 1
i.e link layer address will be that of the relay/network facing interface
of the client and allow this option to be inserted by the first hop relay
only?

Thanks,
Shwetha


On 7/4/12 1:23 AM, "Andre Kostur" <[e-mail]> wrote:

>I think section 4 needs a little more to it.   As it stands, the
>section talks about putting in the link-layer address, but does not
>specify which one.  Perhaps that should be changed to specify that
>this is the link-address of the interface that the host is attempting
>to configure.    The use-case I'm thinking of is perhaps a laptop with
>both a wired and wireless interface.  We'd like to communicate the
>link-address of the wired interface when configuring the wired
>interface, and the link-address of the wifi interface when configuring
>that interface.    As written (since it's unspecified), a host could
>conceivably use the wired link-address for both transactions.
>
>I think the phrasing "All hosts or clients MAY include.." is
>inconsistent with other RFCs.  I think it is sufficient to say "A
>client MAY include this option ..." to be consistent with RFC 3315,
>section 22.14, 22.9, and others.
>
>On Tue, Jul 3, 2012 at 9:09 AM, <[e-mail]> wrote:
>>
>>
>> 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-00.txt
>>         Pages           : 6
>>         Date            : 2012-07-03
>>
>> Abstract:
>>    This document specifies the format and mechanism that is to be used
>>    for encoding client link-layer address in DHCPv6 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-o
>>pt-00
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>--
>Andre Kostur
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg