idnits 2.17.1 draft-arifumi-ipv6-nd-source-address-select-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 405. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 373), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 (January 26, 2005) is 7028 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) -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3315 (ref. '3') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (ref. '4') (Obsoleted by RFC 8415) -- No information found for draft-hirotaka-dhcp6-sas-option - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' ** Obsolete normative reference: RFC 3484 (ref. '6') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3775 (ref. '8') (Obsoleted by RFC 6275) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Arifumi Matsumoto 2 Internet-Draft Tomohiro Fujisaki 3 Expires: July 26, 2005 Hirotaka Matsuoka 4 Jun-ya Kato 5 NTT PF Lab. 6 January 26, 2005 8 Configuring Source Address Selection Policy 9 by Neighbor Discovery Protocol for IPv6 10 draft-arifumi-ipv6-nd-source-address-select-02 12 Status of this Memo 14 By submitting this Internet-Draft, we certify that any applicable 15 patent or other IPR claims of which we are aware have been disclosed, 16 or will be disclosed, and any of which we become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document describes a Neighbor Discovery IPv6 Source Address 42 Selection(SAS) Policy option for distributing of source address 43 selection policies to end nodes. This option is particularly 44 effective when a consumer site has multiple address blocks. Every 45 end node is guided by such a policy in selecting an appropriate 46 source address for each destination address. This makes it possible 47 for an end node to set up a connection without concern for transfer 48 failures due to ingress filtering by ISPs, for ISP operators to 49 manage user behavior and networking policy, and for consumers to be 50 provided with networks that are almost automatically robust and 51 reliable. 53 1. Introduction 55 An IPv6 multihoming site has multiple nodes, each of which is 56 assigned multiple IPv6 addresses by up stream ISPs. When there are 57 multiple up stream ISPs, the current means of selecting the ISP for 58 an outgoing packet is based on the destination address. Actually, in 59 general, each packet should have a source address that has been 60 allocated by the selected up stream ISP. This is because the routers 61 of ISPs may be configured to perform ingress filtering with the aim 62 of blocking packets with illegal source addresses. 64 In another Internet-Draft [1], we propose a technique that can be 65 used both to distribute policy information for source address 66 selection(SAS) at end nodes and to establish a method for packet- 67 forwarding by routers. This enables ISPs to control incoming traffic 68 from customer sites and the end nodes to select appropriate source 69 addresses. It also enables the selection of outgoing ISPs in a way 70 that is almost certain to produce successful connection setups. 72 In this document, we propose an extension to the Neighbor Discovery 73 Router Advertisement Message [2]. In another draft, we propose a new 74 option [5] for DHCPv6 [3,4] to handle delivery of address selection 75 policies end nodes. An address selection policy delivered to an end 76 node is stored in the form of a policy table, as defined in RFC 3484 77 [6]. These two drafts are protocol specifications implementing the 78 multihome network technique proposed previously [1]. 80 2. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [7]. 86 3. Message formats 88 3.1. Changes to Prefix Information option of Router Advertisement 89 Message 91 The change from Neighbor Discovery [2] section 4.6 is as follows: 93 0 1 2 3 94 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | Type | Length | Prefix Length |L|A|M| SASID | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | Valid Lifetime | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Preferred Lifetime | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Reserved2 | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | | 105 + + 106 | | 107 + Prefix + 108 | | 109 + + 110 | | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 Fields: 115 SASID 116 A 5-bit unsigned integer; the identifier of the Source Address 117 Selection (SAS) Policy option related to this Prefix Information 118 option. Each Prefix Information option can be linked with one 119 SAS Policy option, as mentioned in the next paragraph. If this 120 Prefix Information option isn't bound with any SAS Policy 121 option, the value of this field must be zero. Otherwise, it 122 will be the identifier of the corresponding SAS option. 124 3.2 Source Address Selection (SAS) Policy option 126 0 1 2 3 127 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Type | Length | Reserved | SASID | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Prefix Length | | 132 +-+-+-+-+-+-+-+-+ Prefix (Variable Length) | 133 | | 134 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | | Prefix Length | | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix (Variable Length) | 137 | | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 . . 140 . Prefix Length & Prefix ... . 141 . +-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | | Padding and End Marker | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Fields: 147 Type TBD 149 Length An 8-bit unsigned integer; the length of the option 150 (including the Type and Length fields) in units of 8 octets. 152 Reserved A 10-bit unused field. This field MUST be initialized to 153 zero by the sender and ignored by the receiver. 155 SASID A 5-bit unsigned integer; the identifier of the SAS Policy 156 option. A Router Advertisement Message cannot contain 157 multiple SAS Policy options with the same SASID. With this 158 identifier, the SAS Policy options are linked with the Prefix 159 Information option. An SAS Policy option with no linked 160 Prefix Information option will be discarded. 162 Prefix Length 163 An 8-bit unsigned integer; the number of leading bits in the 164 prefix that are valid. The value ranges from 0 to 128. The 165 Prefix field is 0, 4, 8, 12, or 16 octets, depending on the 166 length. 168 Prefix A variable-length field containing an IP address or the 169 prefix of an IP address. The Prefix Length field contains 170 the number of valid leading bits in the prefix. The bits in 171 the Prefix after the prefix length (if any) MUST be 172 initialized to zero by the sender and ignored by the 173 receiver. Pairs of Prefix Length and Prefix field may follow 174 here. 176 Padding and End Marker A variable-length padding field for 32-bit 177 alignment. This field also serves as a end marker and MUST 178 be initialized to 1 by the sender and ignored by the 179 receiver, in order not to be confused with Prefix field. 181 This option appears only in Router Advertisement Message and has to 182 have corresponding Prefix Information option within the same Router 183 Advertisement Message. Otherwise, this option MUST be ignored. 185 3.3 Discussion 187 The SASID, mentioned above, is used to link the Prefix Information 188 and a SAS Policy option. This field occupies as much space as 5-bit 189 reserved field in the Prefix Information option. Instead of the 190 SASID, an alternative method of linking is to copy the prefix of the 191 corresponding Prefix Information option into the SAS Policy option, 192 as shown in the figure below. This method, however, is expected to 193 consume more option space. 195 0 1 2 3 196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type | Length | Prefix Length | Reserved | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | | 201 | | 202 | Prefix | 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Prefix Length | | 206 +-+-+-+-+-+-+-+-+ Prefix (Variable Length) | 207 | | 208 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | Prefix Length | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix (Variable Length) | 211 | | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 . . 214 . Prefix ... . 215 . +-+-+-+-+-+-+-+-+ 216 | | Padding | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 4. Specifications 221 4.1 Router Specification 223 - The SAS Policy option MUST NOT appear in anything other than a 224 Neighbor Discovery Router Advertisement Message. 226 - Multiple Prefix Information options can share the same SASID. 228 - When a router has too much information to make into one packet 229 (1280 bytes), the incident SHOULD be reported or logged. 231 4.2 Host Specification 233 - An SAS Policy option in anything other than a Neighbor 234 Distribution Router Advertisement Message MUST be ignored. 236 - Each SAS Policy option is linked with one or more Prefix 237 Information options. This tuple will be kept in a policy table, 238 as defined in RFC 3484, Section 2.1 [6]. Assume that a host 239 receives the following tuples: 241 Prefix SAS 243 2001:1:1:1::/64 - SAS1 (2001:1::/16, 2001:2::/16) 244 2001:2:2:2::/64 - SAS1 (2001:1::/16, 2001:2::/16) 245 2002:3:3:3::/64 - SAS2 (::/0) 247 Table 1 249 Then, these tuples are stored in a policy table like that shown 250 below. 252 Prefix Precedence Label 254 2001:1:1:1::/64 undefined 10 255 2001:2:2:2::/64 undefined 10 256 2001:1::/16 undefined 10 257 2001:2::/16 undefined 10 258 2002:3:3:3::/64 undefined 20 259 ::/0 undefined 20 261 Table 2 263 The first two tuples in Table 1 are linked with the same SAS 264 Policy option (SAS1), so they are also linked with each other, and 265 thus, they have the same Label value in Table 2. 267 - When two Prefixes contained in different SAS Policy options are 268 the same, the Prefixes will be ignored. 270 - Each SAS Policy option has a lifetime, which is the valid lifetime 271 of the corresponding Prefix Information option. When an SAS 272 Policy option is related to multiple Prefix Information options, 273 its lifetime will be the maximum lifetime among those of all the 274 Prefix Information options. 276 5. Security Considerations 278 With regard to the possibility of traffic abduction by announcing a 279 bogus policy, this scheme seems to neither lower nor raise the 280 security level obtained with the existing base protocol, namely, 281 Neighbor Discovery Router Advertisement. It does, however, raise the 282 possibility of a new form of DoS attack on routers and hosts, in 283 which large numbers of address selection policies are generated by 284 different source addresses. We will have to discuss this and take 285 precautionary measures in designing the protocol specification. 287 6. IANA Considerations 289 This document defines a new ICMP option type. This must be assigned 290 ICMPv6 type number. 292 7. Revision History 294 - Unit of Source Address Selection Policy Option's Length field was 295 changed to 8 octets in conformance with RFC 2461. 297 - The length of SASID field in Prefix Information Option and Source 298 Address Selection Policy Option reduced to 5 bits for the support 299 of R flag defined by MobileIPv6 [8]. 301 - The field name 'padding' was changed to 'padding and end marker' to 302 clarify that it isn't just a padding. 304 8. Normative References 306 [1] Matsumoto, A., Fujisaki, T., Matsuoka. H and J. Kato, "Source 307 Address Selection Policy Distribution for Multihoming", 308 Internet-Draft, January 2005, draft-arifumi-ipv6-sas-policy- 309 dist-00.txt. (Work In Progress) 311 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 312 for IP Version 6 (IPv6)," RFC 2461, December 1998. 314 [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 315 Carney, "Dynamic Host Configuration Protocol for IPv6 316 (DHCPv6)," RFC 3315, July 2003. 318 [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 319 Configuration Protocol (DHCP) version 6" RFC 3633, December 320 2003. 322 [5] Matsuoka, H., Fujisaki, T., Kato, J. and A. Matsumoto, "Source 323 Address Selection Option DHCPv6," Internet-Draft, October 324 2004, draft-hirotaka-dhcp6-sas-option-00.txt. 326 [6] R. Draves, "Default Address Selection for Internet Protocol 327 version 6 (IPv6)," RFC 3484, February 2003. 329 [7] S. Bradner, "Key words for use in RFCs to Indicate Requirement 330 Levels", BCP 14, RFC 2119, March 1997. 332 [8] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", 333 RFC 3775, June 2004. 335 Authors' Addresses 337 Arifumi Matsumoto 338 Nippon Telegraph and Telephone Corporation 339 Information Sharing Platform Laboratories 340 3-9-11 Midori-cho 341 Musashino-shi, Tokyo 180-8585 Japan 342 Phone: +81-422-59-3334 343 E-Mail: matsumoto.arifumi@lab.ntt.co.jp 345 Tomohiro Fujisaki 346 Nippon Telegraph and Telephone Corporation 347 Information Sharing Platform Laboratories 348 3-9-11 Midori-cho 349 Musashino-shi, Tokyo 180-8585 Japan 350 Phone: +81-422-59-7351 351 E-Mail: fujisaki.tomohiro@lab.ntt.co.jp 353 Hirotaka Matsuoka 354 Nippon Telegraph and Telephone Corporation 355 Information Sharing Platform Laboratories 356 3-9-11 Midori-cho 357 Musashino-shi, Tokyo 180-8585 Japan 358 Phone: +81-422-59-4949 359 E-Mail: matsuoka.hirotaka@lab.ntt.co.jp 361 Jun-ya Kato 362 Nippon Telegraph and Telephone Corporation 363 Information Sharing Platform Laboratories 364 3-9-11 Midori-cho 365 Musashino-shi, Tokyo 180-8585 Japan 366 Phone: +81-422-59-2939 367 E-Mail: kato.junya@lab.ntt.co.jp 369 Full Copyright Statement 371 Copyright (C) The Internet Society (2004). This document is subject 372 to the rights, licenses and restrictions contained in BCP 78, and 373 except as set forth therein, the authors retain all their rights. 375 This document and the information contained herein are provided on 376 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 377 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 378 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 379 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 380 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 381 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 383 Intellectual Property 385 The IETF takes no position regarding the validity or scope of any 386 Intellectual Property Rights or other rights that might be claimed 387 to pertain to the implementation or use of the technology described 388 in this document or the extent to which any license under such 389 rights might or might not be available; nor does it represent that 390 it has made any independent effort to identify any such rights. 391 Information on the procedures with respect to rights in RFC 392 documents can be found in BCP 78 and BCP 79. 394 Copies of IPR disclosures made to the IETF Secretariat and any 395 assurances of licenses to be made available, or the result of an 396 attempt made to obtain a general license or permission for the use 397 of such proprietary rights by implementers or users of this 398 specification can be obtained from the IETF on-line IPR repository 399 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 this standard. Please address the information to the IETF at ietf- 405 ipr@ietf.org.