idnits 2.17.1 draft-ietf-pppext-scm-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-03-28) 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 18 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([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 128: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 131: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 134: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 140: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 142: '...h does not include this option MUST be...' (48 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 619 has weird spacing: '...no peer rel =...' == Line 624 has weird spacing: '...no peer set =...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Remote host implementations SHOULD impose a lower boundary for the Idle timer. Considering that the most of the traffic flows use TCP the lower boundary SHOULD not be less than RTO preventing the physical link from being terminated while the remote host is waiting for an acknowledgement. However, because the value of RTO varies in time based on the state of a link(s) the only recommendation that can be given is that the value of the Idle timer SHOULD be no less than 3 sec which [6] is specified as an initial RTO value. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '9' is mentioned on line 339, but not defined == Unused Reference: '2' is defined on line 563, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-09 ** Obsolete normative reference: RFC 2138 (ref. '4') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '5') (Obsoleted by RFC 2866) -- No information found for draft-ietf-pppext-sessid - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Point-to-Point Protocol Extension Group Mikael Latvala 3 INTERNET DRAFT Oy L M Ericsson Ab 4 Expires May, 1999 November, 1998 6 Semi Connected Mode for PPP links 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this memo is unlimited. 29 Abstract 31 The Point-to-Point Protocol (PPP) [1] provides a standard method for 32 transporting multi-protocol datagrams over point-to-point links. 34 This document introduces a new PPP feature called Semi Connected 35 Mode. When both sides of a point-to-point link agree to use Semi Con- 36 nected Mode, either side can transparently disconnect and re- 37 establish a circuit-switched connection without having to reconfigure 38 the point-to-point link each time. 40 Table of Contents 42 1. Introduction .......................................... 3 43 1.1 Specification of Requirements ................... 5 44 1.2 Terminology ..................................... 5 45 2. Operation ............................................. 7 46 2.1 SCM negotiation ....................................... 7 47 2.2 Terminating and re-establishing a physical link ....... 8 48 3. LCP Configuration Option for SCM ...................... 10 49 4. Implementation Requirements ........................... 11 50 4.1 Remote hosts .................................... 11 51 4.2 Network Access Servers .......................... 11 52 4.2 Roaming hosts ................................... 13 53 5. Timers ................................................ 15 54 6. Security Considerations ............................... 16 55 REFERENCES ................................................... 16 56 CONTACTS ..................................................... 17 57 Appendix A: LCP Translation Table ............................ 18 59 1. Introduction 61 General Switched Telephone Networks (GSTN) are not well suited for 62 bursty data traffic because the end user is charged for the duration 63 of a circuit-switched connection even though he utilizes the 64 connection only for a fraction of the total connection length. 66 The current practice among the GSTN customers using circuit-switched 67 data services is to disconnect the link manually when there is no 68 data to send or to receive. This is feasible as long as the user does 69 not need to disconnect and reconnect the link too often and knows 70 when he wants to receive or send data, e.g. when one is reading or 71 sending email. But when the traffic pattern is more unpredictable 72 this becomes quite a tedious or even impossible task, e.g. when one 73 surfs the web or unexpectedly receives a VoIP call request. In 74 addition, some GSTNs, i.e. cellular networks, suffer from long end- 75 to-end delays so that disconnection/reconnection of a physical link 76 is no longer transparent to the user. Therefore it would be 77 convenient if there were a mechanism which would automatically drop a 78 circuit-switched connection if it had been idle for a pre-defined 79 amount of time and re-establish it without having to go through the 80 PPP configuration process when there is data to send or receive. 82 The concept of dropping the connection without informing the data 83 link layer was introduced in RFC1662 [3]. RFC1662 says that the 84 implementation may "choose to disconnect the physical layer during 85 periods of inactivity". This approach, however, has three problems: 87 1. Currently there is no mechanism to identify a PPP session. 88 It is crucial that in cases where CLID information is not 89 available, implementations can associate a re-established 90 circuit-switched connection with the existing PPP session. 91 PPP Session-Identifier is described in [10]. 93 2. The PPP implementation cannot advise the peer what the peer 94 should do in case it receives a packet(s) destined for the 95 host in which the implementation is running. Many remote 96 host users insist that they have a final say in whether or 97 not the peer (usually Network Access Server, NAS) can re- 98 establish the physical link. 100 3. The implementation cannot know whether or not the peer 101 supports the functionality of disconnecting a circuit- 102 switched connection without terminating the PPP session. The 103 only way to deduce this is to probe the peer by sending it a 104 network-layer packet. If the peer does not support this 105 functionality it discards the packet and initiates the PPP 106 link configuration. The discarded packet and the unexpected 107 delay caused by the link configuration have a negative 108 impact on TCP performance, e.g. on short HTTP transactions. 109 This is especially harmful when the implementation attempts 110 to use the circuit-switched connection in a packet-switched 111 manner. 113 To fix these problems and to give this concept a more formal standing 114 among other PPP features this document introduces a new PPP feature 115 called Semi Connected Mode (SCM). When properly configured, SCM 116 allows PPP to re-establish a physical link without having to go 117 through the PPP configuration process thus reducing the data 118 connection setup time. This document introduces a PPP option which 119 allows the implementation to find out whether or not NAS supports the 120 SCM feature and to inform the peer of its ability to accept mobile 121 terminated calls. 123 1.1. Specification of Requirements 125 In this document, several words are used to signify the requirements 126 of the specification. These words are often capitalized. 128 MUST This word, or the adjective "required", means that the 129 definition is an absolute requirement of the specification. 131 MUST NOT This phrase means that the definition is an absolute 132 prohibition of the specification. 134 SHOULD This word, or the adjective "recommended", means that there 135 may exist valid reasons in particular circumstances to 136 ignore this item, but the full implications must be 137 understood and carefully weighed before choosing a 138 different course. 140 MAY This word, or the adjective "optional", means that this 141 item is one of an allowed set of alternatives. An 142 implementation which does not include this option MUST be 143 prepared to interoperate with another implementation which 144 does include the option. 146 1.2. Terminology 148 datagram The unit of transmission in the network layer (such as 149 IP). A datagram may be encapsulated in one or more 150 packets passed to the data link layer. 152 frame The unit of transmission at the data link layer. A 153 frame may include a header and/or a trailer, along with 154 some number of units of data. 156 packet The basic unit of encapsulation, which is passed across 157 the interface between the network layer and the data 158 link layer. A packet is usually mapped to a frame; the 159 exceptions are when data link layer fragmentation is 160 being performed, or when multiple packets are 161 incorporated into a single frame. 163 peer The other end of the point-to-point link. 165 NAS A device which is used to terminate dial-up access to a 166 network. 168 CLID Calling Line ID, an indication to the receiver of a 169 call as to the phone number of the caller. 171 PPP session A PPP session is a time interval during which the 172 options negotiated by the Link Control Protocol remain 173 unchanged. The session starts when the LCP reaches the 174 Open state and is concluded by the LCP Terminate- 175 Request packet sent by either end of the point-to-point 176 link. 178 2. Operation 180 Semi Connected Mode is a new feature in PPP which allows PPP 181 implementations to terminate and re-establish a physical link without 182 having to reconfigure the point-to-point link. This chapter explains 183 how SCM is negotiated and used. Appendix A describes a modified LCP 184 state transition table for reference. 186 Nota Bene: 188 PPP is inherently a symmetrical protocol, i.e. it does not 189 differentiate between the hosts on either end of the point-to- 190 point link. This allows both uplink and downlink to be configured 191 independently of each other. This chapter presents the operation 192 of SCM bearing in mind the symmetrical nature of PPP. 194 However, the way SCM is implemented makes a clear distinction 195 between PPP implementations running on a remote host (client) and 196 on a NAS (server) because customers using dial-up services want to 197 fully control if and when the circuit-switched connection is 198 dropped, and whether or not the server is allowed to re-establish 199 the circuit-switched connection. Furthermore, only NASs should 200 assign PPP Session-Identifier for point-to-point links because 201 remote hosts lack the necessary information to guarantee the 202 uniqueness of a PPP Session-Identifier within the access network. 204 Chapter 5 explains how the SCM implementation differs between 205 remote hosts and NASs. 207 2.1 SCM negotiation 209 The use of SCM is negotiated during the link establishment phase. The 210 implementation includes the SCM option in a Configure-Request packet 211 thus indicating to the peer its willingness to use SCM. 213 When the peer receives a Configure-Request packet which has the SCM 214 option it can respond to it in three different ways: 216 1. If the peer has implemented the SCM feature, is ready to use 217 it, and has accepted the Remote-Term field value it MUST 218 include the SCM option in a Configure-Ack. 220 2. If the peer supports the SCM feature, but the implementation 221 indicated to the peer that it is ready to accept remote host 222 terminating calls (Remote-Term field) when the peer is 223 actually not able or willing to initiate a call setup 224 procedure, the peer MUST send a Configure-Nak and include 225 the unmodified SCM option in the packet. 227 3. If the peer does not support the SCM feature it MUST send a 228 Configure-Reject and include the unmodified SCM option in 229 the packet. 231 Both sides of a point-to-point link must also agree on a PPP 232 Session-Identifier so that the side which accepts a newly re- 233 established physical link (i.e. callee) can associate the physical 234 link with one of the existing PPP sessions. 236 The side of a point-to-point link which can guarantee that the chosen 237 value of a Session-Identifier is always unique within the access 238 network MUST include the Session-Identifier option in a Configure- 239 Request packet (see chapter 5). 241 2.2 Terminating and re-establishing a physical link 243 After having agreed to use SCM and the PPP link has been properly 244 configured (including PPP Session-Identifier) both sides can start 245 sending and receiving network layer packets. If the link has remained 246 idle more than the allowed number of seconds (Idle timer) the 247 implementation MUST terminate the physical link without signaling the 248 Down event. 250 When the peer notices that the implementation has terminated the 251 physical link it MUST mark the time of the event. Later on it uses 252 this value to determine if that link has been idle more than the 253 allowed time. The peer MUST remove all the PPP sessions from the 254 database which uses SCM and whose physical link has been down more 255 than the time specified by the Expiration timer. 257 When the physical link is down and the implementation receives a 258 packet from the network layer it MUST: 260 1. re-establish the circuit-switched connection. If the 261 implementation cannot re-establish the physical link 262 immediately (e.g. received a busy signal) it SHOULD try to 263 re-establish the link "a few times" before signaling the 264 Down event and discarding the network packet. 266 2. send a LCP Identification packet [9] which carries the value 267 of the Session-Identifier negotiated during the link 268 establishment phase to the peer so that the peer can 269 associate the physical link with the right PPP session. 271 3. and finally, start sending network layer packets to the 272 peer. If the implementation receives a Configure-Request 273 from the peer after re-establishing the physical link (e.g. 274 database holding the current PPP session information was 275 destroyed or the PPP session entry expired) it MUST re- 276 configure the PPP link according to [1]. 278 3. LCP Configuration Option for SCM 280 Description 282 The LCP configuration option for SCM allows the remote host 283 and the NAS implementations to negotiate whether SCM is used. 284 By default SCM is disabled. 286 Only the remote host implementation can include the SCM option 287 in Configure-Request packets. The remote host implementation 288 indicates in the Remote-Term field if it accepts remote host 289 terminating calls. 291 A summary of the SCM Configuration Option format is shown below. 292 The fields are transmitted from left to right. 294 0 1 2 295 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length | Remote-Term | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Type 302 TBD 304 Length 306 3 308 Remote-Term 310 The Remote-Term field is one octet and indicates whether the 311 implementation accepts call setup requests (terminating call). 312 If the implementation does not accept remote host terminating 313 calls the peer SHOULD drop all the packets destined to the 314 remote host when the physical link between the remote host and 315 NAS is down. Acceptable values of the Remote-Term field are: 317 0 The remote host does not accept call setup requests. 319 1 The remote host accepts call setup requests. 321 4. Implementation Requirements 323 4.1 Remote hosts 325 The remote host implementation SHOULD include the SCM option in a 326 Configure-Request packet. In case the remote host implementation 327 receives a SCM option in a Configure-Request packet from the peer 328 it SHOULD Configure-Nak it. 330 The remote host implementation MUST have an Idle timer which 331 determines how long the physical link can be idle before it is 332 terminated. The implementation SHOULD offer the end user the 333 option of configuring the Idle timer value so that the end user 334 can find a value which satisfies his needs. 336 The remote host implementation MUST ack the Session-Identifier 337 option it receives from NAS. After having re-established the 338 physical link the remote host implementation MUST first sent a 339 LCP Identification packet [9] which has the value of the 340 Session-Identifier in the Message field before it can send 341 network layer packets to the peer. 343 The remote host implementation MUST include a mechanism so that 344 the end user can decide whether or not he wants to accept the 345 call request. This can be done beforehand by listing CLIDs where 346 calls can be originated or by prompting the end user to accept a 347 call each time the physical layer receives a call request. An 348 implementation whose physical layer cannot provide CLID 349 information, or does not trust a carrier-provided CLID SHOULD 350 request the peer to authenticate itself (see chapter 6. Security 351 Considerations). 353 SCM is valid only for the duration of a PPP session. When 354 restarted after an unexpected crash or shutdown, the 355 implementation MUST always start a new PPP session. The 356 implementation MUST also start a new PPP session after failing to 357 terminate the old session. 359 To avoid NAS from having stale PPP session entries in its 360 database the remote host implementation SHOULD terminate the PPP 361 session properly before the end user logs off or brings the host 362 down. 364 4.2 Network Access Server 366 The NAS implementation SHOULD NOT include the SCM option in a 367 Configure-Request. The NAS implementation MUST respond to the SCM 368 option it receives from the remote host as explained in chapter 369 2. Furthermore, it MUST NOT disconnect the physical link. 370 Rather, it observes the status of the physical link and acts 371 accordingly when the remote host disconnects the link. 373 The NAS implementation MUST include a Session-Identifier option 374 in a Configure-Request packet. The remote-host must accept the 375 Session-Identifier before SCM can be used. If NAS receives a 376 Configure-Request packet which contains a Session-Identifier 377 option it SHOULD ack the Session-Identifier option but not use 378 the value specified by the option to identify the point-to-point 379 link. NAS MUST guarantee that the value of a Session-Identifier 380 option it sends to the remote host is unique within the access 381 network. 383 The NAS implementation MUST re-establish the physical link when 384 it receives a packet destined to the remote host and if the 385 remote host told NAS that it can accept remote host terminated 386 calls. If NAS fails to re-establish the physical link after a 387 number of unsuccessful attempts it MUST remove the PPP session 388 entry from the database. When a physical link belonging to a PPP 389 session is re-established NAS must initialize the field in the 390 PPP session entry which marks the time when the physical link was 391 last terminated. 393 NAS implementations MUST have a database in which they store the 394 current PPP sessions. Session-Identifier [10] SHOULD be used as 395 the key for the database. After having detected that the remote 396 host has terminated the physical link, NAS implementations MUST 397 start the Expiration timer. NAS implementations use this timer to 398 periodically check for PPP sessions whose physical links have 399 been down longer than the allowed time. Implementations MUST 400 remove all the entries which do not satisfy this requirement. In 401 order to differentiate physical links which are up from links 402 that have been terminated, NAS SHOULD allocate a unique value for 403 the timer which indicates that a link is up. NAS implementation 404 SHOULD assign this value to the Expiration timer when NAS creates 405 a new PPP session entry. 407 NAS implementations must be able to cope with the modem hunt- 408 group problem. It is possible that NAS has more than one entity 409 between which the control of PPP sessions and the associated 410 physical links is distributed. NAS MUST guarantee that the 411 entity, which has a PPP session entry in its database when the 412 remote host terminates the physical link of the PPP session, 413 either: 415 1. regains the control of the physical link belonging to 416 that PPP session when the link is re-established, or 418 1. alternatively, transfers the PPP session entry to 419 another entity which now controls the physical link 420 between the remote host and the NAS entity, or deletes 421 the PPP session entry thus forcing the reconfiguration 422 of the PPP link. 424 It is beyond the scope this document to discuss these solutions 425 in greater detail. 427 NAS implementations MAY inform ISP of the time durations when the 428 physical link was up so that the remote user is not charged for 429 the times when the link was down. If ISP honors this information 430 NAS SHOULD pass it to the RADIUS server at the end of the RADIUS 431 accounting service [5] delivery. 433 When the NAS implementation receives a Terminate-Request from the 434 remote host it MUST remove the PPP session entry from the 435 database. 437 Implementation Note: 439 L2TP tunnel between NAS (=LAC) and Authenticator Server (AS, 440 see picture in chapter 4.3) might cause problems when SCM 441 option is negotiated. Because LAC may have negotiated LCP with 442 the remote host without LNS being involved in the negotiation, 443 LCP must send LCP CONFREQs to LNS for its approval. If LNS 444 refuses to accept LCP CONFREQs and wants to renegotiate LCP, 445 it is possible that during the second round of negotiation LNS 446 does not accept SCM option because SCM has not been 447 implemented in it. 449 To be able to use SCM even though LNS does not support this 450 feature, LAC implementers/administrators should make sure that 451 LCP CONFREQs LAC sends to LNS are accepted by LNS. This means 452 that LAC MUST remove at least the SCM option from CONFREQs it 453 sends to LNS. If LNS accepts LAC's LCP CONFREQs SCM can be 454 used because both LAC and the remote host agreed to use it. 456 4.3 Roaming hosts 458 Some remote hosts may be so-called mobile hosts which can roam to 459 a new area served by another NAS (NAS2). Roaming can be a problem 460 if the SCM is in use (the physical link has been temporarily 461 terminated) and the remote host has roamed to a new area without 462 terminating the PPP session with old NAS (NAS1). 464 In many cases the Authenticator Server (AS) does allow end users 465 to have more than one active PPP session at any given time. If 466 the new location is serviced by a new NAS (NAS2) it is possible 467 that NAS2 cannot grant access to the remote host because AS 468 refused to authenticate the remote host due to the existing PPP 469 session. E.g. some RADIUS servers [4] do not allow end users to 470 have more than one open PPP session at any given time. This 471 scenario can also take place in access networks where there is a 472 L2TP tunnel between NAS and AS (NAS = LAC, AS = LNS). 474 +----+ +------+ 475 | RH | ----------- | NAS1 | ---------+ 476 +----+ +------+ | 477 | | 478 | +-- +----+ 479 | roaming | AS | 480 | +-- +----+ 481 V | 482 +----+ +------+ | 483 | RH | ----------- | NAS2 | ---------+ 484 +----+ +------+ 486 RH = remote host 487 AS = Authenticator server (RADIUS server, L2TP Network Server) 488 NAS = Network access server 490 To prevent this scenario from happening, NAS implementations 491 should be able to inquire what PPP sessions other NASs have and, 492 if needed, ask another NAS to release the PPP session 493 information, or to terminate the PPP session when the remote host 494 roams to a new location. It is beyond the scope of this document 495 to discuss these solutions in greater detail. 497 5. Timers 499 Idle timer 501 The Idle timer tells the remote host implementation how many 502 seconds a physical link can be idle before it is terminated. 503 The end user SHOULD be able to adjust the timer according to 504 his preference. 506 Remote host implementations SHOULD impose a lower boundary for 507 the Idle timer. Considering that the most of the traffic flows 508 use TCP the lower boundary SHOULD not be less than RTO 509 preventing the physical link from being terminated while the 510 remote host is waiting for an acknowledgement. However, 511 because the value of RTO varies in time based on the state of 512 a link(s) the only recommendation that can be given is that 513 the value of the Idle timer SHOULD be no less than 3 sec which 514 [6] is specified as an initial RTO value. 516 Remote host implementations can either expect the end user to 517 play with the Idle timer value, or implement a mechanism which 518 mirrors the current values of RTOs and assigns the lowest of 519 them to the Idle timer. 521 Expiration timer 523 The Expiration timer determines how long the physical link can 524 be down without NAS removing the PPP session entry from its 525 database. The value of this timer should be high enough to 526 make circuit-switched data service resemble packet-switched 527 data service. 529 6. Security Considerations 531 One way to provide security in SCM is to rely on CLID, which can 532 be used to authenticate the peer, or on a PPP Session-Identifier. 534 It is, however, possible that GSTN and/or hardware cannot provide 535 CLID, or that the implementation desires a stronger 536 authentication mechanism, e.g. CHAP [7] or some mechanism used by 537 EAP [8]. In these cases the authenticator MUST be able to request 538 the peer to authenticate itself immediately after the physical 539 link has been re-established. 541 Implementation Note: 543 It is left up to the implementation to decide what to do with 544 network packets which the implementation receives before the 545 peer has authenticated itself. To make the 546 disconnection/reconnection of the physical link as transparent 547 as possible to the end user the implementation SHOULD accept 548 the network layer packets within a certain time frame even 549 though the peer has not yet authenticated itself. In case of 550 NAS the implementation can either buffer the packets or 551 forward them (preferred) while waiting for the authentication 552 response from the peer. If the peer fails to authenticate 553 itself the implementation MUST immediately close the 554 connection, discard all the buffered packets and clear the 555 peer's PPP session entry. 557 REFERENCES 559 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP) for 560 the Transmission of Multi-protocol Datagrams over Point- 561 to-Point Links," RFC 1661, July 1994. 563 [2] Valencia, A. et al., "Layer Two Tunneling Protocol "L2TP"", 564 draft-ietf-pppext-l2tp-09.txt, January 1998. 566 [3] Simpson, W., Editor. "PPP in HDLC-like Framing", RFC 1662, 567 July 1994. 569 [4] C. Rigney, et. al., "Remote Authentication Dial In User 570 Service (RADIUS)", RFC 2138, April 1997. 572 [5] C. Rigney, "RADIUS accounting", RFC 2139, April 1997. 574 [6] R. Braden, Editor, "Requirements for Internet Hosts -- 575 Communication Layers", RFC 1122, October 1989. 577 [7] W. Simpson, "PPP Challenge Handshake Authentication 578 Protocol (CHAP)", RFC 1994, August 1996. 580 [8] L. Blunk and J. Volbrecht, "PPP Extensible Authentication 581 Protocol (EAP)", RFC 2284, March 1998. 583 [8] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, 584 January 1994. 586 [10] Latvala, M., "PPP Session-Identifier Option", "work in 587 progress" draft-ietf-pppext-sessid-00.txt, November 1998. 589 CONTACTS 591 Questions about this paper can be directed to: 593 Mikael Latvala 594 Oy LM Ericsson Ab 595 SF-02420 Jorvas, Finland 597 E-Mail: mikael.latvala@ericsson.com 598 Voice: +358 9 299 2850 599 GSM: +358 40 507 2555 600 Fax: +358 9 299 3247 602 Appendix A: LCP Translation Table 604 The Semi-Connected phase SHOULD be implemented by adding one new 605 state, Semi-Connected, six new events, and seven new actions to 606 the LCP's state translation table. The new events can cause a 607 legal transition only in the Request-Sent, Request-Ack, Opened or 608 Semi-Connected state which is the reason why only those four 609 states are shown in the table below. The new functionalities can 610 be implemented without sacrificing the integrity of the 611 "traditional" PPP implementation. 613 Because of the asymmetrical nature of SCM small 'c' indicates 614 events which are seen by the remote host (client) and small 's' 615 events seen by NAS (server). 617 Events Actions 619 CSC = Close event, SCM configured, no peer rel = re-establish link 620 DSC = Down event, SCM configured tel = terminate link 621 IDT = Idle timer expired ssi = send session id 622 ETE = Expiration timer expired dse = delete session entry 623 DUP+ = Packet from the upper layer sit = start idle timer 624 DUP- = Packet from the upper layer, no peer set = start expr timer 625 iet = initialize expr timer 627 | State 628 | 7 8 9 10 629 Events| Ack-Rcvd Ack-Sent Opened Semi-Connected 630 ------+--------------------------------------------------------------- 631 Up-c | - - - sit/9 632 Up-s | - - - iet/9 633 Down | 1 1 tld/1 - 634 Open | 7 8 9r - 635 Close-c| irc,str/4 irc,str/4 tld,irc,str/4 rel,tld,irc,str/4 636 Close-s| irc,str/4 irc,str/4 tld,irc,str/4 rel,tld,irc,dse,str/4 637 | 638 TO+ | scr/6 scr/8 - - 639 TO- | tlf/3p tlf/3p - - 640 | 641 RCR+ | sit,sca,tlu/9 sca/8 tld,scr,sca/8 - 642 RCR- | scn/7 scn/6 tld,scr,scn/6 - 643 RCA | scr/6x sit,irc,tlu/9 tld,scr/6x - 644 RCN | scr/6x irc,scr/8 tld,scr/6x - 645 | 646 RTR | sta/6 sta/6 tld,zrc,sta/5 - 647 RTA | 6 8 tld,scr/6 - 648 | 649 RUC | scj/7 scj/8 scj/9 - 650 RXJ+ | 6 8 9 - 651 RXJ- | tlf/3 tlf/3 tld,irc,str/5 - 652 | 653 RXR | 7 8 ser/9 - 654 | 655 CSCc | - - - tld/1 656 CSCs | - - - tld,dse/1 657 DSCc | - - 10 - 658 DSCs | - - set/10 - 659 IDT | - - tel/10 - 660 ETE | - - - tld,dse/1 661 DUP+c | - - - rel,ssi,sit/9 662 DUP+s | - - - rel,iet/9 663 DUP-c | - - - tld/1 664 DUP-s | - - - tld,dse/1 666 Events 668 Close event when SCM configured (CSC) 670 This event occurs when the automaton is in the Semi-Connected 671 state, the network administrator (human or program) indicates that 672 the link is not allowed to be Opened, and the implementation is 673 not able to re-establish the physical link to properly terminate 674 the point-to-point link. 676 Down event when SCM configured (DSC) 678 This event occurs when the PPP link is configured to use SCM, the 679 automaton is in the Opened state, and a lower layer indicates that 680 it is no longer ready to carry packets. Usually the event takes 681 place when the remote host terminates the physical link because 682 the point-to-point link has remained idle too long. 684 Idle timer expired (IDT) 686 This event occurs when the PPP link is configured to use SCM, the 687 automaton is in the Opened state, and the Idle timer expires. 688 Event noticed only by the remote host. 690 Expiration timer expired (EXE) 692 This event occurs when the PPP link is configured to use SCM, the 693 automaton is in the Semi-Connected state, and the Expiration timer 694 expires. Event noticed only by NAS. 696 Datagram from the upper layer (DUP) 697 This event occurs when the PPP link is configured to use SCM, the 698 automaton is in the Semi-Connected state, and a upper layer has 699 given a packet to PPP to transfer to the peer. 701 The DUP+ event indicates that the peer is still available so that 702 the physical link can be re-established and packets can be sent to 703 the peer. 705 The DUP- event indicates that the peer is not available and that 706 the physical link cannot be re-established. 708 Actions 710 Re-establish link (rel) 712 The physical link is re-established. 714 Terminate link (tel) 716 The physical link is terminated. 718 Start expiration timer (set) 720 This action prompts NAS to start the Expiration timer. 722 Start idle timer (sit) 724 This action prompts the remote host to start the Idle timer. 726 Send session id (ssi) 728 This action causes the implementation to send a LCP Identification 729 packet to the peer. 731 Initialize expiration timer (iet) 733 This action causes NAS to initialize the Expiration timer to a 734 value which indicates that the physical link is up.