idnits 2.17.1 draft-templin-6man-aeroaddr-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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 04, 2018) is 2153 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 (-27) exists of draft-templin-v6ops-pdhost-20 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Updates: rfc4191, rfc4861 (if approved) June 04, 2018 5 Intended status: Standards Track 6 Expires: December 6, 2018 8 The AERO Address 9 draft-templin-6man-aeroaddr-02.txt 11 Abstract 13 IPv6 interfaces are required to have a link-local address that is 14 unique on the link. Nodes normally derive a link local address 15 through the use of IPv6 Stateless Address Autoconfiguration (SLAAC) 16 and employ Duplicate Address Detection (DAD) to ensure uniqueness. 17 This document presents a method for a node that obtains a delegated 18 prefix to statelessly construct a link-local address (known as the 19 "AERO address") that is assured to be unique on the link. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 6, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. The AERO Address . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 65 9.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 IPv6 interfaces are required to have a link-local address that is 71 unique on the link [RFC8200][RFC4861]. Nodes normally derive a link 72 local address through the use of IPv6 StateLess Address Auto 73 Configuration (SLAAC) and employ Duplicate Address Detection (DAD) 74 [RFC4862] to ensure uniqueness. This document presents a method for 75 a node that obtains a delegated prefix to statelessly construct a 76 link-local address (known as the "AERO address") that is assured to 77 be unique on the link. 79 Nodes that construct AERO addresses must have assurance that all 80 other nodes on the link employ the same address autoconfiguration 81 method. This can be assured on links for which there is an 82 "IPv6-over-(foo)" specfication that mandates use of AERO addresses 83 (e.g., see: [I-D.templin-aerolink]). Other link types can be 84 administratively coordinated (e.g., via network management) to assure 85 that only AERO addresses are used. 87 2. Terminology 89 The terminology in the normative references applies. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. Lower case 94 uses of these words are not to be interpreted as carrying RFC2119 95 significance. 97 3. The AERO Address 99 An AERO address is an IPv6 link-local address with an interface 100 identifier based on a prefix that has been delegated to a node for 101 its own exclusive use. AERO addresses begin with the prefix 102 fe80::/64 and include in the interface identifier (i.e., the lower 64 103 bits) a 64-bit prefix taken from one of the node's delegated 104 prefixes. For example, if the node obtains the delegated prefix: 106 2001:db8:1000:2000::/64 108 it constructs its corresponding AERO addresses as: 110 fe80::2001:db8:1000:2000 112 After constructing the AERO address, the node can assign the address 113 to the interface over which it received the prefix delegation. Since 114 the prefix delegation is already known to be unique, the node need 115 not use Duplicate Address Detection (DAD) to test the AERO address 116 for uniqueness. 118 AERO addresses can be constructed for any IPv6 prefix that is no 119 longer than /64. For prefixes shorter than /64, the AERO address is 120 constructed based on the lowest-numbered /64 prefix taken from the 121 shorter prefix. For example, if the node obtains the delegated 122 prefix: 124 2001:db8:1000:2000::/56 126 it constructs its corresponding AERO addresses as: 128 fe80::2001:db8:1000:2000 130 4. Applicability 132 The AERO address is intended for use by mobile networks that comprise 133 a mobile router and a tethered network of "Internet of Things" 134 devices that travel together with the router as a single unit. The 135 mobile router assigns the AERO address to its upstream interface over 136 which it receives a prefix delegation from a delegating router. The 137 manner for receiving the delegated prefix could be through static 138 configuration or some automated prefix delegation service. 140 Many other use case scenarios are possible (e.g., home networks) but 141 the above case extends to multitudes of applications, e.g., a cell 142 phone and its associated devices, an airplane and its on-board 143 network, etc. A similar uses case exists for a mobile node that 144 obtains a delegated prefix solely for its own internal multi- 145 addressing purposes. These use cases are discussed in 146 [I-D.templin-v6ops-pdhost]. 148 5. Implementation Status 150 Public domain implementations exist that use the AERO address format 151 as described in this document. 153 6. IANA Considerations 155 This document introduces no IANA considerations. 157 7. Security Considerations 159 TBD 161 8. Acknowledgements 163 This work is aligned with the NASA Safe Autonomous Systems Operation 164 (SASO) program under NASA contract number NNA16BD84C. 166 This work is aligned with the FAA as per the SE2025 contract number 167 DTFAWA-15-D-00030. 169 This work is aligned with the Boeing Information Technology (BIT) 170 MobileNet program and the Boeing Research & Technology (BR&T) 171 enterprise autonomy program. 173 9. References 175 9.1. Normative References 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, 179 DOI 10.17487/RFC2119, March 1997, 180 . 182 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 183 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 184 DOI 10.17487/RFC4861, September 2007, 185 . 187 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 188 Address Autoconfiguration", RFC 4862, 189 DOI 10.17487/RFC4862, September 2007, 190 . 192 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 193 (IPv6) Specification", STD 86, RFC 8200, 194 DOI 10.17487/RFC8200, July 2017, 195 . 197 9.2. Informative References 199 [I-D.templin-aerolink] 200 Templin, F., "Asymmetric Extended Route Optimization 201 (AERO)", draft-templin-aerolink-82 (work in progress), May 202 2018. 204 [I-D.templin-v6ops-pdhost] 205 Templin, F., "IPv6 Prefix Delegation Models", draft- 206 templin-v6ops-pdhost-20 (work in progress), May 2018. 208 Author's Address 210 Fred L. Templin (editor) 211 Boeing Research & Technology 212 P.O. Box 3707 213 Seattle, WA 98124 214 USA 216 Email: fltemplin@acm.org