idnits 2.17.00 (12 Aug 2021) /tmp/idnits23910/draft-fan-sunset4-router-id-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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2014) is 2892 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Fan 3 Internet-Draft China Mobile 4 Intended status: Informational June 20, 2014 5 Expires: December 22, 2014 7 Managing Router Identifiers during IPv4 Sunset 8 draft-fan-sunset4-router-id-00 10 Abstract 12 This document describes problems of managing protocol identifiers 13 when turning off IPv4 and migrating to IPv6 only network, with some 14 potential solutions discussed. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 22, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Solution Ideas . . . . . . . . . . . . . . . . . . . . . . . 2 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 55 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1. Introduction 60 There are many places in IETF protocols where a unique identifier is 61 needed. An identifier is typically referred to as a router ID or 62 system ID identifying a router/system running the protocol, and is 63 traditionally designed to be a 32-bit number. Usually the IDs are 64 required to be unique across some domain, but the actual value is not 65 relevant. The value of IDs is often conventionally chosen to be an 66 IPv4 address on the router, and in many implementations the IDs are 67 even expressed in dotted decimal notation. There is some operational 68 convenience of the common practice of tying the IDs to IP addresses: 70 1. A human-readable set of information is easy for network operators 71 to deal with. 73 2. IDs can be auto-configured, saving the work of planning and 74 assignment. 76 3. It is helpful to quickly perform diagnosis and troubleshooting, 77 and easy to identify the availability and location of the 78 identified router. 80 2. Problem Statement 82 In an IPv6 only network, there are no IP addresses that can be 83 directly used to number an ID. IDs have to be planned individually 84 to meet the uniqueness requirement, and the advantages of tying to IP 85 addresses indicated in section 1 are lost. 87 3. Solution Ideas 89 If the ID is required to correspond to some information on the router 90 or system, e.g. an IP address, the ID should be extended to meet the 91 requirement; if the value is irrelevant and only needs to be unique, 92 there has been suggestion about avoiding protocol change. 94 One can use some record keeping mechanisms, e.g. DNS or even text 95 file, to associate IDs and IPv6 addresses to retain some of the 96 operational convenience, though extra record keeping does introduce 97 additional work. Record keeping should be reliable enough so as to 98 be reachable when a network problem occurs. Another option is to use 99 some external provisioning system, e.g. network management system, to 100 manage and allocate the IDs. 102 Another possible solution is to embed the ID into an IPv6 address, 103 e.g. use a /96 IPv6 prefix and append it with a 32-bit long ID, then 104 an ID is naturally tied to an IP address. 106 The above ideas require IDs be planned and generated in advance and 107 meet the uniqueness requirement. IDs can be manually planned, 108 possibly with some hierarchy or design rule, or can be created 109 automatically. A simple way of automatic ID creation is to generate 110 pseudo-random numbers, and one can use another source of data such as 111 the clock time at boot or configuration time to provide additional 112 entropy during the generation of unique IDs. 114 One can also hash an IPv6 address down to a value as ID. It is 115 necessary to be able to override the hashed value, and desirable if 116 hash is provided by the router implementation. The hash algorithm is 117 supposed to be known and the same across the domain. Since typically 118 the number of routers in a domain is far smaller than the value range 119 of IDs, the hashed IDs are hardly likely to conflict with each other, 120 as long as the hash algorithm is not designed too badly. 122 4. Security Considerations 124 TBD. 126 5. IANA Considerations 128 None. 130 6. Acknowledgements 132 Thanks to Fred Baker, Shane Amante, David Farmer, Wes George for 133 their valuable ideas in forming this document. 135 Author's Address 137 Peng Fan 138 China Mobile 139 32 Xuanwumen West Street, Xicheng District 140 Beijing 100053 141 P.R. China 143 Email: fanp08@gmail.com