Internet Engineering Task Force S. SUZUKI
Internet-Draft Hitachi, Ltd.
Expires: August 2, 2003 T. JINMEI
Toshiba Corporation
Feb 2003
PIM upstream detection among multiple addresses
draft-suz-pim-upstream-detection-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 2, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo describes a PIM routing problem owing to the reverse path
forwarding (RPF) failure on routers having multiple addresses on a
link. This memo also considers possible solutions with their pros
and cons. The solutions include operational one which does not
require any protocol change, and one which uses a new PIM Hello
option. However, it is beyond the scope of this memo to discuss what
is the most appropriate solution for this problem.
SUZUKI & JINMEI Expires August 2, 2003 [Page 1]
Internet-Draft PIM Upstream Detection among Addresses Feb 2003
Table of Contents
1. Overview of the problem . . . . . . . . . . . . . . . . . . . 3
2. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Avoid such situation by operation . . . . . . . . . . . . . . 5
2.2 Use a new PIM Hello option . . . . . . . . . . . . . . . . . . 6
2.3 Use a separate protocol . . . . . . . . . . . . . . . . . . . 7
2.4 Loosen the PIM protocol . . . . . . . . . . . . . . . . . . . 8
3. Security considerations . . . . . . . . . . . . . . . . . . . 9
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . . 11
Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
SUZUKI & JINMEI Expires August 2, 2003 [Page 2]
Internet-Draft PIM Upstream Detection among Addresses Feb 2003
1. Overview of the problem
The PIM protocol uses the reverse path forwarding (RPF) algorithm to
detect an upstream PIM router with respect to the address of a packet
sender or a rendezvous point (RP) router [1].
The RPF algorithm requires a look-up in a multicast routing
information base (multicast RIB, which is normally derived from
unicast routing table, but may be from other routing protocols such
as MBGP [2]) to find the next hop address for a given address. If
the next hop address matches with the address of a PIM neighbor then
that PIM neighbor can be regarded as the upstream PIM router for the
address. The address of the upstream neighbor is then used in the
Upstream Neighbor Address field of Join/Prune or Graft messages.
The address of a PIM neighbor is given as the source address of PIM
Hello messages from the neighbor. The PIM protocol specifies to use
a link-local address for this purpose. (Note: it is not very clear
what "link-local" means for IPv4, but link-local addresses are well-
defined for IPv6.)
The entire procedure to detect the upstream address assumes the
address of a PIM neighbor is always same as the address of the next
hop router, as long as they refer to the same router. This is
typically the case for IPv4, and so is for IPv6 when an Interior
Gateway Protocol is used to build the multicast RIB. In general,
however, it may not be the case when a router has multiple addresses
on a link.
Suppose a router-A has address-A1 and address-A2 on a link and it
establishes a PIM neighboring with a router-B using address-A1.
address-A1 PIM neighbor = address-A1
address-A2 next-hop to S = address-A2
S----router-A ------|------- router-B
When router-B tries to detect an upstream router for a source address
S, router-B cannot detect an upstream PIM router even though its RPF
calculation says the S's upstream is address-A2, because router-B
does not know address-A2 and address-A1 refer to the same router. In
this case, router-B does not create Join/Prune or Graft messages for
S, and PIM does not work correctly.
There are two typical cases that lead to this situation for IPv6.
The first case can occur when the multicast RIB is not built by an
IPv6 Interior Gateway Protocol. This includes static routing and
MBGP. The second case occurs when the address of RP shares a subnet
prefix with down stream routers (note that the RP router's address
SUZUKI & JINMEI Expires August 2, 2003 [Page 3]
Internet-Draft PIM Upstream Detection among Addresses Feb 2003
has to be domain-wide and thus cannot be a link-local address).
The following figure depicts the second case.
fe80::1 PIM neighbor = fe80::1
2001:db8::1 RP(G) = 2001:db8::1
RP router ---------|---------- router
2001:db8::/64
Since this issue can happen in some typical cases for IPv6, the issue
has to be resolved in some manner, in order to deploy IPv6
multicasting (with PIM).
SUZUKI & JINMEI Expires August 2, 2003 [Page 4]
Internet-Draft PIM Upstream Detection among Addresses Feb 2003
2. Possible solutions
There are four possible solutions to this problem. This section
describes their details and their pros and cons.
o Avoid such situation by operation
o Use a new PIM Hello option
o Use a separate protocol
o Loosen the PIM protocol
2.1 Avoid such situation by operation
There is operational workaround for this problem.
When manually specifying an upstream router's address, it is always
possible to use a link-local address. When using MBGP, a link-local
next hop address can be specified if the BGP peering is single-hop
and a separate non link-local prefix is shared on the peering link
[3].
The problem occurring when a RP shares a subnet prefix with
downstream routers can also be avoided by using a separate RP
address. In this case, the RP address has to be picked up from some
link whose prefix is not shared with any downstream routers. One
practical way to implement this would be to choose a new prefix and
assign an address derived by the prefix to a loopback interface.
Another possible approach is to advertise a host route for the
upstream address in the routing protocol used to build multicast RIB.
This can work unless static routing is used, and if the host route
does not interfere with other intra-link information, such as IPv6
Neighbor Discovery (ND) or IPv4 Address Resolution Protocol (ARP).
All of the approaches will work without any protocol extensions.
However, they impose additional costs in operation and/or restrict
flexibility in operation.
pro = Does not need to change anything in the PIM protocol.
con = Imposes additional costs in operation, and/or restricts
operational flexibility.
SUZUKI & JINMEI Expires August 2, 2003 [Page 5]
Internet-Draft PIM Upstream Detection among Addresses Feb 2003
2.2 Use a new PIM Hello option
This is a solution to let the PIM protocol avoid such situation by
adding a PIM hello message option including all the addresses on the
interface where PIM hello message is advertised.
When a PIM router finds an upstream router for some address, the
result of RPF calculation is compared with the addresses in this
option, in addition to PIM neighbor's address itself. Since this
option includes all the possible addresses of a PIM router on that
link, it always includes the RPF calculation result if it refers to
the PIM router supporting this option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address-List |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : TBD (All vendors supporting this option use 65001)
Length : The Length of the Address-List field in byte.
Address-List: The list of the IP addresses of the router on the link
where this Hello message is advertised. Each IP address is
encoded in Encoded-Unicast format [1].
This approach does not require a separate configuration to deal with
the problem, because the address mapping is provided automatically.
Thus, this approach reduces the operational costs comparing to the
first solution.
Furthermore, since this is an optional attribute in PIM hello
message, PIM implementations not supporting this option do not have
any problem in PIM routing, unless the problem described here does
not occur.
pro = Does not increase operational cost. Keeps flexibility of
configuration.
con = Requires a change (an extension) in the PIM protocol, and
increases implementation cost.
SUZUKI & JINMEI Expires August 2, 2003 [Page 6]
Internet-Draft PIM Upstream Detection among Addresses Feb 2003
2.3 Use a separate protocol
This solution is similar to the previous one except for the protocol
to be used; this solution assumes the existence of some other
protocol to detect a list of addresses that point to the same node
pointed by the given address.
One possible example is to use a protocol to resolve link-layer
addresses. IPv6 ND or IPv4 ARP is available for this purpose. With
this approach, the downstream router resolves the link-layer address
both for the upstream router address and for the PIM neighbor
address. If the link-layer addresses coincides, the corresponding
layer 3 addresses are regarded to specify a same node.
IPv6 also has a dedicated layer 3 protocol that can be used for this
purpose; ICMPv6 Node Information Query [4] using Node Addresses query
type.
These protocols can provide a complete mapping among PIM neighbor
addresses and upstream router addresses. Thus, they can solve the
problem just like the solution described in the previous section.
It does not increase operational costs, just like the previous
solution. This approach does not require any change in the PIM
protocol, either. However, PIM implementations will need to be
modified to solve the PIM-specific problem using the separate
protocol.
Additionally, there is limitation on applicability of this approach.
ND or ARP does not work to solve the problem on a link that does not
need to resolve link-layer addresses (e.g. a point-to-point link).
Also, in theory, different layer-3 addresses on one interface may be
mapped to different link-layer addresses resolved by ND or ARP.
Though this should be practically rare, ND or ARP does not work in
this case, either.
There may be a different kind of clue for this mapping in such cases.
For example, in case of point-to-point link, addresses not belonging
to one side should belong to the other side of the link. The
implementation can also use inverse ARP [5] or inverse ND [6] to deal
with these cases. However, an exceptional rule has to be implemented
in addition to ND or ARP, which may increase implementation costs.
ICMPv6 Node Information Query, particularly the Node Addresses query
type, is not widely implemented. This means the protocol cannot be
used as a solution today, and will increase implementation cost for
router developers.
SUZUKI & JINMEI Expires August 2, 2003 [Page 7]
Internet-Draft PIM Upstream Detection among Addresses Feb 2003
The use of a separate protocol also requires additional process to
ensure consistency of the mapping. In the first place, there is no
guarantee that the mapping is provided when it is necessary in the
PIM protocol. Thus, implementation may have to invoke the other
protocol after it noticed the need for the mapping. This can delay
the detection procedure. Secondly, in order to follow address
changes, it is necessary for the downstream router to poll the
neighbor's address periodically.
pro = Does not increase operational cost. Keeps flexibility of
configuration.
con = May require additional implementation cost.
con = May require additional consideration (and implementation costs
as a result) for corner cases or to ensure consistency.
2.4 Loosen the PIM protocol
The problem can be solved by loosening restrictions of the PIM
protocol. For example, the loosened protocol would allow a router to
specify a non-link-local address as the Upstream Neighbor Address of
Join/Prune or Graft messages. If the upstream router does not check
if the Upstream Neighbor Address is link-local, the corresponding
part of the PIM protocol should still work.
However, this solution itself does not provide a mapping between the
address of a PIM neighbor and the RPF upstream address corresponding
to the neighbor. Thus, the downstream router cannot make fast
retransmission of Join/Prune messages when the router detects
recovery from failure of an upstream router by Generation ID.
This approach may require further changes in the PIM protocol in the
future, if the protocol has a new header field where an upstream
neighbor address should be specified.
pro = Does not increase operational cost. Keeps flexibility of
configuration.
con = Requires a change in the PIM protocol
con = Not a complete solution. It would hinder the optimization by
Generation ID.
SUZUKI & JINMEI Expires August 2, 2003 [Page 8]
Internet-Draft PIM Upstream Detection among Addresses Feb 2003
3. Security considerations
When using the new PIM hello option described in Section Section 2.2,
a forged message can be used to hijack a multicast distribution path
or to cause a denial of service attack. However, since the use of
PIM hello messages is limited to a single link, such attacks cannot
be made off-link. Additionally, these attacks within a single link
can be done using existing PIM messages. The new PIM hello option
thus does not increase the security threat of the existing PIM
protocol.
SUZUKI & JINMEI Expires August 2, 2003 [Page 9]
Internet-Draft PIM Upstream Detection among Addresses Feb 2003
4. Acknowledgements
We would like to express thanks to Pekka Savola, Dave Thaler, and
Brian Haberman for their valuable comments.
SUZUKI & JINMEI Expires August 2, 2003 [Page 10]
Internet-Draft PIM Upstream Detection among Addresses Feb 2003
Normative References
[1] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol
Independent Multicast Sparse Mode (revised)", Internet Draft
draft-ietf-pim-sm-v2-new-06.txt, December 2002.
[2] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol
Extensions for BGP-4", RFC 2858, June 2000.
[3] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[4] Crawford, M., "IPv6 Node Information Queries", Internet Draft
draft-ietf-ipngwg-icmp-name-lookups-09.txt, May 2002.
[5] Bradley, T., Brown, C. and A. Malis, "Inverse Address Resolution
Protocol", RFC 2390, August 1998.
[6] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse
Discovery Specification", RFC 3122, June 2001.
SUZUKI & JINMEI Expires August 2, 2003 [Page 11]
Internet-Draft PIM Upstream Detection among Addresses Feb 2003
Informative References
Authors' Addresses
SUZUKI Shinsuke
Hitachi, Ltd.
1-280 Higashi-Koigakubo
Kokubunji-shi, Tokyo 185-8601
Japan
EMail: suz@crl.hitachi.co.jp
JINMEI Tatuya
Toshiba Corporation
1 Komukai Toshiba-cho
Kawasaki-shi, Kanagawa 212-8582
Japan
EMail: jinmei@isl.rdc.toshiba.co.jp
SUZUKI & JINMEI Expires August 2, 2003 [Page 12]
Internet-Draft PIM Upstream Detection among Addresses Feb 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
SUZUKI & JINMEI Expires August 2, 2003 [Page 13]