Subject: draft-kumar-kulkarni-riprestart-00.txt

From: Saravana K <[email-masked]>
Date: Wed, 18 Jul 2007 23:36:22 +0530

Hi All,

We have written a new draft proposing a set of restart signaling 
extensions for the RIP protocol. Currently we discovered some issues 
related to route path flapping when a RIP router undergoes a restart and 
came up with a mechanism to avoid it. I request you all to please go 
through the draft and give us your comments. I will be presenting the 
idea behind the same in the upcoming IETF-69 meeting.

The draft is attached in this mail as i had missed the ID submission 
cutoff date.

Thanks,
Saravana

Network Working Group                                    Saravana Kumar 
Internet Draft                                      Huawei Technologies 
Intended status: Standard                            Janardhan Kulkarni 
Expires: January 2008                                            Citrix 
                                                          July 18, 2007 

                          RIP Restart Extensions 
                draft-kumar-kulkarni-riprestart-00.txt 

Status of this Memo 

   By submitting this Internet-Draft, each author represents that       
   any applicable patent or other IPR claims of which he or she is       
   aware have been or will be disclosed, and any of which he or she       
   becomes aware will be disclosed, in accordance with Section 6 of       
   BCP 79. 

   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 January 18, 2007. 

Copyright Notice 

   Copyright (C) The IETF Trust (2007). 

 

<Kumar-Kulkarni>       Expires January 18, 2008                [Page 1] 

Internet-Draft          RIP Restart Signaling                 July 2007 

Abstract 

   This draft proposes a restart signaling mechanism for the RIP 
   protocol to effectively eliminate the routing disturbances in the 
   network when a RIP router is restarted. The basic idea is for the 
   restarting RIP router to not update its routing tables and not 
   advertise any route information before it receives the routing 
   information from all its peers. In addition to the base restart 
   signaling mechanism this document also describes a mechanism for 
   deterministically selecting equal cost routes and a security 
   enhancement to recover the cryptographic sequence number after a 
   restart. These enhancements will help the RIP router to continue 
   functioning in the same way after a restart as if nothing happened to 
   it. 

1. Introduction 

   By its very nature the RIP protocol ([RIP], [RIP2]) is to an extent 
   resilient to protocol and system restarts. There is no stateful 
   neighbor relationship maintained and the routes have a relatively 
   comfortable ageing time of (typical) 180 seconds. So the base RIP 
   protocol does not have many of the issues faced by the other link 
   state protocols like ISIS and OSPF during a restart (the term 
   'restart' applies equally to both the protocol level restart and a 
   control plane restart). But its behavior is not perfect either and 
   could cause some routing disturbances in the network as described 
   below. 

   When the RIP router comes up after a restart (either a protocol level 
   or a system level restart) it will send out a full table request over 
   all its enabled interfaces and start receiving the route updates from 
   its peers. As and when the new route updates are received the router 
   will update its forwarding table and propagate these routes to its 
   peers. This premature behavior will disrupt the packet forwarding in 
   the network, mainly resulting in a switch in the packet flow to a low 
   preference path and back again to the preferred path. If equal cost 
   paths are present in the network then there might be a permanent 
   switch to a different set of paths after a router restart. This kind 
   of disturbance to the network can be eliminated using a simple 
   restart signaling mechanism described in this document. The mechanism 
   also provides certain additional benefits like preventing aging out 
   of routes in the peers during a restart, detecting topology changes, 
   protecting against replay attacks in the network etc. 

 
<Kumar-Kulkarni>       Expires January 18, 2008                [Page 2] 

Internet-Draft          RIP Restart Signaling                 July 2007 

   The basic idea behind the restart signaling mechanism is similar to 
   the ones used in other protocols. The entire restart mechanism works 
   in three different phases. In the first Helper Solicitation Phase the 
   restarting router requests its peers to help by sending a full 
   routing table update and notifying the restarting route when the 
   update is over. Next during the Route Update Phase the restarting 
   router tracks the route update progress of all its peers and builds 
   its routing database. Finally during the Restart Complete phase the 
   restarting router updates its forwarding tables with the route 
   information and begins sending route updates to its peers. 

2. RIP Extension Message format 

   In order to support the restart extensions and any other extensions 
   in the future a new message has been introduced. This message can 
   carry different types of notifications, acknowledgements along with 
   multiple options. The format of this new RIP extension message is: 

    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    Command    |     Version   |     Type      |  Option Num   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |             0xFFFF            |    Authentication Type        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   ~                     Authentication Data(16)                   ~ 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |         Option Type           |         Option Length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   ~                           Option Data                         ~ 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   ~                     Authentication Trailer                    ~ 
   +---------------------------------------------------------------+ 

   Command: 
   A new command type 7 has been introduced to denote the Extension 
   Message 

   Version: 
   The version field is not modified. 

<Kumar-Kulkarni>       Expires January 18, 2008                [Page 3] 

Internet-Draft          RIP Restart Signaling                 July 2007 

   Type: 
   This field indicates the type of the extension message. Currently 
   there are 8 different message types. 

      1 - Restart Notification (RN) 
      2 - Restart Acknowledgment (RA) 
      3 - Update Complete Notification (UCN) 
      4 - Update Complete Acknowledgement (UCA) 
      5 - Restart Abort Notification (RAN) 
      6 - Restart Abort Acknowledgement (RAA) 
      7 - Restart Complete Notification (RCN) 
      8 - Restart Complete Acknowledgement (RCA) 
      9 - Sequence Number Request 
     10 - Sequence Number Reply 
    
   Option Num: 
   Some extension messages may carry some additional information in 
   options. This field indicates how many such options are present in 
   the message. 

   Options: 
   All the options are encoded in a Type, Length and Value format. The 
   2-byte type field identifies the option, the 2-byte length field 
   indicates the length of the value field in bytes and the Value field 
   can be of zero or more bytes as denoted by the length field.  

   The values of different Option Types are listed below: 
    
      1 - Neighbor-List Option 
      2 - Delayed-Restart Option 
      3 - Sequence Number Option 

   If the option type field carries a value of 0xFFFF then it denotes 
   authentication information as defined in [RFC-2082] and [RFC-4822]. 

3. Planned and Unplanned restarts 

   A router can undergo a restart due to two reasons, a planned restart 
   or an unplanned restart. An unplanned restart happens when there is 
   some failure in the control plane of a router and it immediately 
   switches over to a standby board. This event cannot be predicted 
   beforehand and the RIP protocol should start its restart processing 
   when it comes up after the unplanned restart. On the other hand a 
   planned restart is a controlled event initiated by a network 
   administrator, typically to upgrade the hardware/software in the 

<Kumar-Kulkarni>       Expires January 18, 2008                [Page 4] 

Internet-Draft          RIP Restart Signaling                 July 2007 

   router. RIP can take some advantage of this event to pre-notify its 
   peers about the pending failure and enable them to play a better 
   supporting role. 

   When a router is scheduled to undergo a planned restart it SHOULD 
   inform its peers about this by sending out a Restart Notification 
   message with a Delayed-Restart Option. The time interval for which 
   the restarting router is expected to be down is also mentioned in the 
   Restart-Time field in the Delayed-Restart Option. This will ensure 
   that the peers do not let the routes from the restarting router to be 
   aged out while it is being restarted. Another advantage to informing 
   the peer early is that the helper can track topology changes from the 
   moment the restarting router goes down. 

4. Helper Solicitation Phase 

4.1. Actions of the Restarting router 

   When the restarting router comes up after a Planned or an Un-planned 
   restart it MUST immediately notify all its peers about its state by 
   sending out a Restart Notification (RN) message without the 'Delayed-
   Restart' option. Along with the Restart Notification a Full Table 
   Request message MUST also be sent over all the interfaces. This will 
   ensure that the restart incapable routers on the link start sending 
   their route updates to the restarting router. If no processing to 
   recover the sequence number (see Section 8) is carried out then both 
   the RN and the Full Table Request messages MUST be generated with a 
   sequence number of zero (even when they are being retransmitted). 

   The Restart Notification (RN) message SHOULD be retransmitted for a 
   predetermined number of times to ensure its reliable receipt over the 
   link. On a point-to-point link the retransmission SHOULD be stopped 
   once a valid Restart Acknowledgement message is received. On a multi-
   access link however the RN message SHOULD be re-transmitted for the 
   predetermined number of times irrespective of whether a RA was 
   received over the link or not. Each RN message sent on a link MUST 
   have a 'Neighbor-List' option containing the list of neighbors from 
   whom a RA message was received already. This will help prevent the 
   peer router from sending the RA multiple times. 

 
<Kumar-Kulkarni>       Expires January 18, 2008                [Page 5] 

Internet-Draft          RIP Restart Signaling                 July 2007 

   Once a RA is received from a peer, the restarting router SHOULD mark 
   that peer as 'Restart-Capable'. If no RA is received from a peer even 
   after resending the RN message for the pre-determined number of 
   times, then the restarting router SHOULD mark that peer as 'Restart-
   Incapable'. A static-update-timer MUST be started for each of the 
   'Restart-Incapable' peers to statically track their route update 
   progress. 

4.2. Actions of the Helper router 

   On receiving the Restart Notification message from the restarting 
   router, a Restart-Capable router SHOULD check if its interface 
   address is present in the Neighbor-List option of the RN message. If 
   so then the peer router MUST ignore the (retransmitted) RN message. 
   Otherwise the peer should do some checks to decide if it can act as a 
   helper to the restarting router or not. 

   o  If the peer router has an existing neighbor relationship with the 
      restarting router then it SHOULD act as a helper for the 
      restarting router. 

   o  If the peer router is also undergoing the restart process then it 
      SHOULD NOT act as a helper for the restarting router. 

   The peer router decides not to act as a helper it indicates a 
   topology change event and the peer MAY send a Restart Abort 
   Notification message to tell the restarting router to stop its 
   restart processing. Otherwise the peer SHOULD mark itself as the 
   'Helper' for the restarting router and send a Restart Acknowledgement 
   (RA) message. Once the peer enters the 'Helper' mode it should do the 
   following additional processing. 

   o  If the 'Delayed-Restart' Option is present in the RN message then 
      Helper router SHOULD set the status of the restarting router as 
      RESTART_INACTIVE and SHOULD reset the age time for all the routes 
      learnt from the restarting router to the 'Restart-Time' value 
      specified in the RN message. It SHOULD NOT send its full table 
      route updates to the restarting router. 

   o  If the 'Delayed-Restart' Option is NOT present in the RN message 
      then Helper router SHOULD set the status of the restarting router 
      as RESTART_ACTIVE and SHOULD refresh the age time for all the 
      routes learnt from the restarting router. And it SHOULD start 
      sending its full table route updates to the restarting router. 

 
<Kumar-Kulkarni>       Expires January 18, 2008                [Page 6] 

Internet-Draft          RIP Restart Signaling                 July 2007 

   If a Helper router receives a Full Table Request from the restarting 
   router while it is still in the helper mode it SHOULD ignore the 
   message.  

5. Route Update Phase 

5.1. Actions of the Restarting router 

   On entering the Restart mode, the main job of the restarting router 
   is to build its route database and determine when it has finished 
   receiving route updates from all its peers. During this time the 
   restarting router MUST NOT update its forwarding table with the 
   learnt routes and it MUST NOT send out any route updates (neither 
   periodic nor triggered) to any of its peers.  

   The route update progress of each peer is tracked separately by the 
   restarting router. As an added safety mechanism the restarting router 
   should start a RESTART_CUTOFF_TIMER (300s), which will forcefully end 
   the route update phase. For a 'Restart-Capable' peer the route update 
   is considered to be over upon receiving a Update Complete 
   Notification (UCN) message from that peer. For a 'Restart-Incapable' 
   peer its route update is considered to be over when its static-
   update-timer expired. The route update phase is considered to be over 
   in the following cases. 

   o  Route update is completed for all its peers. 

   o  A Restart Abort Notification message is received from any of its 
      peers. 

   o  The restarting router detects a topology change locally. 

   o  The RESTART_CUTOFF_TIMER expires. 

5.2. Actions of the Helper router 

   Once the helper router has completed sending all its route updates to 
   the restarting router it SHOULD send a Update Complete Notification 
   (UCN) message directly to the restarting router. This message must be 
   retransmitted for a pre-determined number of times until an Update 
   Complete Acknowledgement (UCA) message is received from the 
   restarting router. 

 
<Kumar-Kulkarni>       Expires January 18, 2008                [Page 7] 

Internet-Draft          RIP Restart Signaling                 July 2007 

6. Restart Complete Phase 

6.1. Actions of the Restarting Router 

   On exiting the Restart mode, the restarting router SHOULD perform the 
   following actions: 

   o  Update all the learnt routes to the forwarding table and flush out 
      any stale route entries that might've been added before the 
      restart happened. 

   o  Start the processing to send out periodic updates over all 
      interfaces. 

   o  Send a Restart Complete Notification (RCN) message over all its 
      interfaces. The RCN message is re-transmitted till the Restart 
      Complete Acknowledgement (RCA) is received from all the 'Restart-
      Capable' peers on an interface. Each time the RCN message is re-
      transmitted it SHOULD include the list of routers from which a RCA 
      has already been received. 

6.2. Actions of the Helper router 

   A Helper router SHOULD reset its Helper mode status for a restarting 
   neighbor once it receives the Restart Complete Notification (RCN) 
   from that neighbor or when the neighbor is deleted. On receiving the 
   RCN message that needs to be acknowledged it SHOULD immediately send 
   a Restart Complete Acknowledgement (RCA) back and reset the Helper 
   status for that neighbor. 

7. ECMP routes selection 

   ECMP support for RIP is widely implemented by many of the vendors 
   today and [RIP-ECMP] provides some recommendations for the same. One 
   of the aspects of ECMP that needs to be considered for un-interrupted 
   forwarding is the selection procedure for the equal cost paths. 
   Typically when RIP (or any protocol) has a set of ECMP routes to 
   choose from for a particular destination, depending on the system 
   configuration, it will choose a subset of these routes and discard 
   the rest. If the selection of these routes is in a first come first 
   serve basis, then the set of ECMP routes selected by a RIP router 
   before and after a restart would be different. This will affect the 
   forwarding in the network. 

<Kumar-Kulkarni>       Expires January 18, 2008                [Page 8] 

Internet-Draft          RIP Restart Signaling                 July 2007 

   This problem can be avoided if RIP chooses its equal cost paths in a 
   deterministic manner. The paths MAY chosen based on the neighbor and 
   nexthop IP address information associated with the routes, giving 
   preference to the routes with smaller neighbor and nexthop addresses. 
   One of the disadvantages with this method is that if the 'preferred' 
   neighbor is unstable, then still its routes will be learnt instead of 
   the more stable routes from a different neighbor. Implementers must 
   consider this issue carefully before going for a deterministic ECMP 
   selection mechanism. 

8. Handling topology changes 

   If during the restart processing there is any change in the topology 
   then it is RECOMMENDED that the restarting router exit the Restart 
   mode immediately. Topology change can be detected by either the 
   restarting router or the helper. A couple of recommended topology 
   change detection mechanisms are described below, however the 
   implementations are free to choose their own mechanism. 

   o  If a Helper router needs to send some triggered updates to the 
      restarting router, then it indicates a topology change.  

   o  Any local configuration change in the restarting router or the 
      helper router that would change their route advertisements. 

   If the Helper router detects any topology change it SHOULD send a 
   Restart Abort Notification (RAN) message to the restarting router. 
   This message is sent only if the restarting router's state is 
   RESTART_ACTIVE. Otherwise the helper SHOULD wait until the status 
   changes to RESTART_ACTIVE and then send the RAN message. The RAN 
   message SHOULD be retransmitted for a predetermined number of times 
   until the Restart Abort Acknowledgement message is received from the 
   restarting router. 

9. Security Considerations 

9.1. Sequence number re-acquisition during restart. 

   [RIPMD5] allows a RIP router to accept a cryptographically protected 
   packet with sequence number of zero. This opens up the RIP protocol 
   to replay attacks as documented in [CRYPT]. The Restart Notification 
   message will usually be the first RIP packet sent out of an interface 
   after a restart and will have a sequence number of zero and is 
   vulnerable to such replay attacks. This section describes how a 

<Kumar-Kulkarni>       Expires January 18, 2008                [Page 9] 

Internet-Draft          RIP Restart Signaling                 July 2007 

   restarting router can re-acquire its sequence number from its helper, 
   using the sequence number request and reply messages. It is assumed 
   in this section that all the routers involved are using sequence 
   number based cryptographic authentication mechanisms. 

   When RIP is enabled on any interface it SHOULD first try to recover 
   its sequence number before sending any other packets. This is 
   achieved by sending out a Sequence-Number-Request message containing 
   a Sequence Number option. For a request message the sequence number 
   field is set to zero and the Session ID field SHOULD be set to a 
   random number that will be used for the rest of the sequence number 
   re-acquisition processing.  

   0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Option Type (3)         |       Option Length (8)       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           Session ID                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         Sequence Number                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   On receiving a Sequence-Number-Request message over an interface, a 
   RIP router SHOULD reply with a Sequence-Number-Response message. The 
   Session ID value MUST be the same as the one on the Request message. 
   The Sequence Number field SHOULD be set to the last received sequence 
   number from the originating router or if there is no neighbor 
   relationship with the originating router then the value SHOULD be set 
   to zero. 

   When the originator of the request messages gets the Sequence Number 
   Response message it SHOULD first check the Session ID field to ensure 
   that the Session ID value is the same as the one it generated. If the 
   Session ID value is different (possible replayed packet) then the 
   response message MUST be dropped. Otherwise the router SHOULD use the 
   sequence number mentioned in the response message to generate its 
   other messages. The Sequence Number Request message must be re-
   transmitted a pre-determined number of times till a response is 
   received over the interface If no response is received then it should 
   generate its packets starting with a sequence number of zero. 

   This sequence number re-acquisition capability can be optionally 
   enabled by the administrator on an interface. If this capability is 
   enabled then the router SHOULD NOT accept any messages with sequence 

<Kumar-Kulkarni>       Expires January 18, 2008               [Page 10] 

Internet-Draft          RIP Restart Signaling                 July 2007 

   number zero from a router with which it already has a neighbor 
   relationship. 

10. IANA Considerations 

   IANA is requested to update the RIP message types   
   (http://www.iana.org/assignments/rip-types) so that the message type 
   7 refers to this document's RFC number. 

11. Acknowledgments 

   This document was prepared using 2-Word-v2.0.template.dot. 

 
<Kumar-Kulkarni>       Expires January 18, 2008               [Page 11] 

Internet-Draft          RIP Restart Signaling                 July 2007 

APPENDIX A: Message Format 

A.1. Restart Notification/Acknowledgement (RN/RA): 

   The Restart Notification (RN) message is sent by the restarting 
   router to all the RIP routers on a particular link. The neighbor list 
   option MUST be included in the RN message only if the restarting 
   router has received acknowledgement from any routers on the link. The 
   neighbor list option contains a list of 4-byte IP addresses of the 
   acknowledging RIP routers.  

   The Restart Acknowledgment (RA) message is sent by the Helper 
   directly to the restarting router. The neighbor list option SHOULD 
   NOT be included in the RA message.  

    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Command(7)  |   Version(2)  |   Type(1/2)   | Option Num(1) | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Option Type(1)          |        Option Length(8)       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         NBR IP Address                        | 
   +-------------------------------+-------------------------------+ 
   |                         NBR IP Address                        | 
   +-------------------------------+-------------------------------+ 

A.2. Update Complete Notification/Acknowledgement (UCN/UCA): 

   The Update Complete Notification (UCN) message is sent by the Helper 
   to the restarting router. The 'option num' field is set to zero. 

   The Update Complete Acknowledgement (UCA) message is sent by the 
   restarting router to the Helper that had sent it the Update Complete 
   Notification message. The 'option num' field is set to zero. 

    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Command(7)  |   Version(2)  |   Type(3/4)   | Option Num(0) | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

A.3. Restart Abort Notification/Acknowledgement (RAN/RAA): 

   The Restart Abort Notification (RAN) message is sent by the Helper to 
   the restarting router. The 'option num' field is set to zero.  

 
<Kumar-Kulkarni>       Expires January 18, 2008               [Page 12] 

Internet-Draft          RIP Restart Signaling                 July 2007 

   The Restart Abort Acknowledgement (RAA) message is sent by the 
   restarting router to the Helper that had sent it the Restart Abort 
   Notification message. The 'option num' field is set to zero. 

    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Command(7)  |   Version(2)  |   Type(5/6)   | Option Num(0) | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

A.4. Restart Complete Notification/Acknowledgement (RCN/RCA): 

   The Restart Complete Notification (RCN) message is sent by the 
   restarting router to all the RIP routers on a particular link. The 
   neighbor list option MUST be included once in the RCN message. The 
   neighbor list option SHOULD contain the 4-byte IP address of the RIP 
   routers on the link which have already sent the Restart Complete 
   Acknowledgement. If no such neighbors are present on the link then 
   the option length field SHOULD be set to zero. 

    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Command(7)  |   Version(2)  |    Type(7)    | Option Num(1) | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Option Type(1)          |        Option Length(8)       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         NBR IP Address                        | 
   +-------------------------------+-------------------------------+ 
   |                         NBR IP Address                        | 
   +-------------------------------+-------------------------------+ 

   The Restart Complete Acknowledgment (RCA) message is sent by the 
   Helper to the restarting router. The neighbor list option is NOT 
   included in the RCA message. The 'option num' field is set to zero. 

    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Command(7)  |   Version(2)  |    Type 8   |  Option Num(0)  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

12. References 

   [RIP]  C. Hedrick, "RIP Routing Information Protocol", RFC 1058, June 
             1988. 

<Kumar-Kulkarni>       Expires January 18, 2008               [Page 13] 

Internet-Draft          RIP Restart Signaling                 July 2007 

   [RIP2]  G. Malkin, "RIP Version 2", RFC 2453, January 1998. 

   [OSPFGR]  J. Moy, P. Pillay-Esnault, A. Lindem, "Graceful OSPF 
             Restart", RFC 3623, November 2003.  

   [RFC-2082]  F. Baker, R. Atkinson, "RIP-2 MD5 Authentication", RFC 
               2082, January 1997. 

   [RFC-4822]  R. Atkinson, M. Fanto, "RIPv2 Cryptographic 
               Authentication", RFC 4822, February 2007.  

   [CRYPT]  V. Manral, R.White, M.Bhatia, G., "Issues with existing 
             Cryptographic Protection Methods for Routing Protocols",         
             draft-manral-rpsec-existing-crypto-04.txt, May 2007. 

   [RIP-ECMP]  J. Kulkarni, N. Anand, "Equal cost routes support for 
             RIP/RIPNG", draft-janardhan-naveen-rtgwg-equalcostroutes-
             rip-00, June 2007.  

Author's Addresses 

   Saravana Kumar 
   Huawei Technologies 
   Level-3, Leela Galleria. Airport Road 
   Bangalore, 
   India - 560008 
   Email: [email-masked] 

   Janardhan Kulkarni 
   Citrix 
   Email: [email-masked] 

Intellectual Property Statement 

   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 

<Kumar-Kulkarni>       Expires January 18, 2008               [Page 14] 

Internet-Draft          RIP Restart Signaling                 July 2007 

   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 
   [email-masked]. 

Disclaimer of Validity 

   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, THE IETF TRUST 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. 

Copyright Statement 

   Copyright (C) The IETF Trust (2007). 

   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. 

Acknowledgment 

   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

 
<Kumar-Kulkarni>       Expires January 18, 2008               [Page 15] 

_______________________________________________
rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg