idnits 2.17.1 draft-ietf-dna-goals-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 430. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 446), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 230: '...tial solicitation, it SHOULD delay the...' RFC 2119 keyword, line 233: '...ponse to a Router Solicitation MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 13, 2004) is 7133 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 355, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 373, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 377, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '1') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '2') (Obsoleted by RFC 4862) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '3') -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '5') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '7') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2411 (ref. '8') (Obsoleted by RFC 6071) == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-00 == Outdated reference: A later version (-18) exists of draft-ietf-dhc-dna-ipv4-08 Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA WG JinHyeock Choi 3 Internet-Draft Samsung AIT 4 Expires: April 13, 2005 Greg Daley 5 CTIE Monash University 6 October 13, 2004 8 Detecting Network Attachment in IPv6 Goals 9 draft-ietf-dna-goals-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 13, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 At the time a host establishes a new link-layer connection, it may or 43 may not have a valid IP configuration for Internet connectivity. The 44 host may check for link change, i.e. determine whether a link change 45 has occurred, and then, based on the result, it can automatically 46 decide whether its IP configuration is still valid or not. During 47 link identity detection, the host may also collect necessary 48 information to initiate a new IP configuration for the case that the 49 IP subnet has changed. In this memo, this procedure is called 50 Detecting Network Attachment (DNA). DNA schemes should be precise, 51 sufficiently fast, secure and of limited signaling. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Problems in Detecting Network Attachment . . . . . . . . . . . 5 57 2.1 Wireless link properties . . . . . . . . . . . . . . . . . 5 58 2.2 Link identity detection with a single RA . . . . . . . . . 5 59 2.3 Delays . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Goals for Detecting Network Attachment . . . . . . . . . . . . 8 61 3.1 Goals list . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 67 7.2 Informative References . . . . . . . . . . . . . . . . . . . 13 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . . 15 71 1. Introduction 73 When a host has established a new link-layer connection, it can send 74 and receive some IPv6 packets at the link, particularly those used 75 for configuration. On the other hand, the host has full Internet 76 connectivity only when it is able to exchange packets with arbitrary 77 destinations. 79 When a link-layer connection is established or re-established, the 80 host may not know whether its existing IP configuration is still 81 valid for Internet connectivity. A subnet change might have occurred 82 when the host changed its attachment point. 84 In practice, the host doesn't know which of its addresses are valid 85 on the newly attached link. The host knows neither if its existing 86 default router is on this link, nor whether its neighbor cache 87 entries are valid. Correct configuration of each of these components 88 are necessary in order to send packets on and off the link. 90 To examine the status of the existing configuration, a host may check 91 whether a 'link change' has occurred. The term 'link' used in this 92 document is as defined in RFC 2461 [1]. The notion 'link' is not 93 identical with the notion 'subnet' as defined in RFC 3753 [3]. For 94 example, there may be more than one subnets on a link and a host 95 connected to a link may be part of one or more of the subnets on the 96 link. 98 Today, a link change necessitates an IP configuration change. 99 Whenever a host detects that it has remained at the same link, it can 100 usually assume its IP configuration is still valid. Otherwise, the 101 existing one is no longer valid and a new configuration must be 102 acquired. Hence, to examine the validity of an IP configuration, all 103 that is required is that the host checks for link change. 105 In the process of checking for link change, a host may collect some 106 of the necessary information for a new IP configuration, such as 107 on-link prefixes. So, when an IP subnet change has occurred, the 108 host can immediately initiate the process of getting a new IP 109 configuration. This may reduce handoff delay and minimize signaling. 111 Rapid attachment detection is required for a device that changes 112 subnet while having on-going sessions. This may be the case if a 113 host is connected intermittently, is a mobile node, or has urgent 114 data to transmit upon attachment to a link. 116 The process by which a host collects the appropriate information and 117 detects the identity of its currently attached link to ascertains the 118 validity of its IP configuration, is called Detecting Network 119 Attachment (DNA). 121 DNA schemes are typically run per interface. When a host has 122 multiple interfaces, the host separately checks for link changes on 123 each interface. 125 It is important to note that DNA process does not include the actual 126 IP configuration procedure. For example, with respect to DHCP, the 127 DNA process may determine that the host needs to get some 128 configuration information from a DHCP server. However, the process 129 of actually retrieving the information from a DHCP server falls 130 beyond the scope of DNA. 132 This draft considers the DNA procedure only from the IPv6 point of 133 view, unless otherwise explicitly mentioned. Hence, the term "IP" is 134 to be understood to denote IPv6, by default. For the IPv4 case, 135 refer [10]. 137 2. Problems in Detecting Network Attachment 139 There are a number of issues that make DNA complicated. First, 140 wireless connectivity is not as clear-cut as wired one. Second, it's 141 difficult for a single RA message to indicate a link change. Third, 142 Router Discovery may take too long and result in service disruption. 144 2.1 Wireless link properties 146 Unlike wired environments, what constitutes a wireless link is 147 variable both in time and space. Wireless links do not have clear 148 boundaries. This may be illustrated by the fact that a host may be 149 within the coverage area of multiple (802.11) access points at the 150 same time. Moreover, connectivity on a wireless link can be very 151 volatile, which may make link identity detection hard. For example, 152 it takes time for a host to check for link change. If the host 153 ping-pongs between two links and doesn't stay long enough at a given 154 link, it can't complete the DNA procedure. 156 2.2 Link identity detection with a single RA 158 Usually a host gets the information necessary for IP configuration 159 from RA messages. Based on the current definition [1], it's 160 difficult for a host to check for link change upon a single RA 161 reception. 163 To detect link identity, a host may compare the information in an RA, 164 such as router address or prefixes, with the locally stored 165 information. 167 The host may use received router addresses to check for link change. 168 The router address in the source address field of an RA is of 169 link-local scope, however, so its uniqueness is not guaranteed 170 outside of a link. If it happens that two different router 171 interfaces on different links have the same link-local address, the 172 host can't detect that it has moved from one link to another by 173 checking the router address in RA messages. 175 The set of all the global prefixes assigned to a link can represent 176 link identity. The host may compare the prefixes in an incoming RA 177 with the currently stored ones. An unsolicited RA message, however, 178 can omit some prefixes for convenience [1] and it's not easy for a 179 host to attain and retain all the prefixes on a link with certainty. 180 Hence, neither the absence of a previously known prefix nor the 181 presence of a previously unknown prefix in the RA guarantees that a 182 link change has occurred. 184 2.3 Delays 186 The following issues cause DNA delay that may result in communication 187 disruption. 189 1) Delay for receiving a hint 191 Hint is an indication that a link change might have occurred. This 192 hint itself doesn't confirm a link change, but initiates appropriate 193 DNA procedures to detect the identity of the currently attached link. 195 Hints come in various forms, and differ in how they indicate a 196 possible link change. They can be link-layer event notifications 197 [9], the lack of RA from the default router, or the receipt of a new 198 RA. The time taken to receive a hint also varies. 200 As soon as a new link-layer connection has been made, the link-layer 201 may send a link up notification to the IP layer. A host may 202 interpret the new link-layer connection as a hint for a possible link 203 change. With link-layer support, a host can receive such a hint 204 almost instantly. 206 Mobile IPv6 [5] defines the use of RA Interval Timer expiry for a 207 hint. A host keeps monitoring for periodic RAs and interprets the 208 lack of them as a hint. It may implement its own policy to determine 209 the number of missing RAs needed to interpret that as a hint. Hence, 210 the delay depends on the Router Advertisement interval. 212 Without schemes such as the ones above, a host must receive a new RA 213 from a new router to detect a possible link change. The detection 214 time then also depends on the Router advertisement frequency. 216 Periodic RA beaconing transmits packets within an interval varying 217 randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds. 218 Because a network attachment is unrelated to the advertisement time 219 on the new link, hosts are expected to arrive, on average, half way 220 through the interval. This is approximately 1.75 seconds with 221 Neighbor Discovery [1] advertisement rates. 223 2) Random delay execution for RS/ RA exchange 225 Router Solicitation and Router Advertisement messages are used for 226 Router Discovery. According to [1], it is sometimes necessary for a 227 host to wait a random amount of time before it may send an RS, and 228 for a router to wait before it may reply with an RA. 230 Before a host sends an initial solicitation, it SHOULD delay the 231 transmission for a random amount of time between 0 and 232 MAX_RTR_SOLICITATION_DELAY (1 second). Furthermore, any Router 233 Advertisement sent in response to a Router Solicitation MUST be 234 delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 235 seconds). 237 3. Goals for Detecting Network Attachment 239 The DNA working group has been chartered to define an improved scheme 240 for detecting IPv6 network attachment. In this section, we define 241 the goals that any such solutions should aim to fulfil. 243 DNA solutions should correctly determine whether a link change has 244 occurred. Additionally, they should be sufficiently fast so that 245 there would be no or at most minimal service disruption. They should 246 neither flood the link with related signaling nor introduce new 247 security holes. 249 When defining new solutions, it is necessary to investigate the usage 250 of available tools, NS/NA messages, RS/RA messages, link-layer event 251 notifications [9], and other features. This will allow precise 252 description of procedures for efficient DNA Schemes. 254 3.1 Goals list 256 G1 DNA schemes should detect the identity of the currently attached 257 link to ascertain the validity of the existing IP configuration. 258 They should recognize and determine whether a link change has 259 occurred and initiate the process of acquiring a new configuration 260 if necessary. 262 G2 When upper-layer protocol sessions are being supported, DNA 263 schemes should detect the identity of an attached link with 264 minimal latency lest there should be service disruption. 266 G3 In the case where a host has not changed a link, DNA schemes 267 should not falsely assume a link change and an IP configuration 268 change should not occur. 270 G4 DNA schemes should not cause undue signaling on a link. 272 G5 DNA schemes should make use of existing signaling mechanisms where 273 available. 275 G6 DNA schemes should make use of signaling within the link 276 (particularly link-local scope messages), since communication 277 off-link may not be achievable in the case of a link change. 279 G7 DNA schemes should be compatible with security schemes such as 280 Secure Neighbour Discovery [4]. 282 G8 DNA schemes should not introduce new security vulnerabilities. 283 The node supporting DNA schemes should not expose itself or others 284 on a link to additional man in the middle, identity revealing, or 285 denial of service attacks. 287 G9 The nodes, such as routers or hosts, supporting DNA schemes should 288 work appropriately with unmodified nodes, such as routers or 289 hosts, which do not support DNA schemes. 291 G10 Hosts, especially in wireless environments, may perceive routers 292 reachable on different links. DNA schemes should take into 293 consideration the case where a host is attached to more than one 294 link at the same time. 296 4. IANA Considerations 298 No new message formats or services are defined in this document. 300 5. Security Considerations 302 Because DNA schemes are based on Neighbor Discovery, its trust models 303 and threats are similar to the ones presented in RFC 3756 [6]. Nodes 304 connected over wireless interfaces may be particularly susceptible to 305 jamming, monitoring, and packet insertion attacks. 307 With unsecured DNA schemes, it is inadvisable for a host to adjust 308 its security based on which network it believes it is attached to. 309 For example, it would be inappropriate for a host to disable its 310 personal firewall based on the belief that it had connected to a home 311 network. 313 Even in the case where authoritative information (routing and prefix 314 state) are advertised, wireless network attackers may still prevent 315 soliciting nodes from receiving packets. This may cause unnecessary 316 IP configuration change in some devices. Such attacks may be used to 317 make a host preferentially select a particular configuration or 318 network access. 320 Devices receiving confirmations of reachability (for example from 321 upper-layer protocols) should be aware that unless these indications 322 are sufficiently authenticated, reachability may falsely be asserted 323 by an attacker. Similarly, such reachability tests, even if known to 324 originate from a trusted source, should be ignored for reachability 325 confirmation if the packets are not fresh, or have been replayed. 326 This may reduce the effective window for attackers replaying 327 otherwise authentic data. 329 It may be dangerous to receive link-change notifications from 330 link-layer and network-layer, if they are received from devices which 331 are insufficiently authenticated. In particular, notifications that 332 authentication has completed at the link-layer may not imply that a 333 security relationship is available at the network-layer. Additional 334 authentication may be required at the network layer to justify 335 modification of IP configuration. 337 6. Acknowledgment 339 Erik Nordmark has contributed significantly to work predating this 340 draft. Also Ed Remmell's comments on the inconsistency of RA 341 information were most illuminating. The authors wish to express our 342 appreciation to Pekka Nikander for valuable feedback. We gratefully 343 acknowledge the generous assistance we received from Shubhranshu 344 Singh for clarifying the structure of the arguments. Thanks to Brett 345 Pentland, Nick Moore, Youn-Hee Han, JaeHoon Kim, Alper Yegin, Jim 346 Bound and Jari Arkko for their contributions to this draft. 348 7. References 350 7.1 Normative References 352 [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 353 IP Version 6 (IPv6)", RFC 2461, December 1998. 355 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 356 Autoconfiguration", RFC 2462, December 1998. 358 [3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 359 3753, June 2004. 361 [4] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 362 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 363 (work in progress), July 2004. 365 7.2 Informative References 367 [5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 368 IPv6", RFC 3775, June 2004. 370 [6] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 371 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 373 [7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 374 Carney, "Dynamic Host Configuration Protocol for IPv6 375 (DHCPv6)", RFC 3315, July 2003. 377 [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document 378 Roadmap", RFC 2411, November 1998. 380 [9] Yegin, A., "Link-layer Event Notifications for Detecting 381 Network Attachments", draft-ietf-dna-link-information-00 (work 382 in progress), September 2004. 384 [10] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", 385 draft-ietf-dhc-dna-ipv4-08 (work in progress), July 2004. 387 Authors' Addresses 389 JinHyeock Choi 390 Samsung AIT 391 Communication & N/W Lab 392 P.O.Box 111 Suwon 440-600 393 KOREA 395 Phone: +82 31 280 9233 396 EMail: jinchoe@samsung.com 398 Greg Daley 399 CTIE Monash University 400 Centre for Telecommunications and Information Engineering 401 Monash University 402 Clayton 3800 Victoria 403 Australia 405 Phone: +61 3 9905 4655 406 EMail: greg.daley@eng.monash.edu.au 408 Intellectual Property Statement 410 The IETF takes no position regarding the validity or scope of any 411 Intellectual Property Rights or other rights that might be claimed to 412 pertain to the implementation or use of the technology described in 413 this document or the extent to which any license under such rights 414 might or might not be available; nor does it represent that it has 415 made any independent effort to identify any such rights. Information 416 on the procedures with respect to rights in RFC documents can be 417 found in BCP 78 and BCP 79. 419 Copies of IPR disclosures made to the IETF Secretariat and any 420 assurances of licenses to be made available, or the result of an 421 attempt made to obtain a general license or permission for the use of 422 such proprietary rights by implementers or users of this 423 specification can be obtained from the IETF on-line IPR repository at 424 http://www.ietf.org/ipr. 426 The IETF invites any interested party to bring to its attention any 427 copyrights, patents or patent applications, or other proprietary 428 rights that may cover technology that may be required to implement 429 this standard. Please address the information to the IETF at 430 ietf-ipr@ietf.org. 432 Disclaimer of Validity 434 This document and the information contained herein are provided on an 435 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 436 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 437 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 438 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 439 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 440 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 442 Copyright Statement 444 Copyright (C) The Internet Society (2004). This document is subject 445 to the rights, licenses and restrictions contained in BCP 78, and 446 except as set forth therein, the authors retain all their rights. 448 Acknowledgment 450 Funding for the RFC Editor function is currently provided by the 451 Internet Society.