👤 ⍰ ❎
`
`
`f 🐦
`
`▾ About this capture
`
`APR MAY JUN
`
`30
`1997 1998 2001
`
`http://www.nic.it/mirrors/rfc/rfc2002.txt
`
`Go
`
`14 captures
`30 May 1998 - 23 Feb 2005
`
`
`
`Network Working Group C. Perkins, Editor
`Request for Comments: 2002 IBM
`Category: Standards Track October 1996
`
` IP Mobility Support
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Abstract
`
` This document specifies protocol enhancements that allow transparent
` routing of IP datagrams to mobile nodes in the Internet. Each mobile
` node is always identified by its home address, regardless of its
` current point of attachment to the Internet. While situated away
` from its home, a mobile node is also associated with a care-of
` address, which provides information about its current point of
` attachment to the Internet. The protocol provides for registering
` the care-of address with a home agent. The home agent sends
` datagrams destined for the mobile node through a tunnel to the care-
` of address. After arriving at the end of the tunnel, each datagram
` is then delivered to the mobile node.
`
`Table of Contents
`
` 1. Introduction 3
` 1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 3
` 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
` 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
` 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
` 1.5. New Architectural Entities . . . . . . . . . . . . . . . 5
` 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
` 1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
` 1.8. Specification Language . . . . . . . . . . . . . . . . . 11
` 1.9. Message Format and Protocol Extensibility . . . . . . . . 12
` 2. Agent Discovery 14
` 2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . . 14
` 2.1.1. Mobility Agent Advertisement Extension . . . . . 16
` 2.1.2. Prefix-Lengths Extension . . . . . . . . . . . . 18
` 2.1.3. One-byte Padding Extension . . . . . . . . . . . 19
` 2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . . 19
` 2.3. Foreign Agent and Home Agent Considerations . . . . . . . 19
` 2.3.1. Advertised Router Addresses . . . . . . . . . . . 20
`
`
`
`Perkins Standards Track [Page 1]
`
`RFC 2002 IP Mobility Support October 1996
`
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 1
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`
`
` 2.3.2. Sequence Numbers and Rollover Handling . . . . . 21
` 2.4. Mobile Node Considerations . . . . . . . . . . . . . . . 21
` 2.4.1. Registration Required . . . . . . . . . . . . . . 22
` 2.4.2. Move Detection . . . . . . . . . . . . . . . . . 22
` 2.4.3. Returning Home . . . . . . . . . . . . . . . . . 24
` 2.4.4. Sequence Numbers and Rollover Handling . . . . . 24
` 3. Registration 24
` 3.1. Registration Overview . . . . . . . . . . . . . . . . . . 25
` 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 26
` 3.3. Registration Request . . . . . . . . . . . . . . . . . . 26
` 3.4. Registration Reply . . . . . . . . . . . . . . . . . . . 29
` 3.5. Registration Extensions . . . . . . . . . . . . . . . . . 32
` 3.5.1. Computing Authentication Extension Values . . . . 32
` 3.5.2. Mobile-Home Authentication Extension . . . . . . 33
` 3.5.3. Mobile-Foreign Authentication Extension . . . . . 33
` 3.5.4. Foreign-Home Authentication Extension . . . . . . 34
` 3.6. Mobile Node Considerations . . . . . . . . . . . . . . . 34
` 3.6.1. Sending Registration Requests . . . . . . . . . . 36
` 3.6.2. Receiving Registration Replies . . . . . . . . . 40
` 3.6.3. Registration Retransmission . . . . . . . . . . . 42
` 3.7. Foreign Agent Considerations . . . . . . . . . . . . . . 43
` 3.7.1. Configuration and Registration Tables . . . . . . 44
` 3.7.2. Receiving Registration Requests . . . . . . . . . 44
` 3.7.3. Receiving Registration Replies . . . . . . . . . 47
` 3.8. Home Agent Considerations . . . . . . . . . . . . . . . . 49
` 3.8.1. Configuration and Registration Tables . . . . . . 49
` 3.8.2. Receiving Registration Requests . . . . . . . . . 49
` 3.8.3. Sending Registration Replies . . . . . . . . . . 53
` 4. Routing Considerations 55
` 4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . . 56
` 4.2. Unicast Datagram Routing . . . . . . . . . . . . . . . . 56
` 4.2.1. Mobile Node Considerations . . . . . . . . . . . 56
` 4.2.2. Foreign Agent Considerations . . . . . . . . . . 57
` 4.2.3. Home Agent Considerations . . . . . . . . . . . . 58
` 4.3. Broadcast Datagrams . . . . . . . . . . . . . . . . . . . 59
` 4.4. Multicast Datagram Routing . . . . . . . . . . . . . . . 60
` 4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . . 61
` 4.6. ARP, Proxy ARP, and Gratuitous ARP . . . . . . . . . . . 62
` 5. Security Considerations 66
` 5.1. Message Authentication Codes . . . . . . . . . . . . . . 66
` 5.2. Areas of Security Concern in this Protocol . . . . . . . 66
` 5.3. Key Management . . . . . . . . . . . . . . . . . . . . . 67
` 5.4. Picking Good Random Numbers . . . . . . . . . . . . . . . 67
` 5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 67
` 5.6. Replay Protection for Registration Requests . . . . . . . 68
` 5.6.1. Replay Protection using Timestamps . . . . . . . 68
` 5.6.2. Replay Protection using Nonces . . . . . . . . . 69
` 6. Acknowledgments 71
`
`
`
`Perkins Standards Track [Page 2]
`
`RFC 2002 IP Mobility Support October 1996
`
`
` A. Patent Issues 72
` A.1. IBM Patent #5,159,592 . . . . . . . . . . . . . . . . . . 72
` A.2. IBM Patent #5,148,479 . . . . . . . . . . . . . . . . . . 72
` B. Link-Layer Considerations 73
` C. TCP Considerations 73
` C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . . 73
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 2
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

` C.2. TCP Congestion Management . . . . . . . . . . . . . . . . 73
` D. Example Scenarios 74
` D.1. Registering with a Foreign Agent Care-of Address . . . . 74
` D.2. Registering with a Co-Located Care-of Address . . . . . . 75
` D.3. Deregistration . . . . . . . . . . . . . . . . . . . . . 76
` E. Applicability of Prefix Lengths Extension 76
`Editor's Address 79
`
`1. Introduction
`
` IP version 4 assumes that a node's IP address uniquely identifies the
` node's point of attachment to the Internet. Therefore, a node must
` be located on the network indicated by its IP address in order to
` receive datagrams destined to it; otherwise, datagrams destined to
` the node would be undeliverable. For a node to change its point of
` attachment without losing its ability to communicate, currently one
` of the two following mechanisms must typically be employed:
`
` a) the node must change its IP address whenever it changes its
` point of attachment, or
`
` b) host-specific routes must be propagated throughout much of
` the Internet routing fabric.
`
` Both of these alternatives are often unacceptable. The first makes
` it impossible for a node to maintain transport and higher-layer
` connections when the node changes location. The second has obvious
` and severe scaling problems, especially relevant considering the
` explosive growth in sales of notebook (mobile) computers.
`
` A new, scalable, mechanism is required for accommodating node
` mobility within the Internet. This document defines such a
` mechanism, which enables nodes to change their point of attachment to
` the Internet without changing their IP address.
`
`1.1. Protocol Requirements
`
` A mobile node must be able to communicate with other nodes after
` changing its link-layer point of attachment to the Internet, yet
` without changing its IP address.
`
`
`
`
`
`Perkins Standards Track [Page 3]
`
`RFC 2002 IP Mobility Support October 1996
`
`
` A mobile node must be able to communicate with other nodes that do
` not implement these mobility functions. No protocol enhancements are
` required in hosts or routers that are not acting as any of the new
` architectural entities introduced in Section 1.5.
`
` All messages used to update another node as to the location of a
` mobile node must be authenticated in order to protect against remote
` redirection attacks.
`
`1.2. Goals
`
` The link by which a mobile node is directly attached to the Internet
` may often be a wireless link. This link may thus have a
` substantially lower bandwidth and higher error rate than traditional
` wired networks. Moreover, mobile nodes are likely to be battery
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 3
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

` powered, and minimizing power consumption is important. Therefore,
` the number of administrative messages sent over the link by which a
` mobile node is directly attached to the Internet should be minimized,
` and the size of these messages should be kept as small as is
` reasonably possible.
`
`1.3. Assumptions
`
` The protocols defined in this document place no additional
` constraints on the assignment of IP addresses. That is, a mobile
` node can be assigned an IP address by the organization that owns the
` machine.
`
` This protocol assumes that mobile nodes will generally not change
` their point of attachment to the Internet more frequently than once
` per second.
`
` This protocol assumes that IP unicast datagrams are routed based on
` the destination address in the datagram header (and not, for example,
` by source address).
`
`1.4. Applicability
`
` Mobile IP is intended to enable nodes to move from one IP subnet to
` another. It is just as suitable for mobility across homogeneous
` media as it is for mobility across heterogeneous media. That is,
` Mobile IP facilitates node movement from one Ethernet segment to
` another as well as it accommodates node movement from an Ethernet
` segment to a wireless LAN, as long as the mobile node's IP address
` remains the same after such a movement.
`
` One can think of Mobile IP as solving the "macro" mobility management
` problem. It is less well suited for more "micro" mobility management
`
`
`
`Perkins Standards Track [Page 4]
`
`RFC 2002 IP Mobility Support October 1996
`
`
` applications -- for example, handoff amongst wireless transceivers,
` each of which covers only a very small geographic area. As long as
` node movement does not occur between points of attachment on
` different IP subnets, link-layer mechanisms for mobility (i.e.,
` link-layer handoff) may offer faster convergence and far less
` overhead than Mobile IP.
`
`1.5. New Architectural Entities
`
` Mobile IP introduces the following new functional entities:
`
` Mobile Node
`
` A host or router that changes its point of attachment from one
` network or subnetwork to another. A mobile node may change its
` location without changing its IP address; it may continue to
` communicate with other Internet nodes at any location using its
` (constant) IP address, assuming link-layer connectivity to a
` point of attachment is available.
`
` Home Agent
`
` A router on a mobile node's home network which tunnels
` datagrams for delivery to the mobile node when it is away from
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 4
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

` home, and maintains current location information for the mobile
` node.
`
` Foreign Agent
`
` A router on a mobile node's visited network which provides
` routing services to the mobile node while registered. The
` foreign agent detunnels and delivers datagrams to the mobile
` node that were tunneled by the mobile node's home agent. For
` datagrams sent by a mobile node, the foreign agent may serve as
` a default router for registered mobile nodes.
`
` A mobile node is given a long-term IP address on a home network.
` This home address is administered in the same way as a "permanent" IP
` address is provided to a stationary host. When away from its home
` network, a "care-of address" is associated with the mobile node and
` reflects the mobile node's current point of attachment. The mobile
` node uses its home address as the source address of all IP datagrams
` that it sends, except where otherwise described in this document for
` datagrams sent for certain mobility management functions (e.g., as in
` Section 3.6.1.1).
`
`
`
`
`
`
`Perkins Standards Track [Page 5]
`
`RFC 2002 IP Mobility Support October 1996
`
`
`1.6. Terminology
`
` This document frequently uses the following terms:
`
` Agent Advertisement
` An advertisement message constructed by attaching a
` special Extension to a router advertisement [4] message.
`
` Care-of Address
` The termination point of a tunnel toward a mobile node,
` for datagrams forwarded to the mobile node while it is
` away from home. The protocol can use two different types
` of care-of address: a "foreign agent care-of address" is
` an address of a foreign agent with which the mobile node
` is registered, and a "co-located care-of address" is an
` externally obtained local address which the mobile node
` has associated with one of its own network interfaces.
`
` Correspondent Node
` A peer with which a mobile node is communicating. A
` correspondent node may be either mobile or stationary.
`
` Foreign Network
` Any network other than the mobile node's Home Network.
`
` Home Address
` An IP address that is assigned for an extended period of
` time to a mobile node. It remains unchanged regardless
` of where the node is attached to the Internet.
`
` Home Network
` A network, possibly virtual, having a network prefix
` matching that of a mobile node's home address. Note that
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 5
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

` standard IP routing mechanisms will deliver datagrams
` destined to a mobile node's Home Address to the mobile
` node's Home Network.
`
` Link A facility or medium over which nodes can communicate at
` the link layer. A link underlies the network layer.
`
` Link-Layer Address
` The address used to identify an endpoint of some
` communication over a physical link. Typically, the
` Link-Layer address is an interface's Media Access Control
` (MAC) address.
`
` Mobility Agent
` Either a home agent or a foreign agent.
`
`
`
`Perkins Standards Track [Page 6]
`
`RFC 2002 IP Mobility Support October 1996
`
`
` Mobility Binding
` The association of a home address with a care-of address,
` along with the remaining lifetime of that association.
`
` Mobility Security Association
` A collection of security contexts, between a pair
` of nodes, which may be applied to Mobile IP protocol
` messages exchanged between them. Each context indicates
` an authentication algorithm and mode (Section 5.1), a
` secret (a shared key, or appropriate public/private
` key pair), and a style of replay protection in use
` (Section 5.6).
`
` Node A host or a router.
`
` Nonce A randomly chosen value, different from previous choices,
` inserted in a message to protect against replays.
`
` Security Parameter Index (SPI)
` An index identifying a security context between a pair
` of nodes among the contexts available in the Mobility
` Security Association. SPI values 0 through 255 are
` reserved and MUST NOT be used in any Mobility Security
` Association.
`
` Tunnel The path followed by a datagram while it is encapsulated.
` The model is that, while it is encapsulated, a datagram
` is routed to a knowledgeable decapsulating agent, which
` decapsulates the datagram and then correctly delivers it
` to its ultimate destination.
`
` Virtual Network
` A network with no physical instantiation beyond a router
` (with a physical network interface on another network).
` The router (e.g., a home agent) generally advertises
` reachability to the virtual network using conventional
` routing protocols.
`
` Visited Network
` A network other than a mobile node's Home Network, to
` which the mobile node is currently connected.
`
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 6
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

` Visitor List
` The list of mobile nodes visiting a foreign agent.
`
`
`
`
`
`
`
`Perkins Standards Track [Page 7]
`
`RFC 2002 IP Mobility Support October 1996
`
`
`1.7. Protocol Overview
`
` The following support services are defined for Mobile IP:
`
` Agent Discovery
` Home agents and foreign agents may advertise their
` availability on each link for which they provide service.
` A newly arrived mobile node can send a solicitation on
` the link to learn if any prospective agents are present.
`
` Registration
` When the mobile node is away from home, it registers
` its care-of address with its home agent. Depending on
` its method of attachment, the mobile node will register
` either directly with its home agent, or through a foreign
` agent which forwards the registration to the home agent.
`
` The following steps provide a rough outline of operation of the
` Mobile IP protocol:
`
` - Mobility agents (i.e., foreign agents and home agents) advertise
` their presence via Agent Advertisement messages (Section 2). A
` mobile node may optionally solicit an Agent Advertisement message
` from any locally attached mobility agents through an Agent
` Solicitation message.
`
` - A mobile node receives these Agent Advertisements and determines
` whether it is on its home network or a foreign network.
`
` - When the mobile node detects that it is located on its home
` network, it operates without mobility services. If returning
` to its home network from being registered elsewhere, the mobile
` node deregisters with its home agent, through exchange of a
` Registration Request and Registration Reply message with it.
`
` - When a mobile node detects that it has moved to a foreign
` network, it obtains a care-of address on the foreign network.
` The care-of address can either be determined from a foreign
` agent's advertisements (a foreign agent care-of address), or by
` some external assignment mechanism such as DHCP [6] (a co-located
` care-of address).
`
` - The mobile node operating away from home then registers its
` new care-of address with its home agent through exchange of a
` Registration Request and Registration Reply message with it,
` possibly via a foreign agent (Section 3).
`
`
`
`
`
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 7
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

`Perkins Standards Track [Page 8]
`
`RFC 2002 IP Mobility Support October 1996
`
`
` - Datagrams sent to the mobile node's home address are intercepted
` by its home agent, tunneled by the home agent to the mobile
` node's care-of address, received at the tunnel endpoint (either
` at a foreign agent or at the mobile node itself), and finally
` delivered to the mobile node (Section 4.2.3).
`
` - In the reverse direction, datagrams sent by the mobile node
` are generally delivered to their destination using standard IP
` routing mechanisms, not necessarily passing through the home
` agent.
`
` When away from home, Mobile IP uses protocol tunneling to hide a
` mobile node's home address from intervening routers between its home
` network and its current location. The tunnel terminates at the
` mobile node's care-of address. The care-of address must be an
` address to which datagrams can be delivered via conventional IP
` routing. At the care-of address, the original datagram is removed
` from the tunnel and delivered to the mobile node.
`
` Mobile IP provides two alternative modes for the acquisition of a
` care-of address:
`
` - A "foreign agent care-of address" is a care-of address provided
` by a foreign agent through its Agent Advertisement messages. In
` this case, the care-of address is an IP address of the foreign
` agent. In this mode, the foreign agent is the endpoint of the
` tunnel and, upon receiving tunneled datagrams, decapsulates them
` and delivers the inner datagram to the mobile node. This mode
` of acquisition is preferred because it allows many mobile nodes
` to share the same care-of address and therefore does not place
` unnecessary demands on the already limited IPv4 address space.
`
` - A "co-located care-of address" is a care-of address acquired
` by the mobile node as a local IP address through some external
` means, which the mobile node then associates with one of its own
` network interfaces. The address may be dynamically acquired as
` a temporary address by the mobile node such as through DHCP [6],
` or may be owned by the mobile node as a long-term address for its
` use only while visiting some foreign network. Specific external
` methods of acquiring a local IP address for use as a co-located
` care-of address are beyond the scope of this document. When
` using a co-located care-of address, the mobile node serves as the
` endpoint of the tunnel and itself performs decapsulation of the
` datagrams tunneled to it.
`
` The mode of using a co-located care-of address has the advantage that
` it allows a mobile node to function without a foreign agent, for
` example, in networks that have not yet deployed a foreign agent.
`
`
`
`Perkins Standards Track [Page 9]
`
`RFC 2002 IP Mobility Support October 1996
`
`
` It does, however, place additional burden on the IPv4 address space
` because it requires a pool of addresses within the foreign network to
` be made available to visiting mobile nodes. It is difficult to
` efficiently maintain pools of addresses for each subnet that may
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 8
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

` permit mobile nodes to visit.
`
` It is important to understand the distinction between the care-of
` address and the foreign agent functions. The care-of address is
` simply the endpoint of the tunnel. It might indeed be an address of
` a foreign agent (a foreign agent care-of address), but it might
` instead be an address temporarily acquired by the mobile node (a co-
` located care-of address). A foreign agent, on the other hand, is a
` mobility agent that provides services to mobile nodes. See Sections
` 3.7 and 4.2.2 for additional details.
`
` A home agent MUST be able to attract and intercept datagrams that are
` destined to the home address of any of its registered mobile nodes.
` Using the proxy and gratuitous ARP mechanisms described in Section
` 4.6, this requirement can be satisfied if the home agent has a
` network interface on the link indicated by the mobile node's home
` address. Other placements of the home agent relative to the mobile
` node's home location MAY also be possible using other mechanisms for
` intercepting datagrams destined to the mobile node's home address.
` Such placements are beyond the scope of this document.
`
` Similarly, a mobile node and a prospective or current foreign agent
` MUST be able to exchange datagrams without relying on standard IP
` routing mechanisms; that is, those mechanisms which make forwarding
` decisions based upon the network-prefix of the destination address in
` the IP header. This requirement can be satisfied if the foreign
` agent and the visiting mobile node have an interface on the same
` link. In this case, the mobile node and foreign agent simply bypass
` their normal IP routing mechanism when sending datagrams to each
` other, addressing the underlying link-layer packets to their
` respective link-layer addresses. Other placements of the foreign
` agent relative to the mobile node MAY also be possible using other
` mechanisms to exchange datagrams between these nodes, but such
` placements are beyond the scope of this document.
`
` If a mobile node is using a co-located care-of address (as described
` in (b) above), the mobile node MUST be located on the link identified
` by the network prefix of this care-of address. Otherwise, datagrams
` destined to the care-of address would be undeliverable.
`
` For example, the figure below illustrates the routing of datagrams to
` and from a mobile node away from home, once the mobile node has
` registered with its home agent. In the figure below, the mobile node
` is using a foreign agent care-of address:
`
`
`
`Perkins Standards Track [Page 10]
`
`RFC 2002 IP Mobility Support October 1996
`
`
` 2) Datagram is intercepted 3) Datagram is
` by home agent and detunneled and
` is tunneled to the delivered to the
` care-of address. mobile node.
`
` +-----+ +-------+ +------+
` |home | =======> |foreign| ------> |mobile|
` |agent| | agent | <------ | node |
` +-----+ +-------+ +------+
` 1) Datagram to /|\ /
` mobile node | / 4) For datagrams sent by the
` arrives on | / mobile node, standard IP
` home network | / routing delivers each to its
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 9
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

` via standard | |_ destination. In this figure,
` IP routing. +----+ the foreign agent is the
` |host| mobile node's default router.
` +----+
`
`1.8. Specification Language
`
` In this document, several words are used to signify the requirements
` of the specification. These words are often capitalized.
`
` MUST This word, or the adjective "required", means that
` the definition is an absolute requirement of the
` specification.
`
` MUST NOT This phrase means that the definition is an absolute
` prohibition of the specification.
`
` SHOULD This word, or the adjective "recommended", means
` that, in some circumstances, valid reasons may exist
` to ignore this item, but the full implications must
` be understood and carefully weighed before choosing
` a different course. Unexpected results may result
` otherwise.
`
` MAY This word, or the adjective "optional", means that this
` item is one of an allowed set of alternatives. An
` implementation which does not include this option MUST
` be prepared to interoperate with another implementation
` which does include the option.
`
`
`
`
`
`
`
`
`
`Perkins Standards Track [Page 11]
`
`RFC 2002 IP Mobility Support October 1996
`
`
` silently discard
` The implementation discards the datagram without
` further processing, and without indicating an error
` to the sender. The implementation SHOULD provide the
` capability of logging the error, including the contents
` of the discarded datagram, and SHOULD record the event
` in a statistics counter.
`
`1.9. Message Format and Protocol Extensibility
`
` Mobile IP defines a set of new control messages, sent with UDP [17]
` using well-known port number 434. Currently, the following two
` message types are defined:
`
` 1 Registration Request
` 3 Registration Reply
`
` Up-to-date values for the message types for Mobile IP control
` messages are specified in the most recent "Assigned Numbers" [20].
`
` In addition, for Agent Discovery, Mobile IP makes use of the existing
` Router Advertisement and Router Solicitation messages defined for
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 10
`IPR2019-00820, Apple Inc. v. MPH Technologies Oy
`
`

`

` ICMP Router Discovery [4].
`
` Mobile IP defines a general Extension mechanism to allow optional
` information to be carried by Mobile IP control messages or by ICMP
` Router Discovery messages. Each of these Extensions (with one
` exception) is encoded in the following Type-Length-Value format:
`
` 0 1 2
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
` | Type | Length | Data ...
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
`
` Type Indicates the particular type of Extension.
`
` Length Indicates the length (in bytes) of the data field within
` this Extension. The length does NOT include the Type and
` Length bytes.
`
` Data The particular data associated with this Extension. This
` field may be zero or more bytes in length. The format
`