`
`Exhibit 1017Exhibit 1017
`
`
`
`ZTE Corporation and ZTE (USA) Inc.ZTE Corporation and ZTE (USA) Inc.
`
`

`

`ing Group
`Ne:wor Wor
`Request for Comments: 2002
`Category: Standards Track
`
`Status of
`
`ihis Memo
`
`IP Mobility Support
`
`This document specifies an Internet standards track protocol for the
`Interne: community, and requests discussion and suggestions for
`improvements.
`Please refer to the current edijion of the "Internet
`Official Protocol Standards" (STD l)
`for the siandardization state
`
`and sta:us of this protocol. Distribution of :his memo is unlimited.
`
`Abstract
`
`This document specifies protocol enhancements that allow transparent
`routing of IP datagrams to mobi_e nodes in the Lnternet.
`Each mobile
`node is always identified by its home address,
`regard_ess of its
`current point of attachment
`to the Lnternet. 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 pro:oco_ provides for registering
`the care—of address with a home agen:.
`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
`Ls
`then delivered to the mobile node.
`
`_e of Contents
`
`>—4 t oduction
`
`Protocol Requirements
`Goa_s
`
`Assumptions
`App"cability
`New Architectural Entities
`
`Term no ogy
`Protoco_ Overview
`
`.
`
`[\Ji—‘COO‘vU‘|>J>»J>»J>L,«J(.«.)
`
`P—‘l—‘>—‘
`
`11
`
`O\»J>»J>
`
`CO
`C
`
`KOKO
`I—‘l—‘
`l\.) G
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00001
`
`r l 2 3 4
`
`.
`5.
`
`6 7 8 9
`
`is[\)LQ>—‘>—‘I—‘I—‘>—‘>—‘}—‘I—‘I—‘5
`
`l\)
`
`Specification Language
`Message Format and Protocol Extensibili
`e t
`Discovery
`»—| Agent Advertisement
`.
`.
`.
`.
`.
`.
`.
`.
`2.l.l. Mobility Agent Adver:isement
`2.l.2. Prefix—Lengths Extension
`2.l.3. One-byte Padding Extension
`Agent Solicitation
`2.3. Foreign Agent and Home Agent Considerations
`2.3.l. Advertised Router Addresses
`
`

`

`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page 1]
`
`IP Mobility Support
`
`October 1996
`
`2.3.2. Sequence Numbers and Rollover Handling
`2.4. Mobile Node Considerations
`
`Registration Required
`ove Detection
`
`Returning Home
`Sequence Numbers and Rollover Handling
`
`3. Registra"
`3.1. Registra:ion Overview
`Authentication
`
`Registration Request
`Registration Reply
`Registration Extensions
`0
`3.r.1. Computing Authentication Rxtension Values
`. Mobile—Home Authentication Extension
`
`. Mobile—Poreign Authentication Extension
`. Foreign—Home Authentication Extension
`Node Considerations
`
`2 3 4 e 1 2 3 9 1 2
`
`LULULAJ
`
`Z o CT
`
`'l
`
`“'1LAJLOOLUUJLAJ ti\l\1(DO“.O‘\OWl—‘U'|U'|L)7
`
`Sending Registration Requests
`Receiving Registration Replies
`Registration Retransmission
`i n Agent Considerations
`Configuration and Registration Tables
`Receiving Registration Requests
`3.7.3. Receiving Registration Replies
`Home Agent Considerations
`3.8.1. Contiguration and Registration Tables
`3.8.2. Receiving Registration Requests
`3.8.3. Sending Registration Replies
`4. Routing Considerations
`4.1. Encapsulation Types
`4.2. Jnicast Datagram Routing
`4.2.1.
`obile Node Considerations
`
`4.2.2. Foreign Agent Considerations
`4.2.3.
`{ome Agent Considerations
`Broadcast Datagrams
`ulticast Datagram Routing
`obile Routers
`.
`.
`.
`.
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`ARP, Proxy ARP, and Gratuitous ARP
`rity Considerations
`Wessage Authentication Codes
`Areas of Security Concern in this Protocol
`<ey Management
`?icking Good Random Numbers
`?rivacy
`Replay Protection for Registration Requests
`5.6.1. Replay Protection using Timestamps
`5.6.2. Replay Protection using Nonces
`6. Acknowledgments
`
`(_;‘\U‘IU'I(D»J>»J>»J>»J>
`
`U'|L)7(_J“
`
`o\Ln»J>LuM>—\CowU‘Iu>oo
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00002
`
`

`

`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page 2]
`
`IP Mobility Support
`
`October 1996
`
`Patent Issues
`
`A.1.
`A.2.
`
`"RM Pat nt
`IBM Patcnt
`
`5,159,592
`5,148,479
`
`Link—Layer Considerations
`TCP Considerations
`C.1. TCP Timers
`
`C.2. TCP Congestion Management
`Example Scenarios
`D.1. Registering with a Foreign Agent Care-of Address
`D.2. Registering with a Co—socated Care—of Address
`D.3. Deregistration
`.
`3. Applicability of Prefix Lengths Extension
`Editor's Address
`
`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:
`
`a)
`
`b)
`
`the node must change its IP address whenever it changes its
`point of attachment, or
`
`1OSt—Sp€Clf1C routes must be propagated throughout much of
`the Internet routing fabric.
`
`The 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
`exp_osive 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 LP 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
`
`

`

`RFC 2002
`
`TP Mobility Support
`
`.tober 1996
`
`A mobile node must be ab_e to communicate with other nodes that do
`
`No protocol enhancements are
`implement these mobiiity functions.
`not
`required in hosts or routers that are not acting as any of the new
`architectural entities introduced in Section l.5.
`
`All messages used to update another node as to the location of a
`mobiie node must be authenticated in order to protect against remote
`redirection attacks.
`
`l.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
`powered, and minimizing power consumption is important. Therefore,
`the number of administrativ m ssag s s nt ov r th
`‘ink by which a
`mobiie 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.
`
`IP 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 T? is int nd d to nabl
`
`nod s
`
`to move from one TP subnet
`
`to
`
`It is just as suitab_e for mobility across homogeneous
`another.
`media as it is for mobility across heterogeneous media. That is,
`Mobile T? fac"itates node movement
`from one Ethernet segment to
`another as well as it accommodates node movement
`from an Ethernet
`
`to a wireless LAN, as _ong as the mobile node's I? address
`segment
`remains the same after such a movement.
`
`One can think of Mobile IP as solving the "macro" mobility managemen
`problem.
`It is less well suited for more "micro" mobility managemen
`
`Standards Track
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00004
`
`

`

`IP 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 IP.
`
`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" IP
`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.
`IP datagrams
`node uses its home address as the source address of a_l
`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]
`
`IP Mobility Support
`
`October 1996
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00005
`
`

`

`.o. Termino ogy
`
`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
`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
`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.
`Lt remains unchanged regardless
`of where the node is attached to the internet.
`
`Home Network
`
`A network, possibly virtual, having a networ< prefix
`matching that of a mobile node's home address. Note that
`standard TP routing mecqanisms will deliver datagrams
`destined to a mobile node's Home Address to the mobile
`node's Home Network.
`
`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]
`
`IF Mobility Support
`
`October l996
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00006
`
`

`

`Mobility Rinding
`The association of a home address wit? a care-of address,
`
`along wi_h _he remaining lifetime of that 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 authentication algorithm and mode
`(Section 5.l),
`a
`secret
`(a shared key, or appropriate public/private
`key pair], and a style of replay protection in use
`(Section 5.6).
`
`A host or a router.
`
`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.
`SP1 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.
`The model
`is that, while it is encapsulated,
`a datagram
`is routed to a knowledgeable decapsulating agent, which
`decapsilates the datagram and then correctly delivers it
`to its ultimate destination.
`
`Virtual Network
`
`A network witq no physical instantiation beyond a router
`(with a physical network interface on another network).
`The router (e.g.,
`a home agent) generally advertises
`reacfiability to the virtual network using conventional
`routing 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
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00007
`
`

`

`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
`tie link to learn if any prospective agents are present.
`
`Registration
`is away from home, it registers
`Wqen the mobi
`ith its home agent. Depending on
`its care-of
`its method of attachment,
`the mobile node will register
`either direcely with ies home agent, or through a foreign
`agent which forwards tie registration to the home agent.
`
`The following steps provide a IOUQT outline of operation of the
`Mobile IP protocol:
`
`foreign agents and home agents) advertise
`Mobility agents (i.e.,
`their presence via Agent Adv rtis m nt m ssag s
`(S ction 2).
`A
`mobile node may optionally solicit an Agent Advertisement message
`from any locally attached mobility agents through an Agent
`Solicitation message.
`
`node rec ives thes Agent Advertisements and determines
`A mobil
`whether it is on its home network or a foreign network.
`
`When the mobile node detects that it is located on its home
`
`If returning
`network, it operates without mobility services.
`to its home network from b ing regist red elsewhere,
`tie mobile
`node deregisters with i:s home agen:,
`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).
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page 8]
`
`IR Mobility Support
`
`tober 1996
`
`— Datagrams sent
`
`to the mobile node's home address are intercepted
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00008
`
`

`

`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 IP
`routing mechanisms, not necessarily passing through the home
`agent.
`
`tunneling to hide a
`When away from home, Mobile IP 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.
`"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 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
`
`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
`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.
`
`‘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 l996
`
`It does, however, place additional burden on the IPv4 address space
`because it requires a pool of addresses within the foreign network to
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00009
`
`

`

`ft is difficul
`be made available to visiting mobile nodes.
`efficiently maintain poo's of addresses for each subnet tha
`permit mobiie nodes to visit.
`
`to understand the distinction between the care—of
`It is important
`address and the foreign agent functions.
`The care—of address is
`simpiy 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-
`iocated care—of address .
`A foreign agent, on the other hand,
`is a
`mobiiity agent that provides services to mobile nodes.
`See Sections
`3.7 and 4.2.2 for additional details.
`
`A home agent MUST be abie 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 tie home agent has a
`network interface on the link indicated by the mob"e node's home
`address. Other placements of th hom ag nt r lativ to the mobile
`node's home iocation 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 prospective or current foreign agent
`Sim"arly,
`MUS" be able to exchange datagrams without relying on standard IP
`routing mechanisms;
`that is,
`those mecianisms which make forwarding
`decisions based upon the network—prefix of the destination address in
`the :P header. This requirement can be satisfied if the foreign
`agen'
`and the visiting mobile node Have an interface on the same
`link.
`in this case,
`the mobile node and foreign agent simply bypass
`thei
`normai TP roiting mechanism wqen sending datagrams to each
`othe , addressing the underlying link—layer packets to tneir
`respect ve "ink-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 undeliverabie.
`
`the figure below illustrates the routing of datagrams to
`For example,
`and from a mobile node away from home, once the mobiie 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 l0]
`
`IP Mobility Support
`
`October 1996
`
`2) Datagram is intercepted
`by home agent and
`is tunneled to the
`
`3) Datagram is
`detunneled and
`delivered to the
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00010
`
`

`

`care—of address.
`
`mobile node.
`
`+ _ _ _ _ _ _ __
`
`lforeign
`
`_ _ _ _ _ _ __
`
`\+
`
`For datagrams sent by’
`mobile node, standard KP
`
`routing delivers each to its
`destination.
`In this figure,
`the foreign agent is tie
`mobile node's default router.
`
`l) Datagram to
`mobile node
`arrives on
`
`home network
`via standard
`LP routing.
`
`.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 th adj ctiv "r guir d", m ans 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
`
`“his word, or th adj ciiv "r comm nd d", 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.
`
`‘his word, or the adjective "optional", means that this
`item is one of an allowed set of alternatives.
`An
`
`include this option MUST
`implementation which does not
`be prepared to interoperate with another implementation
`wqich does include the option.
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page ll]
`
`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 SHOUQD provide the
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00011
`
`

`

`including the conten
`capability of logging the error,
`of the discarded datagram, and SHOULD record the even
`in a statistics counter.
`
`1.9. Message Format and Protocol 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 s 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:
`
`0
`0
`
`1 2 3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`l
`0
`
`1
`
`2 3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`2
`0
`
`1 2
`
`\
`
`Length
`
`Indicates the particular type of
`
`tension.
`
`Indicates the length (in bytes)
`this Extension.
`The length does
`Lengti bytes.
`
`o
`
`the data field within
`OT inclade the Type and
`
`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.
`
`Rerkins
`
`RFC 2002
`
`Standards Track
`
`[Rage 12]
`
`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
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00012
`
`

`

`Extension Type values are allocated, are used in Mobile LP:
`
`The first set consists of those Extensions which may appear only
`in Mobile IP control messages
`(tqose sent
`to and from UDP port
`number 434). Currently,
`the following Types are defined for
`Extensions appearing in Mobile i? controi messages:
`
`32 Mobile-Home Authentication
`
`33 Mobile—Foreign Autientication
`34
`Foreign—Home Authentication
`
`‘he second set consists of those extensions which may appear only
`in TCMP Router Discovery messages
`[4]. Currently, Mobile IP
`defines the following Types for Extensions appearing in ICMP
`Router Discovery messages:
`
`0 One-byte Padding (encoded with no Length nor Data field)
`16 Mobility Agent Advertisement
`19 Prefix-Eengths
`
`Each indiv’dua" Extension is described in detail in a separate
`section later in tqis document. Up—to—date values for these
`Extension Type numbers are specified in the most recent "Assigned
`umbers"
`[20].
`
`Due to the separation (orthogonality) of these sets, it is
`conceivable that two Extensions tnat 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 eitner 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,
`twat particular Extension is ignored, but
`the rest of the
`—:E
`Extensions and message data
`UST still be processed.
`The Length
`-—a
`field of the ixiension is used to skip the Data field in searching
`for the next
`xtension.
`
`4_
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page 13]
`
`IP Mobility Support
`
`October 1996
`
`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 qas moved from
`one network to another. When connected to a foreign network,
`the
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00013
`
`

`

`methods specified in this section also allow the mobile node to
`determine the foreign agent care-of address being offered by each
`foreign agent on that network.
`
`e “P extends ICMP 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 LCM? Qouter
`A
`Advcrtiscm nt mcssag
`(Section 2.i).
`An Agent Solicitation message
`is 'dentica’
`to an iCMP Router Soiicitation, except that its IP "TL
`MUST be set to 1
`(Section 2.2). This 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).
`r
`‘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
`[1], 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 TCMP Router Advertisement that was been
`extended to aiso carry an Mobility Agent Advertisement Extension
`(Section 2.l.i) and, optionally,
`a Prefix-Lengths Extension (Section
`2.l.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 quir d to conform to the following
`additional specifications:
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page 14]
`
`IP Mobility Support
`
`October l996
`
`— 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.
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00014
`
`

`

`-
`
`IP Fields
`
`TTL
`
`The TTL for all Agent Advertisements MUST be set
`to 1.
`
`Destination Address
`
`the IP
`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>.<—l> 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:
`
`The mobility agent handles common traffic —— that
`is, i: acts as a router for IR datagrams not
`necessarily related to mobile nodes.
`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.
`
`If sent periodically,
`
`the nominal interval at which Agent
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00015
`
`

`

`Advertisements are sent SHOU;D be l 3 of the advertisement Lifetime
`
`given in the ICMP header. This allows a mobile node to miss three
`successive advcrtiscm nts bctor deleting the agent
`from its list of
`valid ageqts.
`The actual
`transmission time for each advertisement
`SHOULD be slightly randomized [4]
`in order to avoid synchronization
`and subsequent collisions with otqer Agent Advertisements that may be
`sent by other agents (or witi other Router Advertisements sent by
`other routers). Note that tiis field has no relation to tie
`
`"Registration Lifetime” field witdin the Mobility Agent Advertisement
`Extension defined below.
`
`2.l.l. Mobility Agent Advertisement Extension
`
`The Mobility Agent Advertisement Extension follows the ICMP Router
`Advertisement fields.
`It is used to indicate that an ICMP Router
`
`Advertisement message is also an Agent Advertisement being sent by a
`mobility agent.
`The Mobility Agent Advertisement Extension is
`defined as follows:
`
`0
`O
`
`l 2 3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`l
`O
`
`l 2 3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`2
`O
`
`l 2 3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`Length
`——+—— ——~—+—+—~—~—~—+—+——
`
`Sequence Number
`——~—+—+—~—~—~—+—+——
`
`Registration Lifetime
`
`M G V}
`
`reserved
`
`zero or more Cafe—o’
`
`l6
`
`Length
`
`(6 + 4*N], where N is the number of care—of addresses
`advertised.
`
`Sequence Number
`The count of Agent Adv rtis m nt m ssag s
`agent was initialized (Section 2.3.2).
`
`s nt since the
`
`Perkins
`
`RFC 2002
`
`Standards Track
`
`[Page l6]
`
`IR Mobility Support
`
`October l996
`
`Registration Lifetime
`that this
`"he longest _ifetime {measured in seconds)
`agent is willing to accept
`in any Registration Request.
`A value of Oxffft indicates infinity. Tnis field has no
`relation to ;
`.ifetime" field within the ICM? Router
`
`Advertisemen'
`
`tion of the Agent Advertisement.
`
`Registration required. Registration witfi this foreign
`agent
`(or another foreign agent on this link)
`is required
`
`ZTE Corporation and ZTE (USA) Inc.
`
`Exhibit 1017-00016
`
`

`

`rather than using a co—located care—of address.
`
`The foreign agent will not accept registrations
`Busy.
`from additional mobil