such address to the node’s RID.
10.5. Support for Network Prefixes
MANET routers may advertise network prefixes which the router
discovered via attached networks, external routes advertised by other
protocols, or other means. Network prefixes are advertised in
NETWORK PREFIX ASSOCIATION messages, which bind each such prefix to
the node’s RID.
10.6. Support for non-MANET Hosts
Non-MANET hosts may establish connections to MANET routers through
on-demand mechanisms such as ARP or IPv6 Neighbor Discovery. Such
connections do not constitute a MANET link and therefore are not
reported in TBRPF topology updates. Non-MANET hosts are advertised
in HOST ASSOCIATION messages, which bind the IP address of each host
to the node’s RID.
10.7. Internet Protocol Considerations
TBRPF packets are communicated using UDP/IP. Port 712 has been
assigned by IANA for exclusive use by TBRPF. Implementations in
private networks MAY employ alternate data delivery services (i.e.,
raw IP or local data-link encapsulation). The selection of an
alternate data delivery service MUST be consistent among all MANET
routers in the private network. In all implementations, the data
delivery service MUST provide a checksum facility.
The following sections specify the operation of TBRPF over UDP/IP.
10.7.1. IPv4 Operation
When IPv4 is used, TBRPF nodes obey IPv4 host and router requirements
[4][5]. TBRPF packets are sent to the multicast address 224.0.0.2
(All Routers) and thus reach all TBRPF routers within single-hop
transmission range of the sender. TBRPF routers MUST NOT forward
packets sent to this multicast address.
Since non-negligible packet loss due to link failure, interference,
etc. can occur, implementations SHOULD avoid IPv4 fragmentation/
reassembly whenever possible, by splitting large TBRPF protocol
packets into multiple smaller packets at the application layer. When
fragmentation is unavoidable, senders SHOULD NOT send TBRPF packets
that exceed the minimum reassembly buffer size ([4], section 3.3.2)
for all receivers in the network.
10.7.2. IPv6 Operation
The specification of TBRPF for IPv6 is the same as for IPv4, except
that 32-bit IPv4 addresses are replaced by 128-bit IPv6 addresses.
However, to minimize overhead, router IDs remain at 32 bits, similar
to OSPF for IPv6 [18].
11. IANA Considerations
The IANA has assigned port number 712 for TBRPF.
The TBRPF flooding mechanism specified in this document uses the IPv4
multicast address 224.0.1.20, which is currently assigned by IANA for
"any private experiment". In the event that this specification is
advanced to standards track, a new multicast address assignment would
be requested for this purpose.
12. Security Considerations
Wireless networks are vulnerable to a variety of attacks, including
denial-of-service attacks (e.g., flooding and jamming), man-in-the-
middle attacks (e.g., interception, insertion, deletion,
modification, replaying) and service theft. To counter such attacks,
it is important to prevent the spoofing (impersonation) of TBRPF
nodes, and to prevent unauthorized nodes from joining the network via
neighbor discovery. To achieve this, TBRPF packets can be
authenticated using the IP Authentication Header [19][20]. In
addition, the Encapsulating Security Payload (ESP) header [21] can be
used to provide confidentiality (encryption) of TBRPF packets.
The IETF SEcuring Neighbor Discovery (SEND) Working Group analyzes
trust models and threats for ad hoc networks [22]. TBRPF can be
extended in a straightforward manner to use SEND mechanisms, e.g.,
[23].
13. Acknowledgements
The authors would like to thank the Army Systems Engineering Office
(ASEO) for funding part of this work.
The authors would like to thank several members of the MANET working
group for many helpful comments and suggestions, including Thomas
Clausen, Philippe Jacquet, and Joe Macker.
The authors would like to thank Bhargav Bellur for major
contributions to the original (full-topology) version of TBRPF,
Ambatipudi Sastry for his support and advice, and Julie S. Wong for
developing a new implementation of TBRPF and suggesting several
clarifications to the TBRPF Routing Operation section.
14. References
14.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[4] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[5] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
14.2. Informative References
[6] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[7] Ogier, R., Message in IETF email archive for MANET,
ftp://ftp.ietf.org/ietf-mail-archive/manet/2002-02.mail,
February 2002.
[8] Ogier, R., "Topology Dissemination Based on Reverse-Path
Forwarding (TBRPF): Correctness and Simulation Evaluation",
Technical Report, SRI International, October 2003.
[9] Ogier, R., Message in IETF email archive for MANET,
ftp://ftp.ietf.org/ietf-mail-archive/manet/2002-03.mail, March
2002.
[10] Ogier, R., "Efficient Routing Protocols for Packet-Radio
Networks Based on Tree Sharing", Proc. Sixth IEEE Intl. Workshop
on Mobile Multimedia Communications (MOMUC’99), November 1999.
[11] Bellur, B. and R. Ogier, "A Reliable, Efficient Topology
Broadcast Protocol for Dynamic Networks", Proc. IEEE INFOCOM
’99, New York", March 1999.
[12] Clausen, T. and P. Jacquet, Eds., "Optimized Link State Routing
Protocol (OLSR)", RFC 3626, October 2003.
[13] Bertsekas, D. and R. Gallager, "Data Networks", Prentice-Hall,
1987.
[14] Perkins, C., Belding-Royer, E. and S. Das, "IP Flooding in Ad
Hoc Mobile Networks", Work in Progress, November 2001.
[15] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet address
for transmission on Ethernet hardware", STD 37, RFC 826,
November 1982.
[16] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[17] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[18] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740,
December 1999.
[19] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[20] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[22] Nikander, P., "IPv6 Neighbor Discovery Trust Models and
Threats", Work in Progress, April 2003.
[23] Arkko, J., "SEcure Neighbor Discovery (SEND)", Work in Progress,
June 2003.
Authors’ Addresses
Richard G. Ogier
SRI International
333 Ravenswood Ave.
Menlo Park, CA 94025
USA
Phone: +1 650 859-4216
Fax: +1 650 859-4812
EMail: ogier@erg.sri.com
Fred L. Templin
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1 650 625 2331
Fax: +1 650 625 2502
EMail: ftemplin@iprg.nokia.com
Mark G. Lewis
SRI International
333 Ravenswood Ave.
Menlo Park, CA 94025
USA
Phone: +1 650 859-4302
Fax: +1 650 859-4812
EMail: lewis@erg.sri.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.