--- 1/draft-ietf-mboned-auto-multicast-07.txt 2007-10-08 19:12:13.000000000 +0200 +++ 2/draft-ietf-mboned-auto-multicast-08.txt 2007-10-08 19:12:13.000000000 +0200 @@ -1,23 +1,23 @@ Network Working Group D. Thaler Internet-Draft M. Talwar -Expires: May 20, 2007 A. Aggarwal - Microsoft Corporation +Intended status: Standards Track A. Aggarwal +Expires: April 5, 2008 Microsoft Corporation L. Vicisano Cisco Systems T. Pusateri !j - November 16, 2006 + October 3, 2007 Automatic IP Multicast Without Explicit Tunnels (AMT) - draft-ietf-mboned-auto-multicast-07 + draft-ietf-mboned-auto-multicast-08 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -28,100 +28,100 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 20, 2007. + This Internet-Draft will expire on April 5, 2008. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). Abstract Automatic Multicast Tunneling (AMT) allows multicast communication amongst isolated multicast-enabled sites or hosts, attached to a network which has no native multicast support. It also enables them to exchange multicast traffic with the native multicast infrastructure and does not require any manual configuration. AMT uses an encapsulation interface so that no changes to a host stack or applications are required, all protocols (not just UDP) are handled, and there is no additional overhead in core routers. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 - 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 7 - 4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.4. AMT Relay Router . . . . . . . . . . . . . . . . . . . . . 7 - 4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 8 - 4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 8 - 4.7. AMT Subnet Anycast Prefix . . . . . . . . . . . . . . . . 8 - 4.8. AMT Gateway Anycast Address . . . . . . . . . . . . . . . 8 - 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . 9 - 5.1.1. Scalability Considerations . . . . . . . . . . . . . . 10 - 5.1.2. Spoofing Considerations . . . . . . . . . . . . . . . 10 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7 + 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 8 + 4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.4. AMT Relay Router . . . . . . . . . . . . . . . . . . . . . 8 + 4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 9 + 4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 9 + 4.7. AMT Subnet Anycast Prefix . . . . . . . . . . . . . . . . 9 + 4.8. AMT Gateway Anycast Address . . . . . . . . . . . . . . . 9 + 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . 10 + 5.1.1. Scalability Considerations . . . . . . . . . . . . . . 11 + 5.1.2. Spoofing Considerations . . . . . . . . . . . . . . . 11 5.1.3. Protocol Sequence for a Gateway Joining SSM - Receivers to a Relay . . . . . . . . . . . . . . . . . 11 - 5.2. Sourcing Multicast from an AMT site . . . . . . . . . . . 13 - 5.2.1. Supporting Site-MBone Multicast . . . . . . . . . . . 13 - 5.2.2. Supporting Site-Site Multicast . . . . . . . . . . . . 14 - 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 16 - 6.1.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.1.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.1.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 16 - 6.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 16 - 6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 17 - 6.2.4. Relay Address . . . . . . . . . . . . . . . . . . . . 17 - 6.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 18 - 6.3.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 18 - 6.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . 18 - 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 19 - 6.4.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 19 - 6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19 - 6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19 - 6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 20 - 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20 - 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20 - 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21 - 6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21 - 6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21 - 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 21 - 6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22 - 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 23 - 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 23 - 7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 23 - 7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 24 - 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 25 - 7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 26 - 7.6. Receiving AMT Membership Updates by the Gateway . . . . . 26 - 7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 26 + Receivers to a Relay . . . . . . . . . . . . . . . . . 12 + 5.2. Sourcing Multicast from an AMT site . . . . . . . . . . . 14 + 5.2.1. Supporting Site-MBone Multicast . . . . . . . . . . . 15 + 5.2.2. Supporting Site-Site Multicast . . . . . . . . . . . . 16 + 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 + 6.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 17 + 6.1.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6.1.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17 + 6.1.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 17 + 6.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 17 + 6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 18 + 6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 18 + 6.2.4. Relay Address . . . . . . . . . . . . . . . . . . . . 18 + 6.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 18 + 6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.3.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 19 + 6.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . 19 + 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20 + 6.4.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20 + 6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 20 + 6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 20 + 6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 21 + 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22 + 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 22 + 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 22 + 6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 22 + 6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 22 + 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23 + 6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 23 + 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 24 + 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 24 + 7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 24 + 7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 26 + 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 26 + 7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 27 + 7.6. Receiving AMT Membership Updates by the Gateway . . . . . 27 + 7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 27 8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 28 8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 28 8.2. Receiving Relay Discovery messages sent to the Anycast Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.3. Receiving Membership Updates from AMT Gateways . . . . . . 28 8.4. Receiving (S,G) Joins from the Native Side, for AMT Sources . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 30 9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 @@ -152,25 +152,25 @@ small and concentrated changes to the network infrastructure, and no changes at all to user applications or to the socket API of end- nodes' operating systems. The protocol introduced in this specification can be deployed in a few strategically-placed network nodes and in user-installable software modules (pseudo device drivers and/or user-mode daemons) that reside underneath the socket API of end-nodes' operating systems. This mechanism is very similar to that used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6 connectivity. - Effectively, AMT treats the unicast-only internetwork as a large non- - broadcast multi-access (NBMA) link layer, over which we require the - ability to multicast. To do this, multicast packets being sent to or - from a site must be encapsulated in unicast packets. If the group - has members in multiple sites, AMT encapsulation of the same + Effectively, AMT treats the unicast-only inter-network as a large + non-broadcast multi-access (NBMA) link layer, over which we require + the ability to multicast. To do this, multicast packets being sent + to or from a site must be encapsulated in unicast packets. If the + group has members in multiple sites, AMT encapsulation of the same multicast packet will take place multiple times by necessity. 2. Applicability AMT is not a substitute for native multicast or a statically configured multicast tunnel for high traffic flow. Unicast replication is required to reach multiple receivers that are not part of the native multicast infrastructure. Unicast replication is also required by non-native sources to different parts of the native multicast infrastructure. However, this is no worse than regular @@ -239,21 +239,21 @@ A multicast-enabled network not connected to the multicast backbone served by an AMT Gateway. It could also be a stand- alone AMT Gateway. 4.4. AMT Relay Router A multicast router configured to support transit routing between AMT Sites and the native multicast backbone infrastructure. The relay router has one or more interfaces connected to the native multicast infrastructure, zero or more interfaces connected to the non- - multicast capable internetwork, and an AMT pseudo-interface. It is + multicast capable inter-network, and an AMT pseudo-interface. It is simply referred to in this document as a "relay". As with [RFC3056], we assume that normal multicast routers do not want to be tunnel endpoints (especially if this results in high fan out), and similarly that service providers do not want encapsulation to arbitrary routers. Instead, we assume that special-purpose routers will be deployed that are suitable for serving as relays. 4.5. AMT Relay Anycast Prefix @@ -293,20 +293,22 @@ Internet +---------------+ +---------------+ | AMT Site | 2. 3-way Membership | MBone | | | Handshake | | | 1. Join +---+---+ =================> +---+---+ | | +---->|Gateway| | Relay | | | | +---+---+ <================= +---+---+ | | R-+ | 3. Receive Data | | +---------------+ +---------------+ + Receiving Multicast in an AMT Site + AMT relays and gateways cooperate to transmit multicast traffic sourced within the native multicast infrastructure to AMT sites: relays receive the traffic natively and unicast-encapsulate it to gateways; gateways decapsulate the traffic and possibly forward it into the AMT site. Each gateway has an AMT pseudo-interface that serves as a default multicast route. Requests to join a multicast session are sent to this interface and encapsulated to a particular relay reachable across the unicast-only infrastructure. @@ -347,21 +349,21 @@ It is possible that millions of hosts will enable AMT gateway functionality and so an important design goal is not to create gateway state in each relay until the gateway joins a multicast group. But even the requirement that a relay keep group state per gateway that has joined a group introduces potential scalability concerns. Scalability of AMT can be achieved by adding more relays, and using an appropriate relay discovery mechanism for gateways to discover relays. The solution we adopt is to assign addresses in anycast - fashion to relays [RFC1546], [RFC2373]. However, simply sending + fashion to relays [RFC1546], [RFC4291]. However, simply sending periodic membership reports to an anycast address can cause duplicates. Specifically, if routing changes such that a different relay receives a periodic membership report, both the new and old relays will encapsulate data to the AMT site until the old relay's state times out. This is obviously undesirable. Instead, we use the anycast address merely to find the unicast address of a relay to which membership reports are sent. Since adding another relay has the result of adding another independent NBMA link, this allows the gateways to be spread out @@ -393,55 +395,68 @@ the respondent finalizing the 3-way handshake. Upon reception, the respondent can recalculate the MAC based on the source IP address, the source UDP port, the request nonce, and the local secret. The IGMP/MLD message is only accepted if the received MAC matches the calculated MAC. The local secret never has to be shared with the other side. It is only used to verify return routability of the originator. + Since the same Request Nonce and source IP address can be re-used, + the receiver SHOULD change its secret key at least once per hour. + However, AMT Membership updates received with the previous secret + MUST be accepted for up to the IGMP/MLD Query Interval. + 5.1.3. Protocol Sequence for a Gateway Joining SSM Receivers to a Relay This description assumes the Gateway can be a host joining as a receiver or a network device acting as a Gateway when a directly connected host joins as a receiver. o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1). - o Gateway receives report has no tunnel state with a Relay so it - originates an AMT Relay Discovery message addressed to the Anycast - Relay IP address. + o Gateway receives report. If it has no tunnel state with a Relay, + it originates an AMT Relay Discovery message addressed to the + Anycast Relay IP address. The AMT Relay Discovery message can be + sent on demand if no relay is known at this time or at startup and + be periodically refreshed. o The closest Relay topologically receives the AMT Relay Discovery message and returns the nonce from the Discovery in an AMT Relay Advertisement message so the Gateway can learn of the Relay's unique IP address. o When the Gateway receives the AMT Relay Advertisement message, it now has an address to use for all subsequent (S,G) entries it will join on behalf of attached receivers (or itself). - o The Gateway now sends an AMT Request message to the Relay's unique - IP address to begin the process of joining the (S,G). + o If the gateway has a valid Response MAC from a previous AMT Query + message, it can send an AMT Membership Update message as described + below. Otherwise, the Gateway sends an AMT Request message to the + Relay's unique IP address to begin the process of joining the + (S,G). The gateway also SHOULD initialize a timer used to send + periodic Requests to a random value from the interval [0, [Query + Interval]] before sending the first periodic report, in order to + prevent startup synchronization. o The Relay responds to the AMT Request message by returning the nonce from the Request in a AMT Query message. The Query message contains an IGMP/MLD QUERY indicating how often the Gateway should repeat AMT Request messages so the (S,G) state can stay refreshed in the Relay. The Query message also includes an opaque security code which is generated locally (with no external coordination). o When the Gateway receives the AMT Query message it responds by copying the security code from the AMT Query message into a AMT - Membership Update message. In the Update message contains (S1,G1) - in an IGMPv3/MLDv2 formatted packet with an IP header. The nonce + Membership Update message. The Update message contains (S1,G1) in + an IGMPv3/MLDv2 formatted packet with an IP header. The nonce from the AMT Request is also included in the AMT Membership Update message. o When the Relay receives the AMT Membership Update, it will add the tunnel to the Gateway in it's outgoing interface list for it's (S1,G1) entry stored in the multicast routing table. If the (S1,G1) entry was created do to this interaction, the multicast routing protocol running on the Relay will trigger a Join message towards source S1 to build a native multicast tree in the native multicast infrastructure. @@ -458,24 +473,26 @@ associated with the tunnel to the Relay it had attached to, and forward the packet to the outgoing interfaces joined by any attached receiver hosts (or deliver the packet to the application when the Gateway is the receiver). o If later (S2,G2) is joined by a receiver, a 3-way handshake of Request/ Query/Update occurs for this entry. The Discovery/ Advertisement exchange is not required. o To keep the state for (S1,G1) and (S2,G2) alive in the Relay, the - Gateway will send periodic AMT Request messages which cause Query - messages to be returned. And in response to the Query message all - joined state in the Gateway is packed in the fewest number of AMT - Membership Update messages. + Gateway will send periodic AMT Membership Updates. The Membership + Update can be sent directly if the sender has a valid nonce from a + previous Request. If not, an AMT Request messages should be sent + to solicit a Query Message. When sending a periodic state + refresh, all joined state in the Gateway is packed in the fewest + number of AMT Membership Update messages. o When the Gateway leaves all (S,G) entries, the Relay can free resources associated with the tunnel. It is assumed that when the Gateway would want to join an (S,G) again, it would start the Discovery/Advertisement tunnel establishment process over again. This same procedure would be used for receivers who operate in Any- Source Multicast (ASM) mode. 5.2. Sourcing Multicast from an AMT site @@ -514,20 +531,22 @@ Internet +---------------+ +---------------+ | AMT Site | 2. 3-way Membership | MBone | | | Handshake | | | +---+---+ <================= +---+---+ 1. Join | | |Gateway| | Relay |<-----+ | | +---+---+ =================> +---+---+ | | | | 3. Receive Data | +-R | +---------------+ +---------------+ + Site-MBone Multicast + If a relay receives an explicit join from the native infrastructure, for a given (source, group) pair where the source address belongs to the AMT Subnet Anycast Prefix, then the relay will periodically (using the rules specified in Section 5.1.2) encapsulate membership updates for the group to the gateway. The gateway must keep state per relay from which membership reports have been sent, and forward multicast traffic from the site to all relays from which membership reports have been received. The choice of whether this state and replication is done at the link-layer (i.e., by the tunnel interface) or at the network-layer is implementation dependent. @@ -556,20 +575,22 @@ Internet +---------------+ +---------------+ | AMT Site | 2. 3-way Membership | AMT Site | | | Handshake | | | +---+---+ <================= +---+---+ 1. Join | | |Gateway| |Gateway|<-----+ | | +---+---+ =================> +---+---+ | | | | 3. Receive Data | +-R | +---------------+ +---------------+ + Site-Site Multicast + Since we require gateways to accept membership reports, as described above, it is also possible to support multicast among AMT sites, without requiring assistance from any relays. When a gateway wants to join a given (source, group) pair, where the source address belongs to the AMT Subnet Anycast Prefix, then the gateway will periodically unicast encapsulate an IGMPv3/MLDv2 Report [RFC3376], [RFC3810] (including IP Header) directly to the site gateway for the source. @@ -598,21 +619,21 @@ The payload of the UDP packet contains the following fields. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Fields: + AMT Relay Discovery 6.1.1. Type The type of the message. 6.1.2. Reserved A 24-bit reserved field. Sent as 0, ignored on receipt. 6.1.3. Discovery Nonce @@ -634,21 +655,21 @@ 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x2 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Relay Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Fields: + AMT Relay Advertisement 6.2.1. Type The type of the message. 6.2.2. Reserved A 24-bit reserved field. Sent as 0, ignored on receipt. 6.2.3. Discovery Nonce @@ -678,21 +699,21 @@ checksum MUST be valid in AMT control messages. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x3 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Fields: + AMT Relay Advertisement 6.3.1. Type The type of the message. 6.3.2. Reserved A 24-bit reserved field. Sent as 0, ignored on receipt. 6.3.3. Request Nonce @@ -723,87 +744,91 @@ | Response MAC (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IGMP Membership Query or MLD Listener Query | | (including IP Header) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Fields: + AMT Membership Query 6.4.1. Type The type of the message. 6.4.2. Reserved A 8-bit reserved field. Sent as 0, ignored on receipt. 6.4.3. Response MAC A 48-bit hash generated by the respondent and sent to the originator for inclusion in the AMT Membership Update. The algorithm used for - this is chosen by the respondent. One algorithm that could be used - is HMAC-MD5-48 [RFC2104]. + this is chosen by the respondent but an algorithm such as HMAC-MD5-48 + [RFC2104] SHOULD be used at a minimum. 6.4.4. Request Nonce A 32-bit identifier used to distinguish this request echoed back to the originator. 6.4.5. IGMP/MLD Query (including IP Header) The message contains either an IGMP Query or an MLD Multicast Listener Query. The IGMP or MLD version sent should default to IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1. The IGMP/MLD Query includes a full IP Header. The IP source address of the query would match the anycast address on the pseudo interface. The TTL of the outer header should be sufficient to reach the tunnel endpoint and not mimic the inner header TTL which is typically 1 for IGMP/MLD messages. 6.5. AMT Membership Update - An AMT Membership Update is sent in response to a previously received - AMT Query message. It contains the original IGMP/MLD Membership/ - Listener Report or Leave/Done received over the AMT pseudo-interface - including the original IP header. It echoes the Response MAC - received in the AMT Membership Query so the respondent can verify - return routability to the originator. + An AMT Membership Update is sent to report a membership after a valid + Response MAC has been received. It contains the original IGMP/MLD + Membership/Listener Report or Leave/Done received over the AMT + pseudo-interface including the original IP header. It echoes the + Response MAC received in the AMT Membership Query so the respondent + can verify return routability to the originator. It is sent from the destination address received in the Query to the source address received in the Query which should both be the same as the original Request. The UDP source and destination port numbers should be the same ones sent in the original Request. The relay is not required to use the IP source address of the IGMP Membership Report for any particular purpose. + The same Request Nonce and Response MAC can be used across multiple + AMT Membership Update messages without having to send individual AMT + Membership Query messages. + 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x5 | Reserved | Response MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response MAC (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IGMP or MLD Message (including IP header) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Fields: + AMT Membership Update 6.5.1. Type The type of the message. 6.5.2. Reserved A 8-bit reserved field. Sent as 0, ignored on receipt. 6.5.3. Response MAC @@ -839,21 +864,21 @@ The payload of the UDP packet contains the following fields. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x6 | Reserved | IP Multicast Data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Fields: + AMT IP Multicast Data 6.6.1. Type The type of the message. 6.6.2. Reserved An 8-bit reserved field. Sent as 0, ignored on receipt. 6.6.3. IP Multicast Data @@ -863,30 +888,30 @@ 7. AMT Gateway Details This section details the behavior of an AMT Gateway, which may be a router serving an AMT site, or the site may consist of a single host, serving as its own gateway. 7.1. At Startup Time At startup time, the AMT gateway will bring up an AMT pseudo- - interface, to be used for encapsulation. The gateway will then send - an AMT Relay Discovery message to the AMT Relay Anycast Address, and - note the unicast address (which is treated as a link-layer address to - the encapsulation interface) from the AMT Relay Advertisement - message. This discovery SHOULD be done periodically (e.g., once a - day) to re-resolve the unicast address of a close relay. The gateway - also SHOULD initialize a timer used to send periodic membership - reports to a random value from the interval [0, [Query Interval]] - before sending the first periodic report, in order to prevent startup - synchronization (e.g., after a power outage). + interface to be used for encapsulation. The gateway needs to + discover an AMT Relay to send Membership Requests. It can send an + AMT Relay Discovery at startup time or wait until it has a group + membership to report. The AMT Relay Discovery message is sent to the + AMT Relay Anycast Address. A unicast address (which is treated as a + link-layer address to the encapsulation interface) is received in the + AMT Relay Advertisement message. The discovery process SHOULD be + done periodically (e.g., once a day) to re-resolve the unicast + address of a close relay. To prevent startup synchronization, the + timer SHOULD use at least 10 percent jitter. If the gateway is serving as a local router, it SHOULD also function as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD host-mode interface being the AMT pseudo-interface. This enables it to translate group memberships on its downstream interfaces into IGMP/MLD Reports. Hosts receiving multicast packets through an AMT gateway acting as a proxy should ensure that their M-RIB accepts multicast packets from the AMT gateway for the sources it is joining. 7.2. Gateway Group and Source Addresses @@ -923,40 +948,43 @@ +------------+------------------------+-------------+ | SSM prefix | Low 16 bits of | Local | | 232/8 | real source address | Policy | +------------+------------------------+-------------+ Source: +-------------------------+-------------------------+ |16-bit AMT unicast prefix| high 16 bits of real src| +-------------------------+-------------------------+ + IPv4 format + This allows for 2^8 (256) IPv4 group addresses for use by each AMT - gateway. An allocation of a prefix with length 18 would allow for - 2^6 (64) IPv4 group addresses. + gateway. 7.2.2. IPv6 Similarly for IPv6, this is illustrated in the following figure. Group: 32 64 32 +------------+------------------------+-------------+ | SSM prefix | Low 64 bits of | Local | | FF3x::/32 | real source address | Policy | +------------+------------------------+-------------+ Source: +-------------------------+-------------------------+ |64-bit AMT unicast prefix| high 64 bits of real src| +-------------------------+-------------------------+ + IPv6 format + This allows for 2^32 (over 4 billion) IPv6 group addresses for use by each AMT gateway. 7.3. Joining Groups with MBone Sources The IGMP/MLD protocol usually operates by having the Querier multicast an IGMP/MLD Query message on the link. This behavior does not work on NBMA links which do not support multicast. Since the set of gateways is typically unknown to the relay (and potentially quite large), unicasting the queries is also impractical. The following @@ -969,43 +997,37 @@ in this document), the destination address in the outer IP header is the relay's unicast address. Robustness is provided by the underlying IGMP/MLD protocol messages sent on the AMT pseudo- interface. In other words, the gateway does not need to retransmit IGMP/MLD Membership/Listener Reports and Leave/Done messages received on the pseudo-interface since IGMP/MLD will already do this. The gateway simply needs to encapsulate each IGMP/MLD Membership/Listener Report and Leave/Done message it receives. However, since periodic IGMP/MLD Membership/Listener Reports are sent - in response to IGMP/MLD Queries, some mechanism to trigger periodic - Membership/Listener Reports and Leave/Done messages are necessary. - This can be achieved in any implementation-specific manner. Some - possibilities include: - - 1. The AMT pseudo-interface might periodically manufacture IGMPv3/ - MLDv2 Queries as if they had been received from an IGMP/MLD - Querier, and deliver them to the IP layer, after which normal - IGMP/MLD behavior will cause the appropriate reports to be sent. - - 2. The IGMP/MLD module itself might provide an option to operate in - periodic mode on specific interfaces. - - The Querier's Robustness Variable (QRV) defined in [RFC3376] and - [RFC3810] can be used to adjust the number of Membership/Listener - Reports that are sent by the host joining the group. + in response to IGMP/MLD Queries, a mechanism to trigger periodic + Membership/Listener Reports and Leave/Done messages is necessary. + The gateway should use a timer to trigger periodic AMT Membership + Updates. If the gateway is behind a firewall device, the firewall may require the gateway to periodically refresh the UDP state in the firewall at - a shorter interval than the standard IGMP/MLD Query interval. - Therefore, this IGMP/MLD Query interval should be configurable to + a shorter interval than the standard IGMP/MLD Query interval. AMT + Requests can be sent periodically to solicit IGMP/MLD Queries. The + interval at which the AMT Requests are sent should be configurable to ensure the firewall does not revert to blocking the UDP encapsulated - IP Multicast data packets. + IP Multicast data packets. When the AMT Query is received, it can be + ignored unless it is time for a periodic AMT Membership Update. + + The relay can use the Querier's Robustness Variable (QRV) defined in + [RFC3376] and [RFC3810] to adjust the number of Membership/Listener + Reports that are sent by the host joining the group. 7.4. Responding to Relay Changes When a gateway determines that its current relay is unreachable (e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the relay's unicast address), it may need to repeat relay address discovery. However, care should be taken not to abandon the current relay too quickly due to transient network conditions. 7.5. Joining SSM Groups with AMT Gateway Sources @@ -1111,63 +1133,67 @@ to a pre-existing IGMP/MLD module. 2. The IGMP/MLD module might have native support for explicit membership tracking, especially if it supports other NBMA-style interfaces. If a relay wants to affect the rate at which the AMT Requests are originated from a gateway, it can tune the membership timeout by adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/ MLD Query contained within the AMT Membership Query message. The - QQIC field is defined in [RFC3376] and [RFC3810]. + QQIC field is defined in [RFC3376] and [RFC3810]. However, since the + gateway may need to send AMT Requests frequently enough to prevent + firewall state from timing out, the relay may be limited in its + ability to spread out Requests coming from a gateway by adjusting the + QQIC field. 8.4. Receiving (S,G) Joins from the Native Side, for AMT Sources The relay sends an IGMPv3/MLDv2 report to the AMT source as described above in Section 5.1.2 9. IANA Considerations 9.1. IPv4 and IPv6 Anycast Prefix Allocation The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated to the public AMT Relays to advertise to the native multicast backbone. The prefix length should be determined by the IANA; the prefix should be large enough to guarantee advertisement in the default-free BGP networks. 9.1.1. IPv4 - A prefix length of 18 will meet this requirement. + A prefix length of 16 will meet this requirement. 9.1.2. IPv6 A prefix length of 32 will meet this requirement. IANA has previously set aside the range 2001::/16 for allocating prefixes for this purpose. 9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation It should also be noted that this prefix length directly affects the number of groups available to be created by the AMT gateway: in the IPv4 case, a prefix length of 16 gives 256 groups, and a prefix length of 8 gives 65536 groups. 9.2.1. IPv4 As described above in Section 7.2.1 an IPv4 prefix with a length of - 18 is requested for this purpose. + 16 is requested for this purpose. 9.2.2. IPv6 As described above in Section 7.2.2 an IPv6 prefix with a length of - 48 is requested. + 32 is requested. 9.3. UDP Port number IANA has previously allocated UDP reserved port number 2268 for AMT encapsulation. All allocations are a one time effort and there will be no need for any recurring assignment after this stage. 10. Security Considerations @@ -1265,32 +1291,32 @@ [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. Authors' Addresses Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 @@ -1326,21 +1352,37 @@ Phone: +1 408 525 2530 Email: lorenzo@cisco.com Tom Pusateri !j 222 E. Jones Ave. Wake Forest, NC 27587 USA Email: pusateri@bangj.com -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. @@ -1350,30 +1392,14 @@ such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - Acknowledgment - Funding for the RFC Editor function is currently provided by the - Internet Society. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA).