idnits 2.17.1 draft-ietf-ipngwg-pppext-ipv6cp-03.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-25) 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 12 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 101: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 104: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 107: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 113: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 115: '...h does not include this option MUST be...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 310 has weird spacing: '...kely to be un...' -- 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 1996) is 10207 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 432, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1884 (ref. '2') (Obsoleted by RFC 2373) -- 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) Summary: 14 errors (**), 0 flaws (~~), 3 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 November 1996 Ed Allen 5 Bay Networks, Inc. 7 May 1996 9 IP Version 6 over PPP 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check 25 the ``1id-abstracts.txt'' listing contained in the Internet- 26 Drafts Shadow Directories on ftp.is.co.za (Africa), 27 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 28 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 The Point-to-Point Protocol (PPP) [1] provides a standard method of 33 encapsulating Network Layer protocol information over point-to-point 34 links. PPP also defines an extensible Link Control Protocol, and 35 proposes a family of Network Control Protocols (NCPs) for 36 establishing and configuring different network-layer protocols. 38 This document defines the method for transmission of IP Version 6 [2] 39 packets over PPP links as well as the Network Control Protocol (NCP) 40 for establishing and configuring the IPv6 over PPP. It also specifies 41 the method of forming IPv6 link-local addresses on PPP links. 43 Table of Contents 45 1. Introduction .......................................... 2 46 1.1. Specification of Requirements ...................... 3 48 2. Sending IPv6 Datagrams ................................ 3 50 3. A PPP Network Control Protocol for IPv6 ............... 4 52 4. IPV6CP Configuration Options .......................... 5 53 4.1. Interface-Token ................................... 8 54 4.2. IPv6-Compression-Protocol 56 5. Stateless Autoconfiguration and Link-Local Addresses .. 9 58 A. IPV6CP Recommended Options ............................. 10 60 Security Considerations ....................................... 10 62 References .................................................... 10 64 Acknowledgments ............................................... 10 66 Authors' Addresses ............................................ 11 68 1. Introduction 70 PPP has three main components: 72 1. A method for encapsulating datagrams over serial links. 74 2. A Link Control Protocol (LCP) for establishing, configuring, 75 and testing the data-link connection. 77 3. A family of Network Control Protocols (NCPs) for establishing 78 and configuring different network-layer protocols. 80 In order to establish communications over a point-to-point link, each 81 end of the PPP link must first send LCP packets to configure and test 82 the data link. After the link has been established and optional 83 facilities have been negotiated as needed by the LCP, PPP must send 84 NCP packets to choose and configure one or more network-layer 85 protocols. Once each of the chosen network-layer protocols has been 86 configured, datagrams from each network-layer protocol can be sent 87 over the link. 89 In this document, the NCP for establishing and configuring the IPv6 90 over PPP is referred as the IPv6 Control Protocol (IPV6CP). 92 The link will remain configured for communications until explicit LCP 93 or NCP packets close the link down, or until some external event 94 occurs (power failure at the other end, carrier drop, etc.). 96 1.1. Specification of Requirements 98 In this document, several words are used to signify the requirements 99 of the specification. These words are often capitalized. 101 MUST This word, or the adjective "required", means that the 102 definition is an absolute requirement of the specification. 104 MUST NOT This phrase means that the definition is an absolute 105 prohibition of the specification. 107 SHOULD This word, or the adjective "recommended", means that there 108 may exist valid reasons in particular circumstances to 109 ignore this item, but the full implications must be 110 understood and carefully weighed before choosing a 111 different course. 113 MAY This word, or the adjective "optional", means that this 114 item is one of an allowed set of alternatives. An 115 implementation which does not include this option MUST be 116 prepared to inter-operate with another implementation which 117 does include the option. 119 2. Sending IPv6 Datagrams 121 Before any IPv6 packets may be communicated, PPP must reach the 122 Network-Layer Protocol phase, and the IPv6 Control Protocol must reach 123 the Opened state. 125 Exactly one IPv6 packet is encapsulated in the Information field of 126 PPP Data Link Layer frames where the Protocol field indicates type 127 hex 0057 (Internet Protocol Version 6). 129 The maximum length of an IPv6 packet transmitted over a PPP link is 130 the same as the maximum length of the Information field of a PPP data 131 link layer frame. PPP links supporting IPv6 must allow at least 576 132 octets in the information field of a data link layer frame. 134 3. A PPP Network Control Protocol for IPv6 136 The IPv6 Control Protocol (IPV6CP) is responsible for configuring, 137 enabling, and disabling the IPv6 protocol modules on both ends of the 138 point-to-point link. IPV6CP uses the same packet exchange mechanism 139 as the Link Control Protocol (LCP). IPV6CP packets may not be 140 exchanged until PPP has reached the Network-Layer Protocol phase. 141 IPV6CP packets received before this phase is reached should be 142 silently discarded. 144 The IPv6 Control Protocol is exactly the same as the Link Control 145 Protocol [1] with the following exceptions: 147 Data Link Layer Protocol Field 149 Exactly one IPV6CP packet is encapsulated in the Information field 150 of PPP Data Link Layer frames where the Protocol field indicates 151 type hex 8057 (IPv6 Control Protocol). 153 Code field 155 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 156 Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack 157 and Code-Reject) are used. Other Codes should be treated as 158 unrecognized and should result in Code-Rejects. 160 Timeouts 162 IPV6CP packets may not be exchanged until PPP has reached the 163 Network-Layer Protocol phase. An implementation should be 164 prepared to wait for Authentication and Link Quality Determination 165 to finish before timing out waiting for a Configure-Ack or other 166 response. It is suggested that an implementation give up only 167 after user intervention or a configurable amount of time. 169 Configuration Option Types 171 IPV6CP has a distinct set of Configuration Options, which are 172 defined below. 174 4. IPV6CP Configuration Options 176 IPV6CP Configuration Options allow negotiation of desirable IPv6 177 parameters. IPV6CP uses the same Configuration Option format defined 178 for LCP [1], with a separate set of Options. If a Configuration 179 Option is not included in a Configure-Request packet, the default 180 value for that Configuration Option is assumed. 182 Up-to-date values of the IPV6CP Option Type field are specified in 183 the most recent "Assigned Numbers" RFC [5]. Current values are 184 assigned as follows: 186 1 Interface-Token 187 2 IPv6-Compression-Protocol 189 4.1. Interface-Token 191 Description 193 This Configuration Option provides a way to negotiate a unique 194 32-bit interface token to be used for the address 195 autoconfiguration [3] at the local end of the link (see section 5). 196 The interface token MUST be unique within the PPP link; i.e. upon 197 completion of the negotiation different Interface-Token values are 198 to be selected for the ends of the PPP link. 200 Before this Configuration Option is requested, an implementation 201 must choose its tentative Interface-Token. It is recommended that 202 a non-zero value be chosen in the most random manner possible in 203 order to guarantee with very high probability that an 204 implementation will arrive at a unique token value. A good way to 205 choose a unique random number is to start with a unique seed. 206 Suggested sources of uniqueness include machine serial numbers, 207 other network hardware addresses, system clocks, etc. Note that it 208 may not be sufficient to use a link-layer address alone as the 209 seed, since it will not always be unique. Thus it is suggested 210 that the seed should be calculated from a variety of sources that 211 are likely to be different even on identical systems and as many 212 sources as possible be used simultaneously. Good sources of 213 uniqueness or randomness are required for the Interface-Token 214 negotiation to succeed. If a good source of randomness cannot be 215 found, it is recommended that a zero value be used for the 216 Interface-Token transmitted in the Configure-Request. In this case 217 the PPP peer may provide a valid non-zero Interface-Token in its 218 response as described below. Note that if at least one of the PPP 219 peers is able to generate a unique random number, the token 220 negotiation will succeed. 222 When a Configure-Request is received with the Interface-Token 223 Configuration Option and the receiving peer implements this option, 224 the received Interface-Token is compared with the Interface-Token 225 of the last Configure-Request sent to the peer. Depending on the 226 result of the comparison an implementation MUST respond in one of 227 the following ways: 229 If the two Interface-Tokens are different but the received 230 Interface-Token is zero, a Configure-Ack is sent with a non-zero 231 Interface-Token value suggested for use by the remote peer. 232 Such a suggested Interface-Token MUST be different from the 233 Interface-Token of the last Configure-Request sent to the peer. 235 If the two Interface-Tokens are different and the received 236 Interface-Token is not zero, the Interface-Token MUST be 237 acknowledged, i.e. a Configure-Ack is sent with the requested 238 Interface-Token, meaning that the responding peer agrees with 239 the Interface-Token requested. 241 If the two Interface-Tokens are equal and are not zero, a 242 Configure-Nak MUST be sent specifying a different non-zero 243 Interface-Token value suggested for use by the remote peer. 245 If the two Interface-Tokens are equal to zero, the 246 Interface-Tokens negotiation MUST be terminated by transmitting 247 the Configure-Reject with the Interface-Token value set to zero. 248 In this case a unique Interface-Token can not be negotiated. 250 If a Configure-Request is received with the Interface-Token 251 Configuration Option and the receiving peer does not implement 252 this option, Configure-Rej is sent. 254 A new Configure-Request SHOULD NOT be sent to the peer until normal 255 processing would cause it to be sent (that is, until a Configure- 256 Nak is received or the Restart timer runs out). 258 A new Configure-Request MUST NOT contain the Interface-Token option 259 if a valid Interface-Token Configure-Reject is received. 261 Reception of a Configure-Nak with a suggested Interface-Token 262 different from that of the last Configure-Nak sent to the peer 263 indicates a unique Interface-Token. In this case a new Configure- 264 Request MUST be sent with the token value suggested in the last 265 Configure-Nak from the peer. But if the received Interface-Token 266 is equal to the one sent in the last Configure-Nak, a new 267 Interface-Token MUST be chosen. In this case, a new Configure- 268 Request SHOULD be sent with the new tentative Interface-Token. 269 This sequence (transmit Configure-Request, receive Configure- 270 Request, transmit Configure-Nak, receive Configure-Nak) might 271 occur a few times, but it is extremely unlikely to occur 272 repeatedly. More likely, the Interface-Tokens chosen at either end 273 will quickly diverge, terminating the sequence. 275 If negotiation about the Interface-Token is required, and the peer 276 did not provide the option in its Configure-Request, the option 277 SHOULD be appended to a Configure-Nak. The tentative value of the 278 Interface-Token given must be acceptable as the remote 279 Interface-Token; i.e. should be different from the token value 280 selected for the local end of the PPP link. The next Configure- 281 Request from the peer may include this option. If the next 282 Configure-Request does not include this option the peer MUST NOT 283 send another Configure-Nak with this option included. It should 284 assume that the peer's implementation does not support this option. 286 By default, an implementation SHOULD attempt to negotiate the 287 Interface-Token for its end of the PPP connection. 289 A summary of the Interface-Token Configuration Option format is 290 shown below. The fields are transmitted from left to right. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | Interface-Token 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Interface-Token (cont) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Type 302 1 304 Length 306 6 308 Interface-Token 310 The 32-bit Interface-Token which is very likely to be unique on 311 the link or zero if a good source of uniqueness can not be found. 313 Default Token Value 315 If no valid interface token can be successfully negotiated, 316 no default Interface-Token value should be assumed. The procedures 317 for recovering from such a case are unspecified. One approach is 318 to manually configure the interface token of the interface. 320 4.2. IPv6-Compression-Protocol 322 Description 324 This Configuration Option provides a way to negotiate the use of 325 a specific IPv6 packet compression protocol. The IPv6-Compression- 326 Protocol Configuration Option is used to indicate the ability to 327 receive compressed packets. Each end of the link must separately 328 request this option if bi-directional compression is desired. By 329 default, compression is not enabled. 331 IPv6 compression negotiated with this option is specific to IPv6 332 datagrams and is not to be confused with compression resulting from 333 negotiations via Compression Control Protocol (CCP), which 334 potentially effect all datagrams. 336 A summary of the IPv6-Compression-Protocol Configuration Option format 337 is shown below. The fields are transmitted from left to right. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type | Length | IPv6-Compression-Protocol | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Data ... 345 +-+-+-+-+ 347 Type 349 2 351 Length 353 >= 4 355 IPv6-Compression-Protocol 357 The IPv6-Compression-Protocol field is two octets and indicates 358 the compression protocol desired. Values for this field are always 359 the same as the PPP Data Link Layer Protocol field values for that 360 same compression protocol. 362 Up-to-date values of the IPv6-Compression-Protocol field are 363 specified in the most recent "Assigned Numbers" RFC [5]. 365 Current values are assigned as follows: 367 Value (in hex) Protocol 369 004f IPv6 Header Compression 371 Data 373 The Data field is zero or more octets and contains additional data 374 as determined by the particular compression protocol. 376 Default 378 No IPv6 compression protocol enabled. 380 5. Stateless Autoconfiguration and Link-Local Addresses 382 The interface token, which is used for forming IPv6 addresses of 383 a PPP interface, SHOULD be negotiated in the IPV6CP phase of the PPP 384 connection setup (see section 4.1). If no valid interface token has 385 been successfully negotiated, procedures for recovering from such 386 a case are unspecified. One approach is to manually configure 387 the interface token of the interface. 389 As long as the interface token is negotiated in the IPV6CP phase of 390 the PPP connection setup, it is redundant to perform duplicate 391 address detection as a part of the IPv6 Stateless Autoconfiguration 392 protocol [3]. Therefore it is recommended that for PPP links with 393 the IPV6CP Interface-Token option enabled the default value of the 394 DupAddrDetectTransmits autoconfiguration variable [3] be zero. 396 Link-local addresses of PPP interfaces have the following format: 398 | 10 bits | 86 bits | 32 bits | 399 +----------+--------------+---------------------+-----------------+ 400 |1111111010| 0 | Interface Token | 401 +----------+--------------+---------------------+-----------------+ 403 The most significant 10 bits of the address is the Link-Local prefix 404 FE80::. 86 zero bits pad out the address between the Link-Local 405 prefix and the Interface Token fields. 407 A. IPV6CP Recommended Options 409 The following Configurations Options are recommended: 411 Interface-Token 413 IPv6-Compression-Protocol 415 Security Considerations 417 Security issues are not discussed in this memo. 419 References 421 [1] W. Simpson, "The Point-to-Point Protocol", RFC 1661, July 1994. 423 [2] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 424 (IPv6) Specification", RFC 1883, December 1995. 426 [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 427 RFC 1884, December 1995. 429 [3] S. Thomson, T. Narten, "IPv6 Stateless Address 430 Autoconfiguration", Work in progress 432 [4] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery for 433 IP Version 6 (IPv6)", Work in progress 435 [5] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700, 436 October 1994. 438 Acknowledgments 440 This document borrows from the Magic-Number LCP option and as such is 441 partially based on previous work done by the PPP working group. 443 Authors' Addresses 445 Dimitry Haskin 446 Bay Networks, Inc. 447 2 Federal Street 448 Billerica, MA 01821 449 email: dhaskin@baynetworks.com 451 Ed Allen 452 Bay Networks, Inc. 453 2 Federal Street 454 Billerica, MA 01821 455 email: eallen@baynetworks.com