One document matched: draft-hain-templin-ipv6-localcomm-03.txt
Differences from draft-hain-templin-ipv6-localcomm-02.txt
IPv6 Working Group T. Hain
Internet-Draft Cisco Systems, Inc.
Expires: April 14, 2004 F. Templin
Nokia
October 15, 2003
Goals for Local Communications within Sites
draft-hain-templin-ipv6-localcomm-03.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 April 14, 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
for their use. There is a clear need for IPv6 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, etc. This memo will discuss scenarios and goals for IPv6
support of local communications within sites.
Hain & Templin Expires April 14, 2004 [Page 1]
Internet-Draft Local Communication Goals October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Border Filtering . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Maintaining Confidentiality of the Address Space . . . . . . 4
3.3 Test Networks . . . . . . . . . . . . . . . . . . . . . . . 4
3.4 Static Address Configuration . . . . . . . . . . . . . . . . 4
3.5 Mobile Router with Personal Area Network . . . . . . . . . . 4
3.6 Mobile Ad-hoc Networks (MANETs) . . . . . . . . . . . . . . 5
3.7 Asset Protection in Enterprise Networks . . . . . . . . . . 6
3.8 Home Networks . . . . . . . . . . . . . . . . . . . . . . . 6
3.9 Multi-homed Sites . . . . . . . . . . . . . . . . . . . . . 6
4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Easy to Acquire . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Stable . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Multiple Link Support . . . . . . . . . . . . . . . . . . . 8
4.4 Prefix Filtering and Hints to Applications . . . . . . . . . 8
4.5 Globally Unique . . . . . . . . . . . . . . . . . . . . . . 8
4.6 Usable in the Absence of a Provider . . . . . . . . . . . . 9
4.7 Applicable in Managed/Unmanaged Environments . . . . . . . . 9
4.8 Compatible with Site Naming System . . . . . . . . . . . . . 9
4.9 Compatible with VPN . . . . . . . . . . . . . . . . . . . . 9
4.10 Multiple Addressing . . . . . . . . . . . . . . . . . . . . 9
5. Perceived Advantages of Limited Range Addressing Solutions . 10
6. Appeal for Alternative Proposals . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
Normative References . . . . . . . . . . . . . . . . . . . . 11
Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . 14
Hain & Templin Expires April 14, 2004 [Page 2]
Internet-Draft Local Communication Goals October 2003
1. Introduction
The IPv6 addressing architecture [RFC3513] specifies global and
local-use unicast addresses. 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 for real-world deployment
scenarios.
There is a clear need for IPv6 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, etc. This
memo will discuss goals for IPv6 support of 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 [RFC3582].
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.
limited range:
a range bounded by, e.g., routing policies, filters, etc.
PI:
Provider Independent
PA:
Provider Aggregated
VPN:
Virtual Private Network
Hain & Templin Expires April 14, 2004 [Page 3]
Internet-Draft Local Communication Goals October 2003
3. Scenarios
The following example scenarios touch on anticipated use cases for
local communications within sites using IPv6:
3.1 Border Filtering
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.
3.2 Maintaining Confidentiality of the Address Space
Some organizations may wish 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.
3.3 Test Networks
Test networks are frequently 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 if the test network is ever connected to the Internet.
3.4 Static Address Configuration
Applications that configure static IP addresses in ACLs or
configurations are susceptible to operational problems due to site
renumbering. Examples include license servers that use IP addresses,
firewalls within the site, web site access mechanisms to allow access
to only certain subnets, etc. Stable addressing for local
communications within sites is needed to satisfy such scenarios.
3.5 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 should
be supported even when no connection to the global Internet is
available. As mobile users travel about, multiple PANs may come
Hain & Templin Expires April 14, 2004 [Page 4]
Internet-Draft Local Communication Goals October 2003
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.
3.6 Mobile Ad-hoc Networks (MANETs)
Numerous aspects of MANETs provide challenges for addressing schemes
that support local communications. The following scenarios provide
some specific examples:
3.6.1 Nomadic Nodes that form Temporal MANETs
Nomadic nodes with no pre-defined group affiliation are in actuality
singleton sites that may from time to time merge with other such
"sites" as they move about to form MANETs. Such MANETs may exist only
temporarily in space/time, but should allow local communications
between nodes even during rapidly-changing MANET dynamics. Therefore
each such nomadic node should have a pre-configured address that can
be injected into the intra-MANET routing protocol during the duration
of its visit to any such temporal MANET.
3.6.2 Groups of Nodes that Travel Together
As with the mobile PAN in Section 3.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.
3.6.3 Vehicular Networks
Vehicular networks may connect elements in an automobile to provide
sensory and situational awareness data to the driver. Periodic
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
Hain & Templin Expires April 14, 2004 [Page 5]
Internet-Draft Local Communication Goals October 2003
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.
3.7 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 should not end up in
the global routing system, even by accident.
3.8 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.
3.9 Multi-homed Sites
An example chain of events that may arise in Home Networks and other
scenarios is:
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
Hain & Templin Expires April 14, 2004 [Page 6]
Internet-Draft Local Communication Goals October 2003
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
Such chains of events should not disrupt local communications within
sites A and B.
4. Goals
There is a clear need for IPv6 to support local communications within
sites. One obvious solution alternative is an easy-to-get, stable, PI
space for use within a limited range as this is consistent with
current practices familiar to IPv4 network managers. The following
sections present goals that should be met by any solution proposal.
Proposals should be brought forward in a timely fashion so that their
merits can be evaluated with respect to these goals.
4.1 Easy to Acquire
Some portion of the address space should be made available that
requires no public registration, payment, customer/provider
relationship, or approval to support scenarios for which strict
global uniqueness and conflict resolution are not necessary. These
addresses should be architecturally supported and
end-user-controlled.
(Other scenarios may have more stringent requirements for global
uniqueness and conflict resolution and may be willing to pay a
reasonable fee to a registration authority for this assurance.)
4.2 Stable
Applications that enable local communications should use addresses
that support session stability (i.e., connection survivability)
during intermittent connectivity, site mergers, change to a new
provider, etc. In particular, session stability should not be
affected by renumbering events [BAKER].
It must be considered that future local communications scenarios
(e.g., a home security monitoring system with 24x7 coverage) will
require "always-on" operation such that the desired duration of
stability can be regarded as infinite. The infinite stability goal
may be less critical for applications/transports that can accommodate
a change of IP address during the session lifetime, however.
Hain & Templin Expires April 14, 2004 [Page 7]
Internet-Draft Local Communication Goals October 2003
4.3 Multiple Link Support
Addresses 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.
4.4 Prefix Filtering and Hints to Applications
Addressing scheme proposals that use a well-known prefix provide
applications that choose to check with a hint that a filtering policy
has been applied somewhere in the network, though it does not by
itself indicate where the boundaries are. Proposals that carve
prefixes for filtering from an arbitrary global prefix may not
provide hints to applications, but the value of hints to applications
needs to be understood. Therefore, proposals should state clearly how
filtering, privacy, etc will be supported.
4.5 Globally Unique
Addresses used by sites should be globally unique such that site
mergers will not result in collisions. When no central registry is
used, global uniqueness is based on the statistical properties of the
inertial address allocations performed by the site. Therefore,
proposals should specify a suitable means for sites to perform random
prefix generation.
Proposals should also specify a suitable means for sites to procure
certified prefixes through, e.g., certification through a central
registry, distributed database, etc, when more stringent global
uniqueness, conflict resolution, etc. are required.
Sufficient global uniqueness is needed to support, e.g.:
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
Hain & Templin Expires April 14, 2004 [Page 8]
Internet-Draft Local Communication Goals October 2003
extremely low probability of collisions resulting in conflict is
desired. Proposals should therefore provide statistical analysis of
the uniqueness properties of the addressing scheme.
4.6 Usable in the Absence of a Provider
Active sites need addresses that can be used when there is no active
link to a provider. In the case of intermittently-connected sites,
provider access may be unavailable for long periods but this should
not disrupt local communications within the site. In the case of
sites moving to new provider points of attachment, frequent
renumbering events may occur but, again, local communications should
not be disrupted.
Renumbering allows for overlapping of the old and new prefixes for a
period of time such that applications can continue to use the old
prefixes for internal sessions until the pre-planned, hard cutover.
This may or may not satisfy the goal of stability in all scenarios.
4.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.
Addressing scheme proposals should provide general applicability in
any environment - be it managed or unmanaged.
4.8 Compatible with Site Naming System
Addresses for local communications within sites should 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 within the range of operation of the
site's naming system.
4.9 Compatible with VPN
Proposed addressing schemes should support VPN connections between
multiple sites, e.g., to form geographically-extended organizations.
Prefix delegations in effect at each constituent site should remain
valid when connected via VPN.
4.10 Multiple Addressing
Proposals that support concurrent use of limited & global range
addresses allow nodes in the site to implement individual security
policies about global visibility. This moves the security policy
decision from the edge to the originating device, which allows the
Hain & Templin Expires April 14, 2004 [Page 9]
Internet-Draft Local Communication Goals October 2003
application which has enough information decide the appropriate
action. In the case of devices that move between subnets, it also
mitigates the need for continuous changes of access controls at the
edge.
Proposals that do not support multiple addressing should state
clearly how security policies can be enforced. In particular, they
should clearly state how the originating devices can implement
security policies without the need for edge intervention when only a
single address is available.
5. Perceived Advantages of Limited Range Addressing Solutions
Limited range addressing solutions allow filtering, and 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
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 policy
tables might need modifications to enable the selection of limited
range address space over global addresses. Given such modifications,
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.
Other proposals (e.g., those that advertise "special" prefixes via
Router Advertisements) may provide a workable alternative.
Operational issues between using such approaches and using a limited
range addressing scheme should be better understood.
6. Appeal for Alternative Proposals
A limited range addressing scheme would seem a logical choice to
satisfy the requirements 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
Hain & Templin Expires April 14, 2004 [Page 10]
Internet-Draft Local Communication Goals October 2003
timely fashion through full disclosure to the public domain so that
their merits can be evaluated. Such proposals should state clearly
how they address the goals outlined in this document and should
include mathematical formulas analyzing the likelyhood of duplicate
address assignment, analysis of effects on address selection,
filtering/privacy considerations, etc.
7. IANA Considerations
This document does not introduce any IANA requirements.
8. 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.
9. Acknowledgements
The authors acknowledge the contributions of numerous posts on the
ipng mailing list [IPNG] that led to a better understanding of the
issues. The following individuals are noted for their contributions:
Brian Carpenter, Ralph Droms, Brian Haberman, Tim Hartrick, Dan
Lanciani, Eliot Lear, Chirayu Patel, Michel Py, Pekka Savola, Daniel
Senie, Stephen Sprunk, Michael Thomas, and Andrew White.
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.
[IPNG] "IPng mailing list archive: ftp://playground.sun.com/pub/
ipng/mail-archive".
Hain & Templin Expires April 14, 2004 [Page 11]
Internet-Draft Local Communication Goals October 2003
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address",
RFC 3177, September 2001.
[RFC3582] Abley, J., Black, B. and V. Gill, "Goals for IPv6
Site-Multihoming Architectures", RFC 3582, August 2003.
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
Appendix A. Change Log
Changes since draft-02:
o Changed document ID; title
o Reversed order of appearance of scenarios/goals sections
o Incorporated comments from Ralph Droms; Brian Haberman
Changes since draft-01:
o Changed document ID; title
o Changed "Requirements" "to "Goals" in several places
o Incorporated comments from Chirayu Patel, Pekka Savola
o Expanded "scenarios" section with several new subsections,
including nomadic nodes in MANETs.
o Removed appendices
Hain & Templin Expires April 14, 2004 [Page 12]
Internet-Draft Local Communication Goals October 2003
o Updated reference for RFC3582.
Changes since draft-00:
o Changed title, and removed linkage of requirements 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 April 14, 2004 [Page 13]
Internet-Draft Local Communication Goals October 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 April 14, 2004 [Page 14]
Internet-Draft Local Communication Goals October 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 April 14, 2004 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 15:23:33 |