draft-ietf-mboned-auto-multicast-02.txt   draft-ietf-mboned-auto-multicast-03.txt 
MBoneD Working Group Dave Thaler Network Working Group Dave Thaler
Internet Draft Mohit Talwar Internet-Draft Mohit Talwar
Document: draft-ietf-mboned-auto-multicast-02.txt Amit Aggarwal October 2004 Amit Aggarwal
February 9, 2004 Microsoft Expires: April 22, 2005 Microsoft
Lorenzo Vicisano Lorenzo Vicisano
Cisco Cisco
Dirk Ooms Dirk Ooms
Alcatel OneSparrow
IPv4 Automatic Multicast Without Explicit Tunnels (AMT) Automatic IP Multicast Without Explicit Tunnels (AMT)
draft-ietf-mboned-auto-multicast-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC2026. 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
aware will be disclosed, in accordance with Section 6 of RFC 3668.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
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
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
1. 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 (MBone) and does not require any manual infrastructure (MBone) and does not require any manual configuration.
configuration. AMT uses an encapsulation interface so that no AMT uses an encapsulation interface so that no changes to a host
changes to a host stack or applications are required, all protocols stack or applications are required, all protocols (not just UDP) are
(not just UDP) are handled, and there is no additional overhead in handled, and there is no additional overhead in core routers.
core routers.
2. Introduction Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
1. Introduction
The primary goal of this document is to foster the deployment of The primary goal of this document is to foster the deployment of
native IP multicast by enabling a potentially large number of nodes native IP multicast by enabling a potentially large number of nodes
Thaler, et al. Expires May 2004 1
to connect to the already present multicast infrastructure. to connect to the already present multicast infrastructure.
Therefore, the techniques discussed here should be viewed as an Therefore, the techniques discussed here should be viewed as an
interim solution to help in the various stages of the transition to interim solution to help in the various stages of the transition to a
a native multicast network. native multicast network.
To allow fast deployment, the solution presented here only requires To allow fast deployment, the solution presented here only requires
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 protocols introduced in this nodes' operating systems. The protocol introduced in this
specification are implemented in a few strategically-placed network specification is deployed in a few strategically-placed network nodes
nodes and in user-installable software modules (pseudo device and in user-installable software modules (pseudo device drivers
drivers and/or user-mode daemons) that reside underneath the socket and/or user-mode daemons) that reside underneath the socket API of
API of end-nodes' operating systems. This mechanism is very similar end-nodes' operating systems. This mechanism is very similar to that
to that used by "6to4" [6TO4, ANYCAST] to get automatic IPv6 used by "6to4" [6TO4, ANYCAST] to get automatic IPv6 connectivity.
connectivity.
Effectively, AMT treats the unicast-only internetwork as a large Effectively, AMT treats the unicast-only internetwork as a large non-
non-broadcast multi-access (NBMA) link layer, over which we require broadcast multi-access (NBMA) link layer, over which we require the
the ability to multicast. To do this, multicast packets being sent ability to multicast. To do this, multicast packets being sent to or
to or from a site must be encapsulated in unicast packets. If the from a site must be encapsulated in unicast packets. If the group
group has members in multiple sites, AMT encapsulation of the same 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.
The following problems are addressed: The following problems are addressed:
1. Allowing isolated sites/hosts to receive the SSM flavor of 1. Allowing isolated sites/hosts to receive the SSM flavor of
multicast ([SSM]). multicast ([SSM]).
2. Allowing isolated sites/hosts to transmit the SSM flavor of 2. Allowing isolated sites/hosts to transmit the SSM flavor of
multicast. multicast.
3. Allowing isolated sites/hosts to receive general multicast (ISM 3. Allowing isolated sites/hosts to receive general multicast (ISM
[RFC1112]). [RFC1112]).
This document does not address allowing isolated sites/hosts to This document does not address allowing isolated sites/hosts to
transmit general multicast. We expect that other solutions (e.g., transmit general multicast. We expect that other solutions (e.g.,
Tunnel Brokers, a la [BROKER]) will be used for sites that desire Tunnel Brokers, a la [BROKER]) will be used for sites that desire
this capability. this capability.
Thaler, et al. Expires August 2004 2 2. Requirements Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC-2119].
3. Definitions 3. Definitions
+---------------+ Internet +---------------+ +---------------+ Internet +---------------+
| AMT Site | | MBone | | AMT Site | | MBone |
| | AMT | | | | AMT | |
| +------+----+ Relay +----+----+ AMT | | +------+----+ Relay +----+----+ AMT |
| |AMT Gateway| Anycast |AMT Relay| Subnet | | |AMT Gateway| Anycast |AMT Relay| Subnet |
| | +-----+-+ Prefix +-+-----+ | Prefix | | | +-----+-+ Prefix +-+-----+ | Prefix |
| | |AMT IF | <--------|AMT IF | |--------> | | | |AMT IF | <--------|AMT IF | |--------> |
skipping to change at line 114 skipping to change at page 3, line 31
| | +-----+-+ Prefix +-+-----+ | Prefix | | | +-----+-+ Prefix +-+-----+ | Prefix |
| | |AMT IF | <--------|AMT IF | |--------> | | | |AMT IF | <--------|AMT IF | |--------> |
| | +-----+-+ +-+-----+ | | | | +-----+-+ +-+-----+ | |
| +------+----+ +----+----+ | | +------+----+ +----+----+ |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
Figure 1: Automatic Multicast Definitions. Figure 1: Automatic Multicast Definitions.
AMT Pseudo-Interface AMT Pseudo-Interface
AMT encapsulation of multicast packets inside unicast packets AMT encapsulation of multicast packets inside unicast packets
occurs at a point that is logically equivalent to an interface, occurs at a point that is logically equivalent to an interface,
with the link layer being the unicast-only network. This point with the link layer being the unicast-only network. This point is
is referred to as a pseudo-interface. Some implementations may referred to as a pseudo-interface. Some implementations may treat
treat it exactly like any other interface and others may treat it exactly like any other interface and others may treat it like a
it like a tunnel end-point. tunnel end-point.
AMT Gateway AMT Gateway
A host, or a site gateway router, supporting an AMT Pseudo- A host, or a site gateway router, supporting an AMT Pseudo-
Interface. It does not have native multicast connectivity to Interface. It does not have native multicast connectivity to the
the native multicast backbone infrastructure. It is simply native multicast backbone infrastructure. It is simply referred
referred to in this document as a "gateway". to in this document as a "gateway".
AMT Site AMT Site
A multicast-enabled network not connected to the multicast A multicast-enabled network not connected to the multicast
backbone served by an AMT Gateway. It could also be a stand- backbone served by an AMT Gateway. It could also be a stand-
alone AMT Gateway. alone AMT Gateway.
AMT Relay Router AMT Relay Router
A multicast router configured to support transit routing between
AMT Sites and the native multicast backbone infrastructure. The
relay router has one or more interfaces connected to the native
multicast infrastructure, zero or more interfaces connected to the
non-multicast capable internetwork, and an AMT pseudo-interface.
It is simply referred to in this document as a "relay".
A multicast router configured to support transit routing
between AMT Sites and the native multicast backbone
infrastructure. The relay router has one or more interfaces
connected to the native multicast infrastructure, zero or more
interfaces connected to the non-multicast capable internetwork,
and an AMT pseudo-interface. It is simply referred to in this
document as a "relay".
Thaler, et al. Expires August 2004 3
As with [6TO4], we assume that normal multicast routers do not As with [6TO4], we assume that normal multicast routers do not
want to be tunnel endpoints (especially if this results in high want to be tunnel endpoints (especially if this results in high
fanout), and similarly that service providers do not want fanout), and similarly that service providers do not want
encapsulation to arbitrary routers. Instead, we assume that encapsulation to arbitrary routers. Instead, we assume that
special-purpose routers will be deployed that are suitable for special-purpose routers will be deployed that are suitable for
serving as relays. serving as relays.
AMT Relay Anycast Prefix AMT Relay Anycast Prefix
A well-known address prefix used to advertise (into the unicast A well-known address prefix used to advertise (into the unicast
routing infrastructure) a route to an available AMT Relay routing infrastructure) a route to an available AMT Relay Router.
Router. This could also be private (i.e. not well-known) for a This could also be private (i.e., not well-known) for a private
private relay. relay.
The value of this prefix is x.x.x.0/nn [length and value TBD Prefixes for both IPv4 and IPv6 will be assigned in a future
IANA]. version of this draft.
AMT Relay Anycast Address AMT Relay Anycast Address
An anycast address which is used to reach the nearest AMT Relay An anycast address which is used to reach the nearest AMT Relay
Router. Router.
This address corresponds to host number 1 in the AMT Relay This address corresponds to the lowest address in the AMT Relay
Anycast Prefix, x.x.x.1. Anycast Prefix.
AMT Unicast Autonomous System ID AMT Unicast Autonomous System ID
A 16-bit Autonomous System ID, for use in BGP in accordance to A 16-bit Autonomous System ID, for use in BGP in accordance to
this memo. AS 10888 might be usable for this, but for now this memo. AS 10888 might be usable for this, but for now we'll
we'll assume it's different, to avoid confusion. This number assume it's different, to avoid confusion. This number represents
represents a "pseudo-AS" common to all AMT relays using the a "pseudo-AS" common to all AMT relays using the well known AMT
well known AMT Relay Anycast Prefix (private relays use their Relay Anycast Prefix (private relays use their own ID).
own ID).
To protect themselves from erroneous advertisements, managers To protect themselves from erroneous advertisements, managers of
of border routers often use databases to check the relation border routers often use databases to check the relation between
between the advertised network and the last hop in the AS path. the advertised network and the last hop in the AS path.
Associating a specific AS number with the AMT Relay Anycast Associating a specific AS number with the AMT Relay Anycast
Address allows us to enter this relationship in the databases Address allows us to enter this relationship in the databases used
used to check inter-domain routing [ANYCAST]. to check inter-domain routing [ANYCAST].
AMT Subnet Prefix AMT Subnet Prefix
A well-known address prefix used to advertise (into the M-RIB of
the native multicast-enabled infrastructure) a route to AMT Sites.
A well-known address prefix used to advertise (into the M-RIB This prefix will be used to enable sourcing SSM traffic from an
of the native multicast-enabled infrastructure) a route to AMT AMT Gateway.
Sites. This prefix will be used to enable sourcing SSM traffic
from an AMT Gateway.
AMT Gateway Anycast Address AMT Gateway Anycast Address
An anycast address in the AMT Subnet Prefix range, which is used
by an AMT Gateway to enable sourcing SSM traffic from local
applications.
An anycast address in the AMT Subnet Prefix range, which is
used by an AMT Gateway to enable sourcing SSM traffic from
local applications.
Thaler, et al. Expires August 2004 4
AMT Multicast Autonomous System ID AMT Multicast Autonomous System ID
A 16-bit Autonomous system ID, for use in MBGP in accordance to A 16-bit Autonomous system ID, for use in MBGP in accordance to
this memo. This number represents a "pseudo-AS" common to all this memo. This number represents a "pseudo-AS" common to all AMT
AMT relays using the well known AMT Subnet Prefix (private relays using the well known AMT Subnet Prefix (private relays use
relays use their own ID). We assume that the existing AS 10888 their own ID). We assume that the existing AS 10888 is suitable
is suitable for this purpose. (Note: if this is a problem, a for this purpose. (Note: if this is a problem, a different one
different one would be fine.) would be fine.)
4. Overview 4. Overview
4.1. Receiving Multicast in an AMT Site 4.1. Receiving Multicast in an AMT Site
+---------------+ Internet +---------------+ Internet
| AMT Site | | MBone | +---------------+ +---------------+
| | 2. IGMP Report | | | AMT Site | 2. 3-way Membership | MBone |
| | Handshake | |
| 1. Join +---+---+ =================> +---+---+ | | 1. Join +---+---+ =================> +---+---+ |
| +---->|Gateway| | Relay | | | +---->|Gateway| | Relay | |
| | +---+---+ <================= +---+---+ | | | +---+---+ <================= +---+---+ |
| R-+ | 3. Data | | | R-+ | 3. Receive Data | |
+---------------+ +---------------+ +---------------+ +---------------+
Figure 2: Receiving Multicast in an AMT Site. Figure 2: 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.
Each relay has an AMT pseudo-interface too. Multicast traffic sent Each relay has an AMT pseudo-interface too. Multicast traffic sent
on this interface is encapsulated to zero or more gateways that have on this interface is encapsulated to zero or more gateways that have
joined to the relay. The AMT recipient-list is determined for each joined to the relay. The AMT recipient-list is determined for each
multicast session. This requires the relay to keep state for each multicast session. This requires the relay to keep state for each
gateway which has joined a particular group or (source, group) gateway which has joined a particular group or (source, group) pair).
pair). Multicast packets from the native infrastructure behind the Multicast packets from the native infrastructure behind the relay
relay will be sent to each gateway which has requested them. will be sent to each gateway which has requested them.
All multicast packets (data and control) are encapsulated in unicast All multicast packets (data and control) are encapsulated in unicast
packets. To work across NAT's, the encapsulation is done over UDP packets. To work across NAT's, the encapsulation is done over UDP
using a well-known port number [TBD IANA]. using a reserved port number [TBD IANA].
Thaler, et al. Expires August 2004 5 Each relay, plus the set of all gateways using the relay, together
Each relay, plus the set of all gateways (perhaps unknown to the are thought of as being on a separate logical NBMA link. This
relay) using the relay, together can be thought of as being on a implies that the AMT recipient- list is a list of "link layer"
separate logical NBMA link. This implies that the AMT recipient- addresses which are (IP address, UDP port) pairs.
list is a list of "link layer" addresses which are (IP address, UDP
port) pairs.
Since the number of gateways using a relay can be quite large, and Since the number of gateways using a relay can be quite large, and we
we expect that most sites will not want to receive most groups, an expect that most sites will not want to receive most groups, an
explicit-joining protocol is required for gateways to communicate explicit-joining protocol is required for gateways to communicate
group membership information to a relay. The two most likely group membership information to a relay. The two most likely
candidates are the IGMP [IGMPv3] protocol, and the PIM-Sparse Mode candidates are the IGMP/MLD [IGMPv3/MLDv2] protocol, and the PIM-
[PIMSM] protocol. Since an AMT gateway may be a host, and hosts Sparse Mode [PIMSM] protocol. Since an AMT gateway may be a host,
typically do not implement routing protocols, gateways will use IGMP and hosts typically do not implement routing protocols, gateways will
as described in Section 5 below. This allows a host kernel (or a use IGMP/MLD as described in Section 5 below. This allows a host
pseudo device driver) to easily implement AMT gateway behavior, and kernel (or a pseudo device driver) to easily implement AMT gateway
obviates the relay from the need to know whether a given gateway is behavior, and obviates the relay from the need to know whether a
a host or a router. From the relay's perspective, all gateways are given gateway is a host or a router. From the relay's perspective,
indistinguishable from hosts on an NBMA leaf network. all gateways are indistinguishable from hosts on an NBMA leaf
network.
4.1.1. Scalability Considerations 4.1.1. Scalability Considerations
The requirement that a relay keep group state per gateway that has The requirement that a relay keep group state per gateway that has
joined the group introduces potential scalability concerns. joined the group introduces potential scalability concerns.
However, scalability of AMT can be achieved by adding more relays, However, scalability of AMT can be achieved by adding more relays,
and using an appropriate relay discovery mechanism for gateways to and using an appropriate relay discovery mechanism for gateways to
discover relays. The solution we adopt is to assign an anycast discover relays. The solution we adopt is to assign an anycast
address to relays. However, simply sending periodic IGMP Reports to address to relays. However, simply sending periodic membership
the anycast address can cause duplicates. Specifically, if routing reports to the anycast address can cause duplicates. Specifically,
changes such that a different relay receives a periodic IGMP Report, if routing changes such that a different relay receives a periodic
both the new and old relays will encapsulate data to the AMT site membership report, both the new and old relays will encapsulate data
until the old relay's state times out. This is obviously to the AMT site until the old relay's state times out. This is
undesirable. Instead, we use the anycast address merely to find a obviously undesirable. Instead, we use the anycast address merely to
unicast address which can then be used. find the unicast address of a relay to 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
among more relays so as to keep the number of gateways per relay at among more relays so as to keep the number of gateways per relay at a
a reasonable level. reasonable level.
4.1.2 Spoofing Considerations 4.1.2. Spoofing Considerations
An attacker could affect the group state in the relay by spoofing An attacker could affect the group state in the relay or gateway by
the source address in the join or leave reports. This can be used to spoofing the source address in the join or leave reports. This can be
launch reflection or denial of service attacks on the target. Such used to launch reflection or denial of service attacks on the target.
attacks can be mitigated by using a three way handshake between the Such attacks can be mitigated by using a three way handshake between
gateway and the relay for each multicast membership report. On the gateway and the relay for each multicast membership report or
receiving an IGMP report, the relay sends a message to the source of leave.
the report with the original report as well as a nonce. The state in
the relay is updated only on receiving a confirmation for the report
with the nonce in it.
Thaler, et al. Expires August 2004 6 When a gateway or relay wants to send a membership report, it first
sends an AMT Request with a request nonce in it. The receiving side
(the respondent) can calculate a message authentication code (MAC)
based on the source IP address of the Request, the request nonce, and
a secret key known only to the respondent.
An AMT Membership Query is sent back including the request nonce and
the MAC to the originator of the Request. The originator then sends
the IGMP/MLD Membership/Listener Report or Leave/Done along with the
request nonce and the received MAC back to the respondent finalizing
the 3-way handshake.
Upon reception, the respondent can recalculate the MAC based on the
source IP address, the request nonce, and the local secret. The
IGMP/MLD message is only accepted if the received MAC matches the
calculated MAC.
The local secret never has to be shared with the other side. It is
only used to verify return routability of the originator.
4.2. Sourcing Multicast from an AMT site 4.2. Sourcing Multicast from an AMT site
Two cases are discussed below: multicast traffic sourced in an AMT Two cases are discussed below: multicast traffic sourced in an AMT
site and received in the MBone, and multicast traffic sourced in an site and received in the MBone, and multicast traffic sourced in an
AMT site and received in another AMT site. AMT site and received in another AMT site.
In both cases only SSM sources are supported. Furthermore this In both cases only SSM sources are supported. Furthermore this
specification only deals with the source residing directly in the specification only deals with the source residing directly in the
gateway. To enable a generic node in an AMT site to source gateway. To enable a generic node in an AMT site to source
multicast, additional coordination between the gateway and the multicast, additional coordination between the gateway and the
source-node is required. source-node is required.
The general mechanism used to join towards AMT sources is based on The general mechanism used to join towards AMT sources is based on
the following: the following:
1. Applications residing in the gateway use addresses in the AMT 1. Applications residing in the gateway use addresses in the AMT
Subnet Prefix to send multicast, as a result of sourcing traffic on Subnet Prefix to send multicast, as a result of sourcing traffic
the AMT pseudo-interface. on the AMT pseudo-interface.
2. The AMT Subnet Prefix is advertised for RPF reachability in the 2. The AMT Subnet Prefix is advertised for RPF reachability in the M-
M-RIB by relays and gateways. RIB by relays and gateways.
3. Relays or gateways that receive a join for a source/group pair 3. Relays or gateways that receive a join for a source/group pair use
use information encoded in the address pair to rebuild the address information encoded in the address pair to rebuild the address of
of the gateway (source) to which to encapsulate the join (see the gateway (source) to which to encapsulate the join (see Section
section 5 for more details). The membership reports use the same 5 for more details). The membership reports use the same three way
three way handshake as outlined in section 4.1.2. handshake as outlined in Section 4.1.2.
4.2.1. Supporting Site-MBone Multicast 4.2.1. Supporting Site-MBone Multicast
+---------------+ Internet +---------------+ Internet
| AMT Site | | MBone | +---------------+ +---------------+
| | 2. IGMP Report | | | AMT Site | 2. 3-way Membership | MBone |
| | Handshake | |
| +---+---+ <================= +---+---+ 1. Join | | +---+---+ <================= +---+---+ 1. Join |
| |Gateway| | Relay |<-----+ | | |Gateway| | Relay |<-----+ |
| +---+---+ =================> +---+---+ | | | +---+---+ =================> +---+---+ | |
| | 3. Data | +-R | | | 3. Receive Data | +-R |
+---------------+ +---------------+ +---------------+ +---------------+
Figure 3: Site-MBone Multicast. Figure 3: 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 Prefix, then the relay will periodically (using the the AMT Subnet Prefix, then the relay will periodically (using the
rules specified in Section 5) UDP encapsulate an IGMP Report for the rules specified in Section 4.1.2) encapsulate membership updates for
group to the gateway. The gateway must keep state per relay from the group to the gateway. The gateway must keep state per relay from
which an IGMP Report has been sent, and forward multicast traffic which membership reports have been sent, and forward multicast
from the site to all relays from which IGMP Reports have been traffic from the site to all relays from which membership reports
received. The choice of whether this state and replication is done have been received. The choice of whether this state and replication
is done at the link-layer (i.e., by the tunnel interface) or at the
Thaler, et al. Expires August 2004 7 network-layer is implementation dependent.
at the link-layer (i.e., by the tunnel interface) or at the network-
layer is implementation-dependent.
If there are multiple relays present, this ensures that data from If there are multiple relays present, this ensures that data from the
the AMT site is received via the closest relay to the receiver. This AMT site is received via the closest relay to the receiver. This is
is necessary when the routers in the native multicast infrastructure necessary when the routers in the native multicast infrastructure
employ Reverse-Path Forwarding (RPF) checks against the source employ Reverse-Path Forwarding (RPF) checks against the source
address, such as occurs when [PIMSM] is used by the multicast address, such as occurs when [PIMSM] is used by the multicast
infrastructure. infrastructure.
The solution above will scale to an arbitrary number of relays, as The solution above will scale to an arbitrary number of relays, as
long at the number of relays requiring multicast traffic from a long at the number of relays requiring multicast traffic from a given
given AMT site remains reasonable enough to not overly burden the AMT site remains reasonable enough to not overly burden the site's
site's gateway. gateway.
4.2.2. Supporting Site-Site Multicast 4.2.2. Supporting Site-Site Multicast
+---------------+ Internet +---------------+ Internet
| AMT Site | | AMT Site | +---------------+ +---------------+
| | 2. IGMP Report | | | AMT Site | 2. 3-way Membership | AMT Site |
| | Handshake | |
| +---+---+ <================= +---+---+ 1. Join | | +---+---+ <================= +---+---+ 1. Join |
| |Gateway| |Gateway|<-----+ | | |Gateway| |Gateway|<-----+ |
| +---+---+ =================> +---+---+ | | | +---+---+ =================> +---+---+ | |
| | 3. Data | +-R | | | 3. Receive Data | +-R |
+---------------+ +---------------+ +---------------+ +---------------+
Figure 4: Site-Site Multicast. Figure 4: Site-Site Multicast.
Since we require gateways to accept IGMP 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 Prefix, then the gateway source address belongs to the AMT Subnet Prefix, then the gateway
will periodically unicast encapsulate an IGMPv3 [IGMPv3] Report will periodically unicast encapsulate an IGMPv3/MLDv2 [IGMPv3/MLDv2]
directly to the site gateway for the source. Report directly to the site gateway for the source.
We note that this can result in a significant amount of state at a We note that this can result in a significant amount of state at a
site gateway sourcing multicast to a large number of other AMT site gateway sourcing multicast to a large number of other AMT sites.
sites. However, it is expected that this is not unreasonable for However, it is expected that this is not unreasonable for two
two reasons. First, the gateway does not have native multicast reasons. First, the gateway does not have native multicast
connectivity, and as a result is likely doing unicast replication at connectivity, and as a result is likely doing unicast replication at
present. The amount of state is thus the same as what such a site present. The amount of state is thus the same as what such a site
already deals with. Secondly, any site expecting to source traffic already deals with. Secondly, any site expecting to source traffic to
to a large number of sites could get a point-to-point tunnel to the a large number of sites could get a point-to-point tunnel to the
native multicast infrastructure, and use that instead of AMT. native multicast infrastructure, and use that instead of AMT.
Thaler, et al. Expires August 2004 8
5. Message Formats 5. Message Formats
5.1. AMT Relay Discovery 5.1. AMT Relay Discovery
The AMT Relay Discovery message is a UDP packet sent from the AMT The AMT Relay Discovery message is a UDP packet sent from the AMT
gateway unicast address to the AMT relay anycast address to discover gateway unicast address to the AMT relay anycast address to discover
the unicast address of an AMT relay. The payload of the UDP packet the unicast address of an AMT relay.
contains the following fields.
The UDP source port is uniquely selected by the local host operating
system. The UDP destination port is the IANA reserved AMT port
number.
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 | Nonce | | Type=0x1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type Type
The type of the message. The type of the message.
Nonce Reserved
A 24 bit random value generated by the gateway and A 24-bit reserved field. Sent as 0, ignored on receipt.
replayed by the relay.
Discovery Nonce
A 32-bit random value generated by the gateway and replayed by the
relay.
5.2. AMT Relay Advertisement 5.2. AMT Relay Advertisement
The AMT Relay Advertisement message is a UDP packet sent from the The AMT Relay Advertisement message is a UDP packet sent from the AMT
AMT relay anycast address to the source of the discovery message. relay anycast address to the source of the discovery message.
The UDP source port is the IANA reserved AMT port number and the UDP
destination port is the source port received in the Discovery
message.
The payload of the UDP packet contains the following fields. The payload of the UDP packet contains the following fields.
Fields:
Type
The type of the message.
Reserved
A 24-bit reserved field. Sent as 0, ignored on receipt.
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 | Nonce | | Type=0x2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Address | | Relay Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Discovery Nonce
A 32-bit random value replayed from the discovery message.
Relay Address
The unicast IPv4 or IPv6 address of the AMT relay. The family can
be determined by the length of the Advertisement.
5.3. AMT Request
A Request packet is sent to begin a 3-way handshake for sending an
IGMP/MLD Membership/Listener Report or Leave/Done. It can be sent
from a gateway to a relay, from a gateway to another gateway, or from
a relay to a gateway.
It is sent from the originator's unique unicast address to the
respondents' unique unicast address.
The UDP source port is uniquely selected by the local host operating
system. It can be different for each Request and different from the
source port used in Discovery messages but does not have to be. The
UDP destination port is the IANA reserved AMT port number.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type Type
The type of the message. The type of the message.
Nonce Reserved
A 24 bit random value replayed from the discovery A 24-bit reserved field. Sent as 0, ignored on receipt.
message.
Relay Address Request Nonce
The unicast IP address of the AMT relay. A 32-bit identifier used to distinguish this request.
Thaler, et al. Expires August 2004 9 5.4. AMT Membership Query
5.3. Membership Report Confirmation An AMT Membership Query packet is sent from the relay back to the
originator to solicit an AMT Membership Update while confirming the
source of the original request. It contains a relay Message
Authentication Code (MAC) that is a non-cryptographic hash of a
private secret, the originators address, and the request nonce.
The membership report confirmation is a UDP packet sent by the It is sent from the destination address received in the Request to
gateway or relay to the source of a multicast membership report. the source address received in the Request.
The UDP source port is the IANA reserved AMT port number and the UDP
destination port is the source port received in the Request message.
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 | Nonce | | Type=0x4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Report | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type Type
The type of the message. The type of the message.
Nonce Reserved
A 24 bit random value generated by the relay or gateway A 24-bit reserved field. Sent as 0, ignored on receipt.
on receiving a multicast report.
Multicast Report Request Nonce
The complete multicast report that the relay or gateway A 32-bit identifier used to distinguish this request echoed back
is trying to confirm. to the originator.
5.4. Membership Report Acknowledgement Response MAC
A 32-bit hash generated by the respondent and sent to the
originator for inclusion in the AMT Membership Update. This MUST
be calculated as HMAC-MD5-32 [HMAC].
The membership report acknowledgement is a UDP packet sent by the 5.5. AMT Membership Update
source of a membership report to a gateway or relay/
An AMT Membership Update is sent from the originator to the
respondent containing the original IGMP/MLD Membership/Listener
Report or Leave/Done received over the AMT pseudo-interface. It
echoes the Response MAC received in the AMT Membership Query so the
respondent can verify return routability to the originator.
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
the original Request.
The UDP source and destination port numbers should be the same ones
sent in the original Request.
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 | Nonce | | Type=0x5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Report | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGMP/MLD Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type Type
The type of the message. The type of the message.
Nonce Reserved
A 24 bit random value replayed from the confirmation A 24-bit reserved field. Sent as 0, ignored on receipt.
message.
Multicast Report Request Nonce
The complete multicast report that the relay or gateway A 32-bit identifier used to distinguish this request.
is trying to confirm.
Thaler, et al. Expires August 2004 10 Response MAC
The MAC received from the relay and echoed back in the AMT
Membership Update.
5.6. AMT UDP Data
The AMT UDP Data message is a UDP packet encapsulating the data
requested by the originator based on a previous AMT Membership Update
message. Currently, it is only defined for original UDP multicast
data packets. This prevents the tunnel from being used as an
arbitrary tunnel mechanism and greatly reduces the possibility of
exploitation.
It is sent from the unicast destination address of the Membership
update to the source address of the Membership Update.
The UDP source and destination port numbers should be the same ones
sent in the original Query.
The payload of the UDP packet contains the following fields.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x6 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Multicast Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type
The type of the message.
Reserved
A 24-bit reserved field. Sent as 0, ignored on receipt.
UDP Multicast Data
The original Multicast UDP data packet that is being replicated by
the relay to the gateways.
6. AMT Gateway Details 6. 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 router serving an AMT site, or the site may consist of a single host,
host, serving as its own gateway. serving as its own gateway.
6.1. At Startup Time 6.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 will then send
a AMT Relay Discovery message to the AMT Relay Anycast Address, and a AMT Relay Discovery message to the AMT Relay Anycast Address, and
note the unicast address (which is treated as a link-layer address note the unicast address (which is treated as a link-layer address to
to the encapsulation interface) from the AMT Relay Advertisement the encapsulation interface) from the AMT Relay Advertisement
message. This discovery should be done periodically (e.g., once a message. This discovery should be done periodically (e.g., once a
day) to re-resolve the unicast address of a close relay. The day) to re-resolve the unicast address of a close relay. The gateway
gateway also initializes a timer used to send periodic IGMP Reports also initializes a timer used to send periodic membership reports to
to a random value from the interval [0, [Query Interval]] before a random value from the interval [0, [Query Interval]] before sending
sending the first periodic report, in order to prevent startup the first periodic report, in order to prevent startup
synchronization (e.g., after a power outage). synchronization (e.g., after a power outage).
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 Proxy, as described in [IGMPPROXY], with its IGMP host- as an IGMP/MLD Proxy, as described in [PROXY], with its IGMP/MLD
mode interface being the AMT pseudo-interface. This enables it to host-mode interface being the AMT pseudo-interface. This enables it
translate group memberships on its downstream interfaces into IGMP to translate group memberships on its downstream interfaces into
Reports. The gateway MUST also advertise itself as the default IGMP/MLD Reports. The gateway MUST also advertise itself as the
route for multicast in the M-RIB (or it must be the default unicast default route for multicast in the M-RIB (or it must be the default
router if unicast and multicast topologies are congruent). Also, if unicast router if unicast and multicast topologies are congruent).
a shared tree routing protocol is used inside the AMT site, each Also, if a shared tree routing protocol is used inside the AMT site,
tree-root must be a gateway, e.g., in PIM-SM each RP must be a each tree-root must be a gateway, e.g., in PIM-SM each RP must be a
gateway. gateway.
Finally, to support sourcing traffic to SSM groups by a gateway with Finally, to support sourcing traffic to SSM groups by a gateway with
a global unicast address, the AMT Subnet Prefix is treated as the a global unicast address, the AMT Subnet Prefix is treated as the
subnet prefix of the AMT pseudo-interface, and an anycast address is subnet prefix of the AMT pseudo-interface, and an anycast address is
added on the interface. This anycast address is formed by added on the interface. This anycast address is formed by
concatenating the AMT Subnet Prefix followed by the high bits of the concatenating the AMT Subnet Prefix followed by the high bits of the
gateway's global unicast address. For example, if IANA assigns the gateway's global unicast address. For example, if IANA assigns the
prefix x.y/16 as the AMT Subnet Prefix, and the gateway has global IPv4 prefix x.y/16 as the AMT Subnet Prefix, and the gateway has
unicast address a.b.c.d, then the AMT Gateway's Anycast Address will global unicast address a.b.c.d, then the AMT Gateway's Anycast
be x.y.a.b. Note that multiple gateways might end up with the same Address will be x.y.a.b. Note that multiple gateways might end up
address anycast assigned to their pseudo-interfaces. with the same anycast address assigned to their pseudo-interfaces.
6.2. Joining Groups with MBone Sources 6.2. Joining Groups with MBone Sources
The IGMP protocol usually operates by having the Querier multicast The IGMP/MLD protocol usually operates by having the Querier
an IGMP Query message on the link. This behavior does not work on multicast an IGMP/MLD Query message on the link. This behavior does
NBMA links which do not support multicast. Since the set of not work on NBMA links which do not support multicast. Since the set
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
behavior is used instead. behavior is used instead.
Thaler, et al. Expires August 2004 11
Applications residing in a gateway should join groups on the AMT Applications residing in a gateway should join groups on the AMT
pseudo-interface, causing IGMP Membership Reports to be sent over pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be
that interface. When UDP encapsulating the IGMP Reports (and in sent over that interface. When UDP encapsulating the membership
fact any other messages, unless specified otherwise in this reports (and in fact any other messages, unless specified otherwise
document), the destination address in the outer IP header is the in this document), the destination address in the outer IP header is
relay's unicast address. To provide robustness, gateways unicast the relay's unicast address. Robustness is provided by the
IGMP Reports to the relay every [Query Interval] (defined as 125 in underlying IGMP/MLD protocol messages sent on the AMT pseudo-
[IGMPv3]) seconds. The gateway also needs to respond to Membershsip interface. In other words, the gateway does not need to retransmit
Confirmation messages sent by the relay with a Membership IGMP/MLD Membership/Listener Reports and Leave/Done messages received
Acknowledgement message. on the pseudo-interface since IGMP/MLD will already do this. The
gateway simply needs to encapsulate each IGMP/MLD Membership/Listener
Report and Leave/Done message it receives.
Generating periodic reports can be done in any implementation- However, since periodic IGMP/MLD Membership/Listener Reports are sent
specific manner. Some possibilities include: in response to IGMP/MLD Queries, some mechanism to trigger periodic
Membership/Listener Reports and Leave/Done messages are necessary.
This can be achieved in any implementation-specific manner. Some
possibilities include:
1. The AMT pseudo-interface might periodically manufacture IGMPv3 1. The AMT pseudo-interface might periodically manufacture
Queries as if they had been received from an IGMP Querier, and IGMPv3/MLDv2 Queries as if they had been received from an IGMP/MLD
deliver them to the IP layer, after which normal IGMP behavior will Querier, and deliver them to the IP layer, after which normal
cause the appropriate reports to be sent. IGMP/MLD behavior will cause the appropriate reports to be sent.
2. The IGMP module itself might provide an option to operate in 2. The IGMP/MLD module itself might provide an option to operate in
periodic mode on specific interfaces. periodic mode on specific interfaces.
6.3. Responding to Relay Changes 6.3. 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 a ICMP Unreachable message for the relay's (e.g., upon receipt of a ICMP Unreachable message [ICMP] for the
unicast address), it immediately repeats the unicast address relay's unicast address), it may need to repeat relay address
resolution step by sending a UDP encapsulated ICMP Echo Request to discovery. However, care should be taken not to abandon the current
the AMT Relay Anycast Address, and storing the source address of the relay too quickly due to transient network conditions. Some
UDP encapsulated ICMP Echo Response as the new unicast address to implementations may find it difficult to send a discovery packet to
use as a "link-layer" destination. the anycast relay address while the gateway has an address configured
on the AMT pseudo-interface on the same anycast prefix. Therefore, it
may be necessary to tear down the AMT pseudo-interface to rediscover
a new relay.
6.4. Creating SSM groups 6.4. Creating SSM groups
When a gateway wants to create an SSM group (i.e., in 232/8) for When a gateway wants to create an SSM group (i.e., in 232/8) for
which it can source traffic, the remaining 24 bits MUST be generated which it can source traffic, the remaining 24 bits MUST be generated
as described below. ([SSM] states that "the policy for allocating as described below. ([SSM] states that "the policy for allocating
these bits is strictly locally determined at the sender's host.") these bits is strictly locally determined at the sender's host.")
When the gateway determined its AMT Gateway Anycast Address as When the gateway determined its AMT Gateway Anycast Address as
described above, it used the high bits of its global unicast described above, it used the high bits of its global unicast address.
address. The remaining bits of its global unicast address are The remaining bits of its global unicast address are appended to the
appended to the 232/8 prefix, and any spare bits may be allocated 232/8 prefix, and any spare bits may be allocated using any policy
using any policy (again, strictly locally determined at the sender's (again, strictly locally determined at the sender's host).
host).
For example, if the AMT Subnet Prefix is x.y/16, and the device has
global unicast address a.b.c.d, then it MUST allocate SSM groups in
the range 232.c.d/24.
Thaler, et al. Expires August 2004 12 For example, if the IPv4 AMT Subnet Prefix is x.y/16, and the device
has global unicast address a.b.c.d, then it MUST allocate IPv4 SSM
groups in the range 232.c.d/24.
6.5. Joining SSM Groups with AMT Sources 6.5. Joining SSM Groups with AMT Sources
An IGMPv3 Report for a given (source, group) pair MAY be An IGMPv3/MLDv2 Report for a given (source, group) pair MAY be
encapsulated directly to the source, when the source address belongs encapsulated directly to the source, when the source address belongs
to the AMT Subnet Prefix. to the AMT Subnet Prefix.
The "link-layer" address to use as the destination address in the The "link-layer" address to use as the destination address in the
outer IP header is obtained as follows. The source address in the outer IP header is obtained as follows. The source address in the
inclusion list of the IGMPv3 report will be an AMT Gateway Anycast inclusion list of the IGMPv3/MLDv2 report will be an AMT Gateway
Address with the high bits of the address, and the remaining bits Anycast Address with the high bits of the address, and the remaining
will be in the middle of the group address. bits will be in the middle of the group address.
For example, if the AMT Subnet Prefix is x.y/16, and the IGMPv3 For example, if the IPv4 AMT Subnet Prefix is x.y/16, and the IGMPv3
Report is for (x.y.a.b, 232.c.d.e), then the "link layer" Report is for (x.y.a.b, 232.c.d.e), then the "link layer" IPv4
destination address used for encapsulation is a.b.c.d. destination address used for encapsulation is a.b.c.d.
6.6. Receiving IGMPv3 Reports on the AMT Interface 6.6. Receiving IGMPv3/MLDv2 Reports at the Gateway
When an IGMPv3 report is received on the AMT pseudo-interface, and When an AMT Request is received by the gateway, it follows the same
the report is a request to join a given (S, G) pair, then the 3-way handshake procedure a relay would follow if it received the AMT
following actions are taken. Request. It generates a MAC and responds with an AMT Membership
Query. When the AMT Membership Update is received, it verifies the
MAC and then processes the IGMP/MLD Membership/Listener Report or
Leave/Done.
If S is not the AMT Gateway Anycast Address of the gateway, the At the gateway, the IGMP/MLD packet should be an IGMPv3/MLDv2 source
packet is dropped. If G does not contain the low bits of the global specific (S,G) join or leave.
unicast address (as described above), the packet is also dropped.
Otherwise, the gateway sends a Membership Confirmation message to If S is not the AMT Gateway Anycast Address, the packet is dropped.
the source of the IGMPv3 report. The message contains a random If G does not contain the low bits of the global unicast address (as
nonce. On receiving a Membership Acknowledgement message, the described above), the packet is also dropped.
gateway verifies that the nonce in the acknowledgement is the same
as the one in the confirmation message. If the two differ, the The gateway adds the source address (from the outer IP header) and
message is dropped without any change to the gateway state. If the UDP port of the report to a membership list for G. Maintaining this
two nonces are the same, the gateway adds the source address (from membership list may be done in any implementation-dependent manner.
the outer IP header) and UDP port of the report to a membership list For example, it might be maintained by the "link-layer" inside the
for G. Maintaining this membership list may be done in any AMT pseudo-interface, making it invisible to the normal IGMP/MLD
implementation-dependent manner. For example, it might be module.
maintained by the "link-layer" inside the AMT pseudo-interface,
making it invisible to the normal IGMP module.
6.7. Sending data to SSM groups 6.7. Sending data to SSM groups
When multicast packets are sent on the AMT pseudo-interface, they When multicast packets are sent on the AMT pseudo-interface, they are
are encapsulated as follows. If the group address is not an SSM encapsulated as follows. If the group address is not an SSM group,
group, then the packet is dropped (this memo does not currently then the packet is dropped (this memo does not currently provide a
provide a way to send to non-SSM groups). way to send to non-SSM groups).
If the group address is an SSM group, then the packet is unicast If the group address is an SSM group, then the packet is unicast
encapsulated to each remote node from which the gateway has received encapsulated to each remote node from which the gateway has received
an IGMPv3 report for the packet's (source, group) pair. an IGMPv3/MLDv2 report for the packet's (source, group) pair.
Thaler, et al. Expires August 2004 13
7. Relay Router Details 7. Relay Router Details
7.1. At startup time 7.1. At Startup time
At startup time, the relay router will bring up an NBMA-style AMT At startup time, the relay router will bring up an NBMA-style AMT
pseudo-interface. It shall also add the AMT Relay Anycast Address pseudo-interface. It shall also add the AMT Relay Anycast Address on
on some interface. some interface.
The relay router shall then advertise the AMT Relay Anycast Prefix The relay router shall then advertise the AMT Relay Anycast Prefix
into the unicast-only Internet, as if it were a connection to an into the unicast-only Internet, as if it were a connection to an
external network. When the advertisement is done using BGP, the AS external network. When the advertisement is done using BGP, the AS
path leading to the AMT Relay Anycast Prefix shall include the path leading to the AMT Relay Anycast Prefix shall include the
identifier of the local AS and the AMT Unicast Autonomous System ID. identifier of the local AS and the AMT Unicast Autonomous System ID.
The relay router shall also enable IGMPv3 on the AMT pseudo- The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo-
interface, except that it shall not multicast Queries (this might be interface, except that it shall not multicast Queries (this might be
done, for example, by having the AMT pseudo-device drop them, or by done, for example, by having the AMT pseudo-device drop them, or by
having the IGMP module not send them in the first place). having the IGMP/MLD module not send them in the first place).
Finally, to support sourcing SSM traffic from AMT sites, the AMT Finally, to support sourcing SSM traffic from AMT sites, the AMT
Subnet Prefix is assigned to the AMT pseudo-interface, and the AMT Subnet Prefix is assigned to the AMT pseudo-interface, and the AMT
Subnet Prefix is injected into the M-RIB of MBGP. Subnet Prefix is injected into the M-RIB of MBGP.
7.2. Receiving Echo Requests to the Anycast Address 7.2. Receiving Relay Discovery messages sent to the Anycast Address
When a relay receives a AMT Relay Discovery message directed to the When a relay receives a AMT Relay Discovery message directed to the
AMT Relay Anycast Address, it should respond with a AMT Relay AMT Relay Anycast Address, it should respond with a AMT Relay
Advertisement containing its unicast address. The source and Advertisement containing its unicast address. The source and
destination addresses of the advertisement should be the same as the destination addresses of the advertisement should be the same as the
destination and source addresses of the discovery message destination and source addresses of the discovery message
respectively. Further, the nonce in the discovery message MUST be respectively. Further, the nonce in the discovery message MUST be
copied into the advertisement message. copied into the advertisement message.
7.3. Receiving Joins from AMT Gateways 7.3. Receiving Membership Updates from AMT Gateways
The relay operates passively, sending no Queries but simply tracking The relay operates passively, sending no Queries but simply tracking
membership information according to Reports and Leave messages, as a membership information according to Reports and Leave messages, as a
router normally would. In addition, the relay must also do explicit router normally would. In addition, the relay must also do explicit
membership tracking, as to which gateways on the AMT pseudo- membership tracking, as to which gateways on the AMT pseudo-
interface have joined which groups. On receiving a membership interface have joined which groups. Once an AMT Membership Update has
report, the gateway generates a Membership Confirmation message with been successfully received, it updates the forwarding state for the
a random nonce in it. On receiving a Membership Acknowledgement, it appropriate group and source (if provided). When data arrives for
updates the group state if the nonce in the reply matches the one in that group, the traffic must be encapsulated to each gateway which
the confirmation message. When data arrives for that group, the has joined that group.
traffic must be encapsulated to each gateway which has joined that
group.
Thaler, et al. Expires August 2004 14
The explicit membership tracking and unicast replication may be done The explicit membership tracking and unicast replication may be done
in any implementation-specific manner. Some examples are: in any implementation-specific manner. Some examples are:
1. The AMT pseudo-device driver might track the group information 1. The AMT pseudo-device driver might track the group information and
and perform the replication at the "link-layer", with no changes to perform the replication at the "link-layer", with no changes to a
a pre-existing IGMP module. pre-existing IGMP/MLD module.
2. The IGMP module might have native support for explicit membership 2. The IGMP/MLD module might have native support for explicit
tracking, especially if it supports other NBMA-style interfaces. membership tracking, especially if it supports other NBMA-style
interfaces.
7.4. Receiving (S,G) Joins from the Native Side, for AMT 7.4. Receiving (S,G) Joins from the Native Side, for AMT Sources
Sources
The relay encapsulates an IGMPv3 report to the AMT source as The relay encapsulates an IGMPv3/MLDv2 report to the AMT source as
described above in Section 5.5. described above in Section 4.1.2.
8. IANA Considerations 8. IANA Considerations
The IANA should allocate a prefix dedicated to the public AMT Relays The IANA should allocate a prefix dedicated to the public AMT Relays
to the native multicast backbone. The prefix length should be to the native multicast backbone. The prefix length should be
determined by the IANA; the prefix should be large enough to determined by the IANA; the prefix should be large enough to
guarantee advertisement in the default- free BGP networks; a length guarantee advertisement in the default- free BGP networks; a length
of 16 will meet this requirement. This is a one time effort; there of 16 will meet this requirement. This is a one time effort; there
is no need for any recurring assignment after this stage. is no need for any recurring assignment after this stage.
The IANA should also allocate an Autonomous System ID which can be The IANA should also allocate an Autonomous System ID which can be
used as a pseudo-AS when advertising routes to the above prefix. used as a pseudo-AS when advertising routes to the above prefix.
Furthermore, to support sourcing SSM traffic from AMT gateways, the Furthermore, to support sourcing SSM traffic from AMT gateways, the
IANA should allocate a subnet prefix dedicated to the AMT link. The IANA should allocate a subnet prefix dedicated to the AMT link. The
prefix length should be determined by the IANA; the prefix should be prefix length should be determined by the IANA; the prefix should be
large enough to guarantee advertisement in the default- free BGP large enough to guarantee advertisement in the default- free BGP
networks; a length of 16 will meet this requirement. This is a one networks; a length of 16 will meet this requirement. This is a one
time effort; there is no need for any recurring assignment after time effort; there is no need for any recurring assignment after this
this stage. It should also be noted that this prefix length stage. It should also be noted that this prefix length directly
directly affects the number of groups available to be created by the affects the number of groups available to be created by the AMT
AMT gateway: a length of 16 gives 256 groups, and a length of 8 gateway: a length of 16 gives 256 groups, and a length of 8 gives
gives 65536 groups. For diagnostic purposes, it is helpful to have 65536 groups. For diagnostic purposes, it is helpful to have a
a prefix length which is a multiple of 8, although this is not prefix length which is a multiple of 8, although this is not
required. required.
An autonomous system number dedicated to a pseudo-AS for multicast An autonomous system number dedicated to a pseudo-AS for multicast is
is already in use today (AS 10888), and so it is expected that no already in use today (AS 10888), and so it is expected that no
additional AS number is required for this prefix. additional AS number is required for this prefix.
Finally, IANA should reserve a well-known UDP port number for AMT Finally, IANA should allocate a reserved UDP port number for AMT
encapsulation. encapsulation.
9. Security Considerations 9. Security Considerations
Thaler, et al. Expires August 2004 15
The anycast technique introduces a risk that a rogue router or a The anycast technique introduces a risk that a rogue router or a
rogue AS could introduce a bogus route to the AMT Relay Anycast rogue AS could introduce a bogus route to the AMT Relay Anycast
Prefix, and thus divert the traffic. Network managers have to Prefix, and thus divert the traffic. Network managers have to
guarantee the integrity of their routing to the AMT Relay anycast guarantee the integrity of their routing to the AMT Relay anycast
prefix in much the same way that they guarantee the integrity of all prefix in much the same way that they guarantee the integrity of all
other routes. other routes.
Within the native MBGP infrastructure, there is a risk that a rogue Within the native MBGP infrastructure, there is a risk that a rogue
router or a rogue AS could introduce a bogus route to the AMT Subnet router or a rogue AS could introduce a bogus route to the AMT Subnet
Prefix, and thus divert joins and cause RPF failures of multicast Prefix, and thus divert joins and cause RPF failures of multicast
traffic. Again, network managers have to guarantee the integrity of traffic. Again, network managers have to guarantee the integrity of
the MBGP routing to the AMT subnet prefix in much the same way that the MBGP routing to the AMT subnet prefix in much the same way that
they guarantee the integrity of all other routes in the M-RIB. they guarantee the integrity of all other routes in the M-RIB.
Gateways and relays will accept and decapsulate multicast traffic Gateways and relays will accept and decapsulate multicast traffic
from any source from which regular unicast traffic is accepted. If from any source from which regular unicast traffic is accepted. If
this is for any reason felt to be a security risk, then additional this is for any reason felt to be a security risk, then additional
source address based packet filtering MUST be applied: source address based packet filtering MUST be applied:
1. To avoid that a rogue sender (that can't do traditional spoofing 1. To prevent a rogue sender (that can't do traditional spoofing
because of e.g. access lists deployed by its ISP) makes use of AMT because of e.g. access lists deployed by its ISP) from making use
to send packets to an SSM tree, a relay that receives an of AMT to send packets to an SSM tree, a relay that receives an
encapsulated multicast packet MUST discard the multicast packet if encapsulated multicast packet MUST discard the multicast packet if
the IPv4 source address in the outer header is not composed of the the IPv4 source address in the outer header is not composed of the
last 2 bytes of the source address and the 2 middle bytes of the last 2 bytes of the source address and the 2 middle bytes of the
destination address of the inner header (i.e. a.b.c.d must be destination address of the inner header (i.e., a.b.c.d must be
composed of the a.b of x.y.a.b and the c.d of 232.c.d.e). composed of the a.b of x.y.a.b and the c.d of 232.c.d.e).
2. A gateway MUST discard encapsulated multicast packets if the 2. A gateway MUST discard encapsulated multicast packets if the
source address in the outer header is not the address to which the source address in the outer header is not the address to which the
encapsulated join message was sent. An AMT Gateway that receives an encapsulated join message was sent. An AMT Gateway that receives
encapsulated IGMPv3 (S,G)-Join MUST discard the message if the IPv4 an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the message
destination address in the outer header is not composed of the last if the IPv4 destination address in the outer header is not
2 bytes of S and the 2 middle bytes of G (i.e. the destination composed of the last 2 bytes of S and the 2 middle bytes of G
address a.b.c.d must be composed of the a.b of the multicast source (i.e. the destination address a.b.c.d must be composed of the a.b
x.y.a.b and the c.d of the multicast group 232.c.d.e). of the multicast source x.y.a.b and the c.d of the multicast group
232.c.d.e).
3. A gateway MUST drop an AMT Relay Advertisement if the nonce in
the advertisement does not match the nonce in the discovery packet
sent by the gateway. This prevents an attacker from acting as an AMT
anycast relay even without publishing a route to the AMT Anycast
Subnet Prefix.
4. A gateway or relay MUST not update its group state on receiving a
membership report. Instead, it MUST generate a Membership
Confirmation message to the source of the report. On receiving a
Membership Acknowledgement, the group state should be updated only
if the nonce in the acknowledgement matches the one in the
confirmation message. This prevents an attacker from spoofing the
source address of a membership report and causing a denial of
service or reflection attack on the target.
Thaler, et al. Expires August 2004 16
10. Acknowledgements 10. Acknowledgments
Most of the mechanisms described in this document are based on Most of the mechanisms described in this document are based on
similar work done by the NGTrans WG for obtaining automatic IPv6 similar work done by the NGTrans WG for obtaining automatic IPv6
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. Tom
Pusateri helped flush out protocol details based on implementation
experience and provided updates to this draft.
11. Appendix A: Open Issues 11. Normative References
Under the proposed mechanism, a gateway sends its IGMPv3 Reports for [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-
MBone sources to the relay closest to itself (discovered using the Hashing for Message Authentication", RFC 2104, February
UDP encapsulated "ping"). This ensures that, as far as possible, 1997.
multicast traffic flows through the native multicast infrastructure
and the automatic multicast encapsulation is short.
However, there might be reasons to create automatic tunnels to the [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792,
relay closest to the MBone source instead. An ISP, for example, September 1981.
might be willing to provide a relay for only its own customers,
those wishing to multicast their transmission to a much wider
audience. A mechanism, complementary to the one described in this
document, might be used to provide this facility. It uses UDP
encapsulated ICMP Redirect messages as described below.
While injecting routes for its sources into the M-RIB, such an ISP [PROXY] Fenner, W., He, H., Haberman, B., Sandick, H., "IGMP/MLD-
might, for example, use a new BGP attribute to convey the address of based Multicast Forwarding ("IGMP/MLD Proxying")", Work
the preferred relay. This would let other relays redirect any IGMP in progress, draft-ietf-magma-igmp-proxy-06.txt, April
Reports to the preferred relay by sending a UDP encapsulated ICMP 2004.
Redirect.
An IGMP Report sent by a gateway to the relay closest to it would [IGMPv3] Cain, B., Deering, S., Fenner, B., Kouvelas, I.,
consist of the following packet: Thyagarajan A., "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
OuterIP [UDP [InnerIP [IGMP Report]]] [MLDv2] Vida, R., Costa, L., "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
The relay would respond with: [SSM] Holbrook, H., Cain, B., "Source-Specific Multicast for
IP", Work in Progress, draft-ietf-ssm-arch-06.txt,
September 2004.
OuterIP' [UDP' [InnerIP' [ICMP Redirect [InnerIP [IGMP Report]]]]] 12. Informative References
An ICMP Redirect contains the first 64 bits of the original packet [Brad88] Braden, R., Borman, D., Partridge, C., "Computing the
[ICMP]. Hence the gateway would get 44 bytes (64 - sizeof(Inner Internet Checksum", RFC 1071, September 1988.
IP)) of the IGMP Report, enough to easily extract the (source,
group) pair, and redirect its report to the preferred gateway.
Certainly additional complexity is undesirable, so it is an open [6TO4] Carpenter, B., Moore, K., "Connection of IPv6 Domains via
issue as to whether redirects are needed at all. IPv4 Clouds", RFC 3056, February 2001.
12. Authors' Addresses [BROKER] Durand, A., Fasano, P., Guardini, I., Lento, D., "IPv6
Tunnel Broker", RFC 3053, January 2001.
Dave Thaler [ANYCAST] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
Thaler, et al. Expires August 2004 17 [PIMSM] Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., Wei,
L., "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, June 1998.
13. Author's Address
Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
Phone: +1 425 703 8835 Phone: +1 425 703 8835
EMail: dthaler@microsoft.com EMail: dthaler@microsoft.com
Mohit Talwar Mohit Talwar
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
skipping to change at line 887 skipping to change at page 23, line 4
Redmond, WA 98052-6399 Redmond, WA 98052-6399
Phone: +1 425 705 3131 Phone: +1 425 705 3131
EMail: mohitt@microsoft.com EMail: mohitt@microsoft.com
Amit Aggarwal Amit Aggarwal
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
Phone: +1 425 706 0593 Phone: +1 425 706 0593
EMail: amitag@microsoft.com EMail: amitag@microsoft.com
Lorenzo Vicisano Lorenzo Vicisano
Cisco Systems Cisco Systems
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
Phone: +1 408 525 2530 Phone: +1 408 525 2530
EMail: lorenzo@cisco.com EMail: lorenzo@cisco.com
Dirk Ooms Dirk Ooms
Alcatel OneSparrow
F. Wellesplein 1, 2018 Antwerp, Belgium Belegstraat 13; 2018 Antwerp; Belgium
Phone: +32 3 2404732 EMail: dirk@onesparrow.com
EMail: dirk.ooms@alcatel.be
13. Normative References
[ICMP] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981.
[IGMPPROXY] W. Fenner, "IGMP-based Multicast Forwarding (``IGMP
Proxying'')", Work in progress, draft-fenner-igmp-proxy-
03.txt, July 2000.
[IGMPv3] Cain, B., Deering, S., Fenner, B., Kouvelas, I., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
Thaler, et al. Expires August 2004 18
[SSM] Holbrook, H., and B. Cain, "Source-Specific Multicast for IP",
Work in progress, draft-holbrook-ssm-arch-04.txt, October
2003.
14. Informative References
[6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains via 14. Intellectual Property Rights Notice
IPv4 Clouds", RFC 3056, February 2001.
[BROKER] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 The IETF takes no position regarding the validity or scope of any
Tunnel Broker", RFC 3053, January 2001. Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
[ANYCAST] C. Huitema, "An Anycast Prefix for 6to4 Relay Routers", Copies of IPR disclosures made to the IETF Secretariat and any
RFC 3068, June 2001. assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
[PIMSM] Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering, The IETF invites any interested party to bring to its attention any
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. copyrights, patents or patent applications, or other proprietary
Wei. "Protocol Independent Multicast-Sparse Mode (PIM-SM): rights that may cover technology that may be required to implement
Protocol Specification", RFC 2362, June 1998. this standard. Please address the information to the IETF at ietf-
ipr@ietf.org."
15. Full Copyright Statement 15. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
This document and translations of it may be copied and furnished to except as set forth therein, the authors retain all their rights.
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be 16. Disclaimer
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Table of Contents
Thaler, et al. Expires August 2004 19 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . . 5
4.2. Sourcing Multicast from an AMT site . . . . . . . . . . . . 7
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . . 9
5.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . . 10
5.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . . 12
5.5. AMT Membership Update . . . . . . . . . . . . . . . . . . . 13
5.6. AMT UDP Data . . . . . . . . . . . . . . . . . . . . . . . . 14
6. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 14
6.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Joining Groups with MBone Sources . . . . . . . . . . . . . 15
6.3. Responding to Relay Changes . . . . . . . . . . . . . . . . 16
6.4. Creating SSM groups . . . . . . . . . . . . . . . . . . . . 16
6.5. Joining SSM Groups with AMT Sources . . . . . . . . . . . . 17
6.6. Receiving IGMPv3/MLDv2 Reports at the Gateway . . . . . . . 17
6.7. Sending data to SSM groups . . . . . . . . . . . . . . . . . 18
7. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 18
7.1. At Startup time . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Receiving Relay Discovery messages sent to the Anycast
Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3. Receiving Membership Updates from AMT Gateways . . . . . . . 19
7.4. Receiving (S,G) Joins from the Native Side, for AMT Sources
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
11. Normative References . . . . . . . . . . . . . . . . . . . . 21
12. Informative References . . . . . . . . . . . . . . . . . . . 22
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . 22
14. Intellectual Property Rights Notice . . . . . . . . . . . . . 23
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
16. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 24
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/