[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Draft                                                Sam Martel
<draft-martel-bootp-mixedlinklayers-00.txt>       Cabletron Systems Inc.

                                                              Walt Wimer
                                                       FORE Systems Inc.

                                                           February 1997


               This document EXPIRES on August 31, 1997

          BOOTP and DHCP on Mixed Media Link-Layer Networks



Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast),
   or ftp.isi.edu (US West Coast).

Abstract

   RFCs 951 [1], 1541 [2], and 1542 [3] describe the interactions of
   BOOTP [1] and DHCP [2] client, server, and relay agents.  However,
   further experience with these protocols has revealed the existence of
   an interoperability issue.  The issue occurs when a given IP subnet
   is constructed over one link-layer network inter-connected by
   translational bridges to other dissimilar link-layer networks.  The
   following information attempts to address this problem.

   It is impossible for a BOOTP or DHCP client, server, or relay agent
   to know in advance whether or not it will be operating in a mixed
   media link-layer network environment.  Given this fact, all BOOTP
   and DHCP client, server, and relay agents SHOULD adopt the
   recommendations defined in this memo.








Martel, Wimer                                                   [Page 1]


INTERNET-DRAFT       MIXED LINK-LAYER BOOTP/DHCP     Expires August 1997

Table of Contents

   1. Introduction.....................................................2
   1.1 Requirements....................................................2
   1.2 Terminology.....................................................3
   2. General Issues...................................................3
   3. Client Behavior Extension........................................3
   3.1 The 'htype' Field...............................................3
   3.2 The 'chaddr' Field..............................................4
   4. Relay Agent Behavior Extension...................................4
   4.1 The 'htype' and 'chaddr' Fields.................................4
   4.2 Additional Relay Agent Processes................................4
   5. DHCP Server Behavior Extension...................................4
   5.1 The 'htype' and 'chaddr' Fields.................................4
   5.2 Additional Server Processes.....................................5
   6. Examples.........................................................5
   6.1 IEEE 802.5 Token Ring to IEEE 802.3 Ethernet with a Relay.......5
   6.2 IEEE 802.5 Token Ring to IEEE 802.3 Ethernet without a Relay....6

1. Introduction

   Some aspects of the BOOTP and DHCP protocols need additional
   definition in order to expand compatibility with certain network
   devices.  RFCs 951, 1541, and 1542 do not adequately describe the
   behavior of BOOTP server, client, and relay agent so as to ensure
   compatibility with devices that provide layer 2 forwarding of BOOTP
   and DHCP messages.  The client, server, and relay agent need
   additional behavior definition in order to strengthen the current
   standards in these areas.  The information in this memo attempts to
   clarify the interaction of BOOTP client, server, and relay agent
   in order to increase compatibility with devices which provide layer 2
   forwarding.

   Note: This document provides additional information to further define
   the behavior of BOOTP and DHCP servers, clients, and relay agents as
   defined in RFCs 951, 1541, and 1542 and should be considered an
   extension of the original documents.

1.1 Requirements

   In this memo, the words that are used to define the significance of
   particular requirements are capitalized.  These words are:

      o "MUST"

        This word or the adjective "REQUIRED" means that the item is an
        absolute requirement of the specification.

      o "MUST NOT"

        This phrase means that the item is an absolute prohibition of
        the specification.


Martel, Wimer                                                   [Page 2]


INTERNET-DRAFT       MIXED LINK-LAYER BOOTP/DHCP     Expires August 1997



      o "SHOULD"

        This word or the adjective "RECOMMENDED" means that there may
        exist valid reasons in particular circumstances to ignore this
        item, but the full implications should be understood and the
        case carefully weighed before choosing a different course.

      o "SHOULD NOT"

        This phrase means that there may exist valid reasons in
        particular circumstances when the listed behavior is
        acceptable or even useful, but the full implications should be
        understood and the case carefully weighed before implementing
        any behavior described with this label.

      o "MAY"

        This word or the adjective "OPTIONAL" means that this item is
        truly optional.  One vendor may choose to include the item
        because a particular marketplace requires it or because it
        enhances the product, for example; another vendor may omit the
        same item.

1.2 Terminology

   This memo uses the following terms:

      BOOTREQUEST

         A BOOTP message sent from a BOOTP client to a BOOTP server
         requesting configuration information.

      BOOTREPLY

         A BOOTP message sent from a BOOTP server to a BOOTP client
         providing configuration information.

      'htype' field

         An 8 bit field contained in BOOTP and DHCP messages which
         represents the client's link-layer network type as specified in
         RFC 1700 [4], "Assigned Numbers", except where amended by this
         document.

      'chaddr' field

         A 16 byte field contained in BOOTP and DHCP messages which
         represents the link-layer address of the client.




Martel, Wimer                                                   [Page 3]


INTERNET-DRAFT       MIXED LINK-LAYER BOOTP/DHCP     Expires August 1997

2. General Issues

   An interoperability issue concerning BOOTP and DHCP messages can
   occur on networks which connect different link-layer technologies
   through devices which provide only layer 2 forwarding.  The issue can
   occur when the client is located on a link-layer network that has a
   different 'htype', as defined in the "Assigned Numbers" RFC, than
   that of the server or relay agent.  Primarily, this issue can occur
   when the relay agent or server resides on an 'htype' link-layer
   network of 1 while the client resides on an 'htype' link-layer
   network of 6.  The reverse situation can also pose potential
   problems.

   The key to ensuring proper operation revolves around the 2 fields in
   BOOTP and DHCP messages known as the 'htype' and 'chaddr'.
   Therefore, it is necessary to describe in detail how each element
   should handle these fields and the information derived therefrom.

3. Client Behavior Extension

   In addition to adhering to all applicable sections of RFCs 951, 1541,
   and 1542, the client MUST set the 'htype' and 'chaddr' as directed in
   sections 3.1 and 3.2 of this document for all BOOTP and DHCP messages
   generated by the client.

   3.1 The 'htype' Field

      The client MUST set the 'htype' field in accordance with the
      values defined in this document for the client's link-layer
      network.

      IMPORTANT NOTE:  As of the date of publication of this
      BOOTP/DHCP memo, the current Assigned Numbers document is
      RFC 1700.  RFC 1700 contains the following table (edited for
      brevity):

      Value Hardware Type (hrd)
      ----- -------------------
          1 Ethernet (10Mb)
          6 IEEE 802 Networks

      The above table suggests that all IEEE 802 networks should use an
      'htype' value of 6.  However, this does not reflect actual
      practice, and blindly following the above table will result in
      serious interoperability problems.  The table would be more
      correctly represented as:

      Value Hardware Type (hrd)
      ----- -------------------
          1 IEEE canonical format (Ethernet, IEEE 802.3, FDDI canonical)
          6 IEEE reverse canonical format (IEEE 802.5 Token Ring
            Networks)


Martel, Wimer                                                   [Page 4]


INTERNET-DRAFT       MIXED LINK-LAYER BOOTP/DHCP     Expires August 1997


      Actual practice dictates that BOOTP and DHCP clients which are
      directly connected to an IEEE 802.5 Token Ring network MUST set
      'htype' to 6, and BOOTP and DHCP clients which are directly
      connected to a DIX Ethernet, IEEE 802.3 Ethernet, or FDDI network
      MUST set 'htype' to 1.

   3.2 The 'chaddr' Field

      The bit ordering used for the link-level hardware addresses in
      the 'chaddr' field MUST be the same as the ordering used for the
      ARP protocol [5] on the client's link-level network (assuming ARP
      is defined for that network).

4. Relay Agent Behavior Extension

   In addition to adhering to all applicable sections of RFCs 951, 1541,
   and 1542, the relay agent MUST adhere to the recommendations in
   sections 4.1 and 4.2 of this document.

   4.1 The 'htype' and 'chaddr' Fields

      All relay agents MUST preserve the 'htype' and 'chaddr' fields of
      all DHCP and BOOTP messages and forward as is.  Preservation is
      necessary in order to allow the final relay agent to properly
      format a unicast response to the BOOTP client in accordance with
      RFC 1542 and this document.

   4.2 Additional Relay Agent Processes

      The final relay agent MUST reference the BOOTREPLY 'htype' field
      when building unicast BOOTREPLY messages.  The relay agent MUST
      compare the 'htype' contained in the BOOTREPLY message to the
      'htype' of the relay agent's network interface from which the
      outgoing BOOTREPLY message is about to be sent.  It MUST then
      perform any link-layer translation required in order to ensure the
      appropriate form of the link-layer address is used in the
      link-layer header of the outgoing BOOTREPLY message and/or
      corresponding ARP table entries.

      Note:  The actual value of the 'chaddr' field within the outgoing
      BOOTREPLY message MUST NOT be modified.

5. DHCP Server Behavior Extension

   In addition to adhering to all applicable sections of RFCs 951, 1541,
   and 1542, the server MUST adhere to the recommendations in sections
   5.1 and 5.2 of this document.

   5.1 The 'htype' and 'chaddr' Fields

      The server MUST copy the 'htype' and 'chaddr' fields of all
      BOOTREQUESTs to the corresponding BOOTREPLY.  The server MUST do

Martel, Wimer                                                   [Page 5]


INTERNET-DRAFT       MIXED LINK-LAYER BOOTP/DHCP     Expires August 1997


      this in order to allow the final relay agent to properly format a
      unicast response to the BOOTP client in accordance with RFC 1541
      and this document.

   5.2 Additional Server Processes

      The server MUST consider the 'htype' field when building unicast
      BOOTREPLY messages.  Therefore, the server must check the 'htype'
      contained in the BOOTREPLY message and compare it to the 'htype'
      of the server's link-layer interface.  The server MUST perform any
      translation required to ensure the correct form of the link-layer
      address is used within the link-layer header of the BOOTREPLY
      message and any ARP table entries.  (The actual value of the
      'chaddr' field within the outgoing BOOTREPLY message MUST NOT be
      modified.)

6. Examples

   6.1 IEEE 802.5 Token Ring to IEEE 802.3 Ethernet with a Relay

      --------   ----   ----------          -------          --------
      |BOOTP |  /    \  |Trans-  | ETHERNET |BOOTP| ETHERNET |BOOTP |
      |/DHCP |-|TOKEN |-|lational|----------|/DHCP|----------|/DHCP |
      |Client|  \RING/  |Switch  |          |RELAY|          |SERVER|
      --------   ----   ----------          -------          --------

      The Token Ring client's link-layer address, as represented in an
      ARP message, is 00:00:B8:E1:D2:A3.  Therefore, the client will
      generate all DHCP and BOOTP messages with the 'htype' set to 6 and
      the 'chaddr' set to 00:00:B8:E1:D2:A3.

      The message will be received by the BOOTP/DHCP relay with the
      'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3.  The relay
      will forward the message in accordance with RFC 1542, preserving
      the 'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3.

      The BOOTP/DHCP server will receive the BOOTREQUEST and process
      the message in accordance with existing procedures preserving the
      'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3.  At this
      point, the BOOTP/DHCP server determines that there is a relay
      between the client and itself and will direct the BOOTREPLY to
      the BOOTP/DHCP relay.

      The BOOTP/DHCP relay will receive the BOOTREPLY and preserve the
      'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3.  It will check
      to see if a broadcast or a unicast will be used to deliver the
      message to the client.  If a broadcast will be used, the relay
      will process the message in accordance with existing procedures.
      If a unicast will be used, the relay will need to translate the
      link-layer address attained from the BOOTREPLY message 'chaddr'
      field because its transmitting interface 'htype' is 1 and the
      BOOTREPLY 'htype' is 6.  The result is a link-layer address of

Martel, Wimer                                                   [Page 6]


INTERNET-DRAFT       MIXED LINK-LAYER BOOTP/DHCP     Expires August 1997


      00:00:1D:87:4B:C5 being used to send the unicast to the client and
      for any ARP table entry generated.  It is important to note that,
      in the BOOTREPLY, the 'chaddr' field remains set to
      00:00:B8:E1:D2:A3 and the 'htype' remains set to 6.

      The client will receive the BOOTREPLY and process it in
      accordance with existing procedures.

      NOTE:  In this example, the client is on IEEE 802.5 Token Ring
      while the server is on IEEE 802.3 Ethernet.  However, a
      translation would still be required if the server were located on
      Token Ring and the client on Ethernet or FDDI.

   6.2 IEEE 802.5 Token Ring to IEEE 802.3 Ethernet without a Relay

      --------   ----   ----------          --------
      |BOOTP |  /    \  |Trans-  | ETHERNET |BOOTP |
      |/DHCP |-|TOKEN |-|lational|----------|/DHCP |
      |Client|  \RING/  |Switch  |          |SERVER|
      --------   ----   ----------          --------

      The Token Ring client's link-layer address, as represented in an
      ARP message, is 00:00:B8:E1:D2:A3.  Therefore, the client will
      generate all DHCP and BOOTP messages with the 'htype' set to 6 and
      the 'chaddr' set to 00:00:B8:E1:D2:A3.

      The BOOTP/DHCP server will receive the BOOTREQUEST and process
      the message in accordance with existing procedures, preserving the
      'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3.  At this
      point, the BOOTP/DHCP server will determine that there is no relay
      between the client and itself will itself determine whether a
      broadcast or a unicast will be used for the BOOTREPLY.  If a
      broadcast will be used, the server will process the message in
      accordance with the existing procedures.  If a unicast will be
      used, the server will need to translate the link-layer address
      attained from the 'chaddr' field of the corresponding BOOTREQUEST
      because it's transmitting interface 'htype' is 1 and the
      BOOTREQUEST 'htype' is 6.  The result is a link-layer address of
      00:00:1D:87:4B:C5 being used to send the unicast to the client.
      It is important to note that, in the BOOTREPLY, the 'chaddr'
      field remains set to 00:00:B8:E1:D2:A3 and the 'htype' remains set
      to 6.

      The client will receive the BOOTREPLY and process it in
      accordance with existing procedures.

      NOTE:  In this example, the client is on IEEE 802.5 Token Ring
      while the server is on IEEE 802.3 Ethernet.  However, a
      translation would still be required if the server were located on
      Token Ring and the client on Ethernet or FDDI.



Martel, Wimer                                                   [Page 7]


INTERNET-DRAFT       MIXED LINK-LAYER BOOTP/DHCP     Expires August 1997



References

   [1] B. Croft, and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
       Stanford University and Sun Microsystems, September 1985.

   [2] R. Droms, "Dynamic Host Configuration Protocol", RFC 1541,
       Bucknell University, October 1993.

   [3] W. Wimer, "Clarifications and Extensions for the Bootstrap
       Protocol", RFC 1542, Carnegie Mellon University, October 1993.

   [4] J. Reynolds, and J. Postel, "Assigned Numbers", STD2, RFC 1700,
       USC/Information Sciences Institute, October 1994.


Authors' Addresses

   Sam Martel
   Product Support Engineering
   Cabletron Systems Inc.
   PO Box 5005
   Rochester, NH 03866-5005

   Phone:   (603) 332-9400
   Fax:     (603) 337-3710
   Email:   martel@ctron.com

   Walt Wimer
   Software Engineer
   FORE Systems Inc.
   Research Park
   5800 Corporate Drive
   Pittsburgh, PA  15237-5829

   Phone:   (412) 635-3387
   Fax:     (412) 635-3333
   Email:   wlw@fore.com















Martel, Wimer                                                   [Page 8]