draft-ietf-mboned-auto-multicast-09.txt   draft-ietf-mboned-auto-multicast-10.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: December 29, 2008 Microsoft Corporation Expires: September 8, 2010 Microsoft Corporation
L. Vicisano L. Vicisano
Cisco Systems Qualcomm Inc.
T. Pusateri T. Pusateri
!j !j
June 27, 2008 March 7, 2010
Automatic IP Multicast Without Explicit Tunnels (AMT) Automatic IP Multicast Without Explicit Tunnels (AMT)
draft-ietf-mboned-auto-multicast-09 draft-ietf-mboned-auto-multicast-10
Abstract
Automatic Multicast Tunneling (AMT) allows multicast communication
amongst isolated multicast-enabled sites or hosts, attached to a
network which has no native multicast support. It also enables them
to exchange multicast traffic with the native multicast
infrastructure and does not require any manual configuration. AMT
uses an encapsulation interface so that no changes to a host stack or
applications are required, all protocols (not just UDP) are handled,
and there is no additional overhead in core routers.
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six 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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 29, 2008. This Internet-Draft will expire on September 8, 2010.
Abstract Copyright Notice
Automatic Multicast Tunneling (AMT) allows multicast communication Copyright (c) 2010 IETF Trust and the persons identified as the
amongst isolated multicast-enabled sites or hosts, attached to a document authors. All rights reserved.
network which has no native multicast support. It also enables them
to exchange multicast traffic with the native multicast This document is subject to BCP 78 and the IETF Trust's Legal
infrastructure and does not require any manual configuration. AMT Provisions Relating to IETF Documents
uses an encapsulation interface so that no changes to a host stack or (http://trustee.ietf.org/license-info) in effect on the date of
applications are required, all protocols (not just UDP) are handled, publication of this document. Please review these documents
and there is no additional overhead in core routers. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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
skipping to change at page 3, line 21 skipping to change at page 4, line 9
6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 21 6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 21
6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22 6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22
6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 22 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 22
6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 22 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 22
6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 22 6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 22
6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 22 6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 22
6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23
6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 23 6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 23
7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 24 6.7. AMT Membership Teardown . . . . . . . . . . . . . . . . . 23
7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 24 6.7.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 24 6.7.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 24
7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.7.3. Original Response MAC . . . . . . . . . . . . . . . . 24
7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.7.4. Original Request Nonce . . . . . . . . . . . . . . . . 24
7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 26 6.7.5. Original Source Port . . . . . . . . . . . . . . . . . 24
7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 26 6.7.6. Source AFI . . . . . . . . . . . . . . . . . . . . . . 24
7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 27 6.7.7. Original Source Address . . . . . . . . . . . . . . . 25
7.6. Receiving AMT Membership Updates by the Gateway . . . . . 27 6.7.8. IGMP/MLD Message (including IP Header) . . . . . . . . 25
7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 27 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 26
8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 28 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 26
8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 28 7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 26
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 . . . . . . . . . . . . . . . . . . . . . . . . . 28 Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.3. Receiving Membership Updates from AMT Gateways . . . . . . 28 8.3. Receiving Membership Updates from AMT Gateways . . . . . . 30
8.4. Receiving (S,G) Joins from the Native Side, for AMT 8.4. Receiving (S,G) Joins from the Native Side, for AMT
Sources . . . . . . . . . . . . . . . . . . . . . . . . . 29 Sources . . . . . . . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 30 9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 32
9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation . . . . . . . . 30 9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation . . . . . . . . 32
9.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.3. UDP Port number . . . . . . . . . . . . . . . . . . . . . 30 9.3. UDP Port number . . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . . 36
13.2. Informative References . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 38
1. Introduction 1. Introduction
The primary goal of this document is to foster the deployment of The primary goal of this document is to foster the deployment of
native IP multicast by enabling a potentially large number of nodes native IP multicast by enabling a potentially large number of nodes
to connect to the already present multicast infrastructure. to connect to the already present multicast infrastructure.
Therefore, the techniques discussed here should be viewed as an Therefore, the techniques discussed here should be viewed as an
interim solution to help in the various stages of the transition to a interim solution to help in the various stages of the transition to a
native multicast network. native multicast network.
skipping to change at page 12, line 29 skipping to change at page 12, line 29
MAC matches the calculated MAC. MAC matches the calculated MAC.
The local secret never has to be shared with the other side. It is The local secret never has to be shared with the other side. It is
only used to verify return routability of the originator. only used to verify return routability of the originator.
Since the same Request Nonce and source IP address can be re-used, 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 receiver 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
sent the AMT Request dynamically changes its IP address. This might
occur due to a change in wireless networks, a DHCP assignment, or
another network failure. When this occurs, it is no longer possible
to verify the MAC using the source address and source port. Though,
in order to reduce state, it is desirable to tear down the state that
was created with the old source address. A Teardown message with
special considerations for calculating the MAC is described below to
perform this function.
5.1.3. Protocol Sequence for a Gateway Joining SSM Receivers to a Relay 5.1.3. Protocol Sequence for a Gateway Joining SSM Receivers to a Relay
This description assumes the Gateway can be a host joining as a This description assumes the Gateway can be a host joining as a
receiver or a network device acting as a Gateway when a directly receiver or a network device acting as a Gateway when a directly
connected host joins as a receiver. connected host joins as a receiver.
o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1). o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1).
o Gateway receives report. 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
skipping to change at page 17, line 49 skipping to change at page 17, line 49
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.2. AMT Relay Advertisement
The AMT Relay Advertisement message is a UDP packet sent from the AMT The AMT Relay Advertisement message is a UDP packet sent from the AMT
relay anycast address to the source of the discovery message. relay anycast address to the source of the discovery message.
The UDP source port is the IANA reserved AMT port number and the UDP The UDP source port is the IANA reserved AMT port number and the UDP
destination port is the source port received in the Discovery destination port is the source port received in the Discovery
message. The UDP checksum MUST be valid in AMT control messages. message. The UDP CHECKSUM MUST be valid in AMT control messages.
The payload of the UDP packet contains the following fields. The payload of the UDP packet contains the following fields.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x2 | Reserved | | Type=0x2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce | | Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 36 skipping to change at page 22, line 36
6.6. AMT IP Multicast Data 6.6. 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 unicast destination address of the Membership
update to the source address of the Membership Update. update to the source address of the Membership Update.
The UDP source and destination port numbers should be the same ones The UDP source and destination port numbers should be the same ones
sent in the original Query. The UDP checksum SHOULD be 0 in the AMT sent in the original Query. The UDP checksum MUST be valid in AMT
IP Multicast Data message. control messages.
The payload of the UDP packet contains the following fields. The payload of the UDP packet contains the following fields.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x6 | Reserved | IP Multicast Data ... | | Type=0x6 | Reserved | IP Multicast Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 5 skipping to change at page 23, line 18
6.6.2. Reserved 6.6.2. Reserved
An 8-bit reserved field. Sent as 0, ignored on receipt. An 8-bit reserved field. Sent as 0, ignored on receipt.
6.6.3. IP Multicast Data 6.6.3. IP Multicast Data
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 gateways 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
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,
it must contain the original source address and source port in
addition to the Original Request Nonce and Original Response MAC.
It is sent to the source address received in the original Query which
should be the same as the original Request.
The UDP destination port number should be the same one sent in the
original Request.
The relay is not required to use the IP source address of the IGMP
Membership Report for any particular purpose.
0 1 2 3
0 1 2 3 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Response MAC (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Source Port | Source AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Source Address |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGMP Membership Leave or |
| MLD Listener Done (including IP header) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AMT Membership Teardown
6.7.1. Type
The type of the message.
6.7.2. Reserved
A 8-bit reserved field. Sent as 0, ignored on receipt.
6.7.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
A 16-bit Address Family Identifier (AFI) [RFC4760] used to determine
the protocol address family of the following Original Source Address.
Presently defined values for the Address Family Identifier field are
specified in IANA's Address Family Numbers registry [IANA.AFN]
6.7.7. Original Source Address
The source address used in the original AMT Membership update that
was used to generate the Original Response MAC.
6.7.8. IGMP/MLD Message (including IP Header)
The message contains either an IGMP Membership Leave or an MLD
Listener Done. The IGMP or MLD version sent should be in response
the version of the query received in the original AMT Membership
Query. The IGMP/MLD Message includes a full IP Header.
7. AMT Gateway Details 7. AMT Gateway Details
This section details the behavior of an AMT Gateway, which may be a This section details the behavior of an AMT Gateway, which may be a
router serving an AMT site, or the site may consist of a single host, router serving an AMT site, or the site may consist of a single host,
serving as its own gateway. serving as its own gateway.
7.1. At Startup Time 7.1. At Startup Time
At startup time, the AMT gateway will bring up an AMT pseudo- At startup time, the AMT gateway will bring up an AMT pseudo-
interface to be used for encapsulation. The gateway needs to interface to be used for encapsulation. The gateway needs to
skipping to change at page 34, line 5 skipping to change at page 35, line 19
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, and Lenny Giuliano.
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
message based on field experience.
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 34, line 29 skipping to change at page 36, line 29
[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 13.2. Informative References
[IANA.AFN]
IANA, "Address Family Numbers", <http://www.iana.org/
assignments/address-family-numbers/
address-family-numbers.txt>.
[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 36, line 5 skipping to change at page 37, line 15
[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 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. 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,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
Authors' Addresses Authors' Addresses
Dave Thaler Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
USA USA
Phone: +1 425 703 8835 Phone: +1 425 703 8835
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
skipping to change at page 36, line 35 skipping to change at page 38, line 35
Amit Aggarwal Amit Aggarwal
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
USA USA
Phone: +1 425 706 0593 Phone: +1 425 706 0593
Email: amitag@microsoft.com Email: amitag@microsoft.com
Lorenzo Vicisano Lorenzo Vicisano
Cisco Systems Qualcomm Inc.
170 West Tasman Dr. 3165 Kifer Road
San Jose, CA 95134 Santa Clara, CA 95051
USA USA
Phone: +1 408 525 2530 Email: vicisano@qualcomm.com
Email: lorenzo@cisco.com
Tom Pusateri Tom Pusateri
!j !j
222 E. Jones Ave. 2109 Mountain High Rd.
Wake Forest, NC 27587 Wake Forest, NC 27587
USA USA
Email: pusateri@bangj.com Email: pusateri@bangj.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 22 change blocks. 
59 lines changed or deleted 205 lines changed or added

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