Internet DRAFT - draft-baker-ipv6-isis-automatic-prefix
draft-baker-ipv6-isis-automatic-prefix
Network Working Group F.J. Baker
Internet-Draft Cisco Systems
Intended status: Standards Track February 19, 2013
Expires: August 23, 2013
Automated prefix allocation in IS-IS
draft-baker-ipv6-isis-automatic-prefix-00
Abstract
This note describes a TLV and associated mechanisms for the
allocation of /64 prefixes from a less specific prefix.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 23, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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.
Table of Contents
Baker Expires August 23, 2013 [Page 1]
Internet-Draft Automated Prefix Management February 2013
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 2
2.1. Autoconfiguration TLV Advertisement . . . . . . . . . . . 3
2.2. Subnet prefix allocation and announcement . . . . . . . . 3
2.3. Autoconfiguration TLV Withdrawal . . . . . . . . . . . . 4
2.4. Renumbering using autoconfiguration . . . . . . . . . . . 4
3. IPv6 Autoconfiguration TLV . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
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.
1.1. Requirements Language
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 [RFC2119].
2. Theory of Operation
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 [RFC3633],
although that is not actually required.
IS-IS [ISO.10589.1992] 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.
Baker Expires August 23, 2013 [Page 2]
Internet-Draft Automated Prefix Management February 2013
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.
2.1. Autoconfiguration TLV Advertisement
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
Section 3 within the intended area or network.
2.2. Subnet prefix allocation and announcement
Each router advertising a Reachability TLV [RFC5308], 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.
Baker Expires August 23, 2013 [Page 3]
Internet-Draft Automated Prefix Management February 2013
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.
2.3. Autoconfiguration TLV Withdrawal
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.
2.4. Renumbering using autoconfiguration
[RFC4192] 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
[RFC4192] 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 Section 2.3 and waits until the process is complete.
There are two obvious ways to determine completion:
o 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, or
o Wait 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.
Baker Expires August 23, 2013 [Page 4]
Internet-Draft Automated Prefix Management February 2013
At this point, the managing system may re-advertise the prefix as
described in Section 2.1, and the routers in the network will re-
allocate prefixes as described in Section 2.3.
3. IPv6 Autoconfiguration TLV
The structure of the Autoconfiguration TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = IANA | Length |U|X| Reserve | Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* - if present
U - up/down bit
X - external original bit
Figure 1: Autoconfiguration TLV
As is described in [RFC5305]: "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)
4. IANA Considerations
This section will request an identifying value for the TLV defined.
This is deferred to the -01 version of the draft.
5. Security Considerations
To be considered.
Baker Expires August 23, 2013 [Page 5]
Internet-Draft Automated Prefix Management February 2013
6. Privacy Considerations
To be considered.
7. Acknowledgements
8. Change Log
Initial Version: February 2013
9. References
9.1. Normative References
[ISO.10589.1992]
International Organization for Standardization,
"Intermediate system to intermediate system intra-domain-
routing routine information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO
Standard 10589, 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
9.2. Informative References
[I-D.baker-fun-routing-class]
Baker, F., "Routing a Traffic Class", draft-baker-fun-
routing-class-00 (work in progress), July 2011.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
Baker Expires August 23, 2013 [Page 6]
Internet-Draft Automated Prefix Management February 2013
[RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991.
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992.
[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
Author's Address
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Email: fred@cisco.com
Baker Expires August 23, 2013 [Page 7]
