[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Mobile IP Working Group                                       Pat Calhoun
INTERNET DRAFT                                         Gabriel Montenegro
Category: Standards Track                                 Charles Perkins
Title: draft-ietf-mobileip-calhoun-tep-01.txt      Sun Microsystems, Inc.
Date: March 1998






                            Tunnel Establishment Protocol
                        draft-ietf-mobileip-calhoun-tep-01.txt


Status of this Memo

   This document is a submission by the Mobile IP Working  Group  of  the
   Internet  Engineering Task Force (IETF).  Comments should be submitted
   to the mobile-ip@SmallWorks.COM mailing list.

   Distribution of this memo is unlimited.

   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  (North  Europe),
   ftp.nis.garr.it   (South   Europe),   munnari.oz.au   (Pacific   Rim),
   ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).


Abstract

   A general tunnel establishment protocol (TEP)  is  defined  to  handle
   multi-protocol  tunneling  as  well  as  multilevel domains guarded by
   tunnel agents which  may  be  thought  of  as  security  gateways,  or
   alternatively  as  modified  foreign agents defined by with Mobile IP.
   Mobile IP provides the model for TEP; the registration messages in RFC
   2002 establish a tunnel between the home agent and the foreign agent.




Calhoun, Montenegro, Perkins       expires September 1998        [Page 1]


INTERNET DRAFT                                                 March 1998


1. Introduction

   Tunnels are needed for a variety of  reasons  in  the  Internet.   Two
   nodes  may wish to communicate by using protocol data units (PDUs) for
   protocols other than IP that are not easily routed over  the  Internet
   infrastructure.   Such  PDUs  can,  however,  be  transmitted over the
   Internet encapsulated within IP. For remote access, one might wish  to
   set  up  a  secure  tunnel between a current point of attachment and a
   enterprise network.  Mobile IP (RFC 2002) [9] requires the creation of
   a tunnel so that the home agent can transmit IP datagrams to the care-
   of address of the mobile node.  All of these separate  needs  share  a
   common  need  for  tunnel  establishment  and management, which can be
   fulfilled by  enhancements  of  the  tunnel  establishment  procedures
   specified  in  RFC  2002  [9],  and  the  tunnel management procedures
   specified  in  RFC  2003   [7].    This   document   specifies   those
   enhancements.

   Currently, Mobile  IP  lacks  flexibility  in  how  registrations  are
   accomplished  in  that it assumes that the endpoints of the tunnel are
   mutually trusting entities that are able to and  willing  to  exchange
   registration protocol packets.

   Furthermore, it assumes that the mobile node creates the  Registration
   Request.   TEP  addresses  these  issues  by  allowing the creation of
   compound tunnels. TEP recognizes that in addition to tunnel endpoints,
   there  may be tunnel intermediate points.  Registrations are exchanged
   only between intermediate points. The result  is  a  composite  tunnel
   with some very desireable security and scalability characteristics:

      - Different security domains interface at an intermediate point,
        which provides a clean separation between segments.

      - Movement beyond a certain intermediate point only implies
        re-registrations from that point onward.

      This document  draws  on  several  previous  documents  --  notably
      "Integrated  Mobility  Extension"  [4], "Virtual Tunneling Protocol
      (VTP)" [1], and "Tunnel Set-up Protocol" [5].


1.1. Terminology

   This document uses the following terms:

      Binding

          An association between a  mobile  node's  address  and  the  IP
          address of a Tunnel Agent nearer to the mobile node.

      Chained Registration


Calhoun, Montenegro, Perkins       expires September 1998        [Page 2]


INTERNET DRAFT                                                 March 1998


          A registration in which the home agent and the mobile  node  do
          not   directly  exchange  a  Registration  Request  and  Reply.
          Rather, the request/reply is carried out between  endpoints  of
          tunnel  segments. The composition of tunnel segments represents
          the compound tunnel from home agent to mobile node.

      Downstream Agent

          The endpoint of a tunnel segment that is closer to  the  mobile
          node.  The  last downstream agent may be the mobile node itself
          or its foreign agent.

      Home Agent

          The  tunnel  agent  which  terminates  the  tunnel,  and  which
          encapsulates datagrams to be sent to the mobile node.

      Mobile Node

          The node on whose behalf the tunnel is established.

      SPI

          Acronym for "Security Parameters Index".  The combination of  a
          destination  address, and an SPI uniquely identifies a security
          association.  The SPI  is  carried  Registration  Requests  and
          Replies  to  enable the receiving system to select the SA under
          which a received packet will be processed.   An  SPI  has  only
          local  significance,  as  defined  by  the  creator  of  the SA
          (usually the receiver of the packet carrying the SPI); thus  an
          SPI  is generally viewed as an opaque bit string.  However, the
          creator of an SA may choose to interpret the bits in an SPI  to
          facilitate local processing.

      Surrogate Agent

          A tunnel agent establishing a tunnel on behalf of a mobile node
          which  does  not  take  any  active  role  in the establishment
          process.

      Surrogate Registrations

          These are registrations that are  not  created  by  the  mobile
          node.  Rather, they are created on its behalf by another entity
          (a foreign agent). This is not a new concept and is in  use  in
          commercial implementations. Nevertheless, with its introduction
          of chained registrations and compound  tunnels,  this  document
          allows  for  registrations that neither originate at the mobile
          node (i.e. they start off as surrogate registrations),  nor  do
          they  terminate  at  the home agent (i.e.  they terminate at an


Calhoun, Montenegro, Perkins       expires September 1998        [Page 3]


INTERNET DRAFT                                                 March 1998


          intermediate point at least  one  tunnel  away  from  the  home
          agent).

      Targeted Tunnel Agent

          The ultimate intended  recipient  for  a  Tunnel  Establishment
          Request.

      Tunnel Agent

          An agent which can perform encapsulation and decapsulation

      Tunnel Requestor

          Either a mobile node,  or  a  surrogate  agent  acting  on  its
          behalf.

      Upstream Agent

          The endpoint of a tunnel segment that is  closer  to  the  home
          agent. The last upstream agent is the home agent itself.


   Notice that in this document, the term "mobile node" is used  to  help
   understanding.  There is no protocol dependence upon the fact that the
   node is mobile, but we so far have not been very successful in finding
   suitable  terminology.  The previous term we had used in this document
   was  "PDU  receiver".   Similarly,  what  was  previously  called  the
   "encapsulator"  is  now  called  a  home  agent.   Finally,  what  was
   previously called  the  "decapsulator"  is  now  called  the  "foreign
   agent",  and is a tunnel agent capable of forwarding decapsulated PDUs
   from the home agent to the mobile node.


1.2. Design Goals

   One of the main objectives  in  defining  TEP  is  to  support  Mobile
   Network  Computers [11]. Given that these devices are meant to be very
   lightweight and to keep as little  state  as  possible,  TEP's  design
   goals are:

      - Simplicity.

          TEP only defines the minimum required to support the additional
          applications  and  target devices. Surprisingly little needs to
          be specified in order to adapt Mobile IP to serve as  a  remote
          access mechanism based on layer 3 forwarding.

      - Reusability.



Calhoun, Montenegro, Perkins       expires September 1998        [Page 4]


INTERNET DRAFT                                                 March 1998


          Unless otherwise  specified,  TEP  adopts  packet  formats  and
          protocol  behavior  as  specified by Mobile IP. This results in
          one protocol that solves mobility and remote access.

      - Security.

          Given the nature of remote access,  security  associations  are
          required  of  entities exchanging Registration Protocol packets
          over public sectors of the internet. Privacy and authentication
          of data transfer is also a requirement in these conditions, and
          is accomplished by using ESP [12] and optionally using AH [13].


2. Overview of tunnel establishment

   Mobile IP [9] is a tunnel between  the  home  agent  and  the  foreign
   agent, on behalf of a mobile node.

   In the Tunnel Establishment Protocol (TEP), the protocol methods  used
   by  Mobile  IP  are  modified to work between arbitrary nodes.  When a
   tunnel is established, the upstream agent (called the home agent) then
   transmits  PDUs  to  the  tunnel  endpoint  (called the foreign agent)
   according to the  tunnel  establishment  parameters.   Generally,  the
   tunnel  establishment parameters include a network address of the node
   for which the tunnel is being established,  called  the  mobile  node.
   The foreign agent may then use any of a variety of methods, to further
   transmit the decapsulated PDU so that it can be received by the mobile
   node  (one mechanism which is defined in this document). If the mobile
   node is the same node as the foreign agent, then  no  further  network
   operations are needed to deliver the PDU.

   When the home agent obtains a PDU that needs to be transmitted to  the
   mobile  node,  the  home  agent  consults  a  table  to  determine the
   appropriate tunnel endpoint for that mobile  node.   In  the  case  of
   mobile  IP, the table is indexed by the mobile node's IP address. This
   document specifies ways to allow the table  to  be  indexed  by  other
   network-layer  addresses.  Additionally, each table entry will contain
   other necessary parameters associated with the tunnel as part  of  the
   establishment  process.   The  act  of  creating or updating the table
   entry which contains all of the parameters associated to the tunnel is
   called  tunnel  establishment,  or  just  establishment.  Note  that a
   binding is the equivalent of a row (entry) in the table.

   The procedures in this document deal with the actions of four separate
   TEP  entities,  as  outlined above, called the home agent, the foreign
   agent, the gateway foreign agent, and the mobile node. For simplicity,
   it  is assumed that all home agents can also perform decapsulation and
   vice versa.  A tunnel agent is  thus  a  node  that  can  perform  the
   functions of either the home agent or the (gateway) foreign agent, and
   tunnels are said to be established between  two  tunnel  agents.   The


Calhoun, Montenegro, Perkins       expires September 1998        [Page 5]


INTERNET DRAFT                                                 March 1998


   foreign agent and mobile node may be the same node.

   This document does not specify means by which a mobile node  discovers
   a  suitable  tunnel endpoint (foreign agent) which can be used for the
   tunnel establishment.  An example of  one  such  method,  by  which  a
   mobile  node  (receiving  IP  data  units) discovers a tunnel endpoint
   called a care-of address, is  specified  as  part  of  the  Mobile  IP
   protocol, and consists of a straightforward modification of the Mobile
   Service Extension to  the  ICMP  Router  Discovery  protocol  [2],  as
   specified in Mobile IP [9]. This extension will soon be specified in a
   companion document.

   This document assumes that each tunnel endpoint will be equipped  with
   an  IP  address.   If  the  establishment  completes successfully, the
   foreign agent becomes one endpoint of a GRE  tunnel  [3].   The  other
   endpoint  is  the  home  agent.   Once  the  tunnel is established, it
   provides IP  (network  layer)  connectivity  between  the  two  tunnel
   agents.   The  tunnel appears to be a virtual point-to-point link, and
   encapsulated PDUs traverse the tunnel as if it were a single link.

   This document defines new extensions which are used with the  existing
   Mobile IP message types as defined in [9].

   Tunnel   establishment   requires    authentication.     The    tunnel
   establishment  messages  use  some  of  the  authentication extensions
   defined by [17].  This security association between receiver and  home
   agent  may  require  additional security mechanisms such as encryption
   which are not part of the tunnel establishment, but which  affect  the
   format  of  the  encapsulated datagrams which flow through the tunnel.
   Intermediate nodes which are involved with  the  tunnel  establishment
   may   additionally   impose   their  own  authentication  and  privacy
   requirements.  Such  nodes  follow  the  dictates  of  their  security
   associations  with  the other nodes with which they communicate in the
   course  of  managing  the  established  tunnel,   but   the   security
   associations  or  the  use  of them are established by policy which is
   external to TEP.

   A requesting foreign agent MAY use procedures that are  not  specified
   in  this  document  to  obtain  all  tunnel  establishment parameters,
   including authentication information for the mobile node, for  use  in
   the  Registration Request message.  Alternatively, the mobile node MAY
   (as is the case  with  mobile  IP)  transmit  a  Registration  Request
   message  to  a  prospective  tunnel  endpoint  to  enable that node to
   transact a tunnel establishment with some home agent.

   TEP specifies that the downstream agent issue the Registration Request
   message as surrogate for the mobile node.  This MAY happen as a result
   of protocol operations transacted between the foreign  agent  and  the
   mobile  node.   The  downstream  agent  could,  on  the other hand, be
   configured by any convenient means to have all  the  necessary  tunnel


Calhoun, Montenegro, Perkins       expires September 1998        [Page 6]


INTERNET DRAFT                                                 March 1998


   establishment parameters needed to issue a request message  on  behalf
   of  the mobile node.  TEP makes no restriction on the methods by which
   the foreign agent discovers the establishment parameters.


2.1. Chained Registrations

   Base Mobile IP assumes that the foreign agent  is  directly  reachable
   from  the  home  agent.   In  many  situations this is not possible or
   desirable.  For example, if the foreign agent belongs to an ISP, or  a
   wireless  carrier, it is not desirable to allow it direct reachability
   to a system (the HA) that "lives" within the private network.

   A much more secure configuration is  to  allow  the  ISP's  system  to
   directly  reach  only  as  far  as  the  private  network's gateway or
   firewall.   These  two  systems  need  to  share  some  mutual  trust,
   particularly if using surrogate registrations.

   Another separate trust relationship is then built between the  gateway
   or  firewall  system,  and  the home agent inside the private network.
   Notice that by introducing this intermediate system there  is  a  very
   clean  separation  between  external  and  internal  systems  security
   domains.

   This  configuration  is  possible  because  of  the  use  of   chained
   registrations,  whereas usual registration requests flow directly from
   the mobile node to the home agent [15].


2.2. Surrogate Registrations

   Surrogate registrations are composed on behalf  of  a  given  node  by
   another node. Consider the following network:

      MN@COA  ---------------------- GFA ----- HA

   where the mobile node has acquired a co-located address (COA).  Assume
   that  the mobile node is not allowed to exchange packets directly with
   its home agent  within  the  private  network.  Instead,  it  sends  a
   Registration Request to the gateway foreign agent (GFA) as follows:

      MN@COA, home agent = GFA.

   The gateway foreign agent is not, of course, the  mobile  node's  home
   agent. Nevertheless, it has knowledge or can obtain knowledge (perhaps
   after consulting a RADIUS database) of the mobile node's  home  agent.
   It then composes a Registration Request aimed at establishing a tunnel
   with the home agent:

      MN@GFA, home agent = HA.


Calhoun, Montenegro, Perkins       expires September 1998        [Page 7]


INTERNET DRAFT                                                 March 1998


   From the home agent's point of  view,  this  registration  request  is
   almost  indistinguishable from what it would have received from the MN
   directly.  Notice that when the mobile node roams within  the  private
   network,   mobility   is   probably   accomplished  without  surrogate
   registrations.  Hence,  Registration  Requests  like  the  above   are
   sometimes sent directly by the mobile node to the home agent.


2.3. Regionalized Tunnel Management

   The use of Hierarchical Foreign Agent  Extension  as  defined  in  [6]
   provides  TEP  with  a  method to support mobile nodes accessing their
   private home networks from a private foreign network.

          +------------------------------------+
          |      Private Foreign Network       |
          | +------+   +------+      +-------+ |
          | |  MN  |---|  FA  |------|  PFA  | |
          | +------+   +------+      +---+---+ |
          |                              |     |
          +------------------------------|-----+
                                 +-------|--------+
                                 |       |        |
                                 | Public Network |
                                 |       |        |
                                 +-------|--------+
                                         |
          +------------------------------|-----+
          |       Private Home Network   |     |
          |            +------+      +---+---+ |
          |            |  HA  |------|  PHA  | |
          |            +------+      +-------+ |
          |                                    |
          +------------------------------------+

   The above diagram provides an example of a mobile node that belongs to
   a  private network (NET 10) and temporarily visiting a foreign private
   network (NET 10).

   In this example the mobile node receives an advertisement from the  FA
   with   the   PFA's  public  IP  address.  The  mobile  node  issues  a
   Registration Request to the FA with the home agent set  to  the  PHA's
   public  address,  which  in  turn  adds  a  Hierarchical Foreign Agent
   Extension indicating its address and forwards the request to the PFA.

   The PFA keeps track of the mobile node's current point of  attachement
   as  indicated  in the hierarchical foreign agent extension and removes
   the extension. The request is then forwarded to the PHA.

   The PHA performs a lookup either locally or  through  the  use  of  an


Calhoun, Montenegro, Perkins       expires September 1998        [Page 8]


INTERNET DRAFT                                                 March 1998


   external AAA Policy Server in order to  determine  the  mobile  node's
   true home agent. Once found, the PHA adds a hierarchical foreign agent
   extension to the request and forwards the request to the HA.

   The HA is now aware that the mobile node is reachable through the  PHA
   and  will  reply  back  directly  to the PHA. The PHA will forward the
   reply back to the PFA, which will in turn forward the request  to  the
   FA.  The  FA then uses the MN's link layer address in order to forward
   the reply to it.


3. Dynamic Home Address Discovery

   It is possible for a mobile node to not have a permanently assigned IP
   address.  This is the default operating condition for a Mobile Network
   Computer.


3.1. Registering over the Internet

   When a Mobile Network Computer tries to register over the internet, it
   may  not  have  a  valid  IP address (because it is booting instead of
   resuming, or because its lease ran out).  TEP defines a  home  address
   discovery mechanism akin to the home agent discovery mechanism defined
   by Mobile IP.  In  both  cases,  a  registration  denial  carries  the
   necessary information (see Section 6).


3.2. Registering within the Corporation

   In this case, the Mobile Network  Computer  boots  using  the  Network
   Computer  model  of  obtaining  its  operating  parameters from a DHCP
   server.  One of the parameters received is the IP address to be  used.
   The  Mobile  Network  Computer  must  make sure that it receives an IP
   address valid for roaming as a Mobile IP node,  i.e.  it  must  be  an
   address  that a home agent is willing to provide forwarding service to
   [14].  The home agent could also be communicated  using  DHCP,  or  it
   could be discovered using the home agent discovery mechanism in [9].


4. Payload Encapsulation

   There are two methods which may be used to encapsulate  TEP  payloads.
   IP  in  IP  encapsulation [7] can be used to encapsulate an IP packet.
   However, TEP also  adds  multi-protocol  support  which  can  only  be
   handled  by encapsulating with GRE [3]. The encapsulation mechanism is
   negotiated during Mobility Registration and cannot be changed while  a
   binding is active.




Calhoun, Montenegro, Perkins       expires September 1998        [Page 9]


INTERNET DRAFT                                                 March 1998


4.1 Multi-Protocol Support and IP-only Foreign Agents

   There are two methods for foreign  agents  to  support  multi-protocol
   mobile  nodes.  One  is  to support all of the protocols requested and
   "route" multi-protocol packets  based  on  the  innermost  destination
   address.

   However, it is envisioned that not all  foreign  agents  will  support
   protocols  other  than  IP.  Therefore in order for an IP only foreign
   agent to support multi-protocol, it is necessary to support the Tunnel
   Identifier extension.

   When a foreign agent receives a Registration  Request  from  a  mobile
   node,  the  foreign  agent adds the Tunnel Identifier extension to the
   request.  The foreign agent MUST insert a locally unique value  within
   the most significant 16 bits of the Tunnel ID.

   When a home agent responds successfully to a Registration Request that
   included  the  Tunnel  Identifier  extension, it MUST insert a locally
   unique within the least significant 16 bits of the field.

   When the home agent receives a packet destined for the mobile node, it
   MUST  include the negotiated Tunnel ID within the KEY field of the GRE
   header. Similarly, when the foreign Agent receives a packet  from  the
   mobile  node it MUST include the Tunnel ID within the KEY field of the
   GRE header.

   If a Registration Request is sent to re-register  an  existing  tunnel
   (which  is  presumably  about  to  expire)  it is recommended that the
   foreign  agent  includes  the  negotiated  Tunnel  ID  in  the  Tunnel
   Identifier extension.


5. Security Model

   TEP  uses  the  Key  Registration  mechanisms  as  defined  in   [17].
   Specifically  when  a  mobile  node  wishes  to establish a tunnel, it
   includes  the  Foreign  Agent  Key  Request   extension   within   the
   Registration  Request.  Upon receipt the home agent includes a Foreign
   Agent Key Reply Extension and a Home-Mobile Key Reply Extension in the
   Registration Reply.


5.1. SPI Usage

   According to [9] and [19, 20] a given security association is  indexed
   by the SPI (a 32-bit number), the destination address and the security
   protocol (for example AH, ESP or Mobility Security Associations).

   The first 256 SPI values are assigned by IANA, and the  rest  MUST  be


Calhoun, Montenegro, Perkins       expires September 1998       [Page 10]


INTERNET DRAFT                                                 March 1998


   unique at the destination. There are several ways to assign  the  non-
   reserved SPIs:

      - the SPI is the result of some previous and fixed agreement
        between both parties,

      - the SPI is the result of a security association establishment
        procedure (for example [21] or assignment by a key-distribution
        center).

   Even if an SPI value has not been determined by either  of  the  above
   procedures,  secure communication may still be possible. In this case,
   the SPI value MUST be set to 0 [22]. This typically implies  that  the
   security  association  is  being  negotiated in-line using information
   found elsewhere within the datagram. This is similar to SKIP's in-line
   keying,  although in this case the SPI value of 1 has been assigned by
   IANA [22].

   Once this secure exchange is over, a non-reserved SPI MUST be assigned
   and used in subsequent messages.


6. Registration Request

   A Registration Request message is sent by the mobile node towards  the
   foreign agent which forwards the request to the home agent.

   Unless otherwise specified by the 'G' bit, the  requestor  expects  to
   receive  PDUs  encapsulated  within an IP header.  When the 'G' bit is
   set, the PDU is to be encapsulated within GRE, which  can  further  be
   encapsulated within IP.

   Since TEP requires reverse tunnels, the Registration Request MUST have
   the reverse tunnel 'T' bit set [16].

   The Registration Request  MUST  include  an  authentication  extension
   appropriate   to  the  targeted  tunnel  agent.   The  format  of  the
   authentication extension is identical to one of the extensions defined
   in   the   base   Mobile   IP   specification,  either  a  Mobile-Home
   Authentication   Extension,   or   a   Mobile-Foreign   Authentication
   Extension.  In the case of the Mobile-Foreign Authentication Extension
   the mobile node MAY use the SPI and Mobility Security Association  set
   up  when  it  obtained  a  session  key (say, using Route Optimization
   extension numbers 104 and 105 [8]), from a previous Tunnel  Parameters
   Extension  it  transacted  with  its  home  agent  and all intervening
   foreign agents at that time.

   The relative order in which different extensions, when  present,  MUST
   be placed is defined in [9].



Calhoun, Montenegro, Perkins       expires September 1998       [Page 11]


INTERNET DRAFT                                                 March 1998


7. Registration Reply

   A tunnel agent returns  a  Registration  Reply  message  to  a  tunnel
   requestor  which  has  sent a Registration Request (Section 6) message
   The Registration Reply message contains the necessary codes to  inform
   the  tunnel  requestor about the status of its Request, along with the
   lifetime granted by the targeted agent.

   When the foreign agent receives a successful  Registration  Reply,  it
   updates  its binding for the mobile node and forwards the reply to the
   mobile node.

   The multi-protocol network address(es) of  the  mobile  node  MUST  be
   included  in multi-protocol extension(s) within the Registration Reply
   as they appeared in  the  Registration  Request.  Unless  specifically
   superseded in this document, all processing of Registration Replies by
   tunnel agents is specified to be the same as the processing by  tunnel
   agents  in  the  base mobile-IP draft specification [9]. This includes
   determining the validity of the Registration  Request,  and  selecting
   the  appropriate  status  code (from among those listed below) for the
   reply.  The IP fields and UDP fields  are  chosen  just  as  with  the
   Registration Reply message in the base mobile-IP specification.

   The following value is available for use  within  the  Code  field  in
   addition to the values defined in [9] and in the most recent "Assigned
   Numbers" [10]:

          140 invalid home address

   Notice that the "invalid" home address (140) error may  occur  in  two
   cases:

      1. mobile node requires an address assignment,

      2. mobile node's lease on its previous address has expired.

   An "invalid home address" denial carries the assigned home address  in
   the home address field of the registration reply.


8. Multi-Protocol Extension

   This specification defines  the  Multi-Protocol  Extension,  which  is
   found  in  Registration Request and Reply messages.  This extension is
   denoted by the value of 128 in the extension field.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |          EtherType            |


Calhoun, Montenegro, Perkins       expires September 1998       [Page 12]


INTERNET DRAFT                                                 March 1998


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Sub-Length   |M|  reserved   |           Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      is encoded in the following Type-Length-Value format:

      Type

          TDB


      Length

          Indicates the length (in octets) of the data field within  this
          Extension.   The  length  does  NOT include the Type and Length
          octets.


      EtherType

          The EtherType indicates which network layer protocol address is
          included  in  the  Data  field, and thus the particular type of
          tunnel to be registered with the home agent.


      Sub-Length

          The length of the data following the reserved field


      M(andatory)

          When the Mandatory bit is set, the Home Agent MUST support  the
          requested extension in order to return a successful reply.


      Data

          Data  in  the  particular  format,  specified   in   subsequent
          sections,  needed  for  the establishment of tunnel appropriate
          for the Addr Family.

   Each Addr Family defines a protocol and address  format.   The  values
   for the Addr Family are compatible with those defined by GRE [3].  The
   contents of the Data field depend on  the  particular  network  layer.
   For  each value of the Addr Family, the format of the Data field is to
   be outlined in a subsequent Section.


8.1. IPX


Calhoun, Montenegro, Perkins       expires September 1998       [Page 13]


INTERNET DRAFT                                                 March 1998


   An IPX address is either 6 or 10 octets.  If  the  target  is  an  IPX
   host,  the extension MUST supply its 6 octet IEEE 802 address.  If the
   target is an IPX router, the extension MUST supply  both  its  network
   number and node number (its IEEE 802 address).

   This extension is OPTIONAL and must be  present  only  if  the  client
   being  registered supports IPX. This extension may be sent to register
   a new client  on  an  existing  tunnel  even  if  the  initial  tunnel
   establishment request did not register IPX support.

   Many instances of this extension may  be  present  in  a  registration
   request  in  the case that several IPX addresses are to be registered.
   In this case, a conventional  router  or  dial-up  router  is  serving
   multiple  IPX addresses in the remote LAN. The format of the extension
   is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |          EtherType            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Sub-Length   |M|  reserved   |       IPX Network Number      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  IPX Network Number (cont.)   |        IPX Node Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPX Node Number (cont.)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Routing Support|
      +-+-+-+-+-+-+-+-+

      EtherType

          8137h (IPX)


      Sub-Length

          12 (the length of the Data field)


      M(andatory)

          The Mandatory bit MUST be set


      reserved

          MUST be zero




Calhoun, Montenegro, Perkins       expires September 1998       [Page 14]


INTERNET DRAFT                                                 March 1998


      IPX Network

          This field contains the IPX Network number of the remote client
          (as negotiated by IPXCP for a dial-up user).


      IPX Node Number

          This field contains the IPX Node number of the remote client.


      IPX Routing Flag

          It is possible to enable a routing protocol  over  an  existing
          tunnel  only  if  one was not already negotiated. The following
          routing protocols may be used over the tunnel  by  setting  the
          following values:

             IPX_RIP          0x0001

             NLSP             0x0002

             IPXWAN_2         0x0004


8.2. AppleTalk Address Extension

   An AppleTalk address is three octets.  If the target does not yet have
   an  AppleTalk  address, the tunnel endpoint should use the address 0.0
   (three octets of all zeros).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |          EtherType            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Sub-Length   |M|Z| reserved  |       Appletalk Network       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Node number  |              Zone             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      EtherType

          809Bh (Ethertalk - Appletalk)


      Sub-Length

          5 or 7 (the length of the Data field)



Calhoun, Montenegro, Perkins       expires September 1998       [Page 15]


INTERNET DRAFT                                                 March 1998


      M(andatory)

          The Mandatory bit MUST be set


      Z(one)

          If set, the Zone field is present


      Appletalk Network

          Two octets for the Appletalk network number


      Node number

          One octet for the Appletalk node number


      Zone

          If present, an unsigned integer indicating the  Zone  in  which
          the Appletalk Address is located.


8.3. Vines Address Extension

   A Vines address is either 6 or 10 octets.  If the target  is  a  Vines
   host,  it  MUST supply its 6 octet Vines address (normally an IEEE 802
   address).  If the target is a Vines router, it MUST  supply  both  its
   Vines address and the subnet number.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |          EtherType            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Sub-Length   |M|  reserved   |       Vines Node Number ...   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            ...  Vines Node Number, continued.                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Vines subnet Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      EtherType

          0BADh (Vines)




Calhoun, Montenegro, Perkins       expires September 1998       [Page 16]


INTERNET DRAFT                                                 March 1998


      Sub-Length

          12 (the length of the Data field)


      M(andatory)

          The Mandatory bit MUST be set


      reserved

          MUST be zero


      Vines Node Number

          This field contains the Vines Node number of the remote client.


      Vines Network

          This field contains the Vines  Network  number  of  the  remote
          client.


8.4. CLNP Address Extension

   CLNP uses NSAPs as its addresses, which are of variable length. If the
   target knows its NET (NSAP with an NSEL of 0), it MUST Include its NET
   in the extension.  Targets which do not know their NET May  specify  a
   zero length address.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |          EtherType            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Sub-Length   |M|  reserved   |       NSAP ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      EtherType

          00FEh (OSI)


      Sub-Length

          12 (the length of the Data field)



Calhoun, Montenegro, Perkins       expires September 1998       [Page 17]


INTERNET DRAFT                                                 March 1998


      M(andatory)

          The Mandatory bit MUST be set


      reserved

          MUST be zero

      NSAP

          Network address for use by NSAP


9. Tunnel Establishment Protocol Extensions

   This section contains several optional TEP  extensions  which  MAY  be
   used during the registration process.


9.1. Client-Identifier Extension

   The Client-Identifier Extension contains the user or hosts name in the
   format  defined  in  [18] and serves two purposes. First and foremost,
   this extension MAY be used by intermediate foreign agents in order  to
   identify   a  user's  domain  for  authentication,  authorization  and
   accounting purposes.

   When  a  foreign  agent  receives  a  TEP  request,  it  can  form  an
   Authentication/  Authorization  request and forward the request to its
   AAA Server to see if the local policy authorizes the  mobile  node  to
   use  the services requested. Simply using an IP address is problematic
   since it does not necessarily identify the user's domain.

   The Client-Identifier Extension is also used if  the  mobile  node  is
   requesting dynamic home address discovery. In this case since the home
   address is set to zero (0) the foreign agent can only rely on  the  ID
   field,  which  is  not  guaranteed to be unique across multiple mobile
   nodes. The Client-Identifier does provide sufficient  information  for
   the  foreign  agent  (or  downstream  agent)  to uniquely identify the
   mobile node. The home agent  (or  upstream  agent)  MUST  return  this
   identifier  in the Registration Reply for the foreign agent to be able
   to resolve which mobile node it is intended for.

   The Client-Identifier Extension defined below serves this purpose.

   The Client-Identifier Extension MUST appear  before  the  TEP-required
   Foreign-Home  Authentication  Extension.  It SHOULD appear immediately
   before it.



Calhoun, Montenegro, Perkins       expires September 1998       [Page 18]


INTERNET DRAFT                                                 March 1998


   As per section 1.9 of [9], the type value of TDB  implies  that  if  a
   node  encounters  a  Client-Identifier  Extension  in  a  Registration
   Request or Reply, it MAY silently ignore it. This  implies  that  home
   agents  that  comply  with  Mobile  IP,  but  are  unaware  of the TEP
   extension MAY still be used, as long  as  the  mobile  node  does  not
   attempt home address discovery.

   TEP home agents that support Mobile Network Computers MUST  understand
   the  Client-Identifier  Extension  and  return it in its replies.  The
   reason is that Mobile Network Computers may attempt to register  using
   a   certain   home   address   whose  DHCP  lease  may  have  expired.
   Furthermore, two or more Mobile Network Computers may attempt  to  use
   the  same  home  address.  Without the Client-Identifier Extension the
   foreign agent (or downstream agent)  may  be  unable  to  resolve  the
   conflict.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Client-Identifier...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

          TDB


      Length

          8


      Reserved

          0


      Client-Identifier

          Contains the Client's username  or  host  name  in  the  format
          defined in [18].


9.2. VPN Identifier Extension

   The VPN Identifier Extension has no significance when the  Home  Agent
   belongs  to  the MN's home network. However there are current services
   already deployed which allow service providers to own the HA and share


Calhoun, Montenegro, Perkins       expires September 1998       [Page 19]


INTERNET DRAFT                                                 March 1998


   it among many customers.

   There are some  obvious  security  considerations  since  the  service
   providers  want  to  ensure  that  these  customers cannot access each
   other's networks through the shared HA.

   The VPN Identifier allows the shared HA to know which domain a  mobile
   node  belongs  to,  and furthermore only permits routing of the mobile
   node's packet to routes which are tagged with the same VPN Identifier.

   Implementation details of how  a  shared  HA  can  handle  routes  for
   multiple domains is outside the scope of this specification.

   The optional VPN Identifier extension MAY be present in a Registration
   Request.  If  present  the  VPN  Identifier  MUST  be  returned in the
   Registration Reply (even if not used by the HA).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        VPN Identifier                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          VPN Name...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

          TDB


      Length

          >8


      Reserved

          0


      VPN Identifier

          The VPN Identifier is a numerical representation of  a  domain.
          This identifier is assigned by the service provider and must be
          unique within the mobile network.

          It is common for a foreign agent to retrieve this value from an
          authentication service such as RADIUS.


Calhoun, Montenegro, Perkins       expires September 1998       [Page 20]


INTERNET DRAFT                                                 March 1998


      VPN Name

          This optional field contains the ASCII  representation  of  the
          VPN  identifier  (i.e.  ABC.COM).  The  length  of the field is
          computed using the length (less the size of the VPN  Identifier
          field).


9.3. Dynamic-Connection Extension

   The Dynamic Connection Extension  is  used  when  a  service  provider
   provides  a  Gateway  Foreign Agent or a Home Agent within its network
   and the link to the customer network is over a WAN.

   The information contained in this extension should  be  sufficient  in
   order  for  the  GFA or HA to communicate or establish a link with the
   CPE device.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Link Type           |          Address...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

          TDB


      Length

          >8


      Reserved

          0


      Link Type

          The Link Type field contains a numerical representation of  the
          underlying  link  to use in order to connect to the CPE device.
          The following have already been defined:

             VTP_FR_PVC                      0x0001
                When set, the address refers to a Frame  Relay  Permanent
                Virtual Circuit.


Calhoun, Montenegro, Perkins       expires September 1998       [Page 21]


INTERNET DRAFT                                                 March 1998


             VTP_FR_SVC                      0x0002
                When set, the address refers to a  Frame  Relay  Switched
                Virtual Circuit.

             VTP_ATM_PVC                     0x0003
                When set, the address refers to an ATM Permanent  Virtual
                Circuit.

             VTP_ATM_SVC                     0x0004
                When set, the address refers to an ATM  Switched  Virtual
                Circuit.

             VTP_X25_PVC                     0x0005
                When set, the address refers to a X.25 Permanent  Virtual
                Circuit.

             VTP_X25_SVC                     0x0006
                When set, the address refers to a X.25  Switched  Virtual
                Circuit.


      Address

          A link layer address that the  GFA  or  HA  uses  in  order  to
          communicate or establish a link with the CPE device. The length
          of the address field is determined by the  length  field  (less
          the size of the reserved and link type field).


9.4. Tunnel-Identifier Extension

   The optional Tunnel Identifier MAY be added in a Registration  Request
   by  the  foreign  agent.  This  extension MUST NOT be used if IP-in-IP
   encapsulation is requested.

   The Tunnel Identifier added  by  the  foreign  agent  MUST  include  a
   locally  unique  value in the most significant 16 bits. The home agent
   MUST include a locally unique value within the  least  significant  16
   bits.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        VPN Identifier                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Tunnel Identifier                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun, Montenegro, Perkins       expires September 1998       [Page 22]


INTERNET DRAFT                                                 March 1998


      Type

          TDB


      Length

          >8


      Reserved

          0


      Tunnel ID

          The  Tunnel  Identifier  contains  the  GRE  session  ID.  This
          identifier  is  used  within  each  GRE  header to indicate the
          session associated with with the payload.


10. Hierarchical Foreign Agent Extension

   One or more Hierarchical Foreign Agent Extension MAY be present  in  a
   Registration  Request  or Reply. If more than one Hierarchical Foreign
   Agent Extension is present, the order  of  these  extensions  MUST  be
   maintained through the hierarchy.

   When replying with a Registration Reply, the Home  Agent  MUST  ensure
   that  the  order  of  the  Hierarchical  Foreign  Agent extensions are
   reversed. (PRC?!?)

   If the hierarchical Foreign Agent Extension is present in the Request,
   Each  foreign  agent  MUST  check  to  make  sure  that its address is
   Included in the list of tunnel agents. If not, it rejects the  Request
   with a status code of 70.

   Otherwise, the foreign agent makes note of the  address  of  the  next
   lower-level  tunnel  agent,  for  future  association  with the mobile
   node's network address.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |        Reserved               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Next Level Care-of Address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun, Montenegro, Perkins       expires September 1998       [Page 23]


INTERNET DRAFT                                                 March 1998


      Type

          TDB


      Length

          6


      Reserved

          0


      Foreign Agent Address

          The IP Address of the next Foreign Agent in the hierarchy.


11. Mobile Node Considerations

   The tunnel requestor MAY also  include  at  least  one  multi-protocol
   extension  as  well as Tunnel establishment extensions.  Only one such
   extension MAY be included per additional network layer protocol.  Note
   that  a tunnel requestor may change which ethertypes are to be used by
   establishing a tunnel  with  different  ethertype  extensions  in  its
   establishment packets.

   If the mobile node receives a successful Reply message  containing  an
   Tunnel  Establishment  extension,  the  mobile node should immediately
   establish a GRE tunnel with the home agent as the  other  endpoint  of
   the tunnel.  Then, all data packets at the mobile node with a next hop
   of the home agent will be tunneled to the home agent using GRE over IP
   as  the  transport  mechanism.   This  includes  IP packets.  Once the
   packet reaches the home agent, the outer header (IP)  and  GRE  header
   are  stripped  and  the  packet  is submitted for local processing, as
   appropriate for the particular network layer protocol.


12. Foreign Agent Considerations

   The foreign agent MUST copy the Tunnel  Establishment  extension  from
   the  Mobile  Request to the Establishment Request without modifying it
   in any way.  The foreign agent MUST NOT reject a Mobile Request due to
   the  presence  or  contents of any well formed Tunnel Establishment or
   multi-protocol extensions.

   Foreign Agents that support IP only wishing to provide  multi-protocol
   support MUST support the Tunnel Identifier extension.


Calhoun, Montenegro, Perkins       expires September 1998       [Page 24]


INTERNET DRAFT                                                 March 1998


13. Home Agent Considerations

   The home agent  MAY  reject  an  Registration  Request  based  on  the
   contents  of  an  multi-protocol  or  any  other  Tunnel Establishment
   extensions.  If the home agent accepts a Registration Request with  an
   multi-protocol  extension,  it MUST provide connectivity to the mobile
   node for the network layer protocol described  in  the  multi-protocol
   extension.  Further, the multi-protocol extensions MUST be copied into
   the Reply message.

   If the home agent accepts a Registration Request  with  an  Integrated
   Mobility extension, the request MUST also have a Local Care-Of Address
   extension.  The home agent MUST use the Local Care-Of Address  as  the
   tunnel  endpoint  and MUST establish a GRE tunnel to the Local Care-Of
   Address.

   Once the GRE tunnel is established, a PDU arriving at the  home  agent
   for the mobile node will be tunneled to the receiver using GRE over IP
   as the transport mechanism.  Note that this includes IP packets.  Once
   the  packet  reaches  the  mobile  node, the outer header (IP) and GRE
   header are stripped and the packet is submitted for local  processing,
   as appropriate for the particular network layer protocol.


14. Security

   Tunnel establishment follows the design philosophy of  the  Mobile  IP
   specification   to   provide   accceptable   authentication   of   the
   establishment process.  This document does not discuss confidentiality
   of user data.

   Note that tunnel establishment often has the effect of controlling and
   possibly  redirecting data streams to new points of attachment for the
   mobile node.  Thus, failure to provide  sufficient  authentication  of
   Registration   Request  messages  can  have  the  effect  of  allowing
   malicious disruption of traffic which is supposed to  be  received  by
   the  mobile  node.  Even failure to properly authenticate Registration
   Reply messages could have the effect of masking control or data errors
   in the establishment process.


15. Acknowledgements Acks anyone??? (PRC)


16. References

   [1] Pat R. Calhoun and Ellis Won.  Virtual Tunneling Protocol
       (VTP).  draft-calhoun-vtp-protocol-00.txt, July 1996.  (work in
       progress).



Calhoun, Montenegro, Perkins       expires September 1998       [Page 25]


INTERNET DRAFT                                                 March 1998


   [2] Stephen E. Deering, Editor.  ICMP Router Discovery Messages.
       RFC 1256, September 1991.

   [3] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina.  Generic
       Routing Encapsulation (GRE).  RFC 1701, October 1994.

   [4] T. Li and Y. Rekhter.  Integrated Mobility Extension.
       draft-ietf-mobileip-integrated-00.txt, March 1994.  (work in
       progress).

   [5] G. Montenegro.  Tunnel Set-up Protocol (TSP).
       draft-montenegro-tsp-00.txt, August 1997.  (work in progress).

   [6] C. Perkins.  Mobile-IP Local Registration with Hierarchical
       Foreign Agents.  draft-perkins-mobileip-hierfa-00.txt, February
       1996.  (work in progress).

   [7] Charles Perkins.  IP Encapsulation within IP.  RFC 2003, May
       1996.

   [8] Charles E. Perkins and David B. Johnson.  Route Optimization in
       Mobile-IP.  draft-ietf-mobileip-optim-07.txt, November 1997.
       (work in progress).

   [9] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
       1996.

  [10] Joyce K. Reynolds and Jon Postel.  Assigned Numbers.  RFC 1700,
       October 1994.

  [11] Mobile Network Computer Reference Specification, June 1997.
       http://www.internet.ibm.com/computers/networkstation/os/mncrs.html

  [12] S. Kent, R. Atkinson. IP Encapsulating Payload -- work in
       progress, draft-ietf-ipsec-esp-v2-00.txt, July 1997
       (obsoletes RFC 1827, August 1995).

  [13] S. Kent, R. Atkinson.  IP Authentication Header -- work in
       progress, draft-ietf-ipsec-auth-header-01.txt, July 1997
       (obsoletes RFC 1826, August 1995).

  [14] S. Alexander, R. Droms. DHCP Options and BOOTP Vendor Extensions.
       RFC 2132.

  [15] V Gupta, S. Glass. Firewall Traversal for Mobile IP: Guidelines
       for Firewalls and Mobile IP entities.
       draft-ietf-mobileip-firewall-trav-00.txt, March 1997. (work in
       progress).

  [16] G. Montenegro. Reverse Tunneling for Mobile IP.


Calhoun, Montenegro, Perkins       expires September 1998       [Page 26]


INTERNET DRAFT                                                 March 1998


       draft-ietf-mobileip-tunnel-reverse-05.txt, January 1998.
       (work in progress).

  [17] C. Perkins, D. Johnson. Registration Keys for Route Optimization.
       draft-ietf-mobileip-regkey-00.txt. November 1997. (work in
       progress).

  [18] B. Aboba, M. Beadles. Network Address Identifier.
       draft-ietf-roamops-nai-10.txt, February 1998. (work in progress).

  [19] Atkinson, R., "IP Authentication Header", RFC 1826, Naval
       Research Laboratory, August 1995.

  [20] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
       RFC 1827, Naval Research Laboratory, August 1995.

  [21] Harkins, D., Carrel, D., The Internet Key Exchange (IKE),
       February 1998, Internet-draft
       draft-ietf-ipsec-isakmp-oakley-06.txt (work in progress).

  [22] Assigned numbers for Security Parameters Index. Available at:
       http://www.isi.edu/in-notes/iana/assignments/spi-numbers




17. Chairs' Addresses

   The working group can be contacted via the current chairs:

      Jim Solomon
      Motorola, Inc.
      1301 E. Algonquin Road
      Schaumburg, IL 60196
      USA

       Voice:  +1-847-576-2753
         Fax:  +1-847-576-3240
      E-Mail:  solomon@comm.mot.com


      Erik Nordmark
      Sun Microsystems, Inc.
      901 San Antonio Road
      Mailstop UMPK17-202
      Mountain View, California 94303

       Phone:  +1 650 786-5166
         Fax:  +1 650 786-5896
      E-Mail:  erik.nordmark@eng.sun.com


Calhoun, Montenegro, Perkins       expires September 1998       [Page 27]


INTERNET DRAFT                                                 March 1998


17. Author's Address

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Technology Development
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-847-548-9587
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@toast.net


      Gabriel E. Montenegro
      Technology Development
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-650-786-6288
         Fax:  1-650-786-6445
      E-mail: Gabriel.Montenegro@Eng.Sun.Com


      Charles E. Perkins
      Technology Development
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-650-786-6464
         Fax:  1-650-786-6445
      E-mail:  Charles.Perkins@Eng.Sun.Com


Appendix A.  Example of an IPX Mobile Node

   A Mobile Node  which  desired  IPX  connectivity  in  addition  to  IP
   connectivity would include an extension of the form:

      0x?? 0x06 0x81 0x37 0x00 0x00 0x0c 0x01 0x0e 0x36 0x00 0x00

   This indicates an extension of TDB [0x??]  (Tunnel  Establishment),  a
   data  length  of  6 octets, an ethertype value of 0x8137 (IPX), and an
   IEEE 802 address of 00:00:0c:01:03:36.  The final two octets  of  0x00


Calhoun, Montenegro, Perkins       expires September 1998       [Page 28]


INTERNET DRAFT                                                 March 1998


   are sent so that the extension terminates on a four-  octet  boundary,
   in accordance with the IP Mobility RFC.


Appendix B.  TEP as a Mobile Remote Access Solution

   Chained registrations flow in separate steps which together build  one
   compound  tunnel. For example, assuming there is only one intermediate
   point (or "traversal point"), labelled GFA ("gateway foreign  agent"),
   this is how the chained registration would work:

      EXAMPLE: TEP for Mobility and Remote Access

      MN -- FA ---------------------- GFA ----- HA

      A. The MN sends a registration request to the FA with the following
      information:

          name:                   MN
          care-of address:        FA
          home agent:             GFA

      B. The FA then forwards this registration to the "home agent", i.e.
      to  GFA.  Notice  that  GFA  is not a home agent in the traditional
      sense, because it's address and MN's do  not  belong  to  the  same
      subnet.   Also  notice  that  the  FA could have composed the above
      registration  on  behalf  of  the  MN  (the  so-called   "surrogate
      registration").  At  any  rate,  whoever  composes the registration
      request must share a secret with GFA, as this  is  needed  to  fill
      correctly  the authenticator field of the registration request (not
      shown above).

      C. GFA  verifies  the  authentication  for  this  registration  and
      fetches  the  information  contained therein. It notices that it is
      listed as the home agent for the MN,  which  is  not  really  true.
      However,  it checks its database, and obtains information that MN's
      real home agent is HA, with which it  can  engage  in  yet  another
      authenticated     registration    protocol    exchange    ("chained
      registration").

      GFA sends the following registration to HA:

          name:                   MN
          care-of address:        GFA
          home agent:             HA

       Notice two things:

         1. This registration is composed by the GFA on behalf of the MN,
         so it is a surrogate registration.


Calhoun, Montenegro, Perkins       expires September 1998       [Page 29]


INTERNET DRAFT                                                 March 1998


         2. If GFA is indeed the home agent for the mobile node  at  this
         point Remote Access has been accomplished.

      D. HA verifies the authentication for this registration and notices
      that  it  is  indeed  valid (it is possible for HA and GFW to use a
      shared secret different from the one used by HA and  MN).  It  then
      establishes  a  "tunnel"  (i.e  an IP forwarder) of MN's packets to
      GFA.

   Once this chained registration is in place, this is how data  transfer
   may occur:

      A. A correspondent node, CN, sends a packet  to  the  MN  with  the
      following IP header:

          IP source:              CN
          IP destination:         MN

      B. The packet arrives in the vicinity of HA, which  intercepts  and
      forwards it to GFA by prepending a new IP header like this:

          New IP source:          HA
          New IP destination:     GFA

      C. GFA receives the packet, recovers the original packet:

          IP source:              CN
          IP destination:         MN

      and notices that it has a binding  or  registration  for  MN.  This
      prompts GFA to forward the packet, this time with the following new
      IP header prepended to it:

          New IP source:          GFA
          New IP destination:     FA

      D. FA obtains the packet, recovers the inner, original packet:

          IP source:              CN
          IP destination:         MN

      and notices that is has a binding or  registration  for  MN.   This
      time, it just forwards without any additional headers because MN is
      directly reachable.

      E. MN receives the packet:

          IP source:              CN
          IP destination:         MN



Calhoun, Montenegro, Perkins       expires September 1998       [Page 30]


INTERNET DRAFT                                                 March 1998


      which from the point of view of its  applications  is  exactly  the
      same  packet they would have received if MN had been in its office.
      Thus mobility is transparent.


Appendix C. Registering Without a Permanent Home Address

   Assume that the mobile node is a Mobile Network Computer, and as such,
   does  not  have  a  permanent  home  address. If at home, it typically
   acquires an address via DHCP for use during that session.  The  notion
   of  session, however, does not necessarily imply a certain time limit.
   As long as the Mobile Network Computer renews its DHCP lease,  it  can
   continue  to  use  the  assigned address. If it reboots again, it will
   need a new address, but  this  is  probably  a  very  rare  ocurrence.
   Instead  of  rebooting,  what  is  customary  is  for a Mobile Network
   Computer to suspend its state and resume it at a later time.  At  that
   time,  it will attempt to use the same address as it was using when it
   suspended its state. It's DHCP lease may have expired, or it may  even
   ignore  what to use as a home address. At this point, it establishes a
   presence on the public internet, perhaps by  starting  a  PPP  session
   with an ISP. It needs to obtain a new home address.

   This is what it knows:

       *1. the home prefix is known
        2. HA is known
        3. secret is known
        4. care-of address is known
       *5. care-of address is co-located

   This is what it wishes to find out:

       1. MN home address

   The mobile node issues this Registration Request:

      IP fields:
          Source Address = co-located care-of address
          Destination Address = IP address of home agent
          Time to Live = 64
      UDP fields:
          Source Port = <any>
          Destination Port = 434
      Registration Request fields:
          Type = 1
          S=0,B=x,D=1,M=x,G=x
          Lifetime = 1800 (seconds)
          Home Address = the mobile node's home prefix
          Home Agent = IP address of mobile node's home agent
          Care-of Address = co-located care-of address


Calhoun, Montenegro, Perkins       expires September 1998       [Page 31]


INTERNET DRAFT                                                 March 1998


          Identification = timestamp
      Extensions:
          The Mobile-Home Authentication Extension

   The home agent sees that the home  address  field  is  not  completely
   filled  out,  obtains  a  new  address within the indicated prefix and
   returns it to the mobile node using this reply:

   Upon return:

      IP fields:
          Source Address = IP address of home agent
          Destination Address = co-located care-of address
          Time to Live = 64
      UDP fields:
         Source Port = <any> Destination Port = copied from src  port  or
         reg req
      Registration Reply fields:
          Type = 3
          Code = 140 (invalid home address)
          Lifetime = 1800 (seconds)
          Home Address = the mobile node's newly assigned home address
          Home Agent = IP address of mobile node's home agent
          Identification = timestamp
      Extensions:
          The Mobile-Home Authentication Extension

   Notice that it is possible to discover both the  home  agent  and  the
   mobile node addresses:

   Now, this is what the Mobile Network Computer knows:

       *1. the home prefix is known
       *2. HA prefix is known
        3. secret is known
        4. care-of address is known
       *5. care-of address is co-located

   And this is what it wishes to find out:

       1. HA address
       2. MN home address

   It issues this Registration Request:

      Registration Request fields:.in 9
       Type = 1
       S=0,B=x,D=1,M=x,G=x
       Lifetime = 1800 (seconds)
       Home Address = the mobile node's home prefix


Calhoun, Montenegro, Perkins       expires September 1998       [Page 32]


INTERNET DRAFT                                                 March 1998


       Home Agent = directed broadcast to HA's prefix
       Care-of Address = co-located care-of address
       Identification = timestamp
      Extensions:
          The Mobile-Home Authentication Extension

   An initial reply with code 136 (unknown home agent address) tells  the
   mobile node which home agent to use. Subsequently, the mobile node may
   discover its own home address. It must first discover the  home  agent
   address  because  the  latter  must be willing to provide some address
   allocation services on the mobile node's behalf.

   We could also use a separate foreign agent:

   In this case, these are the known quantities:

       *1. the home prefix is known
       *2. HA prefix is known
        3. secret is known
        4. care-of address is known

   In this case, the foreign agent uses a Mobile  Node  Cookie  Extension
   (Section  9.5.)  to  determine  which  mobile node to send replies to.
   Notice that it is presumed that an foreign agent learn the mobile node
   MAC address from snooping the Registration Request.



























Calhoun, Montenegro, Perkins       expires September 1998       [Page 33]