draft-ietf-mboned-auto-multicast-15.txt   draft-ietf-mboned-auto-multicast-16.txt 
Network Working Group G. Bumgardner Network Working Group G. Bumgardner
Internet-Draft Internet-Draft
Intended status: Standards Track July 15, 2013 Intended status: Standards Track October 21, 2013
Expires: January 16, 2014 Expires: April 24, 2014
Automatic Multicast Tunneling Automatic Multicast Tunneling
draft-ietf-mboned-auto-multicast-15 draft-ietf-mboned-auto-multicast-16
Abstract Abstract
This document describes Automatic Multicast Tunneling (AMT), a This document describes Automatic Multicast Tunneling (AMT), a
protocol for delivering multicast traffic from sources in a protocol for delivering multicast traffic from sources in a
multicast-enabled network to receivers that lack multicast multicast-enabled network to receivers that lack multicast
connectivity to the source network. The protocol uses UDP connectivity to the source network. The protocol uses UDP
encapsulation and unicast replication to provide this functionality. encapsulation and unicast replication to provide this functionality.
The AMT protocol is specifically designed to support rapid deployment The AMT protocol is specifically designed to support rapid deployment
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on January 16, 2014. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 3, line 20 skipping to change at page 3, line 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 72
6.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . . 73 6.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 74 6.2. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3. Encapsulated IP Packets . . . . . . . . . . . . . . . . . 75 6.3. Encapsulated IP Packets . . . . . . . . . . . . . . . . . 75
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
7.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 75 7.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 75
7.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 75 7.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 75
7.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 75 7.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses 75 7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses 75
7.3. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 75 7.3. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 75
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 75 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 76
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.1. Normative References . . . . . . . . . . . . . . . . . . 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 77
10.2. Informative References . . . . . . . . . . . . . . . . . 77 10.2. Informative References . . . . . . . . . . . . . . . . . 78
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 79 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 79
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 81
1. Introduction 1. Introduction
The advantages and benefits provided by multicast technologies are The advantages and benefits provided by multicast technologies are
well known. There are a number of application areas that are ideal well known. There are a number of application areas that are ideal
candidates for the use of multicast, including media broadcasting, candidates for the use of multicast, including media broadcasting,
video conferencing, collaboration, real-time data feeds, data video conferencing, collaboration, real-time data feeds, data
replication, and software updates. Unfortunately, many of these replication, and software updates. Unfortunately, many of these
skipping to change at page 12, line 34 skipping to change at page 12, line 34
Figure 5: AMT Relay Pseudo-Interface (Router-Based) Figure 5: AMT Relay Pseudo-Interface (Router-Based)
The pseudo-interface is conceptually a network interface on which the The pseudo-interface is conceptually a network interface on which the
relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2 relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2
protocols. Relays do not send unsolicited IGMPv3/MLDv2 query protocols. Relays do not send unsolicited IGMPv3/MLDv2 query
messages to gateways so relays must consume or discard any local messages to gateways so relays must consume or discard any local
queries normally generated by IGMPv3 or MLDv2. Note that the queries normally generated by IGMPv3 or MLDv2. Note that the
protocol mandates the use of IGMPv3 and MLDv2 for query messages. protocol mandates the use of IGMPv3 and MLDv2 for query messages.
The AMT protocol is primarily intended for use in SSM applications The AMT protocol is primarily intended for use in SSM applications
and relies on several values provided by IGMPv2/MLDv2 to control and relies on several values provided by IGMPv3/MLDv2 to control
gateway behavior. gateway behavior.
A relay maintains group membership state for each gateway connected A relay maintains group membership state for each gateway connected
through the pseudo-interface as well as for the entire pseudo- through the pseudo-interface as well as for the entire pseudo-
interface (if multiple gateways are managed via a single interface). interface (if multiple gateways are managed via a single interface).
Multicast packets received on upstream interfaces on the relay are Multicast packets received on upstream interfaces on the relay are
routed to the pseudo-interface where they are replicated, routed to the pseudo-interface where they are replicated,
encapsulated and sent to interested gateways. Changes in the pseudo- encapsulated and sent to interested gateways. Changes in the pseudo-
interface group membership state may trigger the transmission of interface group membership state may trigger the transmission of
multicast protocol requests upstream towards a given source or multicast protocol requests upstream towards a given source or
skipping to change at page 23, line 8 skipping to change at page 23, line 8
messages for each protocol (IPv4/IGMP and IPv6/MLD). messages for each protocol (IPv4/IGMP and IPv6/MLD).
4.2.1.3. Teardown Sequence 4.2.1.3. Teardown Sequence
A gateway sends a Teardown message to a relay to request that it stop A gateway sends a Teardown message to a relay to request that it stop
delivering Multicast Data messages to a tunnel endpoint created by an delivering Multicast Data messages to a tunnel endpoint created by an
earlier Membership Update message. This message is intended to be earlier Membership Update message. This message is intended to be
used following a gateway address change (See Section 4.2.2.1) to stop used following a gateway address change (See Section 4.2.2.1) to stop
the transmission of undeliverable or duplicate multicast data the transmission of undeliverable or duplicate multicast data
messages. Gateway support for the Teardown message is optional - messages. Gateway support for the Teardown message is optional -
gateways are not required to send them and may instead relay on group gateways are not required to send them and may instead rely on group
membership to expire on the relay. membership to expire on the relay.
Gateway Relay Gateway Relay
------- ----- ------- -----
: Request : : Request :
[1] | N | [1] | N |
|---------------------->| |---------------------->|
| Membership Query | [2] | Membership Query | [2]
| N,MAC,gADDR,gPORT | | N,MAC,gADDR,gPORT |
|<======================| |<======================|
skipping to change at page 63, line 18 skipping to change at page 63, line 18
A relay MUST set the Querier's Robustness Variable (QRV) field in the A relay MUST set the Querier's Robustness Variable (QRV) field in the
general query to a non-zero value. This value SHOULD be greater than general query to a non-zero value. This value SHOULD be greater than
one. If a gateway retransmits membership state change messages, it one. If a gateway retransmits membership state change messages, it
will retransmit them (robustness variable - 1) times. The QRV field will retransmit them (robustness variable - 1) times. The QRV field
is defined in Section 4.1.6 in [RFC3376] and Section 5.1.8 in is defined in Section 4.1.6 in [RFC3376] and Section 5.1.8 in
[RFC3810]. [RFC3810].
A relay SHOULD set the Maximum Response Code field in the general A relay SHOULD set the Maximum Response Code field in the general
query to a value of 1 to trigger an immediate response from the query to a value of 1 to trigger an immediate response from the
gateway (some host IGMP/MLD implementations may not accept a value of gateway (some host IGMP/MLD implementations may not accept a value of
zero). A relay SHOULD NOT use the IGMPv2/MLDv2 Query Response zero). A relay SHOULD NOT use the IGMPv3/MLDv2 Query Response
Interval variable, if available, to generate the Maximum Response Interval variable, if available, to generate the Maximum Response
Code field value as the Query Response Interval variable is used in Code field value as the Query Response Interval variable is used in
setting the duration of group state timers and must not be set to setting the duration of group state timers and must not be set to
such a small value. The Maximum Response Code field is defined in such a small value. The Maximum Response Code field is defined in
Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810]. See Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810]. See
Section 5.3.3.7. Section 5.3.3.7.
5.3.3.4. Handling a Membership Update Message 5.3.3.4. Handling a Membership Update Message
This section describes relay requirements related to the membership This section describes relay requirements related to the membership
skipping to change at page 68, line 24 skipping to change at page 68, line 24
receives a multicast datagram whose size is greater than the Tunnel receives a multicast datagram whose size is greater than the Tunnel
MTU of the tunnel or tunnels through which it must be delivered. MTU of the tunnel or tunnels through which it must be delivered.
5.3.3.6.2.1. IPv4 Multicast IP Datagrams 5.3.3.6.2.1. IPv4 Multicast IP Datagrams
If the DF bit in the multicast datagram header is set to 1 (Don't If the DF bit in the multicast datagram header is set to 1 (Don't
Fragment), the relay MUST discard the packet and, if the datagram Fragment), the relay MUST discard the packet and, if the datagram
originated from an SSM source, send an ICMPv4 [RFC0792] Destination originated from an SSM source, send an ICMPv4 [RFC0792] Destination
Unreachable message to the source, with type equal to 4 Unreachable message to the source, with type equal to 4
(fragmentation needed and DF set). The ICMP Destination Unreachable (fragmentation needed and DF set). The ICMP Destination Unreachable
message MUST contain an next-hop MTU (as specified by [RFC1191] and message MUST contain an next-hop MTU (as specified by [RFC1191]) and
[RFC1191]) and the relay MUST set the next-hop MTU to the TMTU the relay MUST set the next-hop MTU to the TMTU associated with the
associated with the tunnel or tunnels. If the DF bit in the tunnel or tunnels. If the DF bit in the multicast datagram header is
multicast datagram header is set to 0 (May Fragment), the relay MUST set to 0 (May Fragment), the relay MUST fragment the datagram and
fragment the datagram and encapsulate each fragment within Multicast encapsulate each fragment within Multicast Data messages for
Data messages for transmission through the tunnel or tunnels. This transmission through the tunnel or tunnels. This ensures that
ensures that gateways will receive complete, non-fragmented Multicast gateways will receive complete, non-fragmented Multicast Data
Data messages, containing fragmented multicast datagram payloads. messages, containing fragmented multicast datagram payloads. The
The relay SHOULD avoid generating a separate ICMP message for each relay SHOULD avoid generating a separate ICMP message for each
tunnel, but instead send a single ICMP message with a Next-hop MTU tunnel, but instead send a single ICMP message with a Next-hop MTU
equal to the smallest TMTU of all tunnels to which the datagram was equal to the smallest TMTU of all tunnels to which the datagram was
to be forwarded. to be forwarded.
5.3.3.6.2.2. IPv6 Multicast IP Datagrams 5.3.3.6.2.2. IPv6 Multicast IP Datagrams
The relay MUST discard the packet and, if the datagram originated The relay MUST discard the packet and, if the datagram originated
from an SSM source, send an ICMPv6 [RFC4443] Packet Too Big message from an SSM source, send an ICMPv6 [RFC4443] Packet Too Big message
to the payload source. The MTU specified in the Packet Too Big to the payload source. The MTU specified in the Packet Too Big
message MUST be equal to the TMTU associated with the tunnel or message MUST be equal to the TMTU associated with the tunnel or
skipping to change at page 69, line 46 skipping to change at page 69, line 46
message datagram containing an IPv6 fragment header. message datagram containing an IPv6 fragment header.
5.3.3.6.4. Handling Destination Unreachable Messages 5.3.3.6.4. Handling Destination Unreachable Messages
If a relay receives a sequence of ICMP or ICMPv6 messages of type If a relay receives a sequence of ICMP or ICMPv6 messages of type
"Destination Unreachable" in response to transmission of a sequence "Destination Unreachable" in response to transmission of a sequence
of AMT Multicast Data messages to a gateway, the relay SHOULD of AMT Multicast Data messages to a gateway, the relay SHOULD
discontinue sending messages to that gateway and shutdown the tunnel discontinue sending messages to that gateway and shutdown the tunnel
for that gateway (Handling of ICMP "Destination Unreachable" messages for that gateway (Handling of ICMP "Destination Unreachable" messages
with code 4, "fragmentation required" is covered in with code 4, "fragmentation required" is covered in
Section 5.3.3.6.1). If a relay provides this capability, it MUTST Section 5.3.3.6.1). If a relay provides this capability, it MUST
provide a configuration option that indicates what number of provide a configuration option that indicates what number of
sequential "Destination Unreachable" messages can be received and sequential "Destination Unreachable" messages can be received and
ignored before the relay will automatically shutdown a tunnel. ignored before the relay will automatically shutdown a tunnel.
5.3.3.7. State Timers 5.3.3.7. State Timers
A relay MUST maintain a timer or timers whose expiration will trigger A relay MUST maintain a timer or timers whose expiration will trigger
the removal of any group subscriptions and forwarding state the removal of any group subscriptions and forwarding state
previously created for a gateway endpoint should the gateway fail to previously created for a gateway endpoint should the gateway fail to
refresh the group membership state within a specified time interval. refresh the group membership state within a specified time interval.
skipping to change at page 71, line 37 skipping to change at page 71, line 37
required. required.
5.3.5. Response MAC Generation 5.3.5. Response MAC Generation
A Response MAC is produced by a hash digest computation. A Response A Response MAC is produced by a hash digest computation. A Response
MAC computation is required in the following situations: MAC computation is required in the following situations:
o To generate a Response MAC value from a Request message for o To generate a Response MAC value from a Request message for
inclusion in a Membership Query message. inclusion in a Membership Query message.
o Tp generate a Response MAC value from a Membership Update message o To generate a Response MAC value from a Membership Update message
for use in authenticating the Response MAC carried within that for use in authenticating the Response MAC carried within that
message. message.
o To generate a Response MAC value from a Teardown message to o To generate a Response MAC value from a Teardown message to
authenticate the Response MAC carried within that message. authenticate the Response MAC carried within that message.
Gateways treat the Response MAC field as an opaque value, so a relay Gateways treat the Response MAC field as an opaque value, so a relay
implementation may generate the MAC using any method available to it. implementation may generate the MAC using any method available to it.
The hash function RECOMMENDED for use in computing the Response MAC The hash function RECOMMENDED for use in computing the Response MAC
is the MD5 hash digest [RFC1321], though hash functions or keyed-hash is the MD5 hash digest [RFC1321], though hash functions or keyed-hash
skipping to change at page 74, line 8 skipping to change at page 74, line 8
specific administrative routing domains. This will isolate such specific administrative routing domains. This will isolate such
attacks to a single domain. attacks to a single domain.
The Path and Tunnel MTU adjustment (discovery) procedure described in The Path and Tunnel MTU adjustment (discovery) procedure described in
Section 5.3.3.6.1 is vulnerable to two denial of service attacks (see Section 5.3.3.6.1 is vulnerable to two denial of service attacks (see
Section 8 of [RFC1191] for details). Both attacks are based upon on Section 8 of [RFC1191] for details). Both attacks are based upon on
a malicious party sending forged ICMPv4 Destination Unreachable or a malicious party sending forged ICMPv4 Destination Unreachable or
ICMPv6 Packet Too Big messages to a host. In the first attack, the ICMPv6 Packet Too Big messages to a host. In the first attack, the
forged message indicates an inordinately small Path MTU. In the forged message indicates an inordinately small Path MTU. In the
second attack, the forged message indicates an inordinately large second attack, the forged message indicates an inordinately large
Path MTU. In both cases, throughput is adversely affected. On order Path MTU. In both cases, throughput is adversely affected. In order
to mitigate such attacks, relay implementations MUST include a to mitigate such attacks, relay implementations MUST include a
configuration option to disable Path MTU adjustments on AMT tunnels. configuration option to disable Path MTU adjustments on AMT tunnels.
6.2. Gateways 6.2. Gateways
A passive eavesdropper may launch a denial-of-service attack on a A passive eavesdropper may launch a denial-of-service attack on a
gateway by capturing a Membership Query or Membership Update message gateway by capturing a Membership Query or Membership Update message
and using the request nonce and message authentication code carried and using the request nonce and message authentication code carried
by the captured message to send a spoofed a Membership Update or by the captured message to send a spoofed a Membership Update or
Teardown message to the relay. The spoofed messages may be used to Teardown message to the relay. The spoofed messages may be used to
skipping to change at page 75, line 25 skipping to change at page 75, line 25
Properly implemented gateways and relays will also filter Properly implemented gateways and relays will also filter
encapsulated IP packets that appear corrupted or truncated by encapsulated IP packets that appear corrupted or truncated by
verifying packet length and checksums. verifying packet length and checksums.
7. IANA Considerations 7. IANA Considerations
7.1. IPv4 and IPv6 Anycast Prefix Allocation 7.1. IPv4 and IPv6 Anycast Prefix Allocation
The following unicast prefixes have been assigned to provide anycast The following unicast prefixes have been assigned to provide anycast
routing of relay discovery messages to public AMT Relays as as routing of relay discovery messages to public AMT Relays as described
described in Section 4.1.4. in Section 4.1.4.
7.1.1. IPv4 7.1.1. IPv4
IANA has assigned 154.7.0/24 for IPv4 relays. IANA has assigned 154.7.0/24 for IPv4 relays.
7.1.2. IPv6 7.1.2. IPv6
IANA has assigned 2001:0003::/32 for IPv6 relays. IANA has assigned 2001:0003::/32 for IPv6 relays.
7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses 7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses
IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses. IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses.
7.3. UDP Port Number 7.3. UDP Port Number
IANA has assigned UDP port number 2268 for AMT. The UDP port number 2268 has been reserved with IANA for use in the
implementation and deployment of AMT. The protocol described by this
document continues to use this port number according to the intent of
the original request. This port number should be assigned to AMT
upon acceptance of this I-D.
8. Contributors 8. Contributors
The following people provided significant contributions to the design The following people provided significant contributions to the design
of the protocol and earlier versions of this specification: of the protocol and earlier versions of this specification:
Amit Aggarwal
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
USA
Email: amitag@microsoft.com
Thomas Morin Thomas Morin
France Telecom - Orange Orange
2, avenue Pierre Marzin 2, avenue Pierre Marzin
Lannion 22300 Lannion 22300
France France
Email: thomas.morin@orange.com Email: thomas.morin@orange.com
Dirk Ooms Dirk Ooms
OneSparrow OneSparrow
Belegstraat 13; 2018 Antwerp; Robert Molsstraat 11; 2018 Antwerp
Belgium Belgium
EMail: dirk@onesparrow.com EMail: dirk@onesparrow.com
Tom Pusateri Tom Pusateri
!j !j
2109 Mountain High Rd. Wake Forest, NC
Wake Forest, NC 27587
USA USA
Email: pusateri@bangj.com Email: pusateri@bangj.com
Dave Thaler Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
USA USA
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
9. Acknowledgments 9. Acknowledgments
The authors would like to thank the following individuals for their The authors would like to thank the following individuals for their
suggestions, comments, and corrections: suggestions, comments, and corrections:
Amit Aggarwal
Mark Altom Mark Altom
Toerless Eckert Toerless Eckert
Marshall Eubanks Marshall Eubanks
Gorry Fairhurst Gorry Fairhurst
Dino Farinacci Dino Farinacci
Lenny Giuliano Lenny Giuliano
Andy Huang Andy Huang
Tom Imburgia Tom Imburgia
Patricia McCrink Patricia McCrink
Han Nguyen Han Nguyen
 End of changes. 19 change blocks. 
29 lines changed or deleted 38 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/