[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 3046

DHC  Working Grop                                      Michael Patrick

<draft-ietf-dhc-agent-options-06.txt>                  Motorola ING

August 5, 1999

                  DHCP Relay Agent Information
Option

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.  Internet
Drafts may be updated, replaced, or obsoleted by other documents at any
time.  It is not appropriate to use Internet Drafts as reference material
or to cite them other than as a "working draft" or "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

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

   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 [4].

Abstract

   Newer high-speed public Internet access technologies call for a

   high-speed modem to have a LAN attachment to one or more customer

   premise hosts.  It is advantageous to use the Dynamic Host

   Configuration Protocol as defined in RFC 2131 [1] to assign customer

   premise host IP addresses in this environment.
   However, a number of security and scaling problems arise with such
   "public" DHCP use. This document describes a new DHCP option to address
   these issues. This option extends the set of DHCP options as defined in
   RFC 2132 [2].

   The new option is called the Relay Agent Information option and is

   inserted by the DHCP relay agent when forwarding client-originated

   DHCP packets to a DHCP server.  Servers recognizing the Relay Agent

   Information option may use the information to implement IP address or

   other parameter assignment policies. The DHCP Server echoes the

   option back verbatim to the relay agent in server-to-client replies,

   and the relay agent strips the option before forwarding the reply to

   Expires February 2000                                           [Page
1]

<draft-ietf-dhc-agent-options-06.txt>                     August 5,
1999

   the client.

   The "Relay Agent Information" option is organized as a single DHCP

   option that contains one or more "sub-options" that convey

   information known by the relay agent.  The initial sub-options are

   defined for a relay agent that is co-located in a public circuit

   access unit.  These include a "circuit ID" for the incoming circuit, a
   "remote ID" which provides a trusted identifier for the remote high-speed
   modem, and the "subnet mask" of the logical IP subnet from which the
   relay agent received the client DHCP packet.

Table of Contents

        1
Introduction........................................... 3

        1.1
High-Speed Circuit Switched Data Networks.............. 3

        1.2 DHCP
Relay Agent in the Circuit Access Equipment....... 4

        2.0 Relay Agent
Information Option......................... 6

        2.1 Agent
Operation........................................ 7

        2.1.1
Reforwarded DHCP requests............................ 8

        2.2 Server
Operation....................................... 8

        3.0 Relay Agent
Information Suboptions..................... 9

        3.1 Agent Circuit
ID....................................... 9

        3.2 Agent Remote
ID........................................ 10

        3.3 Agent Subnet
Mask...................................... 11

        4.0 Issues
Resolved........................................ 11

        5.0 Security
Considerations................................ 12

        6.0 IANA
Considerations.................................... 13

        7.0
Intellectual Property Notice........................... 13

        8.0
References............................................. 14

        9.0
Glossary............................................... 14

        10.0
Author's Address...................................... 14

Revision History

        Rev  Date               Description

        ---
--------           -----------

        -06  4/8/99             Added
editorial paragraph at end of 1.1 noting

that some host lan installations may not rely

on a centralized DHCP server.

                                Added
editorial pararaph at end of 5.0 noting

                                the
security risks of automatically reforward-

ing IP/ARP packets back downstream.

Expires February 2000
[Page 2]


<draft-ietf-dhc-agent-options-06.txt>
August 5, 1999

1   Introduction

1.1 High-Speed Circuit Switched Data
Networks

   Public Access to the Internet is usually via a circuit switched
data

   network.  Today, this is primarily implemented with dial-up modems

connecting to a Remote Access Server.  But higher speed circuit

   access
networks also include ISDN, ATM, Frame Relay, and Cable Data

   Networks.
All of these networks can be characterized as a "star"

   topology where
multiple users connect to a "circuit access unit" via

   switched or
permanent circuits.

   With dial-up modems, only a single host PC attempts
to connect to the

   central point.  The PPP protocol is widely used to
assign IP

   addresses to be used by the single host PC.

   The newer
high-speed circuit technologies, however, frequently

   provide a LAN
interface (especially Ethernet) to one or more host

   PCs.  It is desirable
to support centralized assignment of the IP

   addresses of host computers
connecting on such circuits via DHCP.

   The DHCP server can be, but usually
is not, co-implemented with the

   centralized circuit concentration access
device.  The DHCP server is

   often connected as a separate server on the
"Central LAN" to which

   the central access device (or devices) attach.

A common physical model for high-speed Internet circuit access is

   shown
in Figure 1, below.

Expires February 2000
[Page 3]


<draft-ietf-dhc-agent-options-06.txt>
August 5, 1999

                      +---------------+
|

        Central       |   Circuit     |-- ckt 1--- Modem1-- Host-|- Host
A

        LAN     |     |   Access      |                     Lan  |- Host
B

                |     |   Unit 1      |                          |- Host
C

                |-----|               |--                        |

|     |(relay agent)  |...

   +---------+  |     +---------------+

   |
DHCP   |--|

   | Server  |  |

   +---------+  |

                |

|     +---------------+

   +---------+  |     |   Circuit     |-- ckt 1---
Modem2-- Host--- Host D

   | Other   |  |     |   Access      |
Lan

   | Servers |--|-----|   Unit 2      |

   |  (Web,  |  |     |
|-- ckt 2--- Modem3-- Host--- Host E

   |   DNS)  |  |     |(relay agent)
|...                  Lan

   |         |        +---------------+

+---------+

            Figure 1:  DHCP High Speed Circuit Access Model

Note that in this model, the "modem" connects to a LAN at the user

   site,
rather than to a single host. Multiple hosts are implemented at

   this
site.  Although it is certainly possible to implement a full IP

   router at
the user site, this requires a relatively expensive piece

   of equipment
(compared to typical modem costs).  Furthermore, a

   router requires an IP
address not only for every host, but for the

   router itself. Finally, a
user-side router requires a dedicated

   Logical IP Subnet (LIS) for each
user.  While this model is

   appropriate for relatively small corporate
networking environments,

   it is not appropriate for large, public accessed
networks. In this

   scenario, it is advantageous to implement an IP
networking model that

   does not allocate an IP address for the modem (or
other networking

   equipment device at the user site), and especially not
an entire LIS

   for the user side LAN.

   Note that using this method to
obtain IP addresses means that IP

   addresses can only be obtained while
communication to the central

   site is available. Some host lan
installations may use a local DHCP

   server or other methods to obtain IP
addresses for in-house use.

Expires February 2000
[Page 4]


<draft-ietf-dhc-agent-options-06.txt>
August 5, 1999

1.2 DHCP Relay Agent in the Circuit Access Unit

   It is
desirable to use DHCP to assign the IP addresses for public

   high-speed
circuit access.  A number of circuit access units (e.g.

   RAS's, cable
modem termination systems, ADSL access units, etc)

   connect to a LAN (or
local internet) to which is attached a DHCP

   server.

   For scaling and
security reasons, it is advantageous to implement a

   "router hop" at the
circuit access unit, much like high-capacity

   RAS's do today.  The circuit
access equipment acts as both a router

   to the circuits and as the DHCP
relay agent.

   The advantages of co-locating the DHCP relay agent with the
circuit

   access equipment are:

   DHCP broadcast replies can be routed to
only the proper circuit,

   avoiding, say, the replication of the DCHP reply
broadcast onto

   thousands of access circuits;

   The same mechanism used
to identify the remote connection of the

   circuit (e.g. a user ID
requested by a Remote Access Server acting as

   the circuit access
equipment) may be used as a host identifier by

   DHCP, and used for
parameter assignment.  This includes centralized

   assignment of IP
addresses to hosts.  This provides a secure remote

   ID from a trusted
source -- the relay agent.

   A number of issues arise when forwarding DHCP
requests from hosts

   connecting publicly accessed high-speed circuits with
LAN connections

   at the host. Many of these are security issues arising
from DHCP

   client requests from untrusted sources.  How does the relay
agent

   know to which circuit to forward replies?  How does the system

prevent  DHCP IP exhaustion attacks?  This is when an attacker

   requests
all available IP addresses from a DHCP server by sending

   requests with
fabricated client MAC addresses.  How can an IP address

   or LIS be
permanently assigned to a particular user or modem?  How

   does one prevent
"spoofing" of client identifer fields used to assign

   IP addresses?  How
does one prevent denial of service by "spoofing"

   other client's MAC
addresses?

   All of these issues may be addressed by having the circuit
access

   equipment, which is a trusted component, add information to DHCP

client requests that it forwards to the DHCP server.

Expires
February 2000                                           [Page
5]

<draft-ietf-dhc-agent-options-06.txt>                     August 5,
1999

2.0 Relay Agent Information Option

   This document defines a new
DHCP Option called the Relay Agent

   Information Option.  It is a
"container" option for specific agent-

   supplied sub-options.  The format
of the Relay Agent Information

   option is:

            Code   Len
Agent Information Field

+------+------+------+------+------+------+--...-+------+

           |  82
|   N  |  i1  |  i2  |  i3  |  i4  |      |  iN  |

+------+------+------+------+------+------+--...-+------+

   The length N
gives the total number of octets in the Agent

   Information Field. The
Agent Information field consists of a sequence

   of SubOpt/Length/Value
tuples for each sub-option, encoded in the

   following manner:

SubOpt  Len     Sub-option Value

+------+------+------+------+------+------+--...-+------+

           |  1
|   N  |  s1  |  s2  |  s3  |  s4  |      |  sN  |

+------+------+------+------+------+------+--...-+------+

            SubOpt
Len     Sub-option Value

+------+------+------+------+------+------+--...-+------+

           |  2
|   N  |  i1  |  i2  |  i3  |  i4  |      |  iN  |

+------+------+------+------+------+------+--...-+------+

   No "pad"
sub-option is defined, and the Information field shall NOT

   be terminated
with a 255 sub-option.  The length N of the DHCP Agent

   Information Option
shall include all bytes of the sub-option

   code/length/value tuples. Since
at least one sub-option must be

   defined, the minimum Relay Agent
Information length is two (2).  The

   length N of the sub-options shall be
the number of octets in only

   that sub-option's value field.  A sub-option
length may be zero.  The

   sub-options need not appear in sub-option code
order.

   The initial assignment of DHCP Relay Agent Sub-options is as
follows:

                   DHCP Agent              Sub-Option Descrption

Sub-option Code

                   ---------------
----------------------

                       1                   Agent
Circuit ID Sub-option

                       2                   Agent
Remote ID Sub-option

                       3                   Agent Subnet
Mask Sub-option

Expires February 2000
[Page 6]


<draft-ietf-dhc-agent-options-06.txt>
August 5, 1999

   New sub-option codes MUST be assigned by IANA according
to the policy

   described in the "IANA Considerations" section of this
document.

2.1 Agent Operation

   Overall adding of the DHCP relay agent
option SHOULD be configurable,

   and SHOULD be disabled by default. Relay
agents SHOULD have separate

   configurables for each sub-option to control
whether it is added to

   client-to-server packets.

   A DHCP relay agent
adding a Relay Agent Information field SHALL add

   it as the last DHCP
agent option in the DHCP options field of any

   recognized DHCP packet
forwarded from a client to a server.  Such

   additions shall be made for
only those packets recognized as DHCP;

   BOOTP-only packets shall not be
affected.

   Relay agents receiving a DHCP packet with giaddr set to zero

(indicating that they are the first-hop router) but with a Relay

   Agent
Information option already present in the packet SHALL discard

   the packet
and increment an error count.

   Relay agents MAY have a configurable for
the maximum size of the DHCP

   packet to be created after appending the
Agent Information option.

   Packets which, after appending the Relay Agent
Information option,

   would exceed this configured maximum size shall be
forwarded WITHOUT

   adding the Agent Information option. An error counter
SHOULD be

   incremented in this case.  In the absence of this configurable,
the

   agent SHALL NOT increase a forwarded DHCP packet size to exceed the

MTU of the interface on which it is forwarded.

   The Relay Agent
Information option echoed by a server MUST be removed

   by the agent when
forwarding a server-to-client response back to the

   client.

   The agent
SHALL NOT add an "Option Overload" option to the packet or

   use the "file"
or "sname" fields for adding Relay Agent Information

   option.  It SHALL
NOT parse or remove Relay Agent Information options

   that may appear in
the sname or file fields of a server-to-client

   packet forwarded through
the agent.

   The operation of relay agents for specific sub-options is
specified

   with that sub-option.

   Relay agents are NOT required to
monitor or modify client-originated

   DHCP packets addressed to a server
unicast address. This  includes

   the DHCP-REQUEST sent when entering the
RENEWING state.

Expires February 2000
[Page 7]


<draft-ietf-dhc-agent-options-06.txt>
August 5, 1999

2.1.1 Reforwarded DHCP requests

   A DHCP relay agent may
receive a client DHCP packet forwarded from a

   BOOTP/DHCP relay agent
closer to the client. Such a packet will have

   giaddr as non-zero, and may
or may not already have a DHCP Relay

   Agent option in it.

   Relay agents
configured to add a Relay Agent option which receive a

   client DHCP packet
with a nonzero giaddr SHALL discard the packet if

   the giaddr spoofs a
giaddr address implemented by the local agent

   itself.

   Otherwise, the
relay agent SHALL forward any received DHCP packet

   with a valid non-zero
giaddr WITHOUT adding any relay agent options.

   Per RFC 2131, it shall
also NOT modify the giaddr value.

2.2     Server Operation

   DHCP
servers unaware of the Relay Agent Information option will

   ignore the
option upon receive and will not echo it back on

   responses.  This is the
specified server behavior for unknown

   options.

   DHCP servers claiming
to support the Relay Agent Information option

   SHALL echo the entire
contents of the Relay Agent Information option

   in all replies.  Servers
SHOULD copy the Relay Agent Information

   option as the last DHCP option in
the response.  Servers SHALL NOT

   place the echoed Relay Agent Information
option in the overloaded

   sname or file fields.  If a server is unable to
copy a full Relay

   Agent Information field into a response, it SHALL send
the response

   without the Relay Information Field, and SHOULD increment an
error

   counter for the situation.

   The operation of DHCP servers for
specific sub-options is specified

   with that sub-option.

   Note that
DHCP relay agents are not required to monitor unicast DHCP

   messages sent
directly between the client and server (i.e, those that

   aren't sent via a
relay agent). However, some relay agents MAY chose

   to do such monitoring
and add relay agent options. Consequently,

   servers SHOULD be prepared to
handle relay agent options in unicast

   messages, but MUST NOT expect them
to always be there.

Expires February 2000
[Page 8]


<draft-ietf-dhc-agent-options-06.txt>
August 5, 1999

3.0 Relay Agent Information Sub-options

3.1 Agent Circuit
ID Sub-option

   This sub-option MAY be added by DHCP relay agents which
terminate

   switched or permanent circuits.  It encodes an agent-local
identifier

   of the circuit from which a DHCP client-to-server packet was

received.  It is intended for use by agents in relaying DHCP

   responses
back to the proper circuit.  Possible uses of this field

   include

       -
Router interface number

       - Switching Hub port number

       - Remote
Access Server port number

       - Frame Relay DLCI

       - ATM virtual
circuit number

       - Cable Data virtual circuit number

   Servers MAY
use the Circuit ID for IP and other parameter assignment

   policies. The
Circuit ID SHOULD be considered an opaque value, with

   policies based on
exact string match only; that is, the Circuit ID

   SHOULD NOT be internally
parsed by the server.

   The DHCP server SHOULD report the Agent Circuit ID
value of current

   leases in statistical reports (including its MIB) and in
logs.  Since

   the Circuit ID is local only to a particular relay agent, a
circuit

   ID should be qualified with the giaddr value that identifies the

relay agent.

            SubOpt   Len     Circuit ID

+------+------+------+------+------+------+------+------+--

           |  1
|   n  |  c1  |  c2  |  c3  |  c4  |  c5  |  c6  | ...

+------+------+------+------+------+------+------+------+--

Expires February 2000                                           [Page
9]

<draft-ietf-dhc-agent-options-06.txt>                     August 5,
1999

3.2 Agent Remote ID Sub-option

   This sub-option MAY be added by
DHCP relay agents which terminate

   switched or permanent circuits and have
mechanisms to identify the

   remote host end of the circuit.  The Remote ID
field may be used to

   encode, for instance:

       -- a "caller ID"
telephone number for dial-up connection

       -- a "user name" prompted for
by a Remote Access Server

       -- a remote caller ATM address

       -- a
"modem ID" of a cable data modem

       -- the remote IP address of a
point-to-point link

       -- a remote X.25 address for X.25 connections

The remote ID MUST be globally unique.

   DHCP servers MAY use this option
to select parameters specific to

   particular users, hosts, or subscriber
modems. The option SHOULD be

   considered an opaque value, with policies
based on exact string match

   only; that is, the option SHOULD NOT be
internally parsed by the

   server.

   The relay agent MAY use this field
in addition to or instead of the

   Agent Circuit ID field to select the
circuit on which to forward the

   DHCP reply (e.g. Offer, Ack, or Nak).
DHCP servers SHOULD report this

   value in any reports or MIBs associated
with a particular client.

            SubOpt   Len     Agent Remote ID

+------+------+------+------+------+------+------+------+--

           |  2
|   n  |  r1  |  r2  |  r3  |  r4  |  r5  |  r6  | ...

+------+------+------+------+------+------+------+------+--

Expires February 2000                                          [Page
10]

<draft-ietf-dhc-agent-options-06.txt>                     August 5,
1999

3.3 Agent Subnet Mask Sub-option

   This sub-option MAY be added by
DHCP relay agents  to identify the

   subnet mask of the Logical IP Subnet
(LIS) from which the client DHCP

   packet was received.  The LIS of the
client is defined as the subnet

   formed by the giaddr ANDed with the
Agent Subnet Mask.

   Servers MAY use this mask field to automatically
create scopes of

   assignable IP addresses.  Use of this field avoids the
need to have

   identical configuration of the logical IP subnets on which
clients

   reside in both the relaying routers and the DHCP server.  In
this

   case, the router configuration defines the LISs, and the DHCP
servers

   automatically discover the LISs from the relay agent options of

forwarded client DHCP requests.

            SubOpt   Len     Agent Subnet
Mask

           +------+------+------+------+------+------+

           |  3
|   4  |  m1  |  m2  |  m3  |  m4  |

+------+------+------+------+------+------+

4.0 Issues Resolved

Broadcast Forwarding

      The circuit access equipment forwards the
normally broadcasted

      DHCP response only on the circuit indicated in
the Agent Circuit

      ID.

   DHCP Address Exhaustion

      In general,
the DHCP server may be extended to maintain a database

      with the
"triplet" of

                  (client IP address,  client MAC address,
client remote ID)

      The DHCP server SHOULD implement policies that
restrict the number

      of IP addresses to be assigned to a single remote
ID.

Expires February 2000
[Page 11]


<draft-ietf-dhc-agent-options-06.txt>
August 5, 1999

   Static Assignment

      The DHCP server may use the
remote ID to select the IP address to

      be assigned.  It may permit
static assignment of IP addresses to

      particular remote IDs, and
disallow an address request from an

      unauthorized remote ID.

   IP
Spoofing

      The circuit access device may associate the IP address
assigned by

      a DHCP server in a forwarded DHCP Ack packet with the
circuit to

      which it was forwarded. The circuit access device MAY
prevent

      forwarding of IP packets with source IP addresses -other
than-

      those it has associated with the receiving circuit.  This
prevents

      simple IP spoofing attacks on the Central LAN, and IP
spoofing of

      other hosts.

   Client Identifer Spoofing

      By using
the agent-supplied Agent Remote ID option, the untrusted

      and as-yet
unstandardized client identifer field need not be used

      by the DHCP
server.

   MAC Address Spoofing

      By associating a MAC address with an
Agent Remote ID, the DHCP

      server can prevent offering an IP address to
an attacker spoofing

      the same MAC address on a different remote
ID.

5.0 Security Considerations

   DHCP as currently defined provides no
authentication or security

   mechanisms.  Potential exposures to attack are
discussed in section 7

   of the DHCP protocol specification in RFC 2131
[1].

   This document introduces mechanisms to address several security

attacks on the operation of IP address assignment, including IP

   spoofing,
Client ID spoofing, MAC address spoofing, and DHCP server

   address
exhaustion. It relies on an implied trusted relationship

   between the DHCP
Relay Agent and the DHCP server, with an assumed

   untrusted DHCP client.
It introduces a new identifer, the "Remote

   ID", that is also assumed to
be trusted. The Remote ID is provided by

   the access network or modem and
not by client premise equipment.

   Cryptographic or other techniques to
authenticate the remote ID are

   certainly possible and encouraged, but are
beyond the scope of this

   document.

Expires February 2000
[Page 12]


<draft-ietf-dhc-agent-options-06.txt>
August 5, 1999

   Note that any future mechanisms for authenticating DHCP
client to

   server communications must take care to omit the DHCP Relay
Agent

   option from server authentication calculations. This was the

principal reason for organizing the DHCP Relay Agent Option as a

   single
option with sub-options, and for requiring the relay agent to

   remove the
option before forwarding to the client.

   While it is beyond the scope of
this document to specify the general

   forwarding algorithm of public data
circuit access units, note that

   automatic reforwarding of IP or ARP
broadcast packets back downstream

   exposes serious IP security risks.  For
example, if an upstream

   broadcast DHCP-DISCOVER or DHCP-REQUEST were
re-broadcast back

   downstream, any public host may easily spoof the
desired DHCP server.

6.0 IANA Considerations

   IANA is required to
maintain a new number space of "DHCP Relay Agent

   Sub-options", with the
initial sub-options as described in this

   document.

   IANA MUST assign
future DHCP Relay Agent Sub-options with a "IETF

   Consensus" policy as
described in RFC 2434 [3].  Future proposed

   sub-options MUST be
referenced symbolically in the internet-drafts

   that describe them, and
shall be assigned numeric codes by IANA when

   and if the draft is approved
by IESG for Proposed Standard RFC

   status.

7.0 Intellectual Property
Notices

   This section contains two notices as required by [5] for
standards

   track documents.

   Per [5], section 10.4(A):

   The IETF
takes no position regarding the validity or scope of any

   intellectual
property or other rights that might be claimed to

   pertain to the
implementation or use of the technology described in

   this document or the
extent to which any license under such rights

   might or might not be
available; neither does it represent that it

   has made any effort to
identify any such rights. Information on the

   IETF's procedures with
respect to rights in standards-track and

   standards-related documentation
can be found in BCP-11. Copies of

   claims of rights made available for
publication and any assurances of

   licenses to be made available, or the
result of an attempt made to

   obtain a general license or permission for
the use of such

   proprietary rights by implementors or users of this
specification can

   be obtained from the IETF Secretariat.

Expires
February 2000                                          [Page
13]

<draft-ietf-dhc-agent-options-06.txt>                     August 5,
1999

   Per [5] section 10.4(D):

   The IETF has been notified of
intellectual property rights claimed in

   regard to some or all of the
specification contained in this

   document.  For more information consult
the online list of claimed

   rights.

8.0 References

        [1]
Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,

Bucknell University, March 1997.

        [2]     Alexander,S. and Droms,
R., "DHCP Options and BOOTP Vendor

                Extension"  RFC 2132.

[3]     Narten,T. and Alvestrand, H. "Guidelines for Writing an

IANA Considerations Section in RFCs", RFC 2434.

        [4]     Bradner, S.
"Key words for use in RFCs to Indicate Requirement

                Levels",
RFC 2119.

        [5]     Bradner, S. "The Internet Standards Process --
Revision 3",

                RFC 2026

9.0 Glossary

           IANA
Internet Assigned Numbers Authority

           LIS     Logical IP Subnet

MAC     Message Authentication Code

           RAS     Remote Access
Server

10.0 Author's Address DS

       Michael Patrick

       Motorola
Information Systems Group

       20 Cabot Blvd., MS M4-30

       Mansfield,
MA 02048

       Phone: (508) 261-5707

       Email:
mpatrick@dma.isg.mot.com

Expires February 2000
[Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/