Network Working Group Alvaro Retana Internet Draft Russ White Expiration Date: April 2003 Cisco Systems, Inc. File Name: draft-retana-marp-00.txt October 2002 MultiAccess Reachability Protocol (MARP) 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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. Abstract This document defines a protocol to quickly determine the existence or aliveness of devices attached to a shared media (broadcast) subnet. While the examples used are narrowly defined for simplicity, the protocol could be applied to other situations as well. 1. Motivation There is a great deal of interest in discovering when a device drops off of a broadcast (shared) media link for various purposes, not limited to: o Loss of routing protocol neighbors. Routing protocols would like to discover the loss of a neighbor as quickly as possible so they can reconverge around the topology change, dropping as lit- tle traffic as possible. o Loss of a server. If multiple servers, offering the same Retana, White [Page 1] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) October 2002 service, exist on a segment, a device which is load balancing traffic between those servers would like to know as soon as one of them fails. Towards this end, several solutions ([ISIS_SHORT], [LSP_PING] and [FLIP], for example) have been designed, most (or all) of which rely on some sort of "fast aliveness" or "fast hello" protocol to quickly determine the failure of a node on a shared media segment. There is some question about the scalability of such protocols, since there could be hundreds of devices on a single high speed broadcast net- work, and a single device could be connected to hundreds of broadcast networks. Most devices in today's networks are not connected to a true broacast segment (such as a 10base5 coax cable), but are instead connected to a layer 2 switch (using point-to-point connections) that can deter- mine if a device is still alive based on the carrier detect circuitry at the physical or data link layers. It should be possible to somehow harness this immediate and constant status information to inform other network devices about state changes for a particular device. This document defines the MultiAccess Reachability Protocol (MARP), which allows for the fast notification of loss of connectivity to devices attached to a shared media (broadcast) subnet. 2. MARP Packet Format MARP runs directly over layer 2; all packets are sent to a well-known (TBD) multicast address specific to the underlying layer 2 media. The data portion of the packet has the following format: 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 +---------------+---------------+-------------------------------+ | Version | Length | Reserved | +---------------+---------------+-------------------------------+ | Opcode | Hold | +---------------+---------------+---------------+---------------+ | Holddown | Auth Type | Reserved | +-----------------------------------------------+---------------+ | Authentication String... | +---------------------------------------------------------------+ | | | Layer 2 Address | | | | | +---------------------------------------------------------------+ Retana, White [Page 2] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) October 2002 o Version (1 octet): Protocol version number; current version is 1. o Length (2 octets): The total length of the packet in octets. o Opcode (2 octets): A bit field containing information about how the packet should be handled (described below). o Hold (2 octets): The number of minutes the receiving device should track the list of layer 2 addresses included in the packet; note the hold time of any given entry need not match the hold time of any other entry on the network o Holddown (1 octet): The time in seconds a port which loses connectivity to the addresses listed in the packet should be held in the down state. o Authentication Type (1 octet): an unsigned integer indicating the type of authentication present (described below). o Authentication String (variable length): contains the authen- tication information. o Layer 2 Address (16 octets - more than one field may be present in a packet): each field contains one layer 2 address. The format of the address depends on the underlying media. Layer 2 addresses which are less than 16 octets in length MUST be padded with 0's on the left (msd padding). o Reserved: These fields are reserved for future use. The SHOULD be sent as 0 and ignored by the receiver. The Opcode field is used to determine how a MARP packet should be processed when it is received. o If the high order bit of this field is set, then the remain- ing 15 bits are vendor implementation specific. If clear, then the remaining 15 bits are implemented according to this document. o The two low order bits indicate the MARP packet type: 00 UPDATE: MARP servers should provide notification when reachability to the layer 2 devices listed fails. MARP clients should ignore this packet. 01 NOTIFY_HARD: Reachability to the layer 2 devices listed has failed. Only a server should send this message type. Retana, White [Page 3] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) October 2002 10 NOTIFY_SOFT: Reachability to the layer 2 devices listed may have failed. Only a server should send this message type. 11 REMOVE: MARP servers should remove the layer 2 address listed in the packet from their local MARP table. The Authentication Type field serves to indicate what type of is present in the MARP packet, as well as how long the authentication information is. 0 No authentication included (authentication string not present). 1 Plain text authentication included (authentication string is 16 octets). 2 MD5 [MD5] authentication included (authentication string is 16 octets). 3. MARP Operation Several factors were taken into consideration when designing MARP, including: o The monitored device or the monitoring device should be able to request notification of state changes. o Devices monitoring the state of other devices should be required to maintain as little state as possible. o The protocol used to signal monitoring requests and state changes should be as simple as possible to reduce any processing overhead. Three sections follow: one discusses the operation of MARP within a MARP client, while the other discusses the processing MARP packets by devices providing MARP notifications (a MARP server). Note that a single device may be a MARP server and a MARP client at the same time. Retana, White [Page 4] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) October 2002 3.1. MARP Client Operation Layer 3 devices connected to a common multiaccess layer 2 network may become MARP clients. In general, a MARP client requires that a peer (such as a routing protocol neighbor, for example) be tracked and that a notification be received if the peer is no longer reachable. Once the client has determined which peer relationships to monitor, it can: o Discover the layer 2 addresses of each adjacent peers using layer 2 to layer 3 mapping methods. o Using MARP, periodically declare their peers' layer 2 addresses as interesting to other devices connected to the network. A client may also periodically advertise its own address. The list of layer 2 addresses to be tracked must be periodically advertised before the specified Hold Time expires. A client that receives a NOTIFY_HARD or NOTIFY_SOFT message MAY use this information to reset known adjacencies, check adjacency status, or take other action as deemed appropriate locally. If a REMOVE packet is received, the client SHOULD examine the list of layer 2 addreses. If one of the addresses is still of interest to the local device, then a new UPDATE packet MUST be advertised. 3.2. MARP Server Operation In general, a MARP server is a layer 2 device that is capable of tracking the reachability of other devices on the local multiaccess segment. If a received packet is an UPDATE, for each layer 2 address listed in it, the MARP server MUST: o Examine its local connectivity tables to determine reachability to it. o If the address is found to not be reachable, then it should be silently ignored. o If the address is found to be reachable, the Hold Time MUST be set to the maximum of the current value or the time specified in the packet. The Holdown Time MUST be set to the maximum of the current value or the time specified in the packet. Retana, White [Page 5] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) October 2002 A MARP server SHOULD stop tracking any layer 2 addresses listed in a REMOVE packet. It is recommended that the server stop tracking the address only once a locally configurable grace period has expired to allow other clients to send an UPDATE if continued monitoring is required. A MARP server MUST stop tracking any layer 2 addresses listed in a NOTIFY_HARD packet. MARP servers SHOULD ignore any NOTIFY_SOFT packets. In conjunction with processing the packets as described, the server MUST also forward the packets according to the local multicast forwarding rules. If a MARP server detects loss of connectivity to a layer 2 address it is tracking (the Hold Time has not expired), it MUST send a notifica- tion (NOTIFY_HARD or NOTIFY_SOFT according to the local configura- tion). If the loss of connectivity was due to a port failure (physi- cal or logical), then the corresponding port SHOULD be maintained in the down state for the length of the corresponding Holdown Time. 4. Security Considerations This document presents a new protocol which provides a mechanism for a device to notify another device that a particular layer 2 destina- tion is no longer reachable within a given broadcast domain. One pos- sible form of attack that this new protocol would allow is to spoof MARP packets such that devices appear to be down when they are not. To alleviate this risk, MARP SHOULD be implemented with authentica- tion in some form, and the source address of MARP packets SHOULD be checked to ensure MARP updates and notifications are sourced from devices attached to the local broadcast domain. 5. IANA Considerations The section "MARP Packet Format" defines the field that make up a MARP packet and it defines meaning to some of the values in it. IANA is expected to maintain the registry for these values as follows. Version Number Field: o Version number 0 is reserved. o Version number 1 is assigned to the current version specified in this document. o Version numbers 2 through 127 MUST be assigned using the "IETF Consensus" policy defined in RFC2434 [RFC2434]. o Version numbers 128 through 191 SHOULD be assigned using the Retana, White [Page 6] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) October 2002 "Specification Required" policy defined in RFC2434 [RFC2434]. o Version numbers 192 through 255 are for "Private Use" as defined in RFC2434 [RFC2434]. Opcode Field: o Bit 15 (high order bit) is reserved to indicate if the remaining bits are vendor specific or not. o Bits 0 and 1 (two low order bits) are reserved to indicate the MARP packet type. o Bits 2 through 4 (and its combinations with bits 0 and 1) are to be used for additional MAPR packet types and SHOULD be assigned using the "IETF Consensus" policy defined in RFC2434 [RFC2434]. o Bits 5 through 9 MUST be assigned using the "IETF Consensus" policy defined in RFC243 [RFC2434]. o Bits 10 through 14 SHOULD be assigned using the "Specification Required" policy defined in RFC2434 [RFC2434]. Reserved Field: This field, or parts of it, MUST be assigned using the "IETF Consensus" policy defined in RFC2434 [RFC2434]. Authentication Type Field: o Types 0 through 2 are explicitly defined in this document. o Authentication Type values 3 thru 63 MUST be assigned using the "IETF Consensus" policy defined in RFC2434 [RFC2434]. o Authentication Type values 64 thru 127 SHOULD be assigned using the "Specification Required" policy defined in RFC2434 [RFC2434]. o Authentication Type values 128 thru 255 are for "Private Use" as defined in RFC2434 [RFC2434]. Retana, White [Page 7] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) October 2002 6. Intellectual Property Considerations Cisco Systems may seek patent or other intellectual property protec- tion for some or all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Cisco Systems, Cisco intends to disclose those patents and license them on reasonable and non- discriminatory terms. 7. Security Considerations This document defines a new protocol that operates directly over a layer 2 transport. The protocol is used to determine the existence (or not) of other devices on a multiaccess network. While the threat zone is limited to only the local layer 2 segment, it is recommended that authentication be used to minimize the threat of false (or spoofed) notifications of lost connectivity. 8. Acknowledgements We want to acknowledge David Oran, who had the original idea from which MARP grew. We would like to thank all the people (too many to list individually) for their valuable input. 9. References [ISIS_SHORT] Parker, J., McPherson, D., and Alaettinoglu, Cengiz, "Short Adja- cency Hold Times in IS-IS", Work In Progress (draft-parker-short- isis-hold-times-01.txt), July 2001. [LSP_PING] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow, G., Wadhwa, S., and Bonica, R., "Detecting Data Plane Liveliness in MPLS", Work In Progress (draft-ietf-mpls-lsp-ping-00.txt), March 2002. [FLIP] Sandick, H., Squire, M., Cain, B., Duncan, I., Haberman, B., "Fast LIveness Protocol (FLIP)", Work In Progress (draft-sandiick-flip- 00.txt), February 2000. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, April 1992. Retana, White [Page 8] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) October 2002 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Con- siderations Section in RFCs", RFC 2434, BCP 26, October, 1998. 10. Authors' Addresses Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 EMail: aretana@cisco.com Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 EMail: riw@cisco.com Retana, White [Page 9]