idnits 2.17.1 draft-ietf-ipngwg-pppext-ipv6cp-01.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 9 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...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 303 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 (February 1996) is 10297 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 418, 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 August 1996 Ed Allen 5 Bay Networks, Inc. 7 February 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 0xxx (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 8xxx (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 48-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. 218 Note that if at least one of the PPP peers is able to generate 219 a unique random number, the token 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, the Interface-Token 229 MUST be acknowledged, i.e. Configure-Ack is sent with the 230 requested Interface-Token, meaning that the responding peer 231 agrees with the Interface-Token requested. 233 If the two Interface-Tokens are equal and are not zero, a 234 Configure-Nak MUST be sent specifying a different non-zero 235 Interface-Token value suggested for use by the remote peer. 237 If the two Interface-Tokens are equal to zero, the 238 Interface-Tokens negotiation MUST be terminated by transmitting 239 the Configure-Reject with the Interface-Token value set to zero. 240 In this case, a unique Interface-Token can not be negotiated. 242 If a Configure-Request is received with the Interface-Token 243 Configuration Option and the receiving peer does not implement 244 this option, Configure-Rej is sent. 246 A new Configure-Request SHOULD NOT be sent to the peer until normal 247 processing would cause it to be sent (that is, until a Configure- 248 Nak is received or the Restart timer runs out). 250 A new Configure-Request MUST NOT contain the Interface-Token option 251 if a valid Interface-Token Configure-Reject is received. 253 Reception of a Configure-Nak with a suggested Interface-Token 254 different from that of the last Configure-Nak sent to the peer 255 indicates a unique Interface-Token. In this case a new Configure- 256 Request MUST be sent with the token value suggested in the last 257 Configure-Nak from the peer. But if the received Interface-Token 258 is equal to the one sent in the last Configure-Nak, a new 259 Interface-Token MUST be chosen. In this case, a new Configure- 260 Request SHOULD be sent with the new tentative Interface-Token. 262 This sequence (transmit Configure-Request, receive Configure- 263 Request, transmit Configure-Nak, receive Configure-Nak) might 264 occur a few times, but it is extremely unlikely to occur 265 repeatedly. More likely, the Interface-Tokens chosen at either end 266 will quickly diverge, terminating the sequence. 268 If negotiation about the Interface-Token is required, and the peer 269 did not provide the option in its Configure-Request, the option 270 SHOULD be appended to a Configure-Nak. The tentative value of the 271 Interface-Token given must be acceptable as the remote 272 Interface-Token; i.e. should be different from the token value 273 selected for the local end of the PPP link. The next Configure- 274 Request from the peer may include this option. If the next 275 Configure-Request does not include this option the peer MUST NOT 276 send another Configure-Nak with this option included. It should 277 assume that the peer's implementation does not support this option. 279 By default, an implementation SHOULD attempt to negotiate the 280 Interface-Token for its end of the PPP connection. 282 A summary of the Interface-Token Configuration Option format is 283 shown below. The fields are transmitted from left to right. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Type | Length | Interface-Token 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Interface-Token (cont) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Type 295 1 297 Length 299 8 301 Interface-Token 303 The 48-bit Interface-Token which is very likely to be unique 304 to one end of the link or zero if a good sources of uniqueness 305 can not be found. 307 Default 309 No Interface-Token is selected. 311 4.2. IPv6-Compression-Protocol 313 Description 315 This Configuration Option provides a way to negotiate the use of 316 a specific compression protocol. The IPv6-Compression-Protocol 317 Configuration Option is used to indicate the ability to receive 318 compressed packets. Each end of the link must separately request 319 this option if bi-directional compression is desired. By default, 320 compression is not enabled. 322 A summary of the IPv6-Compression-Protocol Configuration Option format 323 is shown below. The fields are transmitted from left to right. 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type | Length | IPv6-Compression-Protocol | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Data ... 331 +-+-+-+-+ 333 Type 335 2 337 Length 339 >= 4 341 IPv6-Compression-Protocol 343 The IPv6-Compression-Protocol field is two octets and indicates 344 the compression protocol desired. Values for this field are always 345 the same as the PPP Data Link Layer Protocol field values for that 346 same compression protocol. 348 Up-to-date values of the IPv6-Compression-Protocol field are 349 specified in the most recent "Assigned Numbers" RFC [5]. 351 Current values are assigned as follows: 353 Value (in hex) Protocol 355 004f IPv6 Header Compression 357 Data 359 The Data field is zero or more octets and contains additional data 360 as determined by the particular compression protocol. 362 Default 364 No compression protocol enabled. 366 5. Stateless Autoconfiguration and Link-Local Addresses 368 The interface token, which is used for forming IPv6 addresses of 369 a PPP interface, SHOULD be negotiated in the IPV6CP phase of the PPP 370 connection setup (see section 4.1). If no valid interface token has 371 been successfully negotiated, procedures for recovering from such 372 a case are unspecified. One approach is to manually configure 373 the interface token of the interface. 375 As long as the interface token is negotiated in the IPV6CP phase of 376 the PPP connection setup, it is redundant to perform duplicate 377 address detection as a part of the IPv6 Stateless Autoconfiguration 378 protocol [3]. Therefore it is recommended that for PPP links with 379 the IPV6CP Interface-Token option enabled the default value of the 380 DupAddrDetectTransmits autoconfiguration variable [3] be zero. 382 Link-local addresses of PPP interfaces have the following format: 384 | 10 bits | 70 bits | 48 bits | 385 +----------+--------------+----------------+----------------------+ 386 |1111111010| 0 | Interface Token | 387 +----------+--------------+----------------+----------------------+ 389 The most significant 10 bits of the address is the Link-Local prefix 390 FE80::. 70 zero bits pad out the address between the Link-Local 391 prefix and the Interface Token fields. 393 A. IPV6CP Recommended Options 395 The following Configurations Options are recommended: 397 Interface-Token 399 IPv6-Compression-Protocol 401 Security Considerations 403 Security issues are not discussed in this memo. 405 References 407 [1] W. Simpson, "The Point-to-Point Protocol", RFC 1661, July 1994. 409 [2] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 410 (IPv6) Specification", RFC 1883, December 1995. 412 [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 413 RFC 1884, December 1995. 415 [3] S. Thomson, T. Narten, "IPv6 Stateless Address 416 Autoconfiguration", Work in progress 418 [4] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery for 419 IP Version 6 (IPv6)", Work in progress 421 [5] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700, 422 October 1994. 424 Acknowledgments 426 This document borrows from the Magic-Number LCP option and as such is 427 partially based on previous work done by the PPP working group. 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