Internet-Draft Tokenised IPv6 Identifiers October 2012
Chown Expires 4 May 2013 [Page]
Workgroup:
IPv6 Maintenance
Internet-Draft:
draft-chown-6man-tokenised-ipv6-identifiers-02
Published:
Intended Status:
Informational
Expires:
Author:
T.J. Chown
University of Southampton

Tokenised IPv6 Identifiers

Abstract

This text is intended to open discussion towards the adoption of support for tokenised IPv6 interface identifiers in IPv6 nodes. The primary target for such support is server platforms where addresses are usually manually configured, rather than using DHCPv6 or SLAAC. By using tokenised identifiers, hosts can still determine their network prefix by use of SLAAC, but more readily be automatically renumbered should their network prefix change.

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 4 April 2013.

Table of Contents

1. Introduction

The usual choices for IPv6 nodes to obtain addresses are Stateless Address Autoconfiguration (SLAAC) [RFC4862], DHCPv6 [RFC3315], or manual configuration. Client devices generally use SLAAC or DHCPv6. In the case of server systems, interface addresses are typically both static and manually configured. SLAAC is not used in case the interface hardware changes and the associated SLAAC generated address changes with it. DHCPv6 is often not used due to concerns of server stability should DHCPv6 fail.

The disadvantage with static addresses is that they are likely to require manual editing should the network prefix in use change. If instead there were a method to only manually configure the static identifier part of the IPv6 address, then the address could be automatically updated when a new prefix was introduced, as described in [RFC4192] for example. In such cases a DNS server might be configured with such a tokenised interface identifier of ::53, and SLAAC would use the token in constructing the interface address, using the advertised prefix.

2. Tokenised IPv6 identifier support

The author is aware of support for tokenised IPv6 identifiers in Solaris, and of a proof of concept implementation for Linux.

Under Solaris, tokenised identifiers can be configured directly with ifconfig, e.g.

ifconfig qfe0 inet6 token ::53/64

or the configuration can be made persistent by adding a line to the appropriate /etc/hostname6.interface file.

In the Linux proof of concept implementation [Thompson05], a command line can be used to configure the interface:

ip6token eth0 ::53

The specifics of how such tokenised identifiers are configured are likely to be operating system dependent. The important point is that such identifier configuration should be supported.

3. On the static address problem

This approach would address in part the problems discussed in [I-D.ietf-6renum-static-problem] in Sections 2.3 and 2.8, for the address configuration of server systems.

While a broader solution for the management of static addresses is desirable, tokenised identifiers present a useful interim step, if vendors choose to support the concept.

4. Conclusions

It would be desirable if all potential IPv6 server platforms supported tokenised interface identifiers. There may also be benefits for other IPv6 nodes to do so.

The author welcomes feedback on this draft, and any comments on platforms currently supporting such identifier configuration, or any reasons why wider implementation should not be considered.

5. Security Considerations

There are no extra security consideration for this document.

6. IANA Considerations

There are no extra IANA consideration for this document.

7. Acknowledgments

The author thanks the 6NET project under which considerations of tokenised identifiers was originally made, and colleague (at the time) Mark Thompson for his proof of concept implementation of such identifiers on a Linux platform.

8. Informative References

[RFC3315]
Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, , <https://www.rfc-editor.org/info/rfc3315>.
[RFC4192]
Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, DOI 10.17487/RFC4192, , <https://www.rfc-editor.org/info/rfc4192>.
[RFC4862]
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, , <https://www.rfc-editor.org/info/rfc4862>.
[I-D.ietf-6renum-static-problem]
Carpenter, B. and S. Jiang, "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks", Work in Progress, Internet-Draft, draft-ietf-6renum-static-problem-03, , <http://www.ietf.org/internet-drafts/draft-ietf-6renum-static-problem-03.txt>.
[Thompson05]
Thompson, M., "Introducing IPv6 Tokenised Interface Identifiers into the Linux Kernel", , <http://eprints.ecs.soton.ac.uk/11045/1/tokenisedlinux.pdf>.

Author's Address

Tim Chown
University of Southampton
Highfield
Southampton
SO17 1BJ
United Kingdom