idnits 2.17.1 draft-ietf-pier-consider-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-26) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 105 lines 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 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.) ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 15 instances of lines with control characters in the document. 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 section? '1' on line 83 looks like a reference -- Missing reference section? '2' on line 84 looks like a reference -- Missing reference section? '3' on line 85 looks like a reference -- Missing reference section? '4' on line 86 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Bill Manning 3 April 1996 ISI 4 Expires in six months 6 Why consider Renumbering Now 7 draft-ietf-pier-consider-00.txt 9 Status of this Memo 11 This document wants to be an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 23 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 This document is a fuller explanation of the intent and 28 goals of the PIER working group of the IETF. 30 The current charter states that PIER will work with other 31 groups in identifying those locations in IP where the actual IP 32 addresses are used. This will lead to the development of a series 33 of educational materials for users of IP to recognize where IP 34 addresses are used. In addition, PIER will assist other IETF working 35 groups in identifying processes and procedures, tools and techniques 36 that can be used to facilitate renumbering. 38 That raises the question of why even consider renumbering. 39 The salient points have been raised in an IAB document[1] and on 40 various mailing lists. To summarize, in IPv6, renumbering is a basic 41 design consideration, along with mobility and security. For those 42 that embrace this new version of IP, renumbering considerations must 43 be taken in to account in the network design and operations phases. 45 In IPv4, this was not part of the original design constraint, 46 therefore most existing network infrastructure was designed without 47 any hooks to which facilitate easier renumbering. It is within PIERs 48 charter to encourage those who design networks to consider adding 49 renumbering elements to future designs and in redesigns, as network 50 topologies are upgraded and changed. Consideration of renumbering in 51 the design will make future operations much easier. It could even be 52 argued that such features allow any network to be more nimble and react 53 to changes faster, leading to a competitive edge. 55 The results in this approach are that as the designs change, 56 the network infrastructure mutates to be able to support renumbering. 57 This can be a slow mutation, allowing for advances in renumbering 58 techniques to mature. The larger tasks are efforts to change user 59 perception regarding the value of any particular IP address. Others 60 have taken up this challenge and have produced a number of documents 61 that attempt to educate old and new IP users on this topic [2],[3]. 62 PIERS efforts in this area are to provide additional education and 63 perhaps even one on one assistance in understanding the options 64 surrounding IP address selection. Regardless of the outcome, some 65 social engineering will have been done, pointing out the logistics 66 involved in the renumbering process. 68 And what about those who will not be migrating to IPv6 and do 69 not believe that IPv6 has anything viable to offer the Internet? ALE 70 predictions indicate that the global Internet will run out of IPv4 space 71 eventually. One of the only ways to extend the lifetime of IPv4 is 72 through aggressive renumbering. This has been argued forcefully in other 73 mailing lists[4]. While the relative merits of this approach (staying 74 with IPv4 and aggressively renumbering into provider blocks) are still 75 being debated, the problem has similar characteristics to the IPv6 76 migration issues mentioned above. 78 It is the intent of the PIER wg to facilitate the education 79 of both old and new IP users as well as architects and protocol and 80 application designers on the need to consider renumbering in network 81 design and operations. 83 [1] - RFC1900 84 [2] - Address Ownership considered Fatal - Yakov Rekter, Tony Li, Connexions 85 [3] - R. Moskowitz - 86 [4] - CIDR archives - 1995/1996 88 Security considerations of this memo 90 None. 92 Authors Address 94 Bill Manning 95 USC/ISI 96 4676 Admiralty Way 97 Marina del Rey, CA. 90292 98 01.310.822.1511 99 bmanning@isi.edu