idnits 2.17.1 draft-chown-6man-tokenised-ipv6-identifiers-02.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 (October 22, 2012) is 4201 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-03) exists of draft-ietf-6renum-static-problem-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance T. Chown 3 Internet-Draft University of Southampton 4 Intended status: Informational October 22, 2012 5 Expires: April 25, 2013 7 Tokenised IPv6 Identifiers 8 draft-chown-6man-tokenised-ipv6-identifiers-02 10 Abstract 12 This text is intended to open discussion towards the adoption of 13 support for tokenised IPv6 interface identifiers in IPv6 nodes. The 14 primary target for such support is server platforms where addresses 15 are usually manually configured, rather than using DHCPv6 or SLAAC. 16 By using tokenised identifiers, hosts can still determine their 17 network prefix by use of SLAAC, but more readily be automatically 18 renumbered should their network prefix change. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 25, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Tokenised IPv6 identifier support . . . . . . . . . . . . . . . 3 56 3. On the static address problem . . . . . . . . . . . . . . . . . 3 57 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 60 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 61 8. Informative References . . . . . . . . . . . . . . . . . . . . 4 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 The usual choices for IPv6 nodes to obtain addresses are Stateless 67 Address Autoconfiguration (SLAAC) [RFC4862], DHCPv6 [RFC3315], or 68 manual configuration. Client devices generally use SLAAC or DHCPv6. 69 In the case of server systems, interface addresses are typically both 70 static and manually configured. SLAAC is not used in case the 71 interface hardware changes and the associated SLAAC generated address 72 changes with it. DHCPv6 is often not used due to concerns of server 73 stability should DHCPv6 fail. 75 The disadvantage with static addresses is that they are likely to 76 require manual editing should the network prefix in use change. If 77 instead there were a method to only manually configure the static 78 identifier part of the IPv6 address, then the address could be 79 automatically updated when a new prefix was introduced, as described 80 in [RFC4192] for example. In such cases a DNS server might be 81 configured with such a tokenised interface identifier of ::53, and 82 SLAAC would use the token in constructing the interface address, 83 using the advertised prefix. 85 2. Tokenised IPv6 identifier support 87 The author is aware of support for tokenised IPv6 identifiers in 88 Solaris, and of a proof of concept implementation for Linux. 90 Under Solaris, tokenised identifiers can be configured directly with 91 ifconfig, e.g. 93 ifconfig qfe0 inet6 token ::53/64 95 or the configuration can be made persistent by adding a line to the 96 appropriate /etc/hostname6.interface file. 98 In the Linux proof of concept implementation [Thompson05], a command 99 line can be used to configure the interface: 101 ip6token eth0 ::53 103 The specifics of how such tokenised identifiers are configured are 104 likely to be operating system dependent. The important point is that 105 such identifier configuration should be supported. 107 3. On the static address problem 109 This approach would address in part the problems discussed in 111 [I-D.ietf-6renum-static-problem] in Sections 2.3 and 2.8, for the 112 address configuration of server systems. 114 While a broader solution for the management of static addresses is 115 desirable, tokenised identifiers present a useful interim step, if 116 vendors choose to support the concept. 118 4. Conclusions 120 It would be desirable if all potential IPv6 server platforms 121 supported tokenised interface identifiers. There may also be 122 benefits for other IPv6 nodes to do so. 124 The author welcomes feedback on this draft, and any comments on 125 platforms currently supporting such identifier configuration, or any 126 reasons why wider implementation should not be considered. 128 5. Security Considerations 130 There are no extra security consideration for this document. 132 6. IANA Considerations 134 There are no extra IANA consideration for this document. 136 7. Acknowledgments 138 The author thanks the 6NET project under which considerations of 139 tokenised identifiers was originally made, and colleague (at the 140 time) Mark Thompson for his proof of concept implementation of such 141 identifiers on a Linux platform. 143 8. Informative References 145 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 146 and M. Carney, "Dynamic Host Configuration Protocol for 147 IPv6 (DHCPv6)", RFC 3315, July 2003. 149 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 150 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 151 September 2005. 153 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 154 Address Autoconfiguration", RFC 4862, September 2007. 156 [I-D.ietf-6renum-static-problem] 157 Carpenter, B. and S. Jiang, "Problem Statement for 158 Renumbering IPv6 Hosts with Static Addresses", 159 draft-ietf-6renum-static-problem-02 (work in progress), 160 September 2012. 162 [Thompson05] 163 Thompson, M., "Introducing IPv6 Tokenised Interface 164 Identifiers into the Linux Kernel", 2005, . 167 Author's Address 169 Tim Chown 170 University of Southampton 171 Highfield 172 Southampton, Hampshire SO17 1BJ 173 United Kingdom 175 Email: tjc@ecs.soton.ac.uk