home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mobileip-ipv6-02.txt < prev    next >
Text File  |  1996-11-27  |  115KB  |  2,970 lines
  1.  
  2. Mobile IP Working Group                                 David B. Johnson
  3. INTERNET-DRAFT                                Carnegie Mellon University
  4.                                                          Charles Perkins
  5.                                                          IBM Corporation
  6.                                                         26 November 1996
  7.  
  8.  
  9.                         Mobility Support in IPv6
  10.  
  11.                    <draft-ietf-mobileip-ipv6-02.txt>
  12.  
  13.  
  14. Abstract
  15.  
  16.    This document specifies the operation of mobile computers using IPv6.
  17.    Each mobile node is always identified by its home address, regardless
  18.    of its current point of attachment to the Internet.  While situated
  19.    away from its home, a mobile node is also associated with a care-of
  20.    address, which provides information about the mobile node's current
  21.    location.  IPv6 packets addressed to a mobile node's home address are
  22.    transparently routed to its care-of address.  The protocol enables
  23.    IPv6 nodes to cache the binding of a mobile node's home address with
  24.    its care-of address, and to then send packets destined for the mobile
  25.    node directly to it at this care-of address.
  26.  
  27.  
  28. Status of This Memo
  29.  
  30.    This document is a submission by the Mobile IP Working Group of the
  31.    Internet Engineering Task Force (IETF).  Comments should be submitted
  32.    to the Working Group mailing list at "mobile-ip@SmallWorks.COM".
  33.    Distribution of this memo is unlimited.
  34.  
  35.    This document is an Internet-Draft.  Internet-Drafts are working
  36.    documents of the Internet Engineering Task Force (IETF), its areas,
  37.    and its working groups.  Note that other groups may also distribute
  38.    working documents as Internet-Drafts.
  39.  
  40.    Internet-Drafts are draft documents valid for a maximum of six months
  41.    and may be updated, replaced, or obsoleted by other documents at
  42.    any time.  It is inappropriate to use Internet-Drafts as reference
  43.    material or to cite them other than as "work in progress."
  44.  
  45.    To learn the current status of any Internet-Draft, please check
  46.    the "1id-abstracts.txt" listing contained in the Internet-Drafts
  47.    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  48.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  49.    ftp.isi.edu (US West Coast).
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Johnson and Perkins             Expires 26 May 1997             [Page i]
  57.  
  58. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  59.  
  60.  
  61.  
  62.  
  63.                                 Contents
  64.  
  65.  
  66.  
  67. Abstract                                                               i
  68.  
  69. Status of This Memo                                                    i
  70.  
  71.  1. Introduction                                                       1
  72.  
  73.  2. Terminology                                                        2
  74.      2.1. General Terms . . . . . . . . . . . . . . . . . . . . . .    2
  75.      2.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . .    3
  76.      2.3. Specification Language  . . . . . . . . . . . . . . . . .    4
  77.  
  78.  3. Overview of Mobile IPv6 Operation                                  6
  79.  
  80.  4. New IPv6 Destination Options                                      11
  81.      4.1. Binding Update Option . . . . . . . . . . . . . . . . . .   11
  82.      4.2. Binding Acknowledgement Option  . . . . . . . . . . . . .   14
  83.      4.3. Binding Request Option  . . . . . . . . . . . . . . . . .   17
  84.  
  85.  5. Requirements for IPv6 Nodes                                       18
  86.  
  87.  6. Correspondent Node Operation                                      20
  88.      6.1. Receiving Binding Updates . . . . . . . . . . . . . . . .   20
  89.      6.2. Requests to Cache a Binding . . . . . . . . . . . . . . .   21
  90.      6.3. Requests to Delete a Binding  . . . . . . . . . . . . . .   21
  91.      6.4. Sending Binding Acknowledgements  . . . . . . . . . . . .   21
  92.      6.5. Cache Replacement Policy  . . . . . . . . . . . . . . . .   22
  93.      6.6. Receiving ICMP Error Messages . . . . . . . . . . . . . .   23
  94.      6.7. Sending Packets to a Mobile Node  . . . . . . . . . . . .   24
  95.  
  96.  7. Home Agent Operation                                              26
  97.      7.1. Primary Care-of Address Registration  . . . . . . . . . .   26
  98.      7.2. Primary Care-of Address De-registration . . . . . . . . .   28
  99.      7.3. Tunneling Intercepted Packets to a Mobile Node  . . . . .   28
  100.      7.4. Renumbering the Home Subnet . . . . . . . . . . . . . . .   29
  101.  
  102.  8. Mobile Node Operation                                             31
  103.      8.1. Movement Detection  . . . . . . . . . . . . . . . . . . .   31
  104.      8.2. Forming New Care-of Addresses . . . . . . . . . . . . . .   33
  105.      8.3. Sending Binding Updates to the Home Agent . . . . . . . .   34
  106.      8.4. Sending Binding Updates to Correspondent Nodes  . . . . .   35
  107.      8.5. Sending Binding Updates to the Previous Default Router  .   37
  108.      8.6. Retransmitting Binding Updates  . . . . . . . . . . . . .   37
  109.  
  110.  
  111.  
  112. Johnson and Perkins            Expires 26 May 1997             [Page ii]
  113.  
  114. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  115.  
  116.  
  117.      8.7. Rate Limiting for Sending Binding Updates . . . . . . . .   38
  118.      8.8. Receiving Binding Acknowledgements  . . . . . . . . . . .   38
  119.      8.9. Using Multiple Care-of Addresses  . . . . . . . . . . . .   39
  120.     8.10. Returning Home  . . . . . . . . . . . . . . . . . . . . .   39
  121.  
  122.  9. Routing Multicast Packets                                         41
  123.  
  124. 10. Constants                                                         42
  125.  
  126. 11. Security Considerations                                           43
  127.  
  128. Acknowledgements                                                      44
  129.  
  130.  A. Open Issues                                                       45
  131.      A.1. Session Keys with Local Routers . . . . . . . . . . . . .   45
  132.      A.2. Source Address Filtering by Firewalls . . . . . . . . . .   45
  133.      A.3. Dynamic Home Agent Address Discovery  . . . . . . . . . .   46
  134.      A.4. Replay Protection for Binding Updates . . . . . . . . . .   46
  135.  
  136. References                                                            47
  137.  
  138. Chair's Address                                                       49
  139.  
  140. Authors' Addresses                                                    50
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168. Johnson and Perkins            Expires 26 May 1997            [Page iii]
  169.  
  170. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  171.  
  172.  
  173. 1. Introduction
  174.  
  175.    This document specifies the operation of mobile computers using
  176.    Internet Protocol Version 6 (IPv6) [5].  Without specific support for
  177.    mobility in IPv6, packets destined to a mobile node (host or router)
  178.    would not be able to reach it while the mobile node is away from its
  179.    home IPv6 subnet, since routing is based on the network prefix in a
  180.    packet's destination IP address.  In order continue communication
  181.    in spite of its movement, a mobile node could change its IP address
  182.    each time it moves to a new IPv6 subnet, but the mobile node would
  183.    then not be able to maintain transport and higher-layer connections
  184.    when it changes location.  Mobility support in IPv6 is particularly
  185.    important, as mobile computers are likely to account for a majority
  186.    or at least a substantial fraction of the population of the Internet
  187.    during the lifetime of IPv6.
  188.  
  189.    The protocol operation defined here, known as Mobile IPv6, allows a
  190.    mobile node to move from one IPv6 subnet to another without changing
  191.    the mobile node's IP address.  A mobile node is always addressable
  192.    by its "home address", the IP address assigned to the mobile node
  193.    within its home IPv6 subnet.  Packets may be routed to it using this
  194.    address regardless of the mobile node's current point of attachment
  195.    to the Internet, and the mobile node may continue to communicate with
  196.    other nodes (stationary or mobile) after moving to a new subnet.
  197.    The movement of a mobile node away from its home subnet is thus
  198.    transparent to transport and higher-layer protocols and applications.
  199.  
  200.    The Mobile IPv6 protocol is just as suitable for mobility across
  201.    homogeneous media as for mobility across heterogeneous media.  For
  202.    example, Mobile IPv6 facilitates node movement from one Ethernet
  203.    segment to another as well as it accommodates node movement from an
  204.    Ethernet segment to a wireless LAN cell, as long as the mobile node's
  205.    IP address remains unchanged after such a movement.
  206.  
  207.    One can think of the Mobile IPv6 protocol as solving the "macro"
  208.    mobility management problem.  More "micro" mobility management
  209.    applications -- for example, handoff amongst wireless transceivers,
  210.    each of which covers only a very small geographic area, are possibly
  211.    more suited to other solutions.  For example, as long as node
  212.    movement does not occur between link-level points of attachment on
  213.    different IPv6 subnets, link-layer mobility support offered by a
  214.    number of current wireless LAN products is likely to offer faster
  215.    convergence and lower overhead than Mobile IPv6.  Extensions to the
  216.    Mobile IPv6 protocol are also possible to support a more local,
  217.    hierarchical form of handoff, but such extensions are beyond the sope
  218.    of this document.
  219.  
  220.  
  221.  
  222.  
  223.  
  224. Johnson and Perkins             Expires 26 May 1997             [Page 1]
  225.  
  226. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  227.  
  228.  
  229. 2. Terminology
  230.  
  231. 2.1. General Terms
  232.  
  233.       IP
  234.  
  235.          Internet Protocol Version 6 (IPv6).
  236.  
  237.       node
  238.  
  239.          A device that implements IP.
  240.  
  241.       router
  242.  
  243.          A node that forwards IP packets not explicitly addressed to
  244.          itself.
  245.  
  246.       host
  247.  
  248.          Any node that is not a router.
  249.  
  250.       link
  251.  
  252.          A communication facility or medium over which nodes can
  253.          communicate at the link layer, such as an Ethernet (simple or
  254.          bridged).  A link is the layer immediately below IP.
  255.  
  256.       interface
  257.  
  258.          A node's attachment to a link.
  259.  
  260.       network prefix
  261.  
  262.          A bit string that consists of some number of initial bits of an
  263.          IP address.
  264.  
  265.       link-layer address
  266.  
  267.          A link-layer identifier for an interface, such as IEEE 802
  268.          addresses on Ethernet links.
  269.  
  270.       packet
  271.  
  272.          An IP header plus payload.
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280. Johnson and Perkins             Expires 26 May 1997             [Page 2]
  281.  
  282. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  283.  
  284.  
  285. 2.2. Mobile IPv6 Terms
  286.  
  287.       home address
  288.  
  289.          An IP address assigned to a mobile node within its home subnet.
  290.          The network prefix in a mobile node's home address is equal to
  291.          the network prefix of the home subnet.
  292.  
  293.       home subnet
  294.  
  295.          The IP subnet indicated by a mobile node's home address.
  296.          Standard IP routing mechanisms will deliver packets destined
  297.          for a mobile node's home address to its home subnet.
  298.  
  299.       mobile node
  300.  
  301.          A node that can change its link-level point of attachment from
  302.          one IP subnet to another, while still being addressable via its
  303.          home address.
  304.  
  305.       movement
  306.  
  307.          A change in a mobile node's point of attachment to the Internet
  308.          such that it is no longer link-level connected to the same IP
  309.          subnet as it was previously.  If a mobile node is not currently
  310.          link-level connected to its home subnet, the mobile node is
  311.          said to be "away from home".
  312.  
  313.       correspondent node
  314.  
  315.          A peer with which a mobile node is communicating.  The
  316.          correspondent node may be either mobile or stationary.
  317.  
  318.       foreign subnet
  319.  
  320.          Any IP subnet other than the mobile node's home subnet.
  321.  
  322.       home agent
  323.  
  324.          A router on a mobile node's home subnet with which the mobile
  325.          node has registered its current care-of address.  While the
  326.          mobile node is away from home, the home agent intercepts
  327.          packets on the home subnet destined to the mobile node's home
  328.          address, encapsulates them, and tunnels them to the mobile
  329.          node's registered care-of address.
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336. Johnson and Perkins             Expires 26 May 1997             [Page 3]
  337.  
  338. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  339.  
  340.  
  341.       care-of address
  342.  
  343.          An IP address associated with a mobile node while visiting
  344.          a foreign subnet, which uses the network prefix of that
  345.          foreign subnet.  Among the multiple care-of addresses that a
  346.          mobile node may have at a time (e.g., with different network
  347.          prefixes), the one registered with its home agent is called its
  348.          "primary" care-of address.
  349.  
  350.       binding
  351.  
  352.          The association of the home address of a mobile node with a
  353.          care-of address for that mobile node, along with the remaining
  354.          lifetime of that association.
  355.  
  356.  
  357. 2.3. Specification Language
  358.  
  359.    In this document, several words are used to signify the requirements
  360.    of the specification.  These words are often capitalized.
  361.  
  362.       MUST
  363.  
  364.          This word, or the adjective "REQUIRED", means that the
  365.          definition is an absolute requirement of the specification.
  366.  
  367.       MUST NOT
  368.  
  369.          This phrase means that the definition is an absolute
  370.          prohibition of the specification.
  371.  
  372.       SHOULD
  373.  
  374.          This word, or the adjective "RECOMMENDED", means that there may
  375.          exist valid reasons in particular circumstances to ignore a
  376.          particular item, but the full implications must be understood
  377.          and carefully weighed before choosing a different course.
  378.  
  379.       SHOULD NOT
  380.  
  381.          This phrase means that there may exist valid reasons in
  382.          particular circumstances when the particular behavior is
  383.          acceptable or even useful, but the full implications should be
  384.          understood and the case carefully weighed before implementing
  385.          any behavior described with this label.
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392. Johnson and Perkins             Expires 26 May 1997             [Page 4]
  393.  
  394. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  395.  
  396.  
  397.       MAY
  398.  
  399.          This word, or the adjective "OPTIONAL", means that an item
  400.          is truly optional.  For example, one vendor may choose to
  401.          include the item because a particular marketplace requires
  402.          it or because the vendor feels that it enhances the product,
  403.          while another vendor may omit the same item.  An implementation
  404.          which does not include a particular option MUST be prepared to
  405.          interoperate with another implementation which does include the
  406.          option.
  407.  
  408.       silently discard
  409.  
  410.          The implementation discards the packet without further
  411.          processing, and without indicating an error to the sender.  The
  412.          implementation SHOULD provide the capability of logging the
  413.          error, including the contents of the discarded packet, and
  414.          SHOULD record the event in a statistics counter.
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448. Johnson and Perkins             Expires 26 May 1997             [Page 5]
  449.  
  450. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  451.  
  452.  
  453. 3. Overview of Mobile IPv6 Operation
  454.  
  455.    A mobile node is always addressable by its home address, whether it
  456.    is currently attached to its home subnet or is away from home.  While
  457.    a mobile node is at home, packets addressed to the mobile node's
  458.    home address are routed to it using conventional Internet routing
  459.    mechanisms in the same way as if the node were never mobile.  Since
  460.    the network prefix of a mobile node's home address is equal to the
  461.    network prefix of its home subnet, packets addressed to it will be
  462.    routed to its home subnet.
  463.  
  464.    While a mobile node is attached to some foreign subnet away from
  465.    home, it is also addressable by one or more care-of addresses, in
  466.    addition to its home address.  A care-of address is an IP address
  467.    associated with a mobile node only while visiting a particular
  468.    foreign subnet.  The network prefix of a care-of address being used
  469.    by a mobile node is equal to the network prefix of the foreign
  470.    subnet to which the mobile node is link-level connected, and thus
  471.    packets addressed to this care-of address will be routed to the
  472.    mobile node's location away from home.  The association between
  473.    a mobile node's home address and care-of address is known as a
  474.    "binding" for the mobile node.  A mobile node typically acquires its
  475.    care-of address through stateless [14] or stateful (e.g., DHCPv6 [3])
  476.    address autoconfiguration, according to the methods of IPv6 Neighbor
  477.    Discovery [8], although other methods of acquiring a care-of address
  478.    are also possible.
  479.  
  480.    While away from home, the mobile node registers one of its binding
  481.    with a router in its home subnet, requesting this router to function
  482.    as the "home agent" for the mobile node.  The care-of address in this
  483.    binding registered with its home agent is known as the mobile node's
  484.    "primary care-of address".  The mobile node's home agent thereafter
  485.    uses proxy Neighbor Discovery to intercept any IPv6 packets addressed
  486.    to the mobile node's home address on the home subnet, and tunnels
  487.    each intercepted packet to the mobile node's primary care-of address.
  488.    To tunnel each intercepted packet, the home agent encapsulates the
  489.    packet using IPv6 encapsulation [4], addressed to the mobile node's
  490.    primary care-of address.
  491.  
  492.    Mobile IPv6 provides a mechanism for IPv6 nodes communicating with
  493.    a mobile node, to dynamically learn and cache the mobile node's
  494.    binding.  When sending a packet to any IPv6 destination, a node
  495.    checks its cached bindings for an entry for the packet's destination
  496.    address.  If a cached binding for this destination address is
  497.    found, the node uses an IPv6 Routing header [5] (instead of IPv6
  498.    encapsulation) to route the packet to the mobile node through the
  499.    care-of address indicated in this binding.  If, instead, the sending
  500.    node has no cached binding for this destination address, the node
  501.  
  502.  
  503.  
  504. Johnson and Perkins             Expires 26 May 1997             [Page 6]
  505.  
  506. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  507.  
  508.  
  509.    sends the packet normally (with no Routing header), and the packet
  510.    is subsequently intercepted and tunneled by the mobile node's home
  511.    agent as described above.  A node communicating with a mobile node is
  512.    referred to in this document as a "correspondent node" of the mobile
  513.    node.
  514.  
  515.    A mobile node's home agent and correspondent nodes learn and
  516.    cache the mobile node's binding through use of a set of new IPv6
  517.    destination options [5] defined for Mobile IPv6.  Since an IPv6
  518.    Destination Options header containing one or more destination options
  519.    can appear in any IPv6 packet, any Mobile IPv6 option can be sent in
  520.    either of two ways:
  521.  
  522.     -  A Mobile IPv6 option can be included within any IPv6 packet
  523.        carrying any payload such as TCP [11] or UDP [10].
  524.  
  525.     -  A Mobile IPv6 option can be sent as a separate IPv6 packet
  526.        containing no payload.  In this case, the Next Header field
  527.        in the Destination Options header is set to the value 59, to
  528.        indicate "No Next Header" [5].
  529.  
  530.    The following three new IPv6 destination options are defined for
  531.    Mobile IPv6:
  532.  
  533.       Binding Update
  534.  
  535.          A Binding Update is used by a mobile node to notify a
  536.          correspondent node or its home agent of its current binding.
  537.          The Binding Update sent to the mobile node's home agent is
  538.          marked as a "home registration".  Any packet that includes a
  539.          Binding Update option MUST also include an IPv6 Authentication
  540.          header [1].  The Binding Update option is described in detail
  541.          in Section 4.1.
  542.  
  543.       Binding Acknowledgement
  544.  
  545.          A Binding Acknowledgement is used to acknowledge receipt of
  546.          a Binding Update, if an acknowledgement was requested in the
  547.          Binding Update.  Other Binding Updates MAY be acknowledged
  548.          but need not be.  Any packet that includes a Binding
  549.          Acknowledgement option MUST also include an IPv6 Authentication
  550.          header [1].  The Binding Acknowledgement option is described in
  551.          detail in Section 4.2.
  552.  
  553.       Binding Request
  554.  
  555.          A Binding Request is used to request a mobile node to send a
  556.          Binding Update to this node, containing its current binding.
  557.  
  558.  
  559.  
  560. Johnson and Perkins             Expires 26 May 1997             [Page 7]
  561.  
  562. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  563.  
  564.  
  565.          This option is typically used by a correspondent node to
  566.          refresh a cached binding for a mobile node, when the lifetime
  567.          on this cached binding is close to expiration.  The Binding
  568.          Request option is described in detail in Section 4.3.
  569.  
  570.    Extensions to the format of these options may be included after the
  571.    fixed portion of the option data specified in this document.  The
  572.    presence of such extensions will be indicated by the Option Length
  573.    field within the option.  When the Option Length is greater than the
  574.    length required for the option specified here, the remaining octets
  575.    are interpreted as extensions.  Currently, no extensions have been
  576.    defined.
  577.  
  578.    This document describes the Mobile IPv6 protocol in terms of the
  579.    following two conceptual data structures used in the maintenance of
  580.    cached bindings:
  581.  
  582.       Binding Cache
  583.  
  584.          A cache, maintained by each IPv6 node, of bindings for other
  585.          nodes.  An entry in a node's binding cache for which the node
  586.          is serving as a home agent is marked as a "home registration"
  587.          entry and SHOULD NOT be deleted by the home agent until the
  588.          expiration of its binding lifetime, whereas other Binding Cache
  589.          entries MAY be replaced at any time by any reasonable local
  590.          cache replacement policy.  The Binding Cache MAY be implemented
  591.          in any manner consistent with the external behavior described
  592.          in this document, for example by being combined with the node's
  593.          Destination Cache as maintained through Neighbor Discovery [8].
  594.  
  595.       Binding Update List
  596.  
  597.          A list, maintained by each mobile node, recording information
  598.          for each Binding Update sent by this mobile node, for which
  599.          the Lifetime of the binding sent in that Update has not yet
  600.          expired.  For each such Binding Update, the Binding Update List
  601.          records the IP address of the node to which the Update was
  602.          sent, the home address for which the Update was sent, and the
  603.          remaining lifetime of the binding.  The Binding Update List
  604.          MAY be implemented in any manner consistent with the external
  605.          behavior described in this document.
  606.  
  607.    When a mobile node configures a new care-of address and decides to
  608.    use this new address as its primary care-of address, the mobile
  609.    node registers this new binding with its home agent by sending
  610.    the home agent a Binding Update.  The mobile node indicates
  611.    that an acknowledgement is needed for this Binding Update and
  612.    continues to periodically retransmit it until acknowledged.  The
  613.  
  614.  
  615.  
  616. Johnson and Perkins             Expires 26 May 1997             [Page 8]
  617.  
  618. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  619.  
  620.  
  621.    home agent acknowledges the Binding Update by returning a Binding
  622.    Acknowledgement to the mobile node.
  623.  
  624.    When a mobile node receives a packet tunneled to it from its
  625.    home agent, the mobile node assumes that the original sending
  626.    correspondent node has no binding cache entry for the mobile node,
  627.    since the correspondent node would otherwise have sent the packet
  628.    directly to the mobile node using a Routing header.  The mobile node
  629.    thus returns a Binding Update to the correspondent node, allowing
  630.    it to cache the mobile node's binding for routing future packets.
  631.    Although the mobile node may request an acknowledgement for this
  632.    Binding Update, it need not, since subsequent packets from the
  633.    correspondent node will continue to be intercepted and tunneled by
  634.    the mobile node's home agent, effectively causing any needed Binding
  635.    Update retransmission.
  636.  
  637.    A correspondent node with a binding cache entry for a mobile node
  638.    may refresh this binding, for example if the binding's lifetime
  639.    is near expiration, by sending a Binding Request to the mobile
  640.    node.  Normally, a correspondent node will only refresh a binding
  641.    cache entry in this way if it is actively communicating with the
  642.    mobile node and has indications, such as an open TCP connection to
  643.    the mobile node, that it will continue this communication in the
  644.    future.  When a mobile node receives a Binding Request, it replies by
  645.    returning a Binding Update to the node sending the Binding Request.
  646.  
  647.    A mobile node may use more than one care-of address at the same time,
  648.    although only one care-of address may be registered for it at its
  649.    home agent as its primary care-of address.  The mobile node's home
  650.    agent will tunnel all intercepted packets for the mobile node to its
  651.    registered primary care-of address, but the mobile node will accept
  652.    packets that it receives at any of its current care-of addresses.
  653.    Use of more than one care-of address by a mobile node may be useful,
  654.    for example, to improve smooth handoff when the mobile node moves
  655.    from one wireless IP subnet to another.  If each wireless subnet is
  656.    connected to the Internet through a separate base station, such that
  657.    the wireless transmission range from the two base stations overlap,
  658.    the mobile node may be able to remain link-level connected within
  659.    both subnets while in the area of overlap.  In this case, the mobile
  660.    node could acquire a new care-of address in the new subnet before
  661.    moving out of transmission range and link-level disconnecting from
  662.    the old subnet.  The mobile node may thus still accept packets at
  663.    its old care-of address while it works to update its home agent and
  664.    correspondent nodes, notifying them of its new care-of address.
  665.  
  666.    Since correspondent nodes cache bindings, it is expected that
  667.    correspondent nodes usually will route packets directly to the mobile
  668.    node's care-of address, so that the home agent is rarely involved
  669.  
  670.  
  671.  
  672. Johnson and Perkins             Expires 26 May 1997             [Page 9]
  673.  
  674. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  675.  
  676.  
  677.    with packet transmission to the mobile node.  This is essential for
  678.    scalability and reliability, and for minimizing overall network load.
  679.    By caching the care-of address of a mobile node, optimal routing of
  680.    packets can be achieved from the correspondent node to the mobile
  681.    node.  Routing packets directly to the mobile node's care-of address
  682.    also eliminates congestion at the mobile node's home agent and home
  683.    subnet.  In addition, the impact of of any possible failure of the
  684.    home agent, the home subnet, or intervening networks leading to the
  685.    home subnet is reduced, since these nodes and links are not involved
  686.    in the delivery of most packets to the mobile node.
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728. Johnson and Perkins            Expires 26 May 1997             [Page 10]
  729.  
  730. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  731.  
  732.  
  733. 4. New IPv6 Destination Options
  734.  
  735. 4.1. Binding Update Option
  736.  
  737.    The Binding Update destination option is used by a mobile node to
  738.    notify a correspondent node or its home agent of a new care-of
  739.    address.
  740.  
  741.    The Binding Update option is encoded in type-length-value (TLV)
  742.    format as follows:
  743.  
  744.     0                   1                   2                   3
  745.     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
  746.                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  747.                                    |  Option Type  | Option Length |
  748.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  749.    |A|H|L|       Reserved          |            Lifetime           |
  750.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  751.    |                         Identification                        |
  752.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  753.    |                                                               |
  754.    +                                                               +
  755.    |                                                               |
  756.    +                        Care-of Address                        +
  757.    |                                                               |
  758.    +                                                               +
  759.    |                                                               |
  760.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  761.    |                                                               |
  762.    +                                                               +
  763.    |                                                               |
  764.    +                    Home Link-Local Address                    +
  765.    |                  (only present if L bit set)                  |
  766.    +                                                               +
  767.    |                                                               |
  768.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  769.  
  770.       Option Type
  771.  
  772.          192 ???
  773.  
  774.       Option Length
  775.  
  776.          8-bit unsigned integer.  Length of the option, in octets,
  777.          excluding the Option Type and Option Length fields.  For the
  778.          current definition of the Binding Update option, this field
  779.          MUST be set to 24 if the Home Link-Local Address Present (L)
  780.          bit is not set, and MUST otherwise be set to 40.
  781.  
  782.  
  783.  
  784. Johnson and Perkins            Expires 26 May 1997             [Page 11]
  785.  
  786. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  787.  
  788.  
  789.       Acknowledge (A)
  790.  
  791.          The Acknowledge (A) bit is set by the sending node to request a
  792.          Binding Acknowledgement (Section 4.2) be returned upon receipt
  793.          of the Binding Update option.
  794.  
  795.       Home Registration (H)
  796.  
  797.          The Home Registration (H) bit is set by the sending node to
  798.          request the receiving node to act as this node's home agent.
  799.          The Destination Address in the IP header of the packet carrying
  800.          this option MUST be that of a router sharing the same network
  801.          prefix as the home address of the mobile node in the binding.
  802.  
  803.       Home Link-Local Address Present (L)
  804.  
  805.          The Home Link-Local Address Present (L) bit indicates the
  806.          presence of the Home Link-Local Address field in the Binding
  807.          Update.  This bit is set by the sending node to request
  808.          the receiving node to act as a proxy (for participating in
  809.          the Neighbor Discovery Protocol) for the node while it is
  810.          away from home.  This bit MUST NOT be set unless the Home
  811.          Registration (H) bit is also set in the Binding Update.
  812.  
  813.       Reserved
  814.  
  815.          Sent as 0; ignored on reception.
  816.  
  817.       Lifetime
  818.  
  819.          16-bit unsigned integer.  The number of seconds remaining
  820.          before the binding must be considered expired.  A value of all
  821.          ones (0xffff) indicates infinity.  A value of zero indicates
  822.          that the Binding Cache entry for the mobile node should be
  823.          deleted.
  824.  
  825.       Identification
  826.  
  827.          a 32-bit number used by the receiving node to sequence Binding
  828.          Updates, and by the sending node to match a returned Binding
  829.          Acknowledgement message with this Binding Update.
  830.  
  831.       Care-of Address
  832.  
  833.          The care-of address of the mobile node for this binding.  When
  834.          set equal to the home address of the mobile node, the Binding
  835.          Update option instead indicates that any existing binding for
  836.  
  837.  
  838.  
  839.  
  840. Johnson and Perkins            Expires 26 May 1997             [Page 12]
  841.  
  842. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  843.  
  844.  
  845.          the mobile node should be deleted; no binding for the mobile
  846.          node should be created in this case.
  847.  
  848.       Home Link-Local Address
  849.  
  850.          The link-local address of the mobile node used by the mobile
  851.          node when it was last attached to its home subnet.  This field
  852.          in the Binding Update is optional and is only present when the
  853.          Home Link-Local Address (L) bit is set.
  854.  
  855.    The home address of the mobile node in the binding is indicated by
  856.    the Source Address field in the IP header of the packet containing
  857.    the Binding Update option.
  858.  
  859.    Any packet that includes a Binding Update option MUST include an IPv6
  860.    Authentication header [1] in order to protect against forged Binding
  861.    Updates.
  862.  
  863.    The three highest-order bits of the Option Type are encoded to
  864.    indicate specific processing of the option [5].  For the Binding
  865.    Update option, these three bits are set to 110, indicating that the
  866.    data within the option cannot change en-route to the packet's final
  867.    destination, and that any IPv6 node processing this option that does
  868.    not recognize the Option Type must discard the packet and, only if
  869.    the packet's Destination Address was not a multicast address, return
  870.    an ICMP Parameter Problem, Code 2, message to the packet's Source
  871.    Address.
  872.  
  873.    Extensions to the Binding Update option format may be included after
  874.    the fixed portion of the Binding Update option specified above.  The
  875.    presence of such extensions will be indicated by the Option Length
  876.    field.  When the Option Length is greater than 24 octets if the Home
  877.    Link-Local Address (L) bit is not set, or greater than 40 octets if
  878.    the Home Link-Local Address (L) bit is set, the remaining octets
  879.    are interpreted as extensions.  Currently, no extensions have been
  880.    defined.
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896. Johnson and Perkins            Expires 26 May 1997             [Page 13]
  897.  
  898. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  899.  
  900.  
  901. 4.2. Binding Acknowledgement Option
  902.  
  903.    The Binding Acknowledgement destination option is used to acknowledge
  904.    receipt of a Binding Update option (Section 4.1).  When a node
  905.    receives a Binding Update addressed to itself, in which the
  906.    Acknowledge (A) bit set, it MUST return a Binding Acknowledgement.
  907.  
  908.    The Binding Acknowledgement option is encoded in type-length-value
  909.    (TLV) format as follows:
  910.  
  911.     0                   1                   2                   3
  912.     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
  913.                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  914.                    |  Option Type  | Option Length |    Status     |
  915.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  916.    |            Refresh            |            Lifetime           |
  917.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  918.    |                         Identification                        |
  919.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  920.  
  921.       Option Type
  922.  
  923.          193 ???
  924.  
  925.       Option Length
  926.  
  927.          8-bit unsigned integer.  Length of the option, in octets,
  928.          excluding the Option Type and Option Length fields.  For the
  929.          current definition of the Binding Acknowledgement option, this
  930.          field MUST be set to 8.
  931.  
  932.       Status
  933.  
  934.          8-bit unsigned integer indicating the disposition of the
  935.          Binding Update.  Values of the Status field less than 128
  936.          indicate that the Binding Update was accepted by the receiving
  937.          node.  The following such Status values are currently defined:
  938.  
  939.               0   Binding Update accepted
  940.  
  941.          Values of the Status field greater than or equal to 128
  942.          indicate that the Binding Update was rejected by the receiving
  943.          node.  The following such Status values are currently defined:
  944.  
  945.             128   Reason unspecified
  946.             129   Poorly formed Binding Update
  947.             130   Administratively prohibited
  948.             131   Insufficient resources
  949.  
  950.  
  951.  
  952. Johnson and Perkins            Expires 26 May 1997             [Page 14]
  953.  
  954. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  955.  
  956.  
  957.             132   Home registration not supported
  958.             133   Not home subnet
  959.             134   Identification field mismatch
  960.             135   Unknown home agent address
  961.  
  962.          Up-to-date values of the Status field are to be specified in
  963.          the most recent "Assigned Numbers" [12].
  964.  
  965.       Refresh
  966.  
  967.          The recommended period at which the mobile node should send
  968.          a new Binding Update to this node in order to "refresh" the
  969.          mobile node's binding in this node's binding cache, in case
  970.          the node fails and loses its cache state.  The Refresh period
  971.          is determined by the node sending the Binging Acknowledgement
  972.          (the node caching the binding).  If this node is serving as the
  973.          mobile node's home agent, the Refresh value may be set, for
  974.          example, based on whether the node stores the mobile node's
  975.          binding in volatile storage or in nonvolatile storage.  If the
  976.          node sending the Binding Acknowledgement is not serving as the
  977.          mobile node's home agent, the Refresh period SHOULD be set
  978.          equal to the Lifetime period in the Binding Acknowledgement;
  979.          even if this node loses this cache entry due to a failure of
  980.          the node, packets from it can still reach the mobile node
  981.          through the mobile node's home agent, causing a new Binding
  982.          Update to this node to allow it to recreate this cache entry.
  983.  
  984.       Lifetime
  985.  
  986.          The granted lifetime for which this node will attempt to retain
  987.          the entry for this mobile node in its binding cache.  If the
  988.          node sending the Binding Acknowledgement is serving as the
  989.          mobile node's home agent, the Lifetime period also indicates
  990.          the period for which this node will continue this service; if
  991.          the mobile node requires home agent service from this node
  992.          beyond this period, the mobile node MUST send a new Binding
  993.          Update to it before the expiration of this period to extend the
  994.          lifetime.
  995.  
  996.       Identification
  997.  
  998.          The acknowledgement Identification is copied from the Binding
  999.          Update option, for use by the mobile node in matching the
  1000.          acknowledgement with an outstanding Binding Update.
  1001.  
  1002.    Any packet that includes a Binding Acknowledgement option MUST
  1003.    include an IPv6 Authentication header [1] in order to protect against
  1004.    forged Binding Acknowledgements.
  1005.  
  1006.  
  1007.  
  1008. Johnson and Perkins            Expires 26 May 1997             [Page 15]
  1009.  
  1010. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1011.  
  1012.  
  1013.    If the node returning the Binding Acknowledgement accepted the
  1014.    Binding Update for which the Acknowledgement is being returned (the
  1015.    value of the Status field in the Acknowledgement is less than 128),
  1016.    this node will have an entry for the mobile node in its Binding
  1017.    Cache, and MUST use this entry (which includes the care-of address
  1018.    received in the Binding Update) in sending the packet containing the
  1019.    Binding Acknowledgement to the mobile node.  The details of sending
  1020.    this packet to the mobile node are the same as for sending any packet
  1021.    to a mobile node using a Binding Cache entry, and are described in
  1022.    Section 6.7.  The packet is sent using a Routing header, routing the
  1023.    packet to the mobile node through its care-of address recorded in the
  1024.    Binding Cache entry.
  1025.  
  1026.    If the node returning the Binding Acknowledgement instead
  1027.    rejected the Binding Update (the value of the Status field in the
  1028.    Acknowledgement is greater than or equal to 128), this node MUST
  1029.    similarly use a Routing header in sending the packet containing the
  1030.    Binding Acknowledgement, as described in Section 6.7, but MUST NOT
  1031.    use its Binding Cache in forming the IP header or Routing header
  1032.    in this packet.  Rather, the care-of address used by this node in
  1033.    sending the packet containing the Binding Acknowledgement MUST be
  1034.    copied from the care-of address received in the rejected Binding
  1035.    Update; this node MUST NOT modify its Binding Cache in response
  1036.    to receiving this rejected Binding Update and MUST ignore its
  1037.    Binding Cache in sending the packet in which it returns this Binding
  1038.    Acknowledgement.  The packet is sent using a Routing header, routing
  1039.    the packet to the Source Address of the rejected Binding Update
  1040.    through the care-of address indicated in the Binding Update.
  1041.  
  1042.    The three highest-order bits of the Option Type are encoded to
  1043.    indicate specific processing of the option [5].  For the Binding
  1044.    Acknowledgement option, these three bits are set to 110, indicating
  1045.    that the data within the option cannot change en-route to the
  1046.    packet's final destination, and that any IPv6 node processing this
  1047.    option that does not recognize the Option Type must discard the
  1048.    packet and, only if the packet's Destination Address was not a
  1049.    multicast address, return an ICMP Parameter Problem, Code 2, message
  1050.    to the packet's Source Address.
  1051.  
  1052.    Extensions to the Binding Acknowledgement option format may be
  1053.    included after the fixed portion of the Binding Acknowledgement
  1054.    option specified above.  The presence of such extensions will be
  1055.    indicated by the Option Length field.  When the Option Length is
  1056.    greater than 8 octets, the remaining octets are interpreted as
  1057.    extensions.  Currently, no extensions have been defined.
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064. Johnson and Perkins            Expires 26 May 1997             [Page 16]
  1065.  
  1066. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1067.  
  1068.  
  1069. 4.3. Binding Request Option
  1070.  
  1071.    The Binding Request destination option is used to request a mobile
  1072.    node's binding from the mobile node.  When a mobile node receives
  1073.    a packet containing a Binding Request option, it SHOULD return a
  1074.    Binding Update (Section 4.1) to that node.
  1075.  
  1076.    The Binding Request option is encoded in type-length-value (TLV)
  1077.    format as follows:
  1078.  
  1079.     0                   1
  1080.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  1081.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1082.    |  Option Type  | Option Length |
  1083.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1084.  
  1085.       Option Type
  1086.  
  1087.          194 ???
  1088.  
  1089.       Option Length
  1090.  
  1091.          8-bit unsigned integer.  Length of the option, in octets,
  1092.          excluding the Option Type and Option Length fields.  For the
  1093.          current definition of the Binding Acknowledgement option, this
  1094.          field MUST be set to 0.
  1095.  
  1096.    The three highest-order bits of the Option Type are encoded to
  1097.    indicate specific processing of the option [5].  For the Binding
  1098.    Request option, these three bits are set to 110, indicating that the
  1099.    data within the option cannot change en-route to the packet's final
  1100.    destination, and that any IPv6 node processing this option that does
  1101.    not recognize the Option Type must discard the packet and, only if
  1102.    the packet's Destination Address was not a multicast address, return
  1103.    an ICMP Parameter Problem, Code 2, message to the packet's Source
  1104.    Address.
  1105.  
  1106.    Extensions to the Binding Request option format may be included after
  1107.    the fixed portion of the Binding Request option specified above.
  1108.    The presence of such extensions will be indicated by the Option
  1109.    Length field.  When the Option Length is greater than 0 octets,
  1110.    the remaining octets are interpreted as extensions.  Currently, no
  1111.    extensions have been defined.
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120. Johnson and Perkins            Expires 26 May 1997             [Page 17]
  1121.  
  1122. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1123.  
  1124.  
  1125. 5. Requirements for IPv6 Nodes
  1126.  
  1127.    Mobile IPv6 places some special requirements on the functions
  1128.    provided by different IPv6 nodes.  This section summarizes those
  1129.    requirements, identifying the functionality each requirement is
  1130.    intended to support.  Further details on this functionality is
  1131.    provided in the following sections.
  1132.  
  1133.    Since any IPv6 node may at any time be a correspondent node of a
  1134.    mobile node, the following requirements pertain to all IPv6 nodes:
  1135.  
  1136.     -  Every IPv6 node SHOULD be able to process a received Binding
  1137.        Update option, and to return a Binding Acknowledgement message if
  1138.        requested.
  1139.  
  1140.     -  Every IPv6 node SHOULD be able to maintain a Binding Cache of the
  1141.        bindings received in accepted Binding Updates.
  1142.  
  1143.    In order for a mobile node to operate correctly while away from
  1144.    home, at least one IPv6 router in the mobile node's home subnet must
  1145.    function as a home agent for the mobile node.  The following special
  1146.    requirements pertain to all IPv6 routers capable of serving as a home
  1147.    agent:
  1148.  
  1149.     -  Every home agent MUST be able to maintain a registry of mobile
  1150.        node bindings, recording each mobile node's primary care-of
  1151.        address, for those mobile nodes for which it is serving as the
  1152.        home agent.
  1153.  
  1154.     -  Every home agent MUST be able to intercept packets (using proxy
  1155.        Neighbor Discovery) on the local subnet addressed to a mobile
  1156.        node for which it is currently serving as the home agent while
  1157.        that mobile node is away from home.
  1158.  
  1159.     -  Every home agent MUST be able to encapsulate such intercepted
  1160.        packets in order to tunnel them to the primary care-of address
  1161.        for the mobile node indicated in its binding.
  1162.  
  1163.     -  Every home agent MUST be able to return Binding Acknowledgements
  1164.        in response to Binding Updates received from a mobile node.
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176. Johnson and Perkins            Expires 26 May 1997             [Page 18]
  1177.  
  1178. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1179.  
  1180.  
  1181.    Finally, the following requirements pertain all IPv6 nodes capable of
  1182.    functioning as mobile nodes:
  1183.  
  1184.     -  Every IPv6 mobile node MUST be able to perform IPv6
  1185.        decapsulation [4].
  1186.  
  1187.     -  Every IPv6 mobile node MUST support sending Binding Updates, as
  1188.        specified in Sections 8.3, 8.4, and 8.5; and MUST be able to
  1189.        receive and process Binding Acknowledgements, as specified in
  1190.        Section 8.8.
  1191.  
  1192.     -  Every IPv6 mobile node MUST maintain a Binding Update List in
  1193.        which it records the IP address of each other node to which it
  1194.        has sent a Binding Update, for which the Lifetime sent in that
  1195.        binding has not yet expired.
  1196.  
  1197.  
  1198.  
  1199.  
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232. Johnson and Perkins            Expires 26 May 1997             [Page 19]
  1233.  
  1234. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1235.  
  1236.  
  1237. 6. Correspondent Node Operation
  1238.  
  1239.    A correspondent node is any node communicating with a mobile node.
  1240.    The correspondent node, itself, may be fixed or mobile, and may
  1241.    possibly also be functioning as a home agent for Mobile IPv6.  The
  1242.    procedures in this section thus apply to all IPv6 nodes.
  1243.  
  1244.  
  1245. 6.1. Receiving Binding Updates
  1246.  
  1247.    Upon receiving a Binding Update option in some packet, the receiving
  1248.    node MUST validate the packet according to the following tests:
  1249.  
  1250.     -  The packet contains an IP Authentication header and the
  1251.        authentication is valid [1].  The Authentication header is
  1252.        assumed to provide both authentication and integrity protection.
  1253.  
  1254.     -  The Option Length field in the option is greater than or equal to
  1255.        24 octets if the Home Link-Local Address (L) bit is not set, or
  1256.        greater or equal to 40 octets if the Home Link-Local Address (L)
  1257.        bit is set.
  1258.  
  1259.     -  The Identification field is valid.
  1260.  
  1261.    Any Binding Update not satisfying all of these tests MUST be silently
  1262.    ignored, although the remainder of the packet (i.e., other options,
  1263.    extension headers, or payload) SHOULD be processed normally according
  1264.    to any procedure defined for that part of the packet.
  1265.  
  1266.    If the Binding Update is valid according to the tests above, then the
  1267.    Binding Update is processed further as follows:
  1268.  
  1269.     -  If the Lifetime specified in the Binding Update is nonzero and
  1270.        the specified Care-of Address is not equal to the Source Address
  1271.        in the IP header of the packet carrying the Binding Update,
  1272.        then this is a request to cache a binding for the mobile node
  1273.        (the home address of the mobile node is specified by the Source
  1274.        Address field in the packet's IP header).  Processing for this
  1275.        type of received Binding Update is described in Section 6.2.
  1276.  
  1277.     -  If the Lifetime specified in the Binding Update is zero or the
  1278.        specified Care-of Address matches the Source Address field in the
  1279.        IP header of the packet carrying the Binding Update, then this is
  1280.        a request to delete the mobile node's binding (as above, the home
  1281.        address of the mobile node is specified by the Source Address
  1282.        field in the packet's IP header).  Processing for this type of
  1283.        received Binding Update is described in Section 6.3.
  1284.  
  1285.  
  1286.  
  1287.  
  1288. Johnson and Perkins            Expires 26 May 1997             [Page 20]
  1289.  
  1290. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1291.  
  1292.  
  1293. 6.2. Requests to Cache a Binding
  1294.  
  1295.    If a node receives a valid Binding Update requesting it to cache a
  1296.    binding for a mobile node, as specified in Section 6.1, then the node
  1297.    MUST examine the Home Registration (H) bit in the Binding Update
  1298.    to determine how to further process the Binding Update.  If the
  1299.    Home Registration (H) bit is set, the Binding Update is processed
  1300.    according to the procedure specified in Section 7.1.
  1301.  
  1302.    If the Home Registration (H) bit is not set, then the receiving node
  1303.    SHOULD create a new entry in its Binding Cache for this mobile node
  1304.    (or update its existing Binding Cache entry for this mobile node, if
  1305.    such an entry already exists).  The home address of the mobile node
  1306.    is taken from the Source Address field in the packet's IP header.
  1307.    The new Binding Cache entry records the association between this
  1308.    address and the Care-of Address specified in the Binding Update.
  1309.    The node must also begin a timer to delete this Binding Cache entry
  1310.    after the expiration of the Lifetime period specified in the Binding
  1311.    Update.
  1312.  
  1313.  
  1314. 6.3. Requests to Delete a Binding
  1315.  
  1316.    If a node receives a valid Binding Update requesting it to delete
  1317.    a binding for a mobile node, as specified in Section 6.1, then the
  1318.    node MUST examine the Home Registration (H) bit in the Binding Update
  1319.    to determine how to further process the Binding Update.  If the
  1320.    Home Registration (H) bit is set, the Binding Update is processed
  1321.    according to the procedure specified in Section 7.2.
  1322.  
  1323.    If the Home Registration (H) bit is not set, then the receiving node
  1324.    MUST delete any existing entry in its Binding Cache for this mobile
  1325.    node.  The home address of the mobile node is taken from the Source
  1326.    Address field in the packet's IP header.
  1327.  
  1328.  
  1329. 6.4. Sending Binding Acknowledgements
  1330.  
  1331.    When any node receives a packet containing a Binding Update option
  1332.    in which the Acknowledge (A) bit is set, it SHOULD return a Binding
  1333.    Acknowledgement message acknowledging receipt of the Binding
  1334.    Update.  If the node accepts the Binding Update and adds the binding
  1335.    contained in it to its Binding Cache, the Status field in the
  1336.    Binding Acknowledgement MUST be set to a value less than 128; if
  1337.    the node rejects the Binding Update and does not add the binding
  1338.    contained in it to its Binding Cache, the Status field in the Binding
  1339.    Acknowledgement MUST be set to a value greater than or equal to 128.
  1340.  
  1341.  
  1342.  
  1343.  
  1344. Johnson and Perkins            Expires 26 May 1997             [Page 21]
  1345.  
  1346. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1347.  
  1348.  
  1349.    Specific values for the Status field are described in Section 4.2 and
  1350.    in the most recent "Assigned Numbers" [12].
  1351.  
  1352.    As described in Section 4.2, the packet in which the Binding
  1353.    Acknowledgement is returned MUST include an IPv6 Authentication
  1354.    header [1] in order to protect against forged Binding
  1355.    Acknowledgements, and the packet MUST be sent using a Routing
  1356.    header through the care-of address contained in the Binding Update
  1357.    being acknowledged.  This ensures that the Binding Acknowledgement
  1358.    will be routed to the current location of the node sending the
  1359.    Binding Update, whether the Binding Update was accepted or rejected.
  1360.  
  1361.  
  1362. 6.5. Cache Replacement Policy
  1363.  
  1364.    Any entry in a node's Binding Cache MUST be deleted after the
  1365.    expiration of the Lifetime specified in the Binding Update from which
  1366.    the entry was created or was last updated.  Conceptually, a node
  1367.    maintains a separate timer for each entry in its Binding Cache.  When
  1368.    creating or updating a Binding Cache entry in response to a received
  1369.    and accepted Binding Update, the node sets the timer for this entry
  1370.    to the specified Lifetime period.  When a Binding Cache entry's timer
  1371.    expires, the node deletes the entry.
  1372.  
  1373.    Each node's Binding Cache will, by necessity, have a finite size.
  1374.    A node MAY use any reasonable local policy for managing the space
  1375.    within its Binding Cache, except that any entry marked as a "home
  1376.    registration" (Section 7.1) MUST NOT be deleted from the cache until
  1377.    the expiration of its lifetime period.  When attempting to add a new
  1378.    "home registration" entry in response to a Binding Update with the
  1379.    Home Registration (H) bit set, if insufficient space exists (or can
  1380.    be reclaimed) in the node's Binding Cache, the node MUST reject the
  1381.    Binding Update and SHOULD return a Binding Acknowledgement message
  1382.    to the sending mobile node, in which the Status field is set to 131
  1383.    (Insufficient resources).  When otherwise attempting to add a new
  1384.    entry to its Binding Cache, a node MAY, if needed, choose to drop any
  1385.    entry already in its Binding Cache, other than a "home registration"
  1386.    entry, in order to make space for the new entry.  For example, a
  1387.    "least-recently used" (LRU) strategy for cache entry replacement is
  1388.    likely to work well.
  1389.  
  1390.    If a packet is sent by a node to a destination for which it has
  1391.    dropped the cache entry from its Binding Cache, the packet will be
  1392.    routed normally, leading to the mobile node's home subnet.  There,
  1393.    the packet will be intercepted by the mobile node's home agent and
  1394.    tunneled to the mobile node's current primary care-of address.  As
  1395.    when a Binding Cache entry is initially created, this indirect
  1396.    routing to the mobile node through its home agent will result in the
  1397.  
  1398.  
  1399.  
  1400. Johnson and Perkins            Expires 26 May 1997             [Page 22]
  1401.  
  1402. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1403.  
  1404.  
  1405.    mobile node sending a Binding Update to this sending node, allowing
  1406.    this node to add an entry again for this destination to its Binding
  1407.    Cache.
  1408.  
  1409.  
  1410. 6.6. Receiving ICMP Error Messages
  1411.  
  1412.    When a correspondent node sends a packet to a mobile node, if the
  1413.    correspondent node has a Binding Cache entry for the destination
  1414.    mobile node's address (its home address), then the correspondent
  1415.    node uses a Routing header to deliver the packet to the mobile node
  1416.    through the care-of address recorded in the Binding Cache entry.  Any
  1417.    ICMP error message caused by the packet on its way to the mobile node
  1418.    will be returned normally to the correspondent node.
  1419.  
  1420.    On the other hand, if the correspondent node has no Binding Cache
  1421.    entry for the mobile node, the packet will be routed to the mobile
  1422.    node's home subnet, where it will be intercepted by the mobile node's
  1423.    home agent, encapsulated, and tunneled to the mobile node's care-of
  1424.    address.  Any ICMP error message caused by the packet on its way to
  1425.    the mobile node while in the tunnel, will be returned to the mobile
  1426.    node's home agent (the source of the tunnel) By the definition of
  1427.    IPv6 encapsulation [4], this encapsulating node MUST relay certain
  1428.    ICMP error messages back to the original sender of the packet, which
  1429.    in this case is the correspondent node.
  1430.  
  1431.    Likewise, if a packet for a mobile node arrives at the mobile node's
  1432.    previous default router (e.g., the mobile node moved after the packet
  1433.    was sent), the router will encapsulate and tunnel the packet to the
  1434.    mobile node's new care-of address (if it has a Binding Cache entry
  1435.    for the mobile node).  As above, any ICMP error message caused by the
  1436.    packet while in this tunnel will be returned to the previous default
  1437.    router (the source of the tunnel), which MUST relay certain ICMP
  1438.    error messages back to the correspondent node [4].
  1439.  
  1440.    Thus, in all cases, any meaningful ICMP error messages caused by
  1441.    packets from a correspondent node to a mobile node will be returned
  1442.    to the correspondent node.  If the correspondent node receives
  1443.    persistent ICMP Host Unreachable or Network Unreachable error
  1444.    messages after sending packets to a mobile node based on an entry in
  1445.    its Binding Cache, the correspondent node SHOULD delete this Binding
  1446.    Cache entry.  If the correspondent node subsequently transmits
  1447.    another packet to the mobile node, the packet will be routed to the
  1448.    mobile node's home subnet, intercepted by the mobile node's home
  1449.    agent, and tunneled to the mobile node's care-of address using IPv6
  1450.    encapsulation.  The mobile node will then return a Binding Update to
  1451.    the correspondent node, allowing it to recreate a (correct) Binding
  1452.    Cache entry for the mobile node.
  1453.  
  1454.  
  1455.  
  1456. Johnson and Perkins            Expires 26 May 1997             [Page 23]
  1457.  
  1458. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1459.  
  1460.  
  1461. 6.7. Sending Packets to a Mobile Node
  1462.  
  1463.    Before sending any packet, the sending node SHOULD examine its
  1464.    Binding Cache for an entry for the destination address to which the
  1465.    packet is being sent.  If the sending node has a Binding Cache entry
  1466.    for this address, the sending node SHOULD use a Routing header to
  1467.    route the packet to this mobile node (the destination node) through
  1468.    the care-of address recorded in that Binding Cache entry.  For
  1469.    example, assuming use of a Type 0 Routing header [5], if no other use
  1470.    of a Routing header is involved in the routing of this packet, the
  1471.    mobile node sets the following fields in the packet's IP header and
  1472.    Routing header as indicated below:
  1473.  
  1474.     -  The Destination Address in the packet's IP header is set to the
  1475.        mobile node's care-of address copied from the Binding Cache
  1476.        entry.
  1477.  
  1478.     -  The Routing header is initialized to contain a single route
  1479.        segment, with an Address of the mobile node's home address (the
  1480.        original destination address to which the packet was being sent).
  1481.  
  1482.    Following the definition of a Type 0 Routing header [5], this packet
  1483.    will routed to the mobile node's care-of address, where it will be
  1484.    delivered to the mobile node (the mobile node has associated the
  1485.    care-of address with its network interface).  Normal processing of
  1486.    the Routing header by the mobile node will then proceed as follows:
  1487.  
  1488.     -  The mobile node swaps the Destination Address in the packet's IP
  1489.        header and the Address specified in the Routing header.  This
  1490.        results in the packet's IP Destination Address being set to the
  1491.        mobile node's home address.
  1492.  
  1493.     -  The mobile node then resubmits the packet to its IPv6 module for
  1494.        further processing.  Since the mobile node recognizes its own
  1495.        home address as one if its current IP addresses, the packet is
  1496.        processed further within the mobile node, in the same way then as
  1497.        if the mobile node was at home.
  1498.  
  1499.    If, instead, the sending node has no Binding Cache entry for the
  1500.    destination address to which the packet is being sent, the sending
  1501.    node simply sends the packet normally, with no Routing header.  If
  1502.    the destination node is not a mobile node (or is a mobile node that
  1503.    is currently at home), the packet will be delivered directly to this
  1504.    node and processed normally by it.  If, however, the destination node
  1505.    is a mobile node that is currently away from home, the packet will
  1506.    be intercepted by the mobile node's home agent and tunneled (using
  1507.    IPv6 encapsulation [4]) to the mobile node's current primary care-of
  1508.    address, as described in Section 7.3.  The mobile node will then send
  1509.  
  1510.  
  1511.  
  1512. Johnson and Perkins            Expires 26 May 1997             [Page 24]
  1513.  
  1514. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1515.  
  1516.  
  1517.    a Binding Update to the sending node, as described in Section 8.4,
  1518.    allowing the sending node to create a Binding Cache entry for its use
  1519.    in sending subsequent packets to this mobile node.
  1520.  
  1521.  
  1522.  
  1523.  
  1524.  
  1525.  
  1526.  
  1527.  
  1528.  
  1529.  
  1530.  
  1531.  
  1532.  
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  
  1539.  
  1540.  
  1541.  
  1542.  
  1543.  
  1544.  
  1545.  
  1546.  
  1547.  
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568. Johnson and Perkins            Expires 26 May 1997             [Page 25]
  1569.  
  1570. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1571.  
  1572.  
  1573. 7. Home Agent Operation
  1574.  
  1575. 7.1. Primary Care-of Address Registration
  1576.  
  1577.    General processing of a received Binding Update that requests a
  1578.    binding to be cached, is described in Section 6.2.  However, if the
  1579.    Home Registration (H) bit is set in the Binding Update, then the
  1580.    receiving node MUST process the Binding Update as specified in this
  1581.    section, rather than following the general procedure specified in
  1582.    Section 6.2.
  1583.  
  1584.    To begin processing the Binding Update, the home agent MUST perform
  1585.    the following sequence of tests:
  1586.  
  1587.     -  If the node is not a router that implements home agent
  1588.        functionality, then the node MUST reject the Binding Update and
  1589.        SHOULD return a Binding Acknowledgement message to the mobile
  1590.        node, in which the Status field is set to 132 (Home registration
  1591.        not supported).
  1592.  
  1593.     -  Else, if the home address for the binding in the Binding Update
  1594.        (the Source Address in the packet's IP header) is not an on-link
  1595.        IPv6 address with respect to the home agent's current Prefix
  1596.        List, then the home agent MUST reject the Binding Update and
  1597.        SHOULD return a Binding Acknowledgement message to the mobile
  1598.        node, in which the Status field is set to 133 (Not home subnet).
  1599.  
  1600.     -  Else, if the home agent chooses to reject the Binding Update for
  1601.        any other reason (e.g., insufficient resources to serve another
  1602.        mobile node as a home agent), then the home agent SHOULD return
  1603.        a Binding Acknowledgement message to the mobile node, in which
  1604.        the Status field is set to an appropriate value to indicate the
  1605.        reason for the rejection.
  1606.  
  1607.    If the home agent does not reject the Binding Update as described
  1608.    above, then it becomes the home agent for the mobile node.  The new
  1609.    home agent (the receiving node) MUST then create a new entry or
  1610.    update the existing entry in its Binding Cache for this mobile node's
  1611.    home address, as described in Section 6.2.  In addition, the home
  1612.    agent MUST mark this Binding Cache entry as a "home registration"
  1613.    to indicate that the node is serving as a home agent for this
  1614.    binding.  Binding Cache entries marked as a "home registration" MUST
  1615.    be excluded from the normal cache replacement policy used for the
  1616.    Binding Cache (Section 6.5) and MUST NOT be removed from the Binding
  1617.    Cache until the expiration of the Lifetime period.
  1618.  
  1619.    If the home agent was not already serving as a home agent for this
  1620.    mobile node (the home agent did not already have a Binding Cache
  1621.  
  1622.  
  1623.  
  1624. Johnson and Perkins            Expires 26 May 1997             [Page 26]
  1625.  
  1626. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1627.  
  1628.  
  1629.    entry for this address marked as a "home registration"), then the
  1630.    home agent MUST multicast onto the home subnet (to the all-nodes
  1631.    multicast address) a Neighbor Advertisement message [8] on behalf
  1632.    of the mobile node, to advertise the home agent's own link-layer
  1633.    address for the mobile node's home IP address.  The Target Address in
  1634.    the Neighbor Advertisement message MUST be set to the mobile node's
  1635.    home address, and the Advertisement MUST include a Target Link-layer
  1636.    Address option specifying the home agent's link-layer address.  The
  1637.    Solicited Flag (S) in the Advertisement MUST NOT be set, since it was
  1638.    not solicited by any Neighbor Solicitation message.  The Override
  1639.    Flag (O) in the Advertisement MUST be set, indicating that the
  1640.    Advertisement SHOULD override any existing Neighbor Cache entry at
  1641.    any node receiving it.
  1642.  
  1643.    Any node on the home subnet receiving this Neighbor Advertisement
  1644.    message will thus update its Neighbor Cache to associate the mobile
  1645.    node's home address with the home agent's link layer address, causing
  1646.    it to transmit future packets for the mobile node instead to the
  1647.    mobile node's home agent.  Since multicasts on the local link (such
  1648.    as Ethernet) are typically not guaranteed to be reliable, the home
  1649.    agent MAY retransmit this Neighbor Advertisement message up to
  1650.    MAX_ADVERT_REXMIT times to increase its reliability.  It is still
  1651.    possible that some nodes on the home subnet will not receive any of
  1652.    these Neighbor Advertisements, but these nodes will eventually be
  1653.    able to detect the link-layer address change for the mobile node's
  1654.    home address, through use of Neighbor Unreachability Detection [8].
  1655.  
  1656.    In addition, while this node is serving as a home agent to this
  1657.    mobile node (it still has a "home registration" entry for this mobile
  1658.    node in its Binding Cache), it MUST act as a proxy for this mobile
  1659.    node to reply to any received Neighbor Solicitation messages for it.
  1660.    When a home agent receives a Neighbor Solicitation message, it MUST
  1661.    check if the Target Address specified in the message matches the home
  1662.    address of any mobile node for which it has a Binding Cache entry
  1663.    marked as a "home registration".  If such an entry exists in its
  1664.    Binding Cache, the home agent MUST reply to the Neighbor Solicitation
  1665.    message with a Neighbor Advertisement message, giving the home
  1666.    agent's own link-layer address as the link-layer address for the
  1667.    specified Target Address.  Likewise, if the mobile node included its
  1668.    home link-local address and set the Home Link-Local Address (L) bit
  1669.    in its Binding Update with which it registered with its home agent,
  1670.    its home agent MUST also similarly act as a proxy for the mobile
  1671.    node's home link-local address while it has a "home registration"
  1672.    entry in its Binding Cache for the mobile node.  Acting as a proxy
  1673.    in this way allows other nodes on the mobile node's home subnet to
  1674.    resolve the mobile node's IPv6 home address and IPv6 link-local
  1675.    address, and allows the home agent to to defend these addresses on
  1676.    the home subnet for Duplicate Address Detection [8].
  1677.  
  1678.  
  1679.  
  1680. Johnson and Perkins            Expires 26 May 1997             [Page 27]
  1681.  
  1682. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1683.  
  1684.  
  1685. 7.2. Primary Care-of Address De-registration
  1686.  
  1687.    General processing of a received Binding Update that requests a
  1688.    binding to be deleted, is described in Section 6.3.  However, if the
  1689.    Home Registration (H) bit is set in the Binding Update, then the
  1690.    receiving node MUST process the Binding Update as specified in this
  1691.    section, rather than following the general procedure specified in
  1692.    Section 6.3.
  1693.  
  1694.    To begin processing the Binding Update, the home agent MUST perform
  1695.    the following sequence of tests:
  1696.  
  1697.     -  If the node is not a router that implements home agent
  1698.        functionality, then the node MUST reject the Binding Update and
  1699.        SHOULD return a Binding Acknowledgement message to the mobile
  1700.        node, in which the Status field is set to 132 (Home registration
  1701.        not supported).
  1702.  
  1703.     -  Else, if the home address for the binding in the Binding Update
  1704.        (the Source Address in the packet's IP header) is not an on-link
  1705.        IPv6 address with respect to the home agent's current Prefix
  1706.        List, then it MUST reject the Binding Update and SHOULD return a
  1707.        Binding Acknowledgement message to the mobile node, in which the
  1708.        Status field is set to 133 (Not home subnet).
  1709.  
  1710.    If the home agent does not reject the Binding Update as described
  1711.    above, then it MUST delete any existing entry in its Binding Cache
  1712.    for this mobile node.
  1713.  
  1714.    In addition, the home agent MUST multicast a Neighbor Advertisement
  1715.    message (to the all-nodes multicast address), giving the mobile
  1716.    node's home address as the Target Address, and specifying the mobile
  1717.    node's link-layer address in a Target Link-layer Address option in
  1718.    the Neighbor Advertisement message.  The home agent MAY retransmit
  1719.    this Neighbor Advertisement message up to MAX_ADVERT_REXMIT times
  1720.    to increase its reliability; any nodes on the home subnet that miss
  1721.    all of these Neighbor Advertisements can also eventually detect the
  1722.    link-layer address change for the mobile node's home address, through
  1723.    use of Neighbor Unreachability Detection [8].
  1724.  
  1725.  
  1726. 7.3. Tunneling Intercepted Packets to a Mobile Node
  1727.  
  1728.    For any packet sent to a mobile node from the mobile node's home
  1729.    agent, for which the home agent is the original sender of the packet,
  1730.    the home agent is operating as a correspondent node of the mobile
  1731.    node for this packet and the procedures described in Section 6.7
  1732.    apply.  The home agent uses a Routing header to route the packet
  1733.  
  1734.  
  1735.  
  1736. Johnson and Perkins            Expires 26 May 1997             [Page 28]
  1737.  
  1738. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1739.  
  1740.  
  1741.    to the mobile node through the care-of address in the home agent's
  1742.    Binding Cache (the mobile node's primary care-of address, in this
  1743.    case).
  1744.  
  1745.    In addition, while the mobile node is away from home and this node
  1746.    is acting as the mobile node's home agent, the home agent intercepts
  1747.    any packets on the home subnet addressed to the mobile node's
  1748.    home address, as described in Section 7.1.  The home agent cannot
  1749.    use a Routing header to forward these intercepted packets to the
  1750.    mobile node, since it cannot modify the packet in flight without
  1751.    invalidating any existing IPv6 Authentication header present in the
  1752.    packet [1].
  1753.  
  1754.    For forwarding each intercepted packet to the mobile node, the
  1755.    home agent MUST tunnel the packet to the mobile node using IPv6
  1756.    encapsulation [4]; the tunnel entry point node is the home agent,
  1757.    and the tunnel exit point node is the mobile node itself (using its
  1758.    primary care-of address as registered with the home agent).  When a
  1759.    home agent encapsulates an intercepted packet for forwarding to the
  1760.    mobile node, the home agent sets the Source Address in the prepended
  1761.    tunnel IP header to its own IP address, and sets the Destination
  1762.    Address in the tunnel IP header to the mobile node's primary care-of
  1763.    address.  When received by the mobile node (using its primary care-of
  1764.    address), normal processing of the tunnel header [4] will result in
  1765.    decapsulation and processing of the original packet by the mobile
  1766.    node.
  1767.  
  1768.  
  1769. 7.4. Renumbering the Home Subnet
  1770.  
  1771.    Neighbor Discovery [8] specifies a mechanism by which all nodes on a
  1772.    subnet can gracefully autoconfigure new addresses, say by each node
  1773.    combining a new routing prefix with its existing link-layer address.
  1774.    As currently specified, this mechanism works when the nodes are on
  1775.    the same link as the router issuing the necessary multicast packets
  1776.    to advertise the new routing prefix(es) appropriate for the link.
  1777.  
  1778.    However, for mobile nodes away from home, special care must be taken
  1779.    to allow the mobile nodes to renumber gracefully.  The most direct
  1780.    method of ensuring this is for the home agent to encapsulate and
  1781.    tunnel the multicast packets to the primary care-of address of each
  1782.    mobile node for which it is serving as the home agent.  The rules for
  1783.    this are as follows:
  1784.  
  1785.     -  A mobile node assumes that its routing prefix has not changed
  1786.        unless it receives authenticated Router Advertisement messages
  1787.        from its home agent that the prefix has changed.
  1788.  
  1789.  
  1790.  
  1791.  
  1792. Johnson and Perkins            Expires 26 May 1997             [Page 29]
  1793.  
  1794. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1795.  
  1796.  
  1797.     -  When the mobile node is at home, the home agent does not tunnel
  1798.        Router Advertisements to it.
  1799.  
  1800.     -  The mobile node's home agent serves as a proxy for the mobile
  1801.        node's home address and link-local address, including defending
  1802.        these addresses for Duplicate Address Detection, while the mobile
  1803.        node is registered with the home agent away from home.
  1804.  
  1805.     -  When a home subnet prefix changes, the home agent tunnels Router
  1806.        Advertisement packets to each mobile node which is currently
  1807.        away from home and using a home address with the affected
  1808.        routing prefix.  Such tunneled Router Advertisements MUST be
  1809.        authenticated [1].
  1810.  
  1811.     -  When a mobile node receives a tunneled Router Advertisement
  1812.        containing a new routing prefix, it must perform the standard
  1813.        autoconfiguration operation to create its new address
  1814.  
  1815.     -  When a mobile node returns to its home subnet, it must again
  1816.        perform Duplicate Address Detection at the earliest possible
  1817.        moment after it has registered with its home agent.
  1818.  
  1819.     -  A mobile node may send a Router Solicitation to its home agent at
  1820.        any time, within the constraints imposed by rate control in the
  1821.        Neighbor Discovery specification [8]
  1822.  
  1823.  
  1824.  
  1825.  
  1826.  
  1827.  
  1828.  
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848. Johnson and Perkins            Expires 26 May 1997             [Page 30]
  1849.  
  1850. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1851.  
  1852.  
  1853. 8. Mobile Node Operation
  1854.  
  1855. 8.1. Movement Detection
  1856.  
  1857.    A mobile node MAY use any combination of mechanisms available to
  1858.    it to detect when its link-level point of attachment has moved
  1859.    from one IP subnet to another.  The primary movement detection
  1860.    mechanism for Mobile IPv6 defined here uses the facilities of
  1861.    IPv6 Neighbor Discovery, including Router Discovery and Neighbor
  1862.    Unreachability Detection.  The description here is based on the
  1863.    conceptual model of the organization and data structures defined by
  1864.    Neighbor Discovery [8].
  1865.  
  1866.    Mobile nodes SHOULD use Router Discovery to discover new routers and
  1867.    on-link network prefixes; a mobile node MAY send Router Solicitation
  1868.    messages, or MAY wait for unsolicited (periodic) Router Advertisement
  1869.    messages, as specified for Router Discovery [8].  Based on received
  1870.    Router Advertisement messages, a mobile node (in the same way as any
  1871.    other node) maintains an entry in its Default Router List for each
  1872.    router, and an entry in its Prefix List for each network prefix, that
  1873.    it currently considers to be on-link.  Each entry in these lists has
  1874.    an associated invalidation timer value (extracted from the Router
  1875.    Advertisement) used to expire the entry when it becomes invalid.
  1876.  
  1877.    While away from home, a mobile node SHOULD select one router from its
  1878.    Default Router List to use as its default router, and one network
  1879.    prefix advertised by that router from its Prefix List to use as
  1880.    the network prefix in its primary care-of address.  A mobile node
  1881.    MAY also have associated additional care-of addresses, using other
  1882.    network prefixes from its Prefix List.  The method by which a mobile
  1883.    node selects and forms a care-of address from the available network
  1884.    prefixes is described in Section 8.2.  The mobile node registers
  1885.    its primary care-of address with its home agent, as described in
  1886.    Section 8.3.
  1887.  
  1888.    While away from home and using some router as its default router,
  1889.    it is important for a mobile node to be able to quickly detect when
  1890.    that router becomes unreachable, so that it can switch to a new
  1891.    default router and to a new primary care-of address.  Since some
  1892.    links (notably wireless) do not necessarily work equally well in both
  1893.    directions, it is likewise important for the mobile node to detect
  1894.    when it becomes unreachable to its default router, so that the mobile
  1895.    node can take steps to ensure that any correspondent nodes attempting
  1896.    to communicate with the it can still reach it through some other
  1897.    route.
  1898.  
  1899.    To detect when its default router becomes unreachable, a mobile
  1900.    node SHOULD use Neighbor Unreachability Detection.  As specified in
  1901.  
  1902.  
  1903.  
  1904. Johnson and Perkins            Expires 26 May 1997             [Page 31]
  1905.  
  1906. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1907.  
  1908.  
  1909.    Neighbor Discovery [8], while the mobile node is actively sending
  1910.    packets to (or through) its default router, the mobile node can
  1911.    detect that the router is still reachable either through indications
  1912.    from upper layer protocols on the mobile node that a connection is
  1913.    making "forward progress" (e.g., receipt of TCP acknowledgements for
  1914.    new data transmitted), or through receipt of a Neighbor Advertisement
  1915.    message form its default router in response to an explicit Neighbor
  1916.    Solicitation messages to it.  Note that although this mechanism only
  1917.    detects that the mobile node's default router has become unreachable
  1918.    to the mobile node while the mobile node is actively sending packets
  1919.    to it, this is the only time that this direction of reachability
  1920.    confirmation is needed.  Confirmation that the mobile node is still
  1921.    reachable from the router is handled separately, as described below.
  1922.  
  1923.    For a mobile node to detect when it has become unreachable to its
  1924.    default router, however, the mobile node cannot efficiently rely on
  1925.    Neighbor Unreachability Detection alone, since the network overhead
  1926.    would be prohibitively high in many cases for a mobile node to
  1927.    continually probe its default router with Neighbor Solicitation
  1928.    messages even when it is not otherwise actively sending packets to
  1929.    it.  Instead, a mobile node SHOULD consider receipt of any IPv6
  1930.    packets from its current default router as an indication that it is
  1931.    still reachable from the router.  Both packets from the router's IP
  1932.    address and (IPv6) packets from its link-layer address (e.g., those
  1933.    forwarded but not originated by the router) SHOULD be considered.
  1934.  
  1935.    Since the router SHOULD be sending periodic multicast Router
  1936.    Advertisement messages, the mobile node will have frequent
  1937.    opportunity to check if it is still reachable to its default router,
  1938.    even in the absence of other packets to it from the router.  On some
  1939.    types of network interfaces, the mobile node MAY also supplement this
  1940.    by setting its network interface into "promiscuous" receive mode,
  1941.    so that it is able to receive all packets on the link, including
  1942.    those not link-level addressed to it.  The mobile node will then
  1943.    be able to detect any packets sent by the router, in order to to
  1944.    detect reachability from the router.  This may be useful on very low
  1945.    bandwidth (e.g., wireless) links, but its use MUST be configurable on
  1946.    the mobile node.
  1947.  
  1948.    If the above means do not provide indication that the mobile node
  1949.    is still reachable from its current default router (i.e., the
  1950.    mobile node receives no packets form the router for a period of
  1951.    time), then the mobile node SHOULD actively probe the router with
  1952.    Neighbor Solicitation messages, even if it is not otherwise actively
  1953.    sending packets to the router.  If it receives a solicited Neighbor
  1954.    Advertisement message in response from the router, then the mobile
  1955.    node can deduce that it is still reachable.  It is expected that the
  1956.    mobile node will in most cases be able to determine its reachability
  1957.  
  1958.  
  1959.  
  1960. Johnson and Perkins            Expires 26 May 1997             [Page 32]
  1961.  
  1962. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  1963.  
  1964.  
  1965.    from the router by listening for packets from the router as described
  1966.    above, and thus, such extra Neighbor Solicitation probes should
  1967.    rarely be necessary.
  1968.  
  1969.    With some types of networks, it is possible that additional
  1970.    indications about link-layer mobility can be obtained from
  1971.    lower-layer protocol or device driver software within the mobile
  1972.    node.  However, a mobile node MUST NOT assume that all link-layer
  1973.    mobility indications from lower layers indicate a movement of the
  1974.    mobile node's link-layer connection to a new IP subnet, such that the
  1975.    mobile node would need to switch to a new default router and primary
  1976.    care-of address.  Upon lower-layer indication of link-layer mobility,
  1977.    the mobile node SHOULD send Router Solicitation messages to determine
  1978.    if new routers (and new on-link network prefixes) are present on its
  1979.    new link.
  1980.  
  1981.    Such lower-layer information might also be useful to a mobile node in
  1982.    deciding to switch its primary care-of address to one of the other
  1983.    care-of addresses it has formed from the on-link network prefixes
  1984.    currently available through different default routers from which the
  1985.    mobile node is reachable.  For example, a mobile node MAY use signal
  1986.    strength or signal quality information (with suitable hysteresis)
  1987.    for its link with the available default routers to decide when to
  1988.    switch to a new primary care-of address using that default router
  1989.    rather than its current default router (and current primary care-of
  1990.    address).  Even though the mobile node's current default router may
  1991.    still be reachable in terms of Neighbor Unreachability Detection, the
  1992.    mobile node MAY use such lower-layer information to determine that
  1993.    switching to a new default router would provide a better connection.
  1994.  
  1995.  
  1996. 8.2. Forming New Care-of Addresses
  1997.  
  1998.    After detecting that its link-layer point of attachment has moved
  1999.    from one IPv6 subnet to another (i.e., its current default router
  2000.    has become unreachable and it has discovered a new default router),
  2001.    a mobile node SHOULD form a new primary care-of address using one of
  2002.    the on-link network prefixes advertised by the new router.  A mobile
  2003.    node MAY form a new primary care-of address at any time, except
  2004.    that it MUST NOT do so too frequently (not more often than once per
  2005.    MAX_UPDATE_RATE seconds).
  2006.  
  2007.    In addition, after discovering a new on-link network prefix, a
  2008.    mobile node MAY form a new (non-primary) care-of address using that
  2009.    network prefix, even when it has not switched to a new default
  2010.    router.  A mobile node can have only one primary care-of address
  2011.    at a time (registered with its home agent), but it MAY have an
  2012.    additional care-of address for each network prefix on its current
  2013.  
  2014.  
  2015.  
  2016. Johnson and Perkins            Expires 26 May 1997             [Page 33]
  2017.  
  2018. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2019.  
  2020.  
  2021.    link.  Furthermore, since a wireless network interface may actually
  2022.    allow a mobile node to be reachable on more than one link at a time
  2023.    (i.e., within wireless transmitter range of routers on more than one
  2024.    separate link), a mobile node MAY have care-of addresses on more than
  2025.    one link at a time.  The use of more than one care-of address at a
  2026.    time is described in Section 8.9.
  2027.  
  2028.    As described in Section 3, in order to form a new care-of address,
  2029.    a mobile node MAY use either stateless [14] or stateful (e.g.,
  2030.    DHCPv6 [3]) address autoconfiguration.  If a mobile node needs to
  2031.    send packets as part of the method of address autoconfiguration,
  2032.    it MUST use an IPv6 link-local address rather than its own IPv6
  2033.    home address as the Source Address in the IP header of each such
  2034.    autoconfiguration packet.
  2035.  
  2036.    In some cases, a mobile node may already know a (constant) IPv6
  2037.    address that has been assigned to it for its use only while visiting
  2038.    a specific foreign subnet.  For example, a mobile node may be
  2039.    statically configured with an IPv6 address assigned by the system
  2040.    administrator of some foreign subnet, for its use while visiting that
  2041.    subnet.  If so, rather than using address autoconfiguration to form
  2042.    a new care-of address using this network prefix, the mobile node
  2043.    SHOULD use its own pre-assigned address as its care-of address on
  2044.    this subnet.
  2045.  
  2046.  
  2047. 8.3. Sending Binding Updates to the Home Agent
  2048.  
  2049.    After deciding to change its primary care-of address as described
  2050.    in Sections 8.1 and 8.2, a mobile node MUST register this care-of
  2051.    address with its home agent in order to make this its primary care-of
  2052.    address.  To do so, the mobile node sends a packet to its home agent
  2053.    containing a Binding Update option with the Home Registration (H)
  2054.    bit is set in the Binding Update.  The mobile node also sets the
  2055.    Acknowledge (A) bit in the Binding Update, requesting the home
  2056.    agent to return a Binding Acknowledgement message in response to
  2057.    this Binding Update.  As described in Section 4.2, the mobile node
  2058.    SHOULD retransmit this Binding Update to its home agent until it
  2059.    receives a matching Binding Acknowledgement message.  Once reaching a
  2060.    retransmission timeout period of MAX_BINDACK_TIMEOUT, the mobile node
  2061.    SHOULD continue to periodically retransmit the Binding Update at this
  2062.    rate until acknowledged (or until it begins attempting to register a
  2063.    different primary care-of address).
  2064.  
  2065.  
  2066.  
  2067.  
  2068.  
  2069.  
  2070.  
  2071.  
  2072. Johnson and Perkins            Expires 26 May 1997             [Page 34]
  2073.  
  2074. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2075.  
  2076.  
  2077. 8.4. Sending Binding Updates to Correspondent Nodes
  2078.  
  2079.    A mobile node MAY send a Binding Update to any correspondent node at
  2080.    any time (subject to the rate limiting defined in Section 8.7).  In
  2081.    any Binding Update sent by a mobile node, the Care-of Address field
  2082.    MUST be set to one of the care-of addresses currently in use by the
  2083.    mobile node or to the mobile node's home address.  If set to one of
  2084.    the mobile node's current care-of addresses (the care-of address
  2085.    given MAY differ from the mobile node's primary care-of address), the
  2086.    Binding Update requests the correspondent node to create or update
  2087.    a an entry for the mobile node in the correspondent node's Binding
  2088.    Cache to record this care-of address for use in sending future
  2089.    packets to the mobile node.  If, instead, the Care-of Address field
  2090.    is set to the mobile node's home address, the Binding Update requests
  2091.    the correspondent node to delete any existing Binding Cache entry
  2092.    that it has for the mobile node.  A mobile node MAY set the Care-of
  2093.    Address field differently for sending Binding Updates to different
  2094.    correspondent nodes.
  2095.  
  2096.    When sending any Binding Update, the mobile node MUST record in its
  2097.    Binding Update List the following fields from the Binding Update:
  2098.  
  2099.     -  The IP address of the node to which the Binding Update was sent.
  2100.  
  2101.     -  The home address for which the Binding Update was sent,
  2102.  
  2103.     -  The remaining lifetime of the binding, initialized from the
  2104.        Lifetime field of the Binding Update.
  2105.  
  2106.    The mobile node MUST retain in its Binding Update List information
  2107.    about all Binding Updates sent, for which the lifetime of the
  2108.    binding has not yet expired.  When sending a Binding Update, if an
  2109.    entry already exists in the mobile node's Binding Update List for
  2110.    an earlier Binding Update sent to that same destination node, the
  2111.    existing Binding Update List is updated to reflect the new Binding
  2112.    Update rather than creating a new Binding Update List entry.
  2113.  
  2114.    In general, when a mobile node sends a Binding Update to its home
  2115.    agent to register a new primary care-of address (as described in
  2116.    Section 8.3), the mobile node will also typically send a Binding
  2117.    Update to each correspondent node for which an entry exists in the
  2118.    mobile node's Binding Update List.  Thus, correspondent nodes are
  2119.    generally kept updated and can send almost all packets directly to
  2120.    the mobile node using the mobile node's current binding.
  2121.  
  2122.    The mobile node, however, need not send these Binding Updates
  2123.    immediately after configuring a new care-of address.  For example,
  2124.    since the Binding Update is a destination option and can be included
  2125.  
  2126.  
  2127.  
  2128. Johnson and Perkins            Expires 26 May 1997             [Page 35]
  2129.  
  2130. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2131.  
  2132.  
  2133.    in any packet sent by a mobile node, the mobile node MAY delay
  2134.    sending a new Binding Update to any correspondent node for a
  2135.    short period of time, in hopes that the needed Binding Update
  2136.    can be included in some packet that the mobile node sends to that
  2137.    correspondent node for some other reason (for example, as part of
  2138.    some TCP connection in use).  In this case, when sending a packet
  2139.    to some correspondent node, the mobile node SHOULD check in its
  2140.    Binding Update List to determine if a new Binding Update to this
  2141.    correspondent node is needed, and SHOULD include the new Binding
  2142.    Update in this packet as necessary.
  2143.  
  2144.    In addition, when a mobile node receives a packet for which the
  2145.    mobile node can deduce that the original sender of the packet has no
  2146.    Binding Cache entry for the mobile node, or for which the mobile node
  2147.    can deduce that the original sender of the packet has an out-of-date
  2148.    care-of address in its Binding Cache entry for the mobile node, the
  2149.    mobile node SHOULD return a Binding Update to the sender giving its
  2150.    current care-of address.  In particular, the mobile node SHOULD
  2151.    return a Binding Update in response to receiving a packet that meets
  2152.    all of the following tests:
  2153.  
  2154.     -  The packet was tunneled using IPv6 encapsulation.
  2155.  
  2156.     -  The Destination Address in the tunnel (outer) IP header is equal
  2157.        to any of the mobile node's care-of addresses.
  2158.  
  2159.     -  The Destination Address in the original (inner) IP header is
  2160.        equal to the mobile node's home address.  If the original packet
  2161.        contains a Routing header, the final Address indicated in the
  2162.        Routing header should be used in this comparison rather than the
  2163.        Destination Address in the original IP header.
  2164.  
  2165.     -  The Source Address in the tunnel (outer) IP header differs from
  2166.        the Source Address in the original (inner) IP header.
  2167.  
  2168.    The destination address to which the Binding Update should be sent in
  2169.    response to receiving a packet meeting all of the tests above, is the
  2170.    Source Address in the original (inner) IP header of the packet.
  2171.  
  2172.    Binding Updates sent to correspondent nodes are not generally
  2173.    required to be acknowledged.  However, if the mobile node wants to be
  2174.    sure that its new care-of address has been added to a correspondent
  2175.    node's Binding Cache, the mobile node MAY request an acknowledgement
  2176.    by setting the Acknowledge (A) bit in the Binding Update.  In this
  2177.    case, however, the mobile node SHOULD NOT continue to retransmit the
  2178.    Binding Update once the retransmission timeout period has reached
  2179.    MAX_BINDACK_TIMEOUT.
  2180.  
  2181.  
  2182.  
  2183.  
  2184. Johnson and Perkins            Expires 26 May 1997             [Page 36]
  2185.  
  2186. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2187.  
  2188.  
  2189.    A mobile node MAY choose to keep its location private from certain
  2190.    correspondent nodes, and thus need not send new Binding Updates to
  2191.    those correspondents.  A mobile node MAY also send a Binding Update
  2192.    to such a correspondent node to instruct it to delete any existing
  2193.    binding for the mobile node from its Binding Cache, as described in
  2194.    Section 4.1.  No other IPv6 nodes are authorized to send Binding
  2195.    Updates on behalf of a mobile node.
  2196.  
  2197.  
  2198. 8.5. Sending Binding Updates to the Previous Default Router
  2199.  
  2200.    After switching to a new default router (and thus also changing
  2201.    its primary care-of address), a mobile node SHOULD send a Binding
  2202.    Update message to its previous default router, giving its new care-of
  2203.    address.  If the mobile node sends such a Binding Update, the Source
  2204.    Address in the packet carrying this Binding Update MUST be set the
  2205.    mobile node's old primary care-of address (that it used while using
  2206.    this default router), and the Care-of Address field MUST be set to
  2207.    the mobile node's new primary care-of address.  In addition, the Home
  2208.    Registration (H) bit MUST also be set in this Binding Update, to
  2209.    request the mobile node's previous default router to temporarily act
  2210.    as a home agent for the mobile node's old primary care-of address.
  2211.    Note that the previous router does not necessarily know the mobile
  2212.    node's home address as part of this sequence of events.
  2213.  
  2214.    If any subsequent packets arrive at this previous router for
  2215.    forwarding to the mobile node's old primary care-of address,
  2216.    the router SHOULD encapsulate each such packet (using IPv6
  2217.    encapsulation [4]) and tunnel it to the mobile node at its new
  2218.    primary care-of address.  Moreover, for the lifetime of the "home
  2219.    registration" Binding Cache entry at this router, this router MUST
  2220.    act as a proxy for the mobile node's previous care-of address,
  2221.    for purposes of participation in Neighbor Discovery [8], in the
  2222.    same way as any home agent does for a mobile node's home address
  2223.    (Section 7.1).  This allows the router to intercept packets addressed
  2224.    to the mobile node's previous care-of address, and to encapsulate and
  2225.    tunnel them to the mobile node's new care-of address, as described in
  2226.    Section 7.3.
  2227.  
  2228.  
  2229. 8.6. Retransmitting Binding Updates
  2230.  
  2231.    If, after sending a Binding Update in which the Acknowledge (A)
  2232.    bit is set, a mobile node fails to receive an acceptable Binding
  2233.    Acknowledgement within INITIAL_BINDACK_TIMEOUT seconds, the
  2234.    mobile node SHOULD retransmit the Binding Update until a Binding
  2235.    Acknowledgement is received.  Such a retransmitted Binding
  2236.    Update MUST use he same Identification value as the original
  2237.  
  2238.  
  2239.  
  2240. Johnson and Perkins            Expires 26 May 1997             [Page 37]
  2241.  
  2242. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2243.  
  2244.  
  2245.    transmission.  The retransmissions by the mobile node MUST use
  2246.    an exponential back-off process, in which timeout period is
  2247.    doubled upon each retransmission until either the node receives a
  2248.    Binding Acknowledgement or the timeout period reaches the value
  2249.    MAX_BINDACK_TIMEOUT.
  2250.  
  2251.  
  2252. 8.7. Rate Limiting for Sending Binding Updates
  2253.  
  2254.    A mobile node MUST NOT send Binding Updates more often than once per
  2255.    MAX_UPDATE_RATE seconds to any correspondent node.  After sending 5
  2256.    consecutive Binding Updates to a particular correspondent node with
  2257.    the same care-of address, the mobile node SHOULD reduce its rate
  2258.    of sending Binding Updates to that correspondent node, to the rate
  2259.    of SLOW_UPDATE_RATE per second.  The mobile node MAY continue to
  2260.    send Binding Updates at the slower rate indefinitely, in hopes that
  2261.    the correspondent node will eventually be able to process a Binding
  2262.    Update and begin to route its packets directly to the mobile node at
  2263.    its new care-of address.
  2264.  
  2265.  
  2266. 8.8. Receiving Binding Acknowledgements
  2267.  
  2268.    Upon receiving a packet carrying a Binding Acknowledgement, a mobile
  2269.    node MUST validate the packet according to the following tests:
  2270.  
  2271.     -  The packet contains an IP Authentication header and the
  2272.        authentication is valid [1].  The Authentication header is
  2273.        assumed to provide both authentication and integrity protection.
  2274.  
  2275.     -  The Option Length field in the option is greater than or equal to
  2276.        8 octets.
  2277.  
  2278.     -  The Identification field is valid.
  2279.  
  2280.    Any Binding Acknowledgement not satisfying all of these tests MUST be
  2281.    silently ignored, although the remainder of the packet (i.e., other
  2282.    options, extension headers, or payload) SHOULD be processed normally
  2283.    according to any procedure defined for that part of the packet.
  2284.  
  2285.    When a mobile node receives a packet carrying a valid Binding
  2286.    Acknowledgement, the mobile node MUST examine the Status field as
  2287.    follows:
  2288.  
  2289.     -  If the Status field indicates that the Binding Update was
  2290.        accepted (the Status field is less than 128), then the mobile
  2291.        node MUST update the corresponding entry in its Binding Update
  2292.  
  2293.  
  2294.  
  2295.  
  2296. Johnson and Perkins            Expires 26 May 1997             [Page 38]
  2297.  
  2298. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2299.  
  2300.  
  2301.        List to indicate that the Binding Update has been acknowledged.
  2302.        The mobile node MUST thus stop retransmitting the Binding Update.
  2303.  
  2304.     -  If the Status field indicates that the Binding Update was not
  2305.        accepted (the Status field is greater than or equal to 128), then
  2306.        the mobile node MUST delete the corresponding Binding Update List
  2307.        entry.  Optionally, the mobile node MAY take steps to correct the
  2308.        cause of the error and retransmit the Binding Update, subject to
  2309.        the rate limiting restriction specified in Section 8.7.
  2310.  
  2311.  
  2312. 8.9. Using Multiple Care-of Addresses
  2313.  
  2314.    As described in Section 8.2, a mobile node MAY have more than
  2315.    one care-of address at a time.  Particularly in the case of many
  2316.    wireless networks, a mobile node effectively may be reachable
  2317.    through multiple link-level points of attachment at the same time
  2318.    (e.g., with overlapping wireless cells), on which different on-link
  2319.    network prefixes may exist.  A mobile node SHOULD select a primary
  2320.    care-of address from among those care-of addresses it has formed
  2321.    using any of these network prefixes, based on the movement detection
  2322.    mechanism in use (Section 8.1).  When the mobile node selects a new
  2323.    primary care-of address, it MUST register it with its home agent
  2324.    through a Binding Update message with the Home Registration (H) and
  2325.    Acknowledge (A) bits set, as described in Section 8.3.
  2326.  
  2327.    To assist with smooth handoffs, a mobile node SHOULD retain
  2328.    its previous primary care-of address as a (non-primary) care-of
  2329.    address, and SHOULD still accept packets at this address, even after
  2330.    registering its new primary care-of address with its home agent.
  2331.    This is reasonable, since the mobile node could only receive packets
  2332.    at its previous primary care-of address if it were indeed still
  2333.    connected to that link.  If the previous primary care-of address
  2334.    was allocated using stateful address autoconfiguration [3], the
  2335.    mobile node may not wish to release the address immediately upon
  2336.    switching to a new primary care-of address.  The stateful address
  2337.    autoconfiguration server will allow mobile nodes to acquire new
  2338.    addresses while still using previously allocated addresses.
  2339.  
  2340.  
  2341. 8.10. Returning Home
  2342.  
  2343.    A mobile node detects that it has returned to its home subnet through
  2344.    the movement detection algorithm in use (Section 8.1), when the
  2345.    mobile node detects that the network prefix of its home subnet is
  2346.    again on-link.  The mobile node SHOULD then send a Binding Update to
  2347.    its home agent, to instruct its home agent to no longer intercept
  2348.    or tunnel packets for it.  In this Binding Update, the mobile node
  2349.  
  2350.  
  2351.  
  2352. Johnson and Perkins            Expires 26 May 1997             [Page 39]
  2353.  
  2354. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2355.  
  2356.  
  2357.    MUST set the Care-of Address field to its own IPv6 home address.  As
  2358.    with other Binding Updates sent to register with its home agent, the
  2359.    mobile node MUST set the Acknowledge (A) and Home Registration (H)
  2360.    bits, and SHOULD retransmit the Binding Update until a matching
  2361.    Binding Acknowledgement message is received.
  2362.  
  2363.    In addition, the mobile node MUST multicast onto the home subnet
  2364.    (to the all-nodes multicast address) a Neighbor Advertisement
  2365.    message [8], to advertise its link-layer address for its own IPv6
  2366.    home address.  The Target Address in this Neighbor Advertisement
  2367.    message MUST be set to the mobile node's home address, and the
  2368.    Advertisement MUST include a Target Link-layer Address option
  2369.    specifying the mobile node's link-layer address.  Similarly, the
  2370.    mobile node MUST multicast a Neighbor Advertisement message to
  2371.    advertise its link-layer address for its IPv6 link-local address.
  2372.    The Solicited Flag (S) in these Advertisements MUST NOT be set, since
  2373.    they were not solicited by any Neighbor Solicitation message.  The
  2374.    Override Flag (O) in these Advertisements MUST be set, indicating
  2375.    that the Advertisements SHOULD override any existing Neighbor Cache
  2376.    entries at any node receiving them.
  2377.  
  2378.    Since multicasts on the local link (such as Ethernet) are typically
  2379.    not guaranteed to be reliable, the mobile node MAY retransmit
  2380.    these Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times
  2381.    to increase their reliability.  It is still possible that some
  2382.    nodes on the home subnet will not receive any of these Neighbor
  2383.    Advertisements, but these nodes will eventually be able to recover
  2384.    through use of Neighbor Unreachability Detection [8].
  2385.  
  2386.  
  2387.  
  2388.  
  2389.  
  2390.  
  2391.  
  2392.  
  2393.  
  2394.  
  2395.  
  2396.  
  2397.  
  2398.  
  2399.  
  2400.  
  2401.  
  2402.  
  2403.  
  2404.  
  2405.  
  2406.  
  2407.  
  2408. Johnson and Perkins            Expires 26 May 1997             [Page 40]
  2409.  
  2410. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2411.  
  2412.  
  2413. 9. Routing Multicast Packets
  2414.  
  2415.    A mobile node that is connected to its home subnet functions in the
  2416.    same way as any other (stationary) node.  Thus, when it is at home,
  2417.    a mobile node functions identically to other multicast senders and
  2418.    receivers.  This section therefore describes the behavior of a mobile
  2419.    node that is not on its home subnet.
  2420.  
  2421.    In order receive packets sent to some multicast group, a mobile node
  2422.    must join the that multicast group.  One method by which a mobile
  2423.    node MAY join the group is via a (local) multicast router on the
  2424.    foreign subnet being visited.  This option assumes that there is a
  2425.    multicast router present on the foreign subnet.  The mobile node
  2426.    SHOULD use its care-of address sharing a network prefix with the
  2427.    multicast router, as the source IPv6 address of its multicast group
  2428.    membership control message packets.
  2429.  
  2430.    Alternatively, a mobile node MAY join multicast groups via a
  2431.    bi-directional tunnel to its home agent, assuming that its home agent
  2432.    is a multicast router.  The mobile node tunnels the appropriate
  2433.    multicast group membership control packets to its home agent, and the
  2434.    home agent forwards multicast packets down the tunnel to the mobile
  2435.    node.  The home agent MUST tunnel the packet directly to the mobile
  2436.    node's primary care-of address.
  2437.  
  2438.    A mobile node that wishes to send packets to a multicast group
  2439.    also has two options:  (1) send directly on the foreign subnet
  2440.    being visited; or (2) send via a tunnel to its home agent.  Because
  2441.    multicast routing in general depends upon the Source Address used
  2442.    in the IP header of the multicast packet, a mobile node that sends
  2443.    multicast packets directly on the foreign subnet MUST use its
  2444.    care-of address as the IPv6 Source Address of each multicast packet.
  2445.    Similarly, a mobile node that tunnels a multicast packet to its home
  2446.    agent MUST use its home address as the IPv6 Source Address of both
  2447.    the (inner) multicast packet and the (outer) encapsulating packet.
  2448.    This second option assumes that the home agent is a multicast router.
  2449.  
  2450.  
  2451.  
  2452.  
  2453.  
  2454.  
  2455.  
  2456.  
  2457.  
  2458.  
  2459.  
  2460.  
  2461.  
  2462.  
  2463.  
  2464. Johnson and Perkins            Expires 26 May 1997             [Page 41]
  2465.  
  2466. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2467.  
  2468.  
  2469. 10. Constants
  2470.  
  2471.       INITIAL_BINDACK_TIMEOUT   1 second
  2472.  
  2473.       MAX_BINDACK_TIMEOUT       256 seconds
  2474.  
  2475.       MAX_UPDATE_RATE           once per second
  2476.  
  2477.       SLOW_UPDATE_RATE          once per 10 seconds
  2478.  
  2479.       MAX_ADVERT_REXMIT         3
  2480.  
  2481.  
  2482.  
  2483.  
  2484.  
  2485.  
  2486.  
  2487.  
  2488.  
  2489.  
  2490.  
  2491.  
  2492.  
  2493.  
  2494.  
  2495.  
  2496.  
  2497.  
  2498.  
  2499.  
  2500.  
  2501.  
  2502.  
  2503.  
  2504.  
  2505.  
  2506.  
  2507.  
  2508.  
  2509.  
  2510.  
  2511.  
  2512.  
  2513.  
  2514.  
  2515.  
  2516.  
  2517.  
  2518.  
  2519.  
  2520. Johnson and Perkins            Expires 26 May 1997             [Page 42]
  2521.  
  2522. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2523.  
  2524.  
  2525. 11. Security Considerations
  2526.  
  2527.    The Binding Update option described in this document will result
  2528.    in packets addressed to a mobile node being delivered instead to
  2529.    its care-of address.  This ability to change the routing of these
  2530.    packets could be a significant vulnerability if any packet containing
  2531.    a Binding Update option was not authenticated.  Such use of "remote
  2532.    redirection", for instance as performed by the Binding Update option,
  2533.    is widely understood to be a security problem in the current Internet
  2534.    if not authenticated [2].
  2535.  
  2536.    The mobile computing environment is potentially very different from
  2537.    the ordinary computing environment.  In many cases, mobile computers
  2538.    will be connected to the network via wireless links.  Such links
  2539.    are particularly vulnerable to passive eavesdropping, active replay
  2540.    attacks, and other active attacks.
  2541.  
  2542.    Users who have sensitive data that they do not wish others to see
  2543.    should use mechanisms outside the scope of this document (such as
  2544.    encryption) to provide appropriate protection.  Users concerned about
  2545.    traffic analysis should consider appropriate use of link encryption.
  2546.    If absolute location privacy is desired, the mobile node can create a
  2547.    tunnel to its home agent.  Then, packets destined for correspondent
  2548.    nodes will appear to emanate from the home subnet, and it may be
  2549.    more difficult to pinpoint the location of the mobile node.  Such
  2550.    mechanisms are all beyond the scope of this document.
  2551.  
  2552.  
  2553.  
  2554.  
  2555.  
  2556.  
  2557.  
  2558.  
  2559.  
  2560.  
  2561.  
  2562.  
  2563.  
  2564.  
  2565.  
  2566.  
  2567.  
  2568.  
  2569.  
  2570.  
  2571.  
  2572.  
  2573.  
  2574.  
  2575.  
  2576. Johnson and Perkins            Expires 26 May 1997             [Page 43]
  2577.  
  2578. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2579.  
  2580.  
  2581. Acknowledgements
  2582.  
  2583.    We would like to thank the members of the Mobile IP and IPng Working
  2584.    Groups for their comments and suggestions on this draft.  We would
  2585.    particularly like to thank Thomas Narten and Erik Nordmark for
  2586.    their detailed reviews of earlier versions of this draft.  Their
  2587.    suggestions have helped to improve both the design and presentation
  2588.    of the protocol.
  2589.  
  2590.  
  2591.  
  2592.  
  2593.  
  2594.  
  2595.  
  2596.  
  2597.  
  2598.  
  2599.  
  2600.  
  2601.  
  2602.  
  2603.  
  2604.  
  2605.  
  2606.  
  2607.  
  2608.  
  2609.  
  2610.  
  2611.  
  2612.  
  2613.  
  2614.  
  2615.  
  2616.  
  2617.  
  2618.  
  2619.  
  2620.  
  2621.  
  2622.  
  2623.  
  2624.  
  2625.  
  2626.  
  2627.  
  2628.  
  2629.  
  2630.  
  2631.  
  2632. Johnson and Perkins            Expires 26 May 1997             [Page 44]
  2633.  
  2634. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2635.  
  2636.  
  2637. A. Open Issues
  2638.  
  2639. A.1. Session Keys with Local Routers
  2640.  
  2641.    In the IPv4 route optimization proposal [7], a mechanism is outlined
  2642.    whereby a session key can be established between foreign agents
  2643.    and mobile nodes, without requiring any pre-established security
  2644.    relationship between them.  A similar mechanism could be defined for
  2645.    IPv6, to avoid the need for a possibly time-consuming negotiation
  2646.    between routers and mobile nodes for the purpose of obtaining the
  2647.    session key, which under many circumstances would only be used once.
  2648.    This mechanism, if needed, can be specified completely outside
  2649.    the Mobile IPv6 protocol and would amount to a way of creating a
  2650.    dynamic security association between two nodes which do not share an
  2651.    existing trust relationship, but which need to agree on a key for
  2652.    some particular purpose (here, allowing the future authentication of
  2653.    a Binding Update).  Hopefully, the work of the IP Security Working
  2654.    Group will allow this function to be performed appropriately for
  2655.    mobile nodes, say by a Diffie-Hellman key exchange.
  2656.  
  2657.  
  2658. A.2. Source Address Filtering by Firewalls
  2659.  
  2660.    The current specification does nothing to permit mobile nodes to
  2661.    send their packets through firewalls which filter out packets with
  2662.    the "wrong" source IPv6 addresses in the IPv6 packet header.  The
  2663.    mobile node's home address may be unlikely to fall within the ranges
  2664.    required to satisfy the firewall's criteria for further delivery.
  2665.  
  2666.    As indicated by recent discussion, firewalls are unlikely to
  2667.    disappear.  Any standardized solution [13] to the firewall problem
  2668.    based on hiding the non-local source address outside the source
  2669.    address field of the IP header is likely to fail.  Any vendor or
  2670.    facilities administrator wanting to filter based on the address in
  2671.    the IPv6 source address field would also quickly begin filtering on
  2672.    hidden source addresses.
  2673.  
  2674.    Assume, for the moment, that a mobile node is able to establish a
  2675.    secure tunnel through a firewall protecting the domain in which
  2676.    a correspondent node is located.  The mobile node could then
  2677.    encapsulate its packet so that the outer IP header was addressed
  2678.    to the firewall and used the mobile node's care-of address as the
  2679.    source address.  When the firewall decapsulates, it would be able to
  2680.    authenticate the inner packet based (correctly) on the mobile node's
  2681.    home address.  After the authentication is performed, the firewall
  2682.    could forward the packet to the correspondent node as desired.  This
  2683.    simple procedure has the feature that it requires the minimal amount
  2684.    of encapsulation, no assistance by routers or other agents, and that
  2685.  
  2686.  
  2687.  
  2688. Johnson and Perkins            Expires 26 May 1997             [Page 45]
  2689.  
  2690. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2691.  
  2692.  
  2693.    the firewall can establish a security relationship with the mobile
  2694.    node based on its home (i.e., permanent) address.
  2695.  
  2696.  
  2697. A.3. Dynamic Home Agent Address Discovery
  2698.  
  2699.    It is useful for a mobile node to be able to send a Binding Update
  2700.    its home agent without explicitly knowing the home agent's address.
  2701.    For example, since the mobile node was last at home, it may have
  2702.    become necessary to replace the node serving as its home agent due
  2703.    to the failure of the original node or due to reconfiguration of the
  2704.    home subnet.  It thus may not always be possible or convenient for a
  2705.    mobile node to know the exact address of its own home agent.  Several
  2706.    methods of allowing a mobile node to dynamically discover the address
  2707.    of a router in its home subnet are currently under consideration.
  2708.  
  2709.  
  2710. A.4. Replay Protection for Binding Updates
  2711.  
  2712.    Some transforms for use in conjunction with the IP Authentication
  2713.    Header [1] provide support for replay protection [9, 6].  Ideally,
  2714.    such transforms would directly support the needs of Mobile IPv6
  2715.    for providing replay protection for Binding Updates and Binding
  2716.    Acknowledgements.  However, this does not currently appear to be
  2717.    the case.  These transforms provide optional support for accepting
  2718.    packets out of order, through use of an "out of order window" in the
  2719.    receiver, and it does not currently seem to be specified how the
  2720.    size (or presence) of such a window can be controlled.  For Binding
  2721.    Updates, it is important that any packets containing a Binding
  2722.    Update that arrive at the receiver do so strictly in the order sent
  2723.    (although some may harmlessly be dropped, as long as a later Binding
  2724.    Update does arrive).  Without control of the window at the receiver,
  2725.    this ordering requirement on Binding Update delivery cannot be
  2726.    supported directly by these transforms, although these transforms do
  2727.    use a sequence number to support their own replay protection.
  2728.  
  2729.    The Identification field in the Binding Update (and Binding
  2730.    Acknowledgement) is currently specified in this document for use
  2731.    in sequencing Binding Updates at the receiver, and in matching
  2732.    returned Binding Acknowledgements with outstanding Binding Updates
  2733.    at the sender.  The use of this field in this manner, together with
  2734.    the use of the current IP Authentication transforms that supports
  2735.    replay protection, seems to support the necessary replay protection
  2736.    requirements for Mobile IPv6, although it seems that the need for two
  2737.    sequence numbers in the packet (one for IP Authentication and one for
  2738.    Mobile IPv6) could be simplified.
  2739.  
  2740.  
  2741.  
  2742.  
  2743.  
  2744. Johnson and Perkins            Expires 26 May 1997             [Page 46]
  2745.  
  2746. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2747.  
  2748.  
  2749. References
  2750.  
  2751.     [1] Randall Atkinson.  IP Authentication header.  RFC 1826, August
  2752.         1995.
  2753.  
  2754.     [2] S. M. Bellovin.  Security problems in the TCP/IP protocol suite.
  2755.         ACM Computer Communications Review, 19(2), March 1989.
  2756.  
  2757.     [3] Jim Bound and Charles Perkins.  Dynamic Host Configuration
  2758.         Protocol for IPv6 (DHCPv6).  Internet-Draft,
  2759.         draft-ietf-dhc-dhcpv6-07.txt, August 1996.  Work in progress.
  2760.  
  2761.     [4] Alex Conta and Stephen Deering.  Generic packet
  2762.         tunneling in IPv6 specification.  Internet-Draft,
  2763.         draft-ietf-ipngwg-ipv6-tunnel-02.txt, June 1996.  Work
  2764.         in progress.
  2765.  
  2766.     [5] Stephen E. Deering and Robert M. Hinden.  Internet Protocol
  2767.         version 6 (IPv6) specification.  RFC 1883, December 1995.
  2768.  
  2769.     [6] Shu jen Chang and Robert Glenn.  HMAC-SHA IP authentication with
  2770.         replay prevention.  Internet-Draft,
  2771.         draft-ietf-ipsec-ah-hmac-sha-04.txt, November 1996.  Work in
  2772.         progress.
  2773.  
  2774.     [7] David B. Johnson and Charles Perkins.  Route optimization in
  2775.         Mobile IP.  Internet-Draft, draft-ietf-mobileip-optim-04.txt,
  2776.         February 1996.  Work in progress.
  2777.  
  2778.     [8] Thomas Narten, Erik Nordmark, and William Allen Simpson.
  2779.         Neighbor Discovery for IP version 6 (IPv6).  RFC 1970, August
  2780.         1996.
  2781.  
  2782.     [9] Michael J. Oehler and Robert Glenn.  HMAC-MD5 IP
  2783.         authentication with replay prevention.  Internet-Draft,
  2784.         draft-ietf-ipsec-ah-hmac-md5-04.txt, November 1996.  Work in
  2785.         progress.
  2786.  
  2787.    [10] J. B. Postel.  User Datagram Protocol.  RFC 768, August 1980.
  2788.  
  2789.    [11] J. B. Postel, editor.  Transmission Control Protocol.  RFC 793,
  2790.         September 1981.
  2791.  
  2792.    [12] Joyce K. Reynolds and Jon Postel.  Assigned numbers.  RFC 1700,
  2793.         October 1994.
  2794.  
  2795.  
  2796.  
  2797.  
  2798.  
  2799.  
  2800. Johnson and Perkins            Expires 26 May 1997             [Page 47]
  2801.  
  2802. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2803.  
  2804.  
  2805.    [13] Fumio Teraoka.  Mobility support in IPv6.  Internet-Draft,
  2806.         draft-teraoka-ipv6-mobility-sup-03.txt, April 1996.  Work in
  2807.         progress.
  2808.  
  2809.    [14] Susan Thomson and Thomas Narten.  IPv6 stateless address
  2810.         autoconfiguration.  RFC 1971, August 1996.
  2811.  
  2812.  
  2813.  
  2814.  
  2815.  
  2816.  
  2817.  
  2818.  
  2819.  
  2820.  
  2821.  
  2822.  
  2823.  
  2824.  
  2825.  
  2826.  
  2827.  
  2828.  
  2829.  
  2830.  
  2831.  
  2832.  
  2833.  
  2834.  
  2835.  
  2836.  
  2837.  
  2838.  
  2839.  
  2840.  
  2841.  
  2842.  
  2843.  
  2844.  
  2845.  
  2846.  
  2847.  
  2848.  
  2849.  
  2850.  
  2851.  
  2852.  
  2853.  
  2854.  
  2855.  
  2856. Johnson and Perkins            Expires 26 May 1997             [Page 48]
  2857.  
  2858. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2859.  
  2860.  
  2861. Chair's Address
  2862.  
  2863.    The Working Group can be contacted via its current chairs:
  2864.  
  2865.         Jim Solomon
  2866.         Motorola, Inc.
  2867.         1301 E. Algonquin Rd.
  2868.         Schaumburg, IL  60196
  2869.         USA
  2870.  
  2871.         Phone:  +1 847 576-2753
  2872.         E-mail: solomon@comm.mot.com
  2873.  
  2874.  
  2875.         Erik Nordmark
  2876.         Sun Microsystems, Inc.
  2877.         2550 Garcia Avenue
  2878.         Mt. View, CA  94041
  2879.         USA
  2880.  
  2881.         Phone:  +1 415 786-5166
  2882.         Fax:    +1 415 786-5896
  2883.         E-mail: nordmark@sun.com
  2884.  
  2885.  
  2886.  
  2887.  
  2888.  
  2889.  
  2890.  
  2891.  
  2892.  
  2893.  
  2894.  
  2895.  
  2896.  
  2897.  
  2898.  
  2899.  
  2900.  
  2901.  
  2902.  
  2903.  
  2904.  
  2905.  
  2906.  
  2907.  
  2908.  
  2909.  
  2910.  
  2911.  
  2912. Johnson and Perkins            Expires 26 May 1997             [Page 49]
  2913.  
  2914. INTERNET-DRAFT         Mobility Support in IPv6         26 November 1996
  2915.  
  2916.  
  2917. Authors' Addresses
  2918.  
  2919.    Questions about this document can also be directed to the authors:
  2920.  
  2921.         David B. Johnson
  2922.         Carnegie Mellon University
  2923.         Computer Science Department
  2924.         5000 Forbes Avenue
  2925.         Pittsburgh, PA  15213-3891
  2926.         USA
  2927.  
  2928.         Phone:  +1 412 268-7399
  2929.         Fax:    +1 412 268-5576
  2930.         E-mail: dbj@cs.cmu.edu
  2931.  
  2932.  
  2933.         Charles Perkins
  2934.         IBM Corporation
  2935.         T. J. Watson Research Center
  2936.         Room H3-D34
  2937.         30 Saw Mill River Rd.
  2938.         Hawthorne, NY  10532
  2939.         USA
  2940.  
  2941.         Phone:  +1 914 789-7350
  2942.         Fax:    +1 914 784-6205
  2943.         E-mail: perk@watson.ibm.com
  2944.  
  2945.  
  2946.  
  2947.  
  2948.  
  2949.  
  2950.  
  2951.  
  2952.  
  2953.  
  2954.  
  2955.  
  2956.  
  2957.  
  2958.  
  2959.  
  2960.  
  2961.  
  2962.  
  2963.  
  2964.  
  2965.  
  2966.  
  2967.  
  2968. Johnson and Perkins            Expires 26 May 1997             [Page 50]
  2969.  
  2970.