idnits 2.17.1 draft-ietf-ipngwg-test-addr-alloc-00.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. ** 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 Abstract 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. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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: 'DHCPv6' is mentioned on line 38, but not defined == Missing Reference: 'PRVD' is mentioned on line 43, but not defined == Unused Reference: 'DHCP6' is defined on line 148, but no explicit reference was found in the text == Unused Reference: 'PROV' is defined on line 151, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-hinden-ipng-addr is -00, but you're referring to -03. -- Possible downref: Normative reference to a draft: ref. 'ARCH' == Outdated reference: A later version (-07) exists of draft-ietf-addrconf-ipv6-auto-03 == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-02 == Outdated reference: A later version (-03) exists of draft-ietf-ipngwg-unicast-addr-fmt-02 Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Ipsilon Networks 2 August 30, 1995 J. Postel, ISI 3 Expires in six months 5 IPv6 Testing Address Allocation 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, and 13 its Working Groups. Note that other groups may also distribute working 14 documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six months. 17 Internet Drafts may be updated, replaced, or obsoleted by other 18 documents at any time. It is not appropriate to use Internet Drafts as 19 reference material or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 Please check the 1id-abstracts.txt listing contained in the internet- 23 drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, 24 ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any 25 Internet Draft. 27 1.0 Introduction 29 This document describes an allocation plan for IPv6 addresses to be used 30 in testing IPv6 prototype software. These addresses are temporary and 31 will be reclaimed in the future. Any IPv6 system using these addresses 32 will have to renumber at some time in the future. These addresses will 33 not to be routable in the Internet other than for IPv6 testing. 35 The addresses described in this document are consistent with the IPv6 36 Addressing Architecture [ARCH]. They may be assigned to nodes manually, 37 with IPv6 Auto Address Allocation [AUTO], or with DHCP for IPv6 38 [DHCPv6]. 40 2.0 Address Format 42 The address format for the IPv6 test address is consistent with the 43 provider-based unicast address allocation [PRVD] which is as follows: 45 | 3 | 5 bits | 16 bits | 8 | 24 bits | 8 | 64 bits | 46 +---+----------+----------+---+------------+---+----------------+ 47 |010|RegistryID|ProviderID|RES|SubscriberID|RES|Intra-Subscriber| 48 +---+----------+----------+---+------------+---+----------------+ 50 The specific allocation of each field of the test address format is as 51 follows: 53 | 3 | 5 bits | 16 bits | 8 | 24 bits | 8 | 16 bits|48 bits| 54 +---+----------+----------+---+------------+---+--------+-------+ 55 | | |Autonomous| | IPv4 | | Subnet | Intf. | 56 |010| 11111 | System |RES| Network |RES| | | 57 | | | Number | | Address | | Address| ID | 58 +---+----------+----------+---+------------+---+--------+-------+ 60 where: 62 010 64 This is the Format Prefix used to identify provider-based 65 unicast addresses. 67 11111 69 This is a Registry ID reserved by the IANA. The initial use of 70 addresses in this Registry ID for IPv6 testing is temporary. 71 All users of these addresses will be required to renumber at 72 some time in the future. 74 Autonomous System Number 76 This is the current autonomous system number assigned to the 77 provider providing internet service to the an IPv6 testers 78 organization. For example for IPv6 testers receiving internet 79 service from BBN Barrnet would use autonomous system number 189. 80 This would be coded in the autonomous system field of the 81 address as follows: 83 0000 0000 1011 1101 (binary) 85 The values for the autonomous system number of an organization's 86 provider can be obtained from that provider, or can be looked up 87 in the "whois" database maintained by the internic.net. 89 RES 91 This field is reserved and must be set to zero. 93 IPv4 Network Address 95 This is based on the current IPv4 routable address for the 96 subscriber which the interface is connected. It is formed by 97 taking the high order 24 bits of the IPv4 address. For example 98 for an IPv4 address (in IPv4 syntax): 100 IPv4 Address 101 ------------ 102 39.11.22.1 104 the value to put in this field of IPv6 address is: 106 IPv4 Format Hex 107 ------------ ------ 108 39.11.22 270B16 110 This technique for generating values for this field only works 111 for subscribers which have IPv4 subscriber prefixes less than 112 equal to 24 bits long. There may be subscribers using IPv4 113 addresses with longer subscriber prefixes, but this conflict is 114 expected to be very rare. Subscribers with subscriber prefixes 115 larger than 24 bits should use the remaining bits in the IPv4 116 prefix as the high order bits in the Subnet Address field. 118 RES 120 This field is reserved and must be set to zero. 122 Subnet Address 124 The Subnet ID identifies a specific physical link on which the 125 interface is located. There can be multiple subnets on the same 126 physical link. A specific subnet can not span multiple physical 127 links. The assignment of values for this field is left to an 128 individual subscriber. One possible algorithm to generate 129 values for this field is to use the bits in the IPv4 address 130 which identify the IPv4 subnet. 132 Interface ID 134 This is the unique identifier of the interface on the link, 135 usually the 48-bit IEEE 802 MAC address of the interface if 136 available. 138 4.0 References 140 [ARCH] Hinden, R., S. Deering, "IP Version 6 Addressing 141 Architecture", Internet Draft, draft-hinden-ipng-addr-03.txt, 142 June 1995. 144 [AUTO] Thompson, S., "IPv6 Stateless Address Autoconfiguration" , 145 Internet Draft, draft-ietf-addrconf-ipv6-auto-03.txt , July 146 1995. 148 [DHCP6] Bound, J., "Host Configuration Protocol for IPv6", Internet 149 Draft, draft-ietf-dhc-dhcpv6-02.txt , July 1995. 151 [PROV] Rekhter, Y., P. Lothberg, "An IPv6 Provider-Based Unicast 152 Address Format", Internet Draft, draft-ietf-ipngwg-unicast- 153 addr-fmt-02.txt , August 1995. 155 5.0 Security Considerations 157 Security issues are not discussed in this memo. 159 6.0 Authors Address 161 Robert M. Hinden 162 Ipsilon Networks, Inc. 163 2465 Latham Street, Suite 100 164 Mt. View, CA 94040 165 USA 167 phone: +1 415 528 4604 168 fax: +1 415 528 4653 170 email: hinden@ipsilon.com 172 Jon Postel 173 Information Sciences Institute 174 4676 Admiralty Way 175 Marina del Rey, CA 90292-6695 176 USA 178 phone: +1 310 822 1511 179 fax: +1 310 823 6714 181 email: postel@isi.edu