📄 rfc2894.txt
字号:
Crawford Standards Track [Page 11]
RFC 2894 Router Renumbering for IPv6 August 2000
defined meanings to date: the L (on-link) and A
(autonomous configuration) flags. These flags occupy
the two leftmost bit positions in the RAFlags field,
corresponding to their position in the Prefix
Information Option.
Valid Lifetime
A 32-bit unsigned integer which is the number of seconds
for which the New Prefix will be valid [ND, SAA].
Preferred Lifetime
A 32-bit unsigned integer which is the number of seconds
for which the New Prefix will be preferred [ND, SAA].
V A 1-bit flag indicating that the valid lifetime of the
New Prefix MUST be effectively decremented in real time.
P A 1-bit flag indicating that the preferred lifetime of
the New Prefix MUST be effectively decremented in real
time.
UsePrefix The 128-bit Use-prefix which either becomes or is used
in forming (if KeepLen is nonzero) the New Prefix. It
MUST NOT have the form of a multicast or link-local
address [AARCH].
3.3. Message Body -- Result Message
The body of an RR Result message is a sequence of zero or more Match
Reports of 24 octets. An RR Command message with the "R" flag set
will elicit an RR Result message containing one Match Report for each
Prefix Control Operation, for each different prefix it matches on
each interface. The Match Report has the following format.
Crawford Standards Track [Page 12]
RFC 2894 Router Renumbering for IPv6 August 2000
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |B|F| Ordinal | MatchedLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InterfaceIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- MatchedPrefix -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
B A one-bit flag which, when set, indicates that one or
more fields in the associated PCO were out of bounds.
The bounds check is described in section 4.2.
F A one-bit flag which, when set, indicates that one or
more Use-Prefix parts from the associated PCO were not
honored by the router because of attempted formation of
a forbidden prefix format, such as a multicast or
loopback address.
Ordinal Copied from the Prefix Control Operation whose
MatchPrefix matched the MatchedPrefix on the interface
indicated by InterfaceIndex.
MatchedLen The length of the Matched Prefix.
InterfaceIndex
The router's numeric designation of the interface on
which the MatchedPrefix was configured. This MUST be
the same as the value of ipv6IfIndex which designates
that index in the SNMP IPv6 MIB General Group [IPV6MIB].
It is possible for a Result message to be larger than the Command
message which elicited it. Such a Result message may have to be
fragmented for transmission. If so, it SHOULD be fragmented to the
IPv6 minimum required MTU [IPV6].
Crawford Standards Track [Page 13]
RFC 2894 Router Renumbering for IPv6 August 2000
4. Message Processing
Processing of received Router Renumbering Result messages is entirely
implementation-defined. Implementation of Command message processing
may vary in detail from the procedure set forth below, so long as the
result is not affected.
Processing of received Router Renumbering Command messages consists
of three conceptual parts: header check, bounds check, and execution.
4.1. Header Check
The ICMPv6 checksum and type are presumed to have been checked before
a Router Renumbering module receives a Command to process. In an
implementation environment where this may not be the case, those
checks MUST be made at this point in the processing.
If the ICMPv6 length derived from the IPv6 length is less than 16
octets, the message MUST be discarded and SHOULD be logged to network
management.
If the ICMPv6 Code field indicates a Result message, a router which
is not a source of RR Command messages MUST discard the message and
SHOULD NOT log it to network management.
If the IPv6 destination address is neither an All Routers multicast
address [AARCH] nor one of the receiving router's unicast addresses,
the message MUST be discarded and SHOULD be logged to network
management.
Next, the SequenceNumber is compared to the Recorded Sequence Number.
(If no RR messages have been received and accepted since system
initialization, the Recorded Sequence Number is zero.) This
comparison is done with the two numbers considered as unsigned
integers, not as DNS-style serial numbers. If the SequenceNumber is
less than the Recorded Sequence Number, the message MUST be discarded
and SHOULD be logged to network management.
Finally, if the SequenceNumber in the message is greater than the
Recorded Sequence Number or the T flag is set, skip to the bounds
check. Otherwise the SegmentNumber MUST now be checked. If a
correctly authenticated message with the same SequenceNumber and
SegmentNumber has not already been processed, skip to the bounds
check. Otherwise, this Command is a duplicate and not a Test
Command. If the R flag is not set, the duplicate message MUST be
discarded and SHOULD NOT be logged to network management. If R is
set, an RR Result message with the P flag set MUST be scheduled for
transmission to the source address of the Command after a random time
Crawford Standards Track [Page 14]
RFC 2894 Router Renumbering for IPv6 August 2000
uniformly distributed between 0 and MaxDelay milliseconds. The body
of that Result message MUST either be empty or be a saved copy of the
Result message body generated by processing of the previous message
with the same SequenceNumber and SegmentNumber. After scheduling the
Result message, the Command MUST be discarded without further
processing.
4.2. Bounds Check
If the SequenceNumber is greater than the Recorded Sequence Number,
then the list of processed SegmentNumbers and the set of saved Result
messages, if any, MUST be cleared and the Recorded Sequence Number
MUST be updated to the value used in the current message, regardless
of subsequent processing errors.
Next, if the ICMPv6 Code field indicates a Sequence Number Reset,
skip to section 5.
At this point, if T is set in the RR header and R is not set, the
message MAY be discarded without further processing.
If the R flag is set, begin constructing an RR Result message. The
RR header of the Result message is completely determined at this time
except for the Checksum.
The values of the following fields of a PCO MUST be checked to ensure
that they are within the appropriate bounds.
OpCode must be a defined value.
OpLength must be of the form 4N+3 and consistent the the length
of the Command packet and the PCO's offset within the
packet.
MatchLen must be between 0 and 128 inclusive
UseLen, KeepLen
in each Use-Prefix Part must be between 0 and 128
inclusive, as must the sum of the two.
If any of these fields are out of range in a PCO, the entire PCO MUST
NOT be performed on any interface. If the R flag is set in the RR
header then add to the RR Result message a Match Report with the B
flag set, the F flag clear, the Ordinal copied from the PCO, and all
other fields zero. This Match Report MUST be included only once, not
once per interface.
Crawford Standards Track [Page 15]
RFC 2894 Router Renumbering for IPv6 August 2000
Note that MinLen and MaxLen need not be explicitly bounds checked,
even though certain combinations of values will make any matches
impossible.
4.3. Execution
For each applicable router interface, as determined by the A and S
flags, the Prefix Control Operations in an RR Command message must be
carried out in order of appearance. The relative order of PCO
processing among different interfaces is not specified.
If the T flag is set, create a copy of each interface's configuration
on which to operate, because the results of processing a PCO may
affect the processing of subsequent PCOs. Note that if all
operations are performed on one interface before proceeding to
another interface, only one interface-configuration copy will be
required at a time.
For each interface and for each Prefix Control Operation, each prefix
configured on that interface with a length between the MinLen and
MaxLen values in the PCO is tested to determine whether it matches
(as defined in section 2.1) the MatchPrefix of the PCO. The
configured prefixes are tested in an arbitrary order. Any new prefix
configured on an interface by the effect of a given PCO MUST NOT be
tested against that PCO, but MUST be tested against all subsequent
PCOs in the same RR Command message.
Under a certain condition the addresses on an interface are also
tested to see whether any of them matches the MatchPrefix. If and
only if a configured prefix "P" does have a length between MinLen and
MaxLen inclusive, does not match the MatchPrefix "M", but M does
match P (this can happen only if M is longer than P), then those
addresses on that interface which match P MUST be tested to determine
whether any of them matches M. If any such address does match M,
process the PCO as if P matched M, but when forming New Prefixes, if
KeepLen is non-zero, bits are copied from the address. This special
case allows a PCO to be easily targeted to a single specific
interface in a network.
If P does not match M, processing is finished for this combination of
PCO, interface and prefix. Continue with another prefix on the same
interface if there are any more prefixes which have not been tested
against this PCO and were not created by the action of this PCO. If
no such prefixes remain on the current interface, continue processing
with the next PCO on the same interface, or with another interface.
Crawford Standards Track [Page 16]
RFC 2894 Router Renumbering for IPv6 August 2000
If P does match M, either directly or because a configured address
which matches P also matches M, then P is the Matched Prefix.
Perform the following steps.
If the Command has the R flag set, add a Match Report to the
Result message being constructed.
If the OpCode is CHANGE, mark P for deletion from the current
interface.
If the OpCode is SET-GLOBAL, mark all global-scope prefixes on the
current interface for deletion.
If there are any Use-Prefix parts in the current PCO, form the New
Prefixes. Discard any New Prefix which has a forbidden format,
and if the R flag is set in the command, set the F flag in the
Match Report for this PCO and interface. Forbidden prefix formats
include, at a minimum, multicast, unspecified and loopback
addresses. [AARCH] Any implementation MAY forbid, or allow the
network manager to forbid other formats as well.
For each New Prefix which is already configured on the current
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -