Skip to main content

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]