idnits 2.17.1 draft-ietf-dna-goals-04.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 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 425. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 441), 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 234: '...tial solicitation, it SHOULD delay the...' RFC 2119 keyword, line 239: '... Solicitation MUST be delayed by a ...' 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 (December 17, 2004) is 7069 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) ** Obsolete normative reference: RFC 2461 (ref. '1') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '2') -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == 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-09 Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: June 17, 2005 Greg Daley 5 CTIE Monash University 6 December 17, 2004 8 Goals of Detecting Network Attachment in IPv6 9 draft-ietf-dna-goals-04.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 June 17, 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 . . . . . . . . . . . . . . . . . . . . . . 13 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 on the link, including those used for 75 configuration. On the other hand, the host has Internet connectivity 76 only when it is able to exchange packets with off-link destinations. 78 When a link-layer connection is established or re-established, the 79 host may not know whether its existing IP configuration is still 80 valid for Internet connectivity. A subnet change might have occurred 81 when the host changed its attachment point. 83 In practice, the host doesn't know which of its addresses are valid 84 on the newly attached link. It also doesn't know whether its 85 existing default router is on this link nor if its neighbor cache 86 entries are valid. Correct configuration of each of these components 87 is necessary in order to send packets on and off the link. 89 To examine the status of the existing configuration, a host may check 90 whether a 'link change' has occurred. The term 'link' used in this 91 document is as defined in RFC 2461 [1]. The notion 'link' is not 92 identical with the notion 'subnet' as defined in RFC 3753 [2]. For 93 example, there may be more than one subnet on a link and a host 94 connected to a link may be part of one or more of the subnets on the 95 link. 97 Today, a link change necessitates an IP configuration change. 98 Whenever a host detects that it has remained at the same link, it can 99 usually assume its IP configuration is still valid. Otherwise, the 100 existing one is no longer valid and a new configuration must be 101 acquired. Hence, to examine the validity of an IP configuration, all 102 that is required is that the host checks for link change. 104 In the process of checking for link change, a host may collect some 105 of the necessary information for a new IP configuration, such as 106 on-link prefixes. So, when an IP subnet change has occurred, the 107 host can immediately initiate the process of getting a new IP 108 configuration. This may reduce handoff delay and minimize signaling. 110 Rapid attachment detection is required for a device that changes 111 subnet while having on-going sessions. This may be the case if a 112 host is connected intermittently, is a mobile node, or has urgent 113 data to transmit upon attachment to a link. 115 The process by which a host collects the appropriate information and 116 detects the identity of its currently attached link to ascertain the 117 validity of its IP configuration, is called Detecting Network 118 Attachment (DNA). 120 DNA schemes are typically run per interface. When a host has 121 multiple interfaces, the host separately checks for link changes on 122 each interface. 124 It is important to note that DNA process does not include the actual 125 IP configuration procedure. For example, with respect to DHCP, the 126 DNA process may determine that the host needs to get some 127 configuration information from a DHCP server. However, the process 128 of actually retrieving the information from a DHCP server falls 129 beyond the scope of DNA. 131 This draft considers the DNA procedure only from the IPv6 point of 132 view, unless otherwise explicitly mentioned. Hence, the term "IP" is 133 to be understood to denote IPv6, by default. For the IPv4 case, 134 refer to [7]. 136 2. Problems in Detecting Network Attachment 138 There are a number of issues that make DNA complicated. First, 139 wireless connectivity is not as clear-cut as wired connectivity. 140 Second, it's difficult for a single Router Advertisement message to 141 indicate a link change. Third, the current Router Discovery 142 specification specifies that routers wait a random delay of 0-.5 143 seconds prior to responding with a solicited RA. This delay can be 144 significant and may result in service disruption. 146 2.1 Wireless link properties 148 Unlike wired environments, what constitutes a wireless link is 149 variable both in time and space. Wireless links do not have clear 150 boundaries. This may be illustrated by the fact that a host may be 151 within the coverage area of multiple (802.11) access points at the 152 same time. Moreover, connectivity on a wireless link can be very 153 volatile, which may make link identity detection hard. For example, 154 it takes time for a host to check for link change. If the host 155 ping-pongs between two links and doesn't stay long enough at a given 156 link, it can't complete the DNA procedure. 158 2.2 Link identity detection with a single RA 160 Usually a host gets the information necessary for IP configuration 161 from RA messages. Based on the current definition [1], it's 162 difficult for a host to check for link change upon a single RA 163 reception. 165 To detect link identity, a host may compare the information in an RA, 166 such as router address or prefixes, with the locally stored 167 information. 169 The host may use received router addresses to check for link change. 170 The router address in the source address field of an RA is of 171 link-local scope, however, so its uniqueness is not guaranteed 172 outside of a link. If it happens that two different router 173 interfaces on different links have the same link-local address, the 174 host can't detect that it has moved from one link to another by 175 checking the router address in RA messages. 177 The set of all the global prefixes assigned to a link can represent 178 link identity. The host may compare the prefixes in an incoming RA 179 with the currently stored ones. An unsolicited RA message, however, 180 can omit some prefixes for convenience [1] and it's not easy for a 181 host to attain and retain all the prefixes on a link with certainty. 182 Hence, neither the absence of a previously known prefix nor the 183 presence of a previously unknown prefix in the RA guarantees that a 184 link change has occurred. 186 2.3 Delays 188 The following issues cause DNA delay that may result in communication 189 disruption. 191 1) Delay for receiving a hint 193 Hint is an indication that a link change might have occurred. This 194 hint itself doesn't confirm a link change, but initiates appropriate 195 DNA procedures to detect the identity of the currently attached link. 197 Hints come in various forms, and differ in how they indicate a 198 possible link change. They can be link-layer event notifications 199 [6], the lack of RA from the default router, or the receipt of a new 200 RA. The time taken to receive a hint also varies. 202 As soon as a new link-layer connection has been made, the link-layer 203 may send a link up notification to the IP layer. A host may 204 interpret the new link-layer connection as a hint for a possible link 205 change. With link-layer support, a host can receive such a hint 206 almost instantly. 208 Mobile IPv6 [4] defines the use of RA Interval Timer expiry for a 209 hint. A host keeps monitoring for periodic RAs and interprets the 210 lack of them as a hint. It may implement its own policy to determine 211 the number of missing RAs needed to interpret that as a hint. Hence, 212 the delay depends on the Router Advertisement interval. 214 Without schemes such as the ones above, a host must receive a new RA 215 from a new router to detect a possible link change. The detection 216 time then also depends on the Router Advertisement frequency. 218 Periodic RA beaconing transmits packets within an interval varying 219 randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds. 220 Because a network attachment is unrelated to the advertisement time 221 on the new link, hosts are expected to arrive, on average, half way 222 through the interval. This is approximately 1.75 seconds with 223 Neighbor Discovery [1] advertisement rates. 225 2) Random delay execution for RS/ RA exchange 227 Router Solicitation and Router Advertisement messages are used for 228 Router Discovery. According to [1], it is sometimes necessary for a 229 host to wait a random amount of time before it may send an RS, and 230 for a router to wait before it may reply with an RA. 232 According to RFC 2461 [1]: 234 - before a host sends an initial solicitation, it SHOULD delay the 235 transmission for a random amount of time between 0 and 236 MAX_RTR_SOLICITATION_DELAY (1 second). 238 - Furthermore, any Router Advertisement sent in response to a Router 239 Solicitation MUST be delayed by a random time between 0 and 240 MAX_RA_DELAY_TIME (0.5 seconds). 242 3. Goals for Detecting Network Attachment 244 The DNA working group has been chartered to define an improved scheme 245 for detecting IPv6 network attachment. In this section, we define 246 the goals that any such solution should aim to fulfil. 248 DNA solutions should correctly determine whether a link change has 249 occurred. Additionally, they should be sufficiently fast so that 250 there would be no or at most minimal service disruption. They should 251 neither flood the link with related signaling nor introduce new 252 security holes. 254 When defining new solutions, it is necessary to investigate the usage 255 of available tools, Neighbor Solicitation/Neighbor Advertisement 256 messages, RS/RA messages, link-layer event notifications [6], and 257 other features. This will allow precise description of procedures 258 for efficient DNA Schemes. 260 3.1 Goals list 262 G1 DNA schemes should detect the identity of the currently attached 263 link to ascertain the validity of the existing IP configuration. 264 They should recognize and determine whether a link change has 265 occurred and initiate the process of acquiring a new configuration 266 if necessary. 268 G2 DNA schemes should detect the identity of an attached link with 269 minimal latency lest there should be service disruption. 271 G3 In the case where a host has not changed a link, DNA schemes 272 should not falsely assume a link change and an IP configuration 273 change should not occur. 275 G4 DNA schemes should not cause undue signaling on a link. 277 G5 DNA schemes should make use of existing signaling mechanisms where 278 available. 280 G6 DNA schemes should make use of signaling within the link 281 (particularly link-local scope messages), since communication 282 off-link may not be achievable in the case of a link change. 284 G7 DNA schemes should be compatible with security schemes such as 285 Secure Neighbour Discovery [3]. 287 G8 DNA schemes should not introduce new security vulnerabilities. 288 The node supporting DNA schemes should not expose itself or others 289 on a link to additional man-in-the-middle, identity revealing, or 290 denial of service attacks. 292 G9 The nodes, such as routers or hosts, supporting DNA schemes should 293 work appropriately with unmodified nodes, such as routers or 294 hosts, which do not support DNA schemes. 296 G10 Hosts, especially in wireless environments, may perceive routers 297 reachable on different links. DNA schemes should take into 298 consideration the case where a host is attached to more than one 299 link at the same time. 301 4. IANA Considerations 303 No new message formats or services are defined in this document. 305 5. Security Considerations 307 DNA process is intimately related to Neighbor Discovery protocol [1] 308 and its trust model and threats have much in common with the ones 309 presented in RFC 3756 [5]. Nodes connected over wireless interfaces 310 may be particularly susceptible to jamming, monitoring, and packet 311 insertion attacks. 313 With unsecured DNA schemes, it is inadvisable for a host to adjust 314 its security based on which network it believes it is attached to. 315 For example, it would be inappropriate for a host to disable its 316 personal firewall based on the belief that it had connected to a home 317 network. 319 Even in the case where authoritative information (routing and prefix 320 state) are advertised, wireless network attackers may still prevent 321 soliciting nodes from receiving packets. This may cause unnecessary 322 IP configuration change in some devices. Such attacks may be used to 323 make a host preferentially select a particular configuration or 324 network access. 326 Devices receiving confirmations of reachability (for example from 327 upper-layer protocols) should be aware that unless these indications 328 are sufficiently authenticated, reachability may falsely be asserted 329 by an attacker. Similarly, such reachability tests, even if known to 330 originate from a trusted source, should be ignored for reachability 331 confirmation if the packets are not fresh, or have been replayed. 332 This may reduce the effective window for attackers replaying 333 otherwise authentic data. 335 It may be dangerous to receive link-change notifications from 336 link-layer and network-layer, if they are received from devices which 337 are insufficiently authenticated. In particular, notifications that 338 authentication has completed at the link-layer may not imply that a 339 security relationship is available at the network-layer. Additional 340 authentication may be required at the network layer to justify 341 modification of IP configuration. 343 6. Acknowledgment 345 Erik Nordmark has contributed significantly to work predating this 346 draft. Also Ed Remmell's comments on the inconsistency of RA 347 information were most illuminating. The authors wish to express our 348 appreciation to Pekka Nikander for valuable feedback. We gratefully 349 acknowledge the generous assistance we received from Shubhranshu 350 Singh for clarifying the structure of the arguments. Thanks to Brett 351 Pentland, Nick Moore, Youn-Hee Han, JaeHoon Kim, Alper Yegin, Jim 352 Bound and Jari Arkko for their contributions to this draft. 354 7. References 356 7.1 Normative References 358 [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 359 IP Version 6 (IPv6)", RFC 2461, December 1998. 361 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 362 3753, June 2004. 364 [3] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 365 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 366 (work in progress), July 2004. 368 7.2 Informative References 370 [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 371 IPv6", RFC 3775, June 2004. 373 [5] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 374 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 376 [6] Yegin, A., "Link-layer Event Notifications for Detecting Network 377 Attachments", draft-ietf-dna-link-information-00 (work in 378 progress), September 2004. 380 [7] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", 381 draft-ietf-dhc-dna-ipv4-09 (work in progress), October 2004. 383 Authors' Addresses 385 JinHyeock Choi 386 Samsung AIT 387 Communication & N/W Lab 388 P.O.Box 111 Suwon 440-600 389 KOREA 391 Phone: +82 31 280 9233 392 EMail: jinchoe@samsung.com 393 Greg Daley 394 CTIE Monash University 395 Centre for Telecommunications and Information Engineering 396 Monash University 397 Clayton 3800 Victoria 398 Australia 400 Phone: +61 3 9905 4655 401 EMail: greg.daley@eng.monash.edu.au 403 Intellectual Property Statement 405 The IETF takes no position regarding the validity or scope of any 406 Intellectual Property Rights or other rights that might be claimed to 407 pertain to the implementation or use of the technology described in 408 this document or the extent to which any license under such rights 409 might or might not be available; nor does it represent that it has 410 made any independent effort to identify any such rights. Information 411 on the procedures with respect to rights in RFC documents can be 412 found in BCP 78 and BCP 79. 414 Copies of IPR disclosures made to the IETF Secretariat and any 415 assurances of licenses to be made available, or the result of an 416 attempt made to obtain a general license or permission for the use of 417 such proprietary rights by implementers or users of this 418 specification can be obtained from the IETF on-line IPR repository at 419 http://www.ietf.org/ipr. 421 The IETF invites any interested party to bring to its attention any 422 copyrights, patents or patent applications, or other proprietary 423 rights that may cover technology that may be required to implement 424 this standard. Please address the information to the IETF at 425 ietf-ipr@ietf.org. 427 Disclaimer of Validity 429 This document and the information contained herein are provided on an 430 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 431 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 432 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 433 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 434 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 435 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 437 Copyright Statement 439 Copyright (C) The Internet Society (2004). This document is subject 440 to the rights, licenses and restrictions contained in BCP 78, and 441 except as set forth therein, the authors retain all their rights. 443 Acknowledgment 445 Funding for the RFC Editor function is currently provided by the 446 Internet Society.