Compare commits
1 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
c49ca02c02 |
@@ -1,899 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group R. Hinden
|
||||
Request for Comments: 4193 Nokia
|
||||
Category: Standards Track B. Haberman
|
||||
JHU-APL
|
||||
October 2005
|
||||
|
||||
|
||||
Unique Local IPv6 Unicast Addresses
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2005).
|
||||
|
||||
Abstract
|
||||
|
||||
This document defines an IPv6 unicast address format that is globally
|
||||
unique and is intended for local communications, usually inside of a
|
||||
site. These addresses are not expected to be routable on the global
|
||||
Internet.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. Acknowledgements ................................................3
|
||||
3. Local IPv6 Unicast Addresses ....................................3
|
||||
3.1. Format .....................................................3
|
||||
3.1.1. Background ..........................................4
|
||||
3.2. Global ID ..................................................4
|
||||
3.2.1. Locally Assigned Global IDs .........................5
|
||||
3.2.2. Sample Code for Pseudo-Random Global ID Algorithm ...5
|
||||
3.2.3. Analysis of the Uniqueness of Global IDs ............6
|
||||
3.3. Scope Definition ...........................................6
|
||||
4. Operational Guidelines ..........................................7
|
||||
4.1. Routing ....................................................7
|
||||
4.2. Renumbering and Site Merging ...............................7
|
||||
4.3. Site Border Router and Firewall Packet Filtering ...........8
|
||||
4.4. DNS Issues .................................................8
|
||||
4.5. Application and Higher Level Protocol Issues ...............9
|
||||
4.6. Use of Local IPv6 Addresses for Local Communication ........9
|
||||
4.7. Use of Local IPv6 Addresses with VPNs .....................10
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 1]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
5. Global Routing Considerations ..................................11
|
||||
5.1. From the Standpoint of the Internet .......................11
|
||||
5.2. From the Standpoint of a Site .............................11
|
||||
6. Advantages and Disadvantages ...................................12
|
||||
6.1. Advantages ................................................12
|
||||
6.2. Disadvantages .............................................13
|
||||
7. Security Considerations ........................................13
|
||||
8. IANA Considerations ............................................13
|
||||
9. References .....................................................13
|
||||
9.1. Normative References ......................................13
|
||||
9.2. Informative References ....................................14
|
||||
|
||||
1. Introduction
|
||||
|
||||
This document defines an IPv6 unicast address format that is globally
|
||||
unique and is intended for local communications [IPV6]. These
|
||||
addresses are called Unique Local IPv6 Unicast Addresses and are
|
||||
abbreviated in this document as Local IPv6 addresses. They are not
|
||||
expected to be routable on the global Internet. They are routable
|
||||
inside of a more limited area such as a site. They may also be
|
||||
routed between a limited set of sites.
|
||||
|
||||
Local IPv6 unicast addresses have the following characteristics:
|
||||
|
||||
- Globally unique prefix (with high probability of uniqueness).
|
||||
|
||||
- Well-known prefix to allow for easy filtering at site
|
||||
boundaries.
|
||||
|
||||
- Allow sites to be combined or privately interconnected without
|
||||
creating any address conflicts or requiring renumbering of
|
||||
interfaces that use these prefixes.
|
||||
|
||||
- Internet Service Provider independent and can be used for
|
||||
communications inside of a site without having any permanent or
|
||||
intermittent Internet connectivity.
|
||||
|
||||
- If accidentally leaked outside of a site via routing or DNS,
|
||||
there is no conflict with any other addresses.
|
||||
|
||||
- In practice, applications may treat these addresses like global
|
||||
scoped addresses.
|
||||
|
||||
This document defines the format of Local IPv6 addresses, how to
|
||||
allocate them, and usage considerations including routing, site
|
||||
border routers, DNS, application support, VPN usage, and guidelines
|
||||
for how to use for local communication inside a site.
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 2]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
2. Acknowledgements
|
||||
|
||||
The underlying idea of creating Local IPv6 addresses described in
|
||||
this document has been proposed a number of times by a variety of
|
||||
people. The authors of this document do not claim exclusive credit.
|
||||
Credit goes to Brian Carpenter, Christian Huitema, Aidan Williams,
|
||||
Andrew White, Charlie Perkins, and many others. The authors would
|
||||
also like to thank Brian Carpenter, Charlie Perkins, Harald
|
||||
Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, Alan
|
||||
Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian Huitema, Tim
|
||||
Chown, Steve Bellovin, Alex Zinin, Tony Hain, Bill Fenner, Sam
|
||||
Hartman, and Elwyn Davies for their comments and suggestions on this
|
||||
document.
|
||||
|
||||
3. Local IPv6 Unicast Addresses
|
||||
|
||||
3.1. Format
|
||||
|
||||
The Local IPv6 addresses are created using a pseudo-randomly
|
||||
allocated global ID. They have the following format:
|
||||
|
||||
| 7 bits |1| 40 bits | 16 bits | 64 bits |
|
||||
+--------+-+------------+-----------+----------------------------+
|
||||
| Prefix |L| Global ID | Subnet ID | Interface ID |
|
||||
+--------+-+------------+-----------+----------------------------+
|
||||
|
||||
Where:
|
||||
|
||||
Prefix FC00::/7 prefix to identify Local IPv6 unicast
|
||||
addresses.
|
||||
|
||||
L Set to 1 if the prefix is locally assigned.
|
||||
Set to 0 may be defined in the future. See
|
||||
Section 3.2 for additional information.
|
||||
|
||||
Global ID 40-bit global identifier used to create a
|
||||
globally unique prefix. See Section 3.2 for
|
||||
additional information.
|
||||
|
||||
Subnet ID 16-bit Subnet ID is an identifier of a subnet
|
||||
within the site.
|
||||
|
||||
Interface ID 64-bit Interface ID as defined in [ADDARCH].
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 3]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
3.1.1. Background
|
||||
|
||||
There were a range of choices available when choosing the size of the
|
||||
prefix and Global ID field length. There is a direct tradeoff
|
||||
between having a Global ID field large enough to support foreseeable
|
||||
future growth and not using too much of the IPv6 address space
|
||||
needlessly. A reasonable way of evaluating a specific field length
|
||||
is to compare it to a projected 2050 world population of 9.3 billion
|
||||
[POPUL] and the number of resulting /48 prefixes per person. A range
|
||||
of prefix choices is shown in the following table:
|
||||
|
||||
Prefix Global ID Number of Prefixes % of IPv6
|
||||
Length /48 Prefixes per Person Address Space
|
||||
|
||||
/11 37 137,438,953,472 15 0.049%
|
||||
/10 38 274,877,906,944 30 0.098%
|
||||
/9 39 549,755,813,888 59 0.195%
|
||||
/8 40 1,099,511,627,776 118 0.391%
|
||||
/7 41 2,199,023,255,552 236 0.781%
|
||||
/6 42 4,398,046,511,104 473 1.563%
|
||||
|
||||
A very high utilization ratio of these allocations can be assumed
|
||||
because the Global ID field does not require internal structure, and
|
||||
there is no reason to be able to aggregate the prefixes.
|
||||
|
||||
The authors believe that a /7 prefix resulting in a 41-bit Global ID
|
||||
space (including the L bit) is a good choice. It provides for a
|
||||
large number of assignments (i.e., 2.2 trillion) and at the same time
|
||||
uses less than .8% of the total IPv6 address space. It is unlikely
|
||||
that this space will be exhausted. If more than this were to be
|
||||
needed, then additional IPv6 address space could be allocated for
|
||||
this purpose.
|
||||
|
||||
3.2. Global ID
|
||||
|
||||
The allocation of Global IDs is pseudo-random [RANDOM]. They MUST
|
||||
NOT be assigned sequentially or with well-known numbers. This is to
|
||||
ensure that there is not any relationship between allocations and to
|
||||
help clarify that these prefixes are not intended to be routed
|
||||
globally. Specifically, these prefixes are not designed to
|
||||
aggregate.
|
||||
|
||||
This document defines a specific local method to allocate Global IDs,
|
||||
indicated by setting the L bit to 1. Another method, indicated by
|
||||
clearing the L bit, may be defined later. Apart from the allocation
|
||||
method, all Local IPv6 addresses behave and are treated identically.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 4]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
The local assignments are self-generated and do not need any central
|
||||
coordination or assignment, but have an extremely high probability of
|
||||
being unique.
|
||||
|
||||
3.2.1. Locally Assigned Global IDs
|
||||
|
||||
Locally assigned Global IDs MUST be generated with a pseudo-random
|
||||
algorithm consistent with [RANDOM]. Section 3.2.2 describes a
|
||||
suggested algorithm. It is important that all sites generating
|
||||
Global IDs use a functionally similar algorithm to ensure there is a
|
||||
high probability of uniqueness.
|
||||
|
||||
The use of a pseudo-random algorithm to generate Global IDs in the
|
||||
locally assigned prefix gives an assurance that any network numbered
|
||||
using such a prefix is highly unlikely to have that address space
|
||||
clash with any other network that has another locally assigned prefix
|
||||
allocated to it. This is a particularly useful property when
|
||||
considering a number of scenarios including networks that merge,
|
||||
overlapping VPN address space, or hosts mobile between such networks.
|
||||
|
||||
3.2.2. Sample Code for Pseudo-Random Global ID Algorithm
|
||||
|
||||
The algorithm described below is intended to be used for locally
|
||||
assigned Global IDs. In each case the resulting global ID will be
|
||||
used in the appropriate prefix as defined in Section 3.2.
|
||||
|
||||
1) Obtain the current time of day in 64-bit NTP format [NTP].
|
||||
|
||||
2) Obtain an EUI-64 identifier from the system running this
|
||||
algorithm. If an EUI-64 does not exist, one can be created from
|
||||
a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64
|
||||
cannot be obtained or created, a suitably unique identifier,
|
||||
local to the node, should be used (e.g., system serial number).
|
||||
|
||||
3) Concatenate the time of day with the system-specific identifier
|
||||
in order to create a key.
|
||||
|
||||
4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
|
||||
the resulting value is 160 bits.
|
||||
|
||||
5) Use the least significant 40 bits as the Global ID.
|
||||
|
||||
6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global
|
||||
ID to create a Local IPv6 address prefix.
|
||||
|
||||
This algorithm will result in a Global ID that is reasonably unique
|
||||
and can be used to create a locally assigned Local IPv6 address
|
||||
prefix.
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 5]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
3.2.3. Analysis of the Uniqueness of Global IDs
|
||||
|
||||
The selection of a pseudo random Global ID is similar to the
|
||||
selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of
|
||||
[RTP]. This analysis is adapted from that document.
|
||||
|
||||
Since Global IDs are chosen randomly (and independently), it is
|
||||
possible that separate networks have chosen the same Global ID. For
|
||||
any given network, with one or more random Global IDs, that has
|
||||
inter-connections to other such networks, having a total of N such
|
||||
IDs, the probability that two or more of these IDs will collide can
|
||||
be approximated using the formula:
|
||||
|
||||
P = 1 - exp(-N**2 / 2**(L+1))
|
||||
|
||||
where P is the probability of collision, N is the number of
|
||||
interconnected Global IDs, and L is the length of the Global ID.
|
||||
|
||||
The following table shows the probability of a collision for a range
|
||||
of connections using a 40-bit Global ID field.
|
||||
|
||||
Connections Probability of Collision
|
||||
|
||||
2 1.81*10^-12
|
||||
10 4.54*10^-11
|
||||
100 4.54*10^-09
|
||||
1000 4.54*10^-07
|
||||
10000 4.54*10^-05
|
||||
|
||||
Based on this analysis, the uniqueness of locally generated Global
|
||||
IDs is adequate for sites planning a small to moderate amount of
|
||||
inter-site communication using locally generated Global IDs.
|
||||
|
||||
3.3. Scope Definition
|
||||
|
||||
By default, the scope of these addresses is global. That is, they
|
||||
are not limited by ambiguity like the site-local addresses defined in
|
||||
[ADDARCH]. Rather, these prefixes are globally unique, and as such,
|
||||
their applicability is greater than site-local addresses. Their
|
||||
limitation is in the routability of the prefixes, which is limited to
|
||||
a site and any explicit routing agreements with other sites to
|
||||
propagate them (also see Section 4.1). Also, unlike site-locals, a
|
||||
site may have more than one of these prefixes and use them at the
|
||||
same time.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 6]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
4. Operational Guidelines
|
||||
|
||||
The guidelines in this section do not require any change to the
|
||||
normal routing and forwarding functionality in an IPv6 host or
|
||||
router. These are configuration and operational usage guidelines.
|
||||
|
||||
4.1. Routing
|
||||
|
||||
Local IPv6 addresses are designed to be routed inside of a site in
|
||||
the same manner as other types of unicast addresses. They can be
|
||||
carried in any IPv6 routing protocol without any change.
|
||||
|
||||
It is expected that they would share the same Subnet IDs with
|
||||
provider-based global unicast addresses, if they were being used
|
||||
concurrently [GLOBAL].
|
||||
|
||||
The default behavior of exterior routing protocol sessions between
|
||||
administrative routing regions must be to ignore receipt of and not
|
||||
advertise prefixes in the FC00::/7 block. A network operator may
|
||||
specifically configure prefixes longer than FC00::/7 for inter-site
|
||||
communication.
|
||||
|
||||
If BGP is being used at the site border with an ISP, the default BGP
|
||||
configuration must filter out any Local IPv6 address prefixes, both
|
||||
incoming and outgoing. It must be set both to keep any Local IPv6
|
||||
address prefixes from being advertised outside of the site as well as
|
||||
to keep these prefixes from being learned from another site. The
|
||||
exception to this is if there are specific /48 or longer routes
|
||||
created for one or more Local IPv6 prefixes.
|
||||
|
||||
For link-state IGPs, it is suggested that a site utilizing IPv6 local
|
||||
address prefixes be contained within one IGP domain or area. By
|
||||
containing an IPv6 local address prefix to a single link-state area
|
||||
or domain, the distribution of prefixes can be controlled.
|
||||
|
||||
4.2. Renumbering and Site Merging
|
||||
|
||||
The use of Local IPv6 addresses in a site results in making
|
||||
communication that uses these addresses independent of renumbering a
|
||||
site's provider-based global addresses.
|
||||
|
||||
When merging multiple sites, the addresses created with these
|
||||
prefixes are unlikely to need to be renumbered because all of the
|
||||
addresses have a high probability of being unique. Routes for each
|
||||
specific prefix would have to be configured to allow routing to work
|
||||
correctly between the formerly separate sites.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 7]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
4.3. Site Border Router and Firewall Packet Filtering
|
||||
|
||||
While no serious harm will be done if packets with these addresses
|
||||
are sent outside of a site via a default route, it is recommended
|
||||
that routers be configured by default to keep any packets with Local
|
||||
IPv6 addresses from leaking outside of the site and to keep any site
|
||||
prefixes from being advertised outside of their site.
|
||||
|
||||
Site border routers and firewalls should be configured to not forward
|
||||
any packets with Local IPv6 source or destination addresses outside
|
||||
of the site, unless they have been explicitly configured with routing
|
||||
information about specific /48 or longer Local IPv6 prefixes. This
|
||||
will ensure that packets with Local IPv6 destination addresses will
|
||||
not be forwarded outside of the site via a default route. The
|
||||
default behavior of these devices should be to install a "reject"
|
||||
route for these prefixes. Site border routers should respond with
|
||||
the appropriate ICMPv6 Destination Unreachable message to inform the
|
||||
source that the packet was not forwarded. [ICMPV6]. This feedback is
|
||||
important to avoid transport protocol timeouts.
|
||||
|
||||
Routers that maintain peering arrangements between Autonomous Systems
|
||||
throughout the Internet should obey the recommendations for site
|
||||
border routers, unless configured otherwise.
|
||||
|
||||
4.4. DNS Issues
|
||||
|
||||
At the present time, AAAA and PTR records for locally assigned local
|
||||
IPv6 addresses are not recommended to be installed in the global DNS.
|
||||
|
||||
For background on this recommendation, one of the concerns about
|
||||
adding AAAA and PTR records to the global DNS for locally assigned
|
||||
Local IPv6 addresses stems from the lack of complete assurance that
|
||||
the prefixes are unique. There is a small possibility that the same
|
||||
locally assigned IPv6 Local addresses will be used by two different
|
||||
organizations both claiming to be authoritative with different
|
||||
contents. In this scenario, it is likely there will be a connection
|
||||
attempt to the closest host with the corresponding locally assigned
|
||||
IPv6 Local address. This may result in connection timeouts,
|
||||
connection failures indicated by ICMP Destination Unreachable
|
||||
messages, or successful connections to the wrong host. Due to this
|
||||
concern, adding AAAA records for these addresses to the global DNS is
|
||||
thought to be unwise.
|
||||
|
||||
Reverse (address-to-name) queries for locally assigned IPv6 Local
|
||||
addresses MUST NOT be sent to name servers for the global DNS, due to
|
||||
the load that such queries would create for the authoritative name
|
||||
servers for the ip6.arpa zone. This form of query load is not
|
||||
specific to locally assigned Local IPv6 addresses; any current form
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 8]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
of local addressing creates additional load of this kind, due to
|
||||
reverse queries leaking out of the site. However, since allowing
|
||||
such queries to escape from the site serves no useful purpose, there
|
||||
is no good reason to make the existing load problems worse.
|
||||
|
||||
The recommended way to avoid sending such queries to nameservers for
|
||||
the global DNS is for recursive name server implementations to act as
|
||||
if they were authoritative for an empty d.f.ip6.arpa zone and return
|
||||
RCODE 3 for any such query. Implementations that choose this
|
||||
strategy should allow it to be overridden, but returning an RCODE 3
|
||||
response for such queries should be the default, both because this
|
||||
will reduce the query load problem and also because, if the site
|
||||
administrator has not set up the reverse tree corresponding to the
|
||||
locally assigned IPv6 Local addresses in use, returning RCODE 3 is in
|
||||
fact the correct answer.
|
||||
|
||||
4.5. Application and Higher Level Protocol Issues
|
||||
|
||||
Application and other higher level protocols can treat Local IPv6
|
||||
addresses in the same manner as other types of global unicast
|
||||
addresses. No special handling is required. This type of address
|
||||
may not be reachable, but that is no different from other types of
|
||||
IPv6 global unicast address. Applications need to be able to handle
|
||||
multiple addresses that may or may not be reachable at any point in
|
||||
time. In most cases, this complexity should be hidden in APIs.
|
||||
|
||||
From a host's perspective, the difference between Local IPv6 and
|
||||
other types of global unicast addresses shows up as different
|
||||
reachability and could be handled by default in that way. In some
|
||||
cases, it is better for nodes and applications to treat them
|
||||
differently from global unicast addresses. A starting point might be
|
||||
to give them preference over global unicast, but fall back to global
|
||||
unicast if a particular destination is found to be unreachable. Much
|
||||
of this behavior can be controlled by how they are allocated to nodes
|
||||
and put into the DNS. However, it is useful if a host can have both
|
||||
types of addresses and use them appropriately.
|
||||
|
||||
Note that the address selection mechanisms of [ADDSEL], and in
|
||||
particular the policy override mechanism replacing default address
|
||||
selection, are expected to be used on a site where Local IPv6
|
||||
addresses are configured.
|
||||
|
||||
4.6. Use of Local IPv6 Addresses for Local Communication
|
||||
|
||||
Local IPv6 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). They are
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 9]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
not created automatically in 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 Local IPv6 addresses, routers
|
||||
have to be configured to advertise Local IPv6 /64 prefixes in router
|
||||
advertisements, or a DHCPv6 server must have been configured to
|
||||
assign them. In order for a node to learn the Local IPv6 address of
|
||||
another node, the Local IPv6 address must have been installed in a
|
||||
naming system (e.g., DNS, proprietary naming system, etc.) For these
|
||||
reasons, controlling their usage in a site is straightforward.
|
||||
|
||||
To limit the use of Local IPv6 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 Local IPv6
|
||||
addresses of these nodes. Nodes with only Local IPv6 addresses
|
||||
must not be installed in the global DNS.
|
||||
|
||||
- Nodes that are to be limited to only communicate with other
|
||||
nodes in the site: These nodes should be set to only
|
||||
autoconfigure Local IPv6 addresses via [ADDAUTO] or to only
|
||||
receive Local IPv6 addresses via [DHCP6]. Note: For the case
|
||||
where both global and Local IPv6 prefixes are being advertised
|
||||
on a subnet, this will require a switch in the devices to only
|
||||
autoconfigure Local IPv6 addresses.
|
||||
|
||||
- Nodes that are to be reachable from inside of the site and from
|
||||
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 Local IPv6 addresses of these
|
||||
nodes.
|
||||
|
||||
- Nodes that can communicate with other nodes inside of the site
|
||||
and outside of the site: These nodes should autoconfigure global
|
||||
addresses via [ADDAUTO] or receive global address via [DHCP6].
|
||||
They may also obtain Local IPv6 addresses via the same
|
||||
mechanisms.
|
||||
|
||||
4.7. Use of Local IPv6 Addresses with VPNs
|
||||
|
||||
Local IPv6 addresses can be used for inter-site Virtual Private
|
||||
Networks (VPN) if appropriate routes are set up. Because the
|
||||
addresses are unique, these VPNs will work reliably and without the
|
||||
need for translation. They have the additional property that they
|
||||
will continue to work if the individual sites are renumbered or
|
||||
merged.
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 10]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
5. Global Routing Considerations
|
||||
|
||||
Section 4.1 provides operational guidelines that forbid default
|
||||
routing of local addresses between sites. Concerns were raised to
|
||||
the IPv6 working group and to the IETF as a whole that sites may
|
||||
attempt to use local addresses as globally routed provider-
|
||||
independent addresses. This section describes why using local
|
||||
addresses as globally-routed provider-independent addresses is
|
||||
unadvisable.
|
||||
|
||||
5.1. From the Standpoint of the Internet
|
||||
|
||||
There is a mismatch between the structure of IPv6 local addresses and
|
||||
the normal IPv6 wide area routing model. The /48 prefix of an IPv6
|
||||
local addresses fits nowhere in the normal hierarchy of IPv6 unicast
|
||||
addresses. Normal IPv6 unicast addresses can be routed
|
||||
hierarchically down to physical subnet (link) level and only have to
|
||||
be flat-routed on the physical subnet. IPv6 local addresses would
|
||||
have to be flat-routed even over the wide area Internet.
|
||||
|
||||
Thus, packets whose destination address is an IPv6 local address
|
||||
could be routed over the wide area only if the corresponding /48
|
||||
prefix were carried by the wide area routing protocol in use, such as
|
||||
BGP. This contravenes the operational assumption that long prefixes
|
||||
will be aggregated into many fewer short prefixes, to limit the table
|
||||
size and convergence time of the routing protocol. If a network uses
|
||||
both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these
|
||||
types of addresses will certainly not aggregate with each other,
|
||||
since they differ from the most significant bit onwards. Neither
|
||||
will IPv6 local addresses aggregate with each other, due to their
|
||||
random bit patterns. This means that there would be a very
|
||||
significant operational penalty for attempting to use IPv6 local
|
||||
address prefixes generically with currently known wide area routing
|
||||
technology.
|
||||
|
||||
5.2. From the Standpoint of a Site
|
||||
|
||||
There are a number of design factors in IPv6 local addresses that
|
||||
reduce the likelihood that IPv6 local addresses will be used as
|
||||
arbitrary global unicast addresses. These include:
|
||||
|
||||
- The default rules to filter packets and routes make it very
|
||||
difficult to use IPv6 local addresses for arbitrary use across
|
||||
the Internet. For a site to use them as general purpose unicast
|
||||
addresses, it would have to make sure that the default rules
|
||||
were not being used by all other sites and intermediate ISPs
|
||||
used for their current and future communication.
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 11]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
- They are not mathematically guaranteed to be unique and are not
|
||||
registered in public databases. Collisions, while highly
|
||||
unlikely, are possible and a collision can compromise the
|
||||
integrity of the communications. The lack of public
|
||||
registration creates operational problems.
|
||||
|
||||
- The addresses are allocated randomly. If a site had multiple
|
||||
prefixes that it wanted to be used globally, the cost of
|
||||
advertising them would be very high because they could not be
|
||||
aggregated.
|
||||
|
||||
- They have a long prefix (i.e., /48) so a single local address
|
||||
prefix doesn't provide enough address space to be used
|
||||
exclusively by the largest organizations.
|
||||
|
||||
6. Advantages and Disadvantages
|
||||
|
||||
6.1. Advantages
|
||||
|
||||
This approach has the following advantages:
|
||||
|
||||
- Provides Local IPv6 prefixes that can be used independently of
|
||||
any provider-based IPv6 unicast address allocations. This is
|
||||
useful for sites not always connected to the Internet or sites
|
||||
that wish to have a distinct prefix that can be used to localize
|
||||
traffic inside of the site.
|
||||
|
||||
- Applications can treat these addresses in an identical manner as
|
||||
any other type of global IPv6 unicast addresses.
|
||||
|
||||
- Sites can be merged without any renumbering of the Local IPv6
|
||||
addresses.
|
||||
|
||||
- Sites can change their provider-based IPv6 unicast address
|
||||
without disrupting any communication that uses Local IPv6
|
||||
addresses.
|
||||
|
||||
- Well-known prefix that allows for easy filtering at site
|
||||
boundary.
|
||||
|
||||
- Can be used for inter-site VPNs.
|
||||
|
||||
- If accidently leaked outside of a site via routing or DNS, there
|
||||
is no conflict with any other addresses.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 12]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
6.2. Disadvantages
|
||||
|
||||
This approach has the following disadvantages:
|
||||
|
||||
- Not possible to route Local IPv6 prefixes on the global Internet
|
||||
with current routing technology. Consequentially, it is
|
||||
necessary to have the default behavior of site border routers to
|
||||
filter these addresses.
|
||||
|
||||
- There is a very low probability of non-unique locally assigned
|
||||
Global IDs being generated by the algorithm in Section 3.2.3.
|
||||
This risk can be ignored for all practical purposes, but it
|
||||
leads to a theoretical risk of clashing address prefixes.
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
Local IPv6 addresses do not provide any inherent security to the
|
||||
nodes that use them. They may be used with filters at site
|
||||
boundaries to keep Local IPv6 traffic inside of the site, but this is
|
||||
no more or less secure than filtering any other type of global IPv6
|
||||
unicast addresses.
|
||||
|
||||
Local IPv6 addresses do allow for address-based security mechanisms,
|
||||
including IPsec, across end to end VPN connections.
|
||||
|
||||
8. IANA Considerations
|
||||
|
||||
The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast".
|
||||
|
||||
9. References
|
||||
|
||||
9.1. Normative References
|
||||
|
||||
[ADDARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6
|
||||
(IPv6) Addressing Architecture", RFC 3513, April 2003.
|
||||
|
||||
[FIPS] "Federal Information Processing Standards Publication",
|
||||
(FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
|
||||
|
||||
[GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
|
||||
Unicast Address Format", RFC 3587, August 2003.
|
||||
|
||||
[ICMPV6] Conta, A. and S. Deering, "Internet Control Message
|
||||
Protocol (ICMPv6) for the Internet Protocol Version 6
|
||||
(IPv6) Specification", RFC 2463, December 1998.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 13]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
||||
(IPv6) Specification", RFC 2460, December 1998.
|
||||
|
||||
[NTP] Mills, D., "Network Time Protocol (Version 3)
|
||||
Specification, Implementation and Analysis", RFC 1305,
|
||||
March 1992.
|
||||
|
||||
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
|
||||
"Randomness Requirements for Security", BCP 106, RFC 4086,
|
||||
June 2005.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
|
||||
(SHA1)", RFC 3174, September 2001.
|
||||
|
||||
9.2. Informative References
|
||||
|
||||
[ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address
|
||||
Autoconfiguration", RFC 2462, December 1998.
|
||||
|
||||
[ADDSEL] Draves, R., "Default Address Selection for Internet
|
||||
Protocol version 6 (IPv6)", RFC 3484, February 2003.
|
||||
|
||||
[DHCP6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
|
||||
M. Carney, "Dynamic Host Configuration Protocol for IPv6
|
||||
(DHCPv6)", RFC 3315, July 2003.
|
||||
|
||||
[POPUL] Population Reference Bureau, "World Population Data Sheet
|
||||
of the Population Reference Bureau 2002", August 2002.
|
||||
|
||||
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V.
|
||||
Jacobson, "RTP: A Transport Protocol for Real-Time
|
||||
Applications", STD 64, RFC 3550, July 2003.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 14]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Robert M. Hinden
|
||||
Nokia
|
||||
313 Fairchild Drive
|
||||
Mountain View, CA 94043
|
||||
USA
|
||||
|
||||
Phone: +1 650 625-2004
|
||||
EMail: bob.hinden@nokia.com
|
||||
|
||||
|
||||
Brian Haberman
|
||||
Johns Hopkins University
|
||||
Applied Physics Lab
|
||||
11100 Johns Hopkins Road
|
||||
Laurel, MD 20723
|
||||
USA
|
||||
|
||||
Phone: +1 443 778 1319
|
||||
EMail: brian@innovationslab.net
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 15]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2005).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at ietf-
|
||||
ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 16]
|
||||
|
||||
@@ -1,507 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group J. Schlyter
|
||||
Request for Comments: 4255 OpenSSH
|
||||
Category: Standards Track W. Griffin
|
||||
SPARTA
|
||||
January 2006
|
||||
|
||||
|
||||
Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes a method of verifying Secure Shell (SSH) host
|
||||
keys using Domain Name System Security (DNSSEC). The document
|
||||
defines a new DNS resource record that contains a standard SSH key
|
||||
fingerprint.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. SSH Host Key Verification .......................................2
|
||||
2.1. Method .....................................................2
|
||||
2.2. Implementation Notes .......................................2
|
||||
2.3. Fingerprint Matching .......................................3
|
||||
2.4. Authentication .............................................3
|
||||
3. The SSHFP Resource Record .......................................3
|
||||
3.1. The SSHFP RDATA Format .....................................4
|
||||
3.1.1. Algorithm Number Specification ......................4
|
||||
3.1.2. Fingerprint Type Specification ......................4
|
||||
3.1.3. Fingerprint .........................................5
|
||||
3.2. Presentation Format of the SSHFP RR ........................5
|
||||
4. Security Considerations .........................................5
|
||||
5. IANA Considerations .............................................6
|
||||
6. Normative References ............................................7
|
||||
7. Informational References ........................................7
|
||||
8. Acknowledgements ................................................8
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 1]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The SSH [6] protocol provides secure remote login and other secure
|
||||
network services over an insecure network. The security of the
|
||||
connection relies on the server authenticating itself to the client
|
||||
as well as the user authenticating itself to the server.
|
||||
|
||||
If a connection is established to a server whose public key is not
|
||||
already known to the client, a fingerprint of the key is presented to
|
||||
the user for verification. If the user decides that the fingerprint
|
||||
is correct and accepts the key, the key is saved locally and used for
|
||||
verification for all following connections. While some security-
|
||||
conscious users verify the fingerprint out-of-band before accepting
|
||||
the key, many users blindly accept the presented key.
|
||||
|
||||
The method described here can provide out-of-band verification by
|
||||
looking up a fingerprint of the server public key in the DNS [1][2]
|
||||
and using DNSSEC [5] to verify the lookup.
|
||||
|
||||
In order to distribute the fingerprint using DNS, this document
|
||||
defines a new DNS resource record, "SSHFP", to carry the fingerprint.
|
||||
|
||||
Basic understanding of the DNS system [1][2] and the DNS security
|
||||
extensions [5] is assumed by this document.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in RFC 2119 [3].
|
||||
|
||||
2. SSH Host Key Verification
|
||||
|
||||
2.1. Method
|
||||
|
||||
Upon connection to an SSH server, the SSH client MAY look up the
|
||||
SSHFP resource record(s) for the host it is connecting to. If the
|
||||
algorithm and fingerprint of the key received from the SSH server
|
||||
match the algorithm and fingerprint of one of the SSHFP resource
|
||||
record(s) returned from DNS, the client MAY accept the identity of
|
||||
the server.
|
||||
|
||||
2.2. Implementation Notes
|
||||
|
||||
Client implementors SHOULD provide a configurable policy used to
|
||||
select the order of methods used to verify a host key. This document
|
||||
defines one method: Fingerprint storage in DNS. Another method
|
||||
defined in the SSH Architecture [6] uses local files to store keys
|
||||
for comparison. Other methods that could be defined in the future
|
||||
might include storing fingerprints in LDAP or other databases. A
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 2]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
configurable policy will allow administrators to determine which
|
||||
methods they want to use and in what order the methods should be
|
||||
prioritized. This will allow administrators to determine how much
|
||||
trust they want to place in the different methods.
|
||||
|
||||
One specific scenario for having a configurable policy is where
|
||||
clients do not use fully qualified host names to connect to servers.
|
||||
In this scenario, the implementation SHOULD verify the host key
|
||||
against a local database before verifying the key via the fingerprint
|
||||
returned from DNS. This would help prevent an attacker from
|
||||
injecting a DNS search path into the local resolver and forcing the
|
||||
client to connect to a different host.
|
||||
|
||||
2.3. Fingerprint Matching
|
||||
|
||||
The public key and the SSHFP resource record are matched together by
|
||||
comparing algorithm number and fingerprint.
|
||||
|
||||
The public key algorithm and the SSHFP algorithm number MUST
|
||||
match.
|
||||
|
||||
A message digest of the public key, using the message digest
|
||||
algorithm specified in the SSHFP fingerprint type, MUST match the
|
||||
SSHFP fingerprint.
|
||||
|
||||
2.4. Authentication
|
||||
|
||||
A public key verified using this method MUST NOT be trusted if the
|
||||
SSHFP resource record (RR) used for verification was not
|
||||
authenticated by a trusted SIG RR.
|
||||
|
||||
Clients that do validate the DNSSEC signatures themselves SHOULD use
|
||||
standard DNSSEC validation procedures.
|
||||
|
||||
Clients that do not validate the DNSSEC signatures themselves MUST
|
||||
use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8])
|
||||
between themselves and the entity performing the signature
|
||||
validation.
|
||||
|
||||
3. The SSHFP Resource Record
|
||||
|
||||
The SSHFP resource record (RR) is used to store a fingerprint of an
|
||||
SSH public host key that is associated with a Domain Name System
|
||||
(DNS) name.
|
||||
|
||||
The RR type code for the SSHFP RR is 44.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 3]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
3.1. The SSHFP RDATA Format
|
||||
|
||||
The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
|
||||
type and the fingerprint of the public host key.
|
||||
|
||||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
|
||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| algorithm | fp type | /
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
|
||||
/ /
|
||||
/ fingerprint /
|
||||
/ /
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
3.1.1. Algorithm Number Specification
|
||||
|
||||
This algorithm number octet describes the algorithm of the public
|
||||
key. The following values are assigned:
|
||||
|
||||
Value Algorithm name
|
||||
----- --------------
|
||||
0 reserved
|
||||
1 RSA
|
||||
2 DSS
|
||||
|
||||
Reserving other types requires IETF consensus [4].
|
||||
|
||||
3.1.2. Fingerprint Type Specification
|
||||
|
||||
The fingerprint type octet describes the message-digest algorithm
|
||||
used to calculate the fingerprint of the public key. The following
|
||||
values are assigned:
|
||||
|
||||
Value Fingerprint type
|
||||
----- ----------------
|
||||
0 reserved
|
||||
1 SHA-1
|
||||
|
||||
Reserving other types requires IETF consensus [4].
|
||||
|
||||
For interoperability reasons, as few fingerprint types as possible
|
||||
should be reserved. The only reason to reserve additional types is
|
||||
to increase security.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 4]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
3.1.3. Fingerprint
|
||||
|
||||
The fingerprint is calculated over the public key blob as described
|
||||
in [7].
|
||||
|
||||
The message-digest algorithm is presumed to produce an opaque octet
|
||||
string output, which is placed as-is in the RDATA fingerprint field.
|
||||
|
||||
3.2. Presentation Format of the SSHFP RR
|
||||
|
||||
The RDATA of the presentation format of the SSHFP resource record
|
||||
consists of two numbers (algorithm and fingerprint type) followed by
|
||||
the fingerprint itself, presented in hex, e.g.:
|
||||
|
||||
host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890
|
||||
|
||||
The use of mnemonics instead of numbers is not allowed.
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
Currently, the amount of trust a user can realistically place in a
|
||||
server key is proportional to the amount of attention paid to
|
||||
verifying that the public key presented actually corresponds to the
|
||||
private key of the server. If a user accepts a key without verifying
|
||||
the fingerprint with something learned through a secured channel, the
|
||||
connection is vulnerable to a man-in-the-middle attack.
|
||||
|
||||
The overall security of using SSHFP for SSH host key verification is
|
||||
dependent on the security policies of the SSH host administrator and
|
||||
DNS zone administrator (in transferring the fingerprint), detailed
|
||||
aspects of how verification is done in the SSH implementation, and in
|
||||
the client's diligence in accessing the DNS in a secure manner.
|
||||
|
||||
One such aspect is in which order fingerprints are looked up (e.g.,
|
||||
first checking local file and then SSHFP). We note that, in addition
|
||||
to protecting the first-time transfer of host keys, SSHFP can
|
||||
optionally be used for stronger host key protection.
|
||||
|
||||
If SSHFP is checked first, new SSH host keys may be distributed by
|
||||
replacing the corresponding SSHFP in DNS.
|
||||
|
||||
If SSH host key verification can be configured to require SSHFP,
|
||||
SSH host key revocation can be implemented by removing the
|
||||
corresponding SSHFP from DNS.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 5]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
As stated in Section 2.2, we recommend that SSH implementors provide
|
||||
a policy mechanism to control the order of methods used for host key
|
||||
verification. One specific scenario for having a configurable policy
|
||||
is where clients use unqualified host names to connect to servers.
|
||||
In this case, we recommend that SSH implementations check the host
|
||||
key against a local database before verifying the key via the
|
||||
fingerprint returned from DNS. This would help prevent an attacker
|
||||
from injecting a DNS search path into the local resolver and forcing
|
||||
the client to connect to a different host.
|
||||
|
||||
A different approach to solve the DNS search path issue would be for
|
||||
clients to use a trusted DNS search path, i.e., one not acquired
|
||||
through DHCP or other autoconfiguration mechanisms. Since there is
|
||||
no way with current DNS lookup APIs to tell whether a search path is
|
||||
from a trusted source, the entire client system would need to be
|
||||
configured with this trusted DNS search path.
|
||||
|
||||
Another dependency is on the implementation of DNSSEC itself. As
|
||||
stated in Section 2.4, we mandate the use of secure methods for
|
||||
lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This
|
||||
is especially important if SSHFP is to be used as a basis for host
|
||||
key rollover and/or revocation, as described above.
|
||||
|
||||
Since DNSSEC only protects the integrity of the host key fingerprint
|
||||
after it is signed by the DNS zone administrator, the fingerprint
|
||||
must be transferred securely from the SSH host administrator to the
|
||||
DNS zone administrator. This could be done manually between the
|
||||
administrators or automatically using secure DNS dynamic update [11]
|
||||
between the SSH server and the nameserver. We note that this is no
|
||||
different from other key enrollment situations, e.g., a client
|
||||
sending a certificate request to a certificate authority for signing.
|
||||
|
||||
5. IANA Considerations
|
||||
|
||||
IANA has allocated the RR type code 44 for SSHFP from the standard RR
|
||||
type space.
|
||||
|
||||
IANA has opened a new registry for the SSHFP RR type for public key
|
||||
algorithms. The defined types are:
|
||||
|
||||
0 is reserved
|
||||
1 is RSA
|
||||
2 is DSA
|
||||
|
||||
Adding new reservations requires IETF consensus [4].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 6]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
IANA has opened a new registry for the SSHFP RR type for fingerprint
|
||||
types. The defined types are:
|
||||
|
||||
0 is reserved
|
||||
1 is SHA-1
|
||||
|
||||
Adding new reservations requires IETF consensus [4].
|
||||
|
||||
6. Normative References
|
||||
|
||||
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
|
||||
13, RFC 1034, November 1987.
|
||||
|
||||
[2] Mockapetris, P., "Domain names - implementation and
|
||||
specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
|
||||
Considerations Section in RFCs", BCP 26, RFC 2434, October
|
||||
1998.
|
||||
|
||||
[5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"DNS Security Introduction and Requirements", RFC 4033, March
|
||||
2005.
|
||||
|
||||
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Protocol Modifications for the DNS Security Extensions", RFC
|
||||
4035, March 2005.
|
||||
|
||||
[6] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
|
||||
Protocol Architecture", RFC 4251, January 2006.
|
||||
|
||||
[7] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
|
||||
Transport Layer Protocol", RFC 4253, January 2006.
|
||||
|
||||
7. Informational References
|
||||
|
||||
[8] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
|
||||
Roadmap", RFC 2411, November 1998.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 7]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
[9] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
|
||||
Wellington, "Secret Key Transaction Authentication for DNS
|
||||
(TSIG)", RFC 2845, May 2000.
|
||||
|
||||
[10] Eastlake 3rd, D., "DNS Request and Transaction Signatures
|
||||
( SIG(0)s )", RFC 2931, September 2000.
|
||||
|
||||
[11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
|
||||
Update", RFC 3007, November 2000.
|
||||
|
||||
8. Acknowledgements
|
||||
|
||||
The authors gratefully acknowledge, in no particular order, the
|
||||
contributions of the following persons:
|
||||
|
||||
Martin Fredriksson
|
||||
|
||||
Olafur Gudmundsson
|
||||
|
||||
Edward Lewis
|
||||
|
||||
Bill Sommerfeld
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Jakob Schlyter
|
||||
OpenSSH
|
||||
812 23rd Avenue SE
|
||||
Calgary, Alberta T2G 1N8
|
||||
Canada
|
||||
|
||||
EMail: jakob@openssh.com
|
||||
URI: http://www.openssh.com/
|
||||
|
||||
|
||||
Wesley Griffin
|
||||
SPARTA
|
||||
7075 Samuel Morse Drive
|
||||
Columbia, MD 21046
|
||||
USA
|
||||
|
||||
EMail: wgriffin@sparta.com
|
||||
URI: http://www.sparta.com/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 8]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 9]
|
||||
|
||||
@@ -1,563 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group D. Eastlake 3rd
|
||||
Request for Comments: 4343 Motorola Laboratories
|
||||
Updates: 1034, 1035, 2181 January 2006
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
Domain Name System (DNS) Case Insensitivity Clarification
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
Domain Name System (DNS) names are "case insensitive". This document
|
||||
explains exactly what that means and provides a clear specification
|
||||
of the rules. This clarification updates RFCs 1034, 1035, and 2181.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. Case Insensitivity of DNS Labels ................................2
|
||||
2.1. Escaping Unusual DNS Label Octets ..........................2
|
||||
2.2. Example Labels with Escapes ................................3
|
||||
3. Name Lookup, Label Types, and CLASS .............................3
|
||||
3.1. Original DNS Label Types ...................................4
|
||||
3.2. Extended Label Type Case Insensitivity Considerations ......4
|
||||
3.3. CLASS Case Insensitivity Considerations ....................4
|
||||
4. Case on Input and Output ........................................5
|
||||
4.1. DNS Output Case Preservation ...............................5
|
||||
4.2. DNS Input Case Preservation ................................5
|
||||
5. Internationalized Domain Names ..................................6
|
||||
6. Security Considerations .........................................6
|
||||
7. Acknowledgements ................................................7
|
||||
Normative References................................................7
|
||||
Informative References..............................................8
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 1]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Domain Name System (DNS) is the global hierarchical replicated
|
||||
distributed database system for Internet addressing, mail proxy, and
|
||||
other information. Each node in the DNS tree has a name consisting
|
||||
of zero or more labels [STD13, RFC1591, RFC2606] that are treated in
|
||||
a case insensitive fashion. This document clarifies the meaning of
|
||||
"case insensitive" for the DNS. This clarification updates RFCs
|
||||
1034, 1035 [STD13], and [RFC2181].
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
2. Case Insensitivity of DNS Labels
|
||||
|
||||
DNS was specified in the era of [ASCII]. DNS names were expected to
|
||||
look like most host names or Internet email address right halves (the
|
||||
part after the at-sign, "@") or to be numeric, as in the in-addr.arpa
|
||||
part of the DNS name space. For example,
|
||||
|
||||
foo.example.net.
|
||||
aol.com.
|
||||
www.gnu.ai.mit.edu.
|
||||
or 69.2.0.192.in-addr.arpa.
|
||||
|
||||
Case-varied alternatives to the above [RFC3092] would be DNS names
|
||||
like
|
||||
|
||||
Foo.ExamplE.net.
|
||||
AOL.COM.
|
||||
WWW.gnu.AI.mit.EDU.
|
||||
or 69.2.0.192.in-ADDR.ARPA.
|
||||
|
||||
However, the individual octets of which DNS names consist are not
|
||||
limited to valid ASCII character codes. They are 8-bit bytes, and
|
||||
all values are allowed. Many applications, however, interpret them
|
||||
as ASCII characters.
|
||||
|
||||
2.1. Escaping Unusual DNS Label Octets
|
||||
|
||||
In Master Files [STD13] and other human-readable and -writable ASCII
|
||||
contexts, an escape is needed for the byte value for period (0x2E,
|
||||
".") and all octet values outside of the inclusive range from 0x21
|
||||
("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in
|
||||
the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 2]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
One typographic convention for octets that do not correspond to an
|
||||
ASCII printing graphic is to use a back-slash followed by the value
|
||||
of the octet as an unsigned integer represented by exactly three
|
||||
decimal digits.
|
||||
|
||||
The same convention can be used for printing ASCII characters so that
|
||||
they will be treated as a normal label character. This includes the
|
||||
back-slash character used in this convention itself, which can be
|
||||
expressed as \092 or \\, and the special label separator period
|
||||
("."), which can be expressed as and \046 or \. It is advisable to
|
||||
avoid using a backslash to quote an immediately following non-
|
||||
printing ASCII character code to avoid implementation difficulties.
|
||||
|
||||
A back-slash followed by only one or two decimal digits is undefined.
|
||||
A back-slash followed by four decimal digits produces two octets, the
|
||||
first octet having the value of the first three digits considered as
|
||||
a decimal number, and the second octet being the character code for
|
||||
the fourth decimal digit.
|
||||
|
||||
2.2. Example Labels with Escapes
|
||||
|
||||
The first example below shows embedded spaces and a period (".")
|
||||
within a label. The second one shows a 5-octet label where the
|
||||
second octet has all bits zero, the third is a backslash, and the
|
||||
fourth octet has all bits one.
|
||||
|
||||
Donald\032E\.\032Eastlake\0323rd.example.
|
||||
and a\000\\\255z.example.
|
||||
|
||||
3. Name Lookup, Label Types, and CLASS
|
||||
|
||||
According to the original DNS design decision, comparisons on name
|
||||
lookup for DNS queries should be case insensitive [STD13]. That is
|
||||
to say, a lookup string octet with a value in the inclusive range
|
||||
from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the
|
||||
identical value and also match the corresponding value in the
|
||||
inclusive range from 0x61 to 0x7A, the lowercase ASCII letters. A
|
||||
lookup string octet with a lowercase ASCII letter value MUST
|
||||
similarly match the identical value and also match the corresponding
|
||||
value in the uppercase ASCII letter range.
|
||||
|
||||
(Historical note: The terms "uppercase" and "lowercase" were invented
|
||||
after movable type. The terms originally referred to the two font
|
||||
trays for storing, in partitioned areas, the different physical type
|
||||
elements. Before movable type, the nearest equivalent terms were
|
||||
"majuscule" and "minuscule".)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 3]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
One way to implement this rule would be to subtract 0x20 from all
|
||||
octets in the inclusive range from 0x61 to 0x7A before comparing
|
||||
octets. Such an operation is commonly known as "case folding", but
|
||||
implementation via case folding is not required. Note that the DNS
|
||||
case insensitivity does NOT correspond to the case folding specified
|
||||
in [ISO-8859-1] or [ISO-8859-2]. For example, the octets 0xDD (\221)
|
||||
and 0xFD (\253) do NOT match, although in other contexts, where they
|
||||
are interpreted as the upper- and lower-case version of "Y" with an
|
||||
acute accent, they might.
|
||||
|
||||
3.1. Original DNS Label Types
|
||||
|
||||
DNS labels in wire-encoded names have a type associated with them.
|
||||
The original DNS standard [STD13] had only two types: ASCII labels,
|
||||
with a length from zero to 63 octets, and indirect (or compression)
|
||||
labels, which consist of an offset pointer to a name location
|
||||
elsewhere in the wire encoding on a DNS message. (The ASCII label of
|
||||
length zero is reserved for use as the name of the root node of the
|
||||
name tree.) ASCII labels follow the ASCII case conventions described
|
||||
herein and, as stated above, can actually contain arbitrary byte
|
||||
values. Indirect labels are, in effect, replaced by the name to
|
||||
which they point, which is then treated with the case insensitivity
|
||||
rules in this document.
|
||||
|
||||
3.2. Extended Label Type Case Insensitivity Considerations
|
||||
|
||||
DNS was extended by [RFC2671] so that additional label type numbers
|
||||
would be available. (The only such type defined so far is the BINARY
|
||||
type [RFC2673], which is now Experimental [RFC3363].)
|
||||
|
||||
The ASCII case insensitivity conventions only apply to ASCII labels;
|
||||
that is to say, label type 0x0, whether appearing directly or invoked
|
||||
by indirect labels.
|
||||
|
||||
3.3. CLASS Case Insensitivity Considerations
|
||||
|
||||
As described in [STD13] and [RFC2929], DNS has an additional axis for
|
||||
data location called CLASS. The only CLASS in global use at this
|
||||
time is the "IN" (Internet) CLASS.
|
||||
|
||||
The handling of DNS label case is not CLASS dependent. With the
|
||||
original design of DNS, it was intended that a recursive DNS resolver
|
||||
be able to handle new CLASSes that were unknown at the time of its
|
||||
implementation. This requires uniform handling of label case
|
||||
insensitivity. Should it become desirable, for example, to allocate
|
||||
a CLASS with "case sensitive ASCII labels", it would be necessary to
|
||||
allocate a new label type for these labels.
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 4]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
4. Case on Input and Output
|
||||
|
||||
While ASCII label comparisons are case insensitive, [STD13] says case
|
||||
MUST be preserved on output and preserved when convenient on input.
|
||||
However, this means less than it would appear, since the preservation
|
||||
of case on output is NOT required when output is optimized by the use
|
||||
of indirect labels, as explained below.
|
||||
|
||||
4.1. DNS Output Case Preservation
|
||||
|
||||
[STD13] views the DNS namespace as a node tree. ASCII output is as
|
||||
if a name were marshaled by taking the label on the node whose name
|
||||
is to be output, converting it to a typographically encoded ASCII
|
||||
string, walking up the tree outputting each label encountered, and
|
||||
preceding all labels but the first with a period ("."). Wire output
|
||||
follows the same sequence, but each label is wire encoded, and no
|
||||
periods are inserted. No "case conversion" or "case folding" is done
|
||||
during such output operations, thus "preserving" case. However, to
|
||||
optimize output, indirect labels may be used to point to names
|
||||
elsewhere in the DNS answer. In determining whether the name to be
|
||||
pointed to (for example, the QNAME) is the "same" as the remainder of
|
||||
the name being optimized, the case insensitive comparison specified
|
||||
above is done. Thus, such optimization may easily destroy the output
|
||||
preservation of case. This type of optimization is commonly called
|
||||
"name compression".
|
||||
|
||||
4.2. DNS Input Case Preservation
|
||||
|
||||
Originally, DNS data came from an ASCII Master File as defined in
|
||||
[STD13] or a zone transfer. DNS Dynamic update and incremental zone
|
||||
transfers [RFC1995] have been added as a source of DNS data [RFC2136,
|
||||
RFC3007]. When a node in the DNS name tree is created by any of such
|
||||
inputs, no case conversion is done. Thus, the case of ASCII labels
|
||||
is preserved if they are for nodes being created. However, when a
|
||||
name label is input for a node that already exists in DNS data being
|
||||
held, the situation is more complex. Implementations are free to
|
||||
retain the case first loaded for such a label, to allow new input to
|
||||
override the old case, or even to maintain separate copies preserving
|
||||
the input case.
|
||||
|
||||
For example, if data with owner name "foo.bar.example" [RFC3092] is
|
||||
loaded and then later data with owner name "xyz.BAR.example" is
|
||||
input, the name of the label on the "bar.example" node (i.e., "bar")
|
||||
might or might not be changed to "BAR" in the DNS stored data. Thus,
|
||||
later retrieval of data stored under "xyz.bar.example" in this case
|
||||
can use "xyz.BAR.example" in all returned data, use "xyz.bar.example"
|
||||
in all returned data, or even, when more than one RR is being
|
||||
returned, use a mixture of these two capitalizations. This last case
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 5]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
is unlikely, as optimization of answer length through indirect labels
|
||||
tends to cause only one copy of the name tail ("bar.example" or
|
||||
"BAR.example") to be used for all returned RRs. Note that none of
|
||||
this has any effect on the number or completeness of the RR set
|
||||
returned, only on the case of the names in the RR set returned.
|
||||
|
||||
The same considerations apply when inputting multiple data records
|
||||
with owner names differing only in case. For example, if an "A"
|
||||
record is the first resource record stored under owner name
|
||||
"xyz.BAR.example" and then a second "A" record is stored under
|
||||
"XYZ.BAR.example", the second MAY be stored with the first (lower
|
||||
case initial label) name, the second MAY override the first so that
|
||||
only an uppercase initial label is retained, or both capitalizations
|
||||
MAY be kept in the DNS stored data. In any case, a retrieval with
|
||||
either capitalization will retrieve all RRs with either
|
||||
capitalization.
|
||||
|
||||
Note that the order of insertion into a server database of the DNS
|
||||
name tree nodes that appear in a Master File is not defined so that
|
||||
the results of inconsistent capitalization in a Master File are
|
||||
unpredictable output capitalization.
|
||||
|
||||
5. Internationalized Domain Names
|
||||
|
||||
A scheme has been adopted for "internationalized domain names" and
|
||||
"internationalized labels" as described in [RFC3490, RFC3454,
|
||||
RFC3491, and RFC3492]. It makes most of [UNICODE] available through
|
||||
a separate application level transformation from internationalized
|
||||
domain name to DNS domain name and from DNS domain name to
|
||||
internationalized domain name. Any case insensitivity that
|
||||
internationalized domain names and labels have varies depending on
|
||||
the script and is handled entirely as part of the transformation
|
||||
described in [RFC3454] and [RFC3491], which should be seen for
|
||||
further details. This is not a part of the DNS as standardized in
|
||||
STD 13.
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
The equivalence of certain DNS label types with case differences, as
|
||||
clarified in this document, can lead to security problems. For
|
||||
example, a user could be confused by believing that two domain names
|
||||
differing only in case were actually different names.
|
||||
|
||||
Furthermore, a domain name may be used in contexts other than the
|
||||
DNS. It could be used as a case sensitive index into some database
|
||||
or file system. Or it could be interpreted as binary data by some
|
||||
integrity or authentication code system. These problems can usually
|
||||
be handled by using a standardized or "canonical" form of the DNS
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 6]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
ASCII type labels; that is, always mapping the ASCII letter value
|
||||
octets in ASCII labels to some specific pre-chosen case, either
|
||||
uppercase or lower case. An example of a canonical form for domain
|
||||
names (and also a canonical ordering for them) appears in Section 6
|
||||
of [RFC4034]. See also [RFC3597].
|
||||
|
||||
Finally, a non-DNS name may be stored into DNS with the false
|
||||
expectation that case will always be preserved. For example,
|
||||
although this would be quite rare, on a system with case sensitive
|
||||
email address local parts, an attempt to store two Responsible Person
|
||||
(RP) [RFC1183] records that differed only in case would probably
|
||||
produce unexpected results that might have security implications.
|
||||
That is because the entire email address, including the possibly case
|
||||
sensitive local or left-hand part, is encoded into a DNS name in a
|
||||
readable fashion where the case of some letters might be changed on
|
||||
output as described above.
|
||||
|
||||
7. Acknowledgements
|
||||
|
||||
The contributions to this document by Rob Austein, Olafur
|
||||
Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
|
||||
Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
|
||||
are gratefully acknowledged.
|
||||
|
||||
Normative References
|
||||
|
||||
[ASCII] ANSI, "USA Standard Code for Information Interchange",
|
||||
X3.4, American National Standards Institute: New York,
|
||||
1968.
|
||||
|
||||
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
|
||||
August 1996.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
|
||||
"Dynamic Updates in the Domain Name System (DNS
|
||||
UPDATE)", RFC 2136, April 1997.
|
||||
|
||||
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
|
||||
Specification", RFC 2181, July 1997.
|
||||
|
||||
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
|
||||
Update", RFC 3007, November 2000.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 7]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
|
||||
(RR) Types", RFC 3597, September 2003.
|
||||
|
||||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security
|
||||
Extensions", RFC 4034, March 2005.
|
||||
|
||||
[STD13] Mockapetris, P., "Domain names - concepts and
|
||||
facilities", STD 13, RFC 1034, November 1987.
|
||||
|
||||
Mockapetris, P., "Domain names - implementation and
|
||||
specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
Informative References
|
||||
|
||||
[ISO-8859-1] International Standards Organization, Standard for
|
||||
Character Encodings, Latin-1.
|
||||
|
||||
[ISO-8859-2] International Standards Organization, Standard for
|
||||
Character Encodings, Latin-2.
|
||||
|
||||
[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P.
|
||||
Mockapetris, "New DNS RR Definitions", RFC 1183, October
|
||||
1990.
|
||||
|
||||
[RFC1591] Postel, J., "Domain Name System Structure and
|
||||
Delegation", RFC 1591, March 1994.
|
||||
|
||||
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
|
||||
Names", BCP 32, RFC 2606, June 1999.
|
||||
|
||||
[RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
|
||||
"Domain Name System (DNS) IANA Considerations", BCP 42,
|
||||
RFC 2929, September 2000.
|
||||
|
||||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
|
||||
2671, August 1999.
|
||||
|
||||
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
|
||||
RFC 2673, August 1999.
|
||||
|
||||
[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
|
||||
of "Foo"", RFC 3092, 1 April 2001.
|
||||
|
||||
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
|
||||
Hain, "Representing Internet Protocol version 6 (IPv6)
|
||||
Addresses in the Domain Name System (DNS)", RFC 3363,
|
||||
August 2002.
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 8]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
|
||||
Internationalized Strings ("stringprep")", RFC 3454,
|
||||
December 2002.
|
||||
|
||||
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
|
||||
"Internationalizing Domain Names in Applications
|
||||
(IDNA)", RFC 3490, March 2003.
|
||||
|
||||
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
|
||||
Profile for Internationalized Domain Names (IDN)", RFC
|
||||
3491, March 2003.
|
||||
|
||||
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of
|
||||
Unicode for Internationalized Domain Names in
|
||||
Applications (IDNA)", RFC 3492, March 2003.
|
||||
|
||||
[UNICODE] The Unicode Consortium, "The Unicode Standard",
|
||||
<http://www.unicode.org/unicode/standard/standard.html>.
|
||||
|
||||
Author's Address
|
||||
|
||||
Donald E. Eastlake 3rd
|
||||
Motorola Laboratories
|
||||
155 Beaver Street
|
||||
Milford, MA 01757 USA
|
||||
|
||||
Phone: +1 508-786-7554 (w)
|
||||
EMail: Donald.Eastlake@motorola.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 9]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights 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; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 10]
|
||||
|
||||
Reference in New Issue
Block a user