Internet Engineering Task Force M. Smith Internet-Draft October 22, 2018 Updates: RFC4291, RFC4443, RFC6724 (if approved) Intended status: Standards Track Expires: April 25, 2019 IPv6 Formal Anycast Addresses and Functional Anycast Addresses draft-smith-6man-form-func-anycast-addresses-00 Abstract IPv6 anycast addresses are chosen from within the existing IPv6 unicast address space, with the addresses nominated as anycast addresses through configuration. An alternative scheme is to have a special class of addresses for use as anycast addresses. This memo proposes a distinct general anycast addressing class and a more specific scheme for functional anycast addresses. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 25, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Smith Expires April 25, 2019 [Page 1]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Drawbacks of Informal Anycast Addresses . . . . . . . . . . . 4 4. Formal Anycast Addresses . . . . . . . . . . . . . . . . . . 5 4.1. Address Format . . . . . . . . . . . . . . . . . . . . . 5 4.2. Address Fields . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Formal Anycast Prefix . . . . . . . . . . . . . . . . 5 4.2.2. Visible Scope . . . . . . . . . . . . . . . . . . . . 5 4.2.3. Anycast Identifier Format . . . . . . . . . . . . . . 5 4.2.4. Anycast Identifier . . . . . . . . . . . . . . . . . 6 4.3. Link-Local Visible Scope . . . . . . . . . . . . . . . . 6 4.4. ICMPv6 Destination Unreachable Message . . . . . . . . . 7 4.5. Default Address Selection . . . . . . . . . . . . . . . . 8 4.5.1. Destination Address Selection . . . . . . . . . . . . 8 4.5.2. Formal Anycast Scope Comparison . . . . . . . . . . . 8 4.6. Advice on Structuring the Anycast Identifier Field Values 8 5. Functional Anycast Addresses . . . . . . . . . . . . . . . . 10 5.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Address Format . . . . . . . . . . . . . . . . . . . . . 11 5.3. Assignment of Anycast Function Identifiers . . . . . . . 12 5.4. Assigned Anycast Function Identifiers . . . . . . . . . . 13 5.5. Sources of Inspiration for Anycast Function Identifiers . 14 5.6. Global Scope Functional Anycast Addresses on the Internet 15 5.7. Example Use Cases . . . . . . . . . . . . . . . . . . . . 16 5.7.1. Devices Factory Configured with NTP Functional Anycast Addresses . . . . . . . . . . . . . . . . . . 16 5.7.2. Branch Office DNS Resolvers . . . . . . . . . . . . . 18 5.7.3. Automatic eBGP Session Establishment . . . . . . . . 19 5.7.4. ISP's Anycast DNS Resolvers . . . . . . . . . . . . . 21 5.7.5. Microservices Architecture Applications . . . . . . . 22 5.7.6. Global Time Distribution Network . . . . . . . . . . 22 5.7.7. Example3 . . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. Change Log [RFC Editor please remove] . . . . . . . . . . . . 23 10. Informative References . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 Smith Expires April 25, 2019 [Page 2]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 1. Introduction [RFC1546] was the first description of host anycast services, and proposed two ways of supporting them in terms of addressing: o using parts of the existing address space o create a special class of addresses for anycast use The first method of supporting anycast addresses, by using parts of the existing (unicast) address space, could be described as informal. From the address itself, it is not possible to determine that the apparent unicast address is actually being used as an anycast address. As the second method would create a special class of addresses for anycast use, it could be described as formal. Encoded within the addresses would be a value and perhaps other attributes that indicates they are anycast addresses, regardless of context. In terms of a spectrum of delivery ranging from to a single or to multiple destinations, anycast addresses are a distinct class of addresses when compared to unicast and multicast addresses. Packets sent to a unicast destination are intended to be delivered to one and only one unique destination host. Packets sent to a multicast destination are intended to be delivered to a group of interested destination hosts, with the interested group consisting of one or more members, and the packets being duplicated by the network when and where necessary. Packets sent to an anycast destination are intended to be delivered to only one of a set of hosts sharing the same anycast address. As a type of address, anycast addresses can be imagined to fall between unicast and multicast address types on the delivery spectrum. IPv6 anycast addresses [RFC4291] are currently from within the existing unicast address address space. Therefore, this memo gives these IPv6 anycast addresses the name "Informal Anycast" addresses. This memo proposes a special and formal class of IPv6 addresses for anycast use, calling them "Formal Anycast" addresses. The described IPv6 Formal Anycast address class can support a total of 16 sub-classes of anycast address formats and structures. Following the description of Formal Anycast address class, this memo then proposes the first sub-class called "Functional Anycast" addresses. Smith Expires April 25, 2019 [Page 3]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 There are some existing reserved and well known anycast addresses within the existing Informal Anycast address space. While well known, they do not have any of the formal attributes that the proposed formal Functional Anycast addresses have, other than having specified and well known values; they could be described as semi- formal. Well known Functional Anycast addresses are proposed that correspond to these existing semi-formal anycast addresses. 2. Terminology Anycast Domain Formal Anycast Address Functional Anycast Address Informal Anycast Address Semi-Formal Anycast Address 3. Drawbacks of Informal Anycast Addresses There are drawbacks and limitions of IPv6 Informal Anycast addresses: o As mentioned in the Introduction, there is nothing specifically encoded in an Informal Anycast address to distinguish it from a unicast address, such as being from within a well known address prefix. In some situations, this unintentional obfuscation may be of use, however in others, such as while troubleshooting, it can be detrimental. For example, duplicate routes for an address appearing in a route table with different and distinct announcing routers may be a fault if unintentional, meaning it is a duplicate unicast address assignment. Alternatively, it may be the intended configuration if the routes are Informal Anycast routes i.e., the address from within the unicast address space is being used an anycast address. The duplicate routes and the addresses themselves provide no indication of whether the configuration is intentional or not. o Constraining the visibility and reachability of an anycast provided service or function may be useful for security reasons, which can be fundamentally enforced by encoding and limiting the scope of or domain where packets are intended and able to be forwarded. Informal Anycast addresses can only have one of three fundamental forwarding scopes encoded in the address, matching those of the three types of IPv6 unicast addresses - limited to a link scope (Link-Local Address), limited to a network scope (Unique Local Address) or having global Internet scope (Global Smith Expires April 25, 2019 [Page 4]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 Unicast Address) [RFC4291][RFC4193]. These scopes are coarse. More fine grained scopes, such as those used in IPv6 multicast [RFC7346], would provide much more control over anycast service or function visibility. 4. Formal Anycast Addresses 4.1. Address Format The following diagram shows the structure of an IPv6 Formal Anycast address. 4.2. Address Fields 4.2.1. Formal Anycast Prefix A 8 bit prefix value of TBD (aa00::/8 preferred, indicating a Anycast Address; fa00::/8 an alternative, indicating a Formal Anycast address), identifying this address as a Formal Anycast address. 4.2.2. Visible Scope A 4 bit Visible Scope field used to express and enforce visibility and assumed reachability of the Formal Anycast address. The values and meanings of the values of this field are the same as those for the IPv6 multicast address scope field [RFC4291][RFC7346]. When packets with a Formal Anycast destinaton address are being forwarded, this field's value takes precedence over a non-zero Hop Limit field value, meaning the packet MUST be discarded at the edge of the indicated visibility domain even though it may have a non-zero Hop Limit value. A specific ICMPv6 Destination Unreachable [RFC4443] message, described below, SHOULD be generated and returned to the packet's sender indicating the packet was discarded as it reached the edge of its Visible Scope. 4.2.3. Anycast Identifier Format A 4 bit field identifying the format of the following Anycast Identifier field, holding digits in the range of 0x0 through 0xf in hexidecimal. The first assigned value is 0, specifying that the following Anycast Identifier Format is that of a Functional Anycast addresses, which is described later in this memo. Other values will be assigned by IANA as future Anycast Identifier Formats are specified. Smith Expires April 25, 2019 [Page 5]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 4.2.4. Anycast Identifier A 112 bit field holding the Anycast Identifier value. The format and structure of this field is encoded in the previous Anycast Identifier Format field. 4.3. Link-Local Visible Scope One of the possible Visible Scope values is the Link-Local scope, specifying that the Formal Anycast address's visibility is limited to a link that the host is directly attached to. Nodes on the link will need to consider Formal Anycast addresses with a Link-Local Visible Scope on-link, so that they perform Neighbor Discovery [RFC4861] for these addresses. Similar to the unicast Link-Local prefix [RFC5942], IPv6 implementations SHOULD BE updated to consider the Formal Anycast prefix with a Link-Local Visible Scope on-link. Using the (preferred, IANA TBA) aa00::/8 Formal Anycast prefix, this means IPv6 implementations will consider aa02::/16 to be on-link. Unlike the unicast Link-Local prefix, updated IPv6 implemenations MUST NOT use SLAAC [RFC4862] to generate an automatic address from within this Formal Anycast Link-Local Visible Scope prefix (MRS: Need to further consider this, is there a case I've missed where this could be useful? Hmm, what about, for example, the router subnet anycast address? Perhaps anycast providing applications could/should resister their anycast addresses similar to multicast. Hmm, there really needs to be any "Anycast Listener Discovery" protocol similar or same as MLD.). Note that unlike the unicast Link-Local prefix, IPv6 nodes may not and typically would not have an address from within the Formal Anycast Link-Local Visible Scope prefix. One of the node's Link- Local addresses on the same link should be used as a source address when sending to a Formal Anycast Link-Local Visible Scope destination. This does not preclude using other greater scope unicast source addresses. (MRS: probably need to update source/ destinaton address selection RFC - I think that is already somewhere in this draft?) In the interrim IPv6 implementation update period, IPv6 nodes can be informed that the Formal Anycast Link-Local Visible Scope prefix is on-link in one of two ways: o A manually configured entry in the host's Prefix List [RFC4861]. Smith Expires April 25, 2019 [Page 6]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 o A dynamic update to nodes' Prefix Lists using a Router Advertisement Prefix Information Option (PIO) for the Formal Anycast Link-Local Visible Scope prefix, with the 'L' or on-link flag set to on, and the 'A' or autonomous address-configuration flag set to off (as this prefix MUST NOT be used by the node to automatically generate an address for its use within this prefix). The Valid and Preferred Lifetimes for the Formal Anycast Link- Local Visible Scope prefix in the PIO are set to infinity. 4.4. ICMPv6 Destination Unreachable Message As mentioned prevously, if a packet with a Formal Anycast destination address reaches the edge of the Visible Scope for the address, a ICMPv6 Destination Unreachable [RFC4443] message SHOULD be generated and sent back to trigger packet's sender. Note that if the router at the edge of the visibility domain is also assigned the Formal Anycast address, the packet is host processed locally rather than being discarded, and an ICMPv6 Destination Unreachable message IS NOT generated and returned to the packet's sender. When a router implementation formally supports Formal Anycast addresses, the ICMPv6 Code for the Destination Unreachble message is IANA-TBD, indicating that the Edge of the Visible Scope [was] Reached. If a router implementation does not formally support Formal Anycast addresses an operator should use packet filters to enforce the Visible Scope boundary. A packet failing to pass the packet filter should cause the router to generate a Destination Unreachable Communication with destination administratively prohibited message [RFC4443] (Code 1) message, which is semantically similar to the formal Edge of Visibile Scope Reached message. Note that ICMPv6 messages are not sent reliably, so Formal Anycast packet senders will need to be able to handle not receiving a ICMPv6 Destination Unreachable message in response to a packet reaching the edge of the visibility domain. There may be situations where silently discarding Formal Anycast packets at the Visible Scope boundary may be preferred. In this case, a packet discard route, covering the Visible Scope prefix can be installed in a router's forwarding table. Smith Expires April 25, 2019 [Page 7]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 4.5. Default Address Selection 4.5.1. Destination Address Selection An IPv6 implementation may be presented with a candidate set of destination addresses that consists of both Formal Anycast and unicast addresses. The implementation needs to make a choice or choices as to which of these candidate addresses to attempt to use. The decision to use a Formal Anycast address instead of a unicast address is an active and conscious one. Therefore, when a choice needs to be made between a Formal Anycast address and a unicast address, the Formal Anycast address should always be preferred. In terms of the Destinaton Address Selection algorithm described in [RFC6724], this preference of Formal Anycast over unicast addresses introduces a new rule between Rule 1 ("Avoid unusable destinations") and Rule 2 ("Prefer matching scope"), specifically (using "1.5" here to indicate the position): Rule 1.5: Prefer Formal Anycast addresses. If DA is a unicast address, and DB is a Formal Anycast address, then prefer DB. Note that there may be instances where an application would prefer to use a unicast address over a Formal Anycast address. In this case, Formal Anycast addresses can be identified and ignored using the well known 8 bit Formal Anycast prefix. 4.5.2. Formal Anycast Scope Comparison As the Formal Anycast address scopes are defined to be the same as Multicast address scopes, the same Multicast scope comparison methods, described in [RFC6724], are used with Formal Anycast address scopes. 4.6. Advice on Structuring the Anycast Identifier Field Values The Anycast Identifier Format field within a Formal Anycast address specifies the format and structure of the 112 bit Anycast Identifier field. The following is advice and guidelines to use when developing a new Anycast Identifier field format and structure. Forwarding towards anycast addresses is the same as forwarding towards unicast addresses, which uses the longest match rule BCP 198 [RFC7608]. Longest match forwarding facilitates summarisation of forwarding information, where a single more general forwarding route Smith Expires April 25, 2019 [Page 8]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 can summarise a number of more specific forwarding routes. Summarisation saves entries in forwarding tables outside of the summarised forwarding domain, provides simpler destination based filtering for security purposes, and facilitates easier destination address based traffic analysis. The use of route summarisation with anycast addresses effectively creates an anycast domain that is being identified and summarised by the anycast summary route. Outside of the anycast domain, a single summary route exists, covering all anycast addresses within the domain. Within the anycast domain, individual routes for individual anycast addresses exist. When designing a new Anycast Identifier field format and structure, the following guidelines should be followed. These guidelines should allow a set of more specific anycast routes to be summarised as well as improving operator usability. o The order of fields within the Anycast Identifier field, should be from the most general to most specific, in the direction following the high order to low order bits of the Anycast Identifier field and the broader IPv6 address. o The order of bits within fields should also be from the most general to most specific, matching the direction of high order to low order of bits within the Anycast Identifier field. o The bits in fields holding bits that are matched exactly, such as flag fields or fields holding numeric values that are matched exactly, can be orded to suit the field's use and application. However, a hierarchial order, from most significant to least significant bit, following Anycast Identifier field bit order, is suggested. Although initially defined hierarchially, the order of flags in flag fields may later deviate from this recommendation due to later flag bit definition. o End-users of the functions and services being provided using Formal Anycast addresses are unlikely and ideally should never see these addresses. However, operators of these functions and services will deal with these addresses during planning, configuration and troubleshooting. Where possible, fields and their values should be ordered and structured to assist with these tasks. Field boundaries within the Anycast Identifier field should align with 16 bit word, 8 bit octet or 4 bit nibble positions within the whole IPv6 address. For example, if part of an IPv6 prefix is included in the Anycast Identifier, it should start at a 16 bit "piece" boundary, where colons appear [RFC4291], within the IPv6 address. Note that this guildline should not take Smith Expires April 25, 2019 [Page 9]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 precedence over any previous measures to faciliate more specific anycast route summarisation. o A further address usability recommendation is to set field and bit values to zero for the likely most common or likely most secure meaning for these fields or bit values. In IPv6 addresses zero field values can be compressed [RFC5952], resulting in a shorter address for an operator to enter. A shorter address to enter naturally reduces the opportunities for and likelihood of errors in the address, and reduces the possibilities of security issues caused by errors in the Formal Anycast address.. 5. Functional Anycast Addresses The first defined sub-class or sub-format of Formal Anycast addresses is the Functional Anycast address sub-class. 5.1. Features The following are the features of Functional Anycast addresses. In many cases they're inspired by and mirror IPv6 multicast address features [RFC4291][RFC3306]. o Provides separate globally well known and local network defined anycast function or service identifier spaces. Globally well known identifiers can be encoded in applications during their development as constants, avoiding the need for them to be specified and configured during deployment of the application. o Provides a minimum of 24 bits for use as identifiers for anycast functions or services, supporting more than 16 million values.. o Provides 8 bits for the identification of up to 256 local instances, versions or revisions of the same function or service, assisting with function or service deployment or maintenance. These 8 bits can also be used to increase the size of the function or service identifier space to 32 bits where useful, increasing the range of values to more than 4 billion. o Identifies an anycast function or service identifier space, known as an anycast domain, using an IPv6 unicast address prefix of up to 64 bits in length. A network can create multiple distinct anycast domains by using multiple of its IPv6 prefixes, from its Global [RFC4291] or Unique Local [RFC4193] address spaces (the Link-Local prefix could be used to create a distinct anycast domain, however it can only be used once, despite the network having many instances of the Link-Local prefix (as many as it has links)). A "unspecified" anycast domain is supported using an all Smith Expires April 25, 2019 [Page 10]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 zeros 64 bit IPv6 prefix. External to the anycast domain, the identifying 64 bit prefix can be used to create a single summary route for the anycast function or service identifier space, which will help routing scaling for anycast functions or services. The anycast domain boundary could also correspond to routing protocol scaling boundaries, such as OSPF areas [RFCxxxx] or IS-IS level [RFCxxxx] boundaries, when useful. 5.2. Address Format The format of Functional Anycast addresses is modelled on the IPv6 multicast address format [RFC4291]. The format of an Functional Anycast address is as follows: [diagram to come] The address fields are as follows: o Anycast Domain Prefix - a 64 bit field holding a IPv6 unicast address prefix identifying the anycast domain that is either the provider and possible authority for the following Anycast Function Identifier space. The length of the prefix is specified in the following Prefix-Length field, with the remaining bits of the field set to zero. An all zero Anycast Domain Prefix means an unspecified Anycast Function Identifier provider. An all zeros Prefix in effect means "this" provider, with "this" meaning the current anycast domain. Link-Local, Unique-Local [RFC4193], Global and possible future other unicast prefixes [RFC4291] identify a Anycast Function Identifier provider. Within an anycast function domain, this allows multiple anycast function sub-domains to be created, identified by different unicast Prefixes in this field. o Reserved - a 2 bit reserved field. Set to zero upon transmission, ignored upon receipt. o Prefix-Length - An 6 bit field specifying the length of the previous Anycast Domain Prefix. A value of zero means a 64 bit length prefix, while prefix lengths of 1 through 63 (0x01 through 0x3f) are encoded natively. The unspecified Anycast Domain Prefix of all zeros is considered to be 64 bits in length, meaning a Prefix-Length value of 0 for this prefix. This is an informational field to assist with operation and troubleshooting. o Flags - A 8 bit flag field. The lower 7 flags are reserved and must be set to zero upon transmission, and ignored upon receipt. The high order flag is the 'T' or Transient flag. T=0 indicates Smith Expires April 25, 2019 [Page 11]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 that the later Anycast Function Identifier is well known and assigned by the Internet Assigned Numbers Authority (IANA). T=1 indicates that the Anycast Function Identifier is transient or dyamically assigned, and has been assigned by the Functonal Anycast domain's local authority. o Local Instance - An 8 bit field holding a identifier of the instance, version or revision of the function identified by the following Anycast Function Identifier field, local to the current anycast domain. The default value of this field is zero, indicating the default and first instance of the anycast function. Non-default values are chosen by the local anycast domain operator, even when the following Anycast Function Identifier is using a well-known IANA Anycast Function Identifier value. An anycast domain operator may chose to assign other semantics to this field, as long as they're both less significant than the previous fields and more sigificant than the following Anycast Function Identifier field. When the 'T' bit in the Flags field is set to 1, meaning transient Anycast Function Identifiers, this field could be used to effectively increase the size of the following Anycast Function Identifier field to 32 bits, increasing the value range of Anycast Function Identifiers from in the order of 16 million to in the order of 4 billion. o Anycast Function Identifier - A 24 bit field identifying the anycast function to be performed on the packet when it arrives at a host that has been configured with the Functional Anycast address. When the 'T' bit in the Flags field is set to zero, the Anycast Function Identifiers values are from a well known Anycast Function Identifier registry maintained by IANA, with initial entries specified later in this memo. When the 'T'bit in the Flags field is set to 1, the values in the Anycast Function Identifier field are local to and assigned by the authority identified in the Prefix field in any manner that suits their purposes and requirements. 5.3. Assignment of Anycast Function Identifiers In the history of the Internet, it has been common to conflate a function or service with a protocol. For example, historically, the telnet protocol [RFCxxxx] had been the most popular remote virtual terminal protocol. In more recent times, the SSH protocol [RFCxxx] has become the de facto remote virtual terminal protocol. Accessing the remote virtual terminal service has either been referred to as "telnet in" or "SSH in" to the host providing the service, using the protocol being used to refer to the service being accessed. Smith Expires April 25, 2019 [Page 12]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 In either case, telnet and SSH protocols are being used to access a remote virtual terminal service. Functionally, from the perspective of remote virtual terminal access, the differences are relatively minor; data security and integrity via encryption and authentication is where the primary differences between telnet and SSH are - in telnet encryption of the data stream is optional [RFCxxx], where as with SSH it is mandatory. When both IANA and local anycast domain operators assign Anycast Function Identifiers, it is recommended that they're allocated and identified by protocol agnostic function or service type rather than to a specific protocol that provides that function or service. As the particular protocol being used to access the function or service will be encoded in the upper transport layer protocols and ports in the IPv6 packet, service or function based Anycast Function Identifers can support and stay constant across the use and evolution of different function or service access protocols. For example, with a well-known Anycast Function Identifier specifically allocated to a Network Virtual Terminal service (NVT) [RF852?], the hosts providing the NVT service could initially support both telnet (assuming telnet is considered secure enough) and SSH. If both telnet and SSH become deprecated, and a new NVT access protocol is developed, the same Anycast Function Identifier for the NVT service could be used to reach a node supporting this new access protocol. Another example is the domain name service. Currently domain name resolution takes place using the Domain Name Service protocol [RFCxxx], natively carried over UDP and TCP, using port 53. More recently, work has been taking place to operate DNS over TLS [RFCxxx] and HTTP [RFCxxx] to enhance the security of the domain name resolution function. The use of multiple protocols to access fundamentally the same domain name resolution function suggests a protocol agnostic domain name resolution Anycast Function Identifier. This doesn't preclude Anycast Function Identifiers being used to support and identify specific protocols (examples of this occur later). There may be current and future cases where the allocation and use of an Anycast Function Identifier for a specific protocol is the better choice. This should be considered and evaluated on a case by case basis. 5.4. Assigned Anycast Function Identifiers A number of past RFCs have reserved anycast addresses and identifiers. These addresses and indentifiers are mapped to the following corresponding and well known Anycast Function Identifiers, Smith Expires April 25, 2019 [Page 13]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 and are to be listed in the IANA Anycast Function Address Identifier registery if it is created. [RFC2526] reserves the highest 127 values of a subnet prefix Interface Identifier for anycast addresses. The equivalent values for Functional Anycast addresses are the highest 127 values of the 32 bit Anycast Function Identifier, a range of (in IPv6 address format, excluding the high order 96 bits) :ffff:fff8 through :ffff:ffff. The IANA Internet Protocol Version 6 (IPv6) Anycast Addresses registry [IANA-IPV6ANYC] records assignments for subnet prefix anycast addresses within the Interface Identifier space. The current and future values of these anycast subnet prefix Interface Identifier values are to also be recorded in the Anycast Function Address Identifier registry. [RFC4291] reserves an Interface Identifer of all zeros within a unicast prefix as the Subnet-Router anycast address. The equivalent 32 bit Anycast Function Identifier value for Functional Anycast addresses is also all-zeros. [RFC7723] reserves the IPv6 address 2001:1::1/128 for the use as the Port Control Protocol Anycast address. The equivalent 32 bit Anycast Function Identifier value is (in IPv6 address format, excluding the high order 96 bits) :0001:0001. [RFC8155] reserves the IPv6 address 2001:1::2/128 for the use as the Traversal Using Relays around NAT Anycast address. The equivalent 32 bit Anycast Function Identifier value is (in IPv6 address format, excluding the high order 96 bits) :0001:0002. 5.5. Sources of Inspiration for Anycast Function Identifiers A future possible source of inspiraton for well known assigned Anycast Function Identifiers could be DHCPv6 [RFC3315] options that encode IPv6 addresses for services. A number of these options encode multiple IPv6 addresses as candidates for access to the service (for example, the SIP Servers IPv6 Address List option [RFC3310]). The use of anycast for service resiliance would allow a single Anycast Function Identifier value to provide equivalent service, although this wouldn't preclude defining multiple different Anycast Function Identifiers to the service to provide the service client concurrent access to multiple service instances. For example, 3 Functional Anycast addresses could be allocated for DNS resolvers, providing a client with verifiable DNS resolver services from up to 3 different resolvers, and allowing the client to distribute requests across all 3 resolvers. Smith Expires April 25, 2019 [Page 14]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 Another source of inspiration for well known assigned Anycast Function Identifiers could be the IANA IPv6 Multicast Address Space [IANA-IPV6MCAST] registry, where some of the multicast addresses represent services that could also be useful when provided via anycast. While using these possible source of inspiration, the recommendation to choose protocol agnostic function or service identifiers still stands. DHCPv6 or multicast groups can be used to inspire more generic function or service identifiers. 5.6. Global Scope Functional Anycast Addresses on the Internet Functonal Anycast addresses could be used to provide anycast services across the Internet, by using the the Global scope. When being used on the Internet, many of the possible values of the Prefix field are ambiguous, meaning that they wouldn't unambiguously identify the party using the Functional Anycast address to provide the service or function. Examples of ambiguous prefixes are the all- zeros unspecified prefix, any ULA [RFC4193] prefixes, and the Link- Local [RFC4291] prefix. Other ambiguous prefixes are those in the IPv6 reserved address registry [IANA-IPV6RESA] that are not valid on the Internet. To overcome this ambiguity, if Global scope Functional Addresses are used over the Internet, the Prefix field MUST be set to a GUA [RFC4291] prefix value assigned to the party providing the anycast service to Internet clients. A network either accepting or originating a Global scope Functional Address prefix for announcement from a downstream stub autonomous system for announcement onto the Internet MUST only accept or originate a route announcement for a Global scope Functional Anycast prefix that includes an explicitly identified GUA prefix. All other Global scope Functional Anycast prefix announcements with ambiguous or non-explicitly identified GUA prefixes MUST be ignored. As forwarding towards anycast addresses is functionally the same as forwarding towards unicast addresses, Functional Anycast prefixes would be announced into the Internet's unicast forwarding route table. It is common practice today to limit the prefix length of unicast IPv6 Internet routes accepted to a length of no more than 48 bits i.e. a /48. This is a blunt and simple way to attempt to somewhat limit the number of IPv6 routes in the Internt route table. It is imposing this limit by enforcing a minimal level of aggregation at the /48 boundary. Networks using prefix lengths longer than /48 are Smith Expires April 25, 2019 [Page 15]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 expected to aggregate those networks into a route advertisement that is /48 or shorter. This practice of limiting advertised unicast route prefix lengths to 48 bits will limit the size of the Prefix included in Global scope Functional Anycast announcements to 32 bits, as the high order 16 bits of the Functional Anycast prefix are used to encode the Functional Address type prefix and address scope. This would limit the use of Global scope Functional Anycast addresses to provide global Internet anycast services to those organisations who have a /32 or shorter assignment from an RIR. As Functional Anycast addresses are a separate class of addresses, and are all identified by a unique /8 prefix, this /48 prefix length limit could be specifically relaxed for Functional Anycast routes. A /48 prefix, when included in a Functional Anycast, results in a Functional Anycast prefix length of /64. Imposing a /64 prefix length limit on Functional Anycast routes, identified by a high order prefix of aa0e::/16, and a GUA anycast domain Prefix, would achieve the same outcome of attempting to reducing the number of entries in the IPv6 Internet route table. Wide acceptance of Functional Anycast prefixes of up to 64 bits in length on the Internet may take same time to occur. Use of Global scope Functional Anycast addresses by organisations who have RIR /32 assignments, which will be accepted by unicast /48 prefix filters present today, would raise awareness of Functional Anycast addresses. This increased awareness could be leveraged to motivate the changing of prefix filters to accept Global scope Functional Anycast prefixes up to 64 bits in length. 5.7. Example Use Cases This section provides some example use cases of Functional Anycast addresses that would suit the described scenarios. 5.7.1. Devices Factory Configured with NTP Functional Anycast Addresses Assume IANA has allocated a set of well-known Anycast Function Identifier values of 0x004440, 0x004441, 0x004442 and 0x004443 for use with the Network Time Protocol [RFCxxxx], to facilitate meeting the NTP best practice of having a minimum of 4 NTP time sources [NTP best practices ID]. A device manufacturer uses this set of well-known Anycast Function Identifier to set factory default Functional Anycast addresses for access to a device customer's NTP servers. Smith Expires April 25, 2019 [Page 16]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 The corresponding Functional Anycast address is constructed as follows: o 8 bit Formal Anycast Prefix value (0xaa proposed). o 4 bit Visible Scope value of 0x8, corresponding to Organization- Local [RFC7346], as the manufacturer is unlikely to have any knowledge of device customers' use of or preference for smaller scopes. o 4 bit Anycast Identifier Format value of 0x0, corresponding to the Functional Anycast format. o 112 bit Anycast Identifier in the Functional Anycast format: o * 64 bit Anycast Domain Prefix value of the all zeros unspecified prefix. * 2 bit reserved field set to zero. * 6 bit Prefix-Length field set to zero, meaning a 64 bit length Anycast Domain Prefix value. * 8 bit Flags field set to all zeros. The upper 7 bits are zero as they're served, while the lowest 'T' or Transcient flag is set to zero indicating an IANA assigned well known Anycast Function Identifier. * 8 bit Local Instance flag set to the default value of zero. * 24 bit Anycast Function Identifier field set to either 0x004440, 0x004441, 0x00442 or 0x004443; one of the IANA assigned well known Anycast Function Identifier values for the NTP protocol. All of the above mean that the NTP server Functional Anycast addresses the device manufacturer sets as the defaults would be (in IPv6 address compressed format): o aa08::4440 o aa08::4441 o aa08::4442 o aa08::4443 Smith Expires April 25, 2019 [Page 17]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 5.7.2. Branch Office DNS Resolvers An enterprise network operator decides to use Functional Anycast addresses to provide DNS resolver service to end-user devices, located in various corporate offices. Specifically for a single mid-sized branch office, with in the order of 200 staff, the operator decides to provide two DNS resolvers located in the office. This will provide lower latency DNS resolution through DNS caching, reducing perceiveable application response time [NORMNEIL]. Access to a third, geographically close, off-site DNS resolver is provided for redundancy. This off-site DNS resolver will be one of the other branch office's local DNS resolvers. All three DNS resolvers will provide their services to clients via Functional Anycast addresses. Different clients will receive the on- site DNS resolver addresses in alternating order, both before the off-site DNS resolver address. This provides rudimentry on-site DNS resolver load balancing and keeps both DNS resolvers' lookup caches populated to reduce the client visible performance impact of the fail-over to the remaining on-site DNS resolver, should its sibling fail. The on-site DNS resolvers will watch each others' availablility, taking over its sibling's Functional Anycast address if the sibling becomes unavailable. Should both on-site DNS resolvers become unavailable, clients will resort to using the remaining off-site DNS resolver. Assume IANA have allocated the well known Anycast Function Identifier values of 5300, 5301 and 5302 for use with anycast DNS resolvers. The operator allocates decimal identifiers of 703, 9556, 4739, 38809 and 2764 to the corporate offices, with the order reflecting geographic proximity. Each office will have its own unicast /48 from within a globally unique address space of 2001:db8::/32, meaning that the office prefixes are 2001:db8:2bf::/48, 2001:db8:2554::/48, 2001:db8:9779::/48 and 2001:db8:acc::/48. The corresponding Functional Anycast address is constructed as follows: o The Visibiliity Scope for for these DNS resolvers' Functional Anycast addresses will be Organization-Local (8). For office 9556, using offic 4739 as an off-site backup, the Functional Anycast addresses for the three DNS resolvers will be: Smith Expires April 25, 2019 [Page 18]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 1. aa08:2001:db8:2554::5301 2. aa08:2001:db8:2554::5302 3. aa08:2001:db8:9779::5303 5.7.3. Automatic eBGP Session Establishment Assume IANA has allocated a well-known Anycast Function Identifier value of 0x000179 for use with automatic eBGP [RFC4271?] session establishement. Smaller, stub site routers are preconfigured with a Functional Anycast address to attempt to automatically establish an eBGP session with a one or two upstream eBGP peer aggregation routers over one or two different designated ("WAN") links upon initialisation. The eBGP Functional Anycast address would be a Link-Local Visible scope address. The stub router would use its link's, SLAAC generated [RFC4861] and link unique Link-Local address [RFC4291] as the source address to reach the eBGP Functional Anycast address. Using Link- Local scope Formal Anycast and unicast addresses for this eBGP session would provide a basic level of eBGP access security. The stub site router will need to also be preconfigured or somehow automatically generate an Autonomous System Number (ASN) to use for establishing the eBGP session or sessions. How the ASN is preconfigured or generated is out of scope for this memo, and is left to future work. Once the eBGP session is established, the peer eBGP routers trade routes. These traded routes could include the upstream eBGP providing a default route or other more specific routes, and the downstream stub site router providing a route to its downstream prefix or prefixes. The downstream prefix or prefixes could be those the stub site router has learned via DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633]. An advantage of having the stub site router inject DHCPv6-PD prefixes into the BGP routing domain is that the route information for this or these prefixes within the BGP routing domain would more accurately reflect the state and therefore the availability of the prefixes at the site they've been assigned and are being used it. Stub site routers announcing their own prefixes would also distribute the announcement processing load across the stub site routers rather than concentrating it at the upstream aggregation router(s). This also avoids the upstream aggregation router having to process the DHCPv6-PD response to determine the assigned delegated prefix for Smith Expires April 25, 2019 [Page 19]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 subsequent BGP announcement [RFC about doing this?], meaning it can act as a much simpler and pure DHCPv6 relay [RFC3315]. The upstream link(s) that a stub site is attached to does not have to be limitied to being a true link-layer point-to-point link, meaning that the link only supports a single router pair of a stub and upstream aggregation router. The link could be a multi-access link, with the single link supporting many stub site routers and a number of upstream aggregation routers. As the eBGP Functional Anycast address is a Link-Local Visible Scope address, the address is configured as an anycast address on the upstream aggregation routers' stub site facing network interface. This results in the receiver of the Neighbor Advertisements for this address using the information received in the first received Neighbor Advertisement to update its neighbor cache, rather than the last and most recently received Neighbor Advertisement. These types of Neighbor Advertisements are known as "Anycast Neighbor Advertisements" in [RFC4861]. [RFC4861] says that Anycast Neighbor Advertisements should be delayed a random amount of time between 0 and MAX_ANYCAST_DELAY_TIME, a variable with a default value of 1 second. This random delay is to reduce the probability of loss of the Neighbor Advertisement due to network congestion. Specific to this eBGP use case, the Anycast Neighbor Advertisements delay could include other metrics in the calculation to more intelligently distribute the eBGP sessions across the set of upstream aggregation routers. For example, the number of existing eBGP sessions could be a metric, where an upstream aggregation router delays its Anycast Neighbor Advertisement longer when it has more established eBGP sessions. An operator set router preference metric could be considered, allowing the operator to more gracefully phase out a legacy upstream aggregation router by setting it preference lower than the newer upstream aggregation routers. The operator would then manually terminate the eBGP sessions individually on the legacy upstream aggregation router, at a rate of something like one ever 3 seconds, causing them to be restablished on the higher preference and newer upstream aggregation routers. This would be more graceful than terminating all eBGP sessions at once on the legacy upstream aggregation router by, for example, switching it off. Branch office stub router, automatically attempts to establish a BGP session with a well-known functional anycast address "out of the box" over the default WAN interface. Smith Expires April 25, 2019 [Page 20]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 IANA assigned well-known BGP Anycast Function Identifier Link-local scope Functional Anycast address. Provides a minimum level of security, as only possible to establish BGP sessions between direct link peers. Use unspecified prefix (comment that fe80::/64 could be used, although unnecessary) Well-known AS Number used by all stub routers. This makes the BGP sessions eBGP sessions. Routers will reject routes from other stub routers using the same ASN, however this is both fine and ideal as this is a stub router - default only plus announcing its local prefix(es). Sub router acquires a delegated prefix via DHCPv6-PD The delegated prefix is announced via the BGP session. Stops the upstream aggregation router needing to observe a DHCPv6 server's relayed response to then announce the delegated prefix into the network. Upstrem router accepts and establishes BGP sessions with any link- local address from the well known ASN, to the Functional Anycast BGP address. There are potential trust issues here. BGPsec? Use the first BGP session to bootstrap connectivity to then establish a more trusted connection of some sort via PKI. Requirement for being link-local peers adds a minimal level of security and trust, but not much. 5.7.4. ISP's Anycast DNS Resolvers ISP DNS anycast resolvers Don't want it to be globally reachable across the Internet to mitigate DDoS attacks on the DNS resolver i.e. don't use GUA address(es) Can't use a prefix that has the possibility of colliding with any of the customers' prefixes. ULA addresses would meet this requirement. However, per [RFC4193], ULAs have a site scope. The boundaries of customers' networks correspond to site boundaries, and therefore the ISP's ULA prefix is not reachable from customers' networks unless customers' network boundary routers are explicitly configured to provide ISP ULA prefix access. Smith Expires April 25, 2019 [Page 21]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 Organisation Local Functional Anycast address meets all of the requirements. 5.7.5. Microservices Architecture Applications 5.7.6. Global Time Distribution Network We Have The Time Company (WHTT) are an enterprise who specialise in providing accurate time to global clients across the Internet, via the Network Time Protocol. To provide robust time across they Internet, they provide access to their NTP servers via Functional Anycast addresses. WHTT have a GUA /32 assignment from their Regional Internet Registry. They provide time to clients via the following Global scope Functional Anycast address, with a Global scope, an anycast domain Prefix of 2001:db8::/32, a Prefix Length of 32 (0x20), and the well known NTP Anycast Function Identifier of 0x101. o aa0e:2001:db8:0:0:2000::101 5.7.7. Example3 6. Security Considerations Functional Anycast addresses should not introduce any new security concerns in comparison to the use of addresses from within the unicast address space as anycast addresses. [RFC7094] provides considerable anycast related security discussion and references. The ability to identify a Functional Anycast address using its well known 8 bit prefix, and the inclusion of forwarding scopes in the addresses, provide opportunies to enhance security of anycast services. 7. IANA Considerations IANA are requested to register the aa00::/8 prefix in the Internet Protocol Version 6 Address Space registry for use with Formal Anycast addresses. If aa00::/8 is not chosen, then fa00::/8 is a proposed alternative. IANA are requested to register a new ICMPv6 Destination Unreachble code for Edge of Visible Scope Reached. Smith Expires April 25, 2019 [Page 22]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 IANA are requested to establish a registry for the Flags field of Functional Anycast addresses, and to reserve the T flag to indicate transient Anycast Function Identifiers. IANA are requested to establish a registry for well known Anycast Function Identifiers, and to reserve the values described previously in the "Assigned Anycast Function Identifers" section of this memo. 8. Acknowledgements Review and comments were provided by YOUR NAME HERE! This memo was prepared using the xml2rfc tool. 9. Change Log [RFC Editor please remove] draft-smith-6man-form-func-anycast-addresses-00, initial version, 2017-02-XX 10. Informative References [IANA-IPV6ANYC] "Internet Protocol Version 6 (IPv6) Anycast Addresses", <https://www.iana.org/assignments/ipv6-anycast-addresses/ ipv6-anycast-addresses.xhtml>. [IANA-IPV6MCAST] "IPv6 Multicast Address Space Registry", <https://www.iana.org/assignments/ipv6-multicast- addresses/ipv6-multicast-addresses.xhtml>. [IANA-IPV6RESA] "IPv6 Multicast Address Space Registry", <https://www.iana.org/assignments/ipv6-multicast- addresses/ipv6-multicast-addresses.xhtml>. [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, November 1993, <https://www.rfc-editor.org/info/rfc1546>. [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, DOI 10.17487/RFC2526, March 1999, <https://www.rfc-editor.org/info/rfc2526>. [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, August 2002, <https://www.rfc-editor.org/info/rfc3306>. Smith Expires April 25, 2019 [Page 23]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, DOI 10.17487/RFC3310, September 2002, <https://www.rfc-editor.org/info/rfc3310>. [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <https://www.rfc-editor.org/info/rfc3315>. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>. [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>. [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, <https://www.rfc-editor.org/info/rfc5942>. [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, <https://www.rfc-editor.org/info/rfc7094>. [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, DOI 10.17487/RFC7346, August 2014, <https://www.rfc-editor.org/info/rfc7346>. Smith Expires April 25, 2019 [Page 24]
Internet-DraftIPv6 Formal And Functional Anycast Addresses October 2018 [RFC7723] Kiesel, S. and R. Penno, "Port Control Protocol (PCP) Anycast Addresses", RFC 7723, DOI 10.17487/RFC7723, January 2016, <https://www.rfc-editor.org/info/rfc7723>. [RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays around NAT (TURN) Server Auto Discovery", RFC 8155, DOI 10.17487/RFC8155, April 2017, <https://www.rfc-editor.org/info/rfc8155>. Author's Address Mark Smith PO BOX 521 HEIDELBERG, VIC 3084 AU Email: markzzzsmith@gmail.com Smith Expires April 25, 2019 [Page 25]