idnits 2.17.1 draft-ietf-mext-nemo-pd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 560. 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 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 (November 3, 2008) is 5625 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) ** 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-02 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IPv6 Extensions Group R. Droms 3 Internet-Draft P. Thubert 4 Intended status: Standards Track Cisco 5 Expires: May 7, 2009 F. Dupont 6 ISC 7 W. Haddad 8 Qualcomm 9 November 3, 2008 11 DHCPv6 Prefix Delegation for NEMO 12 draft-ietf-mext-nemo-pd-01 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 7, 2009. 39 Abstract 41 One aspect of network mobility support is the assignment of a prefix 42 or prefixes to a Mobile Router (MR) for use on the links in the 43 Mobile Network. DHCPv6 prefix delegation can be used for this 44 configuration task. 46 1. Introduction 48 One aspect of network mobility support is the assignment of a prefix 49 or prefixes to a Mobile Router for use on the links in the Mobile 50 Network. DHCPv6 prefix delegation [RFC3633] (DHCPv6PD) can be used 51 for this configuration task. 53 2. Terminology 55 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 56 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 57 interpreted as described in RFC2119 [RFC2119]. 59 The following terms used in this document are defined in the IPv6 60 Addressing Architecture document [RFC4291]: 61 link-local unicast address 62 link-local scope multicast address 64 The following terms used in this document are defined in the mobile 65 IPv6 specification [RFC3775]: 66 home agent (HA) 67 home link 69 The following terms used in this document are defined in the Mobile 70 Network terminology document [RFC4886]: 71 Mobile Router (MR) 72 Mobile Network 73 mobile host (MH) 75 The following terms used in this document are defined in the DHCPv6 76 [RFC3315] and DHCPv6 prefix delegation [RFC3633] specifications: 77 delegating router (DR; acts as a DHCPv6 server) 78 requesting router (RR; acts as a DHCPv6 client) 79 DHCPv6 relay agent 81 The following acronym is used in this document: 82 DHCPv6PD: DHCPv6 prefix delegation 84 3. Application of DHCPv6 prefix delegation to mobile networks for 85 delegation of home prefixes 87 The NEMO Basic protocol [RFC3963] extends the mobile IPv6 protocol 88 [RFC3775] to enable network mobility. In this extension, a MR uses 89 the mobile IPv6 protocol to establish and maintain a session with its 90 HA, and uses bidirectional tunneling between the MR and HA to provide 91 a path through which nodes attached to links in the Mobile Network 92 can maintain connectivity with nodes not in the Mobile Network. 94 The requirements for NEMO [RFC4885] include the ability of the MR to 95 receive delegated prefixes that can then be assigned to links in the 96 Mobile Network. DHCPv6PD can be used to meet this requirement for 97 prefix delegation. 99 To use DHCPv6PD for Mobile Networks, the HA assumes the role of 100 either the DR or a DHCPv6 relay agent and the MR assumes the role of 101 the RR. Throughout the remainder of this document, the HA will be 102 assumed to be acting as a DHCPv6PD DR or relay agent and the MR will 103 be assumed to be acting as a RR. 105 If the HA is acting as relay agent, some other device acts as the DR. 106 For example, the server providing DHCPv6 service in the home network 107 might also provide NEMO DHCPv6PD service. Or, a home network with 108 several HAs might configure one of those HAs as a DHCPv6PD server 109 while the other HAs act as relay agents. 111 The HA and MR exchange DHCPv6PD protocol messages through the tunnel 112 connecting them. The tunnel acts as the link labeled "DSL to 113 subscriber premises" in figure 1 of the DHCPv6PD specification. 115 The DHCPv6PD server is provisioned with prefixes to be assigned using 116 any of the prefix assignment mechanisms described in the DHCPv6PD 117 specifications. Other updates to the HA data structures required as 118 a side effect of prefix delegation are specified by the particular 119 network mobility protocol. For example, in the case of Basic Network 120 Mobility Support [RFC3963], the HA would add an entry in its binding 121 cache registering the delegated prefix to the MR to which the prefix 122 was delegated. 124 3.1. When the MR uses DHCPv6 126 The MR initiates a DHCPv6 message exchange for prefix delegation 127 whenever it establishes an MR-HA tunnel to its HA. If the MR does 128 not have any active delegated prefixes (with unexpired leases), the 129 MR initiates a DHCPv6 message exchange with a DHCPv6 Solicit message 130 as described in section 17 of RFC 3315 and section 12.1 of RFC 3633. 131 If the MR has one or more active delegated prefixes, the MR initiates 132 a DHCPv6 message exchange with a DHCPv6 Rebind message as described 133 in section 18.1.2 of RFC 3315 and section 12.1 of RFC 3633. 135 3.2. Use of MR-HA tunnel for DHCPv6 messages 137 The DHCPv6 specification requires the use of link-local unicast and 138 link-local scope multicast addresses in DHCPv6 messages (except in 139 certain cases as defined in section 22.12 of the DHCPv6 140 specification). Section 10.4.2 of the mobile IPv6 specification 141 describes forwarding of intercepted packets, and the third paragraph 142 of that section begins: 144 However, packets addressed to the mobile node's link-local address 145 MUST NOT be tunneled to the mobile node. 147 The DHCPv6 messages exchanged between the HA and the MR originate 148 only with the HA and the MR, and therefore are not "intercepted 149 packets" and may be sent between the HA and the MR through the 150 tunnel. 152 Even though the MR-HA tunnel is a point to point connection, the MR 153 SHOULD use multicast DHCPv6 messages as described in RFC 3315 over 154 that tunnel. 156 3.3. DHCPv6 Relay Agent for transmission of DHCPv6 messages 158 A DHPCv6 relay agent function [RFC3315] can be used as an alternative 159 to multicast DHCPv6 messages over the tunnel between the MR and the 160 HA. In this configuration, the relay agent function is co-located in 161 the MR with the DHCPv6 client function. Rather than using multicast 162 to send DHCPv6 messages through the tunnel to the DHCPv6 server, the 163 DHCPv6 client in the MR hands any outbound DHCPv6 messages to the co- 164 located relay agent. Responses from the DHCPv6 server are delivered 165 to the relay agent function in the MR, which extracts the 166 encapsulated message and delivers it to the DHCPv6 client in the MR. 168 3.3.1. Relay agent configuration 170 The use of the relay agent function in the MR allows the MR to 171 unicast DHCPv6 messages to the DHCPv6 server. The relay agent must 172 be configured with the address of the DHCPv6 server or another DHCPv6 173 relay agent that will forward message on to a DHCPv6 server. For the 174 purposes of NEMO, the relay agent assumes that the HA for the MR 175 hosts the next hop in the path the to the DHCPv6 server: either the 176 DHCPv6 server or a relay agent that will forward message to the 177 DHCPv6 server. Therefore, if the MR acts as a DHCPv6 relay agent, 178 the MR MUST configure the DHCPv6 relay agent to forward DHCPv6 179 messages to the HA. 181 3.3.2. Transmission of DHCPv6 messages 183 In this configuration, when the DHCPv6 client in the MR sends a 184 message, it hands the message to the DHCPv6 relay agent in the MR. 185 The way in which this handoff takes place is beyond the scope of this 186 document. The relay agent encapsulates the message from the client 187 according to RFC 3315 in a Relay-forward message and sends the 188 resulting DHCPv6 message to the HA. The relay agent sets the fields 189 in the Relay-forward message as follows: 190 msg-type RELAY-FORW 191 hop-count 1 192 link-address A non-link-local address from the MR interface to the 193 tunnel between the HA and MR 194 peer-address A non-link-local address from the MR interface to the 195 tunnel between the HA and MR 196 options MUST include a "Relay Message option" [RFC3315]; MAY 197 include other options added by the relay agent. 199 3.3.3. Receipt of DHCPv6 messages 201 In this configuration, messages from the DHCPv6 server will be 202 returned to the DHCPv6 relay agent, with the message for the DHCPv6 203 client encapsulated in the Relay Message option [RFC3315] in a Relay- 204 reply message. The relay agent function extracts the message for the 205 client from the Relay Message option and hands the message to the 206 DHCPv6 client in the MR. The way in which this handoff takes place 207 is beyond the scope of this document. 209 3.4. Exchanging DHCPv6 messages when MR is at home 211 When the MR is on its home link, the HA uses the home link to 212 exchange DHCPv6PD messages with the MR. It is the responsibility of 213 the implementation to determine when the MR is on its home link and 214 to avoid use of any existing tunnel. 216 3.5. Minimizing DHCPv6PD messages 218 DHCPv6PD in a Mobile Network can be combined with the Rapid Commit 219 option [RFC3315] to provide DHCPv6 prefix delegation with a two 220 message exchange between the mobile node and the DHCPv6PD DR. 222 3.6. DHCPv6PD and DHAAD 224 The MR acting as RR needs a direct link to the DR (or relay) 225 function. When the MR is away from Home, that link is the MR-HA 226 tunnel. If a MR needs to obtain a prefix by means of DHCPv6PD, it 227 has to locate a HA that is capable of serving either as a DHCPv6PD 228 relay agent or server. Since the use of DHCPv6PD is optional and 229 comes as an addition to existing protocols RFC 3775 and RFC 3963, it 230 can not be expected that all HAs are DHCPv6PD capable. 232 This specification extends Dynamic Home Agent Address Discovery and 233 the Home Agent Information Option in order to enable the detection by 234 a MR of all HAs that are DHCPv6PD capable. A new 'D' bit is 235 introduced to let Home Agents advertise that they are willing to 236 participate to DHCP. Note that there is no direct way for the MR 237 acting as RR to know whether a HA is actually a DR or simply acting 238 as a relay. 240 3.6.1. Modified Dynamic Home Agent Address Discovery Request 242 A new flag (D) (Support for DHCPv6PD) is introduced in the DHAAD 243 Request message, defined in RFC 3775 and RFC 3963. The Mobile Router 244 sets this flag to indicate that it wants to discover Home Agents 245 participating to DHCPv6 Prefix Delegation. 247 A the MR which sets the 'D' flag MUST also set the 'R' flag, to 248 declare that it is a Mobile Router and asks for a HA that supports 249 Mobile Routers, as defined in RFC 3963. 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type | Code | Checksum | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Identifier |R|D| Reserved | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 DHCPv6PD Support Flag (D) 261 A one-bit flag that when set indicates that the Mobile Router 262 wants to discover Home Agents participating to DHCPv6 Prefix 263 Delegation. 265 For a description of the other fields in the message, see RFC 3775 266 and RFC 3963. 268 3.6.2. Modified Dynamic Home Agent Address Discovery Reply 270 A new flag (D) (Support for DHCPv6PD) is introduced in the DHAAD 271 Reply message, defined in RFC 3775 and RFC 3963. If a Home Agent 272 receives a Dynamic Home Agent Discovery request message with the 273 DHCPv6PD Support Flag set, it MUST include a list of Home Agents 274 participating to DHCPv6PD to any replies. 276 The DHCPv6PD Support Flag MUST be set if there is at least one Home 277 Agent participating to DHCPv6PD. In that case, the reply will list 278 only those HAs that participate to DHCPv6PD, whether they act as 279 servers (DRs) or relays. 281 A HA that supports DHCPv6PD MUST support Mobile Routers as well, so 282 if the 'D' bit is set, then the 'R' bit should be set as well. So 283 there is no need in an implementation to support the case where some 284 HAs would support Mobile Routers while others would be participating 285 to DHCPv6 Prefix Delegation but none could do both. 287 If none of the Home Agents support DHCPv6PD, the Home Agent MAY reply 288 with a list of Home Agents that only support NEMO basic Mobile 289 Routers or Mobile IPv6 Mobile Nodes. In this case, the DHCPv6PD 290 Support Flag MUST be set to 0. 292 The modified message format is as follows. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Code | Checksum | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Identifier |R|D| Reserved | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 + + 303 + + 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 DHCPv6PD Support Flag (D) 309 A one-bit flag that when set indicates that the Home Agents 310 listed in this message participate to DHCPv6 Prefix Delegation. 312 For a description of the other fields in the message, see RFC 3775 313 and RFC 3963. 315 3.6.3. Modified Home Agent Information Option 317 A new flag (D) (Support for DHCPv6PD) is introduced in the Home Agent 318 Information Option defined in RFC 3775 and RFC 3963. 320 If a Home Agent participates to DHCPv6PD, it SHOULD set the flag. If 321 the HA sets the 'D' flag, then it MUST also set the 'R' flag, 322 Indicating that it supports Mobile Routers, as defined in RFC 3963. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type | Length |R|D| Reserved | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Home Agent Preference | Home Agent Lifetime | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 DHCPv6PD Support Flag (D) 334 A one-bit flag that when set indicates that the Home Agents 335 participates to DHCPv6 Prefix Delegation. 337 For a description of the other fields in the message, see RFC 3775 338 and RFC 3963. 340 3.7. Location of DHCPv6PD Delegating Router function 342 Support of DHCPv6PD for a Mobile Network is optional. 344 The use of a DHCPv6 relay agent in DHCPv6PD may require "a protocol 345 or other out-of-band communication to add routing information for 346 delegated prefixes into the provider edge router" (section 14 of RFC 347 3633). If the DHCPv6PD DR function is implemented in the HA for the 348 MR, no relay agent function is required. 350 It may be desirable to use a single DR to manage RRs in a network 351 with multiple HAs. In this scenario, the HAs will act as DHCP relay 352 agents, forwarding messages between the RRs and the DR. 354 Use of the DHCPv6 relay agent function with DHCPv6PD requires that 355 there be some mechanism through which routing information for the 356 delegated prefixes can be added to the appropriate routing 357 infrastructure. If the HA is acting as a DHCPv6 relay agent, the HA 358 SHOULD add a route to the delegated prefix and advertise that route 359 after receiving a binding update for the prefix from the RR 360 [RFC3963]. 362 In particular, if the MR uses NEMO explicit mode, then it must add 363 the delegated prefix to the prefix list in the Binding Update 364 messages. If the binding cache is cleared before the prefix valid 365 lifetime, the MR might bind that prefix again using explicit mode, 366 till the lifetime expires. 368 In implicit mode, the HA must save the delegated prefix with the 369 binding cache entry (BDE) of the Mobile Router. When the BCE is 370 cleared, the HA loses the information about the delegated prefix. 371 Because the MR will use DHCPv6 when it reestablishes its tunnel to 372 the HA (see Section 3.1), the HA will be able to add the delegated 373 prefix back to the BCE. 375 At the time this draft was written, one way in which a DR can 376 explicitly notify a relay agent about delegated prefixes, is to use 377 the "DHCP Relay Agent Assignment Notification Option" 378 [I-D.ietf-dhc-dhcpv6-agentopt-delegate]. 380 Another alternative, if the RR is part of the same administrative 381 domain as the home network to which it is attached through the HA, 382 and the RR can be trusted, the RR can use a routing protocol like 383 OSPF to advertise any delegated prefixes. 385 NEMO explicit mode is recommended to take advantage of the function 386 already defined for NEMO. 388 3.8. Other DHCPv6 functions 390 The DHCPv6 messages exchanged between the MR and the HA may also be 391 used for other DHCPv6 functions in addition to DHCPv6PD. For 392 example, the HA may assign global addresses to the MR and may pass 393 other configuration information such as a list of available DNS 394 recursive name servers [RFC3646] to the MR using the same DHCPv6 395 messages as used for DHCPV6PD. 397 The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR 398 for MRs. 400 4. Changes in this draft 402 This document is based on draft-ietf-nemo-dhcpv6-pd-03 and includes 403 the use of the DHCPv6 relay agent in the MR, as described in 404 Section 3.3, from draft-dupont-mext-dhcrelay-00. 406 5. Security Considerations 408 This document describes the use of DHCPv6 for prefix delegation in 409 Mobile Networks. It does not introduce any additional security 410 considerations for DHCPv6 beyond those described in the "Security 411 Considerations" section of the DHCPv6 base specification [RFC3315] 412 and the "Security Considerations" of the DHCPv6 Prefix Delegation 413 specification [RFC3633]. 415 The use of DHCPv6, as described in this document, requires only 416 message integrity protection, which can be provided by the mobile 417 network infrastructure between the MR and the HA. 419 If the network infrastructure connecting the various communicating 420 nodes does not provide message integrity and source authentication 421 for the DHCPv6PD messages, HAs and MRs SHOULD use DHCPv6 422 authentication as described in section "Authentication of DHCP 423 messages" of the DHCPv6 specification [RFC3315], to guard against 424 attacks mounted through prefix delegation. 426 If the HA and DHCPv6 PD functions are not provided by the same 427 physical node, the HA will act as a DHCPv6 relay agent between the MR 428 and the DHCPv6 server. In this scenario, the mobile network 429 infrastructure will only protect the DHCPv6 traffic between the RR 430 (MR) and the relay agent (HA). Section 21.1 of RFC 3315 describes 431 how appropriate security can be provided between a DHCPv6 relay agent 432 and server. 434 6. IANA Considerations 436 This document describes the use of DHCPv6 for prefix delegation in 437 Mobile Networks. It does not introduce any additional IANA 438 considerations. 440 7. Change Log 442 This section MUST be removed before this document is published as an 443 RFC. 445 7.1. Revision -01 447 Added detail in "Security Considerations" describing protection 448 required for DHCPv6 and a mechanism for protecting traffic between 449 the DHCPv6 relay agent and server. 451 8. References 453 8.1. Normative References 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, March 1997. 458 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 459 and M. Carney, "Dynamic Host Configuration Protocol for 460 IPv6 (DHCPv6)", RFC 3315, July 2003. 462 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 463 Host Configuration Protocol (DHCP) version 6", RFC 3633, 464 December 2003. 466 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 467 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 468 December 2003. 470 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 471 in IPv6", RFC 3775, June 2004. 473 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 474 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 475 RFC 3963, January 2005. 477 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 478 Architecture", RFC 4291, February 2006. 480 8.2. Informative References 482 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 483 Terminology", RFC 4885, July 2007. 485 [RFC4886] Ernst, T., "Network Mobility Support Goals and 486 Requirements", RFC 4886, July 2007. 488 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] 489 Droms, R., "DHCPv6 Relay Agent Assignment Notification 490 (RAAN) Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-02 491 (work in progress), November 2006. 493 Authors' Addresses 495 Ralph Droms 496 Cisco 497 1414 Massachusetts Avenue 498 Boxborough, MA 01719 499 USA 501 Phone: +1 978.936.1674 502 Email: rdroms@cisco.com 503 Pascal Thubert 504 Cisco 505 Village d'Entreprises Green Side 506 400, Avenue Roumanille 507 Biot - Sophia Antipolis 06410 508 FRANCE 510 Email: pthubert@cisco.com 512 Francis Dupont 513 ISC 515 Email: Francis.Dupont@fdupont.fr 517 Wassim Haddad 518 Qualcomm 520 Email: whaddad@qualcomm.com 522 Full Copyright Statement 524 Copyright (C) The IETF Trust (2008). 526 This document is subject to the rights, licenses and restrictions 527 contained in BCP 78, and except as set forth therein, the authors 528 retain all their rights. 530 This document and the information contained herein are provided on an 531 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 532 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 533 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 534 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 535 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 536 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 538 Intellectual Property 540 The IETF takes no position regarding the validity or scope of any 541 Intellectual Property Rights or other rights that might be claimed to 542 pertain to the implementation or use of the technology described in 543 this document or the extent to which any license under such rights 544 might or might not be available; nor does it represent that it has 545 made any independent effort to identify any such rights. Information 546 on the procedures with respect to rights in RFC documents can be 547 found in BCP 78 and BCP 79. 549 Copies of IPR disclosures made to the IETF Secretariat and any 550 assurances of licenses to be made available, or the result of an 551 attempt made to obtain a general license or permission for the use of 552 such proprietary rights by implementers or users of this 553 specification can be obtained from the IETF on-line IPR repository at 554 http://www.ietf.org/ipr. 556 The IETF invites any interested party to bring to its attention any 557 copyrights, patents or patent applications, or other proprietary 558 rights that may cover technology that may be required to implement 559 this standard. Please address the information to the IETF at 560 ietf-ipr@ietf.org.