idnits 2.17.1 draft-ietf-ipngwg-p2p-pingpong-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 140: '...to forward a packet, the router SHOULD...' RFC 2119 keyword, line 146: '...e forwarding router SHOULD NOT forward...' RFC 2119 keyword, line 147: '...case, the router SHOULD NOT generate I...' RFC 2119 keyword, line 149: '...8.2. The router SHOULD generate an IC...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 12, 2001) is 8323 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) -- Missing reference section? 'Hinden' on line 50 looks like a reference -- Missing reference section? '1998' on line 133 looks like a reference -- Missing reference section? 'Narten' on line 133 looks like a reference -- Missing reference section? '2001' on line 126 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Jun-ichiro itojun Hagino 3 INTERNET-DRAFT IIJ Research Laboratory 4 Expires: January 12, 2002 Tatuya JINMEI 5 Toshiba 6 Brian Zill 7 Microsoft 8 July 12, 2001 10 Avoiding ping-pong packets on point-to-point links 11 draft-ietf-ipngwg-p2p-pingpong-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as ``work in progress.'' 27 To view the list Internet-Draft Shadow Directories, see 28 http://www.ietf.org/shadow.html. 30 Distribution of this memo is unlimited. 32 The internet-draft will expire in 6 months. The date of expiration will 33 be January 12, 2002. 35 Abstract 37 In IPv6 point-to-point link operation, there is a significant 38 possibility of aberrant behavior in that packets may ping-pong between 39 the two ends of the link. The problem can lead to wasted bandwidth and 40 can possibly be abused by malicious parties. This document provides an 41 analysis and solution to the problem. 43 1. The problem 45 In IPv6 point-to-point link operation, there are cases where we assign 46 an IPv6 prefix (address block) to the link. They include the following 47 cases: 49 o Link-local prefix. Each of the links has to have fe80::/64 associated 50 with it. Refer to IPv6 addressing architecture [Hinden, 1998] section 51 2.1 and 2.5.8. 53 o In some cases, we assign a global or site-local address prefix to a 54 point-to-point link. 56 Let us assume that we have assigned P::/64 to a point-to-point link. 57 P::/64 could be the link-local address prefix (fe80::/64), a site-local 58 address prefix (fec0:0:0:x::/64) or a global address prefix. Also 59 assume that the Router A, which is on one end of the link, has an 60 address P::a. The Router B is on the other end, and has an address 61 P::b. 63 Router B 64 |P::b 65 | 66 | Point-to-point link, P::/64 67 | 68 |P::a 69 Router A 71 In the above situation, we will see packets go ping-pong between Router 72 A and B under the following conditions: 74 o There is no link-layer address (like MAC address) for the point-to- 75 point link, Link-layer address resolution procedure is not necessary. 76 It is true for many of point-to-point medium, including PPP links and 77 IPv6-over-IPv4 tunnels. 79 o A packet arrives to either of the routers, or one of the routers 80 originates a packet. The destination address of the packet is P::c 81 (matches P::/64, and not equal to neither P::a nor P::b). 83 Now, suppose that Router A is about to forward a packet, destination 84 address is set to P::c. The packet would leave the Router A to the 85 point-to-point link, as the destination address P::c satisfies the 86 following conditions: 88 o The destination address matches P::/64, and 90 o the destination address is not equal to P::a. 92 The packet reaches Router B. The address P::c is not equal to P::b, so 93 the Router B would forward the packet back to the point-to-point link. 94 The packet will be sent back to the point-to-point link repeatedly, 95 until the hop limit field reaches 0. 97 If the packet in this example had originated at Router A, it would have 98 a source address of P::a. This would cause Router B to hit the redirect 99 case given in RFC 2461, section 8.2. In this case, Router B would not 100 only forward the packet back to A, but it would generate a useless 101 redirect as well. 103 All IPv6 implementations are subject to the problem described in this 104 draft, because it is required for nodes to have a link-local address on 105 an interface. 107 1.1. Why an address prefix on a point-to-point interface? 109 It seems that there are a couple of different design decisions made for 110 existing implementations. Some of the IPv6 implementations do not 111 permit assigning an address prefix to a point-to-point link, and require 112 users to specify the whole (/128) IPv6 address on the both ends. Some 113 other implementations assign a prefix to a point-to-point link, and lets 114 the user configure an address for only one end. This is a matter of 115 implementation and operation choice. This document does not try to 116 advocate either of the implementation decisions. 118 Independent from the above implementation decision, there are cases 119 where we need to consider a point-to-point as having an IPv6 address 120 prefix (or prefixes). 122 o Link-local address (fe80::/64). 124 o When a node is connected to an outside network by a point-to-point 125 interface, and if the node would like to use temporary addresses on 126 that point-to-point link [Narten, 2001] , we must assign an IPv6 127 address prefix (/64) to that link. 129 1.2. Why no link-layer address resolution? 131 When there is no link-layer address, or link-layer address resolution is 132 not necessary (for example, it is already configured beforehand), it is 133 not necessary to run Neighbor Discovery [Narten, 1998] (link-layer 134 address resolution). Many of the existing implementations do not. They 135 might run Neighbor Unreachability Detection (NUD) though, but NUD does 136 not really change the situation. 138 2. Solution 140 When a router attempts to forward a packet, the router SHOULD 141 additionally make the following check: 143 o Check the incoming/outgoing interface of the packet. If the interface 144 is the same, is a point-to-point interface and the destination address 145 on the packet seems to be on-link (in terms of Neighbor Discovery) on 146 the point-to-point interface, the forwarding router SHOULD NOT forward 147 the packet. Also, in this case, the router SHOULD NOT generate ICMPv6 148 redirect message even if the incoming packet meets conditions in 149 RFC2461 section 8.2. The router SHOULD generate an ICMPv6 error 150 message instead, with the type field being 1 (destination 151 unreachable), and the code field being 3 (address unreachable). 153 3. Applicability statements 155 There is no change in node behavior, except for the error case. The 156 change prevents the packet from going ping-pong, and consuming the 157 bandwidth on the link. By implementing the change to only one of the 158 two routers, the ping-pong problem will go away. Therefore, the change 159 can be deployed gradually. 161 One might think that it is better to mandate NS-NA exchange (link-layer 162 address resolution) even for links without link-layer addresses, or 163 point-to-point links in general. However, from the following issues, we 164 have dropped the option: 166 o It will cause interoperability issues with existing implementations. 167 If one end runs NS-NA exchange and the other end does not, they will 168 not be able to exchange traffic. The authors have actually seen this 169 kind of interoperability issue on an ATM PVC link during the early 170 stage of IPv6 deployment. 172 o It would be expensive to run NS-NA exchange, just to solve this corner 173 case. By adding NS-NA exchanges, it could cause packet drops during 174 the "resolution" period, or at least could delay the arrival of the 175 packet, while such drops and delay should not really be necessary. 177 4. Security consideration 179 This draft describes a problem with point-to-point links which can be 180 abused by malicious parties to mount denial of service attacks from 181 remote locations. Such attacks could fill up point-to-links with excess 182 traffic. A solution to the problem is discussed and presented in the 183 draft. 185 References 187 Hinden, 1998. 188 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in 189 RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. 191 Narten, 2001. 192 T. Narten and R. Draves, "Privacy Extensions for Stateless Address 193 Autoconfiguration in IPv6" in RFC3041 (January 2001). 194 ftp://ftp.isi.edu/in-notes/rfc3041.txt. 196 Narten, 1998. 197 T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP 198 Version 6 (IPv6)" in RFC2461 (December 1998). ftp://ftp.isi.edu/in- 199 notes/rfc2461.txt. 201 Change history 203 None. 205 Acknowledgements 207 The authors would like to thank Richard Draves and other participants 208 for their comments during meetings, including ipngwg Redmond interim 209 meeting (2001). 211 Authors' addresses 213 Jun-ichiro itojun Hagino 214 Research Laboratory, Internet Initiative Japan Inc. 215 Takebashi Yasuda Bldg., 216 3-13 Kanda Nishiki-cho, 217 Chiyoda-ku,Tokyo 101-0054, JAPAN 218 Tel: +81-3-5259-6350 219 Fax: +81-3-5259-6351 220 Email: itojun@iijlab.net 222 Tatuya JINMEI 223 Research and Development Center, Toshiba Corporation 224 1 Komukai Toshiba-cho, Kawasaki-shi 225 Kanagawa 212-8582, JAPAN 226 Tel: +81-44-549-2230 227 Fax: +81-44-520-1841 228 Email: jinmei@isl.rdc.toshiba.co.jp 230 Brian Zill 231 Microsoft Research 232 One Microsoft Way 233 Redmond, WA 98052 234 Phone: 1-425-703-3568 235 Email: bzill@microsoft.com