Cdma2000 Sip Mip Standard

8/8/2019 Cdma2000 Sip Mip Standard

1/116

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 [email protected]. Requests to reproduce individual Organizational Partner's

documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.

3GPP2 X.S0011-002-E

Version: 1.0

Version Date: November 2009

cdma2000 Wireless IP Network Standard:

Simple IP and Mobile IP Access Services


2/116

This page is left blank intentionally.


3/116

cdma2000 Wireless IP Network Standard X.S0011-002-E v1.0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

i Contents

cdma2000 Wireless IP Network Standard: Chapter 2

CONTENTS

1 Glossary and Definitions .......................................................................................................................... 12 References ................................................................................................................................................ 13 Simple IP Operation ................................................................................................................................. 2

3.1 Common Service Specification .................................................................................................. 23.1.1 PPP Session ................................................................................................................. 2

3.2 PDSN Requirements .................................................................................................................. 23.2.1 PPP Session ................................................................................................................. 23.2.2 RADIUS Support ....................................................................................................... 123.2.3 Ingress Address Filtering ........................................................................................... 14

3.3 RADIUS Server Requirements ................................................................................................ 153.4 MS Requirements .................................................................................................................... 15

3.4.1 PPP Session ............................................................................................................... 154 MIP4 Operation ...................................................................................................................................... 20

4.1 Common Service Specification ................................................................................................ 204.1.1 PPP Session ............................................................................................................... 204.1.2 MIP4 .......................................................................................................................... 204.1.3 Dynamic Home Agent and Home Address Assignment ........... .......... ........... .......... .. 204.1.4 GRE CVSE ................................................................................................................ 21

4.2 PDSN Requirements ................................................................................................................ 224.2.1 PPP Session ............................................................................................................... 224.2.2 MIP4 Registration...................................................................................................... 244.2.3 RADIUS Support ....................................................................................................... 264.2.4 IP Security Support .................................................................................................... 274.2.5 Ingress Address Filtering ........................................................................................... 294.2.6 PDSN Requirements for GRE Tunneling Support .................................................... 29

4.3 Home Agent Requirements ...................................................................................................... 314.3.1 Multiple Registrations ............................................................................................... 314.3.2 MIP4 Authentication Support .................................................................................... 314.3.3 IPsec Support ............................................................................................................. 324.3.4 Dynamic Home Agent Assignment ........................................................................... 334.3.5 DNS Address Assignment ......................................................................................... 334.3.6 HA Requirements for GRE Tunneling Support ......................................................... 33

4.4 RADIUS Server Requirements ................................................................................................ 354.4.1 Dynamic Home Agent Assignment ........................................................................... 364.4.2 MN-HA Shared Key Distribution .............................................................................. 364.4.3 IKE Pre-shared Secret Distribution Procedure .......................................................... 364.4.4 DNS Address Assignment ......................................................................................... 37

4.5 MS Requirements .................................................................................................................... 37


4/116

X.S0011-002-E v1.0 cdma2000 Wireless IP Network Standard

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

4950

51

52

53

54

55

56

57

58

59

60

Contents ii

4.5.1 PPP Session ............................................................................................................... 374.5.2 MIP4 Registration ......... ........... .......... ........... .......... ........... .......... ........... .......... ......... 384.5.3 MS Requirements for GRE Tunneling Support ......................................................... 41

4.6 DNS Server IP Address NVSE ................................................................................................ 425 MIP6 Operation .......... ........... .......... .......... ........... .......... ........... .......... ........... .......... ........... .......... ......... 43

5.1 Common Service Specification ................................................................................................ 455.1.1 PPP Session ............................................................................................................... 455.1.2 MIP6 .......................................................................................................................... 465.1.3 Summary of PDSN and MS Behavior for Dynamic HA/HL Discovery via

MIP6 Bootstrapping .......... .......... ........... .......... ........... .......... ........... .......... ........... ..... 465.1.4 Mobile Station to Home Agent Security for BU and BA .............. .......... .......... ........ 54

5.2 PDSN Requirements ................................................................................................................ 555.2.1 PDSN Requirement to Support Stateless DHCPv6 to Convey MIP6 Bootstrap

Info ............................................................................................................................ 555.2.2 MIP6-HA-Protocol-Capability-Indication ................................................................. 565.2.3 Ingress Address Filtering ........................................................................................... 57

5.3 Home Agent Requirements ...................................................................................................... 575.3.1 Home Agent Requirements to Support Dynamic Home Agent Assignment ............. 575.3.2 Home Agent Requirements to Support Dynamic Home Address Configuration ....... 575.3.3 Multiple Registrations ............................................................................................... 585.3.4 Prefix Registrations ................................................................................................... 585.3.5 Data Forwarding ........................................................................................................ 585.3.6 Home Registration Support ....................................................................................... 585.3.7 Return Routability Support for Route Optimization .......... .......... ........... .......... ......... 605.3.8 HA Requirement as a RADIUS Client ...................................................................... 605.3.9 DNS address assignment ........................................................................................... 60

5.4 RADIUS Server Requirements ................................................................................................ 625.4.1 RADIUS Support for Session Key Generation and Distribution to the HA .............. 645.4.2 RADIUS Support for MIP6 Bootstrap ....................................................................... 66

5.5 MS Requirements .......... ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... .. 675.5.1 PPP Session ............................................................................................................... 675.5.2 MS Requirement to Support Stateless DHCPv6 to Obtain MIP6 Bootstrap

Info ............................................................................................................................ 685.5.3 Multiple Registrations ............................................................................................... 695.5.4 Prefix Registration ..................................................................................................... 695.5.5 MIP6 Home Registration ........................................................................................... 695.5.6 DNS address assignment ........................................................................................... 715.5.7 Termination ............................................................................................................... 71

5.6 Accounting Consideration .......... .......... ........... .......... ........... .......... .......... ........... .......... ........... 715.6.1 PDSN requirements ................................................................................................... 725.6.2 HA requirements .......... .......... ........... .......... ........... .......... .......... ........... .......... ........... 72

6 Simultaneous Services ........... .......... ........... .......... .......... ........... .......... ........... .......... ........... .......... ......... 746.1 PPP Additional Authentication ................................................................................................ 74

6.1.1 PDSN and MS Common Requirements ..................................................................... 746.1.2 PDSN Requirements .................................................................................................. 77


5/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

iii Contents

6.1.3 MS Requirements ...................................................................................................... 787 IP Services Authorization and Selection ................................................................................................ 79

7.1 IP Services Authorization ........................................................................................................ 797.2 IP Services Selection................................................................................................................ 79

8 IP Reachability Service .......................................................................................................................... 808.1 Simple IPv4 Operation ............................................................................................................. 808.2 MIP4 Operation ....................................................................................................................... 81

8.2.1 DNS Update by the Home RADIUS Server .............................................................. 818.2.2 DNS Update by the HA ............................................................................................. 81

8.3 Simple IPv6 Operation ............................................................................................................. 828.4 MobileIPv6 Operation ............................................................................................................. 82

9 MS-PDSN Version Capability Indication .............................................................................................. 839.1 PDSN Requirements ................................................................................................................ 859.2 MS Requirements .................................................................................................................... 85

10 3GPP2 Vendor Specific Reject Packet ................................................................................................... 8611 Hot-Lining .............................................................................................................................................. 87

11.1 Hot-Lining Capabilities ........................................................................................................... 8711.2 Hot-Lining Architecture ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... .. 8811.3 Operations ................................................................................................................................ 90

11.3.1 New-Session Hot-Lining Procedure .......................................................................... 9111.3.2 Active Session Hot-Lining Procedure ....................................................................... 9211.3.3 Limiting the Hot-Lining Duration ............................................................................. 95

11.4 Hot-Lining Requirements ........................................................................................................ 9511.4.1 Requirements for Hot-Line Capable PDSN and HA ................................................. 9511.4.2 MS Requirements ...................................................................................................... 9711.4.3 RADIUS Server ......................................................................................................... 97

Annex A (Normative): IKE/ISAKMP Payloads ................................................................................................. 100ISAKMP Fixed Header: ....................................................................................................................... 100Security Association Payload: .............................................................................................................. 100Proposal Payload: ................................................................................................................................. 100Transform Payload: .............................................................................................................................. 101Key Exchange Payload: ....................................................................................................................... 101Identification Payload: ......................................................................................................................... 101

Certificate Payload: .............................................................................................................................. 102Signature Payload: ............................................................................................................................... 102Notification Payload: ........................................................................................................................... 102Delete Payload: .................................................................................................................................... 102

Annex B (Normative): Certificates ..................................................................................................................... 103Certificates for PDSNs and HAs: ......................................................................................................... 103


6/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

4950

51

52

53

54

55

56

57

58

59

60

Contents iv

CA Certificates: .......... ........... .......... .......... ........... .......... ........... .......... ........... .......... ........... .......... ....... 103Certificate Revocation List (CRL): ...................................................................................................... 104

Annex C (Normative): PDSN Timers ................................................................................................................. 105PPP Inactivity Timer ............................................................................................................................ 105PPP Session Timer ............................................................................................................................... 105

Accounting Interval Timer ................................................................................................................... 106NCP Inactivity Timer ........................................................................................................................... 106


7/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

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 FIGURES

Figure 1 MS Parameters configuration with DHCP .......................................................................... 7Figure 2 Configuration of MSs parameters using DHCPv6 ............................................................ 8Figure 3 Max PPP Inactivity Timer Packet ..................................................................................... 10Figure 4

GRE Key CVSE ............................................................................................................... 21

Figure 5 GRE Header for Tunneling Datagrams ........... .......... ........... .......... .......... ........... .......... .... 22Figure 6 NVSE for DNS Server IP Address ................................................................................... 42Figure 7 The Initial MIP6 Home Registration with MN-AAA mobility message

authentication option ........................................................................................................ 43Figure 8 MIPv6 Home Registration with MN-HA mobility message authentication option .......... 45Figure 9 Flow diagram for Dynamic Home Agent Assignment (HA and HL is assigned by

HAAA) ............................................................................................................................. 48Figure 10 Flow diagram for Dynamic Home Agent Assignment (VAAA assigns HA and HL) ...... 50Figure 11 Bootstrap of Home Link Prefix ........................................................................................ 52Figure 12 Home Address Auto-Configuration .................................................................................. 54Figure 13 Derivation and distribution of IK and MN-HA SPI during Home Registration ............... 65Figure 14 Accounting Procedures for MIP6 ..................................................................................... 72Figure 15 3GPP2 vendor specific PPP Additional Authentication packet format ......... .......... ......... 75Figure 16 Value format for AddAuth packet .................................................................................... 75Figure 17 Additional Authentication (CHAP case) .......................................................................... 76Figure 18 Version/Capability Packet Format .................................................................................... 83Figure 19 Reject Packet Format ........................................................................................................ 86Figure 20 Hot-Lining architecture..................................................................................................... 89Figure 21 New Session Hot-Lining Call Flow .................................................................................. 91Figure 22 Active Session Hot-Lining Procedure .............................................................................. 93


8/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

4950

51

52

53

54

55

56

57

58

59

60

List of Tables vi

LIST OF TABLES

Table 1 Occurrence of RADIUS Attributes for Simple IP .......... ........... .......... ........... .......... ......... 12Table 2 Home Agent and Home Address Scenarios ...................................................................... 21Table 3 Description of Scenarios ................................................................................................... 21Table 4

Occurrence of RADIUS Attributes for MIP4 ................................................................... 35

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


9/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

vii General Description

GENERAL DESCRIPTION

This chapter describes the basic IP access services: Simple IPv4/IPv6, MIP6 and MIP4 with

Home Agent(HA) and/or Dynamic Home IP address Assignment. It also addresses the

security requirements between the Wireless IP Network nodes: PDSN, HA and RADIUS

servers. The chapter includes other capabilities such as Always On, multiple simultaneous

MIP4/MIP6 and Simple IPv4/IPv6 packet data sessions, IP Reachability Service, DHCPSupport, Hot-Lining, additional PPP authentications, and IP service authorization etc.


10/116

This page is left blank intentionally.


11/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

1 1 Glossary and Definitions

1 Glossary and Definitions

See [Chapter 1].

2 References

See [Chapter 1].


12/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

4950

51

52

53

54

55

56

57

58

59

60

3 Simple IP Operation 2

3 Simple IP Operation

This section describes the requirements and procedures for Simple IP operation for both IPv4

[RFC 791] and IPv6 [RFC 2460]. In this document, Simple IP refers to a service in which an

MS is assigned an IP address and is provided IP routing service by an access provider

network. The MS retains its IP address as long as a Radio Access Network (RAN) that hasconnectivity to the same Serving PDSN serves it. IP address mobility beyond the Serving

PDSN and secure access to a home network are beyond the scope of this section.

3.1 Common Service Specification

The common requirements for several network elements (e.g., PDSN and MS) for Simple IP

operation are described here.

3.1.1 PPP Session

PPP shall be the data link protocol between the MS and the PDSN. The PPP session shall be

established prior to any IP datagram being exchanged between the MS and the PDSN. Onlyone PPP session shall be supported between the MS and the PDSN.

PPP shall be supported as defined in the following standards with any limitations or

extensions described in this document.

Point to Point Protocol [RFC 1661];

PPP in HDLC-like Framing [RFC 1662];

IPCP [RFC 1332] (for IPv4);

IPv6CP [RFC 2472] (for IPv6);

CHAP [RFC 1994];

PAP [RFC 1334].

EAP [RFC 3748]

PPP encryption is not supported in this document.

3.2 PDSN Requirements

The PDSN shall support Simple IP operation for both IPv4 and IPv6.

3.2.1 PPP Session

3.2.1.1 Establishment

If the PDSN supports multiple service connections for a user, refer to [Chapter 4] for details

of PPP negotiation. Otherwise, when an A10 connection of SO type 33/59 is established the

PDSN shall send an LCP Configure-Request for a new PPP session to the MS.

PPP shall support transparency in accordance with Section 4.2 of [RFC 1662]. The PDSN

shall not send an LCP Configure-Reject in response to an ACCM configuration option

proposed by the MS in an LCP Configure-Request and shall attempt to negotiate a control


13/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

3 3 Simple IP Operation

character mapping with the minimum number of escaped characters by proposing an ACCM

of 0x00000000.

3.2.1.2 Termination

The PDSN shall close the PPP session if there is no established A10 or P-P session for the MS.

If the PPP session timer is used and has expired, or if Always On service is not enabled and

the PPP inactivity timer for a PPP session expires, the PDSN shall close the PPP session. The

PDSN may receive the Always On attribute with value 1 from the Home RADIUS server in

order to activate the Always On service for a user. If the PDSN receives the Always Onattribute with value 1, it shall send the indicator to the RAN as indicated in [4].

Upon receiving the Always On attribute with value 1 from the Home RADIUS server the

PDSN shall utilize the expiration of the PPP inactivity timer and the procedures described in

Section 3.2.1.10 to determine if the PPP session should be closed.

When the PDSN determines that the PPP session shall be closed, it shall determine if an LCP

Terminate-Request should be sent to the MS. For an Always On session, the PDSN shall send

an LCP Terminate-Request to the MS. The PDSN should also send LCP Terminate-Request

to a non-Always On session unless it has previously received the All Dormant Indicator

NVSE.The PDSN shall clear the A10 and/or P-P session whenever the associated PPP session is

closed. If the PDSN receives IP packet(s) for an MS for which there is no established PPP

session, the PDSN shall silently discard the packet(s). The PDSN shall close the A10 and

associated P-P session if it receives an LCP Terminate-Request message from the MS.

3.2.1.3 PPP Session Authentication

The PDSN shall support the three authentication mechanisms: EAP, CHAP and PAP. The

PDSN shall also support a configuration option to allow an MS to receive Simple IP service

without EAP, CHAP or PAP. If the local policy requires using EAP, the PDSN shall propose

EAP as the authentication protocol in the LCP Configure-Request by setting Authentication-

Protocol option to C227 (hex) in the LCP Configuration Options. If the P DSN doesnt

propose the EAP, the PDSN shall propose CHAP in an initial LCP Configure-Requestmessage that the PDSN sends to the MS during the PPP establishment.

If the response from the MS for the Configure-Request proposing EAP is Configure-Ack,

then the PDSN shall select EAP as the PPP authentication protocol and proceed to play the

role of EAP authenticator and exchange EAP messages using the AAA protocol (e.g.

RADIUS).

If the PDSN receives an LCP Configure-NAK from the MS containing CHAP, the PDSN

shall accept CHAP by sending an LCP Configure-Request message with CHAP.

If the PDSN receives an LCP Configure-NAK from the MS containing PAP, the PDSN shall

accept PAP by sending an LCP Configure-Request message with PAP.

If the PDSN receives an LCP Configure-Reject containing the Authentication-Protocol option

and the PDSN is configured to allow the MS to receive Simple IP service without EAP,

CHAP or PAP, the PDSN shall respond with an LCP Configure-Request without the

Authentication-Protocol option and shall adhere to the guidelines in Section 3.2.2.1 for NAI

construction for accounting purposes.


14/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

4950

51

52

53

54

55

56

57

58

59

60


3.2.1.4 Addressing with IPCP

3.2.1.4.1 IPv4 Addressing

For IPv4, the PDSN shall assign the MS an IP address for Simple IP service when presented

with a zero or non-zero IP address in the IP Address Configuration option, during the IPCP

phase of PPP. The IP address may be a private address as per [RFC 1918]. If the MS requests

a non-zero IP address during the IPCP phase, the PDSN shall send an IPCP Configure-Nak inresponse to the request in order to propose a different IP address. If the MS responds with an

IPCP Configure-Request containing an IP address different from the one proposed by the

PDSN, the PDSN shall re-transmit one time the IPCP Configure-Request containing the new

IP address, and shall send an LCP Terminate- Request if the MS fails to accept the assigned

IP address.

During IPCP phase, the PDSN shall include the IP Address Configuration option containing

its IP address in the IPCP Configure-Request messages sent to the MS.

The PDSN shall implement IPCP configuration options as defined in [RFC 1877] for the DNS

server address negotiation. The PDSN shall negotiate Primary and Secondary DNS server IP

addresses with the MS if the DNS Server Configuration options are received during the IPCP

phase. If the PDSN supports DNS server IP address VSA, it shall determine if the M bit is set

in the DNS Server IP Address VSA received in the RADIUS Access-Accept message. The

PDSN shall select DNS Server IP Address VSA, with the M bit set, for DNS information. If

PDSN receives a RADIUS Access-Accept message from the Visited RADIUS server that has

DNS IP address VSA(s) with the following values included, then the PDSN shall apply local

policies to select the DNS IP Address VSA for DNS information.

A DNS IP Address VSA with the Entity-Type subfield set to the value 1 (=HAAA)and the M bit unset, and/or

One or more DNS IP Address VSA(s) with the Entity-Type subfield set to the value2 (=VAAA).


If the MS-PDSN Version Capability Indication (see section 8) is used, and the MS signaledthat it does not support Simple IPv6 (C2 bit set to 0), then the PDSN shall not negotiate

IPv6CP with the MS and shall not send IPv6 Router Advertisements to the MS.

If the MS-PDSN Version Feature Indication is used, and the MS signaled that it supports

Simple IPv6 (C2 bit set to 1), then the PDSN shall provide Simple IPv6 service to the MS as

described in the rest of this section.

For an IPv6 MS, the PDSN shall be the default router and the PPP termination point. The

PDSN shall allocate one globally unique /64 prefix to each PPP link. The PDSN shall not

construct any global address from this prefix.

The PDSN shall support the following RFCs, with exceptions as noted in this document:

An IPv6 Aggregatable Global Unicast Address Format [RFC 3587];

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

Neighbor Discovery for IP Version 6 (IPv6) [RFC 2461];

IPv6 Stateless Address Auto-configuration [RFC 2462];

Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6(IPv6) Specification [RFC 2463];


15/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


IP Version 6 over PPP [RFC 2472];

IP Version 6 Addressing Architecture [RFC 3513].

The PDSN shall perform Interface-Identifier negotiation as described in [RFC 2472].

Interface-Identifiers used by the PDSN and the MS are configured via IPv6CP. The PDSN

shall provide to the MS a valid non-zero Interface-Identifier of the PDSN in the IPv6CP

Configure-Request. The PDSN shall provide a valid non-zero Interface-Identifier for the MSin IPv6CP Configure-NAK if the MSs proposed Interface-Identifier is not acceptable to the

PDSN. While communicating with the MS, the PDSN shall use only the link local address

that it constructed with its Interface-Identifier that it provided to the MS (i.e. PDSNs

Interface-Identifier) during IPv6CP phase. Because the Interface-Identifier negotiated in the

IPv6CP phase of the PPP connection setup is unique for the PPP connection, it is not required

to perform duplicate address detection for the link local address formed as part of IPv6

stateless address auto-configuration [RFC 2462].

Following successful IPv6CP negotiation and the establishment of a unique link-local address

forboth the PDSN and the MS, the PDSN shall immediately1

transmit initial unsolicited

Router Advertisement (RA) messages on the PPP link using its link-local address as a source

address. The PDSN shall include a globally unique /64 prefix in the Router Advertisement

message to the MS. The MS uses this prefix to configure its global IPv6 addresses.

The PDSN shall send unsolicited Router Advertisement (RA) message for an operator

configurable number of times. Also, the PDSN shall set the interval between initial RA

messages to an operator configurable value, which may be less than

MAX_INITIAL_RTR_ADVERT_INTERVAL. After the configurable number of initial

unsolicited RA messages has been transmitted, the interval between the periodic

transmissions of unsolicited RA messages shall be controlled by the router configurable

parameters MaxRtrAdvInterval and MinRtrAdvInterval as defined in [RFC 2461]. The PDSN

may set MaxRtrAdvInterval to a value greater1F than 1800 seconds and less than 1/3 of the

AdvDefaultLifetime. The PDSN shall set MinRtrAdvInterval2

to a fraction of

MaxRtrAdvInterval as per [RFC 2461].

The PDSN shall send a RA message in response to a Router Solicitation (RS) message

received from the MS. The PDSN may set the delay between consecutive (solicited RA) or

(solicited /unsolicited RA) messages sent to the all-nodes multicast address to a value less3

than that specified by the constant MIN_DELAY_BETWEEN_RAS, contrary to the

specification in sec. 6.2.6 of [RFC 2461].

The advertised /64 prefix4

identifies the subnet associated with the PPP link. The /64 prefix

advertised by the PDSN shall be exclusive to the PPP session.

The PDSN shall set:

the M-flag = 0 in the RA message header;

the L-flag = 0 and the A-flag =1 in the RA message Prefix Information Option.

The PDSN shall set the Router Lifetime value in the Router Advertisement message to a value

of 216-1 (18.2 hrs).

1 This is an exception to [RFC 2461] necessary to optimize applicability over the cdma2000 wireless air-interface.2 This may cause an exception to [RFC 2461] as it may put the interval outside the normal range. This exception is allowedby this document to optimize IPv6 RA over the cdma2000 wireless links.3 This exception is allowed by this document to optimize IPv6 RA over the cdma2000 wireless links.4 If the Access Service Provider desires to reduce frequent unsolicited RA for the prefix, it should set the 32-bit ValidLifetime 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).


16/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

4950

51

52

53

54

55

56

57

58

59

60


The PDSN shall not send any redirect messages to the MS over the PPP interface.

3.2.1.5 DHCPv4 Support

The PDSN shall support DHCP Relay Agent function as specified in [RFC 1542] and [RFC

3046]. If the PDSN includes the Relay Agent Information Option, it shall set the giaddr field

to the Relay Agents IP address, and include one of the following values in the Agent RemoteID Sub-option of the Relay Agent Information Option:

User name = NAI of the user (DHCP client) used to setup the PPP/MIP session.

The remote IP address of a point-to-point link = IPv4 address assigned to the MS viaIPCP negotiation.

The PDSN assigns IPv4 address to MS via IPCP IP address configuration option. However,

if the MS acquires additional IPv4 addresses from a DHCP server using a PDSN as the relay

agent, the PDSN shall store the additional IPv4 addresses. The PDSN shall create one or more

new accounting UDRs depending on the number of service connections established for each

of these additional IPv4 addresses.

The PDSN shall relay the DHCP message received from the MS on port 67 to the DHCP

server(s) IP address(es) configured in the PDSN as specified in [RFC 3046].

The PDSN shall include a DHCP Relay Agent Information option [RFC 3046] when relaying

the DHCP messages to the server and shall set the giaddr field to the relay agent IP address.

The PDSN may support [RFC 3527] to indicate the link on which the DHCP client (i.e., MS)

resides if different from the link from which the agent is communicating with the server. The

PDSN shall identify the DHCP client based on the PPP connection over which the DHCP

messages were received.

The PDSN shall relay the DHCP messages received from the DHCP server(s) to the MS over

PPP using the address specified in the ciaddr field.

If the DHCP message received from the DHCP server is a DHCPAck message and contains a

non zero value in yiaddr field, the PDSN shall store the assigned IPv4 address and the value

in the IP address lease time option as part of the user state information and shall initiate aRADIUS Accounting-Request (start) message, which includes the assigned IPv4 address and

the NAI used during Simple IP authentication.

If the IP address lease time expires and the address has not been renewed or if the PDSN

receives a DHCP release packet from the MS, the PDSN shall remove the binding created for

that IPv4 address and shall send a RADIUS Accounting-Request (Stop). If the PPP session is

closed, the PDSN shall send a RADIUS Accounting-Request (Stop) for all the IPv4 addresses

that may have been assigned through DHCP in addition to the Accounting-Request (Stop)

required for the initial IP address assigned through IPCP.

The following figure shows a flow diagram where DHCP is used for MS configuration of

other parameters (e.g., DNS, PCSCF, BCMCS Controller addresses) after it acquired an IP

address via IPCP.


17/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


MS PDSN DHCP AAA

LCP (a)

EAP/CHAP/PAP(b) Access-Request/Accept (c)

IPCP negotiation (IPaddress) (d)

DHCP Inform (f)

DHCP Inform (g)

DHCPAck (h)

Accouting-Request (start)/ Response (e)

DHCPAck (i)

Figure 1 MS Parameters configuration with DHCP

a-d. The MS and the PDSN negotiate LCP and EAP, (or CHAP or PAP). Following the LCP

phase and successful authentication operation, the Simple IP MS shall include the IP

configuration option in the IPCP configure-request to configure its simple IPv4 address.

e. The PDSN creates a UDR for the IP address/NAI pair and sends a RADIUS Accounting-

Request (start) to the RADIUS server.

f. If the MS wants to configure other parameters using DHCP, it sends a DHCPInform with

the IP destination address set to the limited broadcast address (all 1s), assuming the MS

does not know the DHCP servers IP address.

g. The PDSN relays the DHCP packet to the DHCP server(s) as per [RFC 3046].

h. The DHCP server(s) responds by sending a DHCPAck that contains the options desired

by the MS, and may include additional options that are not specifically requested.

i. The PDSN relays the DHCPAck message to the MSs IP address over the PPP link.

3.2.1.6 Stateless DHCPv6 Support

The PDSN shall support DHCPv6 Relay Agent as specified in [RFC 3315] and [RFC 3736],

and shall set the O bit to 1 in the Router Advertisement messages sent to the MS.

Upon receiving a DHCPv6 Information-Request packet from the MS, the PDSN shall set the

peer-address field in the Relay Forward message to the source IPv6 address of the receivedDHCPv6 packet from the MS. The PDSN shall set the link address field to the global IPv6

address of the MS. Additionally the PDSN may include the Interface-Identifier option

carrying the Interface-Identifier that the MS negotiated during PPP setup.

Upon receiving DHCPv6 Relay-reply message(s) from one or more DHCPv6 servers, the

PDSN shall relay the message according to section 20.2 of [RFC 3315].

The following flow diagram shows an MS that uses stateless DHCPv6 for configuration of

parameters (e.g., DNS configuration options as specified in [RFC 3646]).


18/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

4950

51

52

53

54

55

56

57

58

59

60


MS PDSN DHCPv6 AAA

LCP (a)

EAP/CHAP/PAP(b) Access-Request/Accept(c)

IPv6CP negotiation (d)

Relay-Forward (h)

Relay-Reply (i)

Reply (j)

Accouting-Request (start)/ Response (f)RA (O-flag set) (e)

Information-Request (g)

Figure 2 Configuration of MSs parameters using DHCPv6

a-d. The MS and the PDSN negotiate LCP and EAP, (or CHAP or PAP). Following the LCP

phase and successful authentication operation, the MS and the PDSN execute IPV6CP

and negotiate unique 64-bit Interface-Identifiers.

e. The PDSN sends a Router Advertisement with prefix information and sets the O-flag to

one, to indicate to the MS that it can use DHCPv6 to configure other parameters than the

IPv6 address.

f. The PDSN creates a UDR for the IPv6 prefix/Interface-Identifier/NAI and sends a

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

g. The MS send an Information-Request message with the IP destination address set to the

All_DHCPv6_Relay_Agents_and_Servers multicast address defined in [RFC 3315]

[FF02::1:2]. The source address is the link local address created by the MS. The MS shall

include the Option Request option (ORO) to indicate which options the client is

interested in receiving.

h. The PDSN creates a Relay-forward message. The "Relay Message" option shall include

the entire Information-Request message. The PDSN sends the message to the

ALL_DHCPv6_Servers address [FF05::1:3] or to the DHCPv6 server(s) that may be

configured in the PDSN.

i. The DHCPv6 server receives the Relay-forward and replies to the relay agent with a

Relay-reply, which contains the REPLY message with all the options requested by theMS in the Option Request Option (ORO), and may include additional options.

j. The PDSN extracts the Reply message and forwards it to the MS.

3.2.1.7 Dual Stack of IPv4 and IPv6 Requirements

For dual IP stacks of IPv4 and IPv6, the single EAP/CHAP/PAP authentication is performed.

If the NCP transitions to the stopped state (either because the NCP failed to establish, or

because the NCP was torn down gracefully) and the PDSN allows the establishment of that


19/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


NCP at a later time upon the receipt of NCP configure request, the NCP shall remain in the

stopped state until a configure request from the MS is received.

3.2.1.8 Compression

The PDSN shall support the following header compression algorithm:

Van Jacobson TCP/IP header compression [RFC 1144].

The PDSN may support the following header compression algorithms:

ROHC, Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC3095] with ROHC over PPP [RFC 3241];

ROHC: A Link Layer Assisted Profile for IP/UDP/RTP [RFC 3242];

IP Header Compression [RFC 2507] with IP Header Compression over PPP [RFC2509];

Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-

Layer Assisted RObust Header Compression (ROHC) Profile [RFC 3408];

Compressing IP/UDP/RTP headers on links with high delay, packet loss andreordering [RFC 3545] with IP Header Compression over PPP [RFC 3544].

If the PDSN is able to process received compressed header packets from the MS using various

header compression protocols, the PDSN shall include the appropriate configuration option(s)

to the MS to indicate which IP Header Compression protocol it supports in the IPCP or

IPv6CP Configure-Request message as defined by [RFC 1332], [RFC 3241], [RFC 2509],

and [RFC 3544].

The PDSN shall support CCP [RFC 1962] for the negotiation of PPP payload compression.

The PDSN shall support 4F the following algorithms of PPP payload compression:

Stac-LZS [RFC 1974];

Microsoft Point-To-Point Compression Protocol [RFC 2118];

The PDSN may support other PPP payload compression algorithms.

3.2.1.9 PPP Framing

The PDSN shall frame PPP packets sent on the PPP link layer using the octet synchronous

framing protocol defined in [RFC 1662], except that there shall be no inter-frame time fill

(see 4.4.1 of [RFC 1662]). That is, no flag octets shall be sent between a flag octet that ends

one PPP frame and the flag octet that begins the subsequent PPP frame.

For IPv6, the PDSN shall set the MTU size as specified in [RFC 2460].

3.2.1.10 PPP Link Status Determination

For Always On users, the PDSN shall support the 3GPP2 vendor specific Max PPP Inactivity

Timer packet defined in PPP Vendor specific packet [RFC 2153] and the following

configurable timer and counter:

Echo-Reply-Timeout timer.

Echo-Request-Retries counter.


20/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

4950

51

52

53

54

55

56

57

58

59

60


The MAX PPP Inactivity timer packets shall be sent as LCP packets with PPP Protocol ID set

to C021(hex)

If the MS-PDSN Version Feature Indication (see section 9) is used, and the MS signaled that

it does not support the Max PPP Inactivity Timer (C4 bit set to 0), then the PDSN shall not

send the Max PPP Inactivity Timer to the MS. If the MS-PDSN Version Feature Indication

(see section 9) is used, and the MS signaled that it does not support the NCP Inactivity Timer

(C5 bit set to 0), then the PDSN shall not include any fields following the Max PPP InactivityTimer value in MAX PPP Inactivity Timer packet. The MS shall set C4 bit to 1 if the MS

sets C5 bit to 1.

The format of the Max PPP Inactivity Timer packet is shown in Figure 3 .

0 7 8 15 16 23 24 31

Code Identifier Length

Magic Number

OUI Kind

MAX PPP Inactivity timer value

Reserved 1 Number of NCP Timers

The Number of NCP Timers occurances of the following fields:

Reserved 2 NCP Type

NCP Inactivity timer

Figure 3 Max PPP Inactivity Timer Packet

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

Identifier = The Identifier field shall be changed for each Vendor Specificpacket sent. It is used to match requests with responses.

Length = >= 12 (octets)

Magic Number = The Magic-Number field is four octets and aids in detecting

links that are in the looped-back condition. Until the Magic-Number Configuration Option has been successfullynegotiated, the Magic-Number shall be transmitted as zero.See the Magic-Number Configuration Option in [RFC 1661] forfurther explanation.

OUI = 0xCF0002

Kind (1 octet) = 1, MAX PPP Inactivity Timer Packet8, Max PPP Inactivity Timer Response

Max PPP Inactivity Timer Value(4octets) =

If Kind = 1, 32-bit value = PPP inactivity time +Echo_Reply_Timeout timer (Echo_Request_Retries + 1)If Kind = 8, the Value field shall not be included.

Reserved 1 (3 octets) = Reserved bits. If Kind =1 and if this field is present, it shall beset to all zeros. If Kind = 8, this field shall not be included.

Number of NCP Timers (1 octet)=

The number of NCP Inactivity timers that are included in thispacket. If Kind =1 and if this field is present, it shall beencoded as an interger between 0 and 15. If Kind = 8, this fieldshall not be included.

If Number of NCP Timers field is present and set to a value greater than 0, there shall be Number ofNCP Timers occurrences of the following fields. Otherwise, the following fields shall not beincluded.:

Reserved 2 (3 octets) = Reserved bits. It shall be set to all zeros.

NCP Type (8 bits) = NCP Type for NCP Inactivity timer, 00000000 = IPCP,


21/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


00000001 = IPv6CP; other values are reserved.

NCP Inactivity Timer (32 bits) = NCP inactivity time in unit of second.

Upon entering the IPCP and/or IPv6CP Opened state on a PPP session configured for Always

On Service, the PDSN shall start the PPP inactivity timer for the PPP session, and unless the

MS signaled that it does not support the Max PPP Inactivity Timer, the PDSN shall send the3GPP2 vendor specific Max PPP Inactivity Timer packet [RFC 2153] over the main service

connection. The PDSN should resend the Max PPP Inactivity Timer packet a configurable

number of times if no response from the MS is received. The Max PPP Inactivity Timer Value

field shall be equal to [PPP inactivity timer + Echo_Reply_Timeout timer

(Echo_Request_Retries + 1)] for the PPP session. The PDSN shall reset the PPP inactivity

timer upon detection of traffic activity.

When the MS that complies with this revision of document or later revisions receives the Max

PPP Inactivity Timer packet from the PDSN, the MS shall send the Max PPP Inactivity Timer

Response packet to the PDSN.

If the PPP inactivity timer value, Echo-Reply-Timeout timer and/or Echo-Request-Retries

counter have changed by an administrative action, the PDSN shall send the 3GPP2 vendor

specific Max PPP Inactivity Timer packet over the main service connection.

Upon expiration of the PPP inactivity timer, the PDSN shall send an LCP Echo-Request

message [RFC 1661] over the main service connection, and start the Echo-Reply-Timeout

timer for the PPP session. It shall also initialize the Echo-Request-Retries counter to a

configurable integer value.

Upon receipt of an LCP Echo-Reply message, an LCP Code-Reject [RFC 1661], or any other

packets over the main service connection or secondary service connection(s), the PDSN shall

stop and reset the Echo-Reply-Timeout timer, reset the Echo-Request-Retries counter, and

reset the PPP inactivity timer.

Upon expiration of the Echo-Reply-Timeout timer and when the Echo-Request-Retries

counter value is greater than zero, the PDSN shall send an LCP Echo-Request message,

decrement the Echo-Request-Retries counter by one, and start the Echo-Reply-Timeout timer.Upon expiration of the Echo-Reply-Timeout timer and when the Echo-Request-Retries

counter value is equal to zero, the PDSN shall close the PPP session. In this case, the PDSN

shall not send an LCP Terminate-Request to the MS.

Upon establishing IPv4 and IPv6 simultaneous sessions, the PDSN may send the MAX PPP

Inactivity Timer packet containing the NCP Inactivity timer field if the MS has indicated that

it supports this version (i.e., version field in version/capability packet is set to 1) and the Max

PPP Inactivity Timer and NCP Inactivity Timer (C4 and C5 are set to 1, see section 9). When

the NCP Inactivity timer is sent, the PDSN shall indicate the NCP type that the NCP

Inactivity timer applies. The NCP Inactivity timer shall apply to NCP identified in the NCP IP

Version field. If the NCP Inactivity timer is provided, both the PDSN and the MS shall

maintain the NCP Inactivity timer for the NCP identified in the NCP type field. If this timer

expires, the PDSN and the MS shall close that NCP and may send the IPCP-Term Request or

IPv6CP-Term-Request for the correspondingNCP depending on the operators policy.

The PDSN may send the MAX PPP Inactivity timer packet with new values if needed. If a

MAX PPP Inactivity Timer packet with new values is received, the MS shall override the

timer values. The NCP Inactivity timer value that is not included in the MAX PPP Inactivity

Timer packet shall not be affected.

If the NCP that does not have an associated NCP Inactivity timer is terminated, the remaining

NCP Inactivity timer(s) shall not be impacted in the PDSN and MS.


22/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

4950

51

52

53

54

55

56

57

58

59

60


The PDSN and MS shall reset the NCP inactivity timer upon detection of traffic activity over

the corresponding NCP.

3.2.2 RADIUS Support

The PDSN shall act as a RADIUS client in accordance with [RFC 2865] and shall

communicate EAP, CHAP or PAP authentication information to the Visited RADIUS serverin a RADIUS Access-Request message. Upon receipt of the EAP, CHAP or PAP response

from the MS, the PDSN shall create a RADIUS Access-Request message in accordance with

Table 1.

If EAP is used for authentication, the PDSN shall also support the following RFCs:

RFC 3579, RADIUS (Remote Authentication Dial In User Service) Support ForExtensible Authentication Protocol (EAP),

RFC 2548, Microsoft Vendor-specific RADIUS Attributes.

For EAP authentication, when the Session-Timeout attribute is present in a RADIUS Access-

Accept message, the PDSN shall use it to set the EAP session lifetime.

Table 1 Occurrence of RADIUS Attributes for Simple IP

Attribute Name Type Access-Request

Access-Accept

Access-Challenge

Interface(s)

User-Name 1 M M PDSN AAA

User-Password 2 O Note 1 PDSN -> AAA

CHAP-Password 3 O Note 2 PDSN -> AAA

NAS-IP-Address 4 O Note 3 PDSN -> AAA

MS-MPPE-Send-Key 26/16(VendorType =311)

O PDSN AAA

Always On 26/78 O PDSN AAA

Carrier-ID 26/142 M PDSN->AAA

IP-Services-Authorized 26/185 O PDSN


23/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


(M) Indicates Mandatory Attribute

(O) Indicates Optional Attribute

Note 1: User-Password is mandatory if PAP.

Note 2: CHAP-Password is mandatory if CHAP.

Note 3: At least one of NAS-IP-Address or NAS-IPv6-Address shall be included.

Additional RADIUS attributes and VSAs may be included in the RADIUS Access-Request

and returned in the RADIUS Access-Accept messages as per [Chapter 5].

The Correlation ID VSA and Always On VSA are in addition to those fields specified by

[RFC 2865] and [RFC 3162].

The PDSN shall also act as a RADIUS accounting client in accordance with [RFC 2866] and

shall communicate user accounting information to the Visited RADIUS server in RADIUS

Accounting-Request (Start and Stop) records. The RADIUS Accounting-Request message

shall contain the accounting attributes as specified in [Chapter 5]. The PDSN may also send

RADIUS Accounting-Request (Interim-Update) records between the Accounting-RequestStart and Stop messages as necessary in accordance with Annex A of [Chapter 5].

The security of communications between the PDSN and the RADIUS server may optionally

be provided with IP security. The establishment of the security association is outside the

scope of this document.

When the PDSN sends a RADIUS Access-Request message, it may include both IPv4 and

IPv6 specific attributes and/or VSAs. This is because the PDSN may not know a priori

whether the MS intends to use IPv4, IPv6, or both, since the address assignment does not

occur until after RADIUS authentication and authorization has completed. As per [RFC 3162],

the IPv6 attributes may be sent along with IPv4-related attributes within the same RADIUS

message. The PDSN decides to use IPv4 and/or IPv6 specific attributes and/or VSAs that it

receives in the RADIUS Access-Accept message based on whether the MS initiates IPCP

and/or IPv6CP.

3.2.2.1 NAI Construction in the Absence of EAP, CHAP or PAP

In the event that the MS does not negotiate EAP, CHAP or PAP, no MS NAI is received by

the PDSN. In this case, the PDSN shall not perform additional authentication of the user. If

the PDSN is capable of constructing a properly formatted NAI based on the MSID, using the

syntax defined in [RFC 2486], then accounting records shall be generated and keyed on the

users constructed NAI. The NAI shall be constructed using the syntax defined in [RFC 2486],

in the form @, where is the MSID of the MS, and is thename of the home network that owns the MSs MSID. If the PDSN is unable to construct an

NAI for an MS, then the PDSN may deny service to the MS.

The PDSN shall use one of the following MSID formats to construct the NAI, as provided by

the RAN:

International Mobile Subscriber Identity (IMSI) [E.212];

Mobile Identification Number (MIN) [3];

International Roaming MIN (IRM) [2].

The PDSN shall store the constructed NAI into the accounting records, and the Visited

RADIUS server may use the realm to forward these records to the correct Home RADIUS


24/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

4950

51

52

53

54

55

56

57

58

59

60


server for proper summary and settlement6. The constructed NAI shall not be used for

authentication. If configured by the operator, the PDSN shall send RADIUS accounting

messages to the Visited RADIUS server using the constructed NAI in the absence of EAP,

CHAP or PAP.

3.2.3 Ingress Address Filtering

For IPv4, the Serving PDSN shall check the source address of every packet received on the

PPP link from the MS.

Upon receiving a packet from the MS with invalid7

source IP address, the PDSN shall discard

the packet and may send an LCP Configure-Request message to restart the PPP session8

if

IPCP has reached the open state.

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

invalid source IP address from the MS, the PDSN shall send an LCP Configure-Request

message to the MS.

If the PDSN receives a DHCP packet over port 67, the PDSN shall forward the message to the

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

For MIP4 and simultaneous Simple IP and MIP4 sessions see section 4.2.5.

For IPv6, the Serving PDSN shall check the prefix of the source IP address of every packet

received on the PPP link from the MS. If the prefix is not associated with the PPP Session of

the MS, then the PDSN shall discard the packet and may send an LCP Configure-Request to

restart the PPP session. If the PDSN receives an implementation-defined number of

consecutive packets with an invalid prefix from the MS, the PDSN shall send an LCP

Configure-Request message to the MS. If the source address is the IPv6 unspecified address

and the message type is Neighbor Solicitation for Duplicate Address Detection (DAD), then

the PDSN shall silently discard the packet received from the MS. If the source address is the

IPv6 unspecified address for purposes other than Duplicate Address Detection (DAD) or the

source address is the MSs IPv6 link-local address, the PDSN shall respond according to

[RFC 2461].

6 The Home RADIUS server may require an MSID to user conversion table to map the constructed NAI(msid@realm) to the user's actual NAI (user@realm) to complete the billing process in cases where theconstructed NAI differs from the actual NAI.7 The source IP address from the MS is considered as invalid if it is not one of the addresses that havebeen assigned to the MS or if the MS has not been assigned any IP addresses.8 The reason to restart PPP is because the user could have started a Simple IP session during a previousdormant handoff to another PDSN and returned; in this case the current PDSN would not know the MShad invoked Simple IP and received another IP address. Thus, restarting PPP will force the Simple IP

session to get a topologically correct address.
mailto:msid@realmmailto:msid@realmmailto:msid@realmmailto:user@realmmailto:user@realmmailto:user@realmmailto:user@realmmailto:msid@realm


25/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


3.3 RADIUS Server Requirements

The RADIUS server shall follow the guidelines specified in [RFC 2865], [RFC 2866], [RFC

3162], [RFC 3576], [RFC 3579], [RFC 3748], and [RFC 4187].

The Visited and Home RADIUS server shall support the attributes as specified in Table 1 and

[Chapter 5], the Interim Accounting Record as described in Annex A of [Chapter 5] as well as

the accounting attributes listed in [Chapter 5].

The Home RADIUS server may include the Always On attribute in the RADIUS Access-

Accept message to indicate an Always On Service for a user, based on the User Profile.

If the MS uses EAP, CHAP or PAP, the PDSN sends the Visited RADIUS server a RADIUS

Access-Request message with EAP, CHAP or PAP authentication information. The Visited

RADIUS server shall forward the RADIUS Access-Request message to the home network or

a peer (e.g., a broker) if it does not have the authority to accept/deny the request. This is in

accordance with [RFC 2865]. Upon receiving a RADIUS Access-Request message, the Home

RADIUS server shall send a RADIUS Access-Accept message, RADIUS Access-Challenge

message, or RADIUS Access-Reject message to the Broker or Visited RADIUS server. The

Visited RADIUS server shall send the received response to the PDSN.

If EAP-AKA is used for authentication, the AAA server may support the anonymity featurewith pseudonyms in EAP-AKA. If the EAP-AKA authentication is successful, the AAA

server shall derive the MSK according to [RFC4187]. The AAA server shall send the MSK to

the PDSN via the MS-MPPE-Recv-Key attribute (for the first 32 bytes of the MSK) and MS-

MPPE-Send-Key attribute (for the second 32 bytes of the MSK) in the RADIUS Access-

Accept message. The HAAA shall also send the EAP session lifetime in seconds via the

Session-Timeout attribute in the RADIUS Access-Accept message.

If the RADIUS Access-Request message contains IPv4 and IPv6 specific attributes and/or

VSAs, the RADIUS server should include the IPv4 and/or IPv6 attributes as provisioned in

the user profile (e.g. Framed-Interface-Id, Framed-IPv6-Prefix etc.) and/or VSAs in the

RADIUS Access-Accept message.

Upon receiving RADIUS Accounting-Request records from the PDSN, the Visited RADIUS

server shall forward the RADIUS Accounting-Request records to the home or broker network.

The communication between RADIUS client and RADIUS server or between RADIUS

servers shall be protected using the secret shared with the next hop RADIUS server using the

procedures described in [RFC 2865].

3.4 MS Requirements

The MS may support Simple IP. The MS may choose Simple IP for IPv4 only, IPv6 only, or

both IPv4 and IPv6 simultaneously. The MS shall access the cdma20009

packet data service

using the cdma2000 air interface [5-9], [15].

3.4.1 PPP Session

The MS shall use PPP as the data link layer protocol for Simple IP.

9 cdma2000 is the trademark for the technical nomenclature for certain specifications and standards ofthe Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication),cdma2000 is a registered trademark of the Telecommunications Industry Association (TIA-USA) in

the United States.


26/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

4950

51

52

53

54

55

56

57

58

59

60


3.4.1.1 Establishment

If the cdma2000 1x MS supports multiple service connections, refer to [Chapter 4] for details

of PPP negotiation. Otherwise, for a new PPP session, the cdma2000 1x MS shall use a

service instance of SO type 33 to perform PPP negotiation with the PDSN as described in

[RFC 1661].

If the HRPD MS supports multiple link flows, refer to [Chapter 4] for details of PPPnegotiation. Otherwise, for a new PPP session, the HRPD MS shall use the main link flow

with default reservation label 0xff to perform PPP negotiation with the PDSN as described in

[RFC 1661].

PPP shall support control escaping in accordance with section 4.2 of [RFC 1662]. The PPP

Link Layer shall support negotiation of Asynchronous Control Character Mapping as defined

in [RFC 1662]. The MS should attempt the minimum number of escapes by negotiating an

ACCM of 0x00000000. The MS should not send an LCP Configure-Reject in response to an

ACCM configuration option proposed by the PDSN in an LCP Configure-Request.

3.4.1.2 Termination

When the MS deactivates packet data service, the MS should send an LCP Terminate-Request

message to the PDSN to gracefully close the PPP session before releasing the packet data

service connections with the RAN. In the case of power-down registration [5-9], the MS shall

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

3.4.1.3 Authentication

The MS shall support EAP and CHAP and may support PAP authentication for Simple IP.

During the PPP session negotiation between the MS and the PDSN, if the MS receives LCP

Configure-Request from the PDSN that contains EAP or CHAP, the MS shall respond with

LCP Configure-Ack indicating to the PDSN the acceptance of EAP or CHAP. If the MS

receives LCP Configure-Request from the PDSN that contains PAP, the MS shall respond

with LCP Configure-Ack indicating to the PDSN the acceptance of PAP if the MS supports

PAP.

If the MS is configured not to use any of EAP, CHAP or PAP, the MS shall respond with an

LCP Configure-Reject message containing the Authentication-Protocol option proposed in the

LCP Configure-Request message received from the PDSN.

If the MS is configured to use CHAP, it shall respond to an LCP Configure-Request message

for EAP with an LCP Configure-Nak proposing CHAP.

If the MS is configured to use PAP, it shall respond to an LCP Configure-Request message

for EAP or CHAP with an LCP Configure-Nak proposing PAP.

For both CHAP and PAP, the MS shall send an NAI in the form of user@realm.

3.4.1.3.1 EAP-AKA Support

The MS shall support EAP-AKA [RFC 4187]. The MS may support the anonymity feature

with pseudonyms in EAP-AKA. If the MS receives the EAP-Identity request from the

network, it shall respond with an AKA permanent identity or an identity associated with the

AKA permanent identity.

3.4.1.4 Addressing with IPCP

The MS may support simultaneous operation of IPCP and IPv6CP.


27/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60


The MS shall negotiate the IP address configuration option to acquire an IPv4 address from

the PDSN.

The MS may implement [RFC 1877] in order to auto-configure DNS server IP addresses. The

MS may negotiate Primary and Secondary DNS server IP addresses during the IPCP phase.

The MS may use default of zero for DNS server address negotiation.


A Simple IPv4 MS should send an IP address of 0.0.0.0 during the IPCP phase to request an

IP address from the network. The MS shall accept the address provided by the PDSN. If the

MS requests a non-zero IP address during the IPCP phase, the PDSN replies with an IPCP

Configure-Nak in response to the request in order to propose a different IP address. The MS

shall accept the new address, and shall send an IPCP Configure-Request to the PDSN with the

new IP address.


A Simple IPv6 MS shall support the following RFCs, with exceptions as noted in this

document:

An IPv6 Aggregatable Global Unicast Address Format [RFC 3587]; Internet Protocol, Version 6 (IPv6) Specification [RFC 2460];

Neighbor Discovery for IP Version 6 (IPv6) [RFC 2461];

IPv6 Stateless Address Auto-configuration [RFC 2462];

Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6(IPv6) Specification [RFC 2463];

IP Version 6 over PPP [RFC 2472];

IP Version 6 Addressing Architecture [RFC 3513].

The MS should support Privacy Extensions for Stateless Address Auto-configuration in IPv6

[RFC 3041]. To avoid disruption of an active session, e.g., Voice over IP, the MS should notchange the IPv6 address used for that session.

For IPv6, the MS shall perform Interface-Identifier negotiation as described in [RFC 2472].

The MS shall construct the link-local IPv6 address by pre-pending the link-local prefix FE80::

/64 [RFC 3513] to the Interface-Identifier negotiated during the IPv6CP negotiation phase

[RFC 2472]. When the Interface-Identifier is negotiated in the IPv6CP phase of the PPP

session setup, the MS should not perform duplicate address detection for the link local address

as part of IPv6 stateless address auto-configuration [RFC 2462].

The MS shall construct global IPv6 address by pre-pending the prefix received from the

Router Advertisement messages to the Interface-Identifier negotiated during the IPv6CP

negotiation phase [RFC 2472] or to the Interface-Identifiers generated using techniques

defined in [RFC3041]. The MS should not perform Duplicate Address Detection for global

IPv6 addresses (since the prefix used is a globally unique /64 and exclusive to the PPP

session).

Following the successful IPv6CP phase and auto-configuration of link-local address, the MS

may transmit a Router Solicitation (RS) message(s) if a Router Advertisement message has

not been received from the PDSN within a random amount of time between 0 and

MAX_RTR_SOLICITATION_DELAY seconds per [RFC 2461].

The MS may set the upper bound of the delay to a value greater than that specified by the

constant MAX_RTR_SOLICITATION_DELAY in [RFC 2461]. The MS may also set the


28/116


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

3536

37

38

39

40

41

42

43

44

45

46

47

48

4950

51

52

53

54

55

56

57

58

59

60


lower bound of the delay to a value greater than 0. The MS may set the configurable number

of RS messages to a value less10

than that specified by the constant

MAX_RTR_SOLICITATIONS in [RFC 2461]. The MS may set the interval between the

configurable number of RS messages to a value less254H11 than or greater than that specified

by the constant RTR_SOLICITATION_INTERVAL in [RFC 2461].

If the last RS message is sent and a RA message is not received after a router solicitation

interval, the MS shall send an IPv6CP Configure-Terminate message to the PDSN. Uponreception of a RA message from the PDSN that contains the /64 globally unique prefix, the

MS shall perform stateless address auto-configuration for global IPv6 addresses as per [RFC

2462] (and [RFC 3041] for privacy purposes).

After establishment of a PPP link with the PDSN, the MS shall treat that PDSN as the default

router until the PPP session is closed.

3.4.1.5 DHCPv4 Support

The MS may support and use DHCP [RFC 2131] to request specific configuration parameters

[RFC 2132], which may include DNS addresses and/or SIP server addresses [RFC 3361].The

MS should not use DHCP [RFC 2131] to request additional IPv4 addresses.

To request specific configuration parameters, the MS shall send a DHCPInform message tothe limited broadcast address (all 1s) or to a DHCP servers address if it knows one. The MS

shall set the ciaddr field to its IPv4 address acquired during IPCP and shall include the

parameter request list option to indicate the options the MS is interested in receiving and may

include a vendor class option to request vendor specific information options.

3.4.1.6 Stateless DHCPv6 Support

The MS may support stateless DHCPv6 [RFC 3736] to obtain configuration information. The

MS should not use DHCPv6 [RFC 3736] to request additional IPv6 addresses. If the MS

supports stateless DHCPv6, and wants to obtain configuration information, it shall send a

DHCPv6 Information-Request message to the All_DHCP_Relay_and_Servers address

[FF02::1:2] and shall include the Option Request option to specify the options that it wishes

to receive from the DHCPv6 server, for example DNS configuration options [RFC 3646], SIPserver options [RFC 3319], and BCMCS Controller option [RFC 4280].

3.4.1.7 Compression

The MS shall support Van Jacobson TCP/IP header compression [RFC 1144]. The MS

additionally may support the following header compression

Documents

Cdma2000 Sip Mip Standard