idnits 2.17.1 draft-ietf-ipngwg-pppext-ipv6cp-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-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 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 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: ---------------------------------------------------------------------------- == Line 306 has weird spacing: '... likely to b...' -- 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 (April 1996) is 10236 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 426, 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. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET-DRAFT Dimitry Haskin 3 Expires October 1996 Ed Allen 4 Bay Networks, Inc. 6 April 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 0057 (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 8057 (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 32-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, system clocks, etc. Note that it 207 may not be sufficient to use a link-layer address alone as the 208 seed, since it will not always be unique. Thus it is suggested 209 that the seed should be calculated from a variety of sources that 210 are likely to be different even on identical systems and as many 211 sources as possible be used simultaneously. Good sources of 212 uniqueness or randomness are required for the Interface-Token 213 negotiation to succeed. If a good source of randomness cannot be 214 found, it is recommended that a zero value be used for the 215 Interface-Token transmitted in the Configure-Request. In this case 216 the PPP peer may provide a valid non-zero Interface-Token in its 217 response as described below. Note that if at least one of the PPP 218 peers is able to generate a unique random number, the token 219 negotiation will succeed. 221 When a Configure-Request is received with the Interface-Token 222 Configuration Option and the receiving peer implements this option, 223 the received Interface-Token is compared with the Interface-Token 224 of the last Configure-Request sent to the peer. Depending on the 225 result of the comparison an implementation MUST respond in one of 226 the following ways: 228 If the two Interface-Tokens are different but the received 229 Interface-Token is zero, a Configure-Ack is sent with a non-zero 230 Interface-Token value suggested for use by the remote peer. 231 Such a suggested Interface-Token MUST be different from the 232 Interface-Token of the last Configure-Request sent to the peer. 234 If the two Interface-Tokens are different and the received 235 Interface-Token is not zero, the Interface-Token MUST be 236 acknowledged, i.e. a Configure-Ack is sent with the requested 237 Interface-Token, meaning that the responding peer agrees with 238 the Interface-Token requested. 240 If the two Interface-Tokens are equal and are not zero, a 241 Configure-Nak MUST be sent specifying a different non-zero 242 Interface-Token value suggested for use by the remote peer. 244 If the two Interface-Tokens are equal to zero, the 245 Interface-Tokens negotiation MUST be terminated by transmitting 246 the Configure-Reject with the Interface-Token value set to zero. 247 In this case a unique Interface-Token can not be negotiated. 249 If a Configure-Request is received with the Interface-Token 250 Configuration Option and the receiving peer does not implement 251 this option, Configure-Rej is sent. 253 A new Configure-Request SHOULD NOT be sent to the peer until normal 254 processing would cause it to be sent (that is, until a Configure- 255 Nak is received or the Restart timer runs out). 257 A new Configure-Request MUST NOT contain the Interface-Token option 258 if a valid Interface-Token Configure-Reject is received. 260 Reception of a Configure-Nak with a suggested Interface-Token 261 Configure-Nak from the peer. But if the received Interface-Token 262 is equal to the one sent in the last Configure-Nak, a new 263 Interface-Token MUST be chosen. In this case, a new Configure- 264 Request SHOULD be sent with the new tentative Interface-Token. 265 This sequence (transmit Configure-Request, receive Configure- 266 Request, transmit Configure-Nak, receive Configure-Nak) might 267 occur a few times, but it is extremely unlikely to occur 268 repeatedly. More likely, the Interface-Tokens chosen at either end 269 will quickly diverge, terminating the sequence. 271 If negotiation about the Interface-Token is required, and the peer 272 did not provide the option in its Configure-Request, the option 273 SHOULD be appended to a Configure-Nak. The tentative value of the 274 Interface-Token given must be acceptable as the remote 275 Interface-Token; i.e. should be different from the token value 276 selected for the local end of the PPP link. The next Configure- 277 Request from the peer may include this option. If the next 278 Configure-Request does not include this option the peer MUST NOT 279 send another Configure-Nak with this option included. It should 280 assume that the peer's implementation does not support this option. 282 By default, an implementation SHOULD attempt to negotiate the 283 Interface-Token for its end of the PPP connection. 285 A summary of the Interface-Token Configuration Option format is 286 shown below. The fields are transmitted from left to right. 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type | Length | Interface-Token 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Interface-Token (cont) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Type 298 1 300 Length 302 6 304 Interface-Token 306 The 32-bit Interface-Token which is very likely to be unique 307 to one end of the link or zero if a good sources of uniqueness 308 can not be found. 310 Default 312 No Interface-Token is selected. 314 4.2. IPv6-Compression-Protocol 316 Description 318 This Configuration Option provides a way to negotiate the use of 319 a specific IPv6 packet compression protocol. The IPv6-Compression- 320 Protocol Configuration Option is used to indicate the ability to 321 receive compressed packets. Each end of the link must separately 322 request this option if bi-directional compression is desired. By 323 default, compression is not enabled. 325 IPv6 compression negotiated with this option is specific to IPv6 326 datagrams and is not to be confused with compression resulting from 327 negotiations via Compression Control Protocol (CCP), which 328 potentially effect all datagrams. 330 A summary of the IPv6-Compression-Protocol Configuration Option format 331 is shown below. The fields are transmitted from left to right. 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type | Length | IPv6-Compression-Protocol | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Data ... 339 +-+-+-+-+ 341 Type 343 2 345 Length 347 >= 4 349 IPv6-Compression-Protocol 351 The IPv6-Compression-Protocol field is two octets and indicates 352 the compression protocol desired. Values for this field are always 353 the same as the PPP Data Link Layer Protocol field values for that 354 same compression protocol. 356 Up-to-date values of the IPv6-Compression-Protocol field are 357 specified in the most recent "Assigned Numbers" RFC [5]. 359 Current values are assigned as follows: 361 Value (in hex) Protocol 363 004f IPv6 Header Compression 365 Data 367 The Data field is zero or more octets and contains additional data 368 as determined by the particular compression protocol. 370 Default 372 No IPv6 compression protocol enabled. 374 5. Stateless Autoconfiguration and Link-Local Addresses 376 The interface token, which is used for forming IPv6 addresses of 377 a PPP interface, SHOULD be negotiated in the IPV6CP phase of the PPP 378 connection setup (see section 4.1). If no valid interface token has 379 been successfully negotiated, procedures for recovering from such 380 a case are unspecified. One approach is to manually configure 381 the interface token of the interface. 383 As long as the interface token is negotiated in the IPV6CP phase of 384 the PPP connection setup, it is redundant to perform duplicate 385 address detection as a part of the IPv6 Stateless Autoconfiguration 386 protocol [3]. Therefore it is recommended that for PPP links with 387 the IPV6CP Interface-Token option enabled the default value of the 388 DupAddrDetectTransmits autoconfiguration variable [3] be zero. 390 Link-local addresses of PPP interfaces have the following format: 392 | 10 bits | 86 bits | 32 bits | 393 +----------+--------------+---------------------+-----------------+ 394 |1111111010| 0 | Interface Token | 395 +----------+--------------+---------------------+-----------------+ 397 The most significant 10 bits of the address is the Link-Local prefix 398 FE80::. 86 zero bits pad out the address between the Link-Local 399 prefix and the Interface Token fields. 401 A. IPV6CP Recommended Options 403 The following Configurations Options are recommended: 405 Interface-Token 407 IPv6-Compression-Protocol 409 Security Considerations 411 Security issues are not discussed in this memo. 413 References 415 [1] W. Simpson, "The Point-to-Point Protocol", RFC 1661, July 1994. 417 [2] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 418 (IPv6) Specification", RFC 1883, December 1995. 420 [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 421 RFC 1884, December 1995. 423 [3] S. Thomson, T. Narten, "IPv6 Stateless Address 424 Autoconfiguration", Work in progress 426 [4] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery for 427 IP Version 6 (IPv6)", Work in progress 429 [5] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700, 430 October 1994. 432 Acknowledgments 434 This document borrows from the Magic-Number LCP option and as such is 435 partially based on previous work done by the PPP working group. 437 Authors' Addresses 439 Dimitry Haskin 440 Bay Networks, Inc. 441 2 Federal Street 442 Billerica, MA 01821 443 email: dhaskin@baynetworks.com 445 Ed Allen 446 Bay Networks, Inc. 447 2 Federal Street 448 Billerica, MA 01821 449 email: eallen@baynetworks.com