Cdma2000 Sip Mip Standard

3GPP2 X.
S0011-002-E
Version: 1.0
Version Date: November 2009
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.
This page is left blank intentionally.
cdma2000 Wireless IP Network Standard X.S0011-002-E v1.0
1 cdma2000 Wireless IP Network Standard: Chapter 2

2
3
4
5
6
7
CONTENTS
8
9
1 Glossary and Definitions .......................................................................................................................... 1
10
11 2 References ................................................................................................................................................ 1
12
13 3 Simple IP Operation ................................................................................................................................. 2
14
3.1 Common Service Specification .................................................................................................. 2
15
16
3.1.1 PPP Session ................................................................................................................. 2
17 3.2 PDSN Requirements .................................................................................................................. 2
18 3.2.1 PPP Session ................................................................................................................. 2
19
3.2.2 RADIUS Support ....................................................................................................... 12
20
21
3.2.3 Ingress Address Filtering ........................................................................................... 14
22 3.3 RADIUS Server Requirements ................................................................................................ 15
23
3.4 MS Requirements .................................................................................................................... 15
24
25
3.4.1 PPP Session ............................................................................................................... 15
26
27 4 MIP4 Operation...................................................................................................................................... 20
28 4.1 Common Service Specification ................................................................................................ 20
29
4.1.1 PPP Session ............................................................................................................... 20
30
31
4.1.2 MIP4 .......................................................................................................................... 20
32 4.1.3 Dynamic Home Agent and Home Address Assignment ............................................ 20
33 4.1.4 GRE CVSE ................................................................................................................ 21
34
35
4.2 PDSN Requirements ................................................................................................................ 22
36 4.2.1 PPP Session ............................................................................................................... 22
37 4.2.2 MIP4 Registration...................................................................................................... 24
38 4.2.3 RADIUS Support ....................................................................................................... 26
39
4.2.4 IP Security Support .................................................................................................... 27
40
41 4.2.5 Ingress Address Filtering ........................................................................................... 29
42 4.2.6 PDSN Requirements for GRE Tunneling Support .................................................... 29
43
4.3 Home Agent Requirements ...................................................................................................... 31
44
45
4.3.1 Multiple Registrations ............................................................................................... 31
46 4.3.2 MIP4 Authentication Support .................................................................................... 31
47 4.3.3 IPsec Support ............................................................................................................. 32
48 4.3.4 Dynamic Home Agent Assignment ........................................................................... 33
49
4.3.5 DNS Address Assignment ......................................................................................... 33
50
51
4.3.6 HA Requirements for GRE Tunneling Support ......................................................... 33
52 4.4 RADIUS Server Requirements ................................................................................................ 35
53
4.4.1 Dynamic Home Agent Assignment ........................................................................... 36
54
55
4.4.2 MN-HA Shared Key Distribution .............................................................................. 36
56 4.4.3 IKE Pre-shared Secret Distribution Procedure .......................................................... 36
57 4.4.4 DNS Address Assignment ......................................................................................... 37
58
4.5 MS Requirements .................................................................................................................... 37
59
60
i Contents
X.S0011-002-E v1.0 cdma2000 Wireless IP Network Standard
4.5.1 PPP Session ............................................................................................................... 37 1

4.5.2 MIP4 Registration ...................................................................................................... 38 2
4.5.3 MS Requirements for GRE Tunneling Support ......................................................... 41 3

4
4.6 DNS Server IP Address NVSE ................................................................................................ 42 5
6
5 MIP6 Operation ...................................................................................................................................... 43 7
5.1 Common Service Specification ................................................................................................ 45 8

9
5.1.1 PPP Session ............................................................................................................... 45
10
5.1.2 MIP6 .......................................................................................................................... 46 11
5.1.3 Summary of PDSN and MS Behavior for Dynamic HA/HL Discovery via 12
MIP6 Bootstrapping................................................................................................... 46 13
5.1.4 Mobile Station to Home Agent Security for BU and BA .......................................... 54 14

15
5.2 PDSN Requirements ................................................................................................................ 55 16
5.2.1 PDSN Requirement to Support Stateless DHCPv6 to Convey MIP6 Bootstrap 17
Info ............................................................................................................................ 55 18
5.2.2 MIP6-HA-Protocol-Capability-Indication ................................................................. 56 19
20
5.2.3 Ingress Address Filtering ........................................................................................... 57
21
5.3 Home Agent Requirements ...................................................................................................... 57 22
5.3.1 Home Agent Requirements to Support Dynamic Home Agent Assignment ............. 57 23
5.3.2 Home Agent Requirements to Support Dynamic Home Address Configuration ....... 57 24
25
5.3.3 Multiple Registrations ............................................................................................... 58
26
5.3.4 Prefix Registrations ................................................................................................... 58 27
5.3.5 Data Forwarding ........................................................................................................ 58 28
5.3.6 Home Registration Support ....................................................................................... 58 29
30
5.3.7 Return Routability Support for Route Optimization .................................................. 60
31
5.3.8 HA Requirement as a RADIUS Client ...................................................................... 60
32
5.3.9 DNS address assignment ........................................................................................... 60 33
5.4 RADIUS Server Requirements ................................................................................................ 62 34

35
5.4.1 RADIUS Support for Session Key Generation and Distribution to the HA .............. 64
36
5.4.2 RADIUS Support for MIP6 Bootstrap ....................................................................... 66 37
5.5 MS Requirements ..................................................................................................................... 67 38
5.5.1 PPP Session ............................................................................................................... 67 39

40
5.5.2 MS Requirement to Support Stateless DHCPv6 to Obtain MIP6 Bootstrap
41
Info ............................................................................................................................ 68
42
5.5.3 Multiple Registrations ............................................................................................... 69 43
5.5.4 Prefix Registration ..................................................................................................... 69 44
5.5.5 MIP6 Home Registration ........................................................................................... 69 45

46
5.5.6 DNS address assignment ........................................................................................... 71
47
5.5.7 Termination ............................................................................................................... 71 48
5.6 Accounting Consideration ........................................................................................................ 71 49
50
5.6.1 PDSN requirements ................................................................................................... 72
51
5.6.2 HA requirements ........................................................................................................ 72
52
53
6 Simultaneous Services ............................................................................................................................ 74 54
6.1 PPP Additional Authentication ................................................................................................ 74 55
56
6.1.1 PDSN and MS Common Requirements ..................................................................... 74
57
6.1.2 PDSN Requirements .................................................................................................. 77
58
59
60
Contents ii
1
6.1.3 MS Requirements ...................................................................................................... 78
2
3 7 IP Services Authorization and Selection ................................................................................................ 79
4 7.1 IP Services Authorization ........................................................................................................ 79
5
6
7.2 IP Services Selection................................................................................................................ 79
7
8 8 IP Reachability Service .......................................................................................................................... 80
9 8.1 Simple IPv4 Operation ............................................................................................................. 80
10
11
8.2 MIP4 Operation ....................................................................................................................... 81
12 8.2.1 DNS Update by the Home RADIUS Server .............................................................. 81
13 8.2.2 DNS Update by the HA ............................................................................................. 81
14
8.3 Simple IPv6 Operation ............................................................................................................. 82
15
16 8.4 MobileIPv6 Operation ............................................................................................................. 82
17
18 9 MS-PDSN Version Capability Indication .............................................................................................. 83
19
9.1 PDSN Requirements ................................................................................................................ 85
20
21 9.2 MS Requirements .................................................................................................................... 85
22
23 10 3GPP2 Vendor Specific Reject Packet ................................................................................................... 86
24
25 11 Hot-Lining .............................................................................................................................................. 87
26
11.1 Hot-Lining Capabilities ........................................................................................................... 87
27
28 11.2 Hot-Lining Architecture........................................................................................................... 88
29
11.3 Operations ................................................................................................................................ 90
30
31
11.3.1 New-Session Hot-Lining Procedure .......................................................................... 91
32 11.3.2 Active Session Hot-Lining Procedure ....................................................................... 92
33 11.3.3 Limiting the Hot-Lining Duration ............................................................................. 95
34
11.4 Hot-Lining Requirements ........................................................................................................ 95
35
36
11.4.1 Requirements for Hot-Line Capable PDSN and HA ................................................. 95
37 11.4.2 MS Requirements ...................................................................................................... 97
38 11.4.3 RADIUS Server ......................................................................................................... 97
39
40 Annex A (Normative): IKE/ISAKMP Payloads ................................................................................................. 100
41
42
ISAKMP Fixed Header: ....................................................................................................................... 100
43 Security Association Payload: .............................................................................................................. 100
44
Proposal Payload: ................................................................................................................................. 100
45
46 Transform Payload: .............................................................................................................................. 101
47
Key Exchange Payload: ....................................................................................................................... 101
48
49
Identification Payload: ......................................................................................................................... 101
50 Certificate Payload: .............................................................................................................................. 102
51
Signature Payload: ............................................................................................................................... 102
52
53 Notification Payload: ........................................................................................................................... 102
54
Delete Payload: .................................................................................................................................... 102
55
56
Annex B (Normative): Certificates ..................................................................................................................... 103
57
58 Certificates for PDSNs and HAs: ......................................................................................................... 103
59
60
iii Contents
CA Certificates: .................................................................................................................................... 103 1
Certificate Revocation List (CRL): ...................................................................................................... 104 2

3
4
Annex C (Normative): PDSN Timers ................................................................................................................. 105
5
PPP Inactivity Timer ............................................................................................................................ 105 6
PPP Session Timer ............................................................................................................................... 105 7

8
Accounting Interval Timer ................................................................................................................... 106 9
NCP Inactivity Timer ........................................................................................................................... 106 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
51
52
53
54
55
56
57
58
59
60
Contents iv
1
2
LIST OF FIGURES
3
Figure 1 MS Parameters configuration with DHCP .......................................................................... 7
4
5
Figure 2 Configuration of MS‟s parameters using DHCPv6 ............................................................ 8
6 Figure 3 Max PPP Inactivity Timer Packet ..................................................................................... 10
7 Figure 4 GRE Key CVSE ............................................................................................................... 21
8
Figure 5 GRE Header for Tunneling Datagrams ............................................................................. 22
9
10
Figure 6 NVSE for DNS Server IP Address ................................................................................... 42
11 Figure 7 The Initial MIP6 Home Registration with MN-AAA mobility message
12 authentication option ........................................................................................................ 43
13 Figure 8 MIPv6 Home Registration with MN-HA mobility message authentication option .......... 45
14
Figure 9 Flow diagram for Dynamic Home Agent Assignment (HA and HL is assigned by
15
HAAA) ............................................................................................................................. 48
16
17
Figure 10 Flow diagram for Dynamic Home Agent Assignment (VAAA assigns HA and HL) ...... 50
18 Figure 11 Bootstrap of Home Link Prefix ........................................................................................ 52
19 Figure 12 Home Address Auto-Configuration .................................................................................. 54
20
Figure 13 Derivation and distribution of IK and MN-HA SPI during Home Registration ............... 65
21
Figure 14 Accounting Procedures for MIP6 ..................................................................................... 72
22
23 Figure 15 3GPP2 vendor specific PPP Additional Authentication packet format ............................ 75
24 Figure 16 Value format for AddAuth packet .................................................................................... 75
25 Figure 17 Additional Authentication (CHAP case) .......................................................................... 76
26
Figure 18 Version/Capability Packet Format .................................................................................... 83
27
28
Figure 19 Reject Packet Format ........................................................................................................ 86
29 Figure 20 Hot-Lining architecture..................................................................................................... 89
30 Figure 21 New Session Hot-Lining Call Flow .................................................................................. 91
31
Figure 22 Active Session Hot-Lining Procedure .............................................................................. 93
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
v List of Figures
LIST OF TABLES 1
2
3
Table 1 Occurrence of RADIUS Attributes for Simple IP ............................................................. 12
4
Table 2 Home Agent and Home Address Scenarios ...................................................................... 21 5
Table 3 Description of Scenarios ................................................................................................... 21 6
Table 4 Occurrence of RADIUS Attributes for MIP4 ................................................................... 35 7

8
Table 5 MS Registration Scenarios ................................................................................................ 39
9
Table 6 MIP6 Bootstrapping Scenarios ......................................................................................... 47 10
Table 7 MIP6 RADIUS Attributes ................................................................................................. 63 11
Table 8 List of MS Capabilities ..................................................................................................... 84 12

13
Table 9 List of PDSN Capabilities ................................................................................................. 84
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
51
52
53
54
55
56
57
58
59
60
List of Tables vi
1
2
3
4 GENERAL DESCRIPTION
5
6 This chapter describes the basic IP access services: Simple IPv4/IPv6, MIP6 and MIP4 with
7 Home Agent(HA) and/or Dynamic Home IP address Assignment. It also addresses the
8 security requirements between the Wireless IP Network nodes: PDSN, HA and RADIUS
9 servers. The chapter includes other capabilities such as Always On, multiple simultaneous
10 MIP4/MIP6 and Simple IPv4/IPv6 packet data sessions, IP Reachability Service, DHCP
11 Support, Hot-Lining, additional PPP authentications, and IP service authorization etc.
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
51
52
53
54
55
56
57
58
59
60
vii General Description

This page is left blank intentionally.
1
2
3
4 1 Glossary and Definitions
5
6 See [Chapter 1].
7
8
9
10
11 2 References
12
13 See [Chapter 1].
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
51
52
53
54
55
56
57
58
59
60
1 1 Glossary and Definitions

3 Simple IP Operation 2
3
This section describes the requirements and procedures for Simple IP operation for both IPv4 4
5
[RFC 791] and IPv6 [RFC 2460]. In this document, Simple IP refers to a service in which an
6
MS is assigned an IP address and is provided IP routing service by an access provider
7
network. The MS retains its IP address as long as a Radio Access Network (RAN) that has
8
connectivity to the same Serving PDSN serves it. IP address mobility beyond the Serving
9
PDSN and secure access to a home network are beyond the scope of this section.
10
11
12
3.1 Common Service Specification 13
14
The common requirements for several network elements (e.g., PDSN and MS) for Simple IP 15
operation are described here. 16
17
18
3.1.1 PPP Session
19
20
PPP shall be the data link protocol between the MS and the PDSN. The PPP session shall be
21
established prior to any IP datagram being exchanged between the MS and the PDSN. Only
22
one PPP session shall be supported between the MS and the PDSN.
23
PPP shall be supported as defined in the following standards with any limitations or 24
extensions described in this document. 25

26
 Point to Point Protocol [RFC 1661]; 27
28
 PPP in HDLC-like Framing [RFC 1662]; 29
30
 IPCP [RFC 1332] (for IPv4); 31
 IPv6CP [RFC 2472] (for IPv6); 32

33
 CHAP [RFC 1994]; 34

35
 PAP [RFC 1334]. 36
37
 EAP [RFC 3748] 38
39
PPP encryption is not supported in this document.
40
41
42
3.2 PDSN Requirements 43
44
The PDSN shall support Simple IP operation for both IPv4 and IPv6. 45
46
3.2.1 PPP Session 47

48
49
3.2.1.1 Establishment 50
51
If the PDSN supports multiple service connections for a user, refer to [Chapter 4] for details 52
of PPP negotiation. Otherwise, when an A10 connection of SO type 33/59 is established the 53
PDSN shall send an LCP Configure-Request for a new PPP session to the MS. 54
55
PPP shall support transparency in accordance with Section 4.2 of [RFC 1662]. The PDSN
56
shall not send an LCP Configure-Reject in response to an ACCM configuration option
57
proposed by the MS in an LCP Configure-Request and shall attempt to negotiate a control 58
59
60
1
2
3 character mapping with the minimum number of escaped characters by proposing an ACCM
4 of 0x00000000.
5
6
3.2.1.2 Termination
7
8
The PDSN shall close the PPP session if there is no established A10 or P-P session for the MS.
9
If the PPP session timer is used and has expired, or if Always On service is not enabled and
10
the PPP inactivity timer for a PPP session expires, the PDSN shall close the PPP session. The
11
12
PDSN may receive the Always On attribute with value „1‟ from the Home RADIUS server in
13
order to activate the Always On service for a user. If the PDSN receives the Always On
14
attribute with value „1‟, it shall send the indicator to the RAN as indicated in [4].
15
Upon receiving the Always On attribute with value „1‟ from the Home RADIUS server the
16
PDSN shall utilize the expiration of the PPP inactivity timer and the procedures described in
17
Section 3.2.1.10 to determine if the PPP session should be closed.
18
19 When the PDSN determines that the PPP session shall be closed, it shall determine if an LCP
20
Terminate-Request should be sent to the MS. For an Always On session, the PDSN shall send
21
an LCP Terminate-Request to the MS. The PDSN should also send LCP Terminate-Request
22
to a non-Always On session unless it has previously received the „All Dormant Indicator‟
23
NVSE.
24
25 The PDSN shall clear the A10 and/or P-P session whenever the associated PPP session is
26
closed. If the PDSN receives IP packet(s) for an MS for which there is no established PPP
27
session, the PDSN shall silently discard the packet(s). The PDSN shall close the A10 and
28
associated P-P session if it receives an LCP Terminate-Request message from the MS.
29
30
31
3.2.1.3 PPP Session Authentication
32
The PDSN shall support the three authentication mechanisms: EAP, CHAP and PAP. The
33
34
PDSN shall also support a configuration option to allow an MS to receive Simple IP service
35
without EAP, CHAP or PAP. If the local policy requires using EAP, the PDSN shall propose
36
EAP as the authentication protocol in the LCP Configure-Request by setting Authentication-
37
Protocol option to C227 (hex) in the LCP Configuration Options. If the PDSN doesn‟t
38 propose the EAP, the PDSN shall propose CHAP in an initial LCP Configure-Request
39 message that the PDSN sends to the MS during the PPP establishment.
40
41
If the response from the MS for the Configure-Request proposing EAP is Configure-Ack,
42
then the PDSN shall select EAP as the PPP authentication protocol and proceed to play the
43
role of EAP authenticator and exchange EAP messages using the AAA protocol (e.g.
44
RADIUS).
45
If the PDSN receives an LCP Configure-NAK from the MS containing CHAP, the PDSN
46
shall accept CHAP by sending an LCP Configure-Request message with CHAP.
47
48
If the PDSN receives an LCP Configure-NAK from the MS containing PAP, the PDSN shall
49
accept PAP by sending an LCP Configure-Request message with PAP.
50
51 If the PDSN receives an LCP Configure-Reject containing the Authentication-Protocol option
52 and the PDSN is configured to allow the MS to receive Simple IP service without EAP,
53 CHAP or PAP, the PDSN shall respond with an LCP Configure-Request without the
54 Authentication-Protocol option and shall adhere to the guidelines in Section 3.2.2.1 for NAI
55
construction for accounting purposes.
56
57
58
59
60
3 3 Simple IP Operation
3.2.1.4 Addressing with IPCP 1

2
3.2.1.4.1 IPv4 Addressing 3
4
For IPv4, the PDSN shall assign the MS an IP address for Simple IP service when presented 5
with a zero or non-zero IP address in the IP Address Configuration option, during the IPCP 6
phase of PPP. The IP address may be a private address as per [RFC 1918]. If the MS requests 7
a non-zero IP address during the IPCP phase, the PDSN shall send an IPCP Configure-Nak in 8
response to the request in order to propose a different IP address. If the MS responds with an 9
IPCP Configure-Request containing an IP address different from the one proposed by the 10
PDSN, the PDSN shall re-transmit one time the IPCP Configure-Request containing the new 11
IP address, and shall send an LCP Terminate- Request if the MS fails to accept the assigned 12
IP address. 13
14
During IPCP phase, the PDSN shall include the IP Address Configuration option containing 15
its IP address in the IPCP Configure-Request messages sent to the MS. 16
17
The PDSN shall implement IPCP configuration options as defined in [RFC 1877] for the DNS 18
server address negotiation. The PDSN shall negotiate Primary and Secondary DNS server IP 19
addresses with the MS if the DNS Server Configuration options are received during the IPCP 20
phase. If the PDSN supports DNS server IP address VSA, it shall determine if the M bit is set 21
in the DNS Server IP Address VSA received in the RADIUS Access-Accept message. The 22
PDSN shall select DNS Server IP Address VSA, with the M bit set, for DNS information. If 23
PDSN receives a RADIUS Access-Accept message from the Visited RADIUS server that has 24
DNS IP address VSA(s) with the following values included, then the PDSN shall apply local 25
policies to select the DNS IP Address VSA for DNS information. 26
27
 A DNS IP Address VSA with the Entity-Type subfield set to the value 1 (=HAAA) 28
and the M bit unset, and/or 29
30
 One or more DNS IP Address VSA(s) with the Entity-Type subfield set to the value 31
2 (=VAAA). 32
33
3.2.1.4.2 IPv6 Addressing
34
35
If the MS-PDSN Version Capability Indication (see section 8) is used, and the MS signaled
36
that it does not support Simple IPv6 (C2 bit set to 0), then the PDSN shall not negotiate
37
IPv6CP with the MS and shall not send IPv6 Router Advertisements to the MS.
38
If the MS-PDSN Version Feature Indication is used, and the MS signaled that it supports 39
Simple IPv6 (C2 bit set to 1), then the PDSN shall provide Simple IPv6 service to the MS as 40
41
described in the rest of this section.
42
For an IPv6 MS, the PDSN shall be the default router and the PPP termination point. The 43
PDSN shall allocate one globally unique /64 prefix to each PPP link. The PDSN shall not 44
construct any global address from this prefix. 45

46
The PDSN shall support the following RFCs, with exceptions as noted in this document: 47
48
49
 An IPv6 Aggregatable Global Unicast Address Format [RFC 3587];
50
 Internet Protocol, Version 6 (IPv6) Specification [RFC 2460]; 51

52
 Neighbor Discovery for IP Version 6 (IPv6) [RFC 2461]; 53
54
 IPv6 Stateless Address Auto-configuration [RFC 2462]; 55
56
 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6
57
(IPv6) Specification [RFC 2463]; 58
59
60
1
2
3  IP Version 6 over PPP [RFC 2472];
4
5  IP Version 6 Addressing Architecture [RFC 3513].
6
7 The PDSN shall perform Interface-Identifier negotiation as described in [RFC 2472].
8 Interface-Identifiers used by the PDSN and the MS are configured via IPv6CP. The PDSN
9 shall provide to the MS a valid non-zero Interface-Identifier of the PDSN in the IPv6CP
10 Configure-Request. The PDSN shall provide a valid non-zero Interface-Identifier for the MS
11 in IPv6CP Configure-NAK if the MS‟s proposed Interface-Identifier is not acceptable to the
12 PDSN. While communicating with the MS, the PDSN shall use only the link local address
13 that it constructed with its Interface-Identifier that it provided to the MS (i.e. PDSN‟s
14 Interface-Identifier) during IPv6CP phase. Because the Interface-Identifier negotiated in the
15 IPv6CP phase of the PPP connection setup is unique for the PPP connection, it is not required
16 to perform duplicate address detection for the link local address formed as part of IPv6
17 stateless address auto-configuration [RFC 2462].
18
19 Following successful IPv6CP negotiation and the establishment of a unique link-local address
20 forboth the PDSN and the MS, the PDSN shall immediately 1 transmit initial unsolicited
21 Router Advertisement (RA) messages on the PPP link using its link-local address as a source
22 address. The PDSN shall include a globally unique /64 prefix in the Router Advertisement
23 message to the MS. The MS uses this prefix to configure its global IPv6 addresses.
24
25 The PDSN shall send unsolicited Router Advertisement (RA) message for an operator
26 configurable number of times. Also, the PDSN shall set the interval between initial RA
27 messages to an operator configurable value, which may be less than
28 MAX_INITIAL_RTR_ADVERT_INTERVAL. After the configurable number of initial
29 unsolicited RA messages has been transmitted, the interval between the periodic
30 transmissions of unsolicited RA messages shall be controlled by the router configurable
31 parameters MaxRtrAdvInterval and MinRtrAdvInterval as defined in [RFC 2461]. The PDSN
32 may set MaxRtrAdvInterval to a value greater1F than 1800 seconds and less than 1/3 of the
33
AdvDefaultLifetime. The PDSN shall set MinRtrAdvInterval 2 to a fraction of
34
MaxRtrAdvInterval as per [RFC 2461].
35
36 The PDSN shall send a RA message in response to a Router Solicitation (RS) message
37 received from the MS. The PDSN may set the delay between consecutive (solicited RA) or
38 (solicited /unsolicited RA) messages sent to the all-nodes multicast address to a value less3
39 than that specified by the constant MIN_DELAY_BETWEEN_RAS, contrary to the
40
specification in sec. 6.2.6 of [RFC 2461].
41
42 The advertised /64 prefix4 identifies the subnet associated with the PPP link. The /64 prefix
43 advertised by the PDSN shall be exclusive to the PPP session.
44
45 The PDSN shall set:
46
47
 the M-flag = 0 in the RA message header;
48
49  the L-flag = 0 and the A-flag =1 in the RA message Prefix Information Option.
50
51 The PDSN shall set the Router Lifetime value in the Router Advertisement message to a value
52 of 216-1 (18.2 hrs).
53
54
55 1
This is an exception to [RFC 2461] necessary to optimize applicability over the cdma2000 wireless air-interface.
56 2
This may cause an exception to [RFC 2461] as it may put the interval outside the normal range. This exception is allowed
57
by this document to optimize IPv6 RA over the cdma2000 wireless links.
58 3
This exception is allowed by this document to optimize IPv6 RA over the cdma2000 wireless links.
59 4
If the Access Service Provider desires to reduce frequent unsolicited RA for the prefix, it should set the 32-bit Valid
60 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).
The PDSN shall not send any redirect messages to the MS over the PPP interface. 1
2
3
3.2.1.5 DHCPv4 Support
4
5
The PDSN shall support DHCP Relay Agent function as specified in [RFC 1542] and [RFC
6
3046]. If the PDSN includes the Relay Agent Information Option, it shall set the giaddr field
to the Relay Agent‟s IP address, and include one of the following values in the Agent Remote 7
8
ID Sub-option of the Relay Agent Information Option:
9
 User name = NAI of the user (DHCP client) used to setup the PPP/MIP session. 10
11
 The remote IP address of a point-to-point link = IPv4 address assigned to the MS via 12
IPCP negotiation. 13
14
The PDSN assigns IPv4 address to MS via IPCP IP address configuration option. However, 15
if the MS acquires additional IPv4 addresses from a DHCP server using a PDSN as the relay 16
agent, the PDSN shall store the additional IPv4 addresses. The PDSN shall create one or more 17
new accounting UDRs depending on the number of service connections established for each 18
of these additional IPv4 addresses. 19
20
The PDSN shall relay the DHCP message received from the MS on port 67 to the DHCP 21
server(s) IP address(es) configured in the PDSN as specified in [RFC 3046]. 22
23
The PDSN shall include a DHCP Relay Agent Information option [RFC 3046] when relaying 24
the DHCP messages to the server and shall set the giaddr field to the relay agent IP address. 25
The PDSN may support [RFC 3527] to indicate the link on which the DHCP client (i.e., MS) 26
resides if different from the link from which the agent is communicating with the server. The 27
PDSN shall identify the DHCP client based on the PPP connection over which the DHCP 28
messages were received. 29
30
The PDSN shall relay the DHCP messages received from the DHCP server(s) to the MS over 31
PPP using the address specified in the ciaddr field. 32
33
If the DHCP message received from the DHCP server is a DHCPAck message and contains a
34
non zero value in yiaddr field, the PDSN shall store the assigned IPv4 address and the value
35
in the IP address lease time option as part of the user state information and shall initiate a
36
RADIUS Accounting-Request (start) message, which includes the assigned IPv4 address and
37
the NAI used during Simple IP authentication. 38
39
If the IP address lease time expires and the address has not been renewed or if the PDSN
40
receives a DHCP release packet from the MS, the PDSN shall remove the binding created for
41
that IPv4 address and shall send a RADIUS Accounting-Request (Stop). If the PPP session is
42
closed, the PDSN shall send a RADIUS Accounting-Request (Stop) for all the IPv4 addresses
43
that may have been assigned through DHCP in addition to the Accounting-Request (Stop)
44
required for the initial IP address assigned through IPCP. 45
46
The following figure shows a flow diagram where DHCP is used for MS configuration of
47
other parameters (e.g., DNS, PCSCF, BCMCS Controller addresses) after it acquired an IP
48
address via IPCP.
49
50
51
52
53
54
55
56
57
58
59
60
1
2
3
4
5
6
MS PDSN DHCP AAA
7
8
9
LCP (a)
10
11
EAP/CHAP/PAP(b) Access-Request/Accept (c)
12
13 IPCP negotiation (IP
14 address) (d) Accouting-Request (start)/ Response (e)
15
16
DHCP Inform (f)
17
18
DHCP Inform (g)
19 DHCPAck (h)
DHCPAck (i)
20
21
22
23
24
25
26
Figure 1 MS Parameters configuration with DHCP
27
28
29 a-d. The MS and the PDSN negotiate LCP and EAP, (or CHAP or PAP). Following the LCP
30 phase and successful authentication operation, the Simple IP MS shall include the IP
31 configuration option in the IPCP configure-request to configure its simple IPv4 address.
32
33
e. The PDSN creates a UDR for the IP address/NAI pair and sends a RADIUS Accounting-
34 Request (start) to the RADIUS server.
35
f. If the MS wants to configure other parameters using DHCP, it sends a DHCPInform with
36
37
the IP destination address set to the limited broadcast address (all 1s), assuming the MS
38
does not know the DHCP server‟s IP address.
39
g. The PDSN relays the DHCP packet to the DHCP server(s) as per [RFC 3046].
40
41 h. The DHCP server(s) responds by sending a DHCPAck that contains the options desired
42 by the MS, and may include additional options that are not specifically requested.
43
44 i. The PDSN relays the DHCPAck message to the MS‟s IP address over the PPP link.
45
46 3.2.1.6 Stateless DHCPv6 Support
47
48 The PDSN shall support DHCPv6 Relay Agent as specified in [RFC 3315] and [RFC 3736],
49 and shall set the O bit to 1 in the Router Advertisement messages sent to the MS.
50
51 Upon receiving a DHCPv6 Information-Request packet from the MS, the PDSN shall set the
52 peer-address field in the Relay Forward message to the source IPv6 address of the received
53 DHCPv6 packet from the MS. The PDSN shall set the link address field to the global IPv6
54 address of the MS. Additionally the PDSN may include the Interface-Identifier option
55 carrying the Interface-Identifier that the MS negotiated during PPP setup.
56
57 Upon receiving DHCPv6 Relay-reply message(s) from one or more DHCPv6 servers, the
58 PDSN shall relay the message according to section 20.2 of [RFC 3315].
59
60
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]).
1
2
3
MS PDSN DHCPv6 AAA 4

5
6
LCP (a)
7
EAP/CHAP/PAP(b) Access-Request/Accept(c) 8
9
IPv6CP negotiation (d)
10
RA (O-flag set) (e) 11
Accouting-Request (start)/ Response (f)
12
13
Information-Request (g)
14
Relay-Forward (h) 15
16
Relay-Reply (i)
17
Reply (j) 18
19
20
21
22
23
Figure 2 Configuration of MS’s parameters using DHCPv6 24
25
26
a-d. The MS and the PDSN negotiate LCP and EAP, (or CHAP or PAP). Following the LCP
27
phase and successful authentication operation, the MS and the PDSN execute IPV6CP
28
and negotiate unique 64-bit Interface-Identifiers. 29
30
e. The PDSN sends a Router Advertisement with prefix information and sets the O-flag to
31
one, to indicate to the MS that it can use DHCPv6 to configure other parameters than the
32
IPv6 address.
33
f. The PDSN creates a UDR for the IPv6 prefix/Interface-Identifier/NAI and sends a 34
RADIUS Accounting-Request (start) to the RADIUS server. 35

36
g. The MS send an Information-Request message with the IP destination address set to the 37
All_DHCPv6_Relay_Agents_and_Servers multicast address defined in [RFC 3315] 38
[FF02::1:2]. The source address is the link local address created by the MS. The MS shall 39
include the Option Request option (ORO) to indicate which options the client is 40
interested in receiving. 41
42
h. The PDSN creates a Relay-forward message. The "Relay Message" option shall include 43
the entire Information-Request message. The PDSN sends the message to the 44
ALL_DHCPv6_Servers address [FF05::1:3] or to the DHCPv6 server(s) that may be 45
configured in the PDSN. 46

47
i. The DHCPv6 server receives the Relay-forward and replies to the relay agent with a 48
Relay-reply, which contains the REPLY message with all the options requested by the 49
MS in the Option Request Option (ORO), and may include additional options. 50
51
j. The PDSN extracts the Reply message and forwards it to the MS. 52
53
3.2.1.7 Dual Stack of IPv4 and IPv6 Requirements 54
55
For dual IP stacks of IPv4 and IPv6, the single EAP/CHAP/PAP authentication is performed. 56
If the NCP transitions to the stopped state (either because the NCP failed to establish, or 57
because the NCP was torn down gracefully) and the PDSN allows the establishment of that 58
59
60
1
2
3 NCP at a later time upon the receipt of NCP configure request, the NCP shall remain in the
4 stopped state until a configure request from the MS is received.
5
6
7 3.2.1.8 Compression
8
9 The PDSN shall support the following header compression algorithm:
10
11
 Van Jacobson TCP/IP header compression [RFC 1144].
12
13 The PDSN may support the following header compression algorithms:
14
15
 ROHC, Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC
16
17
3095] with ROHC over PPP [RFC 3241];
18
 ROHC: A Link Layer Assisted Profile for IP/UDP/RTP [RFC 3242];
19
20  IP Header Compression [RFC 2507] with IP Header Compression over PPP [RFC
21 2509];
22
23  Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-
24 Layer Assisted RObust Header Compression (ROHC) Profile [RFC 3408];
25
26  Compressing IP/UDP/RTP headers on links with high delay, packet loss and
27 reordering [RFC 3545] with IP Header Compression over PPP [RFC 3544].
28
29
If the PDSN is able to process received compressed header packets from the MS using various
30
header compression protocols, the PDSN shall include the appropriate configuration option(s)
31
to the MS to indicate which IP Header Compression protocol it supports in the IPCP or
32
IPv6CP Configure-Request message as defined by [RFC 1332], [RFC 3241], [RFC 2509],
33
and [RFC 3544].
34
35
The PDSN shall support CCP [RFC 1962] for the negotiation of PPP payload compression.
36
The PDSN shall support 4F the following algorithms of PPP payload compression:
37
38  Stac-LZS [RFC 1974];
39
40  Microsoft Point-To-Point Compression Protocol [RFC 2118];
41
42
The PDSN may support other PPP payload compression algorithms.
43
44 3.2.1.9 PPP Framing
45
46 The PDSN shall frame PPP packets sent on the PPP link layer using the octet synchronous
47 framing protocol defined in [RFC 1662], except that there shall be no inter-frame time fill
48 (see 4.4.1 of [RFC 1662]). That is, no flag octets shall be sent between a flag octet that ends
49
one PPP frame and the flag octet that begins the subsequent PPP frame.
50
51 For IPv6, the PDSN shall set the MTU size as specified in [RFC 2460].
52
53
3.2.1.10 PPP Link Status Determination
54
55 For Always On users, the PDSN shall support the 3GPP2 vendor specific Max PPP Inactivity
56 Timer packet defined in PPP Vendor specific packet [RFC 2153] and the following
57
configurable timer and counter:
58
59  Echo-Reply-Timeout timer.
60
 Echo-Request-Retries counter.
The MAX PPP Inactivity timer packets shall be sent as LCP packets with PPP Protocol ID set 1
to C021(hex) 2
3
If the MS-PDSN Version Feature Indication (see section 9) is used, and the MS signaled that 4
it does not support the Max PPP Inactivity Timer (C4 bit set to 0), then the PDSN shall not 5
send the Max PPP Inactivity Timer to the MS. If the MS-PDSN Version Feature Indication 6
(see section 9) is used, and the MS signaled that it does not support the NCP Inactivity Timer 7
(C5 bit set to 0), then the PDSN shall not include any fields following the Max PPP Inactivity 8
Timer value in MAX PPP Inactivity Timer packet. The MS shall set C4 bit to „1‟ if the MS 9
sets C5 bit to „1‟. 10
11
The format of the Max PPP Inactivity Timer packet is shown in Figure 3 . 12
13
0 7 8 15 16 23 24 31
14
Code Identifier Length 15
Magic Number 16
OUI Kind 17
18
MAX PPP Inactivity timer value
19
Reserved 1 Number of NCP Timers 20
The Number of NCP Timers occurances of the following fields: 21
Reserved 2 NCP Type 22

23
NCP Inactivity timer
24
25
26
Figure 3 Max PPP Inactivity Timer Packet
27
28
Code = 0 (As defined in [RFC 2153]) 29

30
Identifier = The Identifier field shall be changed for each Vendor Specific
31
packet sent. It is used to match requests with responses.
32
Length = >= 12 (octets) 33
Magic Number = The Magic-Number field is four octets and aids in detecting 34
links that are in the looped-back condition. Until the Magic- 35
Number Configuration Option has been successfully 36
negotiated, the Magic-Number shall be transmitted as zero. 37
See the Magic-Number Configuration Option in [RFC 1661] for 38
further explanation. 39
OUI = 0xCF0002 40
41
Kind (1 octet) = 1, MAX PPP Inactivity Timer Packet
42
8, Max PPP Inactivity Timer Response
43
Max PPP Inactivity Timer Value(4 If Kind = 1, 32-bit value = PPP inactivity time + 44
octets) = Echo_Reply_Timeout timer ×(Echo_Request_Retries + 1) 45
If Kind = 8, the Value field shall not be included.
46
Reserved 1 (3 octets) = Reserved bits. If Kind =1 and if this field is present, it shall be 47
set to all zeros. If Kind = 8, this field shall not be included. 48
Number of NCP Timers (1 octet) The number of NCP Inactivity timers that are included in this 49
= packet. If Kind =1 and if this field is present, it shall be 50

encoded as an interger between 0 and 15. If Kind = 8, this field 51
shall not be included. 52
53
If Number of NCP Timers field is present and set to a value greater than 0, there shall be Number of
NCP Timers occurrences of the following fields. Otherwise, the following fields shall not be 54
included.: 55
56
Reserved 2 (3 octets) = Reserved bits. It shall be set to all zeros.
57
NCP Type (8 bits) = NCP Type for NCP Inactivity timer, 00000000 = IPCP, 58
59
60
1
2
3
00000001 = IPv6CP; other values are reserved.
4
5
NCP Inactivity Timer (32 bits) = NCP inactivity time in unit of second.
6
7
8
Upon entering the IPCP and/or IPv6CP Opened state on a PPP session configured for Always
9
On Service, the PDSN shall start the PPP inactivity timer for the PPP session, and unless the
10 MS signaled that it does not support the Max PPP Inactivity Timer, the PDSN shall send the
11 3GPP2 vendor specific Max PPP Inactivity Timer packet [RFC 2153] over the main service
12 connection. The PDSN should resend the Max PPP Inactivity Timer packet a configurable
13 number of times if no response from the MS is received. The Max PPP Inactivity Timer Value
14 field shall be equal to [PPP inactivity timer + Echo_Reply_Timeout timer ×
15 (Echo_Request_Retries + 1)] for the PPP session. The PDSN shall reset the PPP inactivity
16 timer upon detection of traffic activity.
17
18 When the MS that complies with this revision of document or later revisions receives the Max
19 PPP Inactivity Timer packet from the PDSN, the MS shall send the Max PPP Inactivity Timer
20 Response packet to the PDSN.
21
22
If the PPP inactivity timer value, Echo-Reply-Timeout timer and/or Echo-Request-Retries
23
counter have changed by an administrative action, the PDSN shall send the 3GPP2 vendor
24 specific Max PPP Inactivity Timer packet over the main service connection.
25
Upon expiration of the PPP inactivity timer, the PDSN shall send an LCP Echo-Request
26
27
message [RFC 1661] over the main service connection, and start the Echo-Reply-Timeout
28
timer for the PPP session. It shall also initialize the Echo-Request-Retries counter to a
29
configurable integer value.
30
Upon receipt of an LCP Echo-Reply message, an LCP Code-Reject [RFC 1661], or any other
31
packets over the main service connection or secondary service connection(s), the PDSN shall
32
stop and reset the Echo-Reply-Timeout timer, reset the Echo-Request-Retries counter, and
33
34
reset the PPP inactivity timer.
35
Upon expiration of the Echo-Reply-Timeout timer and when the Echo-Request-Retries
36
counter value is greater than zero, the PDSN shall send an LCP Echo-Request message,
37
decrement the Echo-Request-Retries counter by one, and start the Echo-Reply-Timeout timer.
38
Upon expiration of the Echo-Reply-Timeout timer and when the Echo-Request-Retries
39
counter value is equal to zero, the PDSN shall close the PPP session. In this case, the PDSN
40
41
shall not send an LCP Terminate-Request to the MS.
42
Upon establishing IPv4 and IPv6 simultaneous sessions, the PDSN may send the MAX PPP
43
Inactivity Timer packet containing the NCP Inactivity timer field if the MS has indicated that
44
it supports this version (i.e., version field in version/capability packet is set to 1) and the Max
45
PPP Inactivity Timer and NCP Inactivity Timer (C4 and C5 are set to 1, see section 9). When
46
the NCP Inactivity timer is sent, the PDSN shall indicate the NCP type that the NCP
47
48
Inactivity timer applies. The NCP Inactivity timer shall apply to NCP identified in the NCP IP
49
Version field. If the NCP Inactivity timer is provided, both the PDSN and the MS shall
50
maintain the NCP Inactivity timer for the NCP identified in the NCP type field. If this timer
51
expires, the PDSN and the MS shall close that NCP and may send the IPCP-Term Request or
52 IPv6CP-Term-Request for the corresponding NCP depending on the operator‟s policy.
53
The PDSN may send the MAX PPP Inactivity timer packet with new values if needed. If a
54
55
MAX PPP Inactivity Timer packet with new values is received, the MS shall override the
56
timer values. The NCP Inactivity timer value that is not included in the MAX PPP Inactivity
57
Timer packet shall not be affected.
58
If the NCP that does not have an associated NCP Inactivity timer is terminated, the remaining
59
NCP Inactivity timer(s) shall not be impacted in the PDSN and MS.
60
The PDSN and MS shall reset the NCP inactivity timer upon detection of traffic activity over 1
the corresponding NCP. 2
3
4
3.2.2 RADIUS Support 5
6
The PDSN shall act as a RADIUS client in accordance with [RFC 2865] and shall
7
communicate EAP, CHAP or PAP authentication information to the Visited RADIUS server
8
in a RADIUS Access-Request message. Upon receipt of the EAP, CHAP or PAP response 9
from the MS, the PDSN shall create a RADIUS Access-Request message in accordance with 10
Table 1. 11
12
If EAP is used for authentication, the PDSN shall also support the following RFCs:
13
 RFC 3579, RADIUS (Remote Authentication Dial In User Service) Support For 14
Extensible Authentication Protocol (EAP), 15

16
 RFC 2548, Microsoft Vendor-specific RADIUS Attributes. 17
18
For EAP authentication, when the Session-Timeout attribute is present in a RADIUS Access- 19
Accept message, the PDSN shall use it to set the EAP session lifetime. 20
21
Table 1 Occurrence of RADIUS Attributes for Simple IP 22
23
Attribute Name Type Access- Access- Access- Interface(s)
24
Request Accept Challenge
25
User-Name 1 M M PDSN <-> AAA 26
User-Password 2 O Note 1 PDSN -> AAA 27

28
CHAP-Password 3 O Note 2 PDSN -> AAA 29
NAS-IP-Address 4 O Note 3 PDSN -> AAA 30
31
MS-MPPE-Send-Key 26/16 O PDSN <- AAA
32
(Vendor
Type = 33
311) 34
35
MS-MPPE-Recv-Key 26/17 O PDSN <- AAA
36
(Vendor
37
Type =
38
311)
39
Session-Timeout 27 O PDSN <- AAA 40
EAP-Message 79 O O O PDSN <-> AAA 41

42
NAS-IPv6-Address 95 O Note 3 PDSN -> AAA
43
CHAP-Challenge 60 O PDSN -> AAA 44
45
Correlation ID 26/44 M O PDSN <-> AAA
46
Calling-Station-ID 31 M PDSN -> AAA 47
Always On 26/78 O PDSN <- AAA 48
5 49
NAS-Port-Type 5F 61 O PDSN -> AAA
50
Carrier-ID 26/142 M PDSN->AAA 51
IP-Services-Authorized 26/185 O PDSN <- AAA 52

53
Accounting-Mode 26/198 O PDSN <- AAA
54
55
56
57
5
The values are as follows: 22 (IS-2000) [5-9] or 24 (HRPD) [15], depending on the service option 58
number connected to the PDSN. 59
60
1
2
3
4
5 (M) Indicates Mandatory Attribute
6
7 (O) Indicates Optional Attribute
8
Note 1: User-Password is mandatory if PAP.
9
10
Note 2: CHAP-Password is mandatory if CHAP.
11
12 Note 3: At least one of NAS-IP-Address or NAS-IPv6-Address shall be included.
13
14 Additional RADIUS attributes and VSAs may be included in the RADIUS Access-Request
15 and returned in the RADIUS Access-Accept messages as per [Chapter 5].
16
17
The Correlation ID VSA and Always On VSA are in addition to those fields specified by
18
[RFC 2865] and [RFC 3162].
19
The PDSN shall also act as a RADIUS accounting client in accordance with [RFC 2866] and
20
shall communicate user accounting information to the Visited RADIUS server in RADIUS
21
22
Accounting-Request (Start and Stop) records. The RADIUS Accounting-Request message
23
shall contain the accounting attributes as specified in [Chapter 5]. The PDSN may also send
24
RADIUS Accounting-Request (Interim-Update) records between the Accounting-Request
25
Start and Stop messages as necessary in accordance with Annex A of [Chapter 5].
26
The security of communications between the PDSN and the RADIUS server may optionally
27
be provided with IP security. The establishment of the security association is outside the
28
29
scope of this document.
30
When the PDSN sends a RADIUS Access-Request message, it may include both IPv4 and
31
IPv6 specific attributes and/or VSAs. This is because the PDSN may not know a priori
32
whether the MS intends to use IPv4, IPv6, or both, since the address assignment does not
33
occur until after RADIUS authentication and authorization has completed. As per [RFC 3162],
34
the IPv6 attributes may be sent along with IPv4-related attributes within the same RADIUS
35
36
message. The PDSN decides to use IPv4 and/or IPv6 specific attributes and/or VSAs that it
37
receives in the RADIUS Access-Accept message based on whether the MS initiates IPCP
38
and/or IPv6CP.
39
40 3.2.2.1 NAI Construction in the Absence of EAP, CHAP or PAP
41
42 In the event that the MS does not negotiate EAP, CHAP or PAP, no MS NAI is received by
43 the PDSN. In this case, the PDSN shall not perform additional authentication of the user. If
44 the PDSN is capable of constructing a properly formatted NAI based on the MSID, using the
45 syntax defined in [RFC 2486], then accounting records shall be generated and keyed on the
46 user‟s constructed NAI. The NAI shall be constructed using the syntax defined in [RFC 2486],
47 in the form <MSID>@<realm>, where <MSID> is the MSID of the MS, and <realm> is the
48 name of the home network that owns the MS‟s MSID. If the PDSN is unable to construct an
49 NAI for an MS, then the PDSN may deny service to the MS.
50
51 The PDSN shall use one of the following MSID formats to construct the NAI, as provided by
52 the RAN:
53
54  International Mobile Subscriber Identity (IMSI) [E.212];
55
 Mobile Identification Number (MIN) [3];
56
57  International Roaming MIN (IRM) [2].
58
59 The PDSN shall store the constructed NAI into the accounting records, and the Visited
60 RADIUS server may use the realm to forward these records to the correct Home RADIUS
server for proper summary and settlement 6 . The constructed NAI shall not be used for 1
authentication. If configured by the operator, the PDSN shall send RADIUS accounting 2
messages to the Visited RADIUS server using the constructed NAI in the absence of EAP, 3
CHAP or PAP. 4
5
6
3.2.3 Ingress Address Filtering 7
8
For IPv4, the Serving PDSN shall check the source address of every packet received on the 9
PPP link from the MS. 10
7 11
Upon receiving a packet from the MS with invalid source IP address, the PDSN shall discard
the packet and may send an LCP Configure-Request message to restart the PPP session8 if 12
13
IPCP has reached the open state.
14
If the PDSN receives an implementation-defined number of consecutive packets with an 15

16
invalid source IP address from the MS, the PDSN shall send an LCP Configure-Request
17
message to the MS.
18
If the PDSN receives a DHCP packet over port 67, the PDSN shall forward the message to the 19
configured DHCP server(s) IP address(es) as described in section 3.2.1.5. 20

21
For MIP4 and simultaneous Simple IP and MIP4 sessions see section 4.2.5. 22
23
For IPv6, the Serving PDSN shall check the prefix of the source IP address of every packet 24
received on the PPP link from the MS. If the prefix is not associated with the PPP Session of 25
the MS, then the PDSN shall discard the packet and may send an LCP Configure-Request to 26
restart the PPP session. If the PDSN receives an implementation-defined number of 27
consecutive packets with an invalid prefix from the MS, the PDSN shall send an LCP 28
Configure-Request message to the MS. If the source address is the IPv6 unspecified address 29
and the message type is Neighbor Solicitation for Duplicate Address Detection (DAD), then 30
the PDSN shall silently discard the packet received from the MS. If the source address is the 31
IPv6 unspecified address for purposes other than Duplicate Address Detection (DAD) or the 32
source address is the MS‟s IPv6 link-local address, the PDSN shall respond according to 33
[RFC 2461]. 34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
6
The Home RADIUS server may require an MSID to user conversion table to map the constructed NAI 51
(msid@realm) to the user's actual NAI (user@realm) to complete the billing process in cases where the 52
constructed NAI differs from the actual NAI. 53
7
The source IP address from the MS is considered as invalid if it is not one of the addresses that have 54
been assigned to the MS or if the MS has not been assigned any IP addresses. 55
8
The reason to restart PPP is because the user could have started a Simple IP session during a previous 56
dormant handoff to another PDSN and returned; in this case the current PDSN would not know the MS 57
had invoked Simple IP and received another IP address. Thus, restarting PPP will force the Simple IP 58
session to get a topologically correct address. 59
60
1
2
3
4
3.3 RADIUS Server Requirements
5
The RADIUS server shall follow the guidelines specified in [RFC 2865], [RFC 2866], [RFC
6
7
3162], [RFC 3576], [RFC 3579], [RFC 3748], and [RFC 4187].
8
The Visited and Home RADIUS server shall support the attributes as specified in Table 1 and
9
[Chapter 5], the Interim Accounting Record as described in Annex A of [Chapter 5] as well as
10
the accounting attributes listed in [Chapter 5].
11
12 The Home RADIUS server may include the „Always On‟ attribute in the RADIUS Access-
13 Accept message to indicate an “Always On Service” for a user, based on the User Profile.
14
15 If the MS uses EAP, CHAP or PAP, the PDSN sends the Visited RADIUS server a RADIUS
16 Access-Request message with EAP, CHAP or PAP authentication information. The Visited
17 RADIUS server shall forward the RADIUS Access-Request message to the home network or
18 a peer (e.g., a broker) if it does not have the authority to accept/deny the request. This is in
19 accordance with [RFC 2865]. Upon receiving a RADIUS Access-Request message, the Home
20 RADIUS server shall send a RADIUS Access-Accept message, RADIUS Access-Challenge
21
message, or RADIUS Access-Reject message to the Broker or Visited RADIUS server. The
22
Visited RADIUS server shall send the received response to the PDSN.
23
24 If EAP-AKA is used for authentication, the AAA server may support the anonymity feature
25 with pseudonyms in EAP-AKA. If the EAP-AKA authentication is successful, the AAA
26 server shall derive the MSK according to [RFC4187]. The AAA server shall send the MSK to
27 the PDSN via the MS-MPPE-Recv-Key attribute (for the first 32 bytes of the MSK) and MS-
28
MPPE-Send-Key attribute (for the second 32 bytes of the MSK) in the RADIUS Access-
29
Accept message. The HAAA shall also send the EAP session lifetime in seconds via the
30
Session-Timeout attribute in the RADIUS Access-Accept message.
31
32 If the RADIUS Access-Request message contains IPv4 and IPv6 specific attributes and/or
33 VSAs, the RADIUS server should include the IPv4 and/or IPv6 attributes as provisioned in
34 the user profile (e.g. Framed-Interface-Id, Framed-IPv6-Prefix etc.) and/or VSAs in the
35
RADIUS Access-Accept message.
36
37 Upon receiving RADIUS Accounting-Request records from the PDSN, the Visited RADIUS
38 server shall forward the RADIUS Accounting-Request records to the home or broker network.
39
40 The communication between RADIUS client and RADIUS server or between RADIUS
41 servers shall be protected using the secret shared with the next hop RADIUS server using the
42 procedures described in [RFC 2865].
43
44
45 3.4 MS Requirements
46
47 The MS may support Simple IP. The MS may choose Simple IP for IPv4 only, IPv6 only, or
48 both IPv4 and IPv6 simultaneously. The MS shall access the cdma2000® 9 packet data service
49 using the cdma2000 air interface [5-9], [15].
50
51
52 3.4.1 PPP Session
53
54 The MS shall use PPP as the data link layer protocol for Simple IP.
55
56
57
58 9
cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of
59 the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication),
60 cdma2000® is a registered trademark of the Telecommunications Industry Association (TIA-USA) in
the United States.
2
If the cdma2000 1x MS supports multiple service connections, refer to [Chapter 4] for details 3
of PPP negotiation. Otherwise, for a new PPP session, the cdma2000 1x MS shall use a 4
service instance of SO type 33 to perform PPP negotiation with the PDSN as described in 5
[RFC 1661]. 6
7
If the HRPD MS supports multiple link flows, refer to [Chapter 4] for details of PPP 8
negotiation. Otherwise, for a new PPP session, the HRPD MS shall use the main link flow 9
with default reservation label 0xff to perform PPP negotiation with the PDSN as described in 10
[RFC 1661]. 11
12
PPP shall support control escaping in accordance with section 4.2 of [RFC 1662]. The PPP 13
Link Layer shall support negotiation of Asynchronous Control Character Mapping as defined 14
in [RFC 1662]. The MS should attempt the minimum number of escapes by negotiating an 15
ACCM of 0x00000000. The MS should not send an LCP Configure-Reject in response to an 16
ACCM configuration option proposed by the PDSN in an LCP Configure-Request. 17
18
3.4.1.2 Termination 19
20
When the MS deactivates packet data service, the MS should send an LCP Terminate-Request 21
message to the PDSN to gracefully close the PPP session before releasing the packet data 22
service connections with the RAN. In the case of power-down registration [5-9], the MS shall 23
not send an LCP Terminate-Request message to the PDSN. 24

25
3.4.1.3 Authentication 26
27
The MS shall support EAP and CHAP and may support PAP authentication for Simple IP. 28
29
During the PPP session negotiation between the MS and the PDSN, if the MS receives LCP 30
Configure-Request from the PDSN that contains EAP or CHAP, the MS shall respond with 31
LCP Configure-Ack indicating to the PDSN the acceptance of EAP or CHAP. If the MS 32
receives LCP Configure-Request from the PDSN that contains PAP, the MS shall respond 33
with LCP Configure-Ack indicating to the PDSN the acceptance of PAP if the MS supports 34
PAP. 35
36
If the MS is configured not to use any of EAP, CHAP or PAP, the MS shall respond with an 37
LCP Configure-Reject message containing the Authentication-Protocol option proposed in the 38
LCP Configure-Request message received from the PDSN. 39

40
If the MS is configured to use CHAP, it shall respond to an LCP Configure-Request message 41
for EAP with an LCP Configure-Nak proposing CHAP. 42
43
If the MS is configured to use PAP, it shall respond to an LCP Configure-Request message 44
for EAP or CHAP with an LCP Configure-Nak proposing PAP. 45
46
For both CHAP and PAP, the MS shall send an NAI in the form of user@realm.
47
48
3.4.1.3.1 EAP-AKA Support
49
The MS shall support EAP-AKA [RFC 4187]. The MS may support the anonymity feature 50
with pseudonyms in EAP-AKA. If the MS receives the EAP-Identity request from the 51
52
network, it shall respond with an AKA permanent identity or an identity associated with the
53
AKA permanent identity.
54
55
57
The MS may support simultaneous operation of IPCP and IPv6CP. 58
59
60
1
2
3 The MS shall negotiate the IP address configuration option to acquire an IPv4 address from
4 the PDSN.
5
6 The MS may implement [RFC 1877] in order to auto-configure DNS server IP addresses. The
7 MS may negotiate Primary and Secondary DNS server IP addresses during the IPCP phase.
8 The MS may use default of zero for DNS server address negotiation.
9
10 3.4.1.4.1 IPv4 Addressing
11
12 A Simple IPv4 MS should send an IP address of 0.0.0.0 during the IPCP phase to request an
13 IP address from the network. The MS shall accept the address provided by the PDSN. If the
14 MS requests a non-zero IP address during the IPCP phase, the PDSN replies with an IPCP
15 Configure-Nak in response to the request in order to propose a different IP address. The MS
16 shall accept the new address, and shall send an IPCP Configure-Request to the PDSN with the
17 new IP address.
18
19 3.4.1.4.2 IPv6 Addressing
20
21
A Simple IPv6 MS shall support the following RFCs, with exceptions as noted in this
22 document:
23
 An IPv6 Aggregatable Global Unicast Address Format [RFC 3587];
24
25
 Internet Protocol, Version 6 (IPv6) Specification [RFC 2460];
26
27  Neighbor Discovery for IP Version 6 (IPv6) [RFC 2461];
28
29  IPv6 Stateless Address Auto-configuration [RFC 2462];
30
31
 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6
32
(IPv6) Specification [RFC 2463];
33
 IP Version 6 over PPP [RFC 2472];
34
35  IP Version 6 Addressing Architecture [RFC 3513].
36
37 The MS should support Privacy Extensions for Stateless Address Auto-configuration in IPv6
38 [RFC 3041]. To avoid disruption of an active session, e.g., Voice over IP, the MS should not
39 change the IPv6 address used for that session.
40
41 For IPv6, the MS shall perform Interface-Identifier negotiation as described in [RFC 2472].
42 The MS shall construct the link-local IPv6 address by pre-pending the link-local prefix FE80::
43 /64 [RFC 3513] to the Interface-Identifier negotiated during the IPv6CP negotiation phase
44 [RFC 2472]. When the Interface-Identifier is negotiated in the IPv6CP phase of the PPP
45 session setup, the MS should not perform duplicate address detection for the link local address
46 as part of IPv6 stateless address auto-configuration [RFC 2462].
47
48 The MS shall construct global IPv6 address by pre-pending the prefix received from the
49 Router Advertisement messages to the Interface-Identifier negotiated during the IPv6CP
50 negotiation phase [RFC 2472] or to the Interface-Identifiers generated using techniques
51 defined in [RFC3041]. The MS should not perform Duplicate Address Detection for global
52 IPv6 addresses (since the prefix used is a globally unique /64 and exclusive to the PPP
53 session).
54
55 Following the successful IPv6CP phase and auto-configuration of link-local address, the MS
56 may transmit a Router Solicitation (RS) message(s) if a Router Advertisement message has
57 not been received from the PDSN within a random amount of time between 0 and
58 MAX_RTR_SOLICITATION_DELAY seconds per [RFC 2461].
59
60 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 1
of RS messages to a value less 10 than that specified by the constant 2
MAX_RTR_SOLICITATIONS in [RFC 2461]. The MS may set the interval between the 3
configurable number of RS messages to a value less254H11 than or greater than that specified 4
by the constant RTR_SOLICITATION_INTERVAL in [RFC 2461]. 5
6
If the last RS message is sent and a RA message is not received after a router solicitation 7
interval, the MS shall send an IPv6CP Configure-Terminate message to the PDSN. Upon 8
reception of a RA message from the PDSN that contains the /64 globally unique prefix, the 9
MS shall perform stateless address auto-configuration for global IPv6 addresses as per [RFC 10
2462] (and [RFC 3041] for privacy purposes). 11
12
After establishment of a PPP link with the PDSN, the MS shall treat that PDSN as the default 13
router until the PPP session is closed. 14
15
3.4.1.5 DHCPv4 Support 16
17
The MS may support and use DHCP [RFC 2131] to request specific configuration parameters 18
[RFC 2132], which may include DNS addresses and/or SIP server addresses [RFC 3361].The 19
MS should not use DHCP [RFC 2131] to request additional IPv4 addresses. 20
21
To request specific configuration parameters, the MS shall send a DHCPInform message to 22
the limited broadcast address (all 1‟s) or to a DHCP server‟s address if it knows one. The MS 23
shall set the ciaddr field to its IPv4 address acquired during IPCP and shall include the 24
parameter request list option to indicate the options the MS is interested in receiving and may 25
include a vendor class option to request vendor specific information options. 26
27
3.4.1.6 Stateless DHCPv6 Support 28

29
The MS may support stateless DHCPv6 [RFC 3736] to obtain configuration information. The 30
MS should not use DHCPv6 [RFC 3736] to request additional IPv6 addresses. If the MS 31
supports stateless DHCPv6, and wants to obtain configuration information, it shall send a 32
DHCPv6 Information-Request message to the All_DHCP_Relay_and_Servers address 33

34
[FF02::1:2] and shall include the Option Request option to specify the options that it wishes
35
to receive from the DHCPv6 server, for example DNS configuration options [RFC 3646], SIP
36
server options [RFC 3319], and BCMCS Controller option [RFC 4280].
37
38
3.4.1.7 Compression 39
40
The MS shall support Van Jacobson TCP/IP header compression [RFC 1144]. The MS
41
additionally may support the following header compression algorithms: 42
 IP Header Compression [RFC 2507] with IP Header Compression over PPP [RFC 43
44
2509];
45
 ROHC Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 46
3095] with ROHC over PPP [RFC 3241]; 47

48
 ROHC: A Link Layer Assisted Profile for IP/UDP/RTP [RFC3242]; 49
50
 Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link- 51
Layer Assisted RObust Header Compression (ROHC) Profile [RFC 3408]; 52
53
 Compressing IP/UDP/RTP headers on links with high delay, packet loss and 54
reordering [RFC 3545] with IP Header Compression over PPP [RFC 3544]. 55
56
57
58
10
This exception is allowed by this document to optimize IPv6 RA over the cdma2000 wireless links. 59
60
1
2
3 The MS shall use IPCP and/or IPv6CP to negotiate with the PDSN one or more header
4 compression capabilities.
5
6 If the MS is able to process received compressed header packets from the PDSN using various
7 header compression protocols, the MS shall include the appropriate configuration option(s) to
8 indicate to the PDSN which IP Header Compression protocol it supports in IPCP or IPv6CP
9 Configure-Request message as defined by [RFC 1332], [RFC 3241], [RFC 2509], and [RFC
10 3544].
11
12 The MS shall support the PPP Compression Control Protocol [RFC 1962]. The MS may
13 support PPP payload compression. If the MS intends to use PPP payload compression, the MS
14 shall use PPP Compression Control Protocol to negotiate a PPP payload compression
15 algorithm supported by the MS.
16
17
3.4.1.8 PPP Framing
18
19 The MS shall use the octet-synchronous framing protocol defined in [RFC 1662]. One
20
exception is there shall be no inter-frame time fill (i.e., no flag octets shall be sent between a
21
flag octet that ends one PPP frame and the flag octet that begins the subsequent PPP frame) 11 .
22
23
24
3.4.1.9 PPP Link Status Determination
25
To support Always On service, the MS shall adhere to [RFC 1661] section 5.8 “Echo-Request
26
27
and Echo-Reply” with regards to LCP Echo-Request message processing, and the MS should
28
support the 3GPP2 vendor specific Max PPP Inactivity Timer value packet [RFC 2153].
29
Upon receiving a Max PPP Inactivity Timer packet, the MS shall send a reply and should use
30
the value received in the packet to maintain Always On connectivity.
31
32 The MS shall reset the Max PPP Inactivity Timer when any packets over the main service
33 connection or secondary service connection(s) are sent or received
34
35 Upon expiration of the Max PPP Inactivity Timer, the MS may initiate a new PPP session, or
36 may enter the inactive state
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60 11
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.
4 MIP4 Operation 2
3
This section describes the requirements and procedures for MIP4 operation for IPv4 [RFC 4
5
2002-2006]. In this document, MIP4 refers to a service in which the user is able to maintain a
6
persistent IP address even when handing off between RANs connected to different PDSNs.
7
MIP4 provides the user IP routing service to a public IP network and/or secure IP routing
8
service to private networks.
9
10
11
4.1 Common Service Specification 12
13
The common requirements for several network elements (e.g., PDSN and MS) for MIP4 14
operation are described here. 15
16

18
19
See Section 3.1.1.
20
For MIP4 only, neither CHAP nor PAP should be performed. If CHAP or PAP is performed, 21
longer initial setup time and re-establishment time will occur as the result of an additional 22
RADIUS server traversal. 23

24
Note that the MN-FA Challenge Extension procedures [RFC 3012] are performed regardless 25
of whether or not CHAP/PAP is performed. 26
27
28
4.1.2 MIP4 29
30
The following standards shall be used for MIP4 operations with any limitations or extensions 31
described in this document: 32
33
 [RFC 2002-2006];
34
 Reverse Tunneling [RFC 3024]; 35

36
 Foreign Agent Challenge/Response [RFC 3012]; 37
38
 NAI Extension [RFC 2794]. 39
40
41
4.1.3 Dynamic Home Agent and Home Address Assignment
42
43
In this document, an MS may request dynamic HA and/or Home Address assignment during
44
the initial MIP4 registration according to the following scenarios of Table 2 and Table 3 (and
45
also see section 4.5.2.2).
46
If the network receives an RRQ from the MS with an HA Address value of 0.0.0.0, the 47
network shall treat the value as 255.255.255.255 (see section 4.5.2.2). 48

49
50
51
52
53
54
55
56
57
58
59
60
4 MIP4 Operation 20
1
2
3 Table 2 Home Agent and Home Address Scenarios
4
5 Scenarios Type of Request Home Address Home Agent Address
6 specified in RRQ specified in RRQ
7
Scenario 1 Dynamic case 0.0.0.0 255.255.255.255 or 0.0.0.0
8
9 Scenario 2 Semi-static case x.x.x.x 255.255.255.255 or 0.0.0.0
10
Scenario 3 Semi-static case 0.0.0.0 y.y.y.y
11
12 Scenario 4 Static case x.x.x.x y.y.y.y
13
14
15
Table 3 Description of Scenarios
16
17
Scenarios Description
18
19 Scenario 1 This is for dynamic Home Address assignment and a dynamic HA assignment.
20
Scenario 2 In this scenario, the Home RADIUS server shall assign an appropriate HA to
21
the MS. The Home RADIUS server may use the specified Home Address to
22 select an HA for the MS.
23
24
Scenario 3 This corresponds to dynamic Home Address assignment and static HA
assignment.
25
26 Scenario 4 This is for static HA and static Home Address MIP4 registration, i.e., there is no
27 dynamic assignment.
28
29
30 For details on dynamic HA assignment see the following:
31
32  Section 4.2.2.4 for the PDSN.
33
34
 Section 4.3.4 for the HA.
35
 Section 4.4.1 for the Home RADIUS server.
36
37  Section 4.5.2.2 for the MS.
38
39
40 4.1.4 GRE CVSE
41
42
GRE tunneling support for MIP4 will permit asymmetric GRE keying i.e., the PDSN assigns
43 a GRE key for use in encapsulated traffic and the HA can assign its own GRE key. Once the
44 GRE keys have been exchanged, the PDSN uses the HA-assigned key in the encapsulating
45 GRE header for reverse tunneling and the HA uses the PDSN-assigned key in the
46 encapsulating GRE header.
47
48 1 2 3
49 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
50
Type Reserved Length
51
52 Vendor/Org-ID
53
Vendor-CVSE-Type Vendor-CVSE-Value….
54
Figure 4 GRE Key CVSE
55
56
57 Type: CVSE-TYPE-NUMBER 38
58
59 Reserved: Reserved for future use. To be set to '0'
60
21 4 MIP4 Operation
Length: Length in bytes of this extension, not including the Type and 1
Length bytes. 2
3
Vendor/Org-ID: 5535 4
5
Vendor-CVSE-Type: 1025 (04H 01H)
6
Vendor-CVSE-Value: This 32-bit field indicates to the receiver the value to use in the 7
GRE header Key field when sending GRE encapsulated traffic to 8
the initiating entity. The replying entity may select a Key value 9
10
different from the one received from the initiating entity.
11
The format of the GRE header to be used for tunneling datagrams is defined in [RFC 2890]. 12
The header format is reproduced here. 13

14
15
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 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 17
|C| |K|S| Reserved0 | Ver | Protocol Type | 18
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 19
| Checksum (optional) | Reserved1 (Optional) | 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 21
| Key | 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 23
| Sequence Number (Optional) | 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 25
26
Figure 5 GRE Header for Tunneling Datagrams 27
28
29
Protocol Type: 4 (IP)
30
Key: The value assigned by the PDSN and HA in RRQ/RRP messages 31
respectively. This field MUST be present in the GRE header. 32

33
GRE tunnel related parameters such as checksum and sequence numbers MAY be inserted by 34
the PDSN and/or HA based on local configuration. 35
36
37
4.2 PDSN Requirements 38

39
The PDSN shall support MIP4 operation and act as an FA. 40

41
42
44
The PDSN shall support multiple MIP4 Home Addresses over a single PPP session. 45
46
48
See Section 3.2.1.1. 49
50
52
The Serving PDSN shall close the PPP session if there is no established underlying A10 53
session or P-P session for the MS, respectively. The PDSN shall clear the A10 session and P- 54
55
P session, whenever the PPP session is closed. If the PDSN receives IP packets destined to an
56
MS for which there is no established PPP session, the PDSN shall silently discard the packet.
57
58
59
60
4 MIP4 Operation 22
1
2
3 If the PDSN receives a failure code in the RRP from the HA, then the PDSN shall deliver the
4 RRP to the MS, and shall not close the PPP session before a configurable timer expires. If the
5
PDSN generates a failure code, the PDSN shall deliver the RRP to the MS and shall not close
6
the PPP session before a configurable timer expires.
7
8 See Annex C for description of PPP Inactivity Timer and Session Timer.
9
10 The PDSN may receive the Always On attribute with value „1‟ from the Home RADIUS
11 server in order to activate the Always On service for a user. If the PDSN receives the Always
12 On attribute with value „1‟, it shall send the indicator to the RAN as indicated in [4].
13
14 If the MIP4 binding lifetime has expired for the Always On session and a MIP4 re-registration
15 has not been received from the MS, the PDSN shall send an LCP Terminate-Request to the
16 MS.
17
18 4.2.1.3 Authentication
19
20 The PDSN shall initially propose EAP/CHAP in an LCP Configure-Request message to the
21 MS. The PDSN shall re-send an LCP Configure-Request message without the authentication
22 option after receiving the LCP Configure-Reject (EAP, CHAP or PAP) from the MS.
23
24
4.2.1.4 Addressing with IPCP
25
26 If the MS-PDSN Version Feature Indication (see section 8) is used, and the MS signaled that
27
it supports MIP4 (C1 bit set to 1), then the PDSN shall provide MIP4 service to the MS. In
28
this case, when the MS requests MIP4 service and prior to the initial MIP4 registration, the
29
MS does not include an IP Address Configuration Option in the IPCP Configure-Request
30
message to the PDSN. If the MS includes an IP Address Configuration Option in the IPCP
31
Configure-Request, the PDSN considers this as an MS using Simple IP service. In this case,
32
the PDSN shall send an IPCP Configure-NAK with a new proposed IP address for the MS.
33
34
If the MS-PDSN Version Feature Indication (see section 8) is used, and the MS signaled that
35
it does not support MIP4 (C1 bit set to 0), then the PDSN shall not provide MIP4 service to
36
the MS. In this case, the PDSN shall send a NAK to propose an IP address to revert to Simple
37
IPv4 service.
38
39 During IPCP phase, the PDSN shall include the IP Address Configuration option containing
40 its IP address in the IPCP Configure-Request messages sent to the MS.
41
42 The PDSN shall not support [RFC 2290]. If the PDSN receives an IPCP Configure-Request
43 from the MS containing the MIP4 Configuration Option [RFC 2290], the PDSN shall reply
44 with an IPCP Configure-Reject message.
45
46 The PDSN shall implement the IPCP configuration options as defined in [RFC 1877] for DNS
47 server address negotiation. The PDSN shall negotiate Primary and Secondary DNS server IP
48 addresses with the MS, if DNS Server Configuration options are received during the IPCP
49 phase.
50
51 4.2.1.5 Compression
52
53 See Section 3.2.1.8.
54
55
4.2.1.6 PPP Framing
56
57
See Section 3.2.1.9.
58
59
60
23 4 MIP4 Operation
4.2.2 MIP4 Registration 1

2
3
4.2.2.1 Agent Advertisements
4
5
For the MS that uses MIP4, the PDSN shall begin transmission of an operator configurable
6
number of Agent Advertisements immediately following negotiation or re-negotiation of PPP,
7
or upon receipt of an Agent Solicitation message from the MS. Once the PDSN sends the
8
configurable number of Advertisements, the PDSN shall not send further Advertisements,
9
unless it receives an Agent Solicitation message from the MS. If the PDSN receives the RRQ
10
from the MS, the PDSN shall cease sending Agent Advertisements.
11
12
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. 13
14
The PDSN may also send an Agent Advertisement to the MS with the 'R' bit set if the PDSN
receives a packet with an invalid IP source address 12 from the MS when the PDSN hasn‟t 15
16
previously sent Agent Advertisements. If Agent Advertisements are being sent, the PDSN
17
shall not restart sending the configurable number of Agent Advertisements.
18
13 19
If the PDSN receives an RRQ with the 'D' bit set, the PDSN shall send an RRP with code 65 .
20
In this case, the PDSN shall not close the PPP session.
21
The MIP4 Registration Lifetime field in the Agent Advertisement shall be smaller than the 22
PPP inactivity timer value in use for the underlying PPP session. 23
24
Upon receiving a handoff indication including non-zero values of SID/NID/PZID of the 25
previous PCF and SID/NID/PZID of the current PCF, if the PDSN already supports a MIP4 26
service for the MS, the PDSN shall use this information to determine whether or not MIP4 re- 27
registration is required for the MS. If re-registration is required, then the PDSN shall re- 28
negotiate PPP and begin transmission of an operator configurable number of Agent 29
Advertisements. 30
31
In order to minimize Agent Advertisements sent over the air, the PDSN shall not send 32
unsolicited Agent Advertisements to an MS periodically to refresh the FA advertisement 33
lifetime. The MS may send Agent Solicitations, when the FA advertisement lifetime expires. 34
The Advertisement Lifetime is a configurable value, and shall be set to 9000 seconds (the 35
maximum ICMP router advertisement lifetime). 36

37
38
4.2.2.2 Addressing and MIP4
39
The PDSN shall support [RFC 2794], and therefore, support zero and non-zero Home Address 40
41
values in the MIP4 RRQ. For dynamic Home Address assignment, the PDSN shall accept
42
MIP4 RRQs with a 0.0.0.0 source address from the MS, and shall use the NAI instead of the
Home Address in it‟s pending registration request records, along with the Identification field 43
44
[RFC 2794]. For dynamic Home Address assignment, the PDSN shall acquire the MS‟s
45
Home Address from the MIP4 RRP.
46
In order to provide public network access and to provide private network access across the 47
48
Internet, the PDSN shall use a publicly routable and visible IP address as a FA address.
49
50
51
52
53
54
55
12
The source IP address from the MS is considered as invalid if it is not one of the addresses that have 56
been assigned to the MS or the MS has not been assigned with any IP addresses. 57
13
Previous version of this document uses code 77. In this document, the PDSN uses code 65, because 58
code 77 is not used in RFC 2002. 59
60
4 MIP4 Operation 24
1
2
3
4.2.2.3 MIP4 Extensions
4
5 The PDSN shall include the MN-FA Challenge Extension [RFC 3012] in the Agent
6 Advertisement. Because Advertisements are rarely sent (to save air resources), the PDSN
7
shall include in the RRP a new challenge that the MS should use in its next re-registration
8
with this PDSN. On re-registration, the PDSN may communicate user FAC authentication
9
information to the Home RADIUS server, via broker servers if required, in a RADIUS
10
Access-Request message. The frequency of this re-authentication and re-authorization is
11
configurable by the operator. The challenge shall be changed on a serving access provider
12
configurable basis.
13
14
If the RADIUS attribute “MN-AAA Removal Indication” is included in the RADIUS Access-
15
Accept message, and if the RRQ contains an MN-HA Authentication Extension followed by
16
the MN-FA challenge and MN-AAA Authentication Extension, the PDSN shall remove the
17
MN-FA challenge and the MN-AAA Authentication Extensions when relaying the RRQ to
18
the HA. Otherwise, the PDSN shall relay the RRQ to the HA as received from the MS.
19
20
21 4.2.2.4 Dynamic Home Agent Assignment
22
23
The PDSN shall include the Home Address that it receives in the RRQ message from the MS
24
in the RADIUS Access-Request message in RADIUS attribute 8 (Framed-IP-Address). The
25 PDSN shall include the HA Address that it receives in the RRQ message from the MS in the
26 RADIUS Access-Request message in the HA attribute (see [Chapter 5]). Upon receiving a
27 RADIUS Access-Accept message from the HAAA, the PDSN shall use the assigned HA
28 Address in the HA attribute of the RADIUS Accept message as the destination address of the
29 RRQ message (without modifying the HA field in the RRQ message originated by the MS).
30 Upon receiving an RRP message with successful registration indication (code 0) for the MS,
31 the PDSN shall update the mobility binding for the MS, which is indexed by the NAI and the
32 Home Address (if non zero) in the RRQ, with the HA Address and the Home Address from
33 the RRP.
34
35
4.2.2.5 Private Network Support
36
37 It is possible that two different MSs served by a PDSN have the same, overlapping private
38
address because they belong to two different private networks. To support this scenario, the
39
PDSN forms a logical association that contains the A10 Connection ID, the MS‟s Home
40
Address, and the HA Address. When the PDSN receives a packet for a registered MS from
41
the HA, the PDSN maps the MS‟s HA Address and the Home Address to one association, and
42
transmits the packet on the A10 connection indicated by the A10 Connection ID of the
43
association.
44
45
When processing additional MIP4 registrations for the same MS, if the PDSN receives an
46
RRP from a second HA that includes a private address as the Home Address, and if the
47
private address has already been assigned to the MS by another HA, the PDSN shall set the
48
Code field to 65 (administratively prohibited) before forwarding the RRP to the MS. The first
49
assigned address is not affected.
50
51
52
4.2.2.6 Reverse Tunneling
53
54
The PDSN shall reject a MIP4 registration with an error code of 75, if a private Home
55
Address as defined in [RFC 1918] is present in either the RRQ or RRP, and the RRQ did not
56 indicate reverse tunneling.
57
If the Home RADIUS server sends a Reverse Tunnel Specification attribute in the RADIUS
58
Access-Accept message indicating that reverse tunneling is required, and the MS did not
59
60
indicate reverse tunneling in the RRQ, the PDSN shall reject the registration with an error
code of 75.
25 4 MIP4 Operation
The PDSN shall support both direct delivery and encapsulated delivery styles as specified in 1
[RFC 3024]. 2
3
If Reverse Tunneling with encapsulating delivery style is negotiated with the MS, the PDSN 4
shall send all the packets as specified as [RFC 3024]. 5
6
4.2.2.7 DNS Address Assignment 7
8
If the PDSN supports the DNS Server IP Address VSA and NVSE and it receives a DNS 9
Server IP Address VSA in the RADIUS Access-Accept message from the RADIUS server 10
or/and a DNS Server IP Address NVSE in the MIP4 Registration Reply from the HA, then the 11
PDSN may include each received DNS Server IP Address in a DNS Server IP Address NVSE 12
in the MIP4 Registration Reply to the MS. The format of the DNS Server IP Address VSA is 13
defined in section 4 of [Chapter 5]. The format of the DNS Server IP Address NVSE is 14
defined in section 4.6. 15
16
If the PDSN receives a DNS Server IP Address from both the Visited RADIUS and Home 17
RADIUS servers (entity type 1 and 2), and the PDSN supports the VSA, the PDSN shall 18
determine if the M bit is set in the DNS Server IP Address VSA received in the RADIUS 19
Access-Accept message to select the DNS Server IP Address VSA it forwards to the MS. The 20
DNS Server IP Address VSA with the M bit set, shall have precedence over the VSA that 21
does not have the M bit set. If the PDSN receives a RADIUS Access-Accept message from 22
the Visited RADIUS server that has DNS IP address VSA(s) with the following values 23
included, then the PDSN shall apply local policies to select the DNS IP Address VSA for 24
DNS information. 25
26
 A DNS IP Address VSA with the Entity-Type subfield set to the value 1 (=HAAA) 27
and the M bit unset, and/or 28
29
 One or more DNS IP Address VSA(s) with the Entity-Type subfield set to the value 30
2 (=VAAA). 31
32
33
4.2.3 RADIUS Support 34
35
The PDSN shall act as a RADIUS client in accordance with [RFC 2865]. If the EAP, CHAP
36
or PAP has been performed during PPP establishment for the corresponding MS‟s NAI, the
37
PDSN should bypass the following authentication procedures to the Home RADIUS server by 38
not sending RADIUS Access-Request message to the Home RADIUS server. If the EAP, 39
CHAP or PAP has not been performed during PPP establishment for the corresponding MS‟s 40
NAI, the PDSN shall perform the following authentication procedures: 41
42
On initial mobile access, the PDSN shall communicate user FAC authentication information
43
to the Home RADIUS server, via the broker RADIUS servers if required, in a RADIUS
44
Access-Request message. On receipt of the RRQ from the MS, and if SPI in the MN-AAA 45
Authentication Extension is set to CHAP-SPI, the PDSN shall create a RADIUS Access- 46
Request message in accordance with Table 4. 47
48
 See section 4.3.2 for how to construct CHAP-Password and CHAP-Challenge fields 49
in the RADIUS Access-Request message. 50

51
 If the SPI in the MN-AAA Authentication Extension is set to CHAP SPI as per [RFC 52
3012], the PDSN shall use MD5 when computing the CHAP challenge. If the 53
authentication succeeds, the Home RADIUS server shall send a RADIUS Access- 54
Accept message to the PDSN. If the authentication fails, the Home RADIUS server 55
shall send a RADIUS Access-Reject message to the PDSN. 56

57
58
59
60
4 MIP4 Operation 26
1
2
3  The inclusion of the NAS-IP-Address or the NAS-IPv6-Address, or both in the
4 RADIUS Access-Request message, depends on whether the PDSN has an IPv4
5
address or IPv6 address, or both.
6
7 The PDSN shall act as a RADIUS accounting client in accordance with [RFC 2866] and shall
8 communicate user accounting information to the Visited RADIUS server in RADIUS
9 Accounting-Request messages. The PDSN shall determine at completion of the IPCP phase
10 that a RADIUS Accounting-Request (Start) record shall be sent to the RADIUS server
11 following a successful MIP4 Registration Reply received from the HA. The Accounting-
12
Request (Start) record shall contain the Account Session ID and Correlation ID attribute
13
generated by the PDSN.
14
15 The security of communications between the PDSN and the RADIUS server may be provided
16 using IP security. The establishment of security is outside the scope of this document.
17
18
19 4.2.4 IP Security Support
20
21 There may be a statically configured shared key for computing the MIP4 HA-FA
22 Authentication Extension in MIP4 registration messages. If such a shared key exists, the
23 PDSN and the HA shall use it. Additional Security Associations (SAs) between the PDSN
24 and HA may also be supported for the protection of MIP4 control messages and user data.
25 This document supports the following options for the establishment of such additional SAs:
26
27  Public certificates14.
28
 Dynamic IKE pre-shared secret distributed by the Home RADIUS server.
29
30
Statically configured IKE pre-shared secret.
31
32 The PDSN shall support IPsec and IKE [RFC 2409]. An SA between the PDSN and the HA
33 may be established using X.509 based certificates, or a pre-shared secret for IKE that may be
34 statically configured or dynamically provisioned by the Home RADIUS server. Although ESP
35 is preferred (and shall be implemented), AH shall also be implemented in order to maintain
36 backward compatibility with previous versions of this document.
37
38 In the case of an operator owned HA, and if mandated by operator policy, the PDSN shall
39 have an SA with the HA in order for a RRQ to be successfully processed. The SA may
40 formally be via IPsec (i.e., ESP or AH) or MIP4 HA-FA Authentication Extension.
41
42 An SA between the PDSN and the HA shall be established as follows:
43
44
When receiving a MIP4 RRQ containing a unicast HA Address, the PDSN shall verify if an
45
SA currently exists with the HA. If an SA does not exist, the PDSN shall verify if HA X.509
46 certificates exists. If no HA X.509 certificate exists, the PDSN shall verify if a root certificate
47 exists. If the necessary certificates do not exist, the PDSN shall verify if a statically
48 configured pre-shared secret for IKE exists. If the static pre-shared secret for IKE is also not
49 available, it shall include a request for a pre-shared secret for IKE in the RADIUS Access-
50 Request message. The Home RADIUS server shall include the pre-shared secret for IKE and
51 a KeyID in the RADIUS Access-Accept message if IPsec services are authorized for the user.
52
53 When the MS uses dynamic HA assignment (scenarios 1 and 2 from Section 4.1.3), the PDSN
54 shall always request the IKE pre-shared Secret from the Home RADIUS server. IPsec support
55 for dynamic HA assignment is further described in Section 4.2.4.3.
56
57
58
59
60
14
Refer to Annex A and B for details.
27 4 MIP4 Operation
4.2.4.1 IPsec Service Authorized 1

2
The PDSN shall provide IPsec services as indicated by the Security Level attribute included 3
in the RADIUS Access-Accept message. The Security Level attribute included in the 4
RADIUS Access-Accept message allows the Home RADIUS server to indicate whether IP 5
security should be applied to MIP4 registration messages and MIP4 tunneled data between the 6
HA and the PDSN, or not to use IPsec at all. The same security level shall be applied by the 7
PDSN for all users using the same Home Agent. If the PDSN receives the deprecated value of 8
'1' or '2', the PDSN shall use a default value of '3'. 9

10
If the home network authorizes IPsec services, the PDSN shall not forward an RRQ to the HA 11
unless an IPsec SA is established. The PDSN shall send a failed RRP with an error code of 65 12
(Administratively Prohibited) to the MS if IPsec service is authorized by the Home RADIUS 13
server but it is unable to establish an IPsec SA to the HA. The Home RADIUS server 14
authorizes the PDSN to either use an existing SA with the corresponding HA or to establish a 15
new SA if no prior SA exists. 16
17
If an IPsec SA does not exist and IPsec is authorized, the PDSN shall establish an SA using 18
IKE with either X.509 or root certificates, or statically configured pre-shared secret for IKE, 19
or dynamically distributed pre-shared secret for IKE. The PDSN shall comply with the 20
specifications in IKE [RFC 2409] and the Annexes A and B in this document. 21
22
If reverse tunneling is required and IPsec security is authorized, then the PDSN shall provide 23
security on the reverse tunnel. 24
25
If the PDSN does not receive the Security Level attribute from the Home RADIUS server, 26
and an IPsec SA to the HA already exists, the PDSN shall continue to use the same SA. If it 27
receives a new pre-shared secret for IKE and an SA already exists, the PDSN shall not 28
renegotiate the ISAKMP SA and shall discard any pre-shared secret received in the RADIUS 29
Access-Accept message. If no SA exists, then the PDSN shall follow local security policy. 30
31
If an IPsec SA already exists with the HA, the PDSN shall ensure the IPsec SA is maintained
32
by periodically refreshing the SA for as long as valid MIP4 bindings exist with that HA. 33
34
4.2.4.2 IPsec Service Not Authorized 35
36
If the Home RADIUS server does not authorize security for the MS, the PDSN shall not 37
delete existing IPsec SA with an HA. This is because IPsec should be authorized per PDSN- 38
HA pair and thus other MSs may be using the same IPsec SA. 39
40
4.2.4.3 Dynamic HA Assignment 41
42
When the PDSN receives a MIP4 RRQ containing an HA Address of 255.255.255.255 (or 43
0.0.0.0), it shall always include the IKE Pre-shared Secret Request attribute in the RADIUS 44
Access-Request message sent to the Home RADIUS server. The Home RADIUS server 45
responds with a RADIUS Access-Accept message containing the allocated HA Address and if 46
IPsec services are authorized for the user, the corresponding dynamic pre-shared secret and 47
KeyID for IKE are also included. The PDSN shall verify if IPsec services are authorized by 48
the presence of the Security Level attribute. When IPsec service is authorized for the user, the 49
50
PDSN shall then determine from the received HA Address whether an IPsec SA already exists.
51
If an SA already exists with the HA, the PDSN shall use the existing SA as is and shall
52
discard any pre-shared secret received in the RADIUS Access-Accept message.
53
If an SA does not exist, the PDSN shall determine if certificates or static pre-shared secret for 54
IKE exist for the HA, otherwise the pre-shared secret for IKE, if provided by the Home 55
RADIUS server, shall be used to establish the required SA. 56

57
58
59
60
4 MIP4 Operation 28
1
2
3
4.2.5 Ingress Address Filtering
4
5
Upon receiving a packet from the MS, the PDSN shall discard the packet if one of the
6
following conditions holds:
7
8  the packet is received while the PPP negotiation is in progress (state is not open),
9
10  the packet is received while MIP4 registration is pending 15 , but the source IP
11 address of the packet is invalid1 16 , and the packet is not a MIP4 control packet
12 (MIP4 RRQ or Agent Solicitation).
13
14 For a MIP4 session establishment over a Simple IP session, at the Simple IP establishment,
15
16
If the MS sends an Agent Solicitation to the PDSN, the PDSN shall respond with an
17
Agent Advertisement and shall discard all IP packets with an invalid source IP
18
address while MIP4 registration is pending17.
19
If the MS doesn‟t send Agent Solicitations but sends IP packets with an invalid Source
20
IP address, if the packet is not a DHCP packet, the PDSN may discard the packets
21
and may send an Agent Advertisement to the MS. If the PDSN sends Agent
22
23
Advertisements to the MS as a result of an Invalid Source IP address, it shall discard
24
all IP packets with an invalid source IP address while MIP4 registration is pending17.
25
If the PDSN receives an implementation-defined number of consecutive packets with an
26
invalid source IP address from the MS, and the packets are not DHCP packets, the PDSN
27
shall send an LCP Configure-Request message to the MS.
28
29 If the PDSN receives a DHCP packet over port 67, the PDSN shall forward the message to the
30
configured DHCP server(s) IP address(es) as described in section 3.2.1.5.
31
32
33 4.2.6 PDSN Requirements for GRE Tunneling Support
34
35 The PDSN shall support IP-in-IP tunneling of datagrams. The PDSN may support GRE
36 tunneling. This can be used to allow for overlapping private home IP addresses. Note that
37 this does not preclude implementation-specific solutions for the support of overlaid private
38 home networks. If the PDSN is capable of supporting GRE encapsulation, it should set the
39 „G‟ bit in the Flags field in the Agent Advertisement message sent to the MS during MIP4
40 session establishment.
41
42 If the MS does not set the „G‟ bit in the RRQ, the PDSN may fall back to using IP-in-IP
43 encapsulation for the session per [RFC 2002].
44
45 If the MS does not set the „G‟ bit in the RRQ, and the local policy allows the PDSN to
46 override the „G‟ bit setting received from the MS, the PDSN shall include a new MIP4
47 extension GRE-Key CVSE in the MIP4 RRQ message to request GRE encapsulation for the
48 session. Note that this behavior is not currently supported in [RFC 2002].
49
50
If the PDSN does not support GRE encapsulation, the PDSN shall reset the „G‟ bit in the
51
Agent Advertisement message. In this case, if the MS sets the „G‟ bit in the MIP4 RRQ
52
message, the PDSN returns a MIP4 RRP message to the MS with code 'Requested
53 Encapsulation Unavailable‟ (0x48) per [RFC 2002].
54
55
56
57
58 15
i.e., between the NCP open state and completion of MIP registration.
59 16
The source IP address from the MS is considered as invalid if it is not one of the addresses that have
60 been assigned to the MS or if the MS has not been assigned any IP addresses.
17
i.e., between the NCP open state and completion of MIP registration.
29 4 MIP4 Operation
If PDSN allows GRE encapsulation, and either the MS requested GRE encapsulation or local 1
policy dictates using GRE encapsulation for the session, the PDSN shall assign a GRE key 2
and shall insert the GRE Key CVSE defined in section 4.1.4 in all MIP4 RRQs (including 3
initial, renewal and de-registration requests) that it forwards to the HA. 4
5
The GRE Key CVSE shall follow the CVSE format defined in [RFC 3115]. This extension 6
shall be added after the MN-HA and MN-FA Challenge and MN-AAA extensions (if any) 7
and before the FA-HA Auth extension (if any). 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
51
52
53
54
55
56
57
58
59
60
4 MIP4 Operation 30
1
2
3
4
4.3 Home Agent Requirements
5
The HA shall support MIP4 [RFC 2002-2006], reverse tunneling [RFC 3024], FAC [RFC
6
7
3012], and MIP4 NAI Extension [RFC 2794]. In order to provide public network access and
8
private network access across the public network, the HA shall use a globally routable and
9
visible IP address.
10
11
4.3.1 Multiple Registrations
12
13
The HA shall support Multiple registrations with the same NAI but different static Home
14
Addresses.
15
16
17 4.3.2 MIP4 Authentication Support
18
19 When the HA receives an RRQ from a PDSN, it authenticates the RRQ using the MN-HA
20 shared key. At initial registration, if the HA does not have the MN-HA shared key, it shall
21 retrieve the MN-HA shared key from the Home RADIUS server. Based on the policy of the
22 home network, the HA may also process the MN-AAA Authentication Extension as specified
23 in [RFC 3012], if included in the RRQ.
24
25 If the home network policy dictates that the HA shall process the MN-AAA Authentication
26 Extension, then the HA shall authenticate the request by including the following attributes in a
27 RADIUS Access-Request message to the Home RADIUS server:
28
29  User-Name (1) = MN-NAI field in the MN-NAI Extension
30
31
 CHAP-Password (3) =
32
— CHAP Ident field = High-order byte of the Challenge Field in the MN-FA
33
Challenge Extension
34
35 — String field = Authenticator field from the MN-AAA Authentication Extension
36
37  CHAP-Challenge (60) = MD5 (Preceding MIP4 RRQ, Type, Subtype, Length, SPI),
38 followed by the least-order 237 bytes of the Challenge Field in the MN-FA
39 Challenge Extension. The MD5 checksum is computed over the MIP4 RRQ data
40 preceding the MN-AAA Authentication Extension and the Type, Subtype, Length,
41 SPI fields of the MN-AAA Authentication Extension.
42
43  MN-HA SPI = the value in the SPI field of the MN-HA AE received in the RRQ to
44 request the MN-HA shared key if not available at the HA. The MN-HA shared key
45 corresponds to a single user‟s NAI, or NAI and non-zero static IP address pair.
46
47 If the MN-AAA Authentication Extension is not present in the RRQ or HA policy dictates
48 that the HA shall not process the MN-AAA Authentication Extension (, and the HA requires
49 the MN-HA shared key from the RADIUS server), the HA shall send a RADIUS Access-
50 Request18 message that includes a User Name, a User-Password and an MN-HA SPI.
51
52
If the MN-HA shared key is requested, the Home RADIUS server shall encrypt the MN-HA
53
shared key in a RADIUS Access-Accept message using a method based on the RSA Message
54 Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of [RFC 2868].
55
The HA shall save the MN-HA shared key received from the Home RADIUS server for the
56
57
duration of the MIP4 session with the MS. Based on the local policy, the HA may store the
58
MN-HA shared key a certain time skew after releasing the mobility binding for the MS.
59
60
18
Construction of the message is implementation dependent.
31 4 MIP4 Operation
The HA shall compute the MN-HA Authentication Extension, according to [RFC 2002], 1
based on the MN-HA shared key. Computation of the extension shall include the Type and 2
the SPI field of the MN-HA Authentication Extension itself. 3
4
5
4.3.3 IPsec Support 6
7
The HA shall determine which type of security associations (if any) are required with a PDSN.
8
The HA and the PDSN shall use the same security policy as specified in the Home RADIUS 9
server. The policy may be locally configured at the HA or may be obtained from the Home 10
RADIUS server in the Security Level attribute. 11
12
If IPsec is authorized and no SA is currently in place, the HA shall participate in IKE
13
negotiation with the PDSN. The negotiation will result in establishing an IPsec SA that will
14
be used for all traffic between the HA and the PDSN.
15
16
The HA shall perform a similar operation as the Home RADIUS server to generate the pre-
17
shared secret for IKE (i.e., K), see algorithm for K in Section 4.4.3.
18
When an IKE request is received, the HA shall validate the timestamp in the KeyID field. 19
This timestamp eliminates the possibility of re-using a previously generated shared-key for 20
IKE „K‟ value while the secret key „S‟ is still valid on the HA. The HA shall also use the 'S' 21
Key indexed by Home RADIUS server IP address from the KeyID field. 22
23
If there is no previously assigned 'S' Key, the S Key is not found, or the timestamp in the 24
KeyID is greater than the „S‟ expiration time, then the HA shall send a RADIUS Access- 25
Request message to the Home RADIUS server to request the S Key. 26

27
That RADIUS Access-Request message shall contain: 28
29
 The User-Name attribute consisting of a concatenation of the PDSN‟s CoA and HA 30
Address. 31
32
 The „S‟ Request attribute.
33
The User-Name attribute should be formatted using ASCII hexadecimal notation. Both 34
35
addresses are converted to hexadecimal and the ASCII codes of the hexadecimal characters
36
and are concatenated with the HA Address following the CoA. For example, CoA of
37
10.10.10.11 is concatenated with an HA Address of 92.64.10.1 to yield
“0A0A0A0B5C400A01”. 38
39
The RADIUS Access-Accept message from the Home RADIUS server shall include the 'S' 40
Key and its lifetime, and may include the Security Level attribute. The HA shall save the 'S' 41
42
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). 43
44
Each HA shall have a configurable, allowable time skew to be used to validate the freshness 45
of „K‟. The HA shall maintain expired „S‟ keys for a configurable amount of time. This 46
expired key shall be used when KeyIDs are received that refer to the expired 'S' Key but falls 47
within the allowable time skew19. 48

49
The security method used between the HA and the Home RADIUS server is outside the scope 50
of this document. 51
52
53
54
55
56
57
19
The skew serves to solve the case where RADIUS or IKE messages are lost and must be transmitted 58
yet the 'S' Key expires in the meantime. An example of the skew could be one minute. 59
60
4 MIP4 Operation 32
1
2
3 However, the Home RADIUS server may encrypt the 'S' Key and the 'S' Lifetime using a
4 method based on the RSA Message Digest Algorithm MD5 [RFC 1321] as described in
5
Section 3.5 of [RFC 2868].
6
7 If mandated by an operator security policy, an operator‟s HA shall have an SA with the PDSN
8 in order for a registration request to be successfully processed. The SA may formally be via
9 IPsec (e.g., ESP or AH) or via a MIP4 HA-FA Authentication Extension. Likewise, an HA
10 shall accept or reject an RRQ received directly from an MS with a 'D' bit set depending on
11 security policy.
12
13
14 4.3.4 Dynamic Home Agent Assignment
15
16 During dynamic HA assignment, the HA Address that is specified by the MS in the RRQ
17 message and the IP address of the dynamically assigned HA may not be the same. Upon
18 receipt of such an RRQ message in an IP packet with the destination IP address set to the HA
19 unicast IP address, the HA may accept the RRQ contrary to the specification in [RFC 2002] or
20 may reject it with an error code of 136 in accordance with [RFC 2002]. The HA shall follow
21 the procedures described in Section 4.3.2 to complete its authentication process for the RRQ
22 message. The HA shall put its IP address in the HA Address field of the RRP message to the
23 MS.
24
25
4.3.4.1 DHCPv4 Support
26
27
The HA shall support a DHCP Relay Agent capability [RFC 3046]. The HA shall relay the
28
DHCP message of type DHCPInform received from the MS on port 67 to the DHCP server(s)
29
IP address(es) configured in the HA as specified in [RFC 3046]. The relay destination may be
30
an IP unicast, multicast, broadcast, or some combination.
31
32 The HA shall relay the DHCP messages received from the DHCP server(s) to the MS using
33
the address specified in the ciaddr field (HoA).
34
35
36 4.3.5 DNS Address Assignment
37
38 The DNS server IP addresses may be configured at the HA, or received from the Home
39 RADIUS server in a RADIUS Access-Accept message. If the HA does not receive the DNS
40 Server IP Address VSA from the Home RADIUS server, then the HA may include
41 configured 20 DNS server IP addresses in the DNS Server IP Address NVSE. If the HA
42 includes the configured20. DNS server IP addresses in the DNS Server IP Address NVSE, it
43 shall set the Entity-Type field to 3 (see section 4.6), and send the NVSE in a MIP4
44 Registration Reply message. If the HA receives the DNS Server IP Address VSA from the
45 Home RADIUS server, the HA may include the received DNS server IP addresses in the DNS
46
Server IP Address NVSE. If the HA includes the received DNS server IP addresses in the
47
DNS Server IP Address NVSE it shall set the Entity-Type field to 1 (see section 4.6) and send
48
the NVSE in a MIP4 Registration Reply message.
49
50
51 4.3.6 HA Requirements for GRE Tunneling Support
52
53 The HA shall follow the procedures specified in [RFC 3115] in processing this extension in
54 Registration Request messages. If the HA receives the GRE Key CVSE in a Registration
55 Request and does not recognize GRE Key CVSE, it shall reject the call by sending a MIP4
56 RRP with code „Unknown CVSE (0x8D)‟ per [RFC 3115].
57
58
59
60 20
The DNS information may be pre-configured in the HA or the HA may acquire the DNS information
via other schemes.
33 4 MIP4 Operation
If the HA receives the GRE Key CVSE in a Registration Request and recognizes the GRE 1
Key CVSE but is not configured to support GRE encapsulation, it shall reject the call by 2
sending a MIP4 RRP with code „Requested Encapsulation Unavailable (0x8B)‟. 3
4
If the HA receives a Registration Request with the 'G' bit set but without the GRE Key CVSE, 5
it shall reject the call by sending a MIP4 RRP with code „Poorly Formed Request (0x86)‟. 6
7
If the HA receives a Registration Request with a GRE Key CVSE but without the „G‟ bit set,
8
the HA should treat this as if „G‟ bit is set in the Registration Request, i.e., the presence of
9
GRE Key CVSE indicates a request for GRE encapsulation. In this case the HA shall not 10
send the 'G' bit in the RRP. 11
12
If the HA receives the GRE Key CVSE in a Registration Request and recognizes the GRE
13
Key CVSE as well as supports GRE encapsulation, it should accept the RRQ and send a MIP4
14
RRP with code „Accepted (0)‟. The HA shall assign a GRE key and include the GRE Key
15
CVSE in the MIP4 RRP sent to PDSN. The HA shall include the GRE Key CVSE in all RRPs
16
in response to any MIP4 RRQ that included GRE Key CVSE, when a GRE key is available 17
for the registration. 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
51
52
53
54
55
56
57
58
59
60
4 MIP4 Operation 34
1
2
3
4
4.4 RADIUS Server Requirements
5
See Section 3.3.
6
7
In order to provide the functions defined in this document, the Home and Visited RADIUS
8
servers shall support as required the attributes listed in Table 4 and [Chapter 5], in addition to
9
the standard RADIUS attributes. The Broker RADIUS server shall support the decryption and
10
re-encryption of the Pre-shared Secret attribute and the MN-HA Shared Key attribute.
11
12 Table 4 Occurrence of RADIUS Attributes for MIP4
13
14 Attribute Name Type Access- Access- Interface(s)
15 Request Accept
16
User-Name 1 M M PDSN -> AAA
17
HA -> AAA
18
19 User-Password 2 O Note 1 HA -> AAA
20 CHAP-Password 3 M Note 2 PDSN -> AAA
21 HA -> AAA
22
CHAP-Challenge 60 M Note 2 PDSN -> AAA
23
HA -> AAA
24
25 NAS-IP-Address 4 O Note 3 PDSN -> AAA
26 NAS-IPv6-Address 95 O Note 4 PDSN -> AAA
27
Foreign Agent Address 26/79 O PDSN -> AAA
28
29 Correlation ID 26/44 M O PDSN <-> AAA
30
Calling-Station ID 31 O PDSN -> AAA
31
32 Home Agent 26/7 M M PDSN <-> AAA
33 Framed-IP-Address 8 M O PDSN <-> AAA
34
IKE Pre-shared Secret Request 26/1 O PDSN -> AAA
35
36 Security Level 26/2 O AAA -> PDSN,
37 AAA -> HA
38 Pre-shared Secret 26/3 O AAA -> PDSN
39
Reverse Tunnel Specification 26/4 O AAA -> PDSN
40
41 KeyID 26/8 O AAA -> PDSN
42
‘S’ Key 26/54 O AAA -> HA
43
44
‘S’ Lifetime 26/56 O AAA -> HA
45 ‘S’ Request 26/55 O HA -> AAA
46
MN-HA Shared Key 26/58 O AAA -> HA
47
48 MN-HA SPI 26/57 O HA -> AAA
49 Allowed Differentiated Services 26/73 O AAA -> PDSN
50 Marking
51
DNS Update Required 26/75 O AAA -> HA
52
53 Always On 26/78 O AAA -> PDSN
54 Service Option Profile 26/74 O AAA -> PDSN
55
56
Remote IPv4 Address 26/59 O AAA -> PDSN
57 Remote IPv6 Address 26/70 O AAA -> PDSN
58
Remote Address Table Index 26/71 O AAA -> PDSN
59
60 MN-AAA Removal Indication 26/81 O AAA -> PDSN
35 4 MIP4 Operation
Attribute Name Type Access- Access- Interface(s) 1

Request Accept 2
3
NAS-Port-Type 61 O Note 5 PDSN -> AAA
4
Carrier-ID 26/142 M PDSN -> AAA 5
Allowed Persistent TFTs 26/89 O AAA -> PDSN 6

7
Maximum Authorized Aggregate 26/130 O AAA -> PDSN 8
Bandwidth for Best-Effort Traffic
9
Authorized Flow Profile IDs for the 26/131 O AAA -> PDSN 10
User 11
Maximum Per Flow Priority for the 26/133 O AAA -> PDSN 12
User 13
14
Inter-User Priority 26/139 O AAA -> PDSN
15
IP-Services-Authorized 26/185 O PDSN <- AAA 16
17
Accounting-Mode 26/198 O AAA -> PDSN
18
19
20
(M) Indicates Mandatory attribute
21
(O) Indicates optional attribute 22

23
Note 1: The password is configured between the HA and the RADIUS server. 24
25
Note 2: For MIP4, this attribute is mandatory for the PDSN, and optional for the HA. 26
27
Note 3:This is the IPv4 Address of the RADIUS server interface of the PDSN; at least one of
28
NAS-IP-Address or NAS-IPv6-Address shall be included.
29
Note 4: This attribute is included if the PDSN supports IPv6 addressing. 30

31
Note 5: The values are as follows: 22 (IS-2000) [5-9] or 24 (HRPD) [15], depending on the 32
service option number connected to the PDSN. 33
34
35
4.4.1 Dynamic Home Agent Assignment 36
37
The Home RADIUS server shall implement an HA selection algorithm to perform dynamic 38
HA assignment. The implementation details of this algorithm are outside the scope of this 39
document. The HA selection algorithm shall satisfy the four scenarios described in Section 40
4.1.3. The Home RADIUS server shall return the assigned HA Address in the HA attribute in 41
the RADIUS Access-Accept message to the PDSN during PPP CHAP/PAP authentication or 42
during mobile initial access if the MS is authorized to use MIP4 service. 43
44
45
4.4.2 MN-HA Shared Key Distribution 46
47
Upon receipt of a RADIUS Access-Request message from an HA containing the MN-HA SPI
48
attribute, the RADIUS server shall send a RADIUS Access-Accept message containing the 49
MN-HA shared key encrypted using a method based on RSA MD5 [RFC 1321] as described 50
in Section 3.5 of [RFC 2868]. 51
52
4.4.3 IKE Pre-shared Secret Distribution Procedure 53

54
55
When the RADIUS Access-Request message is received from the PDSN containing the IKE
56
Pre-shared Secret Request attribute, and IPsec services are authorized for the user, the Home
57
RADIUS server shall distribute a key identifier and pre-shared secret for IKE to the PDSN
58
using the Pre-shared Secret and KeyID attributes in the RADIUS Access-Accept message.
59
60
4 MIP4 Operation 36
1
2
3 The Home RADIUS server generates a pre-shared secret for IKE by processing the Home
4 RADIUS IP address, FA IP address, and a timestamp as well as a secret key, known as the 'S'
5
Key, through the HMAC-MD5 hashing algorithm. The 'S' Key is known between the Home
6
RADIUS server and the HA. The 'S' Key is retrieved by the HA from the Home RADIUS
7
server and has a configurable lifetime. The lifetime of the 'S' Key is a Home RADIUS local
8
policy, and is based on the cryptographic strength of the „S‟ Key. The pre-shared secret is
9
generated using the following formula:
10
11
12 K = HMAC-MD5 (Home RADIUS IP address | FA IP address | timestamp, „S‟)
13
14
The Home RADIUS server hides pre-shared secrets for IKE using a method based on the
15
RSA Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of [RFC 2868].
16
17
18 4.4.4 DNS Address Assignment
19
20 The RADIUS server may include the DNS Server IP Address VSA in the RADIUS Access-
21 Accept message in response to a RADIUS Access-Request message from the PDSN and/or
22 the HA. If the RADIUS server includes the DNS Server IP Address VSA, it shall include a
23
Primary and a Secondary DNS server IP addresses. The status of the „M‟ bit in the DNS
24
Server IP Address VSA is controlled by the Home RADIUS server.
25
26
27
28
4.5 MS Requirements
29
The MS may support MIP4 service. The MS shall access cdma2000 packet data service using
30
31
the cdma2000 air interface [5-9] and [15].
32
34
35 The MS shall use PPP as the data link protocol for MIP4. The MS may support multiple MIP4
36 Home Addresses over a single PPP session.
37
38
39 4.5.1.1 Establishment
40
41 Same as Section 3.4.1.1.
42
43
4.5.1.2 Termination
44
45 Same as Section 3.4.1.2.
46
47
48 If the MS tries to register and receives an RRP message with a failure code, it shall do one of
49 the following:
50
51
 Retry MIP4 registration over the existing PPP session.
52
53  If existing Simple IP or MIP4 sessions exist, give up on the failed MIP4 registration
54 and continue using the existing sessions.
55
56  Fall back to Simple IP by re-negotiating the PPP session.
57
58
 Terminate the PPP session.
59
60
37 4 MIP4 Operation
4.5.1.3 Authentication 1
2
The MS should not use EAP, CHAP or PAP if the MS only supports MIP4. In this case when 3
the MS receives an LCP Configure-Request message requesting EAP or CHAP authentication, 4
the MS should reply with an LCP Configure-Reject message requesting no PPP authentication. 5
If the MS receives an LCP Configure-Request message without the authentication option it 6
shall respond with an LCP Configure-Ack message as described in [RFC 1661]. 7
8
The MS shall perform EAP, CHAP or PAP as specified in section 3.4 if the MS supports 9
simple IP (IPv4 and/or IPv6) and MIP4. 10
11
If EAP or CHAP is performed, performance degradation will occur as the result of an 12
unnecessary RADIUS server traversal, a FAC shall be performed regardless of whether or not 13
EAP or CHAP is performed. The MS shall use the challenge received in the Agent 14
Advertisement or RRP to compute the MN-AAA authenticator. 15
16
As a further clarification to [RFC 3012] section 8 (SPI For RADIUS servers):
17
If the challenge has fewer than 238 bytes, this algorithm includes the high-order byte in the 18
19
computation twice, but ensures that the challenge is used exactly as is. Additional padding is
20
never used to increase the length of the challenge; the input data is allowed to be shorter than
21
237 bytes long.
22
23
25
If the MS uses MIP4 only, the MS shall not use the IP Address Configuration Option [RFC 26
1332]. On subsequent PPP session establishments while the MS intends to maintain a Home 27
Address, the MS shall omit the option21. The MS shall not include the MIP4 Configuration 28
Option in the IPCP Configure-Request messages sent to the PDSN. 29
30
The MS may implement [RFC 1877] in order to auto-configure DNS server IP addresses. The
31
MS may negotiate Primary and Secondary DNS server IP addresses during the IPCP phase.
32
The MS may propose a DNS server address of zero to indicate an explicit request that the 33
PDSN provides the DNS server address information in a Configure-Nak. 34
35
The MS shall not use DHCP to request assignment of home IP addresses.
36
37
4.5.1.5 Compression 38
39
Same as Section 3.4.1.7.
40
41
4.5.1.6 PPP Framing 42
43
Same as Section 3.4.1.8. 44
45
4.5.2 MIP4 Registration 46

47
48
4.5.2.1 Agent Discovery 49
50
Immediately after a PPP session is established, the MS may send Agent Solicitations. In this 51
case, the MS should use the same procedure as described in Section 2.4 of [RFC 2002]. If the 52
53
54
55
21
If the MS that uses Mobile IP uses the IP Address Configuration Option [RFC 1332] to indicate the 56
Home Address, the PDSN will consider it as an MS using Simple IP service and send a NAK with an 57
alternative address to the MS. The MS will respond with an IP Configure Request with the alternative 58
address. 59
60
4 MIP4 Operation 38
1
2
3 MS does not have a Home Address, the MS shall use zero in the Source IP Address field of
4 the IP packet that contains the Agent Solicitation. The MS shall support [RFC 3012].
5
6
4.5.2.2 Registration Messages
7
8
Upon receiving Agent Advertisements from the PDSN, the MS shall send an RRQ message.
9
10 The MS may request a non-zero home IP address belonging to its home IP network in the
11 RRQ or indicate that the HA should dynamically assign it an IP address. If the MS requests a
12 dynamic HA assignment, the MS shall set the HA Address to either 255.255.255.255 or
13
0.0.0.0. However, the MS should use 255.255.255.255. If the MS requests a static or already
14
allocated HA Address, it should set the HA Address accordingly.
15
16
17 The Home and HA Address allocations are based on the scenarios described in Section 4.1.3.
18
19
Table 5 MS Registration Scenarios
20
21 Scenario 1 To request a dynamic Home Address and a dynamic HA assignment, the MS shall set
22 the Home Address field to 0.0.0.0 and the HA Address field to 255.255.255.255 or
23 0.0.0.0 in the RRQ message.
24
Scenario 2 To request a dynamic HA assignment only while requesting a previously assigned
25
Home Address, the MS shall set the Home Address field to the desired Home
26
Address, and the MS shall set the HA Address field to 255.255.255.255 or 0.0.0.0 in
27
the RRQ message. If the MS receives a failed RRP, the MS may retry a MIP4
28 registration under any of the scenarios.
29
30
Scenario 3 To request a dynamic Home Address allocation only while requesting a previously
31
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
32
receives a failed RRP, the MS may retry a MIP4 registration under any of the
33
scenarios.
34
35 Scenario 4 When the MS is not requesting dynamic allocation of either a Home Address or an HA
36 Address, the MS shall set the Home Address and HA Address fields with the desired
37 IP addresses in the RRQ message. If the MS receives a failed RRP, the MS may retry
38
a MIP4 registration under any of the scenarios.
39 While requesting a dynamic Home Address assignment, the MS shall use zero in the Source
40 IP Address field of the IP packet that contains the MIP4 RRQ. In this case the NAI is used to
41 identify the MS.
42
43 During MIP4 re-registrations, the MS shall use the same HA Address and the Home Address
44 that were assigned to it during the initial MIP4 registration.
45
46
Upon receipt of an RRP message with successful registration indication (code 0) during initial
47
registration, the MS shall accept the dynamically assigned HA Address contained in the RRP
48 message, even if it is different from the HA Address provided in the RRQ message.
49
If the MS had set up a Simple IP session and decides to run MIP4 simultaneously using the
50
51
FA function in the PDSN, it shall send an Agent Solicitation to the PDSN. Upon receiving an
52
Agent Advertisement, the MS shall register with the PDSN and shall not use collocated CoA.
53
The MS may also register directly with the HA using a collocated CoA obtained from Simple
54
IP IPCP negotiation.
55
If the MS desires reverse tunneling, the MS shall set the T-bit in the RRQ message.
56
57 The MS shall not set the 'V' bit in the RRQ message.
58
59
60
39 4 MIP4 Operation
4.5.2.3 MIP4 Extensions 1

2
The MS shall include the MN-NAI Extension [RFC 2794], MN-HA Authentication Extension 3
[RFC 2002], MN-FA Challenge Extension [RFC 3012], and MN-AAA Authentication 4
Extension [RFC 3012] in the RRQ message. Because advertisements are rarely sent to save 5
air resources, when the MS performs re-registration, the MS shall use the challenge value 6
contained in the last received RRP as described in [RFC 3012]. 7
8
The MS shall compute the MN-AAA Authentication Extension, according to [RFC 3012], 9
based on the shared secret the MS has with the Home RADIUS server. The MS shall compute 10
the MN-HA Authentication Extension, according to [RFC 2002], based on the shared secret 11
the MS has with the HA. Computation of the extension shall include the Type and SPI field of 12
the MN-HA Authentication Extension itself. The MS may use the same shared-secret or 13
different shared secrets in the computation of the MN-AAA Authentication Extension and 14
MN-HA Authentication Extension. This is coordinated between the MS and its home network. 15
16
The MS may use DHCP to request configuration parameters such as DNS addresses [RFC 17
2132], SIP server addresses [RFC 3361] and/or BCMCS controller addresses [RFC 4280], etc. 18
If the MIP4 MS wants to receive local configuration information, it shall negotiate 19
encapsulated delivery style with the PDSN [RFC 3024]. 20
21
4.5.2.4 Private Network Support 22

23
If the MS wants private network access through MIP4, the MS shall use reverse tunneling. 24
25
27
When the MS wishes to terminate a MIP4 session, the MS may send a MIP4 RRQ to the HA 28
29
with a Registration Lifetime of zero to gracefully close the MIP4 session before terminating
the packet data service with the RAN22. For the case of power-down registration [5-9], the MS 30
31
shall not send an LCP Terminate-Request message to the PDSN and shall not send a MIP4
32
RRQ with Registration Lifetime of zero to the HA after receiving from the PDSN a 3GPP2
33
vendor specific Version/Capability packet with C3=1 (see Section 8).
34
35
4.5.2.6 DNS address Assignment 36
37
If the MS receives at least one DNS Server IP Address NVSE (as defined in section 4.6) in 38
the MIP4 Registration Reply message, then the MS may use the DNS server IP address in the 39
NVSE instead of the DNS server IP address received during IPCP. If the MS receives 40
multiple DNS Server IP Address NVSEs, it may select an appropriate entity (i.e., 41
HAAA/VAAA or HA), for acquiring the DNS information, based on its internal policy. 42
43
If Reverse Tunneling is applied for the MIP4 session, and the MIP4 Registration Reply 44
includes at least one DNS Server IP Address NVSE with the entity-type field set to either 1 or 45
3 and the MS supports the DNS Server IP Address NVSE, then the MS shall use the DNS 46
server IP addresses provided in the MIP4 Registration Reply. If the entity type is 3, the DNS 47
information provided by the HA may have precedence over that provided by the HAAA or the 48
VAAA. 49
50
51
52
53
54
55
56
57
22
The MS should send the RRQ with a lifetime of zero to free resources such as public addresses in the 58
HA. 59
60
4 MIP4 Operation 40
1
2
3
4.5.3 MS Requirements for GRE Tunneling Support
4
5
If the MS is capable of supporting GRE encapsulation, it should set the „G‟ bit in the Flags
6
field in the MIP4 Registration Request message per [RFC 2002].
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
51
52
53
54
55
56
57
58
59
60
41 4 MIP4 Operation
4.6 DNS Server IP Address NVSE 1

2
The NVSE contains a Primary and a Secondary DNS IP address and may be included in the 3
MIP4 Registration Reply message from the HA and/or the PDSN. The format of the NVSE 4
shall be as follows: 5
6
1 2 3 7
8
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
9
Type Length Reserved 10
Vendor/Org-ID 11
12
Vendor-NVSE-Type Entity-Type Sub-Type(=1)
13
Length Primary DNS IPv4 address 14
……….. Sub-Type(=2) Length Secondary DNS IPv4 15

16
address
17
……………………….. Unused 18
Figure 6 NVSE for DNS Server IP Address 19
20
21
Type: 134
22
Length = 22 23
24
Vendor/Org-ID: 5535 25
26
Vendor-NVSE-Type: 17 27
28
Vendor-NVSE-Value: This field is formatted as follows:
29
Entity-Type: In the Registration Reply message this field identifies the network entity that has 30
31
provided the DNS information to the mobile station so that it is aware of the source of the
32
DNS information. Currently the following types are defined:
33
HAAA = 1 34
35
VAAA = 2 36
37
HA = 3 38
39
Sub-Type (=1): This field indicates that the associated value field contains the Primary DNS
40
server IP address.
41
Length: 6 42
43
Vendor-Value: IPv4 address of primary DNS server. 44
45
Sub-Type (=2): This field indicates that the associated value field contains the Secondary 46
DNS server IP address. 47
48
Length: 6 49
50
Vendor-Value: IPv4 address of secondary DNS server.
51
52
53
54
55
56
57
58
59
60
4 MIP4 Operation 42
1
2
3
4
5
5 MIP6 Operation
6
7
This section describes the requirements and procedures for MIP6 operation [RFC 3775] [RFC
8 4285], [RFC 4283] and [RFC 3963]. In this document, MIP6 refers to a service in which the
9 user is able to maintain a persistent IPv6 address even when handing off between RNs
10 connected to different PDSNs. MIP6 provides the user IPv6 routing service to a public IPv6
11 network and/or secure IPv6 routing service to private networks. In this document, MIP6
12 operates in two distinct modes of operation, Bi-directional tunnel mode and Route Optimized
13 mode.
14
15 The home link prefix assigned to the MS is unique.
16
In order for the MS to authenticate and authorize with the home network, the MS includes the
17
18
MN-NAI mobility option [RFC 4283] and the Mobility Message authentication option [RFC
19
4285]. This type of authentication and authorization allows the MS to perform Home
20
Registration without IPsec. The HA can authenticate and authorize the MS based on identity
21
credentials that are included in the BU such as the MN-HA mobility message authentication
22 option or the MN-AAA mobility message authentication options [RFC 4285].
23
For an initial home registration, the MS uses the MN-AAA mobility message authentication
24
25
option. The basic message flows for the authentication protocol based MIP6 Home
26
Registration is shown in Figure 7 .
27
28
29
Home
30 MS PDSN HA
RADIUS
31
32
33
34 MS establishes link layer and bootstraps [HL/HA/HoA] a
35
36
37
38
39 Use assigned HoA
b
40 or autoconfig HoA
41
42
BU (IPv6 header | Destination Option Header (HAO) | Mobility Header (MH
43 Type 5, MN-NAI Mobility option, Mesg ID option, MN-AAA auth option) c
44
Access-Request
45
d
46
47
48 Access-Accept
49
e
50
51
HA performs replay
check f
52
53
54 BA (IPv6 header | RH Type 2 | Mobility Header (MH Type 6, NAI option, Mesg
g
55 ID option, MN-HA auth option))
56
57
58
Figure 7 The Initial MIP6 Home Registration with MN-AAA
59
mobility message authentication option
60
43 5 MIP6 Operation
a. The MS performs Link Layer establishment. Optionally, the MS acquires bootstrap 1

information from the Home RADIUS server (via the PDSN). The MS uses stateless 2
DHCPv6 [RFC 3736] to obtain the bootstrap information. 3
4
b. If the MS is assigned a new HoA in step (a) the MS begins to use it. If no HoA was 5
assigned at step (a), the MS generates (auto-configures) an IPv6 global unicast address 6
based on the Home Link Prefix(HL) information received at step (a). 7
8
c. At this step the MS sends a Binding Update to the selected Home Agent. The MS sets the
9
Link-local Compatibility (L) bit to 1 if the MS wants the HA to defend (through proxy 10
DAD) its link-local address in addition to the global address created with the same 11
Interface-Identifier. The fields in this BU are set as per [RFC 4283] and [RFC 4285]. In 12
the BU, the MS includes the MN-AAA mobility message authentication option. If the 13
MS serves as a mobile router (see [RFC 3963]), the MS uses implicit mode as specified 14
in [RFC 3963] to send Binding Update with „R‟ flag set. 15
16
d. The HA extracts the NAI, authenticator etc. from the BU and sends a RADIUS Access 17
Request message to the Home RADIUS server. This step always occurs for the initial 18
registration regardless of whether the MS is using an auto-configured HoA. 19
20
e. The Home RADIUS server authenticates and authorizes the user and sends back a
21
RADIUS Access-Accept to the HA indicating successful authentication and authorization.
22
At this step the Home RADIUS server also sends MS‟s HL prefix to the HA and
23
distributes the Integrity Key (IK) to the HA for subsequent MN-HA processing. 24
25
f. At this step the HA performs replay protection procedure with the Mesg-ID mobility
26
option in the received BU (see RFC 4285).
27
g. If replay check is successful, the HA sends back a Binding Acknowledgment to the MS. 28
In this BA message the HA includes the MN-HA mobility message authentication option, 29
MN-NAI mobility option and the Mesg ID mobility option. The MN-HA authenticator is 30
31
calculated based on the Integrity Key (IK) that was derived in the Home RADIUS server
32
and sent to the HA at step (e). The HA treats Binding Update received from the MS as an
33
implicit mode as specified in [RFC 3963].
34
For the subsequent binding updates, the MS uses the MN-HA mobility message 35
authentication option in BU. This includes binding updates sent to refresh an existing binding 36
cache entry or to update an existing binding cache entry in the event of inter PDSN mobility. 37
38
The subsequent Binding Updates and the resulting Binding Acknowledgements include MN-
39
HA mobility message authentication option. The MN-HA authenticator is computed using the
40
Integrity Key (IK) that was generated during the initial Home Registration. The HA and the
41
MS cache the IK for the duration of the MIP6 session. The Call flow is shown in Figure 8 .
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
5 MIP6 Operation 44
1
2
3
4
5
MN HA
6
7
8
9
10
BU (IPv6 header | Destination Option Header (HAO) | Mobility Header (MH Type 5, optional
11
12
a
MN-NAI mobility option, Mesg-ID option, MN-HA auth option)
13
14
15
16
17
18
19
BA (IPv6 header | RH Type 2 | Mobility Header (MH Type 6, NAI option, Mesg-ID option, MN-HA
20
b
21
auth option))
22
23
24
25
26
Figure 8 MIPv6 Home Registration with MN-HA mobility message authentication option
27
28 a. The MS sends a BU to the HA. The BU includes the Mesg-ID mobility option and the
29 MN-HA mobility message authentication option. The BU includes the MN-NAI mobility
30 option. The MN-HA mobility message authentication option is computed with the IK. If
31
the MS serves as a mobile router (see [RFC 3963]), the MS uses implicit mode as
32
specified in [RFC 3963] to send BU with „R‟ flag set.
33
34 b. The HA authenticates the BU by verifying the authentication data of the MN-HA
35 mobility message authentication option data using the stored IK. The HA performs replay
36 check using the Mesg-ID mobility option. If both authentication and replay check
37 succeeds, the HA sends a BA back to the MS. The BA contains the MN MN-HA mobility
38
message authentication option and the Mesg-ID mobility option. The BA contains the
39
MN-NAI mobility option. The HA treats Binding Update received from the MS as an
40
implicit mode as specified in [RFC 3963].
41
42
43
44
5.1 Common Service Specification
45
46
The common requirements for the network elements (e.g., Home Agent, Home RADIUS
47
server, PDSN and MS) for MIP6 operation are described in this section.
48
49
5.1.1 PPP Session
50
51 From a packet data session setup perspective, the MIP6 access is equivalent to a Simple IPv6
52
access at the PDSN. The role of the PDSN is only a NAS. This is different than the case of
53
MIP4 access where the PDSN plays the role of the Foreign Agent. Currently for Simple IPv6
54
access, EAP/CHAP/PAP is used during PPP setup. Therefore the same authentication and
55
authorization procedure (EAP/CHAP/PAP) is used during the PPP setup for MSs using MIP6.
56
The MS and the PDSN should perform the procedures defined in [Chapter 2], section 3.1.
57
58 The PDSN caches the MIP6 bootstrap information that is received from the Home RADIUS
59
server in the RADIUS Access-Accept message during Simple IPv6 access authentication. The
60
45 5 MIP6 Operation
MS obtains this bootstrap information using stateless DHCPv6 Information-Request message 1

by including a Client Identifier option. 2
3
In the case of MIP6 bootstrapping with DHCPv6, the MS includes the Client Identifier option 4
(set to DUID-EN with access authentication NAI 23 ) as the Identifier to identify which 5
bootstrap information should be sent. 6
7
During PPP setup, the PDSN shall indicate the MIP6-HA-Local-Assignment-Capability to the
8
MS.
9
10
5.1.2 MIP6 11
12
The following standards shall be used for MIP6 operation with any limitations or extensions 13
described in this document: 14

15
16
 [RFC 3775], Mobility Support in IPv6, 17
18
 [RFC 3963], Network Mobility (NEMO) Basic Support Protocol,
19
 [RFC 4283], Mobile Node Identifier Option for Mobile IPv6, 20

21
 [RFC 4285], Authentication Protocol for Mobile IPv6, 22
23
 [Draft-ietf-mip6-bootstrapping-integrated], MIP6-bootstrapping for the Integrated 24
Scenario, 25
26
 [Draft-ietf-mip6-hiopt], DHCP options for Home Information Discovery in MIPv6. 27
28
5.1.3 Summary of PDSN and MS Behavior for Dynamic HA/HL Discovery 29

30
via MIP6 Bootstrapping 31
32
The following table defines the behavior of:
33
34
1. The PDSN in converting the RADIUS 3GPP2 MIP6 bootstrapping VSA's received 35
from the RADIUS Home server to Home Network parameter sub-options in 36
DHCPv6 Home Network Information option. 37
38
2. The MS upon receiving of the corresponding Home Network parameter sub-options 39
in DHCPv6 Home Network Information option. 40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
23 58
The NAI is 72 octets max. 59
60
5 MIP6 Operation 46
1
2
3 Table 6 MIP6 Bootstrapping Scenarios
4
5 RADIUS VSAs MIP6 bootstrapping Home Network MS behavior
6 received by the Parameter sub-options get generated by
7 PDSN PDSN and sent to the MS in a DHCPv6
8
Home Network Information option:
9 Attribute A: HL Assigned Home-Link prefix (Suboption-code HL prefix: Shall use the assigned
10 prefix (which 2) HL prefix.
11
includes prefix HoA:
12
length information If provisioned with a HoA and the
already): HoA is valid over the assigned
13
HL, the MS may use that HoA.
14
Otherwise, the MS shall auto-
15
configure the HoA.
16
HA:
17 The MS shall discover the HA
18 via Dynamic Home Agent
19 Address Discovery procedure as
20 defined in [RFC 3775].
21 Attribute A (HL Assigned Home-Link prefix (option-code HL prefix: Shall use the assigned
22 prefix) and Attribute 2) and Assigned Home Agent Address (Sub- HL prefix.
23 B (HA): option-code 3) HoA:
24 If provisioned with a HoA and the
25 HoA is valid over the assigned
26 HL, the MS may use that HoA.
27
Otherwise, the MS shall auto-
28
configure the HoA.
29
HA: Shall use the assigned HA.
Any other None (PDSN treats this as an error case and The MS may use provisioned
30
combination of does not send any DHCP MIP6 information and/or Dynamic
31
Attributes A, B bootstrapping option to the MS) Home Agent Address Discovery
32
procedure as defined in [RFC
33
3775] to configure HoA, HA and
34
HL prefix.
35
36
37 Note: The Dynamic Home Agent Address Discovery (DHAAD) procedure defined in [RFC
38 3775] requires the use of ICMPv6 messages.
39
40 If the MS is provisioned with HoA, HL prefix and HA addresses for a home network, then it
41 should be able to use these addresses.
42
43 If the MS bootstraps and receives an HL prefix and HA address information for a home
44 network as specified in Table 6, the MS shall use that information when registering with that
45 home network as specified in Table 6.
46
47
The Home Network information for the MS (HL/HA) can be assigned by the Home RADIUS
48
server, the Visited RADIUS server, or the PDSN, depending on the MS request indicated via
49
the id-type included in the DHCPv6 Information-Request message. The detailed node
50 requirements for Dynamic Home Agent Assignment are described in sections 5.2, 5.3 and 0 of
51 this document.
52
53
5.1.3.1 Dynamic Home Agent and Home Link Prefix Assignment via MIP6
54
55
Bootstrap (HA and HL is assigned by HAAA)
56
The Home RADIUS server allocates the Home Agent and the unique Home Link Prefix to an
57
MS during access authentication (PPP setup) using MIP6 Home Agent (Attribute B) VSA and
58
MIP6 Home Link Prefix (Attribute A) VSA. The MS obtains the assigned HA information
59
60
and Home Link Prefix information using stateless DHCPv6 procedures as described below.
47 5 MIP6 Operation
The following shows an example call flow for the dynamic HL and HA address assignment in 1
the Home network by the Home RADIUS server. 2
3
Visited Home 4
MS PDSN RADIUS RADIUS 5
Server Server 6
7
8
Begin Access-Auth a 9
Access-Request(MIP6-HA- 10
Local-assignment-Capability 11
b
12
13
14
Assign HA 15
and HL c
16
17
Access-Accept 18
(HA and HL, HA-Authorized) 19
d
20
21
22
store
e 23
HA and HL info
24
25
26
27
Complete Access-Auth f 28
29
30
31
Information-Request [O-R-O, Cid option] 32
g
33
34
Reply [HNINF with HA and HL sub-options] 35
h 36
37
38
Figure 9 Flow diagram for Dynamic Home Agent Assignment (HA and HL is assigned by 39
HAAA) 40
41
42
a. The MS begins the Access Authentication procedure (e.g., EAP/CHAP/PAP). 43
44
b. The PDSN sends Access-Request to the Home RADIUS server via the Visited RADIUS
45
server. If the PDSN supports local HA assignment and the visited network policy enables
46
this function, the PDSN includes the MIP6-HA-Local-Assignment-Capability VSA to
47
indicate its capability to assign a HA in the local network in the RADIUS Access-Request
48
message.
49
c. The Home RADIUS server verifies the user‟s profile and detects that the user is a MIP6 50
51
subscriber. The Home RADIUS server assigns an HA and a Home Link Prefix for the
52
MS.
53
If the MIP6-HA-Local-Assignment-Capability VSA is received, based on the user profile,
54
roaming agreement, and home network policy, the home RADIUS server decides whether to
55
authorize the visited network to assign a HA. 56
57
d. The Home RADIUS server includes a Home Agent address in the MIP6 Home Agent
58
(Attribute B) VSA. The Home RADIUS server also includes a Home Link Prefix in the
59
60
5 MIP6 Operation 48
1
2
3 MIP6 Home Link Prefix (Attribute A) VSA. The Home RADIUS server also includes the
4 HA-Authorized VSA to authorize the visited network to assign a HA if the MS requests an
5
HA in the visited network. The Home RADIUS server may also include the HAAA-MIP6-
6
HA-Protocol-Capability-Indication VSA to indicate the MIP6 signaling security protocol
7
supported by the HA.
8
9 e. The PDSN receives the HA and HL information VSAs from the Home RADIUS server
10 and stores them.
11
12 f. The Access Authentication procedure completes at this step.
13
14 g. The MS requests MIP6 bootstrap information using the DHCPv6 Information-request
15 message [RFC 3736] sent to the PDSN. In this message the MS includes it‟s access
16 authentication NAI in the Identifier field of the Client Identifier Option with DUID-EN
17 (enterprise number set as 5553). In this example, the MS requests a HA in the Home
18 network, so the MS includes the Home Network Information Option with the id-type set to 1.
19
20
h. The PDSN looks up the appropriate record based on the Client Identifier and replies back
21 to the MS [RFC 3736] with the options that were requested. The PDSN includes
22 configured HL Prefix information and HA address in the Home Network Information Option
23 in the DHCPv6 Reply Message. If the stored record also contains HA protocol capability
24 indication from Home RADIUS server, the PDSN also includes a DHCPv6 3GPP2 Vendor-
25 Specific option with Option-Code=1 in the DHCPv6 Reply containing the stored HA
26 protocol capability indication..
27
28 The detailed node requirements for Dynamic Home Agent Assignment are described in
29 sections 5.2, 5.3 and 5.5 of this document.
30
31 5.1.3.2 Dynamic Home Agent and Home Link Prefix Assignment via MIP6
32 Bootstrap (HA and HL is assigned by VAAA)
33
34 The Visited RADIUS server allocates the Home Agent and the unique Home Link Prefix to
35 an MS during access authentication (PPP setup) using VAAA-Assigned-MIP6-HA VSA and
36 VAAA-Assigned-MIP6-HLVSA. The MS obtains the assigned HA information and Home
37 Link Prefix information using stateless DHCPv6 procedures as described below. The
38
following shows an example call flow for the dynamic HL and HA address assignment in the
39
visited network by the Visited RADIUS server.
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
49 5 MIP6 Operation
Visited Home 1
Server Server 3
4
5
b
9
10
Assign HA 11
and HL c 12
13
Access-Accept
14
(HA and HL, HA-Authorized) d 15
16
17
Assign HA
and HL e 18
19
Access-Accept
20
(VAAA Assigned HA and HL, HA and HL,
f 21
HA-Authorized)
22
23
store 24
g
HA and HL info 25
26
27
h 28
Complete Access-Auth
29
30

i
32
33
Reply [HNINF with HA and HL sub-options]
j 34
35
36
37
Figure 10 Flow diagram for Dynamic Home Agent Assignment (VAAA assigns HA and HL)
38
39
a. The MS begins the Access Authentication procedure (e.g., EAP/CHAP/PAP). 40
41
b. The PDSN sends Access-Request to the Home RADIUS server via the Visited RADIUS
42
server. If the PDSN supports local HA assignment and the visited network policy enables 43
this function, the PDSN includes the MIP6-HA-Local-Assignment-Capability VSA to 44
indicate its capability to assign a HA in the local network in the RADIUS Access- 45
Request message. 46
47
c. The Home RADIUS server verifies the user‟s profile and detects that the user is a MIP6
48
subscriber. The Home RADIUS server assigns an HA and a Home Link Prefix for the
49
MS. If the MIP6-HA-Local-Assignment-Capability VSA is received, Based on the user 50
profile, roaming agreement, and home network policy, the home RADIUS server decides 51
whether to authorize the visited network to assign a HA. 52
53
d. The Home RADIUS server includes a Home Agent address in the MIP6 Home Agent
54
(Attribute B) VSA. The Home RADIUS server also includes a Home Link Prefix in the
55
MIP6 Home Link Prefix (Attribute A) VSA. The Home RADIUS server also includes the 56
HA-Authorized VSA to authorize the visited network to assign a HA if the MS requests 57
an HA in the visited network. The Home RADIUS server may also include the VAAA- 58
59
60
5 MIP6 Operation 50
1
2
3 MIP6-HA-Protocol-Capability-Indication VSA to indicate the MIP6 signaling security
4 protocol supported by the HA.
5
6 e. Since the Visited RADIUS server receives the HA-Authorized VSA to authorize the
7 visited network to assign a HA, the Visited RADIUS server assigns an HA and a Home
8 Link Prefix for the MS.
9
10 f. The Visited RADIUS server includes a Home Agent address in the VAAA-Assigned-
11 MIP6-HA VSA and a HL prefix in the VAAA-Assigned-MIP6-HL VSA.
12
13
g. The PDSN receives the HA and HL information VSAs from the Home RADIUS server
14 and Visited RADIUS server and stores them.
15
h. The Access Authentication procedure completes at this step.
16
17
i. The MS requests MIP6 bootstrap information using the DHCPv6 Information-request
18
message [RFC 3736] sent to the PDSN. In this message the MS includes it‟s access
19
authentication NAI in the Identifier field of the Client Identifier Option with DUID-EN
20
(enterprise number set as 5553). In this example, the MS requests a HA in the Visited
21
network, so the MS includes the Home Network Information Option with the id-type set
22
to 0.
23
24
j. The PDSN looks up the appropriate record based on the Client Identifier and replies back
25
to the MS [RFC 3736] with the options that were requested. The PDSN includes
26
configured HL Prefix information and HA address in the Home Network Information
27
Option in the DHCPv6 Reply Message. If the stored record also contains HA protocol
28
capability indication from Visited RADIUS server, the PDSN also includes a DHCPv6
29
3GPP2 Vendor-Specific option with Option-Code=1 with the DHCPv6 Reply containing
30
31
the stored HA protocol capability indication.
32
The detailed node requirements for Dynamic Home Agent Assignment are described in
33
sections 5.2, 5.3 and 0 of this document.
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
51 5 MIP6 Operation
5.1.3.3 Dynamic Home Link Prefix Discovery via MIP6 Bootstrap 1

2
The Home Link Prefix information is delivered to the PDSN during the PPP setup phase. The 3
Home RADIUS server selects the Home Link Prefix and includes it in a MIP6 Home Link 4
Prefix (Attribute A) VSA in the Access-Accept message. The Home Link Prefix information 5
is delivered to the MS when the MS sends a DHCPv6 Information-Request message. The 6
following shows an example call flow for the dynamic HL prefix in the Home network by the 7
Home RADIUS server. 8
9
Visited Home 10
Server Server 12
13
14
b
18
19
20
Assign HL 21
Prefix c 22
23
Access-Accept 24
(HL Prefix, HA-Authorized) 25
d 26
27
28
Store
e 29
HL info
30
31
32
33
Complete Access-Auth f 34
35
36
37
g 39
40
Reply [HNINF with HL sub-option] 41

h 42
43
44
Figure 11 Bootstrap of Home Link Prefix 45
46
47
a. The MS begins the Access Authentication procedure (e.g., EAP/CHAP/PAP).
48
b. The PDSN sends Access-Request to the Home RADIUS server via the Visited RADIUS 49
server. If the PDSN supports local HA assignment and the visited network policy enables 50
this function, the PDSN includes the MIP6-HA-Local-Assignment-Capability VSA to 51

52
indicate its capability to assign a HA in the local network in the RADIUS Access-Request
53
message.
54
c. The Home RADIUS server verifies the user‟s profile and detects that the user is a MIP6 55
subscriber. The Home RADIUS server assigns a Home Link Prefix for the MS. Based on 56
the user profile, roaming agreement, and home network policy, the home RADIUS server 57
decides whether to authorize the visited network to assign a HA. 58

59
60
5 MIP6 Operation 52
1
2
3 d. The Home RADIUS server includes a Home Link Prefix in the MIP6 Home Link Prefix
4 (Attribute A) VSA. The Home RADIUS server also includes the HA-Authorized VSA to
5
authorize the visited network to assign a HA if the MS requests an HA in the visited network.
6
The Home RADIUS server may also include the HA-Protocol-Capability-Indication VSA to
7
indicate the MIP6 signaling security protocol supported by the HA.
8
9 e. The PDSN receives the HL information VSA from the Home RADIUS server and stores
10 them.
11
12 f. The Access Authentication procedure completes at this step.
13
14 g. The MS requests MIP6 bootstrap information using the DHCPv6 Information-request
15 message [RFC 3736] sent to the PDSN. In this message the MS includes it‟s access
16 authentication NAI in the Identifier field of the Client Identifier Option with DUID-EN
17 (enterprise number set as 5553). In this example, the MS requests a HL in the Home
18 network, so the MS includes the Home Network Information Option with the id-type set to 1.
19
20
h. The PDSN looks up the appropriate record based on the Client Identifier and replies back
21 to the MS [RFC 3736] with the options that were requested. The PDSN includes
22 configured HL Prefix information in the Home Network Information Option in the DHCPv6
23 Reply Message. If the stored record also contains HA protocol capability indication from
24 Home RADIUS server, the PDSN also includes a DHCPv6 3GPP2 Vendor-Specific option
25 with Option-Code=1 with the DHCPv6 Reply containing the stored HA protocol capability
26 indication.
27
28 With the assigned Home Link Prefix, the MS performs dynamic Home Agent Address
29 discovery by using the procedure defined in [RFC 3775] section 5.3. The MS also auto-
30 configures a Home Address with the assigned Home Link Prefix.
31
32 5.1.3.4 Dynamic Home Address Configuration
33
34 In this document, the MS is allowed to perform stateless auto-configuration of its Home
35 Address based on the Home Link Prefix that was assigned to it by the Home RADIUS server.
36
37 The Binding Cache Entry (BCE) Lifetime is limited by the home-link prefix lifetime at the
38 HA. This is controlled by the HA via the lifetime field in the Binding Acknowledgement
39 message sent to the MS. The MS can request an extension to the HoA/BCE lifetime by
40 sending a Binding Update to the Home Agent.
41
42 Once the BCE expires, the MS shall not use the HoA/HL prefix from the expired session. The
43 MS shall initiate the bootstrapping procedure when starting a new MIP6 session if the MS
44 does not have the registration information (i.e., HL Prefix, HoA, HA) provisioned.
45
46
If the Binding Refresh Advice mobility option is present in the BA message [RFC 3775], the
47
Refresh Interval field in the option shall be set to a value less than the lifetime value being
48
returned in the Binding Acknowledgement. This indicates that the mobile node should attempt
49 to refresh its home registration at the indicated shorter interval. The HA shall still retain the
50 registration for the BCE lifetime period, even if the mobile node does not refresh its
51 registration within the refresh period. However, if the mobile node does not refresh the
52 binding by sending a new BU to the HA before the BCE lifetime expires, the HA shall delete
53 the BCE.
54
55
56
57
58
59
60
53 5 MIP6 Operation
5.1.3.4.1 Home Address Auto-configuration by the Mobile Station 1

2
3
Home
MS PDSN 4
RADIUS
5
6
7
PPP setup EAP/CHAP/PAP auth a 8
9
10
Information-Request [O-R-O], Cid option 11

b 12
13
14
Reply [HNINF option with HL/HA information]
c 15
16
17
18
MN 19
autoconfigures d 20
the HoA 21
22
23
24
25
26
Figure 12 Home Address Auto-Configuration
27
28
a. The MS performs PPP link establishment using EAP, CHAP or PAP. 29
30
b. The MS requests the MIP6 bootstrap information using the DHCPv6 Information-request 31
message [RFC 3736] sent to the PDSN In this message the MS includes it‟s access 32
authentication NAI in the Identifier field of the Client Identifier Option with DUID-EN 33
(enterprise number set as 5553). 34
35
c. The PDSN looks up the appropriate record based on the Client Identifier and replies back
36
to the MS [RFC 3736] with the MIP6 bootstrap Home Network Information option.
37
38
d. Upon receiving the MIP6 bootstrap information from the PDSN, the MS auto-configures
39
its HoA in a stateless manner as described in [RFC 2462], using the Home Link Prefix
40
information from the Assigned Home Link Prefix in Home Network Parameter sub-
41
option of the DHCPv6 Home Network Information option.
42
The detailed node requirements for dynamic Home Address via IPv6 stateless address auto- 43
configuration at the mobile station are described in sections 5.2, 5.3, 5.4 and 0 of this document. 44
45
46
5.1.4 Mobile Station to Home Agent Security for BU and BA 47
48
For the MS-to-HA security, the authentication protocol based IPv6 mobility as defined in [RFC 4285] 49
is supported. Consequently, securing BU and BA messages between the MS and the HA is done as 50
described by methods in [RFC 4285] using the MN-AAA shared secret or the derived shared secret 51
(Integrity Key (IK)). 52
53
IK is derived during the initial Home Registration at the Home RADIUS server and is used as an MN- 54
HA key for subsequent BU/BA messages exchanged between the MS and the HA. The IK derivation 55
and distribution mechanisms are explained in section 5.4.1. The Home RADIUS server generates the 56
IK, then it distributes it to the HA in an encrypted form. The MS generates the same key (IK) using 57
the same input, seed and the same algorithm used by the Home RADIUS server. The MN-NAI 58
59
60
5 MIP6 Operation 54
1
2
3 mobility option defined in [RFC 4283] is included along with the initial BU to enable the HA to
4 perform RADIUS procedures. The MN-NAI mobility option is required in all subsequent BUs.
5
6
5.1.4.1 Replay Protection of Binding Update and Binding Acknowledgement
7
8
Replay protection is provided using the Mesg ID option as specified in [RFC 4285]. Timestamp based
9
replay protection is used in this document for the both MN-AAA and MN-HA mobility message
10
authentication options.
11
12
13
14 5.2 PDSN Requirements
15
16
The PDSN shall support IPv6 operation. The PDSN acts as the NAS for Simple IPv6 access. The
17 PDSN shall support Simple IPv6 operational requirements as specified in section 3.2. In addition, the
18 PDSN shall support the MIP6 bootstrapping as specified in this section.
19
20
If the MS-PDSN Version Feature Indication (see section 8) is used, and the MS signaled that it does
21
not support MIP6 (C3 bit set to 0), then the PDSN shall not provide MIP6 bootstrapping information if
22
received from the Home RADIUS server.
23
If the MS-PDSN Version Feature Indication is used, and the MS signaled that it supports MIP6 (C3 bit
24
set to 1), then the PDSN shall provide the MIP6 bootstrapping information to the MS as described in
25
this section.
26
27
The PDSN shall indicate the MIP6-HA-Local-Assignment-Capability to the MS by MS-PDSN Version
28
Capability Indication.
29
30 The PDSN shall support DHCPv6 stateless server function per [RFC 3736]. The PDSN shall support
31 DHCPv6 proxy function to assist the MS in MIP6 bootstrapping. The DHCPv6 proxy function in the
32 PDSN shall support the options for HA assignment as defined in Draft-ietf-mip6-hiopt.
33
34 This information is delivered to the PDSN during the access authentication (PPP establishment) phase
35 from the Home RADIUS server.
36
37
38
5.2.1 PDSN Requirement to Support Stateless DHCPv6 to Convey MIP6
39 Bootstrap Info
40
41 The PDSN shall support the Stateless Dynamic Host Configuration Protocol service for IPv6 as
42 specified in [RFC 3736]. In order to send the MIPv6 bootstrap info, the PDSN shall act as a DHCPv6
43 Proxy. Upon receiving an Information-Request from the MS identified by the NAI in the Client
44 Identifier Option, if the NAI is the same as the access authentication NAI of the MS, the PDSN shall
45 send the MIPv6 bootstrap information to the MS in the DHCPv6 reply message.
46
47 The PDSN shall support the MIP6-HA-Local-Assignment-Capability RADIUS attribute defined in
48 section 5.4. During the access authentication procedure (CHAP or PAP), if the PDSN supports local
49 HA assignment and the visited network policy enables this function, the PDSN shall include the MIP6-
50 HA-Local-Assignment-Capability VSA in the RADIUS Access-Request. If the PDSN receives the
51 HA-Authorized VSA in the RADIUS Access-Accept message, the PDSN is authorized to assign a
52 HA/HL Prefix in the visited network for the MS. The PDSN may receive the VAAA-Assigned-MIP6-
53 HA VSA and VAAA-Assigned-MIP6-HL VSA in RADIUS Access-Accept message. If the HA-
54 Authorized VSA is absent in the RADIUS Access-Accept message, the PDSN is not authorized to
55 assign a HA and HL Prefix in the visited network for the MS.
56
57 If the MS requests a HA/HL Prefix in the visited network by setting the id-type of Home Network
58 Information Option to 0, then the PDSN shall perform the following:
59
60
55 5 MIP6 Operation
a. If the PDSN has received an assigned HA and HL Prefix from the VAAA via the VAAA- 1
Assigned-MIP6-HA VSA and VAAA-Assigned-MIP6-HL VSA, the PDSN shall return 2
the assigned HA address and HL to the MS. 3
4
b. If the PDSN has not received an assigned HA and HL from the VAAA, if the PDSN 5
supports local HA/HL Prefix assignment, and it is enabled by the visited network, and it 6
is authorized by the home network via the HA-Authorized VSA, the PDSN shall assign a 7
HA/HL Prefix in the visited network and return them to the MS. 8
9
c. If the MS requests for a HA/HL Prefix in the visited network, but the PDSN isn‟t 10
authorized by the home network, the PDSN shall return a Home Network Information 11
option with Option-Len set to 1. 12
13
If the MS requests a HA/HL Prefix in the home network by setting the id-type of Home Network
14
Information Option to 1 and with the Home Network Identifier field in the Home Network
15
Identifier sub-option set to the realm part of the NAI that was authenticated and authorized during
16
the access authentication procedure, then the PDSN shall assign a HA/HL Prefix that was 17
received from the home network during the access authentication procedure. Otherwise, the 18
PDSN shall not assign a HA/HL Prefix to the MS and it shall send a DHCPv6 reply with no HA 19
option. If the PDSN did not receive the HA/HL Prefix from the home network during the access 20
authentication procedure, the PDSN shall return a Home Network Information option with 0- 21
length data. 22
23
24
The PDSN shall include the HL prefix information in MIP6 bootstrap DHCPv6 Reply
25
message, such that MS can use it to autoconfigure the Home Address. If PDSN does not
26
receive HL prefix information during access authentication, then PDSN shall consider it as a
27
failure case and shall not include any MIP6 bootstrap information to the MS in the DHCPv6
28
Reply.
29
30
5.2.2 MIP6-HA-Protocol-Capability-Indication 31
32
During the Access-Authentication procedure if the PDSN receives 3GPP2 specific HAAA- 33
MIP6-HA-Protocol-Capability-Indication VSA, or VAAA-MIP6-HA-Protocol-Capability- 34
Indication VSA, or if the PDSN assigns HA/HL to the MS, the PDSN shall include the HA- 35
Protocol-Capability in a DHCPv6 Vendor Specific option with the Reply message for MIP6 36
37
bootstrap information if the MS requests bootstrap information in the home network. If the
38
MS requests bootstrap information. This Vendor-specific DHCPv6 option is formatted as
39
shown below:
40
41
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 42
43
OPTION-VENDOR-OPTS Length 44
45
Enterprise Number 46
47
Option Code 1 Option-Length 48

49
50
HA Proto Code
51
52
53
OPTION-VENDOR-OPTS: 17 54
55
Length: 12 56
57
Enterprise Number: 5535 58
59
60
5 MIP6 Operation 56
1
2
3 Option Code 1: HA-Protocol-Capability-Indication
4
5 Option-Length: 4
6
7 HA Proto Code: HA Protocol Code indicated in HAAA-MIP6-HA-Protocol-Capability-
8 Indication VSA or VAAA-MIP6-HA-Protocol-Capability-Indication VSA. If the local
9 HA/HL is assigned by the PDSN, the PDSN shall use the coding format as specified in
10 VAAA-MIP6-HA-Protocol-Capability-Indication VSA.
11
12
13
14
5.2.3 Ingress Address Filtering
15
16
Since the ingress filtering mechanism for MIP6 packets is same as the one for Simple IPv6,
17
the PDSN shall perform simple IPv6 Ingress address filtering procedures as specified in
18
section 3.2.3.
19
20
21
22
5.3 Home Agent Requirements
23
24
The HA shall support the following additional RFCs for MIP6 support:
25
 [RFC 3775], Mobility Support in IPv6 (to the exception of the security of the MS to
26
HA signaling),
27
28  [RFC 4283], Mobile Node Identifier Option for Mobile IPv6
29
30  [RFC 4285], Authentication Protocol for Mobile IPv6
31
32 The HA may support the following additional RFCs for MIP6 support:
33
34  [RFC 3963], Network Mobility (NEMO) Basic Support Protocol
35
36
37 5.3.1 Home Agent Requirements to Support Dynamic Home Agent
38 Assignment
39
40 The HA shall support Dynamic Home Agent Address Discovery as defined in [RFC 3775].
41
42 The HA shall process Binding Updates that contain Mobility message authentication options
43 (MN-HA or MN-AAA), Mesg-ID option and the MN-NAI mobility option. If the MN-NAI
44 mobility option is not included in the BU of an MS, the HA shall treat it as an error and shall
45 reject the BU.
46
47
48
49
5.3.2 Home Agent Requirements to Support Dynamic Home Address
50
51
Configuration
52
53
The Home Agent shall support Home Addresses/HL prefix that are either assigned by the
54
Home RADIUS server or auto-configured by the Mobile Station from assigned HL prefix as
55
long as the use of the Home Address/ HL prefix by the user (NAI) is authorized by the Home
56 RADIUS server.
57
Upon receiving a Binding Update containing Mobility Message authentication options (MN-
58
59
HA or MN-AAA), Mesg-ID option, MN-NAI mobility option and a Home Address Option
60
(HAO) with a unicast IPv6 address in the Home Address field, the HA shall process the
Binding Update. The lifetime in the Binding Acknowledgement is controlled by local
57 5 MIP6 Operation
configuration at the Home Agent or it is set to the valid-lifetime remaining for the home-link 1
prefix ([RFC 2461], section 4.6.2). 2
3
When the HA receives a BU from the MS (MN-NAI) for which there is an ongoing MIP6 4
session, the HA shall treat this BU as an initial registration if the BU contains MN-AAA 5
mobility message authentication option instead of MN-HA mobility message authentication 6
option. In this case, the HA shall overwrite the BCE for that MS and accepts the BU. 7
8
9
5.3.3 Multiple Registrations
10
11
The HA shall support Multiple home registrations with the same NAI but different Home
12
Addresses. The Binding Cache Entry (BCE) in the HA shall be indexed with the NAI and the
13
Home Address of the MS at a minimum. The HA shall rely on the Home RADIUS server to
14
authorize a user to perform multiple simultaneous home registrations on the same home link.
15
16
The MS is allowed to send more than one Binding Update for home registration with different
17
HoAs and with same or different CoAs. Whether these home registrations will be allowed or
disallowed depends on the Home Network provider‟s policy. If Multiple registrations are not 18
19
authorized by the Home Network's policy, the HA shall send a BA with Status Code set to
20
129 (Administratively prohibited) [RFC 3775].
21
22
5.3.4 Prefix Registrations 23

24
The HA may support prefix registrations based on [RFC 3963]. 25

26
27
If the HA supports [RFC 3963], the Binding Cache Entry (BCE) in the HA shall be indexed 28
with the NAI and the Home Address of the MS at a minimum. The HA shall rely on the 29
Home RADIUS server to authorize a user to perform prefix registration. The HA shall treat 30
Binding Update received from the MS as an implicit mode as specified in [RFC 3963]. If the 31
Home Agent is not configured to support Mobile Routers, it shall set R bit to 1 and include 32
the status code in the Binding Acknowledgement to 140 (Mobile Router Operation not 33
permitted) according to [RFC 3963]. 34
35
36
5.3.5 Data Forwarding 37
38
Upon successful MIPv6 registration, when the Home Agent receives a data packet destined
39
for any IPv6 address derived from the MS‟s unique prefix, it shall tunnel the packet to the
40
MS‟s CoA. 41
42
5.3.6 Home Registration Support 43

44
In this document the HA shall support the Authentication Protocol [RFC 4285] based Home 45
Registration for Home Registration. 46

47
The following sub-sections describe the detailed HA requirement. 48
49
5.3.6.1 Authentication Protocol Based Home Registration Support 50

51
The HA shall support MIP6 authentication protocol as defined in [RFC 4285] and the MN- 52
NAI mobility option as defined in [RFC 4283]. Upon receiving the initial BU, the HA shall 53
perform authentication of the BU based on the MN-AAA mobility message authentication 54

55
option and the MN-NAI mobility option. Upon receiving the subsequent BU for the MN
56
(MN-NAI), the HA shall perform authentication of the BU based on the MN-HA mobility
57
message authentication option.
58
59
60
5 MIP6 Operation 58
1
2
3 5.3.6.1.1 Authentication with MN-AAA mobility Message Authentication Option
4
5 For an initial home registration, the MS uses the MN-AAA mobility message authentication
6 option. In this case, the HA shall act as a RADIUS client in accordance with [RFC 2865].
7 Upon receiving the initial MIP6 Binding Update, the HA shall communicate the user‟s MN-
8 AAA authentication information to the Home RADIUS server with a RADIUS Access-
9
Request message. On receipt of the BU from the MS, if SPI in the MN-AAA mobility
10
message authentication option is set to HMAC_SHA1_SPI, the HA shall create a RADIUS
11
Access-Request message as described in Table 7. If the SPI in the BU is not set to
12
HMAC_SHA1_SPI the HA shall reject the BU using Status Code 129 (Administratively
13
prohibited) [RFC 3775]
14
15 Upon receiving a RADIUS Access-Accept from the Home RADIUS server, the HA shall send
16
a BA to the MS including an MN-HA mobility message authentication option if the replay
17
check (Mesg-ID option verification) is successful. If the replay check fails, the HA shall send
18
a BA back to the MS with MN-HA mobility message authentication option and an error code
19
MIPV6-ID-MISMATCH.
20
21 The MN-HA authenticator shall be calculated by the HA based on the distributed Integrity
22 Key (IK) received in the RADIUS Access-Accept message from the Home RADIUS server.
23
The MN-HA authenticator calculation is as follows:
24
25 Authenticator = First (96, HMAC_SHA1 (IK, Mobility_Data)).
26
27 Where:
28
29
Mobility_Data = care-of address | home address | Mobility header up to and
30
including the SPI field in MN-HA mobility message
31
authentication option.
32
For key derivation and distribution details of IK, please refer to section 5.4.1.
33
34 Upon receiving a RADIUS Access-Reject message from the Home RADIUS server due to
35
MN-AAA authenticator verification failure, the HA shall silently discard the BU since the HA
36
does not have a MN-HA shared secret (IK) at this time.
37
38 The HA shall cache the Integrity Key (IK) as the MN-HA shared secret for each of the
39 registered NAI and HoA pair to process BUs when BCE lifetime > 0. The IK is cached in a
40 security association in the BCE and is associated with the dynamic MN-HA SPI the home
41 agent received in the MN-HA SPI attribute in the RADIUS access accept message. Thus, this
42
SPI is associated with the dynamically derived security association between MS and HA.
43
44
45 5.3.6.1.2 Authentication with MN-HA Mobility Message Authentication Option
46
47 For the subsequent binding updates, the MS uses the MN-HA mobility message
48 authentication option in BU. In this case, the MN-HA shared secret shall be set to the IK,
49 which is derived during the initial BU and the SPI value should be set to the dynamic SPI the
50 MS retrieved from the MN-HA mobility message authentication option in the initial BA.
51 Upon receiving a BU, the HA shall process it as per [RFC 4285].
52
53 The security association indexed by the dynamic MN-HA SPI in the BCE corresponding to
54 the NAI and the HoA shall remain valid as long as the BCE is valid and shall be
55 removed/deleted when the BCE is removed.
56
57 If the initial BU (the BU is considered initial when the HA does not have a BCE for the NAI
58 and the HoA pair) contains MN-HA mobility message authentication option, the HA shall
59 reject the BU for the initial Home Registration. In this case the HA shall use Status Code 129
60 (Administratively prohibited) [RFC 3775]. (Note: This scenario can be allowed by requesting
the MN-HA SA associated with the SPI received in the MN-HA mobility message
59 5 MIP6 Operation
authentication option. If the HAAA does not have a valid MN-HA SA for the specified SPI, 1
the HAAA shall return a Access-Reject message. This scenario, could represent the case after 2
the HA loses its record of the MN BCE without informing the MN. i.e. a mismatch between 3
the MN and its HA.) 4
5
6
5.3.7 Return Routability Support for Route Optimization 7
8
The Home Agent shall support Return Routability (RR) for Route Optimization as specified 9
in [RFC 3775] with the exception that IPsec is not used to protect the RR messages. These 10
messages may be protected on a hop-by-hop basis through the operator‟s network. 11
12
5.3.8 HA Requirement as a RADIUS Client 13

14
The HA shall support RADIUS client as specified in [RFC 2865] and RADIUS Accounting as 15
16
specified in [RFC 2866] and section 5.6.
17
The HA shall send a RADIUS Access-Request to the Home RADIUS server when it receives 18
a BU containing the MN-AAA mobility message authentication option to request 19
authentication and authorization of the user by the RADIUS infrastructure. The HA shall 20
include the following attributes and VSAs: 21

22
User-Name attribute (NAI from BU) 23
24
 MIP6-CoA VSA (CoA from BU). 25
26
 MIP6-HoA VSA (HoA from BU).
27
 MIP6-Authenticator (Authentication data of the MN-AAA mobility message 28

29
authentication option from BU).
30
 MIP6-MAC-Mobility-Data VSA (MAC_Mobility_Data computed). 31

32
 MIP6 Home Agent VSA (HA IPv6 address from BU) 33
34
 MIP6-Mesg-ID (Timestamp value from the Mobility message replay protection 35
option (MESG-ID-OPTION-TYPE) 36
37
 MN-HA SPI Attribute with a value of 5 “3GPP2 Specific”.
38
If the HoA authorization fails, the Home RADIUS server returns a RADIUS Access-Accept 39
40
with a MIP6-HoA-Not-Authorized VSA along with the IK VSA and the MN-HA SPI
41
Attribute so that the HA can respond to the MS with BA. The HA sends back a BA with
42
status code = 129 (Administratively prohibited).
43
After the initial Home Registration (with MN-AAA mobility message authentication option) 44
is successful, the HA shall store the received IK and SPI from the RADIUS server for the 45
duration of the MIP6 session and use it as MN-HA shared secret and MN-HA SPI, 46
47
respectively.
48
49
5.3.9 DNS address assignment 50
51
For an initial successful home registration, the HA may include a MIPv6 vendor specific 52
option [RFC 5094] in the BA message for the home DNS address assignment. The DNS 53
server IPv6 addresses may be configured at the HA, or received from the Home RADIUS 54
server in a RADIUS Access-Accept message. If the HA does not receive the DNS Server 55
56
57
58
59
60
5 MIP6 Operation 60
1
2
3 IPv6 Address VSA from the Home RADIUS server, then the HA may include configured 24
4 DNS server IPv6 addresses. The HA shall conform to the rules specified in [RFC 5094] to
5
include this MIPv6 vendor specific option. The HA shall include this option in response to a
6
BU containing the MN-AAA authentication option to ensure that MS receives DNS
7
information in case the initial BA gets lost in the network. This option should not be included
8
in BA‟s sent to the MS for any subsequent registration.
9
10 This option shall not be sent in case the registration failed and the BA is indicating the failure.
11 The format of the option shall be set as following:
12
13
1 2 3
14 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
15
16 Type Length
17
18
Vendor ID
19
20
21 Subtype Reserved(0)
22
23
24
25
26
27 128 bit Primary DNS address
28
29
30
31
32
33
34
35
36 128 bit secondary DNS address
37
38
39
40
41
42
Type: 19
43
Length: 40
44
45 Vendor ID: 5535
46
47 Subtype: 1
48
49
Subtype is a Vendor defined value. For 3GPP2 Subtype=1 shall indicate DNS address
50 information.
51
52
53
54
55
56
57
58
59
60 24 The DNS information may be pre-configured in the HA or the HA may acquire the DNS information
via other schemes.
61 5 MIP6 Operation
5.4 RADIUS Server Requirements 1

2
The RADIUS server shall support the attributes defined in [RFC 3162]. The Home RADIUS 3
server shall authenticate MIP6 BU received from a user identified by the NAI. The RADIUS 4
server shall support the following attributes for MIP6: 5

6
 User-Name attribute (NAI from BU), 7
8
 User-Password attribute, 9
10
 NAS-ID (of the HA),
11
 MIP6-CoA VSA (CoA from BU), 12

13
 MIP6-HoA VSA (HoA from BU), 14
15
 MIP6-Authenticator (Authentication data from the MN-AAA mobility message 16
authentication option from BU), 17
18
 MIP6-MAC-Mobility-Data VSA (MAC_Mobility_Data computed), 19
20
 MIP6 Home Agent VSA (HA IPv6 address from BU),
21
 MIP6-HoA-Not-Authorized VSA, 22
23
 MIP6-Session Key VSA (IK), 24
25
 MIP6-Home Agent VSA (used for bootstrapping, Attribute B), 26
27
 MIP6-Home-Link Prefix VSA (used for bootstrapping, Attribute A),
28
 MIP6-Mesg-ID (Timestamp value from the Mobility message replay protection 29

30
option (MESG-ID-OPTION-TYPE),
31
 MN-HA SPI Attribute, 32

33
 MIP6-HA-Local-Assignment-Capability VSA (Used to request local HA/HL 34
assignment by PDSN), 35
36
 HA-Authorized VSA (Used to indicate that the HAAA authorizes the visited 37
network to assign HA/HL for the MS), 38
39
 HAAA-MIP6-HA-Protocol-Capability-Indication (Used to indicate protocol
40
capability supported by the HA assigned by HAAA for MIP6 signaling security), 41
 VAAA-Assigned-MIP6-HA (Used by VAAA to assign HA for the MS), 42

43
 VAAA-Assigned-MIP6-HL (Used by VAAA to assign HL Prefix for the MS), 44

45
 VAAA-MIP6-HA-Protocol-Capability-Indication (Used to indicate protocol 46
capability supported by the HA assigned by VAAA for MIP6 signaling security), 47
48
 DNS-Server-IPv6-Address (used by HAAA to indicate IPv6 DNS server addresses 49
to HA). 50
51
52
53
54
55
56
57
58
59
60
5 MIP6 Operation 62
1
2
3 Table 7 MIP6 RADIUS Attributes
4
5 Attributes/ Type Access- Acces Access Direction Description
6 VSAs Request s Reject
7 Accep
8 t
9
10
User-Name 1 1 1 1 HAAA <-> PDSN, NAI extracted from the MN-
11 HAAA <-> HA NAI mobility option in the BU.
12
13
User- 2 1 0 0 HA->HAAA Based on HA/AAA shared
Password secret.
14
15 NAS-ID 32 1 0 0 HA -> HAAA NAS ID of the HA.
16
MIP6 Home 26/118 1 0 0 HA->HAAA Received from BU, used for
17 Agent bootstrapping
18
19
MIP6-CoA 26/119 1 0 0 HA -> HAAA CoA received in BU
20 MIP6-HoA 26/141 1 0 0 HA -> HAAA HoA received in BU.
21
MIP6- 26/134 1 0 0 HA -> HAAA The Authentication data
22
Authenticator extracted from the MN-AAA
23 mobility message
24 authentication option.
25
MIP6-MAC- 26/138 1 0 0 HA -> HAAA SHA-1 (care-of address |
26
Mobility-Data home address | MH Data)
27
followed by the Timestamp
28
field in the Mesg ID mobility
29
option.
30
MH Data is the content of the
31 Mobility Header up to and
32 including the SPI field of MN-
33 AAA mobility message
34 authentication option.
35
MIP6-HoA- 26/120 0 0-1 0 HAAA -> HA Sent by Home RADIUS
36
Not- server if the HoA
37
Authorized authorization fails, always
38 sent along with MIP6-Session
39 Key
40
MIP6-Session 26/121 0 0-1 0 HAAA -> HA This VSA holds the Session
41
Key Key (IK) in its encrypted form.
42
IK is derived from the MN-
43
AAA shared secret after
44
authenticating a BU from the
45 MS.
46
47
MIP6-Home 26/140 0 0-1 0 HAAA -> PDSN Attribute B
Agent IPv6 address of the HA
48
obtained from the BU.
49
50 MIP6-Home 26/128 0 0-1 0 HAAA -> PDSN Attribute A (Section 5.1.3)
51 Link Prefix HAAA ->HA
52 MN-HA SPI 26/57 0-1 0-1 0 HAAA <-> PDSN SPI used to index the
53 dynamic MN-HA SA
54 generated by home RDAIUS.
55
MIP6-Mesg- 26/144 0-1 0 0 HA ->HAAA Contain the Timestamp value
56
ID found in the Mobility
57
message replay protection
58
option (MESG-ID-OPTION-
59 TYPE) used in computing the
60 Integrity Key (IK)
63 5 MIP6 Operation
Attributes/ Type Access- Acces Access Direction Description 1

VSAs Request s Reject 2
Accep 3
t 4
5
6
MIP6-HA- 26/179 0-1 0 0 PDSN->HAAA Indicates PDSN request to
7
Local- allow local HA/HL
8
Assignment- assignment capability
9
Capability
10
HA- 26/169 0 0-1 0 HAAA->PDSN Indicated that the HAAA 11
Authorized authorizes the visited 12
network to assign HA/HL 13
for the MS 14
15
HAAA-MIP6- 26/203 0 0-1 0 HAAA->PDSN Indicates protocol 16
HA-Protocol- capability supported by the 17
Capability- HA for MIP6 signaling 18
Indication security 19
VAAA- 26/205 0 0-1 0 VAAA>PDSN IPv6 address of HA assigned 20

Assigned- by VAAA 21
MIP6-HA 22
23
VAAA- 26/206 0 0-1 0 VAAA>PDSN HL Prefix assigned by VAAA
24
Assigned-
25
MIP6-HL
26
VAAA-MIP6- 26/207 0 0-1 0 VAAA->PDSN Indicates protocol capability 27
HA-Protocol- supported by the HA 28
Capability- assigned by VAAA for MIP6
29
Indication signaling security
30
DNS-Server- 26/214 0 0-1 0 HAAA->HA IPv6 DNS server information 31
IPv6-Address from HAAA to HA 32
The RADIUS server shall support HMAC_SHA-1 for authenticator computation. The 33
authentication computation shall be performed as follows: 34
35
Authentication data = HMAC_SHA1 (MN-AAA Shared key, MIPv6- 36
MAC_Mobility Data) 37
38
If the MN-AAA authenticator verification has failed, the Home RADIUS server shall send 39
RADIUS Access-Reject message to the HA without including the ID and the IK information. 40
41
The authentication and authorization requirements for the Home RADIUS server are as
42
described in sections 5.4.1 and 5.4.2.
43
44
5.4.1 RADIUS Support for Session Key Generation and Distribution to the 45
46
HA 47
48
The Home RADIUS server generates the Session Key (IK) from the MN-AAA shared secret
49
and a unique SPI after authenticating a BU from the Mobile Station. The Home RADIUS
50
server shall send a RADIUS Access-Accept message containing the Session Key (IK)
51
encrypted using a method as described in section 3.5 of [RFC 2868] and the dynamically
52
generated unique MN-HA SPI. In particular, the encrypted IK is included in the MIP6- 53
Session Key VSA and the dynamic SPI in the MN-HA SPI attribute and sent to the HA. The 54
Home RADIUS server derives IK and sends it to the HA (in its encrypted form using the 55
MIP6-Session Key VSA) along with other required attributes/VSAs in the following 56
condition: 57
58
 Authentication, Authorization succeeded
59
60
5 MIP6 Operation 64
1
2
3  Authentication succeeded but the authorization of the HoA failed. This may happen
4 if (1) the MS claimed an HoA that is either reserved (or used by) another user; or (2)
5
the HoA is auto-configured with a prefix that was not authorized to be used by the
6
user.
7
8 The message flow for successful authentication and authorization and IK and SPI derivations
9 and distribution to the HA is shown below:
10
11
12 Home
MS HA
13 RADIUS
14
15 BU (MN-AAA auth opt, MN-NAI option,
16 Mobility message replay protection
17 option)
18 a
19
20
21
Access-Request (VSAs)
22
b
23
24
25 Authenticate ,
26 Genenrate IK Authorize + c
27 Generate IK
28
29
30
Access-Accept
31
(MIP6_Session Key VSA) d
32
33
34
35
36
Store MN-HA SS = IK e
37
38
39
40 BA (MN-HA auth option, Mobility
41 message replay protection option)
42 f
43
44
45
46
47 Auth BA with IK ,
48 Store g
49 MN-HA SS = IK
50
51
52
53
54
55
56 Figure 13 Derivation and distribution of IK and MN-HA SPI during Home Registration
57
58
59
a. The MS sends a Binding Update message to initiate Home Registration. In the BU the
60
MS uses MN-AAA mobility message authentication option and the Mobility message
replay protection option.
65 5 MIP6 Operation
b. The HA sends a RADIUS Access-Request, which include MN-HA SPI attribute with 1
value 5, to the Home RADIUS server to authenticate and authorize the MS. The Home 2
RADIUS server shall treat the MN-HA SPI attribute with a value of 5 as an indication by 3
the HA to generate and communicate back the IK and a unique MN-HA SPI. 4
5
c. The Home RADIUS server authenticates the user based on MN-AAA Shared Secret (SS). 6
The Home RADIUS server then generates IK based on MN-AAA shared secret, a unique 7
MN-HA SPI, and other parameters with a keying material derivation function. In this 8
document this keying material derivation function will be SHA-1 defined also as PRF: f3 9
in S.S0055-0_v1.0_ECA. The keys can be derived as follows (Timestamp is the value of 10
the MIP6-Mesg-ID VSA): 11
12
IK= PRF (MN-AAA shared secret, “Integrity Key” | Timestamp, Home 13
Agent‟s Address, Home Address), 14
15
The input parameters into the subscriber authentication calculation shall be set to:
16
17
Subscriber Authentication (128 bits) = MN-AAA Shared Secret
18
Type Identifier (8-bits) = 0x45 19

20
Random Number (128-bits) = First 128 bits of SHA1(“Integrity Key”| 21
Timestamp | Home Agent‟s Address | 22
Home Address) 23
24
Family Key (32-bits) = 0x4D36414F 25
26
The output of the PRF is a 128-bit long IK that can be used as the MN-HA shared secret for
27
the MIP6 session.
28
29
The MS also performs the same PRF with the same inputs to generate IK at this stage or
30
earlier.
31
d. The Home RADIUS server then sends back a RADIUS Access-Accept message to the 32
HA. In the RADIUS Access-Accept, the Home RADIUS server includes MIP6-Session 33
Key VSA containing the derived IK encrypted using the procedures define in section 3.5 34
of [RFC 2868] and the unique SPI in the MN-HA SPI attribute. 35
36
e. Upon receiving the RADIUS Access-Accept message the HA decrypts the MIP6-Session 37
Key VSA and stores the IK as MN-HA shared secret for the MIP6 session and saves the 38
MN-HA SPI to index the MN-HA SA, in this document it is limited to the IK, for the rest 39
of the session lifetime. 40

41
f. The HA sends a BA back to the MS. In the BA, the HA computes the MN-HA 42
authenticator based on the received IK and include the MN-HA SPI in the MN-HA 43
mobility message authentication option SPI field. 44
45
g. The MS authenticates the BA by computing the MN-HA authenticator with IK that it 46
derived in step (c). If the authentication succeeds the MS stores the derived IK for future 47
use as MN-HA shared secret for the duration of the MIP6 session. The MS stores the SPI 48
received in BA to index the MN-HA SA for the rest of the MIP6 session lifetime. 49
50
51
5.4.2 RADIUS Support for MIP6 Bootstrap 52
53
Upon receiving a RADIUS Access-Request from a PDSN, the Home RADIUS server shall 54
authenticate and authorize the user (identified by NAI) for IPv6 access at the PDSN. If the 55
user is authorized for MIP6 access according to the subscription profile, the Home RADIUS 56
server shall return one or more of the following VSAs to the PDSN in the RADIUS Access- 57
Accept message to assist the MS in performing MIP6 registration: 58
59
60
5 MIP6 Operation 66
1
2
3  Home Link Prefix VSA(Attribute A)
4
5  MIP6-Home Agent VSA (Attribute B)
6
7  HAAA-MIP6-HA-Protocol-Capability-Indication
8
The Home RADIUS server shall include Home Link Prefix (Attribute A) in the Access-
9
10
Accept message to the PDSN if the user is authorized for MIP6 access. This enables the MS
11
to autogenerate the MIP6 HoA.
12
Refer to Table 6 in section 5.1.3 for the corresponding PDSN and MS behavior upon
13
receiving different combinations of these attributes.
14
15 The Home RADIUS server shall assign a globally unique Home Link Prefix for each
16 individual MS. Refer to the Table in section 5.1.3 for the corresponding PDSN and MS
17
behavior upon receiving different combinations of these attributes.
18
19 Upon receiving a RADIUS Access-Request from a HA, the Home RADIUS server shall
20 authenticate and authorize the user (identified by NAI) for MIPv6. If the user is authorized
21 for MIP6 access according to the user profile, the Home RADIUS server shall return Home
22 Link Prefix VSA(Attribute A) (if present) to the HA in the RADIUS Access-Accept message
23 to assist the HA in performing MIP6 registration.
24
25 Upon receiving the RADIUS Access-Request message with the MIP6-HA-Local-Assignment-
26 Capability VSA, if the user profile, roaming agreement, and the policy of the home network
27 allows the MS to access a HA in the visited network, the home RADIUS server shall send the
28 HA-Authorized VSA along with the MIP6-Home Agent VSA containing an assigned HA in
29 the home network and a MIP6-Home Link VSA containing an assigned home link prefix to
30 the PDSN in the RADIUS Access-Accept message. If the user profile or the policy of the
31 home network disallows the MS to access a HA in the visited network, the home RADIUS
32 server shall omit the HA-Authorized VSA but include the MIP6-Home Agent VSA containing
33 an assigned HA in the home network and MIP6-Home Link VSA containing an assigned HL
34 prefix in the RADIUS Access-Accept message.
35
36 If the VAAA supports local HA assignment, and the visited cdma2000 network policy
37 enables this function, when the VAAA receives the HA-Authorized VSA [4] in a RADIUS
38 Access-Accept message, the VAAA shall assign an HA and HL Prefix in the visited
39 cdma2000 network for the MS and convey the assigned HA address and HL prefix in the
40 VAAA-Assigned-MIP6-HA VSA and VAAA-Assigned-MIP6-HL VSA of the RADIUS
41 Access-Accept message. If the local HA assignment is not authorized by the HAAA, the
42 VAAA shall not assign an HA/HL, If the local HA assignment is authorized by the HAAA
43 but the VAAA is not able to assign the HA/HL, the VAAA shall defer the HA/HL assignment
44 to the PDSN.
45
46
47
48
5.5 MS Requirements
49
The MS may support MIP6 service. The MS shall access cdma2000 packet data service using
50
the cdma2000 air interface [5-9] and [15].
51
52
54
55 The MS shall use PPP as the data link protocol for MIP6 access. The MS may support
56 multiple MIP6 Home Addresses over a single PPP session. The Mobile shall use the global
57 IPv6 address with /64 prefix acquired from PDSN as the Care-of Address (CoA) during MIP6
58 operation. The MS shall run PAP/CHAP during establishment of the PPP session.
59
60
67 5 MIP6 Operation
2
4
6
8
5.5.1.3 PPP Authentication 9

10
Same as Simple IPv6 operation. See section 3.4.1.3. 11

12
13
5.5.1.4 Addressing with IPv6CP and ICMPv6
14

16
17
5.5.1.5 Compression
18
19
Same as Simple IPv6 operation. See section 3.2.1.7.
20
21
5.5.1.6 PPP Framing 22
23
25
5.5.2 MS Requirement to Support Stateless DHCPv6 to Obtain MIP6 26

27
Bootstrap Info 28
29
In order to support MIP6 bootstrapping, the MS shall support DHCPv6 client functionality
30
and perform the stateless DHCPv6 procedures according to [RFC 3736].
31
The MS shall send an Information-Request message as per [RFC 3315] to the PDSN and shall 32
include it‟s access authentication NAI in the Identifier field of the Client Identifier Option 33
34
with DUID-EN (enterprise number set as 5553) in order to request for the MIP6 bootstrap
35
configuration information. To construct the Information-Request message; the MS sets the
36
"msg-type" field to “Information-Request”. It also generates a transaction ID and inserts this
37
value in the "transaction-id" field.
38
The MS shall support DHCPv6 for HA/HL assignment as defined in MIP6 integrated scenario 39
40
bootstrapping specification [Draft-ietf-mip6-bootstrapping-integrated].
41
42
The MS shall support DHCPv6 Option for HA/HL Discovery [Draft-ietf-mip6-hiopt]. 43
44
45
If the MS has received the MS-PDSN Version Capability Indication packet from the PDSN
46
and the MIP6-HA-Local-Assignment-Capability bit in the List of PDSN capabilities field is
47
set to 0, the MS shall not request Home networkMIP6 bootstrap information in the visited
48
network.If the MS accepts the HA assignment from either home network and visited network,
49
the MS shall send the DHCPv6 Information-Request message including one instance of Home
50
Network Information Option with id-type 0 and one or more instances of Home Network
51
Information Option with id-type 1, or alternately, the MS shall send one instance of Home 52
Network Information Option with id-type 2 signaling no preference. If the MS doesn‟t receive 53
any HA information in the DHCPv6 Information-Reply, the MS may continue to use Simple 54
IPv6. 55
56
The MS may support processing of DHCPv6 Vendor specific option containing the HA
57
protocol capability indication. If the MS does not support the processing of DHCPv6 Vendor
58
specific option for HA protocol capability then MS shall ignore the contents of the option. 59
60
5 MIP6 Operation 68
1
2
3 If MS does not support the protocol indicated in the option for MIP6 signaling security, then
4 MS shall terminate the MIP6 call.
5
6
5.5.2.1 Mobile Station Requirements to Support Dynamic Home Agent
7
8
Assignment
9
10
The MS shall support the Dynamic Home Agent Address Discovery procedure as defined in
11
[RFC 3775].
12
The MS may also discover an HA address in the MIP6 Bootstrap configuration information in
13
the response to a DHCPv6 Information-Request sent to the PDSN.
14
15 The MS shall process Binding Updates that contain Mobility message authentication options
16 (MN-HA or MN-AAA), Mobility Mesg ID option and MN-NAI mobility option.
17
18
5.5.2.2 Mobile Station Requirements to Support Dynamic Home Address
19
20
Configuration
21
If the HoA is not preconfigured, the MS shall auto-configure the HoA based on the Home
22
23
Link Prefix information.
24
In order to enable Dynamic Home Address configuration, the MS shall send a DHCPv6
25
Information-Request [RFC 3736] for MIP6 bootstrap information to the PDSN. The use of the
26
received bootstrap information by the MS is described in section 5.1.3.
27
28
29 5.5.3 Multiple Registrations
30
31 In this document the MS is allowed to perform multiple simultaneous home registrations with
32 the same NAI as long as the MS is authorized to do so by the Home Network‟s policy. In each
33 registration the MS shall use a different HoA at a minimum.
34
35
36 5.5.4 Prefix Registration
37
38 The MS may perform home and prefix registrations with the same NAI as long as the MS is
39 authorized to do so by the Home Network‟s policy based on [RFC 3963]. If the MS supports
40 [RFC 3963], the MS shall use implicit mode as specified in [RFC 3963] to send Binding
41 Update with R bit set. Upon receiving successful Binding Ack with R bit set, if the MS
42 serves as a mobile router (see [RFC 3963]), the MS may use the assigned home link prefix as
43 mobile network prefix and advertise it on the mobile network attached to it.
44
45
Upon receiving successful Binding Ack with R bit not set and if the MS decides to keep the
46
47
binding with the HA, the MS shall treat the binding as a HoA binding without support of
48
[RFC3963]. Otherwise, the MS shall follow the procedures as specified in [RFC 3963].
49
50
5.5.5 MIP6 Home Registration
51
52 MIP6 Home Registration is performed when the MS sends a Binding Update message to the
53 HA. The MS shall include the MN-NAI mobility option in the BU. The inclusion of the MN-
54
NAI mobility option in the subsequent BUs is required as per [RFC 4285]. The BU is
55
protected either by the MN-AAA or MN-HA Mobility message authentication option and
56
Mesg ID option. Upon receiving a BA back from the HA, the MS authenticates the BA with
57
the MN-HA Mobility message authentication option and the Mesg ID option and retrieve the
58
MN-HA SPI from the MN-HA mobility message authentication option and use it to index the
59
MN-HA SA for the rest of the MIP6 session lifetime.
60
69 5 MIP6 Operation
5.5.5.1 Authentication Protocol based Home Registration Support 1

2
The MS shall support the MIP6 authentication protocol as defined in [RFC 4285] and the 3
MN-NAI mobility option as defined in [RFC 4283]. 4
5
Upon receiving the BA from the HA, the MS shall perform authentication of the BA based on 6
the MN-HA mobility message authentication option contained in the BU and the MN-NAI 7
mobility option. In the authenticator computation the MS shall use the IK that was generated 8
using the MN-AAA shared secret. 9
10
5.5.5.1.1 Authentication with MN-HA Mobility Message Authentication Option 11
12
The MS shall use MN-HA mobility message authentication option in the subsequent BU. In
13
this case, the MS shall include the MN-HA authenticator after computing it as follows in the
14
BU:
15
16
Authenticator = First (96, HMAC_SHA1 (IK, Mobility Data)).
17
Mobility Data = care-of address | home address | MH Data. 18

19
MH Data is the content of the Mobility Header up to and including the SPI field of this 20
extension. The MS shall set the SPI to the dynamic SPI which was received in the initial BA 21
message. Integrity Key (IK) is derived during the initial Home Registration using the MN- 22
AAA shared secret. The MS shall generate the IK in the same manner as described in section 23
5.4.1. 24
25
Upon receiving the BA with status code set to 0, the MS shall extract the MN-HA 26
authenticator and the SPI from the MN-HA mobility message authentication option. The MS 27
shall authenticate the BA by calculating the authenticator as follows: 28
29
Authenticator = First (96, HMAC_SHA1 (IK, Mobility Data)). 30
31
Mobility Data = care-of address | home address | MH Data.
32
extension. The MS shall set the SPI to the dynamic SPI which was received in the initial BA 34
35
message. The HMAC-SHA1 shall be used in the authenticator calculation. Integrity Key (IK)
36
is derived during the initial Home Registration using the MN-AAA shared secret. The MS
37
shall generate the IK in the same manner as described in section 5.4.1.
38
The MS shall process the BA as per [RFC 4285]. 39

40
5.5.5.1.2 Authentication with MN-AAA Mobility Message Authentication Option 41
42
The MS shall use MN-AAA mobility message authentication option in the BU to perform 43
initial Home Registration if the MS has a shared secret with the home RADIUS server. When 44
the MS uses MN-AAA mobility message authentication option it shall compute the IK. The 45
MN-AAA authenticator is calculated using the MN-AAA shared secret. In this case the MS 46
shall set the SPI value to HMAC_SHA1_SPI. 47
48
In the BU, the MS shall include the MN-AAA authenticator after computing it as follows: 49
50
Authenticator = HMAC_SHA1 (MN-AAA shared secret, MAC_Mobility_Data) 51
52
Where:
53
MAC_Mobility Data = SHA-1 (care-of address | home address | MH_Data) 54

55
extension. 57
58
59
60
5 MIP6 Operation 70
1
2
3 Upon receiving the BA with status code set to 0, MS shall extract the MN-HA authenticator
4 and the SPI from the MN-HA mobility message authentication option. The MS shall process
5
the BA as per [RFC 4285] by using the IK to verify the MN-HA authenticator value.
6
7 Upon receiving a BA with error MIPV6-ID-MISMATCH, the MS shall authenticate the BA
8 by verifying the MN-HA authenticator value with IK generated using the timestamp included
9 in the initial BU. On a successful authentication, the MS shall adjust its timestamp and send a
10 subsequent BU using the updated value. The MS shall include the MN-AAA authentication
11 option in the subsequent BU and generate a new IK with the updated timestamp. The Home
12
Radius server shall generate the same IK when it processes the MN-AAA authentication
13
option and sends it to HA with Access-Accept as described in section 5.4.1. Upon receiving a
14
BA with status code set to 0 in response to an initial BU, MS shall include MN-HA
15
authentication option in every subsequent registration.
16
17
18 5.5.6 DNS address assignment
19
20 MS shall support the MIPv6 vendor specific option for home DNS address assignment as
21 defined in section 5.3.9. If the MS receives MIPv6 vendor specific option in BA message in
22 response to its initial BU, the MS shall use the DNS information provided in the option for
23 any DNS query to the home network via the MN-HA tunnel. MS shall process the MIPv6
24 vendor specific option according to specifications in [RFC 5094] and this document.
25
26
27 5.5.7 Termination
28
29 For cases other than power down registration, if the MS wishes to terminate the MIP6 session,
30 it shall send a MIP6 BU to the HA with a Registration Lifetime field set to zero.
31
32
For the case of power-down registration [5-9], the MS shall not send an LCP Terminate-
33 Request message to the PDSN and shall not send a MIP6 BU with Registration Lifetime of
34 zero to the HA.
35
36
37 5.6 Accounting Consideration
38
39 In this document, the PDSN maintains the same accounting model for MIP6 as is used for a
40 Simple IPv6 session. The PDSN generates accounting records based on the NAI used for
41 CHAP/PAP authentication, the (prefix) advertised to the MS in the RA messages, and
42 interface ID negotiated during IPCP, which are used to construct the care of address of the
43 MS.
44
45 The HA shall provide additional accounting records to the Home RADIUS server that include
46 the HoA, NAI and CoA for all MIP6 session established by the MS. The HA shall not
47 generate byte counts for the MIPv6 session if the Home Network‟s policy allows the MS to
48 perform route optimization.
49
50 The following message flow shows the sequence diagram for accounting procedures:
51
52
53
54
55
56
57
58
59
60
71 5 MIP6 Operation
1
2
3
MS PDSN HAAA CN HA
4
5
1. BU (HoA, NAI, CoA) 6
2. Access-Request 7
8
3. Access-Accept
9
4. BA 10
5. Accounting-Request (start) 11
6. Accounting-Response 12
13
14
7. Binding
lifetime expires 15
or MS 16
deregisters 17
8. Accounting-Request (stop) 18
19
9. Accounting-Response
20
21
22
23
24
25
26
27
Figure 14 Accounting Procedures for MIP6
28
29
1. The MS sends an initial BU to the HA, which includes the CoA, HoA and shall include 30
the user‟s NAI. 31
32
2-3. The HA authenticates the BU with the RADIUS server, which results in a successful 33
authentication. 34
35
4. The HA sends a BA to the MS.
36
37
5. The HA sends a RADIUS Accounting-Request (start) message which includes the HoA,
38
NAI and CoA, as well as other attributes defined in [Chapter 5].
39
6. The HAAA sends a RADIUS Accounting-Response back to the HA. 40

41
7. The binding lifetime expires or the MS sends an explicit deregistration. 42
43
8-9. The HA sends a RADIUS Accounting-Request (stop) message to indicate that the MIP6 44
session has closed. 45
46
5.6.1 PDSN requirements 47

48
49
The PDSN shall generate accounting records based on the prefix advertised to the MS in the
50
RA, i.e., there are no additional requirements on the PDSN for accounting of MIP6 sessions.
51
52
5.6.2 HA requirements 53
54
Upon receiving and successfully authenticating a Binding Update, the HA shall send a 55
RADIUS Accounting-Request (start) to the HAAA. The HA shall generate and include an 56
Account-Session ID, the NAS-IP address or Identifier attribute, the Home IPv6 address in the 57
MIP6-HoA VSA and the Care of Address in a MIP6-CoA VSA. The HA shall also include 58
59
60
5 MIP6 Operation 72
1
2
3 the user NAI if available in the User-Name attribute. See [Chapter 5] for complete list of
4 attributes.
5
6 If the MS explicitly deregisters (Binding Update with lifetime 0), or if the binding lifetime
7 expires or if the HA received a Disconnect-Request message from the HAAA, the HA shall
8 send a RADIUS Accounting-Request (stop) message to the HAAA containing the attributes
9 defined in [Chapter 5]. If any of the parameters in the BCE are updated, the HA shall send a
10 RADIUS Accounting-Request (stop) message followed by a RADIUS Accounting-Request
11 (start) message.
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
51
52
53
54
55
56
57
58
59
60
73 5 MIP6 Operation
6 Simultaneous Services 2
3
The PDSN shall support any combination of MIP4, Simple IPv4 and Simple IPv6 4
5
simultaneously. The PDSN shall support MIP6 bootstrapping functionality.
6
The MS may support any combination of MIP4, Simple IPv4, Simple IPv6 and MIP6 7
simultaneously. 8
9
The HA shall support MIP4 and MIP6 simultaneously. 10
11
Although any of these may run simultaneously, individual services are distinct. 12
13
Within a single PPP session, the PDSN shall support simultaneous operation of IPCP [RFC
14
1332] and IPv6CP [RFC 2462].
15
Each packet data session shall be authenticated and authorized independently. In addition, 16
17
each such session shall have unique accounting records. The PDSN shall send RADIUS
18
accounting messages with UDRs associated with each session. The events for RADIUS
19
accounting messages are the same as defined in [X.S0011-005-D].However, simultaneous
20
Simple IPv4 and Simple IPv6 (or MIP6) share a common authentication and authorization
21
procedure at the PDSN as described in Section 3.2.2 if the PPP additional authentication is not
22
used. If the PPP additional authentication is used, simultaneous Simple IPv4 and Simple IPv6
23
(or MIP6) shall be authenticated and authorized independently as specified in section 6.1. 24
25
26
6.1 PPP Additional Authentication 27
28
Operators may want to apply different authentication and authorization procedures to Simple 29
IPv4 and Simple IPv6 (or MIP6). The IPv4 access may have been used for dial-up services for 30
enterprise network access or 3rd Party ISP access. If an operator provides this IPv4 access 31
simultaneously with an IPv6 access for IMS services, different authentication and 32
authorization procedures may be applied to IPv4 and IPv6 sessions since IMS services are 33
typically under control of the operator while the IPv4 services are not. However, the standard 34
PPP [RFC1661] does not allow performing an additional authentication after an NCP reaches 35
the open state. In this section, a 3GPP2 extension for PPP allowing the additional 36
authentication is specified. 37
38
39
6.1.1 PDSN and MS Common Requirements 40
41
The PDSN and MS may support the 3GPP2 vendor specific PPP Additional Authentication 42
packets defined in PPP vendor specific packets [RFC 2153]. The PPP Additional 43
Authentication shall be applied only in IPv4/IPv6 simultaneous operation. If the PDSN and 44
MS support the PPP Additional Authentication, the following four messages shall be 45
supported. 46
47
48
 AddAuth Request
49
This message shall be sent by the MS when it wants to establish another NCP. It 50
51
includes a proposed authentication protocol (PAP or CHAP).
52
53
 AddAuth Reply 54
55
This message shall be sent by the PDSN in response to the AddAuth Request.
56
57
 AddAuth Packet 58
59
60
1
2
3 This message may be sent by either the PDSN or MS. It encapsulates a standard
4 authentication packet, e.g., CHAP Challenge, CHAP Response etc.
5
6
7  AddAuth NAK
8
This message may be sent by either the PDSN or MS in case a received PPP
9
10
additional authentication packet can not be properly processed.
11
12 The format of the 3GPP2 vendor specific PPP Additional Authentication packet is shown in
13 Figure 15 .
14
15
16
0 7 8 15 16 23 24 31
17 Code Identifier Length
18 Magic Number
19 OUI Kind
20 Value
21 Figure 15 3GPP2 vendor specific PPP Additional Authentication packet format
22
23
24 Code = 0 (as defined in RFC 2153)
25 Identifier = The Identifier field shall be changed for each Vendor Specific
26 packet sent. It is used to match requests with responses.
27
28
Length = <= Variable (octets)
29 Magic Number = The Magic-Number field is four octets and aids in detecting
30 links that are in the looped-back condition. Until the Magic-
31 Number Configuration Option has been successfully
32 negotiated, the Magic-Number shall be transmitted as zero. See
33
the Magic-Number Configuration Option in [RFC 1661] for
34
further explanation.
35
36 OUI = 0xCF0002
37 Kind = 9 (AddAuth Request)
38
10 (AddAuth Reply)
39
11 (AddAuth Packet)
40
12 (AddAuth NAK)
41
42 Value = Kind = 9 (AddAuth Request): Authentication options for PAP
43 [RFC 1334] or CHAP [RFC 1994]
44 Kind = 10 (AddAuth Reply): Not included.
45 Kind = 11 (AddAuth Packet): See Figure 16 for the detail
46 format of the value field
47 Kind = 12 (AddAuth NAK): Reason code (1 octet), 00000000
48 (The message received in the wrong state.), 00000001 (The
49 message is inappropriately formatted.)
50 Other values are reserved.
51
52
53
54 0 7 8 15 16 23 24 31
55 Protocol Authentication packet
56 Authentication packet...
57 Figure 16 Value format for AddAuth packet
58
59
60
Protocol: PAP (0xC023) or CHAP (0xC223)
75 6 Simultaneous Services
Authentication packet: Authentication packet for PAP [RFC 1334] or CHAP [RFC 1994] 1
2
3
The PDSN and MS may perform the PPP Additional Authentication when the
4
Version/Capability Indication Packet indicates that both peers support it.
5
During the PPP Additional Authentication, either PAP or CHAP shall be performed. Other 6
authentication mechanisms, such as EAP, shall not be performed. A different NAI from the 7
one used in the PPP authentication phase shall be used during the PPP Additional 8
Authentication. 9
10
While the PPP Additional Authentication is performed, the MS and PDSN may exchange IP 11
packets over the previously negotiated NCP. 12
13
If an expected response message, e.g., AddAuth Reply, to a particular message that has been 14
sent, e.g., AddAuth Request, is not received during the PPP Additional Authentication 15
Procedure, the PDSN and MS may retransmit the message. The number of retransmissions 16
and retransmission timer are configurable by the operator. 17
18
The following figure shows a typical call flow for the PPP Additional Authentication. 19
20
Operator 3rd Party
MS PDSN 21
HAAA HAAA
22
23
24
1. Authentication and 25
1. PPP Establishment with IPv6CP and RA
Accounting 26
27
28
2. AddAuth Request (CHAP) 29
30
3. AddAuth Reply 31
32
4. AddAuth Packet (CHAP Challenge) 33
34
5. AddAuth Packet (CHAP Response) 35

36
6. Access Request
37
38
7. Access Accept
39
8. AddAuth Packet (CHAP Success)
40
41
42
9. IPCP Negotiation 43
10. Accounting Request (Start)
44
45
11. Accounting Response
12. IPv6 and IPv4 Simultaneous Operation 46
47
48
Figure 17 Additional Authentication (CHAP case) 49
50
1. The PDSN and MS establish an NCP (IPv6CP in this example). The authentication and 51
authorization are performed with the operator‟s HAAA. (The NCP negotiated in this 52
phase is called as the first NCP in this document.) 53

54
2. If the MS wants to establish another NCP (IPCP in this example) and requires a different 55
authentication from step 1, it sends the AddAuth Request including the CHAP option. 56
57
3. The PDSN sends the AddAuth Reply. 58
59
60
1
2
3 4. The PDSN sends the CHAP Challenge in the AddAuth Packet.
4
5 5. The MS computes the CHAP response value and include it along with NAI and CHAP
6 ID in the CHAP response in the AddAuth Packet. This NAI is different from the one
7 used in the step 1.
8
9 6. The PDSN sends the RADIUS Access Request message to the 3rd Party‟s HAAA.
10
11
7. 3rd Party‟s HAAA sends the RADIUS Access Accept message to the PDSN.
12
8. The PDSN sends the CHAP success in the AddAuth Packet.
13
14 9. The PDSN and MS perform the IPCP negotiation. (The NCP negotiated in this phase is
15 called as the second NCP in this document.)
16
17 10. The PDSN sends the RADIUS Accounting Request (Start) message to the 3rd party
18 HAAA.
19
20 11. The 3rd party HAAA sends the RADIUS Accounting Response message to the PDSN.
21
22
12. The PDSN and MS exchanges IPv4 and IPv6 packets.
23
24 6.1.2 PDSN Requirements
25
26 If the PDSN supports the PPP Additional Authentication, it shall indicate it in the 3GPP2
27 Version/Capability Indication Packet.
28
29
30 If the PDSN receives the AddAuth Request packet when no NCP is in the open state, it shall
31 send the AddAuth NAK packet to the MS with the reason code 0.
32
33
When the first NCP is already in the open state, if the PDSN receives the AddAuth Request
34
from the MS, it shall accept MS‟s proposed authentication-protocol option [either RFC 1334
35
section 2.1 for PAP or RFC 1994 section 3 for CHAP] and send the AddAuth Reply to the
36
MS. Depending on the MS‟s requested authentication option, the PDSN takes one of the
37
following two procedures.
38
39
40 CHAP case:
41
42 The PDSN shall send the CHAP Challenge in the AddAuth Packet to the MS after the
43 PDSN sends the AddAuth Reply. If the PDSN receives the AddAuth Packet containing the
44 CHAP response, it shall send the RADIUS Access Request message to the HAAA. If the
45 authentication is successful, the PDSN shall send the AddAuth Packet containing the
46 CHAP success to the MS. If the authentication is failed, the PDSN shall send the AddAuth
47 Packet containing the CHAP failure to the MS, terminate the PPP Additional
48 Authentication procedure and maintain the first NCP.
49
50
PAP case:
51
52
The PDSN shall wait for the PAP Authenticate-Request in the AddAuth Packet from the
53
MS after the PDSN sends the AddAuth Reply. If the PDSN receives the AddAuth Packet
54
containing the PAP Authenticate-Request, it shall send the RADIUS Access Request
55
message to the HAAA. If the authentication is successful, the PDSN shall send the
56
AddAuth Packet containing the PAP Authenticate-Ack to the MS. If the authentication is
57
failed, the PDSN shall send the AddAuth Packet containing the PAP Authenticate-Nak to
58
59
the MS, terminate the PPP Additional Authentication procedure and maintain the first NCP.
60
77 6 Simultaneous Services
If the PDSN receives an inappropriately coded PPP Additional Authentication message, it 1

shall send the AddAuth NAK to the MS with the reason code set to 1. The PDSN may send a 2
reconfigured message if it receives the AddAuth NAK from the MS with the reason code set 3
to 1. 4
5
6
After sending PAP or CHAP success, the PDSN may initiate the second NCP negotiation.
7
8
6.1.3 MS Requirements 9
10
If the MS supports the PPP Additional Authentication, it shall indicate it in the 3GPP2 11
Version/Capability Indication Packet. 12

13
14
If the MS wants to establish the second NCP that requires a separate authentication from the 15
established first NCP, the MS shall send the AddAuth Request to the PDSN. The MS shall not 16
send the AddAuth Request packet if the first NCP has not reached the open state. 17
18
If the MS receives the AddAuth NAK Packet with the reason code 0, it should give up the 19
PPP Additional Authentication. 20

21
22
The MS shall include the PAP authentication option [RFC 1334 section 2.1] or the CHAP 23
authentication option [RFC 1994 section 3] in the AddAuth Request. If the second NCP does 24
not require a separate authentication from the established first NCP, the MS shall not perform 25
the PPP Additional Authentication. Depending on the MS‟s requested authentication option, 26
the MS takes one of the following two procedures. 27
28
29
CHAP case:
30
The MS shall wait for the AddAuth Packet containing the CHAP Challenge after it receives 31
the AddAuth Reply. When the MS receives the CHAP Challenge, it shall compute the 32
33
CHAP response value and send it along with NAI and CHAP ID in the CHAP response in
34
the AddAuth Packet to the PDSN. If the MS receives the AddAuth Packet containing a
35
CHAP Challenge without receiving the AddAuth Reply, it shall continue the PPP
36
Additional Authentication procedure. If the AddAuth Reply is received after CHAP
37
authentication starts, the MS shall ignore it. If the MS receives the AddAuth packet
38
containing the CHAP Success, it shall initiate the second NCP negotiation. If the MS
39
receives the AddAuth Packet containing the CHAP Failure, the MS shall terminate the PPP
40
Additional Authentication procedure and maintain the first NCP. 41
42
PAP case: 43
44
After MS receives the AddAuth Reply, it shall send the AddAuth Packet containing the 45
PAP-Authenticate-Request. If the MS receives the AddAuth packet containing the PAP 46
Authenticate-Ack, it shall initiate the second NCP negotiation. If the MS receives the 47
AddAuth Packet containing the PAP Authenticate-Nak, the MS shall terminate the PPP 48
Additional Authentication procedure and maintain the first NCP. 49
50
51
If the MS receives an inappropriately coded PPP Additional Authentication message, it shall
52
send the AddAuth NAK to the PDSN with the reason code set to 1. The MS may send a 53
reconfigured message if it receives the AddAuth NAK from the PDSN with the reason code 54
set to 1. 55
56
57
58
59
60
1
2
3
4 7 IP Services Authorization and Selection
5
6
7
8
7.1 IP Services Authorization
9
The Home AAA may provide the IP-Services-Authorized VSA to the PDSN during the access
10
authentication (section 3.2.2 and 4.4). If the PDSN receives the IP-Services-Authorized VSA
11
in the RADIUS Access Accept message, it shall provide only authorized IP services to the
12
MS. If the MS requests IP services other than authorized services, the PDSN shall reject the
13
14
request using procedures defined in IPCP or IPv6CP. See section 3.2.2.1 in [21] for IPv4
15
addressing with IPCP. See section 3.2.2.2 in [21] for IPv6 addressing with IPv6CP.
16
17
18 7.2 IP Services Selection
19
20 The PDSN shall follow the procedures specified in section 3.2.2 and 4.2.2 of [21].
21
22
The mobile station shall follow the procedures specified in section 3.4 of [21].
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
51
52
53
54
55
56
57
58
59
60
79 7 IP Services Authorization and Selection

8 IP Reachability Service 1
2
3
IP Reachability Service is the capability to update a DNS server in the home network with the
4
current authorized MS IP address. When the MS desires to be reached by a DNS hostname, 5
the Home RADIUS server (in the case of Simple IP or MIP) or the HA (in the case of MIP 6
only) may send a DNS Update [RFC 2136] to a DNS server to add an A Resource Record for 7
IPv4 and AAAA or A6 Resource Record for IPv6 [RFC 1886] and [RFC 287424F ]. 8
9
The Update section of the DNS Update message contains the following values in „Host
10
address‟ Resource Type Resource Record:
11
 Resource Name = username.realm25F 12

13
 Resource Class = Internet address class 14
15
 IP Address = newly assigned IP address 16
17
The TTL (Time To Live) of the Update section in the DNS Update message should be zero so 18
that all queries for the address are resolved using the up to date authoritative server for the 19
user. This is because after the MS is assigned a different address, if the TTL were non-zero, 20
the cache entry of the querying endpoint would no longer be valid, and, in fact, the address 21
may have been given to a different MS. 22
23
The security between the DNS Server and Home RADIUS server or the HA is outside the 24
scope of this document. 25
26
The method used by the Home RADIUS server and/or HA to determine the IP address of the
27
DNS server is outside the scope of this document.
28
IP Reachability Service as specified in this document shall not be provided for users with 29
single NAI and Multiple static Home Addresses. 30

31
32
8.1 Simple IPv4 Operation 33

34
35
The Home RADIUS server shall request that the DNS server add an A Resource Record for
36
the user under the following conditions:
37
 the Home RADIUS server receives a RADIUS Accounting-Request (Start) record 38

39
containing the Beginning-Session VSA and the IP-Technology VSA indicates
40
Simple IP,
41
 the Home RADIUS server is configured to send DNS Update messages, and 42
43
 the user profile indicates that IP Reachability Service is enabled for the user. 44
45
The Home RADIUS server shall send a request to the DNS server to delete the A Resource 46
Record for a user under the following conditions: 47
48
 the Home RADIUS server receives a RADIUS Accounting-Request (Stop) record
49
from the PDSN currently serving the user for a session, and the Session-Continue 50
VSA is either absent or is included but the value is set to FALSE and the IP- 51
Technology VSA indicates Simple IP; 52
 the Home RADIUS server has not previously received an Accounting-Request(start) 53

54
form another PDSN for the same packet data session (inter PDSN handoff with
55
MIP); and
56
 the user profile indicates that IP Reachability Service is enabled for the user. 57
58
59
60
1
2
3
4
8.2 MIP4 Operation
5
The DNS server may be updated by either the Home RADIUS server or the HA.
6
7
8 8.2.1 DNS Update by the Home RADIUS Server
9
10 The Home RADIUS server shall request that the DNS server adds an A Resource Record for
11 the user under the following conditions:
12
13  the Home RADIUS server receives a RADIUS Accounting-Request (Start) record
14 containing the Beginning Session VSA and the IP-Technology VSA indicates MIP,
15 and
16
17  the Home RADIUS server did not receive a RADIUS Access-Request message from
18 the HA with the DNS-Update-Capability VSA, and
19
20
 the Home RADIUS server is configured to do DNS update, and
21
 the user profile indicates that IP Reachability Service is enabled for the user.
22
23 After performing DNS update for the user, the Home RADIUS server shall cache the User
24 Name, NAS IP Address, and Framed IP address as received in the Accounting-Request (Start)
25
record for the user.
26
27 The Home RADIUS server shall send a request to the DNS server to delete the A Resource
28 Record for a user under the following conditions:
29
30  the Home RADIUS server receives a RADIUS Accounting-Request (Stop) record
31 containing the IP-Technology VSA that indicates MIP, and does not contain the
32 Session-Continue VSA or the Session-Continue VSA is included but the value is set
33 to FALSE, and
34
35  the Home RADIUS server has previously sent request(s) to the DNS server to
36 add/update an A Resource Record for the corresponding user,
37
38
 The Home RADIUS server has not previously received an Accounting-Request(start)
39
form another PDSN for the same packet data session (inter PDSN handoff with
40
MIP); and
41
 the user profile indicates that IP Reachability Service is enabled for the user.
42
43
44 8.2.2 DNS Update by the HA
45
46 An HA that supports DNS update capability shall send a RADIUS Access-Request message
47 to the Home RADIUS server at each initial MIP RRQ message it receives, and shall include
48 the DNS-Update-Capability VSA. The home RADIUS server determines based on its
49 configuration and user profile if the HA shall perform DNS update operations. The Home
50
RADIUS server shall include the DNS-Update-Required VSA in the RADIUS Access-Accept
51
message if the DNS-Update-Capability VSA was included in the RADIUS Access-Request
52
message and it allows the HA to perform DNS update for the user.
53
54 The HA shall request the DNS server to add an A Resource Record for a user under the
55 following conditions:
56
57  the HA is capable of DNS update and it is configured to do so, and
58
59  the HA is authorized by the Home RADIUS server to perform DNS update, and
60
 the MIP Registration process is successful.
81 8 IP Reachability Service
The HA shall send a request to the DNS server to delete the A Resource Record for a user 1
under the following conditions: 2
3
 the HA has previously sent request(s) to the DNS server to add/update an A 4
Resource Record for the corresponding user, and 5
6
 the mobility binding for the user is set to expire due to the following reasons:
7
 the HA receives a MIP RRQ with lifetime set to 0 from the user, or 8
9
 the MIP registration lifetime for the user has expired, or 10
11
 the mobility binding for the user has been revoked by the FA or the HA, or 12
13
 administrative reset.
14
15
16
8.3 Simple IPv6 Operation 17
18
For IPv6 IRS support, the Home RADIUS server shall use the Resource Records defined in 19
[RFC 1886] as updated by [RFC 2874] and [RFC 3152]. The operation of IRS service for 20
IPv6 users is identical to the procedures described for Simple IPv4 in Section 7.1. 21
If the MS uses both IPv4 and IPv6, the Home RADIUS server shall request that the DNS 22
server create or delete Resource Records for both IPv4 and IPv6. 23
24
25
8.4 MobileIPv6 Operation 26

27
The DNS server may be updated by the Home RADIUS server. 28

29
The Home RADIUS server shall request that the DNS server adds a AAAA resource Record 30
for the user under the following conditions 31
32
1. It is configured to send DNS updates, and 33
34
2. The user/MS is authorized for IP Reachability Service through the user profile, and
35
3. The Home RADIUS server receives a RADIUS Accounting-Request (Start) message 36
from the HA containing the Beginning Session VSA, the HoA and the User Name (NAI). 37
38
The Home RADIUS server shall request that the DNS server deletes a AAAA resource 39
Record for the user under the following conditions 40
41
1. It is configured to send DNS updates, and 42
43
2. The user/MS is authorized for IP Reachability Service through the user profile, and 44
45
3. If an HoA associated with an MS is in the DNS entry and the RADIUS server receives a
46
RADIUS Accounting-Request (Stop) message from the HA indicating BCE for the HoA
47
is removed from the HA, i.e., Session continue VSA is absent or present with a value set
48
to FALSE, then the Home RADIUS server shall send a DNS Update to the DNS server to
49
delete the record for that HoA. 50
51
52
53
54
55
56
57
58
59
60
1
2
3
4
5
9 MS-PDSN Version Capability Indication
6
7
The MS and PDSN shall support the 3GPP2 vendor specific Version/Capability packet
8 defined in the PPP Vendor specific packet [RFC 2153]. Version/Capability packets shall be
9 sent over the main service connection. The Version/Capability packets shall be sent as LCP
10 packets with PPP Protocol ID set to C021(hex).
11
12
The format of the Version/Capability packet is shown in Figure 18 .
13
0 7 8 15 16 23 24 31
14
15 Code Identifier Length
16
Magic Number
17
18 OUI Kind
19
20
Version List of Capabilities
21 Figure 18 Version/Capability Packet Format
22
23
Code 0 (As defined in [RFC 2153])
24
25 Identifier The Identifier field shall be changed for each vendor specific
26 packet sent. It is used to match requests with responses.
27 Length 16 (octets)
28
Magic Number The Magic-Number field is four octets and aids in detecting links
29
that are in the looped-back condition. Until the Magic-Number
30
Configuration Option has been successfully negotiated, the
31
Magic-Number shall be transmitted as zero. See the Magic-
32 Number Configuration Option in [RFC 1661] for further
33 explanation.
34
OUI 0xCF0002
35
36 Kind 2 for Version/Capability Indication packet
37 3 for Version/Capability Reply packet
38 Version 0 for Version D
39 1 for Version E
40 2-255 reserved for later versions
41
List of Capabilities Table 8 for List of MS capabilities
42 Table 9 List of PDSN capabilities
43
44
45 If the Kind value is 2, the Version/Capability Indication packet shall include the Version and
46 List of Capabilities. If the Kind value is 3, the Version/Capability Reply packet shall not
47
include the Version and List of Capabilities.
48
49 The Version value 0 indicates that the MS (or PDSN) supports all the MS requirements (or
50 PDSN requirements) mandated by X.S0011-D.
51
52 The Version value 1 indicates that the MS (or PDSN) supports all the MS requirements (or
53 PDSN requirements mandated by X.S0011-E.
54
55 The List of MS Capabilities is coded as a bit mask defined in Table 8. C0 is the most-
56 significant bit in the list. Each bit in the list indicates whether an MS capability specified in
57 this document is supported.
58
59
60
83 9 MS-PDSN Version Capability Indication

Table 8 List of MS Capabilities 1

2
Bit MS Capability Description 3
C0 Simple IPv4 Set to 1 if MS supports Simple IPv4. 4

5
C1 MIP4 Set to 1 if MS supports MIP4.
6
C2 Simple IPv6 Set to 1 if MS supports Simple IPv6. 7
8
C3 MIP6 Set to 1 if MS supports MIP6.
9
C4 Max PPP Set to 1 if MS supports the 3GPP2 vendor specific Max 10
inactivity timer PPP Inactivity Timer packet.
11
C5 NCP inactivity Set to 1 if MS supports the NCP Inactivity Timer 12
timer specified in the 3GPP2 vendor specific Max PPP 13
Inactivity Timer packet. If this bit is set, C4 shall also be 14
set to 1. 15
C6 PPP Additional Set to 1 if the MS supports the PPP Additional 16
Authentication Authentication. 17
18
C7 Network Initiated Set to 1 if MS supports network initiated QoS
19
QoS
20
C8 to C23 Reserved 21
22
23
The List of PDSN Capabilities is coded as a bit mask defined in Table 9. C0 is the most- 24
significant bit in the list. Each bit in the list indicates whether a PDSN capability specified in 25
this document is supported. 26
27
Table 9 List of PDSN Capabilities 28
29
Bit PDSN Capability Description
30
C0 Auxiliary SI for Set to 1 if PDSN supports the auxiliary service 31
SO 60 connection for SO 60. 32
33
C1 Auxiliary SI for Set to 1 if PDSN supports the auxiliary service
SO 61 connection for SO 61. 34
35
C2 Auxiliary SI for Set to 1 if PDSN supports the auxiliary service 36
SO 66 connection for SO 66.
37
C3 HA Resource Set to 1 if PDSN and HA resource management via 38
Management MIP4 revocation is enabled. 39
40
C4 Auxiliary Service Set to 1 if PDSN supports the auxiliary service
Connection for connection for SO64 41
SO64 42
43
C5 Auxiliary Service Set to 1 if PDSN supports the auxiliary service
44
Connection for connection for SO67
45
SO67
46
C6 Reserved (for MIP4 enhancement use) 47
C7 MIP6-HA-Local- Set to 1 if PDSN supports the MIP6-HA-Local- 48

49
Assignment Assignment
50
C8 PPP Additional Set to 1 if the PDSN supports the PPP Additional 51
Authentication Authentication. 52
53
C9 Network Set to 1 if PDSN supports network initiated QoS
54
Initiated QoS
55
C10 to C23 Reserved 56
57
58
59
60
9 MS-PDSN Version Capability Indication 84

1
2
3
4
9.1 PDSN Requirements
5
If the PDSN receives the Version/Capability Indication packet from the MS, the PDSN shall
6
7
respond with the Version/Capability Reply packet.
8
The PDSN shall not send the Version/Capability Indication packet unless it has first received
9
the Version/Capability Indication packet from the MS 25.
10
11 The PDSN should resend the Version/Capability Indication packet a configurable number of
12 times if no Version/Capability Reply packet from the MS is received.
13
14 If the PDSN previously received the Version/Capability Indication packet from the MS, the
15 PDSN may send the Version/Capability Indication packet to the MS anytime after the PPP
16 session is established26.
17
18
19
9.2 MS Requirements
20
21
During the LCP negotiation, the MS shall send the Version/Capability Indication packet. The
22
MS should resend the Version/Capability Indication packet a configurable number of times if
23
no Version/Capability Reply packet from the PDSN is received. If the MS receives the Code-
24
Reject28F, the MS shall stop resending the Version/Capability Indication packet.
25
26 If the MS receives the Version/Capability Indication packet from the PDSN, the MS shall
27 respond with the Version/Capability Reply packet.
28
29 The MS may send the Version/Capability Indication packet to the PDSN anytime after the
30 PPP session is established.
31
32 If the MS supports the NCP Inactivity Timer defined in section 3.2.1.10, it shall send the
33 Version/Capability Indication packet with the version field and C4 and C5 set to 1.
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56 25
If the PDSN did not receive the Version/Capability Indication packet from the MS, most likely it is an
57
earlier version MS that does not support the version/capability indication. Therefore, it is wasteful for
58
the PDSN to send the Version/Capability Indication packet to the MS.
59 26
This allows the PDSN to indicate network capabilities that are not available to the PDSN during the
60 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).
85 9 MS-PDSN Version Capability Indication

10 3GPP2 Vendor Specific Reject Packet 2

3
The MS and PDSN shall support the 3GPP2 vendor specific Reject packet defined in 4
5
accordance with the format of the PPP Vendor specific packet [RFC 2153]. The Reject packet
6
shall be sent over the main service connection. The Reject packet shall be sent as LCP packet
7
with PPP Protocol ID set to C021(hex).
8
If the MS (or PDSN) receives an unknown 3GPP2 vendor specific packet, it shall send the 9
3GPP2 vendor specific Reject packet containing the rejected 3GPP2 vendor specific packet. 10
11
If the MS (or PDSN) receives the 3GPP2 vendor specific Reject packet, it shall consider the 12
3GPP2 vender specific packet contained in the Reject packet is not supported by the PDSN 13
(or MS). 14
15
The format of the Reject packet is shown in Figure 19 . 16
17
0 7 8 15 16 23 24 31 18
19
Code Identifier Length
20
Magic Number 21
22
OUI Kind
23
Value 24
Figure 19 Reject Packet Format 25

26
27
Code 0 (As defined in [RFC 2153]) 28
29
Identifier The Identifier field shall be changed for each vendor specific
packet sent. It is used to match requests with responses. 30
31
Length >= 12 (octets) 32
Magic Number The Magic-Number field is four octets and aids in detecting links 33
that are in the looped-back condition. Until the Magic-Number 34

Configuration Option has been successfully negotiated, the 35
Magic-Number shall be transmitted as zero. See the Magic- 36
Number Configuration Option in [RFC 1661] for further 37
explanation. 38
39
OUI 0xCF0002
40
Kind 0 41
Value The Value field contains the rejected PPP 3GPP2 Vendor 42
Specific packet. 43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
10 3GPP2 Vendor Specific Reject Packet 86

1
2
3
4 11 Hot-Lining
5
6 The Hot-Lining capability is optional. In this document, Hot-Lining capability applies only to
7 Simple IPv4, Simple IPv6 and MIP4 services.
8
9 If the PDSN and/or the HA supports Hot-Lining they shall follow the specification as
10 described in this section.
11
12
The Hot-Lining feature described in this document shall not apply to PrePaid sessions.
13
Hot-Lining provides a wireless operator with the capability to efficiently address issues with
14
users that would otherwise be unauthorized to access packet data services. When a problem
15
occurs such that a user may no longer be authorized to use the packet data service, a wireless
16
operator using this feature may Hot-Line the user, and upon the successful resolution of the
17
18
problem, return the user‟s packet data services to normal. When a user is Hot-Lined, their
19
packet data service is redirected to a Hot-Line Application which may notify (if feasible) the
20
user of the reason(s) that they have been Hot-Lined and offers them a means to address the
21
reasons for Hot-Lining, meanwhile blocking access to normal packet data services. Example
22 reasons for Hot-Lining a user are:
23
 users who have billing issues such as expiration of a credit card,
24
25  users who have been suspected of fraudulent use.
26
27 As a result, Hot-Lining performs the following four fundamental activities:
28
29
30
 Blocking normal packet data usage.
31
 Attempting to notify users/MS (if feasible) that packet data usage is blocked.
32
33  Re-directing user/MS traffic to rectify issues causing blockage.
34
35  Restoring normal operations when the User has rectified issues that triggered the
36 Hot-Lining of their service. Alternatively, terminating service if the User failed to
37 address the issues that triggered the Hot-Lining of their service.
38
39
40 11.1 Hot-Lining Capabilities
41
42 The following section describes the general Hot-Line capabilities supported for this release:
43
44
45
1. Hot-Lining is supported for Simple IPv4, Simple IPv4 and Mobile-IP operations. Support
46
of Hot-Lining is therefore required in the PDSN and the HA.
47
2. A user can be Hot-Lined at the start of their packet data session or mid-session as
48
described below:
49
50
Active-Session The user starts a packet data session. In the middle of the session it is Hot-Lined and
51
Hot-Lining: after the account is reconciled by some manner, the Hot-Lining status of the session is
52
removed. The Hot-Lining is done with RADIUS Change of Authorization (COA)
53
message.
54
55 New-Session The user’s session is Hot-Lined at the time of packet data session establishment. In
56 Hot-Lining: this scenario the RADIUS Access-Accept message is used to Hot-Line the session.
57
58
59
3. Similarly, a Hot-Lined packet data session can be returned back to normal, mid-session
60
or at the start of the session.
87 11 Hot-Lining
4. There are two styles that can be used by the Home RADIUS server to indicate that a user 1
is to be Hot-Lined: 2
3
Profile-based Hot- The Home RADIUS server sends a Hot-Line profile identifier in the RADIUS message. 4
Lining The Hot-Line profile identifier sent using RADIUS Filter-Id(11) attribute(s) selects a set 5
of rules that are pre-provisioned in the Hot-Line Device that cause that user’s packet 6
data session to be redirected and/or blocked. 7
Rule-based Hot- The Home RADIUS server sends the actual redirection-rules (HTTP or IP) and filter- 8
Lining rules in the RADIUS messages that cause the user’s packet data session to be 9
redirected and/or blocked. 10
11
12
5. In order to properly account for the Hot-Lining state of the user, the user‟s Hot-Line state 13
should be recorded in the accounting stream. 14

15
The following capabilities are not covered by this document but are described in so far that 16
they are needed to implement a complete Hot-Lining solution: 17
18
6. The trigger(s) that cause an operator to Hot-Line a user is outside the scope of this 19
document. These triggers could come from a number of sources such as a billing system, 20
fraud detection system etc. 21
22
7. The means to notify the Home RADIUS server that a user is to be Hot-Lined is outside 23
the scope of this document. 24
25
8. The means by which the user is notified that they have been Hot-Lined is not within the
26
scope of this document. Typically, the user will be notified that they have been Hot-Lined
27
via their browser. Other methods such as SMS messaging are possible.
28
9. The means by which the user interacts with the system to correct the problems that 29
30
caused them to be Hot-Lined are not within the scope of this document.
31
10. The means by which the system notifies the Home RADIUS server that a user‟s packet 32
data session is to be returned to normal operation is not within the scope of this document. 33
34
11. The details of what happens when the PDSN/HA performs Profile-based Hot-Lining is 35
outside the scope of this document. It is assumed that the user‟s traffic is blocked and that 36
the user gets notified. 37
38
When the packet data session is Hot-Lined some IP flows will be blocked and some IP flows 39
will be redirected. The intent of the redirection is not to continue the normal operation of the 40
flow but rather to provide information (e.g.the user‟s IP address when IP redirection is used) 41
to the Hot-Line application so that the Hot-Line application can determine how to notify the 42
user of their Hot-Lined state. 43
44
45
11.2 Hot-Lining Architecture 46

47
Hot-Lining involves the following packet data network entities: 48

49
 HA 50
51
 PDSN 52
53
 Home RADIUS server
54
 Visited RADIUS server 55

56
The HA and the PDSN are devices that implement the Hot-Lining rules requested by the 57
Home RADIUS server. In this document the HA or the PDSN that is currently applying the 58
59
60
11 Hot-Lining 88
1
2
3 Hot-Line rules for a User is called the Hot-Lining Device. The role of the Visited RADIUS
4 server with respect to Hot-Lining is to act as proxy and as such will not be discussed further.
5
6
7
8
9 AAA-Hot-Line
10
signaling
(not in scope)
11
RADIUS HAAA
12
13
14
15 RADIUS
16 Hot-lining
17 Application
18 PDSN/FA HA (not in scope)
19 Hot-line Hot-line
device Packet device Packet
20
data data
21
Packet
22
data
23
24
25 Mobile-Hot-lining Application interaction: e.g., SMS, Web
26 (not in scope)
27
28
29
30
31 Figure 20 Hot-Lining architecture
32
33
Hot-Lining also involves the Hot-Line Application. The Hot-Line Application is a functional
34
35
entity that performs the following roles:
36
37  Determines when the user should be Hot-Lined.
38
39  Initiates the Hot-Lining signaling with the Home RADIUS server.
40
41
 Redirects Hot-Lined flows to the Hot-Line Application.
42
 Initiates notification of the Hot-Line status to the MS. This could be done via a
43
delivery of an HTML page to the subscriber‟s browser or via some other means such
44
as SMS messaging.
45
46  Provides a mechanism for the user to rectify the issue that triggered Hot-Lining.
47
48  Returns the user back to normal operating mode upon successful resolution of the
49 problem.
50
51  Terminates the user's packet data session upon unsuccessful resolution of the
52 problem.
53
54
The implementation of the Hot-Line Application is not within the scope of this document. The
55
interface between the Hot-Line Application and the various entities is outside the scope of this
56 document.
57
58
59
60
89 11 Hot-Lining
11.3 Operations 1
2
Hot-Lining of a user‟s packet data service starts when the Hot-Line Application determines 3
that the user‟s service is to be Hot-Lined. This determination is entirely deployment specific 4
and can be a result of many factors. Details are not within the scope of this document. 5
6
7
To initiate Hot-Lining of the user, the Hot-Line Application will notify the Home RADIUS 8
server that the user is to be Hot-Lined. The method of notification is outside the scope of this 9
document. Upon receiving the notification from the Hot-Line Application, the Home 10
RADIUS server records the Hot-Lining state against the user record. 11
12
13
The Home RADIUS server will determine if the user has an ongoing packet data session. If
14
the user has an ongoing packet data session, the Home RADIUS server initiates the Active-
15
Session Hot-Lining procedure. If the user has no ongoing packet data session, the Home
16
RADIUS server initiates the New-Session Hot-Lining procedure.
17
18
Hot-Lining requires the Hot-Lining device to support Profile-based Hot-Lining and/or Rule- 19
based Hot-Lining. When a Hot-Line device cannot honor a request for Active Session Hot- 20
Lining, the operator may utilize a Disconnect Message (if supported) to terminate the user‟s 21
session or depend on the RADIUS Session-Timeout attribute that may have been previously 22
sent to the Hot-Line device in a RADIUS Access-Accept or COA message for session 23
termination. To participate in Hot-Lining, an access device (PDSN or HA) shall advertise its 24
Hot-Lining capabilities using the Hot-Line Capability VSA sent in a RADIUS Access- 25
26
Request message. The Home RADIUS server uses the contents of the Hot-Line Capability
27
VSA and other local policies to determine which access device will be the Hot-Lining Device
for the session. If the Home RADIUS server doesn‟t receive the Hot-Line Capability VSA, 28
29
the Home RADIUS server shall consider the PDSN or the HA to not have the Hot-Lining
30
capability.
31
32
RADIUS Access-Accept messages or RADIUS Change of Authorization (COA) messages 33
that signal hot-lining shall contain either: 34
35
36
 A RADIUS Filter-Id attribute; or
37
 Any combination of zero or more of HTTP Redirection Rule VSAs and/or IP 38

39
Redirection Rule VSAs.
40
Furthermore, RADIUS messages that contain HTTP Redirection Rule VSA and/or IP 41
Redirection Rule VSA may also contain Filter Rule VSAs. 42

43
44
RADIUS Access-Accept or COA messages that contain any RADIUS Filter-Id(11) attributes, 45
shall not contain any of the HTTP Redirection Rule VSAs or IP Redirection Rule VSAs or 46
Filter Rule VSA. 47
48
RADIUS Access-Accept messages and RADIUS COA messages may contain the Hot-Line 49
50
Accounting Indication VSA. The Hot-Line Accounting Indication VSA is opaque to the Hot-
51
Line Device and if received shall be included in all accounting packets (start, interim, stop)
52
associated with the Hot-lined session as triggered by the Access-Accept or an acceptable
53
COA message.
54
55
The Hot-line session continues until the HAAA turns hot-lining off or the packet data session 56
is terminated. 57
58
59
60
11 Hot-Lining 90
1
2
3 The Hot-Line Accounting Indication is provided to mark the accounting records that are
4 associated with a hot-lined session. Therefore, the home RADIUS server should only include
5
the Hot-Line Accounting Indication in Access-Accepts or COA messages that initiate hot-
6
lining of the session.
7
8
9 11.3.1 New-Session Hot-Lining Procedure
10
11 The New Session Hot-Lining Procedure is invoked when a user is initiating a packet data
12 session and is marked as Hot-Lined in the Home RADIUS server, as shown in the following
13 call flow.
14
15
16
17
18
19 Hot-line Hot-line
20
HAAA
device Application
21
22
23 User not Hot-line user a
24 online (not in scope)
25
b
26 User starting
Store in user's
27 packet data
profile
28 service
29
Access-Request+Hot-line
30 c
cap.
31
32
Access-Accept+hot-lining d
33
34
35 Acct+Hot-lining indication e
36
37
38 Hot-lined packet data flow f
39
40
41
42
43
44 Figure 21 New Session Hot-Lining Call Flow
45
46
47
a. The Home RADIUS server receives a signal (outside the scope of this document) from
48 the Hot-Lining application to Hot-Line a user‟s packet data service.
49
b. The Home RADIUS server records this information in its user profile store. If the user is
50
51
not active, the Home RADIUS server waits until the user initiates the packet data service,
52
which will result in the user being Hot-Lined immediately. Meanwhile, it is possible for
53
the Hot-Line Application to change the user‟s Hot-Line status back to „normal‟ in which
54
case the Home RADIUS server will update the user profile store accordingly.
55
c. When the user who is to be Hot-Lined initiates a packet data session, a RADIUS Access-
56
Request is received by the Home RADIUS server that indicates the Hot-Line Capability
57
of the Hot Line device.
58
59
d. In the Home RADIUS server, the Local Policies and received Hot-Line Capability will be
60
used to determine which device (PDSN or HA) will receive Hot-Lining VSAs. The Home
91 11 Hot-Lining
RADIUS server shall signal the Hot-Lining Device of the user‟s Hot-Line status by 1
sending Hot-Lining VSA(s) in the RADIUS Access Accept message. The Home 2
RADIUS server may include the Hot-Line Accounting Indication VSA in the RADIUS 3
Access-Accept message. 4
5
e. If the Hot-Lining Device is capable of generating RADIUS Accounting records, then the 6
Hot-Lining Device should generate a RADIUS Accounting-Request (Start) packet and 7
shall include the Hot-Line Accounting Indication VSA if received in the RADIUS 8
Access-Accept message. If the Hot-Lining Device is unable to honor the Hot-Lining 9
VSA(s) received in the RADIUS Access-Accept packet, it shall treat the RADIUS 10
Access-Accept packet as a RADIUS Access-Reject packet and terminate session setup. 11
12
f. Once the Hot-Line session starts, traffic will be blocked and/or directed to the Hot-Line 13
Application. 14
15
16
11.3.2 Active Session Hot-Lining Procedure
17
18
The Active Session Hot-Lining Procedure is invoked when the Hot-Lining state of a user who
19
is currently engaged in a packet-data-session is changed.
20
Upon receiving the Hot-Line signal the Hot-Lining Device will perform the procedures 21
described in the following figure: 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
51
52
53
54
55
56
57
58
59
60
11 Hot-Lining 92
1
2
3
4
5 Hot-line Hot-line
HAAA
6
device Application
7
8 User is in a packet data Some events require that
9 session the user's session be hot- a
10 lined
11
User active in a
12
packet data Hot-line user
13 (not in scope) b
session
14 Store in user's c
15 profile
COA+Hot-line indication
16 d
17
COA Ack
18 e
19
Acct stop
20 f
21
Acct start + Hot-lining
22
indication g
23
24
Hot-lined packet data flow h
25
26 Hot-line issues reconciled,
27 users needs to return to i
28 'normal'
29
30 User back to 'normal' j
31
(not in scope)
32 Store in user's k
33 COA+'normal' profile
l
34
COA Ack
35 m
Acct stop: hot-line
36
User flow returns back to n
37 Acct start + 'normal' normal o
38
39
p
40
41
42
43
Figure 22 Active Session Hot-Lining Procedure
44
45
46 a. The user is currently engaged in a packet data session, which is not Hot-Lined.
47
48
b. The Home RADIUS server starts the Active Session Hot-Lining procedure when it
49
receives a Hot-Line signal from the Hot-Line Application for the user that has already
50
started a packet data session.
51
c. The Home RADIUS server stores the Hot-Line state of the user in the user‟s profile.
52
53 d. In the Home RADIUS server, the Local Policies and received Hot-Line Capability will be
54 used to determine which device (PDSN or HA) will receive Hot-Lining VSAs. The Home
55
RADIUS server will signal the Hot-Lining Device of the user‟s Hot-Line status by
56
sending Hot-Lining VSA(s) or RADIUS Filter-Id(11) attribute in the RADIUS Change
57
Of Authorization (COA) message. The Home RADIUS server may include the Hot-Line
58
Accounting Indication VSA in the RADIUS Change Of Authorization (COA) message.
59
60
93 11 Hot-Lining
e. e) If the Hot-Lining Device can honor the request then it will respond with a COA 1
ACK packet. If the Hot-Lining Device cannot honor the Hot-Lining request, then the 2
Hot-Lining Device shall respond with a COA NAK message. Based on local policy, upon 3
receiving a COA NAK packet the Home RADIUS server may either retry sending the 4
Hot-Lining signal to the Hot-Lining Device, or may send a RADIUS Disconnect-Request 5
message to the Hot-Lining Device or to another device to instruct it to drop the session. 6
7
f. A Hot-Lining Device capable of generating accounting packets shall generate a RADIUS 8
Accounting-Request (Stop) message to close the current accounting session. The Release 9
Indicator (F13) shall be set to 14 (Hot-Line Status Changed). 10
11
g. A Hot Lining Device capable of generating accounting packets shall generate a RADIUS 12
Accounting-Request (Start) message including the Hot-Line Accounting Indication VSA 13
received in the COA packet. 14
15
h. The Hot Lining Device then immediately invokes the Hot-Lining rules as specified in the
16
COA packet. 17
18
i. Once the user has been Hot-Lined the Hot-Line Application might notify the user of their
19
Hot-Lined state and will interact with the user to rectify the issue that caused the Hot-
20
Lining. If the Hot-Lining Application is not satisfied with the results, it may maintain the
21
Hot-Lining status of the user, or it may terminate the users session. If the problem has
22
been rectified the Hot-Lining Application will return the user‟s session back to a „normal‟
23
mode. 24
j. The Hot-Line Application will indicate the back to „normal‟ status to the Home RADIUS 25
26
server. Note the interaction of the Hot-Line Application with the user is beyond the scope
27
of this document.
28
k. The Home RADIUS server will update the user‟s profile. 29

30
l. If the session is active, the Home RADIUS server will send a COA packet to the Hot- 31
Lining Device. In this case, the signal shall be sent to the device that is currently 32
applying the Hot-Line rule. Note that this may not be the same device that initially 33
implemented the Hot-Line state for the session (a handoff may have happened). If the 34
received notification, of step i, indicated session termination from the Hot-Line 35
Application, the Home RADIUS server shall record the termination status of the user in 36
the user‟s policy store and if the session is still active, it shall send a RADIUS 37
38
Disconnect-Request message to an appropriate device. Note that this device may not be
39
the Hot-Lining Device. Upon receiving the RADIUS Disconnect-Message, the device
40
shall promptly terminate the session. If the device is capable of generating accounting
41
messages, it shall generate a RADIUS Accounting-Request (Stop) message with Release
42
Indicator (F13) set to 6 (Termination due to resource management).
43
m. Upon receiving the signal to return the user back to „normal‟ mode, if the Hot-Lining 44
45
Device is unable to honor the request it shall respond with a COA NAK packet. Upon
46
receiving a COA NAK, the Home RADIUS server may send a RADIUS Disconnect-
Request message to terminate the user‟s session. The RADIUS Disconnect-Request 47
48
message may be sent to the Hot-Lining Device or to another device that is capable of
49
terminating the session. On the other hand if the Hot-Lining Device is able to return the
50
user back to normal state, it shall send a COA ACK packet.
51
52
n. If the Hot-Lining Device is capable of generating accounting messages it shall generate a
53
RADIUS Accounting-Request (Stop) message indicating that the Hot-Lining session has
54
been terminated and include the Hot-Line-Accounting Indication VSA if received in the
55
COA message. The Release Indicator (F13) shall be set to 14 (Hot-Line Status Changed).
56
57
58
59
60
11 Hot-Lining 94
1
2
3 o. The RADIUS Accounting-Request (Stop) message shall be followed by a RADIUS
4 Accounting-Request (Start) message indicating the start of the „normal‟ packet data
5
session.
6
7 p. The user‟s session is now returned back to normal.
8
9
10 11.3.3 Limiting the Hot-Lining Duration
11
12
Hot-Lined sessions can still utilize expensive network resources and therefore an operator
13 may wish to limit the period over which a session is to be Hot-Lined. There are two methods
14 that are available to the operator. First, a (Hot-Lined or not Hot-Lined) session can be
15 terminated immediately by sending a Disconnect Message. The Disconnect Message is not
16 required to target the Hot-Lining Device.
17
18
Second, the Home RADIUS server should be configured to include the Session-Timeout (27)
19
attribute when it sends the Hot-Lining indication to the Hot-Lining Device. The Session-
20 Timeout will contain the length of time in seconds that the user would be allowed to remain in
21 the session. If Session-Timeout expires, the packet data session shall be terminated.
22
23
24 11.4 Hot-Lining Requirements
25
26
27 11.4.1 Requirements for Hot-Line Capable PDSN and HA
28
29 This section describes the common requirements of a Hot-Lining Device (PDSN and HA).
30 Requirements that apply specifically to a PDSN or HA are under section 10.4.1.1 and section
31 10.4.1.2 respectively.
32
33
1. Hot-Lining shall not interfere with the establishment of a packet data session. The Hot-
34
line Device shall allow completion of the packet data session and shall allow MIP
35
signaling re-registration. The Hot-Line Device shall apply the Hot-Lining rules to DNS
36
37
traffic and DHCP traffic through relay agent functionality.
38
39 2. A Hot-Lining capable device shall support both New-Session Hot-Lining and Active-
40 Session Hot-Lining.
41
42
43
3. A Hot-lining capable device shall include the Hot-line Capability VSA in the RADIUS
44
Access-Request message indicating its ability to support Hot-Ling.
45
46 4. A Hot-Line Device shall treat a RADIUS Access-Accept message as Access-Reject
47 message or shall respond with a COA NAK message with Error-Cause (101) indicating
48 “Administratively Prohibited”(501) when it receives a RADIUS Access-Accept message
49
or COA message that contains:
50
51
52  A RADIUS Filter-Id(11) attribute that it cannot decode; or
53
54
 A RADIUS Filter-Id(11) attribute and either Filter-Rule VSA(s) or HTTP/IP
55
Redirection-Rule VSA(s); or
56
 Contains Filter-Rule (VSA)s or HTTP/IP Redirection-Rule (VSA)s that it can not
57
decode.
58
59 5. Upon receiving a COA message containing RADIUS Filter-Id(11) attribute(s), the Hot-
60 Lining Device shall locate the Hot-Line rules that match the profile(s) specified by the
95 11 Hot-Lining
RADIUS Filter-Id(11) attribute(s). If the Hot-Lining Device is successful, it shall reply 1

to the HAAA with a COA ACK message. The Hot-Lining Device shall remove any 2
previously specified RADIUS Filter-Id(11) attribute(s), HTTP Redirection Rules, IP 3
Redirection Rules, and Filter Rules and begin applying the rules associated with the 4
newly received RADIUS Filter-Id(11) attribute(s). The Hot-Lining Device shall send 5
accounting messages as described in the Hot-Lining section of [Chapter 5]. If the Hot- 6
Lining Device is not successful at matching the newly received RADIUS Filter-Id(11) 7
attribute(s) with corresponding rules, it shall send a COA NAK with Error-Cause (101) 8
indicating "Administratively Prohibited"(501). In this case, the Hot-Line state and all 9
existing rules shall remain unchanged 10

11
6. If the Hot-Lining Device receives a RADIUS Access Accept message containing HTTP 12
Redirection-Rule VSAs, IP Redirection-Rule VSAs, and/or Filter Rule VSAs that are 13
well-formed (that can be parsed), then the Hot-Lining Device shall apply the HTTP 14
Redirection rule(s) if any first, followed by the IP Redirection rule(s) if any ; Filter-Rule 15
VSA(s) if any are processed last. Within each type of rule, the rules are processed in the 16
order that they appear in the packet. In applying the rules (Filter and HTTP/IP 17
Redirection rules) the Hot-Lining Device should validate the rules against any security 18
19
policies. If any security policies have been violated, the Hot-Lining Device shall tear
down the user‟ s packet data session. 20
21
7. Upon receiving a COA message with well-formed HTTP Redirection Rule, and/or IP 22
Redirection-Rule, and/or Filter-Rule VSAs, the Hot-Lining Device should validate any 23
locally provisioned filtering that effect local system wide policies. If any of the rules 24
violate local policies, or the Hot-Lining Device is not able to accept the COA message, it 25
shall send a COA NAK message with Error-Cause (101) indicating “Administratively 26
Prohibited” (50). In this case, the Hot-Line state and all existing rules shall remain 27
28
unchanged. Otherwise, when no rules violate local security policy, the Hot-Lining
29
Device shall do the following:
30
 If the Hot-Lining Device is currently applying rules associated with a previously 31
received RADIUS Filter-Id(11) attribute(s), it stops applying the rules associated 32

33
with the previously received RADIUS Filter-Id(11) attributes and begins applying
34
the newly received HTTP Redirection Rules, and/or IP Redirection Rules, and/or
35
Filter Rules. The Hot-Lining Device shall respond to the HAAA with a COA ACK
36
and begin sending accounting messages as described in the Hot-Lining section of
37
[Chapter 5].
38
 If the Hot-Lining Device is currently applying rules associated with previously 39

40
received HTTP Redirection Rules and/or IP Redirection Rules and/or Filter Rules, it
41
shall overwrite any old rules of the same kind (HTTP with HTTP, IP with IP, Filter
42
with Filter) with the new rules. If no old rules of the same kind exist, the new rules
43
of that kind shall be applied. The Hot-Lining Device shall respond to the HAAA
44
with a COA ACK and begin sending accounting messages as described in the Hot-
45
Lining section of [Chapter 5].
46
47
8. If the Hot-Lining Device receives the Session-Timeout (27) attribute it shall terminate the
48
session after the time specified for the session (in seconds) has expired. If the Hot-Lining
49
Device is capable of RADIUS accounting it shall send a RADIUS Accounting-Request
50
(Stop) message containing the Hot-Lining Accounting Indication VSA if one was
51
received in a RADIUS Access-Accept or COA message.
52
9. A Hot-Lining Device that receives the HTTP-Redirection VSA shall monitor the IP flows. 53
When an IP flow matches the “src” and “dst” fields, the Hot-Lining Device shall apply 54
55
the rule as specified in the HTTP-Redirection VSA. If the action in the rule is to redirect,
56
the Hot-Lining Device shall block the traffic and respond to every HTTP request it sees
57
with an HTTP Redirect response [RFC 2616] specifying the URL of the matching HTTP-
58
Redirection Rule VSA.
59
60
11 Hot-Lining 96
1
2
3 10. A Hot-Lining Device that receives the IP-Redirection rule VSA shall monitor the IP
4 flows. When an IP flow matches the rule, the Hot-Lining Device shall redirect the flow to
5
the address specified in the matching rule.
6
7 11. A Hot-Lining Device that receives the IP-Filter rule VSA shall monitor the IP flows.
8 When an IP flow matches the rule, the Hot-Lining Device depending on the specified
9 action shall either block or allow the flow to proceed.
10
11 12. A Hot-Lining Device that receives an HTTP Redirection Rule, an IP-Filter-Rule or an IP-
12 Redirection-Rule that contains the keyword “flush” shall flush all previously received
13 attributes of the same kind for that session.
14
15 13. If the Hot-Line device receives an Access-Accept or a COA with the Hot-Line
16 Accounting attribute but no RADIUS FIlter-Id(11) attribute(s)/HTTP Redirection Rule
17 VSA/IP Redirection Rule VSA/Filter Rule VSA then this Hot-Line Accounting-
18 Indication shall not affect the Hot-Line state of the user. If the Hot-Lining Device is
19 capable of generating RADIUS accounting messages then it shall include the newly
20 received Hot-Line Accounting Indicator in all subsequent accounting messages.
21
22 11.4.1.1 Requirements for Hot-Line Capable PDSN
23
24 This section describes the requirements of a Hot-Line Capable PDSN. PDSN accounting
25 procedures that relate to Hot-Lining are covered in [Chapter 5] section 3.5.11. Accounting
26
messages are used to demarcate the Hot-Line session.
27
28
29 1. In multi-homed scenarios (i.e., user with multiple NAIs), the PDSN shall ensure that the
30 Hot-Line only affects flows associated with the home network that is asserting the Hot-
31 Lining.
32
33 11.4.1.2 Requirements for Hot-Line Capable HA
34
35 This section describes the requirements of a Hot-Line Capable HA.
36
37
1. A Hot-Lining capable HA shall send a RADIUS Access-Request message to the Home
38
39
RADIUS server upon receiving an initial MIP4 RRQ for a user. The Hot-Line capable
40
HA shall include the Hot-Line Capability VSA in the RADIUS Access-Request message
41
indicating its ability to support Hot-Lining.
42
Note: Since HA does not generate accounting messages for MIP4, it has no way of
43
demarcating or for that matter recording whether or not the user‟s session has been Hot-Lined.
44
45
46 11.4.2 MS Requirements
47
48 After the Hot-lining state has ended, the MS may perform device configuration to ensure it
49 has the correct parameters for use in a non-Hot-Lined state. This step may be triggered by
50 manual user intervention in case the notification of the end of the Hot-Lining state is at the
51 application layer and cannot be interpreted by the MS.
52
53
54 11.4.3 RADIUS Server
55
56 The following describes the RADIUS Hot-Lining requirements.
57
58
1. If the Home RADIUS server receives the Hot-Lining Capability VSA in the RADIUS
59
Access-Request message indicating the Hot-Lining capabilities of the RADIUS client,
60
97 11 Hot-Lining
the Home RADIUS server shall use the value to determine the Hot-Lining capabilities of 1
the PDSN or the HA. 2
3
2. The Home RADIUS server shall be capable of receiving an indication from the Hot- 4
Lining Application to either assert Hot-Lining for a user‟s packet data session or to 5
remove Hot-Lining from a Hot-Lined packet data session. The specification of the 6
indication is not within the scope of this document. 7
8
3. Upon receiving a Hot-Line indication from the Hot-Lining Application, the Home
9
RADIUS server should record the Hot-Lining state of the user in the user‟s profile. 10
11
4. Upon receiving an indication from the Hot-Line Application to remove Hot-Line state of
a user, the RADIUS server shall modify the user‟s profile. 12
13
5. The Home RADIUS server shall be responsible for selecting the Hot-Lining Device. The 14
selection criteria may be based on the Hot-Lining capability of the device as specified by 15
the Hot-Lining Capability VSA included in the RADIUS Access-Request message; local 16
17
policies; or other factors such as whether reverse tunneling is being used.
18
6. The RADIUS server shall not attempt to Hot-Line a Pre-Paid user. 19
20
7. The RADIUS server shall not attempt to Hot-Line a MIP6 session. Note that the 21
RADIUS server may hot-Line the underlying Simple IPv6 session at the PDSN. 22
23
8. The Home RADIUS server shall also determine whether or not to use Rule-based Hot- 24
Lining (using Filter-Rule and HTTP/IP Redirection-Rule VSAs) or Profile-based Hot- 25
Lining (using RADIUS Filter-Id(11) attribute). This decision should be based on the Hot- 26
Lining capabilities of the device as specified by the Hot-Lining Capability VSA included 27
in the RADIUS Access-Accept message and local policies. 28
29
9. The RADIUS server may include the Hot-Lining Accounting Indication VSA in the 30
RADIUS Access-Accept message and COA message. 31
32
10. The RADIUS server may include Session-Timeout attribute in order to limit the length of
33
time the users session is Hot-Lined.
34
35
11.4.3.1 Active Session 36
37
Upon receiving an indication to commence Active Session Hot-Lining, i.e., Hot-Lining of a 38
user‟s packet data session that is currently online, the Home RADIUS server shall send a 39
COA message to the Hot-Lining device. which includes the NAI, and the NAS ID. 40
41
If the Home RADIUS server receives a COA ACK from the Hot-Lining Device, then Active 42
Session Hot-Lining of a packet data session has been successful. The device's inability to Hot- 43
44
Line the packet data session will be indicated by the reception of COA NAK. The RADIUS
45
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 46
47
RADIUS server may (based on local policies) send a RADIUS Disconnect-Request message
48
to immediately cause the user‟s packet session to be terminated. The RADIUS Disconnect-
49
Request message may be sent to any access device serving the packet data session. 50
51
Upon receiving an indication from the Hot-Line Application to remove Hot-Line state and if 52
the user is currently online, the Home RADIUS server shall send a COA message to the Hot- 53
Lining Device to return the user‟s session back to normal operation. 54

55
56
57
58
59
60
11 Hot-Lining 98
1
2
3
11.4.3.2 New Session
4
5 Upon receiving a RADIUS Access-Request message for a user who is to be Hot-Lined, the
6 Home RADIUS server shall determine if Hot-Lining shall be applied for the user on that
7
device. If it determines that Hot-Lining shall be applied, it shall send that device the Hot-Line
8
indication in the RADIUS Access-Accept message.
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
51
52
53
54
55
56
57
58
59
60
99 11 Hot-Lining
Annex A (Normative): IKE/ISAKMP Payloads 1

2
3
This Annex addresses ISAKMP payloads in which multiple options exist (see [RFC 2407-
4
2409]). The following requirements shall be met by the PDSN and HA, assuming IP security 5
between the HA and PDSN is required. Payloads in which no options exist do not appear in 6
this Annex. 7
8
Note: If the HA (home network) does not require any security then Annex A does not apply
9
nor does it apply to MSs using collocated CoA for MIP.
10
11
12
ISAKMP Fixed Header: 13
14
The PDSN in this document shall use a Major and Minor Version of 0. The HA shall 15
minimally accept Major and Minor Version of 0. This document does not make use of the 16
Fixed Header Authentication (A) bit. 17
18
19
Security Association Payload: 20
21
All Security Association Payloads shall use the IPsec DOI. The Phase 1 ISAKMP Security 22
Payload shall specify a situation of SIT_IDENTITY_ONLY. Phase 2 ISAKMP Security 23
Payloads shall specify a situation of SIT_IDENTITY_ONLY for all cases where privacy or 24
only authentication applies (as outlined in the PDSN and HA "IP Security" sections of this 25
document). 26
27
28
Proposal Payload: 29
30
31
Because the MS first makes contact with the PDSN, the PDSN shall be the Initiator of the
32
Phase 1 ISAKMP SA. The HA shall be the Responder. The PDSN shall propose ISAKMP to
33
the HA for the Phase 1 ISAKMP SA.
34
For Phase 2 Quick Mode exchanges, both the PDSN and HA shall be Initiators and 35
Responders because symmetrical, bi-directional security between the PDSN and HA is 36

37
required. For message authentication, PDSNs conforming to this document shall propose both
38
AH29F and ESP with the authentication option. The HA shall respond with ESP if the PDSN
39
has proposed it. For message privacy, the PDSN shall propose ESP. For combined
40
authentication and privacy, the PDSN shall propose ESP only.
41
MIP registration control packets and IP in IP tunneled packets, or GRE encapsulated packets, 42
may be protected by IPsec authentication, privacy, or both. Security policies to be used 43

44
between the PDSN and the HA in this document are dictated by the home network not the
45
access provider network. The PDSN shall be capable of proposing authentication only,
46
privacy only, and both authentication and privacy. Service provider owned HAs shall accept
47
and propose only one of these, and the PDSN shall accept this proposal. The Home RADIUS
48
server may deliver a User Profile to the Visited RADIUS server and PDSN that indicates
49
whether security should be supported for IP in IP and/or GRE encapsulated packets . If the
50
Home RADIUS server indicates a request for no security on the IP-in-IP and GRE tunneled 51
packets, the PDSN shall not delete existing IPsec security associations to the HA. This is 52
because IPsec should be authorized per PDSN-HA pair and thus other MSs may be using 53
those IPsec security associations. 54
55
The SPI shall be four octets.
56
57
58
59
60
11 Hot-Lining 100
1
2
3
4
Transform Payload:
5
For Phase 1, the PDSN shall use KEY_IKE as the transform identifier. All implementations
6
7
shall support 3DES and RSA.
8
For Phase 2 Quick Exchange, the PDSN shall minimally support the ESP_3DES transform
9
identifier within a Transform Payload for IPsec ESP Proposal Payload. It shall also support
10
both HMAC-MD5 and HMAC-SHA1 as transform identifiers within a Transform payload for
11
IPsec AH Proposal Payload. Service provider HAs shall likewise support these two
12
transforms. The PDSN may optionally support and propose other transforms. An HA shall
13
14
select one of the transforms offered by the PDSN.
15
16
17 Key Exchange Payload:
18
19 The PDSN and HA will exchange D-H (Diffie-Hellman) public values computed in the D-H
20 group negotiated as part of a protection suite in the first message exchange of Phase 1 for
21 ISAKMP SA establishment. The PDSN shall specify Phase 1 authentication with certificates
22 when the HA's certificate or HA's root CA certificate is available.
23
24
Otherwise, if a Dynamic pre-shared IKE secret distributed by the Home RADIUS server is
25 available, the PDSN shall specify Phase 1 authentication with a pre-shared secret mode of
26 operation. In this case, the PDSN shall specify Phase 1 Aggressive mode only. This is
27 necessary in order that the KeyID field can be transmitted in the clear. The Home RADIUS
28 server shall insure that the value of the „S‟ key is hard to guess (i.e., a properly generated
29 random number) in order to prevent dictionary attacks that are possible with Aggressive mode.
30 If the PDSN has a statically configured IKE secret for the SA with the HA, then the PDSN
31 shall specify Phase 1 authentication with pre-shared secret mode of operation. In this case the
32 PDSN may either use Main Mode or use Aggressive Mode.
33
34
35
Identification Payload:
36
37 For Phase 1 negotiation, the PDSN shall set the Protocol-Id field to zero or UDP. The port
38
number shall be set to zero or 500. If the HA receives any other values for these two fields in
39
the Identification Payload, IKE negotiation shall be aborted.
40
41 For IKE authentication using pre-shared secret the PDSN and HA shall minimally support
42 ID_KEY_ID in the ID Type field. For IKE authentication using Revised Public Key
43 Encryption with RSA using X.509 certificates, the PDSN and HA shall minimally support
44 ID_DER_ASN1_DN in the ID Type field.
45
46 For Phase 2 (Quick Mode), both the PDSN and HA shall include the client identifiers in the
47 form of optional Client Identification Payloads as specified in IKE (i.e., IDci and IDcr).
48
49 To apply IPsec on all traffic between the PDSN and the HA, the PDSN and the HA shall
50 exchange IDci and IDcr. The protocol and port number fields shall be “don‟t care” by setting
51 them to 0 in both IDci and IDcr. The following is an example of the format of the client
52 identifiers.
53
54 IDCi: Protocol field = 0, Port = 0, Idtype = ID_IPV4_ADDR,
55 Identification_data = PDSN_IPV4_ADDR.
56
57
IDCr: Protocol field = 0, Port = 0, Idtype = ID_IPV4_ADDR,
58
Identification_data = HA_IPV4_ADDR.
59
60
101 11 Hot-Lining
Certificate Payload: 1
2
The Certificate Payload shall carry X.509 version 3 certificates. 3

4
5
Signature Payload: 6
7
8
The PDSN and HA shall not include this payload.
9
10
11
Notification Payload: 12
13
The Notification Payload carries error messages and reason codes regarding failure for a peer
14
to be able to establish a security association. The PDSN and HA handling of a failed security 15
association establishment is specified in the main body of the document. 16
17
The PDSN and HA shall use the "SA Lifetime Notify" code as a trigger to refresh the
18
indicated security association.
19
20
21
Delete Payload: 22
23
The PDSN shall send a delete payload upon an SA refresh or upon request from a service 24
provider administrator. 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
51
52
53
54
55
56
57
58
59
60
11 Hot-Lining 102
1
2
3
4 Annex B (Normative): Certificates
5
6 PDSNs and HAs shall use X.509 Version 3 certificates in conformance with [RFC 2459].
7 Each PDSN and HA in a service provider network may have a unique certificate which will
8 be configured into the PDSN and HA. The method of configuration of certificates is outside
9 the scope of this document.
10
11 Note: This Annex only applies to FA CoA. Security between a collocated CoA MS and the
12 HA is outside the scope of this document.
13
14
Each service provider may be a Certificate Authority for itself and its client private networks
15 and partner ISPs for PDSNs and for HAs that may be accessed by PDSNs. All PDSNs and
16 HAs shall be configured with all service provider CA certificates. There should be one CA
17 root certificate from each service provider.
18
19
20 Certificates for PDSNs and HAs:
21
22 The Distinguished Name [RFC 2459] contained in the Issuer field is of form:
23
24
cdma2000.service-provider-name
25
26
27 The PDSN or HA determines the issuing service-provider (i.e., the CA) from the service-
28 provider-name attribute of the Issuer's Distinguished Name. The PDSN and HA then use the
29 service-provider-name attribute to locally access the CA's public key.
30
31 The PDSN and HA shall use the SHA-1 as a hash function and either the RSA or DSA
32 signing algorithm, as specified in [RFC 2459] to verify a certificate. The private network or
33 ISP shall provide the public key and Distinguished Name of the certificate.
34
35 The Distinguished Name contained in the Subject field is of form:
36
37 cdma2000. service-provider-name.PDSN.service-provider-identifier
38
39
40 cdma2000. service-provider-name.HA.service-provider-identifier
41
42 Certificates in the PDSN and HA will not use the Unique-Identifier field.
43
44 Certificate extensions for PDSN and HA certificates shall not be supported.
45
46 The method of providing PDSNs and HAs signed certificates to PDSNs and HAs is outside
47 the scope of this document.
48
49
50 CA Certificates:
51
52 Service provider CA certificates shall be configured into all PDSNs and HAs. A service
53 provider CA contains the public key that the PDSN or HA shall use to verify the signature of
54 a certificate received in a Phase 1 ISAKMP exchange.
55
56 A CA certificate shall conform to the X.509 V3 certificates in [RFC 2459]. Since the service
57 provider CA distributes its own certificate, the Authority Key Identifier and Subject Key
58 Identifier extensions shall not be included in the certificate.
59
60 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.
103 11 Hot-Lining
Certificate Revocation List (CRL): 1

2
CRLs shall be used to store the identities of certificates that have been compromised or are 3
otherwise invalid. CRLs shall conform to X.509 v2 as specified in [RFC 2459]. A future 4
version of this document may make use of the Online Certificate Status Protocol. 5
6
Service providers shall exchange revoked certificate information (e.g., serial number). The 7
frequency of the exchange is outside the scope of this document. 8
9
Possession of a certificate does not imply service since the RADIUS server and MIP functions 10
still control the user obtaining service, as well as the HA allowing access to the PDSN. 11
12
The CA certificate shall indicate the service provider CA as Issuer of the CRL. The DN of the 13
Issuer shall be of form: 14
15
cdma2000.service-provider-name
16
17
CRLs exchanged between service providers shall use the SHA-1 as a hash function and either 18
the RSA or the DSA signing algorithm as specified in [RFC 2459]. 19
20
CRL extensions shall not be supported. 21
22
The method of exchanging CRLs between service providers, or to conveying certificates
23
client private network or partnering ISP, as well providing this information into PDSNs and 24
HAs, is outside the scope of this document. 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
51
52
53
54
55
56
57
58
59
60
11 Hot-Lining 104
1
2
3
4 Annex C (Normative): PDSN Timers
5
6 The PDSN shall implement a PPP inactivity timer, a PPP session timer, an accounting interval
7 timer and/or a NCP inactivity timer. These timers are defined as follows.
8
9 PPP inactivity timer (4-byte unsigned integer): This mandatory timer is configured with the
10 maximum number of consecutive seconds that a PPP session may be idle. When a PPP
11 session has been idle for this amount of time, the PPP session may be terminated depending
12 on the user‟s Always On status (see section 3.2.1.10).
13
14
PPP session timer (4-byte unsigned integer): This optional timer is configured with the
15 maximum number of total seconds for which a PPP session may be established. When a PPP
16 session has been established for this amount of time, the PPP session is terminated, regardless
17 of whether it is active or idle.
18
19
Accounting interval timer (4-byte unsigned integer): This optional timer is configured with
20
the number of total seconds between when the PDSN sends periodic interim accounting
21
messages to the RADIUS server.
22
NCP inactivity timer (28 bits unsigned integer): This optional timer is configured with the
23
maximum number of total seconds for which an NCP session may be idle. When an NCP
24
25
session has been idle for this amount of time, the NCP session is terminated.
26
The PPP inactivity timer and PPP session timer use the value of 0 to indicate infinity. When
27
timers are set to an infinity value, they will never expire.
28
29
30
31
PPP Inactivity Timer
32
33
The PPP inactivity timer shall be locally configured on the PDSN with a default value that is
34
used for all PPP sessions. However, this default value may be overridden on a per session
35
basis with a RADIUS Idle-Timeout (28) attribute [RFC 2865] that is returned from the
36
RADIUS server in a RADIUS Access-Accept message.
37
For MIP service, the PPP inactivity timer shall always be greater than the MIP registration
38
lifetime. Thus, the PDSN shall always advertise to the MS a maximum allowed MIP
39
40
registration lifetime smaller than the PPP inactivity timer value currently in use for the PPP
41
session. The PDSN shall ignore a non-zero RADIUS Idle-Timeout value received in a
42
RADIUS Access-Accept message for a MIP session, which is smaller than current PPP
43
inactivity timer for the PPP session. The PDSN may honor the RADIUS-Idle-Timeout value
44 received in a RADIUS Access-Accept message for a MIP session if the received value is
45 greater than the one currently in use for the PPP session.
46
47
In case of Simple IP service, if the PPP session is marked as “Always-On” then the PDSN
48
shall perform the link status determination procedure upon expiry of the PPP inactivity timer
49
(see section 3.2.1.10).
50
51
52 PPP Session Timer
53
54 If the PPP session timer is used, then it shall be locally configured on the PDSN with a default
55 value that is used for all PPP sessions. However, this default value may be overridden on a per
56 session basis with a RADIUS Session-Timeout (27) attribute [RFC 2865] that is returned
57 from the RADIUS server in a RADIUS Access-Accept message. For Always On users, the
58 PDSN shall discard the PPP session timer.
59
60
105 11 Hot-Lining
In the case of multiple MIP sessions over a single PPP session, it is possible that the PDSN 1
receives different RADIUS-Session-Timeout values from different home networks. In this 2
case, the PDSN may honor the initial RADIUS-Session-Timeout value that it received and 3
shall ignore all subsequent RADIUS-Session-Timeout values that it receives. 4
5
6
Accounting Interval Timer 7

8
If the accounting interval timer is used, then it shall be locally configured on the PDSN with a 9
default value that is used for all sessions. However, this default value may be overridden on a 10
per session basis with a RADIUS Acct-Interim-Interval (85) attribute [RFC 2869] that is 11
returned from the RADIUS server in a RADIUS Access-Accept message. For a session using 12
13
the prepaid service, the RADIUS Acct-Interim-Interval shall not be used and the interval
14
timer shall be interpreted as per [Chapter 6] (PrePaid Packet Data Service).
15
16
17
NCP Inactivity Timer 18
19
The NCP inactivity timer shall be configured based on operator‟s policy. How to configure
20
this timer is out of scope of this document. 21
22
The NCP inactivity timer shall always be smaller than the PPP inactivity timer. For MIPv4
23
service, the NCP inactivity timer shall always be greater than the MIPv4 registration lifetime.
24
Thus, the PDSN shall always advertise to the MS a maximum allowed MIPv4 registration
25
lifetime smaller than the NCP inactivity timer value.
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
51
52
53
54
55
56
57
58
59
60
11 Hot-Lining 106

Cdma2000 Sip Mip Standard

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cdma2000 Sip Mip Standard

Transféré par

Droits d'auteur :

Formats disponibles

3GPP2 X.

Version Date: November 2009

cdma2000 Wireless IP Network Standard:

Simple IP and Mobile IP Access Services

1 cdma2000 Wireless IP Network Standard: Chapter 2

4.5.1 PPP Session ............................................................................................................... 37 1

4.5.3 MS Requirements for GRE Tunneling Support ......................................................... 41 3

5.1 Common Service Specification ................................................................................................ 45 8

5.1.4 Mobile Station to Home Agent Security for BU and BA .......................................... 54 14

5.4 RADIUS Server Requirements ................................................................................................ 62 34

5.5.1 PPP Session ............................................................................................................... 67 39

5.5.5 MIP6 Home Registration ........................................................................................... 69 45

CA Certificates: .................................................................................................................................... 103 1

Certificate Revocation List (CRL): ...................................................................................................... 104 2

PPP Session Timer ............................................................................................................................... 105 7

Table 4 Occurrence of RADIUS Attributes for MIP4 ................................................................... 35 7

Table 8 List of MS Capabilities ..................................................................................................... 84 12

vii General Description

1 1 Glossary and Definitions

extensions described in this document. 25

 IPv6CP [RFC 2472] (for IPv6); 32

 CHAP [RFC 1994]; 34

3.2.1 PPP Session 47

3.2.1.4 Addressing with IPCP 1

construct any global address from this prefix. 45

 Internet Protocol, Version 6 (IPv6) Specification [RFC 2460]; 51

MS PDSN DHCPv6 AAA 4

RADIUS Accounting-Request (start) to the RADIUS server. 35

configured in the PDSN. 46

Reserved 2 NCP Type 22

Code = 0 (As defined in [RFC 2153]) 29

= packet. If Kind =1 and if this field is present, it shall be 50

Extensible Authentication Protocol (EAP), 15

User-Password 2 O Note 1 PDSN -> AAA 27

EAP-Message 79 O O O PDSN <-> AAA 41

IP-Services-Authorized 26/185 O PDSN <- AAA 52

If the PDSN receives an implementation-defined number of consecutive packets with an 15

configured DHCP server(s) IP address(es) as described in section 3.2.1.5. 20

not send an LCP Terminate-Request message to the PDSN. 24

LCP Configure-Request message received from the PDSN. 39

3.4.1.6 Stateless DHCPv6 Support 28

DHCPv6 Information-Request message to the All_DHCP_Relay_and_Servers address 33

3095] with ROHC over PPP [RFC 3241]; 47

4.1.1 PPP Session 17

RADIUS server traversal. 23

 Reverse Tunneling [RFC 3024]; 35

network shall treat the value as 255.255.255.255 (see section 4.5.2.2). 48

GRE header Key field when sending GRE encapsulated traffic to 8

The header format is reproduced here. 13

Key: The value assigned by the PDSN and HA in RRQ/RRP messages 31

respectively. This field MUST be present in the GRE header. 32

4.2 PDSN Requirements 38

The PDSN shall support MIP4 operation and act as an FA. 40

4.2.2 MIP4 Registration 1

negotiate PPP and begin transmission of an operator configurable number of Agent 29

maximum ICMP router advertisement lifetime). 36

in the RADIUS Access-Request message. 50

shall send a RADIUS Access-Reject message to the PDSN. 56

4.2.4.1 IPsec Service Authorized 1

'1' or '2', the PDSN shall use a default value of '3'. 9

RADIUS server, shall be used to establish the required SA. 56

Request message to the Home RADIUS server to request the S Key. 26

within the allowable time skew19. 48