One document matched: draft-hinden-ipv6-sl-moderate-01.txt
Differences from draft-hinden-ipv6-sl-moderate-00.txt
INTERNET-DRAFT R. Hinden, Nokia
February 28, 2003
Moderate Use Case for IPv6 Site-Local Addresses
<draft-hinden-ipv6-sl-moderate-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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
This internet draft expires on August 28, 2003.
Abstract
This internet draft describes the moderate use case for IPv6 Site-
Local Addresses.
1.0 Introduction
This internet draft describes the Moderate use case for IPv6 Site-
Local addresses. Site-Local addresses are defined in the IPv6
Addressing Architecture [ADDARCH]. The IPv6 working group has been
discussing what is the appropriate use scenario for IPv6 Site-Local
addresses. The draft describes a possible scenario.
The Moderate use case for IPv6 Site-Local addresses allows Site-Local
addresses to be used inside of a site for services and applications
that prefer to use Site-Local addresses for communication inside of
draft-hinden-ipv6-sl-moderate-01.txt [Page 1]
INTERNET-DRAFT Moderate Usage of IPv6 Site-Local Addresses January 2003
the site. Sites may use site-local addresses concurrently with
global routable addresses or may use them exclusively if they are
disconnected from the Internet and do not have any IPv6 global
routable addresses.
The moderate use scenario limits site-local usage to cases where
site-local addresses are purposely enabled and configured by an
administrator. Site-local addresses will not be used if the source
and destination hosts could have used global addresses instead.
The moderate use scenario document includes approaches for keeping
site-local addresses and DNS names inside of a site, site border
router issues, site-local uniqueness issues, and changes and/or
extensions to existing IPv6 documents.
2.0 Acknowledgments
The author would like to thank Andrew White, Bob Fink, Hiroki
Ishibashi, Juha Wiljakka Pekka Savola, Rich Draves, Rob Austein, and
Tony Hain for their comments and suggestions on this document.
3.0 Site Definition
The document doesn't attempt to define a site in exact terms. A site
is a set of associated subnets. Sites do not overlap each other.
Sites typically range from home or small office to a campus of a
large organization. In most cases the site boundary is where there
is an administrative or geographic boundary such as where the
connection to an ISP is or a campus in a specific geographic
location. In many IPv6 transition scenarios an IPv6 over IPv4 tunnel
will be created at the edge of a site. In routing protocol terms
this is where typically there is an IGP/EGP boundary or between areas
in an IGP like OSPF.
4.0 Site-Local Moderate Use Scenario
The moderate use scenario for IPv6 site-local addresses allows for
the use of site-local addresses concurrently with global IPv6
addresses. The use of site-local addresses is limited to cases where
an administrator has configured hosts and services to use them. They
will not be used if the source and destination hosts could have used
global addresses instead.
The motivation for this use case is to restrict the use of site-local
addresses to communication inside of the site and insure that they
draft-hinden-ipv6-sl-moderate-01.txt [Page 2]
INTERNET-DRAFT Moderate Usage of IPv6 Site-Local Addresses January 2003
are very unlikely to be used for any site to site communication.
Using limited scope addresses for site to site communication, while
possible (i.e., via tunneling or VPN technologies), is problematic
and makes it hard to debug problems. Overall it is simpler to use
global addresses.
4.1 Site-Local Address Assignment
IPv6 site-local addresses, like global scope unicast addresses, are
only assigned to nodes if their use has been enabled (via IPv6
address autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually) and
configured in the DNS. They are not created automatically the way
that IPv6 link-local addresses are and will not appear or be used
unless they are purposely configured.
In order for hosts to autoconfigure site-local addresses routers have
to be configured to advertise site-local /64 prefixes in router
advertisements. Likewise, a DHCPv6 server must have been configured
to assign them. In order for a node to learn the site-local address
of another node, the Site-local address must have been installed in
the DNS. For these reasons, it is straight forward to control their
usage in a site.
To limit the use of site-local addresses the following guidelines
apply:
- Nodes that are to only be reachable inside of a site, the local
DNS should be configured to only include the site-local
addresses of these nodes. Nodes with only site-local addresses
must not be installed in the global DNS.
- Nodes that are to be limited to only communicate with other
nodes in the site should be set to only autoconfigure site-local
addresses via [ADDAUTO] or to only receive site-local addresses
via [DHCP6]. Note: For the case where both global and site-
local prefixes are being advertised on a subnet, this will
require a switch in the devices to only autoconfigure site-local
addresses. See section 5.1 for more details on this.
- Nodes that are to be reachable from inside of the site and
outside of the site, the DNS should be configured to include the
global addresses of these nodes. The local DNS may be
configured to also include the site-local addresses of these
nodes.
- Nodes that can communicate with other nodes inside of the site
and outside of the site, should autoconfigure global addresses
draft-hinden-ipv6-sl-moderate-01.txt [Page 3]
INTERNET-DRAFT Moderate Usage of IPv6 Site-Local Addresses January 2003
via [ADDAUTO] or receive global address via [DHCP6]. They may
also obtain site-local addresses via the same mechanisms.
4.2 Site Local Address Selection
In order for nodes to limit their use of site-locals to specific
configured cases the following address selection rules are needed:
- If the destination only has a site-local address, the source
should prefer to use a site-local source address.
- If the destination only has a global address, the source should
prefer to use a global source address.
- If a source has a site-local and global addresses, and the
destination has site-local and global addresses, the source
should use the global address as the source address and use the
global address of the destination as the destination address.
Note, this is a change to IPv6 Default Address Selection. See
section 5.2 for details of these changes.
4.3 Site Border Router Filtering
It is important to keep any packets with site-local source or
destination addresses from leaking outside of the site and to keep
any site-local prefixes from being advertised outside of their site.
There are two cases to implement this filtering requirements: Site-
Border routers and firewalls.
4.3.1 Site Border Routers
Site border routers must install a black hole route for the Site-
Local prefix FEC0::/10. This will insure that packets with Site-
Local destination addresses will not be forwarded outside of the site
via a default route.
Site border routers must not forward any packets with site-local
source or destination addresses outside of the site. This requires a
filter to be installed in the site-border router.
A simple approach to creating a site border router is to allow an
draft-hinden-ipv6-sl-moderate-01.txt [Page 4]
INTERNET-DRAFT Moderate Usage of IPv6 Site-Local Addresses January 2003
interface to be configured in a "no site" site. If an interface is
in the "no site" site, then the router will not forward any packets
with site-local source and/or destination addresses to or from this
interface.
If BGP is being used at the site border with an ISP, filters must be
installed in the BGP configuration to keep any site-local prefixes
from being advertised outside of the site or for site-local prefixes
to be learned from another site.
4.3.2 Firewalls
Firewalls are commonly used in IPv4 to create site boundaries and are
sometimes used to limit the scope of IPv4 addresses. This includes
filtering packets with private IPv4 source or destination addresses.
If IPv6 firewalls are used to connect the site to other sites
(including ISPs), then the firewall must install filters to drop
packets with site-local source and/or destination addresses to keep
them from entering or exiting the site.
4.4 Routing
Site-local addresses should be routed inside the site just like any
other unicast addresses. They can be carried in any IPv6 routing
protocol without any change. It is expected that an instance of an
IGP routing protocols will be run inside of a single site.
Any routing protocol that is used between sites is required to filter
out any incoming or outgoing site-local routes. For example, if BGP
is being used at the site border with an ISP, filters must be
installed in the BGP configuration to keep any site-local prefixes
from being advertised outside of the site or for site-local prefixes
to be learned from another site.
4.5 DNS Naming Issues
Site-Local addresses must not be installed in the global DNS. They
may be installed in a naming system local to the site or kept
separate from the global DNS using techniques such as "two-faced"
DNS. Approaches for doing this are common in the IPv4 Internet
today.
draft-hinden-ipv6-sl-moderate-01.txt [Page 5]
INTERNET-DRAFT Moderate Usage of IPv6 Site-Local Addresses January 2003
4.6 Site-Local Uniqueness Issues
Site-local addresses as defined in [ADDARCH] all share a common
prefix (i.e., FEC0::/10). There is a potential for confusion if
packets containing these type of address were to escape the site.
Due to the the way that addresses are autoconfigured in IPv6 with
IPv6 IPv6 autoconfiguration [ADDAUTO] is very unlikely that two
complete 128-bit site-local addresses would ever conflict with each
other. It is unlikely to be a problem in practice. This is also
true if temporary address were created using the privacy extensions
defined in [PRIV]. IPv6 addresses created manually or with stateful
methods such as [DHCP6] might have some potential for conflict. For
this reason it is preferable to only create IPv6 site-local addresses
with [ADDAUTO] or [PRIV].
5.0 Changes and Extensions to Existing Specifications
5.1 IPv6 Node Requirements
Nodes that are to intended to have the capability to be limited to
only communicate with other nodes inside of the site (e.g., no global
communication) should include a switch that has a site-only setting.
This could be a software configuration or a hardware toggle switch
for simple appliances.
Support for multi-sited nodes is not required. Routers that are
designed to be used at site borders should implement the "no site"
site and firewalls should support site border filtering.
5.2 Default Address Selection
TBD [Document changes to default address selection]
6.0 Security Considerations
TBD
draft-hinden-ipv6-sl-moderate-01.txt [Page 6]
INTERNET-DRAFT Moderate Usage of IPv6 Site-Local Addresses January 2003
REFERENCES
[ADDARCH] Hinden, R., S. Deering, S., "IP Version 6 Addressing
Architecture", Internet Draft, <draft-ietf-ipngwg-addr-
arch-v3-11.txt>, October 2002.
[ADDAUTO] Thomson, S., T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462, December 1998.
[DEFAULT] Draves, R., "Default Address Selection for IPv6",
Internet Draft, <draft-ietf-ipv6-default-addr-
select-09.txt, August 2002.
[DHCP6] Droms, R., et. al., "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", Internet Draft, <draft-ietf-dhc-
dhcpv6-28.txt>, November 2002.
[IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC2460, December 1998.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC2026, BCP00009, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, BCP14, March 1997.
[PRIV] Narten, T., R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6" RFC3041, January
2001.
AUTHOR'S ADDRESS
Robert M. Hinden
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
phone: +1 650 625-2004
email: hinden@iprg.nokia.com
draft-hinden-ipv6-sl-moderate-01.txt [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 21:19:07 |