Browse Prior Art Database

DHCP for IEEE 1394 (RFC2855)

IP.com Disclosure Number: IPCOM000003454D
Original Publication Date: 2000-Jun-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 5 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

K. Fujisawa: AUTHOR

Related Documents

10.17487/RFC2855: DOI

Abstract

This memo describes specific usage of some fields of DHCP (Dynamic Host Configuration Protocol) messages. 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. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

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...

Processing...
Loading...