idnits 2.17.00 (12 Aug 2021) /tmp/idnits20227/draft-thubert-3122bis-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 561. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3122]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC3122, but the abstract doesn't seem to directly say this. It does mention RFC3122 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3122, updated by this document, for RFC5378 checks: 1998-04-07) -- 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 23, 2008) is 4958 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) == Unused Reference: 'RFC2460' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 493, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Thubert, Ed. 3 Internet-Draft E. Levy-Abegnoli 4 Updates: 3122 (if approved) Cisco 5 Intended status: Standards Track October 23, 2008 6 Expires: April 26, 2009 8 IPv6 Inverse Neighbor Discovery Update 9 draft-thubert-3122bis-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 26, 2009. 36 Abstract 38 This draft updates the Inverse Discovery Specification [RFC3122] to 39 provide Secure Neighbor Discovery. The behaviour of the protocol is 40 slightly amended to enable an easier management of the addresses on a 41 link and enable Secure ND. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 47 2. Inverse Neighbor Discovery Messages . . . . . . . . . . . . . 4 48 2.1. Inverse Neighbor Discovery Solicitation Message . . . . . 4 49 2.2. Inverse Neighbor Discovery Advertisement Message . . . . . 5 50 3. Inverse Neighbor Discovery Options . . . . . . . . . . . . . . 7 51 3.1. Source/Target Address List . . . . . . . . . . . . . . . . 7 52 4. Secure Inverse Neighbor Discovery . . . . . . . . . . . . . . 9 53 5. Interface Type and usages . . . . . . . . . . . . . . . . . . 11 54 5.1. Point to Multipoint Networks . . . . . . . . . . . . . . . 11 55 5.2. Point-to-Point Links . . . . . . . . . . . . . . . . . . . 11 56 5.3. Broadcast Networks . . . . . . . . . . . . . . . . . . . . 12 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 63 Intellectual Property and Copyright Statements . . . . . . . . . . 14 65 1. Introduction 67 This draft updates the Inverse Neighbor Discovery Specification 68 [RFC3122]. Any behaviour or format that is not explicitely changed 69 is preserved. 71 The behaviour of the protocol is slightly amended : 73 o Secure Inverse Neighbor Discovery is added for unicast addresses 74 with a 64bit interface ID. This specification provides the 75 additional options that are required to sign Inverse ND messages 76 with the properties that are defined in [RFC3971] and details how 77 they may be used to prove the ownership of advertised addresses. 79 o Fragmentation of ND messages is accepted but not required. 80 [RFC3122] requires the use of multiple Advertisement messages when 81 the Target Address List does not fit within MTU. With this 82 specification, it is acceptable to fragment a message, but it is 83 still possible to use multiple Advertisement messages, which can 84 be necessary in particular in the context of Secure Inverse 85 Neighbor Discovery. 87 o [RFC3122] does not allow a crisp management of all Addresses that 88 a peer may use on an interface. When multiple Advertisement 89 messages are used, it is possible to miss one and thus miss some 90 information. With this specification, Address Management is 91 improved in such a way that it is possible to advertise the 92 addition or the deletion of a single address and to get the 93 exhaustive list of all the addresses that a neighbor might use to 94 source packets on an interface. 96 o With IPv4, Inverse ARP is traditionally applied to Point to 97 Multipoint networks only. [RFC3122] claims to apply to "Frame 98 Relay networks", and "also apply to other networks with similar 99 behavior". This specification extends the domain of applicability 100 of Inverse Neighbor Discovery and provides some additional 101 information on how and why Inverse ND MAY be used on all types of 102 interface. 104 o Typos such as the length field in the Source/Target Address List 105 are corrected. 107 The concept of transaction is introduced to group multiple messages 108 into a single set to enable the advertisement of the complete list of 109 all addresses used to source packets on on an interface. Whenever 110 possible, a node should use one message per transaction. 112 This is problematic when: 114 o The list of addresses is so large that it causes the message to be 115 larger than MTU and the node can not fragment. 117 o Secure Inverse ND is applied and not all of the addresses are 118 based on a same CGA modifier (see [RFC3972]). 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Inverse Neighbor Discovery Messages 128 This section updates the Inverse Neighbor Discovery Messages defined 129 in [RFC3122] section 2. 131 A new field from the ICMP reserved part is used to indicate the 132 version and preserve backward compatibility. Version 0 is [RFC3122]. 133 Version 1 is this specification. A node proposes a version in the 134 Inverse Neighbor Discovery Solicitation Message and responds with the 135 smallest of its own preferred version and the received proposed 136 version in an Advertisement. 138 Another new field from the ICMP reserved part is used to indicate the 139 Transaction ID of a Neighbor Discovery Solicitation Message, in order 140 to correlate multiple Advertisement messages that may result from one 141 Solicitation Message. A sequence number and a 'more' flag are also 142 added to enable the soliciting node to check that it actually 143 received all the Advertisement messages for a given Transaction ID. 145 2.1. Inverse Neighbor Discovery Solicitation Message 147 The Inverse Neighbor Discovery Solicitation Message can be used to 148 obtain the full list of IPv6 addresses from the remote end of a Point 149 to Point link such as a PPP link, a tunnel or a Virtual Channel. 151 The Inverse Neighbor Discovery Solicitation can also be used as a 152 heartbeat mechanism to verify whether a Point to Point link such as a 153 tunnel is still up when there is no signal from the lower layers to 154 indicate a failure. 156 The Inverse Neighbor Discovery Solicitation Message is changed as 157 follows: 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Type | Code | Checksum | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Version | Trans ID | Reserved |F| Reserved | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Options ... 167 +-+-+-+-+-+-+-+-+-+-+-+- 169 Modified Inverse Neighbor Discovery Solicitation Message 171 This specification adds the following fields: 173 Version: 8bit field. Version of 0 indicates the support of 174 [RFC3122] only. Version of 1 indicates the desire to follow this 175 specification and the backward compatibility with version 0. 177 Transaction ID: 8bit field. The Transaction ID is incremented with 178 each Inverse Neighbor Discovery Solicitation Message sent to the 179 same neighbor. The transaction ID can not be set to zero so it 180 starts at 1 and wraps from 255 directly to 1. 182 F: 1bit field. The "F" flag indicates a request of the Full List of 183 addresses on the peer side of the Link. 185 2.2. Inverse Neighbor Discovery Advertisement Message 187 The Inverse Neighbor Discovery Advertisement Message can be used as a 188 response to an Inverse Neighbor Discovery Solicitation Message or 189 asynchronously at any point of time once a first Inverse Neighbor 190 Discovery Solicitation Message was received indicating that the 191 remote peer supports this specification. 193 Multiple Inverse Neighbor Discovery Advertisement Messages might be 194 needed to report the full list of addresses. Those messages are 195 correlated by a same transaction ID and sequenced. All Messages but 196 the last have the More bit set to indicate that further Messages are 197 to be expected for that transaction. 199 An unsolicited Advertisement is used to advertise the addition or the 200 deletion of a single address and is contained in a single Inverse 201 Neighbor Discovery Advertisement Message, with a transaction ID of 0. 203 The Inverse Neighbor Discovery Advertisement Message is changed as 204 follows: 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Type | Code | Checksum | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Version | Trans ID | Sequence |F|M| Reserved | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Options ... 214 +-+-+-+-+-+-+-+-+-+-+-+- 216 Modified Inverse Neighbor Discovery Advertisement Message 218 This specification adds the following fields: 220 Sequence: 8bit field. The sequence echoes that of the last received 221 Inverse Neighbor Discovery Solicitation Message. 223 Version: 8bit field. Version of 0 indicates the support of 224 [RFC3122] only. Version of 1 indicates the desire to follow this 225 specification. Version can only be set to 1 if the Version in the 226 Solicitation Message was 1 or above. 228 Transaction ID: 8bit field. The Transaction ID echoes that of the 229 Inverse Neighbor Discovery Solicitation Message that this Message 230 is responding to. The transaction ID zero is used for unsolicited 231 Advertisements. 233 Sequence: 8bit field. The sequence is reset to zero for a new 234 transaction ID and incremented with each Advertisement Message 235 sent to a same Neighbor for a same Transaction ID. It is used to 236 detect the loss of one Inverse Neighbor Discovery Advertisement 237 Message in a Transaction that involved multiple ones. 239 M: 1bit field. The More "M" flag indicates that there are more 240 messages for that transaction ID. 242 F: 1bit field. The "F" flag indicates that the Full List of 243 addresses will be provided for that transaction. 245 Upon a request by the remote peer of the Full List of addresses, this 246 node SHOULD answer with all the addresses that can be used to reach 247 it over this link in the modified Target Address List. 249 If the IND Solicitation does not request the full list then his node 250 MAY answer with all the addresses that can be used to reach it over 251 this link in the modified Target Address List. 253 3. Inverse Neighbor Discovery Options 255 This section updates the Inverse Neighbor Discovery Options defined 256 in [RFC3122] section 3. 258 3.1. Source/Target Address List 260 With this specification, the Source/Target Address List may be 261 partial or full. It can be used to indicate addition or deletion of 262 indivisual addresses. This new support can only be used once the 263 first Inverse Neighbor Discovery Solicitation Message is received 264 from the remote peer indicating the support of this specification. 266 Until the Version that is supported by the peer is known, the only 267 Inverse Neighbor Discovery Messages that this node should send are 268 Solicitations, and this option if present can only be a Source 269 Address List option with a list of addresses that can be used to 270 reach this node over this link. 272 This specification uses a Length field of 8 bits, assuming that most 273 implementations of [RFC3122] also use a Length field of 8 bits and 274 that the misalignment in section 3.1 is commonly undestood as an 275 undetected typo. An error in reading the Length field can be 276 detected when confronting the length of the IPv6 packet and the 277 expected length of this option. 279 The Inverse Neighbor Discovery Advertisement Message is changed as 280 follows: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type | Length | Mode | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Reserved | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | 290 + + 291 | | 292 + IPv6 Address + 293 | | 294 + + 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 + + 299 | | 300 + IPv6 Address + 301 | | 302 + + 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | 306 ~ 307 | 308 +-+-+-+-+... 310 Modified Source/Target Address List option 312 This specification adds the following fields: 314 Mode 8bit enumeration 316 RFC3122: Mode of 0 indicates that the list is built conforming to 317 [RFC3122]. All the addresses listed are usable but the list 318 might not be complete. 320 Full: Mode of 1 indicates that the list might contain addresses 321 that are defined on another interface but may be used to source 322 or receive packets over this interface. This is the mode that 323 is used to in reply to a Solicitation with the "F" bit set. 325 Added: Mode of 2 indicates that the list is a list of recently 326 added addresses but not necessarily part of a full report. 328 Deleted: Mode of 3 indicates that the list is a list of recently 329 removed addresses that may no more be used on this link. 331 Upon receiving an Address List, a node should verify that the 332 addresses in the list don't collide with any of its own address. In 333 case it does, the duplicate address received in the list will be 334 ignored. 336 When Secure IND is being used, all the addresses listed in the Target 337 Address List option in one Inverse Neighbor Discovery Advertisement 338 Message must be based on the same CGA modifier. If multiple 339 modifiers are used or some addresses were not built based on CGA, 340 then they must be split in multiple Inverse Neighbor Discovery 341 Advertisement Messages. 343 4. Secure Inverse Neighbor Discovery 345 The list of addresses provided in Source/Target address list can be 346 defended using the CGA and the RSA options specified in [RFC3972] and 347 [RFC3971]. However, in the case of Secure Inverse Neighbor 348 Discovery, several addresses announced in one message (IND 349 Solicitation or Advertisement) are defended by a single CGA option 350 and a single RSA option. That mandates that all addresses in the 351 list are based on CGA and were computed with the same modifier, the 352 same collision count, and the same security parameter sec. In this 353 case, the CGA option is as following: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | | 359 + + 360 | | 361 + Modifier (16 octets) + 362 | | 363 + + 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | 367 + Subnet Prefix = 0 (8 octets) + 368 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |Col.Count = 0 | | 371 +-+-+-+-+-+-+-+-+ | 372 | | 373 ~ Public Key (variable length) ~ 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 ~ Extension Fields (optional, variable length) ~ 378 | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Since each address in the list is going to carry its own prefix (/64 382 if CGA is used), the Subnet Prefix in the CGA option is set to zero. 383 Therefore, it should not be checked by the receiver against the 384 prefix (/64 bits) of each CGA address found in the Address List. 386 The collision count is always zero, since no Duplicate Address 387 Detection is performed, other than the node ignoring peer addresses 388 colliding with one of its own. 390 The remaining of the CGA algorithm, as described in [RFC3972] 391 applies. The 16*Sec leftmost bits of Hash2 should equal zero. Hash1 392 is computed separately for each address in the list, using the first 393 64 bits as the Subnet Prefix, and the interface identifier should 394 match Hash1 (except for bits 0, 1, 2, 6, and 7, which encode the 395 collision count and the "u" and "g" bits). 397 The RSA option must also be provided in the message, and the 398 signature must verify with the public key provided in the CGA option 400 In order to protect against replays, Timestamp and Nonce options, 401 should also be used in the message, with similar rules as one 402 described in [RFC3971]. When the message is a solicitation (INS), it 403 should have a nonce option. When the message is sollicited (INA as a 404 response to INS), it should repeat the nonce value seen in the 405 solicitation. As far as unsolicited message and solicitation, the 406 timestamp option is required. 408 5. Interface Type and usages 410 Because of IPv4 and the ARP legacy, Inverse Neighbor Discovery is 411 usually associated to Point to Multipoint (P2MP) or Non-Broadcast 412 Multi-Access (NBMA) networks. And certainly, this specification is 413 usable on such networks as Frame Relay or Multidrop tunnels. 415 But the similarity with IPv4 is limited and this specification 416 enables a lot more: 418 5.1. Point to Multipoint Networks 420 IPv6 Secure Inverse Neighbor Discovery can be applied to P2MP and 421 NBMA networks to prevent the theft an address by another Node. 423 5.2. Point-to-Point Links 425 As opposed to IPv4, using Inverse Neighbor Discovery makes a lot of 426 sense on Point-to-Point link such as PPP or tunnels: 428 This specification inherits from [RFC3122] the support of the 429 authentication header to authenticate the remote peer on the link. 430 For P2P links, this might prove more relevant than Secure ND itself. 432 Because IPv6 operates purely at layer 3, the PPP Network Control 433 Protocol for IPv6 defined in [RFC5072] provides a way to negotiate a 434 unique, 64bit interface identifier to be used for the address 435 autoconfiguration but does not enable to advertise an IPv6 address. 436 This would not fit anyway since IPv6 might use many addresses of 437 various lifetimes on a same interface. This specification provides 438 the means to create and maintain the list of addresses that can be 439 used to reach the remote peer at any point of time. 441 A number of Denial of Service attacks are documented when using 442 [RFC4861] by sending packets to addresses that are not assigned but 443 belong to a prefix that is associated to the P2P link. On those 444 links, Inverse Neighbor Discovery enables a proactive model that 445 defeats those attacks. Any packet that is received for a destination 446 that is not in the ND table is simply dropped. 448 5.3. Broadcast Networks 450 A multihomed host attached to a broadcast network might use an 451 address that belongs to another interface on another subnet to source 452 a packet. This makes the validation of source addresses very 453 problematic. With this specification, a router may solicit the full 454 list of all addreses that this host might use to source packets on 455 that interface, and prove the ownership using SeND. The router might 456 then accept packets that are sourced off-link and may install a host 457 route to that address. 459 6. IANA Considerations 461 This memo includes no request to IANA. 463 7. Security Considerations 465 This draft improves the security model in [RFC3122] by adding the 466 capability to use Secure Neighbor Discovery 468 8. References 470 8.1. Normative References 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 476 (IPv6) Specification", RFC 2460, December 1998. 478 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 479 Inverse Discovery Specification", RFC 3122, June 2001. 481 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 482 Neighbor Discovery (SEND)", RFC 3971, March 2005. 484 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 485 RFC 3972, March 2005. 487 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 488 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 489 September 2007. 491 8.2. Informative References 493 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 494 June 1999. 496 [RFC5072] S.Varada, Haskin, D., and E. Allen, "IP Version 6 over 497 PPP", RFC 5072, September 2007. 499 Authors' Addresses 501 Pascal Thubert (editor) 502 Cisco Systems 503 Village d'Entreprises Green Side 504 400, Avenue de Roumanille 505 Batiment T3 506 Biot - Sophia Antipolis 06410 507 FRANCE 509 Phone: +33 4 97 23 26 34 510 Email: pthubert@cisco.com 512 Eric Levy-Abegnoli 513 Cisco Systems 514 Village d'Entreprises Green Side 515 400, Avenue de Roumanille 516 Batiment T3 517 Biot - Sophia Antipolis 06410 518 FRANCE 520 Phone: +33 4 97 23 26 20 521 Email: elevyabe@cisco.com 523 Full Copyright Statement 525 Copyright (C) The IETF Trust (2008). 527 This document is subject to the rights, licenses and restrictions 528 contained in BCP 78, and except as set forth therein, the authors 529 retain all their rights. 531 This document and the information contained herein are provided on an 532 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 533 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 534 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 535 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 536 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 537 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 539 Intellectual Property 541 The IETF takes no position regarding the validity or scope of any 542 Intellectual Property Rights or other rights that might be claimed to 543 pertain to the implementation or use of the technology described in 544 this document or the extent to which any license under such rights 545 might or might not be available; nor does it represent that it has 546 made any independent effort to identify any such rights. Information 547 on the procedures with respect to rights in RFC documents can be 548 found in BCP 78 and BCP 79. 550 Copies of IPR disclosures made to the IETF Secretariat and any 551 assurances of licenses to be made available, or the result of an 552 attempt made to obtain a general license or permission for the use of 553 such proprietary rights by implementers or users of this 554 specification can be obtained from the IETF on-line IPR repository at 555 http://www.ietf.org/ipr. 557 The IETF invites any interested party to bring to its attention any 558 copyrights, patents or patent applications, or other proprietary 559 rights that may cover technology that may be required to implement 560 this standard. Please address the information to the IETF at 561 ietf-ipr@ietf.org.