draft-ietf-mboned-auto-multicast-12.txt   draft-ietf-mboned-auto-multicast-13.txt 
Network Working Group G. Bumgardner Network Working Group G. Bumgardner
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track T. Morin Intended status: Standards Track April 23, 2012
Expires: August 19, 2012 France Telecom - Orange Expires: October 25, 2012
February 16, 2012
Automatic Multicast Tunneling Automatic Multicast Tunneling
draft-ietf-mboned-auto-multicast-12 draft-ietf-mboned-auto-multicast-13
Abstract Abstract
This document describes Automatic Multicast Tunneling (AMT), a This document describes Automatic Multicast Tunneling (AMT), a
protocol for delivering multicast traffic from sources in a protocol for delivering multicast traffic from sources in a
multicast-enabled network to receivers that lack multicast multicast-enabled network to receivers that lack multicast
connectivity to the source network. The protocol uses UDP connectivity to the source network. The protocol uses UDP
encapsulation and unicast replication to provide this functionality. encapsulation and unicast replication to provide this functionality.
The AMT protocol is specifically designed to support rapid deployment The AMT protocol is specifically designed to support rapid deployment
skipping to change at page 1, line 38 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2012. This Internet-Draft will expire on October 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 2, line 22
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 3.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. General Architecture . . . . . . . . . . . . . . . . . . . 9 4.1. General Architecture . . . . . . . . . . . . . . . . . . . 8
4.2. General Operation . . . . . . . . . . . . . . . . . . . . 18 4.2. General Operation . . . . . . . . . . . . . . . . . . . . 17
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 33 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 32
5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 33 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 32
5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 47 5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 46
5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 61 5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 61
6. Security Considerations . . . . . . . . . . . . . . . . . . . 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 72
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
7.2. IPv4 Address Prefix Allocation for IGMP Source
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 76 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 76
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78
10.1. Normative References . . . . . . . . . . . . . . . . . . . 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 78
10.2. Informative References . . . . . . . . . . . . . . . . . . 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 78
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 81 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 84
1. Introduction 1. Introduction
The advantages and benefits provided by multicast technologies are The advantages and benefits provided by multicast technologies are
well known. There are a number of application areas that are ideal well known. There are a number of application areas that are ideal
candidates for the use of multicast, including media broadcasting, candidates for the use of multicast, including media broadcasting,
video conferencing, collaboration, real-time data feeds, data video conferencing, collaboration, real-time data feeds, data
replication, and software updates. Unfortunately, many of these replication, and software updates. Unfortunately, many of these
applications must currently rely on unicast replication at or near applications lack multicast connectivity to networks that carry
sources because most clients lack multicast connectivity to the traffic generated by multicast sources. The reasons for the lack of
network containing the sources. The reasons for the lack of
connectivity vary, but are primarily the result of service provider connectivity vary, but are primarily the result of service provider
policies and network limitations. policies and network limitations.
Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based
encapsulation to overcome the aforementioned lack of multicast encapsulation to overcome the aforementioned lack of multicast
connectivity. AMT enables sites, hosts or applications that do not connectivity. AMT enables sites, hosts or applications that do not
have native multicast access to a multicast source network to request have native multicast access to a network with multicast connectivity
and receive SSM [RFC4607] and ASM [RFC1112] multicast traffic from to a source, to request and receive SSM [RFC4607] and ASM [RFC1112]
sources in that network. traffic from a network that does provide multicast connectivity to
that source.
2. Applicability 2. Applicability
This document describes a protocol that may be used to deliver This document describes a protocol that may be used to deliver
multicast traffic from sources in a multicast enabled network to multicast traffic from a multicast enabled network to sites that lack
sites that lack multicast connectivity to the source network. This multicast connectivity to the source network. This document does not
document does not describe any methods for sourcing multicast traffic describe any methods for sourcing multicast traffic from isolated
from isolated sites as this topic is out of scope. sites as this topic is out of scope.
AMT is not intended to be used as a substitute for native multicast, AMT is not intended to be used as a substitute for native multicast,
especially in conditions or environments requiring high traffic flow. especially in conditions or environments requiring high traffic flow.
AMT uses unicast replication to reach multiple receivers and the AMT uses unicast replication to reach multiple receivers and the
bandwidth cost for this replication will be higher than that required bandwidth cost for this replication will be higher than that required
if the receivers were reachable via native multicast. if the receivers were reachable via native multicast.
3. Terminology 3. Terminology
3.1. Requirements Notation 3.1. Requirements Notation
skipping to change at page 10, line 40 skipping to change at page 9, line 40
encapsulation and decapsulation required to transport the IGMP and encapsulation and decapsulation required to transport the IGMP and
MLD messages and multicast IP datagrams between the gateways and MLD messages and multicast IP datagrams between the gateways and
relays. The IGMP and MLD messages that are exchanged between relays. The IGMP and MLD messages that are exchanged between
gateways and relays are encapsulated as complete IP datagrams within gateways and relays are encapsulated as complete IP datagrams within
AMT control messages. Multicast IP datagrams are replicated and AMT control messages. Multicast IP datagrams are replicated and
encapsulated in AMT data messages. All AMT messages are sent via encapsulated in AMT data messages. All AMT messages are sent via
unicast UDP/IP. unicast UDP/IP.
4.1.2. Gateways 4.1.2. Gateways
The downstream side of a gateway services multicast receivers - the The downstream side of a gateway services one or more receivers - the
gateway accepts group membership requests from receivers and forwards gateway accepts group membership requests from receivers and forwards
requested multicast traffic back to those receivers. requested multicast traffic back to those receivers.
The upstream side of a gateway connects to relays. A gateway sends The upstream side of a gateway connects to relays. A gateway sends
encapsulated IGMP and MLD messages to a relay to indicate an interest encapsulated IGMP and MLD messages to a relay to indicate an interest
in receiving specific multicast traffic. in receiving specific multicast traffic.
4.1.2.1. Architecture 4.1.2.1. Architecture
Each gateway possesses a logical pseudo-interface: Each gateway possesses a logical pseudo-interface:
skipping to change at page 16, line 30 skipping to change at page 15, line 30
will always return the nearest operational relay. will always return the nearest operational relay.
o Relays may take themselves offline when they exhaust resources o Relays may take themselves offline when they exhaust resources
required to service additional gateways. Existing gateway required to service additional gateways. Existing gateway
connections may be preserved, but new gateway requests would be connections may be preserved, but new gateway requests would be
routed to the next-nearest relay. routed to the next-nearest relay.
4.1.4.1. Public Versus Private 4.1.4.1. Public Versus Private
Ideally, the AMT protocol would provide a universal solution for Ideally, the AMT protocol would provide a universal solution for
connecting gateways to multicast sources - that any gateway would be connecting receivers to multicast sources - that any gateway could be
able to access any globally advertised multicast source via publicly- used to access any globally advertised multicast source via publicly-
accessible, widely-deployed relays. Unfortunately, today's internet accessible, widely-deployed relays. Unfortunately, today's internet
does not yet allow this, as many relays will lack native multicast does not yet allow this, because many relays will lack native
access to sources even though they may be globally accessible via multicast access to sources even though they may be globally
unicast. accessible via unicast.
In these cases, a provider may deploy relays within their own source In these cases, a provider may deploy relays within their own source
network to allow for multicast distribution within that network. network to allow for multicast distribution within that network.
Gateways that use these relays must use a provider-specific relay Gateways that use these relays must use a provider-specific relay
discovery mechanism or a private anycast address to obtain access to discovery mechanism or a private anycast address to obtain access to
these relays. these relays.
4.1.5. Discovery 4.1.5. Discovery
To execute the gateway portion of the protocol, a gateway requires a To execute the gateway portion of the protocol, a gateway requires a
skipping to change at page 18, line 14 skipping to change at page 17, line 14
4.2. General Operation 4.2. General Operation
4.2.1. Message Sequences 4.2.1. Message Sequences
The AMT protocol defines the following messages for control and The AMT protocol defines the following messages for control and
encapsulation. These messages are exchanged as UDP/IP datagrams, one encapsulation. These messages are exchanged as UDP/IP datagrams, one
message per datagram. message per datagram.
Relay Discovery: Relay Discovery:
Sent by gateways to solicit a Relay Advertisement from any relay Sent by gateways to solicit a Relay Advertisement from any relay.
in order to find a relay with which to communicate. Used to find a relay with which to communicate.
Relay Advertisement: Relay Advertisement:
Sent by relays as a response to a Relay Discovery message. Used Sent by relays as a response to a Relay Discovery message. Used
to deliver a relay address to a gateway. to deliver a relay address to a gateway.
Request: Request:
Sent by gateways to solicit a Membership Query message from a Sent by gateways to solicit a Membership Query message from a
relay. relay.
Membership Query: Membership Query:
skipping to change at page 23, line 13 skipping to change at page 22, line 13
subscriptions and the report does not contain any group subscriptions and the report does not contain any group
subscriptions, so the relay takes no action. subscriptions, so the relay takes no action.
B. The gateway has previously reported a group subscription so B. The gateway has previously reported a group subscription so
the current-state report lists all current subscriptions. the current-state report lists all current subscriptions.
The relay responds by refreshing tunnel or group state and The relay responds by refreshing tunnel or group state and
resetting any related timers. resetting any related timers.
7. A receiver indicates to the gateway that it wishes to join 7. A receiver indicates to the gateway that it wishes to join
(allow) or leave (block) specific multicast traffic. This (allow) or leave (block) specific multicast traffic. This
request is typically made through some form IGMP/MLD service request is typically made using some form IGMP/MLD service
interface (as described in Section 2 of [RFC3376] or Section 3 interface (as described in Section 2 of [RFC3376] or Section 3
of [RFC3810]). The IGMP/MLD protocol responds by generating an of [RFC3810]). The IGMP/MLD protocol responds by generating an
IGMP or MLD state-change message. IGMP or MLD state-change message.
8. When an IGMP or MLD report/leave/done message is passed to the 8. When an IGMP or MLD report/leave/done message is passed to the
pseudo-interface, the gateway encapsulates the message in a pseudo-interface, the gateway encapsulates the message in a
Membership Update message and sends it to the relay. The Membership Update message and sends it to the relay. The
request nonce and MAC fields in the Membership Update are request nonce and MAC fields in the Membership Update are
assigned the values from the last Membership Query message assigned the values from the last Membership Query message
received for the corresponding group membership protocol (IGMP received for the corresponding group membership protocol (IGMP
skipping to change at page 24, line 5 skipping to change at page 23, line 5
accordingly. This includes making any group membership, routing accordingly. This includes making any group membership, routing
and forwarding state changes and issuing any upstream protocol and forwarding state changes and issuing any upstream protocol
requests required to satisfy the state change. The diagram requests required to satisfy the state change. The diagram
illustrates two scenarios: illustrates two scenarios:
A. The gateway wishes to add a group subscription. A. The gateway wishes to add a group subscription.
B. The gateway wishes to delete a previously reported group B. The gateway wishes to delete a previously reported group
subscription. subscription.
10. Multicast datagrams transmitted by a source travel through the 10. Multicast datagrams transmitted from a source travel through the
native multicast infrastructure to the relay. When the relay native multicast infrastructure to the relay. When the relay
receives a multicast IP datagram that carries a source and receives a multicast IP datagram that carries a source and
destination address for which a gateway has expressed an destination address for which a gateway has expressed an
interest in receiving (via the Membership Update message), it interest in receiving (via the Membership Update message), it
encapsulates the datagram into a Multicast Data message and encapsulates the datagram into a Multicast Data message and
sends it to the gateway using the source IP address and UDP port sends it to the gateway using the source IP address and UDP port
carried by the Membership Update message as the destination carried by the Membership Update message as the destination
address. address.
11. When the gateway receives a Multicast Data message, it extracts 11. When the gateway receives a Multicast Data message, it extracts
skipping to change at page 31, line 40 skipping to change at page 30, line 40
| |<------------------------------------------------------->| | | |<------------------------------------------------------->| |
|____| | | | | | | | | | | | | |____| |____| | | | | | | | | | | | | |____|
| |<--------------------------------------------------| | | |<--------------------------------------------------| |
|_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______| |_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______|
| | | | | | | | | |
IP AMT:IP IP:UDP:AMT:IP AMT:IP IP IP AMT:IP IP:UDP:AMT:IP AMT:IP IP
AMT Encapsulation AMT Encapsulation
The IGMP and MLD messages used in AMT are exchanged as complete IP The IGMP and MLD messages used in AMT are exchanged as complete IP
datagrams. These IP datagrams are encapsulated in AMT messages which datagrams. These IP datagrams are encapsulated in AMT messages that
are transmitted using UDP. The same holds true for multicast traffic are transmitted using UDP. The same holds true for multicast traffic
- each multicast IP datagram that arrives at the relay is - each multicast IP datagram that arrives at the relay is
encapsulated in an AMT message and transmitted to one or more encapsulated in an AMT message and transmitted to one or more
gateways via UDP. gateways via UDP.
The IP protocol of the encapsulated packets need not match the IP The IP protocol of the encapsulated packets need not match the IP
protocol used to send the AMT messages. AMT messages sent via IPv4 protocol used to send the AMT messages. AMT messages sent via IPv4
may carry IPv6/MLD packets and AMT messages sent via IPv6 may carry may carry IPv6/MLD packets and AMT messages sent via IPv6 may carry
IPv4/IGMP packets. IPv4/IGMP packets.
skipping to change at page 32, line 18 skipping to change at page 31, line 18
encapsulated packets as they may not have access to the entire encapsulated packets as they may not have access to the entire
datagram. datagram.
To avoid placing an undue burden on the relay platform, the protocol To avoid placing an undue burden on the relay platform, the protocol
specifically allows zero-valued UDP checksums on the multicast data specifically allows zero-valued UDP checksums on the multicast data
messages. This is not an issue in UDP over IPv4 as the UDP checksum messages. This is not an issue in UDP over IPv4 as the UDP checksum
field may be set to zero. However, this is a problem for UDP over field may be set to zero. However, this is a problem for UDP over
IPv6 as that protocol requires a valid, non-zero checksum in UDP IPv6 as that protocol requires a valid, non-zero checksum in UDP
datagrams [RFC2460]. Messages sent over IPv6 with a UDP checksum of datagrams [RFC2460]. Messages sent over IPv6 with a UDP checksum of
zero may fail to reach the gateway. This is a well known issue for zero may fail to reach the gateway. This is a well known issue for
UDP-based tunneling protocols. See [I-D.ietf-6man-udpchecksums] and UDP-based tunneling protocols that is described
[I-D.ietf-6man-udpzero] for details. [I-D.ietf-6man-udpzero]. A recommended solution is described in
[I-D.ietf-6man-udpchecksums].
5. Protocol Description 5. Protocol Description
This section provides a normative description of the AMT protocol. This section provides a normative description of the AMT protocol.
5.1. Protocol Messages 5.1. Protocol Messages
The AMT protocol defines seven message types for control and The AMT protocol defines seven message types for control and
encapsulation. These messages are assigned the following names and encapsulation. These messages are assigned the following names and
numeric identifiers: numeric identifiers:
skipping to change at page 40, line 22 skipping to change at page 39, line 22
5.1.4.8. Encapsulated General Query Message 5.1.4.8. Encapsulated General Query Message
An IP-encapsulated IGMP or MLD message generated by the relay. This An IP-encapsulated IGMP or MLD message generated by the relay. This
field will contain one of the following IP datagrams: field will contain one of the following IP datagrams:
IPv4:IGMPv3 Membership Query IPv4:IGMPv3 Membership Query
IPv6:MLDv2 Listener Query IPv6:MLDv2 Listener Query
The source address carried by the query message SHOULD be set to zero The source address carried by the query message should be set as
to indicate that query originated from a non-querier. described in Section 5.3.3.3.
The Querier's Query Interval Code (QQIC) field in the general query The Querier's Query Interval Code (QQIC) field in the general query
is used by a relay to specify the time offset a gateway should use to is used by a relay to specify the time offset a gateway should use to
schedule a new three-way handshake to refresh the group membership schedule a new three-way handshake to refresh the group membership
state within the relay (current time + Query Interval). state within the relay (current time + Query Interval).
The Querier's Robustness Variable (QRV) field in the general query is The Querier's Robustness Variable (QRV) field in the general query is
used by a relay to specify the number of times a gateway should used by a relay to specify the number of times a gateway should
retransmit unsolicited membership reports, encapsulated within retransmit unsolicited membership reports, encapsulated within
Membership Update messages, and optionally, the number of times to Membership Update messages, and optionally, the number of times to
skipping to change at page 43, line 29 skipping to change at page 42, line 29
IPv4:IGMPv2 Leave Group IPv4:IGMPv2 Leave Group
IPv4:IGMPv3 Membership Report IPv4:IGMPv3 Membership Report
IPv6:MLDv1 Multicast Listener Report IPv6:MLDv1 Multicast Listener Report
IPv6:MLDv1 Multicast Listener Done IPv6:MLDv1 Multicast Listener Done
IPv6:MLDv2 Multicast Listener Report IPv6:MLDv2 Multicast Listener Report
The source address carried by the message should be set as described
in Section 5.2.1.
5.1.6. Multicast Data 5.1.6. Multicast Data
A relay sends a Multicast Data message to deliver an IP multicast A relay sends a Multicast Data message to deliver an IP multicast
packet to a gateway. packet to a gateway.
The checksum field in the UDP header of this message MAY contain a The checksum field in the UDP header of this message MAY contain a
value of zero when sent over IPv4 but SHOULD, if possible, contain a value of zero when sent over IPv4 but SHOULD, if possible, contain a
valid, non-zero value when sent over IPv6 (See Section 4.2.2.3). valid, non-zero value when sent over IPv6 (See Section 4.2.2.3).
The UDP/IP datagram containing this message MUST carry the following The UDP/IP datagram containing this message MUST carry the following
skipping to change at page 47, line 33 skipping to change at page 46, line 33
An application with embedded gateway functionality must provide its An application with embedded gateway functionality must provide its
own implementation of this subset of the IPv4/IGMP and IPv6/MLD own implementation of this subset of the IPv4/IGMP and IPv6/MLD
protocols. The service interface used to manipulate group membership protocols. The service interface used to manipulate group membership
state need not match that described in the IGMP and MLD state need not match that described in the IGMP and MLD
specifications, but the actions taken as a result SHOULD be similar specifications, but the actions taken as a result SHOULD be similar
to those described in Section 5.1 of [RFC3376] and Section 6.1 of to those described in Section 5.1 of [RFC3376] and Section 6.1 of
[RFC3810]. The gateway application will likely need to implement [RFC3810]. The gateway application will likely need to implement
many of the same functions as a host IP stack, including checksum many of the same functions as a host IP stack, including checksum
verification, dispatching, datagram filtering and forwarding, and IP verification, dispatching, datagram filtering and forwarding, and IP
encapsulation/decapsulation. Applications that use AMT to join encapsulation/decapsulation.
multicast UDP streams may also need to perform IP reassembly to
reconstruct UDP datagrams that were fragmented prior to replication
and encapsulation in the relay.
The IP-encapsulated IGMP/MLD messages generated by the gateway IPv4/ The IP-encapsulated IGMP messages generated by the gateway IPv4/IGMP
IGMP or IPv6/MLD implementation MUST conform to the descriptions implementation MUST conform to the description found in Section 4 of
found in Section 4 of [RFC3376] and Section 5 of [RFC3810]. These [RFC3376]. These datagrams MUST possess the IP headers, header
datagrams MUST possess the IP headers, header options and header options and header values called for in [RFC3376], with the following
values called for in these RFCs, with the following exception; the exception; the source IP address for an IGMP report datagram MAY be
source IP address for an IGMP/MLD report datagram MAY be set to the set to the "unspecified" address (all octets are zero ) but SHOULD be
"unspecified" address (all octets are zero ). This exception is made set to an address in the address range specifically assigned by IANA
because the gateway pseudo-interface might not possess an address, for use in the IGMP messages sent from a gateway to a relay (i.e.
and even if such an address exists, that address would not be a valid 154.7.1.2 through 154.7.1.254 as described in Section 7). This
source address on any relay interface. To allow for this exception, exception is made because the gateway pseudo-interface might not
a relay must accept an IGMP or MLD report carried by a Membership possess an assigned address, and even if such an address exists, that
address would not be a valid link-local source address on any relay
interface. The rationale for using the aforementioned source
addresses is primary one of convenience - a relay will accept an IGMP
report carried by a Membership Update message regardless of the
source address it carries. See Section 5.3.1.
The IP-encapsulated MLD messages generated by the gateway IPv6/MLD
implementation MUST conform to the description found in Section 5 of
[RFC3810]. These datagrams MUST possess the IP headers, header
options and header values called for in [RFC3810], with the following
exception; the source IP address for an MLD report datagram MAY be
set to the "unspecified" address (all octets are zero ) but SHOULD be
set to an IPv6 link-local address in the range FE80::/64 excluding
FE80::1 and FE80::2. This exception is made because the gateway
pseudo-interface might not possess a valid IPv6 address. As with
IGMP, a relay will accept an MLD report carried by a Membership
Update message regardless of the source address it carries. See Update message regardless of the source address it carries. See
Section 5.3.1. Section 5.3.1.
The gateway IGMP/MLD implementation SHOULD retransmit unsolicited The gateway IGMP/MLD implementation SHOULD retransmit unsolicited
membership state-change reports and merge new state change reports membership state-change reports and merge new state change reports
with pending reports as described in Section 5.1 of [RFC3376] and with pending reports as described in Section 5.1 of [RFC3376] and
Section 6.1 of [RFC3810]. The number of retransmissions is specified Section 6.1 of [RFC3810]. The number of retransmissions is specified
by the relay in the Querier's Robustness Variable (QRV) field in the by the relay in the Querier's Robustness Variable (QRV) field in the
last general query forwarded by the pseudo-interface. last general query forwarded by the pseudo-interface.
The gateway IGMP/MLD implementation SHOULD handle general query The gateway IGMP/MLD implementation SHOULD handle general query
messages as described in Section 5.2 of [RFC3376] and Section 6.2 of messages as described in Section 5.2 of [RFC3376] and Section 6.2 of
[RFC3810], but MAY ignore the Max Resp Code field value and generate [RFC3810], but MAY ignore the Max Resp Code field value and generate
a current state report without any delay. a current state report without any delay.
A gateway IPv4 implementation MUST accept IPv4 datagrams that carry An IPv4 gateway implementation MUST accept IPv4 datagrams that carry
multicast data or the general query variant of the IGMPv3 Membership the general query variant of the IGMPv3 Membership Query message, as
Query message, as described in Section 4 of [RFC3376]. described in Section 4 of [RFC3376]. The gateway MUST accept the
IGMP datagram regardless of the IP source address carried by that
datagram.
A gateway IPv6 implementations MUST accept IPv6 datagrams that carry An IPv6 gateway implementation MUST accept IPv6 datagrams that carry
multicast data or the general query variant of the MLDv2 Multicast the general query variant of the MLDv2 Multicast Listener Query
Listener Query message, as described in Section 5 of [RFC3810]. message, as described in Section 5 of [RFC3810]. The gateway MUST
accept the MLD datagram regardless of the IP source address carried
by that datagram.
5.2.2. Pseudo-Interface Configuration 5.2.2. Pseudo-Interface Configuration
A gateway host may possess or create multiple gateway pseudo- A gateway host may possess or create multiple gateway pseudo-
interfaces, each with a unique configuration that describes a binding interfaces, each with a unique configuration that describes a binding
to a specific IP protocol, relay address, relay discovery address or to a specific IP protocol, relay address, relay discovery address or
upstream network interface. upstream network interface.
5.2.2.1. Static Relay Address 5.2.2.1. Static Relay Address
skipping to change at page 51, line 5 skipping to change at page 50, line 21
o The destination address carried by the encapsulated IP datagram o The destination address carried by the encapsulated IP datagram
MUST fall within the multicast address allocation assigned to the MUST fall within the multicast address allocation assigned to the
relavent IP protocol, i.e., 224.0.0.0/4 for IPv4 and FF00::/8 for relavent IP protocol, i.e., 224.0.0.0/4 for IPv4 and FF00::/8 for
IPv6. IPv6.
The gateway extracts the encapsulated IP datagram and forwards it to The gateway extracts the encapsulated IP datagram and forwards it to
the local IP protocol implementation for checksum verification, the local IP protocol implementation for checksum verification,
fragmented datagram reassembly, source and group filtering, and fragmented datagram reassembly, source and group filtering, and
transport-layer protocol processing. transport-layer protocol processing.
Because AMT uses UDP encapsulation to deliver multicast datagrams to
gateways, it qualifies as a tunneling protocol subject to the
limitations described in [I-D.ietf-6man-udpzero]. If supported, a
gateway SHOULD employ the solution described in
[I-D.ietf-6man-udpchecksums] to ensure that the local IP stack does
not discard IPv6 datagrams with zero checksums. If Multicast Data
message datagrams are processed directly within the gateway (instead
of the host IP stack), the gateway MUST NOT discard any of these
datagrams because they carry a UDP checksum of zero.
5.2.3.4. Relay Discovery Procedure 5.2.3.4. Relay Discovery Procedure
This section describes gateway requirements related to the relay This section describes gateway requirements related to the relay
discovery message sequence described in Section 4.2.1.1. discovery message sequence described in Section 4.2.1.1.
5.2.3.4.1. Starting Relay Discovery 5.2.3.4.1. Starting Relay Discovery
A gateway may start or restart the relay discovery procedure in A gateway may start or restart the relay discovery procedure in
response to the following events: response to the following events:
skipping to change at page 51, line 37 skipping to change at page 51, line 16
L-flag set to 1. L-flag set to 1.
5.2.3.4.2. Sending a Relay Discovery Message 5.2.3.4.2. Sending a Relay Discovery Message
A gateway sends a Relay Discovery message to a relay to start the A gateway sends a Relay Discovery message to a relay to start the
relay discovery process. relay discovery process.
The gateway MUST send the Relay Discovery message using the current The gateway MUST send the Relay Discovery message using the current
Relay Discovery Address and IANA-assigned UDP port number as the Relay Discovery Address and IANA-assigned UDP port number as the
destination. The Discovery Nonce value in the Relay Discovery destination. The Discovery Nonce value in the Relay Discovery
message must be computed as described in Section 5.2.3.4.5. message MUST be computed as described in Section 5.2.3.4.5.
The gateway MUST save a copy of Relay Discovery message or save the The gateway MUST save a copy of Relay Discovery message or save the
Discovery Nonce value for possible retransmission and verification of Discovery Nonce value for possible retransmission and verification of
a Relay Advertisement response. a Relay Advertisement response.
When a gateway sends a Relay Discovery message, it may be notified When a gateway sends a Relay Discovery message, it may be notified
that an ICMP Destination Unreachable message was received as a result that an ICMP Destination Unreachable message was received as a result
of an earlier AMT message transmission. Handling of ICMP Destination of an earlier AMT message transmission. Handling of ICMP Destination
Unreachable messages is described in Section 5.2.3.9. Unreachable messages is described in Section 5.2.3.9.
skipping to change at page 56, line 40 skipping to change at page 56, line 40
fields for use in sending subsequent Membership Update and Teardown fields for use in sending subsequent Membership Update and Teardown
messages. messages.
The gateway extracts the encapsulated IP datagram and forwards it to The gateway extracts the encapsulated IP datagram and forwards it to
the local IP protocol implementation for checksum verification and the local IP protocol implementation for checksum verification and
dispatching to the IGMP or MLD implementation running on the pseudo- dispatching to the IGMP or MLD implementation running on the pseudo-
interface. The gateway MUST NOT forward any octets that might exist interface. The gateway MUST NOT forward any octets that might exist
between the encapsulated IP datagram and the end of the message or between the encapsulated IP datagram and the end of the message or
Gateway Address fields. Gateway Address fields.
An MLD datagram contained in a Membership Query message may require The IGMP and MLD protocol specifications indicate that senders should
special handling. The encapsulated query generated by a relay will use a link-local source IP address in message datagrams. This
likely carry an unspecified or relay link-local source address. If a requirement must be relaxed for AMT because gateways and relays do
gateway relies on a standard host-mode MLD protocol implementation to not share a common subnet. For this reason, a gateway implementation
process the query, that implementation will silently ignore the MLD MUST accept IGMP and MLD query message datagrams regardless of the
query because it carries an unspecified or non-link-local source source IP address they carry.
address - a gateway may need to construct its own query with a valid
link-local address (e.g., a spoofed address in a virtual subnet
defined by the address and netmask assigned to the gateway pseudo-
interface) to ensure that the report will not be ignored by the MLD
protocol implementation.
The gateway must start a timer that will trigger the next iteration The gateway MUST start a timer that will trigger the next iteration
of the membership update cycle by executing the membership query of the membership update cycle by executing the membership query
procedure. The gateway SHOULD compute the timer duration from the procedure. The gateway SHOULD compute the timer duration from the
Querier's Query Interval Code carried by the general-query. A Querier's Query Interval Code carried by the general-query. A
gateway MAY use a smaller timer duration if required to refresh a NAT gateway MAY use a smaller timer duration if required to refresh a NAT
mapping that would otherwise timeout. A gateway MAY use a larger mapping that would otherwise timeout. A gateway MAY use a larger
timer duration if it has no group subscriptions to report. timer duration if it has no group subscriptions to report.
If the gateway supports the Teardown message and the G-flag is set in If the gateway supports the Teardown message and the G-flag is set in
the Membership Query message, the gateway MUST compare the Gateway IP the Membership Query message, the gateway MUST compare the Gateway IP
Address and Gateway Port Number on the new Membership Query message Address and Gateway Port Number on the new Membership Query message
skipping to change at page 58, line 46 skipping to change at page 58, line 42
o Insert IGMP/MLD messages into a queue for transmission after it o Insert IGMP/MLD messages into a queue for transmission after it
receives a Membership Query message. receives a Membership Query message.
If the datagram contains a valid IGMP or MLD message, the gateway If the datagram contains a valid IGMP or MLD message, the gateway
sends it to the relay as described in the next section. sends it to the relay as described in the next section.
5.2.3.6.2. Sending a Membership Update Message 5.2.3.6.2. Sending a Membership Update Message
A gateway cannot send a Membership Update message to a relay until it A gateway cannot send a Membership Update message to a relay until it
has received a Membership Query message from a relay. If the gateway has received a Membership Query message from a relay. If the gateway
has not yet located a relay with which to communicate, it must first has not yet located a relay with which to communicate, it MUST first
execute the relay discovery procedure described in Section 5.2.3.4 to execute the relay discovery procedure described in Section 5.2.3.4 to
obtain a relay address. If the gateway has a relay address, but has obtain a relay address. If the gateway has a relay address, but has
not yet received a Membership Query message, it must first execute not yet received a Membership Query message, it MUST first execute
the membership query procedure described in Section 5.2.3.5 to obtain the membership query procedure described in Section 5.2.3.5 to obtain
a Request Nonce and Response MAC that can be used to send a a Request Nonce and Response MAC that can be used to send a
Membership Update message. Membership Update message.
Once a gateway possesses a valid Relay Address, Request Nonce and Once a gateway possesses a valid Relay Address, Request Nonce and
Response MAC, it may encapsulate the IP datagram containing the IGMP/ Response MAC, it may encapsulate the IP datagram containing the IGMP/
MLD message into a Membership Update message. The gateway MUST copy MLD message into a Membership Update message. The gateway MUST copy
the Request Nonce and Response MAC values from the last Membership the Request Nonce and Response MAC values from the last Membership
Query received from the relay into the corresponding fields in the Query received from the relay into the corresponding fields in the
Membership Update. The gateway MUST send the Membership Update Membership Update. The gateway MUST send the Membership Update
skipping to change at page 60, line 14 skipping to change at page 60, line 9
corresponding fields of the Teardown message. corresponding fields of the Teardown message.
A gateway MUST send the Teardown message using the Relay Address and A gateway MUST send the Teardown message using the Relay Address and
IANA-assigned AMT port number as the destination. A gateway MAY send IANA-assigned AMT port number as the destination. A gateway MAY send
the the Teardown message multiple times for robustness. The gateway the the Teardown message multiple times for robustness. The gateway
SHOULD use the Querier's Robustness Variable (QRV) field contained in SHOULD use the Querier's Robustness Variable (QRV) field contained in
the query encapsulated within the last Membership Query to set the the query encapsulated within the last Membership Query to set the
limit on the number of retransmissions. If the gateway sends the limit on the number of retransmissions. If the gateway sends the
Teardown message multiple times, it SHOULD insert a delay between Teardown message multiple times, it SHOULD insert a delay between
each transmission using the timing algorithm employed in IGMP/MLD for each transmission using the timing algorithm employed in IGMP/MLD for
transmitting unsolicited state-change reports. transmitting unsolicited state-change reports. The RECOMMENDED
default delay value is 1 second.
When a gateway sends a Teardown message, it may be notified that an When a gateway sends a Teardown message, it may be notified that an
ICMP Destination Unreachable message was received as a result of an ICMP Destination Unreachable message was received as a result of an
earlier AMT message transmission. Handling of ICMP Destination earlier AMT message transmission. Handling of ICMP Destination
Unreachable messages is described in Section 5.2.3.9. Unreachable messages is described in Section 5.2.3.9.
5.2.3.8. Shutdown 5.2.3.8. Shutdown
When a gateway pseudo-interface is stopped and the gateway has When a gateway pseudo-interface is stopped and the gateway has
existing group subscriptions, the gateway SHOULD either: existing group subscriptions, the gateway SHOULD either:
skipping to change at page 62, line 4 skipping to change at page 61, line 48
to provide group membership tracking and report processing. to provide group membership tracking and report processing.
A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY support A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY support
IPv6/MLDv2. A relay accessible via IPv6 MUST support IPv6/MLDv2 and IPv6/MLDv2. A relay accessible via IPv6 MUST support IPv6/MLDv2 and
MAY support IPv4/IGMPv3. MAY support IPv4/IGMPv3.
A relay MUST apply the forwarding rules described in Section 6.3 of A relay MUST apply the forwarding rules described in Section 6.3 of
[RFC3376] and Section 7.3 of [RFC3810]. [RFC3376] and Section 7.3 of [RFC3810].
A relay MUST handle incoming reports as described ,Section 6.4 of A relay MUST handle incoming reports as described ,Section 6.4 of
[RFC3376] and Section 7.4 of [RFC3810] with the exception that [RFC3376] and Section 7.4 of [RFC3810] with the exception that
actions that lead to queries MAY be modified to eliminate query actions that lead to queries MAY be modified to eliminate query
generation. generation. A relay MUST accept IGMP and MLD report datagrams
regardless of the IP source address carried by those datagrams.
All other aspects of IGMP/MLD router behavior, such as the handling All other aspects of IGMP/MLD router behavior, such as the handling
of queries, querier election, etc., are not used or required for of queries, querier election, etc., are not used or required for
relay operation. relay operation.
5.3.2. Startup 5.3.2. Startup
If a relay is deployed for anycast discovery, the relay MUST If a relay is deployed for anycast discovery, the relay MUST
advertise an anycast Relay Discovery Address Prefix into the unicast advertise an anycast Relay Discovery Address Prefix into the unicast
routing system of the anycast domain. An address within that prefix, routing system of the anycast domain. An address within that prefix,
skipping to change at page 63, line 8 skipping to change at page 62, line 52
with a Version field value other than zero. with a Version field value other than zero.
5.3.3.2. Handling a Relay Discovery Message 5.3.3.2. Handling a Relay Discovery Message
This section describes relay requirements related to the relay This section describes relay requirements related to the relay
discovery message sequence described in Section 4.2.1.1. discovery message sequence described in Section 4.2.1.1.
A relay MUST accept and respond to Relay Discovery messages sent to A relay MUST accept and respond to Relay Discovery messages sent to
an anycast relay discovery address or the unicast relay address. If an anycast relay discovery address or the unicast relay address. If
a relay receives a Relay Discovery message sent to its unicast a relay receives a Relay Discovery message sent to its unicast
address, it must respond just as it would if the message had been address, it MUST respond just as it would if the message had been
sent to its anycast discovery address. sent to its anycast discovery address.
When a relay receives a Relay Discovery message it responds by When a relay receives a Relay Discovery message it responds by
sending a Relay Advertisement message back to the source of the Relay sending a Relay Advertisement message back to the source of the Relay
Discovery message. The relay MUST use the source IP address and UDP Discovery message. The relay MUST use the source IP address and UDP
port of the Relay Discovery message as the destination IP address and port of the Relay Discovery message as the destination IP address and
UDP port. The relay MUST use the destination IP address and UDP port UDP port. The relay MUST use the destination IP address and UDP port
of the Relay Discovery as the source IP address and UDP port to of the Relay Discovery as the source IP address and UDP port to
ensure successful NAT traversal. ensure successful NAT traversal.
skipping to change at page 64, line 17 skipping to change at page 64, line 13
If the P-flag in the Request message is 0, the relay MUST return an If the P-flag in the Request message is 0, the relay MUST return an
IPv4-encapsulated IGMPv3 general query in the Membership Query IPv4-encapsulated IGMPv3 general query in the Membership Query
message. If the P-flag is 1, the relay MUST return an IPv6- message. If the P-flag is 1, the relay MUST return an IPv6-
encapsulated MLDv2 general query in the Membership Query message. encapsulated MLDv2 general query in the Membership Query message.
If the relay is not accepting Membership Update messages that create If the relay is not accepting Membership Update messages that create
new tunnel endpoints due to resource limitations, it SHOULD set the new tunnel endpoints due to resource limitations, it SHOULD set the
L-flag in the Membership Query message to notify the gateway of this L-flag in the Membership Query message to notify the gateway of this
state. Support for the L-flag is OPTIONAL. See Section 5.3.3.8. state. Support for the L-flag is OPTIONAL. See Section 5.3.3.8.
The IGMPv3/MLDv2 general query datagram that a relay encapsulates An IGMPv3 general query datagram that a relay encapsulates within a
within a Membership Query message MUST conform to the descriptions Membership Query message MUST conform to the descriptions found in
found in Section 4.1 of [RFC3376] and Section 5.1 of [RFC3810]. Section 4.1 of [RFC3376]. These datagrams MUST possess the IP
These datagrams MUST possess the IP headers, header options and headers, header options and header values called for in [RFC3376],
header values called for in these RFCs, with the following exception; with the following exception; the source IP address for an IGMP
the source IP address for an IGMP/MLD general query datagram MAY be general query datagram MAY be set to the "unspecified" address (all
set to the "unspecified" address (all octets are zero). This octets are zero) but SHOULD be set to an address in the address range
exception is made because any address that a relay might use will not specifically assigned by IANA for use in the IGMP messages sent from
be a valid source address on any gateway interface. To allow for a relay to a gateway (i.e. 154.7.1.1 as described in Section 7).
this exception, gateways must accept an IGMP or MLD query regardless This exception is made because any address that a relay might may not
of the source address it carries. See Section 5.2.1. be a valid source address on any gateway interface. The rationale
for using the aforementioned source addresses is primary one of
convenience - a gateway will accept an IGMP query regardless of the
source address it carries. See Section 5.2.1.
An MLDv2 general query datagram that a relay encapsulates within a
Membership Query message MUST conform to the descriptions found in
Section 5.1 of [RFC3810]. These datagrams MUST possess the IP
headers, header options and header values called for in [RFC3810],
with the following exception; the source IP address for an MLD
general query datagram MAY be set to the "unspecified" address (all
octets are zero) but SHOULD be set to an IPv6 link-local address in
the range FE80::/64. A relay may use a dynamically-generated link-
local address or the fixed address FE80::2. As with IGMP, a gateway
will accept an MLD query regardless of the source address it carries.
See Section 5.2.1.
A relay MUST set the Querier's Query Interval Code (QQIC) field in A relay MUST set the Querier's Query Interval Code (QQIC) field in
the general query to supply the gateway with a suggested time the general query to supply the gateway with a suggested time
duration to use for the membership query timer. The QQIC field is duration to use for the membership query timer. The QQIC field is
defined in Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810]. defined in Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810].
A relay MAY adjust this value to affect the rate at which the Request A relay MAY adjust this value to affect the rate at which the Request
messages are sent from a gateway. However, a gateway is allowed to messages are sent from a gateway. However, a gateway is allowed to
use a shorter duration than specified in the QQIC field, so a relay use a shorter duration than specified in the QQIC field, so a relay
may be limited in its ability to spread out Requests coming from a may be limited in its ability to spread out Requests coming from a
gateway. gateway.
skipping to change at page 65, line 31 skipping to change at page 65, line 42
* IPv4 datagram carrying an IGMPv2 Leave Group message. * IPv4 datagram carrying an IGMPv2 Leave Group message.
* IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener * IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener
Report message. Report message.
* IPv6 datagram carrying MLDv1 Multicast Listener Done message. * IPv6 datagram carrying MLDv1 Multicast Listener Done message.
o The encapsulated IP datagram MUST satisfy the IP header o The encapsulated IP datagram MUST satisfy the IP header
requirements for the IGMP or MLD message type as described in requirements for the IGMP or MLD message type as described in
Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of
[RFC3810], Section 3 of [RFC2710]. [RFC3810], and Section 3 of [RFC2710], with the following
exception - a relay MUST accept an IGMP or MLD message regardless
of the IP source address carried by the datagram.
o The total length of the encapsulated IP datagram as computed from o The total length of the encapsulated IP datagram as computed from
the lengths contained in the datagram header(s) MUST NOT exceed the lengths contained in the datagram header(s) MUST NOT exceed
the available field length within the Membership Update message. the available field length within the Membership Update message.
o The computed checksums for the encapsulated IP datagram and its o The computed checksums for the encapsulated IP datagram and its
payload MUST match the values contained therein. Checksum payload MUST match the values contained therein. Checksum
computation and verification varies by protocol; See [RFC0791] for computation and verification varies by protocol; See [RFC0791] for
IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6). IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6).
skipping to change at page 66, line 28 skipping to change at page 66, line 42
o The encapsulated IP datagram is an IGMPv3 Membership Report or o The encapsulated IP datagram is an IGMPv3 Membership Report or
MLDv2 Multicast Listener Report message that contains no group MLDv2 Multicast Listener Report message that contains no group
records. This may often be the case for gateways that records. This may often be the case for gateways that
continuously repeat the membership update cycle even though they continuously repeat the membership update cycle even though they
have no group subscriptions to report. have no group subscriptions to report.
o The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1 o The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1
Multicast Listener Done message. Multicast Listener Done message.
An MLD datagram contained in a Membership Update message may require The IGMP and MLD protocol specifications indicate that senders SHOULD
special handling. The encapsulated datagram generated by a gateway use a link-local source IP address in message datagrams. This
will likely carry an unspecified or link-local source address. If requirement must be relaxed for AMT because gateways and relays do
the relay relies on a standard router-mode MLD protocol not share a common subnet. For this reason, a relay implementation
implementation to process these reports, that implementation may MUST accept IGMP and MLD datagrams regardless of the source IP
silently ignore the MLD report because it carries an unspecified or address they carry.
non-link-local source address - a relay may need to use the contents
of the encapsulated datagram to construct a new datagram with a valid
link-local source address (e.g., a spoofed address in a virtual
subnet defined by the address and netmask assigned to the relay
pseudo-interface) to ensure that the report will not be ignored by
the MLD protocol implementation.
Once a relay has determined that the Membership Update message is Once a relay has determined that the Membership Update message is
valid, it processes the encapsulated IGMP or MLD membership message valid, it processes the encapsulated IGMP or MLD membership message
to update group membership state and communicates with the multicast to update group membership state and communicates with the multicast
protocol to update forwarding state and possibly send multicast protocol to update forwarding state and possibly send multicast
protocol messages towards upstream routers. The relay MUST ignore protocol messages towards upstream routers. The relay MUST ignore
any octets that might exist between the encapsulated IP datagram and any octets that might exist between the encapsulated IP datagram and
the end of the Membership Update message. the end of the Membership Update message.
As described in Section 4.2.2, a relay uses the source IP address and As described in Section 4.2.2, a relay uses the source IP address and
skipping to change at page 69, line 7 skipping to change at page 69, line 16
for that (*,G) or (S,G) entry. for that (*,G) or (S,G) entry.
o Encapsulate the IP datagram in a UDP/IP Membership Data message, o Encapsulate the IP datagram in a UDP/IP Membership Data message,
using the endpoint UDP/IP address as the destination address and using the endpoint UDP/IP address as the destination address and
the unicast relay address and IANA-assigned port as the source the unicast relay address and IANA-assigned port as the source
UDP/IP address. To ensure successful NAT traversal, the source UDP/IP address. To ensure successful NAT traversal, the source
address and port MUST match the destination address and port address and port MUST match the destination address and port
carried by the Membership Update message sent by the gateway to carried by the Membership Update message sent by the gateway to
create the forwarding table entry. create the forwarding table entry.
o If possible, the relay SHOULD compute a valid, non-zero checksum
for the UDP datagram carrying the Membership Data message. See
Section 4.2.2.3.
o Send the message to the gateway. o Send the message to the gateway.
The relay pseudo-interface MUST ignore any other IP datagrams The relay pseudo-interface MUST ignore any other IP datagrams
forwarded to the pseudo-interface. forwarded to the pseudo-interface.
5.3.3.7. State Timers 5.3.3.7. State Timers
A relay MUST maintain a timer or timers whose expiration will trigger A relay MUST maintain a timer or timers whose expiration will trigger
the removal of any group subscriptions and forwarding state the removal of any group subscriptions and forwarding state
previously created for a gateway endpoint should the gateway fail to previously created for a gateway endpoint should the gateway fail to
skipping to change at page 69, line 28 skipping to change at page 69, line 41
A relay MAY use a variant of the IGMPv3/MLDv2 state management A relay MAY use a variant of the IGMPv3/MLDv2 state management
protocol described in Section 6 of [RFC3376] or Section 7 of protocol described in Section 6 of [RFC3376] or Section 7 of
[RFC3810], or may maintain a per-endpoint timer to trigger the [RFC3810], or may maintain a per-endpoint timer to trigger the
deletion of group membership state. deletion of group membership state.
If a per-endpoint timer is used, the relay MUST restart this timer If a per-endpoint timer is used, the relay MUST restart this timer
each time it receives a new Membership Update message from the each time it receives a new Membership Update message from the
gateway endpoint. gateway endpoint.
The RECOMMENDED endpoint timer duration MAY be computed from tunable The endpoint timer duration MAY be computed from tunable IGMP/MLD
IGMP/MLD variables as follows: variables as follows:
((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval ((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval
If IGMP/MLD default values are used for these variables, the gateway If IGMP/MLD default values are used for these variables, the gateway
will timeout after 125s * 2 + 10s = 260s. The timer duration MUST be will timeout after 125s * 2 + 10s = 260s. The timer duration MUST be
greater than the query interval suggested in the last Membership greater than the query interval suggested in the last Membership
Query message sent to the gateway endpoint. Query message sent to the gateway endpoint.
Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the
Query_Response_Interval value SHOULD be greater than or equal to 10s Query_Response_Interval value SHOULD be greater than or equal to 10s
skipping to change at page 74, line 11 skipping to change at page 74, line 11
An attacker forging or modifying a Membership Query or Membership An attacker forging or modifying a Membership Query or Membership
Update message may attempt to embed something other than an IGMP or Update message may attempt to embed something other than an IGMP or
MLD message within the encapsulated IP packet carried by these MLD message within the encapsulated IP packet carried by these
messages in an effort to introduce these into the recipient's IP messages in an effort to introduce these into the recipient's IP
stack. A properly implemented gateway or relay will ignore any such stack. A properly implemented gateway or relay will ignore any such
messages - and may further choose ignore Membership Query messages messages - and may further choose ignore Membership Query messages
that do not contain a IGMP/MLD general queries or Membership Update that do not contain a IGMP/MLD general queries or Membership Update
messages that do not contain IGMP/MLD membership reports. messages that do not contain IGMP/MLD membership reports.
Property implemented gateways and relays will also filter Properly implemented gateways and relays will also filter
encapsulated IP packets that appear corrupted or truncated by encapsulated IP packets that appear corrupted or truncated by
verifying packet length and checksums. verifying packet length and checksums.
7. IANA Considerations 7. IANA Considerations
7.1. IPv4 and IPv6 Anycast Prefix Allocation 7.1. IPv4 and IPv6 Anycast Prefix Allocation
The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated to
to the public AMT Relays to advertise to the native multicast the public AMT Relays to advertise to the native multicast backbone
backbone (as described in Section 4.1.4). The prefix length should (as described in Section 4.1.4). The prefix length should be
be determined by the IANA; the prefix should be large enough to determined by the IANA; the prefix should be large enough to
guarantee advertisement in the default-free BGP networks. guarantee advertisement in the default-free BGP networks.
7.1.1. IPv4 7.1.1. IPv4
A prefix length of 16 will meet this requirement. A prefix length of 24 will meet this requirement.
Internet Systems Consortium (ISC) has offered154.7.0/24 for this
purpose.
7.1.2. IPv6 7.1.2. IPv6
A prefix length of 32 will meet this requirement. IANA has A prefix length of 32 will meet this requirement. IANA has
previously set aside the range 2001::/16 for allocating prefixes for previously set aside the range 2001::/16 for allocating prefixes for
this purpose. this purpose.
7.2. UDP Port number 7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses
IANA should allocate an IPv4 prefix dedicated for use in IGMP
messages exchanged between gateways and relays. This address range
is intended for use within tunnels constructed between a gateway and
relay, and as such, is not intended to be globally routable.
A prefix length of 24 will meet this requirement.
Internet Systems Consortium (ISC) has offered 154.7.1/24 for this
purpose.
7.3. UDP Port number
IANA has reserved UDP port number 2268 for AMT. IANA has reserved UDP port number 2268 for AMT.
8. Contributors 8. Contributors
The following people provided significant contributions to earlier The following people provided significant contributions to the design
versions of this specification: of the protocol and earlier versions of this specification:
Thomas Morin
France Telecom - Orange
2, avenue Pierre Marzin
Lannion 22300
France
Email: thomas.morin@orange.com
Dirk Ooms Dirk Ooms
OneSparrow OneSparrow
Belegstraat 13; 2018 Antwerp; Belegstraat 13; 2018 Antwerp;
Belgium Belgium
EMail: dirk@onesparrow.com EMail: dirk@onesparrow.com
Tom Pusateri Tom Pusateri
!j !j
2109 Mountain High Rd. 2109 Mountain High Rd.
skipping to change at page 77, line 14 skipping to change at page 77, line 14
9. Acknowledgments 9. Acknowledgments
The authors would like to thank the following individuals for their The authors would like to thank the following individuals for their
suggestions, comments, and corrections: suggestions, comments, and corrections:
Amit Aggarwal Amit Aggarwal
Mark Altom Mark Altom
Toerless Eckert Toerless Eckert
Marshall Eubanks Marshall Eubanks
Gorry Fairhurst
Dino Farinacci Dino Farinacci
Lenny Giuliano Lenny Giuliano
Andy Huang Andy Huang
Tom Imburgia Tom Imburgia
Patricia McCrink Patricia McCrink
Han Nguyen Han Nguyen
Doug Nortz Doug Nortz
Pekka Savola Pekka Savola
Robert Sayko Robert Sayko
Greg Shepherd Greg Shepherd
skipping to change at page 78, line 44 skipping to change at page 78, line 44
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
10.2. Informative References 10.2. Informative References
[I-D.ietf-6man-udpchecksums] [I-D.ietf-6man-udpchecksums]
Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
Packets", draft-ietf-6man-udpchecksums-01 (work in Packets", draft-ietf-6man-udpchecksums-02 (work in
progress), October 2011. progress), March 2012.
[I-D.ietf-6man-udpzero] [I-D.ietf-6man-udpzero]
Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum
Considerations", draft-ietf-6man-udpzero-05 (work in Considerations", draft-ietf-6man-udpzero-05 (work in
progress), December 2011. progress), December 2011.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
skipping to change at page 84, line 5 skipping to change at page 84, line 5
Each time a new private secret is computed, the value and the time at Each time a new private secret is computed, the value and the time at
which the value was computed is pushed into a fixed-length queue of which the value was computed is pushed into a fixed-length queue of
recent values (typically only 2-deep). The relay uses the timestamp recent values (typically only 2-deep). The relay uses the timestamp
contained in the MAC field to lookup the appropriate secret. The contained in the MAC field to lookup the appropriate secret. The
relay iterates over the list of secrets, starting with the newest relay iterates over the list of secrets, starting with the newest
entry, until it finds the first secret with a timestamp that is older entry, until it finds the first secret with a timestamp that is older
than that contained in the MAC field. The relay then uses that than that contained in the MAC field. The relay then uses that
secret to compute the MAC that will be compared with that carried by secret to compute the MAC that will be compared with that carried by
the message. the message.
Authors' Addresses Author's Address
Gregory Bumgardner Gregory Bumgardner
Cisco Cisco
3700 Cisco Way 3700 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 853 4993 Phone: +1 408 853 4993
Email: gbumgard@cisco.com Email: gbumgard@cisco.com
Thomas Morin
France Telecom - Orange
2, avenue Pierre Marzin
Lannion 22300
France
Phone: +33 2 96 05 3734
Email: thomas.morin@orange.com
 End of changes. 47 change blocks. 
121 lines changed or deleted 187 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/