Minutes from conf call on RFC2131 implementation issues Wed 2/25/04 ------------------------------------------------------- Participants: Ralph Droms (rdroms@cisco.com) Barr Hibbs (rbhibbs@pacbell.net) Kim Kinnear (kkineear@cisco.com) Andre Kostur (Andre@incognito.com) Rob Stevens (robs@cruzio.com) Inclusion of DHCPINFORM in specifications ----------------------------------------- The design team affirmed the previous decision not to add DHCPINFORM to the state machine in RFC2131. There may be a need to revisit the definition of when to use DHCPINFORM, based on work elsewhere on "detecting network attachment" (DNA) and recognizing that applications may use DHCPINFORM to obtain specific configuration information. Consideration of parallel work on DHCP specification ---------------------------------------------------- Work from other Internet Drafts that affects the DHCP specification will be integrated into RFC2131bis. XID consistency --------------- Clients MUST use the same XID for retransmitted messages. Otherwise, there are no restrictions on the XID supplied by the client. In particular, the client is not required to use the same XID in a DHCPDISCOVER and subsequent DHCPREQUEST. Server responding with client identifier ---------------------------------------- Servers will be required to include the client identifier in all responses. (The following text discusses sections from draft-ietf-dhc-implementation-01.txt; text not explicitly discussed is implicitly accepted.) Section 2.11: Unicast of DHCPDISCOVER ------------------------------------- The discussion of proxies (e.g., NAS, RAS) will be moved to a different document. Section 2.12; DHCPRELEASE ------------------------- The following changes will be made to table 5 of RFC 2131 for the DHCPDECLINE and DHCPRELEASE messages: * the 'sname' and 'file' fields will be marked "unused" (rather than "MAY"; note that table 5 is inconsistent in its description of the use of the 'sname' and 'file' fields) * The 'message' option will be permitted * The 'message type' option is required (table 5 has the 'options' field as "(unused)") Section 2.13: Client state diagram ---------------------------------- The state transition diagram and associated text will be checked for correctness and consistency. The text describing the diagram will clarify that the client first sends the associated message and then transitions to the next state. Section 2.14.1; Which options to return? ---------------------------------------- The server should return options according to the following priority order: * return required fields (lease time, message type, subnet mask, client ID) * return options client requested * return additional options that an admin wants (SHOULD be configurable to do so) A client MUST be prepared to accept options that it did not request, and MUST gracefully discard any options that it does not recognize. The text from the 'long options' RFC will be folded into RFC2131bis. Section 2.14.3: Option ordering ------------------------------- The client MUST NOT make any assumptions about the order of options in a DHCP message. Section 2.14.4: Options 66 and 67 --------------------------------- Because this section addresses a fundamental change to the DHCP protocol message format, it will be moved to another document. Section 2.15: Vendor Classes ---------------------------- Section 1.1 of RFC2131 will be discarded from RFC2131bis. Section 2.15.1: Character set ----------------------------- The design team was unable to reach consensus on whether the vendor class identifier should be considered an opaque value, a printable string, or some other alternative. Also, there was no consensus about use of NVT ASCII or allowing the inclusion of whitespace characters. The question will be forwarded to the dhc WG mailing list. The text from 'Vendor-Identifying Vendor Options for DHCPv4" should be considered for inclusion in RFC2131bis. Section 2.16: Client/Server Retransmission ------------------------------------------ The text on retransmission timing from RFC3315 should be reviewed for use in RFC2131bis. The issue will be posted to the dhc WG mailing list. Section 2.17: Transmission of DHCPNAKs -------------------------------------- DHCPNAKs SHOULD be broadcast unless the server knows definitively that a unicast will get to the client (e.g., client has valid address in 'yiaddr'; server is disallowing further use of that address). Various sections of RFC2131bis should be reworded for correctness and clarity. Section 2.18: Use of ciaddr --------------------------- The last sentence in this section, "Servers trust 'ciaddr,' period.", is incorrect. Servers SHOULD check 'ciaddr' for correctness. Section 2.19: Size of a BOOTP/DHCP frame ---------------------------------------- RFC2131bis should explicitly mention 300 octet lower bound for DHCP messages. Other issues - maximum size, MTU, use of fragmentation and message size options - will be discussed on the dhc WG mailing list.