idnits 2.17.1 draft-ietf-dhc-triggered-reconfigure-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3315, updated by this document, for RFC5378 checks: 1995-02-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 21, 2013) is 4051 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group M. Boucadair 3 Internet-Draft X. Pougnard 4 Updates: 3315, 6422 (if approved) France Telecom 5 Intended status: Standards Track March 21, 2013 6 Expires: September 22, 2013 8 Reconfigure Triggered by DHCPv6 Relay Agents 9 draft-ietf-dhc-triggered-reconfigure-05 11 Abstract 13 This document defines new DHCPv6 messages: Reconfigure-Request and 14 Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6 15 relay agent to notify a DHCPv6 server about a configuration 16 information change, so that the DHCPv6 server can send a Reconfigure 17 message accordingly. Reconfigure-Reply message is used by the server 18 to acknowledge the receipt of Reconfigure-Request. 20 This document updates RFC 3315 and RFC 6422. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 22, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Link Address Option . . . . . . . . . . . . . . . . . . . . . 6 61 6. Detailed Specification . . . . . . . . . . . . . . . . . . . 6 62 6.1. Messages Format . . . . . . . . . . . . . . . . . . . . . 7 63 6.2. Messages Validation . . . . . . . . . . . . . . . . . . . 7 64 6.2.1. RECONFIGURE-REQUEST . . . . . . . . . . . . . . . . . 7 65 6.2.2. RECONFIGURE-REPLY . . . . . . . . . . . . . . . . . . 7 66 6.3. Creation and Transmission of RECONFIGURE-REQUEST . . . . 7 67 6.4. Intermediate Relay Agents Behaviour . . . . . . . . . . . 9 68 6.5. Server Behaviour . . . . . . . . . . . . . . . . . . . . 9 69 6.6. Receipt of RECONFIGURE-REPLY . . . . . . . . . . . . . . 10 70 7. Rate Limiting Considerations . . . . . . . . . . . . . . . . 10 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 11.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 This document specifies two new DHCPv6 messages [RFC3315]: 82 Reconfigure-Request and Reconfigure-Reply. 84 Section 3 describes a typical problem encountered to trigger the 85 DHCPv6 server to issue a Reconfigure message when the configuration 86 data is supplied by the relay agent. This problem may be encountered 87 in other contexts. It is out of scope of this document to list all 88 these cases. 90 Section 4 describes the proposed solution which relies on the use of 91 Reconfigure-Request and Reconfigure-Reply messages. Reconfigure- 92 Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 93 server about a configuration information change, so that the DHCPv6 94 server can send a Reconfigure message accordingly. Reconfigure-Reply 95 message is used by the server to acknowledge the receipt of 96 Reconfigure-Request. 98 Section 6 provides the detailed specification of the procedure to 99 trigger Reconfigure messages by DHCPv6 relay agents. 101 2. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 3. Problem 109 [RFC6422] updates the DHCPv6 specification with a new feature to let 110 a DHCPv6 relay agent communicate information towards a DHCPv6 client, 111 and which is not available at the DHCPv6 server. This is achieved 112 owing to the use of RSOO (Relay-Supplied Options option) which 113 carries configuration data to the DHCPv6 server. The data conveyed 114 in an RSOO is then sent back by the DHCPv6 server to the requesting 115 DHCPv6 client. 117 An example of a RSOO context is shown in Figure 1; only a subset of 118 exchanged DHCPv6 and RADIUS messages is represented. Figure 1 shows 119 a broadband network scenario in which the Network Access Server (NAS) 120 embeds a DHCPv6 relay agent. 122 +-------+ +-------+ +-------+ 123 |DHCPv6 | | NAS | |Radius | 124 |Client | |(DHCPv6| |Server | 125 | | | Relay)| | | 126 +-------+ +-------+ +-------+ 127 | | | 128 |---Solicit---------------->| | 129 | |---Access-Request---------->| 130 |<--Access-Accept------------| 131 | (e.g. DS-Lite-Tunnel-Name)| 132 .... 133 | +-------+ 134 | |DHCPv6 | 135 | |Server | 136 | | | 137 | +-------+ 138 | | 139 |---Relay-Forward----------->| 140 | (RSOO(OPTION_AFTR_NAME)) | 141 | | 142 | |<--Relay-Reply--------------| 143 |<--Advertise---------------| (e.g., OPTION_AFTR_NAME) | 144 | (e.g., OPTION_AFTR_NAME) | 145 .... 147 Figure 1: An Example of the RSOO Option Usage 149 The change of the configuration may result in an exchange of CoA 150 (Change-of-Authorization, [RFC5176]) messages between the NAS/DHCPv6 151 relay agent and Dynamic Authorization Client (DAC) server as shown in 152 Figure 2. In this example, the NAS answers with a CoA-Ack message to 153 notify the DAC the CoA-Request is successfully handled. 155 Note the change of the configuration in the DHCPv6 relay agent can be 156 triggered by any other out-of-band mechanism. 158 +-------+ +-------+ +-------+ 159 |DHCPv6 | | NAS | |Radius | 160 |Client | |(DHCPv6| |Server/| 161 | | | Relay)| | DAC | 162 +-------+ +-------+ +-------+ 163 | | | 164 |<-----CoA-Request-----------| 165 | (e.g. DS-Lite-Tunnel-Name) | 166 |------CoA-Ack-------------->| 167 .... 169 Figure 2: Change of configuration 171 Whenever the configuration information sent by the DHCPv6 relay agent 172 to the DHCPv6 server change, the DHCPv6 server has no means to detect 173 the change so that it can send a Reconfigure message accordingly. A 174 solution is sketched in Section 4. 176 4. Proposed Solution 178 To solve the problem described in Section 3, this document proposes a 179 new DHCP message called Reconfigure-Request. In the example depicted 180 in Figure 3, a Reconfigure-Request message is sent by the DHCPv6 181 relay agent to a DHCPv6 server as soon as the configuration data 182 conveyed in an RSOO option have changed. Upon receipt of this 183 message, and if it is configured to support such mode, the DHCPv6 184 server must build Reconfigure-Reply and Reconfigure messages. 185 Reconfigure-Reply is used to acknowledge the receipt of Reconfigure- 186 Request. Reconfigure message encapsulated in Relay-Reply is sent to 187 the DHCPv6 relay, which in turn will forward the message to the 188 appropriate DHCPv6 client. 190 This setup assumes the relay has a record of the client, so that it 191 has enough information to send the Reconfigure-Request message to the 192 server. How the state is recorded in the relay is out of scope. 193 Furthermore, means to recover state in failure events must be 194 supported, but are not discussed in this document. 196 +-------+ +-------+ +-------+ 197 |DHCPv6 | | NAS | |Radius | 198 |Client | |(DHCPv6| |Server/| 199 | | | Relay)| | DAC | 200 +-------+ +-------+ +-------+ 201 | | | 202 |<-----CoA-Request-----------| 203 | (e.g. DS-Lite-Tunnel-Name) | 204 | | 205 |------CoA-Ack-------------->| 206 .... 207 | +-------+ 208 | |DHCPv6 | 209 | |Server | 210 | | | 211 | +-------+ 212 | | 213 |---Reconfigure-Request----->| 214 |<--Reconfigure-Reply--------| 215 | | 216 | |<--Relay-Reply -------------| 217 |<--Reconfigure-------------| (Reconfigure) | 218 | | | 219 .... 221 Figure 3: Flow Example with Reconfigure-Request 223 The support of Reconfigure-Reply simplifies the retransmission 224 procedure of the relay as it provides an explicit indication from the 225 server (see Section 6.3 for more details). An alternative approach 226 is the relay monitors Reconfigure messages received from the server 227 to conclude whether Reconfigure-Request was successfully handled or 228 not. Nevertheless, this implicit approach may fail to achieve its 229 goals in some cases: e.g., the server accepts the request but it 230 delays to generate the corresponding Reconfigure messages due to its 231 rate-limiting policies, the request was partially failed for some 232 clients, etc. To avoid useless reconfigure cycles (e.g., due to the 233 loss of Reconfigure-Reply), the approach adopted in this document 234 allows the relay to correct the content of a re-transmitted 235 Reconfigure-Request based on some observed events (e.g., the client 236 has retrieved the updated configuration). If the relay has no client 237 to reconfigured, it stops sending Reconfigure-Request messages. 239 The Reconfigure-Request message can also be used in other scenarios 240 than those that assume the use of RSOO. It is out of scope of this 241 document to describe all these scenarios. 243 5. Link Address Option 245 Figure 4 shows the format of the Link Address Option. 247 0 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | OPTION_LINK_ADDRESS | option-len | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 | link-address (IPv6 address) | 254 | | 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 4: Message Format of Link Address Option 260 The description of the fields are as follows: 262 option-code: OPTION_LINK_ADDRESS (To be assigned by IANA, see 263 Section 8). 265 option-len: 16 (octets). 267 link-address: An IPv6 address used by the server to identify the 268 link on which the client is located. 270 The Link Address Option is used by the relay agent to indicate to the 271 server the link on which the client is located. The relay agent MUST 272 use a link-address value that is equivalent to the value used when 273 relaying messages from the client to the server. Two link-address 274 values are said to be equivalent if both values are IPv6 addresses 275 that are on-link for the network link to which the client is 276 connected. The relay agent SHOULD use the same value that was sent 277 to the DHCPv6 server when relaying messages from the client to the 278 server, as in Section 20.1.1 of [RFC3315]. 280 6. Detailed Specification 281 6.1. Messages Format 283 Two new message type codes are defined: 285 o RECONFIGURE-REQUEST (To be assigned by IANA, see Section 8). 287 o RECONFIGURE-REPLY (To be assigned by IANA, see Section 8). 289 RECONFIGURE-REQUEST and RECONFIGURE-REPLY use the same format as 290 defined in Section 6 of [RFC3315]. 292 6.2. Messages Validation 294 6.2.1. RECONFIGURE-REQUEST 296 Clients MUST silently discard any received RECONFIGURE-REQUEST 297 messages. 299 Servers MUST discard any received RECONFIGURE-REQUEST messages that 300 meet any of the following conditions: 302 o the message does not include a Client Identifier Option [RFC3315]. 304 o the message does not include a Link Address Option (Section 5). 306 o the message includes a Server Identifier Option [RFC3315] but the 307 contents of the Server Identifier Option does not match the 308 server's identifier. 310 6.2.2. RECONFIGURE-REPLY 312 Clients and Servers MUST silently discard any received RECONFIGURE- 313 REPLY messages. 315 The relay MUST silently discard any received RECONFIGURE-REPLY 316 messages that meet any of the following conditions: 318 o the "transaction-id" field in the message does not match the value 319 used in the original message. 321 o the message does not include a Server Identifier Option. 323 o the message does not include a Status Code Option [RFC3315]. 325 6.3. Creation and Transmission of RECONFIGURE-REQUEST 327 For any event (e.g., modification of the configuration information) 328 that requires the server to issue a Reconfigure message, the relay 329 agent determines the client(s) affected by the change and then builds 330 a Reconfigure-Request message: the relay agent sets the "msg-type" 331 field to RECONFIGURE-REQUEST, generates a transaction ID and inserts 332 it in the "transaction-id" field. 334 The relay agent MUST include one or more Client Identifier Options 335 [RFC3315] and a Link Address Option (Section 5) so that the DHCPv6 336 server can identify the corresponding client and the link on which 337 the client is located. 339 The relay agent MAY include a Relay Identifier Option [RFC5460]. 341 The relay agent MAY supply the updated configuration in the RSOO 342 [RFC6422]. The relay agent MAY supply a Reconfigure Message Option 343 to indicate which form of Reconfigure to use. The relay agent MAY 344 include any option (e.g., Interface Identifier [RFC3315]) which it 345 might insert when relaying a message received from a client. 347 When several clients on the same link are affected by a configuration 348 change, the relay MUST include several Client Identifier Options, 349 each of them identifies a specific client. If including Client 350 Identifier Options of all impacted clients exceeds the maximum 351 message size (see Section 7), the relay MUST generate several 352 RECONFIGURE-REQUEST messages required to carry all Client Identifier 353 Options. Rate-limit considerations are discussed in Section 7. 355 The relay sets the destination address of the Reconfigure-Request 356 message to the IP address it would have sent a Relay-Forw message 357 (see Section 20 of [RFC3315]). 359 In case multiple servers are configured to the relay agent, several 360 Reconfigure-Request messages are to be built. The behavior of the 361 relay agent to disambiguate responses when multiple servers are 362 configured is implementation-specific. For example, an 363 implementation may generate distinct "transaction-id"s per server 364 while another implementation may use the content of the "transaction- 365 id" field and the Server Identifier Option to disambiguate the 366 responses. 368 The relay transmits RECONFIGURE-REQUEST messages according to 369 Section 14 of [RFC3315], using the following parameters: 371 IRT 1 sec 372 MRT 10 secs 373 MRC 5 374 MRD 0 375 When retransmission is required, the relay may decide to correct the 376 content of RECONFIGURE-REQUEST message it issues (e.g., update the 377 Client Identifier list). This decision is local to the relay (e.g., 378 it may be based on observed events such as one or more clients were 379 reconfigured on their own). 381 The relay may receive Reconfigure encapsulated in Relay-Reply before 382 Reconfigure-Reply. The relay SHOULD NOT interpret it as if the 383 Reconfigure-Request was successfully handled by the Server. The 384 relay SHOULD use Reconfigure-Reply, not the Reconfigure message, to 385 determine if the request was successful. 387 6.4. Intermediate Relay Agents Behaviour 389 The relay agent MUST be configurable to accept or reject RECONFIGURE- 390 REQUEST messages received from other relay agents. If no indication 391 is explicitly configured to the relay, the default behavior is to 392 accept RECONFIGURE-REQUEST messages. 394 If the relay is configured to reject RECONFIGURE-REQUEST, the relay 395 MUST silently discard any RECONFIGURE-REQUEST it receives. If the 396 relay is configured to accept RECONFIGURE-REQUEST messages, these 397 messages are relayed as specified in Section 20.1.1 of [RFC3315]. 399 6.5. Server Behaviour 401 The server MUST be configurable to accept or reject RECONFIGURE- 402 REQUEST messages. If no indication is explicitly configured to the 403 server, the default behavior is to reject RECONFIGURE-REQUEST 404 messages. 406 Upon receipt of a valid Reconfigure-Request message from a DHCPv6 407 relay agent (see Section 6.2), the server determines the client(s) 408 for which a Reconfigure message is to be sent. 410 The server constructs a Reconfigure-Reply message by setting the 411 "msg-type" field to RECONFIGURE-REPLY, and copying the transaction ID 412 from the RECONFIGURE-REQUEST message into the "transaction-id" field. 413 The server includes its server identifier in a Server Identifier 414 Option. The server MUST include a Status Code Option [RFC3315] 415 indicating whether the request is successfully processed, failed or 416 partially failed. 418 o If the server fails to validate the request, the server MUST set 419 the Status Code Option to the appropriate status code (e.g., 420 UnspecFail, NotAllowed, etc.). In particular, 421 * UnspecFail MUST be returned if Reconfigure-Request message is 422 malformed. 424 * NotAllowed MUST be returned if the server is not configured to 425 allow Reconfigure-Request. 427 * NotConfigured MUST be returned if the server has no record of 428 the link. 430 o If the Reconfigure-Request is successfully validated, the server 431 MUST return a Status Code Option indicating "Success". In 432 addition, the server MUST include a list of all the Client 433 Identifier Options of the clients to which Reconfigure messages 434 will not be sent (e.g., the server has no record of the client or 435 the client did not negotiate for Reconfigure support). Note that 436 this means that "Success" will be returned even if Reconfigure 437 messages will not be sent to any of the clients. 439 If RSOO is supplied, the server MAY use its content to double check 440 whether a Reconfigure is required to be sent to the client. This 441 assumes the server stored the content of RSOO it used to generate 442 configuration data sent to requesting clients. 444 The server MAY use the content of the Reconfigure Message Option 445 supplied by the relay agent to determine which form of Reconfigure to 446 use. 448 Then, the server MUST follow the procedure defined in Section 19.1 of 449 [RFC3315] to construct a Reconfigure message. 451 Rate-limit considerations are discussed in Section 7. 453 6.6. Receipt of RECONFIGURE-REPLY 455 Depending on the status code enclosed in a received RECONFIGURE-REPLY 456 message, the relay may decide to terminate the request or try a 457 different corrected Reconfigure-Request. 459 When multiple servers are configured, the relay should expect to 460 receive several Reconfigure-Reply messages. As mentioned in 461 Section 6.3, the relay should be able to disambiguate these responses 462 and associate them with a given server. The relay agent assumes the 463 request is successfully handled for a client if the corresponding 464 Client Identifier Option does not appear in at least one Reconfigure- 465 Reply message. 467 7. Rate Limiting Considerations 468 The relay MUST rate-limit Reconfigure-Request messages to be sent to 469 the server. The relay MUST be configured with required rate-limit 470 parameters (i.e., the rate of Reconfigure-Request messages). The 471 maximum Reconfigure-Request packet size SHOULD be configurable and 472 the default value MUST be 1280 octets. 474 The server MUST rate-limit Reconfigure messages triggered by 475 Reconfigure-Request messages. The server MUST be configured with 476 required rate-limit parameters (i.e., the rate of Reconfigure 477 messages). 479 8. IANA Considerations 481 IANA is requested to assign the following new DHCPv6 Message type in 482 the registry maintained in http://www.iana.org/assignments/ 483 dhcpv6-parameters: 485 RECONFIGURE-REQUEST 487 RECONFIGURE-REPLY 489 IANA is requested to assign the following new DHCPv6 Option Codes in 490 the registry maintained in http://www.iana.org/assignments/ 491 dhcpv6-parameters: 493 OPTION_LINK_ADDRESS 495 9. Security Considerations 497 Security considerations elaborated in [RFC3315] (in particular 498 Section 21.1) and [RFC6422] must be taken into account. In addition, 499 DHCPv6 servers MAY be configured to reject relayed Reconfigure- 500 Request messages or restrict relay chaining (see [RFC5007] for more 501 discussion about the rationale of this recommended behavior). 502 Section 6.5 specifies the error code to return when the server is 503 configured to reject Reconfigure-Request messages. 505 Relay agents SHOULD implement appropriate means to prevent using 506 Reconfigure-Request messages as a denial-of-service attack on the 507 DHCPv6 servers. 509 Because Reconfigure-Request message provides a mechanism for 510 triggering the DHCP Reconfigure message, and the DHCP Reconfigure 511 message can raise security threats (e.g., to control the timing of a 512 DHCP renewal), the DHCP server MUST have some mechanism for 513 determining that the relay agent is a trusted entity. A control 514 policy based on the content of received Relay Identifier Option MAY 515 be enforced by the DHCPv6 server. Reconfigure-Request messages 516 originating from unknown relay agents MUST be silently dropped. 518 10. Acknowledgements 520 Many thanks to R. Maglione, A. Kostur, G. Halwasia and C. 521 Jacquenet for the comments and review. 523 Special thanks to T. Lemon, B. Volz and T. Mrugalski who provided 524 a detailed review. 526 11. References 528 11.1. Normative References 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 534 and M. Carney, "Dynamic Host Configuration Protocol for 535 IPv6 (DHCPv6)", RFC 3315, July 2003. 537 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 538 6422, December 2011. 540 11.2. Informative References 542 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 543 "DHCPv6 Leasequery", RFC 5007, September 2007. 545 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 546 Aboba, "Dynamic Authorization Extensions to Remote 547 Authentication Dial In User Service (RADIUS)", RFC 5176, 548 January 2008. 550 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 551 2009. 553 Authors' Addresses 554 Mohamed Boucadair 555 France Telecom 556 Rennes 35000 557 France 559 Email: mohamed.boucadair@orange.com 561 Xavier Pougnard 562 France Telecom 563 Lannion 564 France 566 Email: xavier.pougnard@orange.com