IPv6
Internet Draft T. Hain
Document: draft-hain-ipv6-sitelocal-01.txt Cisco
Expires: November 2003 May 2003
Local Scope Address Requirements
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
This memo will discuss the site network manager's requirements for
an address range available for use in a local routing scope.
Status of this Memo................................................1
Abstract...........................................................1
Introduction.......................................................2
What is a private use address space, and why is it discussed here?.3
Requirements for a local scope address space.......................4
Global routing impact..............................................5
Address range......................................................5
Site-local scope...................................................6
Applications of private address space today........................7
Potential applications of private address space....................8
Summary............................................................9
Security Considerations...........................................10
References........................................................10
Acknowledgments...................................................11
Author's Addresses................................................11
T. Hain Expiration - November 2003 [Page 1]
Site-Local Requirements May 2003
Introduction
There has been much discussion lately about the role of site-local
addresses. This memo will discuss the requirements, architectural
role of a limited scope address range for local use, as well as some
real world deployment examples.
Many network managers have developed a comfort level with private
addresses in IPv4, and the first thing they look for in IPv6 is the
comparable mechanism. Their absolute requirement for filtering will
trump any complaints about broken applications. A common mechanism
for accomplishing this is to designate some parts of the address
space as limited to the scope of the local network or site. Well-
known site-local address prefix provides an opportunity to move
beyond the common IPv4 model where all nodes in a network use the
same single scope of filtered space, by providing simultaneous
support for site/global space. To gain the acceptance of network
managers, tools they use as security measures must start from
exactly the same point they are in IPv4. Then with simultaneous use
of local and global prefixes there is an opportunity to expand the
functionality of the network.
Most of the arguments against the use of the currently defined site-
local address prefix amount to wanting applications to work even in
the presence of this intentional filtering imposed by the network
manager. These arguments to remove local scope addresses from the
architecture is equivalent to; we should prevent you from doing harm
to yourself by insisting that scissors were never invented, that way
we don't have to keep telling you not to run with them. Filtering
will exist in networks, so there will be domains of applicability,
or local scopes. Applications that insist on passing topology
information outside the domain of applicability will fail to operate
correctly in this environment.
A defined prefix for local use uniquely identifies addresses that
have a limited administrative domain of applicability. This prefix
provides a network manager with a stable address range, as well as
establishes a clear filter to limit introduction into the public
network. A "site" is, by intent, not rigorously defined (just as
Areas are not rigorously defined in an IGP), but is typically
expected to cover a region of topology that belongs to a single
organization and is located within a single geographic location,
such as an office, an office complex, or a campus. As such, one
common use instance of a site border will be the boundary between
the IGP and EGP. Use of local scope addresses for connections
external to a site is strongly discouraged, because it is difficult
to know when applications will encounter the boundary of the domain
of reference. When applications are expected to work across the site
boundary, care should be taken to ensure all participating nodes
have global scope addresses available.
T. Hain Expiration - November 2003 [Page 2]
Site-Local Requirements May 2003
What is a private use address space, and why is it discussed here?
For purposes of this discussion, a private use address space is any
set of addresses that can not be reached from a significant portion
of the public Internet. The reasons for lack of ability to reach
these addresses are based on policy local to the network using them
vs. policy at an arbitrary remote network.
The implementation mechanism used to accomplish that policy could be
simply restricting the range of routing announcements, or explicit
access controls in a device along the path. In either of those
cases, the result is a local scope with a well defined boundary
controlled by the network manager using the addresses. A consequence
of the implemented policy is that any packets destined for locations
within the limited scope, must originate and stay within that scope,
as there is no way to deliver packets from outside the defined
scope.
As a simple example, take the case below where A & B have a choice
of addresses that they can use to reach each other, but C can only
reach the Public addresses of either.
---- A ----
| |
L P
o u
c b
a l ---- C
l i
| c
| |
---- B ----
One of the requirements of this network environment is that any
process that intends to provide C with topology information for
reaching A or B, needs to understand the topology so that it can
provide C with correct and useful information.
An alternate way to draw the example network is:
---- A ---- -
| | |
L G P
o l u
c o b
a b - R - l ---- C
l a i
| l c
| | |
---- B ---- -
This alternate view correlates the public side of A & B where they
share some aspect of the routing hierarchy. The result still
T. Hain Expiration - November 2003 [Page 3]
Site-Local Requirements May 2003
requires that any process that intends to provide C with topology
information understands the topology to recognize the local and
global scope differences to provide useful information.
To simplify subsequent discussion, the labels will be changed using
that same view. The local prefix will be shown as P(l), while the
global public prefix will be shown as P(g).
---- A ---- -
| | |
| | P
| | u
| | b
P(l) P(g) - R - l ---- C
| | i
| | c
| | |
---- B ---- -
This sequence of network drawings has been presented to show that
limited scopes exist in many IPv4 network deployments today.
Additional discussion of the policies that drive these deployments
can be found in a discussion on deployment and use of a proposed
Provider Independent (PI) address space [2]. Any specific PI
mechanism is not the issue here, so much as the policies that drive
deployment of an address space that is not controlled by the public
network service provider. Further discussion of the requirements for
site controlled space follow in the next section.
Requirements for a local scope address space
Easy to get - No public registration, payment, customer/provider
relationship, or approval required. Network managers have stated,
and historical experience has shown, that there is a need for
address space that does not require public registration.
Stable - Both during ISP changes, and for intermittently connected
networks. The address space available for local use must not be
subject to change by an external entity, and must not create a real
or artificial lock-in to any provider.
Private û Well known routing filter provides multiple levels of
filtering to ensure a single error does not expose the network to
global access. While the local use address space is generally for
use within a network, it is often used in private interconnects.
This may be to avoid exposing the relationship, or may be to provide
a dedicated resource between the networks. In any case, the goal of
restricting these addresses to a local scope is to prevent access
from the public network.
T. Hain Expiration - November 2003 [Page 4]
Site-Local Requirements May 2003
There is a strong requirement for an easy-to-get, stable, private
address space for use in local networks. In some cases this is
simply to avoid the necessary costs associated with running a
registration infrastructure, but in others it is to avoid exposing
their internal network plans to competitors. Placing all local use
address space in a common short prefix allows everyone to filter it
which prevents unwanted exposure in the case of single point
configuration errors.
Global routing impact
The strong demand for stable address space also applies to cases
where network managers want global access. There is a concern that
some network managers will demand that their service providers route
the local scope address range globally. Unless they are specifically
designed to be PI space, local scope addresses must stay local, and
not be leaked into the global routing system. The issue is that
without designed aggregation properties, accepting them will lead to
a global routing table explosion. For this reason a PI mechanism
with reasonable aggregation properties needs to be developed along
side the local use address range. One approach is proposed in An
IPv6 Provider-Independent Global Unicast Address Format [3]. While
this does not aggregate to the same degree as the PA approach, it
does provide a stable space that has modest aggregation properties.
The local use address space has no aggregation properties, and must
not be routed arbitrarily.
Address range
The address range provided for local use is an architecturally
supported, end-user-controlled address space. The address range is
set aside as a block that network managers can use without any
registration, payment, or approval from external sources.
Using the well-known prefix range for local usage provides a hint
that a filtering policy has been applied somewhere in this network,
though it does not by itself indicate where the boundaries are.
Given the presence of a local scope address, an application that
chooses to check can infer that there is an explicit filter
somewhere in the network. That filter may or may not be between it
and the application peer.
The only difference between a individual network defined non-
routable global prefix and a well-known local use prefix is the
coordination and verification of filters. Any prefix can be used in
a local-only context, but the ability to detect a configuration
error which leads to open routing is limited unless it is well-
known.
T. Hain Expiration - November 2003 [Page 5]
Site-Local Requirements May 2003
Local scope
The concept of address scoping is nothing more than a formalization
of the existing deployments of limited route announcements, or
explicit filtering. Defining a well-known address range for local
use allows broad deployment of filters at the edge of the public
network without additional site specific coordination.
Concurrent use of local & global scope addresses allows neighboring
nodes on a network to have individual policies about global
visibility. This moves the policy decision from the edge to the
originating device, which allows the application which has enough
information decide the appropriate action, rather than the
alternative brute force edge approach one-size-fits-all policy. In
the case of devices that move between subnets, it also mitigates the
need for continuous changes of access controls at the edge.
The boundaries of a site are intentionally undefined. An
organization should probably start with the assumption that a site
boundary is exactly congruent with an IGP area or IGP/EGP boundary,
but they may choose to restrict it further, or expand it when it
makes sense for their network. The concepts of sites and IGP areas
are similar in that they are about limiting how much information is
exposed across administrative borders. In any case a policy boundary
will exist at any attachment point to the public Internet, so that
is a very likely place to implement a scope boundary.
While the earlier examples showed a physical separation between the
local and global topology, the scenario is identical between
multiple interfaces with a single address, and individual interfaces
with multiple addresses. This characteristic results in another view
of the example network:
A ---- -
| |
| P
| u
| b
P(l)&P(g) - R - l ---- C
| i
| c
| |
B ---- -
This configuration is not typical in IPv4 networks because
implementing multiple addresses per interface is relatively
difficult. In this view, the router R either informs the public
network of only the global prefix A & B are using, or if the local
use prefix is a subset of the global prefix, R explicitly controls
access to the local use portion. Either way, C can only reach A(g) &
B(g), while A & B can reach either P(g) or P(l). In any case, the
T. Hain Expiration - November 2003 [Page 6]
Site-Local Requirements May 2003
issues raised by the limited routing scope of P(l) are the same as
they were in the multiple interface case we started with, and
completely independent of the allocation source of P(l).
Adding a little more detail to the drawing, shows the distinction
between the customer premise equipment (CPE) router, and the
provider edge (PE) router.
A ---- -
| |
| P
| u
| b
P(l)&P(g) û R(cpe) û R(pe) - l ---- C
| i
| c
| |
B ---- -
Again, the issues don't change, this simply allows discussion about
how P(g) & P(l) are handled at each of those points.
Placing all the local use prefixes under a common shorter prefix
allows the service provider to have a common bogon filter at all
R(pe) borders. This additional level of filtering provides a backup
in the case that R(cpe) is misconfigured in a way that would allow
access to P(l) from the public network. Accomplishing the same
degree of isolation when P(l) is a subset of P(g), would require a
unique configuration for every R(pe), and would explicitly expose
P(l) to global access in the case of a configuration error in
R(cpe).
Applications of private address space today
Network managers limit specific applications to internal use, so
they configure them to only work with a filtered address range. This
simplifies the border filter to an address prefix, rather than
needing to employ deep packet inspection to track a potentially
dynamic range of ports.
Research ships at sea intermittently connect via INMARSAT, or when
in port, the shipboard network is connected to shore via Ethernet.
Of utmost importance is that the systems on board the ship all
function, providing data collection and analysis without
interruption. Static addressing is used on most intra-ship network
components and servers. It's quite expensive to operate a research
ship, so eliminating points of failure is important. Scientists on
board collaborate with colleagues back home by sharing of data and
email. Currently private address space is employed for several
reasons: 1) it provides the ability to allocate significant address
space to each ship without needing to worry about how many computers
T. Hain Expiration - November 2003 [Page 7]
Site-Local Requirements May 2003
will be on a given cruise. 2) it provides separate address space for
each ship. 3) it simplifies filtering to ensure shipboard traffic is
not permitted to transmit out or bring up expensive satellite links.
Private space is used to avoid exposing to competitors what internal
networks they are deploying and which office is coordinating that
effort. Network managers also don't have to expose business plans to
a registrar for evaluation for networks that are not attached to the
global Internet. Some have stated that if they are required to
register for public space for every internal use network, they are
more likely to pick random numbers than tip off the competition.
Another significant use of private address space is test networks.
Frequently these are large, elaborate networks with a mix of public
and private address space. Use of random unallocated space runs the
risk of collision with legitimate addresses on remote networks.
Potential applications of private address space
A well-known prefix than can be embedded in appliances so they are
easy to sell to the average consumer and a simple filter limits
access to the home network. Such a prefix would also simplify the
case of file system mounts between nodes on an intermittently
connected network. If the mount dropped every time a connect event
caused addresses to change, the consumer would quickly find another
product.
Company X has 125,000 employees globally, with regular
reorganizations causing constant office shuffles between regions.
Each employee has a laptop, which will have global access, and a
network connected printer which will not have global access (we
won't bother with the rest of the network connected devices here).
There are 100 touch-points to the Internet, with the 3 primary ones
running multiple OC-48 access loops.
The 'explicit filter lists at the border' model requires keeping 100
tables in sync in the face of constant change, and parsing a 125,000
entry list at OC-48 rates for every packet at 3 of the borders.
The 'well-known SL filter at the border' model requires the
organization to tell their printer manufacturer to preconfigure all
the devices they buy to only accept and auto-configure SL prefixes
from the RA (likely a widely demanded item), and put in a 2 entry
list that remains static at every border. In addition, it is
reasonable and expected that the peer across the border will
maintain a matching version of the filter list.
The compromise model of 'using 2 public prefixes per segment' allows
for a 2 entry static list at every border, which may or may not be
considered reasonable to match by the border peer. It does not
provide the printer manufacturer a preconfiguration option that
T. Hain Expiration - November 2003 [Page 8]
Site-Local Requirements May 2003
matches other customers, and even if it was done, as soon as Company
X changes providers, they have to manually touch every printer for
the new configuration.
To make the name service simple in these 3 cases, Company X chooses
to run back-to-back normal dns servers. The primary set facing
internally to accommodate dynamic updates, with a slave set facing
externally. A periodic process will replicate the information from
the source-of-truth internal facing servers to the external ones,
but the security team requires it to scrub out all records for
internal-only nodes.
For model 1, the scrubbing process would have to contact the border
filter list (after deciding which was the current source of truth),
then parse through it for all 250,000 entries to decide which are
replicated.
For model 2, the scrubbing process simply has to drop records with
the SL prefix and replicate all others.
For model 3, the scrubbing process has to look for the set of
prefixes that identify private-use, and replicate all others.
Once any one of these processes completes, all nodes are accessible
by name in the internal scope, and all nodes that should be accessed
from the outside are accessible by name in the global scope.
Applications that are expected to work across the border will have
global scope addresses to use. Multi-party apps that use name-string
referrals will work across the border, but those that use SL
literals will fail by design (note: use of SL == expected to fail
across border). Use of filtered global scope addresses makes it
impossible for the application to know why it failed to connect.
Summary
Filtering creates a scoped address space, no matter where the bits
come from. The point is that some addresses are only valid within
the scope defined by the local network manager.
In the simple case, hosts that are allowed external access have a
policy that allows them to configure a global prefix along with the
local one, while those that are not allowed global access have a
policy that only allows configuring the local prefix. Address
selection rules will prefer the smallest scope, so internal
communications use the local scope and are forced to stay internal
by the hard filter at the border. This puts the burden of policy
application at the address assignment time (very infrequent) rather
than deep parsing every packet to figure out which app sent it.
T. Hain Expiration - November 2003 [Page 9]
Site-Local Requirements May 2003
If an app chooses to assert a policy that is different from the
network manager's filtering rules, it will fail. Having a well
defined address space that is known to have filtering applied allows
apps to have a hint about potential scope restrictions. That hint
may or may not be helpful, but lack of it leaves the app in complete
trial & error mode.
Some application developers have figured out that having an
architected space makes it easier for them to know when connectivity
will be broken, but others have not. The arguments by those that
have not figured it out are much more about disallowing 'broken
connectivity' than they are about figuring out when that happens.
Reality says that network managers want to, and will break
connectivity when it is in their interest, and no amount of IETF
documentation to the contrary will prevent that.
We can choose to leave the network managers to figure out their own
adhoc mechanisms, or we can put them in a structured space so that
apps will have a chance to react appropriately.
Security Considerations
The concept of route filtering is frequently used as a tool to aid
in network security, so having a well-known range to filter enhances
the deployment of that tool.
Access control is one aspect of what SL provides. It is a clear
address space that service providers can put in bogon filters, and
enterprise managers can filter without having to go into detail
about which specific devices on a subnet are allowed in or not. It
does not comprise a full service security solution, and should not
be sold as such. It is simply a way to clearly articulate the
difference between public and private endpoints.
At the same time the majority of sites that use SL, will simply
treat them as a set of prefixes to be passed around in their IGP.
Since it will require both parties to misconfigure BGP to get those
prefixes leaked between enterprises, they will feel more secure
about using them. For this simple reason we need to meet the network
manager at his comfort zone and provide a familiar tool.
References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 draft-hain-ipv6-pi-addr-use-04.txt, Hain, T.
3 draft-hain-ipv6-pi-addr-04.txt, Hain, T., An IPv6 Provider-
Independent Global Unicast Address Format
T. Hain Expiration - November 2003 [Page 10]
<Title> May 2003
Acknowledgments
Daniel Senie, Tim Hartrick, Michel Py, and Stephen Sprunk provided
valuable input in the creation of this document.
Author's Addresses
Tony Hain
Cisco Systems, Inc.
500 108th Ave. NE, Bellevue, Wa.
Email: alh-ietf@tndh.net
<Lastname> Expiration November 2003 [Page 11]