idnits 2.17.1 draft-hiller-dns-addr-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? 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. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2472, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC2472, updated by this document, for RFC5378 checks: 1996-12-27) -- 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 2002) is 8070 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: '5' is defined on line 198, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 201, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2472 (ref. '4') (Obsoleted by RFC 5072, RFC 5172) ** Obsolete normative reference: RFC 1886 (ref. '7') (Obsoleted by RFC 3596) ** Downref: Normative reference to an Informational RFC: RFC 1877 (ref. '8') Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hiller 3 Internet Draft Lucent Technologies 4 Updates: RFC 2472 G. Zorn 5 Category: Standards Track Cisco Systems 6 March 2002 8 PPP IPV6 Control Protocol Extensions for 9 Name Server Addresses 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1. Abstract 32 The Point-to-Point Protocol (PPP) provides a standard method for 33 transporting multi-protocol datagrams over point-to-point links. PPP 34 defines an extensible Link Control Protocol and a family of Network 35 Control Protocols (NCPs) for establishing and configuring different 36 network-layer protocols. 38 This document extends the NCP for establishing and configuring 39 Version 6 of the Internet Protocol (IPV6) over PPP, defining the 40 negotiation of primary and secondary Domain Name System (DNS) server 41 IPV6 addresses. 43 2. Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 47 this document are to be interpreted as described in RFC 2119 [2]. 49 IPV6CP Extensions for Name Server Addresses 12/2002 51 3. Introduction 53 The Point-to-Point Protocol (PPP) [1] provides a standard method for 54 transporting multi-protocol datagrams over point-to-point links. PPP 55 defines an extensible Link Control Protocol and a family of Network 56 Control Protocols (NCPs) for establishing and configuring different 57 network-layer protocols. 59 This document extends the NCP for establishing and configuring 60 Version 6 of the Internet Protocol (IPV6) [4] over PPP, defining the 61 negotiation of primary and secondary Domain Name System (DNS) server 62 addresses [3] [7] for IPV6. 64 4. Additional IPV6CP Configuration Options 66 The two name server address configuration options, X to X+1, provide 67 a method of obtaining the addresses of Domain Name System (DNS) 68 servers on the remote IPV6 network. 70 For implementation convenience, these options are designed to serve 71 identical purposes, except that when both are present an attempt 72 SHOULD be made to resolve names using the primary address before 73 using the secondary address. 75 4.1 Primary DNS Server IPV6 Address 77 Description 79 This Configuration Option defines a method for negotiating with the 80 remote peer the IPV6 address of the primary DNS server to be used on 81 the local end of the link. If the local peer requests an invalid 82 server address (which it will typically do intentionally) the remote 83 peer specifies the address by NAKing this option, and returning the 84 Ipv6 address of a valid DNS server. 86 By default, no primary DNS address is provided. 88 A summary of the Primary DNS IPV6 Address Configuration Option format 89 is shown below. The fields are transmitted from left to right. 91 IPV6CP Extensions for Name Server Addresses 12/2002 93 0 1 2 3 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Type | Length | Reserved | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Primary-DNS-IPV6-Address | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Primary-DNS-IPV6-Address | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 Type 108 X 110 Length 112 20 114 Primary-DNS-IPV6-Address 116 The sixteen octet Primary-DNS-Address is the address (in 117 network byte order) of the primary DNS server to be used 118 by the local peer. If all sixteen octets are set to zero, 119 it indicates an explicit request that the peer provide the 120 address information in a Config-Nak packet. 122 Default 124 No address is provided. 126 4.2 Secondary DNS Server IPV6 Address 128 Description 130 This Configuration Option defines a method for negotiating with the 131 remote peer the IPV6 address of the secondary DNS server to be used 132 on the local end of the link. If local peer requests an invalid 133 server address (which it will typically do intentionally) the remote 134 peer specifies the address by NAKing this option, and returning the 135 IPV6 address of a valid DNS server. 137 By default, no secondary DNS address is provided. 139 A summary of the Secondary DNS Server IPV6 Address Configuration 140 Option format is shown below. The fields are transmitted from left 141 to right. 143 IPV6CP Extensions for Name Server Addresses 12/2002 145 0 1 2 3 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Type | Length | Reserved | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Secondary-DNS-IPV6-Address | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Secondary-DNS-IPV6-Address | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Type 160 X+1 162 Length 164 20 166 Secondary-DNS-IPV6-Address 168 The sixteen octet Secondary-DNS-IPV6-Address is the IPV6 169 address (in network byte order) of the secondary DNS 170 server to be used by the local peer. If all sixteen 171 octets are set to zero, it indicates an explicit request 172 that the peer provide the address information in a Config- 173 Nak packet. 175 Default 177 No Address is provided. 179 5. Security Considerations 181 The use of these extensions is as secure as the link itself. 183 6. References 185 [1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 186 9, RFC 2026, October 1996. 188 [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement 189 Levels", BCP 14, RFC 2119, March 1997 191 [3] W. Simpson, Editor, "The Point-to-Point Protocol (PPP)", STD 51, 192 RFC 1661, Daydreamer, July 1994 193 IPV6CP Extensions for Name Server Addresses 12/2002 195 [4] Haskin, D., E. Allen, "IP Version 6 over PPP", RFC 2472, 196 December 1998 198 [5] P. Mockapetris, "Domain Names - Concepts and Facilities", STD 13, 199 RFC 1034, USC/Information Sciences Institute, November 1987. 201 [6] P. Mockapetris, "Domain Names - Implementation and 202 Specification", STD 13, RFC 1035, USC/Information Sciences 203 Institute, November 1987. 205 [7] Thomson, S. and C. Huitema, "DNS Extensions to support IP 206 version 6", RFC 1886, December 1995. 208 [8] S. Cobb. "PPP Internet Protocol Control Protocol Extensions for 209 Name Server Addresses", RFC 1877, December 1995. 211 7. Acknowledgments 213 A major portion of the text in this memo was stolen from RFC 1877 214 [8]. 216 11. Authors' Addresses 218 Tom Hiller 219 Lucent Technologies 220 1960 Lucent Lane 221 Phone: +1 (630) 979 7673 222 Email: tom.hiller@lucent.com 224 Glen Zorn 225 Cisco Systems, Inc. 226 500 108th Avenue N.E., Suite 500 227 Bellevue, WA 98004 228 USA 229 Phone: +1 (425) 471-4861 230 Email: gwz@cisco.com 231 IPV6CP Extensions for Name Server Addresses 12/2002 233 Full Copyright Statement 235 "Copyright (C) The Internet Society (date). All Rights Reserved. 236 This document and translations of it may be copied and furnished to 237 others, and derivative works that comment on or otherwise explain it 238 or assist in its implementation may be prepared, copied, published 239 and distributed, in whole or in part, without restriction of any 240 kind, provided that the above copyright notice and this paragraph 241 are included on all such copies and derivative works. However, this 242 document itself may not be modified in any way, such as by removing 243 the copyright notice or references to the Internet Society or other 244 Internet organizations, except as needed for the purpose of 245 developing Internet standards in which case the procedures for 246 copyrights defined in the Internet Standards process must be 247 followed, or as required to translate it into languages other than 248 English. The limited permissions granted above are 249 perpetual and will not be revoked by the Internet Society or its 250 successors or assigns. This document and the information contained 251 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 252 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 253 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 254 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 255 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 256 PARTICULAR PURPOSE." 258 Intellectual Property Statement 260 The IETF takes no position regarding the validity or scope of any 261 intellectual property or other rights that might be claimed to 262 pertain to the implementation or use of the technology described in 263 this document or the extent to which any license under such rights 264 might or might not be available; neither does it represent that it 265 has made any effort to identify any such rights. Information on the 266 IETF's procedures with respect to rights in standards-track and 267 standards-related documentation can be found in BCP-11. Copies of 268 claims of rights made available for publication and any assurances 269 of licenses to be made available, or the result of an attempt made 270 to obtain a general license or permission for the use of such 271 proprietary rights by implementors or users of this specification 272 can be obtained from the IETF Secretariat.