Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

INFORMATIONAL
Internet Engineering Task Force (IETF)                  E. Baccelli, Ed.Request for Comments: 5889                                         INRIACategory: Informational                                 M. Townsley, Ed.ISSN: 2070-1721                                            Cisco Systems                                                          September 2010IP Addressing Model in Ad Hoc NetworksAbstract   This document describes a model for configuring IP addresses and   subnet prefixes on the interfaces of routers which connect to links   with undetermined connectivity properties.Status of This Memo   This document is not an Internet Standards Track specification; it is   published for informational purposes.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Not all documents   approved by the IESG are a candidate for any level of Internet   Standard; seeSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc5889.Copyright Notice   Copyright (c) 2010 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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.Baccelli & Townsley           Informational                     [Page 1]

RFC 5889                  Ad Hoc IP Addressing            September 2010Table of Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .32.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .43.  Applicability Statement . . . . . . . . . . . . . . . . . . . .44.  IP Subnet Prefix Configuration  . . . . . . . . . . . . . . . .45.  IP Address Configuration  . . . . . . . . . . . . . . . . . . .46.  Addressing Model  . . . . . . . . . . . . . . . . . . . . . . .56.1.  IPv6 Model  . . . . . . . . . . . . . . . . . . . . . . . .56.2.  IPv4 Model  . . . . . . . . . . . . . . . . . . . . . . . .67.  Security Considerations . . . . . . . . . . . . . . . . . . . .68.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .78.1.  Normative References  . . . . . . . . . . . . . . . . . . .78.2.  Informative References  . . . . . . . . . . . . . . . . . .7Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . . .71.  Introduction   The appropriate configuration of IP addresses and subnet masks for   router network interfaces is generally a prerequisite to the correct   functioning of routing protocols.  Consideration of various items,   including underlying link capabilities and connectivity, geographical   topology, available address blocks, assumed traffic patterns etc.,   are used when determining the appropriate network topology and the   associated IP interface configuration.   When the capabilities and connectivity of the links that connect   routers are well-known and stable, logical network topology design   and corresponding IP interface configuration are straightforward.   Absent any assumption about link-level connectivity, however, there   is no canonical method for determining a given IP interface   configuration.   Link-level connectivity is generally qualified as undetermined when   it is unplanned and/or time-varying in character.  Ad hoc networks   are typical examples of networks with undetermined link-level   connectivity.  Routing protocols for ad hoc networks are purposely   designed to detect and maintain paths across the network, even when   faced with links with undetermined connectivity, assuming that   routers' interfaces are configured with IP addresses.  This document   thus proposes a model for configuration of IP addresses and subnet   prefixes on router interfaces to links with undetermined connectivity   properties, to allow routing protocols and data packet forwarding to   function.   Note that routers may ultimately need additional IP prefixes for the   diverse applications that could run directly on the routers   themselves, or for assignment to attached hosts or networks.  ForBaccelli & Townsley           Informational                     [Page 2]

RFC 5889                  Ad Hoc IP Addressing            September 2010   IPv6, these addresses may be global [RFC3587], Unique-Local [RFC4193]   or Link-Local [RFC4291].  For IPv4, the addresses may be global   (i.e., public) or private [RFC1918].  In general, global scope is   desired over local scope, though it is understood that this may not   always be achievable via automatic configuration mechanisms.  In this   document however, automatic configuration of the prefixes used for   general applications is considered as a problem that is separable   from that of automatic configuration of addresses and prefixes   necessary for routing protocols to function.  This document thus   focuses on the latter: the type of IP address and subnet mask   configuration necessary for routing protocols and data packet   forwarding to function.2.  Terminology   This document uses the vocabulary and the concepts defined in   [RFC1918] and [RFC4632] for IPv4, as well as [RFC4291] for IPv6.3.  Applicability Statement   This model gives guidance about the configuration of IP addresses and   the IP subnet prefixes on a router's IP interfaces, which connect to   links with undetermined connectivity properties.   When more specific assumptions can be made regarding the connectivity   between interfaces or the (persistent) reachability of some   addresses, these should be considered when configuring subnet   prefixes.4.  IP Subnet Prefix Configuration   If the link to which an interface connects enables no assumptions of   connectivity to other interfaces, the only addresses that can be   assumed "on link", are the address(es) of that interface itself.   Note that while link-local addresses are assumed to be "on link", the   utility of link-local addresses is limited as described inSection 6.   Thus, subnet prefix configuration on such interfaces must not make   any promises in terms of direct (one hop) IP connectivity to IP   addresses other than that of the interface itself.  This suggests the   following principle:   o  no on-link subnet prefix should be configured on such an      interface.   Note that if layer 2 communication is enabled between a pair of   interfaces, IP packet exchange is also enabled, even if IP subnet   configuration is absent or different on each of these interfaces.Baccelli & Townsley           Informational                     [Page 3]

RFC 5889                  Ad Hoc IP Addressing            September 2010   Also note that if, on the contrary, assumptions can be made regarding   the connectivity between interfaces, or regarding the persistent   reachability of some addresses, these should be considered when   configuring IP subnet prefixes, and the corresponding interface(s)   may in such case be configured with an on-link subnet prefix.5.  IP Address Configuration   Routing protocols running on a router may exhibit different   requirements for uniqueness of interface addresses; some have no such   requirements, others have requirements ranging from local uniqueness   only, to uniqueness within, at least, the routing domain (as defined   in [RFC1136]).   Routing protocols that do not require unique IP addresses within the   routing domain utilize a separate unique identifier within the   routing protocol itself; such identifiers could be based on factory   assignment or configuration.   Nevertheless, configuring an IP address that is unique within the   routing domain satisfies the less stringent uniqueness requirements,   while also enabling protocols that have the most stringent   requirements of uniqueness within the routing domain.  As a result,   the following principle allows for IP autoconfiguration to apply to   the widest array of routing protocols:   o  an IP address assigned to an interface that connects to a link      with undetermined connectivity properties should be unique, at      least within the routing domain.6.  Addressing Model   Sections4 and5 describe principles for IP address and subnet prefix   configuration on an interface of a router, when that interface   connects to a link with undetermined connectivity properties.  The   following describes guidelines that follow from these principles,   respectively for IPv6 and IPv4.   Note that the guidelines provided in this document slightly differ   for IPv6 and IPv4, as IPv6 offers possibilities that IPv4 does not   (i.e., the possibility to simply not configure any on-link subnet   prefix on an IPv6 interface), which provide a "cleaner" model.Baccelli & Townsley           Informational                     [Page 4]

RFC 5889                  Ad Hoc IP Addressing            September 20106.1.  IPv6 Model   For IPv6, the principles described in Sections4 and5 suggest the   following rules:   o  An IP address configured on this interface should be unique, at      least within the routing domain, and   o  No on-link subnet prefix is configured on this interface.   Note that while an IPv6 link-local address is assigned to each   interface as per [RFC4291], in general link-local addresses are of   limited utility on links with undetermined connectivity, as   connectivity to neighbors may be constantly changing.  The known   limitations are:   o  In general, there is no mechanism to ensure that IPv6 link-local      addresses are unique across multiple links, though link-local      addresses using an IID that are of the modified EUI-64 form should      be globally unique.   o  Routers cannot forward any packets with link-local source or      destination addresses to other links (as per [RFC4291]), while      most of the time, routers need to be able to forward packets to/      from different links.   Therefore, autoconfiguration solutions should be encouraged to   primarily focus on configuring IP addresses that are not IPv6 link-   local.6.2.  IPv4 Model   For IPv4, the principles described in Sections4 and5 suggest rules   similar to those mentioned for IPv6 inSection 6.1, that are:   o  An IP address configured on this interface should be unique, at      least within the routing domain, and   o  Any subnet prefix configured on this interface should be 32 bits      long.   Note that the use of IPv4 link-local addresses [RFC3927] in this   context should be discouraged for most applications, as the   limitations outlined inSection 6.1 for IPv6 link-local addresses   also concern IPv4 link-local addresses.  These limitations are   further exacerbated by the smaller pool of IPv4 link-local addresses   to choose from and thus increased reliance on Duplicate Address   Detection (DAD).Baccelli & Townsley           Informational                     [Page 5]

RFC 5889                  Ad Hoc IP Addressing            September 20107.  Security Considerations   This document focuses on the IP address and subnet mask configuration   necessary for routing protocols and data packet forwarding to   function.  [RFC4593] describes generic threats to routing protocols,   whose applicability is not altered by the presence of interfaces with   undetermined connectivity properties.  As such, the addressing model   described in this document does not introduce new security threats.   However, the possible lack of pre-established infrastructure or   authority, as enabled by the use of interfaces with undetermined   connectivity properties, may render some of the attacks described in   [RFC4593] easier to undertake.  In particular, detection of   malevolent misconfiguration may be more difficult to detect and to   locate.8.  References8.1.  Normative References   [RFC1136]  Hares, S. and D. Katz, "Administrative Domains and Routing              Domains: A model for routing in the Internet",RFC 1136,              December 1989.   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing              Architecture",RFC 4291, February 2006.   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic              Configuration of IPv4 Link-Local Addresses",RFC 3927,              May 2005.   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,              and E. Lear, "Address Allocation for Private Internets",BCP 5,RFC 1918, February 1996.   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast              Addresses",RFC 4193, October 2005.   [RFC3587]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global              Unicast Address Format",RFC 3587, August 2003.   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing              (CIDR): The Internet Address Assignment and Aggregation              Plan",BCP 122,RFC 4632, August 2006.Baccelli & Townsley           Informational                     [Page 6]

RFC 5889                  Ad Hoc IP Addressing            September 20108.2.  Informative References   [RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to              Routing Protocols",RFC 4593, October 2006.Baccelli & Townsley           Informational                     [Page 7]

RFC 5889                  Ad Hoc IP Addressing            September 2010Appendix A.  Contributors   This document reflects discussions and contributions from several   individuals including (in alphabetical order): Teco Boot, Thomas   Clausen, Ulrich Herberg, Thomas Narten, Erik Nordmark, Charles   Perkins, Zach Shelby, and Dave Thaler.Authors' Addresses   Emmanuel Baccelli (editor)   INRIA   EMail: Emmanuel.Baccelli@inria.fr   URI:http://www.emmanuelbaccelli.org/   Mark Townsley (editor)   Cisco Systems   EMail: mark@townsley.netBaccelli & Townsley           Informational                     [Page 8]

[8]ページ先頭

©2009-2026 Movatter.jp