idnits 2.17.1 draft-ietf-ipngwg-ipv6-over-ppp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 157 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 253 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 91: '... MUST This word, or the adje...' RFC 2119 keyword, line 94: '... MUST NOT This phrase means that...' RFC 2119 keyword, line 97: '... SHOULD This word, or the adje...' RFC 2119 keyword, line 103: '... MAY This word, or the adje...' RFC 2119 keyword, line 105: '...h does not include this option MUST be...' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...ocument is a...' == Line 13 has weird spacing: '...cuments of t...' == Line 14 has weird spacing: '...t other group...' == Line 19 has weird spacing: '...iate to use ...' == Line 20 has weird spacing: '... as refer...' == (152 more instances...) -- 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 (July 1997) is 9775 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 1883 (ref. '2') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1971 (ref. '3') (Obsoleted by RFC 2462) ** Obsolete normative reference: RFC 1700 (ref. '4') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 INTERNET-DRAFT Dimitry Haskin 4 Expires January 1998 Ed Allen 5 Bay Networks, Inc. 6 July 1997 8 IP Version 6 over PPP 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months. 18 Internet-Drafts may be updated, replaced, or obsoleted by other 19 documents at any time. It is not appropriate to use Internet-Drafts 20 as reference material or to cite them other than as a ``working 21 draft'' or ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 The Point-to-Point Protocol (PPP) [1] provides a standard method of 32 encapsulating Network Layer protocol information over point-to-point 33 links. PPP also defines an extensible Link Control Protocol, and 34 proposes a family of Network Control Protocols (NCPs) for establishing 35 and configuring different network-layer protocols. 37 This document defines the method for transmission of IP Version 6 [2] 38 packets over PPP links as well as the Network Control Protocol (NCP) 39 for establishing and configuring the IPv6 over PPP. It also specifies 40 the method of forming IPv6 link-local addresses on PPP links. 42 Table of Contents 44 1. Introduction .......................................... 3 45 1.1. Specification of Requirements ...................... 3 46 2. Sending IPv6 Datagrams ................................ 4 47 3. A PPP Network Control Protocol for IPv6 ............... 4 48 4. IPV6CP Configuration Options .......................... 5 49 4.1. Interface-Token ................................... 5 50 4.2. IPv6-Compression-Protocol.......................... 11 51 5. Stateless Autoconfiguration and Link-Local Addresses .. 12 52 6. IPV6CP Recommended Options ............................. 13 53 Security Considerations ....................................... 13 54 References .................................................... 13 55 Acknowledgments ............................................... 14 56 Authors' Addresses ............................................ 14 58 1. Introduction 60 PPP has three main components: 62 1. A method for encapsulating datagrams over serial links. 64 2. A Link Control Protocol (LCP) for establishing, configuring, and 65 testing the data-link connection. 67 3. A family of Network Control Protocols (NCPs) for establishing and 68 configuring different network-layer protocols. 70 In order to establish communications over a point-to-point link, each 71 end of the PPP link must first send LCP packets to configure and test 72 the data link. After the link has been established and optional 73 facilities have been negotiated as needed by the LCP, PPP must send 74 NCP packets to choose and configure one or more network-layer 75 protocols. Once each of the chosen network-layer protocols has been 76 configured, datagrams from each network-layer protocol can be sent 77 over the link. 79 In this document, the NCP for establishing and configuring the IPv6 80 over PPP is referred as the IPv6 Control Protocol (IPV6CP). 82 The link will remain configured for communications until explicit LCP 83 or NCP packets close the link down, or until some external event 84 occurs (power failure at the other end, carrier drop, etc.). 86 1.1. Specification of Requirements 88 In this document, several words are used to signify the requirements 89 of the specification. These words are often capitalized. 91 MUST This word, or the adjective "required", means that the 92 definition is an absolute requirement of the specification. 94 MUST NOT This phrase means that the definition is an absolute 95 prohibition of the specification. 97 SHOULD This word, or the adjective "recommended", means that there 98 may exist valid reasons in particular circumstances to 99 ignore this item, but the full implications must be 100 understood and carefully weighed before choosing 101 a different course. 103 MAY This word, or the adjective "optional", means that this 104 item is one of an allowed set of alternatives. An 105 implementation which does not include this option MUST be 106 prepared to inter-operate with another implementation 107 which does include the option. 109 2. Sending IPv6 Datagrams 111 Before any IPv6 packets may be communicated, PPP MUST reach the 112 Network-Layer Protocol phase, and the IPv6 Control Protocol MUST reach 113 the Opened state. 115 Exactly one IPv6 packet is encapsulated in the Information field of 116 PPP Data Link Layer frames where the Protocol field indicates type hex 117 0057 (Internet Protocol Version 6). 119 The maximum length of an IPv6 packet transmitted over a PPP link is 120 the same as the maximum length of the Information field of a PPP data 121 link layer frame. PPP links supporting IPv6 MUST allow at least 576 122 octets in the information field of a data link layer frame. 124 3. A PPP Network Control Protocol for IPv6 126 The IPv6 Control Protocol (IPV6CP) is responsible for configuring, 127 enabling, and disabling the IPv6 protocol modules on both ends of the 128 point-to-point link. IPV6CP uses the same packet exchange mechanism 129 as the Link Control Protocol (LCP). IPV6CP packets may not be 130 exchanged until PPP has reached the Network-Layer Protocol phase. 131 IPV6CP packets received before this phase is reached should be 132 silently discarded. 134 The IPv6 Control Protocol is exactly the same as the Link Control 135 Protocol [1] with the following exceptions: 137 Data Link Layer Protocol Field 139 Exactly one IPV6CP packet is encapsulated in the Information 140 field of PPP Data Link Layer frames where the Protocol field 141 indicates type hex 8057 (IPv6 Control Protocol). 143 Code field 145 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 146 Configure-Nak, Configure-Reject, Terminate-Request, Terminate- 147 Ack and Code-Reject) are used. Other Codes should be treated 148 as unrecognized and should result in Code-Rejects. 150 Timeouts 152 IPV6CP packets may not be exchanged until PPP has reached the 153 Network-Layer Protocol phase. An implementation should be 154 prepared to wait for Authentication and Link Quality 155 Determination to finish before timing out waiting for a 156 Configure-Ack or other response. It is suggested that an 157 implementation give up only after user intervention or a 158 configurable amount of time. 160 Configuration Option Types 162 IPV6CP has a distinct set of Configuration Options, which are 163 defined below. 165 4. IPV6CP Configuration Options 167 IPV6CP Configuration Options allow negotiation of desirable IPv6 168 parameters. IPV6CP uses the same Configuration Option format defined 169 for LCP [1], with a separate set of Options. If a Configuration 170 Option is not included in a Configure-Request packet, the default 171 value for that Configuration Option is assumed. 173 Up-to-date values of the IPV6CP Option Type field are specified in the 174 most recent "Assigned Numbers" RFC [4]. Current values are assigned 175 as follows: 177 1 Interface-Token 178 2 IPv6-Compression-Protocol 180 4.1. Interface-Token 182 Description 184 This Configuration Option provides a way to negotiate a unique 64- 185 bit interface token to be used for the address autoconfiguration [3] 186 at the local end of the link (see section 5). The interface token 187 MUST be unique within the PPP link; i.e. upon completion of the 188 negotiation different Interface-Token values are to be selected for 189 the ends of the PPP link. The interface token MAY also be unique 190 over a broader scope. 192 Before this Configuration Option is requested, an implementation 193 chooses its tentative Interface-Token. The non-zero value of the 194 tentative Interface-Token SHOULD be chosen such that the value is 195 both unique to the link and, if possible, consistently reproducible 196 across initializations of the IPV6CP finite state machine 197 (administrative Close and reOpen, reboots, etc). The rationale for 198 preferring a consistently reproducible unique token to a completely 199 random token is to provide stability to global scope addresses that 200 can be formed from the interface token. 202 Assuming that interface token bits are numbered from 0 to 63 where 203 the most significant bit is the bit number 0, the bit number 6 is 204 the "u" bit (universal/local bit in IEEE EUI-64 [5] terminology) 205 which indicates whether or not the interface token is based on a 206 globally unique IEEE identifier (EUI-48 or EUI-64 [5]) (see the case 207 1 below). It is set to one (1) if a globally unique IEEE identifier 208 is used to derive the interface token, and it is set to zero (0) 209 otherwise. 211 The following are methods for choosing the tentative Interface Token 212 in the preference order: 214 1) If an IEEE global identifier (EUI-48 or EUI-64) is available 215 anywhere on the node, it should be used to construct the 216 tentative Interface-Token due to its uniqueness properties. 218 The only transformation from an EUI-64 identifier is to invert 219 the "u" bit (universal/local bit in IEEE EUI-64 terminology). 220 For example, for a globally unique EUI-64 identifier of the form: 222 most-significant least-significant 223 bit bit 224 |0 1|1 3|3 4|4 6| 225 |0 5|6 1|2 7|8 3| 226 +----------------+----------------+----------------+----------------+ 227 |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee| 228 +----------------+----------------+----------------+----------------+ 229 where "c" are the bits of the assigned company_id, "0" is the 230 value of the universal/local bit to indicate global scope, "g" is 231 group/individual bit, and "e" are the bits of the extension 232 identifier, the IPv6 interface token would be of the form: 234 most-significant least-significant 235 bit bit 236 |0 1|1 3|3 4|4 6| 237 |0 5|6 1|2 7|8 3| 238 +----------------+----------------+----------------+----------------+ 239 |cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee| 240 +----------------+----------------+----------------+----------------+ 242 The only change is inverting the value of the universal/local 243 bit. 245 In the case of a EUI-48 identifier, it is first converted to the 246 EUI-64 format by inserting two bytes, with hexadecimal values of 247 0xFF and 0xFE, in the middle of the 48 bit MAC (between the 248 company_id and extension-identifier portions of the EUI-48 249 value). For example, for a globally unique 48 bit EUI-48 250 identifier of the form: 252 most-significant least-significant 253 bit bit 254 |0 1|1 3|3 4| 255 |0 5|6 1|2 7| 256 +----------------+----------------+----------------+ 257 |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee| 258 +----------------+----------------+----------------+ 260 where "c" are the bits of the assigned company_id, "0" is the 261 value of the universal/local bit to indicate global scope, "g" is 262 group/individual bit, and "e" are the bits of the extension 263 identifier, the IPv6 interface token would be of the form: 265 most-significant least-significant 266 bit bit 267 |0 1|1 3|3 4|4 6| 268 |0 5|6 1|2 7|8 3| 269 +----------------+----------------+----------------+----------------+ 270 |cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee| 271 +----------------+----------------+----------------+----------------+ 272 2) If an IEEE global identifier is not available a different source 273 of uniqueness should be used. Suggested sources of uniqueness 274 include link-layer addresses, machine serial numbers, et cetera. 276 In this case the "u" bit of the interface token MUST be set to 277 zero (0). 279 3) If a good source of uniqueness cannot be found, it is recommended 280 that a random number be generated. In this case the "u" bit of 281 the interface token MUST be set to zero (0). 283 Good sources [1] of uniqueness or randomness are required for the 284 Interface-Token negotiation to succeed. If neither a unique number 285 or a random number can be generated it is recommended that a zero 286 value be used for the Interface-Token transmitted in the Configure- 287 Request. In this case the PPP peer may provide a valid non-zero 288 Interface-Token in its response as described below. Note that if at 289 least one of the PPP peers is able to generate separate non-zero 290 numbers for itself and its peer, the token negotiation will succeed. 292 When a Configure-Request is received with the Interface-Token 293 Configuration Option and the receiving peer implements this option, 294 the received Interface-Token is compared with the Interface-Token of 295 the last Configure-Request sent to the peer. Depending on the 296 result of the comparison an implementation MUST respond in one of 297 the following ways: 299 If the two Interface-Tokens are different but the received 300 Interface-Token is zero, a Configure-Nak is sent with a non-zero 301 Interface-Token value suggested for use by the remote peer. Such a 302 suggested Interface-Token MUST be different from the Interface- 303 Token of the last Configure-Request sent to the peer. It is 304 recommended that the value suggested be consistently reproducible 305 across initializations of the IPV6CP finite state machine 306 (administrative Close and reOpen, reboots, etc). The "u" 307 universal/local) bit of the suggested token MUST be set to zero (0) 308 regardless of its source unless the globally unique EUI-48/EUI-64 309 derived token is provided for the exclusive use by the remote peer. 311 If the two Interface-Tokens are different and the received 312 Interface-Token is not zero, the Interface-Token MUST be 313 acknowledged, i.e. a Configure-Ack is sent with the requested 314 Interface-Token, meaning that the responding peer agrees with the 315 Interface-Token requested. 317 If the two Interface-Tokens are equal and are not zero, a 318 Configure-Nak MUST be sent specifying a different non-zero 319 Interface-Token value suggested for use by the remote peer. It is 320 recommended that the value suggested be consistently reproducible 321 across initializations of the IPV6CP finite state machine 322 (administrative Close and reOpen, reboots, etc). The "u" 323 universal/local) bit of the suggested token MUST be set to zero (0) 324 regardless of its source unless the globally unique EUI-48/EUI-64 325 derived token is provided for the exclusive use by the remote peer. 327 If the two Interface-Tokens are equal to zero, the Interface- 328 Tokens negotiation MUST be terminated by transmitting the 329 Configure-Reject with the Interface-Token value set to zero. In this 330 case a unique Interface-Token can not be negotiated. 332 If a Configure-Request is received with the Interface-Token 333 Configuration Option and the receiving peer does not implement this 334 option, Configure-Rej is sent. 336 A new Configure-Request SHOULD NOT be sent to the peer until normal 337 processing would cause it to be sent (that is, until a Configure-Nak 338 is received or the Restart timer runs out). 340 A new Configure-Request MUST NOT contain the Interface-Token option 341 if a valid Interface-Token Configure-Reject is received. 343 Reception of a Configure-Nak with a suggested Interface-Token 344 different from that of the last Configure-Nak sent to the peer 345 indicates a unique Interface-Token. In this case a new Configure- 346 Request MUST be sent with the token value suggested in the last 347 Configure-Nak from the peer. But if the received Interface-Token is 348 equal to the one sent in the last Configure- Nak, a new Interface- 349 Token MUST be chosen. In this case, a new Configure-Request SHOULD 350 be sent with the new tentative Interface-Token. This sequence 351 (transmit Configure-Request, receive Configure-Request, transmit 352 Configure-Nak, receive Configure-Nak) might occur a few times, but 353 it is extremely unlikely to occur repeatedly. More likely, the 354 Interface-Tokens chosen at either end will quickly diverge, 355 terminating the sequence. 357 If negotiation of the Interface-Token is required, and the peer did 358 not provide the option in its Configure-Request, the option SHOULD 359 be appended to a Configure-Nak. The tentative value of the 360 Interface-Token given must be acceptable as the remote Interface- 361 Token; i.e. it should be different from the token value selected for 362 the local end of the PPP link. The next Configure-Request from the 363 peer may include this option. If the next Configure-Request does 364 not include this option the peer MUST NOT send another Configure-Nak 365 with this option included. It should assume that the peer's 366 implementation does not support this option. 368 By default, an implementation SHOULD attempt to negotiate the 369 Interface-Token for its end of the PPP connection. 371 A summary of the Interface-Token Configuration Option format is shown 372 below. The fields are transmitted from left to right. 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Length | Interface-Token (MS Bytes) 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Interface-Token (cont) 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Interface-Token (LS Bytes) | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Type 386 1 388 Length 390 10 392 Interface-Token 394 The 64-bit Interface-Token which is very likely to be unique on 395 the link or zero if a good source of uniqueness can not be found. 397 Default Token Value 399 If no valid interface token can be successfully negotiated, no 400 default Interface-Token value should be assumed. The procedures 401 for recovering from such a case are unspecified. One approach is 402 to manually configure the interface token of the interface. 404 4.2. IPv6-Compression-Protocol 406 Description 408 This Configuration Option provides a way to negotiate the use of a 409 specific IPv6 packet compression protocol. The IPv6-Compression- 410 Protocol Configuration Option is used to indicate the ability to 411 receive compressed packets. Each end of the link must separately 412 request this option if bi-directional compression is desired. By 413 default, compression is not enabled. 415 IPv6 compression negotiated with this option is specific to IPv6 416 datagrams and is not to be confused with compression resulting from 417 negotiations via Compression Control Protocol (CCP), which 418 potentially effect all datagrams. 420 A summary of the IPv6-Compression-Protocol Configuration Option format 421 is shown below. The fields are transmitted from left to right. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Type | Length | IPv6-Compression-Protocol | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Data ... 429 +-+-+-+-+ 431 Type 433 2 435 Length 437 >= 4 439 IPv6-Compression-Protocol 441 The IPv6-Compression-Protocol field is two octets and indicates 442 the compression protocol desired. Values for this field are 443 always the same as the PPP Data Link Layer Protocol field values 444 for that same compression protocol. 446 Up-to-date values of the IPv6-Compression-Protocol field are 447 specified in the most recent "Assigned Numbers" RFC [4]. 449 Current values are assigned as follows: 451 Value (in hex) Protocol 453 004f IPv6 Header Compression 455 Data 457 The Data field is zero or more octets and contains additional data 458 as determined by the particular compression protocol. 460 Default 462 No IPv6 compression protocol enabled. 464 5. Stateless Autoconfiguration and Link-Local Addresses 466 The interface token, which is used as the Interface ID of IPv6 unicast 467 addresses [6] of a PPP interface, SHOULD be negotiated in the IPV6CP 468 phase of the PPP connection setup (see section 4.1). If no valid 469 interface token has been successfully negotiated, procedures for 470 recovering from such a case are unspecified. One approach is to 471 manually configure the interface token of the interface. 473 As long as the interface token is negotiated in the IPV6CP phase of 474 the PPP connection setup, it is redundant to perform duplicate 475 address detection as a part of the IPv6 Stateless Autoconfiguration 476 protocol [3]. Therefore it is recommended that for PPP links with the 477 IPV6CP Interface-Token option enabled the default value of the 478 DupAddrDetectTransmits autoconfiguration variable [3] be zero. 480 Link-local addresses of PPP interfaces have the following format: 482 | 10 bits | 54 bits | 64 bits | 483 +----------+------------------------+-----------------------------+ 484 |1111111010| 0 | Interface Token | 485 +----------+------------------------+-----------------------------+ 487 The most significant 10 bits of the address is the Link-Local prefix 488 FE80::. 54 zero bits pad out the address between the Link-Local 489 prefix and the Interface Token fields. 491 6. IPV6CP Recommended Options 493 The following Configurations Options are recommended: 495 Interface-Token 497 IPv6-Compression-Protocol 499 7. Security Considerations 501 The IPv6 Control Protocol extension to PPP can be used with all 502 defined PPP authentication and encryption mechanisms. 504 8. References 506 [1] Simpson, W., "The Point-to-Point Protocol", STD 51, RFC 1661, 507 July 1994. 509 [2] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 510 6 (IPv6) Specification", RFC 1883, December 1995. 512 [3] Thomson, S., and T. Narten, "IPv6 Stateless Address 513 Autoconfiguration", RFC 1971, August 1996. 515 [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 516 October 1994. 518 [5] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 519 Registration Authority", 520 http://standards.ieee.org/db/oui/tutorials/EUI64.html, 521 March 1997. 523 [6] Hinden, R., and S. Deering, "IP Version 6 Addressing 524 Architecture", Work in progress 526 9. Acknowledgements 528 This document borrows from the Magic-Number LCP option and as such is 529 partially based on previous work done by the PPP working group. 531 10. Authors' Addresses 533 Dimitry Haskin 534 Bay Networks, Inc. 535 2 Federal Street 536 Billerica, MA 01821 537 email: dhaskin@baynetworks.com 539 Ed Allen 540 Bay Networks, Inc. 541 2 Federal Street 542 Billerica, MA 01821 543 email: eallen@baynetworks.com