[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] [dhc] #8: Response to WG last call on draft-ietf-dhc-relay-id-suboption: Conflict between relay ID and DUID
#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 | Resolution:
Keywords: |
--------------------------------+-------------------------------------------
Comment(by rdroms at cisco.com):
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/>
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg