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

From: [email-masked]
Date: Tue, 03 Jul 2012 09:09:01 -0700

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Andre Kostur <[email-masked]>
Date: Tue, 3 Jul 2012 12:53:03 -0700

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

--
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Jul 2012 20:30:41 +0000

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.

---

From: Andre Kostur <[email-masked]>
Date: Tue, 3 Jul 2012 13:43:58 -0700

Do we want to exclude environments where there is no relay agent from
ever being able to talk about client link-addresses?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Jul 2012 21:09:39 +0000

On Jul 3, 2012, at 4:43 PM, Andre Kostur wrote:
Do we want to exclude environments where there is no relay agent from
ever being able to talk about client link-addresses?

No.   Of course not.   In those environments, the link-layer address is available to the server from the layer 2 header.   That's how the relay is getting it too.

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Mon, 9 Jul 2012 18:16:33 +0000

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" <[email-masked]> wrote:

>>         Filename        :
>>draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt
>>         Pages           : 6
>>         Date            : 2012-07-03
>>
>> Abstract:

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Jul 2012 18:30:19 +0000

On Jul 9, 2012, at 2:16 PM, Shwetha Bhandari (shwethab) wrote:
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?

That's certainly what I'd advocate!

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Mon, 9 Jul 2012 19:04:31 -0400

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.

relay/server.

With all DHCPv4 client implementations that I am familiar with, the chaddr
is always the address of the interface which is being configured.  Also,
DHCPv4 does not support the ability to request multiple addresses in one
request.  With DHCPv6, the protocol supports configuration of multiple
interfaces and multiple addresses in one request.  If the proposed option
does not contain the link layer address of the interface being configured,
then it may not be correlated back to the DHCPv4 chaddr.  Therefore, I
would suggest that the option must be within the IA_NA/IA_TA/IA_PD option
"bucket" so as to properly support the multiple interface request case.

Greg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Jul 2012 23:20:17 +0000

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.

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Mon, 9 Jul 2012 19:41:17 -0400

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

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

---

From: Andre Kostur <[email-masked]>
Date: Mon, 9 Jul 2012 17:55:46 -0700

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

-- 
Andre Kostur
Senior Product Design Engineer
P: 604-678-2864
E: [email-masked]
Toll-Free: 1-800-877-1856

F: 604-678-2864
VoIP: sip:[email-masked]

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Mon, 9 Jul 2012 21:04:18 -0400

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

> possible

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Jul 2012 14:11:26 +0000

On Jul 9, 2012, at 7:41 PM, A. Gregory Rabil 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.

Why do we care?   The link layer address is not an interface identifier—it's a hint to be used by your corporate back-office inventory tracking system so that it can tell that an IPv4 address belongs to the same machine as an IPv6 address.   As long as your inventory tracking system has a list of all the interfaces on a machine, or as long as the DHCPv4 server has received a request from the same interface, the connection is made.   We are hinting at the machine's identity, not the interface's identity.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Jul 2012 14:17:11 +0000

On Jul 9, 2012, at 8:55 PM, Andre Kostur wrote:
about.

All of this discussion makes a huge amount of sense if your intention is to deprecate IAIDs, but makes no sense at all if you are intending this option to be a hint.   This option was adopted by the working group on the basis that we would be using it as a hint.

This draft is important work.   If we turn it into a referendum on IAIDs, it will be very contentious and won't get done anytime soon.   I would really appreciate it if we could keep a laser-like focus on the purpose that this draft was adopted to serve, and stop trying to rewrite history.

---

From: Andre Kostur <[email-masked]>
Date: Tue, 10 Jul 2012 07:52:24 -0700

On Tue, Jul 10, 2012 at 7:17 AM, Ted Lemon <[email-masked]> wrote:
> All of this discussion makes a huge amount of sense if your intention is to
> deprecate IAIDs, but makes no sense at all if you are intending this option
> to be a hint.   This option was adopted by the working group on the basis
> that we would be using it as a hint.
>
> This draft is important work.   If we turn it into a referendum on IAIDs, it
> will be very contentious and won't get done anytime soon.   I would really
> appreciate it if we could keep a laser-like focus on the purpose that this
> draft was adopted to serve, and stop trying to rewrite history.

Looking at the background of this draft, one of the justifications for
the draft is "based on an identifier that is already used by that
operator."   None of the operators are currently using the IAID as an
identifier, so that's not a good choice.  If we were simply trying to
select a mechanism to tie a v4 allocation to a v6 allocation one could
just use RFC 4361 on the v4 side and you have that information.  But
back to the problem that the DUID isn't an identifier that is already
used by operators.

The hardware address doesn't necessarily have a one-to-one mapping to
IAIDs.  A MAC address may be associated with multiple IAIDs (perhaps
interface aliasing? eth0:0, eth0:1, etc.), so it won't be replacing
IAIDs.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Jul 2012 15:17:21 +0000

On Jul 10, 2012, at 10:52 AM, Andre Kostur wrote:
> operator."

How so?   I don't recall this justification coming up in the working group meeting in Paris.   What I recall was an agreement that it would be nice if there were a way for a DHCPv6 server to get the hardware address of the client so that it could be correlated with the DHCPv4 client identifier.

> None of the operators are currently using the IAID as an
> identifier, so that's not a good choice.

By "identifier" here I assume you mean "machine inventory identifier," not "database key associated with assigned IP address."    If you mean the latter, then you are saying that operators are using DHCPv6-like servers that don't follow the protocol, which would be news to me, although I suppose it's possible.

> If we were simply trying to
> just use RFC 4361 on the v4 side and you have that information.

We discussed this in the meeting.   We can't use RFC4361 because the timing was wrong—it would have had to come out about ten years earlier in order to have been useful.   Uptake thus far has been zero.   Hence, it cannot be used.

> But back to the problem that the DUID isn't an identifier that is already
> used by operators.

Again, please be clear on what you mean by "identifier."   Otherwise we're going to wind up in a useless debate about stuff we can't change.

> interface aliasing? eth0:0, eth0:1, etc.), so it won't be replacing

Correct.

So unless you really are saying that the link-layer address ought to replace DUID/IAID, there is no reason for the client to send it—it's easier and more deployable if the relay agent does it, because you have to buy a lot fewer of them, and the party interested in the identifier is the one writing the RFP for the device that has the relay agent running on it.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 10 Jul 2012 17:44:51 -0400

On Tue, 2012-07-10 at 14:11 +0000, Ted Lemon 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.
> 
> Why do we care?   The link layer address is not an interface
> identifier—it's a hint to be used by your corporate back-office
> inventory tracking system so that it can tell that an IPv4 address
> belongs to the same machine as an IPv6 address.

No.  Not only is it an interface identifier; for this purpose, it is
_the_ interface identifier.  We use client hardware addresses not just
for after-the-fact tracking, but for making decisions about what
addresses to assign, what options to send, and what DDNS updates to do,
among other things.

It seems to me there are two use cases here, which argue for different
uses of the option:

The first use case is to allow the DHCP server to identify the client by
its hardware address, the same as it could under DHCPv4, even when there
is a relay involved.  The option takes the place of the DHCPv4 chaddr
field or the layer 2 source address, and is needed when and only when
there is a relay involved.

The second use case is to allow a client which is configuring addresses
for multiple interfaces, or for interfaces other than the one which it
is using to reach the server, to identify those interfaces.  As I note
above, we _do_ use hardware addresses for interface identification, and
to me this is definitely a valid use case.  Here, the option performs a
function not available in DHCPv4, and is needed only when the client is
using a feature of DHCPv6 that is also not available in DHCPv4.  The
need exists whether or not there is a relay involved, and a relay does
not have enough information to help anyway.

I would suggest that for the first use case, the option be added at the
top-level by the relay agent.  Relays which support this option should,
in the normal case, unconditionally add or replace this option at the
top level.  Clients SHOULD NOT use this option at the top level.

For the second use case, a client wishing to identify a particular
interface may do so by using this option in the IA options field for
that interface.  Relays SHOULD NOT add, modify, or remove this option at
the IA level.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 10 Jul 2012 17:51:59 -0400

On Tue, 2012-07-10 at 15:17 +0000, Ted Lemon wrote:

> By "identifier" here I assume you mean "machine inventory identifier,"
>  not "database key associated with assigned IP address."    If you mean
>  the latter, then you are saying that operators are using DHCPv6-like
>  servers that don't follow the protocol, which would be news to me,
>  although I suppose it's possible.

The server may use IAIDs as keys in the lease database, but I promise
you that my registration database, which contains the registration
information used to decide which clients get which fixed addresses (or
are given leases at all), contains hardware addresses.

-- Jeff

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Jul 2012 23:11:47 +0000

On Jul 10, 2012, at 5:44 PM, Jeffrey Hutzelman wrote:
No.  Not only is it an interface identifier; for this purpose, it is
_the_ interface identifier.

Jeffrey, you may have your own personal beliefs about how you want to operate your own DHCPv6 server, but these beliefs are out of scope for this discussion.   This discussion is about how to extend the DHCPv6 protocol to provide functionality that will interoperate in a general way, but provide information that sites like yours need in order to associate entries in the DHCPv4 lease database and DHCPv6 allocation database with each other.

If you are interested in pursuing this latter goal, that's great.   If you just want to keep having the same old stupid argument about how RFC3315 ought to have been written, please take it somewhere else.

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Tue, 10 Jul 2012 23:30:33 -0400

> We are hinting at the machine's identity, not the interface's identity.

I believe this is exactly what limits the usefulness of this option.  Why
not identify the machine AND the interface?  I understand the argument that
it is easier to update relay agents versus clients, but it just seems like
this is incomplete solution.  I also understand the DUID/IAID and am not
out to change that at all.  I would simply like add this link-layer option
to identify the interface actually being configured in order to provide as
much information as possible for administrative control, because experience
has shown that such controls are inevitably needed.

Greg

On Tue, Jul 10, 2012 at 10:11 AM, Ted Lemon <[email-masked]> wrote:

> identifier—it's a hint to be used by your corporate back-office inventory
> tracking system so that it can tell that an IPv4 address belongs to the
> same machine as an IPv6 address.   As long as your inventory tracking
> system has a list of all the interfaces on a machine, or as long as the
> DHCPv4 server has received a request from the same interface, the
> connection is made.   We are hinting at the machine's identity, not the
> interface's identity.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jul 2012 03:53:21 +0000

On Jul 10, 2012, at 11:30 PM, A. Gregory Rabil wrote:
I believe this is exactly what limits the usefulness of this option.  Why not identify the machine AND the interface?  I understand the argument that it is easier to update relay agents versus clients, but it just seems like this is incomplete solution.  I also understand the DUID/IAID and am not out to change that at all.  I would simply like add this link-layer option to identify the interface actually being configured in order to provide as much information as possible for administrative control, because experience has shown that such controls are inevitably needed.

The purpose of the draft was very simply and exclusively to tag each DHCPv6 packet with the link-layer address of the interface on which the packet was originally sent.   This is a very simple, very restricted scope.   It's something that I think everyone in the working group can agree on.   It's also very easy to implement, because it can be done in the relay agent.

What you've said is very difficult for me to parse—you seem to be imputing a ton of additional protocol and semantic detail on top of something very simple.   Can you state in simple, clear terms why the first sentence in the paragraph above does not satisfy you?

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Wed, 11 Jul 2012 14:50:01 -0400

What does not satisfy about that first sentence is that it limits the
usefulness of this option because of the part that says "the interface on
which the packet was originally sent".  My argument is that although this
may be useful, it it not a complete solution because I would like it to
identify the interface which is being configured.

This text is from the section 2 of the draft:

   In dual stack scenarios it is desirable for the operator
   to associate DHCPv4 and DHCPv6 messages as belonging to the same
   client interface based on an identifier that is already used by that
   operator such as the client hardware address.

This refers to the client interface, not just the client.  This statement

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.

I believe I have explained how this may not always be the case if the relay
is responsible for inserting the option, whereas it can be ensured if the
client does it.

As an example, consider a client which is dual-stacked on two interfaces.
 In DHCPv4, each request MUST be sent with a chaddr of the interface being
configured, which is, by definition, the interface on which the request is
sent.  In this situation, an administrator could provide different options,
etc. for each interface based upon what the back-office database says.  In
DHCPv6, the text in RFC 3315 section 16 suggests that it is possible for
the client to send a request out an interface other than the one being
configured.  In this scenario, it may not be possible to correlate this as
being "messages from the same client interface" as the DHCPv4 client.
 Earlier you referenced and "inventory tracking system has a list of all
the interfaces on a machine".  What if that inventory tracking system is
trying to "discover" the interfaces by reading the DHCP server's lease
database?  DHCPv4 cannot correlate the two interfaces to being on the same
client, so even if it is the same server serving all four requests (v4 and
v6 address for each interface), it is possible that both v6 requests look
to be coming from one interface.  So, an inventory system would learn that
one interface has an IPv4 address and two IPv6 addresses, and the other
interface has one IPv4 address, which would be incorrect.

In the end, I think it comes down to the fact that DHCPv4/v6 configure
interfaces, not machines.  Administrators are accustomed to being able to
configure interfaces (not machines) by their link-layer address in DHCPv4.
 I believe that in order to provide this same capability in DHCPv6, we need
to ensure that the option identifies the interface being configured, not
just the machine.

Another aspect of the option not being inserted by the client is that it
forces implementations (relays and servers) to read layer 2 information
from the incoming packets.  If the client provides this information as an
option, it works for all implementations without such a requirement.

Greg

On Tue, Jul 10, 2012 at 11:53 PM, Ted Lemon <[email-masked]> wrote:

>  The purpose of the draft was very simply and exclusively to tag each
> DHCPv6 packet with the link-layer address of the interface on which the
> packet was originally sent.   This is a very simple, very restricted scope.
>   It's something that I think everyone in the working group can agree on.
> It's also very easy to implement, because it can be done in the relay agent.
>
>  What you've said is very difficult for me to parse—you seem to be
> imputing a ton of additional protocol and semantic detail on top of
> something very simple.   Can you state in simple, clear terms why the first
> sentence in the paragraph above does not satisfy you?
>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jul 2012 20:10:03 +0000

On Jul 11, 2012, at 2:50 PM, A. Gregory Rabil wrote:
What does not satisfy about that first sentence is that it limits the usefulness of this option because of the part that says "the interface on which the packet was originally sent".  My argument is that although this may be useful, it it not a complete solution because I would like it to identify the interface which is being configured.

Okay, great.   So, the link-layer address for the interface being configured is being attached to the packet that was sent on that interface, but somehow this doesn't satisfy your need.   Can you describe (please, one or two sentences, not several paragraphs) under what real-world circumstances this would occur?

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Wed, 11 Jul 2012 17:10:29 -0400

On Wed, Jul 11, 2012 at 4:10 PM, Ted Lemon <[email-masked]> wrote:

> Okay, great.   So, the link-layer address for the interface being
> configured is being attached to the packet that was sent on that interface,
> but somehow this doesn't satisfy your need.   Can you describe (please, one
> or two sentences, not several paragraphs) under what real-world
> circumstances this would occur?
>
>
Okay, consider prefix-delegation, for example.  The requesting router will
send an IA_PD request out the WAN interface to get a prefix which is then
allocated to the downstream/LAN interface.  Since the packet is sent via
the WAN interface, I believe that the relay would insert the link-layer
address of the WAN interface in the request, and thus the prefix would then
be "associated" with the WAN interface, whereas it is really associated
with the LAN interface.  So, this is how the interface being configured is
NOT the interface on which the packet is sent.  Further, consider a
requesting router with two distinct downstream/LAN interfaces.  The PD
requests for both LAN interfaces would be sent via the WAN interface, and
thus the WAN's link-layer address will be inserted into the option by the
relay (or learnt by the server from layer 2).  An administrator may wish to
configure different prefixes and/or options for each LAN interface, but has
no way to do identify them individually via the proposed mechanism.

Sorry, that was more than two sentences.  I hope it is a bit clearer now.

Greg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jul 2012 21:26:38 +0000

On Jul 11, 2012, at 5:10 PM, A. Gregory Rabil wrote:
> Okay, consider prefix-delegation, for example.  The requesting router will send an IA_PD request out the WAN interface to get a prefix which is then allocated to the downstream/LAN interface.  Since the packet is sent via the WAN interface, I believe that the relay would insert the link-layer address of the WAN interface in the request, and thus the prefix would then be "associated" with the WAN interface, whereas it is really associated with the LAN interface.  So, this is how the interface being configured is NOT the interface on which the packet is sent.  Further, consider a requesting router with two distinct downstream/LAN interfaces.  The PD requests for both LAN interfaces would be sent via the WAN interface, and thus the WAN's link-layer address will be inserted into the option by the relay (or learnt by the server from layer 2).  An administrator may wish to configure different prefixes and/or options for each LAN interface, but has no way to do identify them individually via the proposed mechanism.

So you're saying that we need the functionality because of a protocol feature that doesn't exist.   Got it.

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Wed, 11 Jul 2012 19:14:06 -0400

No.  You asked for me to provide a scenario where the interface being
configured is not the interface on which the packet is sent.  I believe I
have done that.  The example was extended simply to demonstrate that we may
also consider other uses for this option beyond the box you wish to put it
in.  But you are clearly not interested in a larger box.  Got it.

On Wed, Jul 11, 2012 at 5:26 PM, Ted Lemon <[email-masked]> wrote:

> > Okay, consider prefix-delegation, for example.  The requesting router
> will send an IA_PD request out the WAN interface to get a prefix which is
> then allocated to the downstream/LAN interface.  Since the packet is sent
> via the WAN interface, I believe that the relay would insert the link-layer

---

From: Andre Kostur <[email-masked]>
Date: Wed, 11 Jul 2012 16:26:26 -0700

> How so?   I don't recall this justification coming up in the working group meeting in Paris.   What I recall was an agreement that it would be nice if there were a way for a DHCPv6 server to get th…

Whups... hadn't replied to this.   How so?:  Section 2, paragraph 2,
third sentence.  That was a quote from the draft.

-- 
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jul 2012 23:51:10 +0000

On Jul 11, 2012, at 7:26 PM, Andre Kostur wrote:
Whups... hadn't replied to this.   How so?:  Section 2, paragraph 2,
third sentence.  That was a quote from the draft.

The draft was in fact originally written with the intention of doing something like what you and Greg are talking about, but the consensus to adopt in Paris was on the basis of a much more limited scope.   We all understood (I thought!) that trying to change the DUID, or provide something like a DHCPv4 chaddr that has the same semantics, was out of scope.   Now it seems that a few participants are trying to pull that back in-scope.   The problem with this is twofold: one, I think it will create massive interoperability problems.   And two, I don't think it will ever make it to the IESG as a finished draft.

This is why I'm pushing back on the people who have been advocating re-expanding the scope of the draft to what the authors originally intended.   I thought the authors had agreed to the more limited scope, since it achieves their purpose.

---

From: Andre Kostur <[email-masked]>
Date: Wed, 11 Jul 2012 17:35:02 -0700

On Wed, Jul 11, 2012 at 4:51 PM, Ted Lemon <[email-masked]> wrote:
> The draft was in fact originally written with the intention of doing
> something like what you and Greg are talking about, but the consensus to
> adopt in Paris was on the basis of a much more limited scope.   We all
> understood (I thought!) that trying to change the DUID, or provide something
> like a DHCPv4 chaddr that has the same semantics, was out of scope.   Now it
> seems that a few participants are trying to pull that back in-scope.   The
> problem with this is twofold: one, I think it will create massive
> interoperability problems.   And two, I don't think it will ever make it to
> the IESG as a finished draft.
>
> This is why I'm pushing back on the people who have been advocating
> re-expanding the scope of the draft to what the authors originally intended.
> I thought the authors had agreed to the more limited scope, since it
> achieves their purpose.

I wasn't in Paris, but will be in Vancouver since you're all coming to
my backyard.  Paris was in March, but this draft was published in July
without the Paris input?

-- 
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2012 03:44:40 +0000

On Jul 11, 2012, at 8:35 PM, Andre Kostur wrote:
I wasn't in Paris, but will be in Vancouver since you're all coming to
my backyard.  Paris was in March, but this draft was published in July
without the Paris input?

I assumed that it was just publication as a working group draft without an update; was I mistaken?

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Thu, 12 Jul 2012 03:46:21 +0000

Hello Ted and All,

> I assumed that it was just publication as a working group draft without an update; was I mistaken?
[Gaurav] Yes, you are right. It was just a publication as WG draft without an update.

Thanks,
Gaurav

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, July 12, 2012 9:15 AM
To: Andre Kostur
Cc: [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

---

From: perl-list <[email-masked]>
Date: Thu, 12 Jul 2012 08:57:14 -0400 (EDT)

Greg, 

What you say in theory is interesting and could pose a problem. In practice, however, it seems that prefix delegation and WAN configuration happen simultaneously in the same exchange within the same packet. Also, as this draft is intended to help correlation between DHCPv4 and DHCPv6 using the (hardware / link layer / MAC - whatever we are calling it these days) address, your argument about downstream interfaces that would not be known in DHCPv4 space is irrelevant. 
----- Original Message -----

> From: "A. Gregory Rabil" <[email-masked]>
> To: "Ted Lemon" <[email-masked]>
> Cc: [email-masked], "Andre Kostur" <[email-masked]>
> Sent: Wednesday, July 11, 2012 5:10:29 PM
> Subject: Re: [dhcwg] I-D Action:

> On Wed, Jul 11, 2012 at 4:10 PM, Ted Lemon < [email-masked] >
> wrote:

> > configured is being attached to the packet that was sent on that
> > interface, but somehow this doesn't satisfy your need. Can you
> > describe (please, one or two sentences, not several paragraphs)
> > under what real-world circumstances this would occur?
> 

> will send an IA_PD request out the WAN interface to get a prefix
> which is then allocated to the downstream/LAN interface. Since the
> packet is sent via the WAN interface, I believe that the relay would
> insert the link-layer address of the WAN interface in the request,
> and thus the prefix would then be "associated" with the WAN
> interface, whereas it is really associated with the LAN interface.
> So, this is how the interface being configured is NOT the interface
> on which the packet is sent. Further, consider a requesting router
> with two distinct downstream/LAN interfaces. The PD requests for
> both LAN interfaces would be sent via the WAN interface, and thus
> the WAN's link-layer address will be inserted into the option by the
> relay (or learnt by the server from layer 2). An administrator may
> wish to configure different prefixes and/or options for each LAN
> interface, but has no way to do identify them individually via the
> proposed mechanism.

---

From: Simon Hobson <[email-masked]>
Date: Thu, 12 Jul 2012 15:00:47 +0100

perl-list wrote:

>>Okay, consider prefix-delegation, for example. ...

>What you say in theory is interesting and could pose a problem.  In 
>practice, however, it seems that prefix delegation and WAN 
>configuration happen simultaneously in the same exchange within the 
>same packet.  Also, as this draft is intended to 
>help correlation between DHCPv4 and DHCPv6 using the (hardware / 
>link layer / MAC - whatever we are calling it these days) address, 
>your argument about downstream interfaces that would not be known in 
>DHCPv4 space is irrelevant.

I agree, and what's more I can't really see how it's an upstream 
server's job to configure downstream interfaces on a router. In the 
general case where PD is likely, it's going to be an ISP delivering a 
prefix to a customer's router - what the customer wants to do with 
that isn't really anything to do with the ISP.
All the ISP needs to do is a) configure the customer's WAN, and b) 
provide them with a PD.

While I could see some situations where going further might be 
useful, I could only see it working in a managed environment (eg ISP 
supplied routers, I'm thinking something similar to ISP supplied 
cable modems). I'd see that sort of situation managed by 'private' 
extensions/options which could be agreed between the client and 
server - possibly as an industry segment standard vendor option space.

I'm inclined to agree with Ted - keep it simple so it can actually get passed !

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

---

From: Andre Kostur <[email-masked]>
Date: Thu, 12 Jul 2012 07:18:08 -0700

On Thu, Jul 12, 2012 at 5:57 AM, perl-list <[email-masked]> wrote:

> Also, as
> this draft is intended to help correlation between DHCPv4 and DHCPv6 using
> the (hardware / link layer / MAC - whatever we are calling it these days)
> address, your argument about downstream interfaces that would not be known
> in DHCPv4 space is irrelevant.

Changing gears for a second... if the point behind this draft is to
correlate DHCPv4 and DHCPv6 leases, is the MAC address sufficient?
Consider the case of any device using the DHCPv4 client identifier to
distinguish between multiple leases on the same computer.  (One client
that I know does this is Microsoft RRAS servers.).  Or any case where
there is no MAC address to speak of (wasn't there something like DHCP
over Infiniband which mandated the use of Client ID since there was no
MAC address?).

Or are we writing these cases as "we don't care about these edge
problems, using the MAC address will solve the vast majority of the
cases"?

-- 
Andre Kostur

---

From: perl-list <[email-masked]>
Date: Thu, 12 Jul 2012 11:11:52 -0400 (EDT)

This is done with ISPs in mind. ISPs typically use the mac address to maintain customer records as it is the most consistent method of identifying a device on an IPv4 / DHCPv4 network. RRAS or other router types internal interfaces are typically ignored in the IPv4 space and are privately addressed from the customer perspective. Hence, the ISP neither needs nor wants knowledge of those interfaces. In the IPv6 / DHCPv6 world, one would assume that the PD to the internal interfaces would need to be correlated with the external / WAN interface of the customer equipment. The mac address of the WAN can serve the needs here too. 
----- Original Message -----

> From: "Andre Kostur" <[email-masked]>
> To: "perl-list" <[email-masked]>
> Cc: "A. Gregory Rabil" <[email-masked]>, [email-masked],
> "Ted Lemon" <[email-masked]>
> Sent: Thursday, July 12, 2012 10:18:08 AM

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2012 16:26:16 +0000

On Jul 12, 2012, at 10:18 AM, Andre Kostur wrote:
Changing gears for a second... if the point behind this draft is to
correlate DHCPv4 and DHCPv6 leases, is the MAC address sufficient?
Consider the case of any device using the DHCPv4 client identifier to
distinguish between multiple leases on the same computer.

This shouldn't be a problem, because even if the client sends a client-identifier, it still has to send chaddr.

---

From: Andre Kostur <[email-masked]>
Date: Thu, 12 Jul 2012 09:39:12 -0700

On Thu, Jul 12, 2012 at 9:26 AM, Ted Lemon <[email-masked]> wrote:
> This shouldn't be a problem, because even if the client sends a
> client-identifier, it still has to send chaddr.

Yes, you'll likely have a chaddr, but you no longer know which DHCPv4
lease that the DHCPv6 transaction corresponds to.  You may have dozens
of DHCPv4 leases, all with the same CHADDR.

-- 
Andre Kostur

---

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

Its ok tho - in an ISP situation - you want to associate leases to a customer - you may or may not care how many of them you have. What you do care about is you know who they belong to. 
----- Original Message -----

> Cc: "perl-list" <[email-masked]>, "A. Gregory Rabil"
> <[email-masked]>, "<[email-masked]>" <[email-masked]>
> Sent: Thursday, July 12, 2012 12:39:12 PM

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Thu, 12 Jul 2012 21:06:56 -0400

> While I could see some situations where going further might be useful, I
could only see it working in a managed environment (eg ISP supplied
routers, I'm thinking something similar to ISP supplied cable modems).

Consider the case where both the delegating and requesting router are
within an enterprise network, not the current use of PD with home routers.
 In this case, the downstream interfaces are indeed interesting to the
delegating router.

On Thu, Jul 12, 2012 at 10:00 AM, Simon Hobson <[email-masked]>wrote:

>> practice, however, it seems that prefix delegation and WAN configuration
>> happen simultaneously in the same exchange within the same packet.  Also,
>> as this draft is intended to help correlation between DHCPv4 and DHCPv6
>> using the (hardware / link layer / MAC - whatever we are calling it these
>> days) address, your argument about downstream interfaces that would not be
>> known in DHCPv4 space is irrelevant.
>>
>
> I agree, and what's more I can't really see how it's an upstream server's
> job to configure downstream interfaces on a router. In the general case
> where PD is likely, it's going to be an ISP delivering a prefix to a
> customer's router - what the customer wants to do with that isn't really
> anything to do with the ISP.
> All the ISP needs to do is a) configure the customer's WAN, and b) provide
> them with a PD.
>
> While I could see some situations where going further might be useful, I
> could only see it working in a managed environment (eg ISP supplied
> routers, I'm thinking something similar to ISP supplied cable modems). I'd
> see that sort of situation managed by 'private' extensions/options which
> could be agreed between the client and server - possibly as an industry
> segment standard vendor option space.
>
>
> Visit http://www.**magpiesnestpublishing.co.uk/<http://www.magpiesnestpublishing.co.uk/>for books by acclaimed
> ______________________________**_________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dhcwg<https://www.ietf.org/mailman/listinfo/dhcwg>
>