idnits 2.17.1 draft-templin-6man-aeroaddr-00.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 05, 2017) is 2488 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) == Unused Reference: 'I-D.templin-aerolink' is defined on line 186, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-82) exists of draft-templin-aerolink-75 Summary: 1 error (**), 0 flaws (~~), 5 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 05, 2017 5 Intended status: Standards Track 6 Expires: December 7, 2017 8 The AERO Address 9 draft-templin-6man-aeroaddr-00.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 along with Duplicate Address Detection (DAD). This document presents 17 a method for a node to construct a link-local address that is assured 18 to be unique on the link when the node has already received a 19 delegated prefix. This is through the construction of a link-local 20 address format known as the AERO address. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 7, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. The AERO Address . . . . . . . . . . . . . . . . . . . . . . 2 59 4. Intended Use Cases . . . . . . . . . . . . . . . . . . . . . 3 60 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 3 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 66 9.2. Informative References . . . . . . . . . . . . . . . . . 4 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 IPv6 interfaces are required to have a link-local address that is 72 unique on the link [RFC2460][RFC4861]. Nodes normally derive a link 73 local address through the use of IPv6 StateLess Address Auto 74 Configuration (SLAAC) along with Duplicate Address Detection (DAD) 75 [RFC4862]. This document presents a method for a node to construct a 76 link-local address that is assured to be unique on the link when the 77 node has already received a delegated prefix. This is through the 78 construction of a link-local address format known as the AERO 79 address. 81 2. Terminology 83 The terminology in the normative references applies. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. Lower case 88 uses of these words are not to be interpreted as carrying RFC2119 89 significance. 91 3. The AERO Address 93 An AERO address is an IPv6 link-local address with an interface 94 identifier based on a prefix that has been delegated to a node for 95 its own exclusive use. AERO addresses begin with the prefix 96 fe80::/64 and include in the interface identifier (i.e., the lower 64 97 bits) a 64-bit prefix taken from one of the node's delegated 98 prefixes. For example, if the node receives the IPv6 prefix: 100 2001:db8:1000:2000::/64 102 it constructs its corresponding AERO addresses as: 104 fe80::2001:db8:1000:2000 106 After constructing the AERO address, the node can assign the address 107 to the interface over which it received the prefix delegation. Since 108 the prefix delegation is already known to be unique, the node need 109 not use Duplicate Address Detection (DAD) to test the AERO address 110 for uniqueness since no other node on the link will configure the 111 same address. 113 AERO addresses can be constructed for any IPv6 prefix that is no 114 longer than /64. For prefixes shorter than /64, the AERO address is 115 constructed based on the lowest-numbered /64 prefix taken from the 116 shorter prefix. For example, if the node received the IPv6 prefix: 118 2001:db8:1000:2000::/56 120 it constructs its corresponding AERO addresses as: 122 fe80::2001:db8:1000:2000 124 4. Intended Use Cases 126 The AERO address is intended for use by mobile networks that comprise 127 a mobile router and a tethered network of "Internet of Things" 128 devices that travel together with the router as a single unit. The 129 mobile router assigns the AERO address to its upstream interface over 130 which it receives a prefix delegation from a delegating router. The 131 manner for receiving the delegated prefix could be through static 132 configuration or some automated prefix delegation service. 134 Many other use case scenarios are possible (e.g., home networks) but 135 the above case extends to multitudes of applications, e.g., a cell 136 phone and its associated devices, an airplane and its on-board 137 network, etc. 139 5. Implementation Status 141 Public domain implementations exist that use the AERO address format 142 as described in this document. 144 6. IANA Considerations 146 This document introduces no IANA considerations. 148 7. Security Considerations 150 TBD 152 8. Acknowledgements 154 This work was sponsored through several ongoing initiatives, 155 including 1) the NASA Safe Autonomous Systems Operation (SASO) 156 program under NASA contract number NNA16BD84C, 2) the FAA SE2025 157 contract number DTFAWA-15-D-00030, 3) the Boeing Information 158 Technology (BIT) MobileNet program, and 4) the Boeing Research & 159 Technology (BR&T) enterprise autonomy program. 161 9. References 163 9.1. Normative References 165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 166 Requirement Levels", BCP 14, RFC 2119, 167 DOI 10.17487/RFC2119, March 1997, 168 . 170 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 171 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 172 December 1998, . 174 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 175 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 176 DOI 10.17487/RFC4861, September 2007, 177 . 179 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 180 Address Autoconfiguration", RFC 4862, 181 DOI 10.17487/RFC4862, September 2007, 182 . 184 9.2. Informative References 186 [I-D.templin-aerolink] 187 Templin, F., "Asymmetric Extended Route Optimization 188 (AERO)", draft-templin-aerolink-75 (work in progress), May 189 2017. 191 Author's Address 193 Fred L. Templin (editor) 194 Boeing Research & Technology 195 P.O. Box 3707 196 Seattle, WA 98124 197 USA 199 Email: fltemplin@acm.org