idnits 2.17.1 draft-mkhalil-ipv6-fastra-05.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 176. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 183. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 189. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 205), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** 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 issues found here. 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in 'Category: Standards', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 (Obsoleted by RFC 4861) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT 2 Category: Standards 3 Title: draft-mkhalil-ipv6-fastra-05.txt James Kempf 4 Date: July 19, 2004 DoCoMo Labs USA 5 Expires: January 20, 2005 Mohamed M Khalil 6 Nortel Networks 7 Brett Pentland 8 CTIE, Monash University 10 IPv6 Fast Router Advertisement 11 draft-mkhalil-ipv6-fastra-05.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 20, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document specifies an amendment to the router solicitation 45 handling procedures in RFC 2461 that allow for improved default 46 router aquisition performance when an active IP host moves from 47 one subnet to another. 49 1.0 Introduction 51 RFC 2461 [RFC2461] states that a router MUST delay a response to 52 a Router Solicitation (RS) by a random time between 0 and 53 MAX_RA_DELAY_TIME seconds. The idea behind MAX_RA_DELAY_TIME is 54 if there is more than one router on the link, simultaneously 55 transmitted responses will collide if the routers try to answer 56 the RS immediately, and, additionally, to avoid congestion when 57 a link comes up and all hosts on the link solicit. 59 The impact of this constraint on the performance of default 60 router aquisition for hosts that move between subnets can be 61 severe. Consider a wireless link layer technology in which the 62 mobile host gets a trigger from the link layer when the link 63 comes up. The host can immediately send out a RS rather than 64 waiting for the periodically multicast Router Advertisement 65 (RA), in order to optimize default router aquisition. However, 66 if the router abides by RFC 2461, default router aquisition is 67 delayed by some random amount, increasing the amount of time 68 before the host comes up on the link and can get its traffic. 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 72 document are to be interpreted as described in [RFC2119]. 74 2.0 Fast Router Advertisement 76 To allow for faster response times in the processing of RSs, 77 at most one router on any given link SHOULD be allowed to respond 78 immediately to RSs sent by hosts on that link. Determination of 79 how this router is designated is outside the scope of this 80 document. An RA that is immediately unicast to the sender rather 81 than delayed is known as a "fast RA". 83 3.0 Processing Router Solicitations 85 A router that is configured to provide fast RAs MUST maintain a 86 counter, FastRACounter, of the fast RAs sent since the last 87 unsolicited multicast RA was sent. when an RS is received, an 88 RA MUST be sent immediately if: 90 FastRACounter <= MAX_FAST_RAS 92 where MAX_FAST_RAS is the maximum number of RAs returned before 93 rolling over to multicast. 95 A router SHOULD choose to unicast the response directly to the 96 soliciting host's address (if the solicitation's source address 97 is not the unspecified address), otherwise the router MUST schedule 98 a multicast Router Advertisement in accordance with RFC 2461. 100 When a fast RA is sent, FastRACounter MUST be incremented by one. 101 By default, MAX_FAST_RAS is 10, but it SHOULD be configured 102 based on router capacity and expected mobile host solicitation load. 104 When FastRACounter exceeds MAX_FAST_RAS, a multicast Router 105 Advertisement SHOULD be scheduled for transmission as soon as 106 possible subject to the restriction that the interval between 107 multicast Router Advertisements not be less than 108 MIN_DELAY_BEWTEEN_RAS. Any further Router Solicitations received 109 after FastRACounter exceeds MAX_FAST_RAS and before sending the 110 next multicast Router Advertisement MUST be discarded. The 111 FastRACounter MUST be reset to zero after the next multicast Router 112 Advertisement is sent and processing for fast Router Advertisement 113 recommences. 115 4.0 Security Considerations 117 RFC 2461 contains a possible vulnerability to a DoS attack from a 118 host that bombards the router with RSs. Though the exact timing 119 of the RA response is variable, the router is still required to 120 respond with a unicast RA. As a consequence, a malicious host could 121 tie a router up in responding to individually transmitted RSs. This 122 document addresses this security vulnerability by limiting the 123 upper bound of the Router Advertisement's response rate 124 to (MAX_FAST_RAS+1)/MIN_DELAY_BETWEEN_RAS. 126 5.0 IANA Considerations 128 This document has no actions for IANA. 130 6.0 Normative References 132 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 133 Requirement Levels", BCP 14, RFC 2119, March 1997. 135 [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 136 Discovery for IP Version 6 (IPv6)", RFC 2461, December, 1998. 138 Acknowledgements 140 The authors would like to thank Erik Nordmark for his technical 141 feedback. 143 Authors' Contact Information 145 James Kempf 146 DoCoMo Communications Laboratories USA 147 180 Metro Drive 148 San Jose, CA 149 95110 150 Phone: +1 650 451 4711 151 Email: kempf@docomolabs-usa.com 153 Mohamed M Khalil 154 Nortel Networks Inc. 155 2201 Lakeside Blvd 156 Richardson, TX 75082-4399 157 mkhalil@nortelnetworks.com 159 Brett Pentland 160 Centre for Telecommunications and Information Engineering 161 PO Box 35 162 Monash University 3800 163 Australia 164 Phone: +61 3 9905 5245 165 Email: brett.pentland@eng.monash.edu.au 167 Intellectual Property Statement 169 The IETF takes no position regarding the validity or scope of any 170 Intellectual Property Rights or other rights that might be claimed to 171 pertain to the implementation or use of the technology described in 172 this document or the extent to which any license under such rights 173 might or might not be available; nor does it represent that it has 174 made any independent effort to identify any such rights. Information 175 on the procedures with respect to rights in RFC documents can be 176 found in BCP 78 and BCP 79. 178 Copies of IPR disclosures made to the IETF Secretariat and any 179 assurances of licenses to be made available, or the result of an 180 attempt made to obtain a general license or permission for the use of 181 such proprietary rights by implementers or users of this 182 specification can be obtained from the IETF on-line IPR repository at 183 http://www.ietf.org/ipr. 185 The IETF invites any interested party to bring to its attention any 186 copyrights, patents or patent applications, or other proprietary 187 rights that may cover technology that may be required to implement 188 this standard. Please address the information to the IETF at 189 ietf-ipr@ietf.org. 191 Disclaimer of Validity 193 This document and the information contained herein are provided on an 194 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 195 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 196 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 197 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 198 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 199 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 201 Copyright Statement 203 Copyright (C) The Internet Society (2004). This document is subject 204 to the rights, licenses and restrictions contained in BCP 78, and 205 except as set forth therein, the authors retain all their rights. 207 Acknowledgment 209 Funding for the RFC Editor function is currently provided by the 210 Internet Society.