idnits 2.17.1 draft-perkins-autoconf-leghost-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 112: '...r, any such host MUST NOT accept MANET...' RFC 2119 keyword, line 114: '..., and additional allocations SHOULD be...' RFC 2119 keyword, line 120: '... the DHCP Reply MUST indicate a prefi...' RFC 2119 keyword, line 128: '... Solicitation MAY reply with an appr...' RFC 2119 keyword, line 130: '...smitting the Router Advertisement MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2010) is 4933 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET Autoconfiguration (Autoconf) C. Perkins 3 Internet-Draft Tellabs 4 Intended status: Informational T. Clausen 5 Expires: April 21, 2011 Ecole Polytechnique 6 October 18, 2010 8 MANET address autoconfiguration for legacy hosts 9 draft-perkins-autoconf-leghost-00 11 Abstract 13 This document describes methods by which a host running only DHCPv6 14 or Neighbor Discovery can obtain an address suitable for use in an ad 15 hoc network. 17 Status of This Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 21, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Details about DHCPv6 operation . . . . . . . . . . . . . . . . 4 53 3. Details about operation using Router Advertisement . . . . . . 4 54 4. Pictorial representation of address assignment . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 60 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 This document describes methods by which a host running only DHCPv6 65 [RFC3315] or Neighbor Discovery [RFC4862] can obtain an address 66 suitable for use in an ad hoc network. Let us call such a host to be 67 a "legacy host". It is agreed that legacy hosts are not routers and 68 do not forward packets. 70 The basic mechanism in our proposal is very simple. DHCP Request 71 packets and certain Router Solicitations are treated as requests to 72 obtain an address. Any router receiving such an address allocation 73 request initiates an Address Allocation protocol procedure 74 appropriate for the MANET (Mobile Ad Hoc Network) in which the router 75 resides. There are numerous examples of such address allocation 76 protocols [bernardos-survey]. In the case of routers running 77 proactive MANET protocols, simple inspection of the routing table may 78 suffice for the router to determine a unique address for the 79 requesting host. In the case of routers running only reactive 80 protocols, additional steps may be necessary. 82 Once the router has determined a unique address appropriate for the 83 requesting host, the router returns either DHCP Request or Router 84 Advertisement to the requesting host. In the case of the Router 85 Advertisement, the router presumes that the host will follow standard 86 practice. Namely, the host is presumed to make use of the prefix 87 provided by the router along with the host ID of the requesting host. 88 In many cases, the prefix supplied by the router will be such that no 89 link-local addresses are supported within the range of addresses 90 defined by the prefix, because the prefix will be /128. Such 91 allocations do not require additional steps by the host, and the /128 92 prefix supplied by the router will typically already contain the host 93 ID of the requesting host. 95 The cases of interest may be classified into two general categories, 96 depending upon whether or not the ad hoc network (i.e., the MANET) is 97 attached to the Internet. If the MANET is attached to the Internet, 98 then the MANET as a whole is addressable from the Internet according 99 to a routing prefix appropriate for the point of attachment of the 100 MANET. In this case, addresses assigned to the requesting host by 101 the allocating router will be selected from the routing prefix for 102 the MANET. 104 Otherwise, the address will be selected from a generalized MANET 105 prefix (MANET_LOCAL_PREFIX) which is not reachable from the Internet. 106 Any address assignments from the MANET_LOCAL_PREFIX are only valid 107 within the connected domain defined by the routers in the MANET 108 containing the legacy host and its neighboring router(s). The 109 operation of legacy hosts using such addresses allocated form the 110 MANET_LOCAL_PREFIX may be viewed as analogous to the operation of 111 hosts making use of IPv6 Unique Local Addresses (ULAs) [RFC4193]. In 112 particular, any such host MUST NOT accept MANET_LOCAL an address 113 allocation from two different neighboring routers; only one 114 allocation can be accepted, and additional allocations SHOULD be 115 refused. 117 2. Details about DHCPv6 operation 119 In the absence of any additional information, the router returning 120 the DHCP Reply MUST indicate a prefix length of /128 for the address 121 given in the DHCP Reply. 123 3. Details about operation using Router Advertisement 125 After a legacy host has configured a link-local address, it may (if 126 so configured) issue a Router Solicitation in order to obtain routing 127 information from a local router. Any router receiving this 128 Solicitation MAY reply with an appropriate Router Advertisement, 129 unicast to the soliciting host. In the absence of any additional 130 information, the router transmitting the Router Advertisement MUST 131 indicate a prefix length of /128 for the address given in the 132 Advertisement. 134 4. Pictorial representation of address assignment 136 A router and a legacy host 138 <~~~~~~~~~~~~~+~~~~~~~~~~~~~> 139 | <~~~~~~+~~~~~~> 140 +--|--+ +--|--+ 141 | RtrA|<=====>|Host | 142 +-----+ +-----+ 144 Figure 1: RtrA can send and receive packets from Host. 146 In the situation depicted in Figure 1, RtrA may receive a DHCP 147 Request, or a Router Solicitation, from the Host. In either case, if 148 RtrA is able to obtain an appropriate address for use by the Host, it 149 may provide that address to the Host by either of DHCP Reply or a 150 Router Advertisement. 152 5. Security Considerations 154 This document does not have any security considerations. 156 6. IANA Considerations 158 This document does not have any IANA actions. 160 7. References 162 7.1. Normative References 164 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., 165 Perkins, C., and M. Carney, "Dynamic Host 166 Configuration Protocol for IPv6 (DHCPv6)", 167 RFC 3315, July 2003. 169 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 170 Unicast Addresses", RFC 4193, October 2005. 172 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 173 Stateless Address Autoconfiguration", RFC 4862, 174 September 2007. 176 7.2. Informative References 178 [bernardos-survey] Bernardos, CJ., Calderon, M., and H. Moustafa, 179 "Survey of IP address autoconfiguration 180 mechanisms for MANETs", 181 draft-bernardos-manet-autoconf-survey-05.txt 182 (work in progress), 2010. 184 Appendix A. Acknowledgements 186 This document has benefitted from discussions with the following 187 people, in no particular order: Buu-Minh Ta. 189 Authors' Addresses 191 Charles E. Perkins 192 Tellabs 194 Phone: +1-408-435-0777 x337 195 EMail: charliep@wichorus.com 197 Thomas Clausen 198 Ecole Polytechnique 200 Phone: +33-671-116-128 201 EMail: thomas@thomasclausen.org