WO2006005249A1 - Procede servant a empecher la dispersion d'adresses ip quand on utilise un protocole point-a-point - Google Patents

Procede servant a empecher la dispersion d'adresses ip quand on utilise un protocole point-a-point Download PDF

Info

Publication number
WO2006005249A1
WO2006005249A1 PCT/CN2005/000983 CN2005000983W WO2006005249A1 WO 2006005249 A1 WO2006005249 A1 WO 2006005249A1 CN 2005000983 W CN2005000983 W CN 2005000983W WO 2006005249 A1 WO2006005249 A1 WO 2006005249A1
Authority
WO
WIPO (PCT)
Prior art keywords
ppp
negotiation
successful
point
authentication
Prior art date
Application number
PCT/CN2005/000983
Other languages
English (en)
French (fr)
Inventor
Wenli Cao
Original Assignee
Zte Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zte Corporation filed Critical Zte Corporation
Priority to US11/571,739 priority Critical patent/US8533779B2/en
Publication of WO2006005249A1 publication Critical patent/WO2006005249A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H04L12/2858—Access network architectures
    • H04L12/2859—Point-to-point connection between the data network and the subscribers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5053—Lease time; Renewal aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Definitions

  • the present invention relates to a network access technology, and in particular, to a method for preventing IP (Internet Protocol) address leakage when using PPP (The Point-to-Point Protocol). Background technique
  • PPP access has become the mainstream broadband access application mode, especially the PPPoE (PPP Over Ethernet, point-to-point protocol on Ethernet) technical specifications have been widely supported, and now become the broadband connection preferred by broadband access operators. Into the way.
  • PPPoE PPP Over Ethernet, point-to-point protocol on Ethernet
  • the IP address allocation process of the PPP session is implemented by the broadband access server.
  • the PPP session allocates an IP address through AAA (Authentication, Authorization, Account, Authentication, Authorization, and Accounting) client authentication, and sends a charging stop request. Or the charge reject request to release the IP address.
  • AAA Authentication, Authorization, Account, Authentication, Authorization, and Accounting
  • the billing start request is sent after the PPP IPCP (PPP IP Protocol) negotiation is completed.
  • the billing stop request can be sent after the billing start request is sent.
  • the charging rejection request is sent when the PPP session is abnormal before the charging start request is sent.
  • the charging rejection request is only a local exception processing process, and is not sent to the RADIUS (Remote Authentication Dial In User Service) server.
  • the billing package is not a RADIUS protocol standard.
  • the IP address leakage problem of the PPP session often occurs, resulting in a decrease in the available IP addresses of the users, and even no IP addresses are available.
  • the reason for this problem lies in the complexity of the PPP state machine.
  • the AAA client After the LCP (Link Control Protocol) negotiation phase and the authentication phase are completed, the AAA client has assigned the IP address to the user, but in the LCP and IPCP.
  • the negotiation packet is retransmitted, the LCP and the IPCP state machine are oscillated. That is, a PPP session is repeatedly negotiated, resulting in multiple authentication processes for one PPP session, thereby allocating multiple IP addresses to the user, resulting in IP address leakage.
  • the present invention provides a method for preventing IP address leakage when using a point-to-point protocol, wherein, in the PPP LCP negotiation process, the number of successful PPP LCP negotiation is limited, and/or in the PPP authentication process. Only the authentication request is sent to the AAA client once, and/or the IPCP guarantees that only the charging start request is sent once, and the number of successful PPP IPCP negotiation is limited.
  • Step 1 Start a PPP session, and initialize the PPP session.
  • Step 2 Perform PPP LCP negotiation
  • Step 3 Perform PPP authentication; - Step 4, perform PPP IPCP negotiation;
  • Step 5 Terminate the PPP session and release the IP address.
  • the above method for preventing IP address leakage when using a point-to-point protocol includes:
  • the value of initializing the authentication success flag is unsuccessful
  • the value of the initial transmission charging start request flag is not sent
  • the value of initializing the sending of the authentication request flag to the AAA client is not sent.
  • step 2 specifically includes the following steps:
  • Step 201 Determine whether the LCP negotiation is successful. If the process proceeds to step 202 successfully, if not, proceed to step 5;
  • Step 202 the count of successful LCP negotiation is increased by 1;
  • Step 203 Determine whether the count of successful LCP negotiation exceeds the maximum allowed number. If it exceeds the step 5, if not, the process proceeds to step 3.
  • the above method for preventing IP address leakage when using a point-to-point protocol wherein the flag of whether the LCP negotiation is successful is whether the PPP LCP state machine is in an open state.
  • step 3 specifically includes the following steps:
  • Step 301 Receive an authentication request.
  • Step 302 check the authentication success flag, and determine whether the success or failure; if successful, proceed to step 303, if the failure proceeds to step 304;
  • Step 303 Send an authentication success packet to the user and return.
  • Step 304 check to send an authentication request flag to the AAA, and determine whether the value is sent, if not, proceed to step 305, and if yes, proceed to step 306;
  • Step 305 Send an authentication request, and set to send an authentication request flag to the AAA as already sent; Step 306, wait for the authentication result to return;
  • Step 307 determining whether the returned authentication result is successful, if not successfully entering step 311, if successful, proceed to step 308;
  • Step 308 determining whether the LCP state machine is in an open state, if yes, proceeding to step S310, if not proceeding to step S309;
  • Step 309 notifying the AAA to release the IP address and returning;
  • Step 310 Set an authentication success flag, send an authentication success packet to the user, and proceed to step 4; Step 311, go to step 5.
  • step 4 specifically includes the following steps:
  • Step 401 entering IPCP negotiation
  • Step 402 Determine whether the IPCP negotiation is successful. If the process proceeds to step 403 successfully, if it is not successful, the process proceeds to step;
  • Step S403 the count of successful IPCP negotiation is increased by 1;
  • Step S404 determining whether the count of successful IPCP negotiation exceeds the maximum allowed number, if not exceeding the step 405, if yes, proceeding to step 5;
  • Step 405 Check a sending charging start request flag.
  • Step S406 determining whether an accounting start request has been sent, if the charging start request has been sent, returning; if not entering step 407;
  • Step 407 setting a sending charging start request flag, and sending the charging start to the AAA client. Request.
  • the above method for preventing IP address leakage when using a point-to-point protocol wherein the flag of whether the IPCP negotiation is successful is whether the IPCP state machine is in an open state.
  • step 5 specifically includes the following steps:
  • Step 501 Remove the PPP session.
  • Step 502 check the authentication success flag, and determine whether the value is successful, if it is to proceed to step 503, if not proceed to step 506;
  • Step 503 check the transmission charging start request flag, and determine whether the charging start request is sent, if it has been sent, proceed to step 504, if not, proceed to step 505;
  • Step 504 Send a charging end request, and release the IP address at the same time;
  • Step 505 Send a charging rejection request, and release the IP address at the same time;
  • Step 506 releasing the PPP session entity.
  • the method for preventing IP address leakage when using the point-to-point protocol of the present invention effectively prevents the LCP state machine and IPCP by limiting the number of successful PPP LCP negotiations in the PPP LCP negotiation process and limiting the number of PPP IPCP negotiation successes.
  • the state machine has too many oscillations and excessive oscillations.
  • only the authentication request is sent to the AAA client, and the IPCP guarantees that only the charging start request is sent once, which effectively solves the problem of IP leakage.
  • FIG. 1 is a schematic diagram of an IP address allocation process of a PPP session in the prior art
  • Figure 2 is a flow chart showing the operation of the present invention
  • FIG. 5 is a flow chart of PPP IPCP negotiation of the present invention.
  • FIG. 7 is a schematic diagram of a PPP session state machine of the present invention. detailed description
  • the invention is used to prevent the IP address of the PPP session from being leaked, and the access server can correctly allocate the IP address of the PPP session, and the access server can reliably provide the PPP service.
  • the implementation steps of the present invention are as shown in FIG. 2, and include the following steps:
  • Step S1 starting a PPP session, and performing initialization of the PPP session
  • Step S2 Perform PPP LCP negotiation, and limit the number of times the PPP LCP negotiation succeeds in the negotiation process
  • Step S3 Perform PPP authentication. In the authentication process, only the IP address is assigned to the AAA client once.
  • Step S4 Perform PPP IPCP negotiation. In the negotiation process, only the charging start request is sent once, and the number of times the PPP IPCP negotiation succeeds is limited.
  • Step S5 terminating the PPP session, and releasing the IP address.
  • Step S1 is equivalent to the link up phase
  • step S2 is equivalent to the link establishment phase
  • step S3 is equivalent to the authentication phase
  • step S4 is equivalent to the network layer phase
  • step S5 is equivalent to the link termination phase.
  • the flags and counts for the PPP session are initialized, and after a resource is allocated for a PPP session, initialization is performed.
  • the present invention uses the following flags and counts during a PPP session:
  • the authentication success flag indicates whether the PPP session has been successfully authenticated.
  • the LCP negotiation succeeds in counting, indicating the number of times the LCP negotiation succeeds in the PPP session, that is, the number of times the LCP state is up (up);
  • the IPCP negotiation succeeds in counting, indicating the number of successful IPCP negotiation of the PPP session, that is, the number of times the IPCP state machine is up (up);
  • An authentication request flag is sent to the AAA client, indicating whether the PPP session has sent an authentication request to the AAA client.
  • step S1 the initialization of the PPP session specifically includes the following content: The value of the initial authentication success flag is unsuccessful; The value of the initial transmission charging start request flag is not sent;
  • the value of initializing the sending of the authentication request flag to the AAA client is not sent.
  • the PPP LCP negotiation specifically includes the following steps:
  • Step S201 entering LCP negotiation
  • step S202 it is determined whether the negotiation is successful, and the process proceeds to step S203. If the process is unsuccessful, the process proceeds to step S206.
  • the sign of the negotiation success is that the PPP LCP state machine has reached the Opened state;
  • Step S203 adding a count of successful LCP negotiation
  • Step S204 determining whether the count exceeds the maximum number of times allowed, wherein the maximum allowable number of times is 3, if it exceeds the step S206, if not, then proceeds to step S205;
  • Step S205 entering the authentication process, that is, step S3;
  • Step S206 entering a PPP session termination process, that is, step S5.
  • step S3 specifically includes the following steps:
  • Step S301 receiving an authentication request
  • Step S302 checking the authentication success flag, and determining whether the success or failure; if successful, the process proceeds to step S303, if the failure proceeds to step S304;
  • Step S303 sending an authentication success packet to the user, and then proceeds to step S4;
  • Step S304 checking to send an authentication request flag to the AAA, and determining whether the value is sent, if not, proceeding to step S305, if yes, proceeding to step S306;
  • Step S305 Send an authentication request, and set to send an authentication request flag to the AAA as already sent; Step S306, wait for the authentication result to return;
  • Step S307 determining whether the returned authentication result is successful, if not successfully proceeding to step S311, if successful, proceeding to step S308;
  • Step S308 determining whether the LCP state machine is in an open state, if yes, proceeding to step S310, if not proceeding to step S309;
  • Step S309 the AAA is notified to release the IP address, and then proceeds to step S5;
  • Step S310 setting an authentication success flag, sending an authentication success packet to the user, and proceeding to step S4, that is, a PPP IPCP negotiation process;
  • Step S311 the process proceeds to step S5, that is, the PPP session termination process.
  • the PPP IPCP negotiation process is performed, and the PPP IPCP negotiation process is prevented. As shown in Figure 5, the PPP IPCP negotiation process is performed. The following steps:
  • Step S401 entering IPCP negotiation
  • step S402 it is determined whether the IPCP negotiation is successful, and the process proceeds to step S403. If the process is unsuccessful, the process proceeds to step S408.
  • the flag of the negotiation success is whether the PPP IPCP state machine is in an open state.
  • Step S403 the count of successful IPCP negotiation is increased by 1;
  • Step S404 determining whether the count exceeds the maximum allowed number, the maximum allowable number is 3, if yes, proceeding to step S408, if not exceeding step S405;
  • Step S405 checking a sending charging start request flag
  • Step S406 determining whether the charging start request has been sent, if the charging start request has been sent, no processing is performed; if not, proceeding to step S407;
  • Step S407 setting a sending charging start request flag, and sending a charging start request to the AAA client, so that the PPP session is established, and the PPP data transmission phase is started;
  • Step S408 entering a PPP session termination process, that is, step S5.
  • the PPP session termination process S5 is as shown in Figure 6, which includes the following steps:
  • Step S501 removing the PPP session
  • Step S502 checking the authentication success flag, and determining whether the value is successful, if yes, proceeding to step S503, if no, proceeding to step S506;
  • Step S503 checking the sending charging start request flag, and determining whether the charging start request is sent, if yes, proceeding to step S504, if not, proceeding to step S505;
  • Step S504 sending a charging end request, and releasing the IP address at the same time;
  • Step S505 Send a charging rejection request, and release the IP address at the same time;
  • Step S506 releasing the PPP session entity.
  • the method for preventing IP address leakage when using the point-to-point protocol of the present invention effectively prevents the LCP state machine and the IPCP state by limiting the number of successful PPP LCP negotiations in the PPPLCP negotiation process and limiting the number of PPP IPCP negotiation successes. Excessive oscillation and excessive oscillation.
  • the PPP authentication process only the authentication request is sent to the AAA client.
  • the IPCP guarantees that only the accounting start request is sent once, which effectively solves the problem of IP leakage.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Description

一种使用点到点协议时防止 IP地址泄漏的方法 技术领域
本发明涉及网络接入技术， 具体涉及一种使用 PPP ( The Point-to-Point Protocol, 点到点协议） 时防止 IP (Internet Protocol, 互联网络协议） 地址泄 漏的方法。 背景技术
目前， PPP接入已成为主流的宽带接入应用方式，尤其是 PPPoE(PPP Over Ethernet, 以太网上的点到点协议） 技术规范得到了广泛的支持， 目前成为宽 带接入运营商首选的宽带接入方式。
宽带接入服务器实现 PPP会话的 IP地址分配过程如图 1所示， PPP会话 通过 AAA ( Authentication、 Authorization、 Account, 认证、 授权、 计费） 客 户端认证来分配 IP地址， 通过发送计费停止请求或者计费拒绝请求来释放 IP 地址。计费开始请求是在 PPP IPCP (PPP Internet Protocol Control Protocol, PPP IP控制协议） 协商完成后发送的， 计费停止请求在计费开始请求发送完成后 才能发送。 计费拒绝请求是在计费开始请求发送前 PPP会话发生异常时发送 的，计费拒绝请求只是本地异常处理过程，不向 RADIUS(Remote Authentication Dial In User Service , 远程拨入用户认证服务） 服务器发送计费包， 不是 RADIUS协议标准。
但是在宽带接入服务器提供 PPP接入业务时， 经常出现 PPP会话的 IP地 址泄漏问题， 导致用户可用的 IP地址减少， 甚至没有 IP地址可用。 产生这个 问题的原因在于 PPP状态机的复杂性， 在 LCP(Link Control Protocol, 链路控 制协议)协商阶段和认证阶段完成后， AAA客户端就已经给用户分配了 IP地 址， 但是在 LCP和 IPCP协商包重传时， 会导致 LCP和 IPCP状态机的振荡, 即一个 PPP会话进行重复协商， 导致一个 PPP会话的多次认证过程， 从而给 用户分配了多个 IP地址， 导致 IP地址泄漏。对于这个问题， 目前的 PPP协议 没有给出解决的方法， 也没有其它的协议标准来解决。 发明内容 本发明的目的在于提供一种使用点到点协议时防止 ip地址泄漏的方法， 有效的解决现有技术中 IP地址泄漏的问题。
为了实现上述目的， 本发明提供了一种使用点到点协议时防止 IP地址泄 漏的方法， 其中， 在 PPP LCP协商过程中， 限制所述 PPP LCP协商成功的次 数， 和 /或在 PPP认证过程中， 只向 AAA客户端发送一次认证请求， 和 /或在 IPCP保证只发送一次计费开始请求， 并限定 PPP IPCP协商成功的次数。
上述的一种使用点到点协议时防止 IP地址泄漏的方法， 其中， 具体包括 以下步骤：
步骤 1， 启动 PPP会话， 并进行所述 PPP会话的初始化；
步骤 2， 进行 PPP LCP协商；
步骤 3， 进行 PPP认证； - 步骤 4， 进行 PPP IPCP协商；
步骤 5， 终止所述 PPP会话， 释放所述 IP地址。
上述的一种使用点到点协议时防止 IP地址泄漏的方法， 其中， 所述 PPP 会话的初始化包括：
初始化认证成功标志的值为不成功；
初始化发送计费开始请求标志的值为没有发送；
初始化 LCP协商成功计数的值为零；
初始化 IPCP协商成功计数的值为零； 及
初始化向 AAA客户端发送认证请求标志的值为没有发送。
上述的一种使用点到点协议时防止 IP地址泄漏的方法， 其中， 所述步骤 2具体包括以下步骤：
步骤 201， 判断 LCP协商是否成功， 如果成功进入步骤 202， 如果不成功 则进入步骤 5 ;
步骤 202， LCP协商成功的计数加 1 ;
步骤 203，判断 LCP协商成功的计数是否超过允许的最大次数，如果超过 进入步骤 5， 如果没有超过则进入步骤 3。
上述的一种使用点到点协议时防止 IP地址泄漏的方法， 其中， LCP协商 是否成功的标志是 PPP LCP状态机是否为开启状态。
上述的一种使用点到点协议时防止 IP地址泄漏的方法， 其中， LCP协商 成功的计数允许的最大次数为 3次。
上述的一种使用点到点协议时防止 IP地址泄漏的方法， 其中， 所述步骤 3具体包括以下步骤：
步骤 301， 接收到认证请求；
步骤 302， 检查认证成功标志， 并判断成功还是失败； 如果成功进入步骤 303 , 如果失败进入步骤 304;
步骤 303， 向用户发送认证成功包并返回；
步骤 304， 检查向 AAA发送认证请求标志， 并判断值是否为已发送， 如 果不是则进入步骤 305， 如果是则进入步骤 306;
步骤 305， 发送认证请求， 并设置向 AAA发送认证请求标志为已经发送； 步骤 306， 等待认证结果返回；
步骤 307， 判断返回的认证结果是否成功， 如果不成功进入步骤 311， 如 果成功进入步骤 308;
步骤 308， 判断 LCP状态机是否为开启状态， 如果是进入步骤 S310, 如 果不是进入步骤 S309;
步骤 309， 通知 AAA释放 IP地址并返回；
步骤 310， 设置认证成功标志， 向用户发送认证成功包， 并进入步骤 4; 步骤 311， 进入步骤 5。
上述的一种使用点到点协议时防止 IP地址泄漏的方法， 其中， 所述步骤 4具体包括以下步骤：
步骤 401， 进入 IPCP协商；
步骤 402， 判断 IPCP协商是否成功， 如果成功进入步骤 403， 如果不成 功则进入步骤；
步骤 S403， IPCP协商成功的计数加 1 ;
步骤 S404, 判断 IPCP协商成功的计数是否超过允许的最大次数， 如果不 超过进入步骤 405， 如果超过则进入步骤 5;
步骤 405， 检查发送计费开始请求标志；
步骤 S406, 判断是否已经发送了计费开始请求， 如果已经发送了计费开 始请求， 则返回； 如果没有进入步骤 407;
步骤 407， 设置发送计费开始请求标志， 并向 AAA客户端发送计费开始 请求。
上述的一种使用点到点协议时防止 IP地址泄漏的方法， 其中， IPCP协商 是否成功的标志为 IPCP状态机是否为开启状态。
上述的一种使用点到点协议时防止 IP地址泄漏的方法， 其中， IPCP协商 成功的计数的最大次数为 3次。
上述的一种使用点到点协议时防止 IP地址泄漏的方法， 其中， 所述步骤 5具体包括以下步骤：
步骤 501， 拆除 PPP会话；
步骤 502，检査认证成功标志，并判断值是否为成功，如果是进入步骤 503， 如果否进入步骤 506;
步骤 503，检査发送计费开始请求标志，并判断是否发送了计费开始请求， 如果已发送， 则进入步骤 504， 如果没有发送则进入步骤 505;
步骤 504， 发送计费结束请求， 同时释放 IP地址；
步骤 505， 发送计费拒绝请求， 同时释放 IP地址；
步骤 506， 释放 PPP会话实体。
本发明的使用点到点协议时防止 IP地址泄漏的方法， 通过在 PPP LCP协 商过程中限制所述 PPP LCP协商成功的次数和在并限定 PPP IPCP协商成功的 次数， 有效防止 LCP状态机和 IPCP状态机过多的振荡、 过多的振荡， 同时在 PPP认证过程中， 只向 AAA客户端发送一次认证请求， IPCP保证只发送一 次计费开始请求， 有效地解决了 IP泄露的问题。 附图说明
图 1是现有技术中 PPP会话的 IP地址分配过程示意图；
图 2是本发明的操作流程图；
图 3是本发明的 PPP LCP协商流程图；
图 4是本发明的 PPP认证流程图；
图 5是本发明的 PPP IPCP协商流程图；
图 6是本发明的 PPP会话终止流程图；
图 7是本发明的 PPP会话状态机示意图。 具体实施方式
下面结合附图对本发明的技术方案的实施作进一步的详细描述。
本发明用来防止 PPP会话的 IP地址泄漏， 可以确保接入服务器对 PPP会 话的 IP地址进行正确分配， 接入服务器可以可靠的提供 PPP业务。
本发明的实施步骤如图 2所示， 包括以下步骤：
步骤 Sl， 启动 PPP会话， 进行所述 PPP会话的初始化；
步骤 S2， 进行 PPP LCP协商， 在协商的过程中， 限定所述 PPP LCP协商 成功的次数；
步骤 S3， 进行 PPP认证， 在认证过程中， 对 AAA客户端只分配一次 IP 地址；
步骤 S4，进行 PPP IPCP协商，在协商过程中，只发送一次计费开始请求， 并限定所述 PPP IPCP协商成功的次数；
步骤 S5， 终止所述 PPP会话， 释放所述 IP地址。
上述步骤完全符合 PPP协议的会话流程， 如图 7所示。 步骤 S1相当于链 路起来阶段， 步骤 S2相当于链路建立阶段， 步骤 S3相当于认证阶段， 步骤 S4相当于网络层阶段， 步骤 S5相当于链路终止阶段。
在 PPP会话初始化阶段， 初始化用于 PPP会话的标志和计数， 在为一个 PPP会话分配完资源后， 进行初始化。
本发明在 PPP会话过程中使用如下标志和计数：
认证成功标志， 标志此 PPP会话是否已经认证成功；
发送计费开始请求标志，标志此 PPP会话是否已经向 AAA客户端发送了 计费开始请求；
LCP协商成功计数， 标志此 PPP会话 LCP协商成功的次数， 即 LCP状态 机起来 （up) 的次数；
IPCP协商成功计数， 标志此 PPP会话 IPCP协商成功的次数， 即 IPCP状 态机起来 （up) 的次数；
向 AAA客户端发送认证请求标志， 标志此 PPP会话是否已经向 AAA客 户端发送了认证请求。
其中， 如图 3所示， 步骤 Sl， PPP会话的初始化具体包括以下内容： 初始化认证成功标志的值为不成功； 初始化发送计费开始请求标志的值为没有发送；
初始化 LCP协商成功计数的值为零；
初始化 IPCP协商成功计数的值为零； 及
初始化向 AAA客户端发送认证请求标志的值为没有发送。
如图 3所示， 在 PPP LCP协商阶段， 限定所述 PPP LCP协商成功的次数， 即防止 LCP状态机过多的振荡， PPP LCP协商具体包括以下步骤：
步骤 S201 , 进入 LCP协商；
步骤 S202, 判断协商是否成功， 成功进入步骤 S203 , 不成功则进入步骤 S206, 协商成功的标志是 PPP LCP状态机到达了开启 （Opened) 状态；
步骤 S203 , 增加 LCP协商成功的计数；
步骤 S204, 判断计数是否超过允许的最大次数， 其中最大允许次数是 3， 如果超过进入步骤 S206, 如果没有超过则进入步骤 S205;
步骤 S205 , 进入认证流程， 即步骤 S3 ;
步骤 S206， 进入 PPP会话终止流程， 即步骤 S5。
在 PPP认证阶段， 只向 AAA客户端发送一次认证请求， 从而保证 AAA 客户端只分配一次 IP地址。 如图 4所示， PPP认证流程， 即步骤 S3， 具体包 括以下步骤:
步骤 S301 , 接收到认证请求；
步骤 S302, 检查认证成功标志， 并判断成功还是失败； 如果成功进入步 骤 S303 , 如果失败进入步骤 S304;
步骤 S303 , 向用户发送认证成功包， 然后进入步骤 S4;
步骤 S304, 检查向 AAA发送认证请求标志， 并判断值是否为已发送， 如 果不是则进入步骤 S305 , 如果是则进入步骤 S306;
步骤 S305 ,发送认证请求，并设置向 AAA发送认证请求标志为已经发送; 步骤 S306, 等待认证结果返回；
步骤 S307, 判断返回的认证结果是否成功， 如果不成功进入步骤 S311 , 如果成功进入步骤 S308;
步骤 S308, 判断 LCP状态机是否为开启状态， 如果是进入步骤 S310, 如 果不是进入步骤 S309;
步骤 S309, 通知 AAA释放 IP地址， 然后进入步骤 S5 ; 步骤 S310， 设置认证成功标志， 向用户发送认证成功包， 并进入步骤 S4， 即 PPP IPCP协商流程；
步骤 S311 , 进入步骤 S5， 即 PPP会话终止流程。
在 PPP IPCP协商阶段， 保证只发送一次计费开始请求， 并限定 PPP IPCP 协商成功的次数， 即防止 IPCP状态机过多的振荡， 如图 5所示， PPP IPCP协 商流程， 即步骤 S4具体包括以下步骤：
步骤 S401 , 进入 IPCP协商；
步骤 S402, 判断 IPCP协商是否成功， 成功进入步骤 S403 , 不成功则进 入步骤 S408, 在此协商成功的标志是 PPP IPCP状态机是否为开启状态；
步骤 S403， IPCP协商成功的计数加 1 ;
步骤 S404, 判断计数是否超过允许的最大次数， 最大允许次数是 3， 如果 超过则进入步骤 S408, 如果不超过进入步骤 S405 ;
步骤 S405 , 检查发送计费开始请求标志；
步骤 S406, 判断是否已经发送了计费开始请求， 如果已经发送了计费开 始请求， 则不进行任何处理； 如果没有进入步骤 S407;
步骤 S407, 设置发送计费开始请求标志， 并向 AAA客户端发送计费开始 请求， 这样 PPP会话就建立完成， 开始 PPP数据传输阶段；
步骤 S408, 进入 PPP会话终止流程， 即步骤 S5。
在 PPP会话终止阶段， 保证释放 IP地址， PPP会话终止流程 S5如图 6 所示， 具体包括以下步骤：
步骤 S501 , 拆除 PPP会话；
步骤 S502, 检查认证成功标志， 并判断值是否为成功， 如果是进入步骤 S503 , 如果否进入步骤 S506;
步骤 S503 , 检查发送计费开始请求标志， 并判断是否发送了计费开始请 求， 如果已发送， 则进入步骤 S504, 如果没有发送则进入步骤 S505 ;
步骤 S504, 发送计费结束请求， 同时释放 IP地址；
步骤 S505 , 发送计费拒绝请求， 同时释放 IP地址；
步骤 S506, 释放 PPP会话实体。
当然，本发明还可有其它多种实施例， 在不背离本发明精神及其实质的情 况下， 熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形， 但 这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。 工业应用性
本发明的使用点到点协议时防止 IP地址泄漏的方法， 通过在 PPPLCP协 商过程中限制所述 PPP LCP协商成功的次数和在并限定 PPP IPCP协商成功的 次数， 有效防止 LCP状态机和 IPCP状态机过多的振荡、过多的振荡， 同时在 PPP认证过程中， 只向 AAA客户端发送一次认证请求， IPCP保证只发送一 次计费开始请求， 有效地解决了 IP泄露的问题。

Claims

权利要求书
1、 一种使用点到点协议时防止 IP地址泄漏的方法， 其特征在于， 在 PPP LCP协商过程中， 限制所述 PPP LCP协商成功的次数， 和 /或在 PPP认证过程 中， 只向 AAA客户端发送一次认证请求， 和 /或在 IPCP协商过程中只发送一 次计费开始请求， 和 /或在 IPCP协商过程中， 限定 PPP IPCP协商成功的次数。
2、根据权利要求 1所述的一种使用点到点协议时防止 IP地址泄漏的方法， 其特征在于， 具体包括以下步骤：
步骤 1， 启动 PPP会话， 进行 PPP会话的初始化；
步骤 2， 进行 PPP LCP协商， 在协商的过程中， 限定所述 PPP LCP协商 成功的次数；
步骤 3， 进行 PPP认证， 在认证过程中， 只向 AAA客户端发送一次认证 请求；
步骤 4， 进行 PPP IPCP协商， 且只发送一次计费开始请求， 并限定所述 PPP IPCP协商成功的次数；
步骤 5， 终止所述 PPP会话， 释放所述 IP地址。
3、根据权利要求 .2所述的一种使用点到点协议时防止 IP地址泄漏的方法， 其特征在于， 所述 PPP会话的初始化包括：
初始化认证成功标志的值为不成功；
初始化发送计费开始请求标志的值为没有发送；
初始化 LCP协商成功计数的值为零；
初始化 IPCP协商成功计数的值为零； 及
初始化向 AAA客户端发送认证请求标志的值为没有发送。
4、根据权利要求 2所述的一种使用点到点协议时防止 IP地址泄漏的方法， 其特征在于， 所述步骤 2具体包括以下步骤：
步骤 201， 判断 LCP协商是否成功， 如果成功进入步骤 202， 如果不成功 则进入步骤 5 ;
步骤 202， LCP协商成功的计数加 1 ;
步骤 203，判断 LCP协商成功的计数是否超过允许的最大次数，如果超过 进入步骤 5， 如果没有超过则进入步骤 3。
5、 根据权利要求 4所述的一种使用点到点协议时防止 IP地址泄漏的方 法， 其特征在于， LCP协商是否成功的标志是 PPP LCP状态机是否为开启状 态。 ·
6、 根据权利要求 4或 5所述的一种使用点到点协议时防止 IP地址泄漏 的方法， 其特征在于， LCP协商成功的计数允许的最大次数为 3次。
7、 根据权利要求 2所述的一种使用点到点协议时防止 IP地址泄漏的方 法， 其特征在于， 所述步骤 3具体包括以下步骤：
步骤 301， 接收到认证请求；
步骤 302， 检查认证成功标志， 并判断成功还是失败； 如果成功进入步骤 303， 如果失败进入步骤 304;
步骤 303， 向用户发送认证成功包， 然后进入步骤 S4;
步骤 304， 检查向 AAA发送认证请求标志， 并判断值是否为已发送， 如 果不是则进入步骤 305， 如果是则进入歩骤 306;
步骤 305， 发送认证请求， 并设置向 AAA发送认证请求标志为己经发送； 步骤 306， 等待认证结果返回；
步骤 307， 判断返回的认证结果是否成功， 如果不成功进入步骤 311， 如 果成功进入步骤 308;
步骤 308， 判断 LCP状态机是否为开启状态， 如果是进入步骤 310， 如果 不是则进入步骤 309;
步骤 309， 通知 AAA释放 IP地址， 然后进入步骤 S5;
步骤 310， 设置认证成功标志， 向用户发送认证成功包， 并进入步骤 4; 步骤 311， 进入步骤 5。
8、根据权利要求 2所述的一种使用点到点协议时防止 IP地址泄漏的方法， 其特征在于， 所述步骤 4具体包括以下步骤：
步骤 401， 进入 IPCP协商；
步骤 402， 判断 IPCP协商是否成功， 如果成功进入步骤 403， 如果不成 功则进入步骤；
步骤 403， IPCP协商成功的计数加 1 ;
步骤 404， 判断 IPCP协商成功的计数是否超过允许的最大次数， 如果不 超过进入步骤 405， 如果超过则进入步骤 5; 步骤 405 , 检查发送计费开始请求标志；
步骤 406， 判断是否已经发送了计费开始请求， 如果己经发送了计费开始 请求， 则不进行任何处理； 如果没有进入步骤 407;
步骤 407， 设置发送计费开始请求标志， 并向 AAA客户端发送计费开始 请求， 这样 PPP会话就建立完成， 开始 PPP数据传输阶段。
9、根据权利要求 8所述的一种使用点到点协议时防止 IP地址泄漏的方法， 其特征在于， IPCP协商是否成功的标志为 IPCP状态机是否为开启状态。
10、 根据权利要求 8或 9所述的一种使用点到点协议时防止 IP地址泄漏 的方法， 其特征在于， IPCP协商成功的计数的最大次数为 3次。
11、 根据权利要求 2所述的一种使用点到点协议时防止 IP地址泄漏的方 法， 其特征在于， 所述步骤 5具体包括以下步骤：
步骤 501， 拆除 PPP会话；
步骤 502，检查认证成功标志，并判断值是否为成功，如果是进入步骤 503， 如果否进入步骤 506;
步骤 503，检查发送计费开始请求标志，并判断是否发送了计费开始请求， 如果已发送， 则进入步骤 504， 如果没有发送则进入步骤 505;
步骤 504， 发送计费结束请求， 同时释放 IP地址；
步骤 505， 发送计费拒绝请求， 同时释放 地址；
步骤 506， 释放 PPP会话实体。
PCT/CN2005/000983 2004-07-08 2005-07-05 Procede servant a empecher la dispersion d'adresses ip quand on utilise un protocole point-a-point WO2006005249A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/571,739 US8533779B2 (en) 2004-07-08 2005-07-05 Method for preventing IP address from unexpected dispersion when using point-to-point protocol

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200410028024.4 2004-07-08
CN200410028024A CN100589374C (zh) 2004-07-08 2004-07-08 一种使用点到点协议时防止ip地址泄漏的方法

Publications (1)

Publication Number Publication Date
WO2006005249A1 true WO2006005249A1 (fr) 2006-01-19

Family

ID=35783512

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/000983 WO2006005249A1 (fr) 2004-07-08 2005-07-05 Procede servant a empecher la dispersion d'adresses ip quand on utilise un protocole point-a-point

Country Status (3)

Country Link
US (1) US8533779B2 (zh)
CN (1) CN100589374C (zh)
WO (1) WO2006005249A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101365238B (zh) * 2007-08-06 2013-01-09 华为技术有限公司 一种会话转换的方法及装置
CN102076027B (zh) * 2009-11-19 2014-04-30 中兴通讯股份有限公司 统计无线系统中ppp协商状态的系统、装置及方法
CN102394878B (zh) * 2011-10-28 2015-02-18 杭州华三通信技术有限公司 跨板点对点多链路协议捆绑方法及设备
CN111092961B (zh) * 2019-11-15 2021-12-17 中国电子科技集团公司第三十研究所 一种基于ppp协议的ip地址协商的实现方法
CN113206827B (zh) * 2021-03-29 2022-10-21 北京华三通信技术有限公司 报文处理方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001052499A2 (en) * 2000-01-14 2001-07-19 Qualcomm Incorporated Method of avoiding ppp time-outs during ipcp negotiations
KR20020093549A (ko) * 2001-06-09 2002-12-16 주식회사 하이닉스반도체 무선통신 시스템에서의 망요소 통합을 위한 제어 관리 방법
US20030131133A1 (en) * 2002-01-08 2003-07-10 Takayuki Nyu Communications system for establishing PPP connections between IEEE 1394 terminals and IP networks

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6031848A (en) * 1997-05-07 2000-02-29 3Com Corporation Apparatus for an improved ISDN terminal adapter having baud rate unblocking and methods for use therein
US6119160A (en) * 1998-10-13 2000-09-12 Cisco Technology, Inc. Multiple-level internet protocol accounting
US6785823B1 (en) * 1999-12-03 2004-08-31 Qualcomm Incorporated Method and apparatus for authentication in a wireless telecommunications system
US7412528B2 (en) * 2000-01-14 2008-08-12 Qualcomm, Incorporated Avoiding PPP time-outs during IPCP negotiations
US6978128B1 (en) * 2001-05-04 2005-12-20 Utstarcom, Inc. System and method to allow simple IP mobile nodes to operate seamlessly in a mobile IP network with true roaming capabilities
US7197549B1 (en) * 2001-06-04 2007-03-27 Cisco Technology, Inc. On-demand address pools
US7333452B2 (en) * 2001-06-12 2008-02-19 Lg Electronics Inc. Method and system for packet data transmission
JP4236398B2 (ja) * 2001-08-15 2009-03-11 富士通株式会社 通信方法、通信システム及び通信接続プログラム
KR100442594B1 (ko) * 2001-09-11 2004-08-02 삼성전자주식회사 무선통신 시스템의 패킷 데이터 서비스 방법 및 장치
JP3966711B2 (ja) * 2001-11-06 2007-08-29 富士通株式会社 代理応答方法
KR100450950B1 (ko) * 2001-11-29 2004-10-02 삼성전자주식회사 구내/공중망 무선 패킷데이터 서비스를 받는 이동단말기의 인증 방법 및 그 사설망 시스템
US7154868B1 (en) * 2002-01-08 2006-12-26 Utstarcom, Inc. Smooth handoff via state exchange in wireless networks
US20040059821A1 (en) * 2002-09-24 2004-03-25 Jian Tang Method and system for a point to point protocol-bridge operating mode in network communication system
US7454206B1 (en) * 2003-05-15 2008-11-18 Sprint Communications Company L.P. Method and system with user identifiers that indicate session type
US20050021770A1 (en) * 2003-06-13 2005-01-27 Guy Helm Method for transferring PPP inactivity time in a CDMA2000 network
US20050043028A1 (en) * 2003-08-20 2005-02-24 Nokia Corporation Arrangement for supporting data exchange between terminal equipment and a mobile communication network via a mobile terminal
US7773554B2 (en) * 2003-12-03 2010-08-10 John Wallace Nasielski Methods and apparatus for CDMA2000/GPRS roaming
US8619701B2 (en) * 2004-05-03 2013-12-31 Core Wireless Licensing S.A.R.L. Method of facilitating handoff for CDMA networks using IP protocols
US7746774B2 (en) * 2004-06-30 2010-06-29 Research In Motion Limited Methods and apparatus for controlling wireless network resources for data sessions based on IP address usage

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001052499A2 (en) * 2000-01-14 2001-07-19 Qualcomm Incorporated Method of avoiding ppp time-outs during ipcp negotiations
KR20020093549A (ko) * 2001-06-09 2002-12-16 주식회사 하이닉스반도체 무선통신 시스템에서의 망요소 통합을 위한 제어 관리 방법
US20030131133A1 (en) * 2002-01-08 2003-07-10 Takayuki Nyu Communications system for establishing PPP connections between IEEE 1394 terminals and IP networks

Also Published As

Publication number Publication date
CN1719764A (zh) 2006-01-11
CN100589374C (zh) 2010-02-10
US8533779B2 (en) 2013-09-10
US20070245405A1 (en) 2007-10-18

Similar Documents

Publication Publication Date Title
JP5054699B2 (ja) ポリシ施行点インターフェース・システムおよび方法
WO2014015775A1 (zh) 一种IPv6地址无状态自动配置的系统、数据卡及其实现方法
EP2374258B1 (en) System and methods to facilitate connections to access networks
WO2004032421A1 (fr) Procede d'adjonction de dispositifs a un systeme de gestion
US8472422B2 (en) Method and system for avoiding hanging PDP contexts
CN107547321B (zh) 报文处理方法、装置、相关电子设备及可读存储介质
WO2006005249A1 (fr) Procede servant a empecher la dispersion d'adresses ip quand on utilise un protocole point-a-point
WO2009065354A1 (fr) Procédé, système et dispositif pour le traitement d'informations de demande d'accès
CN102025618A (zh) 通信系统中的分组流处理
WO2018191854A1 (zh) 接入固定网络的方法和接入网关网元
KR20130065878A (ko) 이동통신 네트워크에서 요금 지불을 대행하는 인터넷 서비스 제공 방법 및 장치
CN101174997B (zh) 一种bras设备上检测radius服务器可用性的装置及方法
WO2011091667A1 (zh) 一种数据卡及其快速建立拨号连接的方法
US8213364B2 (en) Method for releasing a high rate packet data session
WO2010020123A1 (zh) 一种恢复ip会话的方法、网络系统和网络边缘设备
WO2017080335A1 (zh) 一种基于pppoe网络的拨号方法、拨号系统及路由器
US7974206B2 (en) Method for establishing a secured connection, corresponding SFC apparatus, MFC apparatus, requesting terminal and computer program product
WO2003063429A1 (en) Method and apparatus for authenticated quality of service reservation
US20070162607A1 (en) Insertion of protocol messages through a shim
CN103841219B (zh) 释放ip地址的方法、装置及接入设备
WO2014179951A1 (zh) 服务质量提升方法及装置
KR20050119407A (ko) 유엠티에스시스템의 세션절차해제방법
JP2005528017A (ja) 通信端末装置間の通信リンクの決済方法
Cisco Commands: debug ppp bap through debug sdllc
WO2011150867A2 (zh) 一种终端认证方法及装置

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 11571739

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Ref document number: DE

WWE Wipo information: entry into national phase

Ref document number: 389/KOLNP/2007

Country of ref document: IN

122 Ep: pct application non-entry in european phase
WWP Wipo information: published in national office

Ref document number: 11571739

Country of ref document: US