Re: proxy relay agent

[Mike Carney - Sun BOS Software <[e-mail]>]

Rob and I have already sucessfully tested a variation of this at the 
cupertino (HP) bakeoff. Here's our current (though short ;^)) writeup.

Comments welcome!





Network Working Group                                       M. W. Carney
INTERNET-DRAFT                                    Sun Microsystems, Inc.
                                                              R. Stevens
                                                  Competitive Automation
                                                            October 1995


               DHCP over PPP; use of DHCPINFORM

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

   This document describes a method of using the Dynamic Host
   Configuration Protocol (DHCP) [1] together with the Point To Point
   (PPP) [2] Protocol's Internet Protocol Control Protocol (IPCP) [3]
   to configure Internet configuration parameters on a Point To Point
   (PPP) client.

Table of Contents

    1.  Introduction ..............................................  2
    1.1 Problem definition ........................................  2
    1.2 Requirements ..............................................  3
    1.3 Terminology ...............................................  3
    2.  Internet Address Negotiation ..............................  4
    3.  Configuration of Internet Host Parameters .................  4
    4.  DHCP/PPP Server Behavior .................................   5
    5.  Acknowledgements ..........................................  5
    6.  References ................................................  6
    7.  Security Considerations ...................................  6




Carney & Stevens                                               [Page 1]

INTERNET-DRAFT       DHCP over PPP; use of DHCPINFORM       October 1995


    8.  Authors' Addresses ........................................  6

1. Introduction

   This document describes a method for providing network configuration
   information to a Point To Point Protocol (PPP) [2] client using the
   Internet Protocol Control Protocol (IPCP) [3] of PPP together with
   the Dynamic Host Configuration Protocol (DHCP) [1].

   PPP/IPCP is used to negotiate an IP address between the local and
   remote endpoints. DHCP is not used to acquire an Internet Address.

   DHCP is used to acquire internet configuration information other than
   Internet Address.

1.1 Problem definition

   PPP/IPCP provides the mechanisms for the connection of a PPP client
   to an internet, including the acquisition of IP parameters such as
   IP address, subnet mask, MTU, and default router [4]. However, IPCP
   falls short of providing internet information such as Domain Name
   Service (DNS) [9] parameters, Timezone, and time parameters (NTP [10]
   or Time Server [8]).

   The DHCP can be used in these instances to provide this information,
   through the use of the DHCPINFORM message provided by the protocol.





























Carney & Stevens                                               [Page 2]

INTERNET-DRAFT       DHCP over PPP; use of DHCPINFORM       October 1995

1.2 Requirements

   Throughout this document, 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 this specification.

      o "MUST NOT"

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

      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.

1.3 Terminology
   
   This document uses the following terms:

        o  "DHCP/PPP client"
           
           A DHCP/PPP client is host machine which connects to a network
           service provider, acquires its internet address using
           PPP/IPCP, then acquires other internet host configuration
           parameters by unicasting a DHCPINFORM message to the remote
           endpoint, and processing the resulting DHCPACK appropriately.












Carney & Stevens                                               [Page 3]

INTERNET-DRAFT       DHCP over PPP; use of DHCPINFORM       October 1995

        o  "DHCP/PPP server"

           A DHCP/PPP server is a device which a provides network
           access to DHCP/PPP clients. It provides standard PPP services
           to connecting hosts, which would use the Link Control
           Protocol (LCP) [5] to establish a link, then the Internet
           Protocol Control Protocol (IPCP) for establishing and
           configuring the Internet Protocol (IP) [4] over PPP. This
           device also listens to the User Datagram Protocol (UDP)
           [6] port for the DHCP service (67) on the established link,
           and will either act as a BOOTSTRAP Protocol (BOOTP) [7] relay
           agent and forward these DHCP datagrams to an identified
           DHCP server(s) or act as a DHCP server itself and respond
           appropriately if correctly configured.

2. Internet Address Negotiation.

   Acquisition of the DHCP/PPP client's internet address is achieved
   through the use of IPCP address negotiation between local and
   remote endpoints.  DHCP MUST NOT be used by the client to acquire
   the internet address.

   A DHCP/PPP server acquires the internet addresses for use by
   DHCP/PPP clients by any means available to it; a DHCP/PPP server
   MAY choose to acquire these internet addresses from an available
   DHCP service available on a locally connected LAN, for example.

3. Configuration of Internet Host Parameters.

   Once the DHCP/PPP client can communicate on the internet, it formats
   and unicasts a DHCPINFORM message on UDP port 67 to the remote
   endpoint, and waits for a reply. Retransmissions SHOULD use the
   retransmission algorithm defined in the DHCP. Note that the DHCP/PPP
   client SHOULD allow the waiting period to be configurable, and MAY
   choose to continue DHCP/PPP client startup without having received a
   reply to its DHCPINFORM messages.

   If a DHCPACK message is received from the remote endpoint, then the
   DHCP/PPP client MAY make use of the information contained therein to
   configure internet parameters not provided by IPCP.

   If a DHCPNAK message is received, a DHCP/PPP client MUST report the
   receipt of this message to the user, and MAY choose to:

        1) Ignore it.
        2) Abort the DHCP configuration process.

   The receipt of a DHCPNAK message indicates a configuration mismatch
   between the PPP/IPCP service and the DHCP service.





Carney & Stevens                                               [Page 4]

INTERNET-DRAFT       DHCP over PPP; use of DHCPINFORM       October 1995

4. DHCP/PPP Server Behavior.

   A DHCP/PPP Server responds to a connecting host as specified in the
   PPP [2], LCP [5], and IPCP [3] specifications. A DHCP/PPP server
   acquires the internet addresses for assignment to connecting
   DHCP/PPP clients by any means; exactly how is outside the scope of
   this document.

   A DHCP/PPP server MUST listen to UDP port 67 for DHCPINFORM messages
   on established IP connections. A DHCP/PPP server MUST handle this
   messages in one of two ways:
        
        1) The DHCP/PPP server acts as a BOOTP relay agent, and thus
           MUST provide a mechanism by which an administrator can
           configure DHCP server addresses which the DHCP/PPP server
           will use as destination addresses. A DHCP/PPP server MUST
           place the address of the remote endpoint with the DHCP/PPP
           client in the 'giaddr' field of the DHCP packet, and unicast
           the a copy of the modified DHCPINFORM message to each DHCP
           server address which has been configured. Note that since the
           DHCPINFORM message is always unicast, the use of the giaddr
           field isn't necessary for the correct delivery of DHCP
           replies to the DHCP/PPP client. However, filling in the
           'giaddr' field permits the DHCP/PPP server to detect if there
           is a mismatch in the configuration of the DHCP server(s) and
           IPCP address pool the DHCP/PPP manages. Such a mismatch is
           detected if a DHCPNAK is sent in response to a forwarded
           DHCPINFORM message. If the DHCP/PPP server detects a DHCPNAK
           message, it MUST notify the administrator of the mismatch,
           and MAY forward the DHCPNAK to the DHCP/PPP client. The
           DHCP/PPP server MUST be prepared to accept DHCPACK messages
           on UDP port 67, and forward them to the appropriate
           DHCP/PPP client on UDP port 68.

       2) The DHCP/PPP server operates as a DHCP server, as specified
          in the DHCP.

5. Acknowledgements
   
   The authors would like to acknowledge XXXX's contributions....
   













Carney & Stevens                                               [Page 5]

INTERNET-DRAFT       DHCP over PPP; use of DHCPINFORM       October 1995

6. References

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

   [2] Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992.

   [3] McGregor, G., "The PPP Internet Protocol Control Protocol
       (IPCP)", Merit Network Inc, May 1992.

   [4] Postel, J., "Internet Protocol", RFC 791, USC/Information
       Sciences Institute, September 1981.
   
   [5] Simpson, W., "PPP LCP Extensions", RFC 1548, January 1994.

   [6] Postel, J., "User Datagram Protocol", RFC 768, August 1980.

   [7] Croft, B. and Gilmore, J., "BOOTSTRAP Protocol", RFC 951,
       September 1985.

   [8] Postel, J. and Harrenstien, K., "Time Protocol", RFC 868, May 1983.

   [9] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
       1034, USC/Information Sciences Institute, November 1987.

   [10] Mills, D., "Network Time Protocol", RFC 958, September 1985.

7. Security Considerations

   Security issues are not discussed in this memo.

8. Authors' Addresses

   Mike Carney
   Sun Microsystems, Inc.
   2 Elizabeth Drive
   Chelmsford, MA 01824

   Phone: [phone]
   EMail: [e-mail]


   Rob Stevens
   Competitive Automation
   1050 University Drive, Suite 210
   Menlo Park, CA 94025

   Phone: [phone]
   EMail: [e-mail]







Carney & Stevens                                              [Page 6]


Mike Carney
SunSoft PC Networking
Chelmsford, MA