idnits 2.17.1 draft-matsuoka-multihoming-try-and-error-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC5220]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 8, 2009) is 5491 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: 'Figure 1' is mentioned on line 265, but not defined == Missing Reference: 'Table 1' is mentioned on line 283, but not defined == Missing Reference: 'Table 2' is mentioned on line 305, but not defined == Missing Reference: 'Table 3' is mentioned on line 317, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5220 ** Downref: Normative reference to an Informational RFC: RFC 5221 ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 5461 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Hirotaka Matsuoka 3 Internet-Draft NTT West 4 Category: Proposed Standard 5 Created: April 8, 2009 6 Expires: October 8, 2009 8 A Try and Error type approach for multihoming 9 draft-matsuoka-multihoming-try-and-error-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 [RFC5220] describes the possible problems which an end host may 35 experience, if the end host has multiple prefixes in a single 36 physical link. This document proposes a solution of so-called "try 37 and error" type about these problems originated in "Source Address 38 Selection" which is described in [RFC5220]. A new mechanism to 39 settle almost all of these problems is described in this document, 40 but actually it is not effective in some particular cases. Thus it is 41 necessary for every end user/host to be able to select on/off of this 42 mechanism. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1 47 2. Problems to be solved and preconditions . . . . . . . . . . . 3 48 3. Proposed mechanism 49 3.1. End host categorize source IP addresses 50 as high/low priority . . . . . . . . . . . . . . . . . . 3 51 3.2. End host detect invalid source IP address 52 using ICMPv6 error message . . . . . . . . . . . . . . . 4 53 4.Requirements 54 4.1.End host Requirements . . . . . . . . . . . . . . . . . . . 4 55 4.2.ISP network requirements . . . . . . . . . . . . . . . . . 5 56 5. "prohibited address pair list" and "working address pair list" 57 5.1.Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5.2. Prohibited address pair list . . . . . . . . . . . . . . . 6 59 5.3. working address pair list . . . . . . . . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 Requirements Language 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 1. Introduction 71 When an end host has multiple prefixes/addresses in a physical link, 72 it is required for end node to use a specific source prefix/address 73 which is allocated by the egress ISP network. Some types of problems 74 in this situation are pointed out in [RFC5220]. Some kind of 75 improvements in consumer premises equipment (CPE) router and/or an 76 end host must be needed to fix these problems. [RFC5221] describes 77 requirements for the mechanisms of solutions about these problems, 78 and T.Fujisaki [draft-fujisaki-dhc-addr -select-opt-06] proposes a 79 mechanism which ISP networks provide information to select a collect 80 source prefix/address by using DHCPv6 option message. 82 Actually, a perfect solution which can fix all problems originated in 83 "Source Address Selection" may be needed in the future. On the other 84 hand, a "Light type" solution which cannot fix a few, but can fix 85 almost all problems is very useful. M.Bagnulo proposed "Try and 86 Error" type approach [draft-ietf-6man-addr-select-sol-01], which 87 end host re-tried to communicate with another source address if the 88 end host detected communication failure that originates in source 89 address miss-selection. It is important that in general most end host 90 must not have so many prefix/addresses, but 2-3 or less. Based on 91 this assumption, an end host will find a correct source 92 prefix/address within two times attempt. 94 This document proposes a new "Try and Error" type solution. This 95 document does not include solutions to fix every kind of problems 96 originated in "Source Address Selection". The problems and 97 precondition that this document mentions are described in Section 2. 99 ICMPv6[RFC2463] can transmit the information of network state, and 100 many documents define ICMPv6 message, and expected behavior of an end 101 host which detects an icmpv6 message, respectively. Both the 102 description of proposed solution and the arrangement of relationship 103 in these documents are in Section 3. And the importance that an end 104 host which receives a specific ICMPv6 message retries the 105 communication immediately is also described in this section. 106 Requirements for end hosts and network are in section 4, and the 107 example of implementation is in section 5. The verification from the 108 perspective of [RFC5221] is in section 6. 110 2. Problems to be solved and preconditions 112 This document mainly describes the solution about the problem 113 originated in "Source Address Selection" which is described in 114 [RFC5220] section 2.1. On the other hand, this document doesn't 115 describe the problems about routing, for example, some routers on a 116 link don't cooperate each other, or a CPE router which has multiple 117 ISP uplinks uses them in round robin manner, etc. This document is 118 described on the assumption that correct routing information is 119 configured manually or automatically in their routers, and end hosts 120 will send packets to their default gateway router if an end host 121 doesn't have specific routing information. 123 3. Proposed mechanism 125 3.1. End host categorize source IP addresses as high/low priority 127 If "Try & Error" type approach is adopted, an end host has no need to 128 recognize source IP address that can communicate to destination IP 129 address before the communication starts. It is sufficient for an end 130 host to select a suitable source IP address which based on a rule 131 like [RFC3484] or others before the communication starts. When an end 132 host recognizes communication failure because of source IP address 133 miss-selection, an end host MUST memorize the source IP address that 134 should not be used for communicating to the destination IP address 135 "prohibited source address". An end host MUST reconnect to the 136 destination IP address with using the most suitable source IP address 137 except prohibited source addresses. 139 ICMPv6 error message is suitable to transmit an end host the source 140 address miss-selection. On the other hand, if an end host receives an 141 incoming packet including TCP Syn+Ack, the end host MUST memorize the 142 working source and destination address pair which is used in the 143 incoming packet, and the end host MUST use the pair of addresses for 144 an outgoing packet by priority. 146 3.2. End host detect invalid source IP address using ICMPv6 error 147 message 149 [RFC2463]-Section3.1 defines ICMPv6 destination unreachable error 150 messages "Type=1 Code=0-4" which are informed from a network node to 151 an end host, and [RFC4443] defines informative subsets of "Type=1 152 Code=1" as "Type=1 Code=5,6", respectively. But there is no 153 requirement about behavior for end node which receive these ICMPv6 154 error messages. 156 [RFC1122] defines ICMPv4 destination unreachable message "Type=3 157 Code=2-4" as Hard Error condition, and an end host which receives 158 these ICMPv4 error messages must terminate the corresponding 159 communication. F.Gont [RFC5461] describes ICMPv6 destination 160 unreachable message "Type=1 Code=0,3" as Soft Error condition in 161 comparison with the case in ICMPv4. According to these definition, 162 ICMPv6 error messages "Type=1 Code=1,2,4,5,6" are classified into 163 Hard Error condition, and an end host which receives these ICMPv6 164 error messages MUST terminate the corresponding communication. 166 [RFC4443] defines ICMPv6 error message "Type=1 Code=5" as follows. 167 If the reason for the failure to deliver is that the packet with this 168 source address is not allowed due to ingress or egress filtering 169 policies, the Code field is set to 5. 170 An end host which receives this type of error message MUST terminate 171 the corresponding communication, because communication failure has 172 occurred in source IP address miss-selection. 174 4.Requirements 176 4.1.End host Requirements 178 a. Every end host MUST have "working address pair list" which 179 described in Section 5. This list MUST be given priority than the 180 mechanism of source IP address selection defined in [RFC3484]. 182 a-1. An end host which received an incoming packet including TCP 183 Syn+Ack SHOULD memorize the source and destination IP addresses 184 of an incoming packet as the destination and source IP addresses 185 of "the working address pair list". 187 b. Every end host MUST have "prohibited address pair list" which 188 described in Section 5.2. This list MUST be given priority than 189 both of "working address pair list" and the source IP address 190 selection mechanism which is defined in [RFC3484]. 192 b-1. An end host which received an ICMPv6 "Type=1 Code=5" packet MUST 193 obtain the source and destination IP addresses which are 194 indicated in the invoked packet information and MUST memorize 195 them into "the prohibited address pair list". 197 c. The end host which received ICMPv6 "Type=1 Code=5" MUST terminate 198 the corresponding communication which was indicated in the invoked 199 packet information, immediately. After memorizing the new entry 200 into "the prohibited address pair list", the end host SHOULD retry 201 to communicate to the same destination IP address. The most 202 important thing is that "the prohibited address pair list" is 203 given higher priority than both of "working address pair list" and 204 the source IP address selection mechanism which is defined in 205 [RFC3484]. As a result, the source IP address which has caused 206 source address miss-selection will not be used. 208 c-1. In the case using TCP protocol communication, kernel in an end 209 host MUST edit "the prohibited address pair list" before 210 retrying the communication to the same destination IP address. 212 c-2. In the case using UDP protocol communication, kernel in an end 213 host MUST edit "the prohibited address pair list" and MUST 214 terminate the corresponding communication and inform error 215 message to application. Afterwards, this host will try to 216 communicate to the same destination IP address with another 217 source IP address. 219 4.2.ISP network requirements 221 a. An ISP network which is connected to end users directly MUST reply 222 ICMPv6 "Type=1 Code=5" to the end host that tries to communicate 223 with different source IP prefix that the ISP allocated to the end 224 user. 226 b. An ISP network which does not connect with end users directly MUST 227 NOT reply ICMPv6 "Type=1 Code=5" to the end host. An ISP network 228 which connects with end users directly SHOULD NOT transmit this 229 kind of messages to end user hosts. 231 5. "prohibited address pair list" and "working address pair list" 233 5.1.Overview 235 Every end node MUST have "prohibited address pair list" and "working 236 address pair list" respectively. Some system MAY have these list 237 separately, or MAY express them in one list. The most important thing 238 is that the prohibited address pair list is given priority than the 239 working address pair list, and it is possible to adjust to the 240 composition change in the network, when a working address pair is 241 obsoleted. 243 ==================================================== 244 | Internet | 245 ==================================================== 246 | | | 247 2001:db8:7000::/36 | 2001:db8:8000::/36 | 2001:db8:9000::/36 | 248 +----+-+ +---+--+ +---+--+ 249 | ISP1 | | ISP2 | | ISP3 | 250 +----+-+ +---+--+ +---+--+ 251 | | | 252 2001:db8:7000::/48 | 2001:db8:8000::/48 | 2001:db8:9000::/48 | 253 +-----+---+ +----+----+ +-----+---+ 254 | Router1 | | Router2 | | Router3 | 255 +-------+-+ +------+--+ +-------+-+ 256 | | | 257 2001:db8:7000:1::/64 | 2001:db8:8000:1::/64 | 2001:db8:9000:1::/64 | 258 | | | 259 ------+----------------------+----------------------+-- 260 | 261 +-+----+ 2001:db8:7000:1::abc 262 | Host | 2001:db8:8000:1::abc 263 +------+ 2001:db8:9000:1::abc 265 [Figure 1] 267 5.2. Prohibited address pair list 269 In this list, every record about a specific destination IP address 270 can have multiple source IP addresses. Records generates 271 automatically when the system accept ICMPv6 "Type=1 Code=5" error 272 message, and records SHOULD be configured also manually. In the above 273 figure, the list describes as below. 275 +-----------------+----------------------------------------------+ 276 |Destination | Source IP Addresses | 277 +-----------------+----------------------------------------------+ 278 |2001:db8:1:1::80 | 2001:db8:7000:1::abcd 2001:db8:8000:1::abcd | 279 |2001:db8:2:2::80 | 2001:db8:8000:1::abcd 2001:db8:9000:1::abcd | 280 |2001:db8:3:3::80 | 2001:db8:7000:1::abcd 2001:db8:9000:1::abcd | 281 +-----------------+----------------------------------------------+ 283 [Table 1] 285 These parameters in this list will change according to the network 286 composition, so that it is necessary to keep appropriate TTL. It is 287 preferable that TTL is less than 24 hours, and more than 60 seconds. 289 5.3. working address pair list 291 In this list, every record about a specific destination IP address 292 can have single source IP address. Records generates automatically 293 when the system accept incoming packets including Syn+Ack packet, and 294 records SHOULD be configured also manually. In the above figure, the 295 list describes as below. 297 +-----------------+-----------------------+ 298 |Destination | Source IP Address | 299 +-----------------+-----------------------+ 300 |2001:db8:1:1::80 | 2001:db8:9000:1::abcd | 301 |2001:db8:2:2::80 | 2001:db8:7000:1::abcd | 302 |2001:db8:3:3::80 | 2001:db8:8000:1::abcd | 303 +-----------------+-----------------------+ 305 [Table 2] 307 The following record MUST be deleted or ignored if exists, because 308 "prohibited address pair list" must be given priority than "working 309 address pair list" 311 +-----------------+-----------------------+ 312 |Destination | Source IP Address | 313 +-----------------+-----------------------+ 314 |2001:db8:1:1::80 | 2001:db8:8000:1::abcd | 315 +-----------------+-----------------------+ 317 [Table 3] 319 These records must keep appropriate TTL as the same with the case of 320 prohibited address pair list. 322 6. Security Considerations 324 This document requires end hosts to abort a connection when it 325 receives an ICMPv6 error message "Type=1, Code=5". Therefore, an 326 attacker wishing to reset an ongoing valid connection can send a 327 malicious ICMPv6 error message. In this point of view, ISPs which 328 directly connects with end user should stop any kind of malicious 329 ICMPv6 error message. 331 7. References 333 [RFC5220] A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama, 334 "Problem Statement for Default Address Selection in 335 Multi-Prefix Environments: Operational Issues of RFC 3484 336 Default Rules", RFC5220, July 2008. 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC5221] A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama, 342 "Requirements for Address Selection Mechanisms", RFC5221, 343 July 2008. 345 [RFC2463] A. Conta, S. Deering, "Internet Control Message Protocol 346 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 347 Specification", RFC2463, December 1998. 349 [RFC3484] R. Draves, "Default Address Selection for Internet 350 Protocol version 6 (IPv6)", RFC3484, February 2003. 352 [RFC4443] A. Conta, S. Deering, M. Gupta, "Internet Control Message 353 Protocol (ICMPv6) for the Internet Protocol Version 6 354 (IPv6) Specification", RFC4443, March 2006. 356 [RFC1122] R. Bradden, "RFC1122 - Requirements for Internet Hosts 357 - Communication Layers", RFC1122, October 1989. 359 [RFC5461] F. Gont, "TCP's Reaction to Soft Errors", RFC5461, 360 February 2009. 362 [draft-fujisaki-dhc-addr-select-opt-07] 363 Fujisaki, T., "Distributing Default Address Selection 364 Policy using DHCPv6", 365 draft-fujisaki-dhc-addr-select-opt-07 (work in progress), 366 March 2009. 368 [draft-ietf-6man-addr-select-sol-01] 369 A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama, 370 "Solution approaches for address-selection problems", 371 draft-ietf-6man-addr-select-sol-01.txt (work in progress), 372 June 2008. 374 Authors' Addresses 376 Hirotaka Matsuoka 377 NTT West 378 3-15 Bamba-cho Chuo-ku, Osaka 540-8511 379 Japan 381 phone: +81 6 4793 3921 382 Email: matsuoka.h@west.ntt.co.jp 384 Intellectual Property Statement 386 The IETF Trust takes no position regarding the validity or scope of 387 any Intellectual Property Rights or other rights that might be 388 claimed to pertain to the implementation or use of the technology 389 described in any IETF Document or the extent to which any license 390 under such rights might or might not be available; nor does it 391 represent that it has made any independent effort to identify any 392 such rights. 394 Copies of Intellectual Property disclosures made to the IETF 395 Secretariat and any assurances of licenses to be made available, or 396 the result of an attempt made to obtain a general license or 397 permission for the use of such proprietary rights by implementers or 398 users of this specification can be obtained from the IETF on-line IPR 399 repository at http://www.ietf.org/ipr 401 The IETF invites any interested party to bring to its attention any 402 copyrights, patents or patent applications, or other proprietary 403 rights that may cover technology that may be required to implement 404 any standard or specification contained in an IETF Document. Please 405 address the information to the IETF at ietf-ipr@ietf.org. 407 The definitive version of an IETF Document is that published by, or 408 under the auspices of, the IETF. Versions of IETF Documents that are 409 published by third parties, including those that are translated into 410 other languages, should not be considered to be definitive versions 411 of IETF Documents. The definitive version of these Legal Provisions 412 is that published by, or under the auspices of, the IETF. Versions of 413 these Legal Provisions that are published by third parties, including 414 those that are translated into other languages, should not be 415 considered to be definitive versions of these Legal Provisions. 417 For the avoidance of doubt, each Contributor to the IETF Standards 418 Process licenses each Contribution that he or she makes as part of 419 the IETF Standards Process to the IETF Trust pursuant to the 420 provisions of RFC 5378. No language to the contrary, or terms, 421 conditions or rights that differ from or are inconsistent with the 422 rights and licenses granted under RFC 5378, shall have any effect and 423 shall be null and void, whether published or posted by such 424 Contributor, or included with or in such Contribution. 426 Disclaimer of Validity 428 All IETF Documents and the information contained therein are provided 429 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 430 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 431 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 432 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 433 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 434 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 435 FOR A PARTICULAR PURPOSE. 437 Copyright Statement 439 Copyright (c) 2009 IETF Trust and the persons identified as the 440 document authors. All rights reserved. 442 This document is subject to BCP 78 and the IETF Trust's Legal 443 Provisions Relating to IETF Documents in effect on the date of 444 publication of this document (http://trustee.ietf.org/license-info). 445 Please review these documents carefully, as they describe your 446 rights and restrictions with respect to this document. 448 This document may contain material from IETF Documents or IETF 449 Contributions published or made publicly available before November 450 10, 2008. The person(s) controlling the copyright in some of this 451 material may not have granted the IETF Trust the right to allow 452 modifications of such material outside the IETF Standards Process. 453 Without obtaining an adequate license from the person(s) 454 controlling the copyright in such materials, this document may not 455 be modified outside the IETF Standards Process, and derivative 456 works of it may not be created outside the IETF Standards Process, 457 except to format it for publication as an RFC or to translate it 458 into languages other than English.