idnits 2.17.1 draft-ietf-ipngwg-testv2-addralloc-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-19) 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 45, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 50, but not defined == Unused Reference: 'DHCP6' is defined on line 113, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 124, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'AGGR' ** Obsolete normative reference: RFC 1971 (ref. 'AUTO') (Obsoleted by RFC 2462) -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCP6' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETHER' -- Possible downref: Non-RFC (?) normative reference: ref. 'FDDI' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Hinden, Ipsilon Networks 3 May 27, 1997 R. Fink, LBNL 4 J. Postel, ISI 6 IPv6 Testing Address Allocation 8 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 ``working draft'' or ``work in progress.'' 23 Please check the 1id-abstracts.txt listing contained in the internet- 24 drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 25 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 26 current status of any Internet Draft. 28 This draft expires in November 27, 1997. 30 1.0 Introduction 32 This document describes an allocation plan for IPv6 addresses to be 33 used in testing IPv6 prototype software. These addresses are 34 temporary and will be reclaimed in the future. Any IPv6 system using 35 these addresses will have to renumber at some time in the future. 36 These addresses will not to be routable in the Internet other than 37 for IPv6 testing. 39 This document is intended to replace RFC1897 "IPv6 Testing Address 40 Allocation", January 1996. RFC1897 will become historic. 42 The addresses described in this document are consistent with the IPv6 43 Addressing Architecture [ARCH]. They may be assigned to nodes 44 manually, with IPv6 Auto Address Allocation [AUTO], or with DHCP for 45 IPv6 [DHCPv6]. 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in [RFC 2119]. 51 2.0 Address Format 53 The address format for the IPv6 test address is consistent with the 54 aggregatable global unicast address allocation [AGGR] which is as 55 follows: 57 | 3 | 13 | 32 | 16 | 64 bits | 58 +---+-----+-----------+--------+--------------------------------+ 59 |FP | TLA | NLA* | SLA* | Interface ID | 60 +---+-----+-----------+--------+--------------------------------+ 62 where: 64 FP = 001 = Format Prefix 66 This is the Format Prefix used to identify aggregatable 67 global unicast addresses. 69 TLA = 0x1FFE = Top Level Aggregator 71 This is a TLA assigned by the IANA for 6bone testing under 72 the auspices of the IETF IPng Transition Working Group 6bone 73 testbed activity. It is to be administered by the chair of 74 the 6bone activity (Bob Fink at the present time). The use 75 of this TLA is temporary. All users of these addresses in 76 this TLA will be required to renumber at some time in the 77 future. 79 NLA* = Next-Level Aggregator(s) 81 The NLA* space will be assigned, by the TLA administrator, in 82 an addressing hierarchy sufficient to identify transit 83 networks and end user sites consistent with the architecture 84 and topology of the 6bone. This will provide a multi-level 85 transit service consistent with the 6bone goals of fully 86 testing IPv6 technology in real use environments. 88 SLA* = Site-Level Aggregator(s) 89 The SLA* field is used by an individual organization to 90 create its own local addressing hierarchy and to identify 91 subnets. Assignment of the SLA* field is the responsibility 92 of each individual organization. 94 Interface ID 96 This is the interface identifier of the interface on the link 97 as defined in the appropriate IPv6 over document, such 98 as [ETHER], [FDDI], etc. 100 4.0 References 102 [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", 103 Internet Draft, , May 104 1997. 106 [AGGR] Hinden, R., Deering, S., O'Dell, M., "An Aggregatable 107 Global Unicast Address Format", internet draft, , May 1997. 110 [AUTO] Thompson, S., Narten T., "IPv6 Stateless Address 111 Autoconfiguration", RFC1971, August 1996. 113 [DHCP6] Bound, J., "Host Configuration Protocol for IPv6", Internet 114 Draft, , July 1995. 116 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 117 Networks", Internet Draft, , March 1997. 120 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 121 Networks", Internet Draft, , March 1997. 124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 125 Requirement Levels", RFC2119, BCP14, March 1997. 127 5.0 Security Considerations 129 Documents of this type do not directly impact the security of the 130 Internet infrastructure or its applications. 132 6.0 Authors Address 134 Robert M. Hinden phone: +1 408 990-2004 135 Ipsilon Networks, Inc. email: hinden@ipsilon.com 136 232 Java Drive 137 Sunnyvale, CA 94089 138 USA 140 Robert Fink phone: +1 510 486-5692 141 Lawrence Berkeley National Laboratory email: rlfink@lbl.gov 142 MS 50A-3111 143 Berkeley, CA 94720 144 USA 146 Jon Postel phone: +1 310 822 1511 147 Information Sciences Institute email: postel@isi.edu 148 4676 Admiralty Way 149 Marina del Rey, CA 90292-6695 150 USA