Cisco's Mobile IPv4 Host Configuration Extensions
RFC 4332
Document | Type | RFC - Informational (December 2005) | |
---|---|---|---|
Authors | Alpesh Patel , Kent Leung , George Tsirtsis , Espen Klovning | ||
Last updated | 2015-10-14 | ||
RFC stream | Independent Submission | ||
Formats | |||
IESG | Responsible AD | Margaret Cullen | |
Send notices to | (None) |
RFC 4332
Network Working Group X. Liu Internet-Draft Jabil Intended status: Standards Track P. Sarda Expires: April 29, 2018 Ericsson V. Choudhary Individual October 26, 2017 A YANG Data Model for Routing Information Protocol (RIP) draft-ietf-rtgwg-yang-rip-06 Abstract This document describes a data model for the Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. 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 29, 2018. Copyright Notice Copyright (c) 2017 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. Liu, et al. Expires April 29, 2018 [Page 1] Internet-Draft YANG RIP October 2017 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3 2. Design of the Data Model . . . . . . . . . . . . . . . . . . 4 2.1. Scope of the Model . . . . . . . . . . . . . . . . . . . 4 2.2. Relation with Core Routing Framework . . . . . . . . . . 4 2.3. Protocol Configuration . . . . . . . . . . . . . . . . . 4 2.4. Protocol States . . . . . . . . . . . . . . . . . . . . . 5 2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 7 2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 7 2.7. Optional Features . . . . . . . . . . . . . . . . . . . . 7 3. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 7 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.1. Normative References . . . . . . . . . . . . . . . . . . 36 7.2. Informative References . . . . . . . . . . . . . . . . . 37 Appendix A. Data Tree Example . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction This document introduces a YANG [RFC7950] data model for the Routing Information Protocol (RIP) [RFC2453][RFC2080]. RIP was designed to work as an Interior Gateway Protocol (IGP) in moderate-size Autonomous Systems (AS). This YANG model supports both RIP version 2 and RIPng. RIP version 2 (defined in [RFC2453]) supports IPv4. RIPng (defined in [RFC2080]) supports IPv6. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The following terms are defined in [RFC7950] and are not redefined here: o augment o data model Liu, et al. Expires April 29, 2018 [Page 2] Internet-Draft YANG RIP October 2017 o data node 1.2. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Curly braces "{" and "}" contain names of optional features that make the corresponding node conditional. o Abbreviations before data node names: "rw" means configuration (read-write), and "ro" means state data (read-only). o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list. o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 1.3. Prefixes in Data Node Names In this document, names of data nodes, actions, and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1. +-----------+-----------------+-----------------------------------+ | Prefix | YANG module | Reference | +-----------+-----------------+-----------------------------------+ | yang | ietf-yang-types | [RFC6991] | | inet | ietf-inet-types | [RFC6991] | | if | ietf-interfaces | [I-D.bjorklund-netmod-rfc7223bis] | | ip | ietf-ip | [I-D.bjorklund-netmod-rfc7277bis] | | rt | ietf-routing | [I-D.acee-netmod-rfc8022bis] | | bfd | ietf-bfd | [I-D.ietf-bfd-yang] | | isis | ietf-isis | [I-D.ietf-isis-yang-isis-cfg] | | key-chain | ietf-key-chain | [RFC8177] | | ospf | ietf-ospf | [I-D.ietf-ospf-yang] | +-----------+-----------------+-----------------------------------+ Table 1: Prefixes and Corresponding YANG Modules Liu, et al. Expires April 29, 2018 [Page 3] Internet-Draft YANG RIP October 2017 2. Design of the Data Model 2.1. Scope of the Model The model covers RIP version 2 [RFC2453] and RIPng [RFC2080] protocols. The model is designed to be implemented on a device where RIP version 2 or RIPng is implemented, and can be used to: o Configure the RIP version 2 or RIPng protocol. o Manage the protocol operational behaviors. o Retrieve the protocol operational status. The capabilities describe in [RFC1724] are covered. 2.2. Relation with Core Routing Framework This model augments the core routing data model "ietf-routing" specified in [I-D.acee-netmod-rfc8022bis]. +--rw routing +--rw router-id? +--rw control-plane-protocols | +--rw control-plane-protocol* [type name] | +--rw type | +--rw name | +--rw rip <= Augmented by this Model ... The "rip" container instantiates a RIP protocol entity that supports RIP version 2 or RIPng. Depending on the implementation of "ietf- routing", a RIP instance MAY belong to a logical router or network instance. 2.3. Protocol Configuration The model structure for the protocol configuration is as shown below: Liu, et al. Expires April 29, 2018 [Page 4] Internet-Draft YANG RIP October 2017 augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw rip +--rw <per instance configuration> +--rw interface* [interface] +--rw interface if:interface-ref +--rw <per interface configuration> +--rw neighbors {explicit-neighbors}? | +--rw neighbor* [address] | +--rw address inet:ip-address | +--rw <per neighbor configuration> The model allows to configure the following protocol entities: o Protocol instance (RIP version 2 or RIPng) o Interface o Neighbor 2.4. Protocol States The model structure for the protocol states is as shown below: Liu, et al. Expires April 29, 2018 [Page 5] Internet-Draft YANG RIP October 2017 augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw rip +--ro <per instance operational states&Vendor-NVSE-Type: 14 (Host Configuration) Vendor-NVSE-Value: Format is shown below for each subtype. The Sub-Type field is an integer from 0 to 255. 3.1. Host Configuration Request Extension This format of the Host Configuration Request extension is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Selector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type: 0 Selector: 0 indicates all host configuration available to the Home Agent (HA) is requested by the Mobile Node. 3.2. Home Network Length Prefix Extension This format of the Home Network Prefix Length extension is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type: 1 Prefix Length: The number of bits in the home subnet prefix. Leung, et al. Informational [Page 5] RFC 4332 Host Config December 2005 3.3. DNS Server Extension This format of the DNS Server extension is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Primary DNS Server +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . | Secondary DNS Server +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type: 2 Primary DNS Server: The IP address of the primary DNS server. Secondary DNS Server: The IP address of the secondary DNS server. 3.4. DHCP Server Extension This format of the DHCP Server extension is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | DHCP Server +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type: 3 DHCP Server: The IP address of the DHCP server. Leung, et al. Informational [Page 6] RFC 4332 Host Config December 2005 3.5. DHCP Client ID Extension This format of the DHCP Client ID extension is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Client ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type: 4 Client ID: DHCP servers use this value to index their database of address bindings. This value is expected to be unique for all clients in an administrative domain. The size of field is between 2 and 255 octets. 3.6. Default Gateway Extension This format of the Default Gateway extension is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Default Gateway +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type: 5 Default Gateway: The IP address of the default gateway for the Mobile Node on the home network. Leung, et al. Informational [Page 7] RFC 4332 Host Config December 2005 3.7. DNS Suffix Extension This format of the DNS Suffix extension is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | DNS Suffix . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type: 6 DNS Suffix: The DNS suffix to be appended to the name of Mobile Node when completing its fully qualified domain name (FQDN). The size of field is between 1 and 246 octets. 3.8. Configuration URL Extension This format of the Configuration URL extension is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | URL String . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type: 7 URL String: The Mobile Node can retrieve configuration parameters via the URL. The URL is at most 246 bytes in length. Leung, et al. Informational [Page 8] RFC 4332 Host Config December 2005 4. Security Considerations The host configuration extensions follow the same rules for Mobile IP extensions in registration messages. See the Security Considerations section in RFC 3344. The Configuration URL extension may trigger the Mobile Node to download the configuration parameters from a server. The protection of the data transfer is outside the scope of this document. Possible options include encryption of data before transfer or using HTTPS. 5. Acknowledgements The authors would like to acknowledge Jayshree Bharatia, Kuntal Chowdhury, Avi Lior, and Lila Madour for their contributions to the work in progress titled "Mobile IPv4 Extension for Configuration Options Exchange". 6. Informative References [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ Response Extensions", RFC 3012, November 2000. [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/ Organization-Specific Extensions", RFC 3115, April 2001. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. Leung, et al. Informational [Page 9] RFC 4332 Host Config December 2005 Authors' Addresses Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-526-5030 EMail: kleung@cisco.com Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-853-9580 EMail: alpesh@cisco.com George Tsirtsis Flarion Technologies Bedminster One 135 Route 202/206 South Bedminster, NJ 07921 US Phone: +1 908-947-7059 EMail: g.tsirtsis@flarion.com Espen Klovning Birdstep Technology ASA Bryggegata 7 Oslo, 0250 Norway Phone: +47 95 20 26 29 EMail: espen@birdstep.com Leung, et al. Informational [Page 10] RFC 4332 Host Config December 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Leung, et al. Informational [Page 11]