draft-ietf-mboned-auto-multicast-03.txt   draft-ietf-mboned-auto-multicast-04.txt 
Network Working Group Dave Thaler Network Working Group Dave Thaler
Internet-Draft Mohit Talwar Internet-Draft Mohit Talwar
October 2004 Amit Aggarwal February 2005 Amit Aggarwal
Expires: April 22, 2005 Microsoft Expires: August 21, 2005 Microsoft
Lorenzo Vicisano Lorenzo Vicisano
Cisco Cisco Systems
Dirk Ooms Tom Pusateri
OneSparrow Juniper Networks
Automatic IP Multicast Without Explicit Tunnels (AMT) Automatic IP Multicast Without Explicit Tunnels (AMT)
draft-ietf-mboned-auto-multicast-03.txt draft-ietf-mboned-auto-multicast-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668. aware will be disclosed, in accordance with Section 6 of RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 11 skipping to change at page 2, line 11
amongst isolated multicast-enabled sites or hosts, attached to a amongst isolated multicast-enabled sites or hosts, attached to a
network which has no native multicast support. It also enables them network which has no native multicast support. It also enables them
to exchange multicast traffic with the native multicast to exchange multicast traffic with the native multicast
infrastructure (MBone) and does not require any manual configuration. infrastructure (MBone) and does not require any manual configuration.
AMT uses an encapsulation interface so that no changes to a host AMT uses an encapsulation interface so that no changes to a host
stack or applications are required, all protocols (not just UDP) are stack or applications are required, all protocols (not just UDP) are
handled, and there is no additional overhead in core routers. handled, and there is no additional overhead in core routers.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
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 6, line 11 skipping to change at page 6, line 11
Each relay has an AMT pseudo-interface too. Multicast traffic sent Each relay has an AMT pseudo-interface too. Multicast traffic sent
on this interface is encapsulated to zero or more gateways that have on this interface is encapsulated to zero or more gateways that have
joined to the relay. The AMT recipient-list is determined for each joined to the relay. The AMT recipient-list is determined for each
multicast session. This requires the relay to keep state for each multicast session. This requires the relay to keep state for each
gateway which has joined a particular group or (source, group) pair). gateway which has joined a particular group or (source, group) pair).
Multicast packets from the native infrastructure behind the relay Multicast packets from the native infrastructure behind the relay
will be sent to each gateway which has requested them. will be sent to each gateway which has requested them.
All multicast packets (data and control) are encapsulated in unicast All multicast packets (data and control) are encapsulated in unicast
packets. To work across NAT's, the encapsulation is done over UDP packets. To work across NAT's, the encapsulation is done over UDP
using a reserved port number [TBD IANA]. using the IANA reserved AMT port number.
Each relay, plus the set of all gateways using the relay, together Each relay, plus the set of all gateways using the relay, together
are thought of as being on a separate logical NBMA link. This are thought of as being on a separate logical NBMA link. This
implies that the AMT recipient- list is a list of "link layer" implies that the AMT recipient- list is a list of "link layer"
addresses which are (IP address, UDP port) pairs. addresses which are (IP address, UDP port) pairs.
Since the number of gateways using a relay can be quite large, and we Since the number of gateways using a relay can be quite large, and we
expect that most sites will not want to receive most groups, an expect that most sites will not want to receive most groups, an
explicit-joining protocol is required for gateways to communicate explicit-joining protocol is required for gateways to communicate
group membership information to a relay. The two most likely group membership information to a relay. The two most likely
skipping to change at page 6, line 34 skipping to change at page 6, line 34
and hosts typically do not implement routing protocols, gateways will and hosts typically do not implement routing protocols, gateways will
use IGMP/MLD as described in Section 5 below. This allows a host use IGMP/MLD as described in Section 5 below. This allows a host
kernel (or a pseudo device driver) to easily implement AMT gateway kernel (or a pseudo device driver) to easily implement AMT gateway
behavior, and obviates the relay from the need to know whether a behavior, and obviates the relay from the need to know whether a
given gateway is a host or a router. From the relay's perspective, given gateway is a host or a router. From the relay's perspective,
all gateways are indistinguishable from hosts on an NBMA leaf all gateways are indistinguishable from hosts on an NBMA leaf
network. network.
4.1.1. Scalability Considerations 4.1.1. Scalability Considerations
The requirement that a relay keep group state per gateway that has It is possible that millions of hosts will enable AMT gateway
joined the group introduces potential scalability concerns. functionality and so an important design goal is not to create
gateway state in each relay until the gateway joins a multicast
group. But even the requirement that a relay keep group state per
gateway that has joined a group introduces potential scalability
concerns.
However, scalability of AMT can be achieved by adding more relays, Scalability of AMT can be achieved by adding more relays, and using
and using an appropriate relay discovery mechanism for gateways to an appropriate relay discovery mechanism for gateways to discover
discover relays. The solution we adopt is to assign an anycast relays. The solution we adopt is to assign an anycast address to
address to relays. However, simply sending periodic membership relays. However, simply sending periodic membership reports to the
reports to the anycast address can cause duplicates. Specifically, anycast address can cause duplicates. Specifically, if routing
if routing changes such that a different relay receives a periodic changes such that a different relay receives a periodic membership
membership report, both the new and old relays will encapsulate data report, both the new and old relays will encapsulate data to the AMT
to the AMT site until the old relay's state times out. This is site until the old relay's state times out. This is obviously
obviously undesirable. Instead, we use the anycast address merely to undesirable. Instead, we use the anycast address merely to find the
find the unicast address of a relay to which membership reports are unicast address of a relay to which membership reports are sent.
sent.
Since adding another relay has the result of adding another Since adding another relay has the result of adding another
independent NBMA link, this allows the gateways to be spread out independent NBMA link, this allows the gateways to be spread out
among more relays so as to keep the number of gateways per relay at a among more relays so as to keep the number of gateways per relay at a
reasonable level. reasonable level.
4.1.2. Spoofing Considerations 4.1.2. Spoofing Considerations
An attacker could affect the group state in the relay or gateway by An attacker could affect the group state in the relay or gateway by
spoofing the source address in the join or leave reports. This can be spoofing the source address in the join or leave reports. This can be
used to launch reflection or denial of service attacks on the target. used to launch reflection or denial of service attacks on the target.
Such attacks can be mitigated by using a three way handshake between Such attacks can be mitigated by using a three way handshake between
the gateway and the relay for each multicast membership report or the gateway and the relay for each multicast membership report or
leave. leave.
When a gateway or relay wants to send a membership report, it first When a gateway or relay wants to send a membership report, it first
sends an AMT Request with a request nonce in it. The receiving side sends an AMT Request with a request nonce in it. The receiving side
(the respondent) can calculate a message authentication code (MAC) (the respondent) can calculate a message authentication code (MAC)
based on the source IP address of the Request, the request nonce, and based on the source IP address of the Request, the source UDP port,
a secret key known only to the respondent. the request nonce, and a secret key known only to the respondent.
The algorithm used to calculate the MAC does not have to be
standardized since the respondent generates and verifies the MAC and
the originator simply echoes it.
An AMT Membership Query is sent back including the request nonce and An AMT Membership Query is sent back including the request nonce and
the MAC to the originator of the Request. The originator then sends the MAC to the originator of the Request. The originator then sends
the IGMP/MLD Membership/Listener Report or Leave/Done along with the the IGMP/MLD Membership/Listener Report or Leave/Done along with the
request nonce and the received MAC back to the respondent finalizing request nonce and the received MAC back to the respondent finalizing
the 3-way handshake. the 3-way handshake.
Upon reception, the respondent can recalculate the MAC based on the Upon reception, the respondent can recalculate the MAC based on the
source IP address, the request nonce, and the local secret. The source IP address, the source UDP port, the request nonce, and the
IGMP/MLD message is only accepted if the received MAC matches the local secret. The IGMP/MLD message is only accepted if the received
calculated MAC. MAC matches the calculated MAC.
The local secret never has to be shared with the other side. It is The local secret never has to be shared with the other side. It is
only used to verify return routability of the originator. only used to verify return routability of the originator.
4.2. Sourcing Multicast from an AMT site 4.2. Sourcing Multicast from an AMT site
Two cases are discussed below: multicast traffic sourced in an AMT Two cases are discussed below: multicast traffic sourced in an AMT
site and received in the MBone, and multicast traffic sourced in an site and received in the MBone, and multicast traffic sourced in an
AMT site and received in another AMT site. AMT site and received in another AMT site.
skipping to change at page 10, line 42 skipping to change at page 11, line 5
The AMT Relay Advertisement message is a UDP packet sent from the AMT The AMT Relay Advertisement message is a UDP packet sent from the AMT
relay anycast address to the source of the discovery message. relay anycast address to the source of the discovery message.
The UDP source port is the IANA reserved AMT port number and the UDP The UDP source port is the IANA reserved AMT port number and the UDP
destination port is the source port received in the Discovery destination port is the source port received in the Discovery
message. message.
The payload of the UDP packet contains the following fields. The payload of the UDP packet contains the following fields.
Fields:
Type
The type of the message.
Reserved
A 24-bit reserved field. Sent as 0, ignored on receipt.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x2 | Reserved | | Type=0x2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce | | Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Address | | Relay Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type
The type of the message.
Reserved
A 24-bit reserved field. Sent as 0, ignored on receipt.
Discovery Nonce Discovery Nonce
A 32-bit random value replayed from the discovery message. A 32-bit random value replayed from the discovery message.
Relay Address Relay Address
The unicast IPv4 or IPv6 address of the AMT relay. The family can The unicast IPv4 or IPv6 address of the AMT relay. The family can
be determined by the length of the Advertisement. be determined by the length of the Advertisement.
5.3. AMT Request 5.3. AMT Request
A Request packet is sent to begin a 3-way handshake for sending an A Request packet is sent to begin a 3-way handshake for sending an
skipping to change at page 11, line 37 skipping to change at page 11, line 45
a relay to a gateway. a relay to a gateway.
It is sent from the originator's unique unicast address to the It is sent from the originator's unique unicast address to the
respondents' unique unicast address. respondents' unique unicast address.
The UDP source port is uniquely selected by the local host operating The UDP source port is uniquely selected by the local host operating
system. It can be different for each Request and different from the system. It can be different for each Request and different from the
source port used in Discovery messages but does not have to be. The source port used in Discovery messages but does not have to be. The
UDP destination port is the IANA reserved AMT port number. UDP destination port is the IANA reserved AMT port number.
Fields:
Type
The type of the message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x3 | Reserved | | Type=0x3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type
The type of the message.
Reserved Reserved
A 24-bit reserved field. Sent as 0, ignored on receipt. A 24-bit reserved field. Sent as 0, ignored on receipt.
Request Nonce Request Nonce
A 32-bit identifier used to distinguish this request. A 32-bit identifier used to distinguish this request.
5.4. AMT Membership Query 5.4. AMT Membership Query
An AMT Membership Query packet is sent from the relay back to the An AMT Membership Query packet is sent from the relay back to the
originator to solicit an AMT Membership Update while confirming the originator to solicit an AMT Membership Update while confirming 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 non-cryptographic hash of a Authentication Code (MAC) that is a cryptographic hash of a private
private secret, the originators address, and the request nonce. secret, the originators address, and the request nonce.
It is sent from the destination address received in the Request to It is sent from the destination address received in the Request to
the source address received in the Request. the source address received in the Request.
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.
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 | | Type=0x4 | Reserved | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Response MAC (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response MAC | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type Type
The type of the message. The type of the message.
Reserved Reserved
A 24-bit reserved field. Sent as 0, ignored on receipt. An 8-bit reserved field. Sent as 0, ignored on receipt.
Response MAC
A 48-bit hash generated by the respondent and sent to the
originator for inclusion in the AMT Membership Update. The
algorithm used for this is chosen by the respondent. One algorithm
that could be used is HMAC-MD5-48 [HMAC].
Request Nonce Request Nonce
A 32-bit identifier used to distinguish this request echoed back A 32-bit identifier used to distinguish this request echoed back
to the originator. to the originator.
Response MAC
A 32-bit hash generated by the respondent and sent to the
originator for inclusion in the AMT Membership Update. This MUST
be calculated as HMAC-MD5-32 [HMAC].
5.5. AMT Membership Update 5.5. AMT Membership Update
An AMT Membership Update is sent from the originator to the An AMT Membership Update is sent from the originator to the
respondent containing the original IGMP/MLD Membership/Listener respondent containing the original IGMP/MLD Membership/Listener
Report or Leave/Done received over the AMT pseudo-interface. It Report or Leave/Done received over the AMT pseudo-interface. It
echoes the Response MAC received in the AMT Membership Query so the echoes the Response MAC received in the AMT Membership Query so the
respondent can verify return routability to the originator. respondent can verify return routability to the originator.
It is sent from the destination address received in the Query to the It is sent from the destination address received in the Query to the
source address received in the Query which should both be the same as source address received in the Query which should both be the same as
the original Request. the original Request.
The UDP source and destination port numbers should be the same ones The UDP source and destination port numbers should be the same ones
sent in the original Request. sent in the original Request.
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 | | Type=0x5 | Reserved | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Response MAC (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response MAC | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGMP/MLD Message | | IGMP/MLD Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type Type
The type of the message. The type of the message.
Reserved Reserved
A 24-bit reserved field. Sent as 0, ignored on receipt. An 8-bit reserved field. Sent as 0, ignored on receipt.
Response MAC
The 48-bit MAC received in the Membership Query and echoed back in
the Membership Update.
Request Nonce Request Nonce
A 32-bit identifier used to distinguish this request. A 32-bit identifier used to distinguish this request.
Response MAC 5.6. AMT Multicast Data
The MAC received from the relay and echoed back in the AMT
Membership Update.
5.6. AMT UDP Data
The AMT UDP Data message is a UDP packet encapsulating the data The AMT Data message is a UDP packet encapsulating the data requested
requested by the originator based on a previous AMT Membership Update by the originator based on a previous AMT Membership Update message.
message. Currently, it is only defined for original UDP multicast
data packets. This prevents the tunnel from being used as an
arbitrary tunnel mechanism and greatly reduces the possibility of
exploitation.
It is sent from the unicast destination address of the Membership It is sent from the unicast destination address of the Membership
update to the source address of the Membership Update. update to the source address of the Membership Update.
The UDP source and destination port numbers should be the same ones The UDP source and destination port numbers should be the same ones
sent in the original Query. sent in the original Query.
The payload of the UDP packet contains the following fields. The payload of the UDP packet contains the following fields.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x6 | Reserved | | Type=0x6 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Multicast Data | | Multicast Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type Type
The type of the message. The type of the message.
Reserved Reserved
skipping to change at page 16, line 29 skipping to change at page 16, line 36
possibilities include: possibilities include:
1. The AMT pseudo-interface might periodically manufacture 1. The AMT pseudo-interface might periodically manufacture
IGMPv3/MLDv2 Queries as if they had been received from an IGMP/MLD IGMPv3/MLDv2 Queries as if they had been received from an IGMP/MLD
Querier, and deliver them to the IP layer, after which normal Querier, and deliver them to the IP layer, after which normal
IGMP/MLD behavior will cause the appropriate reports to be sent. IGMP/MLD behavior will cause the appropriate reports to be sent.
2. The IGMP/MLD module itself might provide an option to operate in 2. The IGMP/MLD module itself might provide an option to operate in
periodic mode on specific interfaces. periodic mode on specific interfaces.
If the gateway is behind a firewall device, the firewall may require
the gateway to periodically refresh the UDP state in the firewall at
a shorter interval than the standard IGMP/MLD Query interval.
Therefore, this IGMP/MLD Query interval should be configurable to
ensure the firewall does not revert to blocking the UDP encapsulated
multicast data packets.
6.3. Responding to Relay Changes 6.3. Responding to Relay Changes
When a gateway determines that its current relay is unreachable When a gateway determines that its current relay is unreachable
(e.g., upon receipt of a ICMP Unreachable message [ICMP] for the (e.g., upon receipt of a ICMP Unreachable message [ICMP] 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. Some relay too quickly due to transient network conditions. Some
implementations may find it difficult to send a discovery packet to implementations may find it difficult to send a discovery packet to
the anycast relay address while the gateway has an address configured the anycast relay address while the gateway has an address configured
on the AMT pseudo-interface on the same anycast prefix. Therefore, it on the AMT pseudo-interface on the same anycast prefix. Therefore, it
skipping to change at page 20, line 17 skipping to change at page 20, line 33
affects the number of groups available to be created by the AMT affects the number of groups available to be created by the AMT
gateway: a length of 16 gives 256 groups, and a length of 8 gives gateway: a length of 16 gives 256 groups, and a length of 8 gives
65536 groups. For diagnostic purposes, it is helpful to have a 65536 groups. For diagnostic purposes, it is helpful to have a
prefix length which is a multiple of 8, although this is not prefix length which is a multiple of 8, although this is not
required. required.
An autonomous system number dedicated to a pseudo-AS for multicast is An autonomous system number dedicated to a pseudo-AS for multicast is
already in use today (AS 10888), and so it is expected that no already in use today (AS 10888), and so it is expected that no
additional AS number is required for this prefix. additional AS number is required for this prefix.
Finally, IANA should allocate a reserved UDP port number for AMT IANA has allocated UDP reserved port number 2268 for AMT
encapsulation. encapsulation.
9. Security Considerations 9. 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.
skipping to change at page 21, line 15 skipping to change at page 21, line 29
2. A gateway MUST discard encapsulated multicast packets if the 2. A gateway MUST discard encapsulated multicast packets if the
source address in the outer header is not the address to which the source address in the outer header is not the address to which the
encapsulated join message was sent. An AMT Gateway that receives encapsulated join message was sent. An AMT Gateway that receives
an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the message an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the message
if the IPv4 destination address in the outer header is not if the IPv4 destination address in the outer header is not
composed of the last 2 bytes of S and the 2 middle bytes of G composed of the last 2 bytes of S and the 2 middle bytes of G
(i.e. the destination address a.b.c.d must be composed of the a.b (i.e. the destination address a.b.c.d must be composed of the a.b
of the multicast source x.y.a.b and the c.d of the multicast group of the multicast source x.y.a.b and the c.d of the multicast group
232.c.d.e). 232.c.d.e).
10. Acknowledgments 10. Contributors
The following people provided significant contributions to earlier
versions of this draft.
Dirk Ooms
OneSparrow
Belegstraat 13; 2018 Antwerp; Belgium
EMail: dirk@onesparrow.com
11. 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. Tom provided helpful discussion that inspired this document.
Pusateri helped flush out protocol details based on implementation
experience and provided updates to this draft.
11. Normative References
[HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed- 12. Normative References
Hashing for Message Authentication", RFC 2104, February
1997.
[ICMP] Postel, J., "Internet Control Message Protocol", RFC 792, [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981. September 1981.
[PROXY] Fenner, W., He, H., Haberman, B., Sandick, H., "IGMP/MLD-
based Multicast Forwarding ("IGMP/MLD Proxying")", Work
in progress, draft-ietf-magma-igmp-proxy-06.txt, April
2004.
[IGMPv3] Cain, B., Deering, S., Fenner, B., Kouvelas, I., [IGMPv3] Cain, B., Deering, S., Fenner, B., Kouvelas, I.,
Thyagarajan A., "Internet Group Management Protocol, Thyagarajan A., "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002. Version 3", RFC 3376, October 2002.
[MLDv2] Vida, R., Costa, L., "Multicast Listener Discovery [MLDv2] Vida, R., Costa, L., "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[PROXY] Fenner, W., He, H., Haberman, B., Sandick, H., "IGMP/MLD-
based Multicast Forwarding ("IGMP/MLD Proxying")", Work
in progress, draft-ietf-magma-igmp-proxy-06.txt, April
2004.
[SSM] Holbrook, H., Cain, B., "Source-Specific Multicast for [SSM] Holbrook, H., Cain, B., "Source-Specific Multicast for
IP", Work in Progress, draft-ietf-ssm-arch-06.txt, IP", Work in Progress, draft-ietf-ssm-arch-06.txt,
September 2004. September 2004.
12. Informative References 13. Informative References
[Brad88] Braden, R., Borman, D., Partridge, C., "Computing the [ANYCAST] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
Internet Checksum", RFC 1071, September 1988. RFC 3068, June 2001.
[6TO4] Carpenter, B., Moore, K., "Connection of IPv6 Domains via [6TO4] Carpenter, B., Moore, K., "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
[Brad88] Braden, R., Borman, D., Partridge, C., "Computing the
Internet Checksum", RFC 1071, September 1988.
[BROKER] Durand, A., Fasano, P., Guardini, I., Lento, D., "IPv6 [BROKER] Durand, A., Fasano, P., Guardini, I., Lento, D., "IPv6
Tunnel Broker", RFC 3053, January 2001. Tunnel Broker", RFC 3053, January 2001.
[ANYCAST] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-
RFC 3068, June 2001. Hashing for Message Authentication", RFC 2104, February
1997.
[PIMSM] Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering, [PIMSM] Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., Wei, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., Wei,
L., "Protocol Independent Multicast-Sparse Mode (PIM-SM): L., "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, June 1998. Protocol Specification", RFC 2362, June 1998.
13. Author's Address 14. Author's Address
Dave Thaler Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
Phone: +1 425 703 8835 Phone: +1 425 703 8835
EMail: dthaler@microsoft.com EMail: dthaler@microsoft.com
Mohit Talwar Mohit Talwar
Microsoft Corporation Microsoft Corporation
skipping to change at page 23, line 4 skipping to change at page 23, line 20
Redmond, WA 98052-6399 Redmond, WA 98052-6399
Phone: +1 425 705 3131 Phone: +1 425 705 3131
EMail: mohitt@microsoft.com EMail: mohitt@microsoft.com
Amit Aggarwal Amit Aggarwal
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
Phone: +1 425 706 0593 Phone: +1 425 706 0593
EMail: amitag@microsoft.com EMail: amitag@microsoft.com
Lorenzo Vicisano Lorenzo Vicisano
Cisco Systems Cisco Systems
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
Phone: +1 408 525 2530 Phone: +1 408 525 2530
EMail: lorenzo@cisco.com EMail: lorenzo@cisco.com
Dirk Ooms Tom Pusateri
OneSparrow Juniper Networks, Inc.
Belegstraat 13; 2018 Antwerp; Belgium 1194 North Mathilda Avenue
EMail: dirk@onesparrow.com Sunnyvale, CA 94089 USA
Phone: +1 408 745 2000
EMail: pusateri@juniper.net
14. Intellectual Property Rights Notice 15. Intellectual Property Rights Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 23, line 40 skipping to change at page 24, line 18
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org." ipr@ietf.org."
15. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
16. Disclaimer 17. Disclaimer
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . . 5 4.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . . 5
4.2. Sourcing Multicast from an AMT site . . . . . . . . . . . . 7 4.2. Sourcing Multicast from an AMT site . . . . . . . . . . . . 7
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . . 9 5.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . . 10
5.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . . 10 5.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . . 10
5.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . . 12 5.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . . 12
5.5. AMT Membership Update . . . . . . . . . . . . . . . . . . . 13 5.5. AMT Membership Update . . . . . . . . . . . . . . . . . . . 13
5.6. AMT UDP Data . . . . . . . . . . . . . . . . . . . . . . . . 14 5.6. AMT Multicast Data . . . . . . . . . . . . . . . . . . . . . 14
6. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 14 6. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 15
6.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . . 15 6.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Joining Groups with MBone Sources . . . . . . . . . . . . . 15 6.2. Joining Groups with MBone Sources . . . . . . . . . . . . . 15
6.3. Responding to Relay Changes . . . . . . . . . . . . . . . . 16 6.3. Responding to Relay Changes . . . . . . . . . . . . . . . . 16
6.4. Creating SSM groups . . . . . . . . . . . . . . . . . . . . 16 6.4. Creating SSM groups . . . . . . . . . . . . . . . . . . . . 17
6.5. Joining SSM Groups with AMT Sources . . . . . . . . . . . . 17 6.5. Joining SSM Groups with AMT Sources . . . . . . . . . . . . 17
6.6. Receiving IGMPv3/MLDv2 Reports at the Gateway . . . . . . . 17 6.6. Receiving IGMPv3/MLDv2 Reports at the Gateway . . . . . . . 17
6.7. Sending data to SSM groups . . . . . . . . . . . . . . . . . 18 6.7. Sending data to SSM groups . . . . . . . . . . . . . . . . . 18
7. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 18 7. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 18
7.1. At Startup time . . . . . . . . . . . . . . . . . . . . . . 18 7.1. At Startup time . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Receiving Relay Discovery messages sent to the Anycast 7.2. Receiving Relay Discovery messages sent to the Anycast
Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.3. Receiving Membership Updates from AMT Gateways . . . . . . . 19 7.3. Receiving Membership Updates from AMT Gateways . . . . . . . 19
7.4. Receiving (S,G) Joins from the Native Side, for AMT Sources 7.4. Receiving (S,G) Joins from the Native Side, for AMT Sources
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Normative References . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
12. Informative References . . . . . . . . . . . . . . . . . . . 22 12. Normative References . . . . . . . . . . . . . . . . . . . . 21
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . 22 13. Informative References . . . . . . . . . . . . . . . . . . . 22
14. Intellectual Property Rights Notice . . . . . . . . . . . . . 23 14. Author's Address . . . . . . . . . . . . . . . . . . . . . . 22
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . 23 15. Intellectual Property Rights Notice . . . . . . . . . . . . . 23
16. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 24 16. Full Copyright Statement . . . . . . . . . . . . . . . . . . 24
17. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 24
 End of changes. 

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