Please change this: The AFTR-Name option consists of option-code and option-len fields (as all DHCPv6 options have), and a variable length tunnel-endpoint- name field, containing a partially qualified host name or fully qualified domain name that refers to the AFTR the client is asked to connect to.
To this: The AFTR-Name option contains a single fully-qualified domain name, the tunnel-endpoint name field. This name may be fully- or partially- qualified, and specifies the AFTR to which the client is is expected to connect. My reason for asking for this change is that the text as it appears in the document says more than is necessary (presumably any DHCP client or server implementation already knows how to construct or unpack a DHCP option), and the extra text obscures the essence of the specification. Please change this: The OPTION_AFTR_NAME option MAY appear in the root scope of a DHCPv6 packet. It MUST NOT appear inside any IA_NA, IA_TA, IA_PD, IAADDR, or similar. Any OPTION_AFTR_NAME option received inside any other option MUST be ignored. The OPTION_AFTR_NAME option MUST NOT appear more than once in a message. Clients that receive more than one OPTION_AFTR_NAME options MUST discard all instances of that option, acting as if none were sent. To this: The OPTION_AFTR_NAME option is only valid in the root scope of a DHCPv6 packet. Any OPTION_AFTR_NAME option received inside any other option SHOULD be ignored. DHCP servers SHOULD send a maximum of one OPTION_AFTR_NAME option. Client behavior in the event that a server returns more than one such option is undefined. My reason for requesting this change is that DHCP option specifications should not place new and arbitrary requirements on DHCP servers and clients to enforce particular behaviors. It is an administrative error to configure more than one AFTR option, or to configure it in such a way that it is not returned in the root scope. It is sufficient to say that this won't work--it is not necessary to place onerous new requirements on DHCP clients and servers. Please delete the following text from section 4, for the same reason: A DHCPv6 server MUST NOT send more than one OPTION_AFTR_NAME option. A DHCPv6 server MUST NOT send the OPTION_AFTR_NAME option as a suboption in other options; it MUST appear only in the root scope of any DHCPv6 messages made in response to clients (Reply, Advertise, et al). A client that supports the B4 functionality of DS-Lite (defined in [I-D.softwire-ds-lite]) and conforms to this specification MUST include OPTION_AFTR_NAME on its OPTION_ORO. What if the client doesn't send an ORO? Because it requires DNS name to address resolution, and the use of the domain-search path, a client MAY also wish to include the OPTION_DNS_SERVERS and OPTION_DOMAIN_LIST options on its OPTION_ORO. You might want to phrase this differently: DHCP clients requesting this option SHOULD also request the OPTION_DNS_SERVERS and OPTION_DOMAIN_LIST options, since these will be required to resolve the provided FQDN. Please delete this text, since it inappropriately specifies new behavior for DHCP clients: If the client receives the OPTION_AFTR_NAME option, it MUST verify the option contents as described in Section 3. If the client receives more than one OPTION_AFTR_NAME option, it MUST discard all instances of that option. Here, wouldn't it be easier just to say that if there is no '.' label (the zero-length label) at the end of the name, you have to use the domain search list? If the tunnel-endpoint-name field has less than or equal to 2 labels (not including the terminating zero-length label), the client (B4) iterates through any configured domain-search [RFC3646] path. Thanks for publishing the new draft--sorry for all these additional edits at this late date. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
