idnits 2.17.1 draft-ietf-dna-goals-00.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 567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 557. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 573), 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 171 has weird spacing: '... may be links...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 11, 2004) is 7258 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: '1' is defined on line 476, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 479, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 482, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (ref. '1') (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (ref. '2') (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 2461 (ref. '4') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '5') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (ref. '6') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 2411 (ref. '7') (Obsoleted by RFC 6071) == Outdated reference: A later version (-06) exists of draft-ietf-send-ndopt-05 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '9') (Obsoleted by RFC 6275) Summary: 12 errors (**), 0 flaws (~~), 8 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: December 10, 2004 Greg Daley 5 CTIE Monash University 6 June 11, 2004 8 Detecting Network Attachment in IPv6 Goals 9 draft-ietf-dna-goals-00.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 December 10, 2004. 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. While 47 checking for link change, 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). 52 Rapid attachment detection is required when a host has on-going data 53 traffic. Current DNA schemes are inadequate to support real-time 54 applications. The existing procedures for advertising network 55 information incur reception delays and do not provide enough 56 information to properly determine the identity of links. For 57 to-be-defined, efficient DNA schemes, a way to correctly represent a 58 link change, a complete and consistent procedure for network 59 information advertisement and a rapid delivery of the advertisements 60 will be necessary. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Detecting Network Attachment in Existing IPv6 Systems . . . . 5 66 3. Problems in Detecting Network Attachment . . . . . . . . . . . 7 67 3.1 Wireless link properties . . . . . . . . . . . . . . . . . 7 68 3.2 Inadequacies in RA information . . . . . . . . . . . . . . 7 69 3.3 Delays . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Goals for Detecting Network Attachment . . . . . . . . . . . . 10 71 4.1 Goals list . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 14 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 77 8.2 Informative References . . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 79 Intellectual Property and Copyright Statements . . . . . . . . 17 81 1. Introduction 83 When a host has established a new link-layer connection, it can send 84 and receive some IP packets at the link, particularly those used for 85 configuration. On the other hand, the host has full Internet 86 connectivity only when it is able to exchange packets with arbitrary 87 destinations. 89 When a link-layer connection is established or re-established, the 90 host doesn't know whether its existing IP configuration is still 91 valid for Internet connectivity. A subnet change might have occurred 92 when the host changed its attachment point. 94 In practice, the host doesn't know which of its addresses are valid 95 on the newly attached link. A host knows neither if its existing 96 default router is on this link, nor whether its neighbor cache 97 entries are valid. Correct configuration of each of these components 98 are necessary in order to send packets on and off the link. 100 While other information for IP connectivity (such as DNS server 101 configuration) is also important, obtaining most of such information 102 depends on the determination of correct global addressing and valid 103 default router configuration. 105 Hence, to determine the need of a further configuration, a host needs 106 to check at least that: 108 1) Whether it knows a (partially) reachable default router. 109 2) Whether it possesses a valid IP address. 111 Partial reachability indicates that the host is able to receive 112 packets from the router, but not necessarily vice versa. 114 To examine the status of the existing configuration, a host may check 115 whether a 'link change' has occurred. 117 Today a link change necessitates an IP configuration change. 118 Whenever the host detects that it has remained at the same link, it 119 can usually assume its IP configuration is still valid. Otherwise, 120 the existing one is no longer valid and a new configuration must be 121 acquired. Hence a host only needs to check for link change to 122 examine the validity of its IP configuration. 124 In the process of checking for link change, a host may collect some 125 of the necessary information for a new IP configuration, for example 126 on-link prefixes. So, when an IP subnet change has occurred, a host 127 can immediately initiate the process of getting a new IP 128 configuration. This may reduce handoff delay and minimize signaling. 130 Rapid attachment detection is required for a device that changes 131 subnet while having on-going sessions. This may be the case if a 132 host is connected intermittently, is a mobile node, or has urgent 133 data to transmit upon attachment to a link. 135 The process by which a host collects the appropriate information, 136 detects the identity of its currently attached link, and ascertains 137 the validity of its IP configuration, is called Detecting Network 138 Attachment (DNA). 140 It is important to note that DNA process does not include the actual 141 IP configuration procedure. For example, with respect to DHCP, the 142 DNA process may determine that the host needs to get some 143 configuration information from a DHCP server. However, the process 144 of actually retrieving the information from a DHCP server falls 145 beyond the scope of DNA. 147 2. Detecting Network Attachment in Existing IPv6 Systems 149 When a host changes its attachment point, for efficiency, a host 150 should examine whether its IP configuration is still valid before 151 initiating the process of acquiring a new IP configuration. 153 DNA process aims to examine whether a host's current IP configuration 154 is still valid. To achieve this goal, DNA process checks whether the 155 host is still at the same link. Also, DNA process collects necessary 156 information for a new IP configuration. 158 For this, the following mechanisms and data are available to hosts: 160 1) Router Solicitation/Router Advertisement (RS/RA) messages 161 2) Neighbor Solicitation/Neighbor Advertisement (NS/NA) messages 162 3) Information provided by the link-layer 164 Currently there is no way to represent the identity of links such 165 that link changes can be detected instantly. The information in the 166 above messages cannot be used to unambiguously identify links. 167 Section 3 gives the detail. 169 Though the set of all the assigned prefixes may be used to represent 170 a link identity, it is difficult for a host to attain and retain all 171 the prefixes with certainty. Moreover there may be links without 172 any advertised prefix. 174 Hence, to check for link change, as of today, a host must resort to 175 guessing, based on Router Discovery and Neighbor Unreachability 176 Detection (NUD). A host can examines whether 1) its existing default 177 router is still reachable and 2) its IP addresses are still valid. 179 After a network attachment, a host receives new (solicited or 180 unsolicited) RAs and compares them with the previously received ones. 181 It checks whether the information in the new RAs, the prefixes and 182 the router addresses, matches with the stored ones, the configured IP 183 addresses and the default router addresses. 185 If Router Discovery fails to update the existing router's 186 information, it indicates that the router is unreachable and should 187 not be used. 189 For Internet connectivity, a host needs to have an IP address whose 190 prefix is assigned on the current link. To check the validity of its 191 IP addresses, a host examines whether the prefix of its IP addresses 192 are present in the Prefix Information Option of received RAs. 194 Even if an address prefix is valid, an individual address is known to 195 be valid only after the Duplicate Address Detection (DAD) procedure 196 [5] has been completed. 198 If RAs indicate that a subnet change has occured, the invalidity of 199 other IP subnet information is implied. 201 At the same time, from the received RAs, a host may collect some of 202 the necessary information for a new configuration: a prefix to form a 203 new IP address and router addresses to select a new default router. 205 For rapid attachment detection, it is necessary for a host to receive 206 an RA quickly enough. 208 A host may also use NS/NA exchange to examine the reachability of the 209 existing default router. Upon detecting a new link-layer connection, 210 the host may probe the router with an NS message. If it receives an 211 appropriate NA message, the router is still reachable. Otherwise, if 212 the host receives no replies to Neighbor Solicitations, it may assume 213 that its default router is no longer reachable. 215 If a host receives a message from a router with which it has 216 previously been able to exchange packets, then the Neighbor Discovery 217 procedure may be used to establish full bi-directional reachability. 219 In some environments, link-layer information regarding IP 220 connectivity may be considered as a strong hint that change of 221 link-layer attachment implies change of IP subnet. While this is 222 sometimes the case, not all IP implementations at the network layer 223 will be able to understand the indication from the link-layers, nor 224 will those indications necessarily be always sufficient to make a 225 proper decision. 227 If the information from the link layer is available, but it is not 228 considered authoritative, the information may still be used as a 229 'Link-layer hint'. Link-layer hints are indications from lower 230 layers that IP connectivity may have changed. With suitable 231 hysteresis, these hints may be used to initiate IP based reachability 232 checks. 234 3. Problems in Detecting Network Attachment 236 There are a number of issues that make DNA complicated. First, 237 wireless connectivity is not as clear-cut as wired one. Second the 238 information contained in RA messages is not adequate for efficient 239 DNA. Third, Router Discovery or NUD may take too long and result in 240 service disruption. 242 3.1 Wireless link properties 244 1) Unclear boundary 246 Unlike wired environments, what constitutes wireless link is variable 247 in both time and space. It doesn't have clear boundaries. This may 248 be illustrated by the fact that a host may contact multiple (802.11) 249 access points at the same time. Moreover reachability on a wireless 250 link is very volatile, which may make link detection hard. 252 2) Asymmetric reachability 254 In some wireless environments, it may be possible to receive 255 periodically multicast advertisement information without being able 256 to send IP packets to the network. In these cases, it is 257 insufficient to rely upon reception of unsolicited advertisement 258 information as confirmation of router reachability. 260 3.2 Inadequacies in RA information 262 Usually a host receives the information necessary for IP 263 configuration from RA messages. Based on the current definition [4], 264 the information contained in RA messages is inadequate to represent a 265 link change. RA messages are not designed to represent link 266 identities and have inherent ambiguities. 268 1) Link local scope of Router Address 270 Usually a router address is contained in the source address field of 271 RA messages. That router address is link-local scope and its 272 uniqueness can't be guaranteed out side of a link. 274 So if it happens that two different router interfaces have the same 275 link-local address, a host can't detect that it has moved from one 276 interface to another by checking the router address in RA messages. 278 On the other hand, a host can't be sure that its default router is 279 reachable, even if it can communicate with the router that has the 280 same address as its existing router address. That router may be a 281 different one, which happens to have the same link-local address as 282 its default router address. 284 2) Omission of Prefix Information Option 286 To check the validity of its IP address, a host should examine 287 whether the prefix of its IP address is advertised on the link to 288 which it is currently attached. 290 The host checks whether the prefix of its IP addresses are present in 291 the Prefix Information Option of incoming RA messages. But an 292 unsolicited RA message can omit some prefixes for convenience, for 293 example to save bandwidth [4]. 295 Hence, the host can't be sure that the prefix of its current IP 296 address is not supported on the current link, even though the prefix 297 is not contained in a received RA. 299 3.3 Delays 301 The following issues cause DNA delay that may result in communication 302 disruption. 304 1) Delay for receiving a hint 306 For rapid attachment detection, hints can be used to tell a host that 307 a link change might have happened. This hint itself doesn't confirm 308 a link change, but can be used to initiate the appropriate 309 procedures. 311 Hints come in various forms, and differ in how they indicate a new 312 attachment. They can be link-layer indications, the lack of RA from 313 the default router or the receipt of a new RA. The time taken to 314 receive a hint also varies. 316 As soon as a new link-layer connection has been made, the link-layer 317 may send a link up notification to the IP layer. A host may 318 interpret a new network attachment as a hint for a possible link 319 change. With link-layer support, a host can receive a hint almost 320 instantly. 322 [9] defines the use of RA Interval Timer expiry for a hint. A host 323 keeps monitoring periodic RAs and interprets the lack of them as a 324 hint. It may implement its own policy to determine the number of 325 missing RAs for a hint. Hence the delay depends on the Router 326 Advertisement interval. 328 Without the schemes such as above, a host must receive a new RA from 329 a new router to detect a possible link change. The detection time 330 then also depends on the Router advertisement frequency. 332 Periodic RA beaconing transmits packets within an interval varying 333 randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds. 334 Because a network attachment is unrelated to the advertisement time 335 on the new link, the host is expected to arrive on average half way 336 through the interval. This is approximately 1.75 seconds with [4] 337 advertisement rates. 339 2) Delay for checking current default router Unreachability 341 When a host examines the reachability of the current default router, 342 a certain delay occurs if the current default router is not 343 reachable. 345 Usually it's easier to detect a node's presence than its absence. A 346 host sends a solicitation message and, upon the receipt of a reply, 347 it can assume that it's there. 349 To be sure that a node is absent, time needs to be taken to ensure 350 that the lack of a reply is not due to another reasons (for example, 351 packet loss, MAC latency, or processing delay). So it takes time to 352 verify the unreachability of the current router. 354 After a host moves to another link, if it uses NUD for detection, it 355 will take more than 3 seconds to recognize that the current router is 356 no longer reachable [4]. 358 3) Random delay execution for RS/ RA exchange 360 Router Solicitation and Router Advertisement messages are used for 361 Router Discovery. According to [4], it is sometimes necessary for a 362 host to wait a random amount of time to send an RS and for a router 363 to wait to reply an RA. 365 Before a host sends an initial solicitation, it SHOULD delay the 366 transmission for a random amount of time between 0 and 367 MAX_RTR_SOLICITATION_DELAY (1 second). Also Router Advertisements 368 sent in response to a Router Solicitation MUST be delayed by a random 369 time between 0 and MAX_RA_DELAY_TIME (0.5 seconds). 371 4. Goals for Detecting Network Attachment 373 DNA solutions should be 1) Precise, 2) Sufficiently fast and 3) Of 374 limited signaling. The solutions should correctly determine whether 375 a link change has occurred. They also should be sufficiently fast 376 lest there should be service disruption. They should not flood the 377 link with related signaling. 379 It will be necessary to investigate the usage of available tools, NS/ 380 NA messages, RS/RA messages, link-layer hints and other features. 381 This will allow precise description of procedures for efficient DNA 382 Schemes. 384 4.1 Goals list 386 G1 DNA schemes should detect the identity of the currently attached 387 link to ascertain the validity of the existing IP configuration. 388 They should recognize and determine whether a link change has 389 occurred and initiate the process of acquiring a new configuration 390 if necessary. 392 G2 When upper-layer protocol sessions are being supported, DNA 393 schemes should detect the identity of an attached link rapidly, 394 with minimal latency. 396 G3 In the case where a host has not changed a link or subnet, an IP 397 configuration change should not occur. 399 G4 DNA schemes should not cause undue signaling on a link. 401 G5 DNA schemes should make use of existing signaling mechanisms where 402 available. 404 G6 DNA schemes should make use of signaling within the link 405 (particularly link-local scope messages), since communication 406 off-link may not be achievable in the case of a link change. 408 G7 DNA schemes should be compatible with security schemes such as 409 Secure Neighbour Discovery [8] and IPSec [7]. 411 G8 A host configured for DNA should not expose itself to additional 412 man in the middle or identity revealing attacks. 414 G9 A host or router configured for DNA should not expose itself or 415 other devices on the link to additional denial of service attacks. 417 G10 The Routers supporting DNA should work appropriately with hosts 418 using unmodified configuration schemes, such as [4] and [6]. 420 G11 The Hosts supporting DNA should be able to work with unmodified 421 routers and hosts which do not support DNA schemes. 423 5. IANA Considerations 425 No new message formats or services are defined in this document. 427 6. Security Considerations 429 Because DNA schemes are based on Neighbor Discovery, its trust models 430 and threats are similar to the ones presented in [10]. Nodes 431 connected over wireless interfaces may be particularly susceptible to 432 jamming, monitoring and packet insertion attacks. Use of [8] to 433 secure Neighbor Discovery are important in achieving reliable 434 detection of network attachment. DNA schemes SHOULD incorporate the 435 solutions developed in IETF SEND WG if available, where assessment 436 indicates such procedures are required. 438 Even in the case where authoritative information (routing and prefix 439 state) are advertised, wireless network attackers may still prevent 440 soliciting nodes from receiving packets. This may cause unnecessary 441 IP configuration change in some devices. Such attacks may be used to 442 make a host preferentially select a particular configuration or 443 network access. 445 Devices receiving confirmations of reachability (for example from 446 upper-layer protocols) should be aware that unless these indications 447 are sufficiently authenticated, reachability may falsely be asserted 448 by an attacker. Similarly, such reachability tests, even if known to 449 originate from a trusted source should be ignored for reachability 450 confirmation if duplicates or stale. This may reduce the effective 451 window for attackers replaying otherwise authentic data. 453 It may be dangerous to receive link-change indications from 454 link-layer and network-layer, if they are received from devices which 455 are insufficiently authenticated. In particular, indications that 456 authentication has completed at the link-layer may not imply that a 457 security relationship is available at the network-layer. Additional 458 authentication may be required at the network layer to justify 459 modification of IP configuration. 461 7. Acknowledgment 463 Erik Nordmark has contributed significantly [11] to work predating 464 this draft. Also Ed Remmell's comments on the inconsistency of RA 465 information were most illuminating. The authors wish to express our 466 appreciation to Pekka Nikander for valuable feedback. We gratefully 467 acknowledge the generous assistance we received from Shubhranshu 468 Singh for clarifying the structure of the arguments. Thanks to Brett 469 Pentland, Nick Moore, Youn-Hee Han, JaeHoon Kim and Alper Yegin for 470 their contributions to this draft. 472 8. References 474 8.1 Normative References 476 [1] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, 477 February 2004. 479 [2] Bradner, S., "Intellectual Property Rights in IETF Technology", 480 BCP 79, RFC 3668, February 2004. 482 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 483 Levels", BCP 14, RFC 2119, March 1997. 485 [4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 486 IP Version 6 (IPv6)", RFC 2461, December 1998. 488 [5] Thomson, S. and T. Narten, "IPv6 Stateless Address 489 Autoconfiguration", RFC 2462, December 1998. 491 [6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 492 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 493 RFC 3315, July 2003. 495 [7] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document 496 Roadmap", RFC 2411, November 1998. 498 [8] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 499 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 500 (work in progress), April 2004. 502 8.2 Informative References 504 [9] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 505 IPv6", RFC 3775, June 2004. 507 [10] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 508 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 510 [11] Nordmark, E., "MIPv6: from hindsight to foresight?", 511 draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress), 512 November 2001. 514 Authors' Addresses 516 JinHyeock Choi 517 Samsung AIT 518 i-Networking Lab 519 P.O.Box 111 Suwon 440-600 520 KOREA 522 Phone: +82 31 280 9233 523 EMail: jinchoe@samsung.com 525 Greg Daley 526 CTIE Monash University 527 Centre for Telecommunications and Information Engineering 528 Monash University 529 Clayton 3800 Victoria 530 Australia 532 Phone: +61 3 9905 4655 533 EMail: greg.daley@eng.monash.edu.au 535 Intellectual Property Statement 537 The IETF takes no position regarding the validity or scope of any 538 Intellectual Property Rights or other rights that might be claimed to 539 pertain to the implementation or use of the technology described in 540 this document or the extent to which any license under such rights 541 might or might not be available; nor does it represent that it has 542 made any independent effort to identify any such rights. Information 543 on the procedures with respect to rights in RFC documents can be 544 found in BCP 78 and BCP 79. 546 Copies of IPR disclosures made to the IETF Secretariat and any 547 assurances of licenses to be made available, or the result of an 548 attempt made to obtain a general license or permission for the use of 549 such proprietary rights by implementers or users of this 550 specification can be obtained from the IETF on-line IPR repository at 551 http://www.ietf.org/ipr. 553 The IETF invites any interested party to bring to its attention any 554 copyrights, patents or patent applications, or other proprietary 555 rights that may cover technology that may be required to implement 556 this standard. Please address the information to the IETF at 557 ietf-ipr@ietf.org. 559 Disclaimer of Validity 561 This document and the information contained herein are provided on an 562 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 563 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 564 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 565 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 566 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 567 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 569 Copyright Statement 571 Copyright (C) The Internet Society (2004). This document is subject 572 to the rights, licenses and restrictions contained in BCP 78, and 573 except as set forth therein, the authors retain all their rights. 575 Acknowledgment 577 Funding for the RFC Editor function is currently provided by the 578 Internet Society.