[go: up one dir, main page]

WO2010072953A1 - SYSTEME D'ACHEMINEMENT D'UN PAQUET DE DONNEES IPv4 - Google Patents

SYSTEME D'ACHEMINEMENT D'UN PAQUET DE DONNEES IPv4 Download PDF

Info

Publication number
WO2010072953A1
WO2010072953A1 PCT/FR2009/052609 FR2009052609W WO2010072953A1 WO 2010072953 A1 WO2010072953 A1 WO 2010072953A1 FR 2009052609 W FR2009052609 W FR 2009052609W WO 2010072953 A1 WO2010072953 A1 WO 2010072953A1
Authority
WO
WIPO (PCT)
Prior art keywords
ipv4
address
context
data packet
ipv6
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/FR2009/052609
Other languages
English (en)
Inventor
Eric Burgey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
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 France Telecom SA filed Critical France Telecom SA
Publication of WO2010072953A1 publication Critical patent/WO2010072953A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • 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/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
    • 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/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • 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/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/251—Translation of Internet protocol [IP] addresses between different IP versions
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/166—IP fragmentation; TCP segmentation
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • 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/22—Parsing or analysis of headers

Definitions

  • the field of the invention is that of a telecommunications network, in particular an IP telecommunications network in which data packets are transported from a source equipment to a destination equipment identified by a destination address.
  • Such a telecommunications network groups a plurality of equipment, links and functions dedicated to the transport of data from terminal equipment connected to this network.
  • the transport functions can be implemented through the activation of routing and transmission protocols.
  • a telecommunications network administered by an operator is still called a domain.
  • IP connectivity service provider deploys a dedicated architecture to enable endpoint users to be reachable. Access to the IP connectivity service is managed by the service provider that relies on an operator's telecommunications network to route the data packets transmitted by the terminal equipment to their final destination. In some cases, said service provider is also the telecommunications network operator.
  • a type of addressing, public or private, commonly used in such an IP network is the addressing defined by the IPv4 protocol (Internet Protocol version 4).
  • IPv6 Internet Protocol version 6
  • GROW working group Global Routing Operations Working Group
  • the data packet is first routed to a network node equipment able to process that type of data packet.
  • This node equipment has a correspondence table associating with the pair formed by the shared address and the range of reserved port numbers, a unique identifier of the destination equipment.
  • This unique identifier for example a private IP address, is added to the data packet and allows routing of the data packet to the recipient client equipment.
  • a first drawback of this solution is that it imposes the memorization of the correspondence between the shared address and the destination equipment identifier in the node equipment, which creates a passage required by this node equipment.
  • a second disadvantage is that this solution requires the addition of this unique identifier to the data packet and therefore its modification by the node equipment.
  • the node equipment able to process this type of data packet is generally the equipment dedicated to the processing of all the packets intended for a shared address.
  • the client devices sharing the same address are grouped geographically.
  • Such node equipment is therefore located at a telecommunications network access network.
  • a third disadvantage of such a solution is that it imposes the implementation of a large number of nodes of this type in the telecommunications network, which represents a significant cost for an operator.
  • a fourth disadvantage of this solution is that it does not allow the routing of a data packet that does not include a destination port number. There is therefore a need to overcome these disadvantages of the prior art.
  • the invention responds to this need with the aid of a system for routing an IPv4 data packet sent by a source client equipment to a destination client equipment during a communication established in a network of telecommunications operator, said recipient client equipment having a public IP address shared with other client equipment connected to said IPv4 network, characterized in that:
  • IPv4 network is decomposed into a plurality of subnetworks
  • the plurality of client equipments sharing said IPv4 address is attached to said plurality of subnetworks, so as to connect at most one of said client equipments by sub-network;
  • said system comprises:
  • IPv4 data means for sending IPv4 data, by means of a point-to-point link established between the sending client equipment and identification means of the home subnetwork of the destination equipment;
  • client devices sharing the same IP address are not necessarily located in the same geographical area, nor managed by the same network node equipment. Instead, they can be scattered throughout the network so that they are all attached to different subnets.
  • the routing of the data packet to the subnet to which the client client equipment is attached is done using a context that is identified by a context identifier.
  • the context is related to a shared IPv4 address and identifies the subnet to which the recipient device is attached.
  • the data packet can be routed normally, without adding an IP address, since its destination address is unique in this subnet.
  • the invention thus makes it possible to solve the technical problem of the shortage of IPv4 addresses, without modifying the routing equipment of the access networks to the telecommunications network, or the client equipment connected to these access networks.
  • One advantage is to prepare a migration of the network to the IPv6 protocol without imposing that the client equipment nor the access network already in place have to support this protocol.
  • the IPv4 data packet comprises a shared IPv4 destination address and a port number belonging to a range of port numbers, said port number range being uniquely assigned to the subnet of the destination equipment, said context identifier is said port number.
  • the subnet of the destination device is therefore simply identified by determining the range of port numbers to which the destination port number of the data packet belongs.
  • the data packet comprising a second IPv4 address
  • the context identifier is said second IPv4 address of the data packet.
  • Such a context identifier is advantageously used when the data packet does not include a port number. However, it is not sufficient to directly identify the subnet of the destination equipment and must therefore be completed by at least one context data item that identifies the subnet and is stored in the routing system.
  • the data packet belonging to a datagram and comprising an identifier of said datagram, said context identifier is said datagram identifier.
  • a datagram is a sequence of data that can not always be transported in a single packet.
  • the datagram is fragmented into several packets, each of which includes the datagram identifier. Only the first package includes a port number.
  • An advantage of the datagram identifier is that it can constitute a context identifier used to store the port number upon receipt of the packet carrying the same datagram identifier and the port number.
  • said routing system comprises a node equipment comprising an interface with each of said sub-networks.
  • a single node device of the routing system according to the invention is dedicated to the routing of data packets intended for a shared IPv4 address. It comprises at least one logical interface with each of the subnets constituting the IPv4 network. It is therefore within this node equipment that the identification of the subnet of the destination equipment is performed. Such identification allows the node equipment to route the data packet to the correct logical interface. In a known manner, such an interface may be based on Ethernet, ATM (Asynchronous Transport Mode), Virtual Path Network (VPN) or any other network interface technology.
  • ATM Asynchronous Transport Mode
  • VPN Virtual Path Network
  • said system comprises a plurality of node devices capable of communicating with each other via means an IPv6 telecommunications network and such that for each subnetwork of said plurality of subnets there is at least one node equipment including an interface with that subnetwork.
  • the data packet is routed to a node equipment including an interface with that subnet.
  • a node equipment including an interface with that subnet.
  • the routing system comprises a first node equipment, able to implement, on receiving a data packet from the subnet with which it is interface: a context type of the shared destination address I Pv4; means for converting the IPv4 data packet received from the sending client equipment into an IPv6 data packet, said packet comprising a destination IPv6 address constructed from the source shared IPv4 address, the destination IPv4 address, and the context identifier and a prefix, said prefix being chosen according to the type of context determined; and means for sending the IPv6 data packet obtained in the IPv6 network.
  • IPv4 to an IPv6 data packet which may include the identifier of the home subnet of the sending equipment in its IPv6 source address and whose prefix of the IPv6 destination address is included in one of the prefixes routed over the IPv6 network to the next equipment in the routing system that will have to process this package.
  • This constructed IPv6 destination address is routable in the IPv6 network. Thus, this packet is routinely routed by standard routers of the IPv6 network.
  • the destination IPv6 address is not constructed in the same way according to the type of context associated with the shared IPv4 address.
  • a different prefix can be used, depending on which node equipment address the IPv6 packet that it has built to the node equipment of the home subnet of the receiving client equipment or other equipment of the system according to the invention.
  • the routing system comprises at least one device for storing an association between said shared IPv4 address, the IPv4 context identifier of the communication and the subscriber's subnetwork identifier.
  • the client equipment having said shared address, said equipment being able to provide, on reception of a request comprising the shared IPv4 address and the IPv4 context identifier, at least the subnetwork identifier.
  • the storage device thus makes it possible to associate a context data item with the source IPv4 associated context identifier of the IPv4 data packet. This is necessary when the IPv4 data packet does not itself have a home subnet identifier of the source equipment having the shared IPv4 address. This is particularly the case when the data packet does not include a port number.
  • the stored context data contains, either directly the subnet identifier associated with the shared source IPv4 address, or information to find this subnet identifier.
  • this subnet identifier is not lost when the IPv4 data packet leaves the IPv4 subnet from which it originates to be routed to its destination.
  • the subnet identifier associated with the shared IPv4 address become destination can be recovered from said storage means.
  • said first node device when the source IPv4 address is a shared address, said first node device is able to determine a context type of the source IPv4 address, and when the context type determined is a context with data, the first node device is able to choose the prefix of the destination address of the converted IPv6 data packet so that it reaches said context storage equipment for storing an association between said IPv4 source address shared, said context identifier and a context identifier data item. home network of the source client equipment.
  • At least one context storage device is able to implement, on receiving an IPv6 data packet from one of said node equipment:
  • search means in the database of an association between said destination IPv4 address, said context identifier and a context data item identifying the subnet of attachment of the receiving customer equipment;
  • the storage device (s) according to the invention thus makes it possible to recover the context data item identifying the attachment subnet of the destination equipment of the IPv4 data packet and to modify the IPv6 destination address constructed for it the node interface equipment with this subnet.
  • One advantage is to limit the storage operations to a limited number of system equipment and thus to limit the vulnerability of the system according to the invention to denial of service attacks.
  • the invention also relates to a node equipment of a system for routing a data packet to a destination customer equipment and a destination customer equipment, in an IPv4 telecommunications network, least said client equipment having an IPv4 public address shared with other client equipment connected to said IPv4 network.
  • such a node equipment is characterized in that: said IPv4 network is decomposed into a plurality of subnetworks; the plurality of client equipments sharing said IPv4 address being attached to said plurality of subnetworks, so as to connect at most one of said client equipments by subnet,
  • Said system comprising a plurality of node devices able to communicate between via an IPv6 network
  • said node equipment comprises: first means of communication with one of said IPV4 sub-networks; second communication means with other equipment nodes of said system via an IPv6 telecommunication network; means for determining a context type of the shared IPv4 destination address, able to be implemented on reception of an IPv4 data packet on said first communication means; means for converting the IPv4 data packet received on said first means into an IPv6 data packet, said packet comprising a destination IPv6 address constructed from the destination shared IPv4 address and the context identifier and an operator prefix, said prefix being chosen according to the determined context type related to the destination IPv4 address; and means for sending the IPv6 data packet obtained on the second communication means.
  • said node equipment comprises means for inverse conversion of an IPv6 data packet comprising a shared destination IPv4 address and a context identifier, to an IPv4 data packet comprising said destination address and the IPv4 data packet.
  • context identifier said inverse conversion means being able to be implemented on reception of the packet of data on the second means of communication, and means for sending the IPv4 data packet obtained on the first communication means in the IPv4 subnet interface with said node equipment.
  • the destination IPv6 address of the received packet may allow it to determine to which of these subnets it must deliver the IPv4 packet.
  • the node equipment according to the invention makes it possible to transmit data packets in the IPv6 network linking it to the other nodes of the routing system according to the invention. It also allows receiving IPv6 data packets received from other node devices.
  • the invention further relates to a method of processing a data packet transmitted by a source client equipment to a destination client equipment during a communication established in an IPv4 telecommunications network of an operator, said equipment recipient client having a public IP address shared with other client equipment connected to said IPv4 network, characterized in that:
  • IPv4 network is decomposed into a plurality of subnetworks
  • the plurality of client equipments sharing said IPv4 address is attached to said plurality of subnetworks, so as to connect at most one of said client equipments by sub-network;
  • Said system comprises a plurality of node devices capable of communicating with each other via an IPv6 network, and said method being able to be implemented by one of said node equipment, it comprises the following steps:
  • IPv6 data packet including a destination IPv6 address constructed from the destination shared IPv4 address and the context identifier and an operator prefix, said prefix being chosen according to the determined context type related to the destination IPv4 address; and - sending the IPv6 data packet obtained in the IPv6 network.
  • said method of processing further comprises the following steps, implemented on receipt of the data packet from the IPv6 network:
  • the various steps of the method of processing a data packet according to the invention are determined by instructions of computer programs.
  • the invention also relates to a computer program on an information carrier, this program being capable of being implemented in a node equipment or more generally in a computer, this program including instructions adapted to the implementation implement steps of a method of processing a data packet as described above.
  • the invention also relates to a method for storing a communication context associated with a source IPv4 address of a data packet sent by a client device to a destination client equipment during a communication established in a network.
  • IPv4 telecommunication method said address being shared with other client equipment connected to said IPv4 network and said packet comprising a context identifier of the communication, characterized in that: said IPv4 network is decomposed into a plurality of subnets; the plurality of client equipments sharing said IPv4 address is attached to said plurality of subnetworks, so as to connect at most one of said client equipments by sub-network; said context storage method comprising the following steps implemented upon receipt of a data packet comprising said shared IPv4 address:
  • the various steps of the method of storing a context of a data packet according to the invention are determined by instructions of computer programs.
  • the invention also relates to a computer program on an information carrier, this program being capable of being implemented in a Node equipment or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a method of storing a context of a data packet as described above.
  • FIG. 1 shows an example of a routing system of an IPv4 data packet according to a first embodiment of the invention
  • FIG. 2 shows an example of a routing system of a data packet in an IPv4 telecommunications network according to a second embodiment of the invention
  • FIG. 3 presents a method of processing an IPv4 data packet implemented by a node equipment according to the invention
  • FIG. 4 presents a method of processing an IPv6 data packet implemented by a node equipment according to the invention
  • Figure 5 shows the hardware structure of a node equipment according to the invention
  • FIG. 6 shows an exemplary format for converting an IPv4 address to IPv6 according to the invention used to form the IPv6 addresses destination of the packets sent to a device interface node with the public IPv4 network;
  • FIG. 7 shows an exemplary format for converting an IPv4 address into
  • FIG. 8 shows an exemplary format for converting an IPv4 address into IPv6 according to the invention used to form the IPv6 addresses destination packets sent to an interface node equipment with a subnet that is not the IPv4 public network;
  • Figure 9 shows the hardware structure of a node equipment according to the invention;
  • FIGS. 10 and 11 show a method of memorizing a communication context according to the invention;
  • FIG. 12 shows an example of a routing system of a data packet according to the invention, when the destination equipment comprises a compatible interface.
  • IP connectivity service Internet, Intranet, etc.
  • customer equipment considered will be domestic gateways. It should be noted, however, that the invention is not limited to this example and can be applied to any network, service or device using IPv4 addresses.
  • IPv4 telecommunications network into a plurality of subnets, such that two client devices sharing the same IPv4 address are attached to different subnets;
  • One of these subnets is the normal network or public IPv4 network that is composed of non-shared IPv4 addresses and all public addresses managed by other operators. For simplicity, it also encompasses in this network all shared IPv4 addresses belonging to other sets of disjoint shared IPv4 addresses (most often managed by other operators) that are accessible via the public IPv4 network.
  • Each of the other subnets is associated with a specific identifier or clone_sub_network_identifier.
  • the same IPv4 address, called Shared_ @ IPv4 can therefore be reused with different subnet IDs.
  • each pair (Shared_ @ IPv4, clone_sub_network_identifier) is unique. Subnets can be either
  • shared_ @ IPv4 shared addresses are used to route packets to their destination.
  • a communication context is usually associated with a communication.
  • a communication is a packet exchange between two interfaces so each has its own address.
  • Interface refers to the connection available to a device with a telecommunications network.
  • a normal public IPv4 address usually identifies a single interface. But this is no longer the case with shared IPv4 addresses.
  • To route a packet to the interface of a client device it is necessary to find the home subnet identifier of this client equipment or directly the client equipment attached to this shared IPv4 address from complementary information that the client 'we call communication context. This context may also contain other useful information. Note that the concept of communication applies to both protocols with or without port number.
  • a communication context is a set of information related to a shared IPv4 address shared_ @ IPv4 and which can consist of two types of items:
  • a context identifier which is formed of information exchanged in the packets, and which makes it possible to recognize the context.
  • This information can be transmitted either in the IP header of the packet or in the datagram (the data of the packet), for example in a protocol header (such as UDP or TCP headers).
  • a protocol header such as UDP or TCP headers.
  • the important thing is that in the datagram or the datagrams sent in response to a datagram that carries a context identifier one can find, not necessarily in the same place, the same context identifier; optional context data which, when they exist, are stored in a specific function (which in this case assumes a statefull device) and which can be retrieved on the basis of the context identifier and the shared IPv4 address shared_ @ IPv4 to which this context is linked.
  • a packet can therefore carry two context identifiers, one for its source address and another for its destination address.
  • the context is used to identify the home subnet of the client equipment. There are two cases: the case where the context identifier alone can identify the subnet; and the case where the identifier does not make it possible to identify the sub-network.
  • the subnet identifier is then carried by the context data.
  • a "communication" is then defined as the set of exchanged packets that even have the same pair of pairs ⁇ (source IPv4 address, source context identifier), (destination IPv4 address, destination context identifier) ⁇ .
  • context data When a communication context uses context data, it has a limited duration in time. When the context data is no longer useful or when it is no longer used for some time, the context data is erased. The context is then reset and we will talk about a new context when the context data will be used again.
  • the data of the shared IPv4 address shared_ @ IPv4 and the context makes it possible to unambiguously identify the interface which is concerned by the communication among all those which share this address, (for example, it is sufficient to be able to deduce the identifier subnet or an interface address that is not shared);
  • This context includes only a context identifier consisting of the port number. It uses the fact that in the response to a datagram the source and destination ports are inverted. It does not require context data because it is unique.
  • the subnet identifier is derived directly from the port number by virtue of the limitation according to a range of authorized ports; contexts based on other data specific to a particular communication, for example the IPv4 address of the other client equipment with which the communication is established, which constitutes a very simple context identifier.
  • This context example uses the fact that in the response to a packet the source and destination addresses are inverted.
  • the identifier of this context is not unique because in this case two interfaces located on different devices that share the same address shared_ @ IPv4 may want to communicate each in IPv4 with interfaces with identical IPv4 addresses (for example because they both talk with the same equipment). With this context, two interfaces sharing the same IPv4 address, can not communicate at the same time with the same interface or with two interfaces sharing the same IPv4 address. It will therefore change the source IPv4 address for the second communication to the same IPv4 address. In addition, it is necessary to add context data, which may be, for example, the subnet identifier. Other data can also be added to this context.
  • FIG. 1 there is shown a data packet routing system according to a first embodiment of the invention, wherein an IPv4 network 1 is broken down into four subnetworks SR1 to SR4.
  • the SR1 subnet is the public IPv4 network.
  • the routing system according to the invention comprises a node equipment EN comprising logical interfaces 11 to 14 with each of the sub-networks SR 1 to SR 4.
  • client equipment EC2 connected to the subnet IPv4 SR2 and it is assumed that this client equipment sends a data packet for the client equipment EC4, attached to the subnet SR4 and whose destination address is a shared IPv4 address shared_ @ IPv4.
  • the data packet includes context information that constitutes a context identifier for identifying the subnet EC4 of the IPv4 network to which the recipient client equipment is attached.
  • the context identifier is, for example constituted by the destination port number, this port number belonging to a range of port numbers reserved for the home subnet of the destination equipment.
  • the routing system comprises a node equipment EN comprising a communication interface with each of the subnetworks SR1 to SR4. Since the data packet is intended for another subnet, it must be sent directly to the node node EN in charge of processing this type of packet. It is understood that, since the shared shared IPv4 destination address shared @ IPv4 of the data packet could be assigned to a client equipment of the subnet, conventional routing techniques do not make it possible to route the data packet outside the data packet. subnet. Therefore, the system according to the invention comprises means for establishing a point-to-point link between the sending client equipment and the equipment node EN. A simple solution for achieving this point-to-point link is to build a tunnel TUN2 between the sending client equipment EC2 and the node equipment EN.
  • the sending client equipment EC2 can receive, on request from a DHCP server, the coordinates of the destination address of the tunnel TUN2 to the equipment node EN, for example in the form of a shared IPv4 address which is routable. without risk of confusion on the SR2 subnet. Note that this address can be the same on the other two interfaces with subnets SR3 and SR4.
  • the client equipment EC2 can then mount a tunnel with this equipment.
  • GRE Generic Routing Encapsulation
  • VPN Virtual Private Network
  • the client equipment EC2 then has two interfaces, the normal interface with the SR2 subnet and TUN2 tunnel.
  • the normal interface address with the subnet is its shared_ @ IPv4 shared address.
  • IPv4 address within the client equipment, to the interface constituted by the tunnel TUN2. This address will serve as the source address for the packets sent in the tunnel.
  • the node equipment EN is able to receive the data packet P2, to identify the destination subnet using the destination port number which constitutes an identifier of the destination subnet SR4 and to be switched the data packet on its logical interface with the SR4 subnet.
  • Such a routing system comprises a plurality of node equipments EN1 to EN4, which are connected to each other via a public IPv6 network 10. It is understood that such node devices each comprise at least one communication interface with one another. a subnet SR 1 , i integer from 1 to 4 and a communication interface with the IPv6 network 10. They are therefore necessarily arranged to communicate both according to the IPv4 and IPv6 protocols.
  • a data packet P3 sent by the client equipment EC3 of the subnet SR3 is considered to the client equipment EC2 having a shared address shared_ @ IPv4.
  • a link consists of a tunnel TUN 3 established between the sending client equipment EC3 and the node equipment EN3.
  • the sending client equipment EC3 can receive on request from a DHCP server the coordinates of the destination address of the tunnel TUN 3 to the node equipment EN3, for example in the form of a virtual IPv4 address.
  • This address represents the IPv4 / IPv6 transcoding function address of the EN3 node equipment.
  • the virtual term means that it is the same public IPv4 address that is used by all the node equipment ENi of the routing system according to the invention (even if several different node devices were connected to the same subnet SR3, which does not is not the case in the figure). Seen from the node EN3 equipment, it is an address that it must intercept for treatment as if it were his own address. The client equipment EC3 can then mount the tunnel TUN 3 , for example of the type
  • the system of routing according to the invention On receipt of the data packet P3 sent by a customer equipment of the subnet SR3, for example the equipment EC3 and intended for a client equipment having a shared IPv4 address shared_ @ IPv4, for example the equipment EC2, the system of routing according to the invention is able to send the data packet to the equipment node EN2.
  • the node equipment EN3 is able to implement the method of processing a data packet according to the invention which will now be described in relation to FIG. 3.
  • Such a method comprises a step E1 of FIG. receiving the IPv4 data packet P3 over the direct point-to-point connection TUN 3 established with the source client equipment EC3.
  • a context type is determined from the context identifier contained in the data packet. For example, if the protocol is of the TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) type, the context ID will be the port number and the context will be without data. If the protocol is of a type without port number then it will be a context with data.
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • the context identifier carries an identifier of the subnet attachment of the destination equipment EC2.
  • An IPv6 data packet is therefore built in E3 by converting the IPv4 P3 data packet using the usual conversion mechanisms between IPv4 and IPv6 (alternatively, the IPv4 P3 packet can be simply encapsulated in the IPv6 packet which facilitates the conversion but imposes longer packet headers that can lead to more fragmentation of packets).
  • the IPv6 destination address of this packet is constructed from the shared IPv4 destination address of the packet P3, the context identifier and an operator prefix designating the node equipment EN2.
  • the obtained destination IPv6 address is routable in the IPv6 network using standard routers.
  • a data packet P3_IPv6 is built in E3 from the IPv4 packet P3 with a destination address comprising a prefix designating EM context storage equipment. If, as in the example of the node EN3, this node is interfacing with a subnet that is not the IPv4 public network, this destination IPv6 address is constructed by applying a conversion format known as the non-number common conversion format. port, which will be described in section 5 of this description, with the source IPv4 address of the IPv4 packet. As noted in this section, if we have chosen to convert IPv4 packets to IPv6 packets rather than just encapsulation, we must also copy the destination IPv4 address into the lowest 32 bits of this address.
  • this destination IPv6 address would have been constructed by applying a format called common conversion format without port number, which will also be described in the section 5 of this description, with the IPv4 address destination of the IPv4 packet. Then, the data packet is sent in the IPv6 network, during a step E4.
  • the context is of type without data.
  • the context identifier is, for example, a port number belonging to a range reserved for the receiving client equipment.
  • the IPv6 data packet sent by the node equipment EN3 is received by a node equipment EN2.
  • this equipment is able to implement steps F1 to F3 of the method of processing a data packet according to the invention, which will now be described in relation to FIG. of the data type, the packet would have passed through one or two context storage devices, but the processing of the IPv6 packet received by the node would be the same.
  • the IPv6 data packet is received by the EN2 equipment from the IPv6 network 10.
  • an inverse IPv6 / IPv4 conversion step is performed on the received P3-IPv6 data packet, retrieving from the IPv6 network.
  • the obtained IPv4 P3 data packet is sent to the subnet
  • SR2 to be routinely routed from its IPv4 destination address, which is unique in the SR2 subnet. This package does not need to be placed in the TUN 211 tunnel.
  • a node device ENi, i 1 to 4, 100 which comprises the hardware elements conventionally found in a conventional computer, namely a processor 110, a processor, is presented.
  • random access memory type RAM 120 a read-only memory ROM 130 and first communication means 140 or interface with the IPv4 sub-network SRi and second communication means 150 or interface with the IPv6 network.
  • the ROM 130 constitutes a recording medium in accordance with the invention.
  • This medium stores the computer program according to the invention.
  • This program includes instructions for performing the steps of the method of processing a data packet according to the invention which has just been described with reference to FIG. 4.
  • IPv6 network for communications between the different node equipment makes it possible to separate the different functions implemented by the routing system according to the invention, so that only the IPv4 conversion functions / IPv6 and IPv6 / IPv4 performed by the node devices are specific, the other routing functions being performed by standard routing devices.
  • Another advantage relates to a location of the specific conversion functions mentioned above, which can be implemented very far upstream in the network and on a number of restricted node equipment, the number of node equipment concerned being related to the volume of traffic to deal with the processing capacity of each node, the routing topology retained by the operator and the requirements of securing the operator.
  • IPv4 packets exchanged during this communication will be converted a first time by IPv6 packets, then converted back to an IPv4 packet in a node device according to the invention to be routed on the public IPv4 network of the first operator, before being converted back to IPv6 in a node equipment of the second operator and finally again in IPv4.
  • IPv6 Intermediate IPv6 to IPv4 and then IPv4 to IPv6 conversions made in both node devices could be avoided if the operators agreed to exchange these packets directly in IPv6.
  • this agreement shall specify how to transmit an IPv4 data packet over IPv6 and, at least how to construct the source and destination IPv6 addresses of the IPv6 data packet obtained by converting the IPv4 data packet.
  • routing of data packets with port number coming from an IPv4 subnet according to the invention and intended for the public IPV4 network can be done directly on IPv4 by means of IPv4 routers that would interconnect the subnetwork IPv4 according to the invention and the public IPv4 network or IPv6 through the routing system described above.
  • IPv4 routers that would interconnect the subnetwork IPv4 according to the invention and the public IPv4 network or IPv6 through the routing system described above.
  • the routing of a packet of data from the public IPv4 network to an IPv4 subnet according to the invention must use the routing system via IPV6 described above.
  • routing of data packets without port number from an IPv4 subnet according to the invention and to the public IPV4 network must necessarily be via IPv6 and the routing system described above.
  • IPv6 address can be broken down into a prefix (whose length can be equal to, greater than or less than 64 bits) and an interface address.
  • This format is used to form the destination IPv6 addresses of packets sent to an interface node with the public IPv4 network when the IP protocol uses port numbers. It will also be used to form the source IPv6 addresses of packets sent over the IPv6 network by an interface node with the public IPv4 network if the IP protocol uses port numbers.
  • Such a format includes the port which identifies, the home subnet of the client equipment associated with the shared address.
  • IPv4 / IPv4 EN prefix represents an IPv6 prefix that will be routed to a node device that interfaces with the IPv4 public network or directly to a dual-stack home gateway that uses this shared IPv4 address.
  • this prefix may include a variable portion of the most significant bits of the IPv4 address, or even the entire IPv4 address and part of the port number constituting the port range.
  • This part of the IPv4 address represents the IPv4 prefix of the IPv4 packets that must be routed in IPv6 to this device.
  • IPv6 prefix By varying the size of this IPv6 prefix, the operator may decide to include or exclude IPv4 addresses in this prefix.
  • a dual-stack gateway IPv4 / IPv6
  • IPv4 / IPv6 IPv4 / IPv6
  • IPv4 / IPv6 IPv4 / IPv6
  • IPv4 subnet that includes only one device (itself) and for which the node device interface with this subnet is included in the gateway.
  • the prefix will have the maximum extension and will include the IPv4 address of the home gateway and the port range reserved for the gateway.
  • IPv4 IPv4 address
  • the operator must also ensure that there is a default route to all IPv4 addresses that are not managed by the routing system according to the invention. For this, he will make sure to create a default IPv6 route to the prefix "IP6 / IPv4 EN prefix" formed with all these IPv4 addresses (for example he will be able to use the minimum size which does not include the IPv4 address if he is assured that this conversion format will never be used with addresses managed by the routing system or if it has ensured that addresses formed by applying this conversion format to addresses managed by the routing system will be directed , via a shorter route, to another equipment that will convert them to others conversion formats described below). This default route will lead to an interface node equipment with the IPv4 public network.
  • the Common_portless_format common conversion format allows you to associate an IPv6 address with an IPv4 address for protocols that do not use a port number.
  • This format is used to form the destination IPv6 addresses of packets sent to an interface node with the public IPv4 network when the IP protocol does not use a port number. It will also be used to form the source IPv6 addresses of packets sent over the IPv6 network by a network interface node.
  • IPv4 public if the IP protocol does not use a port number.
  • This conversion format will also be used to form the destination IPv6 addresses of packets obtained by converting an IPv4 packet and which must be sent to a context storage means.
  • This algorithm can be very similar to the one used for the common_format and provide identical or different prefixes depending on the options chosen.
  • Some variants may only use this format, that is, ignore the port number to calculate the IPv6 address.
  • the port field is replaced by a reserved value, usually zeros.
  • IPv4 address is separated into two parts.
  • the low-order bits differentiate the different IPv4 addresses within this pool.
  • the portion that corresponds to the portion marked "IP6 / IPv4 EN prefix" in Figure 6 includes these high-order bits of the IPv4 address.
  • the operator can therefore divide the pool of shared IPv4 addresses into several pools allocated to different storage devices. This division of the shared IPv4 address pool is transparent to subnetwork interface nodes that still use the same address conversion format. It is the normal IPv6 routing mechanisms that manage this distribution.
  • the operator will ensure that there is at least one default route to one or more interfaces nodes with the IPv4 public network for prefixes "IPv6 / IPv4 EN prefix" formed by applying this common format without port number for IPv4 addresses that do not belong to these shared IPv4 address pools.
  • IPv6 packets sent by an interface node to the public IPv4 network, or sent by a context storage device, to a context storage device it is the destination IPv4 address that is used to form the address. IPv6 destination with this format.
  • IPv4 address that is used to form the IPv4.
  • the destination address of the IPv6 packet is the source address of the IPv4 packet. In the latter case, and only in the package conversion variant
  • IPv4 in IPv6 packets that does not use encapsulation one may need the 32 least significant bits, which are not yet affected, to store the destination IPv4 address. Indeed, in this variant, the original destination IPv4 address would be lost without it. This case is shown in relation to Figure 7.
  • This conversion format will also be used to form the source IPv6 addresses of IPv6 packets formed by converting an IPv4 packet by these same nodes.
  • IPv4 address is separated into two parts.
  • the high-order bits that are the IPv4 prefix of the IPv4 address pool assigned to this operator and that it has decided to share among multiple devices.
  • the least significant bits that differentiate the different IPv4 addresses within this pool.
  • IP6 / IPv4 internal prefix represents an IPv6 prefix that will be routed to a node device that interfaces with the IPv4 subnet that is assigned this port range for that IP pool. 'address. 6. Function of memorizing a communication context
  • the routing system comprises means for storing a communication context associated with a shared IPv4 address.
  • such means are advantageously implemented by at least one storage device EM of the routing system of a data packet according to the invention, which is dedicated to the storage of such a context. .
  • the use of such context storage equipment is particularly advantageous in the case of a data type context. Indeed, in this case, the IPv4 packet data does not carry the home subnet identifier of the client equipment associated with the shared IPv4 address. Therefore, it is necessary to associate a context data identifying this subnet.
  • This storage consists of registering an association between the shared IPv4 address, the context identifier and the context data identifying the subnet of the client equipment having the shared address. According to the invention, this association is accessed from the pair (shared IPv4 address, context identifier).
  • the context identifier is a port number belonging to the range of port numbers reserved for the client equipment having the shared address, it constitutes an identifier of this sub-network and the storage of a such association is not necessary.
  • the EM context storage device comprises the hardware elements conventionally found in a conventional computer, namely a processor 210, a type of random access memory.
  • RAM 220 for communication with the IPv6 network.
  • ROM type ROM 230 for communication with the IPv6 network.
  • the EM 200 context storage equipment comprises a memory 250 comprising a database in which are stored the associations between the shared IPv4 address, the context identifier and the context data identifying the home subnet of the client equipment using the shared address.
  • the ROM 230 constitutes a recording medium in accordance with the invention.
  • This medium stores the computer program according to the invention.
  • This program includes instructions for carrying out the steps of the method of memorizing a communication context of a data packet according to the invention which will now be described with reference to FIGS. 10 and 11. For clarity reasons each of these figures describes one of the two main branches of the process. Step M1 and the first decision to select the branch have been reproduced in both figures.
  • the processing branch On receipt M1 of an IPv6 data packet comprising a shared IPv4 source address and a context identifier, the processing branch is determined by comparing the shared IPv4 address that was used to form the destination IPv6 address to the common conversion without port number "with the source address of the IPv4 packet.
  • a step M2 for extracting the shared IPv4 source address and the context identifier is implemented.
  • M3 an associated context type is determined among the different contexts with data that can be implemented by the system.
  • this detection is based on the protocol number. For example, a specific context using the datagram identifier as the context identifier can be implemented for the ICMP protocol, whereas for the other protocols without a port number, the destination IPv4 address will instead be used as the context identifier attached to the ICMP protocol. the source IPv4 address.
  • a search in the database of an association between said source IPv4 address, said context identifier and an identifier of the subnet with which said node device is interface, is performed in M4.
  • a record of an association between said shared IPv4 source address, the context identifier and the subnet identifier is made at M5 and then proceed to the described step M6 below -if an association has been found including the subnet identifier, the destination address of the IPv6 data packet is replaced in M6 by an IPv6 address constructed by applying the "common conversion format without port number" to the destination IPv4 address (this address is in the encapsulated IPv4 packet if the encapsulated variant or in the least significant 32 bits of the received IPv6 address has been chosen if the direct conversion variant has been chosen) .
  • the shared source IPv4 address is replaced in M7 by another IPv4 address taken in a pool specifically assigned to the context storage equipment for that purpose, IPv4 packet source address is modified if the encapsulated variant has been chosen and an association between said other IPv4 address, the context identifier, the subnet identifier and the shared IPv4 address is recorded in M8 in the base of data.
  • a new source IPv6 address is constructed by applying the "common no port number conversion format" to the new source IPv4 address in M9 and step M6 already described. After step M6, all that remains is to send the packet over the IPv6 network to step M10.
  • step D1 for extracting the shared destination address IPv4 and the context identifier is implemented.
  • D2 an associated context type is determined among the different contexts with data that can be implemented by the system.
  • the context type is a context with no data (which can happen for ICMP error packets sent in response to a port number message and contain this port number in the packet) we go directly to the step D5.
  • the packet can not be routed and an ICMP error must be returned to D4.
  • the IPv6 packet is sent over the IPv6 network.
  • step 10 of Figure 10 it is possible for the context storage equipment to send itself an IPv6 packet.
  • the steps M6, M10, the new step M1, the decision and the step M2 may be omitted since the decision necessarily leads in this case to concluding the address.
  • the shared IPv4 that was used to form the IPv6 address to the "common conversion format without port number" is not the source address of the IPv4 packet, but its destination address. The only exception to this rule would be the case where the source shared IPv4 address is equal to the destination IPv4 address. But in this case the packet only serves to open the communication and can be destroyed.
  • the advantage of the solution of the invention is that it makes it possible to isolate the storage function in a single type of specific equipment, the other equipment constituting the routing system being stateless.
  • a data packet is intended to carry a sequence of data or datagrams.
  • datagrams that are too long can be broken down into multiple fragments that are transported by different packets. But in this case, the transport layer header carrying the data packet port identifiers only appears in the IPv4 data packet containing the first fragment (or offset fragment 0).
  • the routing system of a data packet comprises fragmentation storage equipment capable of storing the port number contained in the packet containing the first fragment and associating it with the packets carrying the other fragments.
  • fragmentation storage equipment capable of storing the port number contained in the packet containing the first fragment and associating it with the packets carrying the other fragments.
  • FM fragmentation storage equipment is shown in connection with FIG. 2.
  • An advantage is that thus all the packets of the fragment have a unique context identifier for the communication.
  • the routing system comprises fragmentation storage equipment capable of communicating in IPv6 with the node equipment and comprising said fragmentation storage means.
  • IPv6 routing mechanism is provided for aggregating packets containing fragmented datagrams to this equipment using the same shared IPv4 address shared @ IPv4. 8.
  • a data packet P4 issued by an EC4 client device having a shared IPv4 address shared_ @ IPv4 during a communication with a destination client equipment EC1 having a non-shared public IPv4 address is presented. It is considered that the IPv4 address of the sending client equipment EC4, or source address, is shared with a plurality of client equipments and that the IP communication uses a protocol without a port number. The context that is associated with this communication is therefore of type with data.
  • the data packet P4 is received by a node equipment EN4 of the routing system according to the invention. This node equipment EN4 knows the home subnet SR4 of the sending equipment because it is the subnet with which it is an interface and has received the packet via a point-to-point link with the client equipment EC4 of this subnet.
  • the node equipment EN4 is adapted to convert the IPv4 data packet into a P4_IPv6 data packet whose IPv6 destination address is constructed from a prefix specific to the EM context storage equipment in charge of storing the data.
  • IPv6 source address is constructed from a device-specific prefix that results from the application of the "internal conversion format" to the source IPv4 address and the port range that constitutes the identifier of the subnet SR4 of attachment of the client equipment EC4 transmitting the data packet P4.
  • the obtained IPv6 data packet is routed to an EM context storage equipment.
  • This equipment is able to extract the IPv6 source address from the P4_IPv6 packet, the IPv6 destination address, the IPv4 address source, the subnet identifier of the source IPv4 address, and the destination IPv4 address.
  • the EM context storage device is able to replace the shared source IPv4 address with a new IPv4 address New @ IPv4 belonging to an IPv4 set or pool of addresses reserved for it. .
  • IPv6 destination address will include the IPv4 address New @ IPv4.
  • the EM will query the database from the pair (New @ IPv4, EC2 @ IPv4) and obtain the ID-SR4 subnet ID and the IPv4 shared @ IPv4 address of the receiving client device.
  • IPv6 destination address of the packet may be routed to the EN4 node device, converted to IPv4 by the latter and routed routinely to the destination device EC4.
  • some client devices have a public IPv4 address and an interface with the IPv6 public network with a specific IPv6 address to receive IPv4 packets that have been converted to IPv6.
  • these devices respond to these IPv6 packets by other IPv6 packets that are the IPv6 conversion of IPv4 response packets to IPv6, but with an IPv6 destination address that is the source IPv6 address of the packets received, and if moreover they have a mechanism that allows them to communicate this IPV6 address and to announce that it is associated with an interface intended to receive IPv4 packets intended for this IPv4 address and converted into IPv6 packets, we will speak of fulLcompatible_interface.
  • a client equipment with a compatible interface is therefore a so-called “dual stack IPv4 / IPv6" equipment, which means that it is both able to communicate according to the IPv4 and IPv6 protocols.
  • Such client equipment therefore has: - a non-shared public IPv4 address that is said to be associated with the fuILcompatibleJnterface; an IPv6 interface which is the fuILcompatibleJnterface; an IPv6 address which is the address of the fuILcompatibleJnterface.
  • - a mechanism which allows him to make known to his correspondents the IPv6 address of the thread compatible with his IPv4 address.
  • IPv6 address obtained by applying to the public IPv4 address associated with the fuILcompatibleJnterface the "common conversion format without port number”. It is best if this address is different from the IPv6 address of the fuILcompatibleJnterface.
  • the destination address of the IPv6 packets sent in response to packets whose IPv6 address was obtained by applying the "common conversion format without port number” must be the IPv6 address obtained by applying the "conversion format" common without port number "at the destination IPv4 address.
  • IPv6 address of the network-related driver associated with an IPv4 address there are many mechanisms available to advertise the IPv6 address of the network-related driver associated with an IPv4 address such as publishing this association on a server.
  • a mechanism would be to send an IPv4 packet to the correspondent with a specific feature to recognize it and containing the IPv6 address of the fuILcompatibleJnterface and converted to an IPv6 packet whose destination IPv6 address would be the IPv6 address obtained by applying the "common conversion format without port number" applied to the IPv4 address of the correspondent would be preferable (note in passing that this is not the normal method of responding to packets sent to the fuILcompatiblejnterface but this is the response method to packets sent to the IPv6 address obtained by applying the "common conversion format without port number" to the IPv4 address associated with the full_compatile_interface).
  • an EC1 client device of the public IPv4 network is considered.
  • This equipment has a flexible interface. It is assumed that an EC3 client equipment having the shared shared IPv4 address establishes communication with the client equipment EC1. During this communication, the client equipment EC3 sends a data packet P3 to the client equipment EC1. It is assumed that this data packet does not have a port number.
  • the data packet is converted to an IPv6 packet by an EN3 node equipment and sent to an EM context storage equipment. It is assumed that at least one communication is already in progress between the EC1 equipment having the fuILcompatiblejnterface and an EC4 client equipment sharing the same IPv4 shared @ IPv4 address as the EC3 client equipment.
  • the EM context storage equipment has learned, during the restoration of the communication between the customer equipments EC3 and EC1, that the client equipment EC1 has an interface module whose interface it has learned and memorized the IPv6 address.
  • the source address of the IPv6 packet that has not been modified is always the IPv6 address that was constructed by the equipment EN4. So it's an IPv6 address built using the internal conversion format and it's routed on the IPv6 network to EN4.
  • the response of the full_compatible_interface will therefore be routed in IPv6 to EN4 without ever borrowing the public IPv4 network and without having to go through the context storage equipment.
  • the goal of saving IPv4 addresses is well preserved in this case.
  • IPv6 address with a prefix can, by abuse of language, consider that there are IPV6 prefixes associated with each format (or prefix formats). These prefixes can be used to broadcast the capabilities and processing modes that must be applied to shared IPV4 addresses. Information about the existence of these prefixes and their extent can simply be distributed over the IPV6 network through IPV6 routing information.
  • Each format can exist in two forms: have prefixes included in an operator-specific IPv6 prefix. This format information is then intended to be shared within the IPv6 network of this operator, but is not intended to be interpreted beyond; with a prefix included in a common prefix, to several operators who will then share a common management policy for this prefix. This mode is all the more interesting as the community of operators is extended. Ideally, this community would be the Internet community and that prefix be assigned by IANA.
  • IPV6 address generated by applying a format to a pair (shared_ @ IPv4, port) or (shared_ @ IPv4, subnet identifier) or to a shared_ @ IPv4 only (depending on the format) is well within the scope of an advertised prefix to infer that the address shared_ @ IPv4 has the characteristics and capabilities that characterize this format.
  • the algorithm is well designed and for formats that are intended to be exchanged with other operators, it is not necessary to know the value of the subnet identifier to determine this format information.
  • IPv6 prefixes can be aggregated and include IPv6 addresses, which are built by applying the commonjormat to IPv4 addresses, for which the aggregator is an aggregator. , did not receive any prefix on the IPv6 network. In this case this aggregation is allowed provided that the operator who carries it out sets up a route for these IPv6 addresses to an interface node with the IPv4 public network.
  • IPv4 address in a prefix of this type advertised on the IPV6 network means that the operator who advertises this prefix is ready to receive, over the IPv6 network, communications to these interfaces for protocols using a port number. It provides the necessary node equipment to route IPV6 network communications conforming to this encapsulation format to this IPV4 address. It can be noted that:
  • the announcement of this prefix does not provide any indication of the nature of the IPV4 address that can be both a normal IPv4 address and a Shared_ @ IPv4 shared address.
  • the announcement of a common_portless_format common format and the inclusion of an IPv4 address in a prefix of this type advertised on the IPV6 network means that the operator announcing this prefix is ready to receive, via the IPv6 network, communications to this interface for protocols that do not use a port number. It provides the necessary node equipment to route IPV6 network communications that do not use a port number, conforming to this encapsulation format to this IPV4 address.
  • the other rules, especially the aggregation rule are identical to the commonjormat rule.
  • a possible variant of the routing system according to the invention relates to the connection of client equipment having an interface Shared IPv4 and an IPv6 interface.
  • the case of "dual stack" home gateways capable of communicating with IPv6 client equipment and with terminal equipment of their home network that may be IPv4 and / or IPv6 is considered.
  • such a home gateway normally plays its role as a private IPv4 gateway to shared public IPv4 for the IPv4 client devices of its home network that wish to communicate with IPv4 recipient client devices of another subnet.
  • the home gateway also plays the role of interface node equipment with the subnet consisting of this single shared IPv4 address. It is understood that, in this variant, the client alone constitutes an IPv4 subnetwork within the meaning of the invention.
  • IPv4 address sharing mode is done according to a specific port number sharing mode, so that specific port ranges are reserved for this type of client equipment.
  • IPv6 addresses constructed by applying the aforementioned common-form IPv4 / IPv6 conversion technique, from: a shared IPv4 address according to the specific sharing mode; and a port number contained in the range corresponding to a given subnet; will be assigned as native IPv6 address to the IPv6 interface of the home gateway of the virtual subnet to which this shared IPv4 address has been assigned.
  • IPv4 / IPv6 conversion and IPv6 / IPv4 reverse conversion functions of a data packet are integrated into the home gateway.
  • Such a variant constitutes an evolution of the data packet routing system according to the invention, which makes it possible to adapt to the progressive replacement of IPv4 client gateway servers in IPv6 home gateways and more generally to the progressive migration towards the IPv6 whole. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un système d'acheminement d'un paquet de données IPv4 émis dans un réseau de télécommunications IPv4 d'un opérateur, à destination d'un équipement client possédant une adresse publique IP partagée avec d'autres équipements clients connectés audit réseau IPv4. Selon l'invention : ledit réseau IPv4 est décomposé en une pluralité de sous-réseaux; la pluralité d'équipements clients partageant ladite adresse IPv4 est rattaché à ladite pluralité de sous-réseaux, de façon à connecter au plus un desdits équipements clients par sous-réseau; et ledit système est apte à envoyer le paquet de données IPv4 par une liaison point à point établie entre l'équipement client émetteur à des moyens d'identification du sous- réseau de rattachement de l'équipement client destinataire du paquet, lesdits moyens étant aptes à identifier ledit sous-réseau à partir de l'adresse IPv4 de destination et d'un identifiant de contexte IPv4 de ladite communication contenu dans le paquet de données reçu de l'équipement client source et à acheminer ledit paquet IPv4 vers le sous-réseau identifié.

Description

Système d'acheminement d'un paquet de données IPv4
Domaine de l'invention
Le domaine de l'invention est celui d'un réseau de télécommunications, en particulier un réseau de télécommunications IP dans lequel sont transportés des paquets de données d'un équipement source vers un équipement de destination identifié par une adresse de destination.
Un tel réseau de télécommunications groupe une pluralité d'équipements, de liens et de fonctions dédiés au transport des données issues d'équipements terminaux connectés à ce réseau. En particulier, les fonctions de transport peuvent être implémentées grâce à l'activation de protocoles de routage et de transmission. Un réseau de télécommunications administré par un opérateur est encore appelé un domaine.
Un fournisseur de service de connectivité IP déploie une architecture dédiée pour permettre aux utilisateurs d'équipements terminaux d'être joignables. L'accès au service de connectivité IP est géré par le fournisseur de service qui s'appuie sur le réseau de télécommunications d'un opérateur pour router les paquets de données émis par les équipements terminaux vers leur destination finale. Dans certains cas, ledit fournisseur de service est aussi l'opérateur de réseau de télécommunications. Un type adressage, public ou privé, communément utilisé dans un tel réseau IP est l'adressage défini par le protocole IPv4 (Internet Protocol version 4).
Or il est communément admis par la communauté des fournisseurs de service IP que l'épuisement des adresses IPv4 publiques est une fatalité. Pour éviter ce problème, la communauté s'est mobilisée dans le passé, ce qui a conduit à la définition d'un nouveau protocole IPv6 (Internet Protocol version 6), qui offre un grand nombre d'adresses IP et un mécanisme de routage hiérarchique aux performances améliorées. Néanmoins, cette solution n'est en pratique pas activée par les opérateurs, pour des raisons financières ou stratégiques. Ces mêmes fournisseurs ne sont toutefois pas indifférents aux alarmes récemment émis par l'IETF (Internet Engineering Task Force), notamment dans des rapports présentés au sein du groupe de travail GROW (Global Routing Opérations Working Group) concernant un risque d'épuisement des adresses IPv4 de I1IANA fin 2009.
Le document intitulé "Provider-Provisioned CPE: IPv4 Connectivity Access in the context of IPv4 address exhaustion" et disponible sur le site http://www,ietf.orq/internet-drafts/draft-boucadair-port-ranqe-OO.txt enseigne une solution pour retarder l'épuisement d'adresses IPv4. Une telle solution consiste à partager une adresse IPv4 publique entre une pluralité d'équipements clients, les équipements clients étant différenciés entre eux lors du routage des paquets de données ayant pour adresse de destination l'adresse IPv4 partagée, par un numéro de port compris dans une plage de numéro de ports contrainte et réservée à chacun des équipements destinataires. Le paquet de données est d'abord routé vers un équipement nœud du réseau apte à traiter ce type de paquets de données. Cet équipement nœud dispose d'une table de correspondance associant au couple formé par l'adresse partagée et la plage de numéros de ports réservée, un identifiant unique de l'équipement destinataire. Cet identifiant unique, par exemple une adresse IP privée, est ajouté au paquet de données et permet le routage du paquet de données jusqu'à l'équipement client destinataire.
Un premier inconvénient de cette solution est qu'elle impose la mémorisation de la correspondance entre l'adresse partagée et l'identifiant d'équipement destinataire dans l'équipement nœud, ce qui crée un passage obligé par cet équipement nœud.
Un deuxième inconvénient est que cette solution nécessite l'ajout de cet identifiant unique au paquet de données et donc sa modification par l'équipement nœud.
Par ailleurs, l'équipement nœud apte à traiter ce type de paquet de données est généralement l'équipement dédié au traitement de tous les paquets destinés à une adresse partagée. Autrement dit, les équipements clients partageant la même adresse sont regroupés géographiquement. Un tel équipement nœud est donc situé au niveau d'un réseau d'accès au réseau de télécommunications. Un troisième inconvénient d'une telle solution est qu'elle impose la mise en œuvre d'un grand nombre d'équipements nœuds de ce type dans le réseau de télécommunications, ce qui représente un coût important pour un opérateur.
Un quatrième inconvénient de cette solution est qu'elle ne permet pas le routage d'un paquet de données ne comprenant pas de numéro de port de destination. II existe donc un besoin de pallier ces inconvénients de l'art antérieur.
Plus précisément, il existe un besoin de fournir une nouvelle solution pour économiser l'usage d'adresses IPv4 publiques, qui limite les impacts sur l'architecture du réseau de télécommunications, en particulier des réseaux d'accès IPv4 existants à ce réseau.
Exposé de l'invention
L'invention répond à ce besoin à l'aide d'un système d'acheminement d'un paquet de données IPv4 émis par un équipement client source à destination d'un équipement client destinataire au cours d'une communication établie dans un réseau de télécommunications d'un opérateur, ledit équipement client destinataire possédant une adresse publique IP partagée avec d'autres équipements clients connectés audit réseau IPv4, caractérisé en ce que :
- ledit réseau IPv4 est décomposé en une pluralité de sous-réseaux;
- la pluralité d'équipements clients partageant ladite adresse IPv4 est rattaché à ladite pluralité de sous-réseaux, de façon à connecter au plus un desdits équipements clients par sous-réseau; et
- ledit système comprend :
- des moyens d'envoi de données IPv4, par une liaison point à point établie entre l'équipement client émetteur et des moyens d'identification du sous-réseau de rattachement de l'équipement destinataire;
- des moyens d'identification du sous-réseau de rattachement de l'équipement client destinataire du paquet, à partir de l'adresse IPv4 de destination et d'un identifiant de contexte IPv4 de ladite communication contenu dans le paquet de données reçu de l'équipement client source; et des moyens d'acheminement dudit paquet IPv4 vers le sous-réseau identifié. Selon l'invention, les équipements clients partageant la même adresse IP ne sont plus nécessairement localisés dans la même zone géographique, ni gérés par un même équipement nœud du réseau. Ils peuvent au contraire être disséminés dans le réseau de façon à être tous rattachés à des sous-réseaux différents.
Ainsi, l'acheminement du paquet de données, jusqu'au sous-réseau auquel est rattaché l'équipement client destinataire, se fait à l'aide d'un contexte qui est identifié par un identifiant de contexte.
Le contexte est lié à une adresse IPv4 partagée et permet d'identifier le sous réseau auquel est rattaché l'équipement destinataire.
Une fois le sous réseau atteint, le paquet de données peut être routé normalement, sans ajout d'adresse IP, puisque son adresse de destination est unique dans ce sous-réseau.
L'invention permet ainsi de résoudre le problème technique de la pénurie d'adresses IPv4, sans modifier les équipements de routage des réseaux d'accès au réseau de télécommunications, ni les équipements clients connectés à ces réseaux d'accès.
Un avantage est de préparer une migration du réseau vers le protocole IPv6 sans imposer que les équipements clients ni le réseau d'accès déjà en place n'aient à supporter ce protocole.
Selon un aspect de l'invention, lorsque le paquet de données IPv4 comprend une adresse de destination IPv4 partagée et un numéro de port appartenant à une plage de numéros de ports, ladite plage de numéros de ports étant affectée de façon unique au sous-réseau de l'équipement destinataire, ledit identifiant de contexte est ledit numéro de port.
Le sous-réseau de l'équipement destinataire est donc simplement identifié en déterminant la plage de numéros de ports à laquelle appartient le numéro de port de destination du paquet de données. Selon un aspect de l'invention, le paquet de données comprenant une deuxième adresse IPv4, l'identifiant de contexte est ladite deuxième adresse IPv4 du paquet de données. Un tel identifiant de contexte est avantageusement utilisé, lorsque le paquet de données ne comprend pas de numéro de ports. Il n'est toutefois pas suffisant pour identifier directement le sous-réseau de l'équipement destinataire et doit donc être complété par au moins une donnée de contexte qui identifie le sous-réseau et est mémorisée dans le système d'acheminement.
Selon encore un autre aspect de l'invention, le paquet de données appartenant à un datagramme et comprenant un identifiant dudit datagramme, ledit identifiant de contexte est ledit identifiant de datagramme. Un datagramme est une séquence de données qui ne peut pas toujours être transportée dans un seul paquet. Dans ce cas, le datagramme est fragmenté sur plusieurs paquets, qui comprennent chacun l'identifiant de datagramme. Seul le premier paquet comprend un numéro de port. Un avantage de l'identifiant de datagramme est qu'il peut constituer un identifiant de contexte utilisé pour mémoriser le numéro de port lors de la réception du paquet portant le même identifiant de datagramme et le numéro de port.
Selon un premier mode de réalisation de l'invention, ledit système d'acheminement comprend un équipement nœud comprenant une interface avec chacun desdits sous-réseaux. Un unique équipement nœud du système de routage selon l'invention est dédié au routage des paquets de données destinés à une adresse IPv4 partagée. Il comprend au moins une interface logique avec chacun des sous-réseaux constituant le réseau IPv4. C'est donc au sein de cet équipement nœud que l'identification du sous- réseau de l'équipement destinataire est réalisée. Une telle identification permet à l'équipement nœud d'aiguiller le paquet de données vers la bonne interface logique. De façon connue, une telle interface peut être basée sur une technologie de type Ethernet, ATM (Asynchronous Transport Mode, en anglais), VPN (Virtual Path Network, en anglais) ou toute autre technologie d'interface réseau.
Selon un deuxième mode de réalisation de l'invention, ledit système comprend une pluralité d'équipements nœuds aptes à communiquer entre eux par l'intermédiaire d'un réseau de télécommunications IPv6 et tels que pour chaque sous-réseau de ladite pluralité de sous-réseaux il existe au moins un équipement nœud comprenant une interface avec ce sous-réseau.
Une fois le sous-réseau identifié, le paquet de données est routé jusqu'à un équipement nœud comprenant une interface avec ce sous-réseau. Un avantage est que l'acheminement des paquets de données destinés à une adresse partagée ne repose pas sur un seul équipement nœud.
Selon un aspect de l'invention, le système d'acheminement comprend un premier équipement nœud, apte à mettre en œuvre, sur réception d'un paquet de données en provenance du sous-réseau avec lequel il est interface : des moyens de détermination d'un type de contexte de l'adresse de destination I Pv4 partagée; des moyens de conversion du paquet de données IPv4 reçu de l'équipement client émetteur en un paquet de données IPv6, ledit paquet comprenant une adresse IPv6 de destination construite à partir de l'adresse IPv4 partagée source, de l'adresse IPv4 de destination et de l'identifiant de contexte et d'un préfixe, ledit préfixe étant choisi en fonction du type de contexte déterminé; et Des moyens d'envoi du paquet de données IPv6 obtenu dans le réseau IPv6.
On comprend que le premier équipement nœud convertit le paquet de données
IPv4 en un paquet de données IPv6 qui peut comprendre l'identifiant du sous-réseau de rattachement de l'équipement émetteur dans son adresse source IPv6 et dont le préfixe de l'adresse destination IPv6 est inclus dans un des préfixes routés sur le réseau IPv6 vers le prochain équipement du système d'acheminement qui devra traiter ce paquet. Cette adresse de destination IPv6 construite est routable dans le réseau IPv6. Ainsi, ce paquet est routé de façon classique par des routeurs standards du réseau IPv6.
On comprend en outre que, l'adresse IPv6 de destination n'est pas construite de la même façon selon le type de contexte associé à l'adresse IPv4 partagée. Avantageusement, un préfixe différent peut être utilisé, selon que l'équipement nœud adresse le paquet IPv6 qu'il a construit à l'équipement nœud du sous réseau de rattachement de l'équipement client destinataire ou à un autre équipement du système selon l'invention.
Selon un aspect de l'invention, le système d'acheminement comprend au moins un équipement de mémorisation d'une association entre ladite adresse IPv4 partagée, l'identifiant de contexte IPv4 de la communication et l'identifiant de sous-réseau de rattachement de l'équipement client possédant ladite adresse partagée, ledit équipement étant apte à fournir, sur réception d'une requête comprenant l'adresse IPv4 partagée et l'identifiant de contexte IPv4, au moins l'identifiant de sous-réseau. L'équipement de mémorisation selon l'invention permet ainsi d'associer une donnée de contexte à l'identifiant de contexte associé à IPv4 partagée source du paquet de données IPv4. Ceci est nécessaire lorsque le paquet de données IPv4 ne porte pas lui-même d'identifiant du sous-réseau de rattachement de l'équipement source possédant l'adresse IPv4 partagée. C'est notamment le cas lorsque le paquet de données ne comprend pas de numéro de port. On comprend que la donnée de contexte mémorisée contient, soit directement l'identifiant de sous-réseau associé à l'adresse IPv4 source partagée, soit une information permettant de retrouver cet identifiant de sous-réseau. Un avantage est d'éviter que cet identifiant de sous-réseau ne soit perdu lorsque le paquet de données IPv4 quitte le sous-réseau IPv4 dont il provient pour être acheminé vers sa destination. Lorsqu'un paquet de réponse arrivera, l'identifiant de sous-réseau associée à l'adresse IPv4 partagée devenue destination pourra être récupéré auprès desdits moyens de mémorisation.
Selon encore un autre aspect de l'invention, lorsque l'adresse IPv4 source est une adresse partagée, ledit premier équipement nœud est apte à déterminer un type de contexte de l'adresse IPv4 source, et lorsque le type de contexte déterminé est un contexte avec données, le premier équipement nœud est apte à choisir le préfixe de l'adresse de destination du paquet de données IPv6 converti de façon à ce qu'il parvienne audit équipement de mémorisation de contexte pour mémorisation d'une association entre ladite adresse source IPv4 partagée, ledit identifiant de contexte et une donnée de contexte identifiant de sous- réseau de rattachement de l'équipement client source.
Ainsi, lorsqu'une mémorisation de donnée de contexte est nécessaire, le paquet de données passe obligatoirement par l'équipement de mémorisation de contexte selon l'invention. Selon un autre aspect de l'invention, au moins un équipement de mémorisation de contexte est apte à mettre en oeuvre, sur réception d'un paquet de données IPv6 en provenance d'un desdits équipements nœuds:
- des moyens d'extraction de l'adresse de destination IPv4 partagée et de l'identifiant de contexte, - des moyens de détermination d'un type de contexte associé au paquet de données IPv6 reçu parmi un contexte sans données et un contexte avec données;
- si le type de contexte déterminé est un contexte avec données, des moyens de recherche dans la base de données d'une association entre ladite adresse IPv4 de destination, ledit identifiant de contexte et une donnée de contexte identifiant le sous- réseau de rattachement de l'équipement client destinataire;
- si une association a été trouvée, des moyens de remplacement de l'adresse de destination du paquet de données IPv6 par une adresse IPv6 construite à partir de l'adresse de destination partagée, de l'identifiant de sous-réseau trouvé et d'un préfixe opérateur. Le ou les équipements de mémorisation selon l'invention permettent donc de récupérer la donnée de contexte identifiant le sous-réseau de rattachement de l'équipement destinataire du paquet de données IPv4 et de modifier l'adresse de destination IPv6 construite pour qu'elle désigne l'équipement nœud interface avec ce sous-réseau. Un avantage est de limiter les opérations de mémorisation à un nombre limité d'équipements du système et donc de restreindre la vulnérabilité du système selon l'invention aux attaques de déni de service.
L'invention concerne aussi un équipement nœud d'un système d'acheminement d'un paquet de données à destination d'un équipement client destinataire et un équipement client destinataire, dans un réseau de télécommunications IPv4, l'un au moins desdits équipements clients possédant une adresse publique IPv4 partagée avec d'autres équipements clients connectés audit réseau IPv4.
Selon l'invention, un tel équipement nœud est caractérisé en ce que : - ledit réseau IPv4 étant décomposé en une pluralité de sous-réseaux; - la pluralité d'équipements clients partageant ladite adresse IPv4 étant rattachée à ladite pluralité de sous-réseaux, de façon à connecter au plus un desdits équipements clients par sous réseau,
Ledit système comprenant une pluralité d'équipements nœuds aptes à communiquer entre par l'intermédiaire d'un réseau IPv6, Ledit équipement nœud comprend : des premiers moyens de communication avec un desdits sous réseaux IPV4; des seconds moyens de communication avec d'autres équipements nœuds dudit système par l'intermédiaire d'un réseau de télécommunication IPv6; des moyens de détermination d'un type de contexte de l'adresse de destination IPv4 partagée, aptes à être mis en œuvre sur réception d'un paquet de données IPv4 sur lesdits premiers moyens de communication; des moyens de conversion du paquet de données IPv4 reçu sur lesdits premiers moyens en un paquet de données IPv6, ledit paquet comprenant une adresse IPv6 de destination construite à partir de l'adresse IPv4 partagée de destination et de l'identifiant de contexte et d'un préfixe opérateur, ledit préfixe étant choisi en fonction du type de contexte déterminé lié à l'adresse IPv4 destination ; et des moyens d'envoi du paquet de données IPv6 obtenu sur les deuxièmes moyens de communication.
Selon un aspect de l'invention, ledit équipement nœud comprend des moyens de conversion inverse d'un paquet de données IPv6 comprenant une adresse IPv4 de destination partagée et un identifiant de contexte, en un paquet de données IPv4 comprenant ladite adresse de destination et l'identifiant de contexte, lesdits moyens de conversion inverses étant aptes à être mis en œuvre sur réception du paquet de données sur les deuxièmes moyens de communication, et des moyens d'envoi du paquet de données IPv4 obtenu sur les premiers moyens de communication dans le sous réseau IPv4 interface avec ledit équipement nœud.
Selon une variante, si ledit équipement nœud est interface avec plusieurs sous- réseaux IPv4 de ladite pluralité de sous réseaux, l'adresse IPv6 destination du paquet reçu peut lui permettre de déterminer vers lequel de ces sous-réseaux il doit remettre le paquet IPv4.
L'équipement nœud selon l'invention permet d'émettre des paquets de données dans le réseau IPv6 le reliant aux autres équipements nœuds du système d'acheminement selon l'invention. Il permet aussi de recevoir des paquets de données IPv6 reçus en provenance des autres équipements nœuds.
L'invention concerne en outre un procédé de traitement d'un paquet de données émis par un équipement client source à destination d'un équipement client destinataire au cours d'une communication établie dans un réseau de télécommunications IPv4 d'un opérateur, ledit équipement client destinataire possédant une adresse publique IP partagée avec d'autres équipements clients connectés audit réseau IPv4, caractérisé en ce que :
- ledit réseau IPv4 est décomposé en une pluralité de sous-réseaux;
- la pluralité d'équipements clients partageant ladite adresse IPv4 est rattaché à ladite pluralité de sous-réseaux, de façon à connecter au plus un desdits équipements clients par sous-réseau;
Ledit système comprend une pluralité d'équipements nœuds aptes à communiquer entre eux par l'intermédiaire d'un réseau IPv6, et ledit procédé étant apte à être mis en œuvre par un desdits équipements nœuds, il comprend les étapes suivantes :
- détermination d'un type de contexte de l'adresse de destination IPv4 partagée, destinée à être mise en œuvre sur réception d'un paquet de données IPv4 en provenance d'un sous-réseau IPv4;
- conversion du paquet de données IPv4 reçu en un paquet de données IPv6, ledit paquet comprenant une adresse IPv6 de destination construite à partir de l'adresse IPv4 partagée de destination et de l'identifiant de contexte et d'un préfixe opérateur, ledit préfixe étant choisi en fonction du type de contexte déterminé lié à l'adresse IPv4 destination; et - envoi du paquet de données IPv6 obtenu dans le réseau IPv6.
Selon un aspect de l'invention, ledit procédé de traitement comprend en outre les étapes suivantes, mises en oeuvre sur réception du paquet de données en provenance du réseau IPv6 :
- conversion inverse du paquet de données IPv6 comprenant une adresse IPv4 de destination partagée et un identifiant de sous-réseau de rattachement de l'équipement client destinataire, en un paquet de données IPv4 comprenant ladite adresse de destination et l'identifiant de contexte, et
- envoi du paquet de données IPv4 obtenu dans le sous réseau IPv4 interface avec ledit équipement nœud. Dans un mode particulier de réalisation, les différentes étapes du procédé de traitement d'un paquet de données selon l'invention sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un équipement nœud ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de traitement d'un paquet de données tel que décrit ci-dessus.
L'invention concerne aussi un procédé de mémorisation d'un contexte de communication associé à une adresse IPv4 source d'un paquet de données émis par un équipement client à destination d'un équipement client destinataire au cours d'une communication établie dans un réseau de télécommunication IPv4, ladite adresse étant partagée avec d'autres équipements clients connectés audit réseau IPv4 et ledit paquet comprenant un identifiant de contexte de la communication, caractérisé en ce que : - ledit réseau IPv4 est décomposé en une pluralité de sous-réseaux; - la pluralité d'équipements clients partageant ladite adresse IPv4 est rattaché à ladite pluralité de sous-réseaux, de façon à connecter au plus un desdits équipements clients par sous-réseau; ledit procédé de mémorisation de contexte comprenant les étapes suivantes mises en œuvre sur réception d'un paquet de données comprenant ladite adresse IPv4 partagée:
- des moyens d'extraction de l'adresse source IPv4 partagée et de l'identifiant de contexte,
- des moyens de détermination d'un type de contexte associé, parmi un contexte sans données et un contexte avec données; - si le type de contexte déterminé est un contexte avec données, des moyens de recherche dans la base de données d'une association entre ladite adresse IPv4 source, ledit identifiant de contexte et un identifiant du sous-réseau avec lequel ledit équipement nœud est interface;
- si aucune association n'a été trouvée, des moyens d'enregistrement d'une association entre ladite adresse source IPv4 partagée, l'identifiant de contexte et l'identifiant de sous-réseau;
-si une association a été trouvée comprenant l'identifiant de sous-réseau, des moyens de remplacement de l'adresse de destination du paquet de données IPv6 par une adresse IPv6 construite à partir de l'adresse de destination du paquet de données IPv4 extraite du paquet IPv6 reçu, de l'identifiant du sous-réseau destinataire et d'un préfixe opérateur adapté; et
- si une association a été trouvée comprenant un autre identifiant de sous-réseau, des moyens de remplacement de l'adresse IPv4 source partagée par une autre adresse IPv4 et des moyens d'enregistrement d'une association entre ladite autre adresse IPv4, l'identifiant de contexte, l'identifiant de sous-réseau et l'adresse IPv4 partagée.
Dans un mode particulier de réalisation, les différentes étapes du procédé de mémorisation d'un contexte d'un paquet de données selon l'invention sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un équipement nœud ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de mémorisation d'un contexte d'un paquet de données tel que décrit ci-dessus.
Liste des figures
D'autres avantages et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 présente un exemple de système d'acheminement d'un paquet de données IPv4 selon un premier mode de réalisation de l'invention; la figure 2 présente un exemple de système d'acheminement d'un paquet de données dans un réseau de télécommunications IPv4 selon un deuxième mode de réalisation de l'invention; - la figure 3 présente un procédé de traitement d'un paquet de données IPv4 mis en œuvre par un équipement nœud selon l'invention; la figure 4 présente un procédé de traitement d'un paquet de données IPv6 mis en œuvre par un équipement nœud selon l'invention; la figure 5 présente la structure matérielle d'un équipement nœud selon l'invention; la figure 6 présente un exemple de format de conversion d'une adresse IPv4 en IPv6 selon l'invention utilisé pour former les adresses IPv6 destination des paquets envoyés vers un équipement nœud d'interface avec le réseau public IPv4; - la figure 7 présente un exemple de format de conversion d'une adresse IPv4 en
IPv6 selon l'invention utilisé par un équipement nœud d'interface avec un sous- réseau, qui n'est pas le réseau public IPv4, pour former les adresses IPv6 destination des paquets envoyés à un équipement de mémorisation des contextes; - la figure 8 présente un exemple de format de conversion d'une adresse IPv4 en IPv6 selon l'invention utilisé pour former les adresses IPv6 destination des paquets envoyés vers un équipement nœud d'interface avec un sous-réseau qui n'est pas le réseau public IPv4; la figure 9 présente la structure matérielle d'un équipement nœud selon l'invention; les figures 10 et 11 présentent un procédé de mémorisation d'un contexte de communication selon l'invention; la figure 12 présente un exemple de système d'acheminement d'un paquet de données selon l'invention, lorsque l'équipement destinataire comprend une interface compatible.
Description d'un mode de réalisation particulier de l'invention
Dans la suite de la description, nous nous placerons dans le contexte de l'accès au service de connectivité IP (Internet, Intranet, etc.) et les équipements clients considérés seront des passerelles domestiques. Il faut noter toutefois que l'invention n'est pas limitée à cet exemple et peut s'appliquer à tout réseau, service ou dispositif utilisant des adresses IPv4.
Pour rappel, les principes de l'invention sont les suivants :
- choisir un ou plusieurs ensembles d'adresses IPv4 dont les adresses seront partagées entre plusieurs équipements clients;
- décomposer le réseau de télécommunications IPv4 en une pluralité de sous-réseaux, de telle sorte que deux équipements clients partageant la même adresse IPv4 soient rattachés à des sous-réseaux différents; et
- associer à ladite adresse partagée des informations de contexte comprenant au moins un identifiant de contexte à partir duquel le routage du paquet de données pourra être effectué jusqu'au sous-réseau de l'équipement client destinataire. 1. La décomposition du réseau IPv4 en sous-réseaux
L'un de ces sous réseaux est le réseau normal ou réseau IPv4 public qui est composé d'adresses IPv4 non partagées et de toutes les adresses publiques gérées par d'autres opérateurs. Pour simplifier, on englobe aussi dans ce réseau toutes les adresses IPv4 partagées appartenant aux autres ensembles d'adresses IPv4 partagées disjoints (le plus souvent gérés par d'autres opérateurs) qui sont accessibles via le réseau IPv4 public.
Chacun des autres sous-réseaux est associé à un identifiant spécifique ou clone_sub_network_identifier. Une même adresse IPv4, appelée Shared_@IPv4 peut donc être réutilisée avec des identifiants de sous-réseaux différents. En revanche chaque couple (Shared_@IPv4, clone_sub_network_identifier) est unique. Les sous-réseaux peuvent être soit
- Réels c'est-à-dire qu'à l'intérieur du sous-réseau, les adresses partagées shared_@IPv4 sont utilisées pour effectuer le routage des paquets vers leur destination.
- Virtuels, c'est-à-dire que ce réseau est construit en "overlay" sur un autre réseau IPv4 ou IPv6.
2. Le contexte de communication
Un contexte de communication est généralement associé à une communication. Au sens des protocoles internet, une communication est un échange de paquets entre deux interfaces donc chacune possède sa propre adresse. On désigne par interface la connexion dont dispose un équipement avec un réseau de télécommunication. Une adresse IPv4 public normale identifie habituellement une interface unique. Mais ce n'est plus le cas avec les adresses IPv4 partagées. Pour acheminer un paquet vers l'interface d'un équipement client, il faut retrouver l'identifiant de sous-réseau de rattachement de cet équipement client ou directement l'équipement client attaché à cette adresse IPv4 partagée à partir d'informations complémentaires que l'on appelle contexte de communication. Ce contexte pourra également contenir d'autres informations utiles. On notera que la notion de communication s'applique aussi bien aux protocoles avec ou sans numéro de port.
On adopte donc la définition suivante :
Un contexte de communication est un ensemble d'informations liées à une adresse IPv4 partagée shared_@IPv4 et qui peut se composer des deux types d'éléments suivants :
- un identifiant de contexte, qui est formé d'informations échangées dans les paquets, et qui permettent de reconnaître le contexte. Ces informations peuvent être transmises soit dans l'en-tête IP du paquet, soit dans le datagramme (les données du paquet), par exemple dans un en-tête de protocole (comme les entêtes UDP ou TCP). L'important est que dans le datagramme ou les datagrammes envoyés en réponse à un datagramme qui porte un identifiant de contexte on puisse retrouver, pas nécessairement à la même place, le même identifiant de contexte; - des données de contexte optionnelles qui, lorsqu'elles existent, sont mémorisées dans une fonction spécifique (ce qui suppose dans ce cas un équipement "statefull") et qui peuvent être retrouvées sur la base de l'identifiant de contexte et de l'adresse IPv4 partagée shared_@IPv4 à laquelle ce contexte est lié. Un paquet peut donc porter deux identifiants de contexte, un pour son adresse source et un autre pour son adresse destination.
Le contexte permet d'identifier le sous-réseau de rattachement de l'équipement client. On distingue deux cas : le cas où l'identifiant de contexte permet à lui seul d'identifier le sous-réseau; et - le cas où l'identifiant ne permet pas d'identifier le sous-réseau. L'identifiant de sous-réseau est alors porté par les données de contexte. Une "communication" est alors définie comme l'ensemble des paquets échangés qui ont même la même paire de couples {(adresse IPv4 source, identifiant de contexte source), (adresse IPv4 de destination, identifiant de contexte de destination)}. Lorsqu'un contexte de communication utilise des données de contexte, il a une durée limitée dans le temps. Lorsque les données de contexte ne sont plus utiles ou lorsqu'elles ne sont plus utilisées depuis un certain temps, les données de contexte sont effacées. Le contexte est alors réinitialisé et on parlera d'un nouveau contexte lorsque les données de contexte seront de nouveau utilisées.
On ne s'intéressera donc par la suite qu'à des contextes de communication qui ont les deux propriétés suivantes :
Les données de l'adresse IPv4 partagée shared_@IPv4 et du contexte permettent d'identifier sans ambiguïté l'interface qui est concernée par la communication parmi toutes celles qui partagent cette adresse, (par exemple, il suffit de pouvoir en déduire l'identifiant de sous-réseau ou une adresse d'interface qui n'est pas partagée);
- Un même identifiant de contexte ne peut généralement pas être associé deux fois à la même adresse partagée shared_@IPv4, même s'il existe une exception à cette règle.
Cela signifie qu'à un instant donné deux interfaces qui partagent la même adresse shared_@IPv4 ne peuvent communiquer simultanément en IPv4 que si les identifiants de contexte de ces deux communications sont différents. Sinon, pour un paquet d'une des deux communications qui porte cette adresse partagée, il ne serait plus possible de déterminer lequel de ces deux contextes est associé à cette adresse.
On peut citer deux types principaux de contextes :
- le contexte basé sur un numéro de port appartenant à une plage de numéros de ports réservée à un sous-réseau. Ce contexte comprend seulement un identifiant de contexte constitué du numéro port. Il utilise le fait que dans la réponse à un datagramme les ports source et destination sont inversés. Il ne nécessite pas de données de contexte, car il est unique. Selon l'invention, l'identifiant de sous-réseau est dérivé directement du numéro de port grâce à la limitation selon une plage de ports autorisés; - les contextes basés sur d'autres données propres à une communication particulière, par exemple l'adresse IPv4 de l'autre équipement client avec lequel la communication est établie, qui constitue un identifiant de contexte très simple. Cet exemple de contexte utilise le fait que dans la réponse à un paquet les adresses source et destination sont inversées. Malheureusement l'identifiant de ce contexte n'est pas unique car dans ce cas deux interfaces situés sur des équipements différents qui partagent la même adresse shared_@IPv4 peuvent vouloir communiquer chacune en IPv4 avec des interfaces possédant des adresses IPv4 identiques (par exemple parce qu'elles dialoguent toutes deux avec le même équipement). Avec ce contexte, deux interfaces partageant la même adresse IPv4, ne peuvent pas communiquer au même instant avec la même interface ou avec deux interfaces partageant la même adresse IPv4. Il faudra donc changer l'adresse IPv4 source pour la deuxième communication vers la même adresse IPv4. De plus il est nécessaire de lui ajouter des données de contexte, qui peuvent être, à titre d'exemple, l'identifiant de sous-réseau. On peut également ajouter d'autres données à ce contexte.
Bien entendu, d'autres contextes peuvent être utilisés dans le cadre de l'invention. C'est le cas, en particulier, pour des paquets de type ICMP (Internet Control Message Protocol).
3. Un premier mode de réalisation d'un système d'acheminement selon l'invention
En relation avec la Figure 1 , on présente un système d'acheminement d'un paquet de données selon un premier mode de réalisation de l'invention, dans lequel un réseau IPv4 1 est décomposé en quatre sous-réseaux SR1 à SR4. Dans cet exemple, le sous-réseau SR1 constitue le réseau IPv4 public. Le système d'acheminement selon l'invention comprend un équipement nœud EN comprenant des interfaces logiques 11 à 14 avec chacun des sous-réseaux SR 1 à SR4. On considère maintenant l'équipement client EC2 connecté au sous-réseau IPv4 SR2 et on suppose que cet équipement client émet un paquet de données destiné à l'équipement client EC4, rattaché au sous- réseau SR4 et dont l'adresse de destination est une adresse IPv4 partagée shared_@IPv4. Selon l'invention, le paquet de données comprend des informations de contexte qui constituent un identifiant de contexte permettant d'identifier le sous réseau EC4 du réseau IPv4 auquel est rattaché l'équipement client destinataire. Dans cet exemple, l'identifiant de contexte est, par exemple constitué par le numéro de port de destination, ce numéro de port appartenant à une plage de numéros de ports réservée au sous-réseau de rattachement de l'équipement destinataire.
Selon ce mode de réalisation de l'invention, le système d'acheminement comprend un équipement nœud EN comprenant une interface de communication avec chacun des sous-réseaux SR1 à SR4. Le paquet de données étant destiné à un autre sous-réseau, il doit être envoyé directement à l'équipement nœud EN en charge du traitement de ce type de paquets. On comprend en effet que, puisque l'adresse IPv4 partagée de destination shared@IPv4 du paquet de données pourrait être affectée à un équipement client du sous-réseau, les techniques de routage classiques ne permettent pas de router le paquet de données en dehors du sous-réseau. Par conséquent, le système selon l'invention comprend des moyens d'établissement d'une liaison point à point entre l'équipement client émetteur et l'équipement nœud EN. Une solution simple pour réaliser cette liaison point à point est de construire un tunnel TUN2 entre l'équipement client émetteur EC2 et l'équipement nœud EN.
De façon avantageuse, l'équipement client émetteur EC2 peut recevoir, sur requête d'un serveur DHCP, les coordonnées de l'adresse destination du tunnel TUN2 vers l'équipement nœud EN par exemple sous forme d'une adresse IPv4 partagée qui est routable sans risque de confusion sur le sous-réseau SR2. On notera que cette adresse peut être la même sur les deux autres interfaces avec les sous réseaux SR3 et SR4. L'équipement client EC2 peut alors monter un tunnel avec cet équipement. Un tunnel GRE (Generic Routing Encapsulation) est en général suffisant mais toutes les autres formes connues de liaison point à point ou de VPN (Virtual Private Network) sont utilisables (on peut citer à titre d'exemple les tunnels IPv4 dans IPv4, les tunnels L2TP, les VLAN Ethernet, les VC ATM, Les Label Stack Path MPLS). A ce stade, l'équipement client EC2 dispose alors de deux interfaces, l'interface normale avec le sous-réseau SR2 et le tunnel TUN2. L'adresse de l'interface normale avec le sous- réseau est son adresse partagée shared_@IPv4. Toutefois, il faut alors attribuer une adresse IPv4, au sein de l'équipement client, à l'interface constituée par le tunnel TUN2. Cette adresse servira d'adresse source pour les paquets envoyés dans le tunnel. Par dérogation aux règles usuelles qui veulent que deux interfaces différentes possèdent des adresses IPv4 différentes, on propose d'utiliser également l'adresse partagée shared_@IPv4, car ce sont plus deux composants d'une même interface que deux interfaces différentes. En variante, il est tout à fait possible de choisir une autre adresse pour l'une ou l'autre de ces deux adresses. L'équipement nœud EN selon l'invention est apte à recevoir le paquet de données P2, à identifier le sous-réseau de destination à l'aide du numéro de port de destination qui constitue un identifiant du sous réseau de destination SR4 et à aiguiller le paquet de données sur son interface logique avec le sous réseau SR4.
Une fois dans le sous-réseau SR4, le routage du paquet de données ne pose plus de problème, car son adresse de destination shared_@IPv4 y est unique.
4. Un deuxième mode de réalisation d'un système d'acheminement selon l'invention
En relation avec la Figure 2, on présente maintenant un système d'acheminement selon un deuxième mode de réalisation de l'invention. Un tel système d'acheminement comprend une pluralité d'équipements nœuds EN1 à EN4, lesquels sont connectés entre eux par l'intermédiaire d'un réseau IPv6 public 10. On comprend que de tels équipements nœuds comprennent chacun au moins une interface de communication avec un sous-réseau SR1, i entier de 1 à 4 et une interface de communication avec le réseau IPv6 10. Ils sont donc nécessairement agencés pour communiquer à la fois selon les protocoles IPv4 et IPv6.
On considère un paquet de données P3 émis par l'équipement client EC3 du sous-réseau SR3 à destination de l'équipement client EC2 possédant une adresse partagée shared_@IPv4. De la même façon que précédemment, ce paquet de données envoyé directement à l'équipement nœud EN3 en charge du routage des paquets à destination d'adresses IPv4 partagées via une liaison point à point établie entre l'équipement client EC3 et l'équipement nœud EN3. A titre d'exemple, une telle liaison est constituée d'un tunnel TUN3 établi entre l'équipement client émetteur EC3 et l'équipement nœud EN3. De façon avantageuse, l'équipement client émetteur EC3 peut recevoir sur requête auprès d'un serveur DHCP les coordonnées de l'adresse destination du tunnel TUN3 vers l'équipement nœud EN3, par exemple sous forme d'une adresse IPv4 virtuelle. Cette adresse représente l'adresse de la fonction de transcodage IPv4/IPv6 de l'équipement nœud EN3. Le terme virtuel signifie que c'est la même adresse IPv4 publique qui est utilisée par tous les équipements nœuds ENi du système de routage selon l'invention (même si plusieurs équipements nœuds différents étaient raccordés au même sous-réseau SR3, ce qui n'est pas le cas sur la figure). Vu de l'équipement nœud EN3, c'est une adresse qu'il doit intercepter pour traitement comme si c'était sa propre adresse. L'équipement client EC3 peut alors monter le tunnel TUN3, par exemple de type
GRE ou VPN, avec l'équipement nœud EN3.
Sur réception du paquet de données P3 émis par un équipement client du sous- réseau SR3, par exemple l'équipement EC3 et destiné à un équipement client possédant une adresse IPv4 partagée shared_@IPv4, par exemple l'équipement EC2, le système d'acheminement selon l'invention est apte à envoyer le paquet de données vers l'équipement nœud EN2.
Selon l'invention, l'équipement nœud EN3 est apte à mettre en œuvre le procédé de traitement d'un paquet de données selon l'invention qui va maintenant être décrit en relation avec la Figure 3. Un tel procédé comprend une étape E1 de réception du paquet de données IPv4 P3 sur la liaison point à point directe TUN3 établie avec l'équipement client source EC3. En E2, un type de contexte est déterminé à partir de l'identifiant de contexte contenu dans le paquet de données. Par exemple, si le protocole est du type TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol), l'identifiant de contexte sera le numéro de port et le contexte sera sans données. Si le protocole est d'un type sans numéro de port alors il s'agira d'un contexte avec données.
S'il est établi qu'il s'agit d'un contexte sans données, l'identifiant de contexte est porteur d'un identifiant du sous-réseau de rattachement de l'équipement destinataire EC2. Un paquet de données IPv6 est donc construit en E3 par conversion du paquet de données IPv4 P3 en utilisant les mécanismes usuels de conversion entre IPv4 et IPv6 (dans une variante, le paquet IPv4 P3 peut être simplement encapsulé dans le paquet IPv6 ce qui facilite la conversion mais impose des en-têtes de paquets plus longs qui peuvent conduire à fragmenter davantage de paquets). L'adresse de destination IPv6 de ce paquet est construite à partir de l'adresse de destination IPv4 partagée du paquet P3, de l'identifiant de contexte et d'un préfixe opérateur désignant l'équipement nœud EN2. Ainsi, l'adresse IPv6 de destination obtenue est routable dans le réseau IPv6 à l'aide de routeurs standards.
Si au contraire, il est établi que le contexte est de type avec données (par exemple parce que le protocole IP n'utilise pas de numéro de port), un paquet de données P3_IPv6 est construit en E3 à partir du paquet IPv4 P3 avec une adresse de destination comprenant un préfixe désignant un équipement de mémorisation de contexte EM. Si, comme dans l'exemple du nœud EN3, ce nœud est interface avec un sous-réseau qui n'est pas le réseau public IPv4, cette adresse IPv6 de destination est construite en appliquant un format de conversion dit format de conversion commun sans numéro de port, qui sera décrit en section 5 de cette description, avec l'adresse IPv4 source du paquet IPv4. Comme indiqué dans cette section, si on a choisi de faire une conversion des paquets IPv4 en paquet IPv6 plutôt qu'une simple encapsulation, il faut alors également recopier l'adresse IPv4 destination dans les 32 bits de poids les plus faibles de cette adresse.
Dans le cas d'un équipement nœud tel que EN1 qui est interface avec le réseau public IPv4, cette adresse IPv6 de destination aurait été construite en appliquant un format dit format de conversion commun sans numéro de port, qui sera lui aussi décrit à la section 5 de cette description, avec l'adresse IPv4 destination du paquet IPv4. Ensuite, le paquet de données est envoyé dans le réseau IPv6, au cours d'une étape E4.
Dans la suite de cet exemple, on suppose que le contexte est de type sans données. L'identifiant de contexte est, par exemple, un numéro de port appartenant à une plage réservée à l'équipement client destinataire.
Selon l'invention, le paquet de données IPv6 émis par l'équipement nœud EN3 est reçu par un équipement nœud EN2. Selon l'invention, cet équipement est apte à mettre en œuvre les étapes F1 à F3 du procédé de traitement d'un paquet de données selon l'invention, qui vont maintenant être décrites en relation avec la Figure 4. Si le contexte avait été du type avec données, le paquet aurait transité par un ou deux équipements de mémorisation de contexte, mais le traitement du paquet IPv6 reçu par le nœud serait le même. En F1 , le paquet de données IPv6 est reçu par l'équipement EN2 en provenance du réseau IPv6 10. En F2, une étape de conversion IPv6/IPv4 inverse est effectuée sur le paquet de données P3-IPv6 reçu, en extrayant de l'adresse IPv6 de destination l'adresse partagée shared@IPv4 de destination, de l'adresse IPv6 source l'adresse IPv4 source et en reconstruisant le paquet de données IPv4 P3 à partir des informations extraites et des mécanismes usuels de conversion entre IPv6 et IPv4 (ou en extrayant simplement le paquet IPv4 encapsulé dans la variante avec encapsulation). En F3, le paquet de données IPv4 P3 obtenu est envoyé dans le sous-réseau
SR2 pour y être routé de façon classique à partir de son adresse de destination IPv4, qui est unique dans le sous-réseau SR2. Ce paquet n'a pas besoin d'être placé dans le tunnel TUN211.
En relation avec la Figure 5, on présente un équipement nœud ENi, i entier de 1 à 4, 100 selon l'invention, qui comporte les éléments matériels que l'on retrouve classiquement dans un ordinateur conventionnel, à savoir un processeur 110, une mémoire vive de type RAM 120, une mémoire morte de type ROM 130 et des premiers moyens 140 de communication ou interface avec le sous-réseau IPv4 SRi et des deuxièmes moyens 150 de communication ou interface avec le réseau IPv6. La mémoire morte 130 constitue un support d'enregistrement conforme à l'invention. Ce support mémorise le programme d'ordinateur conforme à l'invention. Ce programme comporte des instructions pour l'exécution des étapes du procédé de traitement d'un paquet de données conforme à l'invention qui vient d'être décrit en référence à la Figure 4.
On comprend donc que l'utilisation d'un réseau IPv6 pour les communications entre les différents équipements nœuds permet de séparer les différentes fonctions mises en œuvre par le système d'acheminement selon l'invention, de telle sorte que seules les fonctions de conversion IPv4/IPv6 et IPv6/IPv4 réalisées par les équipements nœuds soient spécifiques, les autres fonctions de routage étant effectuées par des équipements de routage standards.
Un autre avantage concerne une localisation des fonctions de conversion spécifiques précédemment évoquées, qui peuvent être mises en œuvre très en amont dans le réseau et sur un nombre d'équipements nœuds restreints, le nombre d'équipements nœuds concernés étant liés au volume de trafic à traiter, à la capacité de traitement de chaque nœud, à la topologie de routage retenue par l'opérateur et aux exigences de sécurisation de l'opérateur.
On comprend en outre que si une communication est établie entre les réseaux IPv4 de deux opérateurs qui mettent en œuvre un système d'acheminement de paquets de données selon l'invention, les paquets IPv4 échangés lors de cette communication vont être convertis une première fois en paquets IPv6, puis reconvertis en paquet IPv4 dans un équipement nœud selon l'invention pour être acheminés sur le réseau IPv4 public du premier opérateur, avant d'être reconverti en IPv6 dans un équipement nœud du deuxième opérateur et enfin à nouveau en IPv4.
Les conversions intermédiaires IPv6 vers IPv4 puis IPv4 vers IPv6 réalisées dans les deux équipements nœuds pourraient être évitées si les opérateurs se mettaient d'accord pour échanger ces paquets directement en IPv6.
En supposant qu'une communauté d'opérateur, la plus large possible, puisse s'accorder sur un mécanisme commun d'échange de paquets de données, cet accord devra préciser comment transmettre un paquet de données IPv4 en IPv6 et, au moins comment construire les adresses IPv6 source et destination du paquet de données IPv6 obtenu par conversion du paquet de données IPv4.
On notera que le routage des paquets de données avec numéro de port venant d'un sous-réseau IPv4 selon l'invention et à destination du réseau IPV4 public peut se faire directement en IPv4 par le biais de routeurs IPv4 qui interconnecteraient le sous- réseau IPv4 selon l'invention et le réseau IPv4 public ou en IPv6 à travers le système d'acheminement décrit précédemment. Mais le routage d'un paquet de données venant du réseau IPv4 public vers un sous-réseau IPv4 selon l'invention doit utiliser le système d'acheminement via IPV6 décrit précédemment. De même le routage des paquets de données sans numéro de port venant d'un sous-réseau IPv4 selon l'invention et à destination du réseau IPV4 public doit se faire nécessairement via IPv6 et le système d'acheminement décrit précédemment.
5. Formats de conversion IPv4/IPv6
Trois formats de conversion vont maintenant être décrits, à titre d'exemple :
- le format de conversion commun : afin d'optimiser les communications, différents opérateurs peuvent s'accorder sur un format de conversion permettant d'associer une adresse IPV6 à un couple (adresse_IPv4, port). Dans la suite, on désignera ce format d'adresse IPv6 par commonjormat, dont un exemple est présenté en relation avec la
Figure 6. Comme toute adresse IPv6 celle-ci peut se décomposer en un préfixe (dont la longueur peut être égale, supérieure ou inférieure à 64 bits) et une adresse d'interface.
Ce format est utilisé pour former les adresses IPv6 destination des paquets envoyés vers un nœud interface avec le réseau IPv4 public lorsque le protocole IP utilise des numéros de port. Il sera également utilisé pour former les adresses IPv6 source des paquets envoyés sur le réseau IPv6 par un nœud interface avec le réseau IPv4 public si le protocole IP utilise des numéros de port. Un tel format inclut le port ce qui permet d'identifier, le sous-réseau de rattachement de l'équipement client associé à l'adresse partagée.
Il existe un algorithme qui permet d'extraire l'adresse_IPv4 à partir de l'adresse IPv6. La partie de cette adresse marquée "IP6/IPv4 EN prefix" sur la Figure 6 représente un préfixe IPv6 qui sera routé vers un équipement nœud qui fait l'interface avec le réseau public IPv4 ou directement vers une gateway domestique dual-stack qui utilise cette adresse IPv4 partagée.
On notera que ce préfixe peut inclure une partie variable des bits de poids fort de l'adresse IPv4, voir même toute l'adresse IPv4 et une partie du numéro de port constituant la plage de port. Cette partie de l'adresse IPv4 représente le préfixe IPv4 des paquets IPv4 qui doivent être routés en IPv6 vers cet équipement.
En jouant sur la taille de ce préfixe IPv6, l'opérateur peut décider d'inclure ou d'exclure des adresses IPv4 dans ce préfixe. Par exemple, une passerelle dual-stack (IPv4/IPv6) qui utilise une adresse IPv4 partagée peut être considérée comme un sous-réseau IPv4 qui ne comprend qu'un seul équipement (elle-même) et pour lequel l'équipement nœud d'interface avec ce sous-réseau est inclus dans la passerelle. Dans ce cas, le préfixe aura l'extension maximale et comprendra l'adresse IPv4 de la passerelle domestique et la plage de port réservée à la passerelle.
Mais l'opérateur devra aussi veiller à ce qu'il existe une route par défaut vers toutes les adresses IPv4 qui ne sont pas gérées par le système d'acheminement selon l'invention. Pour cela, il veillera à créer une route IPv6 par défaut vers le préfixe "IP6/IPv4 EN prefix" formé avec toutes ces adresses IPv4 (par exemple il pourra utiliser la taille minimale qui n'inclut pas l'adresse IPv4 si il s'est assuré que ce format de conversion ne sera jamais utilisé avec les adresses gérées par le système d'acheminement ou si il s'est assuré que les adresses formées en appliquant ce format de conversion à des adresses gérées par le système d'acheminement seront dirigées, via une route plus courte, vers un autre équipement qui les convertira vers les autres formats de conversion décrits ci-dessous). Cette route par défaut conduira à un équipement nœud interface avec le réseau public IPv4.
Le format de conversion commun sans numéro de port (common_portless_format) : II permet d'associer une adresse IPv6 à une adresse IPv4 pour les protocoles qui n'utilisent pas de numéro de port.
Cet algorithme est très proche du common_format mais la différence principale est qu'il n'utilise que l'adresse IPv4 et un autre préfixe.
Ce format est utilisé pour former les adresses IPv6 destination des paquets envoyés vers un nœud interface avec le réseau IPv4 public lorsque le protocole IP n'utilise pas de numéro de port. Il sera également utilisé pour former les adresses IPv6 source des paquets envoyés sur le réseau IPv6 par un nœud interface avec le réseau
IPv4 public si le protocole IP n'utilise pas de numéro de port.
Ce format de conversion sera aussi utilisé pour former les adresses IPv6 destination des paquets obtenus par conversion d'un paquet IPv4 et qui doivent être envoyés à un moyen de mémorisation des contextes.
On notera qu'il existe un algorithme qui permet d'extraire l'adresse_IPv4 à partir de l'adresse IPv6.
Cet algorithme peut être très voisin de celui utilisé pour le common_format et fournir des préfixes identiques ou différents suivant les options choisies.
Certaines variantes peuvent n'utiliser que ce format, c'est-à-dire ne pas tenir compte du numéro de port pour calculer l'adresse IPv6.
Le champ port est remplacé par une valeur réservée, en général des zéros.
Il est recommandé que le préfixe formé par la concaténation des champs "Common id" , "IPv6/IPv4 EN" et du champ réservé qui précède l'adresse IPv4 ne diffère de celui du commonjormat que par le bit de poids faible.
Dans le cas d'un préfix commun partagé entre plusieurs opérateurs, il serait donc souhaitable que les 2 préfixes ne différent donc que par le bit 64 (si on numérote par 0 le bit de poids le plus faible et 127 celui de poids le plus fort). La partie de cette adresse qui correspond à la partie marquée "IP6/IPv4 EN prefix" sur la figure 6 représente un préfixe IPv6 qui sera routé vers un équipement de mémorisation des contextes.
On notera que l'adresse IPv4 est séparée en deux parties. Les bits de poids fort qui constituent le préfixe IPv4 d'un pool d'adresse IPv4 qui résulte de la répartition, par l'opérateur, en plusieurs pools, du pool d'adresses partagées attribué à cet opérateur. Les bits de poids faible permettent de différencier les différentes adresses IPv4 au sein de ce pool. La partie qui correspond à la partie marquée "IP6/IPv4 EN prefix" sur la figure 6 inclut ces bits de poids fort de l'adresse IPv4. On notera que l'opérateur peut donc diviser le pool d'adresses IPv4 partagées en plusieurs pools attribués à des équipements de mémorisation différents. Cette division du pool d'adresses IPv4 partagées est transparente pour les noeuds d'interface avec les sous-réseaux qui utilisent toujours le même format de conversion d'adresse. Ce sont les mécanismes normaux de routage IPv6 qui gèrent cette répartition. De plus l'opérateur veillera à ce qu'il existe au moins une route par défaut vers un ou des nœuds interfaces avec le réseau public IPv4 pour les préfixes "IPv6/IPv4 EN prefix" formés en appliquant ce format commun sans numéro de port pour les adresses IPv4 n'appartenant pas à ces pools d'adresses IPv4 partagées.
Pour les paquets IPv6 envoyés par un nœud interface avec le réseau IPv4 public, ou envoyés par un équipements de mémorisation des contextes, vers un équipement de mémorisation des contextes, c'est bien l'adresse IPv4 destination qui est utilisée pour former l'adresse IPv6 de destination avec ce format.
Il en est de même pour les paquets sans numéro de port envoyés vers un nœud interface avec le réseau public IPv4. Cependant pour les échanges internes au système d'acheminement qui ont pour origine un nœud interface avec un sous réseau qui n'est pas le réseau public IPv4 et pour destination un équipement de mémorisation des contextes, l'adresse IPv4 qui est utilisée pour former l'adresse destination du paquet IPv6 est l'adresse source du paquet IPv4. Dans ce dernier cas, et seulement dans la variante de conversion des paquets
IPv4 en paquets IPv6 qui n'utilise pas une encapsulation, on peut avoir besoin des 32 bits de poids faibles, qui ne sont pas encore affectés, pour stocker l'adresse IPv4 destination. En effet, dans cette variante, l'adresse IPv4 destination d'origine serait perdue sans cela. Ce cas est représenté en relation avec la Figure 7.
- le format de conversion interne : afin de router les paquets IPv6 vers l'équipement nœud interface vers le bon sous-réseau IPv4 l'opérateur doit utiliser un format de conversion spécifique décrit en relation avec la Figure 8. Ce format de conversion sera utilisé pour former les adresses IPv6 destination des paquets envoyés vers un nœud interface avec un sous réseau qui n'est ni un sous réseau réduit à une seule passerelle dual-stack, ni le réseau public IPv4.
Ce format de conversion sera aussi utilisé pour former les adresses IPv6 source des paquets IPv6 formés par conversion d'un paquet IPv4 par ces mêmes nœuds.
Par rapport au format de conversion de la figure 6 il utilise un identifiant propre à l'opérateur pour différencier ces adresses des autres adresses utilisées sur le réseau IPv6 et un identifiant "IPv6/IPv4 interne" qui est réservé aux paquets IPv6 transportant un paquet IPv4 selon ce procédé. Ensuite la partie d'un numéro de port représentant la plage de port associée à ce sous réseau est insérée dans le préfixe avant l'adresse IPv4. Cette partie est donc juste un identifiant de sous-réseau et c'est ce même identifiant qui est stocké et récupéré par les moyens de mémorisation.
On notera que l'adresse IPv4 est séparée en deux parties. Les bits de poids fort qui constituent le préfixe IPv4 du pool d'adresse IPv4 attribué à cet opérateur et qu'il a décidé de partager entre plusieurs équipements. Les bits de poids faible qui permettent de différencier les différentes adresses IPv4 au sein de ce pool.
La partie de cette adresse marquée "IP6/IPv4 interne prefix" sur la Figure 8 représente un préfixe IPv6 qui sera routé vers un équipement nœud qui fait l'interface avec le sous-réseau IPv4 auquel est attribuée cette plage de port pour ce pool d'adresse. 6. Fonction de mémorisation d'un contexte de communication
Selon un mode de réalisation de l'invention, le système d'acheminement selon l'invention comprend des moyens de mémorisation d'un contexte de communication associé à une adresse IPv4 partagée. En relation avec la Figure 2, de tels moyens sont avantageusement mis en œuvre par au moins un équipement de mémorisation EM du système d'acheminement d'un paquet de données selon l'invention, qui est dédié à la mémorisation d'un tel contexte.
Le recours à un tel équipement de mémorisation de contexte est particulièrement avantageux dans le cas d'un contexte de type avec données. En effet, dans ce cas, les données du paquet IPv4 ne portent pas l'identifiant de sous-réseau de rattachement de l'équipement client associé à l'adresse IPv4 partagée. Par conséquent, il est nécessaire de lui associer une donnée de contexte identifiant ce sous-réseau.
Cette mémorisation consiste à enregistrer une association entre l'adresse IPv4 partagée, l'identifiant de contexte et la donnée de contexte identifiant de sous-réseau de rattachement de l'équipement client possédant l'adresse partagée. Selon l'invention, on accède à cette association à partir du couple (adresse IPv4 partagée, identifiant de contexte).
On comprend que, lorsque l'identifiant de contexte est un numéro de port appartenant à la plage de numéros de port réservée à l'équipement client possédant l'adresse partagée, il constitue un identifiant de ce sous-réseau et la mémorisation d'une telle association n'est donc pas nécessaire.
En relation avec la Figure 9, l'équipement de mémorisation de contexte EM selon l'invention comporte les éléments matériels que l'on retrouve classiquement dans un ordinateur conventionnel, à savoir un processeur 210, une mémoire vive de type
RAM 220, une mémoire morte de type ROM 230 et des moyens 240 de communication avec le réseau IPv6.
Conformément à l'invention, l'équipement de mémorisation de contexte EM 200 comporte une mémoire 250 comprenant une base de données dans laquelle sont stockées les associations entre l'adresse IPv4 partagée, l'identifiant de contexte et la donnée de contexte identifiant le sous-réseau de rattachement de l'équipement client utilisant l'adresse partagée.
On notera que cette mémoire peut aussi bien être externe à l'équipement EM pourvu qu'il puisse y accéder. La mémoire morte 230 constitue un support d'enregistrement conforme à l'invention. Ce support mémorise le programme d'ordinateur conforme à l'invention. Ce programme comporte des instructions pour l'exécution des étapes du procédé de mémorisation d'un contexte de communication d'un paquet de données conforme à l'invention qui va maintenant être décrit en référence aux Figures 10 et 11. Pour des questions de clarté, chacune de ces figures décrit l'une des deux branches principales du procédé. L'étape M1 et la première décision qui permet de choisir la branche ont été reproduites sur les deux figures.
Sur réception M1 d'un paquet de données IPv6 comprenant une adresse source IPv4 partagée et un identifiant de contexte, la branche de traitement est déterminée en comparant l'adresse IPv4 partagée qui a été utilisée pour former l'adresse IPv6 destination au "format de conversion commun sans numéro de port" avec l'adresse source du paquet IPv4. Il existe plusieurs variantes pour cela, on peut soit chercher l'adresse IPv4 qui a servi à former l'adresse IPv6 source, soit si on a choisi la variante avec encapsulation, regarder directement dans le paquet encapsulé, soit si on a choisi une variante sans encapsulation, regarder dans les 32 bits de poids faibles de l'adresse IPv6 destination car une valeur différente de la valeur réservée indique alors la présence d'une adresse destination et confirme que l'adresse IPv4 utilisée pour appliquer le format est bien l'adresse source.
Si l'adresse IPv4 partagée qui a été utilisée pour former l'adresse IPv6 au "format de conversion commun sans numéro de port" est bien l'adresse source du paquet IPv4, il faut suivre la branche décrite en relation avec la Figure 10. Sinon, il faut suivre la branche décrite en relation avec la Figure 11.
Dans la branche décrite en relation avec la Figure 10, une étape M2 d'extraction de l'adresse source IPv4 partagée et de l'identifiant de contexte est mise en œuvre. En M3, un type de contexte associé est déterminé parmi les différents contextes avec données qui peuvent être mis en œuvre par le système. Avantageusement, cette détection s'appuie sur le numéro de protocole. Par exemple, un contexte spécifique utilisant l'identifiant de datagramme comme identifiant de contexte peut être mis en œuvre pour le protocole ICMP, alors que pour les autres protocoles sans numéro de port on utilisera plutôt l'adresse IPv4 destination comme identifiant du contexte attaché à l'adresse IPv4 source.
Une recherche dans la base de données d'une association entre ladite adresse IPv4 source, ledit identifiant de contexte et un identifiant du sous-réseau avec lequel ledit équipement nœud est interface, est effectuée en M4.
- si aucune association n'a été trouvée, un enregistrement d'une association entre ladite adresse source IPv4 partagée, l'identifiant de contexte et l'identifiant de sous- réseau est effectué en M5 et on passe ensuite à l'étape M6 décrite ci-dessous -si une association a été trouvée comprenant l'identifiant de sous-réseau, l'adresse destination du paquet de données IPv6 est remplacée en M6 par une adresse IPv6 construite en appliquant le "format de conversion commun sans numéro de port" à l'adresse IPv4 de destination (cette adresse se trouve dans le paquet IPv4 encapsulé si on a choisi la variante avec encapsulation ou dans les 32 bits de poids faibles de l'adresse IPv6 destination reçue si on a choisi la variante avec conversion directe). - si une association a été trouvée comprenant un autre identifiant de sous-réseau, l'adresse IPv4 source partagée est remplacée en M7 par une autre adresse IPv4 prise dans un pool attribué spécifiquement à l'équipement de mémorisation des contextes pour cet usage, l'adresse source paquet IPv4 est modifié si on a choisi la variante avec encapsulation et une association entre ladite autre adresse IPv4, l'identifiant de contexte, l'identifiant de sous-réseau et l'adresse IPv4 partagée est enregistrée en M8 dans la base de données.
Une nouvelle adresse IPv6 source est construite en appliquant le "format de conversion commun sans numéro de port" à la nouvelle adresse IPv4 source en M9 et on passe à l'étape M6 déjà décrite. Après l'étape M6 il ne reste plus qu'a envoyer le paquet sur le réseau IPv6 à l'étape M10.
Dans la branche décrite en relation avec la Figure 11 , après la sélection de branche qui a suivi l'étape M1 , une étape D1 d'extraction de l'adresse destination IPv4 partagée et de l'identifiant de contexte est mise en œuvre. En D2, un type de contexte associé est déterminé parmi les différents contextes avec données qui peuvent être mis en œuvre par le système.
Si le type de contexte est un contexte sans données (ce qui peut se produire pour des paquets d'erreurs ICMP envoyés en réponse à un message avec numéro de port et qui contiennent ce numéro de port dans le paquet) on passe directement à l'étape D5.
Sinon une recherche dans la base de donnée d'une association entre ladite adresse destination IPv4 partagée, l'identifiant de contexte est mise en œuvre et un identifiant du sous-réseau est mise en œuvre en D3.
Si aucune association n'est trouvée, le paquet ne peut pas être acheminé et il faut retourner une erreur ICMP en D4.
Si une association est trouvée, elle permet en D5 d'en extraire l'identifiant de sous-réseau et elle peut aussi contenir l'adresse IPv4 d'origine. Dans ce dernier cas et si on a choisi la variante avec encapsulation du paquet IPv4 il faut aussi à cette étape D5 modifier l'adresse IPv4 du paquet encapsulé. Une nouvelle adresse IPv6 destination est construite en D6 en appliquant le
"format de conversion interne" avec comme paramètre l'adresse IPv4 partagée originale extraite en D5 du contexte mémorisée si il y en avait une ou sinon ladite adresse IPv4 destination partagée qui a servi pour la recherche de l'association et comme autre paramètre l'identifiant du sous-réseau qui est une plage de port représentée sur la Figure 8 comme les bits de poids fort d'un numéro de port.
En D7 le paquet IPv6 est envoyé sur le réseau IPv6.
On notera qu'à l'étape 10 de la Figure 10, il est possible que l'équipement de mémorisation des contextes s'envoie lui même un paquet IPv6. Dans ce cas bien entendu les étapes M6, M10 la nouvelle étape M1 la décision et l'étape M2 peuvent être omise puisque la décision conduit forcément dans ce cas à conclure l'adresse IPv4 partagée qui a été utilisée pour former l'adresse IPv6 au "format de conversion commun sans numéro de port" n'est pas l'adresse source du paquet IPv4, mais son adresse destination. La seule exception à cette règle serait le cas où l'adresse IPv4 partagée source est égale à l'adresse IPv4 destination. Mais dans ce cas le paquet ne sert qu'à ouvrir la communication et peut être détruit.
On comprend que le traitement des contextes de communication qui utilisent des données de contexte est plus compliqué que celui des contextes sans données de contexte. En effet l'existence de données à mémoriser entraine:
- des risques d'attaques en déni de service de l'équipement de mémorisation en augmentant artificiellement le volume de données à stocker jusqu'à ce que celui-ci dépasse la capacité de stockage, une complexité accrue pour la sécurisation de cet équipement car il faut alors mettre en place des mécanismes de réplication des données de contexte mémorisées entre l'équipement principal et l'équipement de secours, - une complexité accrue lors de la gestion du passage à l'échelle, car lorsque le volume de traitement nécessite d'éclater le traitement sur plusieurs équipements il faut alors gérer la répartition des données sur plusieurs équipements,
- des temps de traitement plus importants car il faut réaliser des accès aux données de contexte mémorisées, ce qui limite les possibilités de faire directement les traitements à partir d'éléments matériels (hardware, en anglais).
L'avantage de la solution de l'invention est qu'elle permet d'isoler la fonction de mémorisation dans un seul type d'équipement spécifique, les autres équipements constitutifs du système de routage étant sans état (stateless, en anglais).
7. Cas de datagrammes fragmentés
Un paquet de données est destiné à transporter une séquence de données ou datagrammes. Dans un réseau IPv4, les datagrammes qui sont trop long peuvent être décomposés en plusieurs fragments qui sont transportés par des paquets différents. Mais, dans ce cas, l'en-tête de la couche transport qui porte les identifiants de port du paquet de données ne figurent que dans le paquet de données IPv4 contenant le premier fragment (ou fragment d'offset 0).
Selon l'invention, le système d'acheminement d'un paquet de données comprend un équipement de mémorisation de fragmentation aptes à mémoriser le numéro de port figurant dans le paquet contenant le premier fragment et à l'associer aux paquets portant les autres fragments. Un tel équipement de mémorisation de fragmentation FM est représenté, en relation avec la Figure 2.
Un avantage est qu'ainsi tous les paquets du fragment disposent d'un identifiant de contexte unique pour la communication.
Toutefois, comme les paquets portant les fragments peuvent prendre des chemins différents dans le réseau et arriver dans un ordre différent de l'ordre initial, un mécanisme doit être mis en place pour permettre de :
- regrouper les différents fragments d'un même datagramme vers le même équipement de mémorisation de fragmentation,
-mémoriser les numéros de port, tant que tous les fragments issus du même datagramme ne sont pas traités,
-mémoriser tous les paquets portant un fragment tant que l'on n'a pas reçu le paquet portant le fragment d'offset 0. Par construction de tels moyens sont donc vulnérables à des attaques en déni de service (envoi d'un ensemble incomplet de fragments). Même si des mesures existent pour limiter ces attaques (durée de conservation limitée dans le temps) il est donc préférable de séparer cette fonction des autres.
De façon avantageuse, le système d'acheminement selon l'invention comprend un équipement de mémorisation de fragmentation apte à communiquer en IPv6 avec les équipements nœuds et comprenant lesdits moyens de mémorisation de fragmentation.
Selon l'invention, on associe un mécanisme de routage IPv6 permettant de regrouper vers cet équipement les paquets contenant des datagrammes fragmentés utilisant la même adresse IPv4 partagée shared_@IPv4. 8. Un exemple de gestion d'un conflit entre deux communications parallèles par l'équipement de mémorisation de contexte
En relation avec la Figure 2, on présente un paquet de données P4 émis par un équipement client EC4 possédant une adresse IPv4 partagée shared_@IPv4 au cours d'une communication avec un équipement client destinataire EC1 possédant une adresse IPv4 publique non partagée. On considère que l'adresse IPv4 de l'équipement client émetteur EC4, ou adresse source, est partagée avec une pluralité d'équipements clients et que la communication IP utilise un protocole sans numéro de port. Le contexte qui est associé à cette communication est donc de type avec données. Comme décrit précédemment, le paquet de données P4 est reçu par un équipement nœud EN4 du système d'acheminement selon l'invention. Cet équipement nœud EN4 connaît le sous-réseau de rattachement SR4 de l'équipement émetteur, car il s'agit du sous-réseau avec lequel il est interface et il a reçu le paquet via une liaison point à point avec l'équipement client EC4 de ce sous-réseau.
Selon l'invention, il est apte à déterminer le type de contexte de communication qui sera utilisé dans un paquet de données de réponse à ce paquet de données. Pour ce faire, il met en application des règles prédéfinies par l'opérateur du réseau de télécommunications. Pour rappel, le type de contexte est un identifiant avec données. II doit donc faire l'objet d'une mémorisation. L'équipement nœud EN4 est apte à convertir le paquet de données IPv4 en un paquet de données P4_IPv6 dont l'adresse de destination IPv6 est construite à partir d'un préfixe spécifique à l'équipement de mémorisation de contexte EM en charge de mémoriser les contextes, et dont l'adresse source IPv6 est construite à partir d'un préfixe spécifique aux équipements nœuds qui résulte de l'application du "format de conversion interne" à l'adresse adresse IPv4 source et à la plage de port qui constitue l'identifiant du sous-réseau SR4 de rattachement de l'équipement client EC4 émetteur du paquet de données P4.
Selon l'invention, le paquet de données IPv6 obtenu est acheminé, jusqu'à un équipement de mémorisation de contexte EM. Cet équipement est apte à extraire du paquet P4_IPv6 l'adresse source IPv6, l'adresse de destination IPv6, l'adresse IPv4 source, l'identifiant de sous-réseau de l'adresse IPv4 source et l'adresse IPv4 destination.
1. il recherche dans sa base de données s'il existe une entrée correspondant au couple (adresse source shared@IPv4, identifiant de contexte), l'identifiant de contexte étant par exemple égal à l'adresse de destination IPv4.
1.2. Si cette entrée existe et fait correspondre au couple ci-dessus le même identifiant de sous-réseau ID-SR4, alors l'équipement de mémorisation de contexte a déjà mémorisé le contexte associé à cette communication entre l'équipement client EC4 et l'équipement client destinataire EC1. Il n'a donc pas de donnée de contexte supplémentaire à mémoriser pour l'adresse IPv4 source.
1.3 On considère maintenant le cas où l'entrée correspondant au couple
(adresse source shared@IPv4, adresse de destination IPv4) existe, mais associe un autre identifiant de sous-réseau que l'identifiant du sous-réseau SR4, par exemple l'identifiant du sous-réseau SR3. On comprend qu'il existe déjà une première communication en cours entre les deux adresses IPv4 partagées, par exemple celle de l'équipement client EC3 et celle de l'équipement client EC4. Il y a donc un risque de conflit.
Selon un mode de réalisation de l'invention, l'équipement de mémorisation de contexte EM est apte à remplacer l'adresse IPv4 source partagée par une nouvelle adresse IPv4 New@IPv4 appartenant à un ensemble ou pool d'adresses IPv4 qui lui est réservé.
Il enregistre donc une nouvelle entrée dans sa base de données associant au couple (New@IPv4, adresse IPv4 de destination) l'identifiant de sous-réseau de rattachement ID-SR4 et l'adresse IPv4 source partagée d'origine shared@IPv4.
Il modifie en outre l'adresse source du paquet de données IPv6 en remplaçant l'adresse source shared@IPv4 par la nouvelle adresse New@IPv4.
Il reprend ensuite le traitement du paquet de données IPv6, en particulier la construction de l'adresse IPv6 de destination comme décrit sur la Figure 10. On comprend que lorsqu'un paquet de données de réponse sera reçu par l'équipement de mémorisation de contexte EM, son adresse de destination IPv6 comprendra l'adresse IPv4 New@IPv4. L'équipement EM interrogera la base de données à partir du couple (New@IPv4, EC2@IPv4) et il obtiendra l'identifiant de sous-réseau ID-SR4 et l'adresse IPv4 shared@IPv4 de l'équipement client destinataire
EC4. Il pourra ainsi modifier l'adresse de destination IPv6 du paquet en utilisant le format de conversion interne désignant les équipements nœuds, l'adresse de destination shared@IPv4 et l'identifiant de sous-réseau. Le paquet de données IPv6 obtenu pourra être acheminé jusqu'à l'équipement nœud EN4, converti en IPv4 par ce dernier et routé de façon standard jusqu'à l'équipement destinataire EC4.
On comprend que la situation de conflit qui vient d'être décrite a d'autant plus de chances de survenir que l'équipement client impliqué dans les deux communications est populaire et que lorsqu'elle survient elle consomme une nouvelle adresse IPv4 (pour l'équipement situé sur le sous-réseau SR4 dans notre exemple) ce qui va à rencontre de notre objectif d'économiser les adresses IPv4.
9. Cas des interfaces compatibles
Selon l'invention, certains équipements clients possèdent une adresse IPv4 publique et une interface avec le réseau public IPv6 dotée d'une adresse IPv6 spécifique pour recevoir des paquets IPv4 qui ont été convertis en IPv6.
Si, de plus, ces équipements répondent à ces paquets IPv6 par d'autres paquets IPv6 qui sont la conversion en IPv6 des paquets de réponse IPv4, mais avec une adresse destination IPv6 qui est l'adresse IPv6 source des paquets reçus et si de plus ils possèdent un mécanisme qui leur permet de communiquer cette adresse IPV6 et de faire savoir qu'elle est associée à une interface destinée à recevoir des paquets IPv4 destiné à cette adresse IPv4 et convertis en paquets IPv6, on parlera de fulLcompatible_interface.
Une telle interface est particulièrement avantageuse pour les équipements clients populaires qui reçoivent beaucoup de communication sans numéro de port. Un équipement client possédant une interface compatible est donc un équipement dit "dual stack IPv4/IPv6", ce qui signifie qu'il est à la fois apte à communiquer selon les protocoles IPv4 et IPv6. Un tel équipement client possède donc : - une adresse IPv4 publique non partagée que l'on dira associée à la fuILcompatibleJnterface; une interface IPv6 qui est la fuILcompatibleJnterface; une adresse IPv6 qui est l'adresse de la fuILcompatibleJnterface. - un mécanisme qui lui permet de faire connaître à ses correspondants l'adresse IPv6 de la fuILcompatibleJnterface associée à son adresse IPv4.
Il est également préférable d'affecter l'adresse IPv6 obtenue en appliquant à l'adresse IPv4 publique associée à la fuILcompatibleJnterface le "format de conversion commun sans numéro de port". Il est préférable que cette adresse soit différente de l'adresse IPv6 de la fuILcompatibleJnterface. En effet l'adresse destination des paquets IPv6 envoyés en réponse à des paquets dont l'adresse IPv6 a été obtenue en appliquant le "format de conversion commun sans numéro de port" doit être l'adresse IPv6 obtenue en appliquant le "format de conversion commun sans numéro de port" à l'adresse IPv4 destination.
On notera cependant que c'est bien cette adresse IPv6 obtenue en appliquant le "format de conversion commun sans numéro de port" à l'adresse IPv4 associée à la fuILcompatibleJnterface qui sera utilisée comme adresse source des paquets IPv6 envoyés par la fuILcompatibleJnterface.
Il existe de nombreux mécanismes permettant de faire connaître l'adresse IPv6 de la fuILcompatibleJnterface associé à une adresse IPv4 tels que la publication de cette association sur un serveur. Cependant un mécanisme qui consisterait à renvoyer au correspondant un paquet IPv4 avec une caractéristique spécifique permettant de le reconnaître et contenant l'adresse IPv6 de la fuILcompatibleJnterface et converti en un paquet IPv6 dont l'adresse IPv6 destination serait l'adresse IPv6 obtenue en appliquant le "format de conversion commun sans numéro de port" appliquée à l'adresse IPv4 du correspondant serait préférable (on notera au passage que ce n'est pas la méthode normale de réponse aux paquets envoyés à la fuILcompatiblejnterface mais c'est la méthode de réponse aux paquets envoyés à l'adresse IPv6 obtenue en appliquant le "format de conversion commun sans numéro de port" à l'adresse IPv4 associée à la full_compatile_interface).
En relation avec la Figure 12, on considère un équipement client EC1 du réseau IPv4 public. Cet équipement possède une fuILcompatiblejnterface. On suppose qu'un équipement client EC3 possédant l'adresse shared@IPv4 partagée établit une communication avec l'équipement client EC1. Au cours de cette communication, l'équipement client EC3 envoie un paquet de données P3 à l'équipement client EC1. On suppose que ce paquet de données ne possède pas de numéro de port.
Selon l'invention, le paquet de données est converti en un paquet IPv6 par un équipement nœud EN3 et envoyé à un équipement de mémorisation de contexte EM. On suppose qu'au moins une communication est déjà en cours entre l'équipement EC1 possédant la fuILcompatiblejnterface et un équipement client EC4 partageant la même adresse IPv4 shared@IPv4 que l'équipement client EC3.
Selon l'invention, l'équipement de mémorisation de contexte EM a appris lors de rétablissement de la communication entre les équipements clients EC3 et EC1 que l'équipement client EC1 dispose d'une fuILcompatiblejnterface dont il a appris et mémorisé l'adresse IPv6.
Cela n'a rien changé pour la communication entre EC3 et EC1. En revanche lorsqu'il reçoit un paquet en provenance d'EC4 à destination d'EC1 , et qu'il constate qu'il existe déjà une association entre l'adresse IPv4 partagée, l'adresse IPv4 d'EC1 et l'identifiant de sous réseau SR3. Au lieu d'attribuer une nouvelle adresse IPv4 source et de mémoriser un contexte il se contente d'utiliser l'adresse IPv6 de la fuILcompatiblejnterface comme adresse de destination IPv6.
On notera que l'adresse source du paquet IPv6 qui n'a pas été modifiée est toujours l'adresse IPv6 qui a été construite par l'équipement EN4. C'est donc une adresse IPv6 construite en utilisant le format de conversion interne et elle est routée sur le réseau IPv6 vers EN4. La réponse de la full_compatible_interface sera donc routée en IPv6 vers EN4 sans jamais emprunter le réseau IPv4 public et sans avoir besoin de passer par l'équipement de mémorisation des contextes. L'objectif d'économie des adresses IPv4 est bien préservé dans ce cas.
10. L'annonce des préfixes IPv6 sur le réseau
Chaque adresse IPv6 ayant un préfixe on peut, par abus de langage, considérer qu'il existe des préfixes IPV6 associés à chaque format (ou des formats de préfixe). Ces préfixes peuvent permettre de diffuser les capacités et les modes de traitements qui doivent être appliqués aux adresses IPV4 partagées. Les informations concernant l'existence de ces préfixes et leur étendue peuvent être, tout simplement, distribuées sur le réseau IPV6 par le biais des informations de routage IPV6.
Chaque format peut exister sous deux formes: posséder des préfixes inclus dans un préfixe IPv6 propre à l'opérateur. Cette information de format est alors destinée à être partagée au sein du réseau IPv6 de cet opérateur, mais n'a pas vocation à être interprétée au-delà; avec un préfixe inclus dans un préfixe commun, à plusieurs opérateurs qui devront alors partager une politique commune de gestion de ce préfixe. Ce mode est d'autant plus intéressant que la communauté des opérateurs est étendue. L'idéal serait même que cette communauté soit celle de l'internet et que ce préfixe soit assigné par l'IANA.
Il suffit alors de vérifier que l'adresse IPV6 générée en appliquant un format à un couple (shared_@IPv4, port) ou (shared_@IPv4, identifiant de sous-réseau) ou à une shared_@IPv4 seule (suivant le format) est bien dans l'étendue d'un préfixe annoncé pour en déduire que l'adresse shared_@IPv4 possède les caractéristiques et les capacités qui caractérisent ce format. De plus si l'algorithme est bien conçu et pour les formats qui sont destinés à être échangés avec d'autres opérateurs, il n'est pas nécessaire de connaître la valeur de l'identifiant de sous-réseau pour déterminer cette information de format. Pour éviter que les tables de routages IPv6 ne deviennent trop grandes, ces préfixes IPv6 peuvent être agrégés et englober lors de cette opération des adresses IPv6, construites en appliquant le commonjormat à des adresses IPv4, pour lesquelles l'opérateur, qui fait l'agrégation, n'a reçu aucun préfixe sur le réseau IPv6. Dans ce cas cette agrégation est autorisée à condition que l'opérateur qui la réalise mette en place une route pour ces adresses IPv6 vers un nœud interface avec le réseau public IPv4.
Les informations qui peuvent être déduites de l'annonce d'un préfixe commonjormat sont les suivantes : L'inclusion d'une adresse IPv4 dans un préfixe de ce type annoncé sur le réseau IPV6 signifie que l'opérateur qui annonce ce préfixe est prêt à recevoir, via le réseau IPv6, des communications vers ces interfaces pour des protocoles utilisant un numéro de port. Il met à disposition les équipements nœuds nécessaires pour permettre d'acheminer les communications du réseau IPV6 conformes à ce format d'encapsulation vers cette adresse IPV4. On peut noter que :
L'annonce de ce préfixe ne fournit aucune indication sur la nature de l'adresse IPV4 qui peut aussi bien être une adresse IPv4 normale qu'une adresse partagée Shared_@IPv4.
L'annonce d'un format commun de type common_portless_format et l'inclusion d'une adresse IPv4 dans un préfixe de ce type annoncé sur le réseau IPV6 signifie que l'opérateur qui annonce ce préfixe est prêt à recevoir, via le réseau IPv6, des communications vers cette interfaces pour des protocoles n'utilisant pas de numéro de port. Il met à disposition les équipements nœuds nécessaires pour permettre d'acheminer les communications du réseau IPV6 et n'utilisant pas de numéro de port, conformes à ce format d'encapsulation vers cette adresse IPV4. Les autres règles, en particulier la règle d'agrégation sont identiques à celle du commonjormat.
11. Extension à des équipements clients "dual-stack "
Une variante possible du système d'acheminement selon l'invention qui vient d'être décrit, concerne le raccordement d'équipements clients possédant une interface IPv4 partagée et une interface IPv6. On considère, en particulier, le cas de passerelles domestiques "dual stack" aptes à communiquer avec des équipements clients IPv6 et avec des équipements terminaux de leur réseau domestique qui peuvent être IPv4 et/ou IPv6. Dans cette variante, une telle passerelle domestique joue normalement son rôle de passerelle IPv4 privé vers IPv4 public partagé pour les équipements clients IPv4 de son réseau domestique qui souhaitent communiquer avec des équipements clients destinataires IPv4 d'un autre sous-réseau. Mais la passerelle domestique joue aussi le rôle d'équipement nœud interface avec le sous réseau constitué de cette seule adresse IPv4 partagée. On comprend que, dans cette variante, le client constitue à lui seul un sous-réseau IPv4 au sens de l'invention.
A titre d'exemple, on suppose que le mode de partage des adresses IPv4 se fait selon un mode de partage des numéros de ports spécifique, de façon à ce que des plages de ports spécifiques soient réservées à ce type d'équipement client.
Toutes les adresses IPv6 construites en appliquant la technique de conversion IPv4/ IPv6 common_format précédemment évoquée, à partir : d'une adresse IPv4 partagée selon le mode de partage spécifique ; et d'un numéro de port contenu dans la plage correspondant à un sous-réseau donné; seront attribuées comme adresse IPv6 natives à l'interface IPv6 de la passerelle domestique du sous-réseau virtuel à laquelle cette adresse IPv4 partagée a été attribuée.
Dans ce cas les fonctions de conversion IPv4/IPv6 et conversion inverse IPv6/IPv4 d'un paquet de données sont intégrés dans la passerelle domestique.
Une telle variante constitue une évolution du système d'acheminement de paquets de données selon l'invention, qui permet de s'adapter au remplacement progressif de passerelles domestiques clientes IPv4 en passerelles domestiques IPv6 et plus généralement, à la migration progressive vers le tout IPv6.

Claims

REVENDICATIONS
1. Système d'acheminement d'un paquet de données IPv4 émis par un équipement client source à destination d'un équipement client destinataire au cours d'une communication établie dans un réseau de télécommunications IPv4 d'un opérateur, ledit équipement client destinataire possédant une adresse publique IP partagée avec d'autres équipements clients connectés audit réseau IPv4, caractérisé en ce que :
- ledit réseau IPv4 est décomposé en une pluralité de sous-réseaux;
- la pluralité d'équipements clients partageant ladite adresse IPv4 est rattaché à ladite pluralité de sous-réseaux, de façon à connecter au plus un desdits équipements clients par sous-réseau; et
- ledit système comprend :
- des moyens d'envoi du paquet de données IPv4 par une liaison point à point établie entre l'équipement client émetteur et des moyens d'identification du sous- réseau de rattachement de l'équipement destinataire;
- des moyens d'identification du sous-réseau de rattachement de l'équipement client destinataire du paquet, à partir de l'adresse IPv4 de destination et d'un identifiant de contexte IPv4 de ladite communication contenu dans le paquet de données reçu de l'équipement client source; et des moyens d'acheminement dudit paquet IPv4 vers le sous-réseau identifié.
2. Système d'acheminement selon la revendication 1, caractérisé en ce que, lorsque le paquet de données IPv4 comprend une adresse de destination IPv4 partagée et un numéro de port appartenant à une plage de numéros de ports, ladite plage de numéros de ports étant affectée de façon unique au sous-réseau de l'équipement destinataire, ledit identifiant de contexte est ledit numéro de port.
3. Système d'acheminement selon la revendication 1, caractérisé en ce que le paquet de données comprenant une deuxième adresse IPv4, l'identifiant de contexte est ladite deuxième adresse IPv4 du paquet de données.
4. Système d'acheminement selon la revendication 1, caractérisé en ce que, le paquet de données appartenant à un datagramme et comprenant un identifiant dudit datagramme, ledit identifiant de contexte est ledit identifiant de datagramme.
5. Système d'acheminement selon la revendication 1 , caractérisé en ce qu'il comprend un équipement nœud comprenant une interface avec chacun desdits sous- réseaux.
6. Système d'acheminement selon la revendication 1 , caractérisé en ce que ledit système comprend une pluralité d'équipements nœuds aptes à communiquer entre eux par l'intermédiaire d'un réseau de télécommunications IPv6 et tel que pour chaque sous-réseau de ladite pluralité de sous-réseaux il existe au moins un équipement nœud comprenant une interface avec ce sous-réseau.
7. Système d'acheminement selon la revendication 6, caractérisé en ce que, sur réception d'un paquet de données en provenance du sous-réseau avec lequel il est interface, un premier équipement nœud est apte à mettre en œuvre :
- des moyens de détermination d'un type de contexte de l'adresse de destination IPv4 partagée; - des moyens de conversion du paquet de données IPv4 reçu de l'équipement client émetteur en un paquet de données IPv6, ledit paquet comprenant une adresse IPv6 de destination construite à partir de l'adresse IPv4 partagée source, de l'adresse IPv4 de destination et de l'identifiant de contexte et d'un préfixe opérateur, ledit préfixe étant choisi en fonction du type de contexte déterminé; et
- des moyens d'envoi du paquet de données IPv6 obtenu dans le réseau IPv6.
8. Système d'acheminement selon la revendication 6, caractérisé en ce qu'il comprend au moins un équipement de mémorisation d'une association entre ladite adresse IPv4 partagée, l'identifiant de contexte IPv4 de la communication et l'identifiant de sous-réseau de rattachement de l'équipement client possédant ladite adresse partagée, ledit équipement étant apte à fournir, sur réception d'une requête comprenant l'adresse IPv4 partagée et l'identifiant de contexte IPv4, au moins l'identifiant de sous-réseau.
9. Système d'acheminement selon les revendications 7 et 8, caractérisé en ce que: Lorsque l'adresse IPv4 source est une adresse partagée, ledit premier équipement nœud est apte à déterminer un type de contexte de l'adresse IPv4 source, et lorsque le type de contexte déterminé est un contexte avec données, le premier équipement nœud est apte à choisir le préfixe de l'adresse de destination du paquet de données IPv6 converti de façon à ce qu'il parvienne audit équipement de mémorisation de contexte pour mémorisation d'une association entre ladite adresse source IPv4 partagée, ledit identifiant de contexte et une donnée de contexte identifiant de sous- réseau de rattachement de l'équipement client source.
10. Système d'acheminement selon la revendication 8, caractérisé en ce que au moins un équipement de mémorisation de contexte est apte, sur réception d'un paquet de données IPv6 en provenance d'un desdits équipements nœuds, à mettre en œuvre :
- des moyens d'extraction de l'adresse de destination IPv4 partagée et de l'identifiant de contexte,
- des moyens de détermination d'un type de contexte associé au paquet de données IPv6 reçu parmi un contexte sans données et un contexte avec données;
- si le type de contexte déterminé est un contexte avec données, des moyens de recherche dans la base de données d'une association entre ladite adresse IPv4 de destination, ledit identifiant de contexte et un identifiant du sous-réseau de rattachement de l'équipement client destinataire; - si une association a été trouvée, des moyens de remplacement de l'adresse de destination du paquet de données IPv6 par une adresse IPv6 construite à partir de l'adresse de destination partagée, de l'identifiant de sous-réseau trouvé et d'un préfixe opérateur.
11. Système d'acheminement selon la revendication 10, caractérisé en ce que, sur réception d'un paquet de données IPv6 en provenance d'un desdits équipements nœuds et comprenant une adresse IPv4 source partagée, ledit équipement de mémorisation de contexte est apte à mettre en œuvre :
- des moyens d'extraction de l'adresse source IPv4 partagée et de l'identifiant de contexte, - des moyens de détermination d'un type de contexte associé, parmi un contexte sans données et un contexte avec données;
- si le type de contexte déterminé est un contexte avec données, des moyens de recherche dans la base de données d'une association entre ladite adresse IPv4 source, ledit identifiant de contexte et un identifiant du sous-réseau avec lequel ledit équipement nœud est interface;
- si aucune association n'a été trouvée, des moyens d'enregistrement d'une association entre ladite adresse source IPv4 partagée, l'identifiant de contexte et l'identifiant de sous-réseau;
-si une association a été trouvée comprenant l'identifiant de sous-réseau, des moyens de remplacement de l'adresse destination du paquet de données IPv6 par une adresse IPv6 construite à partir de l'adresse IPv4 de destination, et d'un préfixe opérateur adapté; et
- si une association a été trouvée comprenant un autre identifiant de sous-réseau, des moyens de remplacement de l'adresse IPv4 source partagée par une autre adresse IPv4 et des moyens d'enregistrement d'une association entre ladite autre adresse IPv4, l'identifiant de contexte, l'identifiant de sous-réseau et l'adresse IPv4 partagée.
12. Equipement nœud d'un système d'acheminement d'un paquet de données à destination d'un équipement client destinataire et un équipement client destinataire, dans un réseau de télécommunications IPv4, l'un au moins desdits équipements clients possédant une adresse publique IPv4 partagée avec d'autres équipements clients connectés audit réseau IPv4, caractérisé en ce que :
- ledit réseau IPv4 est décomposé en une pluralité de sous-réseaux;
- la pluralité d'équipements clients partageant ladite adresse IPv4 est rattaché à ladite pluralité de sous-réseaux, de façon à connecter au plus un desdits équipements clients par sous réseau,
Ledit système comprend une pluralité d'équipements nœuds aptes à communiquer entre par l'intermédiaire d'un réseau IPv6,
Ledit équipement nœud comprend : des premiers moyens de communication avec un desdits sous réseaux IPV4; des seconds moyens de communication avec d'autres équipements nœuds dudit système par l'intermédiaire d'un réseau de télécommunication IPv6;
Des moyens de détermination d'un type de contexte de l'adresse de destination IPv4 partagée, aptes à être mis en œuvre sur réception d'un paquet de données IPv4 sur lesdits premiers moyens de communication; des moyens de conversion du paquet de données IPv4 reçu sur lesdits premiers moyens en un paquet de données IPv6, ledit paquet comprenant une adresse IPv6 de destination construite à partir de l'adresse IPv4 partagée source, l'adresse IPv4 de destination et de l'identifiant de contexte et d'un préfixe opérateur, ledit préfixe étant choisi en fonction du type de contexte déterminé; et
Des moyens d'envoi du paquet de données IPv6 obtenu sur les deuxièmes moyens de communication.
13. Equipement nœud selon la revendication 12, caractérisé en ce qu'il comprend des moyens de conversion inverse d'un paquet de données IPvβ comprenant une adresse IPv4 de destination partagée et un identifiant de contexte, en un paquet de données IPv4 comprenant ladite adresse de destination et l'identifiant de contexte, lesdits moyens de conversion inverses étant aptes à être mis en œuvre sur réception du paquet de données sur les deuxièmes moyens de communication, et des moyens d'envoi du paquet de données IPv4 obtenu sur les premiers moyens de communication dans le sous réseau IPv4 interface avec ledit équipement nœud.
14. Procédé de traitement d'un paquet de données IPv4 émis par un équipement client source à destination d'un équipement client destinataire au cours d'une communication établie dans un réseau de télécommunications IPv4 d'un opérateur, ledit équipement client destinataire possédant une adresse publique IP partagée avec d'autres équipements clients connectés audit réseau IPv4, caractérisé en ce que :
- ledit réseau IPv4 est décomposé en une pluralité de sous-réseaux;
- la pluralité d'équipements clients partageant ladite adresse IPv4 est rattaché à ladite pluralité de sous-réseaux, de façon à connecter au plus un desdits équipements clients par sous-réseau; Ledit système comprend une pluralité d'équipements nœuds aptes à communiquer entre par l'intermédiaire d'un réseau IPv6, et
Ledit procédé étant apte à être mis en œuvre par un desdits équipements nœuds et comprenant les étapes suivantes :
- détermination d'un type de contexte de l'adresse de destination IPv4 partagée, destinée à être mise en œuvre sur réception d'un paquet de données IPv4 en provenance d'un sous-réseau IPv4;
- conversion du paquet de données IPv4 reçu en un paquet de données IPv6, ledit paquet comprenant une adresse IPv6 de destination construite à partir de l'adresse IPv4 partagée source, de l'adresse IPv4 de destination et d'un préfixe opérateur, ledit préfixe étant choisi en fonction du type de contexte déterminé; et
- envoi du paquet de données IPv6 obtenu dans le réseau IPv6.
15. Procédé de traitement selon la revendication 14, caractérisé en ce qu'il comprend en outre les étapes suivantes, mises en œuvre sur réception d'un paquet de données IPv6 en provenance du réseau IPv6 :
- conversion inverse du paquet de données IPv6 comprenant une adresse IPv4 de destination partagée et un identifiant de sous-réseau de rattachement de l'équipement client destinataire, en un paquet de données IPv4 comprenant ladite adresse de destination et l'identifiant de contexte, et
- envoi du paquet de données IPv4 obtenu dans le sous réseau IPv4 interface avec ledit équipement nœud.
16. Procédé de mémorisation d'un contexte de communication associé à une adresse IPv4 source d'un paquet de données émis par un équipement client à destination d'un équipement client destinataire au cours d'une communication établie dans un réseau de télécommunication IPv4, ladite adresse étant partagée avec d'autres équipements clients connectés audit réseau IPv4 et ledit paquet comprenant un identifiant de contexte de la communication, caractérisé en ce que : - ledit réseau IPv4 est décomposé en une pluralité de sous-réseaux; - la pluralité d'équipements clients partageant ladite adresse IPv4 est rattaché à ladite pluralité de sous-réseaux, de façon à connecter au plus un desdits équipements clients par sous-réseau; ledit procédé de mémorisation de contexte comprenant les étapes suivantes mises en œuvre sur réception d'un paquet de données comprenant ladite adresse IPv4 partagée:
- des moyens d'extraction de l'adresse source IPv4 partagée et de l'identifiant de contexte,
- des moyens de détermination d'un type de contexte associé, parmi un contexte sans données et un contexte avec données; - si le type de contexte déterminé est un contexte avec données, des moyens de recherche dans la base de données d'une association entre ladite adresse IPv4 source, ledit identifiant de contexte et un identifiant du sous-réseau avec lequel ledit équipement nœud est interface;
- si aucune association n'a été trouvée, des moyens d'enregistrement d'une association entre ladite adresse source IPv4 partagée, l'identifiant de contexte et l'identifiant de sous-réseau;
-si une association a été trouvée comprenant l'identifiant de sous-réseau, des moyens de remplacement de l'adresse destination du paquet de données IPv6 par une adresse IPv6 construite à partir de l'adresse IPv4 de destination, et d'un préfixe opérateur adapté; et
- si une association a été trouvée comprenant un autre identifiant de sous-réseau, des moyens de remplacement de l'adresse IPv4 source partagée par une autre adresse IPv4 et des moyens d'enregistrement d'une association entre ladite autre adresse IPv4, l'identifiant de contexte, l'identifiant de sous-réseau et l'adresse IPv4 partagée.
17. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé d'émission d'un paquet de données selon la revendication 14.
18. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de mémorisation d'un contexte d'un paquet de données selon la revendication 16.
PCT/FR2009/052609 2008-12-23 2009-12-18 SYSTEME D'ACHEMINEMENT D'UN PAQUET DE DONNEES IPv4 Ceased WO2010072953A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0859002 2008-12-23
FR0859002 2008-12-23

Publications (1)

Publication Number Publication Date
WO2010072953A1 true WO2010072953A1 (fr) 2010-07-01

Family

ID=40806158

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/052609 Ceased WO2010072953A1 (fr) 2008-12-23 2009-12-18 SYSTEME D'ACHEMINEMENT D'UN PAQUET DE DONNEES IPv4

Country Status (1)

Country Link
WO (1) WO2010072953A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101917707A (zh) * 2010-08-18 2010-12-15 中兴通讯股份有限公司 无线传感器网络的ip寻址方法及系统
CN104333613A (zh) * 2014-10-29 2015-02-04 中国联合网络通信集团有限公司 一种nat连接保持时间的设置方法及装置
WO2020193924A1 (fr) * 2019-03-28 2020-10-01 Orange Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé gestion du trafic

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001031888A1 (fr) * 1999-10-26 2001-05-03 3Com Corporation Procede et systeme pour l'utilisation d'adresses en double reseau par tunnellisation virtuelle
WO2001093540A1 (fr) * 2000-05-31 2001-12-06 Nokia Corporation Procede et appareil permettant de generer une identification de connexion

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001031888A1 (fr) * 1999-10-26 2001-05-03 3Com Corporation Procede et systeme pour l'utilisation d'adresses en double reseau par tunnellisation virtuelle
WO2001093540A1 (fr) * 2000-05-31 2001-12-06 Nokia Corporation Procede et appareil permettant de generer une identification de connexion

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CÉDRIC DE LAUNOIS ET AL: "Connection of Extruded Subnets: A Solution Based on RSIP", NETWORKING 2002: NETWORKING TECHNOLOGIES, SERVICES, AND PROTOCOLS; PERFORMANCE OF COMPUTER AND COMMUNICATION NETWORKS; MOBILE AND WIRELESS COMMUNICATIONS; [LECTURE NOTES IN COMPUTER SCIENCE], SPRINGER BERLIN HEIDELBERG, BERLIN, HEIDELBERG, vol. 2345, 19 May 2002 (2002-05-19), pages 685 - 696, XP019054116, ISBN: 978-3-540-43709-3 *
LANDFELDT B ET AL: "Providing scalable and deployable addressing in third-generation cellular-networks", IEEE WIRELESS COMMUNICATIONS, IEEE SERVICE CENTER, PISCATAWAY, NJ, US, vol. 10, no. 1, 1 February 2003 (2003-02-01), pages 36 - 42, XP011095589, ISSN: 1536-1284 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101917707A (zh) * 2010-08-18 2010-12-15 中兴通讯股份有限公司 无线传感器网络的ip寻址方法及系统
CN104333613A (zh) * 2014-10-29 2015-02-04 中国联合网络通信集团有限公司 一种nat连接保持时间的设置方法及装置
WO2020193924A1 (fr) * 2019-03-28 2020-10-01 Orange Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé gestion du trafic
FR3094590A1 (fr) * 2019-03-28 2020-10-02 Orange Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé de gestion du trafic.

Similar Documents

Publication Publication Date Title
EP2297928B1 (fr) Procede de reception d'un paquet de donnees dans un domaine ipv6, dispositif et passerelle residentielle associes
EP2297927B1 (fr) Procede de reception d'un paquet de donnees en provenance d'un domaine ipv4 dans un domaine ipv6, dispositif et equipement d'acces associes
EP2494747B1 (fr) PROCÉDÉS ET DISPOSITIFS DE ROUTAGE DE PAQUETS DE DONNÉES ENTRE RÉSEAUX IPv4 ET IPv6
EP2294798B1 (fr) Procede de routage d'un paquet de donnees dans un reseau et dispositif associe
EP3284224B1 (fr) Procédé d'émulation dune connexion à chemins multiples
EP3476095A1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
FR2855697A1 (fr) SYSTEME DE CONVERSION DE DONNEES BASEE SUR IPv4 EN DONNEES BASEES SUR IPv6 A TRANSMETTRE A TRAVERS UN RESEAU COMMUTE IP
FR2923969A1 (fr) Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
EP3476096A1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
FR2930100A1 (fr) Procede d'etablissement d'un chemin de communication dans un reseau etendu de communication, tetes de tunnel,produit programme d'ordinateur et moyen de stockage correspondants
WO2020254766A1 (fr) Procede et dispositif d'obtention d'une adresse ip
WO2010072953A1 (fr) SYSTEME D'ACHEMINEMENT D'UN PAQUET DE DONNEES IPv4
EP1641223B1 (fr) Procédé perfectionné d'attribution d'identifiants de réseau, au moyen d'identifiants d'interfaces
EP4268427B1 (fr) Procedes de communication, reflecteur de routes, hote et systeme informatique pour la mise en oeuvre de tels procedes
EP2579545B1 (fr) Méthode d'attribution d'une adresse réseau publique à un équipement disposant d'une adresse réseau privée
FR3023098A1 (fr) Procede et systeme de traitement d'une demande de resolution d'un nom d'un serveur, emise par une application cliente sur un reseau de communication.
WO2021205124A1 (fr) Procede mis en œuvre par une entite intermediaire pour gerer une communication entre deux dispositifs de communication
WO2015197978A1 (fr) Procede de protection d'un routeur contre des attaques
FR3094590A1 (fr) Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé de gestion du trafic.
EP4631215A1 (fr) Procédé de gestion d'un ensemble d'adresses ip, procédé de collaboration et dispositifs configurés pour mettre en oeuvre ces procédés
WO2009080971A1 (fr) Procede de configuration d'un terminal d'utilisateur dans un reseau de telephonie ip
WO2025003097A1 (fr) Procédés d'accès à un service, procédé de fourniture de services, procédé de contrôle, procédé de gestion, terminal, instance de service, contrôleur, nœud de bordure et programmes d'ordinateur correspondants
EP2439901A1 (fr) Procédé de traitement dans un module d'un dispositif d'accès adapté pour connecter un réseau distant à une pluralité de réseaux locaux, module et programme d'ordinateur associés
FR2947123A1 (fr) Procedes de transmission entre un emetteur et un recepteur, et un recepteur, avec transmission d'une donnee additionnelle en fonction de la longueur d'au moins deux paquets, emetteur et recepteur correspondants
FR2876850A1 (fr) Routeur, pour un reseau de communication ip, adapte a la determination de caracteristique(s) de configuration adaptatives(s) pour des routeurs voisins

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09805744

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09805744

Country of ref document: EP

Kind code of ref document: A1