idnits 2.17.1 draft-ietf-ip1394-dhcp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 78: '... 'htype' (hardware address type) MUST be 24 [ARPPARAM]....' RFC 2119 keyword, line 80: '...' (hardware address length) MUST be 0....' RFC 2119 keyword, line 85: '...P client on 1394 SHOULD set a BROADCAS...' RFC 2119 keyword, line 89: '... Note: As described in [RFC2131], 'ciaddr' MUST be filled in with...' RFC 2119 keyword, line 91: '...e BROADCAST flag MUST NOT be set. In ...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1999) is 9021 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-ip1394-ipv4-15 -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. 'ARPPARAM' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft K. Fujisawa 2 Sony Corporation 3 Expires: February, 2000 August 1999 5 DHCP for IEEE 1394 7 Status of this memo 9 This document is an Internet-Draft and is in full conformance 10 with all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. 32 Since 1394 uses different link-layer addressing method than 33 conventional IEEE802/Ethernet, the usage of some fields must be 34 clarified to achieve interoperability. 35 This memo describes the 1394 specific usage of some fields of DHCP 36 messages. 38 1. Introduction 40 IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. 41 IETF IP1394 Working Group specified the method to carry IPv4 42 datagrams and ARP packets over an IEEE1394 network [IP1394]. 44 The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a 45 framework for passing configuration information to hosts on a TCP/IP 46 network. 48 Since 1394 uses different link-layer addressing method than 49 conventional IEEE802/Ethernet, the usage of some fields must be 50 clarified to achieve interoperability. 51 This memo describes the 1394 specific usage of some fields of DHCP. 52 See [RFC2131] for the mechanism of DHCP and the explanations of each 53 fields. 55 This document is a product of the IP1394 working group within the 56 Internet Engineering Task Force. Comments are solicited and should 57 be addressed to the working group's mailing list at 58 ip1394@mailbag.intel.com and/or the author. 60 2. Issues related to 1394 link address 62 By the conventional link-layer protocols, such as an Ethernet, the 63 'chaddr' (client hardware address) field may be used to return a 64 reply message from a DHCP server (or relay-agent) to a client. Since 65 1394 link address (node_ID) is transient and will not be consistent 66 across the 1394 bridge, we have chosen not to put it in the 'chaddr' 67 field. A DHCP client should request the server to send a broadcast 68 reply by setting the BROADCAST flag when ARP is not possible yet. 70 Note: In general, the use of a broadcast reply is discouraged, 71 but we consider the impact in a 1394 network is not an issue. 73 3. 1394 specific usage of DHCP message fields 75 Following rules should be used when a DHCP client is connected to 76 an IEEE1394 network. 78 'htype' (hardware address type) MUST be 24 [ARPPARAM]. 80 'hlen' (hardware address length) MUST be 0. 82 The 'chaddr' (client hardware address) field is reserved. The 83 recipient shall not check the value of this field. 85 A DHCP client on 1394 SHOULD set a BROADCAST flag in DHCPDISCOVER and 86 DHCPREQUEST messages to request the server (or the relay agent) to 87 send a broadcast reply if its 'ciaddr' (client IP address) is zero. 89 Note: As described in [RFC2131], 'ciaddr' MUST be filled in with 90 client's IP address during BOUND, RENEWING or REBINDING state, 91 therefore, the BROADCAST flag MUST NOT be set. In these cases, 92 the DHCP server unicasts DHCPACK message to the address in 93 'ciaddr'. The link address will be resolved by ARP. 95 'client identifier' option MUST be used in DHCP messages from the 96 client to the server due to the lack of the 'chaddr'. 'client 97 identifier' option may consist of any data. Every IP over 1394 node 98 has an EUI-64 (node unique ID) [EUI64], it is useful for a 'client 99 identifier'. When an EUI-64 is used as a 'client identifier', the 100 type value for the EUI-64 is 27 [ARPPARAM], and the format is 101 illustrated as follows. 103 Code Len Type Client-Identifier 104 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 105 | 61 | 9 | 27 | EUI-64 (node unique ID) | 106 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 108 Note that the use of other 'client identifier' type, such as a fully 109 qualified domain name (FQDN), is not precluded by this memo. 111 For more details, see "9.14. Client-identifier" in [RFC2132]. 113 Security Considerations 115 Security issues are not discussed in this document. 117 Acknowledgments 119 The author appreciates the members of the Dynamic Host Configuration 120 working group for their review and valuable comments. 122 References 124 [IP1394] P. Johansson, "IPv4 over IEEE 1394", 125 draft-ietf-ip1394-ipv4-15.txt, work in progress. 127 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, 128 March 1997. 130 [RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor 131 Extensions", RFC2132, March 1997. 133 [EUI64] http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 135 [ARPPARAM] http://www.isi.edu/in-notes/iana/assignments/arp-parameters 137 Author's address 139 Kenji Fujisawa 140 Sony Corporation 141 6-7-35, Kitashinagawa, 142 Shinagawa-ku, Tokyo, 141-0001 Japan 143 Phone: +81-3-5448-8507 144 E-mail: fujisawa@sm.sony.co.jp