One document matched: draft-hain-templin-ipv6-limitedrange-01.txt
Differences from draft-hain-templin-ipv6-limitedrange-00.txt
IPv6 Working Group T. Hain
Internet-Draft Cisco Systems, Inc.
Expires: February 11, 2004 F. Templin
Nokia
August 13, 2003
Addressing Requirements for Local Communications within Sites
draft-hain-templin-ipv6-limitedrange-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
This Internet-Draft will expire on February 11, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The IPv6 addressing architecture specifies global and local-use
unicast addressing schemes, but provides no operational guidelines or
requirements for their use. There is a strong requirement for
addressing to support local communications within sites. Of special
interest are "active sites", e.g., sites that are
intermittently-connected or disconnected from the global Internet,
sites that frequently change provider points of attachment, sites
that temporarily or permanently merge with other sites, multi-homed
sites, etc. This memo will discuss addressing requirements for local
communications within sites.
Hain & Templin Expires February 11, 2004 [Page 1]
Internet-Draft Local Addressing Requirements August 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Easy to Acquire . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Stable . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Multiple Link Support . . . . . . . . . . . . . . . . . . . 4
3.4 Well-known Prefix . . . . . . . . . . . . . . . . . . . . . 4
3.5 Global Uniqueness . . . . . . . . . . . . . . . . . . . . . 5
3.6 Provider Independence . . . . . . . . . . . . . . . . . . . 5
3.7 Applicable in Managed/Unmanaged Environments . . . . . . . . 6
3.8 Compatible with Site Naming System . . . . . . . . . . . . . 6
3.9 Compatible with VPN . . . . . . . . . . . . . . . . . . . . 6
3.10 Multiple Addressing . . . . . . . . . . . . . . . . . . . . 6
4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Applications of Private Addressing Today . . . . . . . . . . 7
4.2 Mobile Router with Personal Area Network . . . . . . . . . . 8
4.3 Mobile Ad-hoc Networks that Travel Together . . . . . . . . 8
4.4 Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 8
4.5 Asset Protection in Enterprise Networks . . . . . . . . . . 9
4.6 Home Networks . . . . . . . . . . . . . . . . . . . . . . . 9
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . 11
Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11
A. Filtering Considerations . . . . . . . . . . . . . . . . . . 12
B. Routing Considerations . . . . . . . . . . . . . . . . . . . 12
C. Multiple Addressing Considerations . . . . . . . . . . . . . 14
D. Potential Applications of Limited Range Address Space . . . 15
E. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . 18
Hain & Templin Expires February 11, 2004 [Page 2]
Internet-Draft Local Addressing Requirements August 2003
1. Introduction
The IPv6 addressing architecture [RFC3513] specifies global and
local-use unicast address formats. Global addresses are understood to
have unlimited range and may be used as the source and destination
addresses in packets that originate from any point on the connected
global IPv6 Internet. Local-use addresses are intended for use only
within the range of a single link/site, but their specification does
not address operational considerations and does not account for the
esoteric aspects of terms such as "site".
There is a strong requirement for addressing that supports local
communications within sites. Of special interest are "active sites",
e.g., sites that are intermittently-connected or disconnected from
the global Internet, sites that frequently change provider points of
attachment, sites that temporarily or permanently merge with other
sites, multi-homed sites, etc. This memo will discuss addressing
requirements for local communications within sites in the context of
real world deployment scenarios.
2. Terminology
site:
an entity autonomously operating a network using IP and, in
particular, determining the addressing plan and routing policy for
that network. This is the same definition as [MULTI6].
active site:
a site that may be intermittently-connected or disconnected from
the global Internet, may frequently change provider points of
attachment, may have multiple concurrent provider points of
attachment, may temporarily or permanently merge with other sites,
etc.
range:
domain of applicability.
identifier range:
range within which an address uniquely identifies an entity.
Addresses that may possibly identify multiple entities within a
limited range are said to be ambiguous.
locator range:
filtering and/or routing functions set by operational policy that
determine a limited range.
Hain & Templin Expires February 11, 2004 [Page 3]
Internet-Draft Local Addressing Requirements August 2003
3. Requirements
There is a strong requirement for addressing that supports local
communications within sites. An obvious solution alternative is an
easy-to-get, stable, private address space for use within a limited
range as this is consistent with current practices familiar to IPv4
network managers. Alternative solution proposals should be made
available in a timely fashion through full disclosure to the public
domain so that their merits can be evaluated. The following sections
present addressing requirements for local communications within
sites.
3.1 Easy to Acquire
Addresses must be made available that require no public registration,
payment, customer/provider relationship, or approval. Network
managers have stated, and historical experience has shown, that there
is a need for addresses that do not require public registration.
These addresses must be architecturally supported and
end-user-controlled.
3.2 Stable
Applications require addresses that remain stable during intermittent
connectivity, site mergers, change to a new provider, etc. In
particular, applications should not be affected by address
renumbering events [BAKER].
The addressing scheme should also support stable communications
within sites that are mobile. In particular, addresses should remain
stable as the site moves to new topological points of attachment or
geographical coordinates.
3.3 Multiple Link Support
Addressing for local communications within sites should support
operation over multiple links, e.g., via L3 routing, L2 bridging or
some combination thereof. As such, subnetting consistent with the
recommendations in ([RFC3177], section 3) should be supported.
Link-local addresses in IPv6: "are designed to be used for addressing
on a single link for purposes such as automatic address
configuration, neighbor discovery, or when no routers are present"
([RFC3513], section 2.5.6). By definition, link-local addressing has
a single link range of operation and will not meet this requirement.
3.4 Well-known Prefix
Hain & Templin Expires February 11, 2004 [Page 4]
Internet-Draft Local Addressing Requirements August 2003
Placing portions of the address space in a common short prefix allows
everyone to filter it which prevents unwanted exposure in the case of
single point configuration errors. In this solution alternative, the
common prefix must not end up in the global routing system, even
accidentally.
Using a well-known prefix provides a hint that a filtering policy has
been applied somewhere in the network, though it does not by itself
indicate where the boundaries are. Alternative solution proposals
should be made available in a timely fashion through full disclosure
to the public domain so that their merits can be evaluated. Given the
presence of the well-known prefix, 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.
3.5 Global Uniqueness
/48 prefixes used by sites [RFC3177] must be globally-unique such
that site mergers will not result in collisions. Global uniqueness is
based on the statistical properties of the prefix assignment,
therefore a suitable means for random prefix generation must be
specified.
Sufficient global uniqueness is required to support:
o VPNs between enterprises
o dynamically created VPNs in support of temporary virtual
organizations
o service provider co-location of hosts that reside in the address
space of multiple customers
o formation of virtual organizations (Grids) among enterprises
o mergers and acquisitions of enterprises such that address spaces
do not collide
Achieving these goals does not require absolute uniqueness, but an
extremely low probability of collisions resulting in conflict is
required. The addressing scheme must also provide a means for
conflict resolution, e.g., certification through a central registry,
distributed database, etc.
3.6 Provider Independence
Active sites require addresses that are provider independent (PI) and
Hain & Templin Expires February 11, 2004 [Page 5]
Internet-Draft Local Addressing Requirements August 2003
do not create a real or artificial lock-in to any provider. In the
case of intermittently-connected sites, provider aggregated prefixes
may be unavailable for long periods but this must not disrupt local
communications within the site. In the case of movement to new
providers, frequent site renumbering events may occur but, again,
local communications must not be affected.
The strong demand for PI addressing also applies to cases where
network managers want global access. The issue is that PI addresses
have no designed aggregation properties, thus advertising them
outside the site may lead to global routing table explosion given
current routing technologies. For this reason:
o a PI mechanism with reasonable aggregation properties should be
investigated.
o a feasibility study for routing technologies with better scaling
properties should be undertaken.
3.7 Applicable in Managed/Unmanaged Environments
Some sites (e.g., large enterprises) may have network management
teams responsible for address planning while others (e.g., home
networks and personal area networks) may require unmanaged operation.
The addressing scheme must provide general applicability in any
environment - be it managed or unmanaged.
3.8 Compatible with Site Naming System
Addresses for local communications within sites must be compatible
with the site's naming system. Examples include DNS, multicast name
resolution, static configuration, etc. In practice, it is expected
that addresses will be resolved only within the range of operation of
the naming system.
3.9 Compatible with VPN
The addressing scheme should support VPN connections between multiple
sites, e.g., to form geographically-extended organizations. Prefix
delegations in effect at each constituent site must remain valid when
connected via VPN.
3.10 Multiple Addressing
A well-known address prefix provides an opportunity to move beyond
the common IPv4 model where all nodes in a network use the same
single range of filtered space, by providing simultaneous support for
Hain & Templin Expires February 11, 2004 [Page 6]
Internet-Draft Local Addressing Requirements August 2003
local and 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.
Concurrent use of limited & global range 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.
Alternative solution proposals should be made available in a timely
fashion through full disclosure to the public domain so that their
merits can be evaluated.
4. Scenarios
Many anticipated IPv6 deployment scenarios require an addressing
scheme that meets the requirements outlined in Section 3. An example
real life deployment scenario is as follows:
o site A sets up a local network with no ISP connection; the network
should "just work" out of the box
o site A later connects to an ISP for external connectivity, but
uses filtering to avoid exposing internal addressing to the
outside
o in the meantime, site B performs corresponding actions
o sometime later, sites A and B connect, e.g., via VPN, shared link,
etc. The sites can send local traffic to each other as well as
traffic out either of the sites' ISPs
o sometime later, site A disconnects from its ISP and site B's ISP
is used
o sometime later, site A disconnects from site B
o sometime later, site A registers with a new ISP
Addressing schemes for local communications within sites should
support this scenario as well as others described in the following
subsections:
4.1 Applications of Private Addressing Today
Hain & Templin Expires February 11, 2004 [Page 7]
Internet-Draft Local Addressing Requirements August 2003
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.
Private space may be 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.
4.2 Mobile Router with Personal Area Network
Multiaccess terminals that serve as routers between the operator and
a personal area network (PAN) of the user's locally-connected devices
are seen as a near-term deployment scenario. Access to the operator
may be intermittent, yet local communications within the PAN must be
supported even when no connection to the global Internet is
available. As mobile users travel about, multiple PANs may come
together in a common space such that two or more PANs merge. As such,
the address prefixes used in each PAN should be globally unique to
avoid collisions and provide a means for verifying ownership to
resolve conflicts.
4.3 Mobile Ad-hoc Networks that Travel Together
As with the mobile PAN in Section 4.2, mobile ad-hoc networks of
nodes that travel together as a group may have long periods of
intermittent/disconnected access to the global Internet. Such
applications as disaster relief, coordinated missions, and
expeditionary forces may comprise numerous ad-hoc networks that may
merge, partition, or lose global connectivity from time to time. An
addressing scheme is needed for the continuous support of local
communications in such mobile ad-hoc networks.
4.4 Vehicular Networks
Vehicular networks may connect elements in an automobile to provide
sensory and situational awareness data to the driver. Periodic
Hain & Templin Expires February 11, 2004 [Page 8]
Internet-Draft Local Addressing Requirements August 2003
contact with roadside Internet access points, other vehicles, etc.
may entail sharing public information (e.g., road conditions
encountered) while protecting private information (e.g., the
vehicle's speedometer reading). The addressing scheme should provide
a means for denoting both public and private components, e.g., for
filtering at site borders.
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.
4.5 Asset Protection in Enterprise Networks
Enterprise networks that protect private corporate assets (e.g.,
printers, faxes, robotics, sensors, etc.) require an addressing
scheme that remains stable even when VPN connections from outside
sites occur. Such VPN connections may arise from home users,
corporate mergers and acquisitions, bridging remote sites together,
etc. Prefixes used for protecting private assets must not end up in
the global routing system, even by accident.
4.6 Home Networks
Home networks with intermittent access to a service provider require
an addressing scheme that supports local communications even when the
service is unavailable. The addressing scheme should also protect
private assets from exposure to the global Internet and should allow
continuous operation when VPN connections to the office or other
extended sites are used.
5. Summary
Filtering creates addressing boundaries, no matter where the bits
come from. The point is that some addresses are only valid within the
range defined by the local network manager.
In the simple case, hosts that are allowed external access have a
Hain & Templin Expires February 11, 2004 [Page 9]
Internet-Draft Local Addressing Requirements August 2003
policy that allows them to configure both global and limited range
prefixes, while those that are not allowed global access have a
policy that only allows limited range. Address selection rules will
prefer the smallest range, so internal communications are forced to
stay internal by the hard filter at the border.
If an application chooses to assert a policy that is different from
the network manager's filtering rules, it will fail. Having a well
defined limited range address space that is known to have filtering
applied allows applications to have a hint about potential range
restrictions. We can choose to leave the network managers to figure
out their own adhoc mechanisms, or we can put them in a structured
limited range address space so that applications will have a chance
to react appropriately.
A limited range addressing scheme would seem a logical choice to
satisfy the requirments and real-life scenarios outlined in this
document, but the authors recognize that it may not be the ONLY
choice. Alternative solution proposals should be made available in a
timely fashion through full disclosure to the public domain so that
their merits can be evaluated.
6. IANA Considerations
This requirements document does not introduce any IANA requirements,
though mechanisms that meet these requirements may.
7. 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 limited range addressing
provides. It is a clear address space that service providers can put
in filters, and enterprise managers can filter without having to go
into detail about which specific devices on a subnet are allowed. It
does not comprise a full service security solution, and should not be
represented as such.
8. Acknowledgements
The authors acknowledge the contributions of numerous postings on the
ipng mailing list [IPNG] that led to a better community understanding
of addressing issues for local communications within sites. In
particular, the following individuals provided valuable input for
this document: Brian Carpenter, Tim Hartrick, Eliot Lear, Michel Py,
Daniel Senie, Stephen Sprunk, and Michael Thomas. Special thanks to
Hain & Templin Expires February 11, 2004 [Page 10]
Internet-Draft Local Addressing Requirements August 2003
Andrew White for supplying an example real-life scenario.
Normative References
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
Informative References
[BAKER] Baker, F., "Procedures for Renumbering an IPv6 Network
without a Flag Day",
draft-baker-ipv6-renumber-procedure-00 (work in progress),
April 2003.
[HAIN] Hain, T., "Application and Use of the IPv6 Provider
Independent Global Unicast Address Format",
draft-hain-ipv6-pi-addr-use-04 (work in progress), April
2003.
[IPNG] "IPng mailing list archive: ftp://playground.sun.com/pub/
ipng/mail-archive".
[MULTI6] Abley, J., Black, B. and V. Gill, "Goals for IPv6
Site-Multihoming Architectures",
draft-ietf-multi6-multihoming-requirements-07 (work in
progress), June 2003.
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address",
RFC 3177, September 2001.
Authors' Addresses
Tony Hain
Cisco Systems, Inc.
500 108th Ave. NE
Bellevue, WA
EMail: alh-ietf@tndh.net
Fred L. Templin
Nokia
313 Fairchild Drive
Mountain View, CA 94043
Phone: +1 650 625 2331
EMail: ftemplin@iprg.nokia.com
Hain & Templin Expires February 11, 2004 [Page 11]
Internet-Draft Local Addressing Requirements August 2003
Appendix A. Filtering Considerations
The only difference between an 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.
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.
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. As such, one common use instance of a site border will be
the boundary between the IGP and EGP. Use of limited range 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 addresses available.
Appendix B. Routing Considerations
The term 'site' is not rigorously defined by intent (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
may be located within a single geographic location, such as an
office, an office complex, or a campus. 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 at least part of the site boundary.
A limited range 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(s) using them vs. policy at an arbitrary
remote network.
Hain & Templin Expires February 11, 2004 [Page 12]
Internet-Draft Local Addressing Requirements August 2003
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 range 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 range, must originate and stay within that range, as
there is no way to deliver packets from outside the defined range.
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 requires
that any process that intends to provide C with topology information
understands the topology to recognize the local and global range
differences to provide useful information.
Hain & Templin Expires February 11, 2004 [Page 13]
Internet-Draft Local Addressing Requirements August 2003
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 ranges 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 [HAIN]. 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.
Applications that insist on passing topology information outside the
domain of applicability will fail to operate correctly in this
environment.
Appendix C. Multiple Addressing Considerations
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 ---- -
Hain & Templin Expires February 11, 2004 [Page 14]
Internet-Draft Local Addressing Requirements August 2003
This configuration is not typical in IPv4 networks, because
implementing multiple addresses per interface is operationally
challenging, making it 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 issues raised by the limited routing range
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 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).
Appendix D. Potential Applications of Limited Range Address Space
A well-known prefix that 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.
Hain & Templin Expires February 11, 2004 [Page 15]
Internet-Draft Local Addressing Requirements August 2003
For example, 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. 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 limited range address 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 limited range 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
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 limited range address 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
Hain & Templin Expires February 11, 2004 [Page 16]
Internet-Draft Local Addressing Requirements August 2003
by name in the internal range, and all nodes that should be accessed
from the outside are accessible by name in the global range.
Applications that are expected to work across the border will have
global addresses to use. Multi-party apps that use name-string
referrals will work across the border, but those that use limited
range literals will fail by design (note: use of limited range
addresses == expected to fail across border). Use of filtered global
addresses makes it impossible for the application to know why it
failed to connect.
Appendix E. Change Log
Changes since draft-00:
o Changed title, and removed linkage of requirments and the
particular solution alternative referred to as "limited range
addressing" in the previous draft. Thanks to Eliot Lear and
Michael Thomas for suggesting the change.
o Added real life example scenario from Andrew White
Hain & Templin Expires February 11, 2004 [Page 17]
Internet-Draft Local Addressing Requirements August 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Hain & Templin Expires February 11, 2004 [Page 18]
Internet-Draft Local Addressing Requirements August 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hain & Templin Expires February 11, 2004 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 09:54:02 |