Network Working Group F. Templin Internet-Draft Boeing Phantom Works Intended status: Informational August 24, 2006 Expires: February 25, 2007 Observations on "Link" in MANET/Autoconf and Other Contexts draft-templin-manet-autoconf-link-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Mobile Ad-hoc Networks (MANETs) comprise MANET routers, and connect to other networks via one or more MANET border routers. MANET routers communicate over semi-broadcast links which present interesting considerations for the classical IP model that are subject matter for this document. In particular, the term "link" requires careful examination in MANET/Autoconf and other contexts. Templin Expires February 25, 2007 [Page 1] Internet-Draft Observations on "Link" August 2006 1. Introduction Mobile Ad-hoc Networks (MANETs) comprise MANET Routers (MRs) that participate in a routing protocol over semi-broadcast links such that intra-MANET packet forwarding may require multiple hops. MANETs attach to other networks via zero or more MANET Border Routers (MBRs), and MRs may be multiple forwarding hops away from their nearest MBR. The Internet Protocol (IP) operates with minimal/no enhancement over most link types, but semi-broadcast links can blur the distinction of traditionally acknowledged link boundaries due to interactions between network sublayers that are not widely discussed in modern literature. This document examines the term "link" and its meaning within different network sublayer viewpoints in MANET/ Autoconf and other contexts. 2. Terminology The terminology in the references apply; the following terms are defined within the scope of this document: semi-broadcast any link over which a MANET router's transmission coverage may be restricted and/or time-varying due to range limitations, terrain features, signal intermittence, etc. Links used in ad-hoc wireless networks are the classic example, but the common link types listed in ([RFC2461], Section 2.2) are also covered under this definition. Mobile Ad-hoc Network (MANET) a connected network region (i.e., a "site") comprising MANET routers that maintain a routing structure among themselves in a relatively arbitrary fashion over semi-broadcast links. Further information on the characteristics of MANETs can be found in [RFC2501]. MANET Interface a MANET router's attachment to a semi-broadcast link via a module that implements network sublayers below IP. The MANET interface preserves the architectural semantics of IP. MANET Router (MR) a node that participates in a routing protocol over one or more MANET interface(s) and has zero or more interfaces attached to downstream links. Templin Expires February 25, 2007 [Page 2] Internet-Draft Observations on "Link" August 2006 MANET Border Router (MBR) an MR that is a site border router and connects the MANET to other networks. link-scoped service a service that is accessed within the scope of the local link, i.e., within a single IP hop. Examples are IPv6 Neighbor Discovery, IPv4 Router Discovery, DHCP for IPv4, and client-side aspects of DHCP for IPv6. 3. Observations on "link" in MANET/Autoconf and Other Contexts 3.1. Classical Definition for "Link" The term "link" is (re)defined in numerous IETF documents, with perhaps the most widely-cited examples appearing in ([RFC1256][RFC2461][RFC3753]) where the definitions for "link" are mutually compatible. The balance of this document assumes the RFC2461 version as representing a classical definition for "link": link a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks as well as internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. where it is also understood that links are bounded by routers that decrement the IP Hop Limit/TTL. In addition, ([TANENBAUM2], Section 1.2) and ([TANENBAUM4], Section 1.2.3) provide detailed discussion of the term "subnet" which clearly shows that the author intended the term in a manner that matches the IETF classical definition for "link". ([TANENBAUM4], Section 5.6.2) gives a second definition for "subnet" (not present in [TANENBAUM2]) that more closely matches its use in the current IETF literature, but the balance of this document cites [TANENBAUM2] and substitutes the term "link" where the author uses the term "subnet". 3.2. Sublayers of Layer 3 Quoting from ([TANENBAUM2], pp. 321-324), the OSI networking model included a conceptual 3-sublayer decomposition of Layer 3 as follows: Templin Expires February 25, 2007 [Page 3] Internet-Draft Observations on "Link" August 2006 internet sublayer (Layer 3c) The principal task of the internet sublayer is end-to-end routing. When a packet arrives at a relay, it works its way up to the internet sublayer, which examines it and decides whether to forward it, and if so, using which subnet (link) (a multilateral relay may have several subnets (links) to choose from). subnet (link) enhancement sublayer (Layer 3b) The subnet (link) enhancement sublayer is designed to harmonize subnets (links) that offer different services. subnet (link) access sublayer (Layer 3a) The purpose of the subnet (link) access layer is to handle the network layer protocol for the specific subnet (link) being used. It generates and receives data and control packets and performs the ordinary network layer functions. The software is designed to interface to the real subnet (link) available. Applying this 3-sublayer decomposition to the modern architecture, the IP protocol (versions 4 and 6) clearly occurs at Layer 3c. Layer 3b is NULL for many common link types such as multicast and point-to- point, but special Layer 3a/b support may be required for other link types such as ATM. (For MANETs, such Layer 3a/b support could be said to occur at the MANET interface level from the viewpoint of IP). The ARP protocol as well as the ARP cache and IPv6 neighbor cache occur at Layer 3a, but it is important to note that the IPv4 Router Discovery [RFC1256] and IPv6 Neighbor Discovery [RFC2461] protocols occur at Layer 3c since they are integral components of the IP protocol. The IP Forwarding Information Base (FIB) is managed by entities across all three network sublayers. 3.3. Sublayer Views of "link" MANETs operate over semi-broadcast links, but a MR's view of the link depends on the particular sublayer in question. o At Layer 3c, the MR's IP stack expects to see a fully-connected link, i.e., one over which link-scoped transmissions can reach all other MRs attached to the link in a single IP hop. Each link may span a single access medium or multiple access media, but it is the responsibility of lower (sub)layers to represent a fully- connected link view to IP. This link view is covered under the classical definition for link. o At Layer 3b, a MR's link view consists of all nodes within transmission range over one or more access media at a specific point in time, and different MRs may have different Layer 3b link Templin Expires February 25, 2007 [Page 4] Internet-Draft Observations on "Link" August 2006 views that may vary over time. This link view is also covered under the classical definition for link. o At Layer 3a, a MR's link view consists of the set of pairwise relationships established between itself and neighbors, i.e., the Layer 3a link view is a set of point-to-point virtual links that correspond to the L3-L2 address mappings in the ARP and/or IPv6 neighbor caches. (If a MANET interface attaches to multiple access media, it can be said that it has multiple Layer 3a link views that may/may not be merged into a single link view at Layer 3b.) Again, this link view is covered under the classical definition for link. As can be seen from the above, the Layer 3c link view is a fully- connected overlay on top of (potentially) multiple Layer 3b link views which are overlays on top of (potentially) multiple Layer 3a link views. 3.4. MANET Layering Alternatives MRs engage in a routing protocol to enable multihop forwarding, and MANETs are bordered by zero or more MBRs that define the MANET (i.e., site) boundaries. Depending on the layering approach, the MANET may appear as a single link or multiple links joined together by MRs, e.g.: o When MRs are configured to perform route calculations and packet forwarding at Layer 2 (and a Layer 2 flooding mechanism is also used), the routing protocol is essentially performing Layer 2 bridging, and each link is restricted to spanning similar access media because media with dissimilar MTUs and Layer 2 address formats cannot be bridged. In this approach, the Layer 3a link view is initially NULL but may be populated with point-to-point virtual links on-demand via either the ARP or IPv6 Neighbor Discovery processes. Layer 3b may be NULL, and the Layer 3c view of the MANET is the same as for one or more (bridged) campus LANs joined together by routers. o When MRs are configured for Layer 2 operation as above but also distribute Layer 3 information, the routing protocol can be said to occur at Layer 3a and the Layer 3a link view can be pre- populated with point-to-point virtual links independently of the ARP or IPv6 Neighbor Discovery mechanisms. Again, Layer 3b may be NULL and the Layer 3c view of the MANET is the same as for the Layer 2 case. o When MRs are configured to perform route calculations and packet forwarding at Layer 3 (and a Layer 3 flooding mechanism is also Templin Expires February 25, 2007 [Page 5] Internet-Draft Observations on "Link" August 2006 used), the routing protocol can be said to occur at Layer 3b. In this approach, MRs can join dissimilar access media together to represent the entire MANET as a single link to Layer 3c, since Layer 3 mechanisms such as IP fragmentation and Path MTU Discovery are available. Since multihop forwarding occurs at the IP layer, however, the IP Hop Limit/TTL would be decremented for intra-MANET packet forwarding which would break the semantics for IP link- scoped transmissions. These IP Hop Limit/TTL issues can be harmonized by Layer 3b link enhancement using IP-in-IP tunneling. 3.5. Layer 3b Link Enhancement When MRs are configured to operate at Layer 3b, a non-enhanced view of the link would be one that limits link-scope to transmission range (i.e., the Layer 3c link view would be identical to the Layer 3b link view). To provide Layer 3c with a fully-connected view of the MANET, Layer 3b can perform IP-in-IP tunneling using the combined mechanisms of 6over4 [RFC2529] and ISATAP [RFC4214] with extensions to support all variants of IP*/IP* tunneling instead of just IPv6/IPv4. A tunnel MTU link adaptation mechanism [I-D.templin-linkadapt] can also be used to provide an assured MTU in the presence of heterogeneous access media. This Layer 3b link enhancement function would be naturally implemented as an embedded function within a MANET interface module immediately below the IP stack such that link-scoped transmissions are forwarded over a tunnel device and non-link-scoped transmissions are forwarded either over the tunnel device or a native device if possible. In particular, the MANET interface module would maintain its own FIB (independent of IP's FIB) and use it to direct packets to the correct egress device. Using this Layer 3b enhancement, link-scoped services would work as- normal across the MANET even though the MR and the on-link neighbor that provides the service may be multiple Layer 3b hops apart, because tunneling presents IP with the view of a single Layer 3c hop. IPv6 Neighbor Discovery, IPv4 Router Discovery, DHCP for IPv4, client-side aspects of DHCP for IPv6, and all other link-scoped services would work as-normal across the MANET for this reason. Without this Layer 3b enhancement, link-scope would be limited to a MR's transmission range and as such all MRs would have to support service-specific relays/servers for link-scoped services, since the worst-case MANET topology is a linear string. An alternative would be to specify new site-scoped services, but many standard services in the Internet architecture are already specified as link-scoped and Templin Expires February 25, 2007 [Page 6] Internet-Draft Observations on "Link" August 2006 designed to work only within that scope. 4. Summary This document shows that the Internet architecture conforms to [TANENBAUM2]'s 3-sublayer decomposition for the OSI network layer even though this is not widely discussed in modern literature. It also shows that there is nothing wrong with the classical definition for "link", but rather that the definition needs to be understood within the context of individual network sublayers. This document is written from a MANET/Autoconf perspective, and examines MANET layering alternatives with respect to the OSI network sublayers. It shows that standard link-scoped services are supported as-normal on a MANET-wide basis when Layer 3b link enhancement (i.e., tunneling) is used. The document also raises the question of whether site-scoped services could be used instead of link-scoped services in order to avoid tunneling, and as such whether there is cause to re- examine those aspects of the Internet architecture. A further derivation that applies to all link types is that unicast transmissions are ultimately carried over point-to-point links at some level; the question becomes one of at which level the point-to- point links are "bound": o Hardwired point-to-point links are bound at Layer 1 and hence privacy issues are restricted to physical security. o Point-to-point links over certain wireless media (e.g., cellular) are bound at Layer 2 and hence privacy issues are restricted to the ability of a sophisticated eavesdropper to intercept wireless transmissions and decrypt them - but the media is still a shared media from the Layer 1 perspective. o Multicast links are actually collections of virtual point-to-point links that are bound at Layer 3a. Simple eavesdropping may be available to some/all nodes on the link, hence privacy issues are restricted to the ability of the eavesdropper to decrypt intercepted transmissions - but the media is only a shared media from the Layer 2 perspective and is really just a collection of virtual point-to-point links above. Finally, multicast transmissions over point-to-point links that are bound at Layer 2 or below are carried as point-to-point over Layer 2 and hence are received by only one neighbor on the link. Multicast transmissions over media with point-to-point links that are bound above Layer 2 are carried as point-to-multipoint over Layer 2 and Templin Expires February 25, 2007 [Page 7] Internet-Draft Observations on "Link" August 2006 hence may be received by many neighbors on the link. The former approach assures link quality and confidentiality by restricting the link to a node and its serving router, while the latter approach assures link quality and confidentiality by trusting neighbors on the link to behave in a neighborly fashion. The choice of which model to prefer is entirely up to the individual. 5. IANA Considerations There are no IANA considerations associated with this document. 6. Security Considerations Section 4 touches briefly on confidentiality, but no other aspects of security are discussed. 7. Acknowledgements The following individuals provided valuable input: Ian Chakeres, Thomas Henderson, Steven Russert, Seung Yi. David Young suggested the term "semi-broadcast" on the IETF MANET mailing list. Phil Roberts encouraged the effort. 8. Informative References [I-D.templin-linkadapt] Templin, F., "Link Adaptation for IPv6-in-IPv4 Tunnels", draft-templin-linkadapt-02 (work in progress), March 2006. [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. Templin Expires February 25, 2007 [Page 8] Internet-Draft Observations on "Link" August 2006 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005. [TANENBAUM2] Tanenbaum, A., "Computer Networks - Second Edition, Prentice Hall, Englewood Cliffs, NJ.", , 1989. [TANENBAUM4] Tanenbaum, A., "Computer Networks - Fourth Edition, Prentice Hall, Uper Saddle River, NJ.", , 2003. Author's Address Fred L. Templin Boeing Phantom Works P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA Email: fred.l.templin@boeing.com Templin Expires February 25, 2007 [Page 9] Internet-Draft Observations on "Link" August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Templin Expires February 25, 2007 [Page 10]