idnits 2.17.1 draft-ietf-mboned-auto-multicast-05.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 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1177. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1154. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1161. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1167. ** 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. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 20, 2005) is 6760 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: 'PIMSM' is mentioned on line 456, but not defined == Missing Reference: 'SSM' is mentioned on line 839, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-11 -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Thaler 2 Internet-Draft M. Talwar 3 Expires: April 23, 2006 A. Aggarwal 4 Microsoft Corporation 5 L. Vicisano 6 Cisco Systems 7 T. Pusateri 8 Juniper Networks 9 October 20, 2005 11 Automatic IP Multicast Without Explicit Tunnels (AMT) 12 draft-ietf-mboned-auto-multicast-05 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 23, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 Automatic Multicast Tunneling (AMT) allows multicast communication 46 amongst isolated multicast-enabled sites or hosts, attached to a 47 network which has no native multicast support. It also enables them 48 to exchange multicast traffic with the native multicast 49 infrastructure and does not require any manual configuration. AMT 50 uses an encapsulation interface so that no changes to a host stack or 51 applications are required, all protocols (not just UDP) are handled, 52 and there is no additional overhead in core routers. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 58 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1 AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 6 60 3.2 AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3 AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.4 AMT Relay Router . . . . . . . . . . . . . . . . . . . . . 6 63 3.5 AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 7 64 3.6 AMT Relay Anycast Address . . . . . . . . . . . . . . . . 7 65 3.7 AMT Unicast Autonomous System ID . . . . . . . . . . . . . 7 66 3.8 AMT Subnet Prefix . . . . . . . . . . . . . . . . . . . . 7 67 3.9 AMT Gateway Anycast Address . . . . . . . . . . . . . . . 7 68 3.10 AMT Multicast Autonomous System ID . . . . . . . . . . . . 8 69 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1 Receiving Multicast in an AMT Site . . . . . . . . . . . . 9 71 4.1.1 Scalability Considerations . . . . . . . . . . . . . . 10 72 4.1.2 Spoofing Considerations . . . . . . . . . . . . . . . 10 73 4.2 Sourcing Multicast from an AMT site . . . . . . . . . . . 11 74 4.2.1 Supporting Site-MBone Multicast . . . . . . . . . . . 12 75 4.2.2 Supporting Site-Site Multicast . . . . . . . . . . . . 12 76 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 14 77 5.1 AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 14 78 5.1.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 5.1.2 Reserved . . . . . . . . . . . . . . . . . . . . . . . 14 80 5.1.3 Discovery Nonce . . . . . . . . . . . . . . . . . . . 14 81 5.2 AMT Relay Advertisement . . . . . . . . . . . . . . . . . 14 82 5.2.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 5.2.2 Reserved . . . . . . . . . . . . . . . . . . . . . . . 15 84 5.2.3 Discovery Nonce . . . . . . . . . . . . . . . . . . . 15 85 5.2.4 Relay Address . . . . . . . . . . . . . . . . . . . . 15 86 5.3 AMT Request . . . . . . . . . . . . . . . . . . . . . . . 15 87 5.3.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 5.3.2 Reserved . . . . . . . . . . . . . . . . . . . . . . . 16 89 5.3.3 Request Nonce . . . . . . . . . . . . . . . . . . . . 16 90 5.4 AMT Membership Query . . . . . . . . . . . . . . . . . . . 16 91 5.4.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 5.4.2 Reserved . . . . . . . . . . . . . . . . . . . . . . . 17 93 5.4.3 Response MAC . . . . . . . . . . . . . . . . . . . . . 17 94 5.4.4 Request Nonce . . . . . . . . . . . . . . . . . . . . 17 95 5.5 AMT Membership Update . . . . . . . . . . . . . . . . . . 17 96 5.5.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 5.5.2 Reserved . . . . . . . . . . . . . . . . . . . . . . . 18 98 5.5.3 Response MAC . . . . . . . . . . . . . . . . . . . . . 18 99 5.5.4 Request Nonce . . . . . . . . . . . . . . . . . . . . 18 100 5.6 AMT Multicast Data . . . . . . . . . . . . . . . . . . . . 18 101 5.6.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 5.6.2 Reserved . . . . . . . . . . . . . . . . . . . . . . . 19 103 5.6.3 UDP Multicast Data . . . . . . . . . . . . . . . . . . 19 104 6. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 20 105 6.1 At Startup Time . . . . . . . . . . . . . . . . . . . . . 20 106 6.2 Joining Groups with MBone Sources . . . . . . . . . . . . 20 107 6.3 Responding to Relay Changes . . . . . . . . . . . . . . . 21 108 6.4 Creating SSM groups . . . . . . . . . . . . . . . . . . . 22 109 6.5 Joining SSM Groups with AMT Sources . . . . . . . . . . . 22 110 6.6 Receiving IGMPv3/MLDv2 Reports at the Gateway . . . . . . 22 111 6.7 Sending data to SSM groups . . . . . . . . . . . . . . . . 23 112 7. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 24 113 7.1 At Startup time . . . . . . . . . . . . . . . . . . . . . 24 114 7.2 Receiving Relay Discovery messages sent to the Anycast 115 Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 116 7.3 Receiving Membership Updates from AMT Gateways . . . . . . 24 117 7.4 Receiving (S,G) Joins from the Native Side, for AMT 118 Sources . . . . . . . . . . . . . . . . . . . . . . . . . 25 119 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 120 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 121 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 122 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 123 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 124 12.1 Normative References . . . . . . . . . . . . . . . . . . . 30 125 12.2 Informative References . . . . . . . . . . . . . . . . . . 30 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31 127 Intellectual Property and Copyright Statements . . . . . . . . 33 129 1. Introduction 131 The primary goal of this document is to foster the deployment of 132 native IP multicast by enabling a potentially large number of nodes 133 to connect to the already present multicast infrastructure. 134 Therefore, the techniques discussed here should be viewed as an 135 interim solution to help in the various stages of the transition to a 136 native multicast network. 138 To allow fast deployment, the solution presented here only requires 139 small and concentrated changes to the network infrastructure, and no 140 changes at all to user applications or to the socket API of end- 141 nodes' operating systems. The protocol introduced in this 142 specification can be deployed in a few strategically-placed network 143 nodes and in user-installable software modules (pseudo device drivers 144 and/or user-mode daemons) that reside underneath the socket API of 145 end-nodes' operating systems. This mechanism is very similar to that 146 used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6 147 connectivity. 149 Effectively, AMT treats the unicast-only internetwork as a large non- 150 broadcast multi-access (NBMA) link layer, over which we require the 151 ability to multicast. To do this, multicast packets being sent to or 152 from a site must be encapsulated in unicast packets. If the group 153 has members in multiple sites, AMT encapsulation of the same 154 multicast packet will take place multiple times by necessity. 156 The following problems are addressed: 158 1. Allowing isolated sites/hosts to receive the SSM flavor of 159 multicast ([I-D.ietf-ssm-arch]). 161 2. Allowing isolated non-NAT sites/hosts to transmit the SSM flavor 162 of multicast. 164 3. Allowing isolated sites/hosts to receive general multicast (ASM 165 [RFC1112]). 167 This document does not address allowing isolated sites/hosts to 168 transmit general multicast. We expect that other solutions (e.g., 169 Tunnel Brokers, a la [RFC3053]) will be used for sites that desire 170 this capability. 172 Implementors should be aware that site administrators may have 173 configured administratively scoped multicast boundaries and a remote 174 gateway may provide a means to circumvent administrative boundaries. 175 Therefore, implementations should allow for the configuration of such 176 boundaries on relays and gateways and perform filtering as needed. 178 2. Requirements notation 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 3. Definitions 186 +---------------+ Internet +---------------+ 187 | AMT Site | | Native MCast | 188 | | AMT | | 189 | +------+----+ Relay +----+----+ AMT | 190 | |AMT Gateway| Anycast |AMT Relay| Subnet | 191 | | +-----+-+ Prefix +-+-----+ | Prefix | 192 | | |AMT IF | <--------|AMT IF | |--------> | 193 | | +-----+-+ +-+-----+ | | 194 | +------+----+ +----+----+ | 195 | | | | 196 +---------------+ +---------------+ 198 3.1 AMT Pseudo-Interface 200 AMT encapsulation of multicast packets inside unicast packets occurs 201 at a point that is logically equivalent to an interface, with the 202 link layer being the unicast-only network. This point is referred to 203 as a pseudo-interface. Some implementations may treat it exactly 204 like any other interface and others may treat it like a tunnel end- 205 point. 207 3.2 AMT Gateway 209 A host, or a site gateway router, supporting an AMT Pseudo- 210 Interface. It does not have native multicast connectivity to the 211 native multicast backbone infrastructure. It is simply referred to 212 in this document as a "gateway". 214 3.3 AMT Site 216 A multicast-enabled network not connected to the multicast backbone 217 served by an AMT Gateway. It could also be a stand- alone AMT 218 Gateway. 220 3.4 AMT Relay Router 222 A multicast router configured to support transit routing between AMT 223 Sites and the native multicast backbone infrastructure. The relay 224 router has one or more interfaces connected to the native multicast 225 infrastructure, zero or more interfaces connected to the non- 226 multicast capable internetwork, and an AMT pseudo-interface. It is 227 simply referred to in this document as a "relay". 229 As with [RFC3056], we assume that normal multicast routers do not 230 want to be tunnel endpoints (especially if this results in high 231 fanout), and similarly that service providers do not want 232 encapsulation to arbitrary routers. Instead, we assume that special- 233 purpose routers will be deployed that are suitable for serving as 234 relays. 236 3.5 AMT Relay Anycast Prefix 238 A well-known address prefix used to advertise (into the unicast 239 routing infrastructure) a route to an available AMT Relay Router. 240 This could also be private (i.e., not well-known) for a private 241 relay. 243 Prefixes for both IPv4 and IPv6 will be assigned in a future version 244 of this draft. 246 3.6 AMT Relay Anycast Address 248 An anycast address which is used to reach the nearest AMT Relay 249 Router. 251 This address corresponds to the lowest address in the AMT Relay 252 Anycast Prefix. 254 3.7 AMT Unicast Autonomous System ID 256 A 16-bit Autonomous System ID, for use in BGP in accordance to this 257 memo. This number represents a "pseudo-AS" common to all AMT relays 258 using the well known AMT Relay Anycast Prefix (private relays use 259 their own ID). 261 To protect themselves from erroneous advertisements, managers of 262 border routers often use databases to check the relation between the 263 advertised network and the last hop in the AS path. Associating a 264 specific AS number with the AMT Relay Anycast Address allows us to 265 enter this relationship in the databases used to check inter-domain 266 routing [RFC3068]. 268 3.8 AMT Subnet Prefix 270 A well-known address prefix used to advertise (into the M-RIB of the 271 native multicast-enabled infrastructure) a route to AMT Sites. This 272 prefix will be used to enable sourcing SSM traffic from an AMT 273 Gateway. 275 3.9 AMT Gateway Anycast Address 277 An anycast address in the AMT Subnet Prefix range, which is used by 278 an AMT Gateway to enable sourcing SSM traffic from local 279 applications. 281 3.10 AMT Multicast Autonomous System ID 283 A 16-bit Autonomous system ID, for use in MBGP in accordance to this 284 memo. This number represents a "pseudo-AS" common to all AMT relays 285 using the well known AMT Subnet Prefix (private relays use their own 286 ID). 288 4. Overview 290 4.1 Receiving Multicast in an AMT Site 292 Internet 293 +---------------+ +---------------+ 294 | AMT Site | 2. 3-way Membership | MBone | 295 | | Handshake | | 296 | 1. Join +---+---+ =================> +---+---+ | 297 | +---->|Gateway| | Relay | | 298 | | +---+---+ <================= +---+---+ | 299 | R-+ | 3. Receive Data | | 300 +---------------+ +---------------+ 302 AMT relays and gateways cooperate to transmit multicast traffic 303 sourced within the native multicast infrastructure to AMT sites: 304 relays receive the traffic natively and unicast-encapsulate it to 305 gateways; gateways decapsulate the traffic and possibly forward it 306 into the AMT site. 308 Each gateway has an AMT pseudo-interface that serves as a default 309 multicast route. Requests to join a multicast session are sent to 310 this interface and encapsulated to a particular relay reachable 311 across the unicast-only infrastructure. 313 Each relay has an AMT pseudo-interface too. Multicast traffic sent 314 on this interface is encapsulated to zero or more gateways that have 315 joined to the relay. The AMT recipient-list is determined for each 316 multicast session. This requires the relay to keep state for each 317 gateway which has joined a particular group or (source, group) pair). 318 Multicast packets from the native infrastructure behind the relay 319 will be sent to each gateway which has requested them. 321 All multicast packets (data and control) are encapsulated in unicast 322 packets. To work across NAT's, the encapsulation is done over UDP 323 using the IANA reserved AMT port number. 325 Each relay, plus the set of all gateways using the relay, together 326 are thought of as being on a separate logical NBMA link. This 327 implies that the AMT recipient- list is a list of "link layer" 328 addresses which are (IP address, UDP port) pairs. 330 Since the number of gateways using a relay can be quite large, and we 331 expect that most sites will not want to receive most groups, an 332 explicit-joining protocol is required for gateways to communicate 333 group membership information to a relay. The two most likely 334 candidates are the IGMP/MLD [RFC3376] [RFC3810] protocol, and the 335 PIM-Sparse Mode [I-D.ietf-pim-sm-v2-new] protocol. Since an AMT 336 gateway may be a host, and hosts typically do not implement routing 337 protocols, gateways will use IGMP/MLD as described in Section 5 338 below. This allows a host kernel (or a pseudo device driver) to 339 easily implement AMT gateway behavior, and obviates the relay from 340 the need to know whether a given gateway is a host or a router. From 341 the relay's perspective, all gateways are indistinguishable from 342 hosts on an NBMA leaf network. 344 4.1.1 Scalability Considerations 346 It is possible that millions of hosts will enable AMT gateway 347 functionality and so an important design goal is not to create 348 gateway state in each relay until the gateway joins a multicast 349 group. But even the requirement that a relay keep group state per 350 gateway that has joined a group introduces potential scalability 351 concerns. 353 Scalability of AMT can be achieved by adding more relays, and using 354 an appropriate relay discovery mechanism for gateways to discover 355 relays. The solution we adopt is to assign an anycast address to 356 relays. However, simply sending periodic membership reports to the 357 anycast address can cause duplicates. Specifically, if routing 358 changes such that a different relay receives a periodic membership 359 report, both the new and old relays will encapsulate data to the AMT 360 site until the old relay's state times out. This is obviously 361 undesirable. Instead, we use the anycast address merely to find the 362 unicast address of a relay to which membership reports are sent. 364 Since adding another relay has the result of adding another 365 independent NBMA link, this allows the gateways to be spread out 366 among more relays so as to keep the number of gateways per relay at a 367 reasonable level. 369 4.1.2 Spoofing Considerations 371 An attacker could affect the group state in the relay or gateway by 372 spoofing the source address in the join or leave reports. This can 373 be used to launch reflection or denial of service attacks on the 374 target. Such attacks can be mitigated by using a three way handshake 375 between the gateway and the relay for each multicast membership 376 report or leave. 378 When a gateway or relay wants to send a membership report, it first 379 sends an AMT Request with a request nonce in it. The receiving side 380 (the respondent) can calculate a message authentication code (MAC) 381 based on (for example) the source IP address of the Request, the 382 source UDP port, the request nonce, and a secret key known only to 383 the respondent. The algorithm and the input used to calculate the 384 MAC does not have to be standardized since the respondent generates 385 and verifies the MAC and the originator simply echoes it. 387 An AMT Membership Query is sent back including the request nonce and 388 the MAC to the originator of the Request. The originator then sends 389 the IGMP/MLD Membership/Listener Report or Leave/Done along with the 390 request nonce and the received MAC back to the respondent finalizing 391 the 3-way handshake. 393 Upon reception, the respondent can recalculate the MAC based on the 394 source IP address, the source UDP port, the request nonce, and the 395 local secret. The IGMP/MLD message is only accepted if the received 396 MAC matches the calculated MAC. 398 The local secret never has to be shared with the other side. It is 399 only used to verify return routability of the originator. 401 4.2 Sourcing Multicast from an AMT site 403 Two cases are discussed below: multicast traffic sourced in an AMT 404 site and received in the MBone, and multicast traffic sourced in an 405 AMT site and received in another AMT site. 407 In both cases only SSM sources are supported. Furthermore this 408 specification only deals with the source residing directly in the 409 gateway. To enable a generic node in an AMT site to source 410 multicast, additional coordination between the gateway and the 411 source-node is required. 413 The general mechanism used to join towards AMT sources is based on 414 the following: 416 1. Applications residing in the gateway use addresses in the AMT 417 Subnet Prefix to send multicast, as a result of sourcing traffic 418 on the AMT pseudo-interface. 420 2. The AMT Subnet Prefix is advertised for RPF reachability in the 421 M-RIB by relays and gateways. 423 3. Relays or gateways that receive a join for a source/group pair 424 use information encoded in the address pair to rebuild the 425 address of the gateway (source) to which to encapsulate the join 426 (see Section 5 for more details). The membership reports use the 427 same three way handshake as outlined in Section 4.1.2. 429 4.2.1 Supporting Site-MBone Multicast 431 Internet 432 +---------------+ +---------------+ 433 | AMT Site | 2. 3-way Membership | MBone | 434 | | Handshake | | 435 | +---+---+ <================= +---+---+ 1. Join | 436 | |Gateway| | Relay |<-----+ | 437 | +---+---+ =================> +---+---+ | | 438 | | 3. Receive Data | +-R | 439 +---------------+ +---------------+ 441 If a relay receives an explicit join from the native infrastructure, 442 for a given (source, group) pair where the source address belongs to 443 the AMT Subnet Prefix, then the relay will periodically (using the 444 rules specified in Section 4.1.2) encapsulate membership updates for 445 the group to the gateway. The gateway must keep state per relay from 446 which membership reports have been sent, and forward multicast 447 traffic from the site to all relays from which membership reports 448 have been received. The choice of whether this state and replication 449 is done at the link-layer (i.e., by the tunnel interface) or at the 450 network-layer is implementation dependent. 452 If there are multiple relays present, this ensures that data from the 453 AMT site is received via the closest relay to the receiver. This is 454 necessary when the routers in the native multicast infrastructure 455 employ Reverse-Path Forwarding (RPF) checks against the source 456 address, such as occurs when [PIMSM] is used by the multicast 457 infrastructure. 459 The solution above will scale to an arbitrary number of relays, as 460 long at the number of relays requiring multicast traffic from a given 461 AMT site remains reasonable enough to not overly burden the site's 462 gateway. 464 4.2.2 Supporting Site-Site Multicast 466 Internet 467 +---------------+ +---------------+ 468 | AMT Site | 2. 3-way Membership | AMT Site | 469 | | Handshake | | 470 | +---+---+ <================= +---+---+ 1. Join | 471 | |Gateway| |Gateway|<-----+ | 472 | +---+---+ =================> +---+---+ | | 473 | | 3. Receive Data | +-R | 474 +---------------+ +---------------+ 476 Since we require gateways to accept membership reports, as described 477 above, it is also possible to support multicast among AMT sites, 478 without requiring assistance from any relays. 480 When a gateway wants to join a given (source, group) pair, where the 481 source address belongs to the AMT Subnet Prefix, then the gateway 482 will periodically unicast encapsulate an IGMPv3/MLDv2 [RFC3376] 483 [RFC3810] Report directly to the site gateway for the source. 485 We note that this can result in a significant amount of state at a 486 site gateway sourcing multicast to a large number of other AMT sites. 487 However, it is expected that this is not unreasonable for two 488 reasons. First, the gateway does not have native multicast 489 connectivity, and as a result is likely doing unicast replication at 490 present. The amount of state is thus the same as what such a site 491 already deals with. Secondly, any site expecting to source traffic 492 to a large number of sites could get a point-to-point tunnel to the 493 native multicast infrastructure, and use that instead of AMT. 495 5. Message Formats 497 5.1 AMT Relay Discovery 499 The AMT Relay Discovery message is a UDP packet sent from the AMT 500 gateway unicast address to the AMT relay anycast address to discover 501 the unicast address of an AMT relay. 503 The UDP source port is uniquely selected by the local host operating 504 system. The UDP destination port is the IANA reserved AMT port 505 number. 507 The payload of the UDP packet contains the following fields. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type=0x1 | Reserved | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Discovery Nonce | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Fields: 519 5.1.1 Type 521 The type of the message. 523 5.1.2 Reserved 525 A 24-bit reserved field. Sent as 0, ignored on receipt. 527 5.1.3 Discovery Nonce 529 A 32-bit random value generated by the gateway and replayed by the 530 relay. 532 5.2 AMT Relay Advertisement 534 The AMT Relay Advertisement message is a UDP packet sent from the AMT 535 relay anycast address to the source of the discovery message. 537 The UDP source port is the IANA reserved AMT port number and the UDP 538 destination port is the source port received in the Discovery 539 message. 541 The payload of the UDP packet contains the following fields. 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type=0x2 | Reserved | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Discovery Nonce | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Relay Address | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Fields: 555 5.2.1 Type 557 The type of the message. 559 5.2.2 Reserved 561 A 24-bit reserved field. Sent as 0, ignored on receipt. 563 5.2.3 Discovery Nonce 565 A 32-bit random value generated by the gateway and replayed by the 566 relay. 568 5.2.4 Relay Address 570 The unicast IPv4 or IPv6 address of the AMT relay. The family can be 571 determined by the length of the Advertisement. 573 5.3 AMT Request 575 A Request packet is sent to begin a 3-way handshake for sending an 576 IGMP/MLD Membership/Listener Report or Leave/Done. It can be sent 577 from a gateway to a relay, from a gateway to another gateway, or from 578 a relay to a gateway. 580 It is sent from the originator's unique unicast address to the 581 respondents' unique unicast address. 583 The UDP source port is uniquely selected by the local host operating 584 system. It can be different for each Request and different from the 585 source port used in Discovery messages but does not have to be. The 586 UDP destination port is the IANA reserved AMT port number. 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type=0x3 | Reserved | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Request Nonce | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Fields: 598 5.3.1 Type 600 The type of the message. 602 5.3.2 Reserved 604 A 24-bit reserved field. Sent as 0, ignored on receipt. 606 5.3.3 Request Nonce 608 A 32-bit identifier used to distinguish this request. 610 5.4 AMT Membership Query 612 An AMT Membership Query packet is sent from the relay back to the 613 originator to solicit an AMT Membership Update while confirming the 614 source of the original request. It contains a relay Message 615 Authentication Code (MAC) that is a cryptographic hash of a private 616 secret, the originators address, and the request nonce. 618 It is sent from the destination address received in the Request to 619 the source address received in the Request. 621 The UDP source port is the IANA reserved AMT port number and the UDP 622 destination port is the source port received in the Request message. 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Type=0x4 | Reserved | Response MAC | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Response MAC (continued) | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Request Nonce | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Fields: 635 5.4.1 Type 637 The type of the message. 639 5.4.2 Reserved 641 A 8-bit reserved field. Sent as 0, ignored on receipt. 643 5.4.3 Response MAC 645 A 48-bit hash generated by the respondent and sent to the originator 646 for inclusion in the AMT Membership Update. The algorithm used for 647 this is chosen by the respondent. One algorithm that could be used 648 is HMAC-MD5-48 [RFC2104]. 650 5.4.4 Request Nonce 652 A 32-bit identifier used to distinguish this request echoed back to 653 the originator. 655 5.5 AMT Membership Update 657 An AMT Membership Update is sent from the originator to the 658 respondent containing the original IGMP/MLD Membership/Listener 659 Report or Leave/Done received over the AMT pseudo-interface. It 660 echoes the Response MAC received in the AMT Membership Query so the 661 respondent can verify return routability to the originator. 663 It is sent from the destination address received in the Query to the 664 source address received in the Query which should both be the same as 665 the original Request. 667 The UDP source and destination port numbers should be the same ones 668 sent in the original Request. 670 0 1 2 3 671 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 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Type=0x5 | Reserved | Response MAC | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Response MAC (continued) | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Request Nonce | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | IGMP/MLD Message | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | ... | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Fields: 686 5.5.1 Type 688 The type of the message. 690 5.5.2 Reserved 692 A 8-bit reserved field. Sent as 0, ignored on receipt. 694 5.5.3 Response MAC 696 The 48-bit MAC received in the Membership Query and echoed back in 697 the Membership Update. 699 5.5.4 Request Nonce 701 A 32-bit identifier used to distinguish this request. 703 5.6 AMT Multicast Data 705 The AMT Data message is a UDP packet encapsulating the data requested 706 by the originator based on a previous AMT Membership Update message. 708 It is sent from the unicast destination address of the Membership 709 update to the source address of the Membership Update. 711 The UDP source and destination port numbers should be the same ones 712 sent in the original Query. 714 The payload of the UDP packet contains the following fields. 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Type=0x6 | Reserved | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Multicast Data | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | ... | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 Fields: 728 5.6.1 Type 730 The type of the message. 732 5.6.2 Reserved 734 A 24-bit reserved field. Sent as 0, ignored on receipt. 736 5.6.3 UDP Multicast Data 738 The original Multicast UDP data packet that is being replicated by 739 the relay to the gateways. 741 6. AMT Gateway Details 743 This section details the behavior of an AMT Gateway, which may be a 744 router serving an AMT site, or the site may consist of a single host, 745 serving as its own gateway. 747 6.1 At Startup Time 749 At startup time, the AMT gateway will bring up an AMT pseudo- 750 interface, to be used for encapsulation. The gateway will then send 751 an AMT Relay Discovery message to the AMT Relay Anycast Address, and 752 note the unicast address (which is treated as a link-layer address to 753 the encapsulation interface) from the AMT Relay Advertisement 754 message. This discovery SHOULD be done periodically (e.g., once a 755 day) to re-resolve the unicast address of a close relay. The gateway 756 also SHOULD initialize a timer used to send periodic membership 757 reports to a random value from the interval [0, [Query Interval]] 758 before sending the first periodic report, in order to prevent startup 759 synchronization (e.g., after a power outage). 761 If the gateway is serving as a local router, it SHOULD also function 762 as an IGMP/MLD Proxy, as described in [I-D.ietf-magma-igmp-proxy], 763 with its IGMP/MLD host-mode interface being the AMT pseudo-interface. 764 This enables it to translate group memberships on its downstream 765 interfaces into IGMP/MLD Reports. Hosts receiving multicast packets 766 through a gateway should ensure that their M-RIB accepts multicast 767 packets from the gateway for the sources it is joining. 769 Also, if a shared tree routing protocol is used inside the AMT site, 770 each tree-root must be a gateway, e.g., in PIM-SM each RP must be a 771 gateway. 773 Finally, to support sourcing traffic to SSM groups by a gateway with 774 a global unicast address, the AMT Subnet Prefix is treated as the 775 subnet prefix of the AMT pseudo-interface, and an anycast address is 776 added on the interface. This anycast address is formed by 777 concatenating the AMT Subnet Prefix followed by the high bits of the 778 gateway's global unicast address. For example, if IANA assigns the 779 IPv4 prefix x.y/16 as the AMT Subnet Prefix, and the gateway has 780 global unicast address a.b.c.d, then the AMT Gateway's Anycast 781 Address will be x.y.a.b. Note that multiple gateways might end up 782 with the same anycast address assigned to their pseudo-interfaces. 784 6.2 Joining Groups with MBone Sources 786 The IGMP/MLD protocol usually operates by having the Querier 787 multicast an IGMP/MLD Query message on the link. This behavior does 788 not work on NBMA links which do not support multicast. Since the set 789 of gateways is typically unknown to the relay (and potentially quite 790 large), unicasting the queries is also impractical. The following 791 behavior is used instead. 793 Applications residing in a gateway should join groups on the AMT 794 pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be 795 sent over that interface. When UDP encapsulating the membership 796 reports (and in fact any other messages, unless specified otherwise 797 in this document), the destination address in the outer IP header is 798 the relay's unicast address. Robustness is provided by the 799 underlying IGMP/MLD protocol messages sent on the AMT pseudo- 800 interface. In other words, the gateway does not need to retransmit 801 IGMP/MLD Membership/Listener Reports and Leave/Done messages received 802 on the pseudo-interface since IGMP/MLD will already do this. The 803 gateway simply needs to encapsulate each IGMP/MLD Membership/Listener 804 Report and Leave/Done message it receives. 806 However, since periodic IGMP/MLD Membership/Listener Reports are sent 807 in response to IGMP/MLD Queries, some mechanism to trigger periodic 808 Membership/Listener Reports and Leave/Done messages are necessary. 809 This can be achieved in any implementation-specific manner. Some 810 possibilities include: 812 1. The AMT pseudo-interface might periodically manufacture IGMPv3/ 813 MLDv2 Queries as if they had been received from an IGMP/MLD 814 Querier, and deliver them to the IP layer, after which normal 815 IGMP/MLD behavior will cause the appropriate reports to be sent. 817 2. The IGMP/MLD module itself might provide an option to operate in 818 periodic mode on specific interfaces. 820 If the gateway is behind a firewall device, the firewall may require 821 the gateway to periodically refresh the UDP state in the firewall at 822 a shorter interval than the standard IGMP/MLD Query interval. 823 Therefore, this IGMP/MLD Query interval should be configurable to 824 ensure the firewall does not revert to blocking the UDP encapsulated 825 multicast data packets. 827 6.3 Responding to Relay Changes 829 When a gateway determines that its current relay is unreachable 830 (e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the 831 relay's unicast address), it may need to repeat relay address 832 discovery. However, care should be taken not to abandon the current 833 relay too quickly due to transient network conditions. 835 6.4 Creating SSM groups 837 When a gateway wants to create an SSM group (i.e., in 232/8) for 838 which it can source traffic, the remaining 24 bits MUST be generated 839 as described below. ([SSM] states that "the policy for allocating 840 these bits is strictly locally determined at the sender's host.") 842 When the gateway determined its AMT Gateway Anycast Address as 843 described above, it used the high bits of its global unicast address. 844 The remaining bits of its global unicast address are appended to the 845 232/8 prefix, and any spare bits may be allocated using any policy 846 (again, strictly locally determined at the sender's host). 848 For example, if the IPv4 AMT Subnet Prefix is x.y/16, and the device 849 has global unicast address a.b.c.d, then it MUST allocate IPv4 SSM 850 groups in the range 232.c.d/24. 852 6.5 Joining SSM Groups with AMT Sources 854 An IGMPv3/MLDv2 Report for a given (source, group) pair MAY be 855 encapsulated directly to the source, when the source address belongs 856 to the AMT Subnet Prefix. 858 The "link-layer" address to use as the destination address in the 859 outer IP header is obtained as follows. The source address in the 860 inclusion list of the IGMPv3/MLDv2 report will be an AMT Gateway 861 Anycast Address with the high bits of the address, and the remaining 862 bits will be in the middle of the group address. 864 For example, if the IPv4 AMT Subnet Prefix is x.y/16, and the IGMPv3 865 Report is for (x.y.a.b, 232.c.d.e), then the "link layer" IPv4 866 destination address used for encapsulation is a.b.c.d. 868 6.6 Receiving IGMPv3/MLDv2 Reports at the Gateway 870 When an AMT Request is received by the gateway, it follows the same 871 3-way handshake procedure a relay would follow if it received the AMT 872 Request. It generates a MAC and responds with an AMT Membership 873 Query. When the AMT Membership Update is received, it verifies the 874 MAC and then processes the IGMP/MLD Membership/Listener Report or 875 Leave/Done. 877 At the gateway, the IGMP/MLD packet should be an IGMPv3/MLDv2 source 878 specific (S,G) join or leave. 880 If S is not the AMT Gateway Anycast Address, the packet is silently 881 discarded. If G does not contain the low bits of the global unicast 882 address (as described above), the packet is also silently discarded. 884 The gateway adds the source address (from the outer IP header) and 885 UDP port of the report to a membership list for G. Maintaining this 886 membership list may be done in any implementation-dependent manner. 887 For example, it might be maintained by the "link-layer" inside the 888 AMT pseudo-interface, making it invisible to the normal IGMP/MLD 889 module. 891 6.7 Sending data to SSM groups 893 When multicast packets are sent on the AMT pseudo-interface, they are 894 encapsulated as follows. If the group address is not an SSM group, 895 then the packet is silently discarded (this memo does not currently 896 provide a way to send to non-SSM groups). 898 If the group address is an SSM group, then the packet is unicast 899 encapsulated to each remote node from which the gateway has received 900 an IGMPv3/MLDv2 report for the packet's (source, group) pair. 902 7. Relay Router Details 904 7.1 At Startup time 906 At startup time, the relay router will bring up an NBMA-style AMT 907 pseudo-interface. It shall also add the AMT Relay Anycast Address on 908 some interface. 910 The relay router shall then advertise the AMT Relay Anycast Prefix 911 into the unicast-only Internet, as if it were a connection to an 912 external network. When the advertisement is done using BGP, the AS 913 path leading to the AMT Relay Anycast Prefix shall include the 914 identifier of the local AS and the AMT Unicast Autonomous System ID. 916 The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo- 917 interface, except that it shall not multicast Queries (this might be 918 done, for example, by having the AMT pseudo-device drop them, or by 919 having the IGMP/MLD module not send them in the first place). 921 Finally, to support sourcing SSM traffic from AMT sites, the AMT 922 Subnet Prefix is assigned to the AMT pseudo-interface, and the AMT 923 Subnet Prefix is injected into the M-RIB of MBGP. 925 7.2 Receiving Relay Discovery messages sent to the Anycast Address 927 When a relay receives an AMT Relay Discovery message directed to the 928 AMT Relay Anycast Address, it should respond with an AMT Relay 929 Advertisement containing its unicast address. The source and 930 destination addresses of the advertisement should be the same as the 931 destination and source addresses of the discovery message 932 respectively. Further, the nonce in the discovery message MUST be 933 copied into the advertisement message. 935 7.3 Receiving Membership Updates from AMT Gateways 937 The relay operates passively, sending no Queries but simply tracking 938 membership information according to Reports and Leave messages, as a 939 router normally would. In addition, the relay must also do explicit 940 membership tracking, as to which gateways on the AMT pseudo- 941 interface have joined which groups. Once an AMT Membership Update 942 has been successfully received, it updates the forwarding state for 943 the appropriate group and source (if provided). When data arrives 944 for that group, the traffic must be encapsulated to each gateway 945 which has joined that group. 947 The explicit membership tracking and unicast replication may be done 948 in any implementation-specific manner. Some examples are: 950 1. The AMT pseudo-device driver might track the group information 951 and perform the replication at the "link-layer", with no changes 952 to a pre-existing IGMP/MLD module. 954 2. The IGMP/MLD module might have native support for explicit 955 membership tracking, especially if it supports other NBMA-style 956 interfaces. 958 7.4 Receiving (S,G) Joins from the Native Side, for AMT Sources 960 The relay encapsulates an IGMPv3/MLDv2 report to the AMT source as 961 described above in Section 4.1.2. 963 8. IANA Considerations 965 The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated 966 to the public AMT Relays to advertise to the native multicast 967 backbone. The prefix length should be determined by the IANA; the 968 prefix should be large enough to guarantee advertisement in the 969 default-free BGP networks. For IPv4, a prefix length of 16 will meet 970 this requirement. For IPv6, a prefix length of 64 will meet this 971 requirement. This is a one time effort and there will be no need for 972 any recurring assignment after this stage. 974 The IANA should also allocate an Autonomous System ID which can be 975 used as a pseudo-AS when advertising routes to the above prefix. 977 It should also be noted that this prefix length directly affects the 978 number of groups available to be created by the AMT gateway: a length 979 of 16 gives 256 groups, and a length of 8 gives 65536 groups. For 980 diagnostic purposes, it is helpful to have a prefix length which is a 981 multiple of 8, although this is not required. 983 IANA has allocated UDP reserved port number 2268 for AMT 984 encapsulation. 986 9. Security Considerations 988 The anycast technique introduces a risk that a rogue router or a 989 rogue AS could introduce a bogus route to the AMT Relay Anycast 990 Prefix, and thus divert the traffic. Network managers have to 991 guarantee the integrity of their routing to the AMT Relay anycast 992 prefix in much the same way that they guarantee the integrity of all 993 other routes. 995 Within the native MBGP infrastructure, there is a risk that a rogue 996 router or a rogue AS could inject a false route to the AMT Subnet 997 Prefix, and thus divert joins and cause RPF failures of multicast 998 traffic. As the AMT Subnet Prefix will be advertised by multiple 999 entities, guaranteeing the integrity of this shared MBGP prefix is 1000 much more challenging than verifying the correctness of a regular 1001 unicast advertisement. To mitigate this threat, routing operators 1002 should configure the BGP sessions to filter out any more specific 1003 advertisements for the AMT Subnet Prefix. 1005 Gateways and relays will accept and decapsulate multicast traffic 1006 from any source from which regular unicast traffic is accepted. If 1007 this is for any reason felt to be a security risk, then additional 1008 source address based packet filtering MUST be applied: 1010 1. To prevent a rogue sender (that can't do traditional spoofing 1011 because of e.g. access lists deployed by its ISP) from making use 1012 of AMT to send packets to an SSM tree, a relay that receives an 1013 encapsulated multicast packet MUST discard the multicast packet 1014 if the IPv4 source address in the outer header is not composed of 1015 the last 2 bytes of the source address and the 2 middle bytes of 1016 the destination address of the inner header (i.e., a.b.c.d must 1017 be composed of the a.b of x.y.a.b and the c.d of 232.c.d.e). 1019 2. A gateway MUST discard encapsulated multicast packets if the 1020 source address in the outer header is not the address to which 1021 the encapsulated join message was sent. An AMT Gateway that 1022 receives an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the 1023 message if the IPv4 destination address in the outer header is 1024 not composed of the last 2 bytes of S and the 2 middle bytes of G 1025 (i.e. the destination address a.b.c.d must be composed of the a.b 1026 of the multicast source x.y.a.b and the c.d of the multicast 1027 group 232.c.d.e). 1029 10. Contributors 1031 The following people provided significant contributions to earlier 1032 versions of this draft. 1034 Dirk Ooms 1035 OneSparrow 1036 Belegstraat 13; 2018 Antwerp; Belgium 1037 EMail: dirk@onesparrow.com 1039 11. Acknowledgments 1041 Most of the mechanisms described in this document are based on 1042 similar work done by the NGTrans WG for obtaining automatic IPv6 1043 connectivity without explicit tunnels ("6to4"). Tony Ballardie 1044 provided helpful discussion that inspired this document. 1046 12. References 1048 12.1 Normative References 1050 [I-D.ietf-magma-igmp-proxy] 1051 Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/ 1052 MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", 1053 draft-ietf-magma-igmp-proxy-06 (work in progress), 1054 April 2004. 1056 [I-D.ietf-ssm-arch] 1057 Holbrook, H. and B. Cain, "Source-Specific Multicast for 1058 IP", draft-ietf-ssm-arch-07 (work in progress), 1059 October 2005. 1061 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1062 RFC 792, September 1981. 1064 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1065 Thyagarajan, "Internet Group Management Protocol, Version 1066 3", RFC 3376, October 2002. 1068 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1069 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1071 12.2 Informative References 1073 [I-D.ietf-pim-sm-v2-new] 1074 Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1075 "Protocol Independent Multicast - Sparse Mode PIM-SM): 1076 Protocol Specification (Revised)", 1077 draft-ietf-pim-sm-v2-new-11 (work in progress), 1078 October 2004. 1080 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1081 RFC 1112, August 1989. 1083 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1084 Hashing for Message Authentication", RFC 2104, 1085 February 1997. 1087 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1088 Requirement Levels", BCP 14, RFC 2119, March 1997. 1090 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1091 Tunnel Broker", RFC 3053, January 2001. 1093 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1094 via IPv4 Clouds", RFC 3056, February 2001. 1096 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1097 RFC 3068, June 2001. 1099 Authors' Addresses 1101 Dave Thaler 1102 Microsoft Corporation 1103 One Microsoft Way 1104 Redmond, WA 98052-6399 1105 USA 1107 Phone: +1 425 703 8835 1108 Email: dthaler@microsoft.com 1110 Mohit Talwar 1111 Microsoft Corporation 1112 One Microsoft Way 1113 Redmond, WA 98052-6399 1114 USA 1116 Phone: +1 425 705 3131 1117 Email: mohitt@microsoft.com 1119 Amit Aggarwal 1120 Microsoft Corporation 1121 One Microsoft Way 1122 Redmond, WA 98052-6399 1123 USA 1125 Phone: +1 425 706 0593 1126 Email: amitag@microsoft.com 1128 Lorenzo Vicisano 1129 Cisco Systems 1130 170 West Tasman Dr. 1131 San Jose, CA 95134 1132 USA 1134 Phone: +1 408 525 2530 1135 Email: lorenzo@cisco.com 1136 Tom Pusateri 1137 Juniper Networks 1138 1194 North Mathilda Avenue 1139 Sunnyvale, CA 94089 1140 USA 1142 Phone: +1 408 745 2000 1143 Email: pusateri@juniper.net 1145 Intellectual Property Statement 1147 The IETF takes no position regarding the validity or scope of any 1148 Intellectual Property Rights or other rights that might be claimed to 1149 pertain to the implementation or use of the technology described in 1150 this document or the extent to which any license under such rights 1151 might or might not be available; nor does it represent that it has 1152 made any independent effort to identify any such rights. Information 1153 on the procedures with respect to rights in RFC documents can be 1154 found in BCP 78 and BCP 79. 1156 Copies of IPR disclosures made to the IETF Secretariat and any 1157 assurances of licenses to be made available, or the result of an 1158 attempt made to obtain a general license or permission for the use of 1159 such proprietary rights by implementers or users of this 1160 specification can be obtained from the IETF on-line IPR repository at 1161 http://www.ietf.org/ipr. 1163 The IETF invites any interested party to bring to its attention any 1164 copyrights, patents or patent applications, or other proprietary 1165 rights that may cover technology that may be required to implement 1166 this standard. Please address the information to the IETF at 1167 ietf-ipr@ietf.org. 1169 Disclaimer of Validity 1171 This document and the information contained herein are provided on an 1172 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1173 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1174 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1175 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1176 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1177 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1179 Copyright Statement 1181 Copyright (C) The Internet Society (2005). This document is subject 1182 to the rights, licenses and restrictions contained in BCP 78, and 1183 except as set forth therein, the authors retain all their rights. 1185 Acknowledgment 1187 Funding for the RFC Editor function is currently provided by the 1188 Internet Society.