Router Renumbering for IPv6
Extracted elements (29)
Individual PCOs are idempotent and can be safely retransmitted. However, multi-PCO messages can be non-idempotent (e.g., ADD followed by DELETE), so all routers are required to guard against reprocessing an RR message with the same SequenceNumber and SegmentNumber rather than relying on idempotency.
The KeepLen field was introduced so a single PCO can define a new global prefix on every router in a site while preserving the subnetting structure: bits encoding the subnet ID are copied from the existing site-local prefix into the new global prefix at the same bit positions.
The reliability estimation framework in section 8 addresses the case where the exact set of managed routers is unknown. A Bayesian confidence estimate is computed from retransmission response counts to determine when the probability that all routers have been reached exceeds a configurable threshold (default 0.999), avoiding indefinite retransmission.
The SegmentNumber field allows a renumbering operation too large for a single packet to be split across multiple RR Command messages with the same SequenceNumber. Unlike the SequenceNumber, SegmentNumber imposes no ordering on processing — if ordering is needed, use SequenceNumbers or PCO order within a single message.
The InterfaceIndex field in a Match Report MUST be the same as the value of ipv6IfIndex that designates that interface in the SNMP IPv6 MIB General Group (RFC 2466), ensuring that management stations can correlate RR results with MIB data.
To detect routers that missed commands during a network partition, a management station MAY periodically send a no-op RR Command (ADD with MatchLen=0, MinLen=0, MaxLen=128, no Use-Prefix Parts) with the R flag set and a SequenceNumber one less than the highest used; responses can only come from routers that missed the last real operation.
A router MUST discard an RR Command whose SequenceNumber is less than the Recorded Sequence Number. If the SequenceNumber equals the Recorded Sequence Number and the same SequenceNumber+SegmentNumber pair was already processed, the message is a duplicate and MUST be discarded (unless R is set, in which case a Result with P flag set MUST be scheduled).
A Sequence Number Reset is safe only when all cryptographic keys previously used to authenticate RR Commands have expired or been revoked. If no unused authentication keys are available after SNR processing, the router SHOULD establish new valid keys; without keys, no new Commands can be processed.
After processing all PCOs on all interfaces, an implementation MUST record the SegmentNumber of the packet in a list associated with the current SequenceNumber, to prevent duplicate processing of retransmitted messages.
All configuration changes resulting from Router Renumbering SHOULD be saved to non-volatile storage where this facility exists, so that router state survives reboots.
All implementations generating RR Command messages MUST support sending to the All Routers multicast address with link and site scopes, and to link-local and site-local unicast addresses. All routers MUST be capable of receiving RR Commands sent to those multicast addresses and any of their link-local and site-local unicast addresses.
Data authentication and message integrity MUST be provided for all Router Renumbering Command messages by appropriate IPsec means. The integrity assurance must cover the IPv6 destination address, the RR Header, and the Message Body.
If a Result message must be fragmented for transmission, it SHOULD be fragmented to the IPv6 minimum required MTU.
If any PCO field (OpCode, OpLength, MatchLen, UseLen, KeepLen) is out of bounds, the entire PCO MUST NOT be performed on any interface. If R is set, a Match Report with the B flag set MUST be included in the Result, appearing only once (not once per interface).
The SequenceNumber in an RR message MUST be non-decreasing between Sequence Number Resets. The highest sequence number found in a valid message MUST be recorded in non-volatile storage (the Recorded Sequence Number).
The UsePrefix in a Use-Prefix Part MUST NOT have the form of a multicast or link-local address. Any New Prefix with a forbidden format (multicast, unspecified, loopback) MUST be discarded; if R is set, the F flag MUST be set in the corresponding Match Report.
A Prefix Control Operation (PCO) specifies one of three OpCodes: ADD (1) appends Use-Prefixes to the interface, CHANGE (2) replaces the matched prefix with Use-Prefixes, or SET-GLOBAL (3) replaces all global-scope prefixes with Use-Prefixes. An empty Use-Prefix set causes ADD to do nothing and the others to delete.
Router Renumbering messages are carried in ICMPv6 packets with Type 138. Code 0 is a Command, Code 1 is a Result, and Code 255 is a Sequence Number Reset. The message consists of a 16-octet RR Header followed by a variable-length Message Body.
The Flags byte in the RR Header defines five bits: T (Test — simulate only, no actual reconfiguration), R (Result requested — router MUST send Result), A (All interfaces — include administratively shut down interfaces), S (Site-specific — restrict to same site as receiving interface), and P (Processed previously — set in Result for duplicate commands).
The KeepLen field in a Use-Prefix Part specifies a number of bits to copy from the Matched Prefix into the New Prefix at positions UseLen through UseLen+KeepLen-1, enabling a single PCO to preserve site subnetting structure when changing a global prefix across an entire site.
The Sequence Number Reset (SNR) message (Code 255) is used to reset a router's Recorded Sequence Number. Upon receipt of an authenticated SNR, the router MUST invalidate all keys previously used to authenticate RR Commands (including the SNR's own key), discard saved Result messages, clear recorded SegmentNumbers, and reset the Recorded Sequence Number to zero.
New values of the Code field in the Router Renumbering Header (section 3.1) and the OpCode field of the Match-Prefix Part (section 3.2.1.1) are to be allocated by IETF consensus only, following the policies in RFC 2434.
At the time of writing, no multicast key management protocol for IPsec existed, making manually configured Security Associations common for the All-Routers multicast case. The SPD may use per-management-station or per-unicast-address entries, with a final wildcard entry to discard all other incoming RR messages.
Authentication keys for RR must be as well protected as any other router reconfiguration access method. Key distribution must not expose or permit alteration of keys, and key validity must be limited in time and number of messages. Replay of old messages must be prevented by the sequence number mechanism.
The SPD of a router implementing this specification MUST cause incoming RR Command packets to be either discarded or have IPsec applied. The SAD entries MUST ensure authentication and integrity of the IPv6 destination address, the RR Header and Message Body; these requirements are met by AH in transport or tunnel mode, or ESP in tunnel mode with non-NULL authentication.
The Match-Prefix Part is 24 octets and contains: OpCode (8-bit), OpLength (8-bit, units of 8 octets, must be of form 4N+3), Ordinal (8-bit, unique per PCO in a message), MatchLen (8-bit, 0–128), MinLen (8-bit), MaxLen (8-bit), 16-bit reserved, and MatchPrefix (128-bit).
The Match Report in a Result message body is 24 octets: reserved bits plus B flag (bounds error) and F flag (forbidden prefix), Ordinal (8-bit copied from PCO), MatchedLen (8-bit), InterfaceIndex (32-bit), and MatchedPrefix (128-bit).
The RR Header contains: Type (8-bit, value 138), Code (8-bit), Checksum (16-bit), SequenceNumber (32-bit unsigned), SegmentNumber (8-bit unsigned), Flags (8-bit: T/R/A/S/P plus 3 reserved bits), MaxDelay (16-bit unsigned milliseconds), and a 32-bit reserved field.
The Use-Prefix Part is 32 octets and contains: UseLen (8-bit), KeepLen (8-bit, sum with UseLen ≤ 128), FlagMask (8-bit), RAFlags (8-bit), Valid Lifetime (32-bit seconds), Preferred Lifetime (32-bit seconds), V and P flags (1-bit each) controlling real-time lifetime decrement, reserved bits, and UsePrefix (128-bit).