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

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 14:09:31 +0000

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.

---

From: perl-list <[email-masked]>
Date: Thu, 16 Aug 2012 11:08:29 -0400 (EDT)

I support moving this draft forward as-is ... The rewording I suggested is not necessary for the success of the document me thinks. Having this option available sooner rather than later is preferable. 

----- Original Message -----

> From: "Ted Lemon" <[email-masked]>
> To: "dhc WG" <[email-masked]>
> Sent: Thursday, August 16, 2012 10:09:31 AM
> Subject: [dhcwg] WGLC:
> draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Thu, 16 Aug 2012 12:56:05 -0400

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 <[email-masked]> 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.
>
> 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.
>

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 16 Aug 2012 13:37:42 -0400

> used.  The draft should specify the expected behavior for networks without

I disagree.  This draft is only about a relay option.  There is no
change to servers or clients with this draft, except that a server may
use the additional information in the RELAY-FORW message.

> packet that the server receives from the client?

There is no required behavior change for clients or servers specified
in this draft, therefore what you ask is out of scope.  This is no
different than Option82 in DHCPv4--if the information is missing or
the packet wasn't relayed, then the server can't use it to classify
clients.

> reverse-engineering the client's EUI-64 link-local IPv6 address?

I could go along with additional text in Section 4 to specify that the
Relay Agent should insert the LL address of the IPv6 interface that is
being configured on the client.  How an implementation does that is an
implementation detail and doesn't need to be specified here, but I
don't think EUI-64 can be relied upon to contain the proper client LL
address in all cases.

> layer-2 implementation requirements are probably applicable.

No, that functionality is out of scope for this draft.  A server could
extract a LL address in the same way that a relay would, but that
behavior isn't specified.

I don't think we should block this draft in order to extend it to
specify how the server may acquire a client's LL address other than
via a RELAY-FORW message.  For the intended use cases as described in
Section 2, an operator can easily design their network to be sure that
all DHCPv6 traffic passes through a relay.  For the non-relayed case,
it would be much easier to modify an open source DHCPv6 server to
implement whatever behavior is wanted without affecting other parts of
the network--hence there is less need to standardize that behavior
through the IETF.  The Relay Agent option described in this draft does
benefit from standardization since an agreed format for passing the
information from the Relay to the Server will need to be implemented
by many switch/router vendors as well as server software vendors.

If it is desired to specify additional client and/or server behavior
for other use cases such as non-relayed packets, I would prefer that
it be done in separate draft(s).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 17:43:12 +0000

Chuck, I think I can read your response as saying that you are happy with the draft as it is, and while you would not oppose having the draft say how the DHCP server might acquire the link local address for a packet that arrived without being relayed, you don't think it's necessary or desirable, correct?   (I ask only so that we will know what to do later on when we evaluate consensus).

---

From: perl-list <[email-masked]>
Date: Thu, 16 Aug 2012 13:51:00 -0400 (EDT)

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" <[email-masked]>
> To: "dhc WG" <[email-masked]>, "Ted Lemon" <[email-masked]>
> Sent: Thursday, August 16, 2012 12:56:05 PM
> Subject: Re: [dhcwg] WGLC:

> 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.

> 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?
> obtain this information itself? If so, the same questions regarding
> the layer-2 implementation requirements are probably applicable.

> On Thu, Aug 16, 2012 at 10:09 AM, Ted Lemon < [email-masked] >
> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 17:53:29 +0000

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.

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 16 Aug 2012 13:55:35 -0400

On Thu, Aug 16, 2012 at 01:51:00PM -0400, 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...

No, DHCPv6 messages are always multicast and picked up by Relays (or
directly connected Servers).  There is no such thing as unicast Renew
in DHCPv6.

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Thu, 16 Aug 2012 14:03:42 -0400

Really?

RFC 3315:

18.1.3. Creation and Transmission of Renew Messages

   To extend the valid and preferred lifetimes for the addresses
   associated with an IA, the client sends a Renew message to the server
   from which the client obtained the addresses in the IA containing an
   IA option for the IA.

Greg

---

From: perl-list <[email-masked]>
Date: Thu, 16 Aug 2012 14:05:05 -0400 (EDT)

----- Original Message -----

> To: "perl-list" <[email-masked]>
> Cc: "A. Gregory Rabil" <[email-masked]>, "dhc WG"
> <[email-masked]>
> Sent: Thursday, August 16, 2012 1:53:29 PM

> > 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.

Thank you, designers, for that!! Very irritating in the DHCPv4 space.

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Thu, 16 Aug 2012 14:07:28 -0400

My point here is that if non-relayed environments are out of scope, that
should be clearly specified in the draft.  The abstract and problem
description does not say anything about it applying only to relayed
environments.

As for the specification not defining the implementation, I agree.
 However, it seems that the nature of this option indeed _forces_ the
implementation.

Greg

On Thu, Aug 16, 2012 at 1:37 PM, Chuck Anderson <[email-masked]> wrote:

> expressed

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Thu, 16 Aug 2012 14:08:29 -0400

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 <[email-masked]> 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...
>
>
> 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.
>
>

---

From: perl-list <[email-masked]>
Date: Thu, 16 Aug 2012 14:12:49 -0400 (EDT)

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

> To: "Ted Lemon" <[email-masked]>
> Cc: "perl-list" <[email-masked]>, "dhc WG" <[email-masked]>
> Sent: Thursday, August 16, 2012 2:08:29 PM

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

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

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 16 Aug 2012 14:21:30 -0400

> Chuck, I think I can read your response as saying that you are happy with the draft as it is, and while you would not oppose having the draft say how the DHCP server might acquire the link local ad…

I don't think it is necessary to update this draft to specify how a
DHCP server might acquire the link layer address from a non-relayed
packet, and I'm somewhat opposed to updating this particular draft for
that behavior now only because it would add more delay.

However, I do recognize that there may be benefit to updating section
4 to clarify what LL address is to be put into the RELAY-FORW option,
but I'm open to others' opinions on this.  Do others think this text
is clear enough, or do we need to clarify what goes into the "client
link-layer address option"?  Right now it just doesn't say what goes
in there:

"4.  DHCPv6 Relay Agent Behavior

   DHCPv6 Relay agents which are directly connected to clients/hosts MAY
   include client link-layer address option in relayed DHCPv6 (RELAY-
   FORW) message.  The DHCPv6 Relay agent behaviour can depend on
   configuration that decides whether Client Link-layer Address option
   needs to be processed and included.

   In Relay chaining scenarios, any other relay agent other than first
   hop DHCPv6 Relay agent or DHCPv6 LDRA [RFC6221] MUST not add this
   option."

---

From: perl-list <[email-masked]>
Date: Thu, 16 Aug 2012 14:28:34 -0400 (EDT)

Is there something else that the link-layer address could be mis-construed as to referring to? Even after they read the section about how it is to be attached describing hardware type as specified in RFC? 

3. DHCPv6 Client Link-layer Address Option 

The format of the DHCPv6 Client Link-layer Address option is shown 
below. 
0 1 2 3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OPTION_CLIENT_LINKLAYER_ADDR | option-length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| hardware type (16 bits) | | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 
| link-layer address (variable length) | 
| | 
| | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

option-code: OPTION_CLIENT_LINKLAYER_ADDR (TBD) 
option-length: 2 + length of link-layer address 
hardware type: Client Link-layer address type. The hardware type MUST be a 
valid hardware type assigned by the IANA, as described in [RFC0826] 
link-layer address: Client Link-layer address. 

----- Original Message -----

> From: "Chuck Anderson" <[email-masked]>
> Cc: "dhc WG" <[email-masked]>
> Sent: Thursday, August 16, 2012 2:21:30 PM

> > Chuck, I think I can read your response as saying that you are
> > happy with the draft as it is, and while you would not oppose
> > having the draft say how the DHCP server might acquire the link
> > local address for a packet that arrived without being relayed, you
> > don't think it's necessary or desirable, correct? (I ask only so
> > that we will know what to do later on when we evaluate consensus).

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 16 Aug 2012 20:36:00 +0200

> directly connected Servers).  There is no such thing as unicast Renew
See section 22.12 of RFC3315. It will spoil the surprise a bit, but
here's relevant quote:

22.12. Server Unicast Option
   The server sends this option to a client to indicate to the client
   that it is allowed to unicast messages to the server.

There are clients and servers that take advantage of that option. In a
properly implemented client, only RENEWs and RELEASEs (and possibly
INFORMATION-REQUEST) are sent using unicast.

Tomek

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 16 Aug 2012 15:08:35 -0400

> INFORMATION-REQUEST) are sent using unicast.

Thanks, I stand corrected.  The default behavior in the absence of the
Server Unicast Option is as I stated, and as Ted pointed out you can
just be sure to not set this option to be sure that multicast/relay is
always used.

---

From: perl-list <[email-masked]>
Date: Thu, 16 Aug 2012 15:17:58 -0400 (EDT)

Here is to hoping that ISC DHCP implements such a keyword to not allow unicast. 
----- Original Message -----

> To: [email-masked]
> Sent: Thursday, August 16, 2012 3:08:35 PM

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 16 Aug 2012 15:38:44 -0400

There is no need.  The default is to disallow unicast.  You only need
a server to implement the Server Unicast Option if you WANT to receive
unicast renews.  ISC already provides such an option:

>From dhcp-options(5):

     "option dhcp6.unicast ip6-address;

          The unicast option is provided by DHCPv6 servers which are
          willing (or prefer) to receive Renew packets from their
          clients by exchanging UDP unicasts with them.  Normally,
          DHCPv6 clients will multicast their Renew messages.  This
          may be configured on the server, and should be configured as
          an address the server is ready to reply to."

>From RFC3315 Section 22.12:

   "A DHCP server rejects any messages sent inappropriately using
   unicast to ensure that messages are relayed by Relay Agents when
   Relay Agent options are in use.

   Details about when the client may send messages to the server using
   unicast are in section 18."

Section 18.1:

   "If the client has a source address of sufficient scope that can be
   used by the server as a return address, and the client has received
   a Server Unicast option (section 22.12) from the server, the client
   SHOULD unicast any Request, Renew, Release and Decline messages to
   the server.

   DISCUSSION:

      Use of unicast may avoid delays due to the relaying of messages by
      relay agents, as well as avoid overhead and duplicate responses by
      servers due to the delivery of client messages to multiple
      servers.  Requiring the client to relay all DHCP messages through
      a relay agent enables the inclusion of relay agent options in all
      messages sent by the client.  The server should enable the use of
      unicast only when relay agent options will not be used."

"18.2.1. Receipt of Request Messages

   When the server receives a Request message via unicast from a client
   to which the server has not sent a unicast option, the server
   discards the Request message and responds with a Reply message
   containing a Status Code option with the value UseMulticast, a Server
   Identifier option containing the server's DUID, the Client Identifier
   option from the client message, and no other options."

"18.2.3. Receipt of Renew Messages

   When the server receives a Renew message via unicast from a client to
   which the server has not sent a unicast option, the server discards
   the Renew message and responds with a Reply message containing a
   Status Code option with the value UseMulticast, a Server Identifier
   option containing the server's DUID, the Client Identifier option
   from the client message, and no other options."

"18.2.6. Receipt of Release Messages

   When the server receives a Release message via unicast from a client
   to which the server has not sent a unicast option, the server
   discards the Release message and responds with a Reply message
   containing a Status Code option with value UseMulticast, a Server
   Identifier option containing the server's DUID, the Client Identifier
   option from the client message, and no other options."

"18.2.7. Receipt of Decline Messages

   When the server receives a Decline message via unicast from a client
   to which the server has not sent a unicast option, the server
   discards the Decline message and responds with a Reply message
   containing a Status Code option with the value UseMulticast, a Server
   Identifier option containing the server's DUID, the Client Identifier
   option from the client message, and no other options."

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 19:38:48 +0000

On Aug 16, 2012, at 2:21 PM, Chuck Anderson wrote:
"4.  DHCPv6 Relay Agent Behavior

Could say:

DHCPv6 Relay agents which receive messages originating from clients (for example Solicit and Request, but not, for example, Relay Forward or Advertise) MAY include the link-layer source address of the received message in relayed DHCPv6 Relay Forward messages.  The DHCPv6 Relay agent behavior can depend on configuration that decides whether Client Link-layer Address option needs to be processed and included.

This makes it clear where the link layer address is coming from.   As an added bonus, there's no need to mention LDRAs or intermediary relays, since Relay Forward messages are specifically excluded.

---

From: [email-masked]
Date: Fri, 17 Aug 2012 09:25:48 +0200 (CEST)

> 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 a…

I support this document going forward as is. It adds an important tool
to the DHCPv6 toolbox.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Chuck Anderson <[email-masked]>
Date: Sat, 18 Aug 2012 23:35:13 -0400

On Thu, Aug 16, 2012 at 07:38:48PM +0000, Ted Lemon wrote:
>   DHCPv6 Relay agents which receive messages originating from clients
>   (for example Solicit and Request, but not, for example, Relay
>   Forward or Advertise) MAY include the link-layer source address of
>   the received message in relayed DHCPv6 Relay Forward messages.
>   The DHCPv6 Relay agent behavior can depend on configuration that
>   decides whether Client Link-layer Address option needs to be
>   processed and included.

I agree that this text would be good to replace the existing text in
section 4.

> This makes it clear where the link layer address is coming from.   As an added bonus, there's no need to mention LDRAs or intermediary relays, since Relay Forward messages are specifically excluded.

Agreed.

---

From: perl-list <[email-masked]>
Date: Mon, 20 Aug 2012 09:07:42 -0400 (EDT)

I also support this text change... 

----- Original Message -----

> Sent: Saturday, August 18, 2012 11:35:13 PM

> >
> > This makes it clear where the link layer address is coming from. As
> > an added bonus, there's no need to mention LDRAs or intermediary
> > relays, since Relay Forward messages are specifically excluded.

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 20 Aug 2012 13:42:53 +0000

Thanks a lot for supporting this document, reviewing and providing feedback so far. We will include this text in the draft.

Thanks,
Gaurav

From: [email-masked] [mailto:[email-masked]] On Behalf Of perl-list
Sent: Monday, August 20, 2012 6:38 PM
To: Chuck Anderson
Cc: dhc WG; Ted Lemon
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01

________________________________
From: "Chuck Anderson" <[email-masked]<mailto:[email-masked]>>
To: "Ted Lemon" <[email-masked]<mailto:[email-masked]>>
Cc: "dhc WG" <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, August 18, 2012 11:35:13 PM
Subject: Re: [dhcwg] WGLC:        draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01

Agreed.
_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg