idnits 2.17.1 draft-ietf-ipngwg-scopedaddr-format-02.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: ---------------------------------------------------------------------------- == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 36 instances of lines with control characters in the document. == There are 6 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2373 (ref. 'ADDRARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2553 (ref. 'BASICAPI') (Obsoleted by RFC 3493) -- Possible downref: Non-RFC (?) normative reference: ref. 'SCOPEARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCOPEDROUTING' ** Obsolete normative reference: RFC 2732 (ref. 'URLFORMAT') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT T. Jinmei, Toshiba 2 June 28, 2000 A. Onoe, Sony 4 An Extension of Format for IPv6 Scoped Addresses 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026 [STD-PROC]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet Draft will expire on December 28, 2000. 31 Abstract 33 This document defines an extension of the format for IPv6 scoped 34 addresses. In the format, a zone identifier is attached to a scoped 35 address in order to supplement ambiguity of the semantics of the 36 address. Using the format with some library routines will make 37 scope-aware applications simpler. 39 1. Introduction 41 There are several types of scoped addresses defined in the "IPv6 42 Addressing Architecture" [ADDRARCH]. Since uniqueness of a scoped 43 address is guaranteed only within a corresponding zone [SCOPEARCH], 44 the semantics for a scoped address is ambiguous on a zone 45 boundary. For example, when a user specifies to send a packet from 46 a node to a link-local address of another node, the user must 47 specify the link of the destination as well, if the node is 48 attached to more than one link. 50 This characteristic of scoped addresses may introduce additional 51 cost to scope-aware applications; a scope-aware application may 52 have to provide a way to specify a scope zone for each scoped 53 address (e.g. a specific link for a link-local address) that the 54 application uses. Also, it is hard for a user to "cut and paste" a 55 scoped address due to the ambiguity of its scope. 57 Applications that are supposed to be used in end hosts 58 like telnet, ftp, and ssh, are not usually aware of scoped 59 addresses, especially of link-local addresses. However, an expert 60 user (e.g. a network administrator) sometimes has to give even 61 link-local addresses to such applications. 63 Here is a concrete example. Consider a multi-linked router, called 64 "R1", that has at least two point-to-point interfaces. Each of the 65 interfaces is connected to another router, called "R2" and "R3". 66 Also assume that the point-to-point interfaces are "unnumbered", 67 that is, they have link-local addresses only. 69 Now suppose that the routing system on R2 hangs up and has to be 70 reinvoked. In this situation, we may not be able to use a global 71 address of R2, because this is a routing trouble and we cannot 72 expect that we have enough routes for global reachability to R2. 74 Hence, we have to login R1 first, and then try to login R2 using 75 link-local addresses. In such a case, we have to give the 76 link-local address of R2 to, for example, telnet. Here we assume 77 the address is fe80::2. 79 Note that we cannot just type like 80 % telnet fe80::2 81 here, since R1 has more than one interface (i.e. link) and hence 82 the telnet command cannot detect which link it should try to 83 connect. 85 Although R1 could spray neighbor solicitations for fe80::2 on all 86 links that R1 attaches in order to detect an appropriate link, we 87 cannot completely rely on the result. This is because R3 might also 88 assign fe80::2 to its point-to-point interface and might return a 89 neighbor advertisement faster than R2. There is currently no 90 mechanism to (automatically) resolve such conflict. Even if we had 91 one, the administrator of R3 might not accept to change the 92 link-local address especially when R3 belongs to a different 93 organization from R1's. 95 Another example is an EBGP peering. When two IPv6 ISPs establish an 96 EBGP peering, using a particular ISP's global addresses for the 97 peer would be unfair, and using their link-local addresses would be 98 better in a neutral IX. In such a case, link-local addresses should 99 be specified in a router's configuration file and the link for the 100 addresses should be disambiguated, since a router usually connects 101 to multiple links. 103 This document defines an extension of the format for scoped addresses 104 in order to overcome this inconvenience. Using the extended format 105 with some appropriate library routines will make scope-aware 106 applications simpler. 108 2. Assumptions and Definitions 109 In this document we adopt the same assumption of characteristics of 110 scopes as described in the scoped routing document [SCOPEDROUTING]. 112 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 113 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, if and where they appear 114 in this document, are to be interpreted as described in [KEYWORDS]. 116 3. Proposal 118 The proposed format for scoped addresses is as follows: 120 % 122 where 123 is a literal IPv6 address, 124 is a string to identify the scope zone of the address, and 125 `%' is a delimiter character to distinguish between 126 and . 128 The following subsections describe detail definitions and concrete 129 examples of the format. 131 3.1 Scoped Addresses 133 The proposed format is applied to all kinds of unicast and 134 multicast scoped addresses, that is, all non-global unicast and 135 multicast addresses. 137 The format should not be used for global addresses. However, an 138 implementation which handles addresses (e.g. name to address 139 mapping functions) MAY allow users to use such a notation (see also 140 Appendix C). 142 3.2 Zone Identifiers 144 An implementation SHOULD support at least numerical identifiers as 145 , which are non-negative decimal numbers. Positive 146 identifiers MUST uniquely specify a single zone for a given scoped 147 address. An implementation MAY use zero to have a special meaning, 148 for example, a meaning that no scope zone is specified. 150 An implementation MAY support other kinds of non-null strings as 151 unless the strings conflict with the delimiter 152 character. The precise semantics of such additional strings is 153 implementation dependent. 155 One possible candidate of such strings would be interface names, 156 since interfaces uniquely disambiguate any type of scopes 157 [SCOPEDROUTING]. In particular, if an implementation can assume 158 that there is a one-to-one mapping between links and interfaces 159 (and the assumption is usually reasonable,) using interface names 160 as link identifiers would be natural. 162 An implementation could also use interface names as for 163 larger scopes than links, but there might be some confusion in such 164 use. For example, when more than one interface belongs to a same 165 site, a user would be confused about which interface should be 166 used. Also, a mapping function from an address to a name would 167 encounter a same kind of problem when it prints a scoped address 168 with an interface name as a zone identifier. This document does 169 not specify how these cases should be treated and leaves it 170 implementation dependent. 172 It cannot be assumed that a same identifier is common to all nodes in 173 a zone. Hence, the proposed format MUST be used only within a node 174 and MUST NOT be sent on a wire. 176 3.3 Examples 178 Here are examples. The following addresses 180 fe80::1234 (whose link identifier is 1) 181 fec0::5678 (whose site identifier is 2) 182 ff02::9abc (whose link identifier is 5) 183 ff08::def0 (whose organization identifier is 10) 185 would be represented as follows: 187 fe80::1234%1 188 fec0::5678%2 189 ff02::9abc%5 190 ff08::def0%10 192 If we use interface names as , those addresses could also 193 be represented as follows: 195 fe80::1234%ne0 196 fec0::5678%ether2 197 ff02::9abc%pvc1.3 198 ff08::def0%interface10 200 where the interface "ne0" belongs to link 1, "ether2" belongs to 201 site 2, and so on. 203 3.4 Omitting Zone Identifiers 205 This document does not intend to invalidate the original format 206 for scoped addresses, that is, the format without the scope 207 identifier portion. An implementation SHOULD rather provide a user 208 with a "default" zone of each scope and allow the user to omit 209 zone identifiers. 211 Also, when an implementation can assume that there is no ambiguity 212 of any type of scopes on a node, it MAY even omit the whole 213 functionality to handle the proposed format. An end host with a 214 single interface would be an example of such a case. 216 4. Combinations of Delimiter Characters 217 There are other kinds of delimiter characters defined for IPv6 218 addresses. In this section, we describe how they should be combined 219 with the proposed format for scoped addresses. 221 The IPv6 addressing architecture [ADDRARCH] also defines the syntax 222 of IPv6 prefixes. If the address portion of a prefix is scoped one 223 and the scope should be disambiguated, the address portion SHOULD 224 be in the proposed format. For example, the prefix fec0:0:0:1::/64 225 on a site whose identifier is 2 should be represented as follows: 227 fec0:0:0:1::%2/64 229 In this combination, it is important to place the zone identifier 230 portion before the prefix length, when we consider parsing the 231 format by a name-to-address library function (see Appendix A). That 232 is, we can first separate the address with the zone identifier from 233 the prefix length, and just pass the former to the library function. 235 The preferred format for literal IPv6 addresses in URL's are also 236 defined [URLFORMAT]. When a user types the preferred format for an 237 IPv6 scoped address whose zone should be explicitly specified, the 238 user could use the proposed format combined with the preferred 239 format. 241 However, the typed URL is often sent on a wire, and it would cause 242 confusion if an application did not strip the portion 243 before sending. Also, the proposed format might conflict with the 244 URI syntax [URI], since the syntax defines the delimiter chracter 245 (`%') as the escape character. 247 Hence, this document does not specify how the proposed format 248 should be combined with the preferred format for literal IPv6 249 addresses. As for the conflict issue with the URI format, it would 250 be better to wait until the relationship between the preferred 251 format and the URI syntax is clarified. Actually, the preferred 252 format for IPv6 literal addresses itself has same kind of conflict. 253 In any case, it is recommended to use an FQDN instead of a literal 254 IPv6 address in a URL, whenever an FQDN is available. 256 5. Related Issues 258 In this document, it is assumed that a zone identifier is not 259 necessarily common in a single zone. However, it would be useful if 260 a common notation is introduced (e.g. an organization name for a 261 site). In such a case, the proposed format could be commonly used 262 to designate a single interface (or a set of interfaces for a 263 multicast address) in a scope zone. 265 When the network configuration of a node changes, the change may 266 affect . Suppose that the case where numerical 267 identifiers are sequentially used as . When a network 268 interface card is newly inserted in the node, some identifiers may 269 have to be renumbered accordingly. This would be inconvenient, 270 especially when addresses with the numerical identifiers are stored 271 in non-volatile storage and reused after rebooting. 273 6. Security Considerations 275 Since the use of this approach to represent IPv6 scoped addresses 276 is restricted within a single node, it does not cause a security 277 atack from the outside of the node. 279 However, a malicious node might send a packet that contains a 280 textual IPv6 scoped address in the proposed format, intending to 281 deceive the receiving node about the zone of the scoped 282 address. Thus, an implementation should be careful when it 283 receives packets that contain IPv6 scoped addresses as data. 285 Appendix A. Interaction with API 287 The proposed format would be useful with some library functions 288 defined in the "Basic Socket API" [BASICAPI], the functions which 289 translate a nodename to an address, or vice versa. 291 For example, if getaddrinfo() parses a literal IPv6 address in the 292 proposed format and fills an identifier according to in 293 the sin6_scope_id field of a sockaddr_in6 structure, then an 294 application would be able to just call getaddrinfo() and would not 295 have to care about scopes. 297 Also, if getnameinfo() returns IPv6 scoped addresses in the proposed 298 format, a user or an application would be able to reuse the result by 299 a simple "cut and paste" method. 301 The kernel should interpret the sin6_scope_id field properly in 302 order to make these extensions feasible. For example, if an 303 application passes a sockaddr_in6 structure that has a non-zero 304 sin6_scope_id value to the sendto() system call, the kernel should 305 send the packet to the appropriate zone according to the 306 sin6_scope_id field. Similarly, when a packet arrives from a scoped 307 address, the kernel should detect the correct zone identifier based 308 on the address and the receiving interface, fill the identifier in 309 the sin6_scope_id field of a sockaddr_in6 structure, and then pass 310 the packet to an application via the recvfrom() system call, etc. 312 Note that the ipng working group is now revising the basic socket 313 API in order to support scoped addresses appropriately. When the 314 revised version is available, it should be preferred to the 315 description of this section. 317 Appendix B. Implementation Experiences 319 The WIDE KAME IPv6 stack implements the extension to the 320 getaddrinfo() and the getnameinfo() functions described in Appendix 321 A of this document. The source code is available as free software, 322 bundled in the KAME IPv6 stack kit. 324 The current implementation assumes a one-to-one mapping between 325 links and interfaces, and hence it uses interface names as 326 for links. 328 For instance, the implementation shows its routing table as 329 follows: 331 Internet6: 332 Destination Gateway Flags Intface 333 default fe80::fe32:93d1%ef0 UG ef0 335 This means that the default router is fe80::fe32:93d1 on the link 336 identified by the interface "ef0". A user can "cut and paste" the 337 result in order to telnet to the default router like this: 339 % telnet fe80::fe32:93d1%ef0 341 even on a multi-linked node. 343 As another example, we show how the implementation can be used for 344 the problem described in Section 1. 346 We first confirm the link-local address assigned to the 347 point-to-point interface of R2: 349 (on R1)% ping ff02::1%pvc0 351 PING(56=40+8+8 bytes) fe80::1 --> ff02::1 352 16 bytes from fe80::1%lo0, icmp_seq=0 hlim=64 time=0.474 ms 353 16 bytes from fe80::2%pvc0, icmp_seq=0 hlim=64 time=0.374 ms(DUP!) 354 ... 355 (we assume here that the name of the point-to-point interface 356 on R1 toward R2 is "pvc0" and that the link-local address on 357 the interface is "fe80::1".) 359 So the address should be fe80::2. Then we can login R2 using the 360 address by the telnet command without ambiguity: 362 % telnet fe80::2%pvc0 364 Though the implementation supports the extended format for all type 365 of scoped addresses, our current experience is limited to link-local 366 addresses. For other type of scopes, we need more experience. 368 The implementation also supports the notion of "default" scope zone 369 as described in Section 3.4. If a user specified "pvc0" as the 370 default link in the above example, the user can just type 372 % telnet fe80::2 374 then the kernel will automatically use the link identified by 375 "pvc0" as the link of the address fe80::2. 377 Appendix C. A Comprehensive Description of KAME's getXXXinfo Functions 378 The following tables describe the behavior of the KAME's 379 implementation we mentioned in Appendix B using concrete 380 examples. Note that those tables are not intended to be standard 381 specifications of the extensions but are references for other 382 implementors. 384 Those tables summarize what value the getXXXinfo functions return 385 against various arguments. For each of two functions we first 386 explain typical cases and then show non-typical ones. 388 The tables for getaddrinfo() have four columns. The first two are 389 arguments for the function, and the last two are the results. The 390 tables for getnameinfo() also have four columns. The first three 391 are arguments, and the last one is the results. 393 Columns "Hostname" contain strings that are numeric or non-numeric 394 IPv6 hostnames. 396 Columns "NI_NUMERICHOST" or "NHOST" show if the NI_NUMERICHOST is 397 set to flags for the corresponding getXXXinfo function. Columns 398 "NSCOPE" show if the NI_NUMERICSCOPE is set to flags for the 399 corresponding getnameinfo function. The value "1" means the flag 400 is set, and "0" means the flag is clear. "-" means that the field 401 does not affect the result. 403 Columns "sin6_addr" contain IPv6 binary addresses in the textual 404 format, which mean the values of the sin6_addr field of the 405 corresponding sockaddr_in6 structure. 407 Columns "sin6_scope_id" contain numeric numbers, which mean the 408 values of the sin6_scope_id field of the corresponding sockaddr_in6 409 structure. 411 If necessary, we use an additional column titled "N/B" to note 412 something special. 414 If an entry of a result column has the value "Error", it means the 415 corresponding function fails. 417 In the examples, we assume the followings: 418 - The hostname "foo.kame.net" has a AAAA DNS record 419 "3ffe:501::1". We also assume the reverse map is configured 420 correctly. 421 - There is no FQDN representation for scoped addresses. 422 - The numeric link identifier for the interface "ne0" is 5. 423 - We have an interface belonging to a site whose numeric identifier 424 is 10. 425 - The numeric identifier "20" is invalid for any type of scopes. 426 - We use the string "none" as an invalid non-numeric zone identifier. 428 Typical cases for getaddrinfo(): 430 Hostname NI_NUMERICHOST sin6_addr sin6_scope_id 431 "foo.kame.net" 0 3ffe:501::1 0 432 "3ffe:501::1" - 3ffe:501::1 0 433 "fec0::1%10" - fec0::1 10 434 "fe80::1%ne0" - fe80::1 5 435 "fe80::1%5" - fe80::1 5 437 Typical cases for getnameinfo(): 439 sin6_addr sin6_scope_id NHOST NSCOPE Hostname 440 3ffe:501::1 0 0 - "foo.kame.net" 441 3ffe:501::1 0 1 - "3ffe:501::1" 442 fec0::1 10 - - "fec0::1%10" 443 fe80::1 5 - 0 "fe80::1%ne0" 444 fe80::1 5 - 1 "fe80::1%5" 446 Non-typical cases for getaddrinfo(): 448 Hostname NI_NUMERICHOST sin6_addr sin6_scope_id N/B 449 "foo.kame.net" 1 Error 450 "foo.kame.net%20" - Error (*1) 451 "foo.kame.net%none" - Error (*1) 452 "3ffe:501::1%none" - Error 453 "3ffe:501::1%0" - 3ffe:501::1 0 (*2) 454 "3ffe:501::1%20" - 3ffe:501::1 20 (*2) 455 "fec0::1%none" - Error 456 "fec0::1" - fec0::1 0 (*3) 457 "fec0::1%0" - fec0::1 0 (*4) 458 "fec0::1%20" - fec0::1 20 (*5) 459 "fe80::1%none" - Error 460 "fe80::1" - fe80::1 0 (*3) 461 "fe80::1%0" - fe80::1 0 (*4) 462 "fe80::1%20" - fe80::1 20 (*5) 464 (*1) against an FQDN is invalid. 465 (*2) We do not expect that is specified for a global 466 address, but we don't regard it as invalid. 467 (*3) We usually expect that a scoped address is specified with 468 , but if no identifier is specified we just set 0 to 469 the sin6_scope_id field. 470 (*4) Explicitly specifying 0 as is not meaningful, but 471 we just treat the value as opaque. 472 (*5) The portion is opaque to getaddrinfo() even if it 473 is invalid. It is kernel's responsibility to raise errors, if 474 there is any connection attempt that the kernel cannot handle. 476 Non-typical cases for getnameinfo(): 478 sin6_addr sin6_scope_id NHOST NSCOPE Hostname N/B 479 3ffe:501::1 20 1 - "3ffe:501::1%20" (*6) 480 3ffe:501::1 20 0 - "foo.kame.net" (*7) 481 fec0::1 20 - - "fec0::1%20" 482 fec0::1 0 - - "fec0::1" (*8) 483 fe80::1 20 - - "fe80::1%20" 484 fe80::1 0 - - "fe80::1" (*8) 485 (*6) We do not expect that a global IPv6 address has a non-zero 486 zone identifier. But if it is the case, we just treat it as 487 opaque. 488 (*7) Despite the above, if the NI_NUMERICHOST is clear, we resolve 489 the address to a hostname and print the name without scope 490 zone information. We might have to reconsider this behavior. 491 (*8) We usually expect that a scoped address has a non-zero zone 492 identifier. But if the identifier is 0, we simply print the 493 address portion without scope zone information. 495 Acknowledgments 497 We authors are indebted to Brian Zill, Richard Draves, and Francis 498 Dupont for their careful comments and suggestions in a discussion 499 to define a unified format among early implementations. 501 Jim Bound also gave us valuable comments and clarifications through 502 discussions about API extensions for scoped addresses in the ipngwg 503 mailing list. 505 Hideaki YOSHIFUJI commented on relationship between the URI syntax 506 and the proposed format, and helped us improve the related section. 508 Jun-ichiro Hagino has been helping us through all the discussions 509 and his implementation efforts. 511 Authors' Addresses 513 Tatuya JINMEI 514 Research and Development Center, Toshiba Corporation 515 1 Komukai Toshiba-cho, Kawasaki-shi 516 Kanagawa 212-8582, JAPAN 517 Tel: +81-44-549-2230 518 Fax: +81-44-520-1841 519 Email: jinmei@isl.rdc.toshiba.co.jp 521 Atsushi Onoe 522 Internet Systems Laboratory, IN Laboratories, Sony Corporation 523 6-7-35 Kitashinagawa, Shinagawa-ku, Tokyo 141-0001, JAPAN 524 Tel: +81-3-5448-4620 525 Fax: +81-3-5448-4622 526 Email: onoe@sm.sony.co.jp 528 References 530 [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing 531 Architecture", RFC 2373, July 1998. 533 [BASICAPI] Gilligan, R. E., Thomson, S., Bound, J., Stevens, W., 534 "Basic Socket Interface Extensions for IPv6", Internet-Draft, 535 May 2000, . 537 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, March 1997. 540 [SCOPEARCH] S. Deering, B. Haberman, B. Zill, "IP Version 6 Scoped 541 Address Architecture", Internet-Draft, March 2000, 542 . 544 [SCOPEDROUTING] Haberman, B., "Routing of Scoped Addresses in the 545 Internet Protocol Version 6 (IPv6)", Internet-Draft, 546 March 2000, . 548 [STD-PROC] Bradner, S., The Internet Standards Process -- Revision 3, 549 RFC 2026, October 1996. 551 [URLFORMAT] Hinden, R., Carpenter, B., Masinter, L., "Preferred 552 Format for Literal IPv6 Addresses in URL's", RFC 2732, 553 December 1999. 555 [URI] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform 556 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 557 1998.