idnits 2.17.1 draft-ietf-ipv6-over-ppp-v2-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 693. 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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (May 2007) is 6184 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 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2462 (ref. '3') (Obsoleted by RFC 4862) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2472 (ref. '8') (Obsoleted by RFC 5072, RFC 5172) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '12') (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Working Group S.Varada (Editor) 3 Internet-Draft Transwitch 4 Obsoletes: RFC 2472 (if approved) D.Haskins 5 Category: Standards track Ed Allen 6 Expires: November 2007 May 2007 8 IP Version 6 over PPP 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 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 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The Point-to-Point Protocol (PPP) provides a standard method of 43 encapsulating Network Layer protocol information over 44 point-to-point links. PPP also defines an extensible Link Control 45 Protocol, and proposes a family of Network Control Protocols 46 (NCPs) for establishing and configuring different network-layer 47 protocols. 49 This document defines the method for sending IPv6 packets over PPP 50 links, the NCP for establishing and configuring the IPv6 over PPP 51 and the method for forming IPv6 link-local addresses on PPP links. 53 It also specifies the conditions for performing Duplicate Address 54 Detection on IPv6 global unicast addresses configured for PPP 55 links either through stateful or stateless address 56 autoconfiguration. 58 This document obsoletes RFC 2472. 60 Table of Contents 62 1. Introduction...................................................2 63 1.1 Specification of Requirements..............................3 64 2. Sending IPv6 Datagrams.........................................3 65 3. A PPP Network Control Protocol for IPv6........................3 66 4. IPV6CP Configuration Options...................................4 67 4.1 Interface-Identifier.......................................5 68 5. Stateless Autoconfiguration and Link-Local Addresses..........10 69 6. Security Considerations.......................................11 70 7. IANA Considerations...........................................12 71 8. Acknowledgments...............................................12 72 9. References....................................................12 73 9.1 Normative References......................................12 74 9.2 Informative references....................................13 75 Appendix A: Global Scope Addresses..............................13 76 Appendix B: Changes from RFC-2472...............................14 77 Authors' Addresses...............................................14 78 IPR Notice .....................................................14 79 Copyright Notice and Disclaimer..................................15 81 1. Introduction 83 PPP has three main components: 85 1) A method for encapsulating datagrams over serial links. 87 2) A Link Control Protocol (LCP) for establishing, configuring, 88 and testing the data-link connection. 90 3) A family of Network Control Protocols (NCPs) for establishing 91 and configuring different network-layer protocols. 93 In order to establish communications over a point-to-point link, 94 each end of the PPP link must first send LCP packets to 95 configure and test the data link. After the link has been 96 established and optional facilities have been negotiated as 97 needed by the LCP, PPP must send NCP packets to choose and 98 configure one or more network-layer protocols. Once each of the 99 chosen network-layer protocols has been configured, datagrams 100 from each network-layer protocol can be sent over the link. 102 In this document, the NCP for establishing and configuring the 103 IPv6 over PPP is referred as the IPv6 Control Protocol (IPV6CP). 105 The link will remain configured for communications until 106 explicit LCP or NCP packets close the link down, or until some 107 external event occurs (power failure at the other end, carrier 108 drop, etc.). 110 This document obsoletes the earlier specification from RFC 2472 111 [8]. Changes from RFC 2472 are listed in Appendix B. 113 1.1 Specification of Requirements 115 In this document, several words are used to signify the 116 requirements of the specification. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 119 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described 121 in [7]. 123 2. Sending IPv6 Datagrams 125 Before any IPv6 packets may be communicated, PPP MUST reach the 126 Network-Layer Protocol phase, and the IPv6 Control Protocol MUST 127 reach the Opened state. 129 Exactly one IPv6 packet is encapsulated in the Information field 130 of PPP Data Link Layer frames where the Protocol field indicates 131 Type hex 0057 (Internet Protocol Version 6). 133 The maximum length of an IPv6 packet transmitted over a PPP link 134 is the same as the maximum length of the Information field of a 135 PPP data link layer frame. PPP links supporting IPv6 MUST allow 136 the information field at least as large as the minimum link MTU 137 size required for IPv6 [2]. 139 3. A PPP Network Control Protocol for IPv6 141 The IPv6 Control Protocol (IPV6CP) is responsible for 142 configuring, enabling, and disabling the IPv6 protocol modules 143 on both ends of the point-to-point link. IPV6CP uses the same 144 packet exchange mechanism as the LCP. IPV6CP packets may not be 145 exchanged until PPP has reached the Network-Layer Protocol phase. 146 IPV6CP packets received before this phase is reached should be 147 silently discarded. 149 The IPv6 Control Protocol is exactly the same as the LCP [1] with 150 the following exceptions: 152 Data Link Layer Protocol Field 154 Exactly one IPV6CP packet is encapsulated in the 155 Information field of PPP Data Link Layer frames where the 156 Protocol field indicates type hex 8057 (IPv6 Control 157 Protocol). 159 Code field 161 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 162 Configure-Nak, Configure-Reject, Terminate-Request, 163 Terminate-Ack and Code-Reject) are used. Other Codes 164 should be treated as unrecognized and should result in 165 Code-Rejects. 167 Timeouts 169 IPV6CP packets may not be exchanged until PPP has reached 170 the Network-Layer Protocol phase. An implementation 171 should be prepared to wait for Authentication and Link 172 Quality Determination to finish before timing out waiting 173 for a Configure-Ack or other response. It is suggested 174 that an implementation give up only after user 175 intervention or a configurable amount of time. 177 Configuration Option Types 179 IPV6CP has a distinct set of Configuration Options. 181 4. IPV6CP Configuration Options 183 IPV6CP Configuration Options allow negotiation of desirable IPv6 184 parameters. IPV6CP uses the same Configuration Option format 185 defined for LCP [1] but with a separate set of Options. If a 186 Configuration Option is not included in a Configure-Request 187 packet, the default value for that Configuration Option is 188 assumed. 190 Up-to-date values of the IPV6CP Option Type field are specified 191 in the on-line database of "Assigned Numbers" maintained at 192 IANA [4]. Current value is assigned as follows: 194 1 Interface-Identifier 196 The only IPV6CP option defined in this document is the Interface 197 Identifier. Any other IPV6CP configuration options that can be 198 defined over time are to be defined in separate documents. 200 4.1 Interface-Identifier 202 Description 204 This Configuration Option provides a way to negotiate an unique 205 64-bit interface identifier to be used for the address 206 autoconfiguration [3] at the local end of the link (see 207 section 5). A Configure-Request MUST contain exactly one 208 instance of the Interface-Identifier option [1]. The interface 209 identifier MUST be unique within the PPP link; i.e. upon 210 completion of the negotiation different Interface-Identifier 211 values are to be selected for the ends of the PPP link. The 212 interface identifier may also be unique over a broader scope. 214 Before this Configuration Option is requested, an implementation 215 chooses its tentative Interface-Identifier. The non-zero value of 216 the tentative Interface-Identifier SHOULD be chosen such that the 217 value is unique to the link and, preferably, consistently 218 reproducible across initializations of the IPV6CP finite state 219 machine (administrative Close and reOpen, reboots, etc). The 220 rationale for preferring a consistently reproducible unique 221 interface identifier to a completely random interface identifier 222 is to provide stability to global scope addresses (see Appendix A) 223 that can be formed from the interface identifier 225 Assuming that interface identifier bits are numbered from 0 to 226 63 in canonical bit order where the most significant bit is 227 the bit number 0, the bit number 6 is the "u" bit (universal/local 228 bit in IEEE EUI-64 [5] terminology) which indicates whether or 229 not the interface identifier is based on a globally unique IEEE 230 identifier (EUI-48 or EUI-64[5])(see the case 1 below). It is set 231 to one (1) if a globally unique IEEE identifier is used to derive 232 the interface-identifier, and it is set to zero (0) otherwise. 234 The following are methods for choosing the tentative Interface 235 Identifier in the preference order: 237 1)If an IEEE global identifier (EUI-48 or EUI-64) is 238 available anywhere on the node, it should be used to 239 construct the tentative Interface-Identifier due to its 240 uniqueness properties. When extracting an IEEE global 241 identifier from another device on the node, care should be 242 taken that the extracted identifier is presented in 243 canonical ordering [14]. 245 The only transformation from an EUI-64 identifier is to invert 246 the "u" bit (universal/local bit in IEEE EUI-64 terminology). 248 For example, for a globally unique EUI-64 identifier of the 249 form: 251 most-significant least significant 252 bit bit 253 |0 1|1 3|3 4|4 6| 254 |0 5|6 1|2 7|8 3| 255 +----------------+----------------+----------------+----------------+ 257 |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee| 258 +----------------+----------------+----------------+----------------+ 260 where "c" are the bits of the assigned company_id, "0" is 261 the value of the universal/local bit to indicate global 262 scope, "g" is group/individual bit, and "e" are the bits 263 of the extension identifier, the IPv6 interface identifier 264 would be of the form: 266 most-significant least-significant 267 bit bit 268 |0 1|1 3|3 4|4 6| 269 |0 5|6 1|2 7|8 3| 270 +----------------+----------------+----------------+----------------+ 272 |cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee| 273 +----------------+----------------+----------------+----------------+ 275 The only change is inverting the value of the 276 universal/local bit. 278 In the case of a EUI-48 identifier, it is first converted 279 to the EUI-64 format by inserting two bytes, with 280 hexa-decimal values of 0xFF and 0xFE, in the middle of the 281 48 bit MAC (between the company_id and extension identifier 282 portions of the EUI-48 value). For example, for a globally 283 unique 48 bit EUI-48 identifier of the 284 form: 286 most-significant least-significant 287 bit bit 288 |0 1|1 3|3 4| 289 |0 5|6 1|2 7| 290 +----------------+----------------+----------------+ 291 |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee| 292 +----------------+----------------+----------------+ 294 where "c" are the bits of the assigned company_id, "0" is 295 the value of the universal/local bit to indicate global 296 scope, "g" is group/individual bit, and "e" are the bits 297 of the extension identifier, the IPv6 interface identifier 298 would be of the form: 300 most-significant least-significant 301 bit bit 302 |0 1|1 3|3 4|4 6| 303 |0 5|6 1|2 7|8 3| 304 +----------------+----------------+----------------+----------------+ 306 |cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee| 307 +----------------+----------------+----------------+----------------+ 309 2) If an IEEE global identifier is not available, a different 310 source of uniqueness should be used. Suggested sources of 311 uniqueness include link-layer addresses, machine serial 312 numbers, et cetera. In this case, the "u" bit of the 313 interface-identifier MUST be set to zero (0). 315 3) If a good source of uniqueness cannot be found, it is 316 recommended that a random number be generated. In this 317 case, the "u" bit of the interface-identifier MUST be set to 318 zero (0). 320 Good sources [1] of uniqueness or randomness are required for 321 the Interface-Identifier negotiation to succeed. If neither an 322 unique number or a random number can be generated, it is 323 recommended that a zero value be used for the Interface 324 Identifier transmitted in the Configure-Request. In this case 325 the PPP peer may provide a valid non-zero Interface-Identifier 326 in its response as described below. Note that if at least one of 327 the PPP peers is able to generate separate non-zero numbers for 328 itself and its peer, the identifier negotiation will succeed. 330 When a Configure-Request is received with the Interface 331 Identifier Configuration Option and the receiving peer 332 implements this option, the received Interface-Identifier is 333 compared with the Interface-Identifier of the last 334 Configure-Request sent to the peer. Depending on the result of the 335 comparison an implementation MUST respond in one of the 336 following ways: 338 If the two Interface-Identifiers are different but the received 339 Interface-Identifier is zero, a Configure-Nak is sent with a 340 non-zero Interface-Identifier value suggested for use by the 341 remote peer. Such a suggested Interface-Identifier MUST be 342 different from the Interface-Identifier of the last 343 Configure-Request sent to the peer. It is recommended that the 344 value suggested be consistently reproducible across 345 initializations of the IPV6CP finite state machine (administrative 346 Close and reOpen, reboots, etc). The "u" (universal/local) bit of 347 the suggested identifier MUST be set to zero (0) regardless of its 348 source unless the globally unique EUI-48/EUI-64 derived 349 identifier is provided for the exclusive use by the remote peer. 351 If the two Interface-Identifiers are different and the received 352 Interface-Identifier is not zero, the Interface-Identifier MUST be 353 acknowledged, i.e. a Configure-Ack is sent with the requested 354 Interface-Identifier, meaning that the responding peer agrees with 355 the Interface-Identifier requested. 357 If the two Interface-Identifiers are equal and are not zero, 358 Configure-Nak MUST be sent specifying a different non-zero 359 Interface-Identifier value suggested for use by the remote peer. 360 It is recommended that the value suggested be consistently 361 reproducible across initializations of the IPV6CP finite state 362 machine (administrative Close and reOpen, reboots, etc). The "u" 363 (universal/local) bit of the suggested identifier MUST be set to 364 zero (0) regardless of its source unless the globally unique 365 EUI-48/EUI-64 derived identifier is provided for the exclusive use 366 by the remote peer. 368 If the two Interface-Identifiers are equal to zero, the Interface 369 Identifiers negotiation MUST be terminated by transmitting the 370 Configure-Reject with the Interface-Identifier value set to zero. 371 In this case a unique Interface-Identifier can not be negotiated. 373 If a Configure-Request is received with the Interface-Identifier 374 Configuration Option and the receiving peer does not implement 375 this option, Configure-Rej is sent. 377 A new Configure-Request SHOULD NOT be sent to the peer until 378 normal processing would cause it to be sent (that is, until a 379 Configure-Nak is received or the Restart timer runs out [1]). 381 A new Configure-Request MUST NOT contain the Interface-Identifier 382 option if a valid Interface-Identifier Configure-Reject is 383 received. 385 Reception of a Configure-Nak with a suggested Interface-Identifier 386 different from that of the last Configure-Nak sent to the peer 387 indicates an unique Interface-Identifier. In this case a new 388 Configure-Request MUST be sent with the identifier value suggested 389 in the last Configure-Nak from the peer. But if the received 390 Interface-Identifier is equal to the one sent in the last 391 Configure-Nak, a new Interface-Identifier MUST be chosen. In this 392 case, a new Configure-Request SHOULD be sent with the new 393 tentative Interface-Identifier. This sequence (transmit 394 Configure-Request, receive Configure-Request, transmit 395 Configure-Nak, receive Configure-Nak) might occur a few times, but 396 it is extremely unlikely to occur repeatedly. More likely, the 397 Interface-Identifiers chosen at either end will quickly diverge, 398 terminating the sequence. 400 If negotiation of the Interface-Identifier is required, and the 401 peer did not provide the option in its Configure-Request, the 402 option SHOULD be appended to a Configure-Nak. The tentative value 403 of the Interface-Identifier given must be acceptable as the remote 404 Interface-Identifier; i.e. it should be different from the 405 identifier value selected for the local end of the PPP link. The 406 next Configure-Request from the peer may include this option. If 407 the next Configure-Request does not include this option the peer 408 MUST NOT send another Configure-Nak with this option included. It 409 should assume that the peer's implementation does not support this 410 option. 412 By default, an implementation SHOULD attempt to negotiate the 413 Interface-Identifier for its end of the PPP connection. 415 A summary of the Interface-Identifier Configuration Option format 416 is shown below. The fields are transmitted from left to right. 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Type | Length | Interface-Identifier (MS Bytes) 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Interface-Identifier (cont) 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Interface-Identifier (LS Bytes) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Type 430 1 432 Length 434 10 435 Interface-Identifier 437 The 64-bit Interface-Identifier, which is very likely to be 438 unique on the link, or zero if a good source of uniqueness 439 can not be found. 441 Default 443 If no valid interface identifier can be successfully 444 negotiated, no default Interface-Identifier value should be 445 assumed. The procedures for recovering from such a case are 446 unspecified. One approach is to manually configure the 447 interface identifier of the interface. 449 5. Stateless Autoconfiguration and Link-Local Addresses 451 The Interface-Identifier of IPv6 unicast addresses [6] of a PPP 452 interface, SHOULD be negotiated in the IPV6CP phase of the PPP 453 connection setup (see section 4.1). If no valid Interface 454 Identifier has been successfully negotiated, procedures for 455 recovering from such a case are unspecified. One approach is to 456 manually configure the Interface-Identifier of the interface. 458 The negotiated Interface-Identifier is used by the local end of 459 the PPP link to autoconfigure IPv6 link-local unicast address for 460 the PPP interface. However, it SHOULD NOT be assumed that the 461 same Interface-Identifier is used in configuring global unicast 462 addresses for the PPP interface using IPv6 stateless address 463 autoconfiguration [3]. The PPP peer MAY generate one or more 464 Interface Identifiers, for instance, using a method described in 465 [9], to autoconfigure one or more global unicast addresses. 467 As long as the Interface-Identifier is negotiated in the IPV6CP 468 phase of the PPP connection setup, it is redundant to perform 469 duplicate address detection (DAD) as a part of the IPv6 Stateless 470 Address Autoconfiguration protocol [3] on the IPv6 link-local 471 address generated by the PPP peer. It may also be redundant to 472 perform DAD on any global unicast addresses configured (using an 473 Interface-Identifier that is either negotiated during IPV6CP or 474 generated, for instance, as per [9]) for the interface as part of 475 the IPv6 Stateless Address Autoconfiguration protocol [3] provided 476 that the following two conditions are met: 478 1) The prefixes advertised, through the Router Advertisement 479 messages, by the access router terminating the PPP link are 480 exclusive to the PPP link. 482 2) The access router terminating the PPP link does not 483 autoconfigure any IPv6 global unicast addresses from the 484 prefixes that it advertises. 486 Therefore, it is RECOMMENDED that for PPP links with the IPV6CP 487 Interface-Identifier option enabled and satisfying the 488 aforementioned two conditions, the default value of the 489 DupAddrDetectTransmits autoconfiguration variable [3] is set to 490 zero by the system management. 3GPP2 networks are an example of a 491 technology that uses PPP to enable a host to obtain an IPv6 global 492 unicast address and satisfies the aforementioned two conditions 493 [10]. 3GPP networks are another example [11] & [13]. 495 Link-local addresses 497 Link-local addresses of PPP interfaces have the following 498 format: 500 | 10 bits | 54 bits | 64 bits | 501 +----------+------------------------+-----------------------------+ 502 |1111111010| 0 | Interface-Identifier | 503 +----------+------------------------+-----------------------------+ 505 The most significant 10 bits of the address is the Link-Local 506 prefix FE80::. 54 zero bits pad out the address between the 507 Link-Local prefix and the Interface-Identifier fields. 509 6. Security Considerations 511 Lack of link security, such as authentication, trigger the 512 security concerns raised in [3] when stateless address auto- 513 configuration method is employed for the generation of global 514 unicast IPv6 addresses out of interface identifiers that are 515 either negotiated through the IPV6CP or generated, for instance, 516 using a method described in [9]. Thus, the mechanisms that are 517 appropriate for ensuring PPP link security are addressed below 518 together with the reference to a generic threat model. 520 The mechanisms that are appropriate for ensuring PPP link 521 Security are: 1) Access Control Lists that apply filters on 522 traffic received over the link for enforcing admission policy, 2) 523 an Authentication protocol that facilitates negotiations between 524 peers [15] to select an authentication method (e.g., MD5 [16]) 525 for validation of the peer, and 3) an Encryption protocol that 526 facilitates negotiations between peers to select encryption 527 algorithms (or, crypto-suites) to ensure data confidentiality 528 [17]). 530 There are certain threats associated with peer interactions on a 531 PPP link even with one or more of the above security measures in 532 place. For instance, using MD5 authentication method [16] exposes 533 one to replay attack, where in which, an attacker could intercept 534 and replay a station's identity and password hash to get access to 535 a network. The user of this specification is advised to refer to 536 [15], which presents a generic threat model, for an understanding 537 of the threats posed to the security of a link. The reference 538 [15] also gives framework to specify requirements for the 539 selection of an authentication method for a given application. 541 7. IANA Considerations 543 The editor has no specific recommendations for the IANA on the 544 assignment of a value for the Type field of IPv6 datagram 545 Interface-Identifier option specified in this specification. The 546 current assignment is up-to-date at [4]. However, the reference 547 to the RFC number needs to be updated. 549 8. Acknowledgments 551 This document borrows from the Magic-Number LCP option and as such 552 is partially based on previous work done by the PPP working group. 554 The editor is grateful for the input provided by members of the 555 IPv6 community in the spirit of updating the RFC 2472. Thanks, in 556 particular, go to Pete Barany and Karim El-malki for their 557 technical contributions. Also, thanks to Alex Conta, for a 558 thorough reviewing, Stephen Kent, for helping with security 559 aspects, Spencer Dawkins and Pekka Savola for the nits. Finally, 560 the author is grateful to Jari Arkko, for his initiation to bring 561 closure to this specification. 563 9. References 565 9.1 Normative References 567 [1] Simpson, W., "The Point-to-Point Protocol," STD 51, RFC 568 1661, July 1994. 570 [2] Deering, S., and R. Hinden, Editors, "Internet Protocol, 571 Version 6 (IPv6) Specification," RFC 2460, December 1998. 573 [3] Thomson, S., and T. Narten, "IPv6 Stateless Address 574 Autoconfiguration," RFC 2462, December 1998. 576 [4] IANA, "Assigned Numbers," http://www.iana.org/numbers.html 578 [5] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 579 Registration Authority", April 2004. 581 [6] Hinden, R., and S. Deering, "IP Version 6 Addressing 582 Architecture", RFC 4291, February 2006. 584 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 585 Levels," BCP 14, RFC 2119, March 1997. 587 [8] Haskin D., and E. Allen, "IP Version 6 over PPP," RFC 2472, 588 December 1998. 590 [9] Narten T., et. al., " Privacy Extensions for Stateless Address 591 Autoconfiguration in IPv6," draft-ietf-ipv6-privacy-addrs-v2- 592 05, August 2006. 594 9.2 Informative references 596 [10] 3GPP2 X.S0011-002-C v1.0, "cdma2000 Wireless IP Network 597 Standard: Simple IP and Mobile IP Access Services," September 598 2003. 600 [11] 3GPP TS 29.061 V6.4.0, "Interworking between the Public Land 601 Mobile Network (PLMN) Supporting packet based services and 602 Packet Data Networks (PDN) (Release 6)," April 2005. 604 [12] Droms, E., et al., "Dynamic Host Configuration Protocol for 605 IPv6 (DHCPv6)," RFC 3315, July 2003. 607 [13] 3GPP TS 23.060 v6.8.0, "General Packet Radio Service (GPRS); 608 Service description; Stage 2 (Release 6)," March 2005. 610 [14] Narten T., and C. Burton, "A Caution On The Canonical Ordering 611 Of Link-Layer Addresses," RFC 2469, December 1998. 613 [15] Aboba, R., et. al., "Extensible Authentication Protocol," RFC 614 3748, June 2004. 616 [16] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, April 617 1992. 619 [17] Meyer, G., "The PPP Encryption Control Protocol (ECP)," RFC 620 1968, June 1996. 622 Appendix A: Global Scope Addresses 624 A node on the PPP link MUST create global unicast addresses either 625 through stateless or stateful address auto-configuration 626 mechanisms. In the stateless address auto-configuration [3], the 627 node relies on sub-net prefixes advertised by the router via the 628 Router Advertisement messages to obtain global unicast addresses 629 from an interface identifier. In the stateful address auto- 630 configuration, the host relies on a Stateful Server, like, DHCPv6 631 [12], to obtain global unicast addresses. 633 Appendix B: Changes from RFC-2472 635 The following changes were made from RFC-2472 "IPv6 over PPP": 637 - Minor updates to sections 3 and 4 639 - Updated the text in section 4.1 to include the reference to 640 Appendix A and minor text clarifications. 642 - Removed the section 4.2 on IPv6-Compression-Protocol, based on 643 the IESG recommendation, and created a new standards track 644 draft to cover the negotiation of IPv6 datagram compression 645 protocol using IPV6CP. 647 - Updated the text in Section 5 to: (a) allow the use of one or 648 more Interface-Identifiers generated by a peer, in addition to 649 the use of Interface-identifier negotiated between peers of the 650 link, in the creation of global unicast addresses for the local 651 PPP interface, and (b) identify cases against the DAD of 652 created non-link-local addresses. 654 - Added new and updated references. 656 - Added the Appendix A 658 Authors' Addresses 660 Dimitry Haskin 661 Ed Allen 663 Srihari Varada (Editor) 664 TranSwitch Corporation 665 3 Enterprise Dr. 666 Shelton, CT 06484. US. 668 Phone: +1 203 929 8810 669 EMail: varada@txc.com 671 IPR Notice 673 The IETF takes no position regarding the validity or scope of any 674 Intellectual Property Rights or other rights that might be claimed 675 to pertain to the implementation or use of the technology 676 described in this document or the extent to which any license 677 under such rights might or might not be available; nor does it 678 represent that it has made any independent effort to identify any 679 such rights. Information on the procedures with respect to rights 680 in RFC documents can be found in BCP 78 and BCP 79. 682 Copies of IPR disclosures made to the IETF Secretariat and any 683 assurances of licenses to be made available, or the result of an 684 attempt made to obtain a general license or permission for the use 685 of such proprietary rights by implementers or users of this 686 specification can be obtained from the IETF on-line IPR repository 687 at http://www.ietf.org/ipr. 689 The IETF invites any interested party to bring to its attention 690 any copyrights, patents or patent applications, or other 691 proprietary rights that may cover technology that may be required 692 to implement this standard. Please address the information to the 693 IETF at ietf-ipr@ietf.org. 695 Copyright Notice and Disclaimer 697 Copyright (C) The IETF Trust (2007). This document is subject to 698 the rights, licenses and restrictions contained in BCP 78, and 699 except as set forth therein, the authors retain all their rights. 701 This document and the information contained herein are provided 702 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 703 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 704 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 705 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 706 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 707 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 708 FOR A PARTICULAR PURPOSE.