On Sat, Dec 11, 2010 at 11:04 AM, Ted Lemon <ted.le...@nominum.com> wrote:
> DHCPv6 server administrators should not configure DHCP servers to return > more > than one AFTR-Name option in any given context. If more than one > AFTR-Name > option is sent, it will be treated as an error by the client. > After deliberation, I'm willing to relax this to SHOULD (along with the other SHOULD for multilple names in one option) and provide the operator direction. I think for the long term, DHCP servers are going to need to be able to determine when only a single value like this is "supposed" to be sent in a given option, and to provide UI hints to the operator rather than just not working and making the operator go hunt down logs on clients. That is, server validation of operator configuration should happen in the server, and not in the client (unless we're going to invest in a command channel to send client parse errors back to server operator eyes). In fact, it wouldn't be a bad idea if we described the sets of validations and limitations we want to make on DHCPv6 options in the future, so that software designers today can make a language so that new options can be defined along with correct validation of configuration. It is an error for the DHCP server to return more than one AFTR-Name > option. > If a DHCP client receives more than one AFTR-Name option, it SHOULD > ignore all > AFTR-name options. > You're also changing the target behavior; I had it picking the first value. I'm thinking of two cases in client class; clients that pass a text string (e.g., writing a config file like ISC dhclient's /sbin/dhclient-script does) are likely to just pass whatever long list of domain names the server has supplied to the configuration knob it writes out; "aftr1.foo.com aftr2.foo.com etc". In this case, we expect the B4 to use the first name and ignore the others. The second possible client implementation passes a binary structure or calling parameter to another task in the same running system; this structure probably only has one field for the name, or maybe it is just a 16 octet IPv6 address and the "dhcpv6 client" end of the software does the resolution on B4's behalf. I'm suggesting this client also should trim the list down to just the first name. I think the current language, that it MUST select the first option and MUST select the first name appearing in the first option, fits current implementation (ISC dhclient) and both environments (you'd have to reduce the long list down to fit your single parameter call-out). What I was doing, is I was referring (for simplicity's sake) to "the client" to mean either software component; the DHCPv6 client or the B4 element it is configuring, one of these two need to perform this validation (and it doesn't really matter which one). I've updated the text to add a new terminology, "a B4 system", as distinct from the B4 element and the DHCPv6 client but whose specifications may be implemented by either party (or even a third party in the middle, some common system configuration software). Hopefully this alleviates your concern that it changes DHCPv6 client behavior. -- David W. Hankins SRE Google, Inc.
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
