idnits 2.17.1 draft-eckert-pim-rfc1112bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 1) being 615 lines 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.) ** There are 45 instances of too long lines in the document, the longest one being 402 characters in excess of 72. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2021) is 1012 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 section? 'RFC4607' on line 173 looks like a reference -- Missing reference section? 'RFC1112' on line 62 looks like a reference -- Missing reference section? 'RFC4861' on line 141 looks like a reference -- Missing reference section? 'RFC3376' on line 148 looks like a reference -- Missing reference section? 'RFC3810' on line 148 looks like a reference -- Missing reference section? 'RFC5790' on line 149 looks like a reference -- Missing reference section? 'RFC4291' on line 170 looks like a reference -- Missing reference section? 'RFC7346' on line 171 looks like a reference -- Missing reference section? 'RFC7371' on line 171 looks like a reference -- Missing reference section? 'RFC3493' on line 378 looks like a reference -- Missing reference section? 'RFC2464' on line 318 looks like a reference -- Missing reference section? 'RFC6085' on line 318 looks like a reference -- Missing reference section? 'RFC3678' on line 379 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG S. Deering 3 Internet-Draft Retired 4 Intended status: Standards Track T. Eckert (Ed.) 5 Obsoletes: RFC1112 Futurewei USA 6 Expires: January 13, 2022 July 12, 2021 8 Host Extensions IP Multicasting - Any Source Multicast (ASM) 9 draft-eckert-pim-rfc1112bis-00 11 ABSTRACT 13 This memo specifies the extensions required of a host implementation 14 of the Internet Protocol (IP) to support Any Source Multicast (ASM) 15 IP Multicasting or abbreviated IP Multicast. 16 Distribution of this memo is unlimited. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 13, 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 2. INTRODUCTION 51 The host extensions defined in this memo are called 52 Any Source Multicast (ASM) IP multicast or abbreviated IP multicast. 53 The term Any Source Multicast is used to distinguish these extensions 54 from Source Specific Multicast (SSM) IP multicast as defined by [RFC4607]. 55 The abbreviation IP multicast always refers to this memo's extensions. 57 This memo applies to both IPv4 and IPv6. When it uses the term IP it 58 implies either or both version of the IP protocol. It uses 59 the terms IPv4 and/or IPv6 explicitly when referring to functions 60 applicable to only a specific version of the IP protocol. 62 This document is a revision of [RFC1112]. See Appendix II. for a detailled 63 list of changes from that memo. 65 IP multicasting is the transmission of an IP datagram to a "host 66 group", a set of zero or more hosts identified by a single IP 67 destination address. A multicast datagram is delivered to all 68 members of its destination host group with the same "best-efforts" 69 reliability as regular unicast IP datagrams, i.e., the datagram is 70 not guaranteed to arrive intact at all members of the destination 71 group or in the same order relative to other datagrams. 73 The membership of a host group is dynamic; that is, hosts may join 74 and leave groups at any time. There is no restriction on the 75 location or number of members in a host group. A host may be a 76 member of more than one group at a time. A host need not be a member 77 of a group to send datagrams to it. 79 A host group may be permanent or transient. A permanent group has a 80 well-known, administratively assigned IP address. It is the address, 81 not the membership of the group, that is permanent; at any time a 82 permanent group may have any number of members, even zero. Those IP 83 multicast addresses that are not reserved for permanent groups are 84 available for dynamic assignment to transient groups which exist only 85 as long as they have members. 87 Internetwork forwarding of IP multicast datagrams is handled by 88 "multicast routers" which may be co-resident with, or separate from, 89 internet gateways. A host transmits an IP multicast datagram as a 90 local network multicast which reaches all immediately-neighboring 91 members of the destination host group. If the datagram has an IP 92 time-to-live greater than 1, the multicast router(s) attached to the 93 local network take responsibility for forwarding it towards all other 94 networks that have members of the destination group. On those other 95 member networks that are reachable within the IP time-to-live, an 96 attached multicast router completes delivery by transmitting the 97 datagram as a local multicast. 99 This memo specifies the extensions required of a host IP 100 implementation to support IP multicasting, where a "host" is any 101 internet host or gateway other than those acting as multicast 102 routers. The algorithms and protocols used within and between 103 multicast routers are transparent to hosts and will be specified in 104 separate documents. This memo also does not specify how local 105 network multicasting is accomplished for all types of network, 106 although it does specify the required service interface to an 107 arbitrary local network and gives an Ethernet specification as an 108 example. Specifications for other types of network will be the 109 subject of future memos. 111 3. LEVELS OF CONFORMANCE 113 There are three levels of conformance to this specification: 115 Level 0: no support for IP multicasting. 117 There is, at this time, no requirement that all IPv4 implementations 118 support IP multicasting. Level 0 hosts will, in general, be 119 unaffected by multicast activity. The only exception arises on some 120 types of local network, where the presence of level 1 or 2 hosts may 121 cause misdelivery of multicast IP datagrams to level 0 hosts. Such 122 datagrams can easily be identified by the presence of a class D IP 123 address in their destination address field; they should be quietly 124 discarded by hosts that do not support IP multicasting. Class D 125 addresses are described in section 4 of this memo. 127 Level 1: support for sending but not receiving multicast IP 128 datagrams. 130 Level 1 allows a host to partake of some multicast-based services, 131 such as resource location or status reporting, but it does not allow 132 a host to join any host groups. An IP implementation may be upgraded 133 from level 0 to level 1 very easily and with little new code. Only 134 sections 4, 5, and 6 of this memo are applicable to level 1 135 implementations. 137 Level 2: full support for IP multicasting. 139 Level 2 allows a host to join and leave host groups, as well as send 140 IP datagrams to host groups. Most IPv6 hosts require Level 2 support 141 because IPv6 Neighbor Discovery ([RFC4861], as used on most link types) 142 depends on multicast and requires that nodes join Solicited Node multicast addresses. 144 Level 2 requires implementation of the Internet Group Management Protocol (IGMPv) 145 for IPv4 and the equivalent Multicast Listener Discovery Protocol (MLDv) for IPv6 146 and extension of the IP and local network service interfaces within the host. 148 The current protocol versions are IGMPv3 [RFC3376] and MLDv2 [RFC3810] or lightweight 149 versions of either protocol [RFC5790]. 151 All of the following sections of this memo are applicable to level 2 152 implementations. 154 4. HOST GROUP ADDRESSES 156 IPv4 Host groups are identified by class D IP addresses, i.e., those with 157 "1110" as their high-order four bits. Class E IP addresses, i.e., 158 those with "1111" as their high-order four bits, are reserved for 159 future addressing modes. 161 In Internet standard "dotted decimal" notation, host group addresses 162 range from 224.0.0.0 to 239.255.255.255. The address 224.0.0.0 is 163 guaranteed not to be assigned to any group, and 224.0.0.1 is assigned 164 to the permanent group of all IPv4 hosts (including gateways). This is 165 used to address all IPv4 multicast hosts on the directly connected 166 network. There is no multicast address (or any other IP address) for 167 all hosts on the total Internet. The addresses of other well-known, 168 permanent groups are to be published in "Assigned Numbers". 170 IPv6 Host groups are identified by IPv6 addresses as defined in [RFC4291] section 2.7 171 and updated by [RFC7346], [RFC7371]. 173 IPv4 and IPv6 addresses as specified in [RFC4607] are not used for 174 ASM IP multicast and are not considered IP host groups. They are instead 175 only the destination address part G of Source Specific Multicast (SSM) 176 IP multicast (S,G) channels. 178 Appendix I contains some background discussion of several issues 179 related to host group addresses. 181 5. MODEL OF A HOST IP IMPLEMENTATION 183 The multicast extensions to a host IP implementation are specified in 184 terms of the layered model illustrated below. In this model, ICMP/ICMPv6 185 and (for level 2 hosts) IGMP/MLD are considered to be implemented within 186 the IP module, and the mapping of IP addresses to local network 187 addresses is considered to be the responsibility of local network 188 modules. This model is for expository purposes only, and should not 189 be construed as constraining an actual implementation. 191 | | 192 | Upper-Layer Protocol Modules | 193 |__________________________________________________________| 195 --------------------- IP Service Interface ----------------------- 196 __________________________________________________________ 197 | | | | 198 | | IPv4: | IPv6: | 199 | | ICMP+ICMP | ICMPv6+MLD | 200 | IP [IPv4 and/or IPv6] |______________|______________| 201 | Module(s) | 202 | | 203 |__________________________________________________________| 205 ---------------- Local Network Service Interface ----------------- 206 __________________________________________________________ 207 | | | 208 | Local | IP-to-local address mapping | 209 | Network | (e.g., ARP/ND) | 210 | Modules |_____________________________| 211 | (e.g., Ethernet) | 212 | | 214 To provide level 1 multicasting, a host IP implementation must 215 support the transmission of multicast IP datagrams. To provide level 216 2 multicasting, a host must also support the reception of multicast 217 IP datagrams. Each of these two new services is described in a 218 separate section, below. For each service, extensions are specified 219 for the IP service interface, the IP module, the local network 220 service interface, and an Ethernet local network module. Extensions 221 to local network modules other than Ethernet are mentioned briefly, 222 but are not specified in detail. 224 6. SENDING MULTICAST IP DATAGRAMS 226 6.1. Extensions to the IP Service Interface 228 Multicast IP datagrams are sent using the same "Send IP" operation 229 used to send unicast IP datagrams; an upper-layer protocol module 230 merely specifies an IP host group address, rather than an individual 231 IP address, as the destination. However, a number of extensions may 232 be necessary or desirable. 234 First, the service interface should provide a way for the upper-layer 235 protocol to specify the IP time-to-live of an outgoing multicast 236 datagram, if such a capability does not already exist. If the 237 upper-layer protocol chooses not to specify a time-to-live, it should 238 default to 1 for all multicast IP datagrams, so that an explicit 239 choice is required to multicast beyond a single network. 241 Second, for hosts that may be attached to more than one network, the 242 service interface should provide a way for the upper-layer protocol 243 to identify which network interface is be used for the multicast 244 transmission. Only one interface is used for the initial 245 transmission; multicast routers are responsible for forwarding to any 246 other networks, if necessary. If the upper-layer protocol chooses 247 not to identify an outgoing interface, a default interface should be 248 used, preferably under the control of system management. 250 Third (level 2 implementations only), for the case in which the host 251 is itself a member of a group to which a datagram is being sent, the 252 service interface should provide a way for the upper-layer protocol 253 to inhibit local delivery of the datagram; by default, a copy of the 254 datagram is looped back. This is a performance optimization for 255 upper-layer protocols that restrict the membership of a group to one 256 process per host (such as a routing protocol), or that handle 257 loopback of group communication at a higher layer (such as a 258 multicast transport protocol). 260 IPv6 socket extensions supporting these functions are defined in [RFC3493], section 5.2. 262 6.2. Extensions to the IP Module 264 To support the sending of multicast IP datagrams, the IP module must 265 be extended to recognize IP host group addresses when routing 266 outgoing datagrams. Most IP implementations include the following 267 logic: 269 if IP-destination is on the same local network, 270 send datagram locally to IP-destination 271 else 272 send datagram locally to GatewayTo( IP-destination ) 274 To allow multicast transmissions, the routing logic must be changed 275 to: 277 if IP-destination is on the same local network 278 or IP-destination is a host group, 279 send datagram locally to IP-destination 280 else 281 send datagram locally to GatewayTo( IP-destination ) 283 If the sending host is itself a member of the destination group on 284 the outgoing interface, a copy of the outgoing datagram must be 285 looped-back for local delivery, unless inhibited by the sender. 286 (Level 2 implementations only.) 288 The IP source address of the outgoing datagram must be one of the 289 individual addresses corresponding to the outgoing interface. 291 A host group address must never be placed in the source address field 292 or anywhere in a source route or record route option of an outgoing 293 IP datagram. 295 6.3. Extensions to the Local Network Service Interface 297 No change to the local network service interface is required to 298 support the sending of multicast IP datagrams. The IP module merely 299 specifies an IP host group destination, rather than an individual IP 300 destination, when it invokes the existing "Send Local" operation. 302 6.4. Extensions to an Ethernet Local Network Module 304 The Ethernet directly supports the sending of local multicast packets 305 by allowing multicast addresses in the destination field of Ethernet 306 packets. All that is needed to support the sending of multicast IP 307 datagrams is a procedure for mapping IP host group addresses to 308 Ethernet multicast addresses. 310 An IPv4 host group address is mapped to an Ethernet multicast address 311 by placing the low-order 23-bits of the IP address into the low-order 312 23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex). 313 Because there are 28 significant bits in an IP host group address, 314 more than one host group address may map to the same Ethernet 315 multicast address. 317 Mapping of IPv6 host group addresses to Ethernet is defined in 318 [RFC2464] and [RFC6085]. 320 6.5. Extensions to Local Network Modules other than Ethernet 322 Other networks that directly support multicasting, such as rings or 323 buses conforming to the IEEE 802.2 standard, may be handled the same 324 way as Ethernet for the purpose of sending multicast IP datagrams. 325 For a network that supports broadcast but not multicast, such as the 326 Experimental Ethernet, all IP host group addresses may be mapped to a 327 single local broadcast address (at the cost of increased overhead on 328 all local hosts). For a point-to-point link joining two hosts (or a 329 host and a multicast router), multicasts should be transmitted 330 exactly like unicasts. For a store-and-forward network like the 331 ARPANET or a public X.25 network, all IP host group addresses might 332 be mapped to the well-known local address of an IP multicast router; 333 a router on such a network would take responsibility for completing 334 multicast delivery within the network as well as among networks. 336 7. RECEIVING MULTICAST IP DATAGRAMS 338 7.1. Extensions to the IP Service Interface 340 Incoming multicast IP datagrams are received by upper-layer protocol 341 modules using the same "Receive IP" operation as normal, unicast 342 datagrams. Selection of a destination upper-layer protocol is based 343 on the protocol field in the IP header, regardless of the destination 344 IP address. However, before any datagrams destined to a particular 345 group can be received, an upper-layer protocol must ask the IP module 346 to join that group. Thus, the IP service interface must be extended 347 to provide two new operations: 349 JoinHostGroup ( group-address, interface ) 351 LeaveHostGroup ( group-address, interface ) 353 The JoinHostGroup operation requests that this host become a member 354 of the host group identified by "group-address" on the given network 355 interface. The LeaveGroup operation requests that this host give up 356 its membership in the host group identified by "group-address" on the 357 given network interface. The interface argument may be omitted on 358 hosts that support only one interface. For hosts that may be 359 attached to more than one network, the upper-layer protocol may 360 choose to leave the interface unspecified, in which case the request 361 will apply to the default interface for sending multicast datagrams 362 (see section 6.1). 364 It is permissible to join the same group on more than one interface, 365 in which case duplicate multicast datagrams may be received. It is 366 also permissible for more than one upper-layer protocol to request 367 membership in the same group. 369 Both operations should return immediately (i.e., they are non- 370 blocking operations), indicating success or failure. Either 371 operation may fail due to an invalid group address or interface 372 identifier. JoinHostGroup may fail due to lack of local resources. 373 LeaveHostGroup may fail because the host does not belong to the given 374 group on the given interface. LeaveHostGroup may succeed, but the 375 membership persist, if more than one upper-layer protocol has 376 requested membership in the same group. 378 IPv6 socket extensions supporting these functions are defined in [RFC3493], section 5.2. 379 [RFC3678] specifies these functions for IPv4 and IPv6 (as well as for SSM). 381 7.2. Extensions to the IP Module 383 To support the reception of multicast IP datagrams, the IP module 384 must be extended to maintain a list of host group memberships 385 associated with each network interface. An incoming datagram 386 destined to one of those groups is processed exactly the same way as 387 datagrams destined to one of the host's individual addresses. 389 Incoming datagrams destined to groups to which the host does not 390 belong are discarded without generating any error report or log 391 entry. On hosts with more than one network interface, if a datagram 392 arrives via one interface, destined for a group to which the host 393 belongs only on a different interface, the datagram is quietly 394 discarded. (These cases should occur only as a result of inadequate 395 multicast address filtering in a local network module.) 397 An incoming datagram is not rejected for having an IP time-to-live of 398 1 (i.e., the time-to-live should not automatically be decremented on 399 arriving datagrams that are not being forwarded). An incoming 400 datagram with an IP host group address in its source address field is 401 quietly discarded. An ICMP/ICMPv6 error message (Destination Unreachable, 402 Time Exceeded, Parameter Problem, Source Quench, or Redirect) is 403 never generated in response to a datagram destined to an IP host 404 group. 406 The list of host group memberships is updated in response to 407 JoinHostGroup and LeaveHostGroup requests from upper-layer protocols. 408 Each membership should have an associated reference count or similar 409 mechanism to handle multiple requests to join and leave the same 410 group. On the first request to join and the last request to leave a 411 group on a given interface, the local network module for that 412 interface is notified, so that it may update its multicast reception 413 filter (see section 7.3). 415 The IP module must also be extended to implement the IGMP protocol for 416 IPv4 and the MLD protocol for IPv6. IGMP/MLD are used to keep neighboring multicast 417 routers informed of the host group memberships present on a 418 particular local network. 420 7.3. Extensions to the Local Network Service Interface 422 Incoming local network multicast packets are delivered to the IP 423 module using the same "Receive Local" operation as local network 424 unicast packets. To allow the IP module to tell the local network 425 module which multicast packets to accept, the local network service 426 interface is extended to provide two new operations: 428 JoinLocalGroup ( group-address ) 430 LeaveLocalGroup ( group-address ) 432 where "group-address" is an IP host group address. The 433 JoinLocalGroup operation requests the local network module to accept 434 and deliver up subsequently arriving packets destined to the given IP 435 host group address. The LeaveLocalGroup operation requests the local 436 network module to stop delivering up packets destined to the given IP 437 host group address. The local network module is expected to map the 438 IP host group addresses to local network addresses as required to 439 update its multicast reception filter. Any local network module is 440 free to ignore LeaveLocalGroup requests, and may deliver up packets 441 destined to more addresses than just those specified in 442 JoinLocalGroup requests, if it is unable to filter incoming packets 443 adequately. 445 The local network module must not deliver up any multicast packets 446 that were transmitted from that module; loopback of multicasts is 447 handled at the IP layer or higher. 449 7.4. Extensions to an Ethernet Local Network Module 451 To support the reception of multicast IP datagrams, an Ethernet 452 module must be able to receive packets addressed to the Ethernet 453 multicast addresses that correspond to the host's IP host group 454 addresses. It is highly desirable to take advantage of any address 455 filtering capabilities that the Ethernet hardware interface may have, 456 so that the host receives only those packets that are destined to it. 458 Unfortunately, many current Ethernet interfaces have a small limit on 459 the number of addresses that the hardware can be configured to 460 recognize. Nevertheless, an implementation must be capable of 461 listening on an arbitrary number of Ethernet multicast addresses, 462 which may mean "opening up" the address filter to accept all 463 multicast packets during those periods when the number of addresses 464 exceeds the limit of the filter. 466 For interfaces with inadequate hardware address filtering, it may be 467 desirable (for performance reasons) to perform Ethernet address 468 filtering within the software of the Ethernet module. This is not 469 mandatory, however, because the IP module performs its own filtering 470 based on IP destination addresses. 472 7.5. Extensions to Local Network Modules other than Ethernet 474 Other multicast networks, such as IEEE 802.2 networks, can be handled 475 the same way as Ethernet for the purpose of receiving multicast IP 476 datagrams. For pure broadcast networks, such as the Experimental 477 Ethernet, all incoming broadcast packets can be accepted and passed 478 to the IP module for IP-level filtering. On point-to-point or 479 store-and-forward networks, multicast IP datagrams will arrive as 480 local network unicasts, so no change to the local network module 481 should be necessary. 483 APPENDIX I. HOST GROUP ADDRESS ISSUES 485 This appendix is not part of the IP multicasting specification, but 486 provides background discussion of several issues related to IP host 487 group addresses. 489 Group Address Binding 491 The binding of IP host group addresses to physical hosts may be 492 considered a generalization of the binding of IP unicast addresses. 493 An IP unicast address is statically bound to a single local network 494 interface on a single IP network. An IP host group address is 495 dynamically bound to a set of local network interfaces on a set of IP 496 networks. 498 It is important to understand that an IP host group address is NOT 499 bound to a set of IP unicast addresses. The multicast routers do not 500 need to maintain a list of individual members of each host group. 501 For example, a multicast router attached to an Ethernet need 502 associate only a single Ethernet multicast address with each host 503 group having local members, rather than a list of the members' 504 individual IP or Ethernet addresses. 506 Allocation of Transient Host Group Addresses 508 This memo does not specify how transient group address are allocated. 509 It is anticipated that different portions of the IP transient host 510 group address space will be allocated using different techniques. 511 For example, there may be a number of servers that can be contacted 512 to acquire a new transient group address. Some higher-level 513 protocols (such as VMTP, specified in RFC-1045) may generate higher- 514 level transient "process group" or "entity group" addresses which are 515 then algorithmically mapped to a subset of the IP transient host 516 group addresses, similarly to the way that IP host group addresses 517 are mapped to Ethernet multicast addresses. A portion of the IP 518 group address space may be set aside for random allocation by 519 applications that can tolerate occasional collisions with other 520 multicast users, perhaps generating new addresses until a suitably 521 "quiet" one is found. 523 In general, a host cannot assume that datagrams sent to any host 524 group address will reach only the intended hosts, or that datagrams 525 received as a member of a transient host group are intended for the 526 recipient. Misdelivery must be detected at a level above IP, using 527 higher-level identifiers or authentication tokens. Information 528 transmitted to a host group address should be encrypted or governed 529 by administrative routing controls if the sender is concerned about 530 unwanted listeners. 532 APPENDIX II. Changes from RFC1112 534 This document updates RFC1112 with the following changes: 536 o It removes the claim that these host extensions are "... the recommended standard for IP multicasting in the Internet." (Status of the memo section). This is reflecting the experience of the past 30 years, in which Interdomain and even more so across the Internet has produced no full IETF standard solution for IPv4 and that SSM IP multicast is now considered the preferred standard for Interdomain/Internet deployments. See [draft-ietf-mboned-deprecate-interdomain-asm]. 538 o It is written to apply to both IPv4 and IPv6 by adding equivalent detail for IPv4 where RFC1112 only covered IPv4: addressing and protocol (MLD vs. IGMP). 540 o It introduces the term "ASM IP multicast" as another term for "Host Extensions for IP multicast". This became necessary because RFC4607 introduced another service model for IP Multicast called "Source Specific Multicast" (SSM), and since then, the original service of RFC1112 is more precisely called Any Source Multicast (ASM) IP multicast. 542 o It removes the original appendix I of RFC1112 that defined the IGMP version 1 protocol and text in the main document referring to details of IGMPv1 because that protocol is intended to be made obsolete as it is superceeded by IGMPv3/IGMPv3. 544 APPENDIX III. Discussion and Explanations 546 [RFC-editor: Please remove this section] 548 Intention: 550 This document is intended to be an update to RFC1112 for the following reasons: 552 RFC1112 is at the time of this writing the only FULL INTERNET STANDARD describing the ASM IP Multicast Service Model for IPv4. There is no eqivalent document for IPv6. RFC6434 section 5.10 is a stand-in, but it only describes MLD protocol version aspects but not the overall aspects of the host extensions and specifically the ASM IP multicast service. Instead it just refers to the term ASM and RFC1112. 554 RFC1112 includes the specification of IGMPv1. PIM WG would like to make IGMPv1 historic, but not the ASM host extensions / service. Instead, it ideally wants a FULL INTERNET STANDARD normative reference for ASM that applies to IPv4 and IPv6. This RFC1112bis is the attempt to do this. 556 Open Issues: 558 Has any document after RFC1112 (re-)defined the mapping of IPv4 multicast 559 group addresses to ethernet multicast MAC ? If so, then we should include 560 a reference to it and update the appropriate text in this rfc1112bis. 562 This document uses/defines the term "host group", which really is only a term 563 relevant in this traditional ASM service model, but not in SSM. Therefore new 564 text stating that IP multicast group addresses from RFC4607 are not included 565 in this ASM definition. This is hopefully aligned with the text in RFC4607. 567 Is it appropriate to have included text to refer to socket API for ASM 568 eg: rfc3678. These socket APIs are primarily about UDP sockets, and only 569 rarely for IP level. This document only specifies an IP Service Interface. 570 Note that RFC4607 (SSM) also refers to the socket interface extensions for 571 SSM under a section called "Extensions to the IP Module Interface". 573 Discuss: Why would this document still need to be a standards track document ? 574 IETF typically does not assign standard track to pure API/service-interface 575 document. With IGMPv1 removed from the document, what does it still make it 576 standards track, aka: define in a normative fashion interoperability 577 impacting behacior of nodes ? 579 Answer1: Definition of the IPv4 ASM address space, Definition of 580 the IP Multicast group to ethernet MAC address mapping for IPv4. The document 581 now also contains references to these standards aspects for IPv6, but those 582 are references to prior standards track documents. 584 Answer2: This document is similar in scope to RFC4607 (SSM) which is standards 585 track. The newly defined interop impacting behavior on the wire are also 586 limited: address ranges for IPv4/IPv6 SSM, and it is referring to RFC1112. 588 Discuss: Which documents should we claim this document is updating ? Hopefully 589 none other than rfc1112 - rfc1112 itself is referenced by > 60 RFCs. 590 si 592 Author's Addresses 594 Stephen E. Deering 595 Retired 596 Vancouver, British Columbia 597 Canada 598 Email: bob.hinden@gmail.com (email secretary) 600 Toerless Eckert (editor) 601 Futurewei Technologies Inc. USA 602 2220 Central Expy 603 Santa Clara, CA 95050 604 United States of America 605 Email: tte@cs.fau.de