I'm mostly okay with the draft, but there are two statements that need to be deleted:
In section 4: A DHCPv6 server MUST NOT send more than one AFTR-Name option. It SHOULD NOT permit the configuration of multiple names within one AFTR-Name option. This requires special handling for this option in DHCP servers. What you should say is this: 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. And in section 5: If the client receives more than one AFTR-Name option, it MUST use only the first instance of that option. If the AFTR-Name option contains more than one FQDN, as distinguished by the presence of multiple root labels, the client MUST use only the first FQDN listed in configuration. Instead say: 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. I'm not adamant about the second change, but I think it's the right thing to do. Generally speaking, it's not the DHCP client itself that's going to implement this restriction--it's the thing that's building the tunnel. So to implement the requirement stated in the draft, the DHCP client has to communicate a lot of information to the tunnel builder that clients ought not to have to communicate. Since it's a misconfiguration for the DHCP server to present more than one option, it seems to me that the best thing to do when more than one option appears is to simply not set up a tunnel--wait for the administrator to correct the problem, and maybe pop up a dialog box indicating what went wrong. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires