One document matched: draft-hain-ipv6-sitelocal-00.txt
IPv6
Internet Draft T. Hain
Document: draft-hain-ipv6-sitelocal-00.txt Cisco
Expires: September 2003 April 2003
Site-Local 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 requirements for the Site-Local address
range.
Status of this Memo................................................1
Abstract...........................................................1
Introduction.......................................................2
Requirements for a local scope address space.......................3
Easy to get........................................................3
Stable.............................................................3
Private............................................................3
Address range......................................................3
Site-local scope...................................................4
Applications of private address space today........................4
Potential applications of private address space....................5
Summary............................................................6
Security Considerations............................................7
References.........................................................7
Acknowledgments....................................................8
Author's Addresses.................................................8
T. Hain Expiration - October 2003 [Page 1]
Site-Local Requirements April 2003
Introduction
There has been much discussion lately about the role of site-local
addresses. This memo will discuss the requirements, architectural
role of the address range and scoping, 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, which means there
will be address space limited to the scope of a site. Well-known
site-local addresses provide an opportunity to move beyond the
current model where all nodes are required to live in the single
scope of filtered space, by providing simultaneous support for
site/global space. To gain the acceptance of network managers,
security measures must start from exactly the same point they are in
IPv4. Then with simultaneous use of site-local and global prefixes
we have the opportunity to expand the functionality of the network.
Most of the arguments against the use of site-local addresses amount
to wanting applications to work even in the presence of intentional
filtering imposed by the network manager. The argument to remove
site-local 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 scopes. Applications that
insist on passing topology information outside its domain of
applicability will fail to operate correctly.
The site-local address format uniquely identifies interfaces within
a single administrative domain of applicability. Site-local
addresses are designed to provide stable addresses for use inside a
site. 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
site-local addresses for connections external to a site is strongly
discouraged, because they will usually be ambiguous values outside
their 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 - October 2003 [Page 2]
Site-Local Requirements April 2003
Requirements for a local scope address space
Easy to get
No public registration, payment, customer/provider relationship, or
approval required.
Stable
Both during ISP changes, and for intermittently connected networks.
Private
Well-known routing filter provides multiple levels of filtering to
ensure a single error does not expose the network to global access.
Global routing impact
Local scope addresses must stay local, and not be leaked into the
global routing system.
Address range
The site-local address range provides 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.
Allocating a well-known address range for site-local 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 site-local address, an application that
chooses to look 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 non-routable global prefix and a well-
known site-local 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.
A side-effect of a well-known site-local range over global scope
prefixes is the simplification of diagnostic efforts for
communications within the site. It makes little sense to use random
IID's within the boundaries of a site, and avoiding them makes it
easier for the support team to correlate network traces. It is
T. Hain Expiration - October 2003 [Page 3]
Site-Local Requirements April 2003
reasonable to expect OS vendors to prevent binding an RFC 3041 IID
to the SL prefix without explicit configuration. In turn, it would
require explicit configuration of every device to recognize the
private nodes (either private-use public prefix, or the entire
border filter list) to avoid use of a random IID when talking to
those nodes.
Site-local scope
The concept of address scoping is nothing more than a formalization
of the existing deployments of route filtering. The fact that we
have 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 site-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 device. In the case of devices that move between subnets, it
mitigates the need for continuous changes of access lists 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, 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 boundary will exist at any
attachment point to the public Internet.
Applications of private address space today
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
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
T. Hain Expiration - October 2003 [Page 4]
Site-Local Requirements April 2003
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.
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.
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 sharing 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.
T. Hain Expiration - October 2003 [Page 5]
Site-Local Requirements April 2003
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
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, we will 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 of the filter.
A simple example would be; as per spec, site-local is filtered at
the border, while global prefixes are allowed without restriction.
Hosts that are allowed external access have a policy that allows
them to configure a global prefix along with the SL one, while those
that are not allowed out have a policy that only allows configuring
a site-local prefix. Address selection rules will prefer the
smallest scope, so internal communications use site-local 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
T. Hain Expiration - October 2003 [Page 6]
Site-Local Requirements April 2003
(very infrequent) rather than parsing every packet for access
control.
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.
T. Hain Expiration - October 2003 [Page 7]
<Title> April 2003
Acknowledgments
Daniel Senie, Tim Hartrick, and Michel Py 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 October 2003 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 06:09:48 |