idnits 2.17.1 draft-behringer-anima-autonomic-addressing-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 237: '...y autonomic node MUST respond to its A...' RFC 2119 keyword, line 250: '...rt of a zone, it MUST also respond to ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2015) is 3086 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-behringer-anima-reference-model-03 ** Downref: Normative reference to an Informational draft: draft-behringer-anima-reference-model (ref. 'I-D.behringer-anima-reference-model') == Outdated reference: A later version (-02) exists of draft-eckert-anima-stable-connectivity-01 ** Downref: Normative reference to an Informational draft: draft-eckert-anima-stable-connectivity (ref. 'I-D.eckert-anima-stable-connectivity') == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-01 ** Downref: Normative reference to an Informational draft: draft-irtf-nmrg-autonomic-network-definitions (ref. 'I-D.irtf-nmrg-autonomic-network-definitions') ** Downref: Normative reference to an Informational RFC: RFC 7404 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA M. Behringer 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track October 16, 2015 5 Expires: April 18, 2016 7 An Autonomic IPv6 Addressing Scheme 8 draft-behringer-anima-autonomic-addressing-02 10 Abstract 12 This document describes a generic IPv6 addressing scheme which is 13 suitable for self-managing Autonomic Control Plane. The scheme 14 allows for a flat address hierarchy as well as optionally, when 15 required, the definition of aggregatable zones. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 18, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Fundamental Concepts of Autonomic Addressing . . . . . . . . 2 53 3. The Base Addressing Scheme . . . . . . . . . . . . . . . . . 3 54 4. Possible Sub-Schemes . . . . . . . . . . . . . . . . . . . . 4 55 4.1. Sub-Scheme 1 . . . . . . . . . . . . . . . . . . . . . . 4 56 4.2. Sub-Scheme 2 . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Usage of the Zone Field . . . . . . . . . . . . . . . . . . . 5 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 In an Autonomic Network, as defined in 67 [I-D.irtf-nmrg-autonomic-network-definitions], and specified in more 68 detail in [I-D.behringer-anima-reference-model], one of the design 69 goals is to minimise central functions. 71 In an autonomic network each node receives a domain-unique 72 identifier, which consists of a domain name and a unique node-ID in 73 that domain. We introduce an addressing scheme and an algorithm that 74 allows the calculation of a unique IPv6 ULA address from those 75 parameters. In other words, once a device has a unique node-ID and 76 domain name, this addressing scheme and algorithm allows for 77 distributed self-management of addressing inside a network. 79 The addressing scheme described here is specifically designed for the 80 Autonomic Control Plane (ACP; see 81 [I-D.ietf-anima-autonomic-control-plane]). It is for communication 82 inside the domain only, specifically to support self-management 83 functions. It may be used for OAM functions inside the ACP as well, 84 as described in [I-D.eckert-anima-stable-connectivity]. 86 2. Fundamental Concepts of Autonomic Addressing 88 We assume that each node has a unique domain name and a unique node 89 ID inside that domain. The fundamental concepts for autonomic 90 addressing are: 92 o IPv6 only: Autonomic processes should use exclusively IPv6, for 93 simplicity reasons. 95 o Usage: Autonomic addresses are exclusively used for self- 96 management functions inside a trusted domain. They are not used 97 for user traffic. Communications with entities outside the 98 trusted domain use another address space, for example normally 99 managed routable address space. 101 o Separation: Autonomic address space is used separately from user 102 address space and other address realms. This supports the 103 robustness requirement. 105 o Loopback-only: Only loopback interfaces of autonomic nodes carry a 106 routable address; all other interfaces exclusively use IPv6 link 107 local for autonomic functions. The usage of IPv6 link local 108 addressing is discussed in [RFC7404]. 110 o Use-ULA: For loopback interfaces of autonomic nodes, we use Unique 111 Local Addresses (ULA), as specified in [RFC4193]. An alternative 112 scheme was discussed, using assigned ULA addressing. The 113 consensus was to use standard ULA, because it was deemed to be 114 sufficient. 116 o No external connectivity: They do not provide access to the 117 Internet. If a node requires further reaching connectivity, it 118 should use another, traditionally managed address scheme in 119 parallel. 121 3. The Base Addressing Scheme 123 The Base ULA addressing scheme for autonomic nodes has the following 124 format: 126 8 40 3 77 127 +--+--------------+------+------------------------------------------+ 128 |FD| hash(domain) | Type | (sub-scheme) | 129 +--+--------------+------+------------------------------------------+ 131 Figure 1: Base Addressing Scheme 133 The first 48 bits follow the ULA scheme, as defined in [RFC4193], to 134 which a type field is added: 136 o "FD" identifies a locally defined ULA address. 138 o The "global ID" is set here to be a hash of the domain name, which 139 results in a pseudo-random 40 bit value. It is calculated as the 140 first 40 bits of the MD5 hash of the domain name, in the example 141 "example.com". 143 o Type: Set to 000 (3 zero bits). This field allows different 144 address sub-schemes in the future. The goal is to start with a 145 minimal number (ideally one) of sub-schemes initially, but to 146 allow for extensions later if and when required. This addresses 147 the "upgradability" requirement. Assignment of types for this 148 field should be maintained by IANA. 150 4. Possible Sub-Schemes 152 The sub-schemes listed here are not intended to be all supported 153 initially, but are listed for discussion. The final document should 154 define ideally only a single sub-scheme for now, and leave the other 155 "types" for later assignment. 157 4.1. Sub-Scheme 1 159 51 13 64 160 +------------------------+---------+--------------------------------+ 161 | (base scheme) | Zone ID | Device ID | 162 +------------------------+---------+--------------------------------+ 164 Figure 2: Addressing Scheme 1 166 The fields are defined as follows: [Editor's note: The lengths of the 167 fields is for discussion.] 169 o Zone ID: If set to all zero bits: The device ID bits are used as 170 an identifier (as opposed to a locator). This results in a non- 171 hierarchical, flat addressing scheme. Any other value indicates a 172 zone. See section Section 5 on how this field is used in detail. 174 o Device ID: A unique value for each device. 176 The device ID is derived as follows: In an Autonomic Network, a 177 registrar is enrolling new devices. As part of the enrolment process 178 the registrar assigns a number to the device, which is unique for 179 this registrar, but not necessarily unique in the domain. The 64 bit 180 device ID is then composed as: 182 o 48 bit: Registrar ID, a number unique inside the domain that 183 identifies the registrar which assigned the name to the device. A 184 MAC address of the registrar can be used for this purpose. 186 o 16 bit: Device number, a number which is unique for a given 187 registrar, to identify the device. This can be a sequentially 188 assigned number. 190 The "device ID" itself is unique in a domain (i.e., the Zone-ID is 191 not required for uniqueness). Therefore, a device can be addressed 192 either as part of a flat hierarchy (zone ID = 0), or with an 193 aggregation scheme (any other zone ID). A address with zone-ID could 194 be interpreted as an identifier, with another zone-ID as a locator. 195 See Section 5 for a description of the zone bits. 197 4.2. Sub-Scheme 2 199 51 13 64-V ? 200 +------------------------+---------+----------------------------+---+ 201 | (base scheme) | Zone ID | Device ID | V | 202 +------------------------+---------+----------------------------+---+ 204 Figure 3: Addressing Scheme 2 206 The fields are defined as follows: [Editor's note: The lengths of the 207 fields is for discussion.] 209 o Zone ID: As in sub-scheme 1. 211 o Device ID: As in sub-scheme 1. 213 o V: Virtualization bit(s): 1 or more bits that indicate a virtual 214 context on an autonomic node. 216 In addition the scheme 1 (Section 4.1), this scheme allows the direct 217 addressing of specific virtual containers / VMs on an autonomic node. 218 An increasing number of hardware platforms have a distributed 219 architecture, with a base OS for the node itself, and the support for 220 hardware blades with potentially different OSs. The VMs on the 221 blades could be considered as separate autonomic nodes, in which case 222 it would make sense to be able to address them directly. Autonomic 223 Service Agents (ASAs) could be instantiated in either the base OS, or 224 one of the VMs on a blade. This addressing scheme allows for the 225 easy separation of the hardware context. 227 The location of the V bit(s) at the end of the address allows to 228 announce a single prefix for each autonomic node, while having 229 separate virtual contexts addressable directly. 231 5. Usage of the Zone Field 233 The "zone ID" allows for the introduction of structure in the 234 addressing scheme. 236 Zone = zero is the default addressing scheme in an autonomic domain. 237 Every autonomic node MUST respond to its ACP address with zone=0. 238 Used on its own this leads to a non-hierarchical address scheme, 239 which is suitable for networks up to a certain size. In this case, 240 the addresses primarily act as identifiers for the nodes, and 241 aggregation is not possible. 243 If aggregation is required, the 13 bit value allows for up to 8191 244 zones. The allocation of zone numbers may either happen 245 automatically through a to-be-defined algorithm; or it could be 246 configured and maintained manually. [We could divide the zone space 247 into manual and automatic space - to be discussed.] 249 If a device learns through an autonomic method or through 250 configuration that it is part of a zone, it MUST also respond to its 251 ACP address with that zone number. In this case the ACP loopback is 252 configured with two ACP addresses: One for zone 0 and one for the 253 assigned zone. This method allows for a smooth transition between a 254 flat addressing scheme and an hierarchical one. 256 (Theoretically, the 13 bits for the zone ID would allow also for two 257 levels of zones, introducing a sub-hierarchy. We do not think this 258 is required at this point, but a new type could be used in the future 259 to support such a scheme.) 261 Note: Another way to introduce hierarchy is to use sub-domains in the 262 naming scheme. The node names "node17.subdomainA.example.com" and 263 "node4.subdomainB.example.com" would automatically lead to different 264 ULA prefixes, which can be used to introduce a routing hierarchy in 265 the network, assuming that the subdomains are aligned with routing 266 areas. 268 6. IANA Considerations 270 The type field in the base addressing scheme should be maintained by 271 IANA. 273 7. Security Considerations 275 tbc 277 8. Acknowledgements 279 The following people have been involved in developing this scheme: 280 Toerless Eckert, Steinthor Bjarnason, BL Balaji, Ravi Kumar 281 Vadapalli. 283 9. References 285 [I-D.behringer-anima-reference-model] 286 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 287 Liu, B., Jeff, J., and J. Strassner, "A Reference Model 288 for Autonomic Networking", draft-behringer-anima- 289 reference-model-03 (work in progress), June 2015. 291 [I-D.eckert-anima-stable-connectivity] 292 Eckert, T. and M. Behringer, "Using Autonomic Control 293 Plane for Stable Connectivity of Network OAM", draft- 294 eckert-anima-stable-connectivity-01 (work in progress), 295 March 2015. 297 [I-D.ietf-anima-autonomic-control-plane] 298 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 299 Autonomic Control Plane", draft-ietf-anima-autonomic- 300 control-plane-01 (work in progress), October 2015. 302 [I-D.irtf-nmrg-autonomic-network-definitions] 303 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 304 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 305 Networking - Definitions and Design Goals", draft-irtf- 306 nmrg-autonomic-network-definitions-07 (work in progress), 307 March 2015. 309 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 310 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 311 . 313 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 314 Addressing inside an IPv6 Network", RFC 7404, 315 DOI 10.17487/RFC7404, November 2014, 316 . 318 Author's Address 320 Michael H. Behringer 321 Cisco Systems 322 Building D, 45 Allee des Ormes 323 Mougins 06250 324 France 326 Email: mbehring@cisco.com