doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc2855.txt b/doc/rfc/rfc2855.txt
new file mode 100644
index 0000000..e30cb16
--- /dev/null
+++ b/doc/rfc/rfc2855.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                        K. Fujisawa
+Request for Comments: 2855                              Sony Corporation
+Category: Standards Track                                      June 2000
+
+
+                           DHCP for IEEE 1394
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   IEEE Std 1394-1995 is a standard for a High Performance Serial Bus.
+   Since 1394 uses a different link-layer addressing method than
+   conventional IEEE802/Ethernet, the usage of some fields must be
+   clarified to achieve interoperability.  This memo describes the 1394
+   specific usage of some fields of DHCP messages.
+
+1. Introduction
+
+   IEEE Std 1394-1995 is a standard for a High Performance Serial Bus.
+   IETF IP1394 Working Group specified the method to carry IPv4
+   datagrams and 1394 ARP packets over an IEEE1394 network [RFC2734].
+
+   The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a
+   framework for passing configuration information to hosts on a TCP/IP
+   network.
+
+   Since 1394 uses a different link-layer addressing method than
+   conventional IEEE802/Ethernet, the usage of some fields must be
+   clarified to achieve interoperability.  This memo describes the 1394
+   specific usage of some fields of DHCP.  See [RFC2131] for the
+   mechanism of DHCP and the explanations of each field.
+
+   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 [RFC2119].
+
+
+
+
+
+Fujisawa                    Standards Track                     [Page 1]
+
+RFC 2855                   DHCP for IEEE 1394                  June 2000
+
+
+2. Issues related to 1394 link address
+
+   With conventional link-layer protocols, such as an Ethernet, the
+   'chaddr' (client hardware address) field may be used to return a
+   reply message from a DHCP server (or relay-agent) to a client.  Since
+   a 1394 link address (node_ID) is transient and will not be consistent
+   across the 1394 bridge, we have chosen not to put it in the 'chaddr'
+   field.  A DHCP client should request that the server sends a
+   broadcast reply by setting the BROADCAST flag when 1394 ARP is not
+   possible yet.
+
+      Note: In general, the use of a broadcast reply is discouraged, but
+      we consider the impact in a 1394 network as a non issue.
+
+3. 1394 specific usage of DHCP message fields
+
+   Following rules should be used when a DHCP client is connected to an
+   IEEE1394 network.
+
+   'htype' (hardware address type) MUST be 24 [ARPPARAM].
+
+   'hlen' (hardware address length) MUST be 0.
+
+   The 'chaddr' (client hardware address) field is reserved.  The sender
+   MUST set this field to zero, and the recipient and the relay agent
+   MUST ignore its value on receipt.
+
+   A DHCP client on 1394 SHOULD set a BROADCAST flag in DHCPDISCOVER and
+   DHCPREQUEST messages (and set 'ciaddr' to zero) to ensure that the
+   server (or the relay agent) broadcasts its reply to the client.
+
+      Note: As described in [RFC2131], 'ciaddr' MUST be filled in with
+      client's IP address during BOUND, RENEWING or REBINDING state,
+      therefore, the BROADCAST flag MUST NOT be set.  In these cases,
+      the DHCP server unicasts DHCPACK message to the address in
+      'ciaddr'. The link address will be resolved by 1394 ARP.
+
+   'client identifier' option MUST be used in DHCP messages from the
+   client to the server due to the lack of the 'chaddr'.  'client
+   identifier' option may consist of any data.  Because every IP over
+   1394 node has an EUI-64 (node unique ID), the EUI-64 makes an obvious
+   'client identifier'.  1394 clients SHOULD include an EUI-64
+   identifier in the 'client identifier' option. The type value for the
+   EUI-64 is 27 [ARPPARAM], and the format is illustrated as follows.
+
+
+
+
+
+
+
+Fujisawa                    Standards Track                     [Page 2]
+
+RFC 2855                   DHCP for IEEE 1394                  June 2000
+
+
+    Code  Len   Type  Client-Identifier
+   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+   |  61 |  9  | 27  |           EUI-64 (node unique ID)             |
+   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+
+   Note that the use of other 'client identifier' type, such as a fully
+   qualified domain name (FQDN), is not precluded by this memo.
+
+   For more details, see "9.14. Client-identifier" in [RFC2132].
+
+4. Security Considerations
+
+   DHCP currently provides no authentication or security mechanisms.
+   Potential exposures to attack are discussed in section 7 of the DHCP
+   protocol specification [RFC2131].
+
+   A malicious client can falsify its EUI-64 identifier, thus
+   masquerading as another client.
+
+Acknowledgments
+
+   The author appreciates the members of the Dynamic Host Configuration
+   Working Group for their review and valuable comments.
+
+References
+
+   [RFC2734]  Johansson, P., "IPv4 over IEEE 1394", RFC 2734, December
+              1999.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, March 1997.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
+              2131, March 1997.
+
+   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+              Extensions", RFC 2132, March 1997.
+
+   [ARPPARAM] http://www.iana.org/numbers.html
+
+
+
+
+
+
+
+
+
+
+
+
+Fujisawa                    Standards Track                     [Page 3]
+
+RFC 2855                   DHCP for IEEE 1394                  June 2000
+
+
+Author's Address
+
+   Kenji Fujisawa
+   Sony Corporation
+   6-7-35, Kitashinagawa,
+   Shinagawa-ku, Tokyo, 141-0001 Japan
+
+   Phone: +81-3-5448-8507
+   EMail: fujisawa@sm.sony.co.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fujisawa                    Standards Track                     [Page 4]
+
+RFC 2855                   DHCP for IEEE 1394                  June 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fujisawa                    Standards Track                     [Page 5]
+