WO2008050061A2

WO2008050061A2 - Communication method and system relating to the dhcp protocol

Info

Publication number: WO2008050061A2
Application number: PCT/FR2007/052233
Authority: WO
Inventors: François BOURDAIS; Nicolas Fourel
Original assignee: France Telecom
Priority date: 2006-10-25
Filing date: 2007-10-23
Publication date: 2008-05-02
Also published as: WO2008050061A3

Abstract

The invention relates to a communication device (21) for a telecommunication network comprising at least one DHCP relay (24) and a DHCP server (22). The device is able to intercept a DHCP message originating from the relay (24) and destined for the server (22) or vice versa and comprises means (28) for modifying the content of the option (82) of the message intercepted and for transmitting the modified message to the relay (24) or to the destination server.

Description

Method and system for communicating with DHCP

The present invention relates to a communication system and method relating to DHCP.

It is known in the state of the art a communication system between a plurality of equipment type DHCP (Dynamic Host Configuration Protocol) comprising at least one DHCP relay and a DHCP server. A DHCP server dynamically assigns configuration data to a device that connects to a network to which the DHCP server belongs. On an IP type network, these configuration data include an IP address of the equipment. When a device, such as a client terminal, connects to an IP network, the terminal first transmits in "broadcast" mode (simultaneous transmission of a message to several possible receivers) a request for data request from configuration. Only a DHCP server is adapted to respond to such a request by assigning the terminal configuration data (including IP address) and sending them.

Sometimes, the IP network is divided into a plurality of subnets and the operational DHCP server or servers are connected to one or more different subnets. In this case, a request broadcast in broadcast mode by a terminal of one of the subnets that does not include a DHCP server remains confined within the subnet and can not reach any server.

To solve this problem, it is known to integrate a DHCP relay in each subnet that does not include a DHCP server, the role of the relay being to transfer the requests sent in "broadcast" mode on the subnet from the relay to a relay. or multiple servers. When the relay sends the request sent by the terminal to one or more servers, the relay generally modifies the content of the message, in particular to ensure that the response of the server to this request will be correctly transmitted to the terminal via the relay .

For example, it is common for the DHCP relay to replace the content of the area of the request called "option 54", titled "server-identifier", initially containing the IP address of the server, by its own IP address. This option informs the terminal of the DHCP server address so that it can send the following requests in unicast mode, and thus communicate with it directly without having to issue requests in "broadcast" mode. Thus, when the terminal newly connected to the network must communicate with the unicast server, that is to say, directly, it sends its requests to the relay which then transmits them to the server. Option 82, "relay agent information option", is another option that DHCP devices may modify. This option is set in the document I ¹ IETF Network Working Group RFC 3046 entitled "DHCP Relay Agent Option Information" in January 2001. As stated in paragraph 5 of this document, the information contained in option 82 of the DHCP message is considered trusted since it has been added by a DHCP device that is a device configured by the network operator. This is why option 82 of DHCP messages is increasingly used to transfer information over an IP network.

However, although RFC 3046 defines option 82 and its division into sub-options, it does not impose any particular format or presentation of the information in option 82. The presentation of information is thus unique to each DHCP relay type. For example, the relays implemented in the Redback SE 800, Cisco 7200, and Juniper ERX devices are three known relays that have option 82 in different ways. Therefore, if the server wishes to use the confidence information transmitted via option 82 of the message, it must first proceed to an identification of the type of relay that inserted this information in the message before being able to interpret these informations.

Currently, however, DHCP servers are not designed to handle this heterogeneity of presentation formats and their operation is limited only to reading the raw information.

The subject of the invention is a communication device for a telecommunication network comprising at least one DHCP relay and at least one DHCP server, the device being able to intercept at least one DHCP message from a said relay and destined for a said server, and comprising means for modifying a content of an option field of an intercepted message, in particular of the option field 82, so that the presentation format of said content after modification is independent of the relay whose originates said message, and means for transmitting the modified message to the recipient server.

The fact that the presentation format is independent of the relay means that when the intercepted message is a first message from a relay of a first type, and a second message is intercepted from a second relay of a second type different from the first type, the modification made is such that the presentation formats of these contents after modification are the same.

The invention makes it possible to overcome the difficulties related to the heterogeneity of the presentation formats of the information contained in the option fields indicated by the DHCP relay, including the option field 82 of a DHCP message. The receiving server is thus able to exploit the information conveyed in this message, regardless of the relay through which the message has passed.

In the following description, the communication device according to the invention will also be called DHCP gateway.

According to one embodiment, when the intercepted message is a message said incident message, the communication device according to the invention is able to intercept a response message sent by a said server in response to the incident message and includes means for modifying a message. content of said option field of the response message so as to restore the presentation format used in the incident message before modifying the incident message.

According to the invention, it is therefore proposed to add in the prior art DHCP communication system a gateway type DHCP communication device inserted between the DHCP server and the DHCP relay whose function is to modify the Option 82 content of a message exchanged between the relay and the server, regardless of the message transfer direction. The relay receiving the modified response message can therefore treat this message as if no modification had been made by the device according to the invention. The presence of such a device in the network is transparent for the servers as for the relays communicating with each other via this device.

A communication device according to the invention may also include one or more of the following features.

The device is intended to be inserted between first and second subnetworks of the telecommunications network, the device being arranged to intercept all the messages sent from one of the subnets to a DHCP server of the other. subnet as well as any replies sent back by the DHCP server. Thus, the device acts on all the messages sent on the network to or from the server.

The device comprises means for replacing, in an intercepted message, in particular in an option 54 of the message, the IP address of the DHCP server receiving the message by the IP address of said device. Thus, when the receiving device of the message will subsequently communicate directly with the server, without the new message passing through the relay, it will send its DHCP data to the address contained in option 54, that is, ie the gateway which will be ensured to see all messages to the server. The device comprises means for replacing, in an intercepted message, in particular in a GIADDR field of the message, the IP address of the DHCP relay sending the message by the IP address of said device. Thus, when the server wishes to respond to the relay, it will send its data to the address contained in the GIADDR field, that is to say to the gateway which will be ensured to see all messages from the server.

The invention also relates to a communication system, comprising at least one DHCP relay, at least one DHCP server and a device as previously defined.

The invention also relates to a communication method in a telecommunication network comprising at least one DHCP relay and at least one DHCP server, a device implementing the following steps:

- interception of at least one message from a said relay and to a said server,

modifying a content of an option field of an intercepted message, in particular of the option field 82, so that the presentation format of said content after modification is independent of the relay from which said message originates, and

- transmission of the modified message to the destination server or relay.

According to one embodiment of the communication method according to the invention, when the intercepted message is a message said incident message, the device implements further the following steps,

interception of a response message sent by a said server in response to the incident message,

modifying a content of said option field of the response message so as to restore the presentation format used in the incident message before modifying the incident message.

A method according to the invention may also include one or more of the following features

The method comprises a step during which the device modifies the intercepted message, in particular an option 54 of the message, by replacing the IP address of the DHCP relay transmitting the message with the IP address of said device. Thus, when the receiving device of the message will subsequently communicate directly with the server, without the new message passing through the relay, it will send its DHCP data to the address contained in option 54, that is to say the gateway which will be ensured to see all messages to the server.

The method comprises a step during which the device modifies the intercepted message, in particular a GIADDR field of the message, by replacing the IP address of the destination DHCP server of the message with the IP address of said device. Thus, when the server wishes to respond to the relay, it will send its data to the address contained in the GIADDR field, that is to say to the gateway which will be ensured to see all messages from the server.

- The intercepted message being an incident message, when the device intercepts a response message to the incident message, it modifies the response message so as to restore a modified item when changing the incident message.

- The intercepted message being a first message from the relay, the relay being of a first type, it implements the interception step to intercept a second message from a second relay of a second different type of the first type and it implements the step of modifying the content of option 82 of the two messages so that the presentation formats of said content are the same. This modification of the content of the DHCP message according to a common presentation format makes it possible to use several types of DHCP relays and a single type of DHCP server without modifying them, even if their presentation formats of the information contained in option 82 of the messages are heterogeneous.

The subject of the invention is also a signal conveying a message from a DHCP relay and intended to be transmitted to a DHCP server, the presentation format of a content of an option field of said message being independent of the relay from which said message comes.

The invention also relates to a computer program capable of controlling the implementation of the steps of a method as defined above.

The invention also relates to a data recording medium, comprising a program as defined above.

The invention also relates to a provision of a program as previously defined for download.

The invention will be better understood on reading the description which follows, given solely by way of example and with reference to the single appended figure which is a diagram of a communication system according to the invention. FIG. 1 shows a data transmission network designated by the general reference 10. In this example, the network 10 comprises two sub-networks 12 and 14. Terminals 16 are connected to the first sub-network 12, and terminals 18 are connected to the second subnet 14. The transmission of data in the network

10 is provided by means of routers 20.

The network 10 comprises a communication system 21 comprising a plurality of DHCP equipment. The communication system 21 comprises a single DHCP server 22 forming part of the second subnet 14.

The first subnet 12 does not include any DHCP server. It comprises however a DHCP relay 24 forming part of the communication system 21 and intended to relay the DHCP messages sent by the equipment 16 of the first subnet 12 to the DHCP server 22 of the second subnet 14.

The role of the DHCP server is to assign an IP address to a newly connected network terminal that requests it. Since a new terminal does not know the IP address of the DHCP server, it sends a request in "broadcast" mode, that is to say a request sent throughout the network. The server 22, responding to an IP address assignment message, modifies the content of option 54 of the message, entitled "Server-identifier", by inserting its own IP address. This makes it possible to inform the terminal of the IP address of the DHCP server so that the terminal can transmit the DHCP messages in unicast mode during the exchanges of subsequent DHCP messages, that is to say directly to the attention of the server. .

Two cases can be envisaged depending on whether a terminal 16 connected to the first sub-network 12 or a terminal 18 connected to the second sub-network 14 is considered.

According to a first case, when a terminal 18 connects to the second subnet 14,

11 transmits a message in "broadcast" mode of configuration data assignment request, including request for assigning an IP address. The message broadcast in "broadcast" mode is transmitted throughout the second subnet 14 but can not exceed the limits. Since the server 18 is part of this second subnet 14, it receives the message from the IP address assignment request and responds directly to it.

According to a second case, an IP address assignment request message transmitted in "broadcast" mode by a terminal 16 belonging to the first subnet 12 remains confined within the first subnet 12 and can not directly reach the DHCP server 22 because it belongs to the second subnet 14. The role of the DHCP relay 24 is to detect messages sent by terminals 16 belonging to the first subnet

12 and transfer them to the server 22 present in the second subnet 14. For this, Relay 24 is previously informed of the address of server 22 for the redirection of messages.

To ensure that the exchange of DHCP messages between the terminal 16 and the DHCP server 22 routinely through it, the relay 24 is able to change the content of DHCP messages.

First, the DHCP relay modifies the DHCP messages sent by the terminal 16 to add its own IP address in a field named GIADDR. The IP address contained in the GIADDR field, that is to say the IP address of the relay 24, is used by the server 22 to send the response to the IP address assignment request to the relay 24 which then transfers to the terminal 16.

In addition, the DHCP relay changes the contents of option 54 of DHCP messages by inserting its own IP address instead of the IP address of the DHCP server originally contained in this option. This allows the subsequent messages that the terminal 16 expects to send to the DHCP server to be sent to the DHCP relay.

Thus, by virtue of these modifications made to the content of the DHCP messages, the relay 24 ensures that all the DHCP messages exchanged between the server 22 and terminals 16 of the first subnet 12 pass through it.

In addition to the GIADDR field and the option 54, the relay 24 is arranged to modify the contents of the option 82 entitled "Relay Agent Information Option", for example, to insert in the DHCP message sent between the terminal 16 and the relay 22 , an identifier of the line of the terminal 16, regardless of the direction of transmission of the message.

However, the encoding format of the data contained in the option field 82 is not standardized and actually depends on the type of DHCP relay 24 modifying that content. The three DHCP relays implemented in the aforementioned Redback SE 800, Cisco 7200, and Juniper ERX devices each present the information contained in option 82 in a different manner.

For example, assume that the line information of the terminal 16 is as follows:

- Slot of the ATM card on the equipment: 1;

- ATM port: 0;

- ATM virtual path: 37;

- ATM virtual channel: 170.

A Cisco 7200-type DHCP Relay encodes this bit-line information into a sub-option 2 of option 82 "remote-ID" as follows: o 520e 020c 0101 0000 0000 0000 2025 OOaa A Redback SE 800 relay presents the contents of option 82 in a different way since this content is coded in ASCII format in sub-option 1 entitled "circuit-ID". The presentation is as follows:

O 1/0 vpi-vci 37 170

Finally, a Juniper ERX-type relay presents the ASCII line information in Option 82 sub-option 1 in a different way:

O ATM 1/0 vpi / vci 37 170

It therefore appears that each type of DHCP relay presents the content of the option 82 of the DHCP frame in a manner that is unique to it.

However, the DHCP server 22 is not suitable for processing these different data encoding formats. . Indeed, by the standard, these servers process the content of option 82 without modifying it, this in particular in order not to complicate the processing of requests made by these servers and not to degrade the performance of these servers in terms of concerns the processing times of requests. To solve this problem, the communication system 21 comprises a communication device 26, also called gateway 26, for the processing of the DHCP messages exchanged between the relay 24 and the server 22 of the network 10.

The gateway 26 is interposed between the two routers 20 respectively part of the subnets 12 and 14, and to ensure the transmission of DHCP messages from one of the subnets to the other. The gateway 26 is distinct from the DHCP relay 24 and the DHCP server 22 and comprises means 28 for modifying the content of the option 82 of a message exchanged between the relay 24 and the server 22. The gateway 26 further comprises means 30 to transmit the modified message to the receiving DHCP device of the message.

Means 28 are capable of modifying the content of option 82 of the DHCP messages exchanged according to a predetermined presentation according to the equipment receiving the DHCP message. For this purpose, the gateway 26 comprises means 32 for storing the predetermined presentation of each DHCP equipment.

The means 28 are also able to modify the content of the option 54 and the GIADDR field of the messages.

The predetermined presentation associated with a DHCP relay 24 depends on the model of the relay. Examples of pre-defined presentations used by the DHCP Redback SE 800, Cisco 7200, and Juniper ERX relays have been previously described.

To simplify the processing of DHCP messages received by a DHCP server, it is proposed in the present embodiment of the invention that for all messages DHCP sent to a DHCP server, the data contained in sub-option 1 of option 82 is coded in ASCII format and formatted as follows:

DSLAM-ldentifier! Chassis! Atm! Slot / port: vpi.vci

In this coding mode, the different subfields are separated by predefined characters ("!", 7 ",": ",". ", Etc.) and the subfields are predefined. the subfields are:

the field "DSLAMJdentifier" represents the DSLAM (Digital Subscriber Line Access Multiplexer)

- the "chassis" field represents the chassis number,

the field "atm" represents the type of line,

the "slot" field represents the slot identifier,

the "port" field represents the port number,

the "vpi" field represents the virtual path identifier ("virtual path identifier"), and

the "vci" field represents the virtual channel identifier ("virtual channel identifier"). Then, the line information of the previously described example would be coded as follows:

DSLAM-12345 PARIS atm 1/0!!! 37170

By using the gateway of the invention, it is possible to use several different DHCP relay models on the same network without having to make the DHCP server capable of interpreting different presentations of the option 82.

For example, if the gateway intercepts two messages from respectively a first relay of a first type and a second relay of a second type different from the first type, it modifies the contents of option 82 of the two messages. so that the presentation formats of said content are the same.

Of course, when the gateway intercepts a response message to an incident message, it modifies the response message so as to restore the modified presentation format when modifying the incident message. Thus, each DHCP device receives messages whose content is presented in the way that is most easy for them to interpret.

Apart from the main function of modifying the content of option 82 of the exchanged DHCP messages, gateway 26 may have additional functions.

The gateway 26 can filter the exchanged DHCP messages according to their content or their number. For example, the gateway 26 can limit the number of DHCP leases allocated per subnet by refusing to transmit the new lease allocation requests when the limit of allocated leases is reached. The gateway 26 can also count the DHCP messages exchanged between a terminal and the DHCP server in order to identify the terminals whose behavior is abnormal, especially those whose activity exceeds a predetermined threshold.

In order for the gateway 26 to be able to modify a maximum of DHCP messages exchanged between the relays 24 and the server 22, it is desirable for all the exchanged messages to pass through the gateway 26. For this, two embodiments can be envisaged.

According to a first embodiment, said "bridge" mode, the gateway 26 is neither the source nor the recipient of the message and does not modify the information for routing the message in the network. In particular, it modifies neither the GIADDR field nor the source and destination IP addresses of the message. The gateway 26 modifies only the contents of certain options including the option 82. In order for all the messages to pass through the gateway and since the gateway is neither the source nor the recipient of the messages, it is necessary that the routing equipments of the network are configured so that all the messages exchanged from one of the subnets to the other pass through the gateway. In the event of software or hardware failure of the gateway, it is advantageous to provide a so-called "bypass" or bypass mode, in which the messages cross the gateway without being modified.

According to a second embodiment, called "proxy" mode, the gateway masquerades as a DHCP relay from the point of view of the DHCP server and pretends to be a DHCP server from the point of view of the DHCP relay. Under these conditions, each DHCP equipment believing to send a DHCP message to another DHCP device will actually send it to the gateway through which all DHCP messages will then pass.

To do this, the gateway modifies the GIADDR field and the content of option 54 messages exchanged between the network equipment.

For example, when a message from a client terminal, which has been relayed by a DHCP relay to a DHCP server, passes through the gateway, it modifies the message to replace the IP address of the DHCP relay initially contained in the GIADDR field by its own IP address. It also modifies the content of option 82 according to the invention.

Then, before transmitting this modified message to the DHCP server, the gateway stores, in its storage means 32, the initial content of the GIADDR field and the presentation of the option 82. To retrieve this stored information, the gateway associates with a unique identifier of the DHCP transaction, for example the identifier Xid or the MAC address of the client terminal.

Upon receiving the message, the DHCP server uses the IP address contained in the GIADDR field to respond. Thus, it will send its response message to the gateway.

Upon receipt of this response message, the gateway again modifies the contents of option 82 to be presented as specified by the relay to which the message is sent. For this, it reuses the information stored in the storage means 32 and in particular the initial content of the GIADDR field which corresponds to the IP address to which the modified response message is transmitted.

In addition, the gateway modifies the response message to replace the IP address of the DHCP server initially contained in option 54 of the message by its own IP address. This address will then be used by the client terminal if it wishes to communicate directly with the DHCP server.

Thanks to this embodiment, the gateway is assured that all DHCP messages pass through it, without however the DHCP equipment noticing it.

Finally, note that the invention is not limited to the embodiments described above.

Claims

A communication device (26) for a telecommunications network comprising at least one DHCP relay (24) and at least one DHCP server (22), the device being able to intercept at least one DHCP message from a said relay (24) and to a said server (22), and comprising means (28) for modifying a content of an option field of an intercepted message so that the presentation format of said content after modification is relay independent from which said message comes, and means for transmitting the modified message to the destination server (22).

2. Communication device (26) according to claim 1, wherein the intercepted message being an incident message, the device is able to intercept a response message sent by a said server (22) in response to the incident message, said device comprising means (28) for modifying a content of said option field of the response message so as to restore the presentation format used in the incident message before modifying the incident message.

3. Communication device (26) according to claim 2, intended to be inserted between a first (12) subnetwork and second (14) subnetwork of the telecommunications network, the device being arranged to intercept all the messages sent from one subnet to a DHCP server on the other subnet, and any replies sent back by the DHCP server.

A communication device (26) according to any one of the preceding claims, the device comprising means (28) for replacing, in an option field of an intercepted message, in particular in the option field 54, the IP address of the DHCP server (22) receiving the message by the IP address of said device (21).

5. Communication device (26) according to any one of the preceding claims, the device comprising means (28) for replacing, in an option field of an intercepted message, in particular in the GIADDR option field, IP address of the DHCP relay (24) transmitting the message by the IP address of said device (21).

A communication system (21) comprising at least one DHCP relay (24), at least one DHCP server (22) and a device (26) according to any one of the preceding claims.

7. A communication method in a telecommunication network comprising at least one DHCP relay (24) and at least one DHCP server (22), in which a device (26) of said network implements the following steps: - interception of at least one message from a said relay and to a said server,

modifying a content of an option field of an intercepted message, so that the presentation format of said content after modification is independent of the relay from which said message originates, and transmission of the modified message to the destination server or relay .

The communication method (26) of claim 7, wherein the intercepted message is an incident message, the device implements the following steps,

interception of a response message sent by a said server (22) in response to the incident message,

9. The communication method as claimed in claim 7, comprising a step during which the device modifies the content of a field of the intercepted message, in particular the content of the GIADDR field, by replacing the IP address of the server. DHCP (22) recipient of the message by the IP address of said device (21).

The communication method according to any one of claims 7 to 9, wherein the method comprises a step in which the device (26) modifies the intercepted message, including an option 54 of the message, by replacing the address IP of the DHCP relay (24) transmitting the message by the IP address of said device (21).

1 1. Signal carrying a message from a DHCP relay (24) and intended to be transmitted to a DHCP server (22), the presentation format of a content of an option field of said message being independent of relay from which said message.

Computer program capable of controlling the implementation of the steps of a method according to any one of claims 7 to 10.

13. Data recording medium comprising a program according to the preceding claim.

14. Provision of a program for downloading, the program being in accordance with claim 12.