draft-ietf-mboned-auto-multicast-14.txt   draft-ietf-mboned-auto-multicast-15.txt 
Network Working Group G. Bumgardner Network Working Group G. Bumgardner
Internet-Draft Cisco Internet-Draft
Intended status: Standards Track June 12, 2012 Intended status: Standards Track July 15, 2013
Expires: December 14, 2012 Expires: January 16, 2014
Automatic Multicast Tunneling Automatic Multicast Tunneling
draft-ietf-mboned-auto-multicast-14 draft-ietf-mboned-auto-multicast-15
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
by requiring minimal changes to existing network infrastructure. by requiring minimal changes to existing network infrastructure.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 14, 2012. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 22 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 3.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. General Architecture . . . . . . . . . . . . . . . . . . . 8 4.1. General Architecture . . . . . . . . . . . . . . . . . . 6
4.2. General Operation . . . . . . . . . . . . . . . . . . . . 17 4.1.1. Relationship to IGMP and MLD Protocols . . . . . . . 7
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 32 4.1.2. Gateways . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 32 4.1.3. Relays . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 47 4.1.4. Deployment . . . . . . . . . . . . . . . . . . . . . 13
5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 62 4.1.5. Discovery . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 73 4.2. General Operation . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 4.2.1. Message Sequences . . . . . . . . . . . . . . . . . . 16
7.2. IPv4 Address Prefix Allocation for IGMP Source 4.2.2. Tunneling . . . . . . . . . . . . . . . . . . . . . . 25
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 30
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 5.1.1. Relay Discovery . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.1.2. Relay Advertisement . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 79 5.1.3. Request . . . . . . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . . 79 5.1.4. Membership Query . . . . . . . . . . . . . . . . . . 34
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 82 5.1.5. Membership Update . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.1.6. Multicast Data . . . . . . . . . . . . . . . . . . . 40
5.1.7. Teardown . . . . . . . . . . . . . . . . . . . . . . 42
5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 44
5.2.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 44
5.2.2. Pseudo-Interface Configuration . . . . . . . . . . . 46
5.2.3. Gateway Service . . . . . . . . . . . . . . . . . . . 47
5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 59
5.3.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 59
5.3.2. Startup . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.3. Running . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.4. Shutdown . . . . . . . . . . . . . . . . . . . . . . 71
5.3.5. Response MAC Generation . . . . . . . . . . . . . . . 71
5.3.6. Private Secret Generation . . . . . . . . . . . . . . 72
6. Security Considerations . . . . . . . . . . . . . . . . . . . 72
6.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3. Encapsulated IP Packets . . . . . . . . . . . . . . . . . 75
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
7.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 75
7.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 75
7.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses 75
7.3. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 75
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 75
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.1. Normative References . . . . . . . . . . . . . . . . . . 77
10.2. Informative References . . . . . . . . . . . . . . . . . 77
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 79
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 81
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 5, line 5 skipping to change at page 4, line 14
multicast connectivity to the source network. This document does not multicast connectivity to the source network. This document does not
describe any methods for sourcing multicast traffic from isolated describe any methods for sourcing multicast traffic 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.
AMT is designed to be deployed at the border of networks possessing
native multicast capabilities where access and provisioning can be
managed by the AMT service provider.
3. Terminology 3. Terminology
3.1. Requirements Notation 3.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3.2. Definitions 3.2. Definitions
skipping to change at page 5, line 45 skipping to change at page 5, line 10
Multicast Receiver: Multicast Receiver:
An entity that requests and receives multicast traffic. A An entity that requests and receives multicast traffic. A
receiver may be a router, host, application, or application receiver may be a router, host, application, or application
component. The method by which a receiver transmits group component. The method by which a receiver transmits group
membership requests and receives multicast traffic varies membership requests and receives multicast traffic varies
according to receiver type. according to receiver type.
Group Membership Database: Group Membership Database:
A group membership database describes the current multicast A group membership database describes the current multicast
subscription/reception sate for an interface or system. subscription state for an interface or system. See Section 3 in
[RFC3376] for a detailed definition.
Reception State: Reception State:
The multicast subscription state of a pseudo, virtual or physical The multicast subscription state of a pseudo, virtual or physical
network interface. See group membership database. network interface. Often synonymous with group membership
database.
Subscription: Subscription:
A group or state entry in a group membership database or reception A group or state entry in a group membership database or reception
state table. state table. The presence of a subscription entry indicates
membership in an IP multicast group.
Group Membership Protocol: Group Membership Protocol:
The term "group membership protocol" is used as a generic The term "group membership protocol" is used as a generic
reference to the Internet Group Management (IGMP) ([RFC1112], reference to the Internet Group Management (IGMP) ([RFC1112],
[RFC2236], [RFC3376]) or Multicast Listener Discovery ([RFC2710], [RFC2236], [RFC3376]) or Multicast Listener Discovery ([RFC2710],
[RFC3810]) protocols. [RFC3810]) protocols.
Multicast Protocol: Multicast Protocol:
The term "multicast protocol" is used as a generic reference to The term "multicast protocol" is used as a generic reference to
multicast routing protocols used to join or leave multicast multicast routing protocols used to join or leave multicast
skipping to change at page 8, line 13 skipping to change at page 6, line 33
PIM - Protocol Independent Multicast. PIM - Protocol Independent Multicast.
4. Protocol Overview 4. Protocol Overview
This section provides an informative description of the protocol. A This section provides an informative description of the protocol. A
normative description of the protocol and implementation requirements normative description of the protocol and implementation requirements
may be found in section Section 5. may be found in section Section 5.
4.1. General Architecture 4.1. General Architecture
Isolated Site | Unicast Network | Native Multicast Isolated Site | Unicast Network | Native Multicast
| (Internet) | | (Internet) |
| | | |
| | | |
| Group Membership | | Group Membership |
+-------+ ===========================> +-------+ Multicast +------+ +-------+ =========================> +-------+ Multicast +------+
|Gateway| | | | Relay |<----//----|Source| |Gateway| | | | Relay |<----//----|Source|
+-------+ <=========================== +-------+ +------+ +-------+ <========================= +-------+ +------+
| Multicast Data | | Multicast Data |
| | | |
| | | |
Figure 1: Basic AMT Architecture Figure 1: Basic AMT Architecture
The AMT protocol employs a client-server model in which a "gateway" The AMT protocol employs a client-server model in which a "gateway"
sends requests to receive specific multicast traffic to a "relay" sends requests to receive specific multicast traffic to a "relay"
which responds by delivering the requested multicast traffic back to which responds by delivering the requested multicast traffic back to
the gateway. the gateway.
Gateways are generally deployed within networks that lack multicast Gateways are generally deployed within networks that lack multicast
support or lack connectivity to a multicast-enabled network support or lack connectivity to a multicast-enabled network
skipping to change at page 9, line 5 skipping to change at page 7, line 25
Multicast Listener Discovery (MLD) [RFC3810] protocols to provide the Multicast Listener Discovery (MLD) [RFC3810] protocols to provide the
functionality required to manage, communicate, and act on changes in functionality required to manage, communicate, and act on changes in
multicast group membership. A gateway or relay implementation does multicast group membership. A gateway or relay implementation does
not necessarily require a fully-functional, conforming implementation not necessarily require a fully-functional, conforming implementation
of IGMP or MLD to adhere to this specification, but the protocol of IGMP or MLD to adhere to this specification, but the protocol
description that appears in this document assumes that this is the description that appears in this document assumes that this is the
case. The minimum functional and behavioral requirements for the case. The minimum functional and behavioral requirements for the
IGMP and MLD protocols are described in Section 5.2.1 and IGMP and MLD protocols are described in Section 5.2.1 and
Section 5.3.1. Section 5.3.1.
Gateway Relay Gateway Relay
General _____ _____ General _____ _____
___________ Query | | | | Query ___________ ___________ Query | | | | Query ___________
| |<------| | | |<------| | | |<------| | | |<------| |
| Host Mode | | AMT | | AMT | |Router Mode| | Host Mode | | AMT | | AMT | |Router Mode|
| IGMP/MLD | | | UDP | | | IGMP/MLD | | IGMP/MLD | | | UDP | | | IGMP/MLD |
|___________|------>| |<----->| |------>|___________| |___________|------>| |<----->| |------>|___________|
Report | | | | Report Report | | | | Report
Leave/Done | | | | Leave/Done Leave/Done | | | | Leave/Done
| | | | | | | |
IP Multicast <------| | | |<------ IP Multicast IP Multicast <------| | | |<------ IP Multicast
|_____| |_____| |_____| |_____|
Multicast Reception State Managed By IGMP/MLD Figure 2: Multicast Reception State Managed By IGMP/MLD
A gateway runs the host portion of the IGMP and MLD protocols to A gateway runs the host portion of the IGMP and MLD protocols to
generate group membership updates that are sent via AMT messages to a generate group membership updates that are sent via AMT messages to a
relay. A relay runs the router portion of the IGMP and MLD protocols relay. A relay runs the router portion of the IGMP and MLD protocols
to process the group membership updates to produce the required to process the group membership updates to produce the required
changes in multicast forwarding state. A relay uses AMT messages to changes in multicast forwarding state. A relay uses AMT messages to
send incoming multicast IP datagrams to gateways according to their send incoming multicast IP datagrams to gateways according to their
current group membership state. current group membership state.
The primary function of AMT is to provide the handshaking, The primary function of AMT is to provide the handshaking,
skipping to change at page 9, line 42 skipping to change at page 8, line 13
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 one or more 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 gateway
functionality may be directly implemented in the host requesting the
multicast service or within an application running on a host.
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:
join/leave ---+ +----------+ join/leave ---+ +----------+
| | | | | |
V IGMPv3/MLDv2 | | V IGMPv3/MLDv2 | |
+---------+ General Query| | AMT +---------+ General Query| | AMT
|IGMP/MLD |<-------------| AMT | Messages +------+ |IGMP/MLD |<-------------| AMT | Messages +------+
|Host Mode| | Gateway |<-------->|UPD/IP| |Host Mode| | Gateway |<-------->|UDP/IP|
|Protocol |------------->|Pseudo I/F| +------+ |Protocol |------------->|Pseudo I/F| +------+
+---------+ IGMP/MLD | | ^ +---------+ IGMP/MLD | | ^
Report | | | Report | | |
Leave/Done | | V Leave/Done | | V
IP Multicast <---------------------| | +---+ IP Multicast <---------------------| | +---+
+----------+ |I/F| +----------+ |I/F|
+---+ +---+
Figure 2: AMT Gateway Pseudo-Interface Figure 3: AMT Gateway Pseudo-Interface
The pseudo-interface is conceptually a network interface on which the The pseudo-interface is conceptually a network interface on which the
gateway executes the host portion of the IPv4/IGMP (v2 or v3) and gateway executes the host portion of the IPv4/IGMP (v2 or v3) and
IPv6/MLD (v1 or v2) protocols. The multicast reception state of the IPv6/MLD (v1 or v2) protocols. The multicast reception state of the
pseudo-interface is manipulated using the IGMP or MLD service pseudo-interface is manipulated using the IGMP or MLD service
interface. The IGMP and MLD host protocols produce IP datagrams interface. The IGMP and MLD host protocols produce IP datagrams
containing group membership messages that the gateway will send to containing group membership messages that the gateway will send to
the relay. The IGMP and MLD protocols also supply the retransmission the relay. The IGMP and MLD protocols also supply the retransmission
and timing behavior required for protocol robustness. and timing behavior required for protocol robustness.
All AMT encapsulation, decapsulation and relay interaction is assumed All AMT encapsulation, decapsulation and relay interaction is assumed
to occur within the pseudo-interface. to occur within the pseudo-interface.
A gateway host or application may create separate interfaces for A gateway host or application may create separate interfaces for IPv4
IPv4/IGMP and IPv6/MLD. A gateway host or application may also /IGMP and IPv6/MLD. A gateway host or application may also require
require additional pseudo-interfaces for each source or domain- additional pseudo-interfaces for each source or domain-specific relay
specific relay address. address.
Within this document, the term "gateway" may be used as a generic Within this document, the term "gateway" may be used as a generic
reference to an entity executing the gateway protocol, a gateway reference to an entity executing the gateway protocol, a gateway
pseudo-interface, or a gateway device that has one or more interfaces pseudo-interface, or a gateway device that has one or more interfaces
connected to a unicast inter-network and one or more AMT gateway connected to a unicast inter-network and one or more AMT gateway
pseudo-interfaces. pseudo-interfaces.
The following diagram illustrates how an existing host IP stack The following diagram illustrates how an existing host IP stack
implementation might be used to provide AMT gateway functionality to implementation might be used to provide AMT gateway functionality to
a multicast application: a multicast application:
+-----------------------------------------------------+ +-----------------------------------------------------+
|Host | |Host |
| ______________________________________ | | ______________________________________ |
| | | | | | | |
| | ___________________________ | | | | ___________________________ | |
| | | | | | | | | | | |
| | | v | | | | | v | |
| | | +-----------+ +--------------+ | | | | +-----------+ +--------------+ |
| | | |Application| | AMT Daemon | | | | | |Application| | AMT Daemon | |
| | | +-----------+ +--------------+ | | | | +-----------+ +--------------+ |
| | | join/leave | ^ data ^ AMT | | | | join/leave | ^ data ^ AMT |
| | | | | | | | | | | | | |
| | | +----|---|-------------|-+ | | | | +----|---|-------------|-+ |
| | | | __| |_________ | | | | | | | __| |_________ | | |
| | | | | | | | | | | | | | | | | |
| | | | | Sockets | | | | | | | | | Sockets | | | |
| | | +-|------+-------+-|---|-+ | | | | +-|------+-------+-|---|-+ |
| | | | | IGMP | TCP | |UDP| | | | | | | | IGMP | TCP | |UDP| | |
| | | +-|------+-------+-|---|-+ | | | | +-|------+-------+-|---|-+ |
| | | | | ^ IP | | | | | | | | | ^ IP | | | |
| | | | | | ____________| | | | | | | | | | ____________| | | |
| | | | | | | | | | | | | | | | | | | |
| | | +-|-|-|----------------|-+ | | | | +-|-|-|----------------|-+ |
| | | | | | | | | | | | | | | |
| | | IP(IGMP)| | |IP(UDP(data)) |IP(UDP(AMT)) | | | | IP(IGMP)| | |IP(UDP(data)) |IP(UDP(AMT)) |
| | | v | | v | | | | v | | v |
| | | +-----------+ +---+ | | | | +-----------+ +---+ |
| | | |Virtual I/F| |I/F| | | | | |Virtual I/F| |I/F| |
| | | +-----------+ +---+ | | | | +-----------+ +---+ |
| | | | ^ ^ | | | | | ^ ^ |
| | | IP(IGMP)| |IP(UDP(data)) | | | | | IP(IGMP)| |IP(UDP(data)) | |
| | |_________| |IP(IGMP) | | | | |_________| |IP(IGMP) | |
| | | | | | | | | |
| |_________________| | | | |_________________| | |
| | | | | |
+--------------------------------------|--------------+ +--------------------------------------|--------------+
v v
AMT Relay AMT Relay
Virtual Interface Implementation Example Figure 4: Virtual Interface Implementation Example
In this example, the host IP stack uses a virtual network interface In this example, the host IP stack uses a virtual network interface
to interact with a gateway pseudo-interface implementation. to interact with a gateway pseudo-interface implementation.
4.1.2.2. Use-Cases 4.1.2.2. Use-Cases
Use-cases for gateway functionality include: Use-cases for gateway functionality include:
IGMP/MLD Proxy IGMP/MLD Proxy
An IGMP/MLD proxy that runs AMT on an upstream interface and An IGMP/MLD proxy that runs AMT on an upstream interface and
skipping to change at page 13, line 9 skipping to change at page 12, line 5
The upstream side of a relay communicates with a native multicast The upstream side of a relay communicates with a native multicast
infrastructure - the relay sends join and prune/leave requests infrastructure - the relay sends join and prune/leave requests
towards multicast sources and accepts requested multicast traffic towards multicast sources and accepts requested multicast traffic
from those sources. from those sources.
4.1.3.1. Architecture 4.1.3.1. Architecture
Each relay possesses a logical pseudo-interface: Each relay possesses a logical pseudo-interface:
+------------------------------+ +------------------------------+
+--------+ | Multicast Control Plane | +--------+ | Multicast Control Plane |
| |IGMP/MLD| | | |IGMP/MLD| |
| | Query* | +------------+ +----------+ | | | Query* | +------------+ +----------+ |
| |<---//----|IGMPv3/MLDv2| | | | | |<---//----|IGMPv3/MLDv2| |Multicast | |
AMT | | | |Router Mode |->| PIM-SM |<--> AMT | | | |Router Mode |->|Routing |<->
+------+ Messages | AMT |----//--->|Protocol | | | | +------+ Messages | AMT |----//--->|Protocol | |Protocol | |
|UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ | |UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ |
+------+ | Pseudo | Report | | | | +------+ | Pseudo | Report | | | |
^ | I/F | Leave/ +------|---------------|-------+ ^ | I/F | Leave/ +------|---------------|-------+
| | | Done | | | | | Done | |
| | | v | | | | v |
V | | IP +-----------+ | V | | IP +-----------+ |
+---+ | | Multicast |Multicast |<------+ +---+ | | Multicast |Multicast |<------+
|I/F| | |<---//-----|Forwarding | |I/F| | |<---//-----|Forwarding |
+---+ +--------+ |Plane |<--- IP Multicast +---+ +--------+ |Plane |<--- IP Multicast
+-----------+ +-----------+
* Queries, if generated, are consumed by the pseudo-interface. * Queries, if generated, are consumed by the pseudo-interface.
AMT Relay Pseudo-Interface (Router-Based) Figure 5: AMT Relay Pseudo-Interface (Router-Based)
The pseudo-interface is conceptually a network interface on which the The pseudo-interface is conceptually a network interface on which the
relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2 relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2
protocols. Relays do not send unsolicited IGMPv3/MLDv2 query protocols. Relays do not send unsolicited IGMPv3/MLDv2 query
messages to gateways so relays must consume or discard any local messages to gateways so relays must consume or discard any local
queries normally generated by IGMPv3 or MLDv2. queries normally generated by IGMPv3 or MLDv2. Note that the
protocol mandates the use of IGMPv3 and MLDv2 for query messages.
The AMT protocol is primarily intended for use in SSM applications
and relies on several values provided by IGMPv2/MLDv2 to control
gateway behavior.
A relay maintains group membership state for each gateway connected A relay maintains group membership state for each gateway connected
through the pseudo-interface as well as for the entire pseudo- through the pseudo-interface as well as for the entire pseudo-
interface (if multiple gateways are managed via a single interface). interface (if multiple gateways are managed via a single interface).
Multicast packets received on upstream interfaces on the relay are Multicast packets received on upstream interfaces on the relay are
routed to the pseudo-interface where they are replicated, routed to the pseudo-interface where they are replicated,
encapsulated and sent to interested gateways. Changes in the pseudo- encapsulated and sent to interested gateways. Changes in the pseudo-
interface group membership state may trigger the transmission of interface group membership state may trigger the transmission of
multicast protocol requests upstream towards a given source or multicast protocol requests upstream towards a given source or
rendezvous point and cause changes in internal routing/forwarding rendezvous point and cause changes in internal routing/forwarding
skipping to change at page 14, line 33 skipping to change at page 13, line 39
zero or more interfaces connected to a unicast inter-network, and one zero or more interfaces connected to a unicast inter-network, and one
or more relay pseudo-interfaces. or more relay pseudo-interfaces.
4.1.3.2. Use-Cases 4.1.3.2. Use-Cases
Use-cases for relay functionality include: Use-cases for relay functionality include:
Multicast Router Multicast Router
A multicast router that runs AMT on a downstream interface to A multicast router that runs AMT on a downstream interface to
provide gateway access to multicast traffic. A "relay router" provide gateway access to multicast traffic. A "relay router"
uses a multicast routing protocol (e.g. PIM-SM RFC4601 [RFC4601]) uses a multicast routing protocol (e.g. PIM-SM RFC4601 [RFC4601])
to construct a forwarding path for multicast traffic by sending to construct a forwarding path for multicast traffic by sending
join and prune messages to neighboring routers to join or leave join and prune messages to neighboring routers to join or leave
multicast distribution trees for a given SSM source or ASM multicast distribution trees for a given SSM source or ASM
rendezvous point. rendezvous point.
IGMP/MLD Proxy Router IGMP/MLD Proxy Router
An IGMP/MLD proxy that runs AMT on a downstream interface and An IGMP/MLD proxy that runs AMT on a downstream interface and
host-mode IGMPv3/MLDv2 on a upstream interface. This "relay host-mode IGMPv3/MLDv2 on a upstream interface. This "relay
proxy" sends group membership reports to a local, multicast- proxy" sends group membership reports to a local, multicast-
enabled router to join and leave specific SSM or ASM groups. enabled router to join and leave specific SSM or ASM groups.
skipping to change at page 15, line 43 skipping to change at page 14, line 48
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.
4.1.4.2. Congestion Considerations
AMT relies on UDP to provide best-effort delivery of multicast data
to gateways. Neither AMT or the UDP protocol provide the congestion
control mechanisms required to regulate the flow of data messages
passing through a network. While congestion remediation might be
provided by multicast receiver applications via multicast group
selection or upstream reporting mechanisms, there are no means by
which to ensure such mechanisms are employed. To limit the possible
congestion across a network or wider Internet, AMT service providers
are expected to deploy AMT relays near the provider's network border
and its interface with edge routers. The provider must limit relay
address advertisements to those edges to prevent distant gateways
from being able to access a relay and potentially generate flows that
consume or exceed the capacity of intervening links.
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
unicast IP address of an operational relay. This address may be unicast IP address of an operational relay. This address may be
obtained using a number of methods - it may be statically assigned or obtained using a number of methods - it may be statically assigned or
dynamically chosen via some form of relay discovery process. dynamically chosen via some form of relay discovery process.
As described in the previous section, the AMT protocol provides a As described in the previous section, the AMT protocol provides a
relay discovery method that relies on anycast addressing. Gateways relay discovery method that relies on anycast addressing. Gateways
are not required to use AMT relay discovery, but all relay are not required to use AMT relay discovery, but all relay
skipping to change at page 16, line 28 skipping to change at page 15, line 49
Relay Address: Relay Address:
The unicast IP address obtained as a result of the discovery The unicast IP address obtained as a result of the discovery
process. process.
4.1.5.1. Relay Discovery Address Selection 4.1.5.1. Relay Discovery Address Selection
The selection of an anycast Relay Discovery Address may be source- The selection of an anycast Relay Discovery Address may be source-
dependent, as a relay located via relay discovery must have multicast dependent, as a relay located via relay discovery must have multicast
connectivity to a desired source. connectivity to a desired source.
Similarly, the selection of a unicast Relay address may be source- Similarly, the selection of a unicast Relay Address may be source-
dependent, as a relay contacted by a gateway to supply multicast dependent, as a relay contacted by a gateway to supply multicast
traffic must have native multicast connectivity to the traffic source traffic must have native multicast connectivity to the traffic source
Methods that might be used to perform source-specific or group- Methods that might be used to perform source-specific or group-
specific relay selection are highly implementation-dependent and are specific relay selection are highly implementation-dependent and are
not further addressed by this document. Possible approaches include not further addressed by this document. Possible approaches include
the use of static lookup tables, DNS-based queries, or a provision of the use of static lookup tables, DNS-based queries, or a provision of
a service interface that accepts join requests on (S,G,relay- a service interface that accepts join requests on (S,G,relay-
discovery-address) or (S,G,relay-address) tuples. discovery-address) or (S,G,relay-address) tuples.
4.1.5.2. IANA-Assigned Relay Discovery Address Prefix 4.1.5.2. IANA-Assigned Relay Discovery Address Prefix
This document calls for IANA to allocate an anycast address prefix IANA has assigned an address prefix for use in advertising and
for use in advertising and discovering publicly accessible relays. discovering publicly accessible relays.
A relay discovery address is constructed from the anycast address A relay discovery address is constructed from the address prefix by
prefix by setting the low-order octet of the prefix address to 1 (for setting the low-order octet of the prefix address to 1 (for both IPv4
both IPv4 and IPv6). and IPv6).
Public relays must advertise a route to the anycast address prefix Public relays must advertise a route to the address prefix (e.g. via
and configure an interface to respond to the relay discovery address. BGP [RFC4271]) and configure an interface to respond to the relay
discovery address.
The IANA address assignments are discussed in Section 7. The IANA address assignments are discussed in Section 7.
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.
skipping to change at page 18, line 7 skipping to change at page 17, line 21
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
Gateway Relay Gateway Relay
------- ----- ------- -----
: : : :
| | | |
[1] |Relay Discovery | [1] |Relay Discovery |
|------------------->| |------------------->|
| | | |
| Relay Advertisement| [2] | Relay Advertisement| [2]
|<-------------------| |<-------------------|
[3] | | [3] | |
: : : :
AMT Relay Discovery Sequence Figure 6: AMT Relay Discovery Sequence
The following sequence describes how the Relay Discovery and Relay The following sequence describes how the Relay Discovery and Relay
Advertisement messages are used to find a relay with which to Advertisement messages are used to find a relay with which to
communicate: communicate:
1. The gateway sends a Relay Discovery message containing a random 1. The gateway sends a Relay Discovery message containing a random
nonce to the Relay Discovery Address. If the Relay Discovery nonce to the Relay Discovery Address. If the Relay Discovery
Address is an anycast address, the message is routed to Address is an anycast address, the message is routed to
topologically-nearest network node that advertises that address. topologically-nearest network node that advertises that address.
skipping to change at page 19, line 16 skipping to change at page 18, line 30
messages that describe their current multicast reception state. messages that describe their current multicast reception state.
However, AMT does not allow relays to send unsolicited query messages However, AMT does not allow relays to send unsolicited query messages
to gateways, as the set of active gateways may be unknown to the to gateways, as the set of active gateways may be unknown to the
relay and potentially quite large. Instead, AMT requires each relay and potentially quite large. Instead, AMT requires each
gateway to periodically send a message to a relay to solicit a gateway to periodically send a message to a relay to solicit a
general-query response. A gateway accomplishes this by sending a general-query response. A gateway accomplishes this by sending a
Request message to a relay. The relay responds by sending Membership Request message to a relay. The relay responds by sending Membership
Query message back to the gateway. The Membership Query message Query message back to the gateway. The Membership Query message
carries an encapsulated general query that is processed by the IGMP carries an encapsulated general query that is processed by the IGMP
or MLD protocol implementation on the gateway to produce a or MLD protocol implementation on the gateway to produce a membership
membership/listener report. Each time the gateway receives a /listener report. Each time the gateway receives a Membership Query
Membership Query message it starts a timer whose expiration will message it starts a timer whose expiration will trigger the start of
trigger the start of a new Request->Membership Query message a new Request->Membership Query message exchange. This timer-driven
exchange. This timer-driven sequence is used to mimic the sequence is used to mimic the transmission of a periodic general
transmission of a periodic general query by an IGMP/MLD router. This query by an IGMP/MLD router. This query cycle may continue
query cycle may continue indefinitely once started by sending the indefinitely once started by sending the initial Request message.
initial Request message.
A membership update occurs when an IGMP or MLD report, leave or done A membership update occurs when an IGMP or MLD report, leave or done
message is passed to the gateway pseudo-interface. These messages message is passed to the gateway pseudo-interface. These messages
may be produced as a result of the aforementioned general-query may be produced as a result of the aforementioned general-query
processing or as a result of receiver interaction with the IGMP/MLD processing or as a result of receiver interaction with the IGMP/MLD
service interface. Each report is encapsulated and sent to the relay service interface. Each report is encapsulated and sent to the relay
after the gateway has successfully established communication with the after the gateway has successfully established communication with the
relay via a Request and Membership Query message exchange. If a relay via a Request and Membership Query message exchange. If a
report is passed to the pseudo-interface before the gateway has report is passed to the pseudo-interface before the gateway has
received a Membership Query message from the relay, the gateway may received a Membership Query message from the relay, the gateway may
discard the report or queue the report for delivery after a discard the report or queue the report for delivery after a
Membership Query is received. Subsequent IGMP/MLD report/leave/done Membership Query is received. Subsequent IGMP/MLD report/leave/done
messages that are passed to the pseudo-interface are immediately messages that are passed to the pseudo-interface are immediately
encapsulated and transmitted to the relay. encapsulated and transmitted to the relay.
IGMP/MLD Pseudo-I/F Relay IGMP/MLD Pseudo-I/F Relay
-------- ---------- ----- -------- ---------- -----
: : : : : :
| | Request | | | Request |
| 1|-------------------->| | 1|-------------------->|
| | Membership Query |2 | | Membership Query |2
Query | | Q(0,{}) | Query | | Q(0,{}) |
Timer | Start 3|<--------------------| Timer | Start 3|<--------------------|
(QT)<--------------------------| | (QT)<--------------------------| |
| Q(0,{}) | | | Q(0,{}) | |
|<--------------------| | |<--------------------| |
4| R({}) | Membership Update | 4| R({}) | Membership Update |
|-------------------->|5 R({}) | |-------------------->|5 R({}) |
| |====================>|6a | |====================>|6a
Join(S,G) : : : Join(S,G) : : :
()--------->|7 R({G:ALLOW({S})}) | Membership Update | ()-------->|7 R({G:ALLOW({S})}) | Membership Update |
|-------------------->|8 R({G:ALLOW({S})}) | |-------------------->|8 R({G:ALLOW({S})}) |
| |====================>|9a Join(S,G) | |====================>|9a Join(S,G)
| | |---------->() | | |---------->()
: : : : : :
| ------------|---------------------|------------ | ------------|---------------------|------------
| | | | | | | | | |
| | | Multicast Data | IP(S,G) | | | | Multicast Data | IP(S,G) |
| | | IP(S,G) 10|<--------() | | | | IP(S,G) 10|<--------() |
| | IP(S,G) 11|<====================| | | | IP(S,G) 11|<====================| |
| | ()<--------| | | | | ()<--------| | |
skipping to change at page 20, line 46 skipping to change at page 19, line 46
| | Membership Query |2 | | Membership Query |2
| | Q(0,{}) | | | Q(0,{}) |
| Start 3|<--------------------| | Start 3|<--------------------|
(QT)<--------------------------| | (QT)<--------------------------| |
| Q(0,{}) | | | Q(0,{}) | |
|<--------------------| | |<--------------------| |
4| R({G:INCLUDE({S})}) | Membership Update | 4| R({G:INCLUDE({S})}) | Membership Update |
|-------------------->|5 R({G:INCLUDE({S})})| |-------------------->|5 R({G:INCLUDE({S})})|
| |====================>|6b | |====================>|6b
Leave(S,G) : : : Leave(S,G) : : :
()--------->|7 R({G:BLOCK({S})}) | Membership Update | ()-------->|7 R({G:BLOCK({S})}) | Membership Update |
|-------------------->|8 R({G:BLOCK({S})}) | |-------------------->|8 R({G:BLOCK({S})}) |
| |====================>|9b Prune(S,G) | |====================>|9b Prune(S,G)
| | |---------->() | | |---------->()
: : : : : :
Membership Update Sequence (IGMPv3/MLDv2 Example) Figure 7: Membership Update Sequence (IGMPv3/MLDv2 Example)
The following sequence describes how the Request, Membership Query, The following sequence describes how the Request, Membership Query,
and Membership Update messages are used to report current group and Membership Update messages are used to report current group
membership state or changes in group membership state: membership state or changes in group membership state:
1. A gateway sends a Request message to the relay that contains a 1. A gateway sends a Request message to the relay that contains a
random nonce and a flag indicating whether the relay should random nonce and a flag indicating whether the relay should
return an IGMPv3 or MLDv2 general query. return an IGMPv3 or MLDv2 general query.
2. When the relay receives a Request message, it generates a 2. When the relay receives a Request message, it generates a
message authentication code (MAC) by computing a hash value from message authentication code (MAC) by computing a hash value from
a private secret and the nonce, source IP address, and source message source IP address, source UDP port, request nonce and a
UDP port carried by the Request message. The relay then sends a private secret. The relay then sends a Membership Query message
Membership Query message to the gateway that contains the to the gateway that contains the request nonce, the MAC, and an
request nonce, the MAC, and an IGMPv3 or MLDv2 general query. IGMPv3 or MLDv2 general query.
3. When the gateway receives a Membership Query message, it 3. When the gateway receives a Membership Query message, it
verifies that the request nonce matches the one sent in the last verifies that the request nonce matches the one sent in the last
Request, and if it does, the gateway saves the request nonce and Request, and if it does, the gateway saves the request nonce and
MAC for use in sending subsequent Membership Update messages. MAC for use in sending subsequent Membership Update messages.
The gateway starts a timer whose expiration will trigger the The gateway starts a timer whose expiration will trigger the
transmission of a new Request message and extracts the transmission of a new Request message and extracts the
encapsulated general query message for processing by the IGMP or encapsulated general query message for processing by the IGMP or
MLD protocol. The query timer duration is specified by the MLD protocol. The query timer duration is specified by the
relay in the QQIC field in the IGMPv3 or MLDv2 general query. relay in the Querier's Query Interval Code (QQIC) field in the
IGMPv3 or MLDv2 general query. The QQIC field is defined in
Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]).
4. The gateway's IGMP or MLD protocol implementation processes the 4. The gateway's IGMP or MLD protocol implementation processes the
general query to produce a current-state report. general query to produce a current-state report.
5. When an IGMP or MLD report is passed to the pseudo-interface, 5. When an IGMP or MLD report is passed to the pseudo-interface,
the gateway encapsulates the report in a Membership Update the gateway encapsulates the report in a Membership Update
message and sends it to the relay. The request nonce and MAC message and sends it to the relay. The request nonce and MAC
fields in the Membership Update are assigned the values from the fields in the Membership Update are assigned the values from the
last Membership Query message received for the corresponding last Membership Query message received for the corresponding
group membership protocol (IGMPv3 or MLDv2). group membership protocol (IGMPv3 or MLDv2).
6. When the relay receives a Membership Update message, it computes 6. When the relay receives a Membership Update message, it computes
a MAC from a private secret and the request nonce, source IP a MAC from the message source IP address, source UDP port,
address, and source UDP port carried by the message. The relay request nonce and a private secret. The relay accepts the
accepts the Membership Update message if the received MAC Membership Update message if the received MAC matches the
matches the computed MAC, otherwise the message is ignored. If computed MAC, otherwise the message is ignored. If the message
the message is accepted, the relay may proceed to allocate, is accepted, the relay may proceed to allocate, refresh, or
refresh, or modify tunnel state. This includes making any group modify tunnel state. This includes making any group membership,
membership, routing and forwarding state changes and issuing any routing and forwarding state changes and issuing any upstream
upstream protocol requests required to satisfy the state change. protocol requests required to satisfy the state change. The
The diagram illustrates two scenarios: diagram illustrates two scenarios:
A. The gateway has not previously reported any group a. The gateway has not previously reported any group
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 using 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.
skipping to change at page 22, line 32 skipping to change at page 21, line 35
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
or MLD). or MLD).
The IGMP and MLD protocols may generate multiple messages to The IGMP and MLD protocols may generate multiple messages to
provide robustness against packet loss - each of these must be provide robustness against packet loss - each of these must be
encapsulated in a new Membership Update message and sent to the encapsulated in a new Membership Update message and sent to the
relay. The Querier Robustness Variable (QRV) field in the last relay. The Querier Robustness Variable (QRV) field in the last
IGMP/MLD query delivered to the IGMP/MLD protocol is typically IGMP/MLD query delivered to the IGMP/MLD protocol is typically
used to specify the number of repetitions (i.e., the host adopts used to specify the number of repetitions (i.e., the host adopts
the QRV value as its own Robustness Variable value). the QRV value as its own Robustness Variable value). The QRV
field is defined in Section 4.1.6 in [RFC3376] and Section 5.1.8
in [RFC3810].
9. When the relay receives a Membership Update message, it again 9. When the relay receives a Membership Update message, it again
computes a MAC from a private secret and the request nonce, computes a MAC from the message source IP address, source UDP
source IP address, and source UDP port carried by the message. port, request nonce and a private secret. The relay accepts the
The relay accepts the Membership Update message if the received Membership Update message if the received MAC matches the
MAC matches the computed MAC, otherwise the message is ignored. computed MAC, otherwise the message is ignored. If the message
If the message is accepted, the relay processes the encapsulated is accepted, the relay processes the encapsulated IGMP/MLD and
IGMP/MLD and allocates, modifies or deletes tunnel state allocates, modifies or deletes tunnel state accordingly. This
accordingly. This includes making any group membership, routing includes making any group membership, routing and forwarding
and forwarding state changes and issuing any upstream protocol state changes and issuing any upstream protocol requests
requests required to satisfy the state change. The diagram required to satisfy the state change. The diagram illustrates
illustrates two scenarios: 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 from 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
skipping to change at page 23, line 39 skipping to change at page 22, line 42
and be rejected by the relay. and be rejected by the relay.
A relay will only allocate new tunnel state if the IGMP/MLD report A relay will only allocate new tunnel state if the IGMP/MLD report
carried by the Membership Update message creates one or more group carried by the Membership Update message creates one or more group
subscriptions. subscriptions.
A relay deallocates tunnel state after one of the following events; A relay deallocates tunnel state after one of the following events;
the gateway sends a Membership Update message containing a report the gateway sends a Membership Update message containing a report
that results in the deletion of all remaining group subscriptions, that results in the deletion of all remaining group subscriptions,
the IGMP/MLD state expires (due to lack of refresh by the gateway), the IGMP/MLD state expires (due to lack of refresh by the gateway),
or the relay receives a valid Teardown message from the gateway. or the relay receives a valid Teardown message from the gateway (See
Section 4.2.1.3).
A gateway that accepts or reports group subscriptions for both IPv4 A gateway that accepts or reports group subscriptions for both IPv4
and IPv6 addresses will send separate Request and Membership Update and IPv6 addresses will send separate Request and Membership Update
messages for each protocol (IPv4/IGMP and IPv6/MLD). messages for each protocol (IPv4/IGMP and IPv6/MLD).
4.2.1.3. Teardown Sequence 4.2.1.3. Teardown Sequence
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
delivering Multicast Data messages to a tunnel endpoint created by an delivering Multicast Data messages to a tunnel endpoint created by an
earlier Membership Update message. This message is intended to be earlier Membership Update message. This message is intended to be
used following a gateway address change (See Section 4.2.2.1) to stop used following a gateway address change (See Section 4.2.2.1) to stop
the transmission of undeliverable or duplicate multicast data the transmission of undeliverable or duplicate multicast data
messages. Support for the Teardown message is optional - gateways messages. Gateway support for the Teardown message is optional -
are not required to send them and relays are not required to act upon gateways are not required to send them and may instead relay on group
them. membership to expire on the relay.
Gateway Relay Gateway Relay
------- ----- ------- -----
: Request : : Request :
[1] | N | [1] | N |
|---------------------->| |---------------------->|
| Membership Query | [2] | Membership Query | [2]
| N,MAC,gADDR,gPORT | | N,MAC,gADDR,gPORT |
|<======================| |<======================|
[3] | Membership Update | [3] | Membership Update |
| ({G:INCLUDE({S})}) | | ({G:INCLUDE({S})}) |
|======================>| |======================>|
| | | |
----------------------:-----------------------:---------------------- ---------------------:-----------------------:---------------------
| | | | | | | |
| | *Multicast Data | *IP Packet(S,G) | | | *Multicast Data | *IP Packet(S,G) |
| | gADDR,gPORT |<------------------() | | | gADDR,gPORT |<-----------------() |
| *IP Packet(S,G) |<======================| | | *IP Packet(S,G) |<======================| |
| ()<------------------| | | | ()<-----------------| | |
| | | | | | | |
----------------------:-----------------------:---------------------- ---------------------:-----------------------:---------------------
~ | ~ ~
~ Request | ~ Request ~
[4] | N' | [4] | N' |
|---------------------->| |---------------------->|
| Membership Query | [5] | Membership Query | [5]
| N',MAC',gADDR',gPORT' | | N',MAC',gADDR',gPORT' |
|<======================| |<======================|
[6] | | [6] | |
| Teardown | | Teardown |
| N,MAC,gADDR,gPORT | | N,MAC,gADDR,gPORT |
|---------------------->| |---------------------->|
| | [7] | | [7]
| Membership Update | | Membership Update |
| ({G:INCLUDE({S})}) | | ({G:INCLUDE({S})}) |
|======================>| |======================>|
| | | |
----------------------:-----------------------:---------------------- ---------------------:-----------------------:---------------------
| | | | | | | |
| | *Multicast Data | *IP Packet(S,G) | | | *Multicast Data | *IP Packet(S,G) |
| | gADDR',gPORT' |<------------------() | | | gADDR',gPORT' |<-----------------() |
| *IP Packet (S,G) |<======================| | | *IP Packet (S,G) |<======================| |
| ()<------------------| | | | ()<-----------------| | |
| | | | | | | |
----------------------:-----------------------:---------------------- ---------------------:-----------------------:---------------------
| | | |
: : : :
Figure 3: Teardown Message Sequence (IGMPv3/MLDv2 Example) Figure 8: Teardown Message Sequence (IGMPv3/MLDv2 Example)
The following sequence describes how the Membership Query and The following sequence describes how the Membership Query and
Teardown message are used to detect an address change and stop the Teardown message are used to detect an address change and stop the
delivery of Multicast Data messages to an address: delivery of Multicast Data messages to an address:
1. A gateway sends a Request message containing a random nonce to 1. A gateway sends a Request message containing a random nonce to
the relay. the relay.
2. The relay sends a Membership Query message to the gateway that 2. The relay sends a Membership Query message to the gateway that
contains the source IP address (gADDR) and source UDP port contains the source IP address (gADDR) and source UDP port
skipping to change at page 26, line 48 skipping to change at page 25, line 7
compares the gateway address and port number values against those compares the gateway address and port number values against those
returned in the previous Membership Query message. returned in the previous Membership Query message.
7. If the reported address or port has changed, the gateway sends a 7. If the reported address or port has changed, the gateway sends a
Teardown message to the relay that contains the request nonce, Teardown message to the relay that contains the request nonce,
MAC, gateway IP address and gateway port number returned in the MAC, gateway IP address and gateway port number returned in the
earlier Membership Query message. The gateway may send the earlier Membership Query message. The gateway may send the
Teardown message multiple times where the number of repetitions Teardown message multiple times where the number of repetitions
is governed by the Querier Robustness Variable (QRV) value is governed by the Querier Robustness Variable (QRV) value
contained in the IGMPv3/MLDv2 general query carried by the contained in the IGMPv3/MLDv2 general query carried by the
original Membership Query. The gateway continues to process the original Membership Query (See Section 4.1.6 in [RFC3376] and
new Membership Query message as usual. Section 5.1.8 in [RFC3810]). The gateway continues to process
the new Membership Query message as usual.
8. When the relay receives a Teardown message, it computes a MAC 8. When the relay receives a Teardown message, it computes a MAC
from a private secret and the request nonce, gateway IP address, from the message source IP address, source UDP port, request
and gateway port number carried by the Teardown message. The nonce and a private secret. The relay accepts the Teardown
relay accepts the Teardown message if the received MAC matches message if the received MAC matches the computed MAC, otherwise
the computed MAC, otherwise the message is ignored. If the the message is ignored. If the message is accepted, the relay
message is accepted, the relay makes any group membership, makes any group membership, routing and forwarding state changes
routing and forwarding state changes required to stop the required to stop the transmission of Multicast Data messages to
transmission of Multicast Data messages to that address. that address.
4.2.1.4. Timeout and Retransmission 4.2.1.4. Timeout and Retransmission
The AMT protocol does not establish any requirements regarding what The AMT protocol does not establish any requirements regarding what
actions a gateway should take if it fails to receive a response from actions a gateway should take if it fails to receive a response from
a relay. A gateway implementation may wait for an indefinite period a relay. A gateway implementation may wait for an indefinite period
of time to receive a response, may set a time limit on how long to of time to receive a response, may set a time limit on how long to
wait for a response, may retransmit messages should the time limit be wait for a response, may retransmit messages should the time limit be
reached, may limit the number of retransmissions, or may simply reached, may limit the number of retransmissions, or may simply
report an error. report an error.
skipping to change at page 28, line 26 skipping to change at page 26, line 36
to delete any and all subscriptions bound to the tunnel endpoint. to delete any and all subscriptions bound to the tunnel endpoint.
o The relay stops receiving updates from the gateway until such time o The relay stops receiving updates from the gateway until such time
that per-group or per-tunnel timers expire, causing the relay to that per-group or per-tunnel timers expire, causing the relay to
delete the subscriptions. delete the subscriptions.
The tunneling approach described above conceptually transforms a The tunneling approach described above conceptually transforms a
unicast-only inter-network into an NBMA link layer, over which unicast-only inter-network into an NBMA link layer, over which
multicast traffic may be delivered. Each relay, plus the set of all multicast traffic may be delivered. Each relay, plus the set of all
gateways using the relay, together may be thought of as being on a gateways using the relay, together may be thought of as being on a
separate logical NBMA link, where the "link layer" address is a separate logical NBMA link, where the "link layer" address is a UDP/
UDP/IP address-port pair provided by the Membership Update message. 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 changes unexpectedly. These changes may messages it sends to a relay changes unexpectedly. These changes may
skipping to change at page 30, line 6 skipping to change at page 28, line 30
| |---------->| |--------->| | | |---------->| |--------->| |
| Gateway | | Mapping | | Relay | | Gateway | | Mapping | | Relay |
| |<----------| |<---------| | | |<----------| |<---------| |
+---------+ +-----------+ +---------+ +---------+ +-----------+ +---------+
| | | |
+---------+ +---------+
Multicast Data Multicast Data Multicast Data Multicast Data
src: rADDR:rPORT src: rADDR:rPORT src: rADDR:rPORT src: rADDR:rPORT
dst: iADDR:iPORT dst: eADDR:ePORT dst: iADDR:iPORT dst: eADDR:ePORT
Network Address Translation in AMT Figure 9: Network Address Translation in AMT
AMT provides automatic NAT traversal by using the source IP address AMT provides automatic NAT traversal by using the source IP address
and UDP port carried by the Membership Update message as received at and UDP port carried by the Membership Update message as received at
the relay as the destination address for any Multicast Data messages the relay as the destination address for any Multicast Data messages
the relay sends back as a result. the relay sends back as a result.
The NAT mapping created by a Membership Update message will The NAT mapping created by a Membership Update message will
eventually expire unless it is refreshed by a passing message. This eventually expire unless it is refreshed by a passing message. This
refresh will occur each time the gateway performs the periodic update refresh will occur each time the gateway performs the periodic update
required to refresh group state within the relay (See required to refresh group state within the relay (See
skipping to change at page 30, line 28 skipping to change at page 29, line 4
4.2.2.3. UDP Encapsulation 4.2.2.3. UDP Encapsulation
Gateway Relay Gateway Relay
IP:IGMP IP:IGMP IP:IGMP IP:IGMP
| AMT:IP:IGMP AMT:IP:IGMP | | AMT:IP:IGMP AMT:IP:IGMP |
| | | | | | | |
| | IP:UDP:AMT:IP:IGMP | | | | IP:UDP:AMT:IP:IGMP | |
_______ | ___ | ______ | ______ | ___ | _______ _______ | ___ | ______ | ______ | ___ | _______
|IGMP|IP| v |AMT| v |UDP|IP| v |IP|UDP| v |AMT| v |IP|IGMP| |IGMP|IP| v |AMT| v |UDP|IP| v |IP|UDP| v |AMT| v |IP|IGMP|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |<------------------------------------------------------->| | | |<------------------------------------------------------->| |
|____| | | | | | | | | | | | | |____| |____| | | | | | | | | | | | | |____|
| |<--------------------------------------------------| | | |<--------------------------------------------------| |
|_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______| |_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______|
| | | | | | | | | |
IP AMT:IP IP:UDP:AMT:IP AMT:IP IP IP AMT:IP IP:UDP:AMT:IP AMT:IP IP
AMT Encapsulation Figure 10: 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 or datagram fragment that arrives at the - each multicast IP datagram or datagram fragment that arrives at the
relay is encapsulated in an AMT message and transmitted to one or relay is encapsulated in an AMT message and transmitted to one or
more 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
skipping to change at page 31, line 18 skipping to change at page 29, line 43
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 that is described UDP-based tunneling protocols that is described [RFC6936]. A
[I-D.ietf-6man-udpzero]. A recommended solution is described in recommended solution is described in [RFC6935].
[I-D.ietf-6man-udpchecksums].
4.2.2.4. UDP Fragmentation
Naive encapsulation of a multicast IP datagrams within an AMT data
messages may produce UDP datagrams that might require fragmentation
if their size exceeds the MTU of network path between the relay and a
gateway. Many multicast applications, especially those related to
media streaming, are designed to deliver independent data samples in
separate packets, without fragmentation, to ensure some number of
complete samples can be delivered even in the presence of packet
loss. To prevent or reduce undesirable fragmentation, the AMT
protocol describes specific procedures for handling multicast
datagrams whose encapsulation might exceed the path MTU. These
procedures are described in Section 5.3.3.6.
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:
+--------------+---------------------+ +--------------+---------------------+
| Message Type | Message Name | | Message Type | Message Name |
+--------------+---------------------+ +--------------+---------------------+
| 1 | Relay Discovery | | 1 | Relay Discovery |
| | | | | |
| 2 | Relay Advertisement | | 2 | Relay Advertisement |
| | | | | |
| 3 | Request | | 3 | Request |
| | | | | |
| 4 | Membership Query | | 4 | Membership Query |
| | | | | |
| 5 | Membership Update | | 5 | Membership Update |
| | | | | |
| 6 | Multicast Data | | 6 | Multicast Data |
| | | | | |
| 7 | Teardown | | 7 | Teardown |
+--------------+---------------------+ +--------------+---------------------+
These messages are exchanged as IPv4 or IPv6 UDP datagrams. These messages are exchanged as IPv4 or IPv6 UDP datagrams.
5.1.1. Relay Discovery 5.1.1. Relay Discovery
A Relay Discovery message is used to solicit a response from a relay A Relay Discovery message is used to solicit a response from a relay
in the form of a Relay Advertisement message. in the form of a Relay Advertisement message.
The UDP/IP datagram containing this message MUST carry a valid, non- The UDP/IP datagram containing this message MUST carry a valid, non-
skipping to change at page 33, line 8 skipping to change at page 31, line 18
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 (See
Section 7.3).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Relay Discovery Message Format Figure 11: Relay Discovery Message Format
5.1.1.1. Version (V) 5.1.1.1. Version (V)
The protocol version number for this message is 0. The protocol version number for this message is 0.
5.1.1.2. Type 5.1.1.2. Type
The type number for this message is 1. The type number for this message is 1.
5.1.1.3. Reserved 5.1.1.3. Reserved
skipping to change at page 34, line 34 skipping to change at page 32, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=2 | Reserved | | V=0 |Type=2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce | | Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Relay Address (IPv4 or IPv6) ~ ~ Relay Address (IPv4 or IPv6) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Relay Advertisement Message Format Figure 12: Relay Advertisement Message Format
5.1.2.1. Version (V) 5.1.2.1. Version (V)
The protocol version number for this message is 0. The protocol version number for this message is 0.
5.1.2.2. Type 5.1.2.2. Type
The type number for this message is 2. The type number for this message is 2.
5.1.2.3. Reserved 5.1.2.3. Reserved
skipping to change at page 36, line 13 skipping to change at page 34, line 13
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=3 | Reserved |P| Reserved | | V=0 |Type=3 | Reserved |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request Message Format Figure 13: Request Message Format
5.1.3.1. Version (V) 5.1.3.1. Version (V)
The protocol version number for this message is 0. The protocol version number for this message is 0.
5.1.3.2. Type 5.1.3.2. Type
The type number for this message is 3. The type number for this message is 3.
5.1.3.3. Reserved 5.1.3.3. Reserved
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.3.4. P Flag 5.1.3.4. P Flag
The "P" flag is set to indicate which group membership protocol the The "P" flag is set to indicate which group membership protocol the
gateway wishes the relay to use in the Membership Query response: gateway wishes the relay to use in the Membership Query response:
Value Meaning Value Meaning
0 The relay MUST respond with a Membership Query message that
contains an IPv4 packet carrying an IGMPv3 general query
message.
1 The relay MUST respond with a Membership Query message that 0 The relay MUST respond with a Membership Query message that
contains an IPv6 packet carrying an MLDv2 general query contains an IPv4 packet carrying an IGMPv3 general query
message. message.
1 The relay MUST respond with a Membership Query message that
contains an IPv6 packet carrying an MLDv2 general query
message.
5.1.3.5. Request Nonce 5.1.3.5. Request Nonce
A 32-bit random value generated by the gateway and echoed by the A 32-bit random value generated by the gateway and echoed by the
relay in a Membership Query message. This value is used by the relay relay in a Membership Query message. This value is used by the relay
to compute the Response MAC value and is used by the gateway to to compute the Response MAC value and is used by the gateway to
correlate Membership Query messages with Request messages. Request correlate Membership Query messages with Request messages. Request
nonce generation is described in Section 5.2.3.5.6. nonce generation is described in Section 5.2.3.5.6.
5.1.4. Membership Query 5.1.4. Membership Query
skipping to change at page 38, line 31 skipping to change at page 36, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
+ + + +
| Gateway IP Address (IPv4 or IPv6) | | Gateway IP Address (IPv4 or IPv6) |
+ + + +
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Membership Query Message Format Figure 14: Membership Query Message Format
5.1.4.1. Version (V) 5.1.4.1. Version (V)
The protocol version number for this message is 0. The protocol version number for this message is 0.
5.1.4.2. Type 5.1.4.2. Type
The type number for this message is 4. The type number for this message is 4.
5.1.4.3. Reserved 5.1.4.3. Reserved
skipping to change at page 40, line 4 skipping to change at page 37, line 31
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 as The source address carried by the query message should be set as
described in Section 5.3.3.3. 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 QQIC
field is defined in Section 4.1.7 in [RFC3376] and Section 5.1.9 in
[RFC3810].
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
send a Teardown message. send a Teardown message. The QRV field is defined in Section 4.1.6
in [RFC3376] and Section 5.1.8 in [RFC3810].
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 message - 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
skipping to change at page 40, line 36 skipping to change at page 38, line 18
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.
5.1.4.9.2. Gateway IP Address 5.1.4.9.2. Gateway IP Address
A 16-byte IP address that, when combined with the value contained in A 16-byte IP address that, when combined with the value contained in
the Gateway Port Number field, forms the gateway endpoint address the Gateway Port Number field, forms the gateway endpoint address
that the relay will use to identify the tunnel instance, if any, that the relay will use to identify the tunnel instance, if any,
created by a subsequent Membership Update message. This field may created by a subsequent Membership Update message. This field may
contain an IPv6 address or an IPv4 address stored as an IPv4- contain an IPv6 address or an IPv4 address stored as an
compatible IPv6 address, where the IPv4 address is prefixed with 96 IPv4-compatible IPv6 address, where the IPv4 address is prefixed with
bits set to zero (See [RFC4291]). This address must match that used 96 bits set to zero (See [RFC4291]). This address must match that
by the relay to compute the value stored in the Response MAC field. used by the relay to compute the value stored in the Response MAC
field.
5.1.5. Membership Update 5.1.5. Membership Update
A gateway sends a Membership Update message to a relay to report a A gateway sends a Membership Update message to a relay to report a
change in group membership state, or to report the current group change in group membership state, or to report the current group
membership state in response to receiving a Membership Query message. membership state in response to receiving a Membership Query message.
The gateway encapsulates the IGMP or MLD message as an IP datagram The gateway encapsulates the IGMP or MLD message as an IP datagram
within a Membership Update message and sends it to the relay, where within a Membership Update message and sends it to the relay, where
it may (see below) be decapsulated and processed by the relay to it may (see below) be decapsulated and processed by the relay to
update group membership and forwarding state. update group membership and forwarding state.
skipping to change at page 41, line 39 skipping to change at page 39, line 21
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 Multicast Data messages from the relay. This port must listen for Multicast Data messages from the relay. This port must
be the same port used to send the initial Request message or the be the same port used to send the initial Request message or the
message will be ignored. Note: The value of this field may be message will be ignored. 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 - The unicast IP address of the relay. Destination IP Address - The unicast IP address of the relay.
Destination UDP Port - The IANA-assigned AMT UDP 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=5 | Reserved | Response MAC | | V=0 |Type=5 | Reserved | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Encapsulated Group Membership Update Message | | Encapsulated Group Membership Update Message |
~ IPv4:IGMP(Membership Report|Leave Group) ~ ~ IPv4:IGMP(Membership Report|Leave Group) ~
| IPv6:MLD(Listener Report|Listener Done) | | IPv6:MLD(Listener Report|Listener Done) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Membership Update Message Format Figure 15: Membership Update Message Format
5.1.5.1. Version (V) 5.1.5.1. Version (V)
The protocol version number for this message is 0. The protocol version number for this message is 0.
5.1.5.2. Type 5.1.5.2. Type
The type number for this message is 5. The type number for this message is 5.
5.1.5.3. Reserved 5.1.5.3. Reserved
skipping to change at page 44, line 17 skipping to change at page 41, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=6 | Reserved | | | V=0 |Type=6 | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
~ IP Multicast Packet ~ ~ IP Multicast Packet ~
| | | |
+ - - - - - - - - - - - - - - - - - - - - - - - -+ + - - - - - - - - - - - - - - - - - - - - - - - -+
| : : : : | : : : :
+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - - +-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - -
Multicast Data Message Format Figure 16: Multicast Data Message Format
5.1.6.1. Version (V) 5.1.6.1. Version (V)
The protocol version number for this message is 0. The protocol version number for this message is 0.
5.1.6.2. Type 5.1.6.2. Type
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
skipping to change at page 45, line 42 skipping to change at page 43, line 11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
+ + + +
| Gateway IP Address (IPv4 or IPv6) | | Gateway IP Address (IPv4 or IPv6) |
+ + + +
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Membership Teardown Message Format Figure 17: Membership Teardown Message Format
5.1.7.1. Version (V) 5.1.7.1. Version (V)
The protocol version number for this message is 0. The protocol version number for this message is 0.
5.1.7.2. Type 5.1.7.2. Type
The type number for this message is 7. The type number for this message is 7.
5.1.7.3. Reserved 5.1.7.3. Reserved
skipping to change at page 46, line 18 skipping to change at page 43, line 34
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. The relay validates fields carried by the Membership Query message. The relay validates
the Teardown message by comparing this value with one computed from the Teardown message by comparing this value with one computed from
the Request Nonce, Gateway Port Number and Gateway IP Address fields the Gateway IP Address, Gateway Port Number, Request Nonce fields and
(just as it does in the Membership Update message). a private secret (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 48, line 15 skipping to change at page 45, line 40
pseudo-interface might not possess a valid IPv6 address. As with pseudo-interface might not possess a valid IPv6 address. As with
IGMP, a relay will accept an MLD report carried by a Membership 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. See
Section 4.1.6 in [RFC3376] and Section 5.1.8 in [RFC3810].
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.
An IPv4 gateway implementation MUST accept IPv4 datagrams that carry An IPv4 gateway implementation MUST accept IPv4 datagrams that carry
the general query variant of the IGMPv3 Membership Query message, as the general query variant of the IGMPv3 Membership Query message, as
described in Section 4 of [RFC3376]. The gateway MUST accept the described in Section 4 of [RFC3376]. The gateway MUST accept the
IGMP datagram regardless of the IP source address carried by that IGMP datagram regardless of the IP source address carried by that
skipping to change at page 50, line 29 skipping to change at page 48, line 12
o Optionally execute the membership query procedure described in o Optionally execute the membership query procedure described in
Section 5.2.3.5 to start the periodic membership update cycle. Section 5.2.3.5 to start the periodic membership update cycle.
5.2.3.2. Handling AMT Messages 5.2.3.2. Handling AMT Messages
A gateway MUST ignore any datagram it receives that cannot be A gateway MUST ignore any datagram it receives that cannot be
interpreted as a Relay Advertisement, Membership Query, or Multicast interpreted as a Relay Advertisement, Membership Query, or Multicast
Data message. The handling of Relay Advertisement, Membership Query, Data message. The handling of Relay Advertisement, Membership Query,
and Multicast Data messages is addressed in the sections that follow. and Multicast Data messages is addressed in the sections that follow.
A gateway that conforms to this specification MUST ignore any message
with a Version field value other than zero.
While listening for AMT messages, a gateway may be notified that an While listening for AMT messages, a gateway 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
AMT message transmission. Handling of ICMP Destination Unreachable AMT message transmission. Handling of ICMP Destination Unreachable
messages is described in Section 5.2.3.9. messages is described in Section 5.2.3.9.
5.2.3.3. Handling Multicast Data Messages 5.2.3.3. Handling Multicast Data Messages
A gateway may receive Multicast Data messages after it sends a A gateway may receive Multicast Data messages after it sends a
Membership Update message to a relay that adds a group subscription. Membership Update message to a relay that adds a group subscription.
The gateway may continue to receive Multicast Data messages long The gateway may continue to receive Multicast Data messages long
skipping to change at page 51, line 17 skipping to change at page 48, line 51
relevant 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 [RFC6936]. If supported, a gateway SHOULD
gateway SHOULD employ the solution described in employ the solution described in [RFC6936] to ensure that the local
[I-D.ietf-6man-udpchecksums] to ensure that the local IP stack does IP stack does not discard IPv6 datagrams with zero checksums. If
not discard IPv6 datagrams with zero checksums. If Multicast Data Multicast Data message datagrams are processed directly within the
message datagrams are processed directly within the gateway (instead gateway (instead of the host IP stack), the gateway MUST NOT discard
of the host IP stack), the gateway MUST NOT discard any of these any of these datagrams because they carry a UDP checksum of zero.
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 52, line 11 skipping to change at page 49, line 39
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
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 AMT 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
skipping to change at page 54, line 5 skipping to change at page 50, line 48
If a gateway executes the relay discovery procedure at the start of If a gateway executes the relay discovery procedure at the start of
each membership update cycle and the relay address returned in the each membership update cycle and the relay address returned in the
latest Relay Advertisement message differs from the address returned latest Relay Advertisement message differs from the address returned
in a previous Relay Advertisement message, then the gateway SHOULD in a previous Relay Advertisement message, then the gateway SHOULD
send a Teardown message (if supported) to the old relay address, send a Teardown message (if supported) to the old relay address,
using information from the last Membership Query message received using information from the last Membership Query message received
from that relay, as described in Section 5.2.3.7. This behavior is from that relay, as described in Section 5.2.3.7. This behavior is
illustrated in the following diagram. illustrated in the following diagram.
Gateway Relay-1 Gateway Relay-1
------- ------- ------- -------
: : : :
Query Expired | | Query Expired | |
Timer (QT)-------->| | Timer (QT)-------->| |
| Relay Discovery | | Relay Discovery |
|------------------->| |------------------->|
| | | |
| Relay Advertisement| | Relay Advertisement|
|<-------------------| |<-------------------|
| | | |
| Request | | Request |
|------------------->| |------------------->|
| | | |
| Membership Query | | Membership Query |
|<===================| |<===================|
Start | | Start | |
(QT)<--------| Membership Update | (QT)<--------| Membership Update |
|===================>| |===================>|
| | | |
~ ~ Relay-2 ~ ~ Relay-2
Expired | | ------- Expired | | -------
(QT)-------->| | : (QT)-------->| | :
| Relay Discovery | | | Relay Discovery | |
|------------------------------------>| |------------------------------------>|
| | | | | |
| Relay Advertisement| | | Relay Advertisement| |
|<------------------------------------| |<------------------------------------|
| | | | | |
| Teardown | | | Teardown | |
|------------------->| | |------------------->| |
| | | | | |
| Request | | | Request | |
|------------------------------------>| |------------------------------------>|
| | | | | |
| Membership Query | | | Membership Query | |
|<====================================| |<====================================|
Start | | | Start | | |
(QT)<--------| Membership Update | | (QT)<--------| Membership Update | |
|====================================>| |====================================>|
| | | | | |
: : : : : :
Teardown After Relay Address Change Figure 18: Teardown After Relay Address Change
5.2.3.4.5. Discovery Nonce Generation 5.2.3.4.5. Discovery Nonce Generation
The discovery nonce MUST be a random, non-zero, 32-bit value, and if The discovery nonce MUST be a random, non-zero, 32-bit value, and if
possible, SHOULD be computed using a cryptographically secure pseudo possible, SHOULD be computed using a cryptographically secure pseudo
random number generator. A new nonce SHOULD be generated each time random number generator. A new nonce SHOULD be generated each time
the gateway restarts the relay discovery process. The same nonce the gateway restarts the relay discovery process. The same nonce
SHOULD be used when retransmitting a Relay Discovery message. SHOULD be used when retransmitting a Relay Discovery message.
5.2.3.5. Membership Query Procedure 5.2.3.5. Membership Query Procedure
skipping to change at page 60, line 24 skipping to change at page 57, line 19
When a gateway sends a Membership Update message, it may be notified When a gateway sends a Membership Update 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.
5.2.3.7. Teardown Procedure 5.2.3.7. Teardown Procedure
This section describes gateway requirements related to the teardown This section describes gateway requirements related to the teardown
message sequence described in Section 4.2.1.3. message sequence described in Section 4.2.1.3.
Gateway support for the Teardown message is OPTIONAL but RECOMMENDED. Gateway support for the Teardown message is RECOMMENDED.
A gateway that supports Teardown SHOULD make use of Teardown A gateway that supports Teardown SHOULD make use of Teardown
functionality if it receives a Membership Query message from a relay functionality if it receives a Membership Query message from a relay
that has the "G" flag set to indicate that it contains valid gateway that has the "G" flag set to indicate that it contains valid gateway
address fields. address fields.
5.2.3.7.1. Handling a Membership Query Message 5.2.3.7.1. Handling a Membership Query Message
As described in Section 5.2.3.5.4, if a gateway supports the Teardown As described in Section 5.2.3.5.4, if a gateway supports the Teardown
message, has reported active group subscriptions, and receives a message, has reported active group subscriptions, and receives a
skipping to change at page 61, line 10 skipping to change at page 58, line 5
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 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 (See Section 4.1.6 in
[RFC3376] and Section 5.1.7 in [RFC3810]). 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
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.
skipping to change at page 61, line 38 skipping to change at page 58, line 34
message, and the current relay is returning gateway address fields message, and the current relay is returning gateway address fields
in Membership Query messages, or in Membership Query messages, or
o Send a Membership Update message to the relay that will delete o Send a Membership Update message to the relay that will delete
existing group subscriptions. existing group subscriptions.
5.2.3.9. Handling ICMP Destination Unreachable Responses 5.2.3.9. Handling ICMP Destination Unreachable Responses
A gateway may receive an ICMP "Destination Unreachable" message A gateway may receive an ICMP "Destination Unreachable" message
[RFC0792] after sending an AMT message. Whether the gateway is [RFC0792] after sending an AMT message. Whether the gateway is
notified that an ICMP message was received is highly dependent the notified that an ICMP message was received is highly dependent on
gateway IP stack behavior and gateway implementation. firewall and gateway IP stack behavior and gateway implementation.
If the reception of an ICMP Destination Unreachable message is If the reception of an ICMP Destination Unreachable message is
reported to the gateway while waiting to receive an AMT message, the reported to the gateway while waiting to receive an AMT message, the
gateway may respond as follows, depending on platform capabilities gateway may respond as follows, depending on platform capabilities
and which outgoing message triggered the ICMP response: and which outgoing message triggered the ICMP response:
1. The gateway MAY simply abandon the current relay and restart 1. The gateway MAY simply abandon the current relay and restart
relay discovery (if used). This is the least desirable approach relay discovery (if used). This is the least desirable approach
as it does not allow for transient network changes. as it does not allow for transient network changes.
skipping to change at page 65, line 9 skipping to change at page 62, line 9
If a relay supports the Teardown message, it MUST set the G-flag in If a relay supports the Teardown message, it MUST set the G-flag in
the Membership Query message and return the source IP address and UDP the Membership Query message and return the source IP address and UDP
port carried by the Request message in the corresponding Gateway IP port carried by the Request message in the corresponding Gateway IP
Address and Gateway Port Number fields. If the relay does not Address and Gateway Port Number fields. If the relay does not
support the Teardown message it SHOULD NOT set these fields as this support the Teardown message it SHOULD NOT set these fields as this
may cause the gateway to generate unnecessary Teardown messages. may cause the gateway to generate unnecessary Teardown messages.
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
encapsulated MLDv2 general query in the Membership Query message. IPv6-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 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],
skipping to change at page 65, line 48 skipping to change at page 62, line 49
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.
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.7 in [RFC3376] and Section 5.1.9 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 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. The QRV field
is defined in Section 4.1.6 in [RFC3376] and Section 5.1.8 in
[RFC3810].
A relay SHOULD set the Max Resp Code field in the general query to a A relay SHOULD set the Maximum Response Code field in the general
value of 1 to trigger an immediate response from the gateway (some query to a value of 1 to trigger an immediate response from the
host IGMP/MLD implementations may not accept a value of zero). A gateway (some host IGMP/MLD implementations may not accept a value of
relay SHOULD NOT use the IGMPv2/MLDv2 Query Response Interval zero). A relay SHOULD NOT use the IGMPv2/MLDv2 Query Response
variable, if available, to generate the Max Resp Code field value as Interval variable, if available, to generate the Maximum Response
the Query Response Interval variable is used in setting the duration Code field value as the Query Response Interval variable is used in
of group state timers and must not be set to such a small value. See setting the duration of group state timers and must not be set to
such a small value. The Maximum Response Code field is defined in
Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810]. See
Section 5.3.3.7. Section 5.3.3.7.
5.3.3.4. Handling a Membership Update Message 5.3.3.4. Handling a Membership Update Message
This section describes relay requirements related to the membership This section describes relay requirements related to the membership
update portion of the message sequence described in Section 4.2.1.2. update portion of the message sequence described in Section 4.2.1.2.
When a relay receives a Membership Update message it must first When a relay receives a Membership Update message it must first
determine whether it should accept or ignore the message. A relay determine whether it should accept or ignore the message. A relay
MUST NOT make any changes to group membership and forwarding state if MUST NOT make any changes to group membership and forwarding state if
skipping to change at page 69, line 45 skipping to change at page 67, line 4
MUST be identical to those that would be made as if the relay had MUST be identical to those that would be made as if the relay had
received an IGMP/MLD report that would cause the IGMP or MLD protocol received an IGMP/MLD report that would cause the IGMP or MLD protocol
to delete all existing group records in the group membership database to delete all existing group records in the group membership database
associated with the endpoint. The processing of the Teardown message associated with the endpoint. The processing of the Teardown message
should trigger or mimic the normal interaction between IGMP or MLD should trigger or mimic the normal interaction between IGMP or MLD
and a multicast protocol to produce required changes in forwarding and a multicast protocol to produce required changes in forwarding
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 or messages and send that message or
process is highly implementation dependent, but conceptually requires messages to the gateway. This process is highly implementation
the following steps: dependent, but conceptually requires 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 If the multicast IP datagram size exceeds the Tunnel MTU as
using the endpoint UDP/IP address as the destination address and determined according to the procedure described in
the unicast relay address and IANA-assigned port as the source Section 5.3.3.6.1, the relay must execute the procedure described
UDP/IP address. To ensure successful NAT traversal, the source in Section 5.3.3.6.2.
address and port MUST match the destination address and port
carried by the Membership Update message sent by the gateway to
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 Encapsulate and transmit the IP datagram according to the
procedure described in Section 5.3.3.6.3.
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.6.1. Path and Tunnel MTU
A relay MUST compute a Tunnel MTU (TMTU) value for each AMT tunnel
that originates on the relay. A relay will use the TMTU value to
determine whether an incoming multicast IP datagram can be delivered
downstream in a Membership Data message without fragmentation. A
relay MUST compute the TMTU by subtracting the size of the Membership
Data message headers (IP, UDP, and AMT) from the current Path MTU
(PMTU) associated with each AMT tunnel. The relay MUST maintain a
PMTU value on a per-tunnel or per-relay basis. A relay MUST support
one or both of the following methods for determining the PMTU value:
o The relay MAY provide a configuration option that establishes a
fixed PMTU that will be applied to all AMT tunnels originating at
the relay.
o The relay MAY dynamically adjust PMTU value(s) in response to
receipt of ICMP/ICMPv6 "Datagram Too Big" messages as described in
[RFC1191] and [RFC1981].
If a relay supports dynamic adjustment of per-tunnel or per-relay
PMTU values in response to ICMP messages, the relay MUST provide a
configuration option that disables this feature and also provide a
configuration option that establishes a minimum PMTU for all tunnels.
These configuration options may be used to mitigate certain types of
denial of service attacks (See (Section 6)). When dynamic PMTU
adjustments are disabled, the PMTU for all tunnels MUST default to
the Link MTU (first-hop) on the downstream interface.
5.3.3.6.2. MTU Filtering Procedure
This section defines procedures that a relay must execute when it
receives a multicast datagram whose size is greater than the Tunnel
MTU of the tunnel or tunnels through which it must be delivered.
5.3.3.6.2.1. IPv4 Multicast IP Datagrams
If the DF bit in the multicast datagram header is set to 1 (Don't
Fragment), the relay MUST discard the packet and, if the datagram
originated from an SSM source, send an ICMPv4 [RFC0792] Destination
Unreachable message to the source, with type equal to 4
(fragmentation needed and DF set). The ICMP Destination Unreachable
message MUST contain an next-hop MTU (as specified by [RFC1191] and
[RFC1191]) and the relay MUST set the next-hop MTU to the TMTU
associated with the tunnel or tunnels. If the DF bit in the
multicast datagram header is set to 0 (May Fragment), the relay MUST
fragment the datagram and encapsulate each fragment within Multicast
Data messages for transmission through the tunnel or tunnels. This
ensures that gateways will receive complete, non-fragmented Multicast
Data messages, containing fragmented multicast datagram payloads.
The relay SHOULD avoid generating a separate ICMP message for each
tunnel, but instead send a single ICMP message with a Next-hop MTU
equal to the smallest TMTU of all tunnels to which the datagram was
to be forwarded.
5.3.3.6.2.2. IPv6 Multicast IP Datagrams
The relay MUST discard the packet and, if the datagram originated
from an SSM source, send an ICMPv6 [RFC4443] Packet Too Big message
to the payload source. The MTU specified in the Packet Too Big
message MUST be equal to the TMTU associated with the tunnel or
tunnels. The relay SHOULD avoid generating a separate ICMPv6 message
for each tunnel, but instead send a single ICMPv6 message with a
Next-hop MTU equal to the smallest TMTU of all tunnels to which the
datagram was to be forwarded.
5.3.3.6.3. Encapsulation Procedure
A relay encapsulates a multicast IP datagram in a UDP/IP Membership
Data message, using the tunnel endpoint UDP/IP address as the
destination address and the unicast relay address and IANA-assigned
AMT port number as the source UDP/IP address. To ensure successful
NAT traversal, the source address and port MUST match the destination
address and port carried by the Membership Update message sent by the
gateway to create the forwarding table entry.
If possible, the relay SHOULD compute a valid, non-zero checksum for
the UDP datagram carrying the Multicast Data message. See
Section 4.2.2.3.
The following sections describe additional requirements related to
the IP protocol of the tunnel and that of the multicast IP datagram.
5.3.3.6.3.1. Tunneling over IPv4
When a relay delivers an IPv4 payload over an IPv4 tunnel, and the DF
Bit in the payload header is set to 1 (Don't Fragment), the relay
MUST set the DF bit in the Multicast Data IP header to 1. When a
relay delivers an IPv4 payload over an IPv4 tunnel, and the DF Bit in
the payload header is set to 0 (May Fragment), by default, the relay
MUST set the DF bit in the Multicast Data IP header to 1. However, a
relay MAY provide a configuration option that allows the DF bit to be
copied from the payload header to the Multicast Data IP header to
allow downstream fragmentation of the Multicast Data message. When a
relay delivers an IPv6 payload over an IPv4 tunnel, the relay MUST
set the DF bit in the Multicast Data IP header to 1. The relay MUST
NOT transmit a Multicast Data message with an IP header in which the
MF (More Fragments) bit is set to 1.
5.3.3.6.3.2. Tunneling over IPv6
When a tunneling over IPv6, a relay MUST NOT emit a Multicast Data
message datagram containing an IPv6 fragment header.
5.3.3.6.4. Handling Destination Unreachable Messages
If a relay receives a sequence of ICMP or ICMPv6 messages of type
"Destination Unreachable" in response to transmission of a sequence
of AMT Multicast Data messages to a gateway, the relay SHOULD
discontinue sending messages to that gateway and shutdown the tunnel
for that gateway (Handling of ICMP "Destination Unreachable" messages
with code 4, "fragmentation required" is covered in
Section 5.3.3.6.1). If a relay provides this capability, it MUTST
provide a configuration option that indicates what number of
sequential "Destination Unreachable" messages can be received and
ignored before the relay will automatically shutdown a tunnel.
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
refresh the group membership state within a specified time interval. refresh the group membership state within a specified time interval.
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
skipping to change at page 70, line 52 skipping to change at page 70, line 27
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 endpoint timer duration MAY be computed from tunable IGMP/MLD The endpoint timer duration MAY be computed from tunable 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
to allow for packet loss and round-trip time in the Request/ to allow for packet loss and round-trip time in the Request/
Membership Query message exchange. Membership Query message exchange.
5.3.3.8. Relay Resource Management 5.3.3.8. Relay Resource Management
skipping to change at page 72, line 9 skipping to change at page 71, line 32
o Stop sending data messages to gateways. o Stop sending data messages to gateways.
o Delete all AMT group membership and forwarding state created on o Delete all AMT group membership and forwarding state created on
the relay, coordinating with the multicast routing protocol to the relay, coordinating with the multicast routing protocol to
update the group membership state on upstream interfaces as update the group membership state on upstream interfaces as
required. required.
5.3.5. Response MAC Generation 5.3.5. Response MAC Generation
A Response MAC is produced by a hash digest computation. A Response A Response MAC is produced by a hash digest computation. A Response
MAC value is computed from a Request message for inclusion in a MAC computation is required in the following situations:
Membership Query message, is computed from a Membership Update
message to authenticate the Response MAC carried within that message, o To generate a Response MAC value from a Request message for
and is computed from fields in a Teardown message to authenticate the inclusion in a Membership Query message.
Response MAC carried within that message.
o Tp generate a Response MAC value from a Membership Update message
for use in authenticating the Response MAC carried within that
message.
o To generate a Response MAC value from a Teardown message to
authenticate the Response MAC carried within that message.
Gateways treat the Response MAC field as an opaque value, so a relay Gateways treat the Response MAC field as an opaque value, so a relay
implementation may generate the MAC using any method available to it. implementation may generate the MAC using any method available to it.
The hash function RECOMMENDED for use in computing the Response MAC The hash function RECOMMENDED for use in computing the Response MAC
is the MD5 hash digest [RFC1321], though hash functions or keyed-hash is the MD5 hash digest [RFC1321], though hash functions or keyed-hash
functions of greater cryptographic strength may be used. functions of greater cryptographic strength may be used.
The digest MUST be computed over the following values: The digest MUST be computed over the following values:
o The Source IP address of the message (or Teardown Gateway IP o The Source IP address of the message (or Teardown Gateway IP
skipping to change at page 74, line 22 skipping to change at page 73, line 50
attack to propagate from one relay to the next until all relays attack to propagate from one relay to the next until all relays
reachable using the anycast address have effectively been taken reachable using the anycast address have effectively been taken
offline. This behavior may also be used to acquire the unicast offline. This behavior may also be used to acquire the unicast
addresses for individual relays which can then be used to launch a addresses for individual relays which can then be used to launch a
DDoS attack on all of the relays without using the relay discovery DDoS attack on all of the relays without using the relay discovery
process. To prevent wider disruption of AMT-based distribution process. To prevent wider disruption of AMT-based distribution
network, relay anycast address advertisements can be limited to network, relay anycast address advertisements can be limited to
specific administrative routing domains. This will isolate such specific administrative routing domains. This will isolate such
attacks to a single domain. attacks to a single domain.
The Path and Tunnel MTU adjustment (discovery) procedure described in
Section 5.3.3.6.1 is vulnerable to two denial of service attacks (see
Section 8 of [RFC1191] for details). Both attacks are based upon on
a malicious party sending forged ICMPv4 Destination Unreachable or
ICMPv6 Packet Too Big messages to a host. In the first attack, the
forged message indicates an inordinately small Path MTU. In the
second attack, the forged message indicates an inordinately large
Path MTU. In both cases, throughput is adversely affected. On order
to mitigate such attacks, relay implementations MUST include a
configuration option to disable Path MTU adjustments on AMT tunnels.
6.2. Gateways 6.2. Gateways
A passive eavesdropper may launch a denial-of-service attack on a A passive eavesdropper may launch a denial-of-service attack on a
gateway by capturing a Membership Query or Membership Update message gateway by capturing a Membership Query or Membership Update message
and using the request nonce and message authentication code carried and using the request nonce and message authentication code carried
by the captured message to send a spoofed a Membership Update or by the captured message to send a spoofed a Membership Update or
Teardown message to the relay. The spoofed messages may be used to Teardown message to the relay. The spoofed messages may be used to
modify or destroy group membership state associated with the gateway, modify or destroy group membership state associated with the gateway,
thereby changing or interrupting the multicast traffic flows. thereby changing or interrupting the multicast traffic flows.
skipping to change at page 76, line 9 skipping to change at page 75, line 24
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
IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated to The following unicast prefixes have been assigned to provide anycast
the public AMT Relays to advertise to the native multicast backbone routing of relay discovery messages to public AMT Relays as as
(as described in Section 4.1.4). The prefix length should be described in Section 4.1.4.
determined by the IANA; the prefix should be large enough to
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. IANA has assigned 154.7.0/24 for IPv4 relays.
Internet Systems Consortium (ISC) has offered 154.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 IANA has assigned 2001:0003::/32 for IPv6 relays.
previously set aside the range 2001::/16 for allocating prefixes for
this purpose.
7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses 7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses
IANA should allocate an IPv4 prefix dedicated for use in IGMP IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses.
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 7.3. UDP Port Number
IANA has reserved UDP port number 2268 for AMT. IANA has assigned UDP port number 2268 for AMT.
8. Contributors 8. Contributors
The following people provided significant contributions to the design The following people provided significant contributions to the design
of the protocol and earlier versions of this specification: of the protocol and earlier versions of this specification:
Thomas Morin Thomas Morin
France Telecom - Orange France Telecom - Orange
2, avenue Pierre Marzin 2, avenue Pierre Marzin
Lannion 22300 Lannion 22300
skipping to change at page 79, line 9 skipping to change at page 77, line 19
connectivity without explicit tunnels ("6to4"). Tony Ballardie connectivity without explicit tunnels ("6to4"). Tony Ballardie
provided helpful discussion that inspired this document. provided helpful discussion that inspired this document.
Juniper Networks was instrumental in funding several versions of this Juniper Networks was instrumental in funding several versions of this
draft as well as an open source implementation. draft as well as an open source implementation.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
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] [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled 1981.
Packets", draft-ietf-6man-udpchecksums-02 (work in
progress), March 2012.
[I-D.ietf-6man-udpzero]
Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum
Considerations", draft-ietf-6man-udpzero-05 (work in
progress), December 2011.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
September 1981. RFC 792, September 1981.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993. Anycasting Service", RFC 1546, November 1993.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
Hashing for Message Authentication", RFC 2104, for IP version 6", RFC 1981, August 1996.
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997. 2", RFC 2236, November 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations", RFC
RFC 2663, August 1999. 2663, August 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710, October
October 1999. 1999.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552, July
July 2003. 2003.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Independent Multicast - Dense Mode (PIM-DM): Protocol Protocol 4 (BGP-4)", RFC 4271, January 2006.
Specification (Revised)", RFC 3973, January 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, December 2006. Services", BCP 126, RFC 4786, December 2006.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, April 2013.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, April 2013.
Appendix A. Implementation Notes Appendix A. Implementation Notes
A.1. Response MAC Generation and Keying A.1. Response MAC Generation and Keying
This specification does not require relays to use any particular This specification does not require relays to use any particular
method to compute the Response MAC field value - only that it contain method to compute the Response MAC field value - only that it contain
a hash of the source IP address, source UDP port, request nonce, and a hash of the source IP address, source UDP port, request nonce, and
a private secret known only to the relay. This allows the relay a private secret known only to the relay. This allows the relay
implementor a significant amount of leeway in the computation and implementor a significant amount of leeway in the computation and
structure of the value stored in the Response MAC field. structure of the value stored in the Response MAC field.
skipping to change at page 83, line 16 skipping to change at page 80, line 16
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 |4 or 5| Reserved | | Response MAC | | V=0 |4 or 5| Reserved | | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
The Opaque Response MAC Field Figure 19: The Opaque Response MAC Field
A relay may use the opaque Response MAC field to store a cookie as A relay may use the opaque Response MAC field to store a cookie as
follows: follows:
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 |4 or 5| Reserved | | Timestamp | | V=0 |4 or 5| Reserved | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5(Secret,Timestamp,IP_ADDR,IP_PORT,Request-Nonce) | | MD5(Secret,Timestamp,IP_ADDR,IP_PORT,Request-Nonce) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
Using The Response MAC Field To Carry An Authentication Cookie Figure 20: Using The Response MAC Field To Carry An Authentication
Cookie
The timestamp is an unsigned integer measured relative to the start The timestamp is an unsigned integer measured relative to the start
time of relay. The age of the MAC is computed by subtracting the MAC time of relay. The age of the MAC is computed by subtracting the MAC
timestamp from the current system timestamp. The operands must be timestamp from the current system timestamp. The operands must be
unsigned 16-bit integers and the subtraction must use unsigned unsigned 16-bit integers and the subtraction must use unsigned
arithmetic to allow for timestamp wrap-around. The timestamp arithmetic to allow for timestamp wrap-around. The timestamp
resolution must provide range sufficient to handle the maximum resolution must provide range sufficient to handle the maximum
allowable age for a MAC, e.g., a resolution of 1 second allows a allowable age for a MAC, e.g., a resolution of 1 second allows a
maximum age of 18 hours. The timestamp should start at a random maximum age of 18 hours. The timestamp should start at a random
value by adding a random offset, computed at startup, to the current value by adding a random offset, computed at startup, to the current
system time. system time.
+-------------------------+----------------/ /-----------------+ +-------------------------+--------------/ /-----------------+
-->| Timestamp(N1) [16-bits] | Random Secret [128-bits] | -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |
| +-------------------------+----------------/ /-----------------+ | +-------------------------+--------------/ /-----------------+
|_____________________________________________________________________ |___________________________________________________________________
| |
+-------------------------+----------------/ /-----------------+ | +-------------------------+--------------/ /-----------------+ |
-->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |-- -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |--
| +-------------------------+----------------/ /-----------------+
|_____________________________________________________________________ | +-------------------------+--------------/ /-----------------+
|___________________________________________________________________
| |
+-------------------------+----------------/ /-----------------+ | +-------------------------+--------------/ /-----------------+ |
-->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |-- -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |--
| +-------------------------+----------------/ /-----------------+ | +-------------------------+--------------/ /-----------------+
| |
|__ Current |__ Current
Secret Secret
Private Secret Queue Figure 21: Private Secret Queue
The timestamp is not only used to compute the age of the MAC, but is The timestamp is not only used to compute the age of the MAC, but is
also used to lookup the private secret used to generate the MAC. also used to lookup the private secret used to generate the MAC.
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.
Author's Address Author's Address
Gregory Bumgardner Gregory Bumgardner
Cisco
3700 Cisco Way
San Jose, CA 95134
USA
Phone: +1 408 853 4993 Phone: +1 541 343 6790
Email: gbumgard@cisco.com Email: gbumgard@gmail.com
 End of changes. 129 change blocks. 
451 lines changed or deleted 631 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/