The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option
draft-ietf-dhc-dhcpv6-fqdn-05
Yes
(Margaret Cullen)
No Objection
(Alex Zinin)
(Bill Fenner)
(Mark Townsley)
(Russ Housley)
(Sam Hartman)
Note: This ballot was opened for revision 05 and is now closed.
Margaret Cullen Former IESG member
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
(2006-03-15)
Unknown
The hash function they implemented in the dhcid is fine now (updating my old comment).
Bert Wijnen Former IESG member
No Objection
No Objection
(2006-03-16)
Unknown
In: draft-ietf-dnsext-dhcid-rr-12.txt - sect 3.6.1. client.example.com. A 10.0.0.1 IP address in examples ought to be from 192.0.2.0/24 range as per RFC3330 - sect 3.6.2 A DHCP server allocates the IPv4 address 10.0.12.99 to a client which and chi.example.com. A 10.0.12.99 Same here, IP address should be from 192.0.2.0/24 range as per RFC3330 - Sect 3.6.4 A DHCP server allocates the IPv6 address 2000::1234:5678 to a client and chi.example.com. A 10.0.12.99 IPv6 addresses in examples should be in the 2001:DB8::/32 range as per RFC3849.
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
(was Discuss)
No Objection
No Objection
(2006-03-06)
Unknown
re draft-ietf-dhc-fqdn-option-11.txt Comments from Gen-ART review by Harald Alverstrand: A smaller piece of missing material is this, from section 3.3.1 of the v4 document: Clients and servers SHOULD follow the character-set recommendations of RFC 1034 [2] and RFC 1035 [3]. However, implementers SHOULD also be aware that some client software could be using UTF-8 [10] character encoding. This specification does not require any support for UTF-8. Given DNS experts' insistence that the DNS protocol does not place any limits on character sets, it would be good to have a clearer pointer to what recommendations are intended here. Given that it's in section 3.3.1 (Deprecated ASCII encoding), one can assume that this refers to a character set recommendation for characters in the ASCII encoding; a DNS encoded name should probably be used "as is", no matter what it contains (although it would be good if the doc said so). It's also unclear from the text whether or not there's a trailing dot on the name in the deprecated ASCII encoding (there's no need for one, since a non-FQDN name can only be one component, but other fields of use have done this in the past, so it's best to be clear that this field does not do so). ------------------------- Many lesser comments on the document set at these URLs: http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-dnsext-dhcid-rr-10-alvestrand.txt http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-dhc-ddns-resolution-10-alvestrand.txt
David Kessens Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2006-03-16)
Unknown
I received a few very detailed reviews from the DNS review team. The number of isssues is that large that I believe that a revised ID is warranted. However, I don't believe that any issue in itself is enough to block this document, there are just too many of them that can easily fixed with RFC editor notes or in 48 hours. Therefore, my DISCUSS is as follows: --- Please consider the reviews form the DNS review team and update the documents where you believe it makes sense. I explicitly am not requiring you to make the proposed changes, I only want you to consider them and make the updates where you believe it makes sense. I actually ran out of space here to include all reviews so I am going to forward them to you seperately. I am also willing to clear my DISCUSS with the condition that the shepherding AD will take this issue up and deal with the revised ID. ---- I received the following comments from the DNS review team by Roy Arends that you might want to consider: This is a review of draft-ietf-dnsext-dhcid-rr-12: In general, an informative reference needs to be fixed. Terminology and examples need to be fixed, and the input construction for the digest algorithm is not clear. Review of draft-ietf-dhc-ddns-resolution-11: There is some wording that needs to be fixed, i.e. "update query" and the likes. Some references need to be fixed. Review of DRAFT-IETF-DHC-FQDN-OPTION-12: In general, draft-ietf-dhc-dhcpv6-fqdn-04.txt is mostly the same as this document. As I only review this wrt DNS, my comments will apply to both documents. --- Detailed review draft-ietf-dnsext-dhcid-rr-12: 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. please put terminology after intro. The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The DHCID RR is only defined in the IN class. DHCID RRs cause no additional section processing. The DHCID RR is not a singleton type. The term "singleton type" is not a DNS term. Where is it defined ? In DNS master files, the RDATA is represented as a single block in base 64 encoding identical to that used for representing binary data in RFC 3548 [7]. There are two alphabets in RFC3548 for base 64. Which one is used here ? The DHCID RR Digest Type Code is an identifier for the digest algorithm used. The digest is calculated over an identifier and the canonical FQDN as described in the next section. Is it ? How do I exactly calculate the digest ? See next section for more comments. The input to the digest hash function is defined to be: digest = SHA-256(< identifier > < FQDN >) what is <identifier> ? This is terribly unclear. The FQDN is represented in the buffer in unambiguous canonical form "unambiguous canonical form" is a pleonasm. Please use "Canonical Wire Format" as described in RFC 4034 [8], section 6.1. RFC 4034 section 6.1 deals with canonical ordering of names. Please refer to 6.2. The identifier type code and the identifier are related as specified in Section 3.3: the identifier type code describes the source of the identifier. A DHCPv4 updater uses the 0x0002 type code if a Client Identifier option is present in the DHCPv4 messages and it is encoded as specified in [12]. [12] is informative, not normative. If one is required to know the encoding to determine a type-code, please refer to the encoding as normative. the client. The DHCID RDATA is composed by setting the two type octets to zero, the 1-octet digest type to 1 for SHA-256, and performing an SHA-256 hash computation across a buffer containing the Ethernet MAC type octet, What is the Ethernet Mac type octet ? is that "htype, chaddr from a DHCPv4 client's DHCPREQUEST" ? If the DHCID RR type is not supported, the RDATA would be encoded [13] as: \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283 fffedeb3f75e6 ) I tried to this, and this is my result: \# 35 000001457811a1e592b6f52a81e6a7767281fb4b1379fbf2cc9645d5a2ffc9b1dd54f7 The input I used, exactly following the description in the example is as follows (base 16 string): 00000101020304050606636c69656e74076578616d706c6503636f6d00 Which breaks down to 0000 identifier type code 01 digest type 010203040506 The six octets of the mac address and the wireformat of client.example.com, which is (6)c l i e n t(7)e x a m p l e(3)c o m(0) 06636c69656e74076578616d706c6503636f6d00 When I follow the construction as specified in the previous chapter, I do not need to use the identifier type code and the digest type as input for the hash function. I tried that too, but again, different results from what you have: \# 35 0000016388f0e5221a5faa6b109dab9bdd4c2f1a3408d59c3c60b8fb45c5b6e4f0ed94 Please tell me what I did wrong. type to 1 for SHA-256, and performing a SHA-256 hash computation across a buffer containing the seven octets from the client-id option and the FQDN (represented as specified in Section 3.5). In this example, the input buffer does not contain the identifier type and the digest type, which seems correct to me. chi.example.com. A 10.0.12.99 chi.example.com. DHCID ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW L3b/NaiUDlW2No= ) If the DHCID RR type is not supported, the RDATA would be encoded [13] as: \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd 6a2503956d8da ) Okay, perfect. I got the same result. ========================================================================= Detailed review draft-ietf-dnsext-dhcid-rr-12: of the DNS data is entirely dependent on the accuracy of the configuration procedure. Sites that deploy Secure DNS [11] may [11] (rfc 2535) reference is updated by rfc 4033/4034/4035 configure credentials for each client and its assigned FQDN in a way that is more error-resistant, as both the FQDN and credentials must match. rfc 2535 and its replacements deal with origin authentication and data integrity. This is, the actual DNS data. If you mean "transaction security" such as SIG(0) and TSIG for dynamic updates, please refer to Secure Dynamic Update [10]. Certain RCODEs defined in RFC 2136 [3] indicate that the destination Nit: Don't use names and references together. please just say "Certain RCODEs defined in [3] indicate that the destination" Because these errors may indicate a misconfiguration of the updater or of the DNS server, the updater MAY attempt to signal to its administrator that an error has occurred, e.g. through a log message. What about errorcodes specific for TSIG or SIG(0) ? 5.3. Adding A and/or AAAA RRs to DNS When a DHCP client or server intends to update A and/or AAAA RRs, it starts with the update query in Section 5.3.1. A DNS message is either a Request or Response. The Request has an opcode. This opcode can be UPDATE or QUERY. So update query is confusing. This should be update request. =========================================================== Detailed review DRAFT-IETF-DHC-FQDN-OPTION-12: This document specifies a Dynamic Host Configuration Protocol for IPv4, DHCPv4, option which can be used to exchange information about a DHCPv4 client's fully-qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. I understand this option already exists, and this document updates and extends its use. I would rephrase this to: This document updates and extends the DHCP Client FQDN option for the Dynamic Host Configuration Protocol IPv4. This option can be used to exchange information about the a DHCPv4 client's fully qualified domain name. This information includes the FQDN and information about the responsibility for updating the DNS RR related to the client's address assignment. Please put terminology after the introduction. 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. In any case, whether a site permits all, some, or no DHCP servers and clients to perform DNS updates into the zones which it controls is entirely a matter of local administrative policy. Please rephrase to: It is considered local policy to permit DHCP clients and servers to perform DNS updates to zones. This document does not require any specific administrative policy, and does not propose one. Yet, the document continues to specify a range of possible policies: > The range of possible policies is very broad, from sites where only the DHCP servers have been given credentials that the DNS servers will accept, to sites where each individual DHCP client has been configured with credentials which allow the client to modify its own domain name. Compliant implementations may support some or all of these possibilities. Furthermore, I'd delete the previous paragraph. This document describes a new DHCP option which a client can use to Is it new ? If it is new, why are there deprecated elements ? convey all or part of its domain name to a DHCP server. Site- specific policy determines whether DHCP servers use the names that clients offer or not, and what DHCP servers may do in cases where clients do not supply domain names. Note that a 'part of its domain name' is not a FQDN. client sends the Client FQDN option in its DHCPDISCOVER message, it MUST send the option in subsequent DHCPREQUEST messages though the contents of the option MAY change. Only one Client FQDN option MAY appear in a message. What if a client has more than one name ? It is possible to have more than one PTR per address. The code for this option is 81. Its minimum length is 3 (octets). To avoid ambiguity, please specify that the length is excluding the Code and Len field. Code Len Flags RCODE1 RCODE2 Domain Name +------+------+------+------+------+------+-- | 81 | n | | | | ... +------+------+------+------+------+------+-- Please state somewhere that the above convention restrict name lengths to 253. In DNS, a name has a maximum length of 255. MUST send the option in subsequent DHCPREQUEST messages though the contents of the option MAY change. Only one Client FQDN option MAY appear in a message. What if a client has more than one name ? It is possible to have more than one PTR per address. The format of the Client FQDN option is: Code Len Flags RCODE1 RCODE2 Domain Name +------+------+------+------+------+------+-- | 81 | n | | | | ... +------+------+------+------+------+------+-- Please state somewhere that the above convention restrict name lengths to 253. In DNS, a name has a maximum length of 255. The format of the 1-octet Flags field is: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MBZ |N|E|O|S| +-+-+-+-+-+-+-+-+ The order of the flags below is not as it appears in the field. Does "S" indicate "Server" ? Please be consistent in using "Flags" or "Bits" in the reply from the server indicates the action to be taken by the server; if 1, the server has taken responsibility for A RR updates for the FQDN. Does "O" indicate "Override" ? The "O" bit indicates whether the server has overridden the client's preference for the "S" bit. A client MUST set this bit to 0. A server MUST set this bit to 1 if the "S" bit in its reply to the client does not match the "S" bit received from the client. What does "N" indicate ?
Jon Peterson Former IESG member
No Objection
No Objection
(2005-11-30)
Unknown
nit: dhc-ddns-resolution, Security Considerations, first sentence: "where or not" should be "whether or not"?
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Scott Hollenbeck Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2005-11-29)
Unknown
draft-ietf-dhc-ddns-resolution: Reserved domains from RFC 2606 might be better than "org.nil" in the examples.
Ted Hardie Former IESG member
No Objection
No Objection
(2005-11-28)
Unknown
In the introduction to fqdn-option, the document says: DNS ([2], [3]) maintains (among other things) the information about the mapping between hosts' Fully Qualified Domain Names (FQDNs) [8] and IP addresses assigned to the hosts. The information is maintained in two types of Resource Records (RRs): A and PTR. Obviously, there are AAAA records as well. Since they are being treated together, an informative pointer from this document to dhcpv6-fqdn seems like a good idea, especially since the ddns-resolution doc cites consistency among A, AAAA, and PTR records as one of its issues. In draft-ietf-dhc-ddns-resolution, the language in 6.3.2 was hard to follow for the case where a DHC client has multiple interfaces and wishes to associate AAAA or records containing the same fqdn with the v6 or v4 addresses associated with those interfaces.