Automated prefix allocation in
IS-ISCisco SystemsSanta Barbara93117CaliforniaUSAfred@cisco.com
Internet Engineering Task Force
This note describes a TLV and associated mechanisms for the
allocation of /64 prefixes from a less specific prefix.This note recommends an approach to the automated allocation of /64
prefixes within a network. This not something that will be done in a
heavily-managed network, but may be appropriate in networks with light
management, such as residential and SOHO networks.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .The premise is that some party allocates a prefix to a network, such
as a PA /48 or /56. The obvious way is using DHCP-PD , although that is not actually
required.IS-IS represents those
destinations as a type-length-value field that identifies an address.
For CLNS, it was designed to the ISO NSAP; by various extensions, it
also handles IPv4 and IPv6 prefixes and their counterparts for other
protocols. In this model, we add a TLV to advertise the delegated
prefix, with the expectation that routers in the network (including
pseudo-nodes) will allocate more specific prefixes from that prefix.In short, some specified system in the network, potentially a
configuration management system or the CPE router facing an upstream
network, is configured with an autoconfiguration prefix, and manages the
use of that prefix in the network.Upon recognizing that it has been configured with a prefix and that
the network management policy is for autoconfiguration, the system in
question advertises the autoconfiguration prefix described in within the intended area or network.Each router advertising a Reachability TLV
, including a pseudonode on a LAN, when it receives the
Autoconfiguration TLV Advertisement, calculates and announces a more
specific prefix from the advertised autoconfiguration prefix in a
Reachability TLV. This prefix is chosen at random, but may not collide
with any prefix currently advertised within the network and therefore
in the LSP database.There are obvious caveats here: if the autoconfiguration prefix is
too long and as a result there are more LANs than there are prefixes
to allocate to them, the procedure breaks down badly, and if there are
just exactly enough, it may take time to converge. Hence, from an
operational perspective, the autoconfiguration prefix should have
enough /64 more specific prefixes, and from an implementation
perspective, the randomization function must be sufficiently robust,
that independent choices are unlikely to collide.In the event of collision, which is likely to happen from time to
time, it is up to the nodes advertising the prefix in question to
detect and resolve the situation. Upon receiving an LSP containing its
"own" prefix advertised by another router, each router waits
CollisionDetect (10) seconds, to give the network ample opportunity to
detect the issue. It then waits an additional random interval between
zero and CollisionDetect seconds, to randomize the recovery process
and maximize the chance that replacement prefixes do not collide. It
then allocates a new prefix following the procedure described in this
section, and re-announces its LSP, removing (and therefore
withdrawing) the offending reachability TLV, and instead announcing
the new one.Subsequent procedures, such as the advertisement of Router
Advertisement using the allocated prefix or DHCPv6 allocation of
addresses, may start CollisionDetect seconds after the LSP has been
announced if no collision has been detected. At this point, routers
MAY store their /64s in non-volatile storage.When the prefix advertised in the Autoconfiguration TLV expires or
is withdrawn, the Autoconfiguration TLV is withdrawn from the network.
Upon detection of the withdrawal, each router in the network MUST
withdraw any addresses or prefixes dependent on it. If those prefixes
are stored in non-volatile storage, they MUST also be removed. describes the process of renumbering
in some detail. The discussion here is somewhat simplistic; refer to
that for a more detailed discussion.In short, "renumbering" a network is a special case of "numbering"
a network. If there is one prefix in use in a network and it is
withdrawn, the network will experience an outage. Hence, it is
generally advisable to ensure that there are at least two prefixes in
use in a network when one of them is removed. This might be
accomplished by simply using multiple prefixes in the network; it
might also be accomplished by deploying a second autoconfiguration
prefix minutes or hours before the "old" one is removed. During that
time, DNS and DHCP databases need to be updated as described in to reflect the new prefix.If an outage is acceptable, it is also possible to renumber using
the same prefix. For this, the administration withdraws the prefix as
described in and waits until the
process is complete. There are two obvious ways to determine
completion: Wait long enough that it is highly unlikely to have not
completed, which might be the number of routers in the network
diameter times the LSP update retransmission interval, orWait until the managing router's LSP database contains no
Reachability TLVs that depend on the prefix.At this point, any systems that are only using that prefix are now
unreachable using global addressing.At this point, the managing system may re-advertise the prefix as
described in , and the routers in
the network will re-allocate prefixes as described in .The structure of the Autoconfiguration TLV is as follows:As is described in : "The up/down bit
SHALL be set to 0 when a prefix is first injected into IS-IS. If a
prefix is advertised from a higher level to a lower level (e.g. level 2
to level 1), the bit SHALL be set to 1, indicating that the prefix has
traveled down the hierarchy. Prefixes that have the up/down bit set to 1
may only be advertised down the hierarchy, i.e., to lower levels".If the prefix was distributed into IS-IS from another routing
protocol, the external bit SHALL be set to 1. This information is useful
when distributing prefixes from IS-IS to other protocols.The prefix is "packed" in the data structure. That is, only the
required number of octets of prefix are present. This number can be
computed from the prefix length octet as follows: prefix octets = integer of ((prefix length + 7) / 8)This section will request an identifying value for the TLV defined.
This is deferred to the -01 version of the draft.To be considered.To be considered.February 2013