+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
projects / thirdparty / bind9.git / commitdiff
