idnits 2.17.1 draft-krishnan-6man-uat-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 : ---------------------------------------------------------------------------- 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 (July 6, 2015) is 3216 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track July 6, 2015 5 Expires: January 7, 2016 7 Uplink access technology indications in Router Advertisements 8 draft-krishnan-6man-uat-00 10 Abstract 12 In IPv6 networks Router Advertisements can be used for providing 13 common configuration information to nodes that are attached. There 14 are some scenarios where it is advantageous for routers to provide 15 their uplink access technology information to attached hosts. This 16 document describes a neighbor discovery option that will allow the 17 routers to do so. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 7, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Uplink Access Technology option . . . . . . . . . . . . . . . 3 56 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 61 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 In several IPv6 networks, the access technology used by routers on 67 their uplinks is different from that used on their downlinks. There 68 are some scenarios where it is advantageous for routers to provide 69 their uplink access technology information to the hosts attached on 70 the downlinks. One such example is a tethering scenario where a 71 mobile phone that uses a cellular uplink such as LTE, shares its 72 internet connection to hosts that connect over a local WiFi link. In 73 this case it would be beneficial for hosts to know that the uplink 74 connection is a cellular link and potentially modify their behavior 75 based on their knowledge. e.g. Application and software updates (and 76 similar bulk transfers) could be rescheduled based on administrative 77 configuration. 79 This document describes an IPv6 Neighbor discovery option [RFC4861] 80 for routers to advertise their uplink access technology(ies) in a 81 router advertisement message. 83 2. Terminology 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]. 89 3. Uplink Access Technology option 91 This option is to be carried in RA messages sent out by a router on a 92 given link. It specifies the uplink type(s) that the router uses. 94 0 1 2 3 95 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Type | Length | Uplink Access Technology | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | reserved (set to 0) | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 Type 104 8-bit identifier of the type of option. The option identifier 105 for the UAT option will be allocated by the IANA. 107 Length 109 8-bit unsigned integer. The length of the option (including 110 the type and length fields) in units of 8 octets. It MUST be 111 set to 1. 113 Uplink Access Technology 115 A 16-bit field that specifies the uplink access technology used 116 by the router sending the Router Avertisement carrying this 117 option. 119 Figure 1: Uplink Access Technology (UAT) Option Layout 121 Multiple UAT options MAY be present in a single Router Advertisement 122 message to allow for routers that use multiple uplinks. This 123 document defines the following initial values for the UAT field that 124 can be extended by adding new values to the IANA registry. 126 UAT Access Technology 127 0x01 3GPP 128 0x02 DSL 129 0x03 Cable 130 0x04 802.3 132 Figure 2 134 4. Router Behavior 135 The value of the UAT(s) provided in this option can either be 136 administratively configured or implicitly derived from the access 137 technology type on the uplink interfaces. 139 5. Host Behavior 141 The value of the UAT(s) provided in this option is purely 142 informational. It helps the hosts gleam additional information about 143 the router's uplink and perform different actions. Legacy hosts that 144 do not recognize this option will simply ignore it. 146 6. Security Considerations 148 An attacker may attempt to modify the information provided inside 149 this option to make hosts . These attacks can easily be prevented by 150 using SeND [RFC3971] 152 7. IANA Considerations 154 This document defines a new IPv6 neighbor discovery option for 155 carrying the uplink access technology type(s). IANA is requested to 156 create a new registry for storing uplink access technology types and 157 populate it with the following initial values. 159 UAT Access Technology Reference 160 0x01 3GPP [RFC-krishnan-6man-uat-00.txt] 161 0x02 DSL [RFC-krishnan-6man-uat-00.txt] 162 0x03 Cable [RFC-krishnan-6man-uat-00.txt] 163 0x04 802.3 [RFC-krishnan-6man-uat-00.txt] 165 Figure 3 167 8. Acknowledgements 169 TBA. 171 9. Normative References 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, March 1997. 176 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 177 Neighbor Discovery (SEND)", RFC 3971, March 2005. 179 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 180 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 181 September 2007. 183 Author's Address 185 Suresh Krishnan 186 Ericsson 187 8400 Decarie Blvd. 188 Town of Mount Royal, QC 189 Canada 191 Phone: +1 514 345 7900 x42871 192 Email: suresh.krishnan@ericsson.com