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

[Bud Millwood <[e-mail]>]

On Fri, Sep 21, 2012 at 4:46 PM, Bernie Volz (volz) <[e-mail]> wrote:
> 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.

> 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)?

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

>
> - Bernie
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Bud Millwood
> Sent: Friday, September 21, 2012 9:55 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-02.txt
>
> 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
>
>
>
> On Fri, Sep 21, 2012 at 12:34 PM,  <[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-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-lay
>> er-addr-opt
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-add
>> r-opt-02
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-client-link-lay
>> er-addr-opt-02
>>
>>
>> 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
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg