Ne :work Working Group
`Request for Comments:
`:egory: Standards Track
`
`Ca
`
`2002
`
`C.
`
`
`Perkins, Editor
`
`
`
`"AM
`October 1996
`
`Status of
`
`ihis Memo
`
`IP Mobility Support
`
` inte :net standards
`
`:rack protocol for the
`This document specifies an _
`Interne: community
`, and requests discussion and suggestions for
`the current edi
`:ion of the "Internet
`improvements.
`Please refer to
`iandardization state
`Official Protocol Standards" (STD 1)
`:his memo is unlimited.
`
`
`
`and sta:us of this protocol. Distribution of
`
`
`
`
`
`for the s
`
`Abstract
`
`enhancements that allow transparent
`This document specifies protocol
`
`
`
`intern
`.e nodes in the
`et.
`Each mobile
`routing of IP datagrams to mobi-
`regardless of its
`node is always identified by its home address,
`
`current point of attachment
`to the internet.
`While situated away
`a care—of
`from its home,
`a mobile node is also associated with
`
`point of
`address, which provides information about its current
`
`attachment
`to the Lnternet.
`The pro:ocon provides for registering
`r
`
`
`the care—of address with a home agen:.
`"he 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
`
`,_r
`
`Introduction
`
`1.1 Protocol Requirements
`1.2 Goals
`
`1.3 Assumptions
`1.4 App"cability
`1.5. New Architectural
`
`
`
`Entities
`
`
`
`
`[\J
`
`
`
`1.6 Term'no’ogy
`
`1.7 Protoco" Overview
`1.8 Specification Language
`1.9. Message Format and Protocol
`Agent Discovery
`2.1. Agent Advertisement
`2.1.1. Mobility Agent Adver:isement
`
`2.1.2. Pre
`fix—Lengths Extension
`
`2.1.3. One—byte Padding Extension
`2.2 Agent Solicitation
`2.3. Foreign Agent and Home Agent Considerations
`2.3.1. Advertised Router Addresses
`
`Extensibili
`
`
`
`
`
`:ension
`
`
`
`[\Jl—‘COO‘VU‘IfififiUJLO
`
`
`HHH mb#
`11
`
`HH:mww
`
`CD
`
`[\J 0
`
`Microsoft Corporation
`Exhibit 1017-00001
`
`Microsoft Corporation
`
`

`

`Perkins
`
`RFC 2002
`
`Standards Track
`
`IP Mobility Support
`
`[Page 1]
`
`October 1996
`
`2.3.2. Sequence Numbers and Rollover Handling
`2.4. Mobile Node Considerations
`
`2.4.1. Registration Required
`2.4.2.
`ove Detection
`
`
`
`2.4.3. Returning Home
`2.4.4. Sequence Numbers and Rollover Handling
`3. Registration
`3.1. Registration Overview
`3.2. Authentication
`
`
`
`3.3. Registration Request
`3.4. Registration Reply
`3.5. Registration Extensions
`.
`.
`
`
`3.5.1. Computing Authentication thension Values
`
`3. 5. 2. Mobile—Home Authentication Extension
`
`
`
`3. 5. 3. Mobile—Foreign Authentication Extension
`
`3. 5. 4. Foreign—Home Authentication Extension
`3.6 Mobile Node Considerations
`
`3. 6. l. Sending Registration Requests
`3 6. 2. Receiving Registration Replies
`3. 6. 3. Registration Retransmission
`Foreign Agent Considerations
`3.7.1. Configuration and Registration Tables
`3. 7. 2. Receiving Registration Requests
`3.7.3. Receiving Registration Replies
`Home Agent Considerations
`3.8.1. Configuration and Registration Tables
`3.8.2. Receiving Registration Requests
`3.8.3. Sending Registration Replies
`4. Routing Considerations
`4.1. Encapsulation r‘ypes
`
`4.2. Jnicast Datagram Routing
`4.2.1.
`obile Node Considerations
`
`3.7
`
`3.8
`
`
`
`
`
`
`
`
`
`4.2.2. Foreign Agent Considerations
`4.2.3.
`{ome Agent Considerations
`4.3. BroadcaSt Datagrams
`4.4. ulticast Datagram Routing
`
`obile Routers
`4.5.
`.
`.
`.
`.
`4.6. ARP, Proxy ARP, and Gratuitous ARP
`5. Security Considerations
`5.1. Message Authentication Codes
`5.2. Areas of Security Concern in this Protocol
`5.3. <ey Management
`5.4. ?icking Good Random Numbers
`5.5. Rrivacy
`.
`.
`.
`5.6. Replay Protection for Registration Requests
`5.6.1. Replay Protection using Timestamps
`
`5.6.2. Replay PrOteCtion using Nonces
`6. Acknowledgments
`
`.
`
`.
`
`.
`
`.
`
`.
`
`
`
`
`
`
`
`
`
`
`21
`21
`22
`22
`24
`24
`24
`25
`26
`26
`29
`32
`32
`33
`33
`34
`34
`36
`4O
`42
`43
`44
`44
`47
`49
`49
`49
`53
`55
`56
`56
`56
`57
`58
`59
`6O
`61
`62
`66
`66
`66
`67
`67
`67
`68
`68
`69
`71
`
`Microsoft Corporation
`Exhibit 1017-00002
`
`Microsoft Corporation
`
`

`

`Perkins
`
`RFC 2002
`
`A.l.
`A.2.
`
`Standards Track
`
`[Page 2]
`
`IP Mobility Support
`
`October 1996
`
`5,l59,592 .
`5,148,479 .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`72
`
`72
`72
`
`73
`73
`73
`
`
`A. Patent Issues
`
`
`"3M Pat nt
`
`
`IBM Patent
`B. Link—Layer Considerations
`C. TCP Considerations
`C.l. TCP Timers
`
`C.2. TCP Congestion Management
`
`D. Example Scenarios
`D.l. Registering with a Foreign Agent Care-of Address
`D.2. Registering with a Co—aocated Care—of Address .
`D.3. Deregistration
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`3. Applicability of Prefix Lengths Extension
`Editor's Address
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`
`
`
`
`
`
`.
`
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`
`73
`74
`74
`75
`76
`76
`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 wouid 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:
`
`
`
`
`
`
`
`the node must change its IP address whenever it changes its
`point of attachment, or
`
`
`
`dost-specific routes must be propagated throughout much of
`the Internet routing fabric.
`
`r
`
`
`
`
`
`a)
`
`b)
`
`
`
`‘he first makes
`Both of these alternatives are often unacceptable.
`
`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
`expiosive growth in sales of notebook (mobile) computers.
`
`
`
`7‘
`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
`
`the Internet without changing their IP address.
`
`to
`
`1.1. Protocol Requirements
`
`A mobile node must be able to communicate with other nodes after
`
`changing its iink—layer point of attachment to the Internet, yet
`
`without changing its IP address.
`
`Perkins
`
`Standards Track
`
`[Page 3]
`
`Microsoft Corporation
`Exhibit 1017-00003
`
`Microsoft Corporation
`
`

`

`
`
`
`
`
`
`
`
`RFC 2002
`
`IP Mobility Support
`
`OCtober 1996
`
`A mobile node must be able to communicate with other nodes that do
`
`No protocol enhancements are
`implement these mobility functions.
`not
`
`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.
`r‘his link may thus have a
`substantially lower bandwidth and higher error rate than traditional
`wired networks. Moreover, mobile nodes are likely to be battery
`powered, and minimizing power consumption is important. Therefore,
`
`the number of administrativ m ssag s s nt ov r th
`‘ink by which a
`
`mobile node is directly attached to the Internet should be minimized,
`and the size of these messages should be kept as sma“ 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 th
`Int rn t mor
`fr gu ntly than once
`per second.
`
`lP unicast datagrams are routed based on
`This protocol assumes that
`the destination address in the datagram header
`(and not,
`for example,
`by source address).
`
`1.4. Applicability
`
`
`Mobile I? is int nd d to nabl
`nod s
`
`to move from one lP subnet
`
`to
`
`It is just as suitable for mobility across homogeneous
`another.
`media as it is for mobility across heterogeneous media. That is,
`
`from one Ethernet segment to
`Mobile T? faci‘itates node movement
`another as well as it accommodates node movement
`from an Ethernet
`
`to a wireless LAN, as long as the mobile node‘s I? address
`segment
`remains the same after such a movement.
`
`
`
`
`
`
`One can think of Mobile TP as solving the "macro” mobility management
`
`
`problem.
`It is less well suited for more "micro" mobility management
`
`
`
`Perkins
`
`Standards Track
`
`[Page 4]
`
`Microsoft Corporation
`Exhibit 1017-00004
`
`Microsoft Corporation
`
`

`

`RFC 2002
`
`IF Mobility Support
`
`October 1996
`
`applications —— for example, handoff amongst wireless transceivers,
`each of which covers oniy 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 IF.
`
`
`
`
`
`1.5. New Architectural Entities
`
`
`
`Mobile TP introduces the following new functional entities:
`
`Mobile Node
`
`from one
`A host or router that changes its point of attachment
`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) TP 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
`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 mobil
`nod whil
`r gist r d.
`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" TP
`
`address is provided to a stationary host. When away from its home
`networ<,
`a "care-of address“ is associated with the mobile node and
`
`The mobile
`reflects the mobile node's current point of attachment.
`node uses its home address as the source address of ail IP datagrams
`that it sends, except wh r
`oth rwis
`d scrib d in this document for
`datagrams sent for certain mobility management functions (e.g., as in
`Section 3.6.l.l].
`
`
`
`
`
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page 5]
`
`IF Mobility Support
`
`October 1996
`
`Microsoft Corporation
`Exhibit 1017-00005
`
`Microsoft Corporation
`
`

`

`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
`
`toward a mobile node,
`The termination point of a tunnel
`
`for datagrams forwarded to the mobile node while it is
`
`The protocol can use two different types
`away from home.
`a "foreign agent care—of address" is
`of care—of address:
`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
`A peer with which a mobile node is communicating.
`
`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 :nternet.
`
`Home Network
`
`A network, possibly virtual, having a networ< prefix
`matching that of a mobile node's home address. Note that
`standard IP routing mecqanisms 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
`the
`communication over a physical link. Typically,
`Link—Layer address is an interface‘s Media Access Control
`(MAC) address.
`
`Mobility Agent
`
`Either a home agent or a foreign agent.
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page 6]
`
`IP Mobility Support
`
`October 1996
`
`Microsoft Corporation
`Exhibit 1017-00006
`
`Microsoft Corporation
`
`

`

`
`
`Mobility Rinding
`
`The associa:ion of a home address wit? a care-of address,
`
`along wi_h the remaining lifetime of :hat association.
`
`
`Mobility Security Association
`A collection of security contexts, between a pair
`of nodes, which may be applied to obile IP protocol
`messages exchanged between them. Eaci context indicates
`an au:hentication algorithm and mode
`(Section 5.1),
`a
`
`secre:
`(a shared key, or appropria:e 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.
`SPl values 0
`through 255 are
`reserved and MUST NOT be used in any Mobility Security
`Association.
`
`
`
`r
`‘he path followed by a datagram while it is encapsulated.
`
`r‘he model
`is :hat, while it is encapsulated,
`a datagram
`is rou:ed to a knowledgeable decapsulating agent, which
`decapSJlates the datagram and then correctly delivers it
`to i:s ultima:e destination.
`
`Tunnel
`
`
`
`
`
`Virtual Network
`
`
`
`
`
`
`
`A ne:work witq no physical instantiation beyond a router
`(wi:h a physical network interface on another network).
`The router (e.g.,
`a home agent) generally advertises
`
`reacqability :o the virtual network using conventional
`rou:ing protocols.
`
`
`
`Visited Network
`
`A network other than a mobile node‘s Home Network,
`which the mobile node is currently connected.
`
`to
`
`Visitor List
`
`The list of mobile nodes visiting a foreign agent.
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page 7]
`
`IP Mobility Support
`
`October 1996
`
`Microsoft Corporation
`Exhibit 1017-00007
`
`Microsoft Corporation
`
`

`

`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.
`olicitation on
`A newly arrived mobile node can send a
`s
`tie link to learn if any prospec
`:ive agents are present.
`
`
`
`
`
`
`
`
`
`
`
`Registration
`qun the mobile
`
` its care-of
`
`it registers
`node is away from home,
`
`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
`the home agent.
`agent which forwards tie registration to
`
`
`
`
` tion of the
`
`The following steps provide a rougi outline of opera
`
`Mobile IP protocol:
`
`— Mobility agents (i.e.,
`foreign agents and home agents) advertise
`
`(S ction 2).
`A
`their presence via Agent Adv rtis m nt m ssag 5
`rtisement message
`mobile node may optionally solicit an Agent Adve
`
`
`from any locally attached mobii
`_ity agents through an Agent
`Solicitation message.
`
`node rcc ivcs
`thcs Agent Advertisement
`whether it is on its home network or a foreign network.
`
`—
`
`A mobil
`
`s and determines
`
`— When the mobile node de
`
`:ects that it is located
`
`on its home
`
`network, it operates wi
`:hout mobility services.
`to its home network from b ing regist red clscwh
`th i
`node deregisters wi
`:5 home agent,
`through ex
`
`Registration Regues
`and Registration Reply mess
`
`crc,
`
`tic mobile
`
`change of a
`age with it.
`
`If returning
`
`
`
`— When a mobile node detects that it Has moved to
`
`
`
`
`
`a foreign
`eign network.
`from a foreign
`address), or by
`(a foreign agent care-of
`agent's advertisements
`[6]
`(a co—located
`some external assignment mechanism such as DHCP
`care—of address).
`
`
`
`network, it obtains a care—of address on the for
`The care-o? address can either be determined
`
`—
`
`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 mess
`age with it,
`
`possibly via a foreign agent
`(SeCtion 3).
`
`Perkins
`
`Standards Track
`
`RFC 2002
`
`IR Mobility Support
`
`[Page 8]
`
`October 1996
`
`
`
`Microsoft Corporation
`Exhibit 1017-00008
`
`— Datagrams sent
`
`to the mobile node‘s home address are intercepted
`
`Microsoft Corporation
`
`

`

`to the mobile
`tunneled by the home agent
`by its home agent,
`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 lP
`routing mechanisms, not necessarily passing through the home
`agent.
`
`
`
`
`tunneling to hide a
`When away from home, Mobile lP uses protocol
`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.
`r“he care-of address must be an
`
`
`
`
`
`
`
`
`
`
`
`
`IP
`address to which datagrams can be delivered via conventional
`routing. At the care—of address,
`the original datagram is removed
`from the tunnel and delivered to the mobile node.
`
`
`Mobi’e "P 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 tanneled 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 in4 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
`The address may be dynamically acquired as
`network interfaces.
`
`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 I? 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.
`
`_‘
`"he 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
`
`RFC 2002
`
`Standards Track
`
`[Page 9]
`
`IP Mobility Support
`
`October 1996
`
`
`It does, however, place additional burden on the va4 address space
`
`because it requires a pool of addresses within the foreign network to
`
`Microsoft Corporation
`Exhibit 1017-00009
`
`Microsoft Corporation
`
`

`

`
`it is difficul
`be made available to visiting mobile nodes.
`efficiently maintain poo's of addresses for each subnet tha
`permit mobile nodes to visit.
`
`
`
`to
`
`may
`
`
`
`
`
`
`
`
`:o understand the dis:inction between the care—of
`It is importan:
`address and the foreign agent functions.
`The care—of address is
`
`simply the endpoint of the tunnel.
`l“ might
`indeed be an address of
`a foreign agen:
`(a foreign agent care-of address), but it might
`instead be an address temporarily acquired by the mobile node (a co—
`loca:ed 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 :0 attract and in:ercept datagrams that are
`destined to :he home address of any of i:s registered mobile nodes.
`Using the proxy and gratui:ous ARP mechanisms described in Section
`4.6,
`this requirement can be satisfied if tie home agent has a
`network interface on the link indicated by :he mob"e node's home
`address. Other placements of th hom ag n: r lativ 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.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`a mobile node and a prospec:ive or current foreign agent
`Sim'7arly,
`MUS" be able to exchange datagrams without relying on standard IP
`routing mechanisms;
`that is,
`those mecqanisms which make forwarding
`decisions based upon the network—prefix of the destination address in
`the lP header. This requirement can be satisfied if the foreign
`agen; and the visi:ing mobile node gave an interface on :he same
`
`In this case,
`link.
`the mobile node and foreign agent simply bypass
`their normal
`IP rOJting mechanism wqen sending datagrams to each
`
`other, addressing :he underlying link—layer packets to tdeir
`respect ve "ink—layer addresses. O:her placements of the foreign
`agen: relative to :he mobile node MAY also be possible using other
`mechanisms to exchange datagrams be:ween these nodes, bu: such
`placements are beyond the scope of :his document.
`
`
`
`
`
`
`
`
`
`If a mobile node is using a co—loca:ed 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.
`
`the figure below illustrates the routing of datagrams to
`For example,
`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
`
`RFC 2002
`
`Standards Track
`
`[Page 10]
`
`IF Mobility Support
`
`October 1996
`
`2) Datagram is intercepted
`by home agent and
`
`is tunneled :o the
`
`3) Datagram is
`
`detunneled and
`delivered to the
`
`Microsoft Corporation
`Exhibit 1017-00010
`
`Microsoft Corporation
`
`

`

`care—of address.
`
`mobile node.
`
`+ ————————,
`
`r————————,
`
`:::::::> \foreign —————— > mobile
`\ agent
`< ——————
`node
`+ —————————
`——————————
`
`
`
`
`
`
`
`4) For datagrams sent by the
`mobile node, standard I?
`routing delivers each to its
`
`In this figure,
`destination.
`the foreign agent is tie
`mobile node's default router.
`
`
`
`
`
`o
`l) Datagram t
`mobile node
`arrives on
`home network
`via standard
`
`LP routing.
`
`+ ——————,
`
`\home
`lagent
`+ ———————
`
`
`
`/|\
`
`|
`|
`|
`
`|
`+ ——————
`\host
`+ _____,
`
`
`
`1.8. Specification
`
`Language
`
`/
`
`/
`
`/
`
`/
`
`i
`
`t,
`several words are used to signify the requirements
`r
`ation.
`‘hese words are often capitalized.
`
`
`
`
`m ans that
`adj ctiv
`r guir d",
`his word,
`he definition is an absolute requirement of the
`pecification.
`
`or th
`
`In this documen
`
`of the specific
`
`T t s
`
`MUST
`
`his phrase means that
`rohibition of the specification.
`
`the definition is an absolute
`
`
`
`means
`
`exist
`must
`
`T p
`
`T t t a 0
`
`
`
`MUST NOT
`
`SHOULD
`
`MAY
`
`
`his word, or th
`adj ctiv "r comm nd d“,
`hat,
`in some circumstances,
`valid reasons may
`the full implications
`0 ignore this item, but
`be understood and carefully weighed before choosing
`different course.
`Unexpected results may result
`therwise.
`
`
`e prepared to inte
`
`T
`
`
`
`b w
`
`include this option MUST
`implementation which does not
`foperate with another implementation
`
`dich does include the option.
`
`means that
`his word, or the adjective "optional",
`item is one of an allowed set of alternatives.
`
`this
`
`An
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`IP Mobility Support
`
`[Page ll]
`
`October 1996
`
`card
`
`silently dis
`The implementation discards the datagram without
`ur
`ther processing,
`and without indicating an error
`
`
`O
`the sender.
`The implementation SHOUSD provide the
`
`f t
`
`Microsoft Corporation
`Exhibit 1017-00011
`
`Microsoft Corporation
`
`

`

`including the contents
`capability of logging the error,
`
`of the discarded datagram, and SHOULD record the event
`in a statistics counter.
`
`
`1.9. Message Format and Rrotocol Extensibility
`
`Mobile IR defines a set of new control messages, sent with UDR [17]
`using well—known port number 434. Currently,
`the following two
`
`m ssag
`typ s ar
`d fin d:
`
`
`
`1 Registration Request
`3 Registration Reply
`
`
`
`Jp-to-date values for the message types for Mobile IR control
`n ssag 5 ar
`sp cifi d in the most recent "Assigned Numbers"
`
`[20].
`
`for Agent Discovery, Mobile IR makes use of the existing
`In addition,
`Router Advertisement and Router Solicitation messages defined for
`ICMR Router Discovery [4].
`
`
`
`
`
`Mobile IR defines a general Extension mechanism to allow optional
`information to be carried by Mobile IR control messages or by ICMR
`
`Router Discovery messages.
`Each of these Extensions (with one
`exception)
`is encoded in the following Type-Length-Value format:
`
`
`
`
`
`
`
`l
`O
`O
`l
`2 3
`4
`5
`6
`7
`8
`9
`O
`l
`2 3
`4
`5
`6
`7
`8
`9
`
`
`2
`O
`
`l
`
`2
`
`
`
`
`
`Type
`
`
`
`
`
`\
`
`
`
`Length
`
`
`
`
`
`
`
`
`
`
`
`Data
`
`
`
`
`
`
`Indicates the particular type of Extension.
`
`
`
`
`
`
`Type
`
`Length
`
`Data
`
`Indicates the length (in bytes) of the data field within
`this Extension.
`The length does
`OT inclade the Type and
`
`Lengto bytes.
`
`
`
`
`
`
`
`The particular data associated with this Extension. This
`field may be zero or more bytes in length.
`The format
`and length of the data field is determined by the type
`and length fields.
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Rage 121
`
`IR Mobility Support
`
`October 1996
`
`
`Extensions allow variable amounts of information to be carried within
`
`The end of the list of Extensions is indicated by the
`each datagram.
`total length of the IR datagram.
`
`Two separately maintained sets of numbering spaces,
`
`from which
`
`Microsoft Corporation
`Exhibit 1017-00012
`
`Microsoft Corporation
`
`

`

`
`
`Extension Type values are allocated, are used in Mobile iP:
`
`—
`
`—
`
`The first set consists of those Extensions which may appear only
`in Mobile IP control messages
`(tdose sent
`to and from UDP port
`number 434). Currently,
`the following Types are defined for
`
`
`Extensions appearing in Mobile :9 controi messages:
`
`
`
`
`
`32 Mobile—Home Authentication
`
`
`33 Mobile—Foreign Autqentication
`34
`Foreign—Home Authentication
`
`‘he second set consists of those extensions which may appear only
`
`in TCMR Router Discovery messages
`[4]. Currently, Mobile IR
`
`defines the following Types for Extensions appearing in ICMP
`Router Discovery messages:
`
`O One—byte Padding (encoded with no Length nor Data field)
`16 Mobility Agent Advertisement
`19 Prefix-dengths
`
`
`
`
`
`
`Each indiv’dua‘ RXtension is described in detail in a separate
`section later in tiis document. Up—to—date values for these
`Extension r‘ype numbers are specified in the most recent “Assigned
`umbers"
`[20].
`
`
`
`
`
`
`
`
`
`Due to the separation (orthogonality) of these sets, it is
`
`
`conceivable that two Extensions twat are defined at a later date
`so long as one of the Extensions
`could have identical Type values,
`
`may be used only in Mobile LP control messages and the other may be
`used only in ICMP Router Discovery messages.
`
`
`
`
`When an Extension numbered in eitier of these sets within the range 0
`through 127 is encountered but not
`recognized,
`the message containing
`
`
`that Extension MUST be silently discarded. When an Extension
`numbered in the range l28 through 255 is encountered which is not
`recognized,
`tqa: particular Extension is ignored, but
`the rest of the
`
`Extensions and message data
`UST still be processed.
`r‘he Length
`
`field of the ixtension is used to skip the Data field in searching
`for the next Extension.
`
`
`
`
`
`
`
`
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page 13]
`
`IR Mobility Support
`
`October 1996
`
`2. Agent Discovery
`
`Agent Discovery is the method by which a mobile node determines
`whether it is currently connected to its home network or to a foreign
`network, and by which a mobile node can detect when it gas moved from
`one network to another. When connected to a foreign network,
`the
`
`
`
`Microsoft Corporation
`Exhibit 1017-00013
`
`Microsoft Corporation
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`methods specified in this section also allow the mobile node to
`detefmine the foreign agent care—of address being offered by each
`foreign agent on that network.
`
`
`
`
`e "P eXtends :CMP Router Discovery [4] as its primary mechanism
`Mobi
`for Agent Discovery.
`An Agent Advertisement is formed by including a
`
`
`Mob:
`ity Agent Advertisement Extension in an :CM? Router
`Advcrtiscm nt mcssag
`(ScCiioo 2.i).
`An Agent Solicitation message
`
`to an :CMP Router Soiicitation, except that its IP r‘Tl.
`is 'dentica’
`MUS" be set to 1
`(Section 2.2).
`r"his section describes the message
`formats and procedires by wqich mobile nodes,
`foreign agents, and
`home agents coop rat
`to r aliz Ag nt Discovery.
`
`
`
`
`
`
`
`
`
`
`Agent Advertisement and Agent Solicitation may not be necessary for
`iink layers that already provide this functionality.
`The method by
`which mobile nodes establish lin<—layer connections with prospective
`
`agents is outside the scope of this document
`(but see Appendix 3).
`Ii
`‘he procedures described below assume that such link—iayer
`connectivity has already been establisqed.
`
`No authentication is required for Agent Advertisement and Agent
`Solicitation messages.
`They MAY be authenticated using the IP
`Authentication Header [l], which is unrelated to the messages
`described in this document.
`Further specification of the way in
`which Advertisement and Solicitation messages may be authenticated is
`outside of the scope of this dociment.
`
`
`
`
`
`2.l. Agent Advertisement
`
`to advertise
`Agent Advertisements are transmitted by a mobility agent
`
`its services on a link. Mobil
`nod s us
`th s
`adv rtis m nts to
`
`An
`determine their current point of attachment to the Internet.
`Agent Advertisement is an lCMP Router Advertisement that ias been
`
`extended to aiso carry an Mobility Agent Advertisement Extension
`
`(Section 2.l.i) and, optionally,
`a Prefix—Lengths Extension (Section
`
`2.1.2), One—byte Padding Extension (Section 2.1.3), or Otier
`
`Extensions that might be defined in the future.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`iCMP Router Advertisement
`Within an Agent Advertisement message,
`
`fieids of th m ssag
`ar
`r guir d to conform to the following
`
`additional specifications:
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page 14]
`
`IP Mobility Support
`
`October 1996
`
`— Link—Layer Fields
`
`Destination Address
`
`The link-layer destination address of a unicast
`Agent Advertisement MUST be the same as the source
`
`link—iayer address of the Agent Solicitation which
`prompted the Advertisement.
`
`
`
`
`
`Microsoft Corporation
`Exhibit 1017-00014
`
`Microsoft Corporation
`
`

`

`—
`
`1P Fields
`
`TTL
`
`The TTL for all Agent Advertisements MUST be set
`to 1.
`
`Destination Address
`
`the TR
`As specified for TCMP Router Discovery [4],
`destination address of an Agen: Advertisement MUST
`
`be either the "all systems on :his link" multicast
`address (224.0.0.1)
`[5] or the "limited broadcast"
`address (255.255.255.255).
`The subnet—directed
`
`broadcast address of the form <prefix>.<—1> cannot be
`used since mobile nodes will not generally know the
`prefix of the foreign network.
`
`
`
`-
`
`ICMP Fields
`
`Code
`
`The Code field of the agent advertisement is
`interpreted as follows:
`
`
`
`0 The mobility agent handles common traffic —— that
`is, it acts as a router for IR datagrams not
`necessarily related to mobile nodes.
`16 The mobility agent does not route common traffic.
`However, all foreign agents MUST (minimally)
`forward to a default router any datagrams received
`
`from a registered mobile node (Section 4.2.2).
`
`
`
`
`
`Lifetime
`
`The maximum length of time that the Advertisement
`
`
`is considered valid in the absence of further
`Advertisements.
`
`Router Address(es)
`See Section 2.3.; for a discussion of the addresses
`
`that may appear in this portion of the Agent
`Advertisement.
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page 15]
`
`IR Mobility Support
`
`October 1996
`
`Num Addrs
`
`The number of Router Addresses advertised in this
`
`message. Note that in an Agent Advertisement
`message,
`the number of router addresses specified in
`the ICMP Rou:er Advertisement portion of the message
`MAY be set to 0.
`See Section 2.3.1 for details.
`
`
`
`1f sent periodically,
`
`the nominal interval at which Agent
`
`Microsoft Corporation
`Exhibit 1017-00015
`
`Microsoft Corporation
`
`

`

`SHOUED be 1/3 of the advertisement Lifetime
`This allows a mobile node to miss three
`given in the ICMP header.
`
`successive advertiscm nts