Simple IPand Mobile IPflow

3GPP2 X.S0011-002-D Version: 1.
0 Version Date: February, 2006
cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services
COPYRIGHT
3GPP2 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 3GPP2 Secretariat at secretariat@3gpp2.org. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.
3GPP2
X.S0011-002-D v1.0
1 2
Content
1 GLOSSARY AND DEFINITIONS ...............................................................................................................2
REFERENCES................................................................................................................................................3
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
SIMPLE IP OPERATION..............................................................................................................................4 COMMON SERVICE SPECIFICATION .......................................................................................4 PPP SESSION ..........................................................................................................................4 PDSN REQUIREMENTS ..........................................................................................................4 PPP SESSION ..........................................................................................................................4 RADIUS SUPPORT ..............................................................................................................12 INGRESS ADDRESS FILTERING ............................................................................................14 RADIUS SERVER REQUIREMENTS .....................................................................................14 MS REQUIREMENTS ............................................................................................................15 PPP SESSION ........................................................................................................................15
3.1 3.1.1 3.2 3.2.1 3.2.2 3.2.3 3.3 3.4 3.4.1 4
MIP4 OPERATION ......................................................................................................................................20 COMMON SERVICE SPECIFICATION .....................................................................................20 PPP SESSION ........................................................................................................................20 MIP4 ....................................................................................................................................20 DYNAMIC HOME AGENT AND HOME A DDRESS ASSIGNMENT ..........................................20 GRE CVSE..........................................................................................................................21 PDSN REQUIREMENTS ........................................................................................................22 PPP SESSION ........................................................................................................................22 MIP4 REGISTRATION ..........................................................................................................23 RADIUS SUPPORT ..............................................................................................................26 IP SECURITY SUPPORT ........................................................................................................26 INGRESS ADDRESS FILTERING ............................................................................................28 PDSN REQUIREMENTS FOR GRE TUNNELING SUPPORT...................................................28 HOME AGENT REQUIREMENTS ...........................................................................................29 MULTIPLE REGISTRATIONS .................................................................................................29 MIP4 AUTHENTICATION SUPPORT .....................................................................................29 IPSEC SUPPORT ....................................................................................................................30 DYNAMIC HOME AGENT A SSIGNMENT ..............................................................................31 DNS ADDRESS A SSIGNMENT ..............................................................................................31 HA REQUIREMENTS FOR GRE TUNNELING SUPPORT .......................................................32 RADIUS SERVER REQUIREMENTS .....................................................................................32 DYNAMIC HOME AGENT A SSIGNMENT ..............................................................................33 MN-HA SHARED KEY DISTRIBUTION ................................................................................33 IKE PRE-SHARED SECRET DISTRIBUTION PROCEDURE .....................................................34 DNS ADDRESS A SSIGNMENT ..............................................................................................34 MS REQUIREMENTS ............................................................................................................34 PPP SESSION ........................................................................................................................34 MIP4 REGISTRATION ..........................................................................................................35 MS REQUIREMENTS FOR GRE TUNNELING SUPPORT .......................................................37 DNS SERVER IP ADDRESS NVSE ......................................................................................37
4.1 4.1.1 4.1.2 4.1.3 4.1.4 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.4 4.4.1 4.4.2 4.4.3 4.4.4 4.5 4.5.1 4.5.2 4.5.3 4.6 5
MIP6 OPERATION ......................................................................................................................................39
Content
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
5.1 COMMON SERVICE SPECIFICATION .....................................................................................41 5.1.1 PPP SESSION ........................................................................................................................41 5.1.2 MIP6 ....................................................................................................................................42 5.1.3 SUMMARY OF PDSN AND MS BEHAVIOR FOR DYNAMIC HA/HL/HOA DISCOVERY VIA MIP6 BOOTSTRAPPING .........................................................................................................................................42 5.1.4 MOBILE STATION TO HOME AGENT SECURITY FOR BU AND BA .....................................50 5.2 PDSN REQUIREMENTS ........................................................................................................50 5.2.1 PDSN REQUIREMENT TO SUPPORT STATELESS DHCPV6 TO CONVEY MIP6 BOOTSTRAP INFO 50 5.2.2 INGRESS ADDRESS FILTERING ............................................................................................52 5.3 HOME AGENT REQUIREMENTS ...........................................................................................52 5.3.1 HOME AGENT REQUIREMENTS TO SUPPORT DYNAMIC HOME AGENT A SSIGNMENT ......52 5.3.2 HOME AGENT REQUIREMENTS TO SUPPORT DYNAMIC HOME ADDRESS CONFIGURATION 52 5.3.3 MULTIPLE REGISTRATIONS .................................................................................................52 5.3.4 HOME REGISTRATION SUPPORT ..........................................................................................53 5.3.5 RETURN ROUTABILITY SUPPORT FOR ROUTE OPTIMIZATION ...........................................54 5.3.6 HA REQUIREMENT AS A RADIUS CLIENT ........................................................................54 5.4 RADIUS SERVER REQUIREMENTS .....................................................................................54 5.4.1 RADIUS SUPPORT FOR SESSION K EY GENERATION AND DISTRIBUTION TO THE HA ....56 5.4.2 RADIUS SUPPORT FOR MIP6 BOOTSTRAP .......................................................................58 5.5 MS REQUIREMENTS ............................................................................................................59 5.5.1 PPP SESSION ........................................................................................................................59 5.5.2 MS REQUIREMENT TO SUPPORT STATELESS DHCPV6 TO OBTAIN MIP6 BOOTSTRAP INFO 59 5.5.3 MULTIPLE REGISTRATIONS .................................................................................................60 5.5.4 MIP6 HOME REGISTRATION ...............................................................................................60 5.5.5 TERMINATION ......................................................................................................................61 5.6 ACCOUNTING CONSIDERATION ...........................................................................................61 5.6.1 PDSN REQUIREMENTS ........................................................................................................62 5.6.2 HA REQUIREMENTS .............................................................................................................62 6 SIMULTANEOUS SERVICES ...................................................................................................................64
33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
IP REACHABILITY SERVICE ..................................................................................................................65 SIMPLE IPV4 OPERATION ....................................................................................................65 MIP4 O PERATION ................................................................................................................66 DNS UPDATE BY THE HOME RADIUS SERVER ................................................................66 DNS UPDATE BY THE HA ...................................................................................................66 SIMPLE IPV6 OPERATION ....................................................................................................67 MOBILEIPV6 OPERATION....................................................................................................67
7.1 7.2 7.2.1 7.2.2 7.3 7.4 8 8.1 8.2 9
MS-PDSN VERSION CAPABILITY INDICATION ...............................................................................68 PDSN REQUIREMENTS ........................................................................................................70 MS REQUIREMENTS ............................................................................................................70 HOT-LINING................................................................................................................................................71 HOT-LINING CAPABILITIES .................................................................................................71 HOT-LINING ARCHITECTURE ..............................................................................................72 OPERATIONS ........................................................................................................................73 NEW-SESSION HOT-LINING PROCEDURE ...........................................................................74 ACTIVE SESSION HOT-LINING PROCEDURE .......................................................................76
9.1 9.2 9.3 9.3.1 9.3.2
Content
ii
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6
9.3.3 9.4 9.4.1 9.4.2 9.4.3
LIMITING THE HOT-LINING DURATION ..............................................................................78 HOT-LINING REQUIREMENTS ..............................................................................................78 REQUIREMENTS FOR HOT-LINE CAPABLE PDSN AND HA ...............................................78 MS REQUIREMENTS ............................................................................................................80 RADIUS SERVER ................................................................................................................80
ANNEX A(NORMATIVE): IKE/ISAKMP PAYLOADS ...............................................................................82 ANNEX B(NORMATIVE): CERTIFICATES..................................................................................................85
ANNEX C(NORMATIVE): PDSN TIMERS....................................................................................................87
Content
iii
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
List of Figures
FIGURE 1- MS PARAMETERS CONFIGURATION WITH DHCP ................................................................................8 FIGURE 2- CONFIGURATION OF MSS PARAMETERS USING DHCPV6..................................................................9 FIGURE 3 - MAX PPP INACTIVITY TIMER PACKET .............................................................................................11 FIGURE 4- GRE K EY CVSE.................................................................................................................................21 FIGURE 5- GRE H EADER FOR TUNNELING DATAGRAMS ...................................................................................22 FIGURE 6- NVSE FOR DNS SERVER IP ADDRESS ..............................................................................................38 FIGURE 7THE INITIAL MIP6 HOME REGISTRATION WITH MN-AAA MOBILITY MESSAGE AUTHENTICATION OPTION ............................................................................................................................39
FIGURE 8- MIPV6 HOME REGISTRATION WITH MN-HA MOBILITY MESSAGE AUTHENTICATION OPTION .......41 FIGURE 9- FLOW DIAGRAM FOR DYNAMIC HOME AGENT A SSIGNMENT ...........................................................44 FIGURE 10- BOOTSTRAP OF HOME LINK PREFIX .................................................................................................46 FIGURE 11- HOME ADDRESS A SSIGNMENT BY HOME RADIUS SERVER ..........................................................48 FIGURE 12- HOME ADDRESS AUTO-CONFIGURATION ........................................................................................49 FIGURE 13 - LAYOUT OF THE DATA 2 FIELD IN THE OPTION-CODE 2. ...............................................................51 FIGURE 14- D ERIVATION AND DISTRIBUTION OF IK DURING H OME REGISTRATION.........................................57 FIGURE 15- A CCOUNTING PROCEDURES FOR MIP6 ............................................................................................62 FIGURE 16- V ERSION/CAPABILITY PACKET FORMAT .........................................................................................68 FIGURE 17- HOT-LINING ARCHITECTURE ...........................................................................................................73 FIGURE 18- N EW SESSION HOT-LINING CALL FLOW ..........................................................................................75 FIGURE 19- A CTIVE SESSION HOT-LINE PROCEDURE .........................................................................................76
List of Figures
iv
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11
List of Tables
TABLE 1 - O CCURRENCE OF RADIUS A TTRIBUTES FOR SIMPLE IP ..................................................................13 TABLE 2 - HOME AGENT AND HOME ADDRESS SCENARIOS...............................................................................21 TABLE 3 - D ESCRIPTION OF SCENARIOS ..............................................................................................................21 TABLE 4 - O CCURRENCE OF RADIUS A TTRIBUTES FOR MIP4 .........................................................................33 TABLE 5 - MS REGISTRATION SCENARIOS ..........................................................................................................36 TABLE 6 - MIP6 BOOTSTRAPPING SCENARIOS ...................................................................................................43 TABLE 7 - MIP6 RADIUS A TTRIBUTES .............................................................................................................56 TABLE 8 - LIST OF MS CAPABILITIES ..................................................................................................................69 TABLE 9 - LIST OF PDSN CAPABILITIES .............................................................................................................70
List of Tables
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6
General Description
This chapter describes the basic IP access services: Simple IPv4/IPv6, MIP6 and MIP4 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 MIP4/MIP6 and Simple IPv4/IPv6 packet data sessions, IP Reachability Service, DHCP Support, and Hot-Lining.
General Description
3GPP2
X.S0011-002-D v1.0
1 2
Glossary and Definitions
See [Chapter 1].
1. Glossary and Definitions
3GPP2
X.S0011-002-D v1.0
1 2
References
See [Chapter 1].
2. References
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7
Simple IP Operation
This section describes the requirements and procedures for Simple IP operation for both IPv4 [RFC 791] and IPv6 [RFC 2460]. 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 document.
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
3.1
Common Service Specification
The common requirements for several network elements (e.g., PDSN and MS) for Simple IP operation are described here. 3.1.1 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 1661]; PPP in HDLC-like Framing [RFC 1662]; IPCP [RFC 1332] (for IPv4); IPv6CP [RFC 2472] (for IPv6); CHAP [RFC 1994]; PAP [RFC 1334].
PPP encryption is not supported in this document.
24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
3.2
3.2.1
PDSN Requirements
PPP Session
The PDSN shall support Simple IP operation for both IPv4 and IPv6.
3.2.1.1 Establishment If the PDSN supports multiple service connections for a user, refer to [Chapter 4] for details of PPP negotiation. Otherwise, when an A10 connection of SO type 33/59 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 4.2 of [RFC 1662]. 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 0x00000000. 3.2.1.2 Termination The PDSN shall close the PPP session if there is no established A10 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 1 from the Home RADIUS server in order
3. Simple IP Operation
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
to activate the Always On service for a user. If the PDSN receives the Always On attribute with value 1, it shall send the indicator to the RAN as indicated in [4]. Upon receiving the Always On attribute with value 1 from the Home RADIUS server the PDSN shall utilize the expiration of the PPP inactivity timer and the procedures described in Section 3.2.1.10 to determine if the PPP session should be closed.
2 4 6 H
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 A10 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 A10 and associated P-P session if it receives an LCP Terminate-Request message from the MS. 3.2.1.3 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 ConfigureNAK from the MS containing PAP, the PDSN shall accept PAP by sending an LCP ConfigureRequest 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 3.2.2.1 for NAI construction for accounting purposes.
2 4 7H
3.2.1.4 Addressing with IPCP 3.2.1.4.1 IPv4 Addressing
For IPv4, 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 1918]. 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 1877] 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 1 (=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 2 (=VAAA).
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
3.2.1.4.2
IPv6 Addressing
If the MS-PDSN Version Feature Indication (see section 8) is used, and the MS signaled that it does not support Simple IPv6 (C2 bit set to 0), then the PDSN shall not negotiate IPv6CP with the MS and shall not send IPv6 Router Advertisements to the MS. If the MS-PDSN Version Feature Indication is used, and the MS signaled that it supports Simple IPv6 (C2 bit set to 1), then the PDSN shall provide Simple IPv6 service to the MS as described in the rest of this section. For an IPv6 MS, the PDSN shall be the default router and the PPP termination point. The PDSN shall allocate one globally unique /64 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 IPv6 Aggregatable Global Unicast Address Format [RFC 3587]; Internet Protocol, Version 6 (IPv6) Specification [RFC 2460]; Neighbor Discovery for IP Version 6 (IPv6) [RFC 2461]; IPv6 Stateless Address Auto-configuration [RFC 2462]; Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [RFC 2463]; IP Version 6 over PPP [RFC 2472]; IP Version 6 Addressing Architecture [RFC 3513].
The PDSN shall perform Interface-identifier negotiation as described in [RFC 2472]. The PDSN shall provide a valid non-zero Interface-Identifier 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 IPv6CP phase with the MS. Because the Interface-Identifier is negotiated in the IPv6CP phase of the PPP connection setup, it is not required to perform duplicate address detection for the link local address formed as part of IPv6 stateless address auto-configuration [RFC 2462]. Following successful IPv6CP negotiation and the establishment of a unique link-local address for 1 both the PDSN and the MS, the PDSN shall immediately 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 /64 prefix in the Router Advertisement message to the MS. The MS shall use this prefix to configure its global IPv6 addresses.
0F
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 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 2461]. The PDSN may set MaxRtrAdvInterval to a value
This is an exception to [RFC 2461] necessary to optimize applicability over the cdma2000 wireless air-interface.
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
greater than 1800 seconds and less than 1/3 of the AdvDefaultLifetime. The PDSN shall set 2 MinRtrAdvInterval to a fraction of MaxRtrAdvInterval as per [RFC 2461].
1 F 2 4 8 H
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 3 /unsolicited RA) messages sent to the all-nodes multicast address to a value less than that specified by the constant MIN_DELAY_BETWEEN_RAS, contrary to the specification in sec. 6.2.6 of [RFC 2461].
2 F
The advertised /64 prefix identifies the subnet associated with the PPP link. The /64 prefix advertised by the PDSN shall be exclusive to the PPP session.
3 F
The PDSN shall set: the M-flag = 0 in the RA message header; the L-flag = 0 and the A-flag =1 in the RA message Prefix Information Option.
The PDSN shall set the Router Lifetime value in the Router Advertisement message to a value of 16 2 -1 (18.2 hrs). The PDSN shall not send any redirect messages to the MS over the PPP interface. 3.2.1.5 DHCPv4 Support The PDSN shall support DHCP Relay Agent function as specified in [RFC 1542] and [RFC 3046]. If the PDSN includes the Relay Agent Information Option, it shall set the giaddr field to the Relay Agents 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 = IPv4 address assigned to the MS via IPCP negotiation.
The PDSN assigns IPv4 address to MS via IPCP IP address configuration option. However, if the MS acquires additional IPv4 addresses from a DHCP server using a PDSN as the relay agent, the PDSN shall store the additional IPv4 addresses. The PDSN shall create one or more new accounting UDRs depending on the number of service connections established for each of these additional IPv4 addresses. The PDSN shall relay the DHCP message received from the MS on port 67 to the DHCP server(s) IP address(es) configured in the PDSN as specified in [RFC 3046]. The PDSN shall include a DHCP Relay Agent Information option [RFC 3046] 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 3527] 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
This may cause an exception to [RFC 2461] as it may put the interval outside the normal range. This exception is allowed by this document to optimize IPv6 RA over the cdma2000 wireless links. 3 This exception is allowed by this document to optimize IPv6 RA over the cdma2000 wireless links. 4 If the Access Service Provider desires to reduce frequent unsolicited RA for the prefix, it should set the 32-bit Valid Lifetime and Preferred Lifetime fields for the advertised /64 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).
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
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 IPv4 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 IPv4 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 IPv4 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 IPv4 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 LCP (a) CHAP(b) IPCP negotiation (IP address) (d) DHCP Inform (f)
PDSN
DHCP
AAA
Access-Request/Accept (c)
Accouting-Request (start)/ Response (e)
DHCP Inform (g) DHCPAck (i) DHCPAck (h)
19
20 21 22 23 24 25 26 27 28
Figure 1- 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 IPv4 address. e) The PDSN creates a UDR for the IP address/NAI pair and sends a RADIUS AccountingRequest (start) to the RADIUS server. 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 1s), assuming the MS does not know the DHCP servers IP address.
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
g) The PDSN relays the DHCP packet to the DHCP server(s) as per [RFC 3046]. 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 MSs IP address over the PPP link. 3.2.1.6 Stateless DHCPv6 Support The PDSN shall support DHCPv6 Relay Agent as specified in [RFC 3315] and [RFC 3736], and shall set the O bit to 1 in the Router Advertisement messages sent to the MS. Upon receiving a DHCPv6 Information-Request packet from the MS, the PDSN shall set the peeraddress field in the Relay Forward message to the source IPv6 address of the received DHCPv6 packet from the MS. The PDSN shall set the link address field to the global IPv6 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 DHCPv6 Relay-reply message(s) from one or more DHCPv6 servers, the PDSN shall relay the message according to section 20.2 of [RFC 3315]. The following flow diagram shows an MS that uses stateless DHCPv6 for configuration of parameters (e.g., DNS configuration options as specified in [RFC 3646]).
MS LCP (a) CHAP(c) IPv6CP negotiation (d) RA (O-flag set) (e) Information-Request (g)
PDSN
DHCPv6
AAA
Access-Request/Accept(b)
Accouting-Request (start)/ Response (f)
Relay-Forward (h) Relay-Reply (i) Reply (j)
17 18 19 20 21 22 23 24 25 26
Figure 2- Configuration of MSs parameters using DHCPv6 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 IPV6CP and negotiate unique 64-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 DHCPv6 to configure other parameters than the IPv6 address. f) The PDSN creates a UDR for the IPv6 prefix/Interface ID/NAI and sends a RADIUS Accounting-Request (start) to the RADIUS server.
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
g) The MS send an Information-Request message with the IP destination address set to the All_DHCPv6_Relay_Agents_and_Servers multicast address defined in [RFC 3315] [FF02::1:2]. 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_DHCPv6_Servers address [FF05::1:3] or to the DHCPv6 server(s) that may be configured in the PDSN. i) The DHCPv6 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. The PDSN extracts the Reply message and forwards it to the MS.
j)
3.2.1.7 Dual Stack of IPv4 and IPv6 Requirements 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. 3.2.1.8 Compression The PDSN shall support the following header compression algorithm: Van Jacobson TCP/IP header compression [RFC 1144]. ROHC, Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 3095] with ROHC over PPP [RFC 3241]; ROHC: A Link Layer Assisted Profile for IP/UDP/RTP [RFC 3242]; IP Header Compression [RFC 2507] with IP Header Compression over PPP [RFC 2509]; Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile [RFC 3408]; Compressing IP/UDP/RTP headers on links with high delay, packet loss and reordering [RFC 3545] with IP Header Compression over PPP [RFC 3544]. The PDSN may support the following header compression algorithms:
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 IPv6CP Configure-Request message as defined by [RFC 1332], [RFC 3241], [RFC 2509], and [RFC 3544]. The PDSN shall support CCP [RFC 1962] for the negotiation of PPP payload compression. The 5 PDSN shall support the following algorithms of PPP payload compression:
4 F
Stac-LZS [RFC 1974]; Microsoft Point-To-Point Compression Protocol [RFC 2118];
The PDSN shall not send compressed PPP frames when Multiple Service Instances are connected.
10
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
The PDSN may support other PPP payload compression algorithms. 3.2.1.9 PPP Framing The PDSN shall frame PPP packets sent on the PPP link layer using the octet synchronous framing protocol defined in [RFC 1662], except that there shall be no inter-frame time fill (see 4.4.1 of [RFC 1662]). 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 IPv6, the PDSN shall set the MTU size as specified in [RFC 2460]. 3.2.1.10 PPP Link Status Determination For Always On users, the PDSN shall support the 3GPP2 vendor specific Max PPP Inactivity Timer packet defined in PPP Vendor specific packet [RFC 2153] 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 C021(hex) If the MS-PDSN Version Feature Indication (see section 8) is used, and the MS signaled that it does not support the Max PPP Inactivity Timer (C4 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 3
2 4 9 H
78
15 16
23 24
30 31
Code
Identifier
Length
Magic Number
OUI
Kind
Max PPP Inactivity Timer

20 21
Figure 3 - Max PPP Inactivity Timer Packet Code = Identifier = 0 (As defined in [RFC 2153]) The Identifier field shall be changed for each Vendor Specific packet sent. It is used to match requests with responses. 16(octets)
Length =
11
3GPP2
X.S0011-002-D v1.0
Magic Number =
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 1661] for further explanation. 0xCF0002 1 32-bit value = PPP inactivity time + Echo_Reply_Timeout timer !(Echo_Request_Retries + 1)
OUI = Kind = Max PPP Inactivity Timer =
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Upon entering the IPCP 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 3GPP2 vendor specific Max PPP Inactivity Timer packet [RFC 2153] 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 + 1)] for the PPP session. The PDSN shall reset the PPP inactivity timer upon detection of traffic activity. 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 3GPP2 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 1661] 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 1661], or any other PPP packet for the PPP session, 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. 3.2.2 RADIUS Support
The PDSN shall act as a RADIUS client in accordance with [RFC 2865] and shall communicate CHAP or PAP authentication information to the Visited RADIUS server in a RADIUS AccessRequest message. Upon receipt of the CHAP or PAP response from the MS, the PDSN shall create a RADIUS Access-Request message in accordance with Table 1.
2 5 0H
Attribute Name User-Name User-Password CHAP-Password NAS-IP-Address NAS-IPv6-Address
Type 1 2 3 4 95
AccessRequest M O Note 1 O Note 2 O Note 3 O Note 3
AccessAccept M
Interface(s) PDSN <-> AAA PDSN -> AAA PDSN -> AAA PDSN -> AAA PDSN -> AAA
12
3GPP2
X.S0011-002-D v1.0
Attribute Name
Type
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
CHAP-Challenge 60 PDSN -> AAA Correlation ID 26/44 O PDSN <-> AAA Calling-Station-ID 31 PDSN -> AAA Always On 26/78 O PDSN <- AAA 6 NAS-Port-Type 61 O PDSN -> AAA Carrier-ID 26/142 M PDSN->AAA (M) Indicates Mandatory Attribute (O) Indicates Optional Attribute Note 1: User-Password is mandatory if PAP. Note 2: CHAP-Password is mandatory if CHAP. Note 3: At least one of NAS-IP-Address or NAS-IPv6-Address shall be included.
5 F
AccessRequest O M M
AccessAccept
Interface(s)
Table 1 - Occurrence of RADIUS Attributes for Simple IP Additional RADIUS attributes and VSAs may be returned in the RADIUS Access-Request and RADIUS Access-Accept messages as per [Chapter 5]. The Correlation ID VSA and Always On VSA are in addition to those fields specified by [RFC 2865] and [RFC 3162]. The PDSN shall also act as a RADIUS accounting client in accordance with [RFC 2866] and shall communicate user accounting information to the Visited RADIUS server in RADIUS AccountingRequest (Start and Stop) records. The RADIUS Accounting-Request message shall contain the accounting attributes as specified in [Chapter 5]. The PDSN may also send RADIUS AccountingRequest (Interim-Update) records between the Accounting-Request Start and Stop messages as necessary in accordance with Annex A of [Chapter 5]. 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 IPv4 and IPv6 specific attributes and/or VSAs. This is because the PDSN may not know a priori whether the MS intends to use IPv4, IPv6, or both, since the address assignment does not occur until after RADIUS authentication and authorization has completed. As per [RFC 3162], the IPv6 attributes may be sent along with IPv4-related attributes within the same RADIUS message. The PDSN decides to use IPv4 and/or IPv6 specific attributes and/or VSAs that it receives in the RADIUS Access-Accept message based on whether the MS initiates IPCP and/or IPv6CP. 3.2.2.1 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 2486], then accounting records shall be generated and keyed on the users constructed NAI. The NAI shall be constructed using the syntax defined in [RFC 2486], 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 MSs MSID. If the PDSN is unable to construct an NAI for an MS, then the PDSN may deny service to the MS.
The values are as follows: 22 (IS-2000) [5-9] or 24 (HRPD) [15], depending on the service option number connected to the PDSN.
13
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
The PDSN shall use one of the following MSID formats to construct the NAI, as provided by the RAN: International Mobile Subscriber Identity (IMSI) [E.212]; Mobile Identification Number (MIN) [3]; International Roaming MIN (IRM) [2].
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 7 summary and settlement . 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.
6 F
3.2.3
Ingress Address Filtering
For IPv4, 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 invalid source IP address, the PDSN shall discard the 9 packet and may send an LCP Configure-Request message to restart the PPP session if IPCP has reached the open state.
7 F 8 F
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 67, the PDSN shall forward the message to the configured DHCP server(s) IP address(es) as described in section 3.2.1.5.
2 5 1 H
For MIP4 and simultaneous Simple IP and MIP4 sessions see section 4.2.5.
2 5 2 H
For IPv6, 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 IPv6 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 IPv6 unspecified address for purposes other than Duplicate Address Detection (DAD) or the source address is the MSs IPv6 link-local address, the PDSN shall respond according to [RFC 2461].
31 32 33
3.3
RADIUS Server Requirements
The RADIUS server shall follow the guidelines specified in [RFC 2865], [RFC 2866], and [RFC 3162].
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. 8 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. 9 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.
14
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
The Visited and Home RADIUS server shall support the attributes as specified in Table 1 and [Chapter 5], the Interim Accounting Record as described in Annex A of [Chapter 5] as well as the accounting attributes listed in [Chapter 5]. 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 AccessRequest 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 2865]. 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 IPv4 and IPv6 specific attributes and/or VSAs, the RADIUS server should include the IPv4 and/or IPv6 attributes as provisioned in the user profile (e.g. Framed-Interface-Id, Framed-IPv6-Prefix etc.) and/or VSAs in the RADIUS AccessAccept 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 2865].
23 24 25 26 27 28 29 30 31 32 33 34 35
3.4
MS Requirements
9 F
The MS may support Simple IP. The MS may choose Simple IP for IPv4 only, IPv6 only, or both 10 IPv4 and IPv6 simultaneously. The MS shall access the cdma2000 packet data service using the cdma2000 air interface [5-9], [15]. 3.4.1 PPP Session
The MS shall use PPP as the data link layer protocol for Simple IP. 3.4.1.1 Establishment If the cdma2000 1x MS supports multiple service connections, refer to [Chapter 4] for details of PPP negotiation. Otherwise, for a new PPP session, the cdma2000 1x MS shall use a service instance of SO type 33 to perform PPP negotiation with the PDSN as described in [RFC 1661]. If the HRPD MS supports multiple link flows, refer to [Chapter 4] 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 1661].
10
cdma2000 is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000 is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.
15
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
PPP shall support control escaping in accordance with section 4.2 of [RFC 1662]. The PPP Link Layer shall support negotiation of Asynchronous Control Character Mapping as defined in [RFC 1662]. The MS should attempt the minimum number of escapes by negotiating an ACCM of 0x00000000. 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. 3.4.1.2 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 [5-9], the MS shall not send an LCP Terminate-Request message to the PDSN. 3.4.1.3 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. 3.4.1.4 Addressing with IPCP The MS may support simultaneous operation of IPCP and IPv6CP. The MS shall negotiate the IP address configuration option to acquire an IPv4 address from the PDSN. The MS may implement [RFC 1877] 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. 3.4.1.4.1 IPv4 Addressing
A Simple IPv4 MS should send an IP address of 0.0.0.0 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. 3.4.1.4.2 IPv6 Addressing
A Simple IPv6 MS shall support the following RFCs, with exceptions as noted in this document: An IPv6 Aggregatable Global Unicast Address Format [RFC 3587]; Internet Protocol, Version 6 (IPv6) Specification [RFC 2460]; Neighbor Discovery for IP Version 6 (IPv6) [RFC 2461]; IPv6 Stateless Address Auto-configuration [RFC 2462]; Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [RFC 2463]; IP Version 6 over PPP [RFC 2472]; IP Version 6 Addressing Architecture [RFC 3513].
16
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
The MS should support Privacy Extensions for Stateless Address Auto-configuration in IPv6 [RFC 3041]. To avoid disruption of an active session, e.g., Voice over IP, the MS should not change the IPv6 address used for that session. For IPv6, the MS shall perform interface-identifier negotiation as described in [RFC 2472]. The MS shall construct the link-local IPv6 address by pre-pending the link-local prefix FE80:: /64 [RFC 3513] to the interface identifier negotiated during the IPv6CP negotiation phase [RFC 2472]. When the Interface-Identifier is negotiated in the IPv6CP phase of the PPP session setup, the MS should not perform duplicate address detection for the link local address as part of IPv6 stateless address auto-configuration [RFC 2462]. The MS shall construct global IPv6 address by pre-pending the prefix received from the Router Advertisement messages to the interface identifier negotiated during the IPv6CP negotiation phase [RFC 2472] or to the interface identifiers generated using techniques defined in [RFC3041]. The MS should not perform Duplicate Address Detection for global IPv6 addresses (since the prefix used is a globally unique /64 and exclusive to the PPP session). Following the successful IPv6CP 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 2461]. 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 2461]. 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 11 messages to a value less than that specified by the constant MAX_RTR_SOLICITATIONS in [RFC 2461]. The MS may set the interval between the configurable number of RS messages to a 11 value less than or greater than that specified by the constant RTR_SOLICITATION_INTERVAL in [RFC 2461].
1 0 F 2 5 4H
If the last RS message is sent and a RA message is not received after a router solicitation interval, the MS shall send an IPv6CP Configure-Terminate message to the PDSN. Upon reception of a RA message from the PDSN that contains the /64 globally unique prefix, the MS shall perform stateless address auto-configuration for global IPv6 addresses as per [RFC 2462] (and [RFC 3041] 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. 3.4.1.5 DHCPv4 Support The MS may support and use DHCP [RFC 2131] to request specific configuration parameters [RFC 2132], which may include DNS addresses and/or SIP server addresses [RFC 3361].The MS should not use DHCP [RFC 2131] to request additional IPv4 addresses. To request specific configuration parameters, the MS shall send a DHCPInform message to the limited broadcast address (all 1s) or to a DHCP servers address if it knows one. The MS shall set the ciaddr field to its IPv4 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. 3.4.1.6 Stateless DHCPv6 Support The MS may support stateless DHCPv6 [RFC 3736] to obtain configuration information. The MS should not use DHCPv6 [RFC 3736] to request additional IPv6 addresses. If the MS supports
11
This exception is allowed by this document to optimize IPv6 RA over the cdma2000 wireless links.
17
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
stateless DHCPv6, and wants to obtain configuration information, it shall send a DHCPv6 Information-Request message to the All_DHCP_Relay_and_Servers address [FF02::1:2] and shall include the Option Request option to specify the options that it wishes to receive from the DHCPv6 server, for example DNS configuration options [RFC 3646], SIP server options [RFC 3319], and BCMCS Controller option [RFC 4280]. 3.4.1.7 Compression The MS shall support Van Jacobson TCP/IP header compression [RFC 1144]. The MS additionally may support the following header compression algorithms: IP Header Compression [RFC 2507] with IP Header Compression over PPP [RFC 2509]; ROHC Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 3095] with ROHC over PPP [RFC 3241]; ROHC: A Link Layer Assisted Profile for IP/UDP/RTP [RFC3242]; Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile [RFC 3408]; Compressing IP/UDP/RTP headers on links with high delay, packet loss and reordering [RFC 3545] with IP Header Compression over PPP [RFC 3544].
The MS shall use IPCP and/or IPv6CP 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 IPv6CP Configure-Request message as defined by [RFC 1332], [RFC 3241], [RFC 2509], and [RFC 3544]. The MS shall support the PPP Compression Control Protocol [RFC 1962]. 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. 3.4.1.8 PPP Framing The MS shall use the octet-synchronous framing protocol defined in [RFC 1662]. One exception is there shall be no inter-frame time fill (i.e., no flag octets shall be sent between a flag octet that 12 ends one PPP frame and the flag octet that begins the subsequent PPP frame) .
1 1 F
3.4.1.9 PPP Link Status Determination To support Always On service, the MS shall adhere to [RFC 1661] section 5.8 Echo-Request and Echo-Reply with regards to LCP Echo-Request message processing, and the MS should support the 3GPP2 vendor specific Max PPP Inactivity Timer value packet [RFC 2153]. 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 a PPP frame is sent or received.
12
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.
18
3GPP2
X.S0011-002-D v1.0
1 2
Upon expiration of the Max PPP Inactivity Timer, the MS may initiate a new PPP session, or may enter the inactive state.
19
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6
MIP4 Operation
This section describes the requirements and procedures for MIP4 operation for IPv4 [RFC 20022006]. In this document, MIP4 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. MIP4 provides the user IP routing service to a public IP network and/or secure IP routing service to private networks.
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
4.1
The common requirements for several network elements (e.g., PDSN and MS) for MIP4 operation are described here. 4.1.1 PPP Session
2 5 5 H
See Section 3.1.1. For MIP4, 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 3012] are performed regardless of whether or not CHAP/PAP is performed. 4.1.2 MIP4
The following standards shall be used for MIP4 operations with any limitations or extensions described in this document: 4.1.3 [RFC 2002-2006]; Reverse Tunneling [RFC 3024]; Foreign Agent Challenge/Response [RFC 3012]; NAI Extension [RFC 2794].
Dynamic Home Agent and Home Address Assignment
In this document, an MS may request dynamic HA and/or Home Address assignment during the initial MIP4 registration according to the following scenarios of Table 2 and Table 3 (and also see section 4.5.2.2).
2 5 6 H 2 5 7H 2 5 8 H
If the network receives an RRQ from the MS with an HA Address value of 0.0.0.0, the network shall treat the value as 255.255.255.255 (see section 4.5.2.2).
2 5 9 H
4. MIP4 Operation
20
3GPP2
X.S0011-002-D v1.0
Scenarios Scenario 1 Scenario 2 Scenario 3 Scenario 4

2
Type of Request Dynamic case Semi-static case Semi-static case Static case
Home Address specified in RRQ 0.0.0.0 x.x.x.x 0.0.0.0 x.x.x.x
Home Agent Address specified in RRQ 255.255.255.255 or 0.0.0.0 255.255.255.255 or 0.0.0.0 y.y.y.y y.y.y.y
Table 2 - Home Agent and Home Address Scenarios Scenarios Scenario 1 Scenario 2 Description This is for dynamic Home Address assignment and a dynamic HA assignment. In this scenario, the Home RADIUS server shall assign an appropriate HA to the MS. The Home RADIUS server may use the specified Home Address to select an HA for the MS. This corresponds to dynamic Home Address assignment and static HA assignment. This is for static HA and static Home Address MIP4 registration, i.e., there is no dynamic assignment. Table 3 - Description of Scenarios For details on dynamic HA assignment see the following: 4.1.4 Section 4.2.2.4 for the PDSN.
2 6 0H
Scenario 3 Scenario 4
3 4 5 6 7 8 9 10 11 12 13 14 15
Section 4.3.4 for the HA.

2 6 1H
Section 4.4.1 for the Home RADIUS server.

2 6 2H
Section 4.5.2.2 for the MS.

2 6 3H
GRE CVSE
GRE tunneling support for MIP4 will permit asymmetric GRE keying i.e., the PDSN assigns a GRE key for use in encapsulated traffic and the HA can assign its own GRE key. Once the GRE keys have been exchanged, the PDSN uses the HA-assigned key in the encapsulating GRE header for reverse tunneling and the HA uses the PDSN-assigned key in the encapsulating GRE header. 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 Reserved Length Vendor/Org-ID Vendor-CVSE-Type Vendor-CVSE-Value.
16 17
Figure 4- GRE Key CVSE Type: CVSE-TYPE-NUMBER 38
4. MIP4 Operation
21
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Reserved: Length: Vendor/Org-ID: Vendor-CVSE-Type: Vendor-CVSE-Value:
Reserved for future use. To be set to '0' Length in bytes of this extension, not including the Type and Length bytes. 5535 1281 (04H 01H) This 32-bit field indicates to the receiver the value to use in the GRE header Key field when sending GRE encapsulated traffic to the initiating entity. The replying entity may select a Key value different from the one received from the initiating entity.
The format of the GRE header to be used for tunneling datagrams is defined in [RFC 2890]. The header format is reproduced here. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5- GRE Header for Tunneling Datagrams Protocol Type: Key: 4 (IP) The value assigned by the PDSN and HA in RRQ/RRP messages respectively. This field MUST be present in the GRE header.
GRE tunnel related parameters such as checksum and sequence numbers MAY be inserted by the PDSN and/or HA based on local configuration.
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
4.2
PDSN Requirements
The PDSN shall support MIP4 operation and act as a FA. 4.2.1 PPP Session
The PDSN shall support multiple MIP4 Home Addresses over a single PPP session. 4.2.1.1 Establishment See Section 3.2.1.1.
2 6 4 H
4.2.1.2 Termination The Serving PDSN shall close the PPP session if there is no established underlying A10 session or P-P session for the MS, respectively. The PDSN shall clear the A10 session and P-P session, whenever the PPP session is closed. If the PDSN receives IP packets destined to an MS for which there is no established PPP session, the PDSN shall silently discard the packet. If the PDSN receives a failure code in the RRP from the HA, then the PDSN shall deliver the RRP to the MS, and shall not close the PPP session before a configurable timer expires. If the PDSN generates a failure code, the PDSN shall deliver the RRP to the MS and shall not close the PPP session before a configurable timer expires.
4. MIP4 Operation
22
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
See Annex C for description of PPP Inactivity Timer and Session Timer. The PDSN may receive the Always On attribute with value 1 from the Home RADIUS server in order to activate the Always On service for a user. If the PDSN receives the Always On attribute with value 1, it shall send the indicator to the RAN as indicated in [4]. If the MIP4 binding lifetime has expired for the Always On session and a MIP4 re-registration has not been received from the MS, the PDSN shall send an LCP Terminate-Request to the MS. 4.2.1.3 Authentication The PDSN shall initially propose CHAP in an LCP Configure-Request message to the MS. The PDSN shall re-send an LCP Configure-Request message without the authentication option after receiving the LCP Configure-Reject (CHAP or PAP) from the MS. 4.2.1.4 Addressing with IPCP If the MS-PDSN Version Feature Indication (see section 8) is used, and the MS signaled that it supports MIP4 (C1 bit set to 1), then the PDSN shall provide MIP4 service to the MS. In this case, when the MS requests MIP4 service and prior to the initial MIP4 registration, the MS does not include an IP Address Configuration Option in the IPCP Configure-Request message to the PDSN. If the MS includes an IP Address Configuration Option in the IPCP Configure-Request, the PDSN considers this as an MS using Simple IP service. In this case, the PDSN shall send an IPCP Configure-NAK with a new proposed IP address for the MS. If the MS-PDSN Version Feature Indication (see section 8) is used, and the MS signaled that it does not support MIP4 (C1 bit set to 0), then the PDSN shall not provide MIP4 service to the MS. In this case, the PDSN shall send a NAK to propose an IP address to revert to Simple IPv4 service. 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 not support [RFC 2290]. If the PDSN receives an IPCP Configure-Request from the MS containing the MIP4 Configuration Option [RFC 2290], the PDSN shall reply with an IPCP Configure-Reject message. The PDSN shall implement the IPCP configuration options as defined in [RFC 1877] for DNS server address negotiation. The PDSN shall negotiate Primary and Secondary DNS server IP addresses with the MS, if DNS Server Configuration options are received during the IPCP phase. 4.2.1.5 Compression See Section 3.2.1.8.
2 6 5 H
4.2.1.6 PPP Framing See Section 3.2.1.9.

2 6 6 H
4.2.2
MIP4 Registration
4.2.2.1 Agent Advertisements For the MS that uses MIP4, the PDSN shall begin transmission of an operator configurable number of Agent Advertisements immediately following negotiation or re-negotiation of PPP, or upon receipt of an Agent Solicitation message from the MS. Once the PDSN sends the configurable number of Advertisements, the PDSN shall not send further Advertisements, unless it receives an Agent Solicitation message from the MS. If the PDSN receives the RRQ from the MS, the PDSN shall cease sending Agent Advertisements.
4. MIP4 Operation
23
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
If the PDSN receives an Agent Solicitation from the MS following PPP establishment of a Simple IP session, the PDSN shall send Agent Advertisements to the MS with the R bit set. The PDSN may also send an Agent Advertisement to the MS with the 'R' bit set if the PDSN receives a 13 packet with an invalid IP source address from the MS when the PDSN hasnt previously sent Agent Advertisements. If Agent Advertisements are being sent, the PDSN shall not restart sending the configurable number of Agent Advertisements.
1 2 F
If the PDSN receives an RRQ with the 'D' bit set, the PDSN shall send an RRP with code 65 this case, the PDSN shall not close the PPP session.
14
1 3 F
. In
The MIP4 Registration Lifetime field in the Agent Advertisement shall be smaller than the PPP inactivity timer value in use for the underlying PPP session. Upon receiving a handoff indication including non-zero values of SID/NID/PZID of the previous PCF and SID/NID/PZID of the current PCF, if the PDSN already supports a MIP4 service for the MS, the PDSN shall use this information to determine whether or not MIP4 re-registration is required for the MS. If re-registration is required, then the PDSN shall re-negotiate PPP and begin transmission of an operator configurable number of Agent Advertisements. In order to minimize Agent Advertisements sent over the air, the PDSN shall not send unsolicited Agent Advertisements to an MS periodically to refresh the FA advertisement lifetime. The MS may send Agent Solicitations, when the FA advertisement lifetime expires. The Advertisement Lifetime is a configurable value, and shall be set to 9000 seconds (the maximum ICMP router advertisement lifetime). 4.2.2.2 Addressing and MIP4 The PDSN shall support [RFC 2794], and therefore, support zero and non-zero Home Address values in the MIP4 RRQ. For dynamic Home Address assignment, the PDSN shall accept MIP4 RRQs with a 0.0.0.0 source address from the MS, and shall use the NAI instead of the Home Address in its pending registration request records, along with the Identification field [RFC 2794]. For dynamic Home Address assignment, the PDSN shall acquire the MSs Home Address from the MIP4 RRP. In order to provide public network access and to provide private network access across the Internet, the PDSN shall use a publicly routable and visible IP address as a FA address. 4.2.2.3 MIP4 Extensions The PDSN shall include the MN-FA Challenge Extension [RFC 3012] in the Agent Advertisement. Because Advertisements are rarely sent (to save air resources), the PDSN shall include in the RRP a new challenge that the MS should use in its next re-registration with this PDSN. On reregistration, the PDSN may communicate user FAC authentication information to the Home RADIUS server, via broker servers if required, in a RADIUS Access-Request message. The frequency of this re-authentication and re-authorization is configurable by the operator. The challenge shall be changed on a serving access provider configurable basis. If the RADIUS attribute MN-AAA Removal Indication is included in the RADIUS Access-Accept message, and if the RRQ contains an MN-HA Authentication Extension followed by the MN-FA challenge and MN-AAA Authentication Extension, the PDSN shall remove the MN-FA challenge and the MN-AAA Authentication Extensions when relaying the RRQ to the HA. Otherwise, the PDSN shall relay the RRQ to the HA as received from the MS.
13
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 the MS has not been assigned with any IP addresses. 14 Previous version of this document uses code 77. In this document, the PDSN uses code 65, because code 77 is not used in RFC 2002.
4. MIP4 Operation
24
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
4.2.2.4 Dynamic Home Agent Assignment The PDSN shall include the Home Address that it receives in the RRQ message from the MS in the RADIUS Access-Request message in RADIUS attribute 8 (Framed-IP-Address). The PDSN shall include the HA Address that it receives in the RRQ message from the MS in the RADIUS Access-Request message in the HA attribute (see [Chapter 5]). Upon receiving a RADIUS Access-Accept message from the HAAA, the PDSN shall use the assigned HA Address in the HA attribute of the RADIUS Accept message as the destination address of the RRQ message (without modifying the HA field in the RRQ message originated by the MS). Upon receiving an RRP message with successful registration indication (code 0) for the MS, the PDSN shall update the mobility binding for the MS, which is indexed by the NAI and the Home Address (if non zero) in the RRQ, with the HA Address and the Home Address from the RRP. 4.2.2.5 Private Network Support It is possible that two different MSs served by a PDSN have the same, overlapping private address because they belong to two different private networks. To support this scenario, the PDSN forms a logical association that contains the A10 Connection ID, the MSs Home Address, and the HA Address. When the PDSN receives a packet for a registered MS from the HA, the PDSN maps the MSs HA Address and the Home Address to one association, and transmits the packet on the A10 connection indicated by the A10 Connection ID of the association. When processing additional MIP4 registrations for the same MS, if the PDSN receives an RRP from a second HA that includes a private address as the Home Address, and if the private address has already been assigned to the MS by another HA, the PDSN shall set the Code field to 65 (administratively prohibited) before forwarding the RRP to the MS. The first assigned address is not affected. 4.2.2.6 Reverse Tunneling The PDSN shall reject a MIP4 registration with an error code of 75, if a private Home Address as defined in [RFC 1918] is present in either the RRQ or RRP, and the RRQ did not indicate reverse tunneling. If the Home RADIUS server sends a Reverse Tunnel Specification attribute in the RADIUS Access-Accept message indicating that reverse tunneling is required, and the MS did not indicate reverse tunneling in the RRQ, the PDSN shall reject the registration with an error code of 75. The PDSN shall support both direct delivery and encapsulated delivery styles as specified in [RFC 3024]. If Reverse Tunneling with encapsulating delivery style is negotiated with the MS, the PDSN shall send all the packets as specified as [RFC 3024]. 4.2.2.7 DNS Address Assignment If the PDSN supports the DNS Server IP Address VSA and NVSE and it receives a DNS Server IP Address VSA in the RADIUS Access-Accept message from the RADIUS server or/and a DNS Server IP Address NVSE in the MIP4 Registration Reply from the HA, then the PDSN may include each received DNS Server IP Address in a DNS Server IP Address NVSE in the MIP4 Registration Reply to the MS. The format of the DNS Server IP Address VSA is defined in section 4 of [Chapter 5]. The format of the DNS Server IP Address NVSE is defined in section 4.6.
2 6 7 H
If the PDSN receives a DNS Server IP Address from both the Visited RADIUS and Home RADIUS servers (entity type 1 and 2), and the PDSN supports the VSA, the PDSN shall determine if the M bit is set in the DNS Server IP Address VSA received in the RADIUS AccessAccept message to select the DNS Server IP Address VSA it forwards to the MS. The DNS Server IP Address VSA with the M bit set, shall have precedence over the VSA that does not have the M bit set. If the 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.
4. MIP4 Operation
25
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
! !
A DNS IP Address VSA with the Entity-Type subfield set to the value 1 (=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 2 (=VAAA).
4.2.3 RADIUS Support The PDSN shall act as a RADIUS client in accordance with [RFC 2865]. On initial mobile access, the PDSN shall communicate user FAC authentication information to the Home RADIUS server, via the broker RADIUS servers if required, in a RADIUS Access-Request message. On receipt of the RRQ from the MS, and if SPI in the MN-AAA Authentication Extension is set to CHAP-SPI, the PDSN shall create a RADIUS Access-Request message in accordance with Table 4. See section 4.3.2 for how to construct CHAP-Password and CHAP-Challenge fields in the RADIUS Access-Request message.
2 6 8H 2 6 9H
If the SPI in the MN-AAA Authentication Extension is set to CHAP SPI as per [RFC 3012], the PDSN shall use MD5 when computing the CHAP challenge. If the authentication succeeds, the Home RADIUS server shall send a RADIUS Access-Accept message to the PDSN. If the authentication fails, the Home RADIUS server shall send a RADIUS Access-Reject message to the PDSN. The inclusion of the NAS-IP-Address or the NAS-IPv6-Address, or both in the RADIUS AccessRequest message, depends on whether the PDSN has an IPv4 address or IPv6 address, or both. The PDSN shall act as a RADIUS accounting client in accordance with [RFC 2866] and shall communicate user accounting information to the Visited RADIUS server in RADIUS AccountingRequest messages. The PDSN shall determine at completion of the IPCP phase that a RADIUS Accounting-Request (Start) record shall be sent to the RADIUS server following a successful MIP4 Registration Reply received from the HA. The Accounting-Request (Start) record shall contain the Account Session ID and Correlation ID attribute generated by the PDSN. The security of communications between the PDSN and the RADIUS server may be provided using IP security. The establishment of security is outside the scope of this document. 4.2.4 IP Security Support
There may be a statically configured shared key for computing the MIP4 HA-FA Authentication Extension in MIP4 registration messages. If such a shared key exists, the PDSN and the HA shall use it. Additional Security Associations (SAs) between the PDSN and HA may also be supported for the protection of MIP4 control messages and user data. This document supports the following options for the establishment of such additional SAs: Public certificates
15
1 4 F
Dynamic IKE pre-shared secret distributed by the Home RADIUS server. Statically configured IKE pre-shared secret.
The PDSN shall support IPsec and IKE [RFC 2409]. An SA between the PDSN and the HA may be established using X.509 based certificates, or a pre-shared secret for IKE that may be statically configured or dynamically provisioned by the Home RADIUS server. Although ESP is preferred (and shall be implemented), AH shall also be implemented in order to maintain backward compatibility with previous versions of this document.
15
Refer to Annex A and B for details.
4. MIP4 Operation
26
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
In the case of an operator owned HA, and if mandated by operator policy, the PDSN shall have an SA with the HA in order for a RRQ to be successfully processed. The SA may formally be via IPsec (i.e., ESP or AH) or MIP4 HA-FA Authentication Extension. An SA between the PDSN and the HA shall be established as follows: When receiving a MIP4 RRQ containing a unicast HA Address, the PDSN shall verify if an SA currently exists with the HA. If an SA does not exist, the PDSN shall verify if HA X.509 certificates exists. If no HA X.509 certificate exists, the PDSN shall verify if a root certificate exists. If the necessary certificates do not exist, the PDSN shall verify if a statically configured pre-shared secret for IKE exists. If the static pre-shared secret for IKE is also not available, it shall include a request for a pre-shared secret for IKE in the RADIUS Access-Request message. The Home RADIUS server shall include the pre-shared secret for IKE and a KeyID in the RADIUS AccessAccept message if IPsec services are authorized for the user. When the MS uses dynamic HA assignment (scenarios 1 and 2 from Section 4.1.3), the PDSN shall always request the IKE pre-shared Secret from the Home RADIUS server. IPsec support for dynamic HA assignment is further described in Section 4.2.4.3.
2 7 0H 2 7 1 H
4.2.4.1 IPsec Service Authorized The PDSN shall provide IPsec services as indicated by the Security Level attribute included in the RADIUS Access-Accept message. The Security Level attribute included in the RADIUS AccessAccept message allows the Home RADIUS server to indicate whether IP security should be applied to MIP4 registration messages and MIP4 tunneled data between the HA and the PDSN, or not to use IPsec at all. The same security level shall be applied by the PDSN for all users using the same Home Agent. If the PDSN receives the deprecated value of '1' or '2', the PDSN shall use a default value of '3'. If the home network authorizes IPsec services, the PDSN shall not forward an RRQ to the HA unless an IPsec SA is established. The PDSN shall send a failed RRP with an error code of 65 (Administratively Prohibited) to the MS if IPsec service is authorized by the Home RADIUS server but it is unable to establish an IPsec SA to the HA. The Home RADIUS server authorizes the PDSN to either use an existing SA with the corresponding HA or to establish a new SA if no prior SA exists. If an IPsec SA does not exist and IPsec is authorized, the PDSN shall establish an SA using IKE with either X.509 or root certificates, or statically configured pre-shared secret for IKE, or dynamically distributed pre-shared secret for IKE. The PDSN shall comply with the specifications in IKE [RFC 2409] and the Annexes A and B in this document. If reverse tunneling is required and IPsec security is authorized, then the PDSN shall provide security on the reverse tunnel. If the PDSN does not receive the Security Level attribute from the Home RADIUS server, and an IPsec SA to the HA already exists, the PDSN shall continue to use the same SA. If it receives a new pre-shared secret for IKE and an SA already exists, the PDSN shall not renegotiate the ISAKMP SA and shall discard any pre-shared secret received in the RADIUS Access-Accept message. If no SA exists, then the PDSN shall follow local security policy. If an IPsec SA already exists with the HA, the PDSN shall ensure the IPsec SA is maintained by periodically refreshing the SA for as long as valid MIP4 bindings exist with that HA. 4.2.4.2 IPsec Service Not Authorized If the Home RADIUS server does not authorize security for the MS, the PDSN shall not delete existing IPsec SA with an HA. This is because IPsec should be authorized per PDSN-HA pair and thus other MSs may be using the same IPsec SA. 4.2.4.3 Dynamic HA Assignment When the PDSN receives a MIP4 RRQ containing an HA Address of 255.255.255.255 (or 0.0.0.0), it shall always include the IKE Pre-shared Secret Request attribute in the RADIUS
4. MIP4 Operation
27
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
Access-Request message sent to the Home RADIUS server. The Home RADIUS server responds with a RADIUS Access-Accept message containing the allocated HA Address and if IPsec services are authorized for the user, the corresponding dynamic pre-shared secret and KeyID for IKE are also included. The PDSN shall verify if IPsec services are authorized by the presence of the Security Level attribute. When IPsec service is authorized for the user, the PDSN shall then determine from the received HA Address whether an IPsec SA already exists. If an SA already exists with the HA, the PDSN shall use the existing SA as is and shall discard any preshared secret received in the RADIUS Access-Accept message. If an SA does not exist, the PDSN shall determine if certificates or static pre-shared secret for IKE exist for the HA, otherwise the pre-shared secret for IKE, if provided by the Home RADIUS server, shall be used to establish the required SA. 4.2.5 Ingress Address Filtering
Upon receiving a packet from the MS, the PDSN shall discard the packet if one of the following conditions holds: the packet is received while the PPP negotiation is in progress (state is not open), the packet is received while MIP4 registration is pending , but the source IP 17 address of the packet is invalid , and the packet is not a MIP4 control packet (MIP4 RRQ or Agent Solicitation).
1 5 F 1 6 F
16
For a MIP4 session establishment over a Simple IP session, at the Simple IP establishment, 1. if the MS sends an Agent Solicitation to the PDSN, the PDSN shall respond with an Agent Advertisement and shall discard all IP packets with an invalid source IP 16 address while MIP4 registration is pending .
2 7 2H
2. If the MS doesnt send Agent Solicitations but sends IP packets with an invalid Source IP address, if the packet is not a DHCP packet, the PDSN may discard the packets and may send an Agent Advertisement to the MS. If the PDSN sends Agent Advertisements to the MS as a result of an Invalid Source IP address, it shall discard 16 all IP packets with an invalid source IP address while MIP4 registration is pending .
2 7 3H
If the PDSN receives an implementation-defined number of consecutive packets with an invalid source IP address from the MS, and the packets are not DHCP packets, the PDSN shall send an LCP Configure-Request message to the MS. If the PDSN receives a DHCP packet over port 67, the PDSN shall forward the message to the configured DHCP server(s) IP address(es) as described in section 3.2.1.5.
2 7 4 H
4.2.6
PDSN Requirements for GRE Tunneling Support
The PDSN shall support IP-in-IP tunneling of datagrams. The PDSN may support GRE tunneling. This can be used to allow for overlapping private home IP addresses. Note that this does not preclude implementation-specific solutions for the support of overlaid private home networks. If the PDSN is capable of supporting GRE encapsulation, it should set the G bit in the Flags field in the Agent Advertisement message sent to the MS during MIP4 session establishment.
16 17
i.e., between the NCP open state and completion of MIP registration. 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.
4. MIP4 Operation
28
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
If the MS does not set the G bit in the RRQ, the PDSN may fall back to using IP-in-IP encapsulation for the session per [RFC 2002]. If the MS does not set the G bit in the RRQ, and the local policy allows the PDSN to override the G bit setting received from the MS, the PDSN shall include a new MIP4 extension GRE-Key CVSE in the MIP4 RRQ message to request GRE encapsulation for the session. Note that this behavior is not currently supported in [RFC 2002]. If the PDSN does not support GRE encapsulation, the PDSN shall reset the G bit in the Agent Advertisement message. In this case, if the MS sets the G bit in the MIP4 RRQ message, the PDSN returns a MIP4 RRP message to the MS with code 'Requested Encapsulation Unavailable (0x48) per [RFC 2002]. If PDSN allows GRE encapsulation, and either the MS requested GRE encapsulation or local policy dictates using GRE encapsulation for the session, the PDSN shall assign a GRE key and shall insert the GRE Key CVSE defined in section 4.1.4 in all MIP4 RRQs (including initial, renewal and de-registration requests) that it forwards to the HA.
2 7 5 H
The GRE Key CVSE shall follow the CVSE format defined in [RFC 3115]. This extension shall be added after the MN-HA and MN-FA Challenge and MN-AAA extensions (if any) and before the FA-HA Auth extension (if any).
4.3
Home Agent Requirements
The HA shall support MIP4 [RFC 2002-2006], reverse tunneling [RFC 3024], FAC [RFC 3012], and MIP4 NAI Extension [RFC 2794]. In order to provide public network access and private network access across the public network, the HA shall use a globally routable and visible IP address. 4.3.1 Multiple Registrations
The HA shall support Multiple registrations with the same NAI but different static Home Addresses. 4.3.2 MIP4 Authentication Support
When the HA receives an RRQ from a PDSN, it authenticates the RRQ using the MN-HA shared key. At initial registration, if the HA does not have the MN-HA shared key, it shall retrieve the MNHA shared key from the Home RADIUS server. Based on the policy of the home network, the HA may also process the MN-AAA Authentication Extension as specified in [RFC 3012], if included in the RRQ. If the home network policy dictates that the HA shall process the MN-AAA Authentication Extension, then the HA shall authenticate the request by including the following attributes in a RADIUS Access-Request message to the Home RADIUS server: User-Name (1) = MN-NAI field in the MN-NAI Extension CHAP-Password (3) = o o CHAP Ident field = High-order byte of the Challenge Field in the MN-FA Challenge Extension String field = Authenticator field from the MN-AAA Authentication Extension
CHAP-Challenge (60) = MD5 (Preceding MIP4 RRQ, Type, Subtype, Length, SPI), followed by the least-order 237 bytes of the Challenge Field in the MN-FA Challenge Extension. The MD5 checksum is computed over the MIP4 RRQ data preceding the
4. MIP4 Operation
29
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
MN-AAA Authentication Extension and the Type, Subtype, Length, SPI fields of the MN-AAA Authentication Extension. MN-HA SPI = to request the MN-HA shared key if not available at the HA. The MNHA shared key corresponds to a single users NAI, or NAI and non-zero static IP address pair.
If the MN-AAA Authentication Extension is not present in the RRQ or HA policy dictates that the HA shall not process the MN-AAA Authentication Extension (, and the HA requires the MN-HA 18 shared key from the RADIUS server), the HA shall send a RADIUS Access-Request message that includes a User Name, a User-Password and an MN-HA SPI.
1 7 F
If the MN-HA shared key is requested, the Home RADIUS server shall encrypt the MN-HA shared key in a RADIUS Access-Accept message using a method based on the RSA Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of [RFC 2868]. The HA shall save the MN-HA shared key received from the Home RADIUS server for the duration of the MIP4 session with the MS. Based on the local policy, the HA may store the MNHA shared key a certain time skew after releasing the mobility binding for the MS. The HA shall compute the MN-HA Authentication Extension, according to [RFC 2002], based on the MN-HA shared key. Computation of the extension shall include the Type and the SPI field of the MN-HA Authentication Extension itself. 4.3.3 IPsec Support
The HA shall determine which type of security associations (if any) are required with a PDSN. The HA and the PDSN shall use the same security policy as specified in the Home RADIUS server. The policy may be locally configured at the HA or may be obtained from the Home RADIUS server in the Security Level attribute. If IPsec is authorized and no SA is currently in place, the HA shall participate in IKE negotiation with the PDSN. The negotiation will result in establishing an IPsec SA that will be used for all traffic between the HA and the PDSN. The HA shall perform a similar operation as the Home RADIUS server to generate the pre-shared secret for IKE (i.e., K), see algorithm for K in Section 4.4.3.
2 7 6 H
When an IKE request is received, the HA shall validate the timestamp in the KeyID field. This timestamp eliminates the possibility of re-using a previously generated shared-key for IKE K value while the secret key S is still valid on the HA. The HA shall also use the 'S' Key indexed by Home RADIUS server IP address from the KeyID field. If there is no previously assigned 'S' Key, the S Key is not found, or the timestamp in the KeyID is greater than the S expiration time, then the HA shall send a RADIUS Access-Request message to the Home RADIUS server to request the S Key. That RADIUS Access-Request message shall contain: The User-Name attribute consisting of a concatenation of the PDSNs CoA and HA Address. The S Request attribute.
The User-Name attribute should be formatted using ASCII hexadecimal notation. Both addresses are converted to hexadecimal and the ASCII codes of the hexadecimal characters and are
18
Construction of the message is implementation dependent.
4. MIP4 Operation
30
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
concatenated with the HA Address following the CoA. For example, CoA of 10.10.10.11 is concatenated with an HA Address of 92.64.10.1 to yield 0A0A0A0B5C400A01. The RADIUS Access-Accept message from the Home RADIUS server shall include the 'S' Key and its lifetime, and may include the Security Level attribute. The HA shall save the 'S' Key received from the Home RADIUS servers. The HA shall compute the pre-shared secret K using KeyID [Chapter 5] and the 'S' Key (see Section 4.4.3).
2 7 7 H
Each HA shall have a configurable, allowable time skew to be used to validate the freshness of K. The HA shall maintain expired S keys for a configurable amount of time. This expired key shall be used when KeyIDs are received that refer to the expired 'S' Key but falls within the 19 allowable time skew .
1 8 F
The security method used between the HA and the Home RADIUS server is outside the scope of this document. However, the Home RADIUS server may encrypt the 'S' Key and the 'S' Lifetime using a method based on the RSA Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of [RFC 2868]. If mandated by an operator security policy, an operators HA shall have an SA with the PDSN in order for a registration request to be successfully processed. The SA may formally be via IPsec (e.g., ESP or AH) or via a MIP4 HA-FA Authentication Extension. Likewise, an HA shall accept or reject an RRQ received directly from an MS with a 'D' bit set depending on security policy. 4.3.4 Dynamic Home Agent Assignment
During dynamic HA assignment, the HA Address that is specified by the MS in the RRQ message and the IP address of the dynamically assigned HA may not be the same. Upon receipt of such an RRQ message in an IP packet with the destination IP address set to the HA unicast IP address, the HA may accept the RRQ contrary to the specification in [RFC 2002] or may reject it with an error code of 136 in accordance with [RFC 2002]. The HA shall follow the procedures described in Section 4.3.2 to complete its authentication process for the RRQ message. The HA shall put its IP address in the HA Address field of the RRP message to the MS.
2 7 8H
4.3.4.1 DHCPv4 Support The HA shall support a DHCP Relay Agent capability [RFC 3046]. The HA shall relay the DHCP message of type DHCPInform received from the MS on port 67 to the DHCP server(s) IP address(es) configured in the HA as specified in [RFC 3046]. The relay destination may be an IP unicast, multicast, broadcast, or some combination. The HA shall relay the DHCP messages received from the DHCP server(s) to the MS using the address specified in the ciaddr field (HoA). 4.3.5 DNS Address Assignment
The DNS server IP addresses may be configured at the HA, or received from the Home RADIUS server in a RADIUS Access-Accept message. If the HA does not receive the DNS Server IP 20 Address VSA from the Home RADIUS server, then the HA may include configured DNS server
1 9 F
19
The skew serves to solve the case where RADIUS or IKE messages are lost and must be transmitted yet the 'S' Key expires in the meantime. An example of the skew could be one minute. 20 The DNS information may be pre-configured in the HA or the HA may acquire the DNS information via other schemes.
4. MIP4 Operation
31
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
IP addresses in the DNS Server IP Address NVSE. If the HA includes the configured DNS server IP addresses in the DNS Server IP Address NVSE, it shall set the Entity-Type field to 3 (see section 4.6), and send the NVSE in a MIP4 Registration Reply message. If the HA receives the DNS Server IP Address VSA from the Home RADIUS server, the HA may include the received DNS server IP addresses in the DNS Server IP Address NVSE. If the HA includes the received DNS server IP addresses in the DNS Server IP Address NVSE it shall set the EntityType field to 1 (see section 4.6) and send the NVSE in a MIP4 Registration Reply message.
2 0 F 2 7 9 H 2 8 0H
21
4.3.6
HA Requirements for GRE Tunneling Support
The HA shall follow the procedures specified in [RFC 3115] in processing this extension in Registration Request messages. If the HA receives the GRE Key CVSE in a Registration Request and does not recognize GRE Key CVSE, it shall reject the call by sending a MIP4 RRP with code Unknown CVSE (0x8D) per [RFC 3115]. If the HA receives the GRE Key CVSE in a Registration Request and recognizes the GRE Key CVSE but is not configured to support GRE encapsulation, it shall reject the call by sending a MIP4 RRP with code Requested Encapsulation Unavailable (0x8B). If the HA receives a Registration Request with the 'G' bit set but without the GRE Key CVSE, it shall reject the call by sending a MIP4 RRP with code Poorly Formed Request (0x86). If the HA receives a Registration Request with a GRE Key CVSE but without the G bit set, the HA should treat this as if G bit is set in the Registration Request, i.e., the presence of GRE Key CVSE indicates a request for GRE encapsulation. In this case the HA shall not send the 'G' bit in the RRP. If the HA receives the GRE Key CVSE in a Registration Request and recognizes the GRE Key CVSE as well as supports GRE encapsulation, it should accept the RRQ and send a MIP4 RRP with code Accepted (0). The HA shall assign a GRE key and include the GRE Key CVSE in the MIP4 RRP sent to PDSN. The HA shall include the GRE Key CVSE in all RRPs in response to any MIP4 RRQ that included GRE Key CVSE, when a GRE key is available for the registration.
27 28 29 30 31 32 33
4.4

2 8 1 H
See Section 3.3. In order to provide the functions defined in this document, the Home and Visited RADIUS servers shall support as required the attributes listed in Table 4 and [Chapter 5], in addition to the standard RADIUS attributes. The Broker RADIUS server shall support the decryption and reencryption of the Pre-shared Secret attribute and the MN-HA Shared Key attribute. Attribute Name User-Name User-Password CHAP-Password CHAP-Challenge Type 1 2 3 60 AccessRequest M O Note 1 M Note 2 M Note 2 AccessAccept M Interface(s) PDSN -> AAA HA -> AAA HA -> AAA PDSN -> AAA HA -> AAA PDSN -> AAA HA -> AAA
21
The DNS information may be pre-configured in the HA or the HA may acquire the DNS information via other schemes.
4. MIP4 Operation
32
3GPP2
X.S0011-002-D v1.0
Attribute Name NAS-IP-Address NAS-IPv6-Address Foreign Agent Address Correlation ID Calling-Station ID Home Agent Framed-IP-Address IKE Pre-shared Secret Request Security Level
Type 4 95 26/79 26/44 31 26/7 8 26/1 26/2
AccessRequest O Note 3 O Note 4 O M O M M O
AccessAccept
Interface(s) PDSN -> AAA PDSN -> AAA PDSN -> AAA PDSN <-> AAA PDSN -> AAA PDSN <-> AAA PDSN <-> AAA PDSN -> AAA AAA -> PDSN, AAA -> HA AAA -> PDSN AAA -> PDSN AAA -> PDSN AAA -> HA AAA -> HA HA -> AAA AAA -> HA HA -> AAA AAA -> PDSN
O M O O
1 2 3 4 5 6 7 8 9 10
Pre-shared Secret 26/3 O Reverse Tunnel Specification 26/4 O KeyID 26/8 O S Key 26/54 O S Lifetime 26/56 O S Request 26/55 O MN-HA Shared Key 26/58 O MN-HA SPI 26/57 O Allowed Differentiated Services 26/73 O Marking DNS Update Required 26/75 O AAA -> HA Always On 26/78 O AAA -> PDSN Service Option Profile 26/74 O AAA -> PDSN Remote IPv4 Address 26/59 O AAA -> PDSN Remote IPv6 Address 26/70 O AAA -> PDSN Remote Address Table Index 26/71 O AAA -> PDSN MN-AAA Removal Indication 26/81 O AAA -> PDSN NAS-Port-Type 61 O Note 5 PDSN -> AAA Carrier-ID 26/142 M PDSN -> AAA (M) Indicates Mandatory attribute (O) Indicates optional attribute Note 1: The password is configured between the HA and the RADIUS server. Note 2: For MIP4, this attribute is mandatory for the PDSN, and optional for the HA. Note 3:This is the IPv4 Address of the RADIUS server interface of the PDSN; at least one of NAS-IP-Address or NAS-IPv6-Address shall be included. Note 4: This attribute is included if the PDSN supports IPv6 addressing. Note 5: The values are as follows: 22 (IS-2000) [5-9] or 24 (HRPD) [15], depending on the service option number connected to the PDSN. Table 4 - Occurrence of RADIUS Attributes for MIP4 4.4.1 Dynamic Home Agent Assignment
11 12 13 14 15 16 17 18 19
The Home RADIUS server shall implement an HA selection algorithm to perform dynamic HA assignment. The implementation details of this algorithm are outside the scope of this document. The HA selection algorithm shall satisfy the four scenarios described in Section 4.1.3. The Home RADIUS server shall return the assigned HA Address in the HA attribute in the RADIUS AccessAccept message to the PDSN.
2 8 2H
4.4.2
MN-HA Shared Key Distribution
Upon receipt of a RADIUS Access-Request message from an HA containing the MN-HA SPI attribute, the RADIUS server shall send a RADIUS Access-Accept message containing the MN-
4. MIP4 Operation
33
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
HA shared key encrypted using a method based on RSA MD5 [RFC 1321] as described in Section 3.5 of [RFC 2868]. 4.4.3 IKE Pre-shared Secret Distribution Procedure
When the RADIUS Access-Request message is received from the PDSN containing the IKE Preshared Secret Request attribute, and IPsec services are authorized for the user, the Home RADIUS server shall distribute a key identifier and pre-shared secret for IKE to the PDSN using the Pre-shared Secret and KeyID attributes in the RADIUS Access-Accept message. The Home RADIUS server generates a pre-shared secret for IKE by processing the Home RADIUS IP address, FA IP address, and a timestamp as well as a secret key, known as the 'S' Key, through the HMAC-MD5 hashing algorithm. The 'S' Key is known between the Home RADIUS server and the HA. The 'S' Key is retrieved by the HA from the Home RADIUS server and has a configurable lifetime. The lifetime of the 'S' Key is a Home RADIUS local policy, and is based on the cryptographic strength of the S Key. The pre-shared secret is generated using the following formula: K = HMAC-MD5 (Home RADIUS IP address | FA IP address | timestamp, S) The Home RADIUS server hides pre-shared secrets for IKE using a method based on the RSA Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of [RFC 2868]. 4.4.4 DNS Address Assignment
The RADIUS server may include the DNS Server IP Address VSA in the RADIUS Access-Accept message in response to a RADIUS Access-Request message from the PDSN and/or the HA. If the RADIUS server includes the DNS Server IP Address VSA, it shall include a Primary and a Secondary DNS server IP addresses. The status of the M bit in the DNS Server IP Address VSA is controlled by the Home RADIUS server.
24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
4.5
MS Requirements
The MS may support MIP4 service. The MS shall access cdma2000 packet data service using the cdma2000 air interface [5-9] and [15]. 4.5.1 PPP Session
The MS shall use PPP as the data link protocol for MIP4. The MS may support multiple MIP4 Home Addresses over a single PPP session. 4.5.1.1 Establishment Same as Section 3.4.1.1.
2 8 3H
4.5.1.2 Termination Same as Section 3.4.1.2.

2 8 4H
If the MS tries to register and receives an RRP message with a failure code, it shall do one of the following: Retry MIP4 registration over the existing PPP session. If existing Simple IP or MIP4 sessions exist, give up on the failed MIP4 registration and continue using the existing sessions. Fall back to Simple IP by re-negotiating the PPP session. Terminate the PPP session.
4. MIP4 Operation
34
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
4.5.1.3 Authentication The MS should not use CHAP or PAP for MIP4. When the MS receives an LCP ConfigureRequest message requesting CHAP authentication, the MS should reply with an LCP ConfigureReject message requesting no PPP authentication. If the MS receives an LCP Configure-Request message without the authentication option it shall respond with an LCP Configure-Ack message as described in [RFC 1661]. If CHAP is performed, performance degradation will occur as the result of an unnecessary RADIUS server traversal, a FAC shall be performed regardless of whether or not CHAP is performed. The MS shall use the challenge received in the Agent Advertisement or RRP to compute the MN-AAA authenticator. As a further clarification to [RFC 3012] section 8 (SPI For RADIUS servers): If the challenge has fewer than 238 bytes, this algorithm includes the high-order byte in the computation twice, but ensures that the challenge is used exactly as is. Additional padding is never used to increase the length of the challenge; the input data is allowed to be shorter than 237 bytes long. 4.5.1.4 Addressing with IPCP If the MS uses MIP4 only, the MS shall not use the IP Address Configuration Option [RFC 1332]. On subsequent PPP session establishments while the MS intends to maintain a Home Address, 22 the MS shall omit the option . The MS shall not include the MIP4 Configuration Option in the IPCP Configure-Request messages sent to the PDSN.
2 1 F
The MS may implement [RFC 1877] 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 propose a DNS server address of zero to indicate an explicit request that the PDSN provides the DNS server address information in a Configure-Nak. The MS shall not use DHCP to request assignment of home IP addresses. 4.5.1.5 Compression Same as Section 3.4.1.7.
2 8 5H
4.5.1.6 PPP Framing Same as Section 3.4.1.8.

2 8 6H
4.5.2
MIP4 Registration
4.5.2.1 Agent Discovery Immediately after a PPP session is established, the MS may send Agent Solicitations. In this case, the MS should use the same procedure as described in Section 2.4 of [RFC 2002]. If the MS does not have a Home Address, the MS shall use zero in the Source IP Address field of the IP packet that contains the Agent Solicitation. The MS shall support [RFC 3012]. 4.5.2.2 Registration Messages Upon receiving Agent Advertisements from the PDSN, the MS shall send an RRQ message.
22
If the MS that uses Mobile IP uses the IP Address Configuration Option [RFC 1332] to indicate the Home Address, the PDSN will consider it as an MS using Simple IP service and send a NAK with an alternative address to the MS. The MS will respond with an IP Configure Request with the alternative address.
4. MIP4 Operation
35
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7
The MS may request a non-zero home IP address belonging to its home IP network in the RRQ or indicate that the HA should dynamically assign it an IP address. If the MS requests a dynamic HA assignment, the MS shall set the HA Address to either 255.255.255.255 or 0.0.0.0. However, the MS should use 255.255.255.255. If the MS requests a static or already allocated HA Address, it should set the HA Address accordingly. The Home and HA Address allocations are based on the scenarios described in Section 4.1.3.
2 8 7H
Scenario 1
To request a dynamic Home Address and a dynamic HA assignment, the MS shall set the Home Address field to 0.0.0.0 and the HA Address field to 255.255.255.255 or 0.0.0.0 in the RRQ message. To request a dynamic HA assignment only while requesting a previously assigned Home Address, the MS shall set the Home Address field to the desired Home Address, and the MS shall set the HA Address field to 255.255.255.255 or 0.0.0.0 in the RRQ message. If the MS receives a failed RRP, the MS may retry a MIP4 registration under any of the scenarios. To request a dynamic Home Address allocation only while requesting a previously assigned HA, the MS shall set the Home Address field to 0.0.0.0 and the MS shall set the HA Address field to the desired HA Address in the RRQ message. If the MS receives a failed RRP, the MS may retry a MIP4 registration under any of the scenarios. When the MS is not requesting dynamic allocation of either a Home Address or an HA Address, the MS shall set the Home Address and HA Address fields with the desired IP addresses in the RRQ message. If the MS receives a failed RRP, the MS may retry a MIP4 registration under any of the scenarios. Table 5 - MS Registration Scenarios
Scenario 2
Scenario 3
Scenario 4
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
While requesting a dynamic Home Address assignment, the MS shall use zero in the Source IP Address field of the IP packet that contains the MIP4 RRQ. In this case the NAI is used to identify the MS. During MIP4 re-registrations, the MS shall use the same HA Address and the Home Address that were assigned to it during the initial MIP4 registration. Upon receipt of an RRP message with successful registration indication (code 0) during initial registration, the MS shall accept the dynamically assigned HA Address contained in the RRP message, even if it is different from the HA Address provided in the RRQ message. If the MS had set up a Simple IP session and decides to run MIP4 simultaneously using the FA function in the PDSN, it shall send an Agent Solicitation to the PDSN. Upon receiving an Agent Advertisement, the MS shall register with the PDSN and shall not use collocated CoA. The MS may also register directly with the HA using a collocated CoA obtained from Simple IP IPCP negotiation. If the MS desires reverse tunneling, the MS shall set the T-bit in the RRQ message. The MS shall not set the 'V' bit in the RRQ message. 4.5.2.3 MIP4 Extensions The MS shall include the MN-NAI Extension [RFC 2794], MN-HA Authentication Extension [RFC 2002], MN-FA Challenge Extension [RFC 3012], and MN-AAA Authentication Extension [RFC 3012] in the RRQ message. Because advertisements are rarely sent to save air resources, when the MS performs re-registration, the MS shall use the challenge value contained in the last received RRP as described in [RFC 3012].
4. MIP4 Operation
36
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
The MS shall compute the MN-AAA Authentication Extension, according to [RFC 3012], based on the shared secret the MS has with the Home RADIUS server. The MS shall compute the MN-HA Authentication Extension, according to [RFC 2002], based on the shared secret the MS has with the HA. Computation of the extension shall include the Type and SPI field of the MN-HA Authentication Extension itself. The MS may use the same shared-secret or different shared secrets in the computation of the MN-AAA Authentication Extension and MN-HA Authentication Extension. This is coordinated between the MS and its home network. The MS may use DHCP to request configuration parameters such as DNS addresses [RFC 2132], SIP server addresses [RFC 3361] and/or BCMCS controller addresses [RFC 4280], etc. If the MIP4 MS wants to receive local configuration information, it shall negotiate encapsulated delivery style with the PDSN [RFC 3024]. 4.5.2.4 Private Network Support If the MS wants private network access through MIP4, the MS shall use reverse tunneling. 4.5.2.5 Termination When the MS wishes to terminate a MIP4 session, the MS may send a MIP4 RRQ to the HA with a Registration Lifetime of zero to gracefully close the MIP4 session before terminating the packet 23 data service with the RAN . For the case of power-down registration [5-9], the MS shall not send an LCP Terminate-Request message to the PDSN and shall not send a MIP4 RRQ with Registration Lifetime of zero to the HA after receiving from the PDSN a 3GPP2 vendor specific Version/Capability packet with C3=1 (see Section 8).
2 2 F 2 8 8H
4.5.2.6 DNS address Assignment If the MS receives at least one DNS Server IP Address NVSE (as defined in section 4.6) in the MIP4 Registration Reply message, then the MS may use the DNS server IP address in the NVSE instead of the DNS server IP address received during IPCP. If the MS receives multiple DNS Server IP Address NVSEs, it may select an appropriate entity (i.e., HAAA/VAAA or HA), for acquiring the DNS information, based on its internal policy.
2 8 9 H
If Reverse Tunneling is applied for the MIP4 session, and the MIP4 Registration Reply includes at least one DNS Server IP Address NVSE with the entity-type field set to either 1 or 3 and the MS supports the DNS Server IP Address NVSE, then the MS shall use the DNS server IP addresses provided in the MIP4 Registration Reply. If the entity type is 3, the DNS information provided by the HA may have precedence over that provided by the HAAA or the VAAA. 4.5.3 MS Requirements for GRE Tunneling Support
If the MS is capable of supporting GRE encapsulation, it should set the G bit in the Flags field in the MIP4 Registration Request message per [RFC 2002].
35 36 37 38 39
4.6
DNS Server IP Address NVSE
The NVSE contains a Primary and a Secondary DNS IP address and may be included in the MIP4 Registration Reply message from the HA and/or the PDSN. The format of the NVSE shall be as follows: 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
23
The MS should send the RRQ with a lifetime of zero to free resources such as public addresses in the HA.
4. MIP4 Operation
37
3GPP2
X.S0011-002-D v1.0
Type Vendor/Org-ID Vendor-NVSE-Type Length .. ..

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Length
Reserved Sub-Type(=1) Secondary DNS IPv4 address Unused
Entity-Type Primary DNS IPv4 address Sub-Type(=2) Length
Figure 6- NVSE for DNS Server IP Address Type: 134
Length = 22 Vendor/Org-ID: 5535 Vendor-NVSE-Type: 17 Vendor-NVSE-Value: This field is formatted as follows: Entity-Type: In the Registration Reply message this field identifies the network entity that has provided the DNS information to the mobile station so that it is aware of the source of the DNS information. Currently the following types are defined:
HAAA = 1 VAAA = 2 HA = 3
Sub-Type (=1): This field indicates that the associated value field contains the Primary DNS server IP address.
Length: 6 Vendor-Value: IPv4 address of primary DNS server.
Sub-Type (=2): This field indicates that the associated value field contains the Secondary DNS server IP address.
Length: 6 Vendor-Value: IPv4 address of secondary DNS server.
4. MIP4 Operation
38
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
MIP6 Operation
This section describes the requirements and procedures for MIP6 operation [RFC 3775] [RFC 4285] and [RFC 4283]. In this document, MIP6 refers to a service in which the user is able to maintain a persistent IPv6 address even when handing off between RNs connected to different PDSNs. MIP6 provides the user IPv6 routing service to a public IPv6 network and/or secure IPv6 routing service to private networks. In this document, MIP6 operates in two distinct modes of operation, Bi-directional tunnel mode and Route Optimized mode. In order for the MS to authenticate and authorize with the home network, the MS includes the MN-NAI mobility option [RFC 4283] and the Mobility Message authentication option [RFC 4285]. This type of authentication and authorization allows the MS to perform Home Registration without IPsec. The HA can authenticate and authorize the MS based on identity credentials that are included in the BU such as the MN-HA mobility message authentication option or the MN-AAA mobility message authentication options [RFC 4285]. For an initial home registration, the MS uses the MN-AAA mobility message authentication option. The basic message flows for the authentication protocol based MIP6 Home Registration is shown in Figure 7.
2 9 0 H
MS
PDSN
HA
Home RADIUS
MS establishes link layer and bootstraps [HL/HA/HoA]
Use assigned HoA or autoconfig HoA
BU (IPv6 header | Destination Option Header (HAO) | Mobility Header (MH Type 5, MN-NAI Mobility option, Mesg ID option, MN-AAA auth option
) Access-Request
Access-Accept e HA performs proxy DAD for HoA
BA (IPv6 header | RH Type 2 | Mobility Header (MH Type 6, ID option, MN-HA auth option ))
17 18 19 20
NAI option, Mesg
Figure 7- The Initial MIP6 Home Registration with MN-AAA mobility message authentication option
5. MIP6 Operation
39
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
a) The MS performs Link Layer establishment. Optionally, the MS acquires bootstrap information from the Home RADIUS server (via the PDSN). The MS uses stateless DHCPv6 [RFC 3736] to obtain the bootstrap information. b) If the MS is assigned a new HoA in step (a) the MS begins to use it. If no HoA was assigned at step (a), the MS generates (auto-configures) an IPv6 global unicast address based on the Home Link Prefix(HL) information received at step (a). c) At this step the MS sends a Binding Update to the selected Home Agent. The MS sets the Link-local Compatibility (L) bit to 1 if the MS wants the HA to defend (through proxy DAD) its link-local address in addition to the global address created with the same IID. The fields in this BU are set as per [RFC 4283] and [RFC 4285]. In the BU, the MS includes the MN-AAA mobility message authentication option. d) The HA extracts the NAI, authenticator etc. from the BU and sends a RADIUS Access Request message to the Home RADIUS server. This step always occurs for the initial registration regardless of whether the MS is using an auto-configured HoA. e) The Home RADIUS server authenticates and authorizes the user and sends back a RADIUS Access-Accept to the HA indicating successful authentication and authorization. At this step the Home RADIUS server also distributes the Integrity Key (IK) to the HA for subsequent MN-HA processing. f) At this step the HA performs replay check with the Mesg-ID mobility option in the received BU. The HA optionally performs proxy Duplicate Address Detection (DAD) on the MSs home address (global) using proxy Neighbor Solicitation as specified in [RFC 2461].
g) Assuming that proxy DAD, if executed, is successful, the HA sends back a Binding Acknowledgment to the MS. In this BA message the HA includes the MN-HA mobility message authentication option, MN-NAI mobility option and the Mesg ID mobility option. The MN-HA authenticator is calculated based on the Integrity Key (IK) that was derived in the Home RADIUS server and sent to the HA at step (e). For the subsequent binding updates, the MS uses the MN-HA mobility message authentication option in BU. This includes binding updates sent to refresh an existing binding cache entry or to update an existing binding cache entry in the event of inter PDSN mobility. The subsequent Binding Updates and the resulting Binding Acknowledgements include MN-HA mobility message authentication option. The MN-HA authenticator is computed using the Integrity Key (IK) that was generated during the initial Home Registration. The HA and the MS cache the IK for the duration of the MIP6 session. The Call flow is shown in Figure 8.
2 9 1 H
5. MIP6 Operation
40
3GPP2
X.S0011-002-D v1.0
MN
HA
BU (IPv6 header | Destination Option Header (HAO) | Mobility Header (MH Type 5, MN-NAI mobility option, Mesg-ID option, MN-HA auth option )
optional
BA (IPv6 header | RH Type 2
| Mobility Header (MH Type 6, auth option ))
NAI option, Mesg-ID option, MN-HA
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Figure 8- MIPv6 Home authentication option
Registration
with
MN-HA
mobility
message
a) The MS sends a BU to the HA. The BU includes the Mesg-ID mobility option and the MN-HA mobility message authentication option. The BU includes the MN-NAI mobility option. The MN-HA mobility message authentication option is computed with the IK. b) The HA authenticates the BU by verifying the authentication data of the MN-HA mobility message authentication option data using the stored IK. The HA performs replay check using the Mesg-ID mobility option. If both authentication and replay check succeeds, the HA sends a BA back to the MS. The BA contains the MN MNHA mobility message authentication option and the Mesg-ID mobility option. The BA contains the MN-NAI mobility option.
15 16 17 18 19 20 21 22 23 24 25 26 27 28
5.1
The common requirements for the network elements (e.g., Home Agent, Home RADIUS server, PDSN and MS) for MIP6 operation are described in this section. 5.1.1 PPP Session
From a packet data session setup perspective, the MIP6 access is equivalent to a Simple IPv6 access at the PDSN. The role of the PDSN is only a NAS. This is different than the case of MIP4 access where the PDSN plays the role of the Foreign Agent. Currently for Simple IPv6 access, CHAP/PAP is used during PPP setup. Therefore the same authentication and authorization procedure (CHAP/PAP) is used during the PPP setup for MSs using MIP6. The MS and the PDSN should perform the procedures defined in [Chapter 2], section 3.1. The PDSN caches the MIP6 bootstrap information that is received from the Home RADIUS server in the RADIUS Access-Accept message during Simple IPv6 access authentication. The MS obtains this bootstrap information using stateless DHCPv6 Information-Request message by including a Client Identifier option.
5. MIP6 Operation
41
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
In the case of MIP6 bootstrapping with DHCPv6, the MS includes the Client Identifier option (set 24 to DUID-EN with access authentication NAI ) as the Identifier to identify which bootstrap information should be sent.
2 3 F
5.1.2
MIP6
The following standards shall be used for MIP6 operation with any limitations or extensions described in this document: 5.1.3 [RFC 3775], Mobility Support in IPv6, [RFC 4283], Mobile Node Identifier Option for Mobile IPv6 [RFC 4285], Authentication Protocol for Mobile IPv6
Summary of PDSN and MS Behavior for Dynamic HA/HL/HoA Discovery via MIP6 Bootstrapping
The following table defines the behavior of: (1) The PDSN in converting the RADIUS 3GPP2 Vendor-specific MIP6 bootstrapping VSA's received from the RADIUS Home server to DHCP 3GPP2 Vendor-specific options and (2) The MS upon receiving of the corresponding DHCP 3GPP2 Vendor-specific MIP6 bootstrapping options. RADIUS VSAs received by the PDSN Attribute A: HL prefix (which included prefix length information already): DHCP 3GPP2 Vendor-specific MIP6 bootstrapping options get generated by PDSN and sent to the MS: Assigned Home-Link prefix (Optioncode 2) MS station behavior
HoA: If provisioned with a HoA and the HoA is valid over the assigned HL, the MS may use that HoA. Otherwise, the MS shall autoconfigure the HoA. HA: The MS shall discover the HA via Dynamic Home Agent Address Discovery procedure as defined in [RFC 3775].
Attribute A (HL prefix) and Attribute B (HA):
Assigned Home Agent Address (Option-code 1) and Assigned Home-Link prefix (Optioncode 2)
HoA: If provisioned with a HoA and the HoA is valid over the assigned HL, the MS may use that HoA. Otherwise, the MS shall autoconfigure the HoA.
24
The NAI is 72 octets max.
5. MIP6 Operation
42
3GPP2
X.S0011-002-D v1.0
RADIUS VSAs received by the PDSN
DHCP 3GPP2 Vendor-specific MIP6 bootstrapping options get generated by PDSN and sent to the MS:
MS station behavior
HA: Shall use the assigned HA. Attribute C: HoA with HL prefix length info Assigned Home-Link prefix (Optioncode 2) and Assigned Home Address (Option-code 3) HoA: Shall use the assigned HoA. HA: The MS shall discover the HA via Dynamic Home Agent Address Discovery procedure as defined in [RFC 3775]. HoA: Shall use the assigned HoA HA: Shall use the assigned HA
Attribute B (HA) and Attribute C (HoA, HL prefix length):
Assigned Home Agent Address (Option-code 1) and Assigned Home-Link prefix (Optioncode 2) and Assigned Home Address (Option-code 3)
Any other combination of Attributes A, B, C
None (PDSN treats this as an error case and does not send any DHCP MIP6 bootstrapping option to the MS)
The MS may use provisioned information and/or Dynamic Home Agent Address Discovery procedure as defined in [RFC 3775] to configure HoA, HA and HL prefix.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Table 6 - MIP6 Bootstrapping Scenarios Note: The Dynamic Home Agent Address Discovery (DHAAD) procedure defined in [RFC 3775] requires the use of ICMP messages. If the MS is provisioned with HoA and HA addresses for a home network, then it should be able to use these addresses. If the MS bootstraps and receives an HA and/or HoA address and/or HL information for a home network as specified in Table 6, the MS shall use that information when registering with that home network as specified in Table 6. .
2 9 2 H 2 9 3H
5.1.3.1 Dynamic Home Agent and Home Link Prefix Assignment via MIP6 Bootstrap The Home RADIUS server allocates the Home Agent and the Home Link Prefix to an MS during access authentication (PPP setup) using MIP6 Home Agent (Attribute B) VSA and MIP6 Home Link Prefix (Attribute A) VSA. The MS obtains the assigned HA information using stateless DHCPv6 procedures as described below.
5. MIP6 Operation
43
3GPP2
X.S0011-002-D v1.0
MS
PDSN
Home RADIUS Server
Begin Access-Auth Access-Request
a b
Assign HA and HL Access-Accept (HA and HL)
store HA and HL info
Complete Access-Auth
Information-Request [O-R-O, Cid option] g Reply [HA and HL, vendor option] h
1 2 3 4 5 6 7 8 9 10 11 12 13
Figure 9- Flow diagram for Dynamic Home Agent Assignment a) The MS begins the Access Authentication procedure (e.g., CHAP/PAP). b) The PDSN sends Access-Request to the Home RADIUS server. c) The Home RADIUS server verifies the users profile and detects that the user is a MIP6 subscriber. The Home RADIUS server assigns an HA and a Home Link Prefix for the MS. d) The Home RADIUS server includes a Home Agent address in the MIP6 Home Agent (Attribute B) VSA. The Home RADIUS server also includes a Home Link Prefix in the MIP6 Home Link Prefix (Attribute A) VSA. e) The PDSN receives the HA and HL information VSAs from the Home RADIUS server and stores them. f) The Access Authentication procedure completes at this step.
5. MIP6 Operation
44
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
g) The MS requests MIP6 bootstrap information using the DHCPv6 Information-request message [RFC 3736] sent to the PDSN. In this message the MS includes its access authentication NAI in the Identifier field of the Client Identifier Option with DUID-EN (enterprise number set as 5553). h) The PDSN looks up the appropriate record based on the Client Identifier and replies back to the MS [RFC 3736] with the options that were requested, attaching the HA information in a DHCP 3GPP2 Vendor Option with a Vendor-Specific Option-Code=1. It also attaches the HL information in a DHCP 3GPP2 Vendor Option with Vendor-Specific Option-Code=2. The detailed node requirements for Dynamic Home Agent Assignment are described in sections 5.2, 5.3 and 5.5 of this document. 5.1.3.2 Dynamic Home Link Prefix Discovery via MIP6 Bootstrap The Home Link Prefix information is delivered to the PDSN during the PPP setup phase. The Home RADIUS server selects the Home Link Prefix and includes it in a MIP6 Home Link Prefix (Attribute A) VSA in the Access-Accept message. The Home Link Prefix information is delivered to the MS when the MS sends a DHCPv6 Information-Request message.
5. MIP6 Operation
45
3GPP2
X.S0011-002-D v1.0
MS
PDSN
Home RADIUS Server
a b
Assign HL Access-Accept (Home-Link prefix )
store HL info
Complete Access-Auth Information-Request [O-R-O, Cid option]
g Reply [HL vendor option] h

1 2 3 4 5 6 7 8 9 10 11 12 13 14
Figure 10- Bootstrap of Home Link Prefix a) The MS begins the Access Authentication procedure (e.g., CHAP/PAP). b) The PDSN sends Access-Request to the Home RADIUS server. c) The Home RADIUS server detects that the user is a MIP6 subscriber by verifying with the users AAA profile. The Home RADIUS server assigns a HL prefix for the MS. d) The Home RADIUS server includes the assigned Home Link Prefix in the RADIUS 3GPP2 MIP6-Home Link Prefix (Attribute A) VSA. e) The PDSN receives the HL information from the Home RADIUS server. The PDSN stores the HL information. f) The Access Authentication procedure completes at this step. g) The MS requests the MIP6 bootstrap information using the DHCPv6 Information-request message [RFC 3736] sent to the PDSN. In this message the MS includes its access
5. MIP6 Operation
46
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
authentication NAI in the Identifier field of the Client Identifier Option with DUID-EN (enterprise number set as 5553). h) The PDSN looks up the appropriate record based on the Client Identifier and replies back to the MS [RFC 3736] with the options that were requested and attaches the HL information in a DHCP 3GPP2 Vendor-specific Option with a Vendor-Option-Code=2. With the assigned Home Link Prefix, the MS performs dynamic Home Agent Address discovery by using the procedure defined in [RFC 3775] section 5.3. The MS also auto-configures a Home Address with the assigned Home Link Prefix. 5.1.3.3 Dynamic Home Address Configuration In this document, the MS is allowed to perform stateless auto-configuration of its Home Address based on the Home Link Prefix that was assigned to it by the Home RADIUS server. Alternatively, the MS may be assigned a Home Address by the Home RADIUS server. In either case, the Binding Cache Entry (BCE) Lifetime is limited by the home-link prefix lifetime at the HA. This is controlled by the HA via the lifetime field in the Binding Acknowledgement message sent to the MS. The MS can request an extension to the HoA/BCE lifetime by sending a Binding Update to the Home Agent. Once the BCE expires, the MS shall not use the HoA from the expired session. The MS shall initiate the bootstrapping procedure when starting a new MIP6 session if the MS does not have the registration information (i.e., HL Prefix, HoA, HA) provisioned. If the Binding Refresh Advice mobility option is present in the BA message [RFC 3775], the Refresh Interval field in the option shall be set to a value less than the lifetime value being returned in the Binding Acknowledgement. This indicates that the mobile node should attempt to refresh its home registration at the indicated shorter interval. The HA shall still retain the registration for the BCE lifetime period, even if the mobile node does not refresh its registration within the refresh period. However, if the mobile node does not refresh the binding by sending a new BU to the HA before the BCE lifetime expires, the HA shall delete the BCE. 5.1.3.3.1 Home Address Assignment by Home RADIUS server
5. MIP6 Operation
47
3GPP2
X.S0011-002-D v1.0
MS
PDSN
Home RADIUS Server
a b
Assign HoA Access-Accept (HoA info )
store HoA info
Complete Access-Auth Information-Request [O-R-O], Cid option
g Reply [HoA vendor option] h

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Figure 11- Home Address Assignment by Home RADIUS server a) The MS begins the Access Authentication procedure (e.g., CHAP/PAP). b) The PDSN sends Access-Request to the Home RADIUS server. c) The Home RADIUS server detects that the user is a MIP6 subscriber by verifying the user's profile. If the user is authorized for MIP6 service and the Home Network's policy dictates that the Home Address should be assigned, the Home RADIUS server assigns a HoA to the MS. d) The Home RADIUS server includes the Home Address information and the HL Prefix Length in the RADIUS 3GPP2 MIP6-Home Address (Attribute C) VSA sent in the RADIUS Access-Accept message. e) The PDSN receives the HoA information from the Home RADIUS server. The PDSN stores the HoA information. f) The Access Authentication procedure completes at this step.
5. MIP6 Operation
48
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11
g) The MS requests the MIP6 bootstrap information using the DHCPv6 Information-request message [RFC 3736] sent to the PDSN. In this message the MS includes its access authentication NAI in the Identifier field of the Client Identifier Option with DUID-EN (enterprise number set as 5553). h) The PDSN looks up the appropriate record based on the Client Identifier and replies back to the MS [RFC 3736] with the options that were requested and attaches the HoA information in a DHCP 3GPP2 Vendor-specific Option with a Vendor-Option-Code=3 for HoA and Vendor-Option-Code= 2 for HL Prefix Length. The detailed node requirements for dynamic Home Address assignment by the Home RADIUS server are described in sections 5.2, 5.3, 5.4 and 5.5 of this document.
2 9 4H 2 9 5H 2 9 6 H 2 9 7H
5.1.3.3.2
MS
Home Address Auto-configuration by the Mobile Station

PDSN Home RADIUS
PPP setup
CHAP/PAP auth
Information-Request [O-R-O], Cid option b Reply [HL/HA/HoA vendor option]
MN autoconfigures the HoA
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Figure 12- Home Address Auto-Configuration a) The MS performs PPP link establishment using CHAP or PAP. b) The MS requests the MIP6 bootstrap information using the DHCPv6 Informationrequest message [RFC 3736] sent to the PDSN In this message the MS includes its access authentication NAI in the Identifier field of the Client Identifier Option with DUID-EN (enterprise number set as 5553). c) The PDSN looks up the appropriate record based on the Client Identifier and replies back to the MS [RFC 3736] with the MIP6 bootstrap options. d) Upon receiving the MIP6 bootstrap information from the PDSN, the MS checks whether a HoA is included or not. If HoA is not included, the MS auto-configures its HoA in a stateless manner as described in [RFC 2462], using the Home Link Prefix information from the Assigned Home Link Prefix DHCP 3GPP2 Vendor-specific option. The detailed node requirements for dynamic Home Address via IPv6 stateless address autoconfiguration at the mobile station are described in sections 5.2, 5.3, 5.4 and 5.5 of this document.
2 9 8 H 2 9 9H 3 0 0H 3 0 1H
5. MIP6 Operation
49
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
5.1.4
Mobile Station to Home Agent Security for BU and BA
For the MS-to-HA security, the authentication protocol based IPv6 mobility as defined in [RFC 4285] is supported. Consequently, securing BU and BA messages between the MS and the HA is done as described by methods in [RFC 4285] using the MN-AAA shared secret or the derived shared secret (Integrity Key (IK)). IK is derived during the initial Home Registration at the Home RADIUS server and is used as an MN-HA key for subsequent BU/BA messages exchanged between the MS and the HA. The IK derivation and distribution mechanisms are explained in section 5.4.1. The Home RADIUS server generates the IK, then it distributes it to the HA in an encrypted form. The MS generates the same key (IK) using the same input, seed and the same algorithm used by the Home RADIUS server. The MN-NAI mobility option defined in [RFC 4283] is included along with the initial BU to enable the HA to perform RADIUS procedures. The MN-NAI mobility option is required in all subsequent BUs.
3 0 2 H
5.1.4.1 Replay Protection of Binding Update and Binding Acknowledgement Replay protection is provided using the Mesg ID option as specified in [RFC 4285]. Timestamp based replay protection is used in this document for the both MN-AAA and MN-HA mobility message authentication options.
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
5.2
PDSN Requirements
3 0 3 H
The PDSN shall support IPv6 operation. The PDSN acts as the NAS for Simple IPv6 access. The PDSN shall support Simple IPv6 operational requirements as specified in section 3.2. In addition, the PDSN shall support the MIP6 bootstrapping as specified in this section. If the MS-PDSN Version Feature Indication (see section 8) is used, and the MS signaled that it does not support MIP6 (C3 bit set to 0), then the PDSN shall not provide MIP6 bootstrapping information if received from the Home RADIUS server. If the MS-PDSN Version Feature Indication is used, and the MS signaled that it supports MIP6 (C3 bit set to 1), then the PDSN shall provide the MIP6 bootstrapping information to the MS as described in this section. The PDSN shall support DHCPv6 stateless server function per [RFC 3736]. The PDSN shall also support the 3GPP2 DHCPv6 vendor options to communicate with the MS to carry MIP6 specific bootstrap information such as Home Link Prefix and Home Agent address and optionally the HoA. This information is delivered to the PDSN during the access authentication (PPP establishment) phase from the Home RADIUS server. 5.2.1 PDSN Requirement to Support Stateless DHCPv6 to Convey MIP6 Bootstrap Info
The PDSN shall support the Stateless Dynamic Host Configuration Protocol service for IPv6 as specified in [RFC 3736]. In order to send the MIPv6 bootstrap info, the PDSN shall act as a stateless DHCPv6 server. Upon receiving an Information-Request from the MS identified by the NAI in the Client Identifier Option, if the NAI is the same as the access authentication NAI of the MS, the PDSN shall send the MIPv6 bootstrap information received from the Home RADIUS server to the MS along with other options that the MS requested, if available at the PDSN. The PDSN shall construct a Reply message by setting the "msg-type" field to Reply, and copying the transaction ID from the Information-Request message into the transaction-id field. The message syntax for the Reply is shown below:
0 Options 8 Message-Type 16 Transaction-ID 31
43
5. MIP6 Operation
50
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6
In the Reply message the PDSN shall include 3GPP2 Vendor Specific Information options along with other requested options if the PDSN supports those requested options. These vendor specific information options are formatted according to [RFC 3315]. As discussed above, the option codes for the 3GPP2 information (Home Link Prefix, Home Agent address and Home Address) and corresponding length fields for each 3GPP2 specific option code are assigned in the Vendor Specific Information option of the Reply message as shown below:
0 8 OPTION-VENDOR-OPTS Enterprise Number Option Code 1 Data 1 Option Code 2 Data 2 ...... Length 2 Length 1 16 Length 31
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
OPTION_VENDOR_OPTS: Length: variable 5535 Enterprise Number: Length 1: Data 1: Length 2:
17
Option Code 1: Assigned Home Agent Address 16 octets. + 4 octets Assigned Home Agent Address > 5 octets
Option Code 2: Assigned Home Link Prefix with prefix length Data 2: HL prefix length and the Assigned Home Link Prefix (upper order bits) for the MS. If the Assigned Home Link Prefix length is not an integral multiple of 8, additional lower order bits of zeros are appended by the sender to make this field octetaligned. The actual number of bits in the Assigned Home Link Prefix is indicated by the HL prefix length field. 1 HL prefix length Assigned Home Link Prefix 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
Assigned Home Link Prefix Assigned Home Link Prefix

22 23 24 25 26
Figure 13 - Layout of the Data 2 field in the Option-Code 2. Option Code 3: Assigned Home Address Length 3: Data3: 16 octets + 4 octets Assigned Home Address
Other 3GPP2 vendor specific Option Codes are reserved.
5. MIP6 Operation
51
3GPP2
X.S0011-002-D v1.0
1 2 3
5.2.2
Ingress Address Filtering
Since the ingress filtering mechanism for MIP6 packets is same as the one for Simple IPv6, the PDSN shall perform simple IPv6 Ingress address filtering procedures as specified in section 3.2.3
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
5.3
Home Agent Requirements

[RFC 3775], Mobility Support in IPv6 (to the exception of the security of the MS to HA signaling), [RFC 4283], Mobile Node Identifier Option for Mobile IPv6 [RFC 4285], Authentication Protocol for Mobile IPv6
The HA shall support the following additional RFCs for MIP6 support:
5.3.1
Home Agent Requirements to Support Dynamic Home Agent Assignment
The HA shall support Dynamic Home Agent Address Discovery as defined in [RFC 3775]. The HA shall process Binding Updates that contain Mobility message authentication options (MNHA or MN-AAA), Mesg-ID option and the MN-NAI mobility option. If the MN-NAI mobility option is not included in the BU of an MS, the HA shall treat it as an error and shall reject the BU. 5.3.2 Home Agent Requirements to Support Dynamic Home Address Configuration
The Home Agent shall support Home Addresses that are either assigned by the Home RADIUS server or auto-configured by the Mobile Station as long as the use of the Home Address by the user (NAI) is authorized by the Home RADIUS server and the optional proxy Duplicate Address Detection procedure on the Home Link passes. Upon receiving a Binding Update containing Mobility Message authentication options (MN-HA or MN-AAA), Mesg-ID option, MN-NAI mobility option and a Home Address Option (HAO) with a unicast IPv6 address in the Home Address field, the HA shall process the Binding Update . The HA may perform proxy Duplicate Address Detection for the requested Home Address as per [RFC 3775]. The lifetime in the Binding Acknowledgement is controlled by local configuration at the Home Agent or it is set to the valid-lifetime remaining for the home-link prefix ([RFC 2461], section 4.6.2). When the HA receives a BU from the MS (MN-NAI) for which there is an ongoing MIP6 session, the HA shall treat this BU as an initial registration if the BU contains MN-AAA mobility message authentication option instead of MN-HA mobility message authentication option. In this case, the HA shall overwrite the BCE for that MS and accepts the BU. 5.3.3 Multiple Registrations
The HA shall support Multiple home registrations with the same NAI but different Home Addresses. The Binding Cache Entry (BCE) in the HA shall be indexed with the NAI and the Home Address of the MS at a minimum. The HA shall rely on the Home RADIUS server to authorize a user to perform multiple simultaneous home registrations on the same home link. The MS is allowed to send more than one Binding Update for home registration with different HoAs and with same or different CoAs. Whether these home registrations will be allowed or disallowed depends on the Home Network providers policy. If Multiple registrations are not authorized by the Home Network's policy, the HA shall send a BA with Status Code set to 129 (Administratively prohibited) [RFC 3775].
5. MIP6 Operation
52
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
5.3.4
Home Registration Support
In this document the HA shall support the Authentication Protocol [RFC 4285] based Home Registration for Home Registration. The following sub-sections describe the detailed HA requirement. 5.3.4.1 Authentication Protocol Based Home Registration Support The HA shall support MIP6 authentication protocol as defined in [RFC 4285] and the MN-NAI mobility option as defined in [RFC 4283]. Upon receiving the initial BU, the HA shall perform authentication of the BU based on the MN-AAA mobility message authentication option and the MN-NAI mobility option. Upon receiving the subsequent BU for the MN (MN-NAI), the HA shall perform authentication of the BU based on the MN-HA mobility message authentication option. 5.3.4.1.1 Authentication with MN-AAA mobility Message Authentication Option
For an initial home registration, the MS uses the MN-AAA mobility message authentication option. In this case, the HA shall act as a RADIUS client in accordance with [RFC 2865]. Upon receiving the initial MIP6 Binding Update, the HA shall communicate the users MN-AAA authentication information to the Home RADIUS server with a RADIUS Access-Request message. On receipt of the BU from the MS, if SPI in the MN-AAA mobility message authentication option is set to HMAC_CHAP_SPI, the HA shall create a RADIUS Access-Request message as described in Table 7. If the SPI in the BU is not set to HMAC_CHAP_SPI the HA shall reject the BU using Status Code 129 (Administratively prohibited) [RFC 3775]
3 0 4 H
Upon receiving a RADIUS Access-Accept from the Home RADIUS server, the HA shall send a BA to the MS including an MN-HA mobility message authentication option if the replay check (Mesg-ID option verification) is successful. If the replay check fails, the HA shall send a BA back to the MS with MN-HA mobility message authentication option and an error code MIPV6-IDMISMATCH. The MN-HA authenticator shall be calculated by the HA based on the distributed Integrity Key (IK) received in the RADIUS Access-Accept message from the Home RADIUS server. The MN-HA authenticator calculation is as follows: Authenticator = First (96, HMAC_SHA1 (IK, Mobility_Data)). Where: Mobility_Data = care-of address | home address | Mobility header up to and including the SPI field in MN-HA mobility message authentication option. For key derivation and distribution details of IK, please refer to section 5.4.1.
3 0 5 H
Upon receiving a RADIUS Access-Reject message from the Home RADIUS server due to MNAAA authenticator verification failure, the HA shall silently discard the BU since the HA does not have a MN-HA shared secret (IK) at this time. The HA shall cache the Integrity Key (IK) as the MN-HA shared secret for each of the registered NAI and HoA pair to process BUs when BCE lifetime > 0. The IK is cached in a security association in the BCE and is associated with SPI=5. Thus, SPI=5 is associated with the dynamically derived security association between MS and HA 5.3.4.1.2 Authentication with MN-HA Mobility Message Authentication Option
For the subsequent binding updates, the MS uses the MN-HA mobility message authentication option in BU. In this case, the MN-HA shared secret shall be set to the IK, which is derived during the initial BU. Upon receiving a BU, the HA shall process it as per [RFC 4285]. The SPI value should be set to 5 (3GPP2 specific) in the BU and the BA containing MN-HA mobility message authentication option, when the security association is dynamically derived
5. MIP6 Operation
53
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
upon receiving IK from the Home RADIUS server. This value indicates that upon receiving the BU or the BA with the MN-HA mobility message authentication option, the HA and the MS respectively should look for the security association indexed by the SPI in the BCE corresponding to the NAI and the HoA. The security association shall remain valid as long as the BCE is valid and shall be removed/deleted when the BCE is removed. If the initial BU (the BU is considered initial when the HA does not have a BCE for the NAI and the HoA pair) contains MN-HA mobility message authentication option, the HA shall reject the BU for the initial Home Registration. In this case the HA shall use Status Code 129 (Administratively prohibited) [RFC 3775]. 5.3.5 Return Routability Support for Route Optimization
The Home Agent shall support Return Routability (RR) for Route Optimization as specified in [RFC 3775] with the exception that IPsec is not used to protect the RR messages. These messages may be protected on a hop-by-hop basis through the operators network. 5.3.6 HA Requirement as a RADIUS Client
The HA shall support RADIUS client as specified in [RFC 2865] and RADIUS Accounting as specified in [RFC 2866] and section 5.6. The HA shall send a RADIUS Access-Request to the Home RADIUS server when it receives a BU containing the MN-AAA mobility message authentication option to request authentication and authorization of the user by the RADIUS infrastructure. The HA shall include the following attributes and VSAs: User-Name attribute (NAI from BU) MIP6-CoA VSA (CoA from BU). MIP6-HoA VSA (HoA from BU). MIP6-Authenticator (Authentication data of the MN-AAA mobility message authentication option from BU). MIP6-MAC-Mobility-Data VSA (MAC_Mobility_Data computed). MIP6 Home Agent VSA (HA IPv6 address from BU) MIP6-Mesg-ID (Timestamp value from the Mobility message replay protection option (MESG-ID-OPTION-TYPE)
If the HoA authorization fails, the Home RADIUS server returns a RADIUS Access-Accept with a MIP6-HoA-Not-Authorized VSA along with the IK VSA so that the HA can respond to the MS with BA. The HA sends back a BA with status code = 129 (Administratively prohibited). After the initial Home Registration (with MN-AAA mobility message authentication option) is successful, the HA shall store the received IK from the RADIUS server for the duration of the MIP6 session and use it as MN-HA shared secret.
36 37 38 39 40 41 42
5.4
The RADIUS server shall support the attributes defined in [RFC 3162]. The Home RADIUS server shall authenticate MIP6 BU received from a user identified by the NAI. The RADIUS server shall support the following attributes for MIP6: User-Name attribute (NAI from BU) User-Password attribute NAS-ID (of the HA)
5. MIP6 Operation
54
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14
MIP6-CoA VSA (CoA from BU). MIP6-HoA VSA (HoA from BU). MIP6-Authenticator (Authentication data from the MN-AAA mobility message authentication option from BU). MIP6-MAC-Mobility-Data VSA (MAC_Mobility_Data computed). MIP6 Home Agent VSA (HA IPv6 address from BU) MIP6-HoA-Not-Authorized VSA. MIP6-Session Key VSA (IK). MIP6-Home Agent VSA (used for bootstrapping, Attribute B). MIP6-Home-Link Prefix VSA (used for bootstrapping, Attribute A). MIP6-Home Address VSA (used for bootstrapping, Attribute C). MIP6-Mesg-ID (Timestamp value from the Mobility message replay protection option (MESG-ID-OPTION-TYPE)
Attributes/ VSAs
User-Name
Type 1
AccessRequest 1
Access Accept 1
Access Reject 1
Direction HAAA <-> PDSN, HAAA <-> HA
Description NAI extracted from the MN-NAI mobility option in the BU. Based on HA/AAA shared secret. NAS ID of the HA. Received from BU, used for bootstrapping CoA received in BU HoA received in BU. The Authentication data extracted from the MNAAA mobility message authentication option. SHA-1 (care-of address | home address | MH Data) followed by the Timestamp field in the Mesg ID mobility option. MH Data is the content of the Mobility Header up to and including the SPI field of MN-AAA mobility message authentication option.
UserPassword NAS-ID MIP6 Home Agent MIP6-CoA MIP6-HoA MIP6Authenticator
2 32 26/118 26/119 26/141 26/134
1 1 1 1 1 1
0 0 0 0 0 0
0 0 0 0 0 0
HA->HAAA HA -> HAAA HA->HAAA HA -> HAAA HA -> HAAA HA -> HAAA
MIP6-MACMobility-Data
26/138
HA -> HAAA
MIP6-HoANotAuthorized
26/120
0-1
HAAA -> HA
Sent by Home RADIUS server if the HoA
5. MIP6 Operation
55
3GPP2
X.S0011-002-D v1.0
Attributes/ VSAs
Type
AccessRequest
Access Accept
Access Reject
Direction
Description authorization fails, always sent along with MIP6Session Key This VSA holds the Session Key (IK) in its encrypted form. IK is derived from the MN-AAA shared secret after authenticating a BU from the MS. Attribute B IPv6 address of the HA obtained from the BU. Attribute A (Section 5.1.6) Attribute C (Section 5.1.6) Contain the Timestamp value found in the Mobility message replay protection option (MESG-IDOPTION-TYPE) used in computing the Integrity Key (IK)
MIP6-Session Key
26/121
0-1
HAAA -> HA
MIP6-Home Agent MIP6-Home Link Prefix MIP6-Home Address MIP6-MesgID
26/140 26/128 26/129 26/144
0 0 0 0-1
0-1 0-1 0-1 0
0 0 0 0
HAAA -> PDSN HAAA -> PDSN HAAA -> PDSN HA ->HAAA
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Table 7 - MIP6 RADIUS Attributes The RADIUS server shall support HMAC_SHA-1 for authenticator computation. The authentication computation shall be performed as follows: Authentication data = First (96, HMAC_SHA1 (MN-AAA Shared key, MIPv6MAC_Mobility Data)). If the MN-AAA authenticator verification has failed, the Home RADIUS server shall send RADIUS Access-Reject message to the HA without including the ID and the IK information. The authentication and authorization requirements for the Home RADIUS server are as described in sections 5.4.1 and 5.4.2.
3 0 6H 3 0 7H
5.4.1
RADIUS Support for Session Key Generation and Distribution to the HA
The Home RADIUS server generates the Session Key (IK) from the MN-AAA shared secret after authenticating a BU from the Mobile Station. The Home RADIUS server shall send a RADIUS Access-Accept message containing the Session Key (IK) encrypted using a method as described in section 3.5 of [RFC 2868]. In particular, the encrypted IK is included in the MIP6-Session Key VSA and sent to the HA. The Home RADIUS server derives IK and sends it to the HA (in its encrypted form using the MIP6-Session Key VSA) along with other required attributes/VSAs in the following condition: Authentication, Authorization succeeded Authentication succeeded but the authorization of the HoA failed. This may happen if (1) the MS claimed an HoA that is either reserved (or used by) another user; or (2) the HoA is auto-configured with a prefix that was not authorized to be used by the user.
5. MIP6 Operation
56
3GPP2
X.S0011-002-D v1.0
1 2 3
The message flow for successful authentication and authorization and IK derivation and distribution to the HA is shown below:
MS BU (MN-AAA auth opt, MN-NAI option, Mobility message replay protection option)
HA
Home RADIUS
a Access-Request (VSAs) b
Genenrate IK
Authenticate , Authorize + Generate IK
Access-Accept (MIP6_Session Key VSA)
Store MN-HA SS = IK
BA (MN-HA auth option, Mobility message replay protection option) f
Auth BA with IK , Store MN-HA SS = IK
4 5 6 7 8 9 10 11 12
Figure 14- Derivation and distribution of IK during Home Registration a) The MS sends a Binding Update message to initiate Home Registration. In the BU the MS uses MN-AAA mobility message authentication option and the Mobility message replay protection option. b) The HA sends a RADIUS Access-Request to the Home RADIUS server to authenticate and authorize the MS.
5. MIP6 Operation
57
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
c) The Home RADIUS server authenticates the user based on MN-AAA Shared Secret (SS). The Home RADIUS server then generates IK based on MN-AAA shared secret and other parameters with a keying material derivation function. In this document this keying material derivation function will be SHA-1 defined also as PRF: f3 in S.S00550_v1.0_ECA. The keys can be derived as follows (Timestamp is the value of the MIP6Mesg-ID VSA): IK= PRF (MN-AAA shared secret, Integrity Key | Timestamp, Home Agents Address, Home Address), The input parameters into the subscriber authentication calculation shall be set to: Subscriber Authentication (128 bits) = MN-AAA Shared Secret Type Identifier (8-bits) = 0x45 Random Number (128-bits) = Integrity Key| Timestamp | Home Agents Address | Home Address Family Key (32-bits) = 0x4D36414F The output of the PRF is a 128-bit long IK that can be used as the MN-HA shared secret for the MIP6 session. The MS also performs the same PRF with the same inputs to generate IK at this stage or earlier. d) The Home RADIUS server then sends back a RADIUS Access-Accept message to the HA. In the RADIUS Access-Accept, the Home RADIUS server includes MIP6-Session Key VSA containing the derived IK encrypted using the procedures define in section 3.5 of [RFC 2868]. e) Upon receiving the RADIUS Access-Accept message the HA decrypts the MIP6-Session Key VSA and stores the IK as MN-HA shared secret for the MIP6 session. f) The HA sends a BA back to the MS. In the BA, the HA computes the MN-HA authenticator based on the received IK.
g) The MS authenticates the BA by computing the MN-HA authenticator with IK that it derived in step (c). If the authentication succeeds the MS stores the derived IK for future use as MN-HA shared secret for the duration of the MIP6 session. 5.4.2 RADIUS Support for MIP6 Bootstrap
Upon receiving a RADIUS Access-Request from a PDSN, the Home RADIUS server shall authenticate and authorize the user (identified by NAI) for IPv6 access at the PDSN. If the user is authorized for MIP6 access according to the subscription profile, the Home RADIUS server shall return one or more of the following VSAs to the PDSN in the RADIUS Access-Accept message to assist the MS in performing MIP6 registration:
3 0 8H
Home Link Prefix VSA(Attribute A) MIP6-Home Agent VSA (Attribute B) MIP6-HoA VSA (Attribute C)
3 0 9H
Refer to Table 6 in section 5.1.3 for the corresponding PDSN and MS behavior upon receiving different combinations of these attributes. The Home RADIUS server shall assign a globally unique /64 Home Link Prefix for each individual MS. Refer to the Table in section 5.1.3 for the corresponding PDSN and MS behavior upon receiving different combinations of these attributes.
3 1 0 H
5. MIP6 Operation
58
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
5.5
MS Requirements
The MS may support MIP6 service. The MS shall access cdma2000 packet data service using the cdma2000 air interface [5-9] and [15]. 5.5.1 PPP Session
The MS shall use PPP as the data link protocol for MIP6 access. The MS may support multiple MIP6 Home Addresses over a single PPP session. The Mobile shall use the global IPv6 address with /64 prefix acquired from PDSN as the Care-of Address (CoA) during MIP6 operation. The MS shall run PAP/CHAP during establishment of the PPP session. 5.5.1.1 Establishment Same as Section 3.4.1.1.
3 1 1H
5.5.1.2 Termination Same as Section 3.4.1.2.

3 1 2H
5.5.1.3 PPP Authentication Same as Simple IPv6 operation. See section 3.4.1.3.
3 1 3 H
5.5.1.4 Addressing with IPv6CP and ICMPv6 Same as Simple IPv6 operation. See section 3.4.1.4.
3 1 4 H
5.5.1.5 Compression Same as Simple IPv6 operation. See section. 3.4.1.7

3 1 5 H
5.5.1.6 PPP Framing Same as Simple IPv6 operation. See section 3.4.1.8.
3 1 6 H
5.5.2
MS Requirement to Support Stateless DHCPv6 to Obtain MIP6 Bootstrap Info
In order to support MIP6 bootstrapping, the MS shall support DHCPv6 client functionality and perform the stateless DHCPv6 procedures according to [RFC 3736]. The MS shall send an Information-Request message as per [RFC 3315] to the PDSN and shall include its access authentication NAI in the Identifier field of the Client Identifier Option with DUID-EN (enterprise number set as 5553) in order to request for the MIP6 bootstrap configuration information. To construct the Information-Request message; the MS sets the "msgtype" field to Information-Request. It also generates a transaction ID and inserts this value in the "transaction-id" field. The format of the Information Request message is as shown below:
0 8 Message-Type Options 16 Transaction-ID 31
30 31 32 33 34 35 36 37
5.5.2.1 Mobile Station Requirements to Support Dynamic Home Agent Assignment The MS shall support the Dynamic Home Agent Address Discovery procedure as defined in [RFC 3775]. The MS may also discover an HA address in the MIP6 Bootstrap configuration information in the response to a DHCPv6 Information-Request sent to the PDSN. The MS shall process Binding Updates that contain Mobility message authentication options (MNHA or MN-AAA), Mobility Mesg ID option and MN-NAI mobility option.
5. MIP6 Operation
59
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
5.5.2.2 Mobile Station Requirements to Support Dynamic Home Address Configuration The MS shall use Home Addresses that are either assigned by the Home RADIUS server or if the HoA is not assigned or preconfigured, the MS shall auto-configure the HoA based on the Home Link Prefix information. In order to enable Dynamic Home Address configuration, the MS shall send a DHCPv6 Information-Request [RFC 3736] for MIP6 bootstrap information to the PDSN. The use of the received bootstrap information by the MS is described in section 5.1.6. 5.5.3 Multiple Registrations
In this document the MS is allowed to perform multiple simultaneous home registrations with the same NAI as long as the MS is authorized to do so by the Home Networks policy. In each registration the MS shall use a different HoA at a minimum. 5.5.4 MIP6 Home Registration
MIP6 Home Registration is performed when the MS sends a Binding Update message to the HA. The MS shall include the MN-NAI mobility option in the BU. The inclusion of the MN-NAI mobility option in the subsequent BUs is required as per [RFC 4285]. The BU is protected by the Mobility message authentication option and Mesg ID option. Upon receiving a BA back from the HA, the MS authenticates the BA with the Mobility message authentication option and the Mesg ID option. 5.5.4.1 Authentication Protocol based Home Registration Support The MS shall support the MIP6 authentication protocol as defined in [RFC 4285] and the MN-NAI mobility option as defined in [RFC 4283]. Upon receiving the BA from the HA, the MS shall perform authentication of the BA based on the MN-HA mobility message authentication option contained in the BU and the MN-NAI mobility option. In the authenticator computation the MS shall use the IK that was generated using the MN-AAA shared secret. 5.5.4.1.1 Authentication with MN-HA Mobility Message Authentication Option
The MS shall use MN-HA mobility message authentication option in the subsequent BU. In this case, the MS shall include the MN-HA authenticator after computing it as follows in the BU: Authenticator = First (96, HMAC_SHA1 (IK, Mobility Data)). Mobility Data = care-of address | home address | MH Data. MH Data is the content of the Mobility Header up to and including the SPI field of this extension. The MS shall set the SPI to 5 which means that HMAC-SHA1 shall be used in the authenticator calculation. Integrity Key (IK) is derived during the initial Home Registration using the MN-AAA shared secret. The MS shall generate the IK in the same manner as described in section 5.4.1
3 1 7 H
Upon receiving the BA with status code set to 0, the MS shall extract the MN-HA authenticator and the SPI from the MN-HA mobility message authentication option. The MS shall authenticate the BA by calculating the authenticator as follows: Authenticator = First (96, HMAC_SHA1 (IK, Mobility Data)). Mobility Data = care-of address | home address | MH Data. MH Data is the content of the Mobility Header up to and including the SPI field of this extension. The MS shall set the SPI to 5 which means that HMAC-SHA1 shall be used in the authenticator calculation. Integrity Key (IK) is derived during the initial Home Registration using the MN-AAA shared secret. The MS shall generate the IK in the same manner as described in section 5.4.1.
5. MIP6 Operation
60
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
The MS shall process the BA as per [RFC 4285]. 5.5.4.1.2 Authentication with MN-AAA Mobility Message Authentication Option
The MS shall use MN-AAA mobility message authentication option in the BU to perform initial Home Registration if the MS has a shared secret with the home RADIUS server. When the MS uses MNMN-AAA mobility message authentication option it shall compute the IK. The MN-AAA authenticator is calculated using the MN-AAA shared secret. In this case the MS shall set the SPI value to HMAC_CHAP_SPI. In the BU, the MS shall include the MN-AAA authenticator after computing it as follows: Authenticator = First (96, HMAC_SHA1 (MN-AAA shared secret, MAC_Mobility_Data)). Where: MAC_Mobility Data = SHA-1 (care-of address | home address | MH_Data) followed by the Timestamp field in the Identification mobility option. MH Data is the content of the Mobility Header up to and including the SPI field of this extension. Upon receiving the BA with status code set to 0, MS shall extract the MN-HA authenticator and the SPI from the MN-HA mobility message authentication option. The MS shall process the BA as per [RFC 4285] by using the IK to verify the MN-HA authenticator value. 5.5.5 Termination
For cases other than power down registration, if the MS wishes to terminate the MIP6 session, it shall send a MIP6 BU to the HA with a Registration Lifetime field set to zero. For the case of power-down registration [5-9], the MS shall not send an LCP Terminate-Request message to the PDSN and shall not send a MIP6 BU with Registration Lifetime of zero to the HA.
24 25 26 27 28 29 30 31 32 33
5.6
Accounting Consideration
In this document, the PDSN maintains the same accounting model for MIP6 as is used for a Simple IPv6 session. The PDSN generates accounting records based on the NAI used for CHAP/PAP authentication, the (prefix) advertised to the MS in the RA messages, and interface ID negotiated during IPCP, which are used to construct the care of address of the MS. The HA shall provide additional accounting records to the Home RADIUS server that include the HoA, NAI and CoA for all MIP6 session established by the MS. The HA shall not generate byte counts for the MIPv6 session if the Home Networks policy allows the MS to perform route optimization. The following message flow shows the sequence diagram for accounting procedures:
5. MIP6 Operation
61
3GPP2
X.S0011-002-D v1.0
MS
PDSN
HAAA
CN
HA
1. BU (HoA, NAI, CoA) 2. Access-Request 3. Access-Accept 4. BA 5. Accounting-Request (start) 6. Accounting-Response 7. Binding lifetime expires or MS deregisters 8. Accounting-Request (stop) 9. Accounting-Response
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Figure 15- Accounting Procedures for MIP6 1) The MS sends an initial BU to the HA, which includes the CoA, HoA and shall include the users NAI. 2-3) The HA authenticates the BU with the RADIUS server, which results in a successful authentication. 4) The HA sends a BA to the MS. 5) The HA sends a RADIUS Accounting-Request (start) message which includes the HoA, NAI and CoA, as well as other attributes defined in [Chapter 5]. 6) The HAAA sends a RADIUS Accounting-Response back to the HA. 7) The binding lifetime expires or the MS sends an explicit deregistration. 8-9) The HA sends a RADIUS Accounting-Request (stop) message to indicate that the MIP6 session has closed. 5.6.1 PDSN requirements
The PDSN shall generate accounting records based on the prefix advertised to the MS in the RA, i.e., there are no additional requirements on the PDSN for accounting of MIP6 sessions. 5.6.2 HA requirements
Upon receiving and successfully authenticating a Binding Update, the HA shall send a RADIUS Accounting-Request (start) to the HAAA. The HA shall generate and include an Account-Session ID, the NAS-IP address or Identifier attribute, the Home IPv6 address in the MIP6-HoA VSA and the Care of Address in a MIP6-CoA VSA. The HA shall also include the user NAI if available in the User-Name attribute. See [Chapter 5] for complete list of attributes.
5. MIP6 Operation
62
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5
If the MS explicitly deregisters (Binding Update with lifetime 0), or if the binding lifetime expires or if the HA received a Disconnect-Request message from the HAAA, the HA shall send a RADIUS Accounting-Request (stop) message to the HAAA containing the attributes defined in [Chapter 5]. If any of the parameters in the BCE are updated, the HA shall send a RADIUS AccountingRequest (stop) message followed by a RADIUS Accounting-Request (start) message.
5. MIP6 Operation
63
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13
Simultaneous Services
The PDSN shall support any combination of MIP4, Simple IPv4 and Simple IPv6 simultaneously. The PDSN shall support MIP6 bootstrapping functionality. The MS may support any combination of MIP4, Simple IPv4, Simple IPv6 and MIP6 simultaneously. The HA shall support MIP4 and MIP6 simultaneously. Although any of these may run simultaneously, individual services are distinct. Within a single PPP session, the PDSN shall support simultaneous operation of IPCP [RFC 1332] and IPv6CP [RFC 2462]. Each packet data session shall be authenticated and authorized independently. In addition, each such session shall have unique accounting records. However, simultaneous Simple IPv4 and Simple IPv6 and MIP6 share a common authentication and authorization procedure at the PDSN as described in Section 3.2.2.
3 1 8 H
6. Simultaneous Services
64
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
IP Reachability Service
IP Reachability Service is the capability to update a DNS server in the home network with the current authorized MS IP address. When the MS desires to be reached by a DNS hostname, the Home RADIUS server (in the case of Simple IP or MIP) or the HA (in the case of MIP only) may send a DNS Update [RFC 2136] to a DNS server to add an A Resource Record for IPv4 and 25 AAAA or A6 Resource Record for IPv6 [RFC 1886] and [RFC 2874 ].
2 4 F
The Update section of the DNS Update message contains the following values in Host address Resource Type Resource Record: Resource Name = username.realm
26
2 5 F
Resource Class = Internet address class IP Address = newly assigned IP address
The TTL (Time To Live) of the Update section in the DNS Update message should be zero so that all queries for the address are resolved using the up to date authoritative server for the user. This is because after the MS is assigned a different address, if the TTL were non-zero, the cache entry of the querying endpoint would no longer be valid, and, in fact, the address may have been given to a different MS. The security between the DNS Server and Home RADIUS server or the HA is outside the scope of this document. The method used by the Home RADIUS server and/or HA to determine the IP address of the DNS server is outside the scope of this document. IP Reachability Service as specified in this document shall not be provided for users with single NAI and Multiple static Home Addresses.
23 24 25 26 27 28 29 30 31 32 33 34 35 36
7.1
Simple IPv4 Operation
The Home RADIUS server shall request that the DNS server add an A Resource Record for the user under the following conditions: the Home RADIUS server receives a RADIUS Accounting-Request (Start) record containing the Beginning-Session VSA and the IP-Technology VSA indicates Simple IP, the Home RADIUS server is configured to send DNS Update messages, and the user profile indicates that IP Reachability Service is enabled for the user.
The Home RADIUS server shall send a request to the DNS server to delete the A Resource Record for a user under the following conditions: the Home RADIUS server receives a RADIUS Accounting-Request (Stop) record from the PDSN currently serving the user for a session, and the Session-Continue VSA is either absent or is included but the value is set to FALSE and the IPTechnology VSA indicates Simple IP;
25 26
[RFC 2874] is an experimental RFC as per [RFC 3363] section 2.2. The MS sends the NAI as username@realm, and the Home RADIUS server converts the username@realm into username.realm. When the HA performs DNS update, the HA shall convert the username@realm to username.realm.
7. IP Reachability Service
65
3GPP2
X.S0011-002-D v1.0
1 2 3 4
The Home RADIUS server has not previously received an Accounting-Request(start) form another PDSN for the same packet data session (inter PDSN handoff with MIP); and the user profile indicates that IP Reachability Service is enabled for the user.
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
7.2
MIP4 Operation
The DNS server may be updated by either the Home RADIUS server or the HA. 7.2.1 DNS Update by the Home RADIUS Server
The Home RADIUS server shall request that the DNS server adds an A Resource Record for the user under the following conditions: The Home RADIUS server receives a RADIUS Accounting-Request (Start) record containing the Beginning Session VSA and the IP-Technology VSA indicates MIP, and the Home RADIUS server did not receive a RADIUS Access-Request message from the HA with the DNS-Update-Capability VSA, and the Home RADIUS server is configured to do DNS update, and the user profile indicates that IP Reachability Service is enabled for the user.
After performing DNS update for the user, the Home RADIUS server shall cache the User Name, NAS IP Address, and Framed IP address as received in the Accounting-Request (Start) record for the user. The Home RADIUS server shall send a request to the DNS server to delete the A Resource Record for a user under the following conditions: The Home RADIUS server receives a RADIUS Accounting-Request (Stop) record containing the IP-Technology VSA that indicates MIP, and does not contain the Session-Continue VSA or the Session-Continue VSA is included but the value is set to FALSE, and the Home RADIUS server has previously sent request(s) to the DNS server to add/update an A Resource Record for the corresponding user, The Home RADIUS server has not previously received an Accounting-Request(start) form another PDSN for the same packet data session (inter PDSN handoff with MIP); and the user profile indicates that IP Reachability Service is enabled for the user.
7.2.2
DNS Update by the HA
An HA that supports DNS update capability shall send a RADIUS Access-Request message to the Home RADIUS server at each initial MIP RRQ message it receives, and shall include the DNS-Update-Capability VSA. The home RADIUS server determines based on its configuration and user profile if the HA shall perform DNS update operations. The Home RADIUS server shall include the DNS-Update-Required VSA in the RADIUS Access-Accept message if the DNSUpdate-Capability VSA was included in the RADIUS Access-Request message and it allows the HA to perform DNS update for the user. The HA shall request the DNS server to add an A Resource Record for a user under the following conditions: The HA is capable of DNS update and it is configured to do so, and the HA is authorized by the Home RADIUS server to perform DNS update, and
66
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11
the MIP Registration process is successful.
The HA shall send a request to the DNS server to delete the A Resource Record for a user under the following conditions: The HA has previously sent request(s) to the DNS server to add/update an A Resource Record for the corresponding user, and the mobility binding for the user is set to expire due to the following reasons: " The HA receives a MIP RRQ with lifetime set to 0 from the user, or " the MIP registration lifetime for the user has expired, or " the mobility binding for the user has been revoked by the FA or the HA, or " administrative reset.
12 13 14 15 16 17
7.3
Simple IPv6 Operation
For IPv6 IRS support, the Home RADIUS server shall use the Resource Records defined in [RFC 1886] as updated by [RFC 2874] and [RFC 3152]. The operation of IRS service for IPv6 users is identical to the procedures described for Simple IPv4 in Section 7.1.
3 1 9 H
If the MS uses both IPv4 and IPv6, the Home RADIUS server shall request that the DNS server create or delete Resource Records for both IPv4 and IPv6.
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
7.4
MobileIPv6 Operation
The DNS server may be updated by the Home RADIUS server. The Home RADIUS server shall request that the DNS server adds a AAAA resource Record for the user under the following conditions 1. It is configured to send DNS updates, and 2. the user/MS is authorized for IP Reachability Service through the user profile, and 3. The Home RADIUS server receives a RADIUS Accounting-Request (Start) message from the HA containing the Beginning Session VSA, the HoA and the User Name (NAI). The Home RADIUS server shall request that the DNS server deletes a AAAA resource Record for the user under the following conditions 1. It is configured to send DNS updates, and 2. the user/MS is authorized for IP Reachability Service through the user profile, and 3. If an HoA associated with an MS is in the DNS entry and the RADIUS server receives a RADIUS Accounting-Request (Stop) message from the HA indicating BCE for the HoA is removed from the HA, i.e., Session continue VSA is absent or present with a value set to FALSE, then the Home RADIUS server shall send a DNS Update to the DNS server to delete the record for that HoA.
67
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6
MS-PDSN Version Capability Indication
The MS and PDSN shall support the 3GPP2 vendor specific Version/Capability packet defined in the PPP Vendor specific packet [RFC 2153]. Version/Capability packets shall be sent over the main service connection. The Version/Capability packets shall be sent as LCP packets with PPP Protocol ID set to C021(hex). The format of the Version/Capability packet is shown in Figure 16.
3 2 0H
78
15 16
23 24
31
Code
Identifier
Length
Magic Number
OUI
Kind
Version
List of Capabilities
7 8 9
Figure 16- Version/Capability Packet Format
Code Identifier Length Magic Number
0 (As defined in [RFC 2153]) The Identifier field shall be changed for each vendor specific packet sent. 16 (octets) 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 1661] for further explanation. 0xCF0002 2 for Version/Capability Indication packet 3 for Version/Capability Reply packet
OUI Kind
8. MS-PDSN Version Capability Indication
68
3GPP2
X.S0011-002-D v1.0
Version List of Capabilities
0 for Version D 1-255 reserved for later versions

3 2 1 H
Table 8 for List of MS capabilities Table 9 for List of PDSN capabilities
3 2 2 H
1 2 3 4 5 6 7 8 9
If the Kind value is 2, the Version/Capability Indication packet shall include the Version and List of Capabilities. If the Kind value is 3, the Version/Capability Reply packet shall not include the Version and List of Capabilities. The Version value 0 indicates that the MS (or PDSN) supports all the MS requirements (or PDSN requirements) mandated by TIA-835-D. The List of MS Capabilities is coded as a bit mask defined in Table 8. C0 is the most-significant bit in the list. Each bit in the list indicates whether an MS capability specified in TIA-835-D is supported.
3 2 3 H
Bit
MS Capability
Description
C0 C1 C2 C3 C4 C5 to C23
10 11 12 13 14
Simple IPv4 MIP4 Simple IPv6 MIP6 Max PPP inactivity timer Reserved
Set to 1 if MS supports Simple IPv4. Set to 1 if MS supports MIP4. Set to 1 if MS supports Simple IPv6. Set to 1 if MS supports MIP6. Set to 1 if MS supports the 3GPP2 vendor specific Max PPP Inactivity Timer packet.
Table 8 - List of MS Capabilities The List of PDSN Capabilities is coded as a bit mask defined in Table 9. C0 is the mostsignificant bit in the list. Each bit in the list indicates whether a PDSN capability specified in this document is supported.
3 2 4 H
Bit
PDSN Capability
Description
C0 C1 C2 C3 C4
Auxiliary SI for SO 60 Auxiliary SI for SO 61 Auxiliary SI for SO 66 HA Resource Management Auxiliary Service Connection for SO64 Auxiliary Service
Set to 1 if PDSN supports the auxiliary service connection for SO 60. Set to 1 if PDSN supports the auxiliary service connection for SO 61. Set to 1 if PDSN supports the auxiliary service connection for SO 66. Set to 1 if PDSN and HA resource management via MIP4 revocation is enabled. Set to 1 if PDSN supports the auxiliary service connection for SO64
C5
Set to 1 if PDSN supports the auxiliary service connection for SO67
69
3GPP2
X.S0011-002-D v1.0
Connection for S)67 C5 to C23

1
Reserved Table 9 - List of PDSN Capabilities
2 3 4 5 6 7 8 9 10 11
8.1
PDSN Requirements
If the PDSN receives the Version/Capability Indication packet from the MS, the PDSN shall respond with the Version/Capability Reply packet. The PDSN shall not send the Version/Capability Indication packet unless it has first received the 27 Version/Capability Indication packet from the MS .
2 6 F
The PDSN should resend the Version/Capability Indication packet a configurable number of times if no Version/Capability Reply packet from the MS is received. If the PDSN previously received the Version/Capability Indication packet from the MS, the PDSN may send the Version/Capability Indication packet to the MS anytime after the PPP session is 28 established .
2 7 F
12 13 14 15 16 17 18 19 20 21
8.2
MS Requirements
During the LCP negotiation, the MS shall send the Version/Capability Indication packet. The MS should resend the Version/Capability Indication packet a configurable number of times if no Version/Capability Indication packet from the PDSN is received. If the MS receives the Configure29 Reject , the MS shall stop resending the Version/Capability Indication packet.
2 8 F
If the MS receives the Version/Capability Indication packet from the PDSN, the MS shall respond with the Version/Capability Reply packet. The MS may send the Version/Capability Indication packet to the PDSN anytime after the PPP session is established.
27
If the PDSN did not receive the Version/Capability Indication packet from the MS, most likely it is an earlier version MS that does not support the version/capability indication. Therefore, it is wasteful for the PDSN to send the Version/Capability Indication packet to the MS. 28 This allows the PDSN to indicate network capabilities that are not available to the PDSN during the PPP session establishment. For example, the PDSN initially may not know whether HA resource management is supported until during the Mobile IP registration (See section 5.2 of Chapter 3). 29 This is an indication that the PDSN is revision C or earlier.
70
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Hot-Lining
The Hot-Lining capability is optional. In this document, Hot-Lining capability applies only to Simple IPv4, Simple IPv6 and MIP4 services. If the PDSN and/or the HA supports Hot-Lining they shall follow the specification as described in this section. The Hot-Lining feature described in this document shall not apply to PrePaid sessions. Hot-Lining provides a wireless operator with the capability to efficiently address issues with users that would otherwise be unauthorized to access packet data services. When a problem occurs such that a user may no longer be authorized to use the packet data service, a wireless operator using this feature may Hot-Line the user, and upon the successful resolution of the problem, return the users packet data services to normal. When a user is Hot-Lined, their packet data service is redirected to a Hot-Line Application which may notify (if feasible) the user of the reason(s) that they have been Hot-Lined and offers them a means to address the reasons for Hot-Lining, meanwhile blocking access to normal packet data services. Example reasons for HotLining a user are: users who have billing issues such as expiration of a credit card, users who have been suspected of fraudulent use. Blocking normal packet data usage. Attempting to notify users/MS (if feasible) that packet data usage is blocked. Re-directing user/MS traffic to rectify issues causing blockage. Restoring normal operations when the User has rectified issues that triggered the Hot-Lining of their service. Alternatively, terminating service if the User failed to address the issues that triggered the Hot-Lining of their service.
As a result, Hot-Lining performs the following four fundamental activities:
25 26 27 28 29 30
9.1
Hot-Lining Capabilities
1. Hot-Lining is supported for Simple IPv4, Simple IPv4 and Mobile-IP operations. Support of Hot-Lining is therefore required in the PDSN and the HA. 2. A user can be Hot-Lined at the start of their packet data session or mid-session as described below:
The following section describes the general Hot-Line capabilities supported for this release:
Active-Session Hot-Lining:
The user starts a packet data session. In the middle of the session it is HotLined and after the account is reconciled by some manner, the Hot-Lining status of the session is removed. The Hot-Lining is done with RADIUS Change of Authorization (COA) message. The users session is Hot-Lined at the time of packet data session establishment. In this scenario the RADIUS Access-Accept message is used to Hot-Line the session.
New-Session Hot-Lining:
31 32 33 34
3. Similarly, a Hot-Lined packet data session can be returned back to normal, mid-session or at the start of the session. 4. There are two styles that can be used by the Home RADIUS server to indicate that a user is to be Hot-Lined: Profile-based Hot-Lining The Home RADIUS server sends a Hot-Line profile identifier in the RADIUS message. The Hot-Line profile identifier sent using RADIUS Filter-Id(11)
9. Hot-Lining
71
3GPP2
X.S0011-002-D v1.0
attribute(s) selects a set of rules that are pre-provisioned in the Hot-Line Device that cause that users packet data session to be redirected and/or blocked. Rule-based HotLining
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
The Home RADIUS server sends the actual redirection-rules (HTTP or IP) and filter-rules in the RADIUS messages that cause the users packet data session to be redirected and/or blocked.
5. In order to properly account for the Hot-Lining state of the user, the users Hot-Line state should be recorded in the accounting stream. The following capabilities are not covered by this document but are described in so far that they are needed to implement a complete Hot-Lining solution: 6. The trigger(s) that cause an operator to Hot-Line a user is outside the scope of this document. These triggers could come from a number of sources such as a billing system, fraud detection system etc. 7. The means to notify the Home RADIUS server that a user is to be Hot-Lined is outside the scope of this document. 8. The means by which the user is notified that they have been Hot-Lined is not within the scope of this document. Typically, the user will be notified that they have been Hot-Lined via their browser. Other methods such as SMS messaging are possible. 9. The means by which the user interacts with the system to correct the problems that caused them to be Hot-Lined are not within the scope of this document. 10. The means by which the system notifies the Home RADIUS server that a users packet data session is to be returned to normal operation is not within the scope of this document. 11. The details of what happens when the PDSN/HA performs Profile-based Hot-Lining is outside the scope of this document. It is assumed that the users traffic is blocked and that the user gets notified. When the packet data session is Hot-Lined some IP flows will be blocked and some IP flows will be redirected. The intent of the redirection is not to continue the normal operation of the flow but rather to provide information (e.g.the users IP address when IP redirection is used) to the HotLine application so that the Hot-Line application can determine how to notify the user of their HotLined state.
26 27 28 29 30 31 32 33 34 35
9.2
Hot-Lining Architecture
HA PDSN Home RADIUS server Visited RADIUS server
Hot-Lining involves the following packet data network entities:
The HA and the PDSN are devices that implement the Hot-Lining rules requested by the Home RADIUS server. In this document the HA or the PDSN that is currently applying the Hot-Line rules for a User is called the Hot-Lining Device. The role of the Visited RADIUS server with respect to Hot-Lining is to act as proxy and as such will not be discussed further.
9. Hot-Lining
72
3GPP2
X.S0011-002-D v1.0
RADIUS
HAAA
AAA-Hot-Line signaling (not in scope)
RADIUS Hot-lining Application (not in scope) Packet data
PDSN/FA Hot-line device
Packet data
HA Hot-line device Packet data
Mobile-Hot-lining Application interaction: e.g., SMS, Web (not in scope)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Figure 17- Hot-Lining Architecture Hot-Lining also involves the Hot-Line Application. The Hot-Line Application is a functional entity that performs the following roles: Determines when the user should be Hot-Lined. Initiates the Hot-Lining signaling with the Home RADIUS server. Redirects Hot-Lined flows to the Hot-Line Application. Initiates notification of the Hot-Line status to the MS. This could be done via a delivery of an HTML page to the subscribers browser or via some other means such as SMS messaging. Provides a mechanism for the user to rectify the issue that triggered Hot-Lining. Returns the user back to normal operating mode upon successful resolution of the problem. Terminates the user's packet data session upon unsuccessful resolution of the problem.
The implementation of the Hot-Line Application is not within the scope of this document. The interface between the Hot-Line Application and the various entities is outside the scope of this document.
19 20 21 22 23 24
9.3
Operations
Hot-Lining of a users packet data service starts when the Hot-Line Application determines that the users service is to be Hot-Lined. This determination is entirely deployment specific and can be a result of many factors. Details are not within the scope of this document. To initiate Hot-Lining of the user, the Hot-Line Application will notify the Home RADIUS server that the user is to be Hot-Lined. The method of notification is outside the scope of this document.
9. Hot-Lining
73
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Upon receiving the notification from the Hot-Line Application, the Home RADIUS server records the Hot-Lining state against the user record. The Home RADIUS server will determine if the user has an ongoing packet data session. If the user has an ongoing packet data session, the Home RADIUS server initiates the Active-Session Hot-Lining procedure. If the user has no ongoing packet data session, the Home RADIUS server initiates the New-Session Hot-Lining procedure. Hot-Lining requires the Hot-Lining device to support Profile-based Hot-Lining and/or Rule-based Hot-Lining. When a Hot-Line device cannot honor a request for Active Session Hot-Lining, the operator may utilize a Disconnect Message (if supported) to terminate the users session or depend on the RADIUS Session-Timeout attribute that may have been previously sent to the HotLine device in a RADIUS Access-Accept or COA message for session termination. To participate in Hot-Lining, an access device (PDSN or HA) shall advertise its Hot-Lining capabilities using the Hot-Line Capability VSA sent in a RADIUS Access-Request message. The Home RADIUS server uses the contents of the Hot-Line Capability VSA and other local policies to determine which access device will be the Hot-Lining Device for the session. If the Home RADIUS server doesnt receive the Hot-Line Capability VSA, the Home RADIUS server shall consider the PDSN or the HA to not have the Hot-Lining capability. RADIUS Access-Accept messages or RADIUS Change of Authorization (COA) messages that signal hot-lining shall contain either: A RADIUS Filter-Id attribute; or Any combination of zero or more of HTTP Redirection Rule VSAs and/or IP Redirection Rule VSAs.
Furthermore, RADIUS messages that contain HTTP Redirection Rule VSA and/or IP Redirection Rule VSA may also contain Filter Rule VSAs. RADIUS Access-Accept or COA messages that contain any RADIUS Filter-Id(11) attributes, shall not contain any of the HTTP Redirection Rule VSAs or IP Redirection Rule VSAs or Filter Rule VSA. RADIUS Access-Accept messages and RADIUS COA messages may contain the Hot-Line Accounting Indication VSA. The Hot-Line Accounting Indication VSA is opaque to the Hot-Line Device and if received shall be included in all accounting packets (start, interim, stop) associated with the Hot-lined session as triggered by the Access-Accept or an acceptable COA message. The Hot-line session continues until the HAAA turns hot-lining off or the packet data session is terminated. The Hot-Line Accounting Indication is provided to mark the accounting records that are associated with a hot-lined session. Therefore, the home RADIUS server should only include the Hot-Line Accounting Indication in Access-Accepts or COA messages that initiate hot-lining of the session. 9.3.1 New-Session Hot-Lining Procedure
The New Session Hot-Lining Procedure is invoked when a user is initiating a packet data session and is marked as Hot-Lined in the Home RADIUS server, as shown in the following call flow.
9. Hot-Lining
74
3GPP2
X.S0011-002-D v1.0
Hot-line device
HAAA
Hot-line Application
User not online User starting packet data service Access-Request+Hot-line cap. Access-Accept+hot-lining Acct+Hot-lining indication
Hot-line user (not in scope) Store in user's profile
a b
c d
e f
Hot-lined packet data flow

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Figure 18- New Session Hot-Lining Call Flow a) The Home RADIUS server receives a signal (outside the scope of this document) from the Hot-Lining application to Hot-Line a users packet data service. b) The Home RADIUS server records this information in its user profile store. If the user is not active, the Home RADIUS server waits until the user initiates the packet data service, which will result in the user being Hot-Lined immediately. Meanwhile, it is possible for the Hot-Line Application to change the users Hot-Line status back to normal in which case the Home RADIUS server will update the user profile store accordingly. c) When the user who is to be Hot-Lined initiates a packet data session, a RADIUS AccessRequest is received by the Home RADIUS server that indicates the Hot-Line Capability of the Hot Line device. d) In the Home RADIUS server, the Local Policies and received Hot-Line Capability will be used to determine which device (PDSN or HA) will receive Hot-Lining VSAs. The Home RADIUS server shall signal the Hot-Lining Device of the users Hot-Line status by sending Hot-Lining VSA(s) in the RADIUS Access Accept message. The Home RADIUS server may include the Hot-Line Accounting Indication VSA in the RADIUS AccessAccept message. e) If the Hot-Lining Device is capable of generating RADIUS Accounting records, then the Hot-Lining Device should generate a RADIUS Accounting-Request (Start) packet and shall include the Hot-Line Accounting Indication VSA if received in the RADIUS AccessAccept message. If the Hot-Lining Device is unable to honor the Hot-Lining VSA(s) received in the RADIUS Access-Accept packet, it shall treat the RADIUS Access-Accept packet as a RADIUS Access-Reject packet and terminate session setup. f) Once the Hot-Line session starts, traffic will be blocked and/or directed to the Hot-Line Application.
9. Hot-Lining
75
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5
9.3.2
Active Session Hot-Lining Procedure
The Active Session Hot-Lining Procedure is invoked when the Hot-Lining state of a user who is currently engaged in a packet-data-session is changed. Upon receiving the Hot-Line signal the Hot-Lining Device will perform the procedures described in the following figure:
Hot-line device User is in a packet data session User active in a packet data session COA+Hot-line indication COA Ack Acct stop Acct start + Hot-lining indication
HAAA
Hot-line Application
Some events require that the user's session be hotlined Hot-line user (not in scope) Store in user's profile
b c d e f g h i
Hot-lined packet data flow Hot-line issues reconciled, users needs to return to 'normal' User back to 'normal' (not in scope) COA+'normal' COA Ack Acct stop: hot-line Acct start + 'normal' User flow returns back to normal Store in user's profile
j k l m n o p
6 7 8 9 10 11 12 13 14 15 16
Figure 19- Active Session Hot-Line Procedure a) The user is currently engaged in a packet data session, which is not Hot-Lined. b) The Home RADIUS server starts the Active Session Hot-Lining procedure when it receives a Hot-Line signal from the Hot-Line Application for the user that has already started a packet data session. c) The Home RADIUS server stores the Hot-Line state of the user in the users profile. d) In the Home RADIUS server, the Local Policies and received Hot-Line Capability will be used to determine which device (PDSN or HA) will receive Hot-Lining VSAs. The Home RADIUS server will signal the Hot-Lining Device of the users Hot-Line status by sending Hot-Lining VSA(s) or RADIUS Filter-Id(11) attribute in the RADIUS Change Of
9. Hot-Lining
76
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Authorization (COA) message. The Home RADIUS server may include the Hot-Line Accounting Indication VSA in the RADIUS Change Of Authorization (COA) message. e) If the Hot-Lining Device can honor the request then it will respond with a COA ACK packet. If the Hot-Lining Device cannot honor the Hot-Lining request, then the Hot-Lining Device shall respond with a COA NAK message. Based on local policy, upon receiving a COA NAK packet the Home RADIUS server may either retry sending the Hot-Lining signal to the Hot-Lining Device, or may send a RADIUS Disconnect-Request message to the Hot-Lining Device or to another device to instruct it to drop the session. f) A Hot-Lining Device capable of generating accounting packets shall generate a RADIUS Accounting-Request (Stop) message to close the current accounting session. The Release Indicator (F13) shall be set to 14 (Hot-Line Status Changed).
g) A Hot Lining Device capable of generating accounting packets shall generate a RADIUS Accounting-Request (Start) message including the Hot-Line Accounting Indication VSA received in the COA packet. h) The Hot Lining Device then immediately invokes the Hot-Lining rules as specified in the COA packet. i) Once the user has been Hot-Lined the Hot-Line Application might notify the user of their Hot-Lined state and will interact with the user to rectify the issue that caused the HotLining. If the Hot-Lining Application is not satisfied with the results, it may maintain the Hot-Lining status of the user, or it may terminate the users session. If the problem has been rectified the Hot-Lining Application will return the users session back to a normal mode. The Hot-Line Application will indicate the back to normal status to the Home RADIUS server. Note the interaction of the Hot-Line Application with the user is beyond the scope of this document. If the session is active, the Home RADIUS server will send a COA packet to the HotLining Device. In this case, the signal shall be sent to the device that is currently applying the Hot-Line rule. Note that this may not be the same device that initially implemented the Hot-Line state for the session (a handoff may have happened). If the received notification, of step i, indicated session termination from the Hot-Line Application, the Home RADIUS server shall record the termination status of the user in the users policy store and if the session is still active, it shall send a RADIUS Disconnect-Request message to an appropriate device. Note that this device may not be the Hot-Lining Device. Upon receiving the RADIUS Disconnect-Message, the device shall promptly terminate the session. If the device is capable of generating accounting messages, it shall generate a RADIUS Accounting-Request (Stop) message with Release Indicator (F13) set to 6 (Termination due to resource management).
j)
k) The Home RADIUS server will update the users profile. l)
m) Upon receiving the signal to return the user back to normal mode, if the Hot-Lining Device is unable to honor the request it shall respond with a COA NAK packet. Upon receiving a COA NAK, the Home RADIUS server may send a RADIUS DisconnectRequest message to terminate the users session. The RADIUS Disconnect-Request message may be sent to the Hot-Lining Device or to another device that is capable of terminating the session. On the other hand if the Hot-Lining Device is able to return the user back to normal state, it shall send a COA ACK packet. n) If the Hot-Lining Device is capable of generating accounting messages it shall generate a RADIUS Accounting-Request (Stop) message indicating that the Hot-Lining session has been terminated and include the Hot-Line-Accounting Indication VSA if received in the COA message. The Release Indicator (F13) shall be set to 14 (Hot-Line Status Changed).
9. Hot-Lining
77
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
o) The RADIUS Accounting-Request (Stop) message shall be followed by a RADIUS Accounting-Request (Start) message indicating the start of the normal packet data session. p) The users session is now returned back to normal.
9.3.3
Limiting the Hot-Lining Duration
Hot-Lined sessions can still utilize expensive network resources and therefore an operator may wish to limit the period over which a session is to be Hot-Lined. There are two methods that are available to the operator. First, a (Hot-Lined or not Hot-Lined) session can be terminated immediately by sending a Disconnect Message. The Disconnect Message is not required to target the Hot-Lining Device. Second, the Home RADIUS server should be configured to include the Session-Timeout (27) attribute when it sends the Hot-Lining indication to the Hot-Lining Device. The Session-Timeout will contain the length of time in seconds that the user would be allowed to remain in the session. If Session-Timeout expires, the packet data session shall be terminated.
17
9.4
9.4.1
Hot-Lining Requirements
Requirements for Hot-Line Capable PDSN and HA
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
This section describes the common requirements of a Hot-Lining Device (PDSN and HA). Requirements that apply specifically to a PDSN or HA are under section 9.4.1.1 and section 9.4.1.2 respectively.
3 2 5H 3 2 6 H
1. Hot-Lining shall not interfere with the establishment of a packet data session. The Hot-line Device shall allow completion of the packet data session and shall allow MIP signaling reregistration. The Hot-Line Device shall apply the Hot-Lining rules to DNS traffic and DHCP traffic through relay agent functionality. 2. A Hot-Lining capable device shall support both New-Session Hot-Lining and ActiveSession Hot-Lining. 3. A Hot-lining capable device shall include the Hot-line Capability VSA in the RADIUS Access-Request message indicating its ability to support Hot-Ling. 4. A Hot-Line Device shall treat a RADIUS Access-Accept message as Access-Reject message or shall respond with a COA NAK message with Error-Cause (101) indicating Administratively Prohibited(501) when it receives a RADIUS Access-Accept message or COA message that contains: A RADIUS Filter-Id(11) attribute that it cannot decode; or A RADIUS Filter-Id(11) attribute and either Filter-Rule VSA(s) or HTTP/IP Redirection-Rule VSA(s); or Contains Filter-Rule (VSA)s or HTTP/IP Redirection-Rule (VSA)s that it can not decode.
5. Upon receiving a COA message containing RADIUS Filter-Id(11) attribute(s), the HotLining Device shall locate the Hot-Line rules that match the profile(s) specified by the RADIUS Filter-Id(11) attribute(s). If the Hot-Lining Device is successful, it shall reply to the HAAA with a COA ACK message. The Hot-Lining Device shall remove any previously specified RADIUS Filter-Id(11) attribute(s), HTTP Redirection Rules, IP Redirection Rules, and Filter Rules and begin applying the rules associated with the newly received RADIUS
9. Hot-Lining
78
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Filter-Id(11) attribute(s). The Hot-Lining Device shall send accounting messages as described in the Hot-Lining section of [Chapter 5]. If the Hot-Lining Device is not successful at matching the newly received RADIUS Filter-Id(11) attribute(s) with corresponding rules, it shall send a COA NAK with Error-Cause (101) indicating "Administratively Prohibited"(501). In this case, the Hot-Line state and all existing rules shall remain unchanged 6. If the Hot-Lining Device receives a RADIUS Access Accept message containing HTTP Redirection-Rule VSAs, IP Redirection-Rule VSAs, and/or Filter Rule VSAs that are wellformed (that can be parsed), then the Hot-Lining Device shall apply the HTTP Redirection rule(s) if any first, followed by the IP Redirection rule(s) if any ; Filter-Rule VSA(s) if any are processed last. Within each type of rule, the rules are processed in the order that they appear in the packet. In applying the rules (Filter and HTTP/IP Redirection rules) the HotLining Device should validate the rules against any security policies. If any security policies have been violated, the Hot-Lining Device shall tear down the user s packet data session. 7. Upon receiving a COA message with well-formed HTTP Redirection Rule, and/or IP Redirection-Rule, and/or Filter-Rule VSAs, the Hot-Lining Device should validate any locally provisioned filtering that effect local system wide policies. If any of the rules violate local policies, or the Hot-Lining Device is not able to accept the COA message, it shall send a COA NAK message with Error-Cause (101) indicating Administratively Prohibited (50). In this case, the Hot-Line state and all existing rules shall remain unchanged. Otherwise, when no rules violate local security policy, the Hot-Lining Device shall do the following: If the Hot-Lining Device is currently applying rules associated with a previously received RADIUS Filter-Id(11) attribute(s), it stops applying the rules associated with the previously received RADIUS Filter-Id(11) attributes and begins applying the newly received HTTP Redirection Rules, and/or IP Redirection Rules, and/or Filter Rules. The Hot-Lining Device shall respond to the HAAA with a COA ACK and begin sending accounting messages as described in the Hot-Lining section of [Chapter 5]. If the Hot-Lining Device is currently applying rules associated with previously received HTTP Redirection Rules and/or IP Redirection Rules and/or Filter Rules, it shall overwrite any old rules of the same kind (HTTP with HTTP, IP with IP, Filter with Filter) with the new rules. If no old rules of the same kind exist, the new rules of that kind shall be applied. The Hot-Lining Device shall respond to the HAAA with a COA ACK and begin sending accounting messages as described in the Hot-Lining section of [Chapter 5].
8. If the Hot-Lining Device receives the Session-Timeout (27) attribute it shall terminate the session after the time specified for the session (in seconds) has expired. If the Hot-Lining Device is capable of RADIUS accounting it shall send a RADIUS Accounting-Request (Stop) message containing the Hot-Lining Accounting Indication VSA if one was received in a RADIUS Access-Accept or COA message. 9. A Hot-Lining Device that receives the HTTP-Redirection VSA shall monitor the IP flows. When an IP flow matches the src and dst fields, the Hot-Lining Device shall apply the rule as specified in the HTTP-Redirection VSA. If the action in the rule is to redirect, the Hot-Lining Device shall block the traffic and respond to every HTTP request it sees with an HTTP Redirect response [RFC 2616] specifying the URL of the matching HTTPRedirection Rule VSA. 10. A Hot-Lining Device that receives the IP-Redirection rule VSA shall monitor the IP flows. When an IP flow matches the rule, the Hot-Lining Device shall redirect the flow to the address specified in the matching rule.
9. Hot-Lining
79
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
11. A Hot-Lining Device that receives the IP-Filter rule VSA shall monitor the IP flows. When an IP flow matches the rule, the Hot-Lining Device depending on the specified action shall either block or allow the flow to proceed. 12. A Hot-Lining Device that receives an HTTP Redirection Rule, an IP-Filter-Rule or an IPRedirection-Rule that contains the keyword flush shall flush all previously received attributes of the same kind for that session. 13. If the Hot-Line device receives an Access-Accept or a COA with the Hot-Line Accounting attribute but no RADIUS FIlter-Id(11) attribute(s)/HTTP Redirection Rule VSA/IP Redirection Rule VSA/Filter Rule VSA then this Hot-Line Accounting-Indication shall not affect the Hot-Line state of the user. If the Hot-Lining Device is capable of generating RADIUS accounting messages then it shall include the newly received Hot-Line Accounting Indicator in all subsequent accounting messages. 9.4.1.1 Requirements for Hot-Line Capable PDSN This section describes the requirements of a Hot-Line Capable PDSN. PDSN accounting procedures that relate to Hot-Lining are covered in [Chapter 5] section 3.5.11. Accounting messages are used to demarcate the Hot-Line session. 1. In multi-homed scenarios (i.e., user with multiple NAIs), the PDSN shall ensure that the Hot-Line only affects flows associated with the home network that is asserting the HotLining. 9.4.1.2 Requirements for Hot-Line Capable HA This section describes the requirements of a Hot-Line Capable HA. 1. A Hot-Lining capable HA shall send a RADIUS Access-Request message to the Home RADIUS server upon receiving an initial MIP4 RRQ for a user. The Hot-Line capable HA shall include the Hot-Line Capability VSA in the RADIUS Access-Request message indicating its ability to support Hot-Lining. Note: Since HA does not generate accounting messages for MIP4, it has no way of demarcating or for that matter recording whether or not the users session has been Hot-Lined. 9.4.2 MS Requirements
After the Hot-lining state has ended, the MS may perform device configuration to ensure it has the correct parameters for use in a non-Hot-Lined state. This step may be triggered by manual user intervention in case the notification of the end of the Hot-Lining state is at the application layer and cannot be interpreted by the MS. 9.4.3 RADIUS Server
The following describes the RADIUS Hot-Lining requirements. 1. If the Home RADIUS server receives the Hot-Lining Capability VSA in the RADIUS Access-Request message indicating the Hot-Lining capabilities of the RADIUS client, the Home RADIUS server shall use the value to determine the Hot-Lining capabilities of the PDSN or the HA. 2. The Home RADIUS server shall be capable of receiving an indication from the Hot-Lining Application to either assert Hot-Lining for a users packet data session or to remove HotLining from a Hot-Lined packet data session. The specification of the indication is not within the scope of this document. 3. Upon receiving a Hot-Line indication from the Hot-Lining Application, the Home RADIUS server should record the Hot-Lining state of the user in the users profile.
9. Hot-Lining
80
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
4. Upon receiving an indication from the Hot-Line Application to remove Hot-Line state of a user, the RADIUS server shall modify the users profile. 5. The Home RADIUS server shall be responsible for selecting the Hot-Lining Device. The selection criteria may be based on the Hot-Lining capability of the device as specified by the Hot-Lining Capability VSA included in the RADIUS Access-Request message; local policies; or other factors such as whether reverse tunneling is being used. 6. The RADIUS server shall not attempt to Hot-Line a Pre-Paid user. 7. The RADIUS server shall not attempt to Hot-Line a MIP6 session. Note that the RADIUS server may hot-Line the underlying Simple IPv6 session at the PDSN. 8. The Home RADIUS server shall also determine whether or not to use Rule-based HotLining (using Filter-Rule and HTTP/IP Redirection-Rule VSAs) or Profile-based Hot-Lining (using RADIUS Filter-Id(11) attribute). This decision should be based on the Hot-Lining capabilities of the device as specified by the Hot-Lining Capability VSA included in the RADIUS Access-Accept message and local policies. 9. The RADIUS server may include the Hot-Lining Accounting Indication VSA in the RADIUS Access-Accept message and COA message. 10. The RADIUS server may include Session-Timeout attribute in order to limit the length of time the users session is Hot-Lined. 9.4.3.1 Active Session Upon receiving an indication to commence Active Session Hot-Lining, i.e., Hot-Lining of a users packet data session that is currently online, the Home RADIUS server shall send a COA message to the Hot-Lining device. which includes the NAI, and the NAS ID. If the Home RADIUS server receives a COA ACK from the Hot-Lining Device, then Active Session Hot-Lining of a packet data session has been successful. The device's inability to HotLine the packet data session will be indicated by the reception of COA NAK. The RADIUS server should examine the Error-Cause (101) attribute to determine why the request failed. Should the Error-Cause (101) indicate the Administrative Prohibited (501) code, the RADIUS server may (based on local policies) send a RADIUS Disconnect-Request message to immediately cause the users packet session to be terminated. The RADIUS Disconnect-Request message may be sent to any access device serving the packet data session. Upon receiving an indication from the Hot-Line Application to remove Hot-Line state and if the user is currently online, the Home RADIUS server shall send a COA message to the Hot-Lining Device to return the users session back to normal operation. 9.4.3.2 New Session Upon receiving a RADIUS Access-Request message for a user who is to be Hot-Lined, the Home RADIUS server shall determine if Hot-Lining shall be applied for the user on that device. If it determines that Hot-Lining shall be applied, it shall send that device the Hot-Line indication in the RADIUS Access-Accept message.
9. Hot-Lining
81
3GPP2
X.S0011-002-D v1.0
Annex A (Normative): IKE/ISAKMP Payloads

This Annex addresses ISAKMP payloads in which multiple options exist (see [RFC 2407-2409]). The following requirements shall be met by the PDSN and HA, assuming IP security between the HA and PDSN is required. Payloads in which no options exist do not appear in this Annex. Note: If the HA (home network) does not require any security then Annex A does not apply nor does it apply to MSs using collocated CoA for MIP. ISAKMP Fixed Header: The PDSN in this document shall use a Major and Minor Version of 0. The HA shall minimally accept Major and Minor Version of 0. This document does not make use of the Fixed Header Authentication (A) bit.
2 3 4 5 6 7 8 9 10
11 12 13 14 15 16
Security Association Payload:

All Security Association Payloads shall use the IPsec DOI. The Phase 1 ISAKMP Security Payload shall specify a situation of SIT_IDENTITY_ONLY. Phase 2 ISAKMP Security Payloads shall specify a situation of SIT_IDENTITY_ONLY for all cases where privacy or only authentication applies (as outlined in the PDSN and HA "IP Security" sections of this document).
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
Proposal Payload:
Because the MS first makes contact with the PDSN, the PDSN shall be the Initiator of the Phase 1 ISAKMP SA. The HA shall be the Responder. The PDSN shall propose ISAKMP to the HA for the Phase 1 ISAKMP SA. For Phase 2 Quick Mode exchanges, both the PDSN and HA shall be Initiators and Responders because symmetrical, bi-directional security between the PDSN and HA is required. For message authentication, PDSNs conforming to this document shall propose 30 both AH and ESP with the authentication option. The HA shall respond with ESP if the PDSN has proposed it. For message privacy, the PDSN shall propose ESP. For combined authentication and privacy, the PDSN shall propose ESP only.
2 9 F
MIP registration control packets and IP in IP tunneled packets, or GRE encapsulated packets, may be protected by IPsec authentication, privacy, or both. Security policies to be used between the PDSN and the HA in this document are dictated by the home network not the access provider network. The PDSN shall be capable of proposing authentication only, privacy only, and both authentication and privacy. Service provider owned HAs shall accept and propose only one of these, and the PDSN shall accept this proposal. The Home RADIUS server may deliver a User Profile to the Visited RADIUS server and PDSN that indicates whether security should be supported for IP in IP and/or GRE encapsulated packets . If the Home RADIUS server indicates a request for no security on the IP-in-IP and GRE tunneled packets, the PDSN shall not delete existing IPsec security associations to the HA. This is because IPsec should be authorized per PDSN-HA pair and thus other MSs may be using those IPsec security associations.
30
Note that a future version of this document is likely to no longer require AH, in accordance with industry trends.
82
3GPP2
X.S0011-002-D v1.0
The SPI shall be four octets.
2 3 4 5 6 7 8 9 10
Transform Payload:
For Phase 1, the PDSN shall use KEY_IKE as the transform identifier. All implementations shall support 3DES and RSA. For Phase 2 Quick Exchange, the PDSN shall minimally support the ESP_3DES transform identifier within a Transform Payload for IPsec ESP Proposal Payload. It shall also support both HMAC-MD5 and HMAC-SHA1 as transform identifiers within a Transform payload for IPsec AH Proposal Payload. Service provider HAs shall likewise support these two transforms. The PDSN may optionally support and propose other transforms. An HA shall select one of the transforms offered by the PDSN.
11 12 13 14 15 16 17 18 19 20 21 22 23 24
Key Exchange Payload:

The PDSN and HA will exchange D-H (Diffie-Hellman) public values computed in the D-H group negotiated as part of a protection suite in the first message exchange of Phase 1 for ISAKMP SA establishment. The PDSN shall specify Phase 1 authentication with certificates when the HA's certificate or HA's root CA certificate is available. Otherwise, if a Dynamic pre-shared IKE secret distributed by the Home RADIUS server is available, the PDSN shall specify Phase 1 authentication with a pre-shared secret mode of operation. In this case, the PDSN shall specify Phase 1 Aggressive mode only. This is necessary in order that the KeyID field can be transmitted in the clear. The Home RADIUS server shall insure that the value of the S key is hard to guess (i.e., a properly generated random number) in order to prevent dictionary attacks that are possible with Aggressive mode. If the PDSN has a statically configured IKE secret for the SA with the HA, then the PDSN shall specify Phase 1 authentication with pre-shared secret mode of operation. In this case the PDSN may either use Main Mode or use Aggressive Mode.
25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
Identification Payload:
For Phase 1 negotiation, the PDSN shall set the Protocol-Id field to zero or UDP. The port number shall be set to zero or 500. If the HA receives any other values for these two fields in the Identification Payload, IKE negotiation shall be aborted. For IKE authentication using pre-shared secret the PDSN and HA shall minimally support ID_KEY_ID in the ID Type field. For IKE authentication using Revised Public Key Encryption with RSA using X.509 certificates, the PDSN and HA shall minimally support ID_DER_ASN1_DN in the ID Type field. For Phase 2 (Quick Mode), both the PDSN and HA shall include the client identifiers in the form of optional Client Identification Payloads as specified in IKE (i.e., IDci and IDcr). To apply IPsec on all traffic between the PDSN and the HA, the PDSN and the HA shall exchange IDci and IDcr. The protocol and port number fields shall be dont care by setting them to 0 in both IDci and IDcr. The following is an example of the format of the client identifiers. IDCi: Protocol field = 0, Port = 0, Idtype = ID_IPV4_ADDR, Identification_data = PDSN_IPV4_ADDR. IDCr: Protocol field = 0, Port = 0, Idtype = ID_IPV4_ADDR, Identification_data = HA_IPV4_ADDR.
43
Certificate Payload:
Annex A (Normative): IKE/ISAKMP Payloads 83
3GPP2
X.S0011-002-D v1.0
The Certificate Payload shall carry X.509 version 3 certificates.
2 3
Signature Payload:
The PDSN and HA shall not include this payload.
4 5 6 7 8 9
Notification Payload:
The Notification Payload carries error messages and reason codes regarding failure for a peer to be able to establish a security association. The PDSN and HA handling of a failed security association establishment is specified in the main body of the document. The PDSN and HA shall use the "SA Lifetime Notify" code as a trigger to refresh the indicated security association.
10 11 12
Delete Payload:
The PDSN shall send a delete payload upon an SA refresh or upon request from a service provider administrator.
84
3GPP2
X.S0011-002-D v1.0
Annex B (Normative): Certificates

PDSNs and HAs shall use X.509 Version 3 certificates in conformance with [RFC 2459]. Each PDSN and HA in a service provider network may have a unique certificate which will be configured into the PDSN and HA. The method of configuration of certificates is outside the scope of this document. Note: This Annex only applies to FA CoA. Security between a collocated CoA MS and the HA is outside the scope of this document. Each service provider may be a Certificate Authority for itself and its client private networks and partner ISPs for PDSNs and for HAs that may be accessed by PDSNs. All PDSNs and HAs shall be configured with all service provider CA certificates. There should be one CA root certificate from each service provider.
2 3 4 5 6 7 8 9 10 11
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
Certificates for PDSNs and HAs:

The Distinguished Name [RFC 2459] contained in the Issuer field is of form: cdma2000.service-provider-name The PDSN or HA determines the issuing service-provider (i.e., the CA) from the service-providername attribute of the Issuer's Distinguished Name. The PDSN and HA then use the serviceprovider-name attribute to locally access the CA's public key. The PDSN and HA shall use the SHA-1 as a hash function and either the RSA or DSA signing algorithm, as specified in [RFC 2459] to verify a certificate. The private network or ISP shall provide the public key and Distinguished Name of the certificate. The Distinguished Name contained in the Subject field is of form: cdma2000. service-provider-name.PDSN.service-provider-identifier cdma2000. service-provider-name.HA.service-provider-identifier Certificates in the PDSN and HA will not use the Unique-Identifier field. Certificate extensions for PDSN and HA certificates shall not be supported. The method of providing PDSNs and HAs signed certificates to PDSNs and HAs is outside the scope of this document.
28 29 30 31 32 33 34 35 36
CA Certificates:
Service provider CA certificates shall be configured into all PDSNs and HAs. A service provider CA contains the public key that the PDSN or HA shall use to verify the signature of a certificate received in a Phase 1 ISAKMP exchange. A CA certificate shall conform to the X.509 V3 certificates in [RFC 2459]. Since the service provider CA distributes its own certificate, the Authority Key Identifier and Subject Key Identifier extensions shall not be included in the certificate. The method by which service providers exchange their CA certificates, as well as of providing certificates into PDSNs and HAs, is outside the scope of this document.
37
Certificate Revocation List (CRL):
85
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
CRLs shall be used to store the identities of certificates that have been compromised or are otherwise invalid. CRLs shall conform to X.509 v2 as specified in [RFC 2459]. A future version of this document may make use of the Online Certificate Status Protocol. Service providers shall exchange revoked certificate information (e.g., serial number). The frequency of the exchange is outside the scope of this document. Possession of a certificate does not imply service since the RADIUS server and MIP functions still control the user obtaining service, as well as the HA allowing access to the PDSN. The CA certificate shall indicate the service provider CA as Issuer of the CRL. The DN of the Issuer shall be of form: cdma2000.service-provider-name CRLs exchanged between service providers shall use the SHA-1 as a hash function and either the RSA or the DSA signing algorithm as specified in [RFC 2459]. CRL extensions shall not be supported. The method of exchanging CRLs between service providers, or to conveying certificates client private network or partnering ISP, as well providing this information into PDSNs and HAs, is outside the scope of this document.
86
3GPP2
X.S0011-002-D v1.0
Annex C (Normative): PDSN Timers

The PDSN shall implement a PPP inactivity timer and may implement a PPP session timer and may implement an accounting interval timer. These timers are defined as follows. PPP inactivity timer (4-byte unsigned integer): This mandatory timer is configured with the maximum number of consecutive seconds that a PPP session may be idle. When a PPP session has been idle for this amount of time, the PPP session may be terminated depending on the users Always On status (see section 3.2.1.10).
3 2 7 H
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
PPP session timer (4-byte unsigned integer): This optional timer is configured with the maximum number of total seconds for which a PPP session may be established. When a PPP session has been established for this amount of time, the PPP session is terminated, regardless of whether it is active or idle. Accounting interval timer (4-byte unsigned integer): This optional timer is configured with the number of total seconds between when the PDSN sends periodic interim accounting messages to the RADIUS server. The PPP inactivity timer and PPP session timer use the value of 0 to indicate infinity. When timers are set to an infinity value, they will never expire.
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
PPP Inactivity Timer

The PPP inactivity timer shall be locally configured on the PDSN with a default value that is used for all PPP sessions. However, this default value may be overridden on a per session basis with a RADIUS Idle-Timeout (28) attribute [RFC 2865] that is returned from the RADIUS server in a RADIUS Access-Accept message. For MIP service, the PPP inactivity timer shall always be greater than the MIP registration lifetime. Thus, the PDSN shall always advertise to the MS a maximum allowed MIP registration lifetime smaller than the PPP inactivity timer value currently in use for the PPP session. The PDSN shall ignore a non-zero RADIUS Idle-Timeout value received in a RADIUS Access-Accept message for a MIP session, which is smaller than current PPP inactivity timer for the PPP session. The PDSN may honor the RADIUS-Idle-Timeout value received in a RADIUS AccessAccept message for a MIP session if the received value is greater than the one currently in use for the PPP session. In case of Simple IP service, if the PPP session is marked as Always-On then the PDSN shall perform the link status determination procedure upon expiry of the PPP inactivity timer (see section 3.2.1.10]).
3 2 8H
33 34 35 36 37 38 39 40 41 42
PPP Session Timer

If the PPP session timer is used, then it shall be locally configured on the PDSN with a default value that is used for all PPP sessions. However, this default value may be overridden on a per session basis with a RADIUS Session-Timeout (27) attribute [RFC 2865] that is returned from the RADIUS server in a RADIUS Access-Accept message. For Always On users, the PDSN shall discard the PPP session timer. In the case of multiple MIP sessions over a single PPP session, it is possible that the PDSN receives different RADIUS-Session-Timeout values from different home networks. In this case, the PDSN may honor the initial RADIUS-Session-Timeout value that it received and shall ignore all subsequent RADIUS-Session-Timeout values that it receives.
43
Accounting Interval Timer
Annex C(Normative): PDSN Timers
87
3GPP2
X.S0011-002-D v1.0
1 2 3 4 5 6
If the accounting interval timer is used, then it shall be locally configured on the PDSN with a default value that is used for all sessions. However, this default value may be overridden on a per session basis with a RADIUS Acct-Interim-Interval (85) attribute [RFC 2869] that is returned from the RADIUS server in a RADIUS Access-Accept message. For a session using the prepaid service, the RADIUS Acct-Interim-Interval shall not be used and the interval timer shall be interpreted as per [Chapter 6] (PrePaid Packet Data Service).
Annex C(Normative): PDSN Timers
88

Simple IPand Mobile IPflow

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Simple IPand Mobile IPflow

Uploaded by

Copyright:

Available Formats

3GPP2 X.S0011-002-D Version: 1.

0 Version Date: February, 2006

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

3.1 3.1.1 3.2 3.2.1 3.2.2 3.2.3 3.3 3.4 3.4.1 4

MIP6 OPERATION ......................................................................................................................................39

7.1 7.2 7.2.1 7.2.2 7.3 7.4 8 8.1 8.2 9

9.1 9.2 9.3 9.3.1 9.3.2

9.3.3 9.4 9.4.1 9.4.2 9.4.3

ANNEX A(NORMATIVE): IKE/ISAKMP PAYLOADS ...............................................................................82 ANNEX B(NORMATIVE): CERTIFICATES..................................................................................................85

ANNEX C(NORMATIVE): PDSN TIMERS....................................................................................................87

Glossary and Definitions

See [Chapter 1].

1. Glossary and Definitions

See [Chapter 1].

Common Service Specification

PPP encryption is not supported in this document.

3.2.1.4 Addressing with IPCP 3.2.1.4.1 IPv4 Addressing

Accouting-Request (start)/ Response (e)

DHCP Inform (g) DHCPAck (i) DHCPAck (h)

Accouting-Request (start)/ Response (f)

Relay-Forward (h) Relay-Reply (i) Reply (j)

Stac-LZS [RFC 1974]; Microsoft Point-To-Point Compression Protocol [RFC 2118];

Max PPP Inactivity Timer

OUI = Kind = Max PPP Inactivity Timer =

Attribute Name User-Name User-Password CHAP-Password NAS-IP-Address NAS-IPv6-Address

AccessRequest M O Note 1 O Note 2 O Note 3 O Note 3

Ingress Address Filtering

RADIUS Server Requirements

Common Service Specification

Dynamic Home Agent and Home Address Assignment

Scenarios Scenario 1 Scenario 2 Scenario 3 Scenario 4

Home Address specified in RRQ 0.0.0.0 x.x.x.x 0.0.0.0 x.x.x.x

Section 4.3.4 for the HA.

Section 4.4.1 for the Home RADIUS server.

Section 4.5.2.2 for the MS.

Figure 4- GRE Key CVSE Type: CVSE-TYPE-NUMBER 38

Reserved: Length: Vendor/Org-ID: Vendor-CVSE-Type: Vendor-CVSE-Value:

4.2.1.6 PPP Framing See Section 3.2.1.9.

Refer to Annex A and B for details.

PDSN Requirements for GRE Tunneling Support

Home Agent Requirements

Construction of the message is implementation dependent.

HA Requirements for GRE Tunneling Support

RADIUS Server Requirements

Type 4 95 26/79 26/44 31 26/7 8 26/1 26/2

AccessRequest O Note 3 O Note 4 O M O M M O

MN-HA Shared Key Distribution

4.5.1.2 Termination Same as Section 3.4.1.2.

4.5.1.6 PPP Framing Same as Section 3.4.1.8.

DNS Server IP Address NVSE

Type Vendor/Org-ID Vendor-NVSE-Type Length .. ..

Reserved Sub-Type(=1) Secondary DNS IPv4 address Unused

Entity-Type Primary DNS IPv4 address Sub-Type(=2) Length

Figure 6- NVSE for DNS Server IP Address Type: 134

MS establishes link layer and bootstraps [HL/HA/HoA]

Use assigned HoA or autoconfig HoA

Access-Accept e HA performs proxy DAD for HoA

NAI option, Mesg

BA (IPv6 header | RH Type 2

| Mobility Header (MH Type 6, auth option ))

NAI option, Mesg-ID option, MN-HA

Figure 8- MIPv6 Home authentication option