draft-ietf-mboned-auto-multicast-13.txt   draft-ietf-mboned-auto-multicast-14.txt 
Network Working Group G. Bumgardner Network Working Group G. Bumgardner
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track April 23, 2012 Intended status: Standards Track June 12, 2012
Expires: October 25, 2012 Expires: December 14, 2012
Automatic Multicast Tunneling Automatic Multicast Tunneling
draft-ietf-mboned-auto-multicast-13 draft-ietf-mboned-auto-multicast-14
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 37 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 October 25, 2012. This Internet-Draft will expire on December 14, 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 2, line 33 skipping to change at page 2, line 33
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 3.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. General Architecture . . . . . . . . . . . . . . . . . . . 8 4.1. General Architecture . . . . . . . . . . . . . . . . . . . 8
4.2. General Operation . . . . . . . . . . . . . . . . . . . . 17 4.2. General Operation . . . . . . . . . . . . . . . . . . . . 17
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 32 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 32
5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 32 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 32
5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 46 5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 47
5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 61 5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 62
6. Security Considerations . . . . . . . . . . . . . . . . . . . 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 73
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
7.2. IPv4 Address Prefix Allocation for IGMP Source 7.2. IPv4 Address Prefix Allocation for IGMP Source
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 76 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 77
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79
10.1. Normative References . . . . . . . . . . . . . . . . . . . 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 79
10.2. Informative References . . . . . . . . . . . . . . . . . . 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 79
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 81 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 82
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 85
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 lack multicast connectivity to networks that carry applications lack multicast connectivity to networks that carry
traffic generated by multicast sources. The reasons for the lack of traffic generated by multicast sources. The reasons for the lack of
skipping to change at page 15, line 32 skipping to change at page 15, line 32
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 receivers to multicast sources - that any gateway could be connecting receivers to multicast sources - that any gateway could be
used 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, because many relays will lack native does not yet allow this, because many relays will lack native
multicast access to sources even though they may be globally multicast access to sources even though they may be globally
accessible via 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.
skipping to change at page 17, line 35 skipping to change at page 17, line 35
Membership Query: Membership Query:
Sent by relays as a response to a Request message. Used to Sent by relays as a response to a Request message. Used to
deliver an encapsulated IGMPv3 or MLDv2 query message to the deliver an encapsulated IGMPv3 or MLDv2 query message to the
gateway. gateway.
Membership Update: Membership Update:
Sent by gateways to deliver an encapsulated IGMP or MLD report/ Sent by gateways to deliver an encapsulated IGMP or MLD report/
leave/done message to a relay. leave/done message to a relay.
Multicast Data: Multicast Data:
Sent by relays to deliver an encapsulated IP multicast datagram to Sent by relays to deliver an encapsulated IP multicast datagram or
a gateway. datagram fragment to a gateway.
Teardown: Teardown:
Sent by gateways to stop the delivery of Multicast Data messages Sent by gateways to stop the delivery of Multicast Data messages
requested in an earlier Membership Update message. requested in an earlier Membership Update message.
The following sections describe how these messages are exchanged to The following sections describe how these messages are exchanged to
execute the protocol. execute the protocol.
4.2.1.1. Relay Discovery Sequence 4.2.1.1. Relay Discovery Sequence
skipping to change at page 18, line 44 skipping to change at page 18, line 44
relay. relay.
3. When the gateway receives the Relay Advertisement message it 3. When the gateway receives the Relay Advertisement message it
verifies that the nonce matches the one sent in the Relay verifies that the nonce matches the one sent in the Relay
Discovery message, and if it does, uses the relay address carried Discovery message, and if it does, uses the relay address carried
by the Relay Advertisement as the destination address for by the Relay Advertisement as the destination address for
subsequent AMT messages. subsequent AMT messages.
Note that the responder need not be a relay - the responder may Note that the responder need not be a relay - the responder may
obtain a relay address by some other means and return the result in obtain a relay address by some other means and return the result in
the Relay Advertisement (i.e. the responder is a load-balancer or the Relay Advertisement (i.e., the responder is a load-balancer or
broker). broker).
4.2.1.2. Membership Update Sequence 4.2.1.2. Membership Update Sequence
There exists a significant difference between normal IGMP and MLD There exists a significant difference between normal IGMP and MLD
behavior and that required by AMT. An IGMP/MLD router acting as a behavior and that required by AMT. An IGMP/MLD router acting as a
querier normally transmits query messages on a network interface to querier normally transmits query messages on a network interface to
construct and refresh group membership state for the connected construct and refresh group membership state for the connected
network. These query messages are multicast to all IGMP/MLD enabled network. These query messages are multicast to all IGMP/MLD enabled
hosts on the network. Each host responds by multicasting report hosts on the network. Each host responds by multicasting report
skipping to change at page 28, line 37 skipping to change at page 28, line 37
UDP/IP address-port pair provided by the Membership Update message. UDP/IP address-port pair provided by the Membership Update message.
4.2.2.1. Address Roaming 4.2.2.1. Address Roaming
As described above, each time a relay receives a Membership Update As described above, each time a relay receives a Membership Update
message from a new source address-port pair, the group subscriptions message from a new source address-port pair, the group subscriptions
described by that message apply to the tunnel endpoint identified by described by that message apply to the tunnel endpoint identified by
that address. that address.
This can cause problems for a gateway if the address carried by the This can cause problems for a gateway if the address carried by the
messages it sends to a relay change unexpectedly. These changes may messages it sends to a relay changes unexpectedly. These changes may
cause the relay to transmit duplicate, undeliverable or unrequested cause the relay to transmit duplicate, undeliverable or unrequested
traffic back towards the gateway or an intermediate device. This may traffic back towards the gateway or an intermediate device. This may
create congestion and have negative consequences for the gateway, its create congestion and have negative consequences for the gateway, its
network, or multicast receivers, and in some cases, may also produce network, or multicast receivers, and in some cases, may also produce
a significant amount of ICMP traffic directed back towards the relay a significant amount of ICMP traffic directed back towards the relay
by a NAT, router or gateway host. by a NAT, router or gateway host.
There are several scenarios in which the address carried by messages There are several scenarios in which the address carried by messages
sent by a gateway may change without that gateway's knowledge, as for sent by a gateway may change without that gateway's knowledge, as for
example, when: example, when:
skipping to change at page 30, line 42 skipping to change at page 30, line 42
| |<--------------------------------------------------| | | |<--------------------------------------------------| |
|_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______| |_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______|
| | | | | | | | | |
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 that 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 or datagram fragment that arrives at the
encapsulated in an AMT message and transmitted to one or more relay is encapsulated in an AMT message and transmitted to one or
gateways via UDP. more 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.
The checksum field contained in the UDP header of the messages The checksum field contained in the UDP header of the messages
requires special consideration. Of primary concern is the cost of requires special consideration. Of primary concern is the cost of
computing a checksum on each replicated multicast packet after it is computing a checksum on each replicated multicast packet after it is
encapsulated for delivery to a gateway. Many routing/forwarding encapsulated for delivery to a gateway. Many routing/forwarding
skipping to change at page 33, line 5 skipping to change at page 33, line 5
Source IP Address - The IP address of the gateway interface on which Source IP Address - The IP address of the gateway interface on which
the gateway will listen for a relay response. Note: The value of the gateway will listen for a relay response. Note: The value of
this field may be changed as a result of network address this field may be changed as a result of network address
translation before arriving at the relay. translation before arriving at the relay.
Source UDP Port - The UDP port number on which the gateway will Source UDP Port - The UDP port number on which the gateway will
listen for a relay response. Note: The value of this field may be listen for a relay response. Note: The value of this field may be
changed as a result of network address translation before arriving changed as a result of network address translation before arriving
at the relay. at the relay.
Destination IP Address - An anycast or unicast IP address, i.e. the Destination IP Address - An anycast or unicast IP address, i.e., the
Relay Discovery Address advertised by a relay. Relay Discovery Address advertised by a relay.
Destination UDP Port - The IANA-assigned AMT port number. Destination UDP Port - The IANA-assigned AMT port number.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=1 | Reserved | | V=0 |Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce | | Discovery Nonce |
skipping to change at page 34, line 6 skipping to change at page 34, line 6
The Relay Advertisement message is used to supply a gateway with a The Relay Advertisement message is used to supply a gateway with a
unicast IP address of a relay. A relay sends this message to a unicast IP address of a relay. A relay sends this message to a
gateway when it receives a Relay Discovery message from that gateway. gateway when it receives a Relay Discovery message from that gateway.
The UDP/IP datagram containing this message MUST carry a valid, non- The UDP/IP datagram containing this message MUST carry a valid, non-
zero UDP checksum and carry the following IP address and UDP port zero UDP checksum and carry the following IP address and UDP port
values: values:
Source IP Address - The destination IP address carried by the Relay Source IP Address - The destination IP address carried by the Relay
Discovery message (i.e. the Relay Discovery Address advertised by Discovery message (i.e., the Relay Discovery Address advertised by
the relay). the relay).
Source UDP Port - The destination UDP port carried by the Relay Source UDP Port - The destination UDP port carried by the Relay
Discovery message (i.e. the IANA-assigned AMT port number). Discovery message (i.e., the IANA-assigned AMT port number).
Destination IP Address - The source IP address carried by the Relay Destination IP Address - The source IP address carried by the Relay
Discovery message. Note: The value of this field may be changed Discovery message. Note: The value of this field may be changed
as a result of network address translation before arriving at the as a result of network address translation before arriving at the
gateway. gateway.
Destination UDP Port - The source UDP port carried by the Relay Destination UDP Port - The source UDP port carried by the Relay
Discovery message. Note: The value of this field may be changed Discovery message. Note: The value of this field may be changed
as a result of network address translation before arriving at the as a result of network address translation before arriving at the
gateway. gateway.
skipping to change at page 35, line 16 skipping to change at page 35, line 16
A 32-bit value copied from the Discovery Nonce field A 32-bit value copied from the Discovery Nonce field
(Section 5.1.1.4) contained in the Relay Discovery message. The (Section 5.1.1.4) contained in the Relay Discovery message. The
gateway uses this value to match a Relay Advertisement to a Relay gateway uses this value to match a Relay Advertisement to a Relay
Discovery message. Discovery message.
5.1.2.5. Relay Address 5.1.2.5. Relay Address
The unicast IPv4 or IPv6 address of the relay. A gateway uses the The unicast IPv4 or IPv6 address of the relay. A gateway uses the
length of the UDP datagram containing the Relay Advertisement message length of the UDP datagram containing the Relay Advertisement message
to determine the address family; i.e. length - 8 = 4 (IPv4) or 16 to determine the address family; i.e., length - 8 = 4 (IPv4) or 16
(IPv6). (IPv6). The relay returns an IP address for the protocol used to
send the Relay Discovery message, i.e., an IPv4 relay address for an
IPv4 discovery address or an IPv6 relay address for an IPv6 discovery
address.
5.1.3. Request 5.1.3. Request
A gateway sends a Request message to a relay to solicit a Membership A gateway sends a Request message to a relay to solicit a Membership
Query response. Query response.
The successful delivery of this message marks the start of the first The successful delivery of this message marks the start of the first
stage in the three-way handshake used to create or update state stage in the three-way handshake used to create or update state
within a relay. within a relay.
skipping to change at page 37, line 10 skipping to change at page 37, line 20
The successful delivery of this message to a gateway marks the start The successful delivery of this message to a gateway marks the start
of the second-stage in the three-way handshake used to create or of the second-stage in the three-way handshake used to create or
update tunnel state within a relay. update tunnel state within a relay.
The UDP/IP datagram containing this message MUST carry a valid, non- The UDP/IP datagram containing this message MUST carry a valid, non-
zero UDP checksum and carry the following IP address and UDP port zero UDP checksum and carry the following IP address and UDP port
values: values:
Source IP Address - The destination IP address carried by the Source IP Address - The destination IP address carried by the
Request message (i.e. the unicast IP address of the relay). Request message (i.e., the unicast IP address of the relay).
Source UDP Port - The destination UDP port carried by the Request Source UDP Port - The destination UDP port carried by the Request
message (i.e. the IANA-assigned AMT port number). message (i.e., the IANA-assigned AMT port number).
Destination IP Address - The source IP address carried by the Destination IP Address - The source IP address carried by the
Request message. Note: The value of this field may be changed as Request message. Note: The value of this field may be changed as
a result of network address translation before arriving at the a result of network address translation before arriving at the
gateway. gateway.
Destination UDP Port - The source UDP port carried by the Request Destination UDP Port - The source UDP port carried by the Request
message. Note: The value of this field may be changed as a result message. Note: The value of this field may be changed as a result
of network address translation before arriving at the gateway. of network address translation before arriving at the gateway.
skipping to change at page 38, line 35 skipping to change at page 39, line 14
this flag before attempting to create new group subscription state on this flag before attempting to create new group subscription state on
the relay to determine whether it should restart relay discovery. A the relay to determine whether it should restart relay discovery. A
gateway that has already created group subscriptions on the relay may gateway that has already created group subscriptions on the relay may
ignore this flag. Support for this flag is RECOMMENDED. ignore this flag. Support for this flag is RECOMMENDED.
5.1.4.5. Gateway Address (G) Flag 5.1.4.5. Gateway Address (G) Flag
A 1-bit flag set to 0 to indicate that the message does NOT carry the A 1-bit flag set to 0 to indicate that the message does NOT carry the
Gateway Port and Gateway IP Address fields, and 1 to indicate that it Gateway Port and Gateway IP Address fields, and 1 to indicate that it
does. A relay implementation that supports the optional teardown does. A relay implementation that supports the optional teardown
procedure (See Section 5.3.3.5) SHOULD set this flag and and the procedure (See Section 5.3.3.5) SHOULD set this flag and the Gateway
Gateway Address field values. If a relay sets this flag, it MUST Address field values. If a relay sets this flag, it MUST also
also include the Gateway Address fields in the message. A gateway include the Gateway Address fields in the message. A gateway
implementation that does not support the optional teardown procedure implementation that does not support the optional teardown procedure
(See Section 5.2.3.7) MAY ignore this flag and the Gateway Address (See Section 5.2.3.7) MAY ignore this flag and the Gateway Address
fields if they are present. fields if they are present.
5.1.4.6. Response MAC 5.1.4.6. Response MAC
A 48-bit source authentication hash generated by the relay as A 48-bit source authentication hash generated by the relay as
described in Section 5.3.5. The gateway echoes this value in described in Section 5.3.5. The gateway echoes this value in
subsequent Membership Update messages to allow the relay to verify subsequent Membership Update messages to allow the relay to verify
that the sender of a Membership Update message was the intended that the sender of a Membership Update message was the intended
skipping to change at page 39, line 43 skipping to change at page 40, line 19
Membership Update messages, and optionally, the number of times to Membership Update messages, and optionally, the number of times to
send a Teardown message. send a Teardown message.
5.1.4.9. Gateway Address Fields 5.1.4.9. Gateway Address Fields
The Gateway Port Number and Gateway Address fields are present in the The Gateway Port Number and Gateway Address fields are present in the
Membership Query message if, and only if, the "G" flag is set. Membership Query message if, and only if, the "G" flag is set.
A gateway need not parse the encapsulated IP datagram to determine A gateway need not parse the encapsulated IP datagram to determine
the position of these fields within the UDP datagram containing the the position of these fields within the UDP datagram containing the
Membership Query messsage - if the G-flag is set, the gateway may Membership Query message - if the G-flag is set, the gateway may
simply subtract the total length of the fields (18 bytes) from the simply subtract the total length of the fields (18 bytes) from the
total length of the UDP datagram to obtain the offset. total length of the UDP datagram to obtain the offset.
5.1.4.9.1. Gateway Port Number 5.1.4.9.1. Gateway Port Number
A 16-bit UDP port containing a UDP port value. A 16-bit UDP port containing a UDP port value.
The Relay sets this field to the value of the UDP source port of the The Relay sets this field to the value of the UDP source port of the
Request message that triggered the Query message. Request message that triggered the Query message.
skipping to change at page 40, line 36 skipping to change at page 41, line 13
A gateway cannot send a Membership Update message until a receives a A gateway cannot send a Membership Update message until a receives a
Membership Query from a relay because the gateway must copy the Membership Query from a relay because the gateway must copy the
Request Nonce and Response MAC values carried by a Membership Query Request Nonce and Response MAC values carried by a Membership Query
into any subsequent Membership Update messages it sends back to that into any subsequent Membership Update messages it sends back to that
relay. These values are used by the relay to verify that the sender relay. These values are used by the relay to verify that the sender
of the Membership Update message was the recipient of the Membership of the Membership Update message was the recipient of the Membership
Query message from which these values were copied. Query message from which these values were copied.
The successful delivery of this message to the relay marks the start The successful delivery of this message to the relay marks the start
of the final stage in the three-way handshake. This stage concludes of the final stage in the three-way handshake. This stage concludes
when the relay successfully verifies that sender of the Message when the relay successfully verifies that sender of the Membership
Update message was the recipient of a Membership Query message sent Update message was the recipient of a Membership Query message sent
earlier. At this point, the relay may proceed to process the earlier. At this point, the relay may proceed to process the
encapsulated IGMP or MLD message to create or update group membership encapsulated IGMP or MLD message to create or update group membership
and forwarding state on behalf of the gateway. and forwarding state on behalf of the gateway.
The UDP/IP datagram containing this message MUST carry a valid, non- The UDP/IP datagram containing this message MUST carry a valid, non-
zero UDP checksum and carry the following IP address and UDP port zero UDP checksum and carry the following IP address and UDP port
values: values:
Source IP Address - The IP address of the gateway interface on which Source IP Address - The IP address of the gateway interface on which
skipping to change at page 42, line 34 skipping to change at page 43, line 22
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 The source address carried by the message should be set as described
in Section 5.2.1. 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 multicast IP
packet to a gateway. datagram or datagram fragment 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
IP address and UDP port values: IP address and UDP port values:
Source IP Address - The unicast IP address of the relay. Source IP Address - The unicast IP address of the relay.
Source UDP Port - The IANA-assigned AMT port number. Source UDP Port - The IANA-assigned AMT port number.
Destination IP Address - A tunnel endpoint IP address, i.e. the Destination IP Address - A tunnel endpoint IP address, i.e., the
source IP address carried by the Membership Update message sent by source IP address carried by the Membership Update message sent by
a gateway to indicate an interest in receiving the multicast a gateway to indicate an interest in receiving the multicast
packet. Note: The value of this field may be changed as a result packet. Note: The value of this field may be changed as a result
of network address translation before arriving at the gateway. of network address translation before arriving at the gateway.
Destination UDP Port - A tunnel endpoint UDP port, i.e. the source Destination UDP Port - A tunnel endpoint UDP port, i.e., the source
UDP port carried by the Membership Update message sent by a UDP port carried by the Membership Update message sent by a
gateway to indicate an interest in receiving the multicast packet. gateway to indicate an interest in receiving the multicast packet.
Note: The value of this field may be changed as a result of Note: The value of this field may be changed as a result of
network address translation before arriving at the gateway. network address translation before arriving at the gateway.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=6 | Reserved | | | V=0 |Type=6 | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
skipping to change at page 43, line 40 skipping to change at page 44, line 34
The type number for this message is 6. The type number for this message is 6.
5.1.6.3. Reserved 5.1.6.3. Reserved
Bits that MUST be set to zero by the relay and ignored by the Bits that MUST be set to zero by the relay and ignored by the
gateway. gateway.
5.1.6.4. IP Multicast Data 5.1.6.4. IP Multicast Data
A complete IPv4 or IPv6 Multicast datagram. A complete IPv4 or IPv6 multicast datagram or datagram fragment.
5.1.7. Teardown 5.1.7. Teardown
A gateway sends a Teardown message to a relay to request that it stop A gateway sends a Teardown message to a relay to request that it stop
sending Multicast Data messages to a tunnel endpoint created by an sending Multicast Data messages to a tunnel endpoint created by an
earlier Membership Update message. A gateway sends this message when earlier Membership Update message. A gateway sends this message when
it detects that a Request message sent to the relay carries an it detects that a Request message sent to the relay carries an
address that differs from that carried by a previous Request message. address that differs from that carried by a previous Request message.
The gateway uses the Gateway IP Address and Gateway Port Number The gateway uses the Gateway IP Address and Gateway Port Number
Fields in the Membership Query message to detect these address Fields in the Membership Query message to detect these address
skipping to change at page 45, line 24 skipping to change at page 46, line 16
Reserved bits that MUST be set to zero by the gateway and ignored by Reserved bits that MUST be set to zero by the gateway and ignored by
the relay. the relay.
5.1.7.4. Response MAC 5.1.7.4. Response MAC
A 48-bit value copied from the Response MAC field (Section 5.1.4.6) A 48-bit value copied from the Response MAC field (Section 5.1.4.6)
in the last Membership Query message the relay sent to the gateway in the last Membership Query message the relay sent to the gateway
endpoint address of the tunnel to be torn down. The gateway endpoint endpoint address of the tunnel to be torn down. The gateway endpoint
address is provided by the Gateway IP Address and Gateway Port Number address is provided by the Gateway IP Address and Gateway Port Number
fields carried by the Membership Query message. fields carried by the Membership Query message. The relay validates
the Teardown message by comparing this value with one computed from
the Request Nonce, Gateway Port Number and Gateway IP Address fields
(just as it does in the Membership Update message).
5.1.7.5. Request Nonce 5.1.7.5. Request Nonce
A 32-bit value copied from the Request Nonce field (Section 5.1.4.7) A 32-bit value copied from the Request Nonce field (Section 5.1.4.7)
in the last Membership Query message the relay sent to the gateway in the last Membership Query message the relay sent to the gateway
endpoint address of the tunnel to be torn down. The gateway endpoint endpoint address of the tunnel to be torn down. The gateway endpoint
address is provided by the Gateway IP Address and Gateway Port Number address is provided by the Gateway IP Address and Gateway Port Number
fields carried by the Membership Query message. This value must fields carried by the Membership Query message. This value must
match that used by the relay to compute the value stored in the match that used by the relay to compute the value stored in the
Response MAC field. Response MAC field.
skipping to change at page 46, line 48 skipping to change at page 47, line 42
options and header values called for in [RFC3376], with the following options and header values called for in [RFC3376], with the following
exception; the source IP address for an IGMP report datagram MAY be exception; the source IP address for an IGMP report datagram MAY be
set to the "unspecified" address (all octets are zero ) but SHOULD be set to the "unspecified" address (all octets are zero ) but SHOULD be
set to an address in the address range specifically assigned by IANA set to an address in the address range specifically assigned by IANA
for use in the IGMP messages sent from a gateway to a relay (i.e. for use in the IGMP messages sent from a gateway to a relay (i.e.
154.7.1.2 through 154.7.1.254 as described in Section 7). This 154.7.1.2 through 154.7.1.254 as described in Section 7). This
exception is made because the gateway pseudo-interface might not exception is made because the gateway pseudo-interface might not
possess an assigned address, and even if such an address exists, that 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 address would not be a valid link-local source address on any relay
interface. The rationale for using the aforementioned source interface. The rationale for using the aforementioned source
addresses is primary one of convenience - a relay will accept an IGMP addresses is primarily one of convenience - a relay will accept an
report carried by a Membership Update message regardless of the IGMP report carried by a Membership Update message regardless of the
source address it carries. See Section 5.3.1. source address it carries. See Section 5.3.1.
The IP-encapsulated MLD messages generated by the gateway IPv6/MLD The IP-encapsulated MLD messages generated by the gateway IPv6/MLD
implementation MUST conform to the description found in Section 5 of implementation MUST conform to the description found in Section 5 of
[RFC3810]. These datagrams MUST possess the IP headers, header [RFC3810]. These datagrams MUST possess the IP headers, header
options and header values called for in [RFC3810], with the following options and header values called for in [RFC3810], with the following
exception; the source IP address for an MLD report datagram MAY be 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 the "unspecified" address (all octets are zero ) but SHOULD be
set to an IPv6 link-local address in the range FE80::/64 excluding 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 FE80::1 and FE80::2. This exception is made because the gateway
skipping to change at page 47, line 47 skipping to change at page 48, line 41
accept the MLD datagram regardless of the IP source address carried accept the MLD datagram regardless of the IP source address carried
by that datagram. 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. Relay Discovery Address
Before a gateway implementation can execute the AMT protocol to
request and receive multicast traffic, it must be supplied with a
unicast relay address. A gateway implementation may rely on static
address assignment or support some form of dynamic address discovery.
This specification does not require the use of any particular method
to obtain a relay address - an implementation may employ any method
that returns a suitable relay address.
5.2.2.2. Static Relay Discovery Address
If a gateway implementation uses AMT relay discovery to obtain a If a gateway implementation uses AMT relay discovery to obtain a
relay address, it must first be supplied with a relay discovery relay address, it must first be supplied with a relay discovery
address. The relay discovery address may be an anycast or unicast address. The relay discovery address may be an anycast or unicast
address. A gateway implementation may rely on a static address address. A gateway implementation may rely on a static address
assignment or some form of dynamic address discovery. This assignment or some form of dynamic address discovery. This
specification does not require that a gateway implementation use any specification does not require that a gateway implementation use any
particular method to obtain a relay discovery address - an particular method to obtain a relay discovery address - an
implementation may employ any method that returns a suitable relay implementation may employ any method that returns a suitable relay
discovery address. discovery address.
5.2.2.2. Relay Address
Before a gateway implementation can execute the AMT protocol to
request and receive multicast traffic, it must be supplied with a
unicast relay address. A gateway implementation may rely on static
address assignment or support some form of dynamic address discovery.
This specification does not require the use of any particular method
to obtain a relay address - an implementation may employ any method
that returns a suitable relay address.
5.2.2.3. Upstream Interface Selection 5.2.2.3. Upstream Interface Selection
A gateway host that possesses multiple network interfaces or A gateway host that possesses multiple network interfaces or
addresses may allow for an explicit selection of the interface to use addresses may allow for an explicit selection of the interface to use
when communicating with a relay. The selection might be made to when communicating with a relay. The selection might be made to
satisfy connectivity, tunneling or IP protocol requirements. satisfy connectivity, tunneling or IP protocol requirements.
5.2.2.4. Optional Retransmission Parameters 5.2.2.4. Optional Retransmission Parameters
A gateway implementation that supports retransmission MAY require the A gateway implementation that supports retransmission MAY require the
skipping to change at page 50, line 13 skipping to change at page 51, line 7
A gateway MUST ignore a Multicast Data message if it fails to satisfy A gateway MUST ignore a Multicast Data message if it fails to satisfy
any of the following requirements: any of the following requirements:
o The source IP address and UDP port carried by the Multicast Data o The source IP address and UDP port carried by the Multicast Data
message MUST be equal to the destination IP address and UDP port message MUST be equal to the destination IP address and UDP port
carried by the matching Membership Update message (i.e., the carried by the matching Membership Update message (i.e., the
current relay address). current relay address).
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 relevant 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 Because AMT uses UDP encapsulation to deliver multicast datagrams to
gateways, it qualifies as a tunneling protocol subject to the gateways, it qualifies as a tunneling protocol subject to the
limitations described in [I-D.ietf-6man-udpzero]. If supported, a limitations described in [I-D.ietf-6man-udpzero]. If supported, a
skipping to change at page 50, line 47 skipping to change at page 51, line 41
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:
o When a gateway pseudo-interface is started (enabled). o When a gateway pseudo-interface is started (enabled).
o When the gateway wishes to report a group subscription when none o When the gateway wishes to report a group subscription when none
currently exist. currently exist.
o Before sending the next Request message in a membership update o Before sending the next Request message in a membership update
cycle, i.e. each time the query timer expires (see below). cycle, i.e., each time the query timer expires (see below).
o After the gateway fails to receive a response to a Request o After the gateway fails to receive a response to a Request
message. message.
o After the gateway receives a Membership Query message with the o After the gateway receives a Membership Query message with the
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
skipping to change at page 56, line 12 skipping to change at page 57, line 12
datagram within it, if the message fails to satisfy any of the datagram within it, if the message fails to satisfy any of the
following requirements: following requirements:
o The gateway MUST be waiting for a Membership Query message. o The gateway MUST be waiting for a Membership Query message.
o The Request Nonce value contained in the Membership Query MUST o The Request Nonce value contained in the Membership Query MUST
equal the Request Nonce value contained in the Request message. equal the Request Nonce value contained in the Request message.
o The source IP address and UDP port of the Membership Query MUST o The source IP address and UDP port of the Membership Query MUST
equal the destination IP address and UDP port of the matching equal the destination IP address and UDP port of the matching
Request message (i.e. the current relay address). Request message (i.e., the current relay address).
o The encapsulated IP datagram MUST carry an IGMPv3 or MLDv2 o The encapsulated IP datagram MUST carry an IGMPv3 or MLDv2
message. The protocol MUST match the protocol identified by the message. The protocol MUST match the protocol identified by the
"P" flag in the Request message. "P" flag in the Request message.
o The IGMPv3 or MLDv2 message MUST be a general query message. o The IGMPv3 or MLDv2 message MUST be a general query message.
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 Query message. the available field length within the Membership Query message.
skipping to change at page 56, line 40 skipping to change at page 57, 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.
The IGMP and MLD protocol specifications indicate that senders should The MLD protocol specification indicates that senders should use a
use a link-local source IP address in message datagrams. This link-local source IP address in message datagrams. This requirement
requirement must be relaxed for AMT because gateways and relays do must be relaxed for AMT because gateways and relays do not normally
not share a common subnet. For this reason, a gateway implementation share a common subnet. For this reason, a gateway implementation
MUST accept IGMP and MLD query message datagrams regardless of the MUST accept MLD (and IGMP) query message datagrams regardless of the
source IP address they carry. source IP address they carry. This may require additional processing
on the part of the gateway that might be avoided if the relay and
gateway use the IPv4 and IPv6 addresses allocated for use in AMT
encapsulated control packets as described in Section 5.2.1.
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
skipping to change at page 58, line 24 skipping to change at page 59, line 26
o IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener o IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener
Report or an MLDv1 Multicast Listener Done message as described in Report or an MLDv1 Multicast Listener Done message as described in
Section 5 of [RFC3810]. Section 5 of [RFC3810].
The gateway must be prepared to receive these messages any time the The gateway must be prepared to receive these messages any time the
pseudo-interface is running. The gateway MUST ignore any datagrams pseudo-interface is running. The gateway MUST ignore any datagrams
not listed above. not listed above.
A gateway that waits to start a membership update cycle until after A gateway that waits to start a membership update cycle until after
it receives an IGMP/MLD state-change message MAY: it receives a datagram containing an IGMP/MLD state-change message
MAY:
o Discard datagrams containing IGMP/MLD messages until it receives a o Discard IGMP or MLD datagrams until it receives a Membership Query
Membership Query message, at which time it processes the message, at which time it processes the Membership Query message
Membership Query message as normal to eventually produce a as normal to eventually produce a current-state report on the
current-state report on the pseudo-interface which describes the pseudo-interface which describes the end state (RECOMMENDED).
end state (RECOMMENDED).
o Insert IGMP/MLD messages into a queue for transmission after it o Insert IGMP or MLD datagrams into a queue for transmission after
receives a Membership Query message. it receives a Membership Query message.
If the datagram contains a valid IGMP or MLD message, the gateway If and when a gateway receives a Membership Query message (for IGMP
sends it to the relay as described in the next section. or MLD) it sends any queued or incoming IGMP or MLD datagrams 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
skipping to change at page 59, line 51 skipping to change at page 61, line 7
group memberships created by the gateway. group memberships created by the gateway.
When a gateway constructs a Teardown message, it MUST copy the When a gateway constructs a Teardown message, it MUST copy the
Request Nonce, Response MAC, Gateway IP Address and Gateway Port Request Nonce, Response MAC, Gateway IP Address and Gateway Port
Number fields from the Membership Query message that provided the Number fields from the Membership Query message that provided the
Response MAC for the last Membership Update message sent, into the Response MAC for the last Membership Update message sent, into the
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 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. The RECOMMENDED transmitting unsolicited state-change reports. The RECOMMENDED
default delay value is 1 second. 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
skipping to change at page 61, line 47 skipping to change at page 62, line 50
A relay requires a subset of router-mode IGMP and MLD functionality A relay requires a subset of router-mode IGMP and MLD functionality
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 in 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. A relay MUST accept IGMP and MLD report datagrams generation. A relay MUST accept IGMP and MLD report datagrams
regardless of the IP source address carried by those 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
skipping to change at page 63, line 16 skipping to change at page 64, line 21
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.
The relay MUST copy the value contained in the Discovery Nonce field The relay MUST copy the value contained in the Discovery Nonce field
of the Relay Discovery message into the Discovery Nonce field in the of the Relay Discovery message into the Discovery Nonce field in the
the Relay Advertisement message. Relay Advertisement message.
If the Relay Discovery message was received as an IPv4 datagram, the If the Relay Discovery message was received as an IPv4 datagram, the
relay MUST return an IPv4 address in the Relay Address field of the relay MUST return an IPv4 address in the Relay Address field of the
Relay Advertisement message. If the Relay Discovery message was Relay Advertisement message. If the Relay Discovery message was
received as an IPv6 datagram, the relay may return an IPv4 or IPv6 received as an IPv6 datagram, the relay MUST return an IPv6 address
address in the Relay Address field. in the Relay Address field.
5.3.3.3. Handling a Request Message 5.3.3.3. Handling a Request Message
This section describes relay requirements related to the membership This section describes relay requirements related to the membership
query portion of the message sequence described in Section 4.2.1.2. query portion of the message sequence described in Section 4.2.1.2.
When a relay receives a Request message it responds by sending a When a relay receives a Request message it responds by sending a
Membership Query message back to the source of the Request message. Membership Query message back to the source of the Request message.
The relay MUST use the source IP address and UDP port of the Request The relay MUST use the source IP address and UDP port of the Request
skipping to change at page 64, line 13 skipping to change at page 65, line 17
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.
An IGMPv3 general query datagram that a relay encapsulates within a The IGMPv3 general query datagram that a relay encapsulates within a
Membership Query message MUST conform to the descriptions found in Membership Query message MUST conform to the descriptions found in
Section 4.1 of [RFC3376]. These datagrams MUST possess the IP Section 4.1 of [RFC3376]. These datagrams MUST possess the IP
headers, header options and header values called for in [RFC3376], headers, header options and header values called for in [RFC3376],
with the following exception; the source IP address for an IGMP with the following exception; the source IP address for an IGMP
general query datagram MAY be set to the "unspecified" address (all general query datagram MAY be set to the "unspecified" address (all
octets are zero) but SHOULD be set to an address in the address range octets are zero) but SHOULD be set to an address in the address range
specifically assigned by IANA for use in the IGMP messages sent from specifically assigned by IANA for use in the IGMP messages sent from
a relay to a gateway (i.e. 154.7.1.1 as described in Section 7). a relay to a gateway (i.e. 154.7.1.1 as described in Section 7).
This exception is made because any address that a relay might may not This exception is made because the source address that a relay might
be a valid source address on any gateway interface. The rationale normally send may not be a valid source address on any gateway
for using the aforementioned source addresses is primary one of interface. The rationale for using the aforementioned source
convenience - a gateway will accept an IGMP query regardless of the addresses is primary one of convenience - a gateway will accept an
source address it carries. See Section 5.2.1. 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 The MLDv2 general query datagram that a relay encapsulates within a
Membership Query message MUST conform to the descriptions found in Membership Query message MUST conform to the descriptions found in
Section 5.1 of [RFC3810]. These datagrams MUST possess the IP Section 5.1 of [RFC3810]. These datagrams MUST possess the IP
headers, header options and header values called for in [RFC3810], headers, header options and header values called for in [RFC3810],
with the following exception; the source IP address for an MLD with the following exception; the source IP address for an MLD
general query datagram MAY be set to the "unspecified" address (all 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 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- 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 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. will accept an MLD query regardless of the source address it carries.
See Section 5.2.1. See Section 5.2.1.
skipping to change at page 65, line 4 skipping to change at page 66, line 9
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.
A relay MUST set the Querier's Robustness Variable (QRV) field in the A relay MUST set the Querier's Robustness Variable (QRV) field in the
general query to a non-zero value. This value SHOULD be greater than general query to a non-zero value. This value SHOULD be greater than
one. If a gateway retransmits a membership state change messages, it one. If a gateway retransmits membership state change messages, it
will retransmit them (robustness variable - 1) times. will retransmit them (robustness variable - 1) times.
A relay SHOULD set the Max Resp Code field in the general query to a A relay SHOULD set the Max Resp Code field in the general query to a
value of 1 to trigger an immediate response from the gateway (some value of 1 to trigger an immediate response from the gateway (some
host IGMP/MLD implementations may not accept a value of zero). A host IGMP/MLD implementations may not accept a value of zero). A
relay SHOULD NOT use the IGMPv2/MLDv2 Query Response Interval relay SHOULD NOT use the IGMPv2/MLDv2 Query Response Interval
variable, if available, to generate the Max Resp Code field value as variable, if available, to generate the Max Resp Code field value as
the Query Response Interval variable is used in setting the duration the Query Response Interval variable is used in setting the duration
of group state timers and must not be set to such a small value. See of group state timers and must not be set to such a small value. See
Section 5.3.3.7. Section 5.3.3.7.
skipping to change at page 67, line 30 skipping to change at page 68, line 36
number of endpoints, or a limit on the total number of endpoints for number of endpoints, or a limit on the total number of endpoints for
a given source address, then the relay MAY ignore the Membership a given source address, then the relay MAY ignore the Membership
Update message and possibly withdraw any Relay Discovery Address Update message and possibly withdraw any Relay Discovery Address
Prefix announcement that it might have made. See Section 5.3.3.8. Prefix announcement that it might have made. See Section 5.3.3.8.
A relay MUST maintain some form of group membership database for each A relay MUST maintain some form of group membership database for each
endpoint. The per-endpoint databases are used update a forwarding endpoint. The per-endpoint databases are used update a forwarding
table containing entries that map an (*,G) or (S,G) subscription to a table containing entries that map an (*,G) or (S,G) subscription to a
list of tunnel endpoints. list of tunnel endpoints.
A relay MUST maintain some form group membership database A relay MUST maintain some form of group membership database
representing a merger of the group membership databases of all representing a merger of the group membership databases of all
endpoints. The merged group membership database is used to update endpoints. The merged group membership database is used to update
upstream multicast forwarding state. upstream multicast forwarding state.
A relay MUST maintain a forwarding table that maps each unique (*,G) A relay MUST maintain a forwarding table that maps each unique (*,G)
and (S,G) subscription to a list of tunnel endpoints. A relay uses and (S,G) subscription to a list of tunnel endpoints. A relay uses
this forwarding table to provide the destination address when this forwarding table to provide the destination address when
performing UDP/IP encapsulation of the incoming multicast IP performing UDP/IP encapsulation of the incoming multicast IP
datagrams to form Multicast Data messages. datagrams to form Multicast Data messages.
skipping to change at page 68, line 45 skipping to change at page 69, line 51
state and possibly send prune/leave messages towards upstream state and possibly send prune/leave messages towards upstream
routers. routers.
5.3.3.6. Handling Multicast IP Datagrams 5.3.3.6. Handling Multicast IP Datagrams
When a multicast IP datagram is forwarded to the relay pseudo- When a multicast IP datagram is forwarded to the relay pseudo-
interface, the relay MUST, for each gateway that has expressed an interface, the relay MUST, for each gateway that has expressed an
interest in receiving the datagram, encapsulate the IP datagram into interest in receiving the datagram, encapsulate the IP datagram into
a Multicast Data message and send that message to the gateway. This a Multicast Data message and send that message to the gateway. This
process is highly implementation dependent, but conceptually requires process is highly implementation dependent, but conceptually requires
the follow steps: the following steps:
o Use the IP datagram source and destination address to look up the o Use the IP datagram source and destination address to look up the
appropriate (*,G) or (S,G) entry in the endpoint forwarding table appropriate (*,G) or (S,G) entry in the endpoint forwarding table
created for the pseudo-interface as a result of IGMP/MLD created for the pseudo-interface as a result of IGMP/MLD
processing. processing.
o Possibly replicate the datagram for each gateway endpoint listed o Possibly replicate the datagram for each gateway endpoint listed
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,
skipping to change at page 70, line 26 skipping to change at page 71, line 31
SHOULD set the L-flag in any Membership Query messages it returns to SHOULD set the L-flag in any Membership Query messages it returns to
gateways while in this state. gateways while in this state.
If the relay receives an update from a gateway that adds group If the relay receives an update from a gateway that adds group
membership or forwarding state for an endpoint that has already membership or forwarding state for an endpoint that has already
reached maximum allowable state entries, the relay SHOULD continue to reached maximum allowable state entries, the relay SHOULD continue to
accept updates from the gateway but ignore any group membership/ accept updates from the gateway but ignore any group membership/
forwarding state additions requested by that gateway. forwarding state additions requested by that gateway.
If the relay receives an update from a gateway that would create a If the relay receives an update from a gateway that would create a
new tunnel endpoint for a source IP address that has already reach new tunnel endpoint for a source IP address that has already reached
maximum allowable number of endpoints (maximum UDP ports), it should the maximum allowable number of endpoints (maximum UDP ports), it
simply ignore the Membership Update. should simply ignore the Membership Update.
5.3.4. Shutdown 5.3.4. Shutdown
The following steps should be treated as an abstract description of The following steps should be treated as an abstract description of
the shutdown procedure for a relay: the shutdown procedure for a relay:
o Withdraw the Relay Discovery Address Prefix advertisement (if o Withdraw the Relay Discovery Address Prefix advertisement (if
used). used).
o Stop listening for Relay Discovery messages. o Stop listening for Relay Discovery messages.
skipping to change at page 73, line 40 skipping to change at page 74, line 40
thereby changing or interrupting the multicast traffic flows. thereby changing or interrupting the multicast traffic flows.
A passive eavesdropper may also spoof Multicast Data messages in an A passive eavesdropper may also spoof Multicast Data messages in an
attempt to overload the gateway or disrupt or supplant existing attempt to overload the gateway or disrupt or supplant existing
traffic flows. A properly implemented gateway will filter Multicast traffic flows. A properly implemented gateway will filter Multicast
Data messages that do not originate from the expected relay address Data messages that do not originate from the expected relay address
and should filter non-multicast packets and multicast IP packets and should filter non-multicast packets and multicast IP packets
whose group or source addresses are not included in the current whose group or source addresses are not included in the current
reception state for the gateway pseudo-interface. reception state for the gateway pseudo-interface.
An active eavesdropper may launch a man-in-the-middle attack in which
messages normally exchanged between a gateway and relay are
intercepted, modified, spoofed or discarded by the attacker. The
attacker may deny access to, modify or replace requested multicast
traffic. The AMT protocol provides no means for detecting or
defending against a man-in-the-middle attack - any such functionality
must be provided by multicast receiver applications through
independent detection and validation of incoming multicast datagrams.
The anycast discovery technique for finding relays (see The anycast discovery technique for finding relays (see
Section 4.1.4) introduces a risk that a rogue router or a rogue AS Section 4.1.4) introduces a risk that a rogue router or a rogue AS
could introduce a bogus route to a specific Relay Discovery Address could introduce a bogus route to a specific Relay Discovery Address
prefix, and thus divert or absorb Relay Discovery messages sent by prefix, and thus divert or absorb Relay Discovery messages sent by
gateways. Network managers must guarantee the integrity of their gateways. Network managers must guarantee the integrity of their
routing to a particular Relay Discovery Address prefix in much the routing to a particular Relay Discovery Address prefix in much the
same way that they guarantee the integrity of all other routes. same way that they guarantee the integrity of all other routes.
6.3. Encapsulated IP Packets 6.3. Encapsulated IP Packets
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 to 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.
Properly 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
skipping to change at page 75, line 19 skipping to change at page 76, line 19
IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated to IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated to
the public AMT Relays to advertise to the native multicast backbone the public AMT Relays to advertise to the native multicast backbone
(as described in Section 4.1.4). The prefix length should be (as described in Section 4.1.4). The prefix length should 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 24 will meet this requirement. A prefix length of 24 will meet this requirement.
Internet Systems Consortium (ISC) has offered154.7.0/24 for this Internet Systems Consortium (ISC) has offered 154.7.0/24 for this
purpose. 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. IPv4 Address Prefix Allocation for IGMP Source Addresses 7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses
 End of changes. 49 change blocks. 
94 lines changed or deleted 114 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/