Method for Preventing Ip Address From Unexpected Dispersion When Using Point-To-Point Protocol

• US 20070245405A1
• Filed: 07/05/2005
• Published: 10/18/2007
• Est. Priority Date: 07/08/2004
• Status: Active Grant

• Current Assignee: ZTE Corporation
• Original Assignee: ZTE Corporation
• Inventors: Cao, Wenli
• Granted Patent: US 8,533,779 B2
• Time in Patent Office: Days
• US Class Current: 726/3
• CPC Class Codes: H04L 12/2856 Access arrangements, e.g. Internet access asynchronous transfer mode networks H04L12/5601; broadband local area networks H04L12/2801; optical access or distribution networks H04Q11/0067; access to open networks H04L12/5691; digital subscriber line end-user equipment and bit-level processing of data on a PSTN-based network H04M11/00; home network gateways H04L12/2834; wireless access networks H04W
• CPC Class Codes: H04L 12/2859 Point-to-point connection between the data network and the subscribers encapsulation H04L12/4633; virtual LANs H04L12/4641; routing of packets H04L45/00
• CPC Class Codes: H04L 61/5007 Internet protocol [IP] addresses
• CPC Class Codes: H04L 61/5053 Lease time; Renewal aspects
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/0892 by using authentication-authorization-accounting [AAA] servers or protocols
• CPC Class Codes: H04L 69/324 in the data link layer [OSI layer 2], e.g. HDLC

Abstract

A method for preventing IP address from unexpected dispersion when using point-to-point protocol is disclosed. The method comprises the steps: starting and initializing a PPP session; performing a PPP LCP negotiation, in which times of the successful PPP LCP negotiation is limited; performing a PPP authentication, in which an authentication request to AAA client is sent only once; performing a PPP IPCP negotiation, in which an accounting-start request is sent only once and times of the successful PPP IPCP negotiation is limited; and terminating the PPP session and releasing the IP address. The method of the invention for preventing IP address from unexpected dispersion when using point-to-point protocol effectively avoid excessive oscillation of a LCP state machine and a IPCP state machine by limiting times of the successful PPP LCP negotiation during the period of PPP LCP negotiation and times of the successful PPP IPCP negotiation. In the meantime, the method the invention effectively solves the problem of IP address unexpected dispersion by sending an authentication request to an AAA client only once during the PPP authentication phase and ensuring that the PPP session sends an accounting-start request only once.

Claims

1. A method for preventing IP address from unexpected dispersion when using point-to-point protocol, the method comprising

limiting times of successful PPP LCP negotiation in PPP LCP negotiation phase,

sending an authentication request to a AAA client only once in PPP authentication phase,

sending an accounting-start request only once in IPCP negotiation phase, and

limiting times of successful PPP IPCP negotiation in IPCP negotiation phase.

2. The method as claimed in claim 1, further comprising

a) starting and initializing a PPP session;

b) performing a PPP LCP negotiation between a terminal of customers and the PPP session, in which times of the successful PPP LCP negotiation is limited;

c) performing a PPP authentication in order to assign a IP address from the AAA client only once by sending an authentication request to the AAA client only once;

d) performing a PPP IPCP negotiation between the PPP and the terminal of customers, in which an accounting-start request is sent only once and times of successful PPP IPCP negotiation is limited;

e) releasing the IP address after the PPP session is terminated.

3. The method as claimed in claim 2, wherein the step of initializing the PPP session comprises

providing an authentication success flag and setting “

FAILURE”

for the initialized value of the authentication success flag;

providing sending accounting-start request flag and setting “

NOT SENT”

for the initialized value of the sending accounting-start request flag;

recording a count of successful LCP negotiation and clearing the count of successful LCP negotiation;

recording a count of successful IPCP negotiation and clearing the count of successful_IPCP negotiation; and

providing a flag for sending authentication request to AAA client and setting “

NOT SENT”

for the initialized value of the flag for sending authentication request to AAA client.

4. The method as claimed in claim 1, wherein the step of performing the PPP LCP negotiation between a terminal of customers and the PPP comprises

determining whether LCP negotiation is successful;

adding 1 to the count of successful LCP negotiation if the LCP negotiation is determined to be successful;

otherwise, terminating the PPP session;

determining whether the count of successful LCP negotiation exceeds an allowed maximum times so that the PPP authentication could be activated if not or the PPP session could be activated if so.

5. The method as claimed in claim 4, wherein the LCP negotiation is determined to be successful if the state of PPP LCP state machine is “

OPENED”

.

6. The method as claimed in claim 4, wherein the allowed maximum times of successful LCP negotiation is 3.

7. The method as claimed in claim 2, wherein the step of performing a PPP authentication comprises

sending an authentication request to the AAA client;

checking the authentication success flag for determining whether the authentication is successful or not;

sending a successful authentication packet to the terminal for response the customer if the authentication is successful to activate the PPP IPCP negotiation;

checking the flag for sending authentication request to AAA client and further determining whether the value of the flag is “

SENT”

;

sending the authentication request to the AAA client and setting “

SENT”

for the value of the flag for sending authentication request to AAA client if the value of the flag for sending authentication request to AAA client is not “

SENT”

;

waiting for the result of the authentication replied by the AAA client if the value of the flag is “

SENT”

;

determining whether the result of authentication request returned from the AAA client is successful or not;

checking whether the state of the LCP state machine is “

OPENED”

if the result of authentication request is determined to be successful;

informing the AAA client to release IP address if the state of the LCP state machine is not “

OPENED”

to terminate the PPP session;

setting “

SUCCESS”

for the value of a authentication success flag and send a successful authentication packet to the customer;

activating the PPP session termination procedure.

8. The method as claimed in claim 2, wherein, the step of performing a PPP IPCP negotiation between the PPP and the terminal of customers comprises

activating the IPCP negotiation procedure;

determining whether the IPCP negotiation is successful or not;

adding 1 to the count of successful IPCP negotiation if the IPCP negotiation is determined to be successful;

determine whether the count of successful IPCP negotiation exceeds an allowed maximum times or not;

checking a sending accounting-start request flag if the count of successful IPCP negotiation does not exceed the allowed maximum times;

otherwise, terminating the PPP session;

determining whether a sending accounting-start request has been already sent;

setting “

SENT”

for the sending accounting-start request flag at first and sends accounting-start request to the AAA client if the sending accounting-start request has not been sent;

otherwise, not proceeding with any process.

9. The method as claimed in claim 8, wherein the IPCP negotiation is determined to be successful if the state of PPP IPCP state machine is “

OPENED”

.

10. The method as claimed in claim 8, wherein the allowed maximum of successful IPCP negotiation is 3.

11. The method as claimed in claim 2, wherein the step of releasing the IP address comprises

closing PPP session;

checking the authentication success flag and further determining whether the value of the authentication success flag is “

SUCCESS”

;

checking the flag for sending accounting-start request in order to determine whether the Accounting-Start request has been already sent if the value is determined as “

SUCCESS”

;

otherwise, releasing the PPP session;

sending an accounting-stop request to the AAA client and releasing the IP address at the same time if the accounting-start request has been already sent;

sending an accounting-reject request and releasing the IP address at the same time if the Accounting-Start request has not been already sent;

releasing the PPP session.

12. The method as claimed in claim 5, wherein the allowed maximum times of successful LCP negotiation is 3.

13. The method as claimed in claim 9, wherein the allowed maximum of successful IPCP negotiation is 3.