idnits 2.17.1 draft-ipversion6-loopback-prefix-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 163 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2015) is 3344 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) == Missing Reference: 'RFC6890' is mentioned on line 108, but not defined == Missing Reference: 'THIS DOCUMENT' is mentioned on line 114, but not defined == Missing Reference: 'APPROVAL DATE' is mentioned on line 116, but not defined -- Looks like a reference, but probably isn't: '1' on line 130 == Unused Reference: 'RFC 6890' is defined on line 149, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Independent Submission E. Lewis 2 Internet-Draft ICANN 3 Expires: September 1, 2015 Date: March 1, 2015 5 Loopback Prefix for IPv6 6 draft-ipversion6-loopback-prefix-00 8 Abstract 10 The IPv6 address range of 0::/64 is reserved for loopback addresses. 11 This expands from the single loophack address already defined for IPv6, 12 ::1, to allow for a set of addresses to be used when packets are intended 13 to stay within a host system. Multiple loopback addresses allow for 14 simultaneous varied uses of the loopback addresses as has proven, albeit 15 in limited ways, in IPv4. And exception is made to accomodate the 16 ::0/128, already defined as The Unspecified Address. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 1, 2015 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 0. NOTE TO RFC EDITOR AND REVIEWERS . . . . . . . . . . . . . . 1 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1 54 2. Use of ::0/64 Addresses . . . . . . . . . . . . . . . . . . . 2 55 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 1 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 1 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 1 59 6.1. Normative References . . . . . . . . . . . . . . . . . . 1 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 1 62 0. NOTE TO RFC EDITOR AND REVIEWERS 64 This section should be removed prior to publication. 66 1. Introduction 68 The "IP Version 6 Addressing Architecture" [RFC 4291] defines a single 69 IPv6 loopback address as ::1/128. In "Special-Purpose IP Address Registries" 70 [RFC6890], 127.0.0.0/8 is assigned for loophack addresses, with usually 71 just 127.0.0.1/32 implemented by default. 73 Ordinarily, just one address (whether IPv4 or IPv6) is sufficient for 74 loopback addressing on a node but there have been a few use cases showing 75 that it is desireable to have more than 1 (but less than the over 16 76 million that are in an IPv4 /8). 78 One use case is testing or prototyping, desiring to mimic a small network 79 of processes on one node. To demonstrate a particular protocol's server 80 running on a well-known port, having multiple addresses where packets 81 can "travel" within the host is useful. 83 Another use case has arisen from ICANN's Controlled Interruption approach 84 [need reference] which directs errant traffic to a loopback address with 85 two distinct goals in mind. One is to prevent the leakage of packets that 86 are known to be erroneously sent and two is to leave "bread crumbs" in log 87 files for operators to use to help track why the erroneous packets are being 88 sent. 90 The use of ::0/64 is (proposed) to represent an address range (or block) 91 encompassing The Unspecified Address and loopback addresses. 93 2. Use of ::0/64 Addresses 95 The Unspecified Address, or ::0/128, remains as defined in RFC 4291's section 96 2.5.2. That definition is included by reference here so as to prevent 97 any unintentional changes to the original text. 99 For all other addresses within ::0/64, the rules for using are the same as 100 the rules in RFC 4291's section 2.5.3, again included by reference so as 101 not to introduce any unintentional changes. 103 3. IANA Considerations 105 Registration in the IANA IPv6 Special-Purpose Address Registry 107 The IANA is directed to add ::0/64 to the "IANA IPv6 Special-Purpose 108 Address Registry" specified in [RFC6890] as follows: 110 Address Block: ::0/64 112 Name: Loopback and Unspecified Addresses 114 RFC: [THIS DOCUMENT] 116 Allocation Date: [APPROVAL DATE] 118 Termination Date: N/A 120 Source: True [1] 122 Destination: False 124 Forwardable: False 126 Global: False 128 Reserved-by-Protocol: True 130 [1] True for ::0/128, False for all other addresses in ::0/64 132 The IANA is directed to remove Table 17 and Table 18 a 133 defined in RFC 6890, section 2.2.3. 135 4. Security Considerations 137 Security is not (yet) a consideration 139 5. Acknowledgements 141 We all this all to David Conrad. 143 6. References 145 6.1. Normative References 147 [RFC 4291] "IP Version 6 Addressing Architecture", Hinden & Deering, 148 Feb 2006 149 [RFC 6890] "Special-Purpose IP Address Registries:, Cotton, Vegoda, 150 Bonica & Haberman, Apr 2013 152 Authors' Addresses 154 Edward Lewis 155 edward.lewis@icann.org 156 801 17th Street NW 157 Suite 400 158 Washington, DC, 20006 159 US 161 Lewis Expires September 1, 2015 [Page 1]