Autoconf T. Boot Internet-Draft Infinity Networks B.V. Intended status: Informational November 29, 2010 Expires: June 2, 2011 Support for hosts in MANETs draft-boot-autoconf-support4hosts-00 Abstract This document describes how hosts using IPv6 Stateless Address Autoconfiguration can be used in a MANET, without a need for any change, neither in functioning of Neighbor Discovery nor in MANET protocols. In addition, legacy hosts nor other parts of the network are faced any deviation on the IPv6 Addressing architecture. 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 June 2, 2011. Copyright Notice Copyright (c) 2010 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. Boot Expires June 2, 2011 [Page 1] Internet-Draft Support for hosts in MANETs November 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Address assignment to hosts . . . . . . . . . . . . . . . . . . 3 3. Reachability establishment . . . . . . . . . . . . . . . . . . 4 4. Mobility support . . . . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Boot Expires June 2, 2011 [Page 2] Internet-Draft Support for hosts in MANETs November 2010 1. Introduction In Mobile Ad hoc Networks [RFC2501], host support can be provided by using address assignment as described in this document. No central server is used and duplicate address detection can be fully supported. The IP Addressing Model in Ad Hoc Networks [RFC5889] argues that no on-link subnet prefix is configured on interfaces to links, where no assumptions of connectivity to other interfaces can be assumed. A straightforward method for this is advertising prefixes with Router Advertisements, where the Prefix Information Option L-bit is set to 0 [RFC4861]. For support for IPv6 Stateless Address Autoconfiguration, the A-bit is set to 1 [RFC4862]. The IPv6 6 Addressing Architecture [RFC4291] is used unmodified, with support for 64-bit Interface IDs. Interface IDs are generated by the hosts, using for example Modified EUI-64 [RFC4291], Cryptographically Generated Addresses [RFC3972] or Randomized Interface Identifiers [RFC4941]. Each MANET router has assigned one or more 64-bit prefixes. Procedures for prefix assignment are out of scope for this document. The prefixes are assigned MANET router exclusively, and reachability to addresses in these prefixes is handled by the MANET protocol. Hosts may send out packets to any reachable router, listed in the default router list. Hosts receive packets via the router that owns the prefix of the destination address of the received packet. Hosts may use multiple source addresses, which may be useful for for example multi-path transport protocols and other types of load balancing. Smooth handover can be supported if methods are implemented for detecting reachability problems with the router that provided the used prefix. Options are running a MANET protocol on the host or a mobility solution. 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 2. Address assignment to hosts Assume a topology as depicted below. Routers RtrA, RtrB and RtrC Boot Expires June 2, 2011 [Page 3] Internet-Draft Support for hosts in MANETs November 2010 send RAs. Host1 receives only advertisements from RtrA and RtrB. <~~~~~~~~~~~~~~~~+~~~~~~~~~~~> <~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~|~~~~~> <~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~> | <~|~~~~~~~~~~~+~~~~~~~~~~~|~~> | +--|--+ +--|--+ +--|--+ +--+--+ | RtrA|<===>|Host1|<===>| RtrB| | RtrC| +-----+ +-----+ +-----+ +-----+ Host1 may autoconfigure addresses with prefixes provided by RtrA and RtrB. It may perform duplicate address detection as described in IPv6 Stateless Address Autoconfiguration [RFC4862] or Optimistic DAD for IPv6 [RFC4429]. Standard duplicate address detection is limited to a single hop. In the topology depicted above, with a single host, this is sufficient. An address generated with the prefix from RtrA can only collide with RtrA itself. Same applies for address with prefix from RtrB. Also, self-generated addresses are likely unique by nature. But in the topology below, an undetected address collision may occur, although it is very unlikely. If a network manager requires guarantee on preventing duplicate addresses, (s)he can implement a DAD proxy function on the MANET routers [I-D.costa-6man-dad-proxy]. As the prefixes are allocated to the MANET routers exclusively, each router manages its own prefixes and no router to router signaling is needed. <~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~> <~~~|~~~~~~~~~~~~+~~~~~~~~~~~~~> <~~~~~~~~~~~~~+~~~~~~~~~~~~~|~~> | +--|--+ +--|--+ +--+--+ |Host1|<=====>| RtrA|<====>|Host2| +-----+ +-----+ +-----+ 3. Reachability establishment This addressing mechanism sticks to the current IPv6 model, where reachability between hosts on different links is arranged by routers. In a MANET, no assumptions can be made on connectivity between interfaces, which results in a recommendation for not using on-link prefixes [RFC5889]. Packet forwarding between hosts is always lead via one ore more MANET routers, unless link-local addresses are used and direct reachability between the hosts exists. However, usage of link-local addresses is not recommended, as non-link-local addresses provide better support for session continuity in mobile environments. Boot Expires June 2, 2011 [Page 4] Internet-Draft Support for hosts in MANETs November 2010 Host outbound traffic is straightforward, the host just picks a next- hop address from the Default Router List [RFC4861], as the Prefix List for the interface connected to the MANET is empty. Also, default router preferences and preferences for more specific routes can be used [RFC4191]. Hosts may use more sophisticated default router selection mechanisms, using the router via a low cost link, the router that provided the prefix used for generating the source address or capture topology information of the MANET protocol and select a shortest path to the destination. Host inbound traffic is also straightforward, the router that provided the prefix of a packet destination address also provides connectivity to that address. MANET routers inject the 64-bit (or shorter length) prefixes in the MANET protocol, all routers in the MANET calculate a route to that prefix, or can calculate in case of reactive MANET routing protocols. 4. Mobility support Reachability problems occur when hosts loose connectivity to routers that provided the used prefix for address generation. In the picture below, Host1 has configured an address with a prefix provided by RtrA. After movement of Host1, it lost its connection with RtrA and therefore Host1 is not reachable anymore via RtrA with a RtrA owned prefix. It can configure a new address from another nearby router, in this case RtrB. <~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~> <~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~> <~|~~~~~~~~~~~+~~~~~~~~~~~~~> | +--|--+ +--|--+ +--|--+ | RtrA|<===>|Host1| | RtrB| +-----+ +-----+ +-----+ Before movement, Host1 uses prefix from RtrA <~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~> <~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~> | <~~~~~~~~~~~+~~~~~~~~~~~|~~~> +--|--+ +--|--+ +--|--+ | RtrA| |Host1|<===>| RtrB| +-----+ +-----+ +-----+ After movement, Host1 switches to RtrB Boot Expires June 2, 2011 [Page 5] Internet-Draft Support for hosts in MANETs November 2010 MANET routing protocols are designed for solving these problems. A host may implement a MANET protocol and still keep the host characteristic by not forwarding packets. Using this approach, the generated addresses are advertised as 128-bit prefixes, this will ensure independent path calculation for each host that has configured an address from the same 64-bit prefix. This solution does not require renumbering, a host can use a single 128-bit prefix and keep being reachable when moving within the MANET. However, running the MANET protocols on a large number of hosts may have a burden on MANET scalability. Alternatively, hosts may generate new addresses when point of attachment to the MANET changes. Such renumbering breaks session continuity, so an additional mobility solution is needed. Mobility solutions are already available and can be used in the MANET scenario. Mobility Support in IPv6 (MIP6) [RFC3775], is designed for macro mobility. Mobile nodes use a Home Agent on the Internet and bind the care-of address(es) to a home address. Session continuity using the home address is arranged using a tunnel. Changes in care-of addresses are handled by updating the Home Agent - Mobile Node tunnel. The router that provides the prefix to the host may also perform the Home Agent role, this enables mobility support for isolated MANETs. Multihoming Shim Protocol for IPv6 (SHIM6), [RFC5533] provides basic mechanisms for multi-homed nodes with session continuity in case of communication failures with certain address pairs. It does not provide a mechanism to set up connections to a fixed IP address, used as identifier. Host Identity Protocol (HIP), [RFC4423] decouples endpoint identifiers with the network layer addresses used for packet forwarding. As such, HIP mobility support is straightforward. The Identificator-Locator Network Protocol ILNP [I-D.rja-ilnp-intro] updates the IPv6 addressing model, the 128-bit address is decomposed to a 64-bit locator and a 64-bit identifier. Locators may change anytime during a connection, without an effect on continuity. For connection setup to mobile nodes, mobility solutions use rendezvous points. On these servers, temporary IP addresses, used as locator, are coupled with the more stable IP addresses or domain names, used as identifier. The rendezvous points can be central servers, such as in the case of MIP6 Home Agent or DNS. In a MANET scenario, a more distributed approach can be used, using multicast service advertisements. Boot Expires June 2, 2011 [Page 6] Internet-Draft Support for hosts in MANETs November 2010 New mobility solutions for this hosts in ad hoc networks can be developed, if needed. 5. Acknowledgements Charles E. Parkins inspired me writing this proposal. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations No new security considerations arise. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. 8.2. Informative References [I-D.costa-6man-dad-proxy] Costa, F., Combes, J., Pougnard, X., and L. Hongyu, "Duplicate Address Detection Proxy", draft-costa-6man-dad-proxy-01 (work in progress), September 2010. [I-D.rja-ilnp-intro] Atkinson, R., "ILNP Concept of Operations", draft-rja-ilnp-intro-07 (work in progress), October 2010. Boot Expires June 2, 2011 [Page 7] Internet-Draft Support for hosts in MANETs November 2010 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad Hoc Networks", RFC 5889, September 2010. Author's Address Teco Boot Infinity Networks B.V. Email: teco@inf-net.nl Boot Expires June 2, 2011 [Page 8]