Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-relay-id-suboption-00.txt

From: Ralph Droms <[email-masked]>
Date: Mon, 8 Sep 2008 15:47:44 -0400

This message announces a WG last call on "The DHCPv4 Relay Agent
Identifier Suboption" <draft-ietf-dhc-relay-id-suboption-00.txt>.
The last call will conclude at 1700PDT on September 29, 2008.  This
document is intended for publication as a Proposed Standard.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

draft-ietf-dhc-relay-id-suboption-00.txt defines a new Relay Agent
Identifier suboption for the Dynamic Host Configuration Protocol's
(DHCP) Relay Agent Information option.  The suboption carries a unique
identifier configured or generated at the relay agent.  The suboption
allows a DHCP relay agent to include the unique identifier in the DHCP
messages it sends.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-00.txt

- John Brzozowski, Ralph Droms
   dhc WG chairs

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

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 8 Sep 2008 14:19:25 -0700

> http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-00.txt

The draft mentions in Introduction the use of the field in identifying
the client instead of the client-identifier or the chaddr field.

It doesn't seem to address or suggest server behaviour when a client
is RENEWING.  All the server would have at this stage is any identity
the client offers, which is sure to mismatch any relay-agent supplied
value, which is what the lease binding is suggested to be identified
against.

I think in particular the advice to generate a DUID for the client to
put in this field is a potentially misleading default, as for example
it would be fairly bad for a relay to manufacture a new DUID-LLT every
time it sees a given client.  I know of no reason why this would be
considered beneficial; presuming the client supplies a DUID, it would
always be preferrable.  If there is some beneficial reason for A
DUID-like identifier to be manufactured by a relay, perhaps it could
be described.

I think this draft could use some more work before going to IESG.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 8 Sep 2008 15:45:09 -0700

I also wonder if anything need be said about DDNS updates ("not doing
them").  It may not be obvious especially since DUID-based identifiers
are described as an applicable content that the client-supplied
hostname is almost certainly incorrect to apply to the relay-supplied
id...?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 9 Sep 2008 21:53:40 -0400

While I would like to see this document advance, the "administratively
configured" "string" concerns me as there is no way to distinguish these
values from the DUID formatted values? Perhaps it doesn't matter as an
id is an id, but this could result in unintended collisions (though of
course not if an ASCII readable string is used as ascii octet 0 would
not be used and all of the existing DUIDs would have a 0 value octet).
And, while it is difficult to believe we'd ever have that many DUID
formats, we never know what the future holds.

I'm also surprised with this as it wasn't considered in
draft-ietf-dhc-dhcpv6-bulk-leasequery-03.txt which defines the DHCPv6
Relay-ID option.

I guess solutions to this are:
- Don't care about it.
- Use a flag byte that identifies the identifier type (1=DUID,
2=administratively configured string, ...).
- Use two different options (not desireable, IMHO).

Also, no motivation is given for this "administratively configured"
string. I do understand why it may be desireable, I just think it needs
to be considered a bit more carefully.

One motivation/explaination of WHY relay agents do not necessarily need
UNIQUE identifiers (ie, DUID) is that they are "controlled" devices in
the administrative domain. This is unlike clients - where any client
could be connected to a network. And somewhat unlike servers, where we
want a unique identifier to avoid issues for mobile clients that might
connect to another network and so a message to a server identifier of
"server1" could easily end up with the wrong server. Relay agents aren't
[yet] mobile like this and aren't identified end-points of the
communication.

Anyway, if others in the DHC WG are comfortable with this, you can
ignore my comments and consider my support for the document.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ralph Droms (rdroms)
Sent: Monday, September 08, 2008 3:48 PM
To: DHC WG
Subject: [dhcwg] dhc WG last call on
draft-ietf-dhc-relay-id-suboption-00.txt

http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-00
.txt

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 9 Sep 2008 22:06:08 -0400

Wow. I don't really understand how you read that, but if you did, then
yes, this draft certainly needs some work!

I don't understand where the manufacturing the client's identifier
entered into the picture.

The point of that introduction was to say that a UNIQUE identifier for a
client might be formed using <relay-id><relay-port-id> -- such as for a
factory floor where a robot plugged into port 6 of switch xyz would
always be welding the door to the car regardless of what the
client-identifier or mac address is. Thus, you'd want to assign it the
"weld door to car" robot IP address.

There are already relay agent suboptions to identify the port
(remote-id, circuit-id). There isn't anything to unique identify the
relay (giaddr *might* be usable, but it has other purposes too and so is
dangerous and it is related to the network topology - for the relay
address on the server side, not the client side of the network).

Once generated, the relay-id would be stable. The remote-id/circuit-id
for a particular port would also. And, the server is expected to use the
relay-id/<remote-id or circuit-id> to identify the client in the server
-- not the client-id or mac-address.

---

There are other uses of this relay-agent id suboption -- such as the
DHCPv4 bulk leasequery work.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David W. Hankins
Sent: Monday, September 08, 2008 5:19 PM
To: DHC WG
Subject: Re: [dhcwg] dhc WG last callon
draft-ietf-dhc-relay-id-suboption-00.txt

On Mon, Sep 08, 2008 at 03:47:44PM -0400, Ralph Droms wrote:

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 10 Sep 2008 13:16:24 +0530

Hi,

    Yes. I also think it need to be a little bit more clear on certain things. I have pointed this out in the comments I sent on this draft few weeks back.

    Once those comments are taken care, I suggest to take this forward.

Thanks,
Bharat
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Bernie Volz (volz) [[email-masked]]
Sent: Wednesday, September 10, 2008 7:36 AM
To: David W. Hankins; DHC WG
Subject: Re: [dhcwg] dhc WG last        callon  draft-ietf-dhc-relay-id-suboption-00.txt

---

- Bernie

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

On Mon, Sep 08, 2008 at 03:47:44PM -0400, Ralph Droms wrote:

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Mark Stapp <[email-masked]>
Date: Wed, 10 Sep 2008 09:40:33 -0400

Hello,

yes, Bharat and I had a brief email thread back in August, and I'll 
publish a new version with some changes.

David: this isn't about cons'ing up new ids for clients. don't let an 
example from the text mislead you about what the data in the suboption 
is: it's just another relay suboption. I'll reorganize the examples to 
try to make the distinction between what the info is and how it might be 
used clerrer.

Regards,
Mark

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 10 Sep 2008 19:39:04 +0530

Just wanted to post the mail thread on which I had put up my suggestions:

http://www.ietf.org/mail-archive/web/dhcwg/current/msg08754.html

Thanks,
Bharat

________________________________
From: Mark Stapp [mailto:[email-masked]]
Sent: Wednesday, September 10, 2008 7:11 PM
To: Bharat Joshi
Cc: Bernie Volz (volz); David W. Hankins; DHC WG
Subject: Re: [dhcwg] dhc WG last callon draft-ietf-dhc-relay-id-suboption-00.txt

Hello,

yes, Bharat and I had a brief email thread back in August, and I'll publish a new version with some changes.

David: this isn't about cons'ing up new ids for clients. don't let an example from the text mislead you about what the data in the suboption is: it's just another relay suboption. I'll reorganize the examples to try to make the distinction between what the info is and how it might be used clerrer.

Regards,
Mark

Bharat Joshi wrote:

Hi,

Thanks,

Bharat

From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Bernie Volz (volz) [[email-masked]<mailto:[email-masked]>]

---

- Bernie

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf

Of David W. Hankins

To: DHC WG

.txt

against.

be described.

--

--

dhcwg mailing list

[email-masked]<mailto:[email-masked]>

Infosys e-mail system.

dhcwg mailing list

[email-masked]<mailto:[email-masked]>

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 10 Sep 2008 08:25:32 -0700

On Wed, Sep 10, 2008 at 09:40:33AM -0400, Mark Stapp wrote:
> example from the text mislead you about what the data in the suboption is: 
> it's just another relay suboption. I'll reorganize the examples to try to 
> make the distinction between what the info is and how it might be used 
> clerrer.

OK, that makes more sense.

My concern there right now is that the draft only says a relay agent
might format this new option as equal to a DUID, but gives no
directions for stable storage of that DUID or what context should be
driven to manufacture it (from packet contents or from the relay's
internal context such as its own interface addresses).

We've had problems with clients manufacturing a new DUID-LLT every
time they restart, and 3315 was pretty clear on this issue I thought.
I'm fairly concerned what we'll see if we're not clear. :)

It might make some sense, from Bernie's comments, to stick to DUID
types entirely and make "vendor or administratively supplied" id's
live under the vendor-identified DUID type, explicitly describing
the field contents as being the relay's DUID and subject to the same
rules that clients and servers use to generate their own.  If we need
a "manually configured NVT-ASCII string" DUID type, we could assign
one I think.

I got the idea somehow from the introduction and the later sections
that an admin might expect to see "sw5.etc:5/19" as the field
contents, being a switch identity concatenated with a port number,
and using that to form an identity with a lease.  I gather I'm
mistaken, and concat(relay-DUID, relay-interface-id) seems much more
reliable and extensible.

But this is a commonly requested and very useful feature, so if this
field is intended to be used in concert with other fields (relay agent
interface-id) to form an identity relationsihp with a lease, I think
we still have a RENEWING problem (maybe solved by referring to
RFC5107)?

---

From: Mark Stapp <[email-masked]>
Date: Wed, 10 Sep 2008 11:34:23 -0400

Yeah, I guess I don't think it's an issue - personally. the id is meant 
to be administratively unique; if it's not unique, there will be 
confusion. but the string "switch3" might well be unique in some 
domains, and might be preferable to a blob of hex. I can't really see 
how it's likely that a DUID and an ascii string would collide, so I'd 
prefer to leave the format as-is, I guess.

are there any other votes _for_ "add a type byte to the suboption"?

Thanks,
Mark

---

From: Mark Stapp <[email-masked]>
Date: Wed, 10 Sep 2008 11:51:37 -0400

I'm hearing these concrete issues based on your emails:

1. make it explicit that the id used, whether configured or
auto-generated, is expected to remain 'stable', which means committed
to some kind of non-volatile storage.

2. make it explicit that if the administrator depends on the relay-id
as part of client provisioning or identification, it must be available
in all the dhcp messages where the server depends on it. I think there
are several ways to deal with that: ignore RENEWs without opt-82;
permit RENEWs without checking opt-82; use server-id-override; use L2
relay.

wrt the question of the admin-configured relay-id value, I think
(personally) that it's overkill to prohibit use of a string until we've
invented and standardized a new DUID type that carries ... a string.
the id value is _meant_ to be opaque, so unless there's a real
technical reason why an admin-configured value could cause an
operational problem, I'd prefer to just leave it be.

Thanks,

Mark

David W. Hankins wrote:

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 10 Sep 2008 12:06:51 -0400

Well, there's also David's suggestion of defining a new DUID format for
this case. However, I'm not so sure that's a good idea because I suspect
it will quickly be misused (by clients -- hey, I want my cleint's DUID
to be "Bernie's system" -- but that won't really work).

Again, this is a fairly minor issue, but I'm sure if I didn't raise it
the IESG would have. Also, without an explaination of why "switch3"
might be a perfectly valid id ... I'm sure there would be objections.

- Bernie 

-----Original Message-----
From: Mark Stapp (mjs) 
Sent: Wednesday, September 10, 2008 11:34 AM
To: Bernie Volz (volz)
Cc: Ralph Droms (rdroms); DHC WG
Subject: Re: [dhcwg] dhc WG last call on

Thanks,
Mark

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 10 Sep 2008 09:17:13 -0700

On Wed, Sep 10, 2008 at 11:51:37AM -0400, Mark Stapp wrote:
> 1. make it explicit that the id used, whether configured or auto-generated,
> is expected to remain 'stable', which means committed to some kind of
> non-volatile storage.

Yes.

> 2. make it explicit that if the administrator depends on the relay-id as part
> of client provisioning or identification, it must be available in all the
> dhcp messages where the server depends on it. I think there are several ways
> to deal with that: ignore RENEWs without opt-82; permit RENEWs without
> checking opt-82; use server-id-override; use L2 relay.

Yes, that's a good way to deal with this.

> wrt the question of the admin-configured relay-id value, I think (personally)
> that it's overkill to prohibit use of a string until we've invented and
> standardized a new DUID type that carries ... a string. the id value is
> _meant_ to be opaque, so unless there's a real technical reason why an
> admin-configured value could cause an operational problem, I'd prefer to
> just leave it be.

My only concern would be that any DUID would be indistinguishable from
manually entered strings (of a very strange typecode).  The DUID uses
a concrete structure, and if at some point we have to (mis)use that
structure for some extension or deprecation, we can't really predict
what kind of problems we're making for ourselves.  It gives us less
flexibility.

Don't change it on my account, I leave the question open for WG
consensus.