idnits 2.17.1 draft-ietf-shim6-reach-detect-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 3978, Section 5.1 on line 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 271. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 287), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** 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. 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 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 an Authors' Addresses Section. 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 (Jul 11, 2005) is 6863 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) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Iljitsch van Beijnum 2 Jul 11, 2005 4 Shim6 Reachability Detection 5 draft-ietf-shim6-reach-detect-00.txt 7 Status of this Memo 9 By submitting this Internet-Draft, each author represents that any 10 applicable patent or other IPR claims of which he or she is aware 11 have been or will be disclosed, and any of which he or she becomes 12 aware will be disclosed, in accordance with Section 6 of BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet Draft expires Jan 11, 2006. 32 Copyright Notice 34 Copyright (C) The Internet Society (2005). All Rights Reserved. 36 Abstract 38 This draft discusses the issues of detecting failures in a currently 39 used address pair between two hosts and picking a new address pair to 40 be used when a failure occurs. The input for these processes are 41 ordered lists of local and remote addresses that are reasonably likely 42 to work. (I.e., not include addresses that are known to be unreachable 43 for local reasons.) These lists must be available at both ends of the 44 communication, although the ordering may differ. Building these address 45 lists from locally available information and synchronizing them with 46 the remote end are outside the scope of this document. 48 This text is for the most part based on discussions on the multi6 list, 49 several multi6 design team lists and the shim6 list, with notable 50 contributions from Erik Nordmark and Marcelo Bagnulo. 52 Suggestions and additions are more than welcome. 54 1 Introduction 56 The most widespread mechanisms to ensure reachability in current 57 protocols are: 59 - Acknowledgments. For instance, in TCP each segment received is 60 acknowledged immediately or after a short delay. Lack of 61 acknowledgments leads to retransmissions, and eventually, session 62 timeouts. 64 - Keepalives. In routing protocols it's customary to send keepalives at 65 periodic intervals and look for either responses to local keepalives 66 or for keepalives generated by the other side. If no keepalives or 67 responses were received for some time the other side is declared 68 unreachable. 70 - Monitoring and probing. IPv6 Neighbor Unreachability Detection 71 monitors the progress of higher layer protocols, and in the absence 72 of progress, probes the other side (when on-link) or the next hop 73 with a directed neighbor solicitation message. If there is no answer, 74 the other side (on-link) or router is declared unreachable. 76 None of these mechanisms seems like a good candidate to adopt for 77 end-to-end reachability detection, either because they duplicate 78 existing mechanisms or introduce unnecessary overhead. 80 In addition, exploring the full set of communication options between 81 two hosts that both have two or more addresses is an expensive 82 operation as the number of combinations to be explored increases very 83 quickly with the number of addresses. For instance, with two addresses 84 on both sides, there are four possible address pairs. Since we can't 85 assume that reachability in one direction automatically means 86 reachability for the complement pair in the other direction, the total 87 number of two-way combinations is eight. (Combinations = nA * nB * 2.) 88 Although links almost always work in two directions, routing protocols 89 and filters only work in one direction so unidirectional reachability 90 can happen. Without additional mechanisms, the practice of ingress 91 filtering by ISPs makes unidirectional connectivity likely. 93 In order to reduce packet overhead, it makes sense to have different 94 on-the-wire protocols for confirming existing reachability and full 95 exploration of potential reachability. 97 2 Determining reachability for the current pair 99 In discussions two models came up for determining whether the current 100 address pair used in ongoing communication still works. 102 The first model resembles IPv6 neighbor unreachability detection (NUD). 103 The idea is that when transport protocols see forward progress, they 104 inform the shim layer (positive feedback) and the shim layer doesn't 105 take any action. However, in the absence of positive feedback and in 106 the presence of outgoing traffic, the shim layer generates packets that 107 probe reachability. When the correspondent receives a probe, it sends 108 back an acknowledgment so the shim layer at the originating host knows 109 the address pair is still functional. When there are no acknowledgments 110 for several probes, a full reachability exploration is executed. 112 The second model ensures that all communication is bidirectional. So 113 when communication isn't bidirectional, there must be a failure and 114 again, a full reachability exploration is executed. Although most 115 protocols generate traffic in both directions most of the time, there 116 are times when there is only legitimate traffic in one direction and 117 not the other. The shim layer monitors incoming and outgoing packets, 118 and when there are incoming packets but no regular outgoing data 119 packets, the shim generates keepalive packets. So when there is 120 outgoing traffic, there must be either regular incoming traffic, or 121 keepalives generated by the other side. If not, there is probably a 122 failure so the full reachability exploration procedure is executed. 124 There are several different tradeoffs between the two models: 126 - In the first model, the sending host detects the problem, in the 127 second model, the receiving host detects the problem 129 - In the first model, a host can detect problems in either direction 131 - In the second model, a host can only detect problems in the receiving 132 direction so it must depend on the correspondent to detect problems 133 in the other direction 135 - The first model generates traffic in both directions, possibly 136 competing with payload traffic in the high-volume direction 138 - The second model only generates traffic in the no-traffic direction, 139 so there is never competition with payload traffic 141 - In absence of upper layer protocol feedback, the first model always 142 sends periodic probes 144 - The second model doesn't require upper layer protocol feedback to 145 suppress keepalives 147 There have been some discussions about positive versus negative 148 feedback. The first model doesn't have any use for negative feedback, 149 but needs positive feedback to reduce overhead. The second model has 150 little or no use for positive feedback, but may use negative feedback 151 to detect failures faster. However, using negative feedback from upper 152 layer protocols may prove challenging because upper layers can't be 153 trusted to provide the right quality or quantity feedback ("feedback 154 spamming"). 156 3 Address pair exploration 158 In its essence, address pair exploration is very simple: just send 159 probes using every possible address pair, wait for something to come 160 back and possibly consider the round trip time. 162 In practice, doing a full address pair exploration is very undesirable 163 because of the large number of packets involved. This can be especially 164 harmful when a lot of hosts on a link start doing this for many of 165 their correspondents at the same time when there is a failure further 166 upstream. 168 At this time, we don't have a clear vision of what this protocol should 169 look like, except that it should be conservative in the number of 170 packets it transmits in average-case scenarios, and that it's vitally 171 important to reject very bad paths or address pairs. 173 Since the failures that have the largest potential to generate a lot of 174 local address pair exploration are the ones where a link that's used 175 for a lot of different sessions breaks, it makes sense to somehow 176 generalize results for one correspondent into optimizations in the 177 address exploration with another correspondent. 179 A promising way to avoid bad paths would be to send out a first probe, 180 wait for about a round trip for the old working path and then send 181 another probe, and after that do an exponential backoff. If either the 182 first or the second pair were reasonable choices, there is a workable 183 solution within several round trips. 185 4 Granularity 187 It has not been determined what the association/multiplexing 188 granularity of shim6 will be: host-to-host, 189 upper-layer-identity-to-upper-layer-identity (ULID) or session. By its 190 nature, the reachability detection works on address or locator pairs. 191 It would be highly inefficient if each session, or even each ULID pair, 192 would do its own address pair exploration. On the other hand, it would 193 also be undesirable force all sessions or ULID associations between 194 two hosts to use the same address pairs. This probably means that when 195 a failure is determined, all sessions or associations should act 196 accordingly, but when reachability is determined, each session or 197 association may react according to its own preferences. 199 5 NAT and firewall considerations 201 Since shim6 is chartered for IPv6 solutions only, and NAT compatibility 202 is not expected, and by most people, not desired in IPv6, there is no 203 requirement for this protocol to pass through Network Address 204 Translation devices. However, the protocol may be applicable outside 205 shim6, making NAT compatibility desirable. 207 It is absolutely essential that the shim6 negotiations and the 208 reachability detection packets are passed through filters or firewalls 209 wherever application packets are passed through. If the shim6 210 negotiation and reachability detection packets are filtered out, shim6 211 can't be used. 213 A more complex situation arises when the shim6 negotiation packets pass 214 through a firewall, but the reachability detection packets are blocked. 215 To avoid this complexity, it's highly desirable to make the shim6 216 negotiation and reachability detection part of the same protocol, so 217 either both are allowed through or both are blocked. However, the same 218 is true if this reachability detection mechanism is used in other 219 protocols. This makes it desirable to define the reachability detection 220 protocol such that it can be embedded in other protocols. 222 Since firewalls are in wide use, it's important to consider whether a 223 new protocol will be able to pass through most firewalls without 224 requiring changes to the filter configuration. On the other hand, it 225 may not be possible to come up with a protocol that would be allowed 226 through a large percentage of all firewalls without changes, so extra 227 effort in this area may produce limited results. Also, in the long run 228 firewall configuration will presumably be changed, so any compromises 229 would only have short term benefits but long term downsides. 231 6 Security considerations 233 To avoid exposing information (even if it's just the fact that an 234 address is reachable), hosts will probably want to limit themselves to 235 taking part in reachability detection with known correspondents. This 236 means that there must be identifying information and a nonce that is at 237 least hard to guess but easy to check in all reachability detection 238 packets. 240 4 Document and author information 242 This document expires January, 2006. The latest version will always be 243 available at http://www.muada.com/drafts/. Comments are welcome at: 245 Iljitsch van Beijnum 247 Email: iljitsch@muada.com 249 Intellectual Property Statement 251 The IETF takes no position regarding the validity or scope of any 252 Intellectual Property Rights or other rights that might be claimed to 253 pertain to the implementation or use of the technology described in 254 this document or the extent to which any license under such rights 255 might or might not be available; nor does it represent that it has 256 made any independent effort to identify any such rights. Information 257 on the procedures with respect to rights in RFC documents can be 258 found in BCP 78 and BCP 79. 260 Copies of IPR disclosures made to the IETF Secretariat and any 261 assurances of licenses to be made available, or the result of an 262 attempt made to obtain a general license or permission for the use of 263 such proprietary rights by implementers or users of this 264 specification can be obtained from the IETF on-line IPR repository at 265 http://www.ietf.org/ipr. 267 The IETF invites any interested party to bring to its attention any 268 copyrights, patents or patent applications, or other proprietary 269 rights that may cover technology that may be required to implement 270 this standard. Please address the information to the IETF at 271 ietf-ipr@ietf.org. 273 Disclaimer of Validity 275 This document and the information contained herein are provided on an 276 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 277 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 278 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 279 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 280 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 281 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 283 Copyright Statement 285 Copyright (C) The Internet Society (2005). This document is subject 286 to the rights, licenses and restrictions contained in BCP 78, and 287 except as set forth therein, the authors retain all their rights. 289 Acknowledgment 291 Funding for the RFC Editor function is currently provided by the 292 Internet Society.