Subject: [dhcwg] [dhc] #8: Response to WG last call on draft-ietf-dhc-relay-id-suboption: Conflict between relay ID and DUID

From: "dhc issue tracker" <[email-masked]>
Date: Wed, 10 Sep 2008 15:13:06 -0000

#8: Response to WG last call on draft-ietf-dhc-relay-id-suboption: Conflict
between relay ID and DUID
--------------------------------+-------------------------------------------
 Reporter:  [email-masked]    |       Owner:  David Hankins
     Type:  defect              |      Status:  new          
 Priority:  major               |   Milestone:               
Component:  relay-id-suboption  |     Version:               
 Severity:  In WG Last Call     |    Keywords:               
--------------------------------+-------------------------------------------
 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.

-- 
Ticket URL: <http://svn.tools.ietf.org/wg/dhc/trac/ticket/8>
dhc <http://tools.ietf.org/wg/dhc/>

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

---

From: "dhc issue tracker" <[email-masked]>
Date: Wed, 10 Sep 2008 15:15:44 -0000

Severity:  In WG Last Call     |   Resolution:               
 Keywords:                      |  

Comment(by [email-masked]):

 Bernie Volz:

 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

 Bernie Volz:

 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.

-- 
Ticket URL: <http://svn.tools.ietf.org/wg/dhc/trac/ticket/8#comment:1>
dhc <http://tools.ietf.org/wg/dhc/>

---

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

Hi Ralph,

ummm - I see you've stuck things into this neat-o tool. but I don't seem 
to be able to edit/respond to them there. maybe I need to know a bit 
more about how this is supposed to work. are you actually planning to 
manually cut-and-paste each step in the email conversation into that 
wiki page? is that really ... better than the email thread+archive 
themselves?

Thanks,
Mark

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Sep 2008 11:38:33 -0400

Mark - no, I don't intend to copy the entire thread into the trouble  
ticket.  The idea is to capture enough of the discussion to document  
consensus on resolving the issue.

I had thought about including a pointer to the initial last call  
thread (and, I suppose, any subsequent spawned threads).  I'll do that  
in the future by including a URL for the last call e-mail message  
itself in the initial last call ticket.

- Ralph

On Sep 10, 2008, at Sep 10, 2008,11:27 AM, Mark Stapp wrote:

> Hi Ralph,
>
> ummm - I see you've stuck things into this neat-o tool. but I don't  
> seem to be able to edit/respond to them there. maybe I need to know  
> a bit more about how this is supposed to work. are you actually  
> planning to manually cut-and-paste each step in the email  
> conversation into that wiki page? is that really ... better than the  
> email thread+archive themselves?
>
> Thanks,
> Mark
>
> dhc issue tracker wrote:
>> -------------------------------- 
>> +-------------------------------------------
>> -------------------------------- 
>> +-------------------------------------------

---

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

thanks, that's (somewhat) clearer. but then ... you're not expecting me 
to interact with the 'tracker' wiki at all - is that right?

the flow seems to be:

email thread starts
WG chair opens ticket
email thread continues
email thread ends
WG chair closes/updates ticket

is that right? (I mean "accurate")

-- Mark

Ralph Droms wrote:
>> seem to be able to edit/respond to them there. maybe I need to know a 
>> bit more about how this is supposed to work. are you actually

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Sep 2008 12:22:59 -0400

Mark - right, for now, John and I will do all the editing in the issue  
tracker.

Your summary of the process is correct.  We'll see if it's right.

- Ralph

On Sep 10, 2008, at Sep 10, 2008,11:43 AM, Mark Stapp wrote:

> thanks, that's (somewhat) clearer. but then ... you're not expecting  
> me to interact with the 'tracker' wiki at all - is that right?
>
> the flow seems to be:
>
> email thread starts
> WG chair opens ticket
> email thread continues
> email thread ends
>> Mark - no, I don't intend to copy the entire thread into the  
>> trouble ticket.  The idea is to capture enough of the discussion to  
>> document consensus on resolving the issue.
>>
>> thread (and, I suppose, any subsequent spawned threads).  I'll do  
>> that in the future by including a URL for the last call e-mail  
>> message itself in the initial last call ticket.
>>
>> - Ralph
>>
>>> ummm - I see you've stuck things into this neat-o tool. but I  
>>> don't seem to be able to edit/respond to them there. maybe I need  
>>> to know a bit more about how this is supposed to work. are you  
>>> actually planning to manually cut-and-paste each step in the email  
>>> conversation into that wiki page? is that really ... better than  
>>> the email thread+archive themselves?
>>>
>>> Thanks,
>>> Mark
>>>
>>> dhc issue tracker wrote: