draft-ietf-mboned-auto-multicast-00.txt   draft-ietf-mboned-auto-multicast-01.txt 
MBoneD Working Group Dave Thaler MBoneD Working Group Dave Thaler
INTERNET-DRAFT Mohit Talwar INTERNET-DRAFT Mohit Talwar
Expires August 2001 Microsoft Expires October 2002 Microsoft
Lorenzo Vicisano Lorenzo Vicisano
Cisco Cisco
Dirk Ooms Dirk Ooms
Alcatel Alcatel
20 February 2001 April 2002
IPv4 Automatic Multicast Without Explicit Tunnels (AMT) IPv4 Automatic Multicast Without Explicit Tunnels (AMT)
<draft-ietf-mboned-auto-multicast-00.txt> <draft-ietf-mboned-auto-multicast-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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.
skipping to change at page 2, line 5 skipping to change at page 10, line ?
in progress." 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.
Copyright Notice Copyright Notice
Draft AMT February 2001 Expires October 2002 [Page 1]
Draft AMT April 2002
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
1. Abstract 1. Abstract
Automatic Multicast Tunneling (AMT) allows multicast communication Automatic Multicast Tunneling (AMT) allows multicast communication
amongst isolated multicast-enabled sites or hosts, attached to a amongst isolated multicast-enabled sites or hosts, attached to a
network which has no native multicast support. It also enables network which has no native multicast support. It also enables
them to exchange multicast traffic with the native multicast them to exchange multicast traffic with the native multicast
infrastructure (MBone) and does not require any manual infrastructure (MBone) and does not require any manual
skipping to change at page 3, line 5 skipping to change at page 10, line ?
To allow fast deployment, the solution presented here only To allow fast deployment, the solution presented here only
requires small and concentrated changes to the network requires small and concentrated changes to the network
infrastructure, and no changes at all to user applications or to infrastructure, and no changes at all to user applications or to
the socket API of end-nodes' operating systems. The protocols the socket API of end-nodes' operating systems. The protocols
introduced in this specification are implemented in a few introduced in this specification are implemented in a few
strategically-placed network nodes and in user-installable strategically-placed network nodes and in user-installable
software modules (pseudo device drivers and/or user-mode daemons) software modules (pseudo device drivers and/or user-mode daemons)
that reside underneath the socket API of end-nodes' operating that reside underneath the socket API of end-nodes' operating
systems. This mechanism is very similar to that used by "6to4" systems. This mechanism is very similar to that used by "6to4"
Draft AMT February 2001 Expires October 2002 [Page 2]
Draft AMT April 2002
[6TO4, ANYCAST] to get automatic IPv6 connectivity. [6TO4, ANYCAST] to get automatic IPv6 connectivity.
In order of importance, the following problems are addressed: In order of importance, the following problems are addressed:
o Allowing isolated sites/hosts to receive general multicast (ISM o Allowing isolated sites/hosts to receive general multicast (ISM
[RFC1112]). [RFC1112]).
o Allowing isolated sites/hosts to receive the SSM flavor of o Allowing isolated sites/hosts to receive the SSM flavor of
multicast ([SSM]). multicast ([SSM]).
skipping to change at page 4, line 5 skipping to change at page 10, line ?
Figure 1: Automatic Multicast Definitions. Figure 1: Automatic Multicast Definitions.
AMT Pseudo-Interface AMT Pseudo-Interface
AMT encapsulation of multicast packets inside unicast packets AMT encapsulation of multicast packets inside unicast packets
occurs at a point that is logically equivalent to an occurs at a point that is logically equivalent to an
interface, with the link layer being the unicast-only interface, with the link layer being the unicast-only
network. This point is referred to as a pseudo-interface. network. This point is referred to as a pseudo-interface.
Some implementors may treat it exactly like any other Some implementors may treat it exactly like any other
interface and others may treat it like a tunnel end-point. interface and others may treat it like a tunnel end-point.
Draft AMT February 2001 Expires October 2002 [Page 3]
Draft AMT April 2002
AMT Gateway AMT Gateway
A host, or a site gateway router, supporting an AMT Pseudo- A host, or a site gateway router, supporting an AMT Pseudo-
Interface. It does not have native multicast connectivity to Interface. It does not have native multicast connectivity to
the native multicast backbone infrastructure. It is simply the native multicast backbone infrastructure. It is simply
referred to in this document as a "gateway". referred to in this document as a "gateway".
AMT Site AMT Site
A multicast-enabled network not connected to the multicast A multicast-enabled network not connected to the multicast
backbone served by an AMT Gateway. It could also be a stand- backbone served by an AMT Gateway. It could also be a
alone AMT Gateway. stand-alone AMT Gateway.
AMT Relay Router AMT Relay Router
A multicast router configured to support transit routing A multicast router configured to support transit routing
between AMT Sites and the native multicast backbone between AMT Sites and the native multicast backbone
infrastructure. The relay router has one or more interfaces infrastructure. The relay router has one or more interfaces
connected to the native multicast infrastructure, zero or connected to the native multicast infrastructure, zero or
more interfaces connected to the non-multicast capable more interfaces connected to the non-multicast capable
internetwork, and an AMT pseudo-interface. It is simply internetwork, and an AMT pseudo-interface. It is simply
referred to in this document as a "relay". referred to in this document as a "relay".
skipping to change at page 5, line 5 skipping to change at page 10, line ?
An anycast address which is used to reach the nearest AMT An anycast address which is used to reach the nearest AMT
Relay Router. Relay Router.
This address corresponds to host number 1 in the AMT Relay This address corresponds to host number 1 in the AMT Relay
Anycast Prefix, x.x.x.1. Anycast Prefix, x.x.x.1.
AMT Unicast Autonomous System ID AMT Unicast Autonomous System ID
A 16-bit Autonomous system ID, for use in BGP in accordance A 16-bit Autonomous system ID, for use in BGP in accordance
to this memo. AS 10888 might be usable for this, but for now to this memo. AS 10888 might be usable for this, but for now
Draft AMT February 2001 Expires October 2002 [Page 4]
Draft AMT April 2002
we'll assume it's different, to avoid confusion. This number we'll assume it's different, to avoid confusion. This number
represents a "pseudo-AS" common to all AMT relays. represents a "pseudo-AS" common to all AMT relays.
To protect themselves from erroneous advertisements, managers To protect themselves from erroneous advertisements, managers
of border routers often use databases to check the relation of border routers often use databases to check the relation
between the advertised network and the last hop in the AS between the advertised network and the last hop in the AS
path. Associating a specific AS number with the AMT Relay path. Associating a specific AS number with the AMT Relay
Anycast Address allows us to enter this relationship in the Anycast Address allows us to enter this relationship in the
databases used to check inter-domain routing [ANYCAST]. databases used to check inter-domain routing [ANYCAST].
skipping to change at page 6, line 5 skipping to change at page 10, line ?
| +---->|Gateway| | Relay | | | +---->|Gateway| | Relay | |
| | +---+---+ =================> +---+---+ | | | +---+---+ =================> +---+---+ |
| R-+ | 2. IGMP Report | | | R-+ | 2. IGMP Report | |
+---------------+ +---------------+ +---------------+ +---------------+
Figure 2: Receiving Multicast in an AMT Site. Figure 2: Receiving Multicast in an AMT Site.
AMT relays and gateways cooperate to transmit multicast traffic AMT relays and gateways cooperate to transmit multicast traffic
sourced within the native multicast infrastructure to AMT sites: sourced within the native multicast infrastructure to AMT sites:
Draft AMT February 2001 Expires October 2002 [Page 5]
Draft AMT April 2002
relays receive the traffic natively and unicast-encapsulate it to relays receive the traffic natively and unicast-encapsulate it to
gateways; gateways decapsulate the traffic and possibly re- gateways; gateways decapsulate the traffic and possibly re-
multicast it in the AMT site. multicast it in the AMT site.
Each gateway has an AMT pseudo-interface that serves as a default Each gateway has an AMT pseudo-interface that serves as a default
multicast route. Requests to join a multicast session are sent to multicast route. Requests to join a multicast session are sent to
this interface and encapsulated to a particular relay reachable this interface and encapsulated to a particular relay reachable
across the unicast-only infrastructure. across the unicast-only infrastructure.
skipping to change at page 7, line 5 skipping to change at page 10, line ?
candidates are the IGMP [IGMP] protocol, and the PIM-Sparse Mode candidates are the IGMP [IGMP] protocol, and the PIM-Sparse Mode
[PIMSM] protocol. Since an AMT gateway may be a host, and hosts [PIMSM] protocol. Since an AMT gateway may be a host, and hosts
typically do not implement routing protocols, gateways will use typically do not implement routing protocols, gateways will use
IGMP as described in Section 5 below. This allows a host kernel IGMP as described in Section 5 below. This allows a host kernel
(or a pseudo device driver) to easily implement AMT gateway (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 given gateway is a host or a router. From the relay's
perspective, all gateways are indistinguishable from hosts on an perspective, all gateways are indistinguishable from hosts on an
NBMA leaf network. NBMA leaf network.
Draft AMT February 2001 Expires October 2002 [Page 6]
Draft AMT April 2002
4.1.1. Scalability Considerations 4.1.1. Scalability Considerations
The requirement that a relay keep group state per gateway that has The requirement that a relay keep group state per gateway that has
joined the group introduces potential scalability concerns. joined the group introduces potential scalability concerns.
However, scalability of AMT can be achieved by adding more relays, However, scalability of AMT can be achieved by adding more relays,
and using an appropriate relay discovery mechanism for gateways to and using an appropriate relay discovery mechanism for gateways to
discover relays. The solution we adopt is to assign an anycast discover relays. The solution we adopt is to assign an anycast
address to relays. However, simply sending periodic IGMP Reports address to relays. However, simply sending periodic IGMP Reports
skipping to change at page 8, line 5 skipping to change at page 10, line ?
The general mechanism used to join towards AMT sources is based on The general mechanism used to join towards AMT sources is based on
the following: the following:
o Applications residing in the gateway use addresses in the AMT o Applications residing in the gateway use addresses in the AMT
Subnet Prefix to send multicast, as a result of sourcing traffic Subnet Prefix to send multicast, as a result of sourcing traffic
on the AMT pseudo-interface. on the AMT pseudo-interface.
o The AMT Subnet Prefix is advertised for RPF reachability in the o The AMT Subnet Prefix is advertised for RPF reachability in the
M-RIB by relays and gateways. M-RIB by relays and gateways.
Draft AMT February 2001 Expires October 2002 [Page 7]
Draft AMT April 2002
o Relays or gateways that receive a join for a source/group pair o Relays or gateways that receive a join for a source/group pair
use information encoded in the address pair to rebuild the use information encoded in the address pair to rebuild the
address of the gateway (source) to which to encapsulate the IGMP address of the gateway (source) to which to encapsulate the join
Report (see section 5 for more details). (see section 5 for more details).
It is expected that this mechanism will be the identical to that It is expected that this join mechanism will be the identical to
used to join back to a source on normal media, as is being that used to join back to a source on normal media, as is being
proposed in the SSM WG. proposed in the SSM WG [MSNIP].
4.2.1. Supporting Site-MBone Multicast 4.2.1. Supporting Site-MBone Multicast
+---------------+ Internet +---------------+ +---------------+ Internet +---------------+
| AMT Site | | MBone | | AMT Site | | MBone |
| | 3. Data | | | | 3. Data | |
| +---+---+ =================> +---+---+ 1. Join | | +---+---+ =================> +---+---+ 1. Join |
| |Gateway| | Relay |<-----+ | | |Gateway| | Relay |<-----+ |
| +---+---+ <================= +---+---+ | | | +---+---+ <================= +---+---+ | |
| | 2. IGMP Report | +-R | | | 2. IGMP Report | +-R |
skipping to change at page 9, line 5 skipping to change at page 10, line ?
the AMT site is received via the closest relay to the receiver. the AMT site is received via the closest relay to the receiver.
This is necessary when the routers in the native multicast This is necessary when the routers in the native multicast
infrastructure employ Reverse-Path Forwarding (RPF) checks against infrastructure employ Reverse-Path Forwarding (RPF) checks against
the source address, such as occurs when [PIMSM] is used by the the source address, such as occurs when [PIMSM] is used by the
multicast infrastructure. multicast infrastructure.
The solution above will scale to an arbitrary number of relays, as The solution above will scale to an arbitrary number of relays, as
long at the number of relays requiring multicast traffic from a long at the number of relays requiring multicast traffic from a
given AMT site remains reasonable enough to not overly burden the given AMT site remains reasonable enough to not overly burden the
Draft AMT February 2001 Expires October 2002 [Page 8]
Draft AMT April 2002
site's gateway. site's gateway.
4.2.2. Supporting Site-Site Multicast 4.2.2. Supporting Site-Site Multicast
+---------------+ Internet +---------------+ +---------------+ Internet +---------------+
| AMT Site | | AMT Site | | AMT Site | | AMT Site |
| | 3. Data | | | | 3. Data | |
| +---+---+ =================> +---+---+ 1. Join | | +---+---+ =================> +---+---+ 1. Join |
| |Gateway| |Gateway|<-----+ | | |Gateway| |Gateway|<-----+ |
skipping to change at page 10, line 5 skipping to change at page 10, line ?
traffic to a large number of sites could get a point-to-point traffic to a large number of sites could get a point-to-point
tunnel to the native multicast infrastructure, and use that tunnel to the native multicast infrastructure, and use that
instead of AMT. instead of AMT.
5. AMT Gateway Details 5. AMT Gateway Details
This section details the behavior of an AMT Gateway, which may be 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 a router serving an AMT site, or the site may consist of a single
host, serving as its own gateway. host, serving as its own gateway.
Draft AMT February 2001 Expires October 2002 [Page 9]
Draft AMT April 2002
5.1. At Startup Time 5.1. At Startup Time
At startup time, the AMT gateway will bring up an AMT pseudo- At startup time, the AMT gateway will bring up an AMT pseudo-
interface, to be used for encapsulation. The gateway will then interface, to be used for encapsulation. The gateway will then
send a UDP encapsulated ICMP Echo Request to the AMT Relay Anycast send a UDP encapsulated ICMP Echo Request to the AMT Relay Anycast
Address, and note the unicast address (which is treated as a link- Address, and note the unicast address (which is treated as a
layer address to the encapsulation interface) from the UDP link-layer address to the encapsulation interface) from the UDP
encapsulated ICMP Echo Response. These "pings" should be done encapsulated ICMP Echo Response. These "pings" should be done
periodically (e.g., once a day) to re-resolve the unicast address periodically (e.g., once a day) to re-resolve the unicast address
of a close relay. Note that the ICMP messages are unicast of a close relay. Note that the ICMP messages are unicast
encapsulated, just as the multicast packets. encapsulated, just as the multicast packets.
The gateway also initializes a timer used to send periodic IGMP The gateway also initializes a timer used to send periodic IGMP
Reports to a random value from the interval [0, [Query Interval]] Reports to a random value from the interval [0, [Query Interval]]
before sending the first periodic report, in order to prevent before sending the first periodic report, in order to prevent
startup synchronization (e.g., after a power outage). startup synchronization (e.g., after a power outage).
skipping to change at page 11, line 5 skipping to change at page 11, line 5
gateway has global unicast address a.b.c.d, then the AMT Gateway's gateway has global unicast address a.b.c.d, then the AMT Gateway's
Anycast Address will be x.y.a.b. Note that multiple gateways Anycast Address will be x.y.a.b. Note that multiple gateways
might end up with the same address assigned to their pseudo- might end up with the same address assigned to their pseudo-
interfaces. interfaces.
5.2. Joining Groups with MBone Sources 5.2. Joining Groups with MBone Sources
The IGMP protocol usually operates by having the Querier multicast The IGMP protocol usually operates by having the Querier multicast
an IGMP Query message on the link. This behavior does not work on an IGMP Query message on the link. This behavior does not work on
Draft AMT February 2001 Draft AMT April 2002
NBMA links which do not support multicast. Since the set of NBMA links which do not support multicast. Since the set of
gateways is typically unknown to the relay (and potentially quite gateways is typically unknown to the relay (and potentially quite
large), unicasting the queries is also impractical. The following large), unicasting the queries is also impractical. The following
behavior is used instead. behavior is used instead.
Applications residing in a gateway should join groups on the AMT Applications residing in a gateway should join groups on the AMT
pseudo-interface, causing IGMP Membership Reports to be sent over pseudo-interface, causing IGMP Membership Reports to be sent over
that interface. When UDP encapsulating the IGMP Reports (and in that interface. When UDP encapsulating the IGMP Reports (and in
fact any other messages, unless specified otherwise in this fact any other messages, unless specified otherwise in this
skipping to change at page 12, line 5 skipping to change at page 12, line 5
to use as a "link-layer" destination. to use as a "link-layer" destination.
5.4. Creating SSM groups 5.4. Creating SSM groups
When a gateway wants to create an SSM group (i.e., in 232/8) for When a gateway wants to create an SSM group (i.e., in 232/8) for
which it can source traffic, the remaining 24 bits must be which it can source traffic, the remaining 24 bits must be
generated as described below. ([SSM] states that "the policy for generated as described below. ([SSM] states that "the policy for
allocating these bits is strictly locally determined at the allocating these bits is strictly locally determined at the
sender's host.") sender's host.")
Draft AMT February 2001 Draft AMT April 2002
When the gateway determined its AMT Gateway Anycast Address as When the gateway determined its AMT Gateway Anycast Address as
described above, it used the high bits of its global unicast described above, it used the high bits of its global unicast
address. The remaining bits of its global unicast address are address. The remaining bits of its global unicast address are
appended to the 232/8 prefix, and any spare bits may be allocated appended to the 232/8 prefix, and any spare bits may be allocated
using any policy (again, strictly locally determined at the using any policy (again, strictly locally determined at the
sender's host). sender's host).
For example, if IANA allocates x.y/16 as the AMT Subnet Prefix, For example, if IANA allocates x.y/16 as the AMT Subnet Prefix,
and the device has global unicast address a.b.c.d, then it must and the device has global unicast address a.b.c.d, then it must
skipping to change at page 13, line 5 skipping to change at page 13, line 5
If S is not the AMT Gateway Anycast Address of the gateway, the If S is not the AMT Gateway Anycast Address of the gateway, the
packet is dropped. If G does not contain the low bits of the packet is dropped. If G does not contain the low bits of the
global unicast address (as described above), the packet is also global unicast address (as described above), the packet is also
dropped. dropped.
Otherwise, the gateway adds the source address (from the outer IP Otherwise, the gateway adds the source address (from the outer IP
header) and UDP port of the report to a membership list for G. header) and UDP port of the report to a membership list for G.
Maintaining this membership list may be done in any Maintaining this membership list may be done in any
Draft AMT February 2001 Draft AMT April 2002
implementation-dependent manner. For example, it might be implementation-dependent manner. For example, it might be
maintained by the "link-layer" inside the AMT pseudo-interface, maintained by the "link-layer" inside the AMT pseudo-interface,
making it invisible to the normal IGMP module. making it invisible to the normal IGMP module.
5.7. Sending data to SSM groups 5.7. Sending data to SSM groups
When multicast packets are sent on the AMT pseudo-interface, they When multicast packets are sent on the AMT pseudo-interface, they
are encapsulated as follows. If the group address is not an SSM are encapsulated as follows. If the group address is not an SSM
group, then the packet is dropped (this memo does not currently group, then the packet is dropped (this memo does not currently
skipping to change at page 14, line 5 skipping to change at page 14, line 5
The relay router shall also enable IGMPv3 on the AMT pseudo- The relay router shall also enable IGMPv3 on the AMT pseudo-
interface, except that it shall not multicast Queries (this might interface, except that it shall not multicast Queries (this might
be done, for example, by having the AMT pseudo-device drop them, be done, for example, by having the AMT pseudo-device drop them,
or by having the IGMP module not send them in the first place). or by having the IGMP module not send them in the first place).
Finally, to support sourcing SSM traffic from AMT sites, the AMT Finally, to support sourcing SSM traffic from AMT sites, the AMT
Subnet Prefix is assigned to the AMT pseudo-interface, and the AMT Subnet Prefix is assigned to the AMT pseudo-interface, and the AMT
Subnet Prefix is injected into the M-RIB of MBGP. Subnet Prefix is injected into the M-RIB of MBGP.
Draft AMT February 2001 Draft AMT April 2002
6.2. Receiving Echo Requests to the Anycast Address 6.2. Receiving Echo Requests to the Anycast Address
When a relay receives a UDP encapsulated ICMP Echo Request When a relay receives a UDP encapsulated ICMP Echo Request
directed to the AMT Relay Anycast Address, it should respond with directed to the AMT Relay Anycast Address, it should respond with
a UDP encapsulated ICMP Echo Response from a unicast address a UDP encapsulated ICMP Echo Response from a unicast address
reachable on the unicast-only network (anycast addresses should reachable on the unicast-only network (anycast addresses should
not be used as the source address of the ICMP Echo Response). not be used as the source address of the ICMP Echo Response).
Unicast encapsulation of the ICMP Echo Request ensures that the Unicast encapsulation of the ICMP Echo Request ensures that the
skipping to change at page 15, line 5 skipping to change at page 15, line 5
o The IGMP module might have native support for explicit o The IGMP module might have native support for explicit
membership tracking, especially if it supports other NBMA- membership tracking, especially if it supports other NBMA-
style interfaces. style interfaces.
6.4. Receiving (S,G) Joins from the Native Side, for AMT 6.4. Receiving (S,G) Joins from the Native Side, for AMT
Sources Sources
The relay encapsulates an IGMPv3 report to the AMT source as The relay encapsulates an IGMPv3 report to the AMT source as
described above in Section 5.5. described above in Section 5.5.
Draft AMT February 2001 Draft AMT April 2002
7. IANA Considerations 7. IANA Considerations
The IANA should allocate a prefix dedicated to the AMT Relays to The IANA should allocate a prefix dedicated to the AMT Relays to
the native multicast backbone. The prefix length should be the native multicast backbone. The prefix length should be
determined by the IANA; the prefix should be large enough to determined by the IANA; the prefix should be large enough to
guarantee advertisement in the default- free BGP networks; a guarantee advertisement in the default- free BGP networks; a
length of 16 will meet this requirement. This is a one time length of 16 will meet this requirement. This is a one time
effort; there is no need for any recurring assignment after this effort; there is no need for any recurring assignment after this
stage. stage.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
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 prefix in much the same way that they guarantee the integrity of
all other routes. all other routes.
Within the native MBGP infrastructure, there is a risk that a Within the native MBGP infrastructure, there is a risk that a
rogue router or a rogue AS could introduce a bogus route to the rogue router or a rogue AS could introduce a bogus route to the
Draft AMT February 2001 Draft AMT April 2002
AMT Subnet Prefix, and thus divert joins and cause RPF failures of AMT Subnet Prefix, and thus divert joins and cause RPF failures of
multicast traffic. Again, network managers have to guarantee the multicast traffic. Again, network managers have to guarantee the
integrity of the MBGP routing to the AMT subnet prefix in much the integrity of the MBGP routing to the AMT subnet prefix in much the
same way that they guarantee the integrity of all other routes in same way that they guarantee the integrity of all other routes in
the M-RIB. the M-RIB.
By default, gateways and relays will accept and decapsulate Gateways and relays will accept and decapsulate multicast traffic
multicast traffic any source from which regular unicast traffic is from any source from which regular unicast traffic is accepted.
accepted. If this is for any reason felt to be a security risk, If this is for any reason felt to be a security risk, then
then additional source address based packet filtering could be additional source address based packet filtering could be applied:
applied.
o To avoid that a rogue sender (that can't do traditional
spoofing because of e.g. access lists deployed by its ISP)
makes use of AMT to send packets to an SSM tree, a relay that
receives an encapsulated multicast packet COULD discard the
multicast packet if the IPv4 source address in the outer
header is not composed of the last 2 bytes of the source
address and the 2 middle bytes of the destination address of
the inner header (i.e. a.b.c.d must be composed of the a.b of
x.y.a.b and the c.d of 232.c.d.e).
o A gateway COULD discard encapsulated multicast packets if the
source address in the outer header is not the address to
which the encapsulated join message was sent.
An AMT Gateway that receives an encapsulated IGMPv3 (S,G)-Join
COULD discard the message 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 (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 232.c.d.e). The usefulness of this check will
depend on the security measures taken in [MSNIP].
9. Acknowledgements 9. Acknowledgements
Most of the mechanisms described in this document are based on Most of the mechanisms described in this document are based on
similar work done by the NGTrans WG for obtaining automatic IPv6 similar work done by the NGTrans WG for obtaining automatic IPv6
connectivity without explicit tunnels ("6to4"). Tony Ballardie connectivity without explicit tunnels ("6to4"). Tony Ballardie
provided helpful discussion that inspired this document. provided helpful discussion that inspired this document.
Draft AMT April 2002
10. Appendix A: Open Issues 10. Appendix A: Open Issues
Under the proposed mechanism, a gateway sends its IGMPv3 Reports Under the proposed mechanism, a gateway sends its IGMPv3 Reports
for MBone sources to the relay closest to itself (discovered using for MBone sources to the relay closest to itself (discovered using
the UDP encapsulated "ping"). This ensures that, as far as the UDP encapsulated "ping"). This ensures that, as far as
possible, multicast traffic flows through the native multicast possible, multicast traffic flows through the native multicast
infrastructure and the automatic multicast encapsulation is short. infrastructure and the automatic multicast encapsulation is short.
However, there might be reasons to create automatic tunnels to the However, there might be reasons to create automatic tunnels to the
relay closest to the MBone source instead. An ISP, for example, relay closest to the MBone source instead. An ISP, for example,
skipping to change at page 17, line 5 skipping to change at page 17, line 32
While injecting routes for its sources into the M-RIB, such an ISP While injecting routes for its sources into the M-RIB, such an ISP
might, for example, use a new BGP attribute to convey the address might, for example, use a new BGP attribute to convey the address
of the preferred relay. This would let other relays redirect any of the preferred relay. This would let other relays redirect any
IGMP Reports to the preferred relay by sending a UDP encapsulated IGMP Reports to the preferred relay by sending a UDP encapsulated
ICMP Redirect. ICMP Redirect.
An IGMP Report sent by a gateway to the relay closest to it would An IGMP Report sent by a gateway to the relay closest to it would
consist of the following packet: consist of the following packet:
Draft AMT February 2001
OuterIP [UDP [InnerIP [IGMP Report]]] OuterIP [UDP [InnerIP [IGMP Report]]]
The relay would respond with: The relay would respond with:
OuterIP' [UDP' [InnerIP' [ICMP Redirect [InnerIP [IGMP Report]]]]] OuterIP' [UDP' [InnerIP' [ICMP Redirect [InnerIP [IGMP Report]]]]]
An ICMP Redirect contains the first 64 bits of the original packet An ICMP Redirect contains the first 64 bits of the original packet
[ICMP]. Hence the gateway would get 44 bytes (64 - sizeof(Inner [ICMP]. Hence the gateway would get 44 bytes (64 - sizeof(Inner
IP)) of the IGMP Report, enough to easily extract the (source, IP)) of the IGMP Report, enough to easily extract the (source,
group) pair, and redirect its report to the preferred gateway. group) pair, and redirect its report to the preferred gateway.
Certainly additional complexity is undesirable, so it is an open Certainly additional complexity is undesirable, so it is an open
issue as to whether redirects are needed at all. issue as to whether redirects are needed at all.
11. Authors' Addresses 11. Authors' Addresses
Dave Thaler Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Draft AMT April 2002
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
One Microsoft Way One Microsoft Way
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
skipping to change at page 18, line 5 skipping to change at page 18, line 31
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 Dirk Ooms
Alcatel Alcatel
F. Wellesplein 1, 2018 Antwerp, Belgium F. Wellesplein 1, 2018 Antwerp, Belgium
Phone: +32 3 2404732 Phone: +32 3 2404732
EMail: dirk.ooms@alcatel.be EMail: dirk.ooms@alcatel.be
Draft AMT February 2001
12. References 12. References
[6TO4] [6TO4]
Carpenter, B., and K. Moore, "Connection of IPv6 Domains via Carpenter, B., and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
[BROKER] [BROKER]
Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001. Tunnel Broker", RFC 3053, January 2001.
[ANYCAST] [ANYCAST]
C. Huitema, "An anycast prefix for 6to4 relay routers", Work C. Huitema, "An anycast prefix for 6to4 relay routers", Work
in progress, draft-ietf-ngtrans-6to4anycast-02.txt, February in progress, draft-ietf-ngtrans-6to4anycast-02.txt, February
2001. 2001.
[BGMP] [BGMP]
Thaler, D., Estrin, D., and D. Meyer, "Border Gateway Thaler, D., Estrin, D., and D. Meyer, "Border Gateway
Multicast Protocol (BGMP): Protocol Specification", Work in Multicast Protocol (BGMP): Protocol Specification", Work in
progress, draft-ietf-bgmp-spec-02.txt, November 2000. progress, draft-ietf-bgmp-spec-02.txt, November 2000.
Draft AMT April 2002
[ICMP] [ICMP]
Postel, J., "Internet Control Message Protocol", RFC 792, Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981. September 1981.
[IGMPPROXY] [IGMPPROXY]
W. Fenner, "IGMP-based Multicast Forwarding (``IGMP W. Fenner, "IGMP-based Multicast Forwarding (``IGMP
Proxying'')", Work in progress, draft-fenner-igmp- Proxying'')", Work in progress, draft-fenner-igmp-proxy-
proxy-03.txt, July 2000. 03.txt, July 2000.
[IGMP] [IGMP]
W. Fenner, "Internet Group Management Protocol, Version 2", W. Fenner, "Internet Group Management Protocol, Version 2",
RFC 2236, November 1997. RFC 2236, November 1997.
[IGMPv3] [IGMPv3]
Cain, B., Deering, S., Fenner, B., Kouvelas, I., and A. Cain, B., Deering, S., Fenner, B., Kouvelas, I., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", Thyagarajan, "Internet Group Management Protocol, Version 3",
Work in progress, draft-ietf-idmr-igmp-v3-06.txt, January Work in progress, draft-ietf-idmr-igmp-v3-06.txt, January
2001. 2001.
[PIMSM] [PIMSM]
Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering, S., Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei. Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei.
"Protocol Independent Multicast-Sparse Mode (PIM-SM): "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, June 1998. Protocol Specification", RFC 2362, June 1998.
Draft AMT February 2001
[SSM] [SSM]
Holbrook, H., and B. Cain, "Source-Specific Multicast for Holbrook, H., and B. Cain, "Source-Specific Multicast for
IP", Work in progress, draft-holbrook-ssm-arch-01.txt, IP", Work in progress, draft-holbrook-ssm-arch-01.txt,
November 2000. November 2000.
[MSNIP]
Fenner B., H. Holbrook, H., and I. Kouvelas, "Multicast
Source Notification of Interest Protocol (MSNIP)", Work in
progress, draft-ietf-idmr-msnip-01.txt, November 2001.
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied, explain it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice restriction of any kind, provided that the above copyright notice
Draft AMT April 2002
and this paragraph are included on all such copies and derivative and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not The limited permissions granted above are perpetual and will not
 End of changes. 

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