idnits 2.17.1 draft-li-hsrp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 764 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 35 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 116: '...ress. The IP address SHOULD belong to...' RFC 2119 keyword, line 117: '...e on the LAN, but MUST differ from the...' RFC 2119 keyword, line 151: '... MUST, SHALL, or MANDATORY -- the...' RFC 2119 keyword, line 154: '... SHOULD or RECOMMENDED -- the ite...' RFC 2119 keyword, line 157: '... MAY or OPTIONAL -- the item is t...' (38 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If an HSRP router is configured to support proxy ARP with HSRP, then the router MUST specify the HSRP virtual MAC address in any proxy ARP responses it generates. These proxy ARP responses MUST not be suppressed based upon HSRP state. Suppression based upon state could result in lack of any proxy ARP response being generated, since these proxy ARP responses may be suppressed due to other reasons, such as split-horizon rules. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Li 2 INTERNET DRAFT Juniper Networks 3 B. Cole 4 Juniper Networks 5 P. Morton 6 Cisco Systems 7 D. Li 8 Cisco Systems 10 Hot Standby Router Protocol (HSRP) 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net (US East Coast), nic.nordu.net 27 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 28 Rim). Distribution of this memo is unlimited. 30 Abstract 32 The memo specifies the Hot Standby Router Protocol (HSRP). The goal 33 of the protocol is to allow hosts to appear to use a single router 34 and to maintain connectivity even if the actual first hop router they 35 are using fails. Multiple routers participate in this protocol and 36 in concert create the illusion of a single virtual router. The 37 protocol insures that one and only one of the routers is forwarding 38 packets on behalf of the virtual router. End hosts forward their 39 packets to the virtual router. 41 The router forwarding packets is known as the active router. A 42 standby router is selected to replace the active router should it 43 fail. The protocol provides a mechanism for determining active and 44 standby routers, using the IP addresses on the participating routers. 45 If an active router fails a standby router can take over without a 46 major interruption in the host's connectivity. This memo also 47 discusses the ARP, MAC address, and security issues with this 48 protocol. 50 TABLE OF CONTENTS 52 1 Introduction 53 2 Conditions of Use 54 3 Scope 55 3.1 Terminology 56 4 Definitions 57 5 Protocol 58 5.1 Packet formats 59 5.2 Operational parameters 60 5.3 States 61 5.4 Timers 62 5.5 Events 63 5.6 Actions 64 5.7 State Transitions 65 6 MAC address considerations 66 6.1 General 67 6.2 Address Filter 68 6.3 ICMP Redirect 69 6.4 Proxy ARP 70 7 Security Considerations 71 8 References 72 9 Authors' Addresses 74 1. Introduction 76 The Hot Standby Router Protocol, HSRP, provides a mechanism which is 77 designed to support non-disruptive failover of IP traffic in certain 78 circumstances. In particular, the protocol protects against the 79 failure of the first hop router when the source host cannot learn the 80 IP address of the first hop router dynamically. The protocol is 81 designed for use over multi-access, multicast or broadcast capable 82 LANs (e.g., Ethernet). HSRP is not intended as a replacement for 83 existing dynamic router discovery mechanisms and those protocols 84 should be used instead whenever possible. [1] A large class of 85 legacy host implementations that do not support dynamic discovery are 86 capable of configuring a default router. HSRP provides failover 87 services to those hosts. 89 All of the routers participating in HSRP are assumed to be running 90 appropriate IP routing protocols and have a consistent set of routes. 91 The discussion of which protocols are appropriate and whether routing 92 is consistent in any given situation is beyond the scope of this 93 specification. 95 Using HSRP, a set of routers work in concert to present the illusion 96 of a single virtual router to the hosts on the LAN. This set is 97 known as an HSRP group or a standby group. A single router elected 98 from the group is responsible for forwarding the packets that hosts 99 send to the virtual router. This router is known as the active 100 router. Another router is elected as the standby router. In the 101 event that the active router fails, the standby assumes the packet 102 forwarding duties of the active router. Although an arbitrary number 103 of routers may run HSRP, only the active router forwards the packets 104 sent to the virtual router. 106 To minimize network traffic, only the active and the standby routers 107 send periodic HSRP messages once the protocol has completed the 108 election process. If the active router fails, the standby router 109 takes over as the active router. If the standby router fails or 110 becomes the active router, another router is elected as the standby 111 router. 113 On a particular LAN, multiple hot standby groups may coexist and 114 overlap. Each standby group emulates a single virtual router. For 115 each standby group, a single well-known MAC address is allocated to 116 the group, as well as an IP address. The IP address SHOULD belong to 117 the primary subnet in use on the LAN, but MUST differ from the 118 addresses allocated as interface addresses on all routers and hosts 119 on the LAN, including virtual IP addresses assigned to other HSRP 120 groups. 122 If multiple groups are used on a single LAN, load splitting can be 123 achieved by distributing hosts among different standby groups. 125 The remainder of this specification discusses the operation of a 126 single standby group. In the case of multiple groups, each group 127 operates independently of other groups on the LAN and according to 128 this specification. Note that individual routers may participate in 129 multiple groups. In this case, the router maintains separate state 130 and timers for each group. 132 2 Conditions of Use 134 US Patent number 5,473,599 [2], assigned to Cisco Systems, Inc. may 135 be applicable to HSRP. If an implementation requires the use of any 136 claims of patent no. 5,473,599, Cisco will license such claims on 137 reasonable, nondiscriminatory terms for use in practicing the 138 standard. More specifically, such license will be available for a 139 one-time, paid up fee. 141 3 Scope 143 This document describes the packets, messages, states, and events 144 used to implement the protocol. It does not discuss network 145 management or internal implementation issues. 147 3.1 Terminology 149 The following language conventions are used in this document: 151 MUST, SHALL, or MANDATORY -- the item is an absolute requirement 152 of the specification. 154 SHOULD or RECOMMENDED -- the item should generally be followed for 155 all but exceptional circumstances. 157 MAY or OPTIONAL -- the item is truly optional and may be followed 158 or ignored according to the needs of the implementation. 160 4 Definitions 162 Active Router - the router that is currently forwarding packets 163 for the virtual router 165 Standby Router - the primary backup router 167 Standby Group - the set of routers participating in HSRP that 168 jointly emulate a virtual router 170 Hello Time - the interval between successive HSRP Hello 171 messages from a given router 173 Hold Time - the interval between the receipt of a Hello 174 message and the presumption that the sending 175 router has failed 177 5 Protocol 179 Within a standby group, the routers periodically advertise state 180 information using various messages. 182 5.1 Packet formats 184 The standby protocol runs on top of UDP, and uses port number 185 1985. Packets are sent to multicast address 224.0.0.2 with TTL 1. 187 Routers use their actual IP address as the source address for 188 protocol packets, not the virtual IP address. This is necessary 189 so that the HSRP routers can identify each other. 191 The format of the data portion of the UDP datagram is: 193 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Version | Op Code | State | Hellotime | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Holdtime | Priority | Group | Reserved | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Authentication Data | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Authentication Data | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Virtual IP Address | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Version: 1 octet 209 The version of the HSRP messages. This document describes 210 version 0. 212 Op Code: 1 octet 214 The Op Code describes the type of message contained in this 215 packet. Possible values are: 217 0 - Hello 218 1 - Coup 219 2 - Resign 221 Hello messages are sent to indicate that a router is running 222 and is capable of becoming the active or standby router. 224 Coup messages are sent when a router wishes to become the 225 active router. 227 Resign messages are sent when a router no longer wishes to be 228 the active router. 230 State: 1 octet 232 Internally, each router in the standby group implements a state 233 machine. The State field describes the current state of the 234 router sending the message. Details on the individual states 235 are described below. Possible values are: 237 0 - Initial 238 1 - Learn 239 2 - Listen 240 4 - Speak 241 8 - Standby 242 16 - Active 244 Hellotime: 1 octet 246 This field is only meaningful in Hello messages. It contains 247 the approximate period between the Hello messages that the 248 router sends. The time is given in seconds. 250 If the Hellotime is not configured on a router, then it MAY be 251 learned from the Hello message from the active router. The 252 Hellotime SHOULD only be learned if no Hellotime is configured 253 and the Hello message is authenticated. A router that sends a 254 Hello message MUST insert the Hellotime that it is using in the 255 Hellotime field in the Hello message. If the Hellotime is not 256 learned from a Hello message from the active router and it is 257 not manually configured, a default value of 3 seconds is 258 RECOMMENDED. 260 Holdtime: 1 octet 262 This field is only meaningful in Hello messages. It contains 263 the amount of time that the current Hello message should be 264 considered valid. The time is given in seconds. 266 If a router sends a Hello message, then receivers should 267 consider that Hello message to be valid for one Holdtime. The 268 Holdtime SHOULD be at least three times the value of the 269 Hellotime and MUST be greater than the Hellotime. If the 270 Holdtime is not configured on a router, then it MAY be learned 271 from the Hello message from the active router. The Holdtime 272 SHOULD only be learned if the Hello message is authenticated. 273 A router that sends a Hello message MUST insert the Holdtime 274 that it is using in the Holdtime field in the Hello message. 276 A router which is in active state MUST NOT learn new values for 277 the Hellotime and the Holdtime from other routers, although it 278 may continue to use values which it learned from the previous 279 active router. It MAY also use the Hellotime and Holdtime 280 values learned through manual configuration. The active router 281 MUST NOT use one configured time and one learned time. If the 282 Holdtime is not learned and it is not manually configured, a 283 default value of 10 seconds is RECOMMENDED. 285 Priority: 1 octet 287 This field is used to elect the active and standby routers. 288 When comparing priorities of two different routers, the router 289 with the numerically higher priority wins. In the case of 290 routers with equal priority the router with the higher IP 291 address wins. 293 Group: 1 octet 295 This field identifies the standby group. For Token Ring, 296 values between 0 and 2 are valid. For other media values 297 between 0 and 255 are valid. 299 Authentication Data: 8 octets 301 This field is used to authenticate HSRP messages. If the 302 authentication data matches a corresponding value configured in 303 the router, then the message is considered authentic. The 304 authentication is only used to validate dynamic acquisition of 305 the virtual IP address and timer values from an active router. 307 If no authentication data is configured, the RECOMMENDED 308 default value is 0x63 0x69 0x73 0x63 0x6F 0x00 0x00 0x00. 310 Virtual IP Address: 4 octets 312 The virtual IP address used by this group. 314 If the virtual IP address is not configured on a router, then 315 it MAY be learned from the Hello message from the active 316 router. An address SHOULD only be learned if no address was 317 configured and the Hello message is authenticated. 319 5.2 Operational parameters 321 The following information MUST be known to each router in the 322 standby group. The mechanisms used to determine this information 323 are outside of the scope of this document. 325 Standby group number 327 Virtual MAC address 329 Priority 331 Authentication Data 333 Hellotime 335 Holdtime 337 The following information MUST be known to at least one router in 338 each standby group and MAY be known by any of the other routers in 339 the group. 341 Virtual IP Address 343 The following information MAY be configured on any router: 345 Preemption capability 347 If a router has higher priority than the active router and 348 preemption is configured, it MAY take over as the active 349 router using a Coup message. 351 5.3 States 353 Each router in the group participates in the protocol by implementing 354 a simple state machine. This specification describes the externally 355 visible behavior of this state machine. Implementations MAY vary 356 their internal implementations within the functional description of 357 the state machine. 359 All routers begin in the Initial state. This section discusses the 360 intent of each state. For specific details on the actions taken in 361 each state, please see the state transition table in section 5.7. 363 1. Initial 365 This is the starting state and indicates that HSRP is not running. 366 This state is entered via a configuration change or when an 367 interface first comes up. 369 2. Learn 371 The router has not determined the virtual IP address, and not yet 372 seen an authenticated Hello message from the active router. In 373 this state the router is still waiting to hear from the active 374 router. 376 3. Listen 378 The router knows the virtual IP address, but is neither the active 379 router nor the standby router. It listens for Hello messages from 380 those routers. 382 4. Speak 384 The router sends periodic Hello messages and is actively 385 participating in the election of the active and/or standby router. 386 A router cannot enter Speak state unless it has the virtual IP 387 address. 389 5. Standby 391 The router is a candidate to become the next active router and 392 sends periodic Hello messages. Excluding transient conditions, 393 there MUST be at most one router in the group in Standby state. 395 6. Active 397 The router is currently forwarding packets that are sent to the 398 group's virtual MAC address. The router sends periodic Hello 399 messages. Excluding transient conditions, there MUST be at most 400 one router in Active state in the group. 402 5.4 Timers 404 Each router maintains three timers, an Active timer, a Standby timer, 405 and a Hello timer. 407 The Active timer is used to monitor the active router. The active 408 timer is started anytime an authenticated Hello message is seen from 409 the active router. It is set to expire in the Holdtime seen in the 410 Hello message. 412 The Standby timer is used to monitor the standby router The Standby 413 timer is started anytime an authenticated Hello message is seen from 414 the standby router. It is set to expire in the Holdtime seen in the 415 Hello message. 417 The Hello timer expires once per Hellotime period. If the router is 418 in Speak, Standby, or Active states, it should generate a Hello 419 message upon Hello timer expiry. The Hello timer MUST be jittered. 421 5.5 Events 423 These are the events in the HSRP finite state machine. 425 a - HSRP is configured on an enabled interface. 427 b - HSRP is disabled on an interface or the interface is disabled. 429 c - Active timer expiry. The Active timer was set to the Holdtime 430 when the last Hello message was seen from the active router. 432 d - Standby timer expiry. The Standby timer was set to the 433 Holdtime when the last Hello message was seen from the standby 434 router. 436 e - Hello timer expiry. The periodic timer for sending Hello 437 messages has expired. 439 f - Receipt of a Hello message of higher priority from a router in 440 Speak state. 442 g - Receipt of a Hello message of higher priority from the active 443 router. 445 h - Receipt of a Hello message of lower priority from the active 446 router. 448 i - Receipt of a Resign message from the active router. 450 j - Receipt of a Coup message from a higher priority router. 452 k - Receipt of a Hello message of higher priority from the standby 453 router. 455 l - Receipt of a Hello message of lower priority from the standby 456 router. 458 5.6 Actions 460 This section specifies the actions to be taken as part of the state 461 machine. 463 A Start Active Timer 464 If this action occurred as the result of the receipt of a an 465 authenticated Hello message from the active router, the Active 466 timer is set to the Holdtime field in the Hello message. 467 Otherwise the Active timer is set to the current Holdtime value 468 in use by this router. The Active timer is then started. 470 B Start Standby Timer 471 If this action occurred as the result of the receipt of an 472 authenticated Hello message from the standby router, the 473 Standby timer is set to the Holdtime field in the Hello 474 message. Otherwise the Standby timer is set to the current 475 hold time value in use by this router. The Standby timer is 476 then started. 478 C Stop Active Timer 479 The Active timer is stopped. 481 D Stop Standby Timer 482 The Standby timer is stopped. 484 E Learn Parameters 485 This action is taken when an authenticated message is received 486 from the active router. If the virtual IP address for this 487 group was not manually configured, the virtual IP address MAY 488 be learned from the message. The router MAY learn Hellotime 489 and Holdtime values from the message. 491 F Send Hello Message 492 The router sends a Hello message with its current State, 493 Hellotime and Holdtime. 495 G Send Coup Message 496 The router sends a Coup message to inform the active router 497 that there is a higher priority router available. 499 H Send Resign Message 500 The router sends a Resign message to allow another router to 501 become the active router. 503 I Send Gratuitous ARP Message 504 The router broadcasts an ARP response packet advertising the 505 group's virtual IP address and virtual MAC address. 507 5.7 State Transitions 509 This table describes the state transitions of the state machine. 510 For each event and current state of the router, the router MUST 511 perform the set of actions specified and transition to the 512 designated state. If no action is specified, no action should be 513 taken. If no state change is specified, no state change should be 514 performed. 516 The notation used in this table has the specified set of actions 517 listed as letters corresponding to the actions listed in section 518 5.6. The next state is listed as a number as specified in section 519 5.3. A slash ('/') separates the actions and states. Certain 520 state transitions have alternatives which depend on external 521 state. Alternatives are separated by a '|'. See the attached 522 notes for details on these transitions. 524 States 525 +-----+----------+----------+----------+----------+----------+----------+ 526 | | 1 | 2 | 3 | 4 | 5 | 6 | 527 | | Initial | Learn | Listen | Speak | Standby | Active | 528 +-----+----------+----------+----------+----------+----------+----------+ 529 |Event| | 530 +-----+----------+----------+----------+----------+----------+----------+ 531 | a | AB/2|3+ | | | | | | 532 +-----+----------+----------+----------+----------+----------+----------+ 533 | b | | CD/1 | CD/1 | CD/1 | CD/1 | CDH/1 | 534 +-----+----------+----------+----------+----------+----------+----------+ 535 | c | | | AB/4 | | CDFI/6 | | 536 +-----+----------+----------+----------+----------+----------+----------+ 537 | d | | | B/4 | D/5 | | | 538 +-----+----------+----------+----------+----------+----------+----------+ 539 | e | | | | F | F | F | 540 +-----+----------+----------+----------+----------+----------+----------+ 541 | f | | | | B/3 | B/3 | | 542 +-----+----------+----------+----------+----------+----------+----------+ 543 | g | | EAB/3 | EA | EA | EA | AB/4 | 544 +-----+----------+----------+----------+----------+----------+----------+ 545 | h | | EAB/3 | A|BGFI/6*| A|BGFI/6*| A|BGFI/6*| G | 546 +-----+----------+----------+----------+----------+----------+----------+ 547 | i | | | AB/4 | A | CFI/6 | | 548 +-----+----------+----------+----------+----------+----------+----------+ 549 | j | | | | | | ABH/4 | 550 +-----+----------+----------+----------+----------+----------+----------+ 551 | k | | | B | B/3 | B/3 | B | 552 +-----+----------+----------+----------+----------+----------+----------+ 553 | l | | | B/4 | D/5 | | B | 554 +-----+----------+----------+----------+----------+----------+----------+ 556 Notes 558 + If the virtual IP address is configured, set state 3 (Listen) If 559 the virtual IP address is not configured, set state 2 (Learn). In 560 either case do actions A and B. 562 * If the router is configured to preempt do actions B, G, F, and I 563 and set state to 6 (Active). If the router is not configured to 564 preempt do actions A with no state change. 566 6 MAC Address Considerations 568 6.1 General 570 Each HSRP group has an associated well known virtual MAC address. 571 On token ring networks, these addresses are actually functional 572 addresses. The three addresses 0xC0 0x00 0x00 0x01 0x00 0x00, 573 0xC0 0x00 0x00 0x02 0x00 0x00, and 0xC0 0x00 0x00 0x04 0x00 0x00 574 correspond to groups 0, 1, and 2 respectively. 576 On other media, the virtual MAC addresses are 0x00 0x00 0x0C 0x07 577 0xAC XX where XX represents the HSRP group number. Routers which 578 implement HSRP SHOULD use well-known HSRP MAC addresses as the 579 group's virtual MAC address whenever possible. 581 The active router MUST accept and forward traffic that is destined 582 for the group's virtual MAC address. It MUST stop accepting or 583 forwarding such traffic when the router leaves the Active state. 585 If and only if the router is in the Active state, the router MUST 586 use the group's virtual MAC address as the source MAC address for 587 its Hello messages. This is necessary in order to allow learning 588 bridges to be able to determine which LAN segment the virtual MAC 589 address currently belongs to. 591 For each group, there is one virtual IP address and one virtual 592 MAC address. This is a desirable situation, since the ARP table 593 entries in the end stations do not need to change over time as the 594 HSRP active router moves from one router to another. 596 Additionally, for HSRP to work in bridging environments, the 597 bridges must be able to quickly update themselves as the virtual 598 MAC address "moves". Although learning bridges typically are able 599 to do this, some have been known to have problems with this. It 600 is RECOMMENDED that only true learning bridges be used with HSRP. 602 The movement of the virtual MAC address can cause further 603 undesirable side effects in environments where additional state is 604 tied to the MAC address. For example on Token Ring, if Source 605 Route Bridging is in use, a RIF will be stored with the virtual 606 MAC address in a host's RIF cache. The RIF indicates the path and 607 final ring used to reach the MAC address. As routers transition 608 into Active state, they will not be able to affect the RIF caches 609 on the hosts on the bridged ring. This may lead to packets being 610 bridged to the ring for the previous active router. 612 In such circumstances, a router MAY use its normal MAC addresses 613 as the virtual MAC address. This method of operation is strongly 614 discouraged. In this mode, the virtual IP address will map to a 615 different MAC address over time. This can create problems for end 616 stations, since ARP tables assume a relatively static mapping 617 between MAC address and IP address. These ARP tables are normally 618 updated when the end stations receive the gratuitous ARP responses 619 generated by a router that enters the active state. 621 6.2 Address Filter 623 As noted, routers currently emulating a virtual router adopt their 624 group's MAC and IP addresses. MAC addresses are typically 625 provided in an address filter or 'list' of MAC addresses in a 626 router's interface controller. It is desirable for routers to be 627 able to add one or more virtual MAC addresses to their 628 controllers' MAC address filter while maintaining their primary 629 MAC addresses. 631 Unfortunately, some interface controllers support address 632 filtering for only one unicast MAC address. Or, in the case of 633 Token Ring, the functional address which HSRP should use is 634 already in use for some other protocol. In these cases, such 635 routers can still implement HSRP, but the protocol must change the 636 interface's primary MAC address when assuming or relinquishing 637 control as the active router. 639 This is potentially problematic because some traffic may otherwise 640 wish to use the router's primary MAC address. However, the 641 problem MAY be mitigated by having the router send out gratuitous 642 ARP packets regarding its non-HSRP IP addresses. Through this, 643 other network entities using IP should update their ARP tables to 644 reflect that the router is now using a group virtual MAC address 645 rather than its primary MAC address. 647 Some protocols may not be able to run simultaneously with the 648 standby protocol due to the interface primary MAC address change. 649 For example, DECnet phase IV and HSRP will not be able to run at 650 the same time on some equipment. 652 6.3 ICMP Redirect 654 While running HSRP, it is important to prevent the host from 655 discovering the primary MAC addresses of the routers in its 656 standby group. Thus, any protocol that informs a host of a 657 router's primary address should be disabled. Thus, routers 658 participating in HSRP on an interface MUST NOT send ICMP redirects 659 on that interface. 661 6.4 Proxy ARP 663 Typically, hosts learn the HSRP virtual IP address through the 664 configuration of their default router. These hosts then send 665 packets for destinations outside of the LAN to the virtual IP 666 address. In some environments, hosts may instead make use of 667 proxy ARP in order to route off of the LAN. In this case, the 668 hosts use the MAC address that is supplied in proxy ARP responses. 669 HSRP functionality is maintained if the proxy ARP responses 670 specify the HSRP virtual MAC address. 672 If an HSRP router is configured to support proxy ARP with HSRP, 673 then the router MUST specify the HSRP virtual MAC address in any 674 proxy ARP responses it generates. These proxy ARP responses MUST 675 not be suppressed based upon HSRP state. Suppression based upon 676 state could result in lack of any proxy ARP response being 677 generated, since these proxy ARP responses may be suppressed due 678 to other reasons, such as split-horizon rules. 680 7. Security Considerations 682 This protocol does not provide security. The authentication field 683 found within the message is useful for preventing 684 misconfiguration. The protocol is easily subverted by an active 685 intruder on the LAN. This can result in a packet black hole and a 686 denial-of-service attack. It is difficult to subvert the protocol 687 from outside the LAN as most routers will not forward packets 688 addressed to the all-routers multicast address (224.0.0.2). 690 8. References 692 [1] RFC 1256, S. Deering, "ICMP Router Discovery Messages" 694 [2] United States Patent. Patent Number : 5,473,599. Standby 695 Router Protocol. Date of Patent: Dec. 5, 1995. 697 9. Authors' Addresses 699 Tony Li 700 Juniper Networks, Inc. 701 3260 Jay St. 702 Santa Clara, CA 95054 703 Phone: (408) 327-1900 704 Email: tli@juniper.net 706 Bruce Cole 707 Juniper Networks, Inc. 708 3260 Jay St. 709 Santa Clara, CA 95054 710 Phone: (408) 327-1900 711 Email: cole@juniper.net 713 Phil Morton 714 Cisco Systems 715 170 Tasman Dr. 716 San Jose, CA 95143 717 Phone: (408) 526-7632 718 Email: pmorton@cisco.com 720 Dawn Li 721 Cisco Systems 722 170 Tasman Dr. 723 San Jose, CA 95143 724 Phone: (408) 527-2014 725 Email: dawnli@cisco.com