(2) A ZBR signs a ZAM it relays if and only if it can authenticate
the previous sender. A ZBR MUST still forward un-authenticated
ZAMs (to provide leak detection), but should propagate an
authenticated ZAM even if an un-authenticated one was received
with the last [ZAM-DUP-TIME] seconds.
(3) A MAAS SHOULD be configured with the public key of the local zone
in which it resides. A MAAS thus configured SHOULD ignore an
unauthenticated ZAM if an authenticated one for the same scope
has been received, and MAY ignore all unauthenticated ZAMs.
9. Acknowledgements
This document is a product of the MBone Deployment Working Group,
whose members provided many helpful comments and suggestions, Van
Jacobson provided some of the original ideas that led to this
protocol. The Multicast Address Allocation Working Group also
provided useful feedback regarding scope names and interactions with
applications.
10. References
[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[3] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast
Address Allocation Architecture", Work in Progress.
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[5] Fenner, W. and S. Casner, "A `traceroute' facility for IP
Multicast", Work in Progress.
[6] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995.
[7] Handley, M. and S. Hanna. "Multicast Address Allocation
Protocol (AAP)", Work in Progress.
[8] Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward
Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998,
Vancouver, Canada.
[9] Hanna, S., Patel, B., and M. Shah. "Multicast Address Dynamic
Client Allocation Protocol (MADCAP)", RFC2730, December 1999.
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994.
[11] IANA, "Address Family Numbers", http://www.isi.edu/in-
notes/iana/assignments/address-family-numbers
[12] Kent, S. and R. Atkinson, "IP Authentication Header", RFC2402,
November 1998.
11. Authors' Addresses
Mark Handley
AT&T Center for Internet Research at ICSI
1947 Center St, Suite 600
Berkely, CA 94704
USA
EMail: mjh@aciri.org
David Thaler
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
EMail: dthaler@microsoft.com
Roger Kermode
Motorola Australian Research Centre
12 Lord St,
Botany, NSW 2019
Australia
EMail: Roger.Kermode@motorola.com
12. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 RFCEditor function is currently provided by the
Internet Society.