cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services

Transcription

1 GPP X.S00-00-D Version:.0 Version Date: November 00 cdma000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services COPYRIGHT GPP and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the GPP Secretariat at Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See for more information.

2 X.S00-00-D vv Content GLOSSARY AND DEFINITIONS... REFERENCES... SIMPLE IP OPERATION.... COMMON SERVICE SPECIFICATION..... PPP SESSION.... PDSN REQUIREMENTS..... PPP SESSION..... RADIUS SUPPORT..... INGRESS ADDRESS FILTERING.... RADIUS SERVER REQUIREMENTS.... MS REQUIREMENTS..... PPP SESSION... MIP OPERATION.... COMMON SERVICE SPECIFICATION..... PPP SESSION..... MIP..... DYNAMIC HOME AGENT AND HOME ADDRESS ASSIGNMENT..... GRE CVSE.... PDSN REQUIREMENTS..... PPP SESSION..... MIP REGISTRATION..... RADIUS SUPPORT..... IP SECURITY SUPPORT..... INGRESS ADDRESS FILTERING..... PDSN REQUIREMENTS FOR GRE TUNNELING SUPPORT HOME AGENT REQUIREMENTS MULTIPLE REGISTRATIONS MIP AUTHENTICATION SUPPORT IPSEC SUPPORT..... DYNAMIC HOME AGENT ASSIGNMENT..... DNS ADDRESS ASSIGNMENT..... HA REQUIREMENTS FOR GRE TUNNELING SUPPORT.... RADIUS SERVER REQUIREMENTS..... DYNAMIC HOME AGENT ASSIGNMENT..... MN-HA SHARED KEY DISTRIBUTION..... IKE PRE-SHARED SECRET DISTRIBUTION PROCEDURE..... DNS ADDRESS ASSIGNMENT.... MS REQUIREMENTS..... PPP SESSION..... MIP REGISTRATION..... MS REQUIREMENTS FOR GRE TUNNELING SUPPORT.... DNS SERVER IP ADDRESS NVSE... MIP OPERATION.... COMMON SERVICE SPECIFICATION..... PPP SESSION..... MIP..... SUMMARY OF PDSN AND MS BEHAVIOR FOR DYNAMIC HA/HL/HOA DISCOVERY VIA MIP BOOTSTRAPPING... i

3 X.S00-00-D vv MOBILE STATION TO HOME AGENT SECURITY FOR BU AND BA.... PDSN REQUIREMENTS..... PDSN REQUIREMENT TO SUPPORT STATELESS DHCPV TO CONVEY MIP BOOTSTRAP INFO..... INGRESS ADDRESS FILTERING HOME AGENT REQUIREMENTS HOME AGENT REQUIREMENTS TO SUPPORT DYNAMIC HOME AGENT ASSIGNMENT..... HOME AGENT REQUIREMENTS TO SUPPORT DYNAMIC HOME ADDRESS CONFIGURATION..... MULTIPLE REGISTRATIONS..... HOME REGISTRATION SUPPORT..... RETURN ROUTABILITY SUPPORT FOR ROUTE OPTIMIZATION..... HA REQUIREMENT AS A RADIUS CLIENT.... RADIUS SERVER REQUIREMENTS..... RADIUS SUPPORT FOR SESSION KEY GENERATION AND DISTRIBUTION TO THE HA..... RADIUS SUPPORT FOR MIP BOOTSTRAP.... MS REQUIREMENTS..... PPP SESSION..... MS REQUIREMENT TO SUPPORT STATELESS DHCPV TO OBTAIN MIP BOOTSTRAP INFO..... MULTIPLE REGISTRATIONS..... MIP HOME REGISTRATION..... TERMINATION.... ACCOUNTING CONSIDERATION..... PDSN REQUIREMENTS..... HA REQUIREMENTS... SIMULTANEOUS SERVICES... IP REACHABILITY SERVICE.... SIMPLE IPV OPERATION.... MIP OPERATION DNS UPDATE BY THE HOME RADIUS SERVER DNS UPDATE BY THE HA SIMPLE IPV OPERATION.... MOBILEIPV OPERATION... MS-PDSN VERSION CAPABILITY INDICATION.... PDSN REQUIREMENTS.... MS REQUIREMENTS... GPP VENDOR SPECIFIC REJECT PACKET... 0 HOT-LINING HOT-LINING CAPABILITIES HOT-LINING ARCHITECTURE OPERATIONS NEW-SESSION HOT-LINING PROCEDURE ACTIVE SESSION HOT-LINING PROCEDURE LIMITING THE HOT-LINING DURATION HOT-LINING REQUIREMENTS REQUIREMENTS FOR HOT-LINE CAPABLE PDSN AND HA MS REQUIREMENTS RADIUS SERVER... ii

4 X.S00-00-D vv.0 ANNEX A (NORMATIVE): IKE/ISAKMP PAYLOADS... ANNEX B (NORMATIVE): CERTIFICATES... 0 ANNEX C (NORMATIVE): PDSN TIMERS... 0 iii

5 X.S00-00-D vv.0 List of Figures 0 0 FIGURE MS PARAMETERS CONFIGURATION WITH DHCP... FIGURE CONFIGURATION OF MS S PARAMETERS USING DHCPV... FIGURE - MAX PPP INACTIVITY TIMER PACKET... FIGURE - GRE KEY CVSE... FIGURE - GRE HEADER FOR TUNNELING DATAGRAMS... FIGURE - NVSE FOR DNS SERVER IP ADDRESS... FIGURE - THE INITIAL MIP HOME REGISTRATION WITH MN-AAA MOBILITY MESSAGE AUTHENTICATION OPTION... FIGURE - MIPV HOME REGISTRATION WITH MN-HA MOBILITY MESSAGE AUTHENTICATION OPTION... FIGURE - FLOW DIAGRAM FOR DYNAMIC HOME AGENT ASSIGNMENT (HA AND HL IS ASSIGNED BY HAAA)... FIGURE 0 - FLOW DIAGRAM FOR DYNAMIC HOME AGENT ASSIGNMENT (VAAA ASSIGNS HA AND HL)... FIGURE 0 - BOOTSTRAP OF HOME LINK PREFIX... FIGURE - HOME ADDRESS AUTO-CONFIGURATION... FIGURE - DERIVATION AND DISTRIBUTION OF IK AND MN-HA SPI DURING HOME REGISTRATION... FIGURE - ACCOUNTING PROCEDURES FOR MIP... FIGURE - VERSION/CAPABILITY PACKET FORMAT... FIGURE - REJECT PACKET FORMAT... FIGURE - HOT-LINING ARCHITECTURE... FIGURE - NEW SESSION HOT-LINING CALL FLOW... FIGURE - ACTIVE SESSION HOT-LINE PROCEDURE... iv

6 X.S00-00-D vv.0 0 List of Tables TABLE - OCCURRENCE OF RADIUS ATTRIBUTES FOR SIMPLE IP... TABLE - HOME AGENT AND HOME ADDRESS SCENARIOS... TABLE - DESCRIPTION OF SCENARIOS... TABLE - OCCURRENCE OF RADIUS ATTRIBUTES FOR MIP... TABLE - MS REGISTRATION SCENARIOS... TABLE - MIP BOOTSTRAPPING SCENARIOS... TABLE - MIP RADIUS ATTRIBUTES... TABLE - LIST OF MS CAPABILITIES... TABLE - LIST OF PDSN CAPABILITIES... v

7 X.S00-00-D vv.0 General Description This chapter describes the basic IP access services: Simple IPv/IPv, MIP and MIP with Home Agent(HA) and/or Dynamic Home IP address Assignment. It also addresses the security requirements between the Wireless IP Network nodes: PDSN, HA and RADIUS servers. The chapter includes other capabilities such as Always On, multiple simultaneous MIP/MIP and Simple IPv/IPv packet data sessions, IP Reachability Service, DHCP Support, and Hot-Lining.

8 X.S00-00-D vv.0 Glossary and Definitions See [Chapter ].

9 X.S00-00-D vv.0 References See [Chapter ].

10 X.S00-00-D vv Simple IP Operation This section describes the requirements and procedures for Simple IP operation for both IPv [RFC ] and IPv [RFC 0]. In this document, Simple IP refers to a service in which an MS is assigned an IP address and is provided IP routing service by an access provider network. The MS retains its IP address as long as a Radio Access Network (RAN) that has connectivity to the same Serving PDSN serves it. IP address mobility beyond the Serving PDSN and secure access to a home network are beyond the scope of this section.. Common Service Specification The common requirements for several network elements (e.g., PDSN and MS) for Simple IP operation are described here... PPP Session PPP shall be the data link protocol between the MS and the PDSN. The PPP session shall be established prior to any IP datagram being exchanged between the MS and the PDSN. Only one PPP session shall be supported between the MS and the PDSN. PPP shall be supported as defined in the following standards with any limitations or extensions described in this document. Point to Point Protocol [RFC ]; PPP in HDLC-like Framing [RFC ]; IPCP [RFC ] (for IPv); IPvCP [RFC ] (for IPv); CHAP [RFC ]; PAP [RFC ]. PPP encryption is not supported in this document.. PDSN Requirements The PDSN shall support Simple IP operation for both IPv and IPv... PPP Session... Establishment If the PDSN supports multiple service connections for a user, refer to [Chapter ] for details of PPP negotiation. Otherwise, when an A0 connection of SO type / is established the PDSN shall send an LCP Configure-Request for a new PPP session to the MS. PPP shall support transparency in accordance with Section. of [RFC ]. The PDSN shall not send an LCP Configure-Reject in response to an ACCM configuration option proposed by the MS in an LCP Configure-Request and shall attempt to negotiate a control character mapping with the minimum number of escaped characters by proposing an ACCM of 0x Termination The PDSN shall close the PPP session if there is no established A0 or P-P session for the MS. If the PPP session timer is used and has expired, or if Always On service is not enabled and the PPP inactivity timer for a PPP session expires, the PDSN shall close the PPP session. The PDSN may receive the Always On attribute with value from the Home RADIUS server in order

11 X.S00-00-D vv to activate the Always On service for a user. If the PDSN receives the Always On attribute with value, it shall send the indicator to the RAN as indicated in []. Upon receiving the Always On attribute with value from the Home RADIUS server the PDSN shall utilize the expiration of the PPP inactivity timer and the procedures described in Section...0 to determine if the PPP session should be closed. When the PDSN determines that the PPP session shall be closed, it shall determine if an LCP Terminate-Request should be sent to the MS. For an Always On session, the PDSN shall send an LCP Terminate-Request to the MS. The PDSN should also send LCP Terminate-Request to a non-always On session unless it has previously received the All Dormant Indicator NVSE. The PDSN shall clear the A0 and/or P-P session whenever the associated PPP session is closed. If the PDSN receives IP packet(s) for an MS for which there is no established PPP session, the PDSN shall silently discard the packet(s). The PDSN shall close the A0 and associated P-P session if it receives an LCP Terminate-Request message from the MS.... PPP Session Authentication The PDSN shall support the two authentication mechanisms: CHAP and PAP. The PDSN shall also support a configuration option to allow an MS to receive Simple IP service without CHAP or PAP. The PDSN shall propose CHAP in an initial LCP Configure-Request message that the PDSN sends to the MS during the PPP establishment. If the PDSN receives an LCP Configure- NAK from the MS containing PAP, the PDSN shall accept PAP by sending an LCP Configure- Request message with PAP. If the PDSN receives an LCP Configure-Reject containing the Authentication-Protocol option and the PDSN is configured to allow the MS to receive Simple IP service without CHAP or PAP, the PDSN shall respond with an LCP Configure-Request without the Authentication-Protocol option and shall adhere to the guidelines in Section... for NAI construction for accounting purposes.... Addressing with IPCP... IPv Addressing For IPv, the PDSN shall assign the MS an IP address for Simple IP service when presented with a zero or non-zero IP address in the IP Address Configuration option, during the IPCP phase of PPP. The IP address may be a private address as per [RFC ]. If the MS requests a non-zero IP address during the IPCP phase, the PDSN shall send an IPCP Configure-Nak in response to the request in order to propose a different IP address. If the MS responds with an IPCP Configure-Request containing an IP address different from the one proposed by the PDSN, the PDSN shall re-transmit one time the IPCP Configure-Request containing the new IP address, and shall send an LCP Terminate- Request if the MS fails to accept the assigned IP address. During IPCP phase, the PDSN shall include the IP Address Configuration option containing its IP address in the IPCP Configure-Request messages sent to the MS. The PDSN shall implement IPCP configuration options as defined in [RFC ] for the DNS server address negotiation. The PDSN shall negotiate Primary and Secondary DNS server IP addresses with the MS if the DNS Server Configuration options are received during the IPCP phase. If the PDSN supports DNS server IP address VSA, it shall determine if the M bit is set in the DNS Server IP Address VSA received in the RADIUS Access-Accept message. The PDSN shall select DNS Server IP Address VSA, with the M bit set, for DNS information. If PDSN receives a RADIUS Access-Accept message from the Visited RADIUS server that has DNS IP address VSA(s) with the following values included, then the PDSN shall apply local policies to select the DNS IP Address VSA for DNS information. A DNS IP Address VSA with the Entity-Type subfield set to the value (=HAAA) and the M bit unset, and/or One or more DNS IP Address VSA(s) with the Entity-Type subfield set to the value (=VAAA).

12 X.S00-00-D vv IPv Addressing If the MS-PDSN Version Capability Indication (see section ) is used, and the MS signaled that it does not support Simple IPv (C bit set to 0), then the PDSN shall not negotiate IPvCP with the MS and shall not send IPv Router Advertisements to the MS. If the MS-PDSN Version Feature Indication is used, and the MS signaled that it supports Simple IPv (C bit set to ), then the PDSN shall provide Simple IPv service to the MS as described in the rest of this section. For an IPv MS, the PDSN shall be the default router and the PPP termination point. The PDSN shall allocate one globally unique / prefix to each PPP link. The PDSN shall not construct any global address from this prefix. The PDSN shall support the following RFCs, with exceptions as noted in this document: An IPv Aggregatable Global Unicast Address Format [RFC ]; Internet Protocol, Version (IPv) Specification [RFC 0]; Neighbor Discovery for IP Version (IPv) [RFC ]; IPv Stateless Address Auto-configuration [RFC ]; Internet Control Message Protocol (ICMPv) for the Internet Protocol Version (IPv) Specification [RFC ]; IP Version over PPP [RFC ]; IP Version Addressing Architecture [RFC ]. The PDSN shall perform Interface-identifier negotiation as described in [RFC ]. Interfaceidentifiers used by the PDSN and the MS are configured via IPvCP. The PDSN shall provide to the MS a valid non-zero Interface-Identifier of the PDSN in the IPvCP Config Request. The PDSN shall provide a valid non-zero Interface-Identifier for the MS in IPvCP Config NAK if the MS s proposed IID is not acceptable to the PDSN during its negotiation of the Interface-identifier. The PDSN shall not have more than one Interface Identifier associated with the PPP connection, i.e., the PDSN shall only use the Interface Identifier negotiated during the IPvCP phase with the MS. While communicating with the MS, the PDSN shall use only the link local address that it constructed with its Interface-Identifier that it provided to the MS (i.e. PDSN s interface-identifier) during IPvCP phase. Because the Interface-Identifier is negotiated in the IPvCP phase of the PPP connection setup is unique for the PPP connection, it is not required to perform duplicate address detection for the link local address formed as part of IPv stateless address autoconfiguration [RFC ]. Following successful IPvCP negotiation and the establishment of a unique link-local address forboth the PDSN and the MS, the PDSN shall immediatelyf transmit initial unsolicited Router Advertisement (RA) messages on the PPP link using its link-local address as a source address. The PDSN shall include a globally unique / prefix in the Router Advertisement message to the MS. The MS shall uses this prefix to configure its global IPv addresses. The PDSN shall send unsolicited Router Advertisement (RA) message for an operator configurable number of times. Also, the PDSN shall set the interval between initial RA messages This is an exception to [RFC ] necessary to optimize applicability over the cdma000 wireless air-interface.

13 X.S00-00-D vv to an operator configurable value, which may be less than MAX_INITIAL_RTR_ADVERT_INTERVAL. After the configurable number of initial unsolicited RA messages has been transmitted, the interval between the periodic transmissions of unsolicited RA messages shall be controlled by the router configurable parameters MaxRtrAdvInterval and MinRtrAdvInterval as defined in [RFC ]. The PDSN may set MaxRtrAdvInterval to a value greaterf than 00 seconds and less than / of the AdvDefaultLifetime. The PDSN shall set MinRtrAdvIntervalH to a fraction of MaxRtrAdvInterval as per [RFC ]. The PDSN shall send a RA message in response to a Router Solicitation (RS) message received from the MS. The PDSN may set the delay between consecutive (solicited RA) or (solicited /unsolicited RA) messages sent to the all-nodes multicast address to a value lessf than that specified by the constant MIN_DELAY_BETWEEN_RAS, contrary to the specification in sec... of [RFC ]. The advertised / prefixf identifies the subnet associated with the PPP link. The / prefix advertised by the PDSN shall be exclusive to the PPP session. The PDSN shall set: the M-flag = 0 in the RA message header; the L-flag = 0 and the A-flag = in the RA message Prefix Information Option. The PDSN shall set the Router Lifetime value in the Router Advertisement message to a value of - (. hrs). The PDSN shall not send any redirect messages to the MS over the PPP interface.... DHCPv Support The PDSN shall support DHCP Relay Agent function as specified in [RFC ] and [RFC 0]. If the PDSN includes the Relay Agent Information Option, it shall set the giaddr field to the Relay Agent s IP address, and include one of the following values in the Agent Remote ID Sub-option of the Relay Agent Information Option: User name = NAI of the user (DHCP client) used to setup the PPP/MIP session. The remote IP address of a point-to-point link = IPv address assigned to the MS via IPCP negotiation. The PDSN assigns IPv address to MS via IPCP IP address configuration option. However, if the MS acquires additional IPv addresses from a DHCP server using a PDSN as the relay agent, the PDSN shall store the additional IPv addresses. The PDSN shall create one or more new accounting UDRs depending on the number of service connections established for each of these additional IPv addresses. The PDSN shall relay the DHCP message received from the MS on port to the DHCP server(s) IP address(es) configured in the PDSN as specified in [RFC 0]. This may cause an exception to [RFC ] as it may put the interval outside the normal range. This exception is allowed by this document to optimize IPv RA over the cdma000 wireless links. This exception is allowed by this document to optimize IPv RA over the cdma000 wireless links. If the Access Service Provider desires to reduce frequent unsolicited RA for the prefix, it should set the -bit Valid Lifetime and Preferred Lifetime fields for the advertised / prefix in the RA message Prefix Information Option to a very high value (i.e., 0xFFFFFFFF to indicate prefix validity for the lifetime of the PPP session).

14 X.S00-00-D vv The PDSN shall include a DHCP Relay Agent Information option [RFC 0] when relaying the DHCP messages to the server and shall set the giaddr field to the relay agent IP address. The PDSN may support [RFC ] to indicate the link on which the DHCP client (i.e., MS) resides if different from the link from which the agent is communicating with the server. The PDSN shall identify the DHCP client based on the PPP connection over which the DHCP messages were received. The PDSN shall relay the DHCP messages received from the DHCP server(s) to the MS over PPP using the address specified in the ciaddr field. If the DHCP message received from the DHCP server is a DHCPAck message and contains a non zero value in yiaddr field, the PDSN shall store the assigned IPv address and the value in the IP address lease time option as part of the user state information and shall initiate a RADIUS Accounting-Request (start) message, which includes the assigned IPv address and the NAI used during Simple IP authentication. If the IP address lease time expires and the address has not been renewed or if the PDSN receives a DHCP release packet from the MS, the PDSN shall remove the binding created for that IPv address and shall send a RADIUS Accounting-Request (Stop). If the PPP session is closed, the PDSN shall send a RADIUS Accounting-Request (Stop) for all the IPv addresses that may have been assigned through DHCP in addition to the Accounting-Request (Stop) required for the initial IP address assigned through IPCP. The following figure shows a flow diagram where DHCP is used for MS configuration of other parameters (e.g., DNS, PCSCF, BCMCS Controller addresses) after it acquired an IP address via IPCP. MS PDSN DHCP AAA LCP (a) CHAP(b) Access-Request/Accept (c) IPCP negotiation (IP address) (d) Accouting-Request (start)/ Response (e) DHCP Inform (f) DHCPAck (i) DHCP Inform (g) DHCPAck (h) Figure MS Parameters configuration with DHCP a-d) The MS and the PDSN negotiate LCP and CHAP (or PAP). Following the LCP phase and successful authentication operation, the Simple IP MS shall include the IP configuration option in the IPCP configure-request to configure its simple IPv address. e) The PDSN creates a UDR for the IP address/nai pair and sends a RADIUS Accounting- Request (start) to the RADIUS server.

15 X.S00-00-D vv.0 0 f) If the MS wants to configure other parameters using DHCP, it sends a DHCPInform with the IP destination address set to the limited broadcast address (all s), assuming the MS does not know the DHCP server s IP address. g) The PDSN relays the DHCP packet to the DHCP server(s) as per [RFC 0]..h) The DHCP server(s) responds by sending a DHCPAck that contains the options desired by the MS, and may include additional options that are not specifically requested..i) The PDSN relays the DHCPAck message to the MS s IP address over the PPP link.... Stateless DHCPv Support The PDSN shall support DHCPv Relay Agent as specified in [RFC ] and [RFC ], and shall set the O bit to in the Router Advertisement messages sent to the MS. Upon receiving a DHCPv Information-Request packet from the MS, the PDSN shall set the peer-address field in the Relay Forward message to the source IPv address of the received DHCPv packet from the MS. The PDSN shall set the link address field to the global IPv address of the MS. Additionally the PDSN may include the Interface-id option carrying the Interface-ID that the MS negotiated during PPP setup. Upon receiving DHCPv Relay-reply message(s) from one or more DHCPv servers, the PDSN shall relay the message according to section 0. of [RFC ]. The following flow diagram shows an MS that uses stateless DHCPv for configuration of parameters (e.g., DNS configuration options as specified in [RFC ]). 0 Figure Configuration of MS s parameters using DHCPv a-d) The MS and the PDSN negotiate LCP and CHAP (or PAP). Following the LCP phase and successful authentication operation, the MS and the PDSN execute IPVCP and negotiate unique -bit Interface IDs. e) The PDSN sends a Router Advertisement with prefix information and sets the O-flag to one, to indicate to the MS that it can use DHCPv to configure other parameters than the IPv address.

16 X.S00-00-D vv f) The PDSN creates a UDR for the IPv prefix/interface ID/NAI and sends a RADIUS Accounting-Request (start) to the RADIUS server. g) The MS send an Information-Request message with the IP destination address set to the All_DHCPv_Relay_Agents_and_Servers multicast address defined in [RFC ] [FF0:::]. The source address is the link local address created by the MS. The MS shall include the Option Request option (ORO) to indicate which options the client is interested in receiving. h) The PDSN creates a Relay-forward message. The "Relay Message" option shall include the entire Information-Request message. The PDSN sends the message to the ALL_DHCPv_Servers address [FF0:::] or to the DHCPv server(s) that may be configured in the PDSN. i) The DHCPv server receives the Relay-forward and replies to the relay agent with a Relay-reply, which contains the REPLY message with all the options requested by the MS in the Option Request Option (ORO), and may include additional options. j) The PDSN extracts the Reply message and forwards it to the MS.... Dual Stack of IPv and IPv Requirements For dual IP stacks of IPv and IPv, the single CHAP/PAP authentication is performed. For dual IP stacks of IPv and IPv, the single CHAP/PAP authentication is performed. If the NCP transitions to the stopped state (either because the NCP failed to establish, or because the NCP was torn down gracefully) and the PDSN allows the establishment of that NCP at a later time upon the receipt of NCP configure request, the NCP shall remain in the stopped state until a configure request from the MS is received.... Compression The PDSN shall support the following header compression algorithm: Van Jacobson TCP/IP header compression [RFC ]. The PDSN may support the following header compression algorithms: ROHC, Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 0] with ROHC over PPP [RFC ]; ROHC: A Link Layer Assisted Profile for IP/UDP/RTP [RFC ]; IP Header Compression [RFC 0] with IP Header Compression over PPP [RFC 0]; Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile [RFC 0]; Compressing IP/UDP/RTP headers on links with high delay, packet loss and reordering [RFC ] with IP Header Compression over PPP [RFC ]. If the PDSN is able to process received compressed header packets from the MS using various header compression protocols, the PDSN shall include the appropriate configuration option(s) to the MS to indicate which IP Header Compression protocol it supports in the IPCP or IPvCP Configure-Request message as defined by [RFC ], [RFC ], [RFC 0], and [RFC ]. 0

17 X.S00-00-D vv The PDSN shall support CCP [RFC ] for the negotiation of PPP payload compression. The PDSN shall supportf the following algorithms of PPP payload compression: Stac-LZS [RFC ]; Microsoft Point-To-Point Compression Protocol [RFC ]; The PDSN may support other PPP payload compression algorithms.... PPP Framing The PDSN shall frame PPP packets sent on the PPP link layer using the octet synchronous framing protocol defined in [RFC ], except that there shall be no inter-frame time fill (see.. of [RFC ]). That is, no flag octets shall be sent between a flag octet that ends one PPP frame and the flag octet that begins the subsequent PPP frame. For IPv, the PDSN shall set the MTU size as specified in [RFC 0]....0 PPP Link Status Determination For Always On users, the PDSN shall support the GPP vendor specific Max PPP Inactivity Timer packet defined in PPP Vendor specific packet [RFC ] and the following configurable timer and counter: Echo-Reply-Timeout timer. Echo-Request-Retries counter. The MAX PPP Inactivity timer packets shall be sent as LCP packets with PPP Protocol ID set to C0(hex) If the MS-PDSN Version Feature Indication (see section ) is used, and the MS signaled that it does not support the Max PPP Inactivity Timer (C bit set to 0), then the PDSN shall not send the Max PPP Inactivity Timer to the MS. The format of the Max PPP Inactivity Timer packet is shown in Figure. The PDSN shall not send compressed PPP frames when Multiple Service Instances are connected.

18 X.S00-00-D vv Code Identifier Length Magic Number OUI Kind Max PPP Inactivity Timer 0 Code Identifier Length Magic Number OUI Kind MAX PPP Inactivity TimerValue Figure - Max PPP Inactivity Timer Packet Code = 0 (As defined in [RFC ]) Identifier = The Identifier field shall be changed for each Vendor Specific packet sent. It is used to match requests with responses. Length = (octets)>= (octets) Magic Number = OUI = Kind ( octet) = The Magic-Number field is four octets and aids in detecting links that are in the looped-back condition. Until the Magic-Number Configuration Option has been successfully negotiated, the Magic-Number shall be transmitted as zero. See the Magic-Number Configuration Option in [RFC ] for further explanation. 0xCF000, MAX PPP Inactivity Timer Packet, Max PPP Inactivity Timer Response Value ( octets) = If Kind =, -bit value = PPP inactivity time + Echo_Reply_Timeout timer (Echo_Request_Retries + ) If Kind =, the Value field is not included. Max PPP Inactivity Timer = -bit value = PPP inactivity time +

19 X.S00-00-D vv Echo_Reply_Timeout timer (Echo_Request_Retries + ) Upon entering the IPCP and/or IPvCP Opened state on a PPP session configured for Always On Service, the PDSN shall start the PPP inactivity timer for the PPP session, and unless the MS signaled that it does not support the Max PPP Inactivity Timer, the PDSN shall send the GPP vendor specific Max PPP Inactivity Timer packet [RFC ] over the main service connection. The PDSN should resend the Max PPP Inactivity Timer packet a configurable number of times if no response from the MS is received. The value in the Max PPP Inactivity Timer field shall be equal to [PPP inactivity timer + Echo_Reply_Timeout timer (Echo_Request_Retries + )] for the PPP session. The PDSN shall reset the PPP inactivity timer upon detection of traffic activity. When the MS that complies with this revision of document or later revisions receives the Max PPP Inactivity Timer packet from the PDSN, the MS shall send the Max PPP Inactivity Timer Response packet to the PDSN. If the PPP inactivity timer value, Echo-Reply-Timeout timer and/or Echo-Request-Retries counter have changed by an administrative action, the PDSN shall send the GPP vendor specific Max PPP Inactivity Timer packet over the main service connection. Upon expiration of the PPP inactivity timer, the PDSN shall send an LCP Echo-Request message [RFC ] over the main service connection, and start the Echo-Reply-Timeout timer for the PPP session. It shall also initialize the Echo-Request-Retries counter to a configurable integer value. Upon receipt of an LCP Echo-Reply message, an LCP Code-Reject [RFC ], or any other packets over the main service connection or secondary service connection(s), the PDSN shall stop and reset the Echo-Reply-Timeout timer, reset the Echo-Request-Retries counter, and reset the PPP inactivity timer. Upon expiration of the Echo-Reply-Timeout timer and when the Echo-Request-Retries counter value is greater than zero, the PDSN shall send an LCP Echo-Request message, decrement the Echo-Request-Retries counter by one, and start the Echo-Reply-Timeout timer. Upon expiration of the Echo-Reply-Timeout timer and when the Echo-Request-Retries counter value is equal to zero, the PDSN shall close the PPP session. In this case, the PDSN shall not send an LCP Terminate-Request to the MS... RADIUS Support The PDSN shall act as a RADIUS client in accordance with [RFC ] and shall communicate CHAP or PAP authentication information to the Visited RADIUS server in a RADIUS Access- Request message. Upon receipt of the CHAP or PAP response from the MS, the PDSN shall create a RADIUS Access-Request message in accordance with HTable. Attribute Name Type Access- Access- Interface(s) Request Accept User-Name M M PDSN <-> AAA User-Password O Note PDSN -> AAA CHAP-Password O Note PDSN -> AAA NAS-IP-Address O Note PDSN -> AAA NAS-IPv-Address O Note PDSN -> AAA CHAP-Challenge 0 O PDSN -> AAA Correlation ID / M O PDSN <-> AAA

20 X.S00-00-D vv Attribute Name Type Access- Access- Interface(s) Request Accept Calling-Station-ID M PDSN -> AAA Always On / O PDSN <- AAA NAS-Port-TypeF O PDSN -> AAA Carrier-ID / M PDSN->AAA Accounting-Mode / O PDSN <- AAA (M) Indicates Mandatory Attribute (O) Indicates Optional Attribute Note : User-Password is mandatory if PAP. Note : CHAP-Password is mandatory if CHAP. Note : At least one of NAS-IP-Address or NAS-IPv-Address shall be included. Table - Occurrence of RADIUS Attributes for Simple IP Additional RADIUS attributes and VSAs may be included in the RADIUS Access-Request and returned in the RADIUS Access-Accept messages as per [Chapter ]. The Correlation ID VSA and Always On VSA are in addition to those fields specified by [RFC ] and [RFC ]. The PDSN shall also act as a RADIUS accounting client in accordance with [RFC ] and shall communicate user accounting information to the Visited RADIUS server in RADIUS Accounting- Request (Start and Stop) records. The RADIUS Accounting-Request message shall contain the accounting attributes as specified in [Chapter ]. The PDSN may also send RADIUS Accounting- Request (Interim-Update) records between the Accounting-Request Start and Stop messages as necessary in accordance with Annex A of [Chapter ]. The security of communications between the PDSN and the RADIUS server may optionally be provided with IP security. The establishment of the security association is outside the scope of this document. When the PDSN sends a RADIUS Access-Request message, it may include both IPv and IPv specific attributes and/or VSAs. This is because the PDSN may not know a priori whether the MS intends to use IPv, IPv, or both, since the address assignment does not occur until after RADIUS authentication and authorization has completed. As per [RFC ], the IPv attributes may be sent along with IPv-related attributes within the same RADIUS message. The PDSN decides to use IPv and/or IPv specific attributes and/or VSAs that it receives in the RADIUS Access-Accept message based on whether the MS initiates IPCP and/or IPvCP.... NAI Construction in the Absence of CHAP or PAP In the event that the MS does not negotiate CHAP or PAP, no MS NAI is received by the PDSN. In this case, the PDSN shall not perform additional authentication of the user. If the PDSN is capable of constructing a properly formatted NAI based on the MSID, using the syntax defined in [RFC ], then accounting records shall be generated and keyed on the user s constructed NAI. The NAI shall be constructed using the syntax defined in [RFC ], in the form <MSID>@<realm>, where <MSID> is the MSID of the MS, and <realm> is the name of the home network that owns the MS s MSID. If the PDSN is unable to construct an NAI for an MS, then the PDSN may deny service to the MS. The PDSN shall use one of the following MSID formats to construct the NAI, as provided by the RAN: The values are as follows: (IS-000) [-] or (HRPD) [], depending on the service option number connected to the PDSN.

21 X.S00-00-D vv International Mobile Subscriber Identity (IMSI) [E.]; Mobile Identification Number (MIN) []; International Roaming MIN (IRM) []. The PDSN shall store the constructed NAI into the accounting records, and the Visited RADIUS server may use the realm to forward these records to the correct Home RADIUS server for proper summary and settlementf. The constructed NAI shall not be used for authentication. If configured by the operator, the PDSN shall send RADIUS accounting messages to the Visited RADIUS server using the constructed NAI in the absence of CHAP or PAP... Ingress Address Filtering For IPv, the Serving PDSN shall check the source address of every packet received on the PPP link from the MS. Upon receiving a packet from the MS with invalidf source IP address, the PDSN shall discard the packet and may send an LCP Configure-Request message to restart the PPP sessionf if IPCP has reached the open state. If the PDSN receives an implementation-defined number of consecutive packets with an invalid source IP address from the MS, the PDSN shall send an LCP Configure-Request message to the MS. If the PDSN receives a DHCP packet over port, the PDSN shall forward the message to the configured DHCP server(s) IP address(es) as described in section... For MIP and simultaneous Simple IP and MIP sessions see section... For IPv, the Serving PDSN shall check the prefix of the source IP address of every packet received on the PPP link from the MS. If the prefix is not associated with the PPP Session of the MS, then the PDSN shall discard the packet and send an LCP Configure-Request to restart the PPP session. If the source address is the IPv unspecified address and the message type is Neighbor Solicitation for Duplicate Address Detection (DAD), then the PDSN shall silently discard the packet received from the MS. If the source address is the IPv unspecified address for purposes other than Duplicate Address Detection (DAD) or the source address is the MS s IPv link-local address, the PDSN shall respond according to [RFC ].. RADIUS Server Requirements The RADIUS server shall follow the guidelines specified in [RFC ], [RFC ], and [RFC ]. The Home RADIUS server may require an MSID to user conversion table to map the constructed NAI (msid@realm) to the user's actual NAI (user@realm) to complete the billing process in cases where the constructed NAI differs from the actual NAI. The source IP address from the MS is considered as invalid if it is not one of the addresses that have been assigned to the MS or if the MS has not been assigned any IP addresses. The reason to restart PPP is because the user could have started a Simple IP session during a previous dormant handoff to another PDSN and returned; in this case the current PDSN would not know the MS had invoked Simple IP and received another IP address. Thus, restarting PPP will force the Simple IP session to get a topologically correct address.

22 X.S00-00-D vv The Visited and Home RADIUS server shall support the attributes as specified in Table and [Chapter ], the Interim Accounting Record as described in Annex A of [Chapter ] as well as the accounting attributes listed in [Chapter ]. The Home RADIUS server may include the Always On attribute in the RADIUS Access-Accept message to indicate an Always On Service for a user, based on the User Profile. If the MS uses CHAP or PAP, the PDSN sends the Visited RADIUS server a RADIUS Access- Request message with CHAP or PAP authentication information. The Visited RADIUS server shall forward the RADIUS Access-Request message to the home network or a peer (e.g., a broker) if it does not have the authority to accept/deny the request. This is in accordance with [RFC ]. Upon receiving a RADIUS Access-Request message, the Home RADIUS server shall send a RADIUS Access-Accept message or RADIUS Access-Reject message to the Broker or Visited RADIUS server. The Visited RADIUS server shall send the received response to the PDSN. If the RADIUS Access-Request message contains IPv and IPv specific attributes and/or VSAs, the RADIUS server should include the IPv and/or IPv attributes as provisioned in the user profile (e.g. Framed-Interface-Id, Framed-IPv-Prefix etc.) and/or VSAs in the RADIUS Access- Accept message. Upon receiving RADIUS Accounting-Request records from the PDSN, the Visited RADIUS server shall forward the RADIUS Accounting-Request records to the home or broker network. The communication between RADIUS client and RADIUS server or between RADIUS servers shall be protected using the secret shared with the next hop RADIUS server using the procedures described in [RFC ].. MS Requirements The MS may support Simple IP. The MS may choose Simple IP for IPv only, IPv only, or both IPv and IPv simultaneously. The MS shall access the cdma000 F0 packet data service using the cdma000 air interface [-], []... PPP Session The MS shall use PPP as the data link layer protocol for Simple IP.... Establishment If the cdma000 x MS supports multiple service connections, refer to [Chapter ] for details of PPP negotiation. Otherwise, for a new PPP session, the cdma000 x MS shall use a service instance of SO type to perform PPP negotiation with the PDSN as described in [RFC ]. If the HRPD MS supports multiple link flows, refer to [Chapter ] for details of PPP negotiation. Otherwise, for a new PPP session, the HRPD MS shall use the main link flow with default reservation label 0xff to perform PPP negotiation with the PDSN as described in [RFC ]. 0 cdma000 is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of GPP. Geographically (and as of the date of publication), cdma000 is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.

23 X.S00-00-D vv PPP shall support control escaping in accordance with section. of [RFC ]. The PPP Link Layer shall support negotiation of Asynchronous Control Character Mapping as defined in [RFC ]. The MS should attempt the minimum number of escapes by negotiating an ACCM of 0x The MS should not send an LCP Configure-Reject in response to an ACCM configuration option proposed by the PDSN in an LCP Configure-Request.... Termination When the MS deactivates packet data service, the MS should send an LCP Terminate-Request message to the PDSN to gracefully close the PPP session before releasing the packet data service connections with the RAN. In the case of power-down registration [-], the MS shall not send an LCP Terminate-Request message to the PDSN.... Authentication The MS shall support CHAP and may support PAP authentication for Simple IP. If the MS is configured to not use CHAP and PAP, the MS shall respond with an LCP Configure-Reject message containing the Authentication-Protocol option proposed in the LCP Configure-Request message received from the PDSN. If the MS uses PAP, it shall respond to an LCP Configure-Request message for CHAP with an LCP Configure-Nak proposing PAP. For both CHAP and PAP, the MS shall send an NAI in the form of user@realm.... Addressing with IPCP The MS may support simultaneous operation of IPCP and IPvCP. The MS shall negotiate the IP address configuration option to acquire an IPv address from the PDSN. The MS may implement [RFC ] in order to auto-configure DNS server IP addresses. The MS may negotiate Primary and Secondary DNS server IP addresses during the IPCP phase. The MS may use default of zero for DNS server address negotiation.... IPv Addressing A Simple IPv MS should send an IP address of during the IPCP phase to request an IP address from the network. The MS shall accept the address provided by the PDSN. If the MS requests a non-zero IP address during the IPCP phase, the PDSN replies with an IPCP Configure-Nak in response to the request in order to propose a different IP address. The MS shall accept the new address, and shall send an IPCP Configure-Request to the PDSN with the new IP address.... IPv Addressing A Simple IPv MS shall support the following RFCs, with exceptions as noted in this document: An IPv Aggregatable Global Unicast Address Format [RFC ]; Internet Protocol, Version (IPv) Specification [RFC 0]; Neighbor Discovery for IP Version (IPv) [RFC ]; IPv Stateless Address Auto-configuration [RFC ]; Internet Control Message Protocol (ICMPv) for the Internet Protocol Version (IPv) Specification [RFC ]; IP Version over PPP [RFC ]; IP Version Addressing Architecture [RFC ].

24 X.S00-00-D vv The MS should support Privacy Extensions for Stateless Address Auto-configuration in IPv [RFC 0]. To avoid disruption of an active session, e.g., Voice over IP, the MS should not change the IPv address used for that session. For IPv, the MS shall perform interface-identifier negotiation as described in [RFC ]. The MS shall construct the link-local IPv address by pre-pending the link-local prefix FE0:: / [RFC ] to the interface identifier negotiated during the IPvCP negotiation phase [RFC ]. When the Interface-Identifier is negotiated in the IPvCP phase of the PPP session setup, the MS should not perform duplicate address detection for the link local address as part of IPv stateless address auto-configuration [RFC ]. The MS shall construct global IPv address by pre-pending the prefix received from the Router Advertisement messages to the interface identifier negotiated during the IPvCP negotiation phase [RFC ] or to the interface identifiers generated using techniques defined in [RFC0]. The MS should not perform Duplicate Address Detection for global IPv addresses (since the prefix used is a globally unique / and exclusive to the PPP session). Following the successful IPvCP phase and auto-configuration of link-local address, the MS may transmit a Router Solicitation (RS) message(s) if a Router Advertisement message has not been received from the PDSN within a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY seconds per [RFC ]. The MS may set the upper bound of the delay to a value greater than that specified by the constant MAX_RTR_SOLICITATION_DELAY in [RFC ]. The MS may also set the lower bound of the delay to a value greater than 0. The MS may set the configurable number of RS messages to a value lessf than that specified by the constant MAX_RTR_SOLICITATIONS in [RFC ]. The MS may set the interval between the configurable number of RS messages to a value lessh than or greater than that specified by the constant RTR_SOLICITATION_INTERVAL in [RFC ]. If the last RS message is sent and a RA message is not received after a router solicitation interval, the MS shall send an IPvCP Configure-Terminate message to the PDSN. Upon reception of a RA message from the PDSN that contains the / globally unique prefix, the MS shall perform stateless address auto-configuration for global IPv addresses as per [RFC ] (and [RFC 0] for privacy purposes). After establishment of a PPP link with the PDSN, the MS shall treat that PDSN as the default router until the PPP session is closed.... DHCPv Support The MS may support and use DHCP [RFC ] to request specific configuration parameters [RFC ], which may include DNS addresses and/or SIP server addresses [RFC ].The MS should not use DHCP [RFC ] to request additional IPv addresses. To request specific configuration parameters, the MS shall send a DHCPInform message to the limited broadcast address (all s) or to a DHCP server s address if it knows one. The MS shall set the ciaddr field to its IPv address acquired during IPCP and shall include the parameter request list option to indicate the options the MS is interested in receiving and may include a vendor class option to request vendor specific information options. This exception is allowed by this document to optimize IPv RA over the cdma000 wireless links.

25 X.S00-00-D vv Stateless DHCPv Support The MS may support stateless DHCPv [RFC ] to obtain configuration information. The MS should not use DHCPv [RFC ] to request additional IPv addresses. If the MS supports stateless DHCPv, and wants to obtain configuration information, it shall send a DHCPv Information-Request message to the All_DHCP_Relay_and_Servers address [FF0:::] and shall include the Option Request option to specify the options that it wishes to receive from the DHCPv server, for example DNS configuration options [RFC ], SIP server options [RFC ], and BCMCS Controller option [RFC 0].... Compression The MS shall support Van Jacobson TCP/IP header compression [RFC ]. The MS additionally may support the following header compression algorithms: IP Header Compression [RFC 0] with IP Header Compression over PPP [RFC 0]; ROHC Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 0] with ROHC over PPP [RFC ]; ROHC: A Link Layer Assisted Profile for IP/UDP/RTP [RFC]; Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile [RFC 0]; Compressing IP/UDP/RTP headers on links with high delay, packet loss and reordering [RFC ] with IP Header Compression over PPP [RFC ]. The MS shall use IPCP and/or IPvCP to negotiate with the PDSN one or more header compression capabilities. If the MS is able to process received compressed header packets from the PDSN using various header compression protocols, the MS shall include the appropriate configuration option(s) to indicate to the PDSN which IP Header Compression protocol it supports in IPCP or IPvCP Configure-Request message as defined by [RFC ], [RFC ], [RFC 0], and [RFC ]. The MS shall support the PPP Compression Control Protocol [RFC ]. The MS may support PPP payload compression. If the MS intends to use PPP payload compression, the MS shall use PPP Compression Control Protocol to negotiate a PPP payload compression algorithm supported by the MS.... PPP Framing The MS shall use the octet-synchronous framing protocol defined in [RFC ]. One exception is there shall be no inter-frame time fill (i.e., no flag octets shall be sent between a flag octet that ends one PPP frame and the flag octet that begins the subsequent PPP frame)f.... PPP Link Status Determination To support Always On service, the MS shall adhere to [RFC ] section. Echo-Request and Echo-Reply with regards to LCP Echo-Request message processing, and the MS should support the GPP vendor specific Max PPP Inactivity Timer value packet [RFC ]. If the MS consists of a laptop and a relay-model handset, the laptop may send inter-frame time fill that prevents the mobile from becoming dormant.

26 X.S00-00-D vv.0 Upon receiving a Max PPP Inactivity Timer packet, the MS shall send a reply and should use the value received in the packet to maintain Always On connectivity. The MS shall reset the Max PPP Inactivity Timer when any packets over the main service connection or secondary service connection(s) are sent or received. Upon expiration of the Max PPP Inactivity Timer, the MS may initiate a new PPP session, or may enter the inactive state. 0

27 X.S00-00-D vv MIP Operation This section describes the requirements and procedures for MIP operation for IPv [RFC 00-00]. In this document, MIP refers to a service in which the user is able to maintain a persistent IP address even when handing off between RANs connected to different PDSNs. MIP provides the user IP routing service to a public IP network and/or secure IP routing service to private networks.. Common Service Specification The common requirements for several network elements (e.g., PDSN and MS) for MIP operation are described here... PPP Session See Section... For MIP only, neither CHAP nor PAP should be performed. If CHAP or PAP is performed, longer initial setup time and re-establishment time will occur as the result of an additional RADIUS server traversal. Note that the MN-FA Challenge Extension procedures [RFC 0] are performed regardless of whether or not CHAP/PAP is performed... MIP The following standards shall be used for MIP operations with any limitations or extensions described in this document: [RFC 00-00]; Reverse Tunneling [RFC 0]; Foreign Agent Challenge/Response [RFC 0]; NAI Extension [RFC ]... Dynamic Home Agent and Home Address Assignment In this document, an MS may request dynamic HA and/or Home Address assignment during the initial MIP registration according to the following scenarios of HTable and HTable (and also see section...). If the network receives an RRQ from the MS with an HA Address value of , the network shall treat the value as... (see section...).