A NETWORK ENTITY

Field of the Invention

The present invention relates in general to a method and apparatus for allocating a unique identifier to a network entity. A potential application of an embodiment of the invention is the generation of an Ipv6 type address from an IPv4 address.

Background of the Invention

An Internet Protocol (IP) address is a numerical label assigned to devices of a computer network that uses the Internet Protocol for communication between its nodes. An IP address provides a host or network interface identification and location addressing for routing on the network. Internet Protocol version 4 (IPv4) is an Internet Layer protocol for packet-switched internetworks which is still in dominant use. IPv4 uses 32-bit (four-byte) addresses, which limits the number of unique addresses that can potentially be allocated for routing on the public

Internet. As a result many large Internet Service Providers (ISPs) face the problem that their networks' customer edges are so large that it will soon not be possible to provide each customer with a unique IPv4 address.

Due to the foreseen IPv4 address exhaustion, IPv4 is due to be replaced by IPv6 which has a significantly larger address field than IPv4, thereby enabling a significantly greater number of unique internet addresses to be provided for allocation. However while IPv4-only legacies are ubiquitous crossing telecom infrastructure, IPv6 and IPv4 are incompatible protocols. Consequently IPv6 will be unable to replace IPv4 and address the public IPv4 exhaustion immediately. Instead both protocols will co-exist for a long period during what is often referred to as the IPv6 transition period.

During the IPv6 transition period, some public IPv4 address sharing solutions need to be deployed in order to achieve a higher utilization ratio of available public IPv4 addresses than is currently achieved, before the majority of the Internet becomes IPv6-capable and most communications are done through IPv6. Several solutions have been proposed to address IPv4 address shortage while migrating to IPv6 - such solutions include Network Address Translation (NAT), Address plus Port (A+P), or Dual-stack Lite (DS-Lite) based solutions.

DS-Lite technology is intended for maintaining connectivity to existing IPv4 devices and networks after the exhaustion of the IPv4 address space while service provider networks make a transition to IPv6-only deployments. DS-Lite enables a broadband service provider to share IPv4 addresses among customers while migrating to IPv6 by combining two well-known technologies: IP in IP (IPv4- in-IPv6) tunnel and NAT. The principle involves moving the current NAT function performed on a Customer Premise Equipment (CPE) to carrier-grade, referred to as carrier-grade NAT, and transporting IPv4 traffic over an IPv6 access network by IPv4-in-IPv6 an IP in IP tunnel, for example as defined in RFC5571 , B. Storer., " Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)", June 2009.

The DS-Lite specification applies two terms: the DS-lite Basic Bridging

Broad Band element (B4) and the DS-lite Address Family Transition Router element (AFTR). A B4 element is a function implemented on a dual-stack capable node, either a Customer Premise Equipment (CPE) or a directly connected device that creates a tunnel to an AFTR. An AFTR element is the combination of an IPv4- in-IPv6 tunnel end-point and an IPv4-IPv4 NAT implemented on the same node.

As illustrated in FIG. 1 , each CPE is assigned a global IPv6 prefix and dynamically allocates private IPv4 addresses, for example RFC1918 private IPv4 addresses, to the terminals located in the customer premises. Inside the customer's network, IPv4 private addresses are still used, and the outgoing traffic generated by terminals is encapsulated and tunnelled to the carrier grade NAT by the CPE through an IPv4-in-IPv6 Softwire, where the B4 element acts as a

Softwire initiator (SI) in the dual-stack lite home router and a Softwire concentrator (SC) in the AFTR. The AFTR performs IPv4-IPv4 NAT translations to multiplex multiple subscribers through a pool of global IPv4 address. Overlapping address spaces used by subscribers are disambiguated through the identification of tunnel endpoints.

In Address plus Port (A+P) sometimes referred to as extended addressing enables address sharing by treating some port number bits as part of an extended IPv4 address. The address is extended by taking bits from the port number in the TCP/UDP (Transmission Control Protocol/User Datagram Protocol) header. The principle of A+P (Address plus Port) is illustrated in FIG. 2. 16 bits taken from the TCP/UDP port field are attached to the IPv4 address to identify different customers that share the same IP address. Multiple CPEs share a common global IPv4 address, but with separate, non-overlapping, port ranges. Each CPE can use the address as if it were its own public address, except that only a limited port range is available for use. IPv6 addresses derived from IPv4 address plus a specified range of ports are allocated to each CPE. A+P leaves applications with a reduced range of ports.

A+P also uses two technologies, IP in IP tunnel and NAT with some differences compared to DS-Lite, 1 ) The NAT is performed on the CPE rather than carrier grade and the NAT follows the restricted source port range rule. 2) IPv4 traffic is transported over the IPv6 access network by IPv4-in-IPv6 tunnels, but in this case the IPv4 address plus port number derived IPv6 address is used for IPv6 routing.

A consensus considering Dual-Stack Lite as a promising solution has been reached, which provides broad band service provider with a scalable and easy way to introduce IPv6 while maintaining IPv4 reachability to its customers. A+P is recommended as a complementary method with a DS-Lite environment, which may lead to the disruption of some subscriber-provided services due to the following reasons

Since there are many applications that require some kind of Application Level Gateway (ALG) to work through NAT, similarly more and more applications expect incoming connections, such as peer-to-peer connections. Ensuring that these subscriber-provided services keep working in a dual-stack lite environment is important. However the service provider does not need to be in the position of provisioning such applications and ALGs. It is reasonable to let such subscriber- provided services be under the control of the customer rather than service provider. This means letting the CPE deal with controlling the NAT traversal and ALG issues. Reserving certain ports under the control of each customer lets the CPE perform the NAT for this kind of traffic. Since A+P works in this way, it has been suggested that AFTRs work in an A+P model to address subscriber-provided services issues. Figure 3 shows an example in which an Internet Service Provider (ISP) reserved a number of ports in an A+P model, for incoming packets that have fallen into the A+P ports range. The AFTR sends them directly to the tunnel endpoint without NAT, and lets CPE deal with NAT. An A+P aware CPE in turn locally NAT A+P packets to internal hosts.

Since IPv4 addresses will be shared among customers and potentially a large number of customers may share a global IP-address, on average, only a limited number N of TCP or UDP port numbers will be available per customer for applications. While dynamic port assignment is used to maximize the number of subscribers sharing each global IPv4 address by an AFTR, the A+P model requires allocating ports in a cookie-cutter fashion, which pre-allocates a range of ports to customers. According to several service providers' reports, the average number of connections per customer is in the single digits while thousands or tens of thousands of ports could potentially be used in peak time by any single customer browsing a number of AJAX/Web 2.0 sites. Allocating a smaller number of ports per user (N in the hundreds) would potentially lead the customer's applications to be disrupted in a more or less random way over time. On the other hand allocating a fixed number of ports per user with a minimum of N = several thousands of ports for every user, would bring the address sharing ratio to a single digit. Furthermore, different customers may require a different number of ports.

For example, enterprise customers may require more ports than private customers, while some private customers provisioning many terminals may also require more ports.

Several methods proposed for allocating A+P information, such as described in Bajko, G. and T. Savolainen, "Port Restricted IP Address

Assignment", draft-bajko-v6ops-port-restricted-ipaddr-assign-02 (work in progress), November 2008., which defines DHCPv4 Options for allocating port restricted public IPv4 address and a range of ports, and the solution described in M.

Boucadair, Ed, " Port Range Configuration Options for PPP IPCP", draft-boucadair pppext-portrange-option-01 (work in progress), July 2009, which defines IPCP Options to convey one range of ports (contiguous or not contiguous) pertaining to a given IP address. However none of the proposed solutions provide the ability to carry differentiated services to customers. Furthermore, recently, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols by guessing or knowing the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance.

Summary of the Invention

The invention has been devised with the foregoing in mind. One of the objectives to be addressed by embodiments of the invention is to provide

customer oriented differentiated services for A+P address sharing. A further objective of embodiments of the invention is to provide better security by

preventing attacker's easy guessing the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port).

Accordingly, a first aspect of the invention provides a method of allocating a unique identifier to a network entity of an I P network, the method comprising:

providing a plurality of I P address pools, wherein each IP address pool comprises a common I P address to be shared between a plurality of network entities, and wherein each I P address pool has a corresponding I P address sharing ratio defining the number of network entities sharing the respective common I P address; for each I P address pool, dividing a port bit set comprising N port bits into M port bits and N-M port bits wherein M<N and wherein the pattern or choice of selected M port bits from the port bit set identifies the corresponding I P address pool and the value of the M port bits is unique to each network entity sharing the common I P address; and combining the M port bits with the common I P address to provide a unique identifier. In a preferred embodiment of the invention the method is operated in a DS-Lite context.

A second aspect of the invention provides a network entity if an IP network for allocating a unique I P identifier to a host network entity of the I P network, wherein the network entity is configured to perform address plus Port addressing and I P-in-I P tunnelling and comprises: request means for requesting a shared I P address for address plus port addressing ; reception means for receiving an I P address pool I D pattern in response to the request; verification means for checking the IP address pool ID pattern to determine whether or not the

corresponding IP address pool provides a desired sharing ratio; means for accepting the IP address pool ID pattern if the corresponding IP address pool provides the desired sharing ratio wherein the request means is configured to send a new request for requesting provision of a shared IP address wherein the new request indicates that a lower IP address sharing ratio is required if the corresponding IP address pool does not provide the desired sharing ratio.

A third aspect of the invention provides a network entity of an IP network, comprising: reception means for receiving a request for provision of a shared IP address for address and port network address translation; transmission means for sending an IP address pool ID pattern identifying a common IP address pool in response to the request; selection means for selecting a different IP address ID pool pattern providing a common IP address with a lower sharing ratio if a new request for provision of a common IP address with a lower IP address sharing ratio is received in response to the first IP address pool ID pattern; wherein the network entity has access to a plurality of IP address pools, for provision of the shared IP address wherein each IP address pool comprises a common IP address to be shared between a plurality of network entities, and wherein each IP address pool has a corresponding IP address sharing ratio defining the potential number of network entities sharing the respective common IP address.

In embodiments of the invention:

• the unique identifier may act as an IP type address such as an IPv6 type address;

· the IP address sharing ratio for each IP address pool depends on the number of M port bits.

• an IP address pool ID pattern identifying a respective IP address pool is defined by setting all of the selected M port bits to 1 and the remaining N-M bits to 0; or setting all of the selected M port bits to 0 and setting all of the remaining N-M port bits to 1 .

• a unique ID value identifying a client of a shared IP address pool is defined by setting the value of the M bits to define an identifier; and setting all of the remaining N-M port bits to 1 or to 0. • the M bits are selected from the N port bits so as not to include the most significant bits of the port bit set.

• the M bits are selected so as not to include the least significant bit of the port bit set.

· the M bits are selected so as not to include only a sub-set of continuous port bits.

• The method may include requesting provision of a shared IP address for address and port network address translation; receiving an IP address pool ID pattern in response to the request; checking the IP address pool ID pattern to determine whether or not the corresponding IP address pool provides the desired sharing ratio; accepting the IP address pool ID pattern if the corresponding IP address pool provides the desired sharing ratio, otherwise sending a new request for requesting provision of a shared IP address wherein the new request indicates that a lower IP address sharing ratio is required.

· The step of determining whether or not the corresponding IP address pool provides the desired sharing ratio may include counting the number of bits in the IP address pool ID pattern which are set to 1 or set to 0.

• The method may include receiving a request for provision of a shared IP address for address and port network address translation; sending an IP address pool ID pattern in response to the request; selecting a different IP address ID pool pattern with a lower sharing ratio if a new request for provision of a shared IP address with a lower IP address sharing ration is received in response to the first IP address pool pattern.

• the shared IP address is an IPv4 address and the unique identifier defines an IPv6 address.

At least part of the methods according to the invention may be computer implemented. The methods may be implemented in software on a programmable apparatus. They may also be implemented solely in hardware or in software, or in a combination thereof.

Since parts of the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

Brief Description of the Drawings Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which :-

Figure 1 is a schematic diagram of an example of a network based on dual-lite architecture

Figure 2 is a schematic diagram of an example of a network based on Address Plus Port architecture

Figure 3 is an example of port allocation

Figure 4 is a schematic diagram of an example of a network based on dual-lite architecture and address plus port architecture according to an embodiment of the invention;

Figure 5A and 5B are communication diagrams illustrating methods of allocating an IP address to a host according to embodiments of the invention;

Detailed description

A first embodiment of a method of, of the invention will be described with reference to Figure 4 to 5B. Figure 4 illustrates an example of a DS-lite environment in which embodiments of the invention may operate. The illustrated network architecture comprises a Public IPv4 address realm connected to an IPv6 address realm via an AFTR. The network also comprises a plurality of CPEs each connected to a respective RFC1918 address realm including a number of hosts, such as a portable computer 100_1 , 200_1 a mobile telephone, 100_2, 200_2 and a server 100_3, 200_3. Each CPE is DS-lite compatible, capable of performing A+P addressing and capable of creating an Ipv4-in-lpv6 tunnel to transport Ipv4 traffic through the IPv6 address realm to the AFTR.

An embodiment of the invention provides a mechanism to enable a service provider to provision different qualities of service by allocating different sharing ratio IP-addresses to different customers. A customer with a lower sharing ratio IP-address will typically get a better level of service compared to a customer with a higher sharing ratio IP-address. A customer demanding a better service and being provided with a lower sharing ratio IP-address may for example be charged more for the lower sharing ratio IP-address.

In this embodiment the operator can configure IP-addresses pools with different service levels depending on the different sharing ratios. Table 1 below shows an example of seven service level IP-addresses pools configured according to seven IP-address sharing ratios. The sharing ratios vary from 1 to 64, which means available ports for each customer varies from 65536 to 64, while the corresponding service level decreases from level 0 (best level of service) to level 6 (lowest level of service). Level 0 provides one unshared global IP-address to a customer as would be typically performed by an operator of the prior art. Each customer may request different service level IP-addresses according to their requirements on quality of service, which depends on the sharing ratio, the lower the sharing ratio, the higher the quality of service at, typically, a higher price.

In this embodiment in order, to provide a way for a customer to generate as random ports as possible in their restricted port range, the core idea is to:

1 ) Divide a 16 bits port field (N=16), into operator control bits and customer control bits. The operator control bits are allocated by the operator to identify customers sharing the same IP-address. It is ensured that the operator control bits chosen follow a pre-defined principle in order to prevent allocating regular ports to customers. (Customer control bits may be used as available ports for applications and running concurrent sessions).

2) Provide a way of allowing a customer to reuse existing Port Randomization algorithms. Once a sharing ratio is decided, M bits are derived from for operator control bits, which are used to distinguish customer ID for 2 ^M customers sharing the same IP-address. For example, According to one IP-address-A from a Level 6 address pool, the third, 4 ^th , 7 ^th , 9 ^th , 10 ^th , 12 ^th bits may be selected as operator control bits which may be used to provide a unique address when combined with the common IP address of the Level 6 address pool. All the customers sharing the IP-address-A gets an operator control bits pattern ' ^**** 1 ^* 1 1 ^* 1 ^** 1 1 ^** ', and each of them gets a unique value of these bits. For example customer 1 gets '****ο*00*0**00**'; customer 2 gets '****o*00*0**01 **; customer 3 gets ' ^**** 0 ^* 00 ^* 0 ^** 10 ^** , customer 4 gets ' ^**** n ^* 00 ^* 0 ^** 1 1 ^** '.

Table 1 : An example of different Service level IP-address pools

To ensure the customer can generate as random ports as possible, there are three principles for choosing the M bits operator control bits from the 16 port bits.

1 ) To avoid allocating a range of continuous ports to a customer, the M bits Customer ID Pattern should not occur in the most significant bits. 2) To avoid allocating only even ports to customers with the least significant bit '0' or only odd ports to customers with the least significant bit Ί ', the M bits Customer ID Pattern should not involve the least significant bit. 3) To avoid allocating a regular range of ports to customer, the M bits Customer ID Pattern should not occur in the continuous bits. In order to facilitate reuse of existing Port Randomization algorithms, two parameters are defined, Customer ID Pattern, turn all the ' ^* ' bits of operator control bits pattern to '0' to form a Customer ID Pattern, turn all the ' ^* ' bits of the unique value of operator control bits to '1 ' to form a Customer ID Value. For example, customer 1 gets IP-address-A with '0000101 101001 100' as Customer ID Pattern and '1 1 1 10100101 1001 1 ' as Customer ID Value; customer 2 gets IP- address-A with '0000101 101001 100' as Customer ID Pattern and Ί 1 1 10100101 101 1 1 ' as Customer ID Value, etc.

Port randomization algorithms such as those referred to in M. Larsen, Ed, "Port Randomization", draft-ietf-tsvwg-port-randomization-05 (work in progress), November 30, 2009, which is incorporated herein by reference thereto, may be used, taking the result port a bitwise OR operator with Customer ID Pattern and an AND operator with Customer ID Value would make sure the result port is within the customer restricted range. It would be done by slight modification to the existing port randomization algorithms. Take the Algorithm 1 referred to in M. Larsen, Ed, for example, Table 2 shows the pseudo code, in which a grey background highlights the modifications.

/* Ephemeral port selection function */

num_ephemeral = max_ephemeral - min_ephemeral + 1 ;

next_ephemeral = min_ephemeral + (random() % num_ephemeral);

next„ep emeraUn„range = iiext„ephemetal II customer J D„parteni & customerJD„vahie

count = num_ephemeral;

do {

if(five-tuple is unique)

return ne f_ephemera l_i ii_range ;

if (next_ephemeral == max_ephemeral) {

next_ephemeral = min_ephemeral;

} else {

next_ephemeral++ ;

}

count—;

Table 2: Pseudo code of new port randomization algorithms

In one illustrative, exemplary embodiment of the invention, for easy deployment and management, an Internet service provider may maintain two service levels as shown in Table 3. Level 2 addresses are provided for customers who do not need many available ports for supporting many simultaneous sessions. Level 1 addresses are provided for customers who run applications opening thousands of concurrent sessions or for a home network with many terminals, and thus require more available ports.

Table 3. An example of providing two service levels with respective sharing ratios and available port numbers

Table 4 shows an example of Customer ID patterns identifying the respective IP-address pools, and the Customer ID values defining unique addresses of the respective pool according to IP-address 'a.b.c.d' of sharing ratio 64 in the Level 2 pool and 'e.f.g.h' of sharing ratio 8 in the Level 1 pool.

Sharing ratio Level 2 IP-address pool Customer ID pattern 64 Customer ID value

1111010010110011 1111010010110111

64 a.b.c.d

0000101101001100

1111111111111011 1111111111111111

Sharing ratio Level 1 IP-address pool Customer ID pattern 8 Customer ID value

8 e.f.g.h 0000001101001000 1111110010110111

1111110010111111 1111111111111111

Table 4. An example Customer ID pattern and Customer ID value

A Customer may be allocated an IP-address in the desired address sharing ratio by negotiating a Customer ID pattern with the operator. The negotiation may be done in several ways. One option is by negotiating DHCPv4 Option for allocating port restricted public IPv4 address defined in Bajko, G. and T. Savolainen, "Port Restricted IP Address Assignment", draft-bajko-v6ops-port- restricted-ipaddr-assign-02 (work in progress), November 2008. Another option is by negotiating PPP IPCP Options defined in M. Boucadair, Ed, " Port Range Configuration Options for PPP IPCP", draft-boucadair pppext-portrange-option- 01 (work in progress), July 2009. The negotiation could be done after Softwire is established and IPCP reaches the Opened state.

Taking the IPCP Option as illustrative examples, two common negotiation cases are described hereafter to show how to convey the IP-address of customer desired sharing ratio.

A first embodiment will now be described with reference to FIG 5A illustrating the exchange of messages between a CPE and an AFTR when a customer CPE requests a shared IP-address of normal sharing ratio.

In step S1 1 of the method of this embodiment of the invention, the CPE sends a Configure-Request to the AFTR with the IP-address, Customer ! D Pattern and Customer I D Value all set to zero and requests that the AFTR provide a shared IP-Address for A+P NAT.

In step S12, in response to the AFTR receiving a Configure-Request specifying an A+P Configuration Option, the AFTR sends a Configure-Nak message to the CPE with the IP-address set to a shared IP-address a.b.c.d allocated from the Level 2 address pool of table 4, which is either assigned from an AAA Radius/Tacacs + server or from a DHCP server. The message includes the Customer ! D Pattern set to ooooioiioiooiioo as shown in Table 4, where all the operator controlled bits of the pattern are set to 1 , and a Customer I D Value liiioiooioiiiiii in which the remaining non-operator controlled bits are set to 1 , the M operator bits being set to corresponding bit values providing the unique ID. In step S13, the CPE receives a Configure-Nak message from the AFTR carrying the A+P parameters, in response sends a Configure- Request specifying the same A+P parameters as in the received Configure-Nak message.

In step S14 the AFTR receives the Configuration request message from the CPE and checks the A+P parameters in the request and in response sends an acknowledgement to the CPE.

FIG. 5B illustrates an example of the exchange of messages between a CPE and an AFTR when for a customer requesting a higher than average quality of service. In step S21 of the method of this embodiment of the invention, the CPE sends a Configure-Request message to the AFTR with the IP-address, Customer } D P attern and Customer ID Value in the message all set to zero requesting that the AFTR provide a shared IP-Address for A+P NAT.

In step S22, in response to the AFTR receiving a Configure-Request message specifying an A+P Configuration Option, the AFTR sends a Configure- Nak message to the CPE with the IP-address set to a shared IP-address a.b.c.d allocated from the Level 2 address pool of table 4, which is either assigned from an AAA Radius/Tacacs + server or from a DHCP server. The message includes the Customer ! D Pattern set to ooooioiioioonoo as shown in Table 4, where all the operator controlled bits of the pattern are set to 1 , and a Customer I D Value liiioiooioiiiiii in which the remaining non-operator controlled bits are set to 1 , the M operator bits being set to the corresponding bit values providing the unique ID.

In step S23 when the CPE receives a shared IP-address from the AFTR it counts the number of Ί ' bits in the Customer ! D Pattern included in the message in order to calculate sharing ratio. Since in this case the CPE receives a Customer_ID_Pattern Ό000101 101001 100', it determines that the sharing ratio is 64 and thus only 1024 ports are available for concurrent use, which does not fulfill the quality of service required. Consequently, in step S23 the CPE sends a new Configure-Request to the AFTR with, in this case the Customer ! D Pattern is set to 1 indicating that it requires an IP-address with a lower sharing ratio. In step S24 after the AFTR has received the new Configure-Request it checks the customer service level with the AAA Radius Server and approves the legalization of the request. A shared IP-address e.f.g.h is allocated from the Level 1 address pool which offers a sharing ratio 8 and 8192 available port numbers. Accordingly in step S24 the corresponding Customer ! D P attem and Customer ! D Value is returned to the CPE.

In step S25 the CPE checks the customer ID pattern and by counting the number of 1 bits and determines that the allocated sharing ratio corresponds to the desired level of service. Consequently, the CPE sends a Configure- Request to the AFTR specifying the same A+P parameters as in the received Configure- Nak message. Otherwise steps S23 to S25 may be repeated to obtain a higher level of service.

In step S26 the AFTR receives the Configuration Request message from the CPE, checks the A+P parameters and sends an acknowledgement to the CPE. The methods according to the embodiments of the invention can be used to define a mechanism enabling a customer to negotiate IP-addresses of desired sharing ratios based on their requirement. Thus customer orientated differentiated services may be provided for A+P address sharing. Moreover, embodiments of the invention thereby define a method enabling a customer to allocate as random ports as possible in their restricted port range thereby provide better security by preventing attacker's easy guessing the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port).

Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention that being determined by the appended claims.