idnits 2.17.1 draft-helenius-ppp-subnet-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 181 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. ** 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 78: '...ation. The peer MAY or MAY NOT provid...' RFC 2119 keyword, line 79: '...The IP Subnet configuration option MAY...' RFC 2119 keyword, line 103: '...ddress. The value of the Mask MUST be...' RFC 2119 keyword, line 109: '... in Configure-Request MUST thus always...' RFC 2119 keyword, line 115: '...f four octets. It MAY have any value....' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The IP Subnet configuration option, x (value to be assigned by IANA), is used together with IP-address configuration option to learn an IP subnet for a LAN attached to a router on the local end of an (unnumbered) PPP link. The IP Subnet configuration option allows the sender of the Configure-Request to request that the peer provides the information. The peer MAY or MAY NOT provide the information by ACKing or NAKing the option. The IP Subnet configuration option MAY be present in the Configure-Nak or Configure-Ack only if the option was present in the corresponding Configure-Request. -- 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 (March 2000) is 8809 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) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Juha Heinanen 2 INTERNET DRAFT Telia Finland 3 Expires September 2000 Dave Allan 4 Nortel Networks 5 Petri Helenius 6 KPNQwest Finland 7 Arthur Lin 8 Shasta Networks 9 March 2000 11 PPP Internet Protocol Control Protocol Extensions for IP Subnet 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 To learn the current status of any Internet-Draft, please check the 34 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 35 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 36 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 37 ftp.isi.edu (US West Coast). 39 Abstract 41 The Point-to-Point Protocol (PPP) [1] provides a standard method for 42 transporting multi-protocol datagrams over point-to-point links. PPP 43 defines an extensible Link Control Protocol and a family of Network 44 Control Protocols (NCPs) for establishing and configuring different 45 network-layer protocols. 47 This document extends the NCP for establishing and configuring the 48 Internet Protocol over PPP [2] by defining an IP Subnet configuration 49 option. 51 1. Motivation 53 The IP-address configuration option [2] allows negotiation of a 54 single IP address used on the local end of a PPP link. It is 55 adequate when the the local end is an IP host. However, when the 56 local end is an router, for example an ISDN or ADSL router providing 57 IP connectivity for a home or small office LAN, then it should be 58 possible to negotiate a whole IP subnet for the LAN rather than a 59 single IP address for the local end of the link. 61 This document defines an IP subnet configuration option that allows a 62 router at the local end of an (unnumbered) PPP link to automatically 63 negotiate an IP subnet for a LAN for which it provides IP 64 connectivity via the PPP link. The received subnet mask will define 65 the subnet in combination of the IP address received from IP address 66 negotiation. 68 The following section contains the formal definition of the IP Subnet 69 configuration option. 71 2. IP Subnet IPCP Configuration Option 73 The IP Subnet configuration option, x (value to be assigned by IANA), 74 is used together with IP-address configuration option to learn an IP 75 subnet for a LAN attached to a router on the local end of an 76 (unnumbered) PPP link. The IP Subnet configuration option allows the 77 sender of the Configure-Request to request that the peer provides the 78 information. The peer MAY or MAY NOT provide the information by 79 ACKing or NAKing the option. The IP Subnet configuration option MAY 80 be present in the Configure-Nak or Configure-Ack only if the option 81 was present in the corresponding Configure-Request. 83 The format of the IP Subnet configuration option is shown below. The 84 fields are transmitted from left to right. 86 0 1 2 3 87 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 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | Type | Length | Size | Pad | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 Type 93 To be assigned. 95 Length 97 8 99 Size 101 The Size indicates the desired size of the IP subnet, i.e., how 102 many most significant bits of the negotiated IP-address belong to 103 the network part of the address. The value of the Mask MUST be 104 from 0 to 32. If the value of the Mask is 0, it indicates a 105 request for the peer to provide the Mask information. Mask value 106 32 denotes a single host address. Note that the sender of 107 Configure-Request can not propose a mask but can only indicate 108 that it would like to receive the mask information on Configure- 109 Ack. The value of the Mask in Configure-Request MUST thus always 110 be 0. 112 Pad 114 The Pad is used to make the length of the IP Subnet configuration 115 option a multiple of four octets. It MAY have any value. 117 Default 119 No IP subnet is assigned. 121 3. Security Considerations 123 The remote end of the PPP link SHOULD verify that the local end is 124 authorized to use the requested IP subnet information before ACKing 125 the request. 127 References 129 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, 130 RFC 1661, Daydreamer, July 1994. 132 [2] McGregor, G., "PPP Internet Control Protocol", RFC 1332, Merit, 133 May 1992. 135 Author Information 137 Juha Heinanen 138 Telia Finland, Inc. 139 Myyrmaentie 2 140 01600 VANTAA 141 Finland 142 jh@telia.fi 144 Dave Allan 145 Nortel Networks 146 P.O. Box 3511, Station 'C' 147 Ottawa, Ontario 148 CANADA, K2B 5P9 149 dallan@nortelnetworks.com 151 Petri Helenius 152 KPNQwest Finland 153 Merimiehenkatu 36 154 00150 HELSINKI 155 FINLAND 156 pete@kpnqwest.fi 158 Arthur Lin 159 Nortel Networks 160 Shasta IP Services Business Unit 161 4500 Great America Parkway 162 Santa Clara, CA 95054 163 U.S.A 164 alin@shastanets.com