draft-ietf-mboned-auto-multicast-10.txt   draft-ietf-mboned-auto-multicast-11.txt 
Network Working Group D. Thaler Network Working Group D. Thaler
Internet-Draft M. Talwar Internet-Draft M. Talwar
Intended status: Standards Track A. Aggarwal Intended status: Standards Track A. Aggarwal
Expires: September 8, 2010 Microsoft Corporation Expires: January 12, 2012 Microsoft Corporation
L. Vicisano L. Vicisano
Qualcomm Inc. Qualcomm Inc.
T. Pusateri T. Pusateri
!j !j
March 7, 2010 T. Morin
France Telecom - Orange
July 11, 2011
Automatic IP Multicast Without Explicit Tunnels (AMT) Automatic IP Multicast Tunneling
draft-ietf-mboned-auto-multicast-10 draft-ietf-mboned-auto-multicast-11
Abstract Abstract
Automatic Multicast Tunneling (AMT) allows multicast communication Automatic IP Multicast Tunneling (AMT) allows multicast reception by
amongst isolated multicast-enabled sites or hosts, attached to a isolated multicast-enabled sites or hosts, attached to a network
network which has no native multicast support. It also enables them which has no native multicast support. It enables them to receive
to exchange multicast traffic with the native multicast multicast traffic from the native multicast infrastructure without
infrastructure and does not require any manual configuration. AMT requiring any manual configuration. AMT uses an encapsulation
uses an encapsulation interface so that no changes to a host stack or interface so that no changes to a host stack or applications are
applications are required, all protocols (not just UDP) are handled, required, all protocols (not just UDP) are handled, and there is no
and there is no additional overhead in core routers. additional overhead in core routers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 12, 2012.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 8 4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 8
4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. AMT Relay Router . . . . . . . . . . . . . . . . . . . . . 8 4.4. AMT Relay . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 9 4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 9
4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 9 4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 9
4.7. AMT Subnet Anycast Prefix . . . . . . . . . . . . . . . . 9
4.8. AMT Gateway Anycast Address . . . . . . . . . . . . . . . 9
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . 10 5.1. Scalability Considerations . . . . . . . . . . . . . . . . 11
5.1.1. Scalability Considerations . . . . . . . . . . . . . . 11 5.2. Spoofing Considerations . . . . . . . . . . . . . . . . . 11
5.1.2. Spoofing Considerations . . . . . . . . . . . . . . . 11 5.3. Protocol Sequence . . . . . . . . . . . . . . . . . . . . 12
5.1.3. Protocol Sequence for a Gateway Joining SSM 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15
Receivers to a Relay . . . . . . . . . . . . . . . . . 12 6.1. Use of UDP . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Sourcing Multicast from an AMT site . . . . . . . . . . . 14 6.2. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 15
5.2.1. Supporting Site-MBone Multicast . . . . . . . . . . . 15 6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.2. Supporting Site-Site Multicast . . . . . . . . . . . . 16 6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 15
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 15
6.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 17 6.3. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 16
6.1.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17 6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 16
6.1.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 17 6.3.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 16
6.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 17 6.3.4. Relay Address . . . . . . . . . . . . . . . . . . . . 16
6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.4. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 18 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 18 6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.4. Relay Address . . . . . . . . . . . . . . . . . . . . 18 6.4.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 17
6.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 18 6.5. AMT Membership Query . . . . . . . . . . . . . . . . . . . 17
6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 19 6.5.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 19 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 19
6.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . 19 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19
6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.5.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19
6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20 6.5.6. Gateway information fields . . . . . . . . . . . . . . 19
6.4.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20 6.6. AMT Membership Update . . . . . . . . . . . . . . . . . . 19
6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 20 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 20 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20
6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 21 6.6.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20
6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.6.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21
6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22 6.6.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21
6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 22 6.7. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21
6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 22 6.7.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 22 6.7.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22
6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 22 6.7.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22
6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23 6.8. AMT Teardown . . . . . . . . . . . . . . . . . . . . . . . 22
6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 23 6.8.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.7. AMT Membership Teardown . . . . . . . . . . . . . . . . . 23 6.8.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23
6.7.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.8.3. Original Response MAC . . . . . . . . . . . . . . . . 23
6.7.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 24 6.8.4. Original Request Nonce . . . . . . . . . . . . . . . . 23
6.7.3. Original Response MAC . . . . . . . . . . . . . . . . 24 6.8.5. Original Source Port . . . . . . . . . . . . . . . . . 23
6.7.4. Original Request Nonce . . . . . . . . . . . . . . . . 24 6.8.6. Original Source Address . . . . . . . . . . . . . . . 23
6.7.5. Original Source Port . . . . . . . . . . . . . . . . . 24 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 25
6.7.6. Source AFI . . . . . . . . . . . . . . . . . . . . . . 24 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 25
6.7.7. Original Source Address . . . . . . . . . . . . . . . 25 7.2. Gateway identification . . . . . . . . . . . . . . . . . . 25
6.7.8. IGMP/MLD Message (including IP Header) . . . . . . . . 25 7.3. Joining Multicast Groups . . . . . . . . . . . . . . . . . 26
7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 26 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 26
7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 26 8. AMT Relay Details . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 26 8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 27
7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 28
7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 28
7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 29
7.6. Receiving AMT Membership Updates by the Gateway . . . . . 29
7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 29
8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 30
8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 30
8.2. Receiving Relay Discovery messages sent to the Anycast 8.2. Receiving Relay Discovery messages sent to the Anycast
Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.3. Receiving Membership Updates from AMT Gateways . . . . . . 30 8.3. Receiving Membership Updates from AMT Gateways . . . . . . 27
8.4. Receiving (S,G) Joins from the Native Side, for AMT 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
Sources . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 32 9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.2. UDP Port number . . . . . . . . . . . . . . . . . . . . . 29
9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation . . . . . . . . 32 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
9.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.3. UDP Port number . . . . . . . . . . . . . . . . . . . . . 32 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 13.2. Informative References . . . . . . . . . . . . . . . . . . 33
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
13.1. Normative References . . . . . . . . . . . . . . . . . . . 36
13.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 5, line 28 skipping to change at page 5, line 28
specification can be deployed in a few strategically-placed network specification can be deployed in a few strategically-placed network
nodes and in user-installable software modules (pseudo device drivers nodes and in user-installable software modules (pseudo device drivers
and/or user-mode daemons) that reside underneath the socket API of and/or user-mode daemons) that reside underneath the socket API of
end-nodes' operating systems. This mechanism is very similar to that end-nodes' operating systems. This mechanism is very similar to that
used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6 used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6
connectivity. connectivity.
Effectively, AMT treats the unicast-only inter-network as a large Effectively, AMT treats the unicast-only inter-network as a large
non-broadcast multi-access (NBMA) link layer, over which we require non-broadcast multi-access (NBMA) link layer, over which we require
the ability to multicast. To do this, multicast packets being sent the ability to multicast. To do this, multicast packets being sent
to or from a site must be encapsulated in unicast packets. If the to site must be encapsulated in unicast packets. If the group has
group has members in multiple sites, AMT encapsulation of the same members in multiple sites, AMT encapsulation of the same multicast
multicast packet will take place multiple times by necessity. packet will take place multiple times by necessity.
A previous of this solution was previously "Automatic IP Multicast
without explicit Tunnels", to highlight the fact that the tunneling
used is lightweight and does not require statically configured
tunnels used as point to point interfaces.
2. Applicability 2. Applicability
AMT is not a substitute for native multicast or a statically AMT is not a substitute for native multicast or a statically
configured multicast tunnel for high traffic flow. Unicast configured multicast tunnel for high traffic flow. Unicast
replication is required to reach multiple receivers that are not part replication is required to reach multiple receivers that are not part
of the native multicast infrastructure. Unicast replication is also of the native multicast infrastructure. However, this is no worse
required by non-native sources to different parts of the native than regular unicast distribution of streams and in most cases much
multicast infrastructure. However, this is no worse than regular better.
unicast distribution of streams and in most cases much better.
The following problems are addressed:
1. Allowing isolated sites/hosts to receive the SSM flavor of
multicast ([RFC4607]).
2. Allowing isolated non-NAT sites/hosts to transmit the SSM flavor
of multicast.
3. Allowing isolated sites/hosts to receive general multicast (ASM This document specifies procedures allowing isolated sites to receive
[RFC1112]). both general Any Source Multicast (ASM, [RFC1112]), and Specific
Source Multicast (SSM, [RFC4607]).
This document does not address allowing isolated sites/hosts to Earlier versions of this document were describing how to use AMT to
transmit general multicast. We expect that other solutions (e.g., allow isolated non-NAT sites/hosts to transmit SSM multicast ; the
Tunnel Brokers, a la [RFC3053]) will be used for sites that desire specifications for these functionalities have been left off the
this capability. current document for the following reasons: the drawback that these
specifications required a source site Gateway to replicate traffic to
many Relays in the multicast-enabled part of the network, lack of
contributors to document alternative proposals based on AMT,
existence of ways to offer similar functionality using Tunnel Broker
approaches [RFC3053], or at the application layer.
Implementers 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.
3. 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].
4. Definitions 4. Definitions
+---------------+ Internet +---------------+ +---------------+ Internet +---------------+
| AMT Site | | Native MCast | | AMT Site | | Native MCast |
| | | | | | | |
| +------+----+ AMT +----+----+ AMT | | +------+----+ AMT +----+----+ |
| |AMT Gateway| Anycast |AMT Relay| Subnet | | |AMT Gateway| Anycast |AMT Relay| |
| | +-----+-+ Prefix +-+-----+ | Prefix | | | +-----+-+ Prefix +-+-----+ | |
| | |AMT IF | <------------|AMT IF | |--------> | | | |AMT IF | <------------|AMT IF | | |
| | +-----+-+ +-+-----+ | | | | +-----+-+ +-+-----+ | |
| +------+----+ +----+----+ | | +------+----+ +----+----+ |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
4.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.
4.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.
Interface. It does not have native multicast connectivity to the It does not have native multicast connectivity to the native
native multicast backbone infrastructure. It is simply referred to multicast backbone infrastructure. It is simply referred to in this
in this document as a "gateway". document as a "gateway".
4.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.
4.4. AMT Relay Router 4.4. AMT Relay
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 inter-network, and an AMT pseudo-interface. It is multicast capable inter-network, and an AMT pseudo-interface. It is
simply referred to in this document as a "relay". simply referred to in this document as a "relay".
As with [RFC3056], we assume that normal multicast routers do not As with [RFC3056], we assume that normal multicast routers do not
want to be tunnel endpoints (especially if this results in high fan want to be tunnel endpoints (especially if this results in high fan
out), and similarly that service providers do not want encapsulation out). Instead, we assume that special-purpose routers will be
to arbitrary routers. Instead, we assume that special-purpose deployed that are suitable for serving as relays.
routers will be deployed that are suitable for serving as relays.
4.5. AMT Relay Anycast Prefix 4.5. AMT Relay Anycast Prefix
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.
4.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 setting the low-order octet of the This address corresponds to the setting the low-order octet of the
AMT Relay Anycast Prefix to 1 (for both IPv4 and IPv6). AMT Relay Anycast Prefix to 1 (for both IPv4 and IPv6).
4.7. AMT Subnet Anycast Prefix
A well-known address prefix used to advertise (into the M-RIB of the
native multicast-enabled infrastructure) a route to AMT Sites. This
prefix will be used to enable sourcing SSM traffic from an AMT
Gateway.
4.8. AMT Gateway Anycast Address
An anycast address in the AMT Subnet Anycast Prefix range, which is
used by an AMT Gateway to enable sourcing SSM traffic from local
applications.
5. Overview 5. Overview
5.1. Receiving Multicast in an AMT Site
Internet Internet
+---------------+ +---------------+ +---------------+ +---------------+
| AMT Site | 2. 3-way Membership | MBone | | AMT Site | 2. 3-way Membership | Native MCast |
| | Handshake | | | | Handshake | |
| 1. Join +---+---+ =================> +---+---+ | | 1. Join +---+---+ =================> +---+---+ |
| +---->|Gateway| | Relay | | | +---->|Gateway| | Relay | |
| | +---+---+ <================= +---+---+ | | | +---+---+ <================= +---+---+ |
| R-+ | 3. Receive Data | | | R-+ | 3. Receive Data | |
+---------------+ +---------------+ +---------------+ +---------------+
Receiving Multicast in an AMT Site Receiving Multicast in an AMT Site
AMT relays and gateways cooperate to transmit multicast traffic AMT relays and gateways cooperate to transmit multicast traffic
skipping to change at page 11, line 14 skipping to change at page 11, line 12
candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the
PIM-Sparse Mode protocol [RFC4601]. Since an AMT gateway may be a PIM-Sparse Mode protocol [RFC4601]. Since an AMT gateway may be a
host, and hosts typically do not implement routing protocols, host, and hosts typically do not implement routing protocols,
gateways will use IGMP/MLD as described in Section 7 below. This gateways will use IGMP/MLD as described in Section 7 below. This
allows a host kernel (or a pseudo device driver) to easily implement allows a host kernel (or a pseudo device driver) to easily implement
AMT gateway behavior, and obviates the relay from the need to know AMT gateway behavior, and obviates the relay from the need to know
whether a given gateway is a host or a router. From the relay's whether a given gateway is a host or a router. From the relay's
perspective, all gateways are indistinguishable from hosts on an NBMA perspective, all gateways are indistinguishable from hosts on an NBMA
leaf network. leaf network.
5.1.1. Scalability Considerations 5.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 addresses in anycast relays. The solution we adopt is to assign addresses in anycast
fashion to relays [RFC1546], [RFC4291]. However, simply sending fashion to relays [RFC1546], [RFC4291]. However, simply sending
periodic membership reports to an anycast address can cause periodic membership reports to an anycast address can cause
duplicates. Specifically, if routing changes such that a different duplicates. Specifically, if routing changes such that a different
relay receives a periodic membership report, both the new and old relay receives a periodic membership report, both the new and old
relays will encapsulate data to the AMT site until the old relay's relays will encapsulate data to the AMT site until the old relay's
state times out. This is obviously undesirable. Instead, we use the state times out. This is obviously undesirable. Instead, we use the
anycast address merely to find the unicast address of a relay to anycast address merely to find the unicast address of a relay to
which membership reports are sent. which membership reports are sent.
Since adding another relay has the result of adding another This approach allows the gateways to be spread out among more relays
independent NBMA link, this allows the gateways to be spread out so as to keep the number of gateways per relay at a reasonable level.
among more relays so as to keep the number of gateways per relay at a
reasonable level.
5.1.2. Spoofing Considerations 5.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 by spoofing the
spoofing the source address in the join or leave reports. This can source address in AMT Update messages containing join or leave
be used to launch reflection or denial of service attacks on the reports. This can be used to launch reflection or denial of service
target. Such attacks can be mitigated by using a three way handshake attacks on the target Relay. Such attacks can be mitigated by using
between the gateway and the relay for each multicast membership a three way handshake between the gateway and the relay for each
report or leave. multicast membership report or leave.
When a gateway or relay wants to send a membership report, it first When a gateway wants to send a membership report, it first sends an
sends an AMT Request with a request nonce in it. The receiving side AMT Request with a request nonce in it. The Relay can calculate a
(the respondent) can calculate a message authentication code (MAC) message authentication code (MAC) based on (for example)the source IP
based on (for example) the source IP address of the Request, the address of the Request, the source UDP port, the request nonce, and a
source UDP port, the request nonce, and a secret key known only to secret key known only to the Relay. The algorithm does not have to
the respondent. The algorithm and the input used to calculate the be standardized since the Relay generates and verifies the MAC and
MAC does not have to be standardized since the respondent generates the Gateway simply echoes it back, but an algorithm such as
and verifies the MAC and the originator simply echoes it. HMAC-MD5-48 [RFC2104] SHOULD be used at a minimum.
An AMT Membership Query is sent back including the request nonce and An AMT Membership Query is sent back to the gateway having originated
the MAC to the originator of the Request. The originator then sends the Request, including the request nonce and the MAC. The gateway
the IGMP/MLD Membership/Listener Report or Leave/Done (including the then sends the IGMP/MLD Membership/Listener Report or Leave/Done
IP Header) along with the request nonce and the received MAC back to (including the IP Header) along with the request nonce and the
the respondent finalizing the 3-way handshake. received MAC back to the relay, finalizing the 3-way handshake.
Upon reception, the respondent can recalculate the MAC based on the Upon reception, the relay can recalculate the MAC based on the source
source IP address, the source UDP port, the request nonce, and the IP address, the source UDP port, the request nonce, and the local
local secret. The IGMP/MLD message is only accepted if the received secret. The IGMP/MLD message is only accepted if the received MAC
MAC matches the calculated MAC. matches the calculated MAC.
A relay MUST NOT create state for a gateway before successful
validation of a MAC of an AMT Update from this gateway; a relay
SHOULD delete all states for a gateway after a small timer after it
stops having any AMT forwarding state for a Gateway (i.e. the Gateway
left all multicast groups it had joined).
The local secret never has to be shared with the other side. It is The local secret never has to be shared with the other side. It is
only used to verify return routability of the originator. only used to verify return routability of the originator.
Since the same Request Nonce and source IP address can be re-used, Since the same Request Nonce and source IP address can be re-used,
the receiver SHOULD change its secret key at least once per hour. the relay SHOULD change its secret key at least once per hour.
However, AMT Membership updates received with the previous secret However, AMT Membership updates received with the previous secret
MUST be accepted for up to the IGMP/MLD Query Interval. MUST be accepted for up to the IGMP/MLD Query Interval.
The condition might occur where the gateway or relay that initially The condition might occur where the gateway that initially sent the
sent the AMT Request dynamically changes its IP address. This might AMT Request dynamically changes its IP address. This might occur due
occur due to a change in wireless networks, a DHCP assignment, or to a change in wireless networks, a DHCP assignment, or another
another network failure. When this occurs, it is no longer possible network failure. When this occurs, it is no longer possible to
to verify the MAC using the source address and source port. Though, verify the MAC using the source address and source port. Though, in
in order to reduce state, it is desirable to tear down the state that order to reduce state, it is desirable to tear down the state that
was created with the old source address. A Teardown message with was created with the old source address. A Teardown message with
special considerations for calculating the MAC is described below to special considerations for calculating the MAC is described below to
perform this function. perform this function.
5.1.3. Protocol Sequence for a Gateway Joining SSM Receivers to a Relay 5.3. Protocol Sequence
This description assumes the Gateway can be a host joining as a This description assumes the Gateway can be a host joining as a
receiver or a network device acting as a Gateway when a directly receiver or a network device acting as a Gateway when a directly
connected host joins as a receiver. connected host joins as a receiver.
Protocol sequence for a multicast SSM channel (S1,G1):
o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1). o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1).
o Gateway receives report. If it has no tunnel state with a Relay, o Gateway receives report. If it has no tunnel state with a Relay,
it originates an AMT Relay Discovery message addressed to the it originates an AMT Relay Discovery message addressed to the
Anycast Relay IP address. The AMT Relay Discovery message can be Anycast Relay IP address. The AMT Relay Discovery message can be
sent on demand if no relay is known at this time or at startup and sent on demand if no relay is known at this time or at startup and
be periodically refreshed. be periodically refreshed.
o The closest Relay topologically receives the AMT Relay Discovery o The closest Relay topologically receives the AMT Relay Discovery
message and returns the nonce from the Discovery in an AMT Relay message and returns the nonce from the Discovery in an AMT Relay
skipping to change at page 14, line 32 skipping to change at page 15, line 5
number of AMT Membership Update messages. number of AMT Membership Update messages.
o When the Gateway leaves all (S,G) entries, the Relay can free o When the Gateway leaves all (S,G) entries, the Relay can free
resources associated with the tunnel. It is assumed that when the resources associated with the tunnel. It is assumed that when the
Gateway would want to join an (S,G) again, it would start the Gateway would want to join an (S,G) again, it would start the
Discovery/Advertisement tunnel establishment process over again. Discovery/Advertisement tunnel establishment process over again.
This same procedure would be used for receivers who operate in Any- This same procedure would be used for receivers who operate in Any-
Source Multicast (ASM) mode. Source Multicast (ASM) mode.
5.2. Sourcing Multicast from an AMT site 6. Message Formats
Two cases are discussed below: multicast traffic sourced in an AMT
site and received in the MBone, and multicast traffic sourced in an
AMT site and received in another AMT site.
In both cases only SSM sources are supported. Furthermore this
specification only deals with the source residing directly in the
gateway. To enable a generic node in an AMT site to source
multicast, additional coordination between the gateway and the
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 following:
1. Applications residing in the gateway use addresses in the AMT
Subnet Anycast Prefix to send multicast, as a result of sourcing
traffic on the AMT pseudo-interface.
2. The AMT Subnet Anycast Prefix is advertised for RPF reachability
in the M-RIB by relays and gateways.
3. Relays or gateways that receive a join for a source/group pair
use information encoded in the address pair to rebuild the
address of the gateway (source) to which to encapsulate the join
(see Section 7.2 for more details). The membership reports use
the same three way handshake as outlined in Section 5.1.2
5.2.1. Supporting Site-MBone Multicast
Internet
+---------------+ +---------------+
| AMT Site | 2. 3-way Membership | MBone |
| | Handshake | |
| +---+---+ <================= +---+---+ 1. Join |
| |Gateway| | Relay |<-----+ |
| +---+---+ =================> +---+---+ | |
| | 3. Receive Data | +-R |
+---------------+ +---------------+
Site-MBone Multicast
If a relay receives an explicit join from the native infrastructure,
for a given (source, group) pair where the source address belongs to
the AMT Subnet Anycast Prefix, then the relay will periodically
(using the rules specified in Section 5.1.2) encapsulate membership
updates for the group to the gateway. The gateway must keep state
per relay from which membership reports have been sent, and forward
multicast traffic from the site to all relays from which membership
reports have been received. The choice of whether this state and
replication is done at the link-layer (i.e., by the tunnel interface)
or at the network-layer is implementation dependent.
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
necessary when the routers in the native multicast infrastructure
employ Reverse-Path Forwarding (RPF) checks against the source
address, such as occurs when PIM Sparse-Mode [RFC4601] is used by the
multicast infrastructure.
The solution above will scale to an arbitrary number of relays, as
long at the number of relays requiring multicast traffic from a given
AMT site remains reasonable enough to not overly burden the site's
gateway.
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
+---------------+ +---------------+
| AMT Site | 2. 3-way Membership | AMT Site |
| | Handshake | |
| +---+---+ <================= +---+---+ 1. Join |
| |Gateway| |Gateway|<-----+ |
| +---+---+ =================> +---+---+ | |
| | 3. Receive Data | +-R |
+---------------+ +---------------+
Site-Site Multicast
Since we require gateways to accept membership reports, as described
above, it is also possible to support multicast among AMT sites,
without requiring assistance from any relays.
When a gateway wants to join a given (source, group) pair, where the 6.1. Use of UDP
source address belongs to the AMT Subnet Anycast Prefix, then the
gateway will periodically unicast encapsulate an IGMPv3/MLDv2 Report
[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 All AMT messages are UDP packets.
site gateway sourcing multicast to a large number of other AMT sites.
However, it is expected that this is not unreasonable for two
reasons. First, the gateway does not have native multicast
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
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
native multicast infrastructure, and use that instead of AMT.
6. Message Formats Messages sent to the Relay are sent to the IANA reserved AMT port
number (Section 9), from a source port uniquely selected by the host
operating system of the Gateway. Messages sent by the Relay are sent
from the IANA reserved AMT port number.
6.1. AMT Relay Discovery The UDP checksum MUST be valid in all AMT control messages (Relay
Discovery, Relay Advertisement, Membership Request, Membership Query,
Membership Update). Section 6.7 specifies the behavior with
reference to the UDP checksums of AMT IP Multicast Data messages.
The AMT Relay Discovery message is a UDP packet sent from the AMT 6.2. AMT Relay Discovery
gateway unicast address to the AMT relay anycast address to discover
the unicast address of an AMT relay.
The UDP source port is uniquely selected by the local host operating The AMT Relay Discovery message is sent from the AMT gateway unicast
system. The UDP destination port is the IANA reserved AMT port address to the AMT Relay Anycast address to discover the unicast
number. The UDP checksum MUST be valid in AMT control messages. address of an AMT relay.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AMT Relay Discovery AMT Relay Discovery
6.1.1. Type 6.2.1. Type
The type of the message. The type of the message.
6.1.2. Reserved 6.2.2. Reserved
A 24-bit reserved field. Sent as 0, ignored on receipt. A 24-bit reserved field. Sent as 0, ignored on receipt.
6.1.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.
6.2. AMT Relay Advertisement 6.3. AMT Relay Advertisement
The AMT Relay Advertisement message is a UDP packet sent from the AMT The AMT Relay Advertisement message sent from the AMT relay anycast
relay anycast address to the source of the discovery message. 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. The UDP CHECKSUM MUST be valid in AMT control messages. 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=0x2 | Reserved | | Type=0x2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce | | Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Address | | Relay Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AMT Relay Advertisement AMT Relay Advertisement
6.2.1. Type 6.3.1. Type
The type of the message. The type of the message.
6.2.2. Reserved 6.3.2. Reserved
A 24-bit reserved field. Sent as 0, ignored on receipt. A 24-bit reserved field. Sent as 0, ignored on receipt.
6.2.3. Discovery Nonce 6.3.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.
6.2.4. Relay Address 6.3.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.
6.3. AMT Request 6.4. AMT Request
A Request packet is sent to begin a 3-way handshake for sending an A Request packet is sent by a Gateway to a Relay to begin a 3-way
IGMP/MLD Membership/Listener Report or Leave/Done. It can be sent handshake for sending an IGMP/MLD Membership/Listener Report or
from a gateway to a relay, from a gateway to another gateway, or from Leave/Done.
a relay to a gateway.
It is sent from the originator's unique unicast address to the It is sent from the Gateway address to the Relay's unique unicast
respondents' unique unicast address. 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 from the source port used in Discovery
source port used in Discovery messages but does not have to be. The messages but does not have to be. The UDP source port must be
UDP destination port is the IANA reserved AMT port number. The UDP consistent across Request and Update messages (see also Section 7.2).
checksum MUST be valid in AMT control messages.
The UDP destination port is the IANA reserved AMT port number.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x3 | Reserved | | Type=0x3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AMT Relay Advertisement AMT Request
6.3.1. Type 6.4.1. Type
The type of the message. The type of the message.
6.3.2. Reserved 6.4.2. Reserved
A 24-bit reserved field. Sent as 0, ignored on receipt. A 24-bit reserved field. Sent as 0, ignored on receipt.
6.3.3. Request Nonce 6.4.3. Request Nonce
A 32-bit identifier used to distinguish this request. A 32-bit identifier used to distinguish this request.
6.4. AMT Membership Query 6.5. AMT Membership Query
An AMT Membership Query packet is sent from the respondent back to An AMT Membership Query packet is sent from the Relay back to the
the originator to solicit an AMT Membership Update while confirming Gateway to solicit an AMT Membership Update while confirming the
the source of the original request. It contains a relay Message 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 which is the same address the source address of the Request, i.e. the Relay Address advertised
used in the Relay Advertisement. in the Relay Advertisement 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 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 | Flags | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response MAC (continued) | | Response MAC (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGMP Membership Query or MLD Listener Query | | IGMP Membership Query or MLD Listener Query |
| (including IP Header) | | (including IP Header) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Port Number | Gateway Address ... | ?
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?
| ... Gateway Address (ctd) ... | ?
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?
| ... Gateway Address (ctd) ... | ?
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?
| ... Gateway Address (ctd) ... | ?
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?
| ... Gateway Address (ctd) | ?
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AMT Membership Query AMT Membership Query
6.4.1. Type 6.5.1. Type
The type of the message. The type of the message.
6.4.2. Reserved 6.5.2. Flags
A 8-bit reserved field. Sent as 0, ignored on receipt. An 8-bit flags field having the following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |G|
+-+-+-+-+-+-+-+-+
6.4.3. Response MAC The "G" flag is set to 1 if Gateway information fields are present in
the Query message (see below Section 6.5.6), and to zero if they are
not.
A 48-bit hash generated by the respondent and sent to the originator Other flags are currently unused and reserved: they are sent as zero
for inclusion in the AMT Membership Update. The algorithm used for and their value is ignored on receipt.
this is chosen by the respondent but an algorithm such as HMAC-MD5-48
[RFC2104] SHOULD be used at a minimum.
6.4.4. Request Nonce 6.5.3. Response MAC
A 32-bit identifier used to distinguish this request echoed back to A 48-bit hash generated by the Relay and sent to the Gateway for
the originator. inclusion in the AMT Membership Update (see Section 5.2).
6.4.5. IGMP/MLD Query (including IP Header) 6.5.4. Request Nonce
A 32-bit identifier echoed back to the originator to used to identify
the corresponding request (see Section 5.2).
6.5.5. IGMP/MLD Query (including IP Header)
The message contains either an IGMP Query or an MLD Multicast The message contains either an IGMP Query or an MLD Multicast
Listener Query. The IGMP or MLD version sent should default to Listener Query. The IGMP or MLD version sent should default to
IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1. IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1.
The IGMP/MLD Query includes a full IP Header. The IP source address The IGMP/MLD Query includes a full IP Header. The IP source address
of the query would match the anycast address on the pseudo interface. of the query would match the anycast address on the pseudo interface.
The TTL of the outer header should be sufficient to reach the tunnel The TTL of the outer IP header should be sufficient to reach the
endpoint and not mimic the inner header TTL which is typically 1 for tunnel endpoint and not mimic the inner IP header TTL which is
IGMP/MLD messages. typically 1 for IGMP/MLD messages.
6.5. AMT Membership Update 6.5.6. Gateway information fields
The "Gateway Port Number" and "Gateway Address" fields are present in
the Query message if, and only if, the "G" flag is set in the Flags
field.
6.5.6.1. Gateway Port Number
A 16-bit field containing a UDP port value.
The Relay sets this field to the value of the UDP source port of the
Request message that triggered the Query message.
6.5.6.2. Gateway Address
A 16-byte field containing the IP source address of the Request
message that triggered this Query message. The field contains an
IPv4-compatible IPv6 address ([RFC4291], section 2.5.5.1) if the
address is an IPv4 address (i.e. the IPv4 address prefixed with 96
bits set to zero), or an IPv6 address.
6.6. AMT Membership Update
An AMT Membership Update is sent to report a membership after a valid An AMT Membership Update is sent to report a membership after a valid
Response MAC has been received. It contains the original IGMP/MLD Response MAC has been received. It contains the original IGMP/MLD
Membership/Listener Report or Leave/Done received over the AMT Membership/Listener Report or Leave/Done received over the AMT
pseudo-interface including the original IP header. It echoes the pseudo-interface including the original IP header. It echoes the
Response MAC received in the AMT Membership Query so the respondent Response MAC received in the AMT Membership Query so the respondent
can verify return routability to the originator. can verify return routability to the originator.
It is sent from the destination address received in the Query to the It is sent from the destination address received in the Query to the
source address received in the Query which should both be the same as source address received in the Query which should both be the same as
the original Request. the original Request.
The UDP source and destination port numbers should be the same ones The UDP source and destination port numbers should be the same ones
sent in the original Request. sent in the original Request.
The relay is not required to use the IP source address of the IGMP The UDP destination port is the IANA reserved AMT port number and the
UDP source port is the source port used for the Request message.
The Relay is not required to use the IP source address of the IGMP
Membership Report for any particular purpose. Membership Report for any particular purpose.
The same Request Nonce and Response MAC can be used across multiple The same Request Nonce and Response MAC can be used across multiple
AMT Membership Update messages without having to send individual AMT AMT Membership Update messages without having to send individual AMT
Membership Query messages. Membership Query messages.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x5 | Reserved | Response MAC | | Type=0x5 | Reserved | Response MAC |
skipping to change at page 21, line 44 skipping to change at page 20, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGMP or MLD Message (including IP header) | | IGMP or MLD Message (including IP header) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AMT Membership Update AMT Membership Update
6.5.1. Type 6.6.1. Type
The type of the message. The type of the message.
6.5.2. Reserved 6.6.2. Reserved
A 8-bit reserved field. Sent as 0, ignored on receipt. A 8-bit reserved field. Sent as 0, ignored on receipt.
6.5.3. Response MAC 6.6.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 (see Section 5.2).
6.5.4. Request Nonce 6.6.4. Request Nonce
A 32-bit identifier used to distinguish this request. A 32-bit identifier matching the nonce in the AMT Request (see
Section 5.2).
6.5.5. IGMP/MLD Message (including IP Header) 6.6.5. IGMP/MLD Message (including IP Header)
The message contains either an IGMP Membership Report, an IGMP The message contains either an IGMP Membership Report, an IGMP
Membership Leave, an MLD Multicast Listener Report, or an MLD Membership Leave, an MLD Multicast Listener Report, or an MLD
Listener Done. The IGMP or MLD version sent should be in response Listener Done. The IGMP or MLD version sent should be in function of
the version of the query received in the AMT Membership Query. The the version of the query received in the AMT Membership Query. The
IGMP/MLD Message includes a full IP Header. IGMP/MLD Message includes a full IP Header.
6.6. AMT IP Multicast Data 6.7. AMT IP Multicast Data
The AMT Data message is a UDP packet encapsulating the IP Multicast The AMT Data message is a UDP packet encapsulating the IP Multicast
data requested by the originator based on a previous AMT Membership data requested by the originator based on a previous AMT Membership
Update message. Update message.
It is sent from the unicast destination address of the Membership It is sent from the Relay's unique unicast address (destination
update to the source address of the Membership Update. address of the Membership update) to the Gateway's unicast address
(source address of the Membership Update).
The UDP source and destination port numbers should be the same ones The UDP source port is the IANA reserved AMT port number and the
sent in the original Query. The UDP checksum MUST be valid in AMT destination port should be the same as the source port of the
control messages. Membership Update that resulted in the creation of forwarding state
for the encapsulated IP packet.
The UDP checksum SHOULD be zero for AMT IP Multicast Data messages
carried over IPv4, and MAY be zero for AMT IP Multicast Data messages
carried over IPv6 [I-D.ietf-6man-udpchecksums].
The payload of the UDP packet contains the following fields. The payload of the UDP packet contains the following fields.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x6 | Reserved | IP Multicast Data ... | | Type=0x6 | Reserved | IP Multicast Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AMT IP Multicast Data AMT IP Multicast Data
6.6.1. Type 6.7.1. Type
The type of the message. The type of the message.
6.6.2. Reserved 6.7.2. Reserved
An 8-bit reserved field. Sent as 0, ignored on receipt. An 8-bit reserved field. Sent as 0, ignored on receipt.
6.6.3. IP Multicast Data 6.7.3. IP Multicast Data
The original IP Multicast data packet that is being replicated by the The original IP Multicast data packet that is being replicated by the
relay to the gateways including the original IP header. Relay to the Gateway, including the original IP header.
6.7. AMT Membership Teardown
An AMT Membership Teardown is sent to report an IGMP Membership Leave
or MLD Listener Done after a valid Response MAC has been received and
after the source address that was used to generate the Response MAC
is no longer available for sourcing packets.
An AMT Membership Teardown from the original source address and
source port is NOT valid and should be discarded if received. Use an
AMT Membership Update instead.
An AMT Membership Teardown can only contain either an IGMP Membership 6.8. AMT Teardown
Leave or an MLD Listener Done message. The encapsulated IGMP/MLD
message will have to be fabricated by the sender of the AMT
Membership Teardown in the case where there wasn't an original IGMP/
MLD message to be forwarded.
In order for the receiver to verify the Membership Teardown message, An AMT Teardown is sent by a Gateway after a valid Response MAC has
it must contain the original source address and source port in been received and after the source address that was used to generate
addition to the Original Request Nonce and Original Response MAC. the Response MAC is no longer available for sending packets.
It is sent to the source address received in the original Query which It is sent to the source address received in the original Query which
should be the same as the original Request. should be the same as the original Request.
The UDP destination port number should be the same one sent in the The UDP destination port number should be the same one sent in the
original Request. original Request.
The relay is not required to use the IP source address of the IGMP An AMT Teardown from the original source address and source port is
Membership Report for any particular purpose. NOT valid and should be discarded if received. Use an AMT Membership
Update instead.
In order for the Relay to verify the Teardown message, this message
must contain the original source address and source port in addition
to the Original Request Nonce and Original Response MAC. In
situations where NAT is used, this information can be known by the
Gateway thanks to the optional Gateway information fields in the
Query message (Section 6.5.6). Hence, a Relay supporting the
Teardown mechanism SHOULD include the Gateway information fields in
the Query messages it sends.
On reception of a valid Teardown message, a Relay should remove all
state corresponding to the gateway identified by the (original source
address, original source port) tuple, and stop forwarding all traffic
to this destination.
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=0x7 | Reserved | Original Response MAC | | Type=0x7 | Reserved | Original Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Response MAC (continued) | | Original Response MAC (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Request Nonce | | Original Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Source Port | Source AFI | | Original Source Port | Original Source Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Source Address | | Original Source Address (ctd) ... |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGMP Membership Leave or | | ... Original Source Address (ctd) ... |
| MLD Listener Done (including IP header) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... Original Source Address (ctd) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Original Src Addr. (ctd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AMT Membership Teardown AMT Membership Teardown
6.7.1. Type 6.8.1. Type
The type of the message. The type of the message.
6.7.2. Reserved 6.8.2. Reserved
A 8-bit reserved field. Sent as 0, ignored on receipt. A 8-bit reserved field. Sent as 0, ignored on receipt.
6.7.3. Original Response MAC 6.8.3. Original Response MAC
The 48-bit MAC received in the Membership Query and echoed back in
the Membership Update.
6.7.4. Original Request Nonce
A 32-bit identifier used to distinguish this request.
6.7.5. Original Source Port
The 16-bit port number used in the original AMT Membership update
that was used to generate the Original Response MAC.
6.7.6. Source AFI The 48-bit MAC received in the Membership Query.
A 16-bit Address Family Identifier (AFI) [RFC4760] used to determine 6.8.4. Original Request Nonce
the protocol address family of the following Original Source Address.
Presently defined values for the Address Family Identifier field are A 32-bit identifier corresponding to the original Request.
specified in IANA's Address Family Numbers registry [IANA.AFN]
6.7.7. Original Source Address 6.8.5. Original Source Port
The source address used in the original AMT Membership update that The 16-bit port number used in the original AMT Request message that
was used to generate the Original Response MAC. was used to generate the Original Response MAC.
6.7.8. IGMP/MLD Message (including IP Header) 6.8.6. Original Source Address
The message contains either an IGMP Membership Leave or an MLD A 16-byte field containing the IP source address used in the original
Listener Done. The IGMP or MLD version sent should be in response AMT Request message that was used to generate the Original Response
the version of the query received in the original AMT Membership MAC of the Request message that triggered this Query message. The
Query. The IGMP/MLD Message includes a full IP Header. field contains an IPv4-compatible IPv6 address ([RFC4291], section
2.5.5.1) if the address is an IPv4 address (i.e. the IPv4 address
prefixed with 96 bits set to zero), or an IPv6 address.
7. AMT Gateway Details 7. AMT Gateway Details
This section details the behavior of an AMT Gateway, which may be a This section details the behavior of an AMT Gateway, which may be a
router serving an AMT site, or the site may consist of a single host, router serving an AMT site, or the site may consist of a single host,
serving as its own gateway. serving as its own gateway.
7.1. At Startup Time 7.1. At Startup Time
At startup time, the AMT gateway will bring up an AMT pseudo- At startup time, the AMT gateway will bring up an AMT pseudo-
skipping to change at page 26, line 33 skipping to change at page 25, line 33
timer SHOULD use at least 10 percent jitter. timer SHOULD use at least 10 percent jitter.
If the gateway is serving as a local router, it SHOULD also function If the gateway is serving as a local router, it SHOULD also function
as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD
host-mode interface being the AMT pseudo-interface. This enables it host-mode interface being the AMT pseudo-interface. This enables it
to translate group memberships on its downstream interfaces into to translate group memberships on its downstream interfaces into
IGMP/MLD Reports. Hosts receiving multicast packets through an AMT IGMP/MLD Reports. Hosts receiving multicast packets through an AMT
gateway acting as a proxy should ensure that their M-RIB accepts gateway acting as a proxy should ensure that their M-RIB accepts
multicast packets from the AMT gateway for the sources it is joining. multicast packets from the AMT gateway for the sources it is joining.
7.2. Gateway Group and Source Addresses 7.2. Gateway identification
To support sourcing traffic to SSM groups by a gateway with a global
unicast address, the AMT Subnet Anycast Prefix is treated as the
subnet prefix of the AMT pseudo-interface, and an anycast address is
added on the interface. This anycast address is formed by
concatenating the AMT Subnet Anycast Prefix followed by the high bits
of the gateway's global unicast address.
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|
+-------------------------+-------------------------+
IPv4 format
This allows for 2^8 (256) IPv4 group addresses for use by each AMT
gateway.
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: From the point of view of a Relay, a Gateway is identified by the (IP
+-------------------------+-------------------------+ source address, UDP source port) tuple in Membership Update messages.
|64-bit AMT unicast prefix| high 64 bits of real src| If an implementation of Gateway procedure was to use a different UDP
+-------------------------+-------------------------+ source port and/or IP source address to join or leave different
multicast groups, it would appear to the Relay as distinct Gateways.
IPv6 format For instance, a Relay having forwarding state resulting in the
forwarding of (S,G) to a said gateway identified by a (IP source
address, UDP source port) tuple, will not remove this state if it
receives an AMT Membership Update message from a different (IP source
address, UDP source port) tuple.
This allows for 2^32 (over 4 billion) IPv6 group addresses for use by It results that a Gateway has to use the same UDP source port for AMT
each AMT gateway. Request and AMT Update messages related to a same (S,G). A said
Gateway instance is typically expected to use the same UDP source
port and IP source address for all Request and Updates messages for
all multicast groups.
7.3. Joining Groups with MBone Sources 7.3. Joining Multicast Groups
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 29, line 5 skipping to change at page 27, line 5
Reports that are sent by the host joining the group. Reports that are sent by the host joining the group.
7.4. Responding to Relay Changes 7.4. Responding to Relay Changes
When a gateway determines that its current relay is unreachable When a gateway determines that its current relay is unreachable
(e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the (e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the
relay's unicast address), it may need to repeat relay address relay's unicast address), it may need to repeat relay address
discovery. However, care should be taken not to abandon the current discovery. However, care should be taken not to abandon the current
relay too quickly due to transient network conditions. relay too quickly due to transient network conditions.
7.5. Joining SSM Groups with AMT Gateway Sources 8. AMT Relay Details
An IGMPv3/MLDv2 Report for a given (source, group) pair MAY be
encapsulated directly to the source, when the source address belongs
to the AMT Subnet Anycast Prefix.
The "link-layer" address to use as the destination 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
Anycast Address with the high bits of the address, and the remaining
bits will be in the middle of the group address.
Section 7.2 describes this format to recover the gateway source
address.
7.6. Receiving AMT Membership Updates by the Gateway
When an AMT Request is received by the gateway from another gateway
or relay, it follows the same 3-way handshake procedure a relay would
follow if it received the AMT Request. It generates a MAC and
responds with an AMT Membership Query. When the AMT Membership
Update is received, it verifies the MAC and then processes the IGMP/
MLD Membership/Listener Report or Leave/Done.
At the gateway, the IGMP/MLD packet should be an IGMPv3/MLDv2 source
specific (S,G) join or leave.
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
address (as described above), the packet is also silently discarded.
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
membership list may be done in any implementation-dependent manner.
For example, it might be maintained by the "link-layer" inside the
AMT pseudo-interface, making it invisible to the normal IGMP/MLD
module.
7.7. Sending data to SSM groups
When multicast packets are sent on the AMT pseudo-interface, they are
encapsulated as follows. If the group address is not an SSM group,
then the packet is silently discarded (this memo does not currently
provide a way to send to non-SSM groups).
If the group address is an SSM group, then the packet is unicast
encapsulated to each remote node from which the gateway has received
an IGMPv3/MLDv2 report for the packet's (source, group) pair.
8. Relay Router Details
8.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. 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
Subnet Anycast Prefix is assigned to the AMT pseudo-interface, and
the AMT Subnet Anycast Prefix is injected by the AMT Relay into the
M-RIB of MBGP.
8.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.
8.3. Receiving Membership Updates from AMT Gateways 8.3. Receiving Membership Updates from AMT Gateways
The relay operates passively, sending no periodic IGMP/MLD Queries The relay operates passively, sending no periodic IGMP/MLD Queries
but simply tracking membership information according to AMT Request/ but simply tracking membership information according to AMT Request/
Query/Membership Update tuples received. In addition, the relay must Query/Membership Update tuples received. As noted in Section 7.2,
also do explicit membership tracking, as to which gateways on the AMT the Relay tracks Gateways based on the (IP source address, UDP source
pseudo-interface have joined which groups. Once an AMT Membership port) tuple. In addition, the relay must also do explicit membership
Update has been successfully received, it updates the forwarding tracking, as to which gateways on the AMT pseudo-interface have
state for the appropriate group and source (if provided). When data joined which groups. Once an AMT Membership Update has been
arrives for that group, the traffic must be encapsulated to each successfully received, it updates the forwarding state for the
gateway which has joined that group or (S,G). appropriate group and source (if provided). When data arrives for
that group, the traffic must be encapsulated, once to each (address,
port) of each 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
skipping to change at page 31, line 23 skipping to change at page 29, line 5
If a relay wants to affect the rate at which the AMT Requests are If a relay wants to affect the rate at which the AMT Requests are
originated from a gateway, it can tune the membership timeout by originated from a gateway, it can tune the membership timeout by
adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/ adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/
MLD Query contained within the AMT Membership Query message. The MLD Query contained within the AMT Membership Query message. The
QQIC field is defined in [RFC3376] and [RFC3810]. However, since the QQIC field is defined in [RFC3376] and [RFC3810]. However, since the
gateway may need to send AMT Requests frequently enough to prevent gateway may need to send AMT Requests frequently enough to prevent
firewall state from timing out, the relay may be limited in its firewall state from timing out, the relay may be limited in its
ability to spread out Requests coming from a gateway by adjusting the ability to spread out Requests coming from a gateway by adjusting the
QQIC field. QQIC field.
8.4. Receiving (S,G) Joins from the Native Side, for AMT Sources
The relay sends an IGMPv3/MLDv2 report to the AMT source as described
above in Section 5.1.2
9. IANA Considerations 9. IANA Considerations
9.1. IPv4 and IPv6 Anycast Prefix Allocation 9.1. IPv4 and IPv6 Anycast Prefix Allocation
The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated
to the public AMT Relays to advertise to the native multicast to the public AMT Relays to advertise to the native multicast
backbone. The prefix length should be determined by the IANA; the backbone. The prefix length should be determined by the IANA; the
prefix should be large enough to guarantee advertisement in the prefix should be large enough to guarantee advertisement in the
default-free BGP networks. default-free BGP networks.
9.1.1. IPv4 9.1.1. IPv4
A prefix length of 16 will meet this requirement. A prefix length of 16 will meet this requirement.
9.1.2. IPv6 9.1.2. IPv6
A prefix length of 32 will meet this requirement. IANA has A prefix length of 32 will meet this requirement. IANA has
previously set aside the range 2001::/16 for allocating prefixes for previously set aside the range 2001::/16 for allocating prefixes for
this purpose. this purpose.
9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation 9.2. UDP Port number
It should also be noted that this prefix length directly affects the
number of groups available to be created by the AMT gateway: in the
IPv4 case, a prefix length of 16 gives 256 groups, and a prefix
length of 8 gives 65536 groups.
All allocations are a one time effort and there will be no need for
any recurring assignment after this stage.
9.2.1. IPv4
As described above in Section 7.2.1 an IPv4 prefix with a length of
16 is requested for this purpose.
9.2.2. IPv6
As described above in Section 7.2.2 an IPv6 prefix with a length of
32 is requested.
9.3. UDP Port number
IANA has previously allocated UDP reserved port number 2268 for AMT IANA has previously allocated UDP reserved port number 2268 for AMT
encapsulation. encapsulation.
10. Security Considerations 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 Gateways will accept and decapsulate multicast traffic from any
router or a rogue AS could inject a false route to the AMT Subnet source from which regular unicast traffic is accepted. If this is,
Anycast Prefix, and thus divert joins and cause RPF failures of for any reason, felt to be a security risk, then additional source
multicast traffic. As the AMT Subnet Anycast Prefix will be address based packet filtering MUST be applied: a gateway MUST
advertised by multiple entities, guaranteeing the integrity of this discard encapsulated multicast packets if the source address in the
shared MBGP prefix is much more challenging than verifying the outer header is not the address of the Relay to which the
correctness of a regular unicast advertisement. To mitigate this encapsulated join message was sent. AMT Gateways MUST also drop non-
threat, routing operators should configure the BGP sessions to filter multicast traffic incoming on an AMT pseudo-interface.
out any more specific advertisements for the AMT Subnet Anycast
Prefix.
Gateways and relays will accept and decapsulate multicast traffic AMT Relays MUST NOT process AMT Data messages.
from any source from which regular unicast traffic is accepted. If
this is for any reason felt to be a security risk, then additional
source address based packet filtering MUST be applied:
1. To prevent a rogue sender (that can't do traditional spoofing AMT Relays and Gateways MUST drop IP messages encapsulated in AMT
because of e.g. access lists deployed by its ISP) from making use Query and Update messages that are not IGMP/MLD messages.
of AMT to send packets to an SSM tree, a relay that receives an
encapsulated multicast packet MUST discard the multicast packet
if the IP source address in the outer header does not match the
source address that would be extracted using the rules of
Section 7.2.
2. A gateway MUST discard encapsulated multicast packets if the Even though a Relay does not need to maintain any state before
source address in the outer header is not the address to which completion of the three-way handshake (Section 5.2), if no mitigation
the encapsulated join message was sent. An AMT Gateway that is in place, it is still possible for one host to instantiate a large
receives an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the amount of Gateways instances that would each join one or more
message if the IP destination address in the outer header does multicast groups to a Relay, thus resulting in a large amount of
not match the source address that would be extracted using the resources being used on the Relay. Thus, AMT Relays MUST be
rules of Section 7.2. implemented so as to allow the mitigation of risks of denial of
service attacks on their resources. A Relay SHOULD NOT allow the
instantiation of an unbounded number of AMT pseudo-interfaces for a
said gateway IP address. For instance, an implementation may provide
a way to set a configurable limit on the maximum number of pseudo-
interfaces to a same gateway IP address, with a default value for
this limit being low enough to provide protection, and high enough to
cope with the possibility of an address being shared by multiple
devices.
In the case where a Relay is reaching the situation where it would
stop accepting to instantiate new pseudo-interfaces, it MAY stop
advertising the AMT Relay Anycast address; thanks to the AMT
discovery procedures, this will allow legitimate AMT Gateways to fall
back on another Relay.
11. 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 these specifications:
Dirk Ooms Dirk Ooms
OneSparrow OneSparrow
Belegstraat 13; 2018 Antwerp; Belgium Belegstraat 13; 2018 Antwerp; Belgium
EMail: dirk@onesparrow.com EMail: dirk@onesparrow.com
12. 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.
In addition, extensive comments were received from Pekka Savola, Greg In addition, extensive comments were received from Pekka Savola, Greg
Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John
Zwiebel, and Lenny Giuliano. Zwiebel, Lenny Giuliano and Greg Bumgardner.
Juniper Networks was instrumental in funding several versions of this Juniper Networks was instrumental in funding several versions of this
draft as well as an open source implementation. draft as well as an open source implementation.
Greg Shepherd suggested the inclusion of the AMT Membership Teardown Greg Shepherd suggested the inclusion of the AMT Membership Teardown
message based on field experience. message based on field experience.
Contributors from AT&T provided useful inputs and ideas that were
integrated into these specifications: Mark Altom, Andy Huang, Tom
Imburgia, Patricia McCrink, Han Nguyen, Doug Nortz and Robert Sayko.
13. References 13. References
13.1. Normative References 13.1. Normative References
[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.
skipping to change at page 36, line 27 skipping to change at page 33, line 27
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006. ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
13.2. Informative References [I-D.ietf-6man-udpchecksums]
Eubanks, M., "UDP Checksums for Tunneled Packets",
draft-ietf-6man-udpchecksums-00 (work in progress),
March 2011.
[IANA.AFN] [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
IANA, "Address Family Numbers", <http://www.iana.org/ Architecture", RFC 4291, February 2006.
assignments/address-family-numbers/
address-family-numbers.txt>. 13.2. Informative References
[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 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993. Anycasting Service", RFC 1546, November 1993.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
skipping to change at page 37, line 8 skipping to change at page 34, line 11
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001. Tunnel Broker", RFC 3053, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001. RFC 3068, June 2001.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. January 2007.
Authors' Addresses Authors' Addresses
skipping to change at line 1504 skipping to change at page 36, line 11
USA USA
Email: vicisano@qualcomm.com Email: vicisano@qualcomm.com
Tom Pusateri Tom Pusateri
!j !j
2109 Mountain High Rd. 2109 Mountain High Rd.
Wake Forest, NC 27587 Wake Forest, NC 27587
USA USA
Email: pusateri@bangj.com Email: pusateri@bangj.com
Thomas Morin
France Telecom - Orange
2, avenue Pierre Marzin
Lannion 22300
France
Phone: +33 2 96 05 3734
Email: thomas.morin@orange-ftgroup.com
 End of changes. 132 change blocks. 
621 lines changed or deleted 415 lines changed or added

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