Network Working Group B. Liu Internet Draft Huawei Technologies Intended status: Stand Track October 21, 2013 Expires: April 24, 2014 IPv6 ND Option for Network Management Server Discovery draft-liu-6man-nd-nms-discovery-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 24, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Bing Liu Expires April 24, 2014 [Page 1] Internet-Draft IPv6 ND Option for NMS Discovery October 2013 Abstract This document introduces a mechanism for devices to actively learn the NMS server address from the neighbors through IPv6 ND protocol extension. It is a good leverage of IPv6 automatic features. This document only discusses problem/solution within the IPv6-only networks/plane. Table of Contents 1. Introduction ................................................. 3 2. Basic Approach ............................................... 3 3. Scenario Description.......................................... 3 3.1. New Devices Getting Online .............................. 3 3.2. Regarding Connectivity .................................. 4 4. Neighbor Discovery Extension for Supporting NMS Discovery .... 4 4.1. Option Definition ....................................... 5 4.2. Sub-Options Definition .................................. 5 4.3. Option Carried in Router Advertisement Messages ......... 6 4.4. Option Carried in Neighbor Solicit/Advertisement Messages 7 5. Security Considerations ...................................... 7 6. IANA Considerations .......................................... 7 7. Acknowledgments .............................................. 7 8. References ................................................... 7 8.1. Normative References .................................... 7 Bing Liu Expires April 24, 2014 [Page 2] Internet-Draft IPv6 ND Option for NMS Discovery October 2013 1. Introduction NMS (Network Management System) has become a must-have component in modern networks. It could be utilized to benefit various aspects of a network. For example, the emerging router auto-configuration solutions are mostly based on NMS. If the devices could successfully connect to the NMS server(s), then auto-configuration won't be a problem. So there is a key problem of how to discover the NMS server for the devices when they get online. Currently there are mainly two methods to solve the problem. One is to set the NMS server's IP/URL into the devices before shipping to the customer premises; the other one is the NMS actively discovering the devices through some polling mechanisms. The former one is easy to be implemented and deployed, but it lacks flexibility due to the static pre-configuration and might be error-prone for configuration when the different networks have different NMS servers; the latter one lacks the instantaneity due to the polling mechanisms need the intermediate nodes to integrate supporting features which introduce complex functions and protocols. This document introduces a mechanism for devices to actively learn the NMS server from the neighbors through IPv6 ND protocol extension. It is a good leverage of IPv6 automatic features. This document only discusses problem/solution within the IPv6-only scope. 2. Basic Approach When a device gets online, we could assume that its neighbors who have already got online have learnt the NMS server's address. So it is quite easy for the new device to learn the information from its neighbor. This document is based on the above Neighbor-Learning approach. 3. Scenario Description 3.1. New Devices Getting Online - Adding a New Device into an Existing Network Bing Liu Expires April 24, 2014 [Page 3] Internet-Draft IPv6 ND Option for NMS Discovery October 2013 For adding a new device into an existing network, it is very reasonable to assume that the neighbors have already connected to the NMS server. So it is obvious that the new device could easily learn the NMS server's address from neighbors. - Deploying a New Network In the case of deploying a new network, the NMS server address needs to be propagated to the whole network, then some kind of flooding mechanism is needed if the propagation also relies on above mentioned neighbor-learning approach. This is applicable through careful plan which might need proper order for the devices to get online successively. The detail of the flooding mechanism is out of the scope of this document. We treat it as an assumption for the application of neighbor-learning NMS discovery. 3.2. Regarding Connectivity - Connecting NMS after Getting Global Connectivity Normally, address assignment is not coupled with NMS processings. Before connected to the NMS server, the devices could obtain global connectivity either through SLAAC or DHCPv6. In this case, once the devices have learnt the NMS server address, they could directly connect to get more configurations. - Connecting NMS before Getting Global Connectivity In contrast, address assignment might be done through NMS in some situations. For example, the device is a backbone router, and the address has been carefully planned and pre-configured in the NMS server, when the device connect to the server, it will be assigned global address through network management processing. In this case, after learning the NMS server address, the device might need a proxy to communicate with the server or configuring itself a ULA address and utilizing the NPTv6 processing on its neighbor or uplink router. The details are out of the scope of this document. 4. Neighbor Discovery Extension for Supporting NMS Discovery Since ND is a basic protocol in IPv6, every router supports IPv6 would support ND, we utilize ND extension to achieve the above mentioned neighbor-learning NMS server discovery. Bing Liu Expires April 24, 2014 [Page 4] Internet-Draft IPv6 ND Option for NMS Discovery October 2013 4.1. Option Definition This section introduces a new option defined to carry the NMS address in ND messages. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | sub-option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Neighbor Discovery NMS Discovery Option o Type: TBD (to be assigned by IANA) o Length: The length of the option (including the type and length fields) in units of 8 octets. o sub-option(s): using sub-option(s) to allow multiple formats of the NMS server location. Sub-option(s) are defined as the following Section 4.2. 4.2. Sub-Options Definition To support multiple NMS server location formats, three sub-options are defined as the following. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IPv6 Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | + + | | + + | (cont.) IPv6 Address | + + | | + | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IPv6-Address Sub-option of NMS Server Location o Type: TBD (to be assigned by IANA) Bing Liu Expires April 24, 2014 [Page 5] Internet-Draft IPv6 ND Option for NMS Discovery October 2013 o Length: 3 o IPv6 Address: 128bit IPv6 address with zero padding behind 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | FQDN... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: FQDN Sub-option of NMS Server Location o Type: TBD (to be assigned by IANA) o Length: The length of the option (including the type and length fields) in units of 8 octets. o FQDN: FQDN of the NMS server, variable length 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | URL... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: FQDN Sub-option of NMS Server Location o Type: TBD (to be assigned by IANA) o Length: The length of the option (including the type and length fields) in units of 8 octets. o URL: URL of the NMS server, variable length 4.3. Option Carried in Router Advertisement Messages - RA-only Mode A device discoveries NMS server's address through received Router Advertisement messages which include a new option defined for carrying NMS server's address. Bing Liu Expires April 24, 2014 [Page 6] Internet-Draft IPv6 ND Option for NMS Discovery October 2013 Since RA messages are usually generated by the gateway on a link, this approach is suitable for a hub-and-spoke subnet in which a new device joins in. After having learnt the NMS server's address, then the device could directly connect to the server 4.4. Option Carried in Neighbor Solicit/Advertisement Messages A device discoveries NMS server's address through actively initiating Neighbor Solicit message and receiving Neighbor Advertisement messages which include the new option carrying the NMS server's address. This approach is suitable for point-to-point or non-broad circuits. 5. Security Considerations - Device authentication for NMS Servers With applying the mechanism described in this document, the devices would actively connect to the NMS servers. So there might be stronger desire for the NMS servers to authenticate the devices. - ND security This document doesn't introduce more threats than original Neighbor Discovery protocol, so generally it aligns with the security considerations described in [RFC4861]. 6. IANA Considerations The newly defined options need IANA to assign type codes. 7. Acknowledgments Many useful comments and contributions were made by Sheng Jiang. 8. References 8.1. Normative References [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,September 2007. Bing Liu Expires April 24, 2014 [Page 7] Internet-Draft IPv6 ND Option for NMS Discovery October 2013 Authors' Addresses Bing Liu Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China Email: leo.liubing@huawei.com