Internet DRAFT - draft-fan-sunset4-router-id
draft-fan-sunset4-router-id
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]
