draft-ietf-mboned-auto-multicast-05.txt   draft-ietf-mboned-auto-multicast-06.txt 
Network Working Group D. Thaler Network Working Group D. Thaler
Internet-Draft M. Talwar Internet-Draft M. Talwar
Expires: April 23, 2006 A. Aggarwal Expires: December 22, 2006 A. Aggarwal
Microsoft Corporation Microsoft Corporation
L. Vicisano L. Vicisano
Cisco Systems Cisco Systems
T. Pusateri T. Pusateri
Juniper Networks !j
October 20, 2005 June 20, 2006
Automatic IP Multicast Without Explicit Tunnels (AMT) Automatic IP Multicast Without Explicit Tunnels (AMT)
draft-ietf-mboned-auto-multicast-05 draft-ietf-mboned-auto-multicast-06
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 38 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 April 23, 2006. This Internet-Draft will expire on December 22, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 6
3.1 AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 6 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 7
3.3 AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 AMT Relay Router . . . . . . . . . . . . . . . . . . . . . 6 4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5 AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 7 4.4. AMT Relay Router . . . . . . . . . . . . . . . . . . . . . 7
3.6 AMT Relay Anycast Address . . . . . . . . . . . . . . . . 7 4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 8
3.7 AMT Unicast Autonomous System ID . . . . . . . . . . . . . 7 4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 8
3.8 AMT Subnet Prefix . . . . . . . . . . . . . . . . . . . . 7 4.7. AMT Subnet Anycast Prefix . . . . . . . . . . . . . . . . 8
3.9 AMT Gateway Anycast Address . . . . . . . . . . . . . . . 7 4.8. AMT Gateway Anycast Address . . . . . . . . . . . . . . . 8
3.10 AMT Multicast Autonomous System ID . . . . . . . . . . . . 8 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . 9
4.1 Receiving Multicast in an AMT Site . . . . . . . . . . . . 9 5.1.1. Scalability Considerations . . . . . . . . . . . . . . 10
4.1.1 Scalability Considerations . . . . . . . . . . . . . . 10 5.1.2. Spoofing Considerations . . . . . . . . . . . . . . . 10
4.1.2 Spoofing Considerations . . . . . . . . . . . . . . . 10 5.1.3. Protocol Sequence for a Gateway Joining SSM
4.2 Sourcing Multicast from an AMT site . . . . . . . . . . . 11 Receivers to a Relay . . . . . . . . . . . . . . . . . 11
4.2.1 Supporting Site-MBone Multicast . . . . . . . . . . . 12 5.2. Sourcing Multicast from an AMT site . . . . . . . . . . . 13
4.2.2 Supporting Site-Site Multicast . . . . . . . . . . . . 12 5.2.1. Supporting Site-MBone Multicast . . . . . . . . . . . 13
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.2. Supporting Site-Site Multicast . . . . . . . . . . . . 14
5.1 AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 14 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 16
5.1.2 Reserved . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.3 Discovery Nonce . . . . . . . . . . . . . . . . . . . 14 6.1.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 AMT Relay Advertisement . . . . . . . . . . . . . . . . . 14 6.1.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 16
5.2.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 16
5.2.2 Reserved . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.3 Discovery Nonce . . . . . . . . . . . . . . . . . . . 15 6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.4 Relay Address . . . . . . . . . . . . . . . . . . . . 15 6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 17
5.3 AMT Request . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.4. Relay Address . . . . . . . . . . . . . . . . . . . . 17
5.3.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.2 Reserved . . . . . . . . . . . . . . . . . . . . . . . 16 6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.3 Request Nonce . . . . . . . . . . . . . . . . . . . . 16 6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 18
5.4 AMT Membership Query . . . . . . . . . . . . . . . . . . . 16 6.3.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 18
5.4.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . 18
5.4.2 Reserved . . . . . . . . . . . . . . . . . . . . . . . 17 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4.3 Response MAC . . . . . . . . . . . . . . . . . . . . . 17 6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 19
5.4.4 Request Nonce . . . . . . . . . . . . . . . . . . . . 17 6.4.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 19
5.5 AMT Membership Update . . . . . . . . . . . . . . . . . . 17 6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19
5.5.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19
5.5.2 Reserved . . . . . . . . . . . . . . . . . . . . . . . 18 6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 20
5.5.3 Response MAC . . . . . . . . . . . . . . . . . . . . . 18 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5.4 Request Nonce . . . . . . . . . . . . . . . . . . . . 18 6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20
5.6 AMT Multicast Data . . . . . . . . . . . . . . . . . . . . 18 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20
5.6.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21
5.6.2 Reserved . . . . . . . . . . . . . . . . . . . . . . . 19 6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21
5.6.3 UDP Multicast Data . . . . . . . . . . . . . . . . . . 19 6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21
6. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 20 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1 At Startup Time . . . . . . . . . . . . . . . . . . . . . 20 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22
6.2 Joining Groups with MBone Sources . . . . . . . . . . . . 20 6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22
6.3 Responding to Relay Changes . . . . . . . . . . . . . . . 21 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 23
6.4 Creating SSM groups . . . . . . . . . . . . . . . . . . . 22 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 23
6.5 Joining SSM Groups with AMT Sources . . . . . . . . . . . 22 7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 23
6.6 Receiving IGMPv3/MLDv2 Reports at the Gateway . . . . . . 22 7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.7 Sending data to SSM groups . . . . . . . . . . . . . . . . 23 7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 24 7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 24
7.1 At Startup time . . . . . . . . . . . . . . . . . . . . . 24 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 25
7.2 Receiving Relay Discovery messages sent to the Anycast 7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 26
Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.6. Receiving AMT Membership Updates by the Gateway . . . . . 26
7.3 Receiving Membership Updates from AMT Gateways . . . . . . 24 7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 26
7.4 Receiving (S,G) Joins from the Native Side, for AMT 8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 28
Sources . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8.2. Receiving Relay Discovery messages sent to the Anycast
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 8.3. Receiving Membership Updates from AMT Gateways . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 8.4. Receiving (S,G) Joins from the Native Side, for AMT
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 Sources . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1 Normative References . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12.2 Informative References . . . . . . . . . . . . . . . . . . 30 9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31 9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . 33 9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation . . . . . . . . 30
9.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.3. UDP Port number . . . . . . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 38
1. Introduction 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
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 a interim solution to help in the various stages of the transition to a
native multicast network. native multicast network.
skipping to change at page 4, line 32 skipping to change at page 5, line 5
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 internetwork as a large non-
broadcast multi-access (NBMA) link layer, over which we require the broadcast multi-access (NBMA) link layer, over which we require the
ability to multicast. To do this, multicast packets being sent to or ability to multicast. To do this, multicast packets being sent to or
from a site must be encapsulated in unicast packets. If the group from a site must be encapsulated in unicast packets. If the 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.
2. Applicability
AMT is not a substitute for native multicast or a statically
configured multicast tunnel for high traffic flow. Unicast
replication is required to reach multiple receivers that are not part
of the native multicast infrastructure. Unicast replication is also
required by non-native sources to different parts of the native
multicast infrastructure. However, this is no worse than regular
unicast distribution of streams and in most cases much better.
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 ([I-D.ietf-ssm-arch]). multicast ([I-D.ietf-ssm-arch]).
2. Allowing isolated non-NAT sites/hosts to transmit the SSM flavor 2. Allowing isolated non-NAT sites/hosts to transmit the SSM flavor
of multicast. of multicast.
3. Allowing isolated sites/hosts to receive general multicast (ASM 3. Allowing isolated sites/hosts to receive general multicast (ASM
[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 [RFC3053]) will be used for sites that desire Tunnel Brokers, a la [RFC3053]) will be used for sites that desire
this capability. this capability.
Implementors should be aware that site administrators may have Implementers should be aware that site administrators may have
configured administratively scoped multicast boundaries and a remote configured administratively scoped multicast boundaries and a remote
gateway may provide a means to circumvent administrative boundaries. gateway may provide a means to circumvent administrative boundaries.
Therefore, implementations should allow for the configuration of such Therefore, implementations should allow for the configuration of such
boundaries on relays and gateways and perform filtering as needed. boundaries on relays and gateways and perform filtering as needed.
2. Requirements notation 3. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definitions 4. Definitions
+---------------+ Internet +---------------+ +---------------+ Internet +---------------+
| AMT Site | | Native MCast | | AMT Site | | Native MCast |
| | AMT | | | | | |
| +------+----+ Relay +----+----+ AMT | | +------+----+ AMT +----+----+ 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 | |--------> |
| | +-----+-+ +-+-----+ | | | | +-----+-+ +-+-----+ | |
| +------+----+ +----+----+ | | +------+----+ +----+----+ |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
3.1 AMT Pseudo-Interface 4.1. AMT Pseudo-Interface
AMT encapsulation of multicast packets inside unicast packets occurs AMT encapsulation of multicast packets inside unicast packets occurs
at a point that is logically equivalent to an interface, with the at a point that is logically equivalent to an interface, with the
link layer being the unicast-only network. This point is referred to link layer being the unicast-only network. This point is referred to
as a pseudo-interface. Some implementations may treat it exactly as a pseudo-interface. Some implementations may treat it exactly
like any other interface and others may treat it like a tunnel end- like any other interface and others may treat it like a tunnel end-
point. point.
3.2 AMT Gateway 4.2. 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 the Interface. It does not have native multicast connectivity to the
native multicast backbone infrastructure. It is simply referred to native multicast backbone infrastructure. It is simply referred to
in this document as a "gateway". in this document as a "gateway".
3.3 AMT Site 4.3. AMT Site
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.
3.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 internetwork, 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 want to be tunnel endpoints (especially if this results in high fan
fanout), and similarly that service providers do not want out), and similarly that service providers do not want encapsulation
encapsulation to arbitrary routers. Instead, we assume that special- to arbitrary routers. Instead, we assume that special-purpose
purpose routers will be deployed that are suitable for serving as routers will be deployed that are suitable for serving as relays.
relays.
3.5 AMT Relay Anycast Prefix 4.5. 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 Router. routing infrastructure) a route to an available AMT Relay Router.
This could also be private (i.e., not well-known) for a private This could also be private (i.e., not well-known) for a private
relay. relay.
Prefixes for both IPv4 and IPv6 will be assigned in a future version Prefixes for both IPv4 and IPv6 will be assigned in a future version
of this draft. of this draft.
3.6 AMT Relay Anycast Address 4.6. 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 the lowest address in the AMT Relay This address corresponds to the setting the low-order octet of the
Anycast Prefix. AMT Relay Anycast Prefix to 1 (for both IPv4 and IPv6).
3.7 AMT Unicast Autonomous System ID
A 16-bit Autonomous System ID, for use in BGP in accordance to this
memo. This number represents a "pseudo-AS" common to all AMT relays
using the well known AMT Relay Anycast Prefix (private relays use
their own ID).
To protect themselves from erroneous advertisements, managers of
border routers often use databases to check the relation between the
advertised network and the last hop in the AS path. Associating a
specific AS number with the AMT Relay Anycast Address allows us to
enter this relationship in the databases used to check inter-domain
routing [RFC3068].
3.8 AMT Subnet Prefix 4.7. AMT Subnet Anycast Prefix
A well-known address prefix used to advertise (into the M-RIB of the A well-known address prefix used to advertise (into the M-RIB of the
native multicast-enabled infrastructure) a route to AMT Sites. This native multicast-enabled infrastructure) a route to AMT Sites. This
prefix will be used to enable sourcing SSM traffic from an AMT prefix will be used to enable sourcing SSM traffic from an AMT
Gateway. Gateway.
3.9 AMT Gateway Anycast Address 4.8. AMT Gateway Anycast Address
An anycast address in the AMT Subnet Prefix range, which is used by An anycast address in the AMT Subnet Anycast Prefix range, which is
an AMT Gateway to enable sourcing SSM traffic from local used by an AMT Gateway to enable sourcing SSM traffic from local
applications. applications.
3.10 AMT Multicast Autonomous System ID 5. Overview
A 16-bit Autonomous system ID, for use in MBGP in accordance to this
memo. This number represents a "pseudo-AS" common to all AMT relays
using the well known AMT Subnet Prefix (private relays use their own
ID).
4. Overview
4.1 Receiving Multicast in an AMT Site 5.1. Receiving Multicast in an AMT Site
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 | |
+---------------+ +---------------+ +---------------+ +---------------+
skipping to change at page 9, line 34 skipping to change at page 9, line 34
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) pair). gateway which has joined a particular group or (source, group) pair.
Multicast packets from the native infrastructure behind the relay Multicast packets from the native infrastructure behind the 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. UDP encapsulation is used for all AMT control and data
using the IANA reserved AMT port number. packets using the IANA reserved UDP port number for AMT.
Each relay, plus the set of all gateways using the relay, together Each relay, plus the set of all gateways using the relay, together
are thought of as being on a separate logical NBMA link. This are thought of as being on a separate logical NBMA link. This
implies that the AMT recipient- list is a list of "link layer" implies that the AMT recipient- list is a list of "link layer"
addresses which are (IP address, UDP port) pairs. addresses which are (IP address, UDP port) pairs.
Since the number of gateways using a relay can be quite large, and we Since the number of gateways using a relay can be quite large, and 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/MLD [RFC3376] [RFC3810] protocol, and the candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the
PIM-Sparse Mode [I-D.ietf-pim-sm-v2-new] protocol. Since an AMT PIM-Sparse Mode protocol [I-D.ietf-pim-sm-v2-new]. Since an AMT
gateway may be a host, and hosts typically do not implement routing gateway may be a host, and hosts typically do not implement routing
protocols, gateways will use IGMP/MLD as described in Section 5 protocols, gateways will use IGMP/MLD as described in Section 7
below. This allows a host kernel (or a pseudo device driver) to below. This allows a host kernel (or a pseudo device driver) to
easily implement AMT gateway behavior, and obviates the relay from easily implement AMT gateway behavior, and obviates the relay from
the need to know whether a given gateway is a host or a router. From the need to know whether a given gateway is a host or a router. From
the relay's perspective, all gateways are indistinguishable from the relay's perspective, all gateways are indistinguishable from
hosts on an NBMA leaf network. hosts on an NBMA leaf network.
4.1.1 Scalability Considerations 5.1.1. Scalability Considerations
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 an anycast address to relays. The solution we adopt is to assign addresses in anycast
relays. However, simply sending periodic membership reports to the fashion to relays [RFC1546], [RFC2373]. However, simply sending
anycast address can cause duplicates. Specifically, if routing periodic membership reports to an anycast address can cause
changes such that a different relay receives a periodic membership duplicates. Specifically, if routing changes such that a different
report, both the new and old relays will encapsulate data to the AMT relay receives a periodic membership report, both the new and old
site until the old relay's state times out. This is obviously relays will encapsulate data to the AMT site until the old relay's
undesirable. Instead, we use the anycast address merely to find the state times out. This is obviously undesirable. Instead, we use the
unicast address of a relay to which membership reports are sent. anycast address merely to 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 a among more relays so as to keep the number of gateways per relay at a
reasonable level. reasonable level.
4.1.2 Spoofing Considerations 5.1.2. Spoofing Considerations
An attacker could affect the group state in the relay or gateway by An attacker could affect the group state in the relay or gateway by
spoofing the source address in the join or leave reports. This can spoofing the source address in the join or leave reports. This can
be used to launch reflection or denial of service attacks on the be used to launch reflection or denial of service attacks on the
target. Such attacks can be mitigated by using a three way handshake target. Such attacks can be mitigated by using a three way handshake
between the gateway and the relay for each multicast membership between the gateway and the relay for each multicast membership
report or leave. report or leave.
When a gateway or relay wants to send a membership report, it first 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 sends an AMT Request with a request nonce in it. The receiving side
(the respondent) can calculate a message authentication code (MAC) (the respondent) can calculate a message authentication code (MAC)
based on (for example) the source IP address of the Request, the based on (for example) the source IP address of the Request, the
source UDP port, the request nonce, and a secret key known only to source UDP port, the request nonce, and a secret key known only to
the respondent. The algorithm and the input used to calculate the the respondent. The algorithm and the input used to calculate the
MAC does not have to be standardized since the respondent generates MAC does not have to be standardized since the respondent generates
and verifies the MAC and the originator simply echoes it. and verifies the MAC and the originator simply echoes it.
An AMT Membership Query is sent back including the request nonce and 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 MAC to the originator of the Request. The originator then sends
the IGMP/MLD Membership/Listener Report or Leave/Done along with the the IGMP/MLD Membership/Listener Report or Leave/Done (including the
request nonce and the received MAC back to the respondent finalizing IP Header) along with the request nonce and the received MAC back to
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.
4.2 Sourcing Multicast from an AMT site 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
receiver or a network device acting as a Gateway when a directly
connected host joins as a receiver.
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
originates an AMT Relay Discovery message addressed to the Anycast
Relay IP address.
o The closest Relay topologically receives the AMT Relay Discovery
message and returns the nonce from the Discovery in an AMT Relay
Advertisement message so the Gateway can learn of the Relay's
unique IP address.
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
join on behalf of attached receivers (or itself).
o The Gateway now sends an AMT Request message to the Relay's unique
IP address to begin the process of joining the (S,G).
o The Relay responds to the AMT Request message by returning the
nonce from the Request in a AMT Query message. The Query message
contains an IGMP/MLD QUERY indicating how often the Gateway should
repeat AMT Request messages so the (S,G) state can stay refreshed
in the Relay. The Query message also includes an opaque security
code which is generated locally (with no external coordination).
o When the Gateway receives the AMT Query message it responds by
copying the security code from the AMT Query message into a AMT
Membership Update message. In the Update message contains (S1,G1)
in an IGMPv3/MLDv2 formatted packet with an IP header. The nonce
from the AMT Request is also included in the AMT Membership Update
message.
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
(S1,G1) entry stored in the multicast routing table. If the
(S1,G1) entry was created do to this interaction, the multicast
routing protocol running on the Relay will trigger a Join message
towards source S1 to build a native multicast tree in the native
multicast infrastructure.
o As packets are sent from the host S1, they will travel natively
down the multicast tree associated with (S1,G1) in the native
multicast infrastructure to the Relay. The Relay will replicate
to all interfaces in it's outgoing interface list as well as the
tunnel outgoing interface, which is encapsulated in a unicast AMT
Multicast Data message.
o When the Gateway receives the AMT Multicast Data message, it will
accept the packet since it was received over the pseudo-interface
associated with the tunnel to the Relay it had attached to, and
forward the packet to the outgoing interfaces joined by any
attached receiver hosts (or deliver the packet to the application
when the Gateway is the receiver).
o If later (S2,G2) is joined by a receiver, a 3-way handshake of
Request/ Query/Update occurs for this entry. The Discovery/
Advertisement exchange is not required.
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
messages to be returned. And in response to the Query message 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
resources associated with the tunnel. It is assumed that when the
Gateway would want to join an (S,G) again, it would start the
Discovery/Advertisement tunnel establishment process over again.
This same procedure would be used for receivers who operate in Any-
Source Multicast (ASM) mode.
5.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 gateway SHOULD allow for filtering link-local and site-local
traffic.
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 Subnet Anycast Prefix to send multicast, as a result of sourcing
on the AMT pseudo-interface. traffic on the AMT pseudo-interface.
2. The AMT Subnet Prefix is advertised for RPF reachability in the 2. The AMT Subnet Anycast Prefix is advertised for RPF reachability
M-RIB by relays and gateways. in the M-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 information encoded in the address pair to rebuild the use information encoded in the address pair to rebuild the
address of the gateway (source) to which to encapsulate the join address of the gateway (source) to which to encapsulate the join
(see Section 5 for more details). The membership reports use the (see Section 7.2 for more details). The membership reports use
same three way handshake as outlined in Section 4.1.2. the same three way handshake as outlined in Section 5.1.2
4.2.1 Supporting Site-MBone Multicast 5.2.1. Supporting Site-MBone Multicast
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 |
+---------------+ +---------------+ +---------------+ +---------------+
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 Anycast Prefix, then the relay will periodically
rules specified in Section 4.1.2) encapsulate membership updates for (using the rules specified in Section 5.1.2) encapsulate membership
the group to the gateway. The gateway must keep state per relay from updates for the group to the gateway. The gateway must keep state
which membership reports have been sent, and forward multicast per relay from which membership reports have been sent, and forward
traffic from the site to all relays from which membership reports multicast traffic from the site to all relays from which membership
have been received. The choice of whether this state and replication reports have been received. The choice of whether this state and
is done at the link-layer (i.e., by the tunnel interface) or at the replication is done at the link-layer (i.e., by the tunnel interface)
network-layer is implementation dependent. or at the network-layer is implementation dependent.
If there are multiple relays present, this ensures that data from the If there are multiple relays present, this ensures that data from the
AMT site is received via the closest relay to the receiver. This is AMT site is received via the closest relay to the receiver. This 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 PIM Sparse-Mode [I-D.ietf-pim-sm-v2-new]
infrastructure. is used by the multicast 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 given long at the number of relays requiring multicast traffic from a given
AMT site remains reasonable enough to not overly burden the site's AMT site remains reasonable enough to not overly burden the site's
gateway. gateway.
4.2.2 Supporting Site-Site Multicast A source at or behind an AMT gateway requires the gateway to do the
replication to one or more relays and receiving gateways. If this
places too much of a burden on the sourcing gateway, the source
should join the native multicast infrastructure through a permanent
tunnel so that replication occurs within the native multicast
infrastructure.
5.2.2. Supporting Site-Site Multicast
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 |
+---------------+ +---------------+ +---------------+ +---------------+
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 Prefix, then the gateway source address belongs to the AMT Subnet Anycast Prefix, then the
will periodically unicast encapsulate an IGMPv3/MLDv2 [RFC3376] gateway will periodically unicast encapsulate an IGMPv3/MLDv2 Report
[RFC3810] Report directly to the site gateway for the source. [RFC3376], [RFC3810] (including IP Header) 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 sites. site gateway sourcing multicast to a large number of other AMT sites.
However, it is expected that this is not unreasonable for two However, it is expected that this is not unreasonable for 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 a large number of sites could get a point-to-point tunnel to the to 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.
5. Message Formats 6. Message Formats
5.1 AMT Relay Discovery 6.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 unicast address of an AMT relay.
The UDP source port is uniquely selected by the local host operating The UDP source port is uniquely selected by the local host operating
system. The UDP destination port is the IANA reserved AMT port system. The UDP destination port is the IANA reserved AMT port
number. number. The UDP checksum MUST be valid in AMT control messages.
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: Fields:
5.1.1 Type 6.1.1. Type
The type of the message. The type of the message.
5.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.
5.1.3 Discovery Nonce 6.1.3. Discovery Nonce
A 32-bit random value generated by the gateway and replayed by the A 32-bit random value generated by the gateway and replayed by the
relay. relay.
5.2 AMT Relay Advertisement 6.2. AMT Relay Advertisement
The AMT Relay Advertisement message is a UDP packet sent from the AMT The AMT Relay Advertisement message is a UDP packet sent from the 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 The UDP source port is the IANA reserved AMT port number and the UDP
destination port is the source port received in the Discovery destination port is the source port received in the Discovery
message. message. The UDP checksum MUST be valid in AMT control messages.
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=0x2 | Reserved | | Type=0x2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce | | Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Address | | Relay Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
5.2.1 Type 6.2.1. Type
The type of the message. The type of the message.
5.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.
5.2.3 Discovery Nonce 6.2.3. Discovery Nonce
A 32-bit random value generated by the gateway and replayed by the A 32-bit random value generated by the gateway and replayed by the
relay. relay.
5.2.4 Relay Address 6.2.4. Relay Address
The unicast IPv4 or IPv6 address of the AMT relay. The family can be The unicast IPv4 or IPv6 address of the AMT relay. The family can be
determined by the length of the Advertisement. determined by the length of the Advertisement.
5.3 AMT Request 6.3. AMT Request
A Request packet is sent to begin a 3-way handshake for sending an 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 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 from a gateway to a relay, from a gateway to another gateway, or from
a relay to a gateway. a relay to a gateway.
It is sent from the originator's unique unicast address to the It is sent from the originator's unique unicast address to the
respondents' unique unicast address. respondents' unique unicast address.
The UDP source port is uniquely selected by the local host operating The UDP source port is uniquely selected by the local host operating
system. It can be different for each Request and different from the 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 source port used in Discovery messages but does not have to be. The
UDP destination port is the IANA reserved AMT port number. UDP destination port is the IANA reserved AMT port number. The UDP
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: Fields:
5.3.1 Type 6.3.1. Type
The type of the message. The type of the message.
5.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.
5.3.3 Request Nonce 6.3.3. Request Nonce
A 32-bit identifier used to distinguish this request. A 32-bit identifier used to distinguish this request.
5.4 AMT Membership Query 6.4. AMT Membership Query
An AMT Membership Query packet is sent from the relay back to the An AMT Membership Query packet is sent from the respondent back to
originator to solicit an AMT Membership Update while confirming the the originator to solicit an AMT Membership Update while confirming
source of the original request. It contains a relay Message the source of the original request. It contains a relay Message
Authentication Code (MAC) that is a cryptographic hash of a private Authentication Code (MAC) that is a cryptographic hash of a private
secret, the originators address, and the request nonce. secret, the originators address, and the request nonce.
It is sent from the destination address received in the Request to It is sent from the destination address received in the Request to
the source address received in the Request. the source address received in the Request which is the same address
used in the Relay Advertisement.
The UDP source port is the IANA reserved AMT port number and the UDP 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. destination port is the source port received in the Request message.
The UDP 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=0x4 | Reserved | Response MAC | | Type=0x4 | Reserved | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response MAC (continued) | | Response MAC (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGMP Membership Query or MLD Listener Query |
| (including IP Header) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
5.4.1 Type 6.4.1. Type
The type of the message. The type of the message.
5.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.
5.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. One algorithm that could be used
is HMAC-MD5-48 [RFC2104]. is HMAC-MD5-48 [RFC2104].
5.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.
5.5 AMT Membership Update 6.4.5. IGMP/MLD Query (including IP Header)
An AMT Membership Update is sent from the originator to the The message contains either an IGMP Query or an MLD Multicast
respondent containing the original IGMP/MLD Membership/Listener Listener Query. The IGMP or MLD version sent should default to
Report or Leave/Done received over the AMT pseudo-interface. It IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1.
echoes the Response MAC received in the AMT Membership Query so the The IGMP/MLD Query includes a full IP Header. The IP source address
respondent can verify return routability to the originator. 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
endpoint and not mimic the inner header TTL which is typically 1 for
IGMP/MLD messages.
6.5. AMT Membership Update
An AMT Membership Update is sent in response to a previously received
AMT Query message. It contains the original IGMP/MLD Membership/
Listener Report or Leave/Done received over the AMT pseudo-interface
including the original IP header. 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 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
Membership Report for any particular purpose.
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/MLD Message | | IGMP or MLD Message (including IP header) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
5.5.1 Type 6.5.1. Type
The type of the message. The type of the message.
5.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.
5.5.3 Response MAC 6.5.3. Response MAC
The 48-bit MAC received in the Membership Query and echoed back in The 48-bit MAC received in the Membership Query and echoed back in
the Membership Update. the Membership Update.
5.5.4 Request Nonce 6.5.4. Request Nonce
A 32-bit identifier used to distinguish this request. A 32-bit identifier used to distinguish this request.
5.6 AMT Multicast Data 6.5.5. IGMP/MLD Message (including IP Header)
The AMT Data message is a UDP packet encapsulating the data requested The message contains either an IGMP Membership Report, an IGMP
by the originator based on a previous AMT Membership Update message. Membership Leave, an MLD Multicast Listener Report, or an MLD
Listener Done. The IGMP or MLD version sent should be in response
the version of the query received in the AMT Membership Query. The
IGMP/MLD Message includes a full IP Header.
6.6. AMT IP Multicast Data
The AMT Data message is a UDP packet encapsulating the IP Multicast
data requested by the originator based on a previous AMT Membership
Update message.
It is sent from the unicast destination address of the Membership It is sent from the unicast destination address of the Membership
update to the source address of the Membership Update. update to the source address of the Membership Update.
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 Query. sent in the original Query. The UDP checksum SHOULD be 0 in the AMT
IP Multicast Data message.
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 | | Type=0x6 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Data | | IP Multicast Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
5.6.1 Type 6.6.1. Type
The type of the message. The type of the message.
5.6.2 Reserved 6.6.2. Reserved
A 24-bit reserved field. Sent as 0, ignored on receipt. A 24-bit reserved field. Sent as 0, ignored on receipt.
5.6.3 UDP Multicast Data 6.6.3. IP Multicast Data
The original Multicast UDP data packet that is being replicated by The original IP Multicast data packet that is being replicated by the
the relay to the gateways. relay to the gateways including the original IP header.
6. 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.
6.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 will then send
an AMT Relay Discovery message to the AMT Relay Anycast Address, and an AMT Relay Discovery message to the AMT Relay Anycast Address, and
note the unicast address (which is treated as a link-layer address to note the unicast address (which is treated as a link-layer address 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 gateway day) to re-resolve the unicast address of a close relay. The gateway
also SHOULD initialize a timer used to send periodic membership also SHOULD initialize a timer used to send periodic membership
reports to a random value from the interval [0, [Query Interval]] reports to a random value from the interval [0, [Query Interval]]
before sending the first periodic report, in order to prevent startup before sending 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/MLD Proxy, as described in [I-D.ietf-magma-igmp-proxy], as an IGMP/MLD Proxy, as described in [I-D.ietf-magma-igmp-proxy],
with its IGMP/MLD host-mode interface being the AMT pseudo-interface. with its IGMP/MLD host-mode interface being the AMT pseudo-interface.
This enables it to translate group memberships on its downstream This enables it to translate group memberships on its downstream
interfaces into IGMP/MLD Reports. Hosts receiving multicast packets interfaces into IGMP/MLD Reports. Hosts receiving multicast packets
through a gateway should ensure that their M-RIB accepts multicast through an AMT gateway acting as a proxy should ensure that their
packets from the gateway for the sources it is joining. M-RIB accepts multicast packets from the AMT gateway for the sources
it is joining.
Also, if a shared tree routing protocol is used inside the AMT site, 7.2. Gateway Group and Source Addresses
each tree-root must be a gateway, e.g., in PIM-SM each RP must be a
gateway.
Finally, to support sourcing traffic to SSM groups by a gateway with To support sourcing traffic to SSM groups by a gateway with a global
a global unicast address, the AMT Subnet Prefix is treated as the unicast address, the AMT Subnet Anycast 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 Anycast Prefix followed by the high bits
gateway's global unicast address. For example, if IANA assigns the of the gateway's global unicast address.
IPv4 prefix x.y/16 as the AMT Subnet Prefix, and the gateway has
global unicast address a.b.c.d, then the AMT Gateway's Anycast
Address will be x.y.a.b. Note that multiple gateways might end up
with the same anycast address assigned to their pseudo-interfaces.
6.2 Joining Groups with MBone Sources The remaining bits of its global unicast address are appended to the
SSM prefix to create the group address and any spare bits may be
allocated using local policy.
If a gateway wants to source multicast traffic, it must select the
gateway source address and SSM group address in such a way that the
AMT relay can have enough information to reconstruct the gateway's
unicast address when it receives an SSM join for the source.
Note that multiple gateways might end up with the same anycast
address assigned to their pseudo-interfaces.
7.2.1. IPv4
For example, if IANA assigns the IPv4 prefix x.y/16 as the AMT Subnet
Anycast Prefix, and the gateway has global unicast address a.b.c.d,
then the AMT Gateway's Anycast Source Address will be x.y.a.b. Since
the IPv4 SSM group range is 232/8, it MUST allocate IPv4 SSM groups
in the range 232.c.d/24.
Group:
8 16 8
+------------+------------------------+-------------+
| SSM prefix | Low 16 bits of | Local |
| 232/8 | real source address | Policy |
+------------+------------------------+-------------+
Source:
+-------------------------+-------------------------+
|16-bit AMT unicast prefix| high 16 bits of real src|
+-------------------------+-------------------------+
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
2^6 (64) IPv4 group addresses.
7.2.2. IPv6
Similarly for IPv6, this is illustrated in the following figure.
Group:
32 64 32
+------------+------------------------+-------------+
| SSM prefix | Low 64 bits of | Local |
| FF3x::/32 | real source address | Policy |
+------------+------------------------+-------------+
Source:
+-------------------------+-------------------------+
|64-bit AMT unicast prefix| high 64 bits of real src|
+-------------------------+-------------------------+
This allows for 2^32 (over 4 billion) IPv6 group addresses for use by
each AMT gateway.
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
behavior is used instead. behavior is used instead.
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/MLD Membership/Listener Reports to be pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be
skipping to change at page 21, line 35 skipping to change at page 25, line 37
possibilities include: possibilities include:
1. The AMT pseudo-interface might periodically manufacture IGMPv3/ 1. The AMT pseudo-interface might periodically manufacture IGMPv3/
MLDv2 Queries as if they had been received from an IGMP/MLD MLDv2 Queries as if they had been received from an IGMP/MLD
Querier, and deliver them to the IP layer, after which normal Querier, and deliver them to the IP layer, after which normal
IGMP/MLD behavior will cause the appropriate reports to be sent. IGMP/MLD behavior will cause the appropriate reports to be sent.
2. The IGMP/MLD 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.
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.
Therefore, this IGMP/MLD Query interval should be configurable to Therefore, this IGMP/MLD Query interval 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
multicast data packets. IP Multicast data packets.
6.3 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.
6.4 Creating SSM groups 7.5. Joining SSM Groups with AMT Gateway Sources
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
as described below. ([SSM] states that "the policy for allocating
these bits is strictly locally determined at the sender's host.")
When the gateway determined its AMT Gateway Anycast Address as
described above, it used the high bits of its global unicast address.
The remaining bits of its global unicast address are appended to the
232/8 prefix, and any spare bits may be allocated using any policy
(again, strictly locally determined at the sender's host).
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
An IGMPv3/MLDv2 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 Anycast 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/MLDv2 report will be an AMT Gateway inclusion list of the IGMPv3/MLDv2 report will be an AMT Gateway
Anycast Address with the high bits of the address, and the remaining Anycast Address with the high bits of the address, and the remaining
bits will be in the middle of the group address. bits will be in the middle of the group address.
For example, if the IPv4 AMT Subnet Prefix is x.y/16, and the IGMPv3 Section 7.2 describes this format to recover the gateway source
Report is for (x.y.a.b, 232.c.d.e), then the "link layer" IPv4 address.
destination address used for encapsulation is a.b.c.d.
6.6 Receiving IGMPv3/MLDv2 Reports at the Gateway 7.6. Receiving AMT Membership Updates by the Gateway
When an AMT Request is received by the gateway, it follows the same When an AMT Request is received by the gateway from another gateway
3-way handshake procedure a relay would follow if it received the AMT or relay, it follows the same 3-way handshake procedure a relay would
Request. It generates a MAC and responds with an AMT Membership follow if it received the AMT Request. It generates a MAC and
Query. When the AMT Membership Update is received, it verifies the responds with an AMT Membership Query. When the AMT Membership
MAC and then processes the IGMP/MLD Membership/Listener Report or Update is received, it verifies the MAC and then processes the IGMP/
Leave/Done. MLD Membership/Listener Report or Leave/Done.
At the gateway, the IGMP/MLD packet should be an IGMPv3/MLDv2 source At the gateway, the IGMP/MLD packet should be an IGMPv3/MLDv2 source
specific (S,G) join or leave. specific (S,G) join or leave.
If S is not the AMT Gateway Anycast Address, the packet is silently If S is not the AMT Gateway Anycast Address, the packet is silently
discarded. If G does not contain the low bits of the global unicast discarded. If G does not contain the low bits of the global unicast
address (as described above), the packet is also silently discarded. address (as described above), the packet is also silently discarded.
The gateway adds the source address (from the outer IP header) and The gateway adds the source address (from the outer IP header) and
UDP port of the report to a membership list for G. Maintaining this UDP port of the report to a membership list for G. Maintaining this
membership list may be done in any implementation-dependent manner. membership list may be done in any implementation-dependent manner.
For example, it might be maintained by the "link-layer" inside the For example, it might be maintained by the "link-layer" inside the
AMT pseudo-interface, making it invisible to the normal IGMP/MLD AMT pseudo-interface, making it invisible to the normal IGMP/MLD
module. module.
6.7 Sending data to SSM groups 7.7. Sending data to SSM groups
When multicast packets are sent on the AMT pseudo-interface, they are When multicast packets are sent on the AMT pseudo-interface, they are
encapsulated as follows. If the group address is not an SSM group, encapsulated as follows. If the group address is not an SSM group,
then the packet is silently discarded (this memo does not currently then the packet is silently discarded (this memo does not currently
provide a way to send to non-SSM groups). provide a 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/MLDv2 report for the packet's (source, group) pair. an IGMPv3/MLDv2 report for the packet's (source, group) pair.
7. Relay Router Details 8. Relay Router Details
7.1 At Startup time 8.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 on pseudo-interface. It shall also add the AMT Relay Anycast Address 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.
The relay router shall also enable IGMPv3/MLDv2 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/MLD 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 Anycast Prefix is assigned to the AMT pseudo-interface, and
Subnet Prefix is injected into the M-RIB of MBGP. the AMT Subnet Anycast Prefix is injected by the AMT Relay into the
M-RIB of MBGP.
7.2 Receiving Relay Discovery messages sent to the Anycast Address 8.2. Receiving Relay Discovery messages sent to the Anycast Address
When a relay receives an AMT Relay Discovery message directed to the When a relay receives an AMT Relay Discovery message directed to the
AMT Relay Anycast Address, it should respond with an AMT Relay AMT Relay Anycast Address, it should respond with an 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 Membership Updates from AMT Gateways 8.3. Receiving Membership Updates from AMT Gateways
The relay operates passively, sending no Queries but simply tracking The relay operates passively, sending no periodic IGMP/MLD Queries
membership information according to Reports and Leave messages, as a but simply tracking membership information according to AMT Request/
router normally would. In addition, the relay must also do explicit Query/Membership Update tuples received. In addition, the relay must
membership tracking, as to which gateways on the AMT pseudo- also do explicit membership tracking, as to which gateways on the AMT
interface have joined which groups. Once an AMT Membership Update pseudo-interface have joined which groups. Once an AMT Membership
has been successfully received, it updates the forwarding state for Update has been successfully received, it updates the forwarding
the appropriate group and source (if provided). When data arrives state for the appropriate group and source (if provided). When data
for that group, the traffic must be encapsulated to each gateway arrives for that group, the traffic must be encapsulated to each
which has joined that group. gateway which has joined that group or (S,G).
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 perform the replication at the "link-layer", with no changes and perform the replication at the "link-layer", with no changes
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.
7.4 Receiving (S,G) Joins from the Native Side, for AMT Sources 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
adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/
MLD Query contained within the AMT Membership Query message. The
QQIC field is defined in [RFC3376] and [RFC3810].
The relay encapsulates an IGMPv3/MLDv2 report to the AMT source as 8.4. Receiving (S,G) Joins from the Native Side, for AMT Sources
described above in Section 4.1.2.
8. IANA Considerations The relay sends an IGMPv3/MLDv2 report to the AMT source as described
above in Section 5.1.2
9. IANA Considerations
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. For IPv4, a prefix length of 16 will meet default-free BGP networks.
this requirement. For IPv6, a prefix length of 64 will meet this
requirement. This is a one time effort and there will be no need for
any recurring assignment after this stage.
The IANA should also allocate an Autonomous System ID which can be 9.1.1. IPv4
used as a pseudo-AS when advertising routes to the above prefix.
A prefix length of 18 will meet this requirement.
9.1.2. IPv6
A prefix length of 32 will meet this requirement. IANA has
previously set aside the range 2001::/16 for allocating prefixes for
this purpose.
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: a length number of groups available to be created by the AMT gateway: in the
of 16 gives 256 groups, and a length of 8 gives 65536 groups. For IPv4 case, a prefix length of 16 gives 256 groups, and a prefix
diagnostic purposes, it is helpful to have a prefix length which is a length of 8 gives 65536 groups.
multiple of 8, although this is not required.
IANA has allocated UDP reserved port number 2268 for AMT 9.2.1. IPv4
As described above in Section 7.2.1 an IPv4 prefix with a length of
18 is requested for this purpose.
9.2.2. IPv6
As described above in Section 7.2.2 an IPv6 prefix with a length of
48 is requested.
9.3. UDP Port number
IANA has previously allocated UDP reserved port number 2268 for AMT
encapsulation. encapsulation.
9. Security Considerations All allocations are a one time effort and there will be no need for
any recurring assignment after this stage.
10. Security Considerations
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 inject a false route to the AMT Subnet router or a rogue AS could inject a false route to the AMT Subnet
Prefix, and thus divert joins and cause RPF failures of multicast Anycast Prefix, and thus divert joins and cause RPF failures of
traffic. As the AMT Subnet Prefix will be advertised by multiple multicast traffic. As the AMT Subnet Anycast Prefix will be
entities, guaranteeing the integrity of this shared MBGP prefix is advertised by multiple entities, guaranteeing the integrity of this
much more challenging than verifying the correctness of a regular shared MBGP prefix is much more challenging than verifying the
unicast advertisement. To mitigate this threat, routing operators correctness of a regular unicast advertisement. To mitigate this
should configure the BGP sessions to filter out any more specific threat, routing operators should configure the BGP sessions to filter
advertisements for the AMT Subnet Prefix. out any more specific advertisements for the AMT Subnet Anycast
Prefix.
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 prevent 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) from making use because of e.g. access lists deployed by its ISP) from making use
of AMT 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 encapsulated multicast packet MUST discard the multicast packet
if the IPv4 source address in the outer header is not composed of if the IP source address in the outer header does not match the
the last 2 bytes of the source address and the 2 middle bytes of source address that would be extracted using the rules of
the destination address of the inner header (i.e., a.b.c.d must Section 7.2.
be 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 source address in the outer header is not the address to which
the encapsulated join message was sent. An AMT Gateway that the encapsulated join message was sent. An AMT Gateway that
receives an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the receives an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the
message if the IPv4 destination address in the outer header is message if the IP destination address in the outer header does
not composed of the last 2 bytes of S and the 2 middle bytes of G not match the source address that would be extracted using the
(i.e. the destination address a.b.c.d must be composed of the a.b rules of Section 7.2.
of the multicast source x.y.a.b and the c.d of the multicast
group 232.c.d.e).
10. Contributors 11. Contributors
The following people provided significant contributions to earlier The following people provided significant contributions to earlier
versions of this draft. versions of this draft.
Dirk Ooms Dirk Ooms
OneSparrow OneSparrow
Belegstraat 13; 2018 Antwerp; Belgium Belegstraat 13; 2018 Antwerp; Belgium
EMail: dirk@onesparrow.com EMail: dirk@onesparrow.com
11. Acknowledgments 12. 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.
12. References In addition, extensive comments were received from Pekka Savola, Greg
Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John
Zwiebel, and Lenny Giuliano.
12.1 Normative References Juniper Networks was instrumental in funding several versions of this
draft as well as an open source implementation.
13. References
13.1. Normative References
[I-D.ietf-magma-igmp-proxy] [I-D.ietf-magma-igmp-proxy]
Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/ Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/
MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", MLD-based Multicast Forwarding ('IGMP/MLD Proxying')",
draft-ietf-magma-igmp-proxy-06 (work in progress), draft-ietf-magma-igmp-proxy-06 (work in progress),
April 2004. April 2004.
[I-D.ietf-ssm-arch] [I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", draft-ietf-ssm-arch-07 (work in progress), IP", draft-ietf-ssm-arch-07 (work in progress),
skipping to change at page 30, line 30 skipping to change at page 34, line 30
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
12.2 Informative References 13.2. Informative References
[I-D.ietf-pim-sm-v2-new] [I-D.ietf-pim-sm-v2-new]
Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, Fenner, B., "Protocol Independent Multicast - Sparse Mode
"Protocol Independent Multicast - Sparse Mode PIM-SM): (PIM-SM): Protocol Specification (Revised)",
Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-12 (work in progress),
draft-ietf-pim-sm-v2-new-11 (work in progress), March 2006.
October 2004.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
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.
Authors' Addresses Authors' Addresses
skipping to change at page 32, line 5 skipping to change at page 37, line 5
Lorenzo Vicisano Lorenzo Vicisano
Cisco Systems Cisco Systems
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 525 2530 Phone: +1 408 525 2530
Email: lorenzo@cisco.com Email: lorenzo@cisco.com
Tom Pusateri Tom Pusateri
Juniper Networks !j
1194 North Mathilda Avenue 222 E. Jones Ave.
Sunnyvale, CA 94089 Wake Forest, NC 27587
USA USA
Phone: +1 408 745 2000 Email: pusateri@bangj.com
Email: pusateri@juniper.net
Intellectual Property Statement Intellectual Property Statement
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
skipping to change at page 33, line 41 skipping to change at page 38, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 currently provided by the
Internet Society. Internet Society.
 End of changes. 132 change blocks. 
325 lines changed or deleted 524 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/