idnits 2.17.1 draft-ietf-mext-nemo-pd-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 26, 2009) is 5295 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 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-04 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Extensions for IPv6 R. Droms 3 (MExt) P. Thubert 4 Internet-Draft Cisco 5 Intended status: Standards Track F. Dupont 6 Expires: April 29, 2010 ISC 7 W. Haddad 8 Ericsson 9 October 26, 2009 11 DHCPv6 Prefix Delegation for NEMO 12 draft-ietf-mext-nemo-pd-03 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 29, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 One aspect of network mobility support is the assignment of a prefix 51 or prefixes to a Mobile Router (MR) for use on the links in the 52 Mobile Network. DHCPv6 prefix delegation can be used for this 53 configuration task. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Application of DHCPv6 prefix delegation to mobile networks 60 for delegation of home prefixes . . . . . . . . . . . . . . . 4 61 3.1. When the MR uses DHCPv6 . . . . . . . . . . . . . . . . . 4 62 3.2. Use of MR-HA tunnel for DHCPv6 messages . . . . . . . . . 5 63 3.3. DHCPv6 Relay Agent for transmission of DHCPv6 messages . . 5 64 3.3.1. Relay agent configuration . . . . . . . . . . . . . . 5 65 3.3.2. Transmission of DHCPv6 messages . . . . . . . . . . . 6 66 3.3.3. Receipt of DHCPv6 messages . . . . . . . . . . . . . . 6 67 3.4. Exchanging DHCPv6 messages when MR is at home . . . . . . 6 68 3.5. Selecting an HA that provides DHCPv6PD . . . . . . . . . . 7 69 3.6. Minimizing DHCPv6PD messages . . . . . . . . . . . . . . . 7 70 3.7. Location of DHCPv6PD Delegating Router function . . . . . 7 71 3.8. Other DHCPv6 functions . . . . . . . . . . . . . . . . . . 8 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1. Revision -00 . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.2. Revision -01 . . . . . . . . . . . . . . . . . . . . . . . 10 77 6.3. Revision -02 . . . . . . . . . . . . . . . . . . . . . . . 11 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 80 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 One aspect of network mobility support is the assignment of a prefix 86 or prefixes to a Mobile Router for use on the links in the Mobile 87 Network. DHCPv6 prefix delegation [RFC3633] (DHCPv6PD) can be used 88 for this configuration task. 90 2. Terminology 92 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 93 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 94 interpreted as described in RFC2119 [RFC2119]. 96 The following terms used in this document are defined in the IPv6 97 Addressing Architecture document [RFC4291]: 99 link-local unicast address 101 link-local scope multicast address 103 The following terms used in this document are defined in the mobile 104 IPv6 specification [RFC3775]: 106 home agent (HA) 108 home link 110 The following terms used in this document are defined in the Mobile 111 Network terminology document [RFC4886]: 113 Mobile Router (MR) 115 Mobile Network 117 mobile host (MH) 119 The following terms used in this document are defined in the DHCPv6 120 [RFC3315] and DHCPv6 prefix delegation [RFC3633] specifications: 122 delegating router (DR; acts as a DHCPv6 server) 124 requesting router (RR; acts as a DHCPv6 client) 126 DHCPv6 relay agent 128 The following acronym is used in this document: 130 DHCPv6PD: DHCPv6 prefix delegation 132 3. Application of DHCPv6 prefix delegation to mobile networks for 133 delegation of home prefixes 135 The NEMO Basic protocol [RFC3963] extends the mobile IPv6 protocol 136 [RFC3775] to enable network mobility. In this extension, a MR uses 137 the mobile IPv6 protocol to establish and maintain a session with its 138 HA, and uses bidirectional tunneling between the MR and HA to provide 139 a path through which nodes attached to links in the Mobile Network 140 can maintain connectivity with nodes not in the Mobile Network. 142 The requirements for NEMO [RFC4885] include the ability of the MR to 143 receive delegated prefixes that can then be assigned to links in the 144 Mobile Network. DHCPv6PD can be used to meet this requirement for 145 prefix delegation. 147 To use DHCPv6PD for Mobile Networks, the HA assumes the role of 148 either the DR or a DHCPv6 relay agent and the MR assumes the role of 149 the RR. Throughout the remainder of this document, the HA will be 150 assumed to be acting as a DHCPv6PD DR or relay agent and the MR will 151 be assumed to be acting as a RR. 153 If the HA is acting as relay agent, some other device acts as the DR. 154 For example, the server providing DHCPv6 service in the home network 155 might also provide NEMO DHCPv6PD service. Or, a home network with 156 several HAs might configure one of those HAs as a DHCPv6PD server 157 while the other HAs act as relay agents. 159 The HA and MR exchange DHCPv6PD protocol messages through the tunnel 160 connecting them. The tunnel acts as the link labeled "DSL to 161 subscriber premises" in figure 1 of the DHCPv6PD specification. 163 The DHCPv6PD server is provisioned with prefixes to be assigned using 164 any of the prefix assignment mechanisms described in the DHCPv6PD 165 specifications. Other updates to the HA data structures required as 166 a side effect of prefix delegation are specified by the particular 167 network mobility protocol. For example, in the case of Basic Network 168 Mobility Support [RFC3963], the HA would add an entry in its binding 169 cache registering the delegated prefix to the MR to which the prefix 170 was delegated. 172 3.1. When the MR uses DHCPv6 174 The MR initiates a DHCPv6 message exchange for prefix delegation 175 whenever it establishes an MR-HA tunnel to its HA. If the MR does 176 not have any active delegated prefixes (with unexpired leases), the 177 MR initiates a DHCPv6 message exchange with a DHCPv6 Solicit message 178 as described in section 17 of RFC 3315 and section 12.1 of RFC 3633. 179 If the MR has one or more active delegated prefixes, the MR initiates 180 a DHCPv6 message exchange with a DHCPv6 Rebind message as described 181 in section 18.1.2 of RFC 3315 and section 12.1 of RFC 3633. 183 3.2. Use of MR-HA tunnel for DHCPv6 messages 185 The DHCPv6 specification requires the use of link-local unicast and 186 link-local scope multicast addresses in DHCPv6 messages (except in 187 certain cases as defined in section 22.12 of the DHCPv6 188 specification). Section 10.4.2 of the mobile IPv6 specification 189 describes forwarding of intercepted packets, and the third paragraph 190 of that section begins: 192 However, packets addressed to the mobile node's link-local address 193 MUST NOT be tunneled to the mobile node. 195 The DHCPv6 messages exchanged between the HA and the MR originate 196 only with the HA and the MR, and therefore are not "intercepted 197 packets" and may be sent between the HA and the MR through the 198 tunnel. 200 Even though the MR-HA tunnel is a point to point connection, the MR 201 SHOULD use multicast DHCPv6 messages as described in RFC 3315 over 202 that tunnel. 204 3.3. DHCPv6 Relay Agent for transmission of DHCPv6 messages 206 A DHPCv6 relay agent function [RFC3315] can be used as an alternative 207 to multicast DHCPv6 messages over the tunnel between the MR and the 208 HA. In this configuration, the relay agent function is co-located in 209 the MR with the DHCPv6 client function. Rather than using multicast 210 to send DHCPv6 messages through the tunnel to the DHCPv6 server, the 211 DHCPv6 client in the MR hands any outbound DHCPv6 messages to the co- 212 located relay agent. Responses from the DHCPv6 server are delivered 213 to the relay agent function in the MR, which extracts the 214 encapsulated message and delivers it to the DHCPv6 client in the MR. 216 3.3.1. Relay agent configuration 218 The use of the relay agent function in the MR allows the MR to 219 unicast DHCPv6 messages to the DHCPv6 server. The relay agent must 220 be configured with the address of the DHCPv6 server or another DHCPv6 221 relay agent that will forward message on to a DHCPv6 server. For the 222 purposes of NEMO, the relay agent assumes that the HA for the MR 223 hosts the next hop in the path the to the DHCPv6 server: either the 224 DHCPv6 server or a relay agent that will forward message to the 225 DHCPv6 server. Therefore, if the MR acts as a DHCPv6 relay agent, 226 the MR MUST configure the DHCPv6 relay agent to forward DHCPv6 227 messages to the HA. 229 3.3.2. Transmission of DHCPv6 messages 231 In this configuration, when the DHCPv6 client in the MR sends a 232 message, it hands the message to the DHCPv6 relay agent in the MR. 233 The way in which this handoff takes place is beyond the scope of this 234 document. The relay agent encapsulates the message from the client 235 according to RFC 3315 in a Relay-forward message and sends the 236 resulting DHCPv6 message to the HA. The relay agent sets the fields 237 in the Relay-forward message as follows: 239 msg-type RELAY-FORW 241 hop-count 1 243 link-address A non-link-local address from the MR interface to the 244 tunnel between the HA and MR 246 peer-address A non-link-local address from the MR interface to the 247 tunnel between the HA and MR 249 options MUST include a "Relay Message option" [RFC3315]; MAY 250 include other options added by the relay agent. 252 3.3.3. Receipt of DHCPv6 messages 254 In this configuration, messages from the DHCPv6 server will be 255 returned to the DHCPv6 relay agent, with the message for the DHCPv6 256 client encapsulated in the Relay Message option [RFC3315] in a Relay- 257 reply message. The relay agent function extracts the message for the 258 client from the Relay Message option and hands the message to the 259 DHCPv6 client in the MR. The way in which this handoff takes place 260 is beyond the scope of this document. 262 3.4. Exchanging DHCPv6 messages when MR is at home 264 When the MR is on its home link, the HA uses the home link to 265 exchange DHCPv6PD messages with the MR. It is the responsibility of 266 the implementation to determine when the MR is on its home link and 267 to avoid use of any existing tunnel. 269 3.5. Selecting an HA that provides DHCPv6PD 271 Not all nodes that are willing to act as an HA are required to 272 provide DHCPv6PD. Therefore, when selecting an HA, a MR that 273 requires DHCPv6PD service must identify an HA that will provide the 274 service. The MR can determine if an HA provides DHCPv6PD by 275 initiating a DHCPv6 message exchange in which the MR requests 276 delegated prefix(es). If the HA does not respond or responds but 277 does not delegate any prefix(es) in its response, the MR assumes that 278 the HA does not provide DHCPv6PD service. The MR continues to query 279 all candidate HAs until it finds an HA that provides DHCPv6PD. 281 Querying an HA to determine if it provides DHCPv6PD requires a small 282 modification to the operation of DHCPv6 as described in RFC 3315. 283 Under normal circumstances, a host will continue to send DHCPv6 284 Solicit messages until it receives a response (see Section 17 of RFC 285 3315). However, an HA may choose not to respond to the Solicit 286 messages from the MR because the HA does not provide DHCPv6. 287 Therefore, when querying an HA to determine if the HA provides 288 DHCPv6PD service, the MR MUST discontinue sending Solicit messages to 289 the HA after sending 6 Solicit messages, and conclude that the HA 290 will not provide DHCPv6PD service. 292 The MR may choose to probe the HAs for DHCPv6PD service sequentially 293 or in parallel. 295 3.6. Minimizing DHCPv6PD messages 297 DHCPv6PD in a Mobile Network can be combined with the Rapid Commit 298 option [RFC3315] to provide DHCPv6 prefix delegation with a two 299 message exchange between the mobile node and the DHCPv6PD DR. 301 3.7. Location of DHCPv6PD Delegating Router function 303 Support of DHCPv6PD for a Mobile Network is optional. 305 The use of a DHCPv6 relay agent in DHCPv6PD may require "a protocol 306 or other out-of-band communication to add routing information for 307 delegated prefixes into the provider edge router" (section 14 of RFC 308 3633). If the DHCPv6PD DR function is implemented in the HA for the 309 MR, no relay agent function is required. 311 It may be desirable to use a single DR to manage RRs in a network 312 with multiple HAs. In this scenario, the HAs will act as DHCP relay 313 agents, forwarding messages between the RRs and the DR. 315 Use of the DHCPv6 relay agent function with DHCPv6PD requires that 316 there be some mechanism through which routing information for the 317 delegated prefixes can be added to the appropriate routing 318 infrastructure. If the HA is acting as a DHCPv6 relay agent, the HA 319 SHOULD add a route to the delegated prefix and advertise that route 320 after receiving a binding update for the prefix from the RR 321 [RFC3963]. 323 In particular, if the MR uses NEMO explicit mode, then it must add 324 the delegated prefix to the prefix list in the Binding Update 325 messages. If the binding cache is cleared before the prefix valid 326 lifetime, the MR might bind that prefix again using explicit mode, 327 till the lifetime expires. 329 In implicit mode, the HA must save the delegated prefix with the 330 binding cache entry (BDE) of the Mobile Router. When the BCE is 331 cleared, the HA loses the information about the delegated prefix. 332 Because the MR will use DHCPv6 when it reestablishes its tunnel to 333 the HA (see Section 3.1), the HA will be able to add the delegated 334 prefix back to the BCE. 336 At the time this draft was written, one way in which a DR can 337 explicitly notify a relay agent about delegated prefixes, is to use 338 the "DHCP Relay Agent Assignment Notification Option" 339 [I-D.ietf-dhc-dhcpv6-agentopt-delegate]. 341 Another alternative, if the RR is part of the same administrative 342 domain as the home network to which it is attached through the HA, 343 and the RR can be trusted, the RR can use a routing protocol like 344 OSPF to advertise any delegated prefixes. 346 NEMO explicit mode is recommended to take advantage of the function 347 already defined for NEMO. 349 3.8. Other DHCPv6 functions 351 The DHCPv6 messages exchanged between the MR and the HA may also be 352 used for other DHCPv6 functions in addition to DHCPv6PD. For 353 example, the HA may assign global addresses to the MR and may pass 354 other configuration information such as a list of available DNS 355 recursive name servers [RFC3646] to the MR using the same DHCPv6 356 messages as used for DHCPV6PD. 358 The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR 359 for MRs. 361 4. Security Considerations 363 This document describes the use of DHCPv6 for prefix delegation in 364 Mobile Networks. It does not introduce any additional security 365 considerations for DHCPv6 beyond those described in the "Security 366 Considerations" section of the DHCPv6 base specification [RFC3315] 367 and the "Security Considerations" of the DHCPv6 Prefix Delegation 368 specification [RFC3633]. 370 The use of DHCPv6, as described in this document, requires only 371 message integrity protection, which can be provided by the mobile 372 network infrastructure between the MR and the HA. 374 If the network infrastructure connecting the various communicating 375 nodes does not provide message integrity and source authentication 376 for the DHCPv6PD messages, HAs and MRs SHOULD use DHCPv6 377 authentication as described in section "Authentication of DHCP 378 messages" of the DHCPv6 specification [RFC3315], to guard against 379 attacks mounted through prefix delegation. 381 If the HA and DHCPv6 PD functions are not provided by the same 382 physical node, the HA will act as a DHCPv6 relay agent between the MR 383 and the DHCPv6 server. In this scenario, the mobile network 384 infrastructure will only protect the DHCPv6 traffic between the RR 385 (MR) and the relay agent (HA). The following text, based on Section 386 21.1 of RFC 3315, describes how appropriate security can be provided 387 between a DHCPv6 relay agent and server. 389 DHCPv6 relay agents and servers MAY use IPsec mechanisms for IPv6 390 [RFC2401] to exchange messages securely. DHCPv6 relay agents and 391 servers that support secure relay agent to server or relay agent 392 to relay agent communication use IPsec under the following 393 conditions: 395 Selectors DHCPv6 relay agents are manually configured with 396 the addresses of the DHCPv6 server to which DHCPv6 397 messages are to be forwarded. Each DHCPv6 server 398 that will be using IPsec for securing DHCPv6 399 messages must also be configured with a list of 400 the DHCPv6 relay agents to which messages will be 401 returned. The selectors for the DHCPv6 relay 402 agents and servers will be the pairs of addresses 403 defining DHCPv6 relay agents and servers that 404 exchange DHCP messages on the DHCPv6 UDP ports 546 405 and 547. 407 Mode DHCPv6 relay agents and servers use transport mode 408 and ESP. The information in DHCPv6 messages is 409 not generally considered confidential, so 410 encryption need not be used (i.e., NULL encryption 411 can be used). 413 Key management If the HA providing the DHCPv6 relay agent 414 function and the DHCPv6 servers are both 415 administered by the same organization, public key 416 schemes are not necessary. Because the relay 417 agents and servers must be manually configured, 418 manually configured key management may suffice, 419 but does not provide defense against replayed 420 messages. Accordingly, IKE with preshared secrets 421 SHOULD be supported. 423 Discussion: If NEMO may be deployed with the HA 424 and the DHCPv6 server in different 425 administrative domains, this text 426 should be extended to include the use 427 of IKE with public keys. 429 Security policy DHCPv6 messages between relay agents and servers 430 should only be accepted from DHCPv6 peers as 431 identified in the local configuration. 433 Authentication Shared keys, indexed to the source IP address of 434 the received DHCPv6 message, are adequate in this 435 application. 437 5. IANA Considerations 439 This document describes the use of DHCPv6 for prefix delegation in 440 Mobile Networks. It does not introduce any additional IANA 441 considerations. 443 6. Change Log 445 This section MUST be removed before this document is published as an 446 RFC. 448 6.1. Revision -00 450 This document is based on draft-ietf-nemo-dhcpv6-pd-03 and includes 451 the use of the DHCPv6 relay agent in the MR, as described in 452 Section 3.3, from draft-dupont-mext-dhcrelay-00. 454 6.2. Revision -01 456 Added detail in Section 4, "Security Considerations", describing 457 protection required for DHCPv6 and a mechanism for protecting traffic 458 between the DHCPv6 relay agent and server. 460 Corrected minor typos. 462 6.3. Revision -02 464 Removed text describing extensions to DHAAD for discovery of HA that 465 will provide PD. 467 Added Section 3.5, "Selecting an HA that provides DHCPv6PD," which 468 describes how an MR can discover DHCPv6PD service through polling of 469 multiple HAs. 471 Added text to Section 4, "Security Considerations", giving detail 472 about the use of IPsec. 474 7. References 476 7.1. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 482 Internet Protocol", RFC 2401, November 1998. 484 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 485 and M. Carney, "Dynamic Host Configuration Protocol for 486 IPv6 (DHCPv6)", RFC 3315, July 2003. 488 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 489 Host Configuration Protocol (DHCP) version 6", RFC 3633, 490 December 2003. 492 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 493 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 494 December 2003. 496 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 497 in IPv6", RFC 3775, June 2004. 499 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 500 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 501 RFC 3963, January 2005. 503 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 504 Architecture", RFC 4291, February 2006. 506 7.2. Informative References 508 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] 509 Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent 510 Assignment Notification (RAAN) Option", 511 draft-ietf-dhc-dhcpv6-agentopt-delegate-04 (work in 512 progress), July 2009. 514 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 515 Terminology", RFC 4885, July 2007. 517 [RFC4886] Ernst, T., "Network Mobility Support Goals and 518 Requirements", RFC 4886, July 2007. 520 Authors' Addresses 522 Ralph Droms 523 Cisco 524 1414 Massachusetts Avenue 525 Boxborough, MA 01719 526 USA 528 Phone: +1 978.936.1674 529 Email: rdroms@cisco.com 531 Pascal Thubert 532 Cisco 533 Village d'Entreprises Green Side 534 400, Avenue Roumanille 535 Biot - Sophia Antipolis 06410 536 FRANCE 538 Email: pthubert@cisco.com 540 Francis Dupont 541 ISC 543 Email: Francis.Dupont@fdupont.fr 544 Wassim Haddad 545 Ericsson 546 6210 Spine Road 547 Boulder, CO 80301 548 USA 550 Phone: +1 303.473.6963 551 Email: wmhaddad@gmail.com