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

["dhc issue tracker" <trac at tools.ietf.org>]

#8: Response to WG last call on draft-ietf-dhc-relay-id-suboption: Conflict
between relay ID and DUID
--------------------------------+-------------------------------------------
 Reporter:  rdroms at cisco.com    |       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
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg