IPv6 Working Group T. Hain
Internet-Draft Cisco Systems, Inc.
Expires: June 7, 2004 F. Templin
Nokia
December 8, 2003
Goals for Organizational-Scope Communications
draft-hain-templin-ipv6-localcomm-04.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 June 7, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The IPv6 addressing architecture specifies formats for unicast
addresses, but provides no operational guidelines for their use.
There is a clear need for IPv6 to support organizational-scope
communications whether members of the organization are located in the
same site or different sites.
Aspects of certain types of sites introduce challenges for supporting
organizational-scope communications. Of special interest are nomadic
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
Hain & Templin Expires June 7, 2004 [Page 1]
Internet-Draft Organizational-Scope Communications December 2003
with other sites, etc. This memo will discuss scenarios and goals for
IPv6 support organizational-scope communications.
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 Ad-hoc Networks (MANETs) . . . . . . . . . . . . . . 4
3.6 Asset Protection in Enterprise Networks . . . . . . . . . . 5
3.7 Home Networks . . . . . . . . . . . . . . . . . . . . . . . 6
3.8 Multi-homed Sites . . . . . . . . . . . . . . . . . . . . . 6
4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Easy to Acquire Addresses . . . . . . . . . . . . . . . . . 7
4.2 Stable . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Multiple Link Support . . . . . . . . . . . . . . . . . . . 7
4.4 Prefix Filtering and Hints to Applications . . . . . . . . . 7
4.5 Globally Unique . . . . . . . . . . . . . . . . . . . . . . 8
4.6 Usable in the Absence of a Provider . . . . . . . . . . . . 8
4.7 Applicable in Managed/Unmanaged Environments . . . . . . . . 9
4.8 Compatible with Name Resolutiuon . . . . . . . . . . . . . . 9
4.9 Compatible with VPN . . . . . . . . . . . . . . . . . . . . 9
4.10 Multiple Addressing . . . . . . . . . . . . . . . . . . . . 9
5. Perceived Advantages of Well-Known Prefix Solutions . . . . 9
6. Appeal for Alternative Proposals . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . 11
Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11
A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . 14
Hain & Templin Expires June 7, 2004 [Page 2]
Internet-Draft Organizational-Scope Communications December 2003
1. Introduction
The IPv6 addressing architecture [RFC3513] specifies unicast address
formats. Global unicast addresses are understood to have unlimited
scope and may be used as the source and destination addresses in
packets that originate from any point on the connected global IPv6
Internet. Other unicast addresses are intended for use within more
limited scope, or scopes.
There is a clear need for IPv6 to support organizational-scope
communications. An "organization" may be an association or society
(e.g., an individual's Yahoo!/AOL "buddy lists", the Audubon Society,
etc.), or it may be an administrative or functional structure (e.g.,
one's company of employment, the International Red Cross, etc). But,
communications between members of an organization should be supported
whether the individuals are located in the same site or different
sites.
Of special interest for study are organizational-scope communications
for nomadic 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. since these represent the most radical
departure from the traditional Internet architecture. Thus, this memo
will discuss goals for IPv6 support of organizational-scope
communications in the context of real-world deployment scenarios for
such sites.
2. Terminology
organization:
from Mirriam-Webster, a) Association, Society (e.g. charitable
organizations) b) an administrative and functional structure
(e.g., a business or a political party); also, the personnel of
such a structure.
organizational-scope communications:
communications that are permitted only between members of an
organization
site:
the same as defined in [RFC3582]: an entity autonomously operating
a network using IP and, in particular, determining the addressing
plan and routing policy for that network. This definition is
intended to be equivalent to "enterprise" as defined in [RFC1918].
Hain & Templin Expires June 7, 2004 [Page 3]
Internet-Draft Organizational-Scope Communications December 2003
3. Scenarios
The following example scenarios touch on anticipated use cases for
organizational-scope communications using IPv6:
3.1 Border Filtering
Network managers limit specific applications to organization-scope
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. 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 often provide a vehicle for limited experimentation
with new Internetworking technologies prior to widescale deployment,
but they may need to connect to the Internet to facilitate the
experiment. Such experiments may entail large, elaborate networks
with a mix of public and private address space, but the use of random
unallocated space runs the risk of collision with legitimate
addresses.
3.4 Static Address Configuration
Applications that configure static IP addresses in ACLs or
configurations are susceptible to operational problems due to
renumbering. Examples include license servers that use IP addresses,
firewalls, web access mechanisms to allow access to only certain
subnets, etc. Stable addressing for organizational-scope
communications is needed to satisfy such scenarios.
3.5 Mobile Ad-hoc Networks (MANETs)
Numerous aspects of MANETs provide challenges for
organizational-scope communications. The following scenarios provide
some specific examples:
Hain & Templin Expires June 7, 2004 [Page 4]
Internet-Draft Organizational-Scope Communications December 2003
3.5.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 organizational-scope
communications between nodes even during rapidly-changing MANET
dynamics.
3.5.2 Groups of Nodes that Travel Together
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. Continuous support of organizational-scope
communications for such mobile ad-hoc networks is needed.
3.5.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).
Research ships at sea intermittently connect via INMARSAT, or when in
port, the shipboard network is connected to shore via Ethernet. It is
of utmost importance 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.
3.6 Asset Protection in Enterprise Networks
Enterprise networks that protect private corporate assets (e.g.,
printers, faxes, robotics, sensors, etc.) require addresses that
remain stable even when Virtual Private Network (VPN) connections
from outside 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.
Hain & Templin Expires June 7, 2004 [Page 5]
Internet-Draft Organizational-Scope Communications December 2003
3.7 Home Networks
Home networks with intermittent access to a service provider should
support organizational-scope communications even when the service is
unavailable. The home network should also be able to protect private
assets from exposure to the global Internet and should allow
continuous operation when VPN connections to the office or other
remote sites are used.
Home network users should be able to join "buddy lists" and
communicate with other members of those "organizations" even if all
members reside in different sites.
3.8 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 should be able to support organizational-scoped
communications as well as communications our 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
Such chains of events should not disrupt the local communications
within sites A and B.
4. Goals
There is a clear need for IPv6 to support organizational-scoped
communications. One obvious solution alternative is an easy-to-get,
stable, Provier Independent (PI) space. The following sections
present goals that should be met by any solution proposal. Proposals
Hain & Templin Expires June 7, 2004 [Page 6]
Internet-Draft Organizational-Scope Communications December 2003
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 Addresses
Addresses for organizational-scoped communications should be made
available that require 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 organizational-scoped communications should
use addresses that support session stability (i.e., connection
survivability) during intermittent connectivity, 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 use-cases (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.)
4.3 Multiple Link Support
Organizational-scope communications should be supported 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
Well-known address prefixes 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 whether/how filtering, privacy, etc will be
supported.
Hain & Templin Expires June 7, 2004 [Page 7]
Internet-Draft Organizational-Scope Communications December 2003
4.5 Globally Unique
Addresses used for organizational-scope communications should be
globally unique such that mergers will not result in collisions. When
no central registry is used, global uniqueness is based on the
statistical properties of inertial address allocations. Therefore,
proposals should specify a suitable means for organizations to
perform random prefix generation.
Proposals should also specify a suitable means for organizations 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 (or, 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
desired. Proposals should therefore provide statistical analysis of
the uniqueness properties of the addressing scheme.
4.6 Usable in the Absence of a Provider
Some organizations will 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 organizational-scope communications. In the case
of moving to new provider points of attachment, frequent renumbering
events may occur but, again, organizational-scope 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.
Hain & Templin Expires June 7, 2004 [Page 8]
Internet-Draft Organizational-Scope Communications December 2003
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.
Solutions for Organizational-scope communications should be supported
for any type of site a member may belong to - be it managed or
unmanaged.
4.8 Compatible with Name Resolutiuon
Organizational-scope communications should be compatible with name
resolution systems. Examples include DNS, multicast name resolution,
static configuration, etc.
4.9 Compatible with VPN
VPN connections between multiple sites, e.g., to form
geographically-extended organizations should be supported. Prefix
delegations in effect at each constituent site should remain valid
when connected via VPN.
4.10 Multiple Addressing
Proposals should support multiple addressing and allow nodes to
implement individual security policies about global visibility. This
moves the security policy decision from the edge to the originating
device, which allows the 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 Well-Known Prefix Solutions
Well-known prefixes allow filtering, and filtering creates addressing
boundaries no matter where the bits come from. The point is that some
addresses are only valid within organizational scopes.
Address selection policy tables might need modifications to enable
the selection of addresses of different scope. Given such
modifications, address selection rules will prefer the smallest range
so organizational-scope communications are forced to stay internal by
Hain & Templin Expires June 7, 2004 [Page 9]
Internet-Draft Organizational-Scope Communications December 2003
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-known prefix 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 prefix 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 well-known
prefixes should be better understood.
6. Appeal for Alternative Proposals
A well-known prefix space for organizational-scope communications
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 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 prefix to filter enhances
the deployment of that tool.
Access control is one aspect of what well-known prefixes provide. 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
Hain & Templin Expires June 7, 2004 [Page 10]
Internet-Draft Organizational-Scope Communications December 2003
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, Keith Moore, 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".
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and
E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
[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
Hain & Templin Expires June 7, 2004 [Page 11]
Internet-Draft Organizational-Scope Communications December 2003
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-03:
o Changed document title
o Added M-W definition for "organization"
o Incorporated comments from Keith Moore, Pekka Savola
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
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.
Hain & Templin Expires June 7, 2004 [Page 12]
Internet-Draft Organizational-Scope Communications December 2003
o Added real life example scenario from Andrew White
Hain & Templin Expires June 7, 2004 [Page 13]
Internet-Draft Organizational-Scope Communications December 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 June 7, 2004 [Page 14]
Internet-Draft Organizational-Scope Communications December 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 June 7, 2004 [Page 15]