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

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