Eig
`E
`
`
`
`DECLARATION OF SANDY GINOZA FOR IETF
`
`RFC: 3103 REALM SPECIFIC IP: PROTOCOL SPECIFICATION
`
`I, Sandy Ginoza, based on my personal knowledge and information, hereby declare as
`
`follows:
`
`1.
`
`I am an employee of Association Management Solutions, LLC (AMS), which
`
`act under contract to the IETF Administration LLC (IETF) as the operator of the RFC
`
`Production Center. The RFC Production Center is part of the "RFC Editor" function, which
`
`prepares documents for publication and places files in an online repository for the
`
`authoritative Request for Comments (RFC) series of documents (RFC Series), and preserves
`
`records relating to these documents. The RFC Series includes, among other things, the series
`
`of Internet standards developed by the IETF. I hold the position of Director of the RFC
`
`Production Center. I began employment with AMS in this capacity on 6 January 2010.
`
`2.
`
`Among my responsibilities as Director of the RFC Production Center, I act as
`
`the custodian of records relating to the RFC Series, and I am familiar with the record keeping
`
`practices relating to the RFC Series, including the creation and maintenance of such records.
`
`3.
`
`From June 1999 to 5 January 2010, I was an employee of the Information
`
`Sciences Institute at University of Southern Caiifornia (1S1). I held various position titles with
`
`the RFC Editor project at ISL ending with Senior Editor.
`
`4.
`
`The RFC Editor function was conducted by 181 under contract to the United
`
`States government prior to 1998. In 1998, ISOC, in furtherance of its IETF activity, entered into
`
`the first in a series of contracts with 181 providing for ISI’S performance of the RFC Editor
`
`function. Beginning in 2010, certain aspects of the RFC Editor function were assumed by the
`
`RFC Production Center operation of AMS under contract to ISOC (acting through its IETF
`
`Apple Inc.
`EX. 1013 - Page 1
`
`Apple Inc.
`Ex. 1013 - Page 1
`
`

`

`function and, in particular, the IETF Administrative Oversight Committee (now the
`
`[ETF Administration LLC ([ETF)). The business records of the RFC Editor function as it was
`
`conducted by ISI are currently housed on the computer systems of AMS, as contractor to the
`
`IETF.
`
`5.
`
`I make this declaration based on my personal knowledge and information
`
`contained in the business records of the RFC Editor as they are currently housed at AMS, or
`
`confirmation with other responsible RFC Editor personnel with such knowledge.
`
`6.
`
`Any RFC published on the RFC Editor website or via FTP was reasonably
`
`accessible to the public and was disseminated or otherwise available to the extent that persons
`
`interested and ordinarily skilled in the subject matter or art exercising reasonable diligence could
`
`have located it. In particular, the RFCs were indexed and placed in a public repository.
`
`7.
`
`The RFCs are kept in an online repository in the course of the RFC Editor‘s
`
`regularly conducted activity and ordinary course of business. The records are made pursuant to
`
`established procedures and are relied upon by the RFC Editor in the performance of its functions.
`
`9.
`
`It is the regular practice of the RFC Editor to make and keep the RFC records.
`
`10.
`
`Based on the business records for the RFC Editor and the RFC Editor’s course of
`
`conduct in publishing RFCs, I have determined that the publication date of RFC 3103 was no
`
`later than October 2001, at which time it was reasonably accessible to the public either on the
`
`RFC Editor website or via FTP from a repository. A copy of that RFC is attached to this
`
`declaration as an exhibit.
`
`Apple Inc.
`EX. 1013 - Page 2
`
`
`
`
`
`
`
`Apple Inc.
`Ex. 1013 - Page 2
`
`

`

`Pursuant to Section 1746 of Title 28 of United States Code, I declare under penaity of
`
`perjury under the laws of the United States of America that the foregoing is true and correct
`
`and that the foregoing is based upon personal knowledge and information and is believed to be
`
`true.
`
`Date: Jim—WW By:
`
`Sandy
`
`'
`
`a
`
`4849-5884-4021]
`
`ATTACHED CALIF. ACKNOWLEDGMENT
`
`h i ‘0‘ \ 1 «3)
`
`
`
`Apple Inc.
`Ex. 1013 - Page 3
`
`Apple Inc.
`Ex. 1013 - Page 3
`
`

`

`CIVIL CODE § 1189
`CALIFORNIA ALL- PURPOSE ACKNOWLEDGMENT
`
`
`A notary public or other officer completing this certificate verifies only the identity of the individuai who signed the
`document to which this certificate is attached, and not the truthfulness. accuracy, or vaiidity of that document.
`
`
`
`
`
`Here lnsert Name and Title of the Of rcer
`
`
`pUbMC
`
`State of California
`
`\ 0g filiifiilfle
`County of\
`H! [01 “go;
`beforeme,
`personally appeared
`
`Date
`
`)
`
`)
`
`
`
`EALLgfiifl' Net—0t
`SWY1%%W
`
`efiof Signerfi
`
`
`
`who proved to me on the basis of satisfactory evidence to be the p
`
`on whose namegii
`
`ribed to the within instrument and acknowlersWe!to me that fit executed the sa e in
`3
`@ttfiéirauthorizedcapacityfleé),andthatbfie‘hfiéirsignatur
`heinstrumentthe persongg),
`entity upon behaif of which the personvzactec executed the instrument.
`rt
`
`age
`
`
`iNI. L PEREZ
`
`Notaryi’ubllc- California
`
`Los Angelus County
`
`Commission 11 22l3039
`MyComm ExpiresSep Iti 202 1
`
`
`.mm
`
`I certify under PENALTY OF PERJURY under the laws
`of the State of California that the foregoing paragraph
`is true and correct.
`
`WiTNESS my hand and official seal.
`
`Signature
`
`
`
`:;
`
`33
`
`:23
`
`10$
`
`Place Notary Seal Above
`
`OPTIONAL
`
`Though this section is optional, completing this information can deter alteration of the document or
`fraudulent reattachment of this form to an unintended document.
`
`Description of Attached Documen
`
`Title or Type of Document:
`Document Date:
`
`
`
`-
`~
`
`
`1300 efldndxflunggfoflsfiw iETLPéfC
`
`
`
`Signer(s) Other Than Named Above:
`
`
`
`Capacityfies) Claimed by Signer(s)
`Signer's Name:
`Signer's Name:
`IZI Corporate Officer — Title(s):
`Iii Corporate Officer — Title(s):
`
`:l Partner ~— i:l Limited
`III General
`III Partner — E Limited
`[:1 Generai
`:1 Individual
`III Attorney in Fact
`El Individual
`III Attorney in Fact
`.3 Trustee
`El Guardian or Conservator
`III Trustee
`CI Guardian or Conservator
`3 Other.
`El Other:
`
`Signer is Representing: Signer Is Representing:
`
`
`@2016 National Notary Association www.NationalNotary.org- 1 800US NOTARY (1——800——876—6827)
`item #5907
`
`Apple Inc.
`EX. 1013 - Page 4
`
`Apple Inc.
`Ex. 1013 - Page 4
`
`

`

`Network Working Group M. Borella
`Request for Comments: 3103 D. Grabelsky
`Category: Experimental CommWorks
` J. Lo
` Candlestick Networks
` K. Taniguchi
` NEC USA
` October 2001
`
` Realm Specific IP: Protocol Specification
`
`Status of this Memo
`
` This memo defines an Experimental Protocol for the Internet
` community. It does not specify an Internet standard of any kind.
` Discussion and suggestions for improvement are requested.
` Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2001). All Rights Reserved.
`
`IESG Note
`
` The IESG notes that the set of documents describing the RSIP
` technology imply significant host and gateway changes for a complete
` implementation. In addition, the floating of port numbers can cause
` problems for some applications, preventing an RSIP-enabled host from
` interoperating transparently with existing applications in some cases
` (e.g., IPsec). Finally, there may be significant operational
` complexities associated with using RSIP. Some of these and other
` complications are outlined in section 6 of the RFC 3102, as well as
` in the Appendices of RFC 3104. Accordingly, the costs and benefits
` of using RSIP should be carefully weighed against other means of
` relieving address shortage.
`
`Abstract
`
` This document presents a protocol with which to implement Realm
` Specific IP (RSIP). The protocol defined herein allows negotiation
` of resources between an RSIP host and gateway, so that the host can
` lease some of the gateway’s addressing parameters in order to
` establish a global network presence. This protocol is designed to
` operate on the application layer and to use its own TCP or UDP port.
` In particular, the protocol allows a gateway to allocate addressing
` and control parameters to a host such that a flow policy can be
` enforced at the gateway.
`
`Borella, et al. Experimental [Page 1]
`
`Apple Inc.
`Ex. 1013 - Page 5
`
`

`

`
`RFC 3103 RSIP Protocol Specification October 2001
`
`Table of Contents
`
` 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
` 2. Specification of Requirements . . . . . . . . . . . . . . . . 4
` 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
` 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
` 5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 7
` 6. Host / Gateway Relationships . . . . . . . . . . . . . . . . 7
` 7. Gateway Flow Policy and State . . . . . . . . . . . . . . . . 8
` 7.1. Local Flow Policy . . . . . . . . . . . . . . . . . . . . . 9
` 7.2. Remote Flow Policy . . . . . . . . . . . . . . . . . . . . 9
` 7.3. Gateway State . . . . . . . . . . . . . . . . . . . . . . . 10
` 8. Parameter Specification and Formats . . . . . . . . . . . . . 11
` 8.1. Address . . . . . . . . . . . . . . . . . . . . . . . . . . 11
` 8.2. Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
` 8.3. Lease Time . . . . . . . . . . . . . . . . . . . . . . . . 13
` 8.4. Client ID . . . . . . . . . . . . . . . . . . . . . . . . . 13
` 8.5. Bind ID . . . . . . . . . . . . . . . . . . . . . . . . . . 13
` 8.6. Tunnel Type . . . . . . . . . . . . . . . . . . . . . . . . 14
` 8.7. RSIP Method . . . . . . . . . . . . . . . . . . . . . . . . 14
` 8.8. 8.8. Error . . . . . . . . . . . . . . . . . . . . . . . . 14
` 8.9. Flow Policy . . . . . . . . . . . . . . . . . . . . . . . . 15
` 8.10. Indicator . . . . . . . . . . . . . . . . . . . . . . . . 15
` 8.11. Message Counter . . . . . . . . . . . . . . . . . . . . . 16
` 8.12. Vendor Specific Parameter . . . . . . . . . . . . . . . . 16
` 9. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 16
` 9.1. ERROR_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 17
` 9.2. REGISTER_REQUEST . . . . . . . . . . . . . . . . . . . . . 18
` 9.3. REGISTER_RESPONSE . . . . . . . . . . . . . . . . . . . . . 19
` 9.4. DE-REGISTER_REQUEST . . . . . . . . . . . . . . . . . . . . 19
` 9.5. DE-REGISTER_RESPONSE . . . . . . . . . . . . . . . . . . . 20
` 9.6. ASSIGN_REQUEST_RSA-IP . . . . . . . . . . . . . . . . . . . 21
` 9.7. ASSIGN_RESPONSE_RSA-IP . . . . . . . . . . . . . . . . . . 22
` 9.8. ASSIGN_REQUEST_RSAP-IP . . . . . . . . . . . . . . . . . . 23
` 9.9. ASSIGN_RESPONSE_RSAP-IP . . . . . . . . . . . . . . . . . . 26
` 9.10. EXTEND_REQUEST . . . . . . . . . . . . . . . . . . . . . . 27
` 9.11. EXTEND_RESPONSE . . . . . . . . . . . . . . . . . . . . . 28
` 9.12. FREE_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 28
` 9.13. FREE_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 29
` 9.14. QUERY_REQUEST . . . . . . . . . . . . . . . . . . . . . . 30
` 9.15. QUERY_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 31
` 9.16. LISTEN_REQUEST . . . . . . . . . . . . . . . . . . . . . . 32
` 9.17. LISTEN_RESPONSE . . . . . . . . . . . . . . . . . . . . . 35
` 10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 36
` 10.1. Use of Message Counters . . . . . . . . . . . . . . . . . 36
` 10.2. RSIP Host and Gateway Failure Scenarios . . . . . . . . . 37
` 10.3. General Gateway Policy . . . . . . . . . . . . . . . . . . 38
` 10.4. Errors Not From the RSIP Protocol . . . . . . . . . . . . 39
`
`Borella, et al. Experimental [Page 2]
`
`Apple Inc.
`Ex. 1013 - Page 6
`
`

`

`
`RFC 3103 RSIP Protocol Specification October 2001
`
` 10.5. Address and Port Requests and Allocation . . . . . . . . . 40
` 10.6. Local Gateways and Flow Policy Interaction . . . . . . . . 40
` 11. Security Considerations . . . . . . . . . . . . . . . . . . 40
` 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41
` 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
` 14. Appendix A: RSIP Error Numbers . . . . . . . . . . . . . . . 42
` 15. Appendix B: Message Types . . . . . . . . . . . . . . . . . 44
` 16. Appendix C: Example RSIP host/gateway transactions . . . . . 45
` 17. Appendix D: Example RSIP host state diagram . . . . . . . . 50
` 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
` 19. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . 53
` 20. Full Copyright Statement . . . . . . . . . . . . . . . . . . 54
`
`1. Introduction
`
` Network Address Translation (NAT) has gained popularity as a method
` of separating public and private address spaces, and alleviating
` network address shortages. A NAT translates the addresses of packets
` leaving a first routing realm to an address from a second routing
` realm, and performs the reverse function for packets entering the
` first routing realm from the second routing realm. This translation
` is performed transparently to the hosts in either space, and may
` include modification of TCP/UDP port numbers and IP addresses in
` packets that traverse the NAT.
`
` While a NAT does not require hosts to be aware of the translation, it
` will require an application layer gateway (ALG) for any protocol that
` transmits IP addresses or port numbers in packet payloads (such as
` FTP). Additionally, a NAT will not work with protocols that require
` IP addresses and ports to remain unmodified between the source and
` destination hosts, or protocols that prevent such modifications from
` occurring (such as some IPsec modes, or application-layer end-to-end
` encryption).
`
` An alternative to a NAT is an architecture that allows the hosts
` within the first (e.g., private) routing realm to directly use
` addresses and other routing parameters from the second (e.g., public)
` routing realm. Thus, RSIP [RSIP-FRAME] has been defined as a method
` for address sharing that exhibits more transparency than NAT. In
` particular, RSIP requires that an RSIP gateway (a router or gateway
` between the two realms) assign at least one address from the second
` routing realm, and perhaps some other resources, to each RSIP host.
` An RSIP host is a host in the first routing realm that needs to
` establish end-to-end connectivity to a host, entity or device in the
` second routing realm. Thus, the second routing realm is not directly
`
`Borella, et al. Experimental [Page 3]
`
`Apple Inc.
`Ex. 1013 - Page 7
`
`

`

`
`RFC 3103 RSIP Protocol Specification October 2001
`
` accessible from the RSIP host, but this system allows packets to
` maintain their integrity from the RSIP host to their destination.
` ALGs are not required in the RSIP gateway.
`
` RSIP requires that hosts be modified so that they place some number
` of layer three, layer four or other values from those assigned by the
` RSIP gateway in each packet bound for the second routing realm.
`
` This document discusses a method for assigning parameters to an RSIP
` host from an RSIP gateway. The requirements, scope, and
` applicability of RSIP, as well as its interaction with other layer 3
` protocols, are discussed in a companion framework document [RSIP-
` FRAME]. Extensions to this protocol that enable end-to-end IPsec are
` discussed in [RSIP-IPSEC].
`
`2. Specification of Requirements
`
` The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
` "SHALL", "SHALL NOT", "MAY" and "MAY NOT" that appear in this
` document are to be interpreted as described in [RFC2119].
`
`3. Terminology
`
` Private Realm
`
` A routing realm that uses private IP addresses from the ranges
` (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified in
` [RFC1918], or addresses that are non-routable from the Internet.
`
` Public Realm
`
` A routing realm with unique network addresses assigned by the
` Internet Assigned Number Authority (IANA) or an equivalent address
` registry.
`
` RSIP Host
`
` A host within the private realm that acquires publicly unique
` parameters from an RSIP gateway through the use of the RSIP
` client/server protocol.
`
` RSIP Gateway
`
` A router situated on the boundary between a private realm and a
` public realm and owns one or more public IP addresses. An RSIP
` gateway is responsible for public parameter management and
` assignment to RSIP hosts. An RSIP gateway may act as a NAT router
` for hosts within the private realm that are not RSIP enabled.
`
`Borella, et al. Experimental [Page 4]
`
`Apple Inc.
`Ex. 1013 - Page 8
`
`

`

`
`RFC 3103 RSIP Protocol Specification October 2001
`
` RSIP Client
`
` An application program that performs the client portion of the
` RSIP client/server protocol. An RSIP client application MUST
` exist on all RSIP hosts, and MAY exist on RSIP gateways.
`
` RSIP Server
`
` An application program that performs the server portion of the
` RSIP client/server protocol. An RSIP server application MUST
` exist on all RSIP gateways.
`
` RSA-IP: Realm Specific Address IP
`
` An RSIP method in which each RSIP host is allocated a unique IP
` address from the public realm. Discussed in detail in [RSIP-
` FRAME]
`
` RSAP-IP: Realm Specific Address and Port IP
`
` An RSIP method in which each RSIP host is allocated an IP address
` (possibly shared with other RSIP hosts) and some number of per-
` address unique ports from the public realm. Discussed in detail
` in [RSIP-FRAME]
`
` Binding
`
` An association of some combination of a local address, one or more
` local ports, a remote address, and a remote port with an RSIP
` host.
`
` Resource
`
` A general way to refer to an item that an RSIP host leases from an
` RSIP gateway; e.g., an address or port.
`
` All other terminology found in this document is consistent with that
` of [RFC2663] and [RSIP-FRAME].
`
`4. Architecture
`
` For simplicity, in the remainder of this document we will assume that
` the RSIP hosts in the first routing realm (network) use private
` (e.g., see [RFC1918]) IP addresses, and that the second routing realm
` (network) uses public IP addresses. (This assumption is made without
` loss of generality and the ensuing discussion applies to more general
`
`Borella, et al. Experimental [Page 5]
`
`Apple Inc.
`Ex. 1013 - Page 9
`
`

`

`
`RFC 3103 RSIP Protocol Specification October 2001
`
` cases.) The RSIP gateway connects the public and private realms and
` contains interfaces to both. Other NAT terminology found in this
` document is defined in [RFC2663].
`
` The diagram below describes an exemplary reference architecture for
` RSIP.
`
` RSIP Host RSIP Gateway Host
`
` Xa Na Nb Yb
` [X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
` ( Network ) ( Network )
`
` Hosts X and Y belong to different addressing realms A and B,
` respectively, and N is an RSIP gateway (which may also perform NAT
` functions). N has two interfaces: Na on address space A, and Nb on
` address space B. N may have a pool of addresses in address space B
` which it can assign to or lend to X and other hosts in address space
`
` A. These addresses are not shown above, but they can be denoted as
` Nb1, Nb2, Nb3 and so on.
`
` Host X, needing to establish an end-to-end connection to a network
` entity Y situated within address space B, first negotiates and
` obtains assignment of the resources from the RSIP gateway. Upon
` assignment of these parameters, the RSIP gateway creates a mapping,
` of X’s addressing information and the assigned resources. This
` binding enables the RSIP gateway to correctly de-multiplex and
` forward inbound traffic generated by Y for X. A lease time is
` associated with each bind.
`
` Using the public parameters assigned by the RSIP gateway, RSIP hosts
` tunnel data packets across address space A to the RSIP gateway. The
` RSIP gateway acts as the end point of such tunnels, stripping off the
` outer headers and routing the inner packets onto the public realm.
` As mentioned above, an RSIP gateway maintains a mapping of the
` assigned public parameters as demultiplexing fields for uniquely
` mapping them to RSIP host private addresses. When a packet from the
` public realm arrives at the RSIP gateway and it matches a given set
` of demultiplexing fields, then the RSIP gateway will tunnel it to the
` appropriate RSIP host. The tunnel headers of outbound packets from X
` to Y, given that X has been assigned Nb, are as follows:
`
` +---------+---------+---------+
` | X -> Na | Nb -> Y | payload |
` +---------+---------+---------+
`
`Borella, et al. Experimental [Page 6]
`
`Apple Inc.
`Ex. 1013 - Page 10
`
`

`

`
`RFC 3103 RSIP Protocol Specification October 2001
`
` There are two basic flavors of RSIP: RSA-IP and RSAP-IP. RSIP hosts
` and gateways MUST support RSAP-IP and MAY support RSA-IP. Details of
` RSA-IP and RSAP-IP are found in [RSIP-FRAME].
`
`5. Transport Protocol
`
` RSIP is an application layer protocol that requires the use of a
` transport layer protocol for end-to-end delivery of packets.
`
` RSIP gateways MUST support TCP, and SHOULD support UDP. Due to the
` fact that RSIP may be deployed across a wide variety of network
` links, RSIP hosts SHOULD support TCP, because of TCP’s robustness
` across said variety of links. However, RSIP hosts MAY support UDP
` instead of TCP, or both UDP and TCP.
`
` For RSIP hosts and gateways using UDP, timeout and retransmissions
` MUST occur. We recommend a binary exponential backoff scheme with an
` initial duration of 12.5 ms, and a maximum of six retries (seven
` total attempts before failure). However, these parameters MAY be
` adjusted or tuned for specific link types or scenarios.
`
` Once a host and gateway have established a registration using either
` TCP or UDP, they may not switch between the two protocols for the
` duration of the registration. The decision of whether to use TCP or
` UDP is made by the client, and is determined by the transport
` protocol of the first packet sent by a client in a successful
` registration procedure.
`
`6. Host / Gateway Relationships
`
` An RSIP host can be in exactly one of three fundamental relationships
` with respect to an RSIP gateway:
`
` Unregistered: The RSIP gateway does not know of the RSIP host’s
` existence, and it will not forward or deliver globally addressed
` packets on behalf of the host. The only valid RSIP-related action
` for an RSIP host to perform in this state is to request
` registration with an RSIP gateway.
`
` Registered: The RSIP gateway knows of the RSIP host and has assigned
` it a client ID and has specified the flow policies that it
` requires of the host. However, no resources, such as addresses or
` ports, have been allocated to the host, and the gateway will not
` forward or deliver globally addressed packets on behalf of the
` host. All registrations have an associated lease time. If this
` lease time expires, the RSIP host automatically reverts to the
` unregistered state.
`
`Borella, et al. Experimental [Page 7]
`
`Apple Inc.
`Ex. 1013 - Page 11
`
`

`

`
`RFC 3103 RSIP Protocol Specification October 2001
`
` Assigned: The RSIP gateway has granted one or more bindings of
` resources to the host. The gateway will forward and deliver
` globally addressed packets on behalf of the host. Each binding
` has an associated lease time. If this lease time expires, the
` binding is automatically revoked.
`
` Architectures in which an RSIP host is simultaneously registered with
` more than one RSIP gateway are possible. In such cases, an RSIP host
` may be in different relationships with different RSIP gateways at the
` same time.
`
` An RSIP gateway MAY redirect an RSIP host to use a tunnel endpoint
` for data traffic that is not the RSIP gateway itself, or perhaps is a
` different interface on the RSIP gateway. This is done by specifying
` the tunnel endpoint’s address as part of an assignment. In such an
` architecture, it is desirable (though not necessary) for the RSIP
` gateway to have a method with which to notify the tunnel endpoint of
` assignments, and the expiration status of these assignments.
`
` Lease times for bindings and registrations are managed as follows.
` All lease times are given in units of seconds from the current time,
` indicating a time in the future at which the lease will expire.
` These expiration times are used in the ensuing discussion.
`
` An initial expiration time (R) is given to a registration. Under
` this registration, multiple bindings may be established, each with
` their own expiration times (B1, B2, ...). When each binding is
` established or extended, the registration expiration time is adjusted
` so that the registration will last at least as long as the longest
` lease. In other words, when binding Bi is established or extended,
` the following calculation is performed: R = max(R, Bi).
`
` Under this scheme, a registration will never expire while any
` binding’s lease is still valid. However, a registration may expire
` when the last binding’s lease expires, or at some point thereafter.
`
`7. Gateway Flow Policy and State
`
` Since an RSIP gateway is likely to reside on the boundary between two
` or more different administrative domains, it is desirable to enable
` an RSIP gateway to be able to enforce flow-based policy. In other
` words, an RSIP gateway should have the ability to explicitly control
` which local addresses and ports are used to communicate with remote
` addresses and ports.
`
` In the following, macro-flow policy refers to controlling flow policy
` at the granularity level of IP addresses, while micro-flow policy
` refers to controlling flow policy at the granularity of IP address
`
`Borella, et al. Experimental [Page 8]
`
`Apple Inc.
`Ex. 1013 - Page 12
`
`

`

`
`RFC 3103 RSIP Protocol Specification October 2001
`
` and port tuples. Of course there may be no policy at all, which
` indicates that the RSIP gateway does not care about the flow
` parameters used by RSIP hosts. We consider two levels of local flow
` policy and three levels of remote flow policy.
`
`7.1. Local Flow Policy
`
` Local flow policy determines the granularity of control that an RSIP
` gateway has over the local addressing parameters that an RSIP host
` uses for particular sessions.
`
` Since an RSIP host must use at least an IP address allocated by the
` gateway, the loosest level of local flow policy is macro-flow based.
` Under local macro-flow policy, an RSIP host is allocated an IP
` address (RSA-IP) or an IP address and one or more ports to use with
` it (RSAP-IP). However, the host may use the ports as it desires for
` establishing sessions with public hosts.
`
` Under micro-flow policy, a host is allocated exactly one port at a
` time. The host may request more ports, also one at a time. This
` policy gives the gateway very tight control over local port use,
` although it affords the host less flexibility.
`
` Note that only local macro-flow policy can be used with RSA-IP, while
` either local macro-flow or local micro-flow policy may be used with
` RSAP-IP.
`
` Examples of how RSIP flow policy operates are given in Appendix C.
`
`7.2. Remote Flow Policy
`
` Remote flow policy determines the granularity of control that an RSIP
` gateway has over the remote (public) hosts with which an RSIP host
` communicates. In particular, remote flow policy dictates what level
` of detail that a host must specify addressing parameters of a remote
` host or application before the RSIP gateway allows the host to
` communicate with that host or application.
`
` The simplest and loosest form of flow policy is no policy at all. In
` other words, the RSIP gateway allocates addressing parameters to the
` host, and the host may use these parameters to communicate with any
` remote host, without explicitly notifying the gateway.
`
` Macro-flow policy requires that the host identify the remote address
` of the host that it wishes to communicate with as part of its request
` for local addressing parameters. If the request is granted, the host
` MUST use the specified local parameters only with the remote address
` specified, and MUST NOT communicate with the remote address using any
`
`Borella, et al. Experimental [Page 9]
`
`Apple Inc.
`Ex. 1013 - Page 13
`
`

`

`
`RFC 3103 RSIP Protocol Specification October 2001
`
` local parameters but the ones allocated. However, the host may
` contact any port number at the remote host without explicitly
` notifying the gateway.
`
` Micro-flow policy requires that the host identify the remote address
` and port of the host that it wishes to communicate with as part of
` its request for local addressing parameters. If the request is
` granted, the host MUST use the specified local parameters only with
` the remote address and port specified, and MUST NOT communicate with
` the remote address and port using any local parameters but the ones
` allocated.
`
` Remote flow policy is implemented in both the ingress and egress
` directions, with respect to the location of the RSIP gateway.
`
`7.3. Gateway State
`
` An RSIP gateway must maintain state for all RSIP hosts and their
` assigned resources. The amount and type of state maintained depends
` on the local and remote flow policy. The required RSIP gateway state
` will vary based on the RSIP method, but will always include the
` chosen method’s demultiplexing parameters.
`
`7.3.1. RSA-IP State
`
` An RSIP gateway serving an RSIP host using the RSA-IP method MUST
` maintain the following minimum state to ensure proper mapping of
` incoming packets to RSIP hosts:
`
` - Host’s private address
` - Host’s assigned public address(es)
`
`7.3.2. RSAP-IP State
`
` An RSIP gateway serving an RSIP host using the RSAP-IP method MUST
` maintain the following minimum state to ensure proper mapping of
` incoming packets to RSIP hosts:
`
` - Host’s private address
` - Host’s assigned public address(es)
` - Host’s assigned port(s) per address
`
`7.3.3. Flow State
`
` Regardless of whether the gateway is using RSA-IP or RSAP-IP,
` additional state is necessary if either micro-flow based or macro-
` flow based remote policy is used.
`
`Borella, et al. Experimental [Page 10]
`
`Apple Inc.
`Ex. 1013 - Page 14
`
`

`

`
`RFC 3103 RSIP Protocol Specification October 2001
`
` If the gateway is using macro-flow based remote policy, the following
` state must be maintained:
`
` - Remote host’s address
`
` If the gateway is using micro-flow based remote policy, the following
` state must be maintained:
`
` - Remote host’s address
` - Remote host’s port
`
` More state MAY be used by an RSIP gateway if desired. For example,
` ToS/DS bytes may be recorded in order to facilitate quality of
` service support.
`
`8. Parameter Specification and Formats
`
` In this section we define the formats for RSIP parameters. Each RSIP
` message contains one or more parameters that encode the information
` passed between the host and gateway. The general format of all
` parameters is TLV (type-length-value) consisting of a 1-byte type
` followed by a 2-byte length followed by a ’length’ byte value as
` shown below.
`
` 0 1 2 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Type |