idnits 2.17.1 draft-liu-6man-nd-nms-discovery-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 (October 21, 2013) is 3811 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- 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. -------------------------------------------------------------------------------- 1 Network Working Group B. Liu 2 Internet Draft Huawei Technologies 3 Intended status: Stand Track October 21, 2013 4 Expires: April 24, 2014 6 IPv6 ND Option for Network Management Server Discovery 7 draft-liu-6man-nd-nms-discovery-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF). Note that other groups may also distribute working 16 documents as Internet-Drafts. The list of current Internet-Drafts is 17 at http://datatracker.ietf.org/drafts/current/. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 This Internet-Draft will expire on April 24, 2014. 26 Copyright Notice 28 Copyright (c) 2013 IETF Trust and the persons identified as the 29 document authors. All rights reserved. 31 This document is subject to BCP 78 and the IETF Trust's Legal 32 Provisions Relating to IETF Documents 33 (http://trustee.ietf.org/license-info) in effect on the date of 34 publication of this document. Please review these documents 35 carefully, as they describe your rights and restrictions with respect 36 to this document. Code Components extracted from this document must 37 include Simplified BSD License text as described in Section 4.e of 38 the Trust Legal Provisions and are provided without warranty as 39 described in the Simplified BSD License. 41 Abstract 43 This document introduces a mechanism for devices to actively learn 44 the NMS server address from the neighbors through IPv6 ND protocol 45 extension. It is a good leverage of IPv6 automatic features. 47 This document only discusses problem/solution within the IPv6-only 48 networks/plane. 50 Table of Contents 52 1. Introduction ................................................. 3 53 2. Basic Approach ............................................... 3 54 3. Scenario Description.......................................... 3 55 3.1. New Devices Getting Online .............................. 3 56 3.2. Regarding Connectivity .................................. 4 57 4. Neighbor Discovery Extension for Supporting NMS Discovery .... 4 58 4.1. Option Definition ....................................... 5 59 4.2. Sub-Options Definition .................................. 5 60 4.3. Option Carried in Router Advertisement Messages ......... 6 61 4.4. Option Carried in Neighbor Solicit/Advertisement Messages 7 62 5. Security Considerations ...................................... 7 63 6. IANA Considerations .......................................... 7 64 7. Acknowledgments .............................................. 7 65 8. References ................................................... 7 66 8.1. Normative References .................................... 7 68 1. Introduction 70 NMS (Network Management System) has become a must-have component in 71 modern networks. It could be utilized to benefit various aspects of a 72 network. For example, the emerging router auto-configuration 73 solutions are mostly based on NMS. If the devices could successfully 74 connect to the NMS server(s), then auto-configuration won't be a 75 problem. 77 So there is a key problem of how to discover the NMS server for the 78 devices when they get online. Currently there are mainly two methods 79 to solve the problem. One is to set the NMS server's IP/URL into the 80 devices before shipping to the customer premises; the other one is 81 the NMS actively discovering the devices through some polling 82 mechanisms. The former one is easy to be implemented and deployed, 83 but it lacks flexibility due to the static pre-configuration and 84 might be error-prone for configuration when the different networks 85 have different NMS servers; the latter one lacks the instantaneity 86 due to the polling mechanisms need the intermediate nodes to 87 integrate supporting features which introduce complex functions and 88 protocols. 90 This document introduces a mechanism for devices to actively learn 91 the NMS server from the neighbors through IPv6 ND protocol extension. 92 It is a good leverage of IPv6 automatic features. 94 This document only discusses problem/solution within the IPv6-only 95 scope. 97 2. Basic Approach 99 When a device gets online, we could assume that its neighbors who 100 have already got online have learnt the NMS server's address. So it 101 is quite easy for the new device to learn the information from its 102 neighbor. 104 This document is based on the above Neighbor-Learning approach. 106 3. Scenario Description 108 3.1. New Devices Getting Online 110 - Adding a New Device into an Existing Network 111 For adding a new device into an existing network, it is very 112 reasonable to assume that the neighbors have already connected to the 113 NMS server. So it is obvious that the new device could easily learn 114 the NMS server's address from neighbors. 116 - Deploying a New Network 118 In the case of deploying a new network, the NMS server address needs 119 to be propagated to the whole network, then some kind of flooding 120 mechanism is needed if the propagation also relies on above mentioned 121 neighbor-learning approach. This is applicable through careful plan 122 which might need proper order for the devices to get online 123 successively. 125 The detail of the flooding mechanism is out of the scope of this 126 document. We treat it as an assumption for the application of 127 neighbor-learning NMS discovery. 129 3.2. Regarding Connectivity 131 - Connecting NMS after Getting Global Connectivity 133 Normally, address assignment is not coupled with NMS processings. 134 Before connected to the NMS server, the devices could obtain global 135 connectivity either through SLAAC or DHCPv6. 137 In this case, once the devices have learnt the NMS server address, 138 they could directly connect to get more configurations. 140 - Connecting NMS before Getting Global Connectivity 142 In contrast, address assignment might be done through NMS in some 143 situations. For example, the device is a backbone router, and the 144 address has been carefully planned and pre-configured in the NMS 145 server, when the device connect to the server, it will be assigned 146 global address through network management processing. 148 In this case, after learning the NMS server address, the device might 149 need a proxy to communicate with the server or configuring itself a 150 ULA address and utilizing the NPTv6 processing on its neighbor or 151 uplink router. The details are out of the scope of this document. 153 4. Neighbor Discovery Extension for Supporting NMS Discovery 155 Since ND is a basic protocol in IPv6, every router supports IPv6 156 would support ND, we utilize ND extension to achieve the above 157 mentioned neighbor-learning NMS server discovery. 159 4.1. Option Definition 161 This section introduces a new option defined to carry the NMS address 162 in ND messages. 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Type | Length | sub-option(s)... 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 1: Neighbor Discovery NMS Discovery Option 172 o Type: TBD (to be assigned by IANA) 174 o Length: The length of the option (including the type and length 175 fields) in units of 8 octets. 177 o sub-option(s): using sub-option(s) to allow multiple formats of the 178 NMS server location. Sub-option(s) are defined as the following 179 Section 4.2. 181 4.2. Sub-Options Definition 183 To support multiple NMS server location formats, three sub-options 184 are defined as the following. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | IPv6 Address... 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 ... | 192 + + 193 | | 194 + + 195 | (cont.) IPv6 Address | 196 + + 197 | | 198 + | 199 | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 2: IPv6-Address Sub-option of NMS Server Location 204 o Type: TBD (to be assigned by IANA) 205 o Length: 3 207 o IPv6 Address: 128bit IPv6 address with zero padding behind 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Type | Length | FQDN... 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 3: FQDN Sub-option of NMS Server Location 217 o Type: TBD (to be assigned by IANA) 219 o Length: The length of the option (including the type and length 220 fields) in units of 8 octets. 222 o FQDN: FQDN of the NMS server, variable length 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Type | Length | URL... 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 3: FQDN Sub-option of NMS Server Location 232 o Type: TBD (to be assigned by IANA) 234 o Length: The length of the option (including the type and length 235 fields) in units of 8 octets. 237 o URL: URL of the NMS server, variable length 239 4.3. Option Carried in Router Advertisement Messages 241 - RA-only Mode 243 A device discoveries NMS server's address through received Router 244 Advertisement messages which include a new option defined for 245 carrying NMS server's address. 247 Since RA messages are usually generated by the gateway on a link, 248 this approach is suitable for a hub-and-spoke subnet in which a new 249 device joins in. 251 After having learnt the NMS server's address, then the device could 252 directly connect to the server 254 4.4. Option Carried in Neighbor Solicit/Advertisement Messages 256 A device discoveries NMS server's address through actively initiating 257 Neighbor Solicit message and receiving Neighbor Advertisement 258 messages which include the new option carrying the NMS server's 259 address. 261 This approach is suitable for point-to-point or non-broad circuits. 263 5. Security Considerations 265 - Device authentication for NMS Servers 267 With applying the mechanism described in this document, the devices 268 would actively connect to the NMS servers. So there might be stronger 269 desire for the NMS servers to authenticate the devices. 271 - ND security 273 This document doesn't introduce more threats than original Neighbor 274 Discovery protocol, so generally it aligns with the security 275 considerations described in [RFC4861]. 277 6. IANA Considerations 279 The newly defined options need IANA to assign type codes. 281 7. Acknowledgments 283 Many useful comments and contributions were made by Sheng Jiang. 285 8. References 287 8.1. Normative References 289 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 290 "Neighbor Discovery for IP version 6 (IPv6)", RFC 291 4861,September 2007. 293 Authors' Addresses 295 Bing Liu 296 Huawei Technologies Co., Ltd 297 Q14, Huawei Campus 298 No.156 Beiqing Rd. 299 Hai-Dian District, Beijing 100095 300 P.R. China 302 Email: leo.liubing@huawei.com