Network Working Group P. Fan Internet-Draft China Mobile Intended status: Informational June 20, 2014 Expires: December 22, 2014 Managing Router Identifiers during IPv4 Sunset draft-fan-sunset4-router-id-00 Abstract This document describes problems of managing protocol identifiers when turning off IPv4 and migrating to IPv6 only network, with some potential solutions discussed. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 22, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Fan Expires December 22, 2014 [Page 1] Internet-Draft Router ID Management June 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 3. Solution Ideas . . . . . . . . . . . . . . . . . . . . . . . 2 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction There are many places in IETF protocols where a unique identifier is needed. An identifier is typically referred to as a router ID or system ID identifying a router/system running the protocol, and is traditionally designed to be a 32-bit number. Usually the IDs are required to be unique across some domain, but the actual value is not relevant. The value of IDs is often conventionally chosen to be an IPv4 address on the router, and in many implementations the IDs are even expressed in dotted decimal notation. There is some operational convenience of the common practice of tying the IDs to IP addresses: 1. A human-readable set of information is easy for network operators to deal with. 2. IDs can be auto-configured, saving the work of planning and assignment. 3. It is helpful to quickly perform diagnosis and troubleshooting, and easy to identify the availability and location of the identified router. 2. Problem Statement In an IPv6 only network, there are no IP addresses that can be directly used to number an ID. IDs have to be planned individually to meet the uniqueness requirement, and the advantages of tying to IP addresses indicated in section 1 are lost. 3. Solution Ideas If the ID is required to correspond to some information on the router or system, e.g. an IP address, the ID should be extended to meet the requirement; if the value is irrelevant and only needs to be unique, there has been suggestion about avoiding protocol change. One can use some record keeping mechanisms, e.g. DNS or even text file, to associate IDs and IPv6 addresses to retain some of the Fan Expires December 22, 2014 [Page 2] Internet-Draft Router ID Management June 2014 operational convenience, though extra record keeping does introduce additional work. Record keeping should be reliable enough so as to be reachable when a network problem occurs. Another option is to use some external provisioning system, e.g. network management system, to manage and allocate the IDs. Another possible solution is to embed the ID into an IPv6 address, e.g. use a /96 IPv6 prefix and append it with a 32-bit long ID, then an ID is naturally tied to an IP address. The above ideas require IDs be planned and generated in advance and meet the uniqueness requirement. IDs can be manually planned, possibly with some hierarchy or design rule, or can be created automatically. A simple way of automatic ID creation is to generate pseudo-random numbers, and one can use another source of data such as the clock time at boot or configuration time to provide additional entropy during the generation of unique IDs. One can also hash an IPv6 address down to a value as ID. It is necessary to be able to override the hashed value, and desirable if hash is provided by the router implementation. The hash algorithm is supposed to be known and the same across the domain. Since typically the number of routers in a domain is far smaller than the value range of IDs, the hashed IDs are hardly likely to conflict with each other, as long as the hash algorithm is not designed too badly. 4. Security Considerations TBD. 5. IANA Considerations None. 6. Acknowledgements Thanks to Fred Baker, Shane Amante, David Farmer, Wes George for their valuable ideas in forming this document. Author's Address Peng Fan China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 P.R. China Email: fanp08@gmail.com Fan Expires December 22, 2014 [Page 3]