idnits 2.17.1 draft-thubert-3122bis-01.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.ii 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 : ---------------------------------------------------------------------------- ** 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 and authors 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 27, 2009) is 5536 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 491, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 509, 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 (==), 4 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 February 27, 2009 6 Expires: August 31, 2009 8 IPv6 Inverse Neighbor Discovery Update 9 draft-thubert-3122bis-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 31, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This draft updates the Inverse Discovery Specification [RFC3122] to 58 provide Secure Neighbor Discovery. The behaviour of the protocol is 59 slightly amended to enable an easier management of the addresses on a 60 link and enable Secure ND. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2. Inverse Neighbor Discovery Messages . . . . . . . . . . . . . 4 67 2.1. Inverse Neighbor Discovery Solicitation Message . . . . . 4 68 2.2. Inverse Neighbor Discovery Advertisement Message . . . . . 5 69 3. Inverse Neighbor Discovery Options . . . . . . . . . . . . . . 6 70 3.1. Source/Target Address List . . . . . . . . . . . . . . . . 7 71 4. Secure Inverse Neighbor Discovery . . . . . . . . . . . . . . 9 72 5. Interface Type and usages . . . . . . . . . . . . . . . . . . 11 73 5.1. Point to Multipoint Networks . . . . . . . . . . . . . . . 11 74 5.2. Point-to-Point Links . . . . . . . . . . . . . . . . . . . 11 75 5.3. Broadcast Networks . . . . . . . . . . . . . . . . . . . . 12 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 This draft updates the Inverse Neighbor Discovery Specification 87 [RFC3122]. Any behaviour or format that is not explicitely changed 88 is preserved. 90 The behaviour of the protocol is slightly amended : 92 o Secure Inverse Neighbor Discovery is added for unicast addresses 93 with a 64bit interface ID. This specification provides the 94 additional options that are required to sign Inverse ND messages 95 with the properties that are defined in [RFC3971] and details how 96 they may be used to prove the ownership of advertised addresses. 98 o Fragmentation of ND messages is accepted but not required. 99 [RFC3122] requires the use of multiple Advertisement messages when 100 the Target Address List does not fit within MTU. With this 101 specification, it is acceptable to fragment a message, but it is 102 still possible to use multiple Advertisement messages, which can 103 be necessary in particular in the context of Secure Inverse 104 Neighbor Discovery. 106 o [RFC3122] does not allow a crisp management of all Addresses that 107 a peer may use on an interface. When multiple Advertisement 108 messages are used, it is possible to miss one and thus miss some 109 information. With this specification, Address Management is 110 improved in such a way that it is possible to advertise the 111 addition or the deletion of a single address and to get the 112 exhaustive list of all the addresses that a neighbor might use to 113 source packets on an interface. 115 o With IPv4, Inverse ARP is traditionally applied to Point to 116 Multipoint networks only. [RFC3122] claims to apply to "Frame 117 Relay networks", and "also apply to other networks with similar 118 behavior". This specification extends the domain of applicability 119 of Inverse Neighbor Discovery and provides some additional 120 information on how and why Inverse ND MAY be used on all types of 121 interface. 123 o Typos such as the length field in the Source/Target Address List 124 are corrected. 126 The concept of transaction is introduced to group multiple messages 127 into a single set to enable the advertisement of the complete list of 128 all addresses used to source packets on on an interface. Whenever 129 possible, a node should use one message per transaction. 131 This is problematic when: 133 o The list of addresses is so large that it causes the message to be 134 larger than MTU and the node can not fragment. 136 o Secure Inverse ND is applied and not all of the addresses are 137 based on a same CGA modifier (see [RFC3972]). 139 1.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 2. Inverse Neighbor Discovery Messages 147 This section updates the Inverse Neighbor Discovery Messages defined 148 in [RFC3122] section 2. 150 A new field from the ICMP reserved part is used to indicate the 151 version and preserve backward compatibility. Version 0 is [RFC3122]. 152 Version 1 is this specification. A node proposes a version in the 153 Inverse Neighbor Discovery Solicitation Message and responds with the 154 smallest of its own preferred version and the received proposed 155 version in an Advertisement. 157 Another new field from the ICMP reserved part is used to indicate the 158 Transaction ID of a Neighbor Discovery Solicitation Message, in order 159 to correlate multiple Advertisement messages that may result from one 160 Solicitation Message. When the information about an address is not 161 seen after 2 consecutive advertisement of a full List of addresses 162 that address is considered as removed. This decision is made upon 163 the reception of an advertisement with a Transaction ID that is 164 sequentially later then the 2 consecutive advertisements. 166 2.1. Inverse Neighbor Discovery Solicitation Message 168 The Inverse Neighbor Discovery Solicitation Message can be used to 169 obtain the full list of IPv6 addresses from the remote end of a Point 170 to Point link such as a PPP link, a tunnel or a Virtual Channel. 172 The Inverse Neighbor Discovery Solicitation can also be used as a 173 heartbeat mechanism to verify whether a Point to Point link such as a 174 tunnel is still up when there is no signal from the lower layers to 175 indicate a failure. 177 The Inverse Neighbor Discovery Solicitation Message is changed as 178 follows: 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type | Code | Checksum | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Version | Trans ID | Reserved |F| Reserved | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Options ... 188 +-+-+-+-+-+-+-+-+-+-+-+- 190 Modified Inverse Neighbor Discovery Solicitation Message 192 This specification adds the following fields: 194 Type: 8bit field. Inverse Neighbor Discovery Solicitation. 196 Version: 8bit field. Version of 0 indicates the support of 197 [RFC3122] only. Version of 1 indicates the desire to follow this 198 specification and the backward compatibility with version 0. 200 Transaction ID: 8bit field. The Transaction ID is incremented with 201 each Inverse Neighbor Discovery Solicitation Message sent to the 202 same neighbor. The transaction ID can not be set to zero so it 203 starts at 1 and wraps from 255 directly to 1. 205 F: 1bit field. The "F" flag indicates a request of the Full List of 206 addresses on the peer side of the Link. 208 2.2. Inverse Neighbor Discovery Advertisement Message 210 The Inverse Neighbor Discovery Advertisement Message can be used as a 211 response to an Inverse Neighbor Discovery Solicitation Message or 212 asynchronously at any point of time once a first Inverse Neighbor 213 Discovery Solicitation Message was received indicating that the 214 remote peer supports this specification. 216 Multiple Inverse Neighbor Discovery Advertisement Messages might be 217 needed to report the full list of addresses. Those messages are 218 correlated by a same transaction ID. 220 An unsolicited Advertisement is used to advertise the addition or the 221 deletion of a single address and is contained in a single Inverse 222 Neighbor Discovery Advertisement Message, with a transaction ID of 0. 224 The Inverse Neighbor Discovery Advertisement Message is changed as 225 follows: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type | Code | Checksum | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Version | Trans ID | Reserved |F| Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Options ... 235 +-+-+-+-+-+-+-+-+-+-+-+- 237 Modified Inverse Neighbor Discovery Advertisement Message 239 This specification adds the following fields: 241 Type: 8bit field. Inverse Neighbor Discovery Advertisement. 243 Version: 8bit field. Version of 0 indicates the support of 244 [RFC3122] only. Version of 1 indicates the desire to follow this 245 specification. Version can only be set to 1 if the Version in the 246 Solicitation Message was 1 or above. 248 Transaction ID: 8bit field. The Transaction ID echoes that of the 249 Inverse Neighbor Discovery Solicitation Message that this Message 250 is responding to. The transaction ID zero is used for unsolicited 251 Advertisements. 253 F: 1bit field. The "F" flag indicates that the Full List of 254 addresses will be provided for that transaction. 256 Upon a request by the remote peer of the Full List of addresses, this 257 node SHOULD answer with all the addresses that can be used to reach 258 it over this link in the modified Target Address List. 260 If the IND Solicitation does not request the full list then his node 261 MAY answer with all the addresses that can be used to reach it over 262 this link in the modified Target Address List. 264 3. Inverse Neighbor Discovery Options 266 This section updates the Inverse Neighbor Discovery Options defined 267 in [RFC3122] section 3. 269 3.1. Source/Target Address List 271 With this specification, the Source/Target Address List may be 272 partial or full. It can be used to indicate addition or deletion of 273 individual addresses. This new support can only be used once the 274 first Inverse Neighbor Discovery Solicitation Message is received 275 from the remote peer indicating the support of this specification. 277 Until the Version that is supported by the peer is known, the only 278 Inverse Neighbor Discovery Messages that this node should send are 279 Solicitations, and this option if present can only be a Source 280 Address List option with a list of addresses that can be used to 281 reach this node over this link. 283 This specification uses a Length field of 8 bits, assuming that most 284 implementations of [RFC3122] also use a Length field of 8 bits and 285 that the misalignment in section 3.1 is commonly undestood as an 286 undetected typo. An error in reading the Length field can be 287 detected when confronting the length of the IPv6 packet and the 288 expected length of this option. 290 The Inverse Neighbor Discovery Advertisement Message is changed as 291 follows: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type | Length | Mode | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Reserved | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 + + 302 | | 303 + IPv6 Address + 304 | | 305 + + 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 + + 310 | | 311 + IPv6 Address + 312 | | 313 + + 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | 317 ~ 318 | 319 +-+-+-+-+... 321 Modified Source/Target Address List option 323 This specification adds the following fields: 325 Mode 8bit enumeration 327 RFC3122: Mode of 0 indicates that the list is built conforming to 328 [RFC3122]. All the addresses listed are usable but the list 329 might not be complete. 331 Full: Mode of 1 indicates that the list might contain addresses 332 that are defined on another interface but may be used to source 333 or receive packets over this interface. This is the mode that 334 is used to in reply to a Solicitation with the "F" bit set. 336 Added: Mode of 2 indicates that the list is a list of recently 337 added addresses but not necessarily part of a full report. 339 Deleted: Mode of 3 indicates that the list is a list of recently 340 removed addresses that may no more be used on this link. 342 Upon receiving an Address List, a node should verify that the 343 addresses in the list don't collide with any of its own address. In 344 case it does, the duplicate address received in the list will be 345 ignored. 347 When Secure IND is being used, all the addresses listed in the Target 348 Address List option in one Inverse Neighbor Discovery Advertisement 349 Message must be based on the same CGA modifier. If multiple 350 modifiers are used or some addresses were not built based on CGA, 351 then they must be split in multiple Inverse Neighbor Discovery 352 Advertisement Messages. 354 4. Secure Inverse Neighbor Discovery 356 The list of addresses provided in Source/Target address list can be 357 defended using the CGA and the RSA options specified in [RFC3972] and 358 [RFC3971]. However, in the case of Secure Inverse Neighbor 359 Discovery, several addresses announced in one message (IND 360 Solicitation or Advertisement) are defended by a single CGA option 361 and a single RSA option. T hat mandates that all addresses in the 362 list are based on CGA and were computed with the same public key, 363 modifier, collision count, and the same security parameter sec. In 364 this case, the CGA option is as following: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | | 370 + + 371 | | 372 + Modifier (16 octets) + 373 | | 374 + + 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 + Subnet Prefix = 0 (8 octets) + 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 |Col.Count = 0 | | 382 +-+-+-+-+-+-+-+-+ | 383 | | 384 ~ Public Key (variable length) ~ 385 | | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | | 388 ~ Extension Fields (optional, variable length) ~ 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Since each address in the list is going to carry its own prefix (/64 393 if CGA is used), the Subnet Prefix in the CGA option is set to zero. 394 Therefore, it should not be checked by the receiver against the 395 prefix (/64 bits) of each CGA address found in the Address List. 397 The collision count is always zero, since no Duplicate Address 398 Detection is performed, other than the node ignoring peer addresses 399 colliding with one of its own. 401 The remaining of the CGA algorithm, as described in [RFC3972] 402 applies. The 16*Sec leftmost bits of Hash2 should equal zero. Hash1 403 is computed separately for each address in the list, using the first 404 64 bits as the Subnet Prefix, and the interface identifier should 405 match Hash1 (except for bits 0, 1, 2, 6, and 7, which encode the 406 collision count and the "u" and "g" bits). 408 The RSA option must also be provided in the message, and the 409 signature must verify with the public key provided in the CGA option 411 In order to protect against replays, Timestamp and Nonce options, 412 should also be used in the message, with similar rules as one 413 described in [RFC3971]. When the message is a solicitation (INS), it 414 should have a nonce option. When the message is sollicited (INA as a 415 response to INS), it should repeat the nonce value seen in the 416 solicitation. As far as unsolicited message and solicitation, the 417 timestamp option is required. 419 5. Interface Type and usages 421 Because of IPv4 and the ARP legacy, Inverse Neighbor Discovery is 422 usually associated to Point to Multipoint (P2MP) or Non-Broadcast 423 Multi-Access (NBMA) networks. And certainly, this specification is 424 usable on such networks as Frame Relay or Multidrop tunnels. 426 But the similarity with IPv4 is limited and this specification 427 enables a lot more: 429 5.1. Point to Multipoint Networks 431 IPv6 Secure Inverse Neighbor Discovery can be applied to P2MP and 432 NBMA networks to prevent the theft an address by another Node. 434 5.2. Point-to-Point Links 436 As opposed to IPv4, using Inverse Neighbor Discovery makes a lot of 437 sense on Point-to-Point link such as PPP or tunnels: 439 This specification inherits from [RFC3122] the support of the 440 authentication header to authenticate the remote peer on the link. 441 For P2P links, this might prove more relevant than Secure ND itself. 443 Because IPv6 operates purely at layer 3, the PPP Network Control 444 Protocol for IPv6 defined in [RFC5072] provides a way to negotiate a 445 unique, 64bit interface identifier to be used for the address 446 autoconfiguration but does not enable to advertise an IPv6 address. 447 This would not fit anyway since IPv6 might use many addresses of 448 various lifetimes on a same interface. This specification provides 449 the means to create and maintain the list of addresses that can be 450 used to reach the remote peer at any point of time. 452 A number of Denial of Service attacks are documented when using 453 [RFC4861] by sending packets to addresses that are not assigned but 454 belong to a prefix that is associated to the P2P link. On those 455 links, Inverse Neighbor Discovery enables a proactive model that 456 defeats those attacks. Any packet that is received for a destination 457 that is not in the ND table is simply dropped. 459 5.3. Broadcast Networks 461 A multihomed host attached to a broadcast network might use an 462 address that belongs to another interface on another subnet to source 463 a packet. This makes the validation of source addresses very 464 problematic. With this specification, a router may solicit the full 465 list of all addreses that this host might use to source packets on 466 that interface, and prove the ownership using SeND. The router might 467 then accept packets that are sourced off-link and may install a host 468 route to that address. 470 6. IANA Considerations 472 This memo includes no request to IANA. 474 7. Security Considerations 476 This draft improves the security model in [RFC3122] by adding the 477 capability to use Secure Neighbor Discovery 479 8. Acknowledgements 481 Thanks to Tony Cheneau and Wojciech Dec for useful feedback and 482 discussion. 484 9. References 486 9.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997. 491 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 492 (IPv6) Specification", RFC 2460, December 1998. 494 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 495 Inverse Discovery Specification", RFC 3122, June 2001. 497 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 498 Neighbor Discovery (SEND)", RFC 3971, March 2005. 500 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 501 RFC 3972, March 2005. 503 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 504 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 505 September 2007. 507 9.2. Informative References 509 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 510 June 1999. 512 [RFC5072] S.Varada, Haskin, D., and E. Allen, "IP Version 6 over 513 PPP", RFC 5072, September 2007. 515 Authors' Addresses 517 Pascal Thubert (editor) 518 Cisco Systems 519 Village d'Entreprises Green Side 520 400, Avenue de Roumanille 521 Batiment T3 522 Biot - Sophia Antipolis 06410 523 FRANCE 525 Phone: +33 4 97 23 26 34 526 Email: pthubert@cisco.com 528 Eric Levy-Abegnoli 529 Cisco Systems 530 Village d'Entreprises Green Side 531 400, Avenue de Roumanille 532 Batiment T3 533 Biot - Sophia Antipolis 06410 534 FRANCE 536 Phone: +33 4 97 23 26 20 537 Email: elevyabe@cisco.com