draft-ietf-mboned-auto-multicast-16.txt   draft-ietf-mboned-auto-multicast-17.txt 
Network Working Group G. Bumgardner Network Working Group G. Bumgardner
Internet-Draft Internet-Draft
Intended status: Standards Track October 21, 2013 Intended status: Standards Track April 24, 2014
Expires: April 24, 2014 Expires: October 26, 2014
Automatic Multicast Tunneling Automatic Multicast Tunneling
draft-ietf-mboned-auto-multicast-16 draft-ietf-mboned-auto-multicast-17
Abstract Abstract
This document describes Automatic Multicast Tunneling (AMT), a This document describes Automatic Multicast Tunneling (AMT), a
protocol for delivering multicast traffic from sources in a protocol for delivering multicast traffic from sources in a
multicast-enabled network to receivers that lack multicast multicast-enabled network to receivers that lack multicast
connectivity to the source network. The protocol uses UDP connectivity to the source network. The protocol uses UDP
encapsulation and unicast replication to provide this functionality. encapsulation and unicast replication to provide this functionality.
The AMT protocol is specifically designed to support rapid deployment The AMT protocol is specifically designed to support rapid deployment
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014. This Internet-Draft will expire on October 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 37 skipping to change at page 2, line 37
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. General Architecture . . . . . . . . . . . . . . . . . . 6 4.1. General Architecture . . . . . . . . . . . . . . . . . . 6
4.1.1. Relationship to IGMP and MLD Protocols . . . . . . . 7 4.1.1. Relationship to IGMP and MLD Protocols . . . . . . . 7
4.1.2. Gateways . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2. Gateways . . . . . . . . . . . . . . . . . . . . . . 8
4.1.3. Relays . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.3. Relays . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.4. Deployment . . . . . . . . . . . . . . . . . . . . . 13 4.1.4. Deployment . . . . . . . . . . . . . . . . . . . . . 13
4.1.5. Discovery . . . . . . . . . . . . . . . . . . . . . . 15 4.1.5. Discovery . . . . . . . . . . . . . . . . . . . . . . 15
4.2. General Operation . . . . . . . . . . . . . . . . . . . . 16 4.2. General Operation . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Message Sequences . . . . . . . . . . . . . . . . . . 16 4.2.1. Message Sequences . . . . . . . . . . . . . . . . . . 16
4.2.2. Tunneling . . . . . . . . . . . . . . . . . . . . . . 25 4.2.2. Tunneling . . . . . . . . . . . . . . . . . . . . . . 26
5. Protocol Description . . . . . . . . . . . . . . . . . . . . 30 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 31
5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 30 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 31
5.1.1. Relay Discovery . . . . . . . . . . . . . . . . . . . 30 5.1.1. Relay Discovery . . . . . . . . . . . . . . . . . . . 31
5.1.2. Relay Advertisement . . . . . . . . . . . . . . . . . 32 5.1.2. Relay Advertisement . . . . . . . . . . . . . . . . . 32
5.1.3. Request . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.3. Request . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.4. Membership Query . . . . . . . . . . . . . . . . . . 34 5.1.4. Membership Query . . . . . . . . . . . . . . . . . . 36
5.1.5. Membership Update . . . . . . . . . . . . . . . . . . 38 5.1.5. Membership Update . . . . . . . . . . . . . . . . . . 39
5.1.6. Multicast Data . . . . . . . . . . . . . . . . . . . 40 5.1.6. Multicast Data . . . . . . . . . . . . . . . . . . . 42
5.1.7. Teardown . . . . . . . . . . . . . . . . . . . . . . 42 5.1.7. Teardown . . . . . . . . . . . . . . . . . . . . . . 43
5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 44 5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 46
5.2.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 44 5.2.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 46
5.2.2. Pseudo-Interface Configuration . . . . . . . . . . . 46 5.2.2. Pseudo-Interface Configuration . . . . . . . . . . . 47
5.2.3. Gateway Service . . . . . . . . . . . . . . . . . . . 47 5.2.3. Gateway Service . . . . . . . . . . . . . . . . . . . 49
5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 59 5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 61
5.3.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 59 5.3.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 61
5.3.2. Startup . . . . . . . . . . . . . . . . . . . . . . . 60 5.3.2. Startup . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.3. Running . . . . . . . . . . . . . . . . . . . . . . . 60 5.3.3. Running . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.4. Shutdown . . . . . . . . . . . . . . . . . . . . . . 71 5.3.4. Shutdown . . . . . . . . . . . . . . . . . . . . . . 73
5.3.5. Response MAC Generation . . . . . . . . . . . . . . . 71 5.3.5. Response MAC Generation . . . . . . . . . . . . . . . 73
5.3.6. Private Secret Generation . . . . . . . . . . . . . . 72 5.3.6. Private Secret Generation . . . . . . . . . . . . . . 74
6. Security Considerations . . . . . . . . . . . . . . . . . . . 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 74
6.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . . 73 6.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 74 6.2. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3. Encapsulated IP Packets . . . . . . . . . . . . . . . . . 75 6.3. Encapsulated IP Packets . . . . . . . . . . . . . . . . . 77
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77
7.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 75 7.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 77
7.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 75 7.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 77
7.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 75 7.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 78
7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses 75 7.2. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 78
7.3. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 75 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 78
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 80
10.1. Normative References . . . . . . . . . . . . . . . . . . 77 10.2. Informative References . . . . . . . . . . . . . . . . . 81
10.2. Informative References . . . . . . . . . . . . . . . . . 78 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 82
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 84
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 8, line 25 skipping to change at page 8, line 21
multicast service or within an application running on a host. 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 |<-------->|UDP/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 3: 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
skipping to change at page 10, line 5 skipping to change at page 10, line 9
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
Figure 4: 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:
skipping to change at page 17, line 21 skipping to change at page 17, line 18
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] | |
: : : :
Figure 6: 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
skipping to change at page 21, line 5 skipping to change at page 21, line 5
a MAC from the message source IP address, source UDP port, a MAC from the message source IP address, source UDP port,
request nonce and a private secret. The relay accepts the request nonce and a private secret. The relay accepts the
Membership Update message if the received MAC matches the Membership Update message if the received MAC matches the
computed MAC, otherwise the message is ignored. If the message computed MAC, otherwise the message is ignored. If the message
is accepted, the relay may proceed to allocate, refresh, or is accepted, the relay may proceed to allocate, refresh, or
modify tunnel state. This includes making any group membership, modify tunnel state. This includes making any group membership,
routing and forwarding state changes and issuing any upstream routing and forwarding state changes and issuing any upstream
protocol requests required to satisfy the state change. The protocol requests required to satisfy the state change. 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 21, line 51 skipping to change at page 21, line 51
port, request nonce and a private secret. The relay accepts the port, request nonce and a private secret. The relay accepts the
Membership Update message if the received MAC matches the Membership Update message if the received MAC matches the
computed MAC, otherwise the message is ignored. If the message computed MAC, otherwise the message is ignored. If the message
is accepted, the relay processes the encapsulated IGMP/MLD and is accepted, the relay processes the encapsulated IGMP/MLD and
allocates, modifies or deletes tunnel state accordingly. This allocates, modifies or deletes tunnel state accordingly. This
includes making any group membership, routing and forwarding includes making any group membership, routing and forwarding
state changes and issuing any upstream protocol requests state changes and issuing any upstream protocol requests
required to satisfy the state change. The diagram illustrates required to satisfy the state change. The diagram 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 31, line 19 skipping to change at page 32, line 9
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 (See Destination UDP Port - The IANA-assigned AMT port number (See
Section 7.3). Section 7.2).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Relay Discovery Message Format Figure 11: Relay Discovery Message Format
skipping to change at page 34, line 33 skipping to change at page 35, line 33
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 0 The relay MUST respond with a Membership Query message that
contains an IPv4 packet carrying an IGMPv3 general query contains an IPv4 packet carrying an IGMPv3 general query
message. message.
1 The relay MUST respond with a Membership Query message that 1 The relay MUST respond with a Membership Query message that
contains an IPv6 packet carrying an MLDv2 general query contains an IPv6 packet carrying an MLDv2 general query
message. 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 45, line 5 skipping to change at page 46, line 33
own implementation of this subset of the IPv4/IGMP and IPv6/MLD own implementation of this subset of the IPv4/IGMP and IPv6/MLD
protocols. The service interface used to manipulate group membership protocols. The service interface used to manipulate group membership
state need not match that described in the IGMP and MLD state need not match that described in the IGMP and MLD
specifications, but the actions taken as a result SHOULD be similar specifications, but the actions taken as a result SHOULD be similar
to those described in Section 5.1 of [RFC3376] and Section 6.1 of to those described in Section 5.1 of [RFC3376] and Section 6.1 of
[RFC3810]. The gateway application will likely need to implement [RFC3810]. The gateway application will likely need to implement
many of the same functions as a host IP stack, including checksum many of the same functions as a host IP stack, including checksum
verification, dispatching, datagram filtering and forwarding, and IP verification, dispatching, datagram filtering and forwarding, and IP
encapsulation/decapsulation. encapsulation/decapsulation.
The IP-encapsulated IGMP messages generated by the gateway IPv4/IGMP The encapsulated IGMP datagrams generated by a gateway MUST conform
implementation MUST conform to the description found in Section 4 of to the descriptions found in Section 4 of [RFC3376]. These datagrams
[RFC3376]. These datagrams MUST possess the IP headers, header MUST possess the IP headers, header options and header values called
options and header values called for in [RFC3376], with the following for in [RFC3376], with the following exception; a gateway MAY use any
exception; the source IP address for an IGMP report datagram MAY be source address value in an IGMP report datagram including the
set to the "unspecified" address (all octets are zero ) but SHOULD be "unspecified" address (all octets are zero ). This exception is made
set to an address in the address range specifically assigned by IANA because a gateway pseudo-interface might not possess a valid IPv4
for use in the IGMP messages sent from a gateway to a relay (i.e. address, and even if an address has been assigned to the interface,
154.7.1.2 through 154.7.1.254 as described in Section 7). This that address might not be a valid link-local source address on any
exception is made because the gateway pseudo-interface might not relay interface. It is for this reason that a relay must accept
possess an assigned address, and even if such an address exists, that encapsulated IGMP reports regardless of the source address they
address would not be a valid link-local source address on any relay carry. See Section 5.3.1.
interface. The rationale for using the aforementioned source
addresses is primarily one of convenience - a relay will accept an
IGMP report carried by a Membership Update message regardless of the
source address it carries. See Section 5.3.1.
The IP-encapsulated MLD messages generated by the gateway IPv6/MLD The encapsulated MLD messages generated by a gateway MUST conform to
implementation MUST conform to the description found in Section 5 of the description found in Section 5 of [RFC3810]. These datagrams
[RFC3810]. These datagrams MUST possess the IP headers, header MUST possess the IP headers, header options and header values called
options and header values called for in [RFC3810], with the following for in [RFC3810], with the following exception; a gateway MAY use any
exception; the source IP address for an MLD report datagram MAY be source address value in an MLD report datagram including the
set to the "unspecified" address (all octets are zero ) but SHOULD be "unspecified" address (all octets are zero ). This exception is made
set to an IPv6 link-local address in the range FE80::/64 excluding because a gateway pseudo-interface might not possess a valid IPv6
FE80::1 and FE80::2. This exception is made because the gateway address, and even if an address has been assigned to the interface,
pseudo-interface might not possess a valid IPv6 address. As with that address might not be a valid link-local source address on any
IGMP, a relay will accept an MLD report carried by a Membership relay interface. As with IGMP, it is for this reason that a relay
Update message regardless of the source address it carries. See must accept encapsulated MLD reports regardless of the source address
Section 5.3.1. they carry. See 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. See last general query forwarded by the pseudo-interface. See
Section 4.1.6 in [RFC3376] and Section 5.1.8 in [RFC3810]. 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
skipping to change at page 50, line 48 skipping to change at page 53, line 5
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 | |
|====================================>| |====================================>|
| | | | | |
: : : : : :
Figure 18: 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.
skipping to change at page 62, line 18 skipping to change at page 64, line 26
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 message. If the P-flag is 1, the relay MUST return an
IPv6-encapsulated MLDv2 general query in the Membership Query IPv6-encapsulated MLDv2 general query in the Membership Query
message. 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 encapsulated IGMPv3 general query datagrams generated by a relay
Membership Query message MUST conform to the descriptions found in MUST conform to the descriptions found in Section 4.1 of [RFC3376].
Section 4.1 of [RFC3376]. These datagrams MUST possess the IP These datagrams MUST possess the IP headers, header options and
headers, header options and header values called for in [RFC3376], header values called for in [RFC3376], with the following exception;
with the following exception; the source IP address for an IGMP a relay MAY use any source IP address for an IGMP general query
general query datagram MAY be set to the "unspecified" address (all datagram including the "unspecified" address (all octets are zero).
octets are zero) but SHOULD be set to an address in the address range This exception is made because any source address that a relay might
specifically assigned by IANA for use in the IGMP messages sent from normally send may not be a valid link-local address on any gateway
a relay to a gateway (i.e. 154.7.1.1 as described in Section 7). interface. It is for this reason that a gateway must accept
This exception is made because the source address that a relay might encapsulated IGMP queries regardless of the source address they
normally send may not be a valid source address on any gateway carry. See Section 5.2.1.
interface. The rationale for using the aforementioned source
addresses is primary one of convenience - a gateway will accept an
IGMP query regardless of the source address it carries. See
Section 5.2.1.
The MLDv2 general query datagram that a relay encapsulates within a The encapsulated MLDv2 general query datagrams generated by a relay
Membership Query message MUST conform to the descriptions found in MUST conform to the descriptions found in Section 5.1 of [RFC3810].
Section 5.1 of [RFC3810]. These datagrams MUST possess the IP These datagrams MUST possess the IP headers, header options and
headers, header options and header values called for in [RFC3810], header values called for in [RFC3810], with the following exception;
with the following exception; the source IP address for an MLD a relay MAY use any source IP address for an MLD general query
general query datagram MAY be set to the "unspecified" address (all datagram including the "unspecified" address (all octets are zero).
octets are zero) but SHOULD be set to an IPv6 link-local address in This exception is made because any source address that a relay might
the range FE80::/64. A relay may use a dynamically-generated link- normally send may not be a valid link-local address on any gateway
local address or the fixed address FE80::2. As with IGMP, a gateway interface. As with IGMP, it is for this reason that a gateway must
will accept an MLD query regardless of the source address it carries. accept encapsulated MLD queries regardless of the source address they
See Section 5.2.1. carry. 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.7 in [RFC3376] and Section 5.1.9 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.
skipping to change at page 75, line 30 skipping to change at page 77, line 30
7. IANA Considerations 7. IANA Considerations
7.1. IPv4 and IPv6 Anycast Prefix Allocation 7.1. IPv4 and IPv6 Anycast Prefix Allocation
The following unicast prefixes have been assigned to provide anycast The following unicast prefixes have been assigned to provide anycast
routing of relay discovery messages to public AMT Relays as described routing of relay discovery messages to public AMT Relays as described
in Section 4.1.4. in Section 4.1.4.
7.1.1. IPv4 7.1.1. IPv4
IANA has assigned 154.7.0/24 for IPv4 relays. We suggest that IANA assign an x.x.x.x/24 from the IPv4 Recovered
Address Space Registry, but any /24 which has been unassigned and
unadvertised for at least twelve months is acceptable. The block
should be registered as follows:
7.1.2. IPv6 +----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block | x.x.x.x./24 |
| Name | AMT |
| RFC | [TBD] |
| Allocation Date | [TBD] |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+----------------+
IANA has assigned 2001:0003::/32 for IPv6 relays. 7.1.2. IPv6
7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses IANA should register the following special-purpose address block for
IPv6 anycast AMT relay discovery.
IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses. +----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block | 2001:0003::/32 |
| Name | AMT |
| RFC | [TBD] |
| Allocation Date | [TBD] |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+----------------+
7.3. UDP Port Number 7.2. UDP Port Number
The UDP port number 2268 has been reserved with IANA for use in the The UDP port number 2268 has been reserved with IANA for use in the
implementation and deployment of AMT. The protocol described by this implementation and deployment of AMT. The protocol described by this
document continues to use this port number according to the intent of document continues to use this port number according to the intent of
the original request. This port number should be assigned to AMT the original request. IANA should assign this port number to AMT
upon acceptance of this I-D. upon acceptance of this I-D.
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:
Amit Aggarwal Amit Aggarwal
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
skipping to change at page 77, line 32 skipping to change at page 80, line 37
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
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[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.
 End of changes. 29 change blocks. 
222 lines changed or deleted 240 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/