idnits 2.17.1 draft-ietf-ipngwg-pppext-ipv6cp-00.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-24) 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 11 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 4 instances of lines with control characters in the document. ** 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 100: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 103: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 106: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 112: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 114: '...h does not include this option MUST be...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 1996) is 10327 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: '4' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'TBA' is defined on line 427, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1700 (ref. '5') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'TBA' Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 Internet Draft Dimitry Haskin 3 Expires July 1996 Ed Allen 4 Bay Networks, Inc. 6 January 1996 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 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), 26 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or 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 35 establishing 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 .......................................... 2 45 1.1. Specification of Requirements ...................... 3 47 2. Sending IPv6 Datagrams ................................ 3 49 3. A PPP Network Control Protocol for IPv6 ............... 4 51 4. IPV6CP Configuration Options .......................... 5 52 4.1. Interface-Token ................................... 8 53 4.2. IPv6-Compression-Protocol 55 5. Stateless Autoconfiguration and Link-Local Addresses .. 9 57 A. IPV6CP Recommended Options ............................. 10 59 Security Considerations ....................................... 10 61 References .................................................... 10 63 Acknowledgments ............................................... 10 65 Authors' Addresses ............................................ 11 67 1. Introduction 69 PPP has three main components: 71 1. A method for encapsulating datagrams over serial links. 73 2. A Link Control Protocol (LCP) for establishing, configuring, 74 and testing the data-link connection. 76 3. A family of Network Control Protocols (NCPs) for establishing 77 and configuring different network-layer protocols. 79 In order to establish communications over a point-to-point link, each 80 end of the PPP link must first send LCP packets to configure and test 81 the data link. After the link has been established and optional 82 facilities have been negotiated as needed by the LCP, PPP must send 83 NCP packets to choose and configure one or more network-layer 84 protocols. Once each of the chosen network-layer protocols has been 85 configured, datagrams from each network-layer protocol can be sent 86 over the link. 88 In this document, the NCP for establishing and configuring the IPv6 89 over PPP is referred as the IPv6 Control Protocol (IPV6CP). 91 The link will remain configured for communications until explicit LCP 92 or NCP packets close the link down, or until some external event 93 occurs (power failure at the other end, carrier drop, etc.). 95 1.1. Specification of Requirements 97 In this document, several words are used to signify the requirements 98 of the specification. These words are often capitalized. 100 MUST This word, or the adjective "required", means that the 101 definition is an absolute requirement of the specification. 103 MUST NOT This phrase means that the definition is an absolute 104 prohibition of the specification. 106 SHOULD This word, or the adjective "recommended", means that there 107 may exist valid reasons in particular circumstances to 108 ignore this item, but the full implications must be 109 understood and carefully weighed before choosing a 110 different course. 112 MAY This word, or the adjective "optional", means that this 113 item is one of an allowed set of alternatives. An 114 implementation which does not include this option MUST be 115 prepared to inter-operate with another implementation which 116 does include the option. 118 2. Sending IPv6 Datagrams 120 Before any IPv6 packets may be communicated, PPP must reach the 121 Network-Layer Protocol phase, and the IPv6 Control Protocol must reach 122 the Opened state. 124 Exactly one IPv6 packet is encapsulated in the Information field of 125 PPP Data Link Layer frames where the Protocol field indicates type 126 hex 0xxx (Internet Protocol Version 6). 128 The maximum length of an IPv6 packet transmitted over a PPP link is 129 the same as the maximum length of the Information field of a PPP data 130 link layer frame. PPP links supporting IPv6 must allow at least 576 131 octets in the information field of a data link layer frame. 133 3. A PPP Network Control Protocol for IPv6 135 The IPv6 Control Protocol (IPV6CP) is responsible for configuring, 136 enabling, and disabling the IPv6 protocol modules on both ends of the 137 point-to-point link. IPV6CP uses the same packet exchange mechanism 138 as the Link Control Protocol (LCP). IPV6CP packets may not be 139 exchanged until PPP has reached the Network-Layer Protocol phase. 140 IPV6CP packets received before this phase is reached should be 141 silently discarded. 143 The IPv6 Control Protocol is exactly the same as the Link Control 144 Protocol [1] with the following exceptions: 146 Data Link Layer Protocol Field 148 Exactly one IPV6CP packet is encapsulated in the Information field 149 of PPP Data Link Layer frames where the Protocol field indicates 150 type hex 8xxx (IPv6 Control Protocol). 152 Code field 154 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 155 Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack 156 and Code-Reject) are used. Other Codes should be treated as 157 unrecognized and should result in Code-Rejects. 159 Timeouts 161 IPV6CP packets may not be exchanged until PPP has reached the 162 Network-Layer Protocol phase. An implementation should be 163 prepared to wait for Authentication and Link Quality Determination 164 to finish before timing out waiting for a Configure-Ack or other 165 response. It is suggested that an implementation give up only 166 after user intervention or a configurable amount of time. 168 Configuration Option Types 170 IPV6CP has a distinct set of Configuration Options, which are 171 defined below. 173 4. IPV6CP Configuration Options 175 IPV6CP Configuration Options allow negotiation of desirable IPv6 176 parameters. IPV6CP uses the same Configuration Option format defined 177 for LCP [1], with a separate set of Options. If a Configuration 178 Option is not included in a Configure-Request packet, the default 179 value for that Configuration Option is assumed. 181 Up-to-date values of the IPV6CP Option Type field are specified in 182 the most recent "Assigned Numbers" RFC [5]. Current values are 183 assigned as follows: 185 1 Interface-Token 186 2 IPv6-Compression-Protocol 188 4.1. Interface-Token 190 Description 192 This Configuration Option provides a way to negotiate a unique 193 64-bit interface token to be used for the address 194 autoconfiguration [3] at the local end of the link (see section 5). 195 The interface token MUST be unique within the PPP link; i.e. upon 196 completion of the negotiation different Interface-Token values are 197 to be selected for the ends of the PPP link. 199 Before this Configuration Option is requested, an implementation 200 must choose its tentative Interface-Token. It is recommended that 201 a non-zero value be chosen in the most random manner possible in 202 order to guarantee with very high probability that an 203 implementation will arrive at a unique token value. A good way to 204 choose a unique random number is to start with a unique seed. 205 Suggested sources of uniqueness include machine serial numbers, 206 other network hardware addresses, time-of-day clocks, etc. 207 Note that it may not be sufficient to use a link-layer address 208 alone as the seed, since it will not always be unique. Thus 209 it is suggested that the seed should be calculated from a variety 210 of sources that are likely to be different even on identical 211 systems and as many sources as possible be used simultaneously. 212 Good sources of uniqueness or randomness are required for the 213 Interface-Token negotiation to succeed. If a good source of 214 randomness cannot be found, it is recommended that a zero 215 value be used for the Interface-Token transmitted in the 216 Configure-Request. Note that if at least one of the PPP peers 217 is able to generate a unique random number, the token negotiation 218 will succeed. 220 When a Configure-Request is received with the Interface-Token 221 Configuration Option and the receiving peer implements this option, 222 the received Interface-Token is compared with the Interface-Token 223 of the last Configure-Request sent to the peer. Depending on the 224 result of the comparison an implementation MUST respond in one of 225 the following ways: 227 If the two Interface-Tokens are different, the Interface-Token 228 MUST be acknowledged, i.e. Configure-Ack is sent with the 229 requested Interface-Token, meaning that the responding peer 230 agrees with the Interface-Token requested. 232 If the two Interface-Tokens are equal and are not zero, a 233 Configure-Nak MUST be sent specifying a different non-zero 234 Interface-Token value suggested for use by the remote peer. 236 If the two Interface-Tokens are equal to zero, the 237 Interface-Tokens negotiation MUST be terminated by transmitting 238 the Configure-Reject with the Interface-Token value set to zero. 239 In this case, a unique Interface-Token can not be negotiated. 241 If a Configure-Request is received with the Interface-Token 242 Configuration Option and the receiving peer does not implement 243 this option, Configure-Rej is sent. 245 A new Configure-Request SHOULD NOT be sent to the peer until normal 246 processing would cause it to be sent (that is, until a Configure- 247 Nak is received or the Restart timer runs out). 249 A new Configure-Request MUST NOT contain the Interface-Token option 250 if a valid Interface-Token Configure-Reject is received. 252 Reception of a Configure-Nak with a suggested Interface-Token 253 different from that of the last Configure-Nak sent to the peer 254 indicates a unique Interface-Token. In this case a new Configure- 255 Request MUST be sent with the token value suggested in the last 256 Configure-Nak from the peer. But if the received Interface-Token 257 is equal to the one sent in the last Configure-Nak, a new 258 Interface-Token MUST be chosen. In this case, a new Configure- 259 Request SHOULD be sent with the new tentative Interface-Token. 261 This sequence (transmit Configure-Request, receive Configure- 262 Request, transmit Configure-Nak, receive Configure-Nak) might 263 occur a few times, but it is extremely unlikely to occur 264 repeatedly. More likely, the Interface-Tokens chosen at either end 265 will quickly diverge, terminating the sequence. 267 If negotiation about the Interface-Token is required, and the peer 268 did not provide the option in its Configure-Request, the option 269 SHOULD be appended to a Configure-Nak. The tentative value of the 270 Interface-Token given must be acceptable as the remote 271 Interface-Token; i.e. should be different from the token value 272 selected for the local end of the PPP link. The next Configure- 273 Request from the peer may include this option. If the next 274 Configure-Request does not include this option the peer MUST NOT 275 send another Configure-Nak with this option included. It should 276 assume that the peer's implementation does not support this option. 278 By default, an implementation SHOULD attempt to negotiate the 279 Interface-Token for its end of the PPP connection. 281 A summary of the Interface-Token Configuration Option format is 282 shown below. The fields are transmitted from left to right. 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Type | Length | Interface-Token 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Interface-Token (cont) 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Interface-Token (cont) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Type 296 1 298 Length 300 10 302 Interface-Token 304 The 64-bit Interface-Token which is very likely to be unique 305 to one end of the link or zero if a good sources of uniqueness 306 can not be found. 308 Default 310 No Interface-Token is selected. 312 4.2. IPv6-Compression-Protocol 314 Description 316 This Configuration Option provides a way to negotiate the use of a 317 specific compression protocol. The IPv6-Compression-Protocol 318 Configuration Option is used to indicate the ability to receive 319 compressed packets. Each end of the link must separately request 320 this option if bi-directional compression is desired. By default, 321 compression is not enabled. 323 A summary of the IPv6-Compression-Protocol Configuration Option format 324 is shown below. The fields are transmitted from left to right. 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type | Length | IPv6-Compression-Protocol | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Data ... 332 +-+-+-+-+ 334 Type 336 2 338 Length 340 >= 4 342 IPv6-Compression-Protocol 344 The IPv6-Compression-Protocol field is two octets and indicates the 345 compression protocol desired. Values for this field are always 346 the same as the PPP Data Link Layer Protocol field values for that 347 same compression protocol. 349 Up-to-date values of the IPv6-Compression-Protocol field are 350 specified in the most recent "Assigned Numbers" RFC [5]. 352 Current values are assigned as follows: 354 Value (in hex) Protocol 356 004f IPv6 Header Compression 358 Data 360 The Data field is zero or more octets and contains additional data 361 as determined by the particular compression protocol. 363 Default 365 No compression protocol enabled. 367 5. Stateless Autoconfiguration and Link-Local Addresses 369 The interface token, which is used for forming IPv6 addresses of 370 a PPP interface, SHOULD be negotiated in the IPV6CP phase of the PPP 371 connection setup (see section 4.1). If no valid interface token has 372 been successfully negotiated, procedures for recovering from such a 373 case are unspecified. One approach is to manually configure all IPv6 374 addresses of the interface. 376 Link-local addresses of PPP interfaces have the following format: 378 | 10 bits | 16 bits | 38 bits | 64 bits | 379 +----------+--------------+----------------+----------------------+ 380 |1111111010| Interface ID | 0 | Interface Token | 381 +----------+--------------+----------------+----------------------+ 383 The most significant 10 bits of the address is the Link-Local prefix 384 FE80::. Other address fields are as followed: 386 Interface ID - [Robert Elz will provide the text for the 387 "Interface ID" description]. 389 Interface Token - the 64-bit link-unique interface token. 391 38 zero bits pad out the address between the Interface ID and the 392 Interface Token fields. 394 A. IPV6CP Recommended Options 396 The following Configurations Options are recommended: 398 Interface-Token 400 IPv6-Compression-Protocol 402 Security Considerations 404 Security issues are not discussed in this memo. 406 References 408 [1] W. Simpson, "The Point-to-Point Protocol", RFC 1661, July 1994. 410 [2] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 411 (IPv6) Specification", Internet Draft. 413 [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 414 Internet Draft 416 [3] S. Thomson, T. Narten, "IPv6 Stateless Address 417 Autoconfiguration", Internet Draft 419 [4] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery for IP 420 Version 6 (IPv6)", Internet Draft 422 [5] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700, 423 October 1994. 425 Acknowledgments 427 [TBA] 429 Authors' Addresses 431 Dimitry Haskin 432 Bay Networks, Inc. 433 2 Federal Street 434 Billerica, MA 01821 435 email: dhaskin@baynetworks.com 437 Ed Allen 438 Bay Networks, Inc. 439 2 Federal Street 440 Billerica, MA 01821 441 email: eallen@baynetworks.com