idnits 2.17.1 draft-yamamoto-wideipv6-comm-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 a Security Considerations 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. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 96 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 369 has weird spacing: '...e-local the l...' == Line 379 has weird spacing: '...e-local the l...' -- 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 (September 1996) is 10056 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 1884 (ref. '1') (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 1970 (ref. '2') (Obsoleted by RFC 2461) -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Kazu Yamamoto 2 draft-yamamoto-wideipv6-comm-model-00.txt NAIST 3 Expires in six months Atsushi Onoe 4 Sony 5 Akira Kato 6 The University fo Tokyo 7 September 1996 9 The IPv6 communication model 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This memo discusses semantics of communication with IPv6 addresses. 32 This model introduces three address scope classes, node-local, 33 site-local, and global, for both IPv6 unicast and multicast 34 addresses. For a given packet, all addresses in the packet including 35 those in the routing header must be in the same address scope class. 37 Since the sockaddr_in6 address data structure is extended to be able 38 to hold an interface index number, a kernel and applications can 39 exchange interface information. A source address is uniquely 40 determined with the destination address and the outgoing interface. 42 This memo also clarifies packet processing mechanism for the input, 43 forward, and output function. 45 1. Introduction 47 Though RFC1884[1] introduced scope for IPv6 address architecture, 48 its semantics is not clear. For example, the following questions are 49 often asked: 51 (1) Are semantics of unicast scope and that of multicast scope equal? 52 (2) What are site-local-use addresses? 53 (3) How to use multicast scope? 54 (4) How to select a source address for a given destination address? 55 (5) How does a routing daemon know an incoming interface where 56 routing advertisement announced to link-local multicast comes? 58 This memo intends to clarify semantics of IPv6 address scope and to 59 define a communication model for IPv6. It is intended to provoke 60 discussion to lead a general consensus. 62 2. Address Scope Class 64 To avoid confusion of terminology, this memo first defines one term 65 "address scope class" or "scope-class" as a short 66 representation. Each IPv6 address is categorized to exactly one 67 scope-class out of node-local, link-local, and global. An IPv6 68 addresses in node-local scope-class are valid inside the node 69 only. Likewise IPv6 addresses in link-local scope-class are valid 70 inside the link only. IPv6 addresses in global scope-class are valid 71 in the entire Internet. Concrete categorization will be discussed 72 later in this memo. Please note that this memo carefully 73 distinguishes the term "scope" for multicast in RFC1884 and the term 74 "scope-class". 76 For convenience, this memo defines one function called "SC()" which 77 takes one IPv6 address as argument and returns a scope-class out of 78 node-local, link-local, and global. Their total ordering is also 79 defined as follows: 81 node-local < link-local < global 83 To ensure communication, this memo defines a basic principle for a 84 given IPv6 packet as follows: 86 SC(src) = SC(r1) = SC(r2) = ... = SC(rn) = SC(dst) 88 where "src" is the source address, "dst" is the destination address, 89 and r1, r2, ..., rn are intermediate nodes specified in the routing 90 header. 92 This basic principle can be logically proved as follows: 94 (1) In general, SC(src) must be greater than or equal to 95 SC(dst). That is, 97 SC(src) >= SC(dst) 99 must be satisfied. If not, it is often happened that the 100 receiving node cannot send back packets to the sending node. 102 (2) If two nodes are on the same link, SC(dst) may be greater 103 than SC(src). For example, node A sends a packet to node B where 104 scope-class of its source address is link-local and that of 105 destination is global. In this case, node B can send back 106 packets to node A where scope-class of its source address is 107 global and that of destination is link-local. Unfortunately, 108 there is no way to tell that the two nodes are on the same link 109 in IPv6 scheme. 111 (3) If two nodes are not on the same link, the following 112 condition must be satisfied according to (1): 114 SC(src) >= SC(r1) >= SC(r2) >= ... >= SC(rn) >= SC(dst) 116 Considering a reply packet, the following condition must be 117 satisfied: 119 SC(src) <= SC(r1) <= SC(r2) <= ... <= SC(rn) <= SC(dst) 121 Therefore, the following condition must be satisfied to ensure 122 communication for two nodes which are not on the same link. 124 SC(src) = SC(r1) = SC(r2) = ... = SC(rn) = SC(dst) 126 (4) According to (2) and (3), the basic principle is introduced. 128 3. Address Scope Class Categorization 130 Each IPv6 address are categorized to scope-class as follows: 132 Unicast and Anycast 133 SC(::1) = node-local 134 Memo: the loopback address 136 SC(FE80::/10) = link-local 137 Memo: link-local-use addresses 139 SC(others) = global 140 Memo: any other addresses including site-local-use 141 addresses and provider based addresses 143 Multicast 144 SC(FF?1/16) = node-local 145 Memo: node local scope multicast addresses 146 SC(FF?2/16) = link-local 147 Memo: link local scope multicast addresses 148 SC(FF/8) = global 149 Memo: any other multicast addresses including site-local 150 scope, organization-local scope, global scope 152 Both the loopback address and node-local scope multicast addresses 153 are valid inside a node by definition. So, it is reasonable to give 154 them node-local scope-class. 156 Link-local-use addresses are IP representations of MAC addresses and 157 are necessary for NDP[2]. They are valid inside the link by 158 definition. Link-local scope multicast addresses are also valid 159 inside the link by definition. So, it is reasonable to categorize 160 them to link-local scope-class. Any communication rather than NDP 161 can be done with global scope-class addresses, though, it is 162 basically a good idea to use link-local scope-class address to 163 ensure that packets are not forwarded to other links. Good examples 164 are kinds of routing protocol. 166 RFC1884 defines neither semantics of site-local-use unicast 167 addresses nor that of site-local scope of multicast addresses. It 168 was suggested to define scope-class for each multicast scope such as 169 site-local and organization-local for a sophisticated communication 170 model. Suppose that lower 64 bits are chosen to be unique inside a 171 site and upper 64 bits are assigned by its provider. A global 172 address is generated by concatenating the upper 64 bits and the 173 lower 64 bits while a site-local-use address is generated by 174 concatenating FEC0::/64 and the lower 64 bits. In this case, it is 175 easy to change the provider to another and to maintains 176 communication inside the site using the site-local-use address 177 during the reassign period of global address. But it is very likely 178 that poor hosts cannot handle such sophisticated communication. For 179 address reassignment, another mechanism such as auto-configuration 180 should be developed. 182 Unfortunately organization-local-use address are not defined in 183 RFC1884, so organization-local scope-class for organization-local 184 multicast addresses cannot be defined. This violates the basic 185 principle. Moreover, address selection is much difficult in this 186 model. For instance, with given a name of target host, how to 187 resolve both its link-local-use address and global address and then 188 how to select the best one out of them? If sites/organizations are 189 allowed to be connected by a router, it must have multiple routing 190 tables for the sites/organizations. This makes packet forwarding 191 mechanism very complicated. 193 This memo tries to make the communication model as simple as 194 possible for feasibility inheriting reasonable parts of the IPv4 195 communication model. Thus, scope-class of site-local-use addresses 196 is global and they are used as PRIVATE defined in [3], that is, free 197 but not unique in the Internet. Likewise, site-local scope multicast 198 and organization-local scope multicast are categorized as global 199 scope-class. Their scope is used for filtering purpose. 201 4. Link-local Scope-class and Interface Selection 203 Applications such as routing daemon cannot determine 204 incoming/outgoing interface for a given link-local scope-class 205 address in the original IPv6 scheme. So, it is necessary to define 206 generic API to resolve this problem. This memo defines an interface 207 index member for the sockaddr_in6 address data structure specified 208 in [4]. The interface index number is unique on a node and 209 orthogonal against IPv6 address. That is, the interface index number 210 is not encoded into an IPv6 address. 212 struct sockaddr_in6 { 213 u_char sin6_len; /* length of this struct */ 214 u_char sin6_family; /* AF_INET6 */ 215 u_int16m_t sin6_port; /* Transport layer port # */ 216 u_int32m_t sin6_flowinfo; /* IPv6 flow information */ 217 u_int32m_t sin6_ifindx; /* Interface Index */ 218 u_int32m_t sin6_pad; /* Reserved */ 219 struct in6_addr sin6_addr; /* IPv6 address */ 220 }; 222 An application specifies an outgoing interface for sending data with 223 the interface index number to the kernel. If the destination address 224 is in node-local scope-class, the kernel ignores the specified 225 interface index number and chooses the loopback interface. If in 226 link-local scope-class, the kernel use the specified interface index 227 number to choose interface. If the destination address is unicast 228 and in global scope-class, the kernel ignores the specified 229 interface index number and chooses a interface according to the 230 routing table. For the case where the destination address is 231 multicast and in global scope-class, this memo does not define any 232 actions and leaves it as an open problem. 234 When you send a multicast packet, this structure may be more useful 235 than specifying the outgoing interface via the setsockopt() 236 function. Discussion is required. 238 The kernel tells the application the incoming interface for the 239 incoming packet with the interface index number. 241 5. Source Address Selection 243 Any physical interface must have exactly one link-local-use address. 244 Any physical interface must have one "primary" global scope-class 245 address and may have one or more "secondary" global scope-class 246 addresses. The loopback interface has only "::1", node-local 247 scope-address. 249 If a destination address is in node-local scope-class, the source 250 address must be "::1". 252 If a destination address is in link-local scope-class, the source 253 address must be the link-local-use address of the outgoing 254 interface. For example, consider the case to send data to "FF01::1", 255 all node multicast address. An application specifies an interface 256 index number as well as the destination address. Kernel can select 257 the link-local-use address of the given interface. 259 If a destination address is in global scope-class, the source 260 address must be one of primary global scope-class addresses assigned 261 to interfaces. If a source address has been already chosen for the 262 communication (like TCP), it is used independent on the outgoing 263 interface. Otherwise (like UDP), the primary global scope-class 264 address of the outgoing interface is selected as a source 265 address. That is, as far as global scope-class unicast addresses are 266 concerned, a node can listen to all packets destined to all 267 addresses assigned to its interfaces but must use the primary global 268 scope-class addresses when it speaks. 270 The BSD API bind() function specifies a listening address and a 271 listening port. This rule can apply for both unicast address and 272 multicast address. If the bind() function is called with a specific 273 unicast address, the source address of the communication is the 274 unicast address. If the bind() function is called with 275 IPV6ADDR_ANY_INIT or a multicast address, both the destination 276 address of the incoming packet and the incoming interface can be 277 resolved by the recvfrom() function thanks to sockaddr_in6 extension 278 defined in this memo. The source address of outgoing packets 279 generated by the sendto() function and the outgoing interface are 280 determined by the rule described up above. 282 6. Packet Processing 284 This section defines how to process packets according to their 285 scope-class. It is supposed that hosts have input and output 286 routines for IPv6 packets. It is also assumed that routers have a 287 forward routine in additions to input and output routines. 289 Illegal packets are filtered out on the beginning of each routines 290 as follows: 292 routine (PACKET) 293 { 294 if (SC(src of PACKET) is NG) { 295 Discard the packet. 296 Generate an ICMP error message if necessary. 297 } 298 if (SC(dst of PACKET) is NG) { 299 Discard the packet. 300 Generate an ICMP error message if necessary. 301 } 303 Do the routine job. 304 } 306 Here is a summary table for the three routines. 308 309 Source 310 Unicast 311 unspecified OK not clear(*1) OK 312 loopback from lo0(*2) meaningless(*3) to lo0(*4) 313 link OK NG OK 314 site OK if !pbound(*5) OK 315 global OK OK OK 316 undefined OK OK OK 317 Multicast NG NG NG 318 Anycast same as UC(*6) same as UC(*6) NG 320 Destination 321 Unicast/Anycast 322 unspecified NG NG NG 323 loopback from lo0(*2) meaningless(*3) to lo0(*4) 324 link OK NG OK 325 site OK if !pbound(*5) OK 326 global OK OK OK 327 undefined OK OK OK 328 Multicast 329 node from lo0(*2) meaningless(*3) to lo0(*4) 330 link OK NG OK 331 site OK if !sbound(*7) OK 332 organization OK if !obound(*8) OK 333 global OK OK OK 334 undefined NG NG NG 336 OK -- Put the packet into the forward step. 337 NG -- Discard the packet. 338 *1 -- Need to research to fill this blank 339 *2 -- If the packet comes from the loopback interface, OK. 340 Otherwise, NG. 341 *3 -- It is meaningless to forward this packet. The action is 342 implementation dependent. 343 *4 -- If the packet goes to the loopback interface, OK. 344 Otherwise, NG. 345 *5 -- If the packet is forwarded to the same private Internet, OK. 346 Otherwise, NG. 347 *6 -- Cannot distinguish anycast packets from unicast in input 348 or forward routine. So, follow the same action of unicast. 349 *7 -- If the packet is forwarded to the same site, OK. 350 Otherwise, NG. 351 *8 -- If the packet is forwarded to the same organization OK. 352 Otherwise, NG. 354 Implementation Note: some filter rules can be omitted to optimize 355 performance. 357 Appendix 359 To conform this memo, some application must take an interface as an 360 argument. A typical example is an ICMP ECHO/REPLY application called 361 "ping". Here is a table of an outgoing interface and a source 362 address for a given destination address and a given interface. That 363 is, an action summary of "ping -i ". 365 Outgoing Interface Source Address 366 367 Unicast/Anycast 369 node-local the loopback "::1" 371 link-local the link-local-use address 372 of 374 global an interface the primary global 375 resolved from scope-class address of 376 the routing table the interface left 378 Multicast 379 node-local the loopback "::1" 381 link-local the link-local-use address 382 of 384 global an open problem an open problem 386 Author's Address 388 Kazuhiko YAMAMOTO 389 Nara Institute of Science and Technology(NAIST) 390 8916-5 Takayama, Ikoma City 630-01 JAPAN 391 Phone: +81-7437-2-5111 392 FAX: +81-7437-2-5329 393 EMail: kazu@is.aist-nara.ac.jp 395 Atsushi ONOE 396 Sony Corporation 397 3-3-1 Tsujido Shinmachi, Fujisawa City 251 JAPAN 398 Phone: +81-466-30-4033 399 FAX: +81-466-30-4205 400 EMail: onoe@sm.sony.co.jp 402 Akira KATO 403 The University of Tokyo 404 2-11-16 Yayoi Bunkyo 113 JAPAN 405 Phone: +81-3-3812-2111 ext 2726 406 FAX: +81-3-5684-7775 407 EMail: kato@wide.ad.jp 409 References 411 [1] R. Hinden, and S. Deering, "IP Version 6 Addressing 412 Architecture", RFC1884, 1995. 414 [2] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for 415 IP Version 6 (IPv6)", RFC1970, 1996. 417 [3] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and 418 E. Lear, "Address Allocation for Private Internets", RFC1918, 1996. 420 [4] R. E. Gilligan, S. Thomson, and J. Bound, "Basic Socket 421 Interface Extensions for IPv6", Internet-Draft, 422 , 1996.