idnits 2.17.1 draft-smith-6man-form-func-anycast-addresses-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 250: '...aning the packet MUST be discarded at ...' RFC 2119 keyword, line 253: '...described below, SHOULD be generated a...' RFC 2119 keyword, line 325: '... implementations SHOULD BE updated to ...' RFC 2119 keyword, line 331: '... MUST NOT use SLAAC [RFC4862] to generate an automatic address from...' RFC 2119 keyword, line 360: '...set to off (as this prefix MUST NOT be...' (5 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 3, 2019) is 1637 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NORMNEIL' is mentioned on line 1010, but not defined == Missing Reference: 'REF' is mentioned on line 1179, but not defined == Unused Reference: 'RFC4786' is defined on line 1504, but no explicit reference was found in the text == Unused Reference: 'RFC5505' is defined on line 1526, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Smith 3 Internet-Draft November 3, 2019 4 Updates: RFC4291, RFC4443, RFC6724 (if 5 approved) 6 Intended status: Standards Track 7 Expires: May 6, 2020 9 IPv6 Formal Anycast Addresses and Functional Anycast Addresses 10 draft-smith-6man-form-func-anycast-addresses-01 12 Abstract 14 Currently, IPv6 anycast addresses are chosen from within the existing 15 IPv6 unicast address space, with the addresses nominated as anycast 16 addresses through configuration. An alternative scheme would be to 17 have a special class of addresses for use as anycast addresses. This 18 memo proposes a distinct general anycast addressing class for IPv6, 19 and a more specific scheme for functional anycast addresses. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 6, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Drawbacks of Informal Anycast Addresses . . . . . . . . . . . 4 58 4. Formal Anycast Addresses . . . . . . . . . . . . . . . . . . 5 59 4.1. Address Format . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Address Fields . . . . . . . . . . . . . . . . . . . . . 5 61 4.2.1. Formal Anycast Prefix . . . . . . . . . . . . . . . . 6 62 4.2.2. Visible Scope . . . . . . . . . . . . . . . . . . . . 6 63 4.2.3. Anycast Identifier Format . . . . . . . . . . . . . . 6 64 4.2.4. Anycast Identifier . . . . . . . . . . . . . . . . . 6 65 4.3. Anycast Address Registration Protocol . . . . . . . . . . 6 66 4.4. Network Service Provider Visible Scope . . . . . . . . . 7 67 4.5. Link-Local Visible Scope . . . . . . . . . . . . . . . . 7 68 4.6. ICMPv6 Destination Unreachable Message . . . . . . . . . 8 69 4.7. Default Address Selection . . . . . . . . . . . . . . . . 9 70 4.7.1. Formal Anycast Scope Comparison . . . . . . . . . . . 9 71 4.7.2. Source Address Selection . . . . . . . . . . . . . . 9 72 4.7.3. Destination Address Selection . . . . . . . . . . . . 9 73 4.8. Non-Local Anycast Forwarding . . . . . . . . . . . . . . 10 74 4.9. Advice on Structuring the Anycast Identifier Field Values 11 75 5. Functional Anycast Addresses . . . . . . . . . . . . . . . . 13 76 5.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 13 77 5.2. Address Format . . . . . . . . . . . . . . . . . . . . . 14 78 5.3. Assignment of Anycast Function Identifiers . . . . . . . 16 79 5.4. Assigned Anycast Function Identifiers . . . . . . . . . . 17 80 5.5. Sources of Inspiration for Anycast Function Identifiers . 18 81 5.6. Global Scope Functional Anycast Addresses on the Internet 19 82 5.7. Example Use Cases . . . . . . . . . . . . . . . . . . . . 20 83 5.7.1. Devices Factory Configured with NTP Functional 84 Anycast Addresses . . . . . . . . . . . . . . . . . . 20 85 5.7.2. Branch Office DNS Resolvers . . . . . . . . . . . . . 22 86 5.7.3. Automatic eBGP Session Establishment . . . . . . . . 23 87 5.7.4. An ISP's Anycast DNS Resolvers . . . . . . . . . . . 25 88 5.7.5. Microservices Architecture Applications . . . . . . . 27 89 5.7.6. Global Time Distribution Network . . . . . . . . . . 27 90 5.7.7. Multipath Transport Layer Protocols . . . . . . . . . 27 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 94 9. Change Log [RFC Editor please remove] . . . . . . . . . . . . 30 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 30 97 10.2. Informative References . . . . . . . . . . . . . . . . . 30 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 100 1. Introduction 102 [RFC1546] was the first description of host anycast services, and 103 proposed two ways of supporting them in terms of addressing: 105 o using parts of the existing address space 107 o create a special class of addresses for anycast use 109 The first method of supporting anycast addresses, by using parts of 110 the existing (unicast) address space, could be described as informal. 111 From the address itself, it is not possible to determine that the 112 apparent unicast address is actually being used as an anycast 113 address. 115 As the second method would create a special class of addresses for 116 anycast use, it could be described as formal. Encoded within the 117 addresses would be a well known value that indicates they are anycast 118 addresses, regardless of context. 120 In terms of a spectrum of packet delivery, ranging from delivery to a 121 single destination (unicast), through to delivery to multiple 122 destinations (multicast), anycast addresses are a distinct class of 123 addresses when compared to unicast and multicast addresses. 125 Packets sent to a unicast destination are intended to be delivered to 126 one and only one unique destination host. Packets sent to a 127 multicast destination are intended to be delivered to a group of 128 interested destination hosts, with the interested group consisting of 129 one or more members, and the packets being duplicated by the network 130 when and where necessary. 132 Packets sent to an anycast destination are intended to be delivered 133 to only one host, however that host is a member a set of hosts 134 sharing the same anycast address. As a type of address, anycast 135 addresses can be imagined to fall between unicast and multicast 136 address types on a packet delivery spectrum. Packet delivery to an 137 anycast address shares characteristics of both unicast and multicast 138 address packet delivery. 140 IPv6 anycast addresses [RFC4291] are currently from within the 141 existing unicast address address space. Therefore, this memo gives 142 these IPv6 anycast addresses the name "Informal Anycast" addresses. 144 This memo proposes a distinct and formal class of IPv6 addresses for 145 anycast use, calling them "Formal Anycast" addresses. 147 The described IPv6 Formal Anycast address class can support a total 148 of 16 sub-classes of anycast address formats and structures, allowing 149 other semantics to be encoded in the anycast address. Following the 150 definition of the Formal Anycast address class, this memo then 151 proposes the first sub-class, called "Functional Anycast" addresses. 153 There are some existing reserved and well known anycast addresses 154 within the existing Informal Anycast address space, that have been 155 assigned by IANA [IANA-IPV6ANYC]. While well known, they do not have 156 any of the formal attributes that the proposed formal Functional 157 Anycast addresses have, other than having specified and well known 158 values; they could be described as semi-formal. Well known 159 Functional Anycast addresses are proposed that correspond to these 160 existing semi-formal anycast addresses. 162 "MRS:" comments - points to consider further, to eventually be 163 removed. 165 2. Terminology 167 Anycast Domain 169 Formal Anycast Address 171 Functional Anycast Address 173 Informal Anycast Address 175 Semi-Formal Anycast Address 177 3. Drawbacks of Informal Anycast Addresses 179 There are drawbacks and limitions of the existing IPv6 Informal 180 Anycast addresses: 182 o As mentioned in the Introduction, there is nothing specifically 183 encoded in an Informal Anycast address to distinguish it from a 184 unicast address, such as being from within a well known address 185 prefix. In some situations, this unintentional obfuscation may be 186 of use, however in others, such as while troubleshooting, it can 187 be detrimental. For example, duplicate routes for an address or 188 prefix appearing in a route table with different announcing 189 routers may be a fault if unintentional, meaning it is a duplicate 190 unicast address assignment. Alternatively, it may be the intended 191 configuration if the address or prefix routes are Informal Anycast 192 routes i.e., the address or prefix from within the unicast address 193 space is being used an anycast address or anycast prefix. The 194 duplicate routes and the addresses or prefixes themselves provide 195 no indication of whether the configuration is intentional or not. 197 o Constraining the visibility and reachability of an anycast 198 provided service or function may be useful for security reasons, 199 which can be fundamentally enforced by encoding and limiting the 200 scope of or domain where packets are intended and able to be 201 forwarded. Informal Anycast addresses can only have one of three 202 fundamental forwarding scopes encoded in the address, matching 203 those of the three types of IPv6 unicast addresses - limited to a 204 link scope (Link-Local Address), limited to a local network scope 205 (Unique Local Address) or having global Internet scope (Global 206 Unicast Address) [RFC4291][RFC4193]. These scopes are coarse. 207 More fine grained scopes, such as those used in IPv6 multicast 208 [RFC7346], would provide much more control over anycast service or 209 function visibility. 211 o Some transport layer protocols, such as SCTP [RFC3286] and 212 Multipath TCP [RFC6824], and some applications, deal directly with 213 IPv6 addresses, and supply them to their communications peer or 214 peers. Currently, if these transport layer protocols or 215 applications are dealing with both unicast and anycast addresses, 216 and wish to provide only unicast or anycast types of address or 217 set of addresses to their peer or peers during their 218 communications transactions, it would be necessary to manually 219 configure the transport protocol or application so that it can 220 distinguish between unicast and anycast addresses. A well known 221 address class that identifies anycast addresses would allow these 222 transport layer protocols or applications to identify the 223 different address types without any manual configuration. 225 4. Formal Anycast Addresses 227 4.1. Address Format 229 The following diagram shows the structure of an IPv6 Formal Anycast 230 address. 232 DIAGRAM TO COME 234 4.2. Address Fields 235 4.2.1. Formal Anycast Prefix 237 A 8 bit prefix value of TBD (aa00::/8 preferred, indicating a Anycast 238 Address; fa00::/8 an alternative, indicating a Formal Anycast 239 address), identifying this address as a Formal Anycast address. 241 4.2.2. Visible Scope 243 A 4 bit Visible Scope field used to express and enforce visibility 244 and assumed reachability of the Formal Anycast address. The values 245 and meanings of the values of this field are the same as those for 246 the IPv6 multicast address scope field [RFC4291][RFC7346]. 248 When packets with a Formal Anycast destinaton address are being 249 forwarded, this field's value takes precedence over a non-zero Hop 250 Limit field value, meaning the packet MUST be discarded at the edge 251 of the indicated visibility domain even though it may have a non-zero 252 Hop Limit value. A specific ICMPv6 Destination Unreachable [RFC4443] 253 message, described below, SHOULD be generated and returned to the 254 packet's sender indicating the packet was discarded as it reached the 255 edge of its Visible Scope. 257 4.2.3. Anycast Identifier Format 259 A 4 bit field identifying the format of the following Anycast 260 Identifier field, holding digits in the range of 0x0 through 0xf in 261 hexidecimal. 263 The first assigned value is 0, specifying that the following Anycast 264 Identifier Format is that of a Functional Anycast addresses, which is 265 described later in this memo. 267 Other values will be assigned by IANA as future Anycast Identifier 268 Formats are specified. 270 4.2.4. Anycast Identifier 272 A 112 bit field holding the Anycast Identifier value. The format and 273 structure of this field is encoded in the previous Anycast Identifier 274 Format field. 276 4.3. Anycast Address Registration Protocol 278 Rather than having to manually configure a network's routing protocol 279 to distribute a host's anycast address, or have a host participate in 280 the network's routing protocol, a protocol for hosts to automatically 281 register an anycast address for routing protocol distribution would 282 be beneficial. 284 Development of this protocol is left for a later memo, however as the 285 requirements of such an anycast address registration protocol are 286 very similar to that of hosts' multicast address registration with a 287 network, it is likely that an anycast address registration protocol 288 could be modelled on and derived from the IPv6 Multicast Listener 289 Discovery protocol [RFC2710][RFC3810]. 291 4.4. Network Service Provider Visible Scope 293 A network service provider, such as an Internet Service Provider, may 294 wish to use an anycast address to provide a service with a 295 visibilility limited to all of its direct customers. 297 When using a Formal Anycast address for this service, that reuses 298 IPv6 multicast scopes, this means the address needs to have a scope 299 that is greater than the Organization-Local scope, yet smaller than 300 the unlimited Global scope. 302 This memo defines a new scope called the Network Service Provider 303 (NSP) scope, that falls between the Organization-Local and Global 304 IPv6 multicast scopes. This NSP scope's hexidecimal value is B. 305 This scope can be used with both Formal Anycast and IPv6 multicast 306 addresses. 308 (MRS: perhaps this scope shouldn't be at B, but instead hard up 309 against the Organization-Local scope i.e. at value 9? Could there be 310 a need for any other future scopes between Organization-Local and 311 Network Service Provider - which would be scopes within the Network 312 Service Provider's network.) 314 4.5. Link-Local Visible Scope 316 One of the possible Visible Scope values is the Link-Local scope, 317 specifying that the Formal Anycast address's visibility is limited to 318 a link that the host is directly attached to. 320 Nodes on the link will need to consider Formal Anycast addresses with 321 a Link-Local Visible Scope on-link, so that they perform Neighbor 322 Discovery [RFC4861] for these addresses. 324 Similar to the unicast Link-Local prefix [RFC5942], IPv6 325 implementations SHOULD BE updated to consider the Formal Anycast 326 prefix with a Link-Local Visible Scope on-link. Using the 327 (preferred, IANA TBA) aa00::/8 Formal Anycast prefix, this means IPv6 328 implementations will consider aa20::/12 to be on-link. 330 Unlike the unicast Link-Local prefix, updated IPv6 implementations 331 MUST NOT use SLAAC [RFC4862] to generate an automatic address from 332 within this Formal Anycast Link-Local Visible Scope prefix. 334 (MRS: Need to further consider this constraint, and more generally 335 the idea of host automatically generated dynamic anycast addresses, 336 rather than either having well known or system administrator chosen 337 and configured anycast addresses. If there is an anycast address 338 registration protocol that hosts can use (suggested above), then 339 hosts could possibly dynamically generate anycast addresses and then 340 register them.) 342 Note that unlike the unicast Link-Local prefix, IPv6 nodes may not 343 and typically would not have an address from within the Formal 344 Anycast Link-Local Visible Scope prefix. One of the node's Link- 345 Local addresses on the same link should be used as a source address 346 when sending to a Formal Anycast Link-Local Visible Scope 347 destination. This does not preclude using other greater scope 348 unicast source addresses. 350 In the interrim IPv6 implementation update period, IPv6 nodes can be 351 informed that the Formal Anycast Link-Local Visible Scope prefix is 352 on-link in one of two ways: 354 o A manually configured entry in the host's Prefix List [RFC4861]. 356 o A dynamic update to nodes' Prefix Lists using a Router 357 Advertisement Prefix Information Option (PIO) [RFC4861]for the 358 Formal Anycast Link-Local Visible Scope prefix of aa20::/12, with 359 the 'L' or on-link flag set to on, and the 'A' or autonomous 360 address-configuration flag set to off (as this prefix MUST NOT be 361 used by the node to automatically generate an address for its use 362 within this prefix). The Valid and Preferred Lifetimes for the 363 Formal Anycast Link-Local Visible Scope prefix in the PIO are set 364 to infinity. 366 4.6. ICMPv6 Destination Unreachable Message 368 As mentioned prevously, if a packet with a Formal Anycast destination 369 address reaches the edge of the Visible Scope for the address, a 370 ICMPv6 Destination Unreachable [RFC4443] message SHOULD be generated 371 and sent back to trigger packet's sender. 373 Note that if the router at the edge of the visibility domain is also 374 assigned the Formal Anycast address, the packet is host processed 375 locally rather than being discarded, and an ICMPv6 Destination 376 Unreachable message IS NOT generated. 378 When a router implementation formally supports Formal Anycast 379 addresses, the ICMPv6 Code for the Destination Unreachble message is 380 IANA-TBD, indicating that the Edge of the Visible Scope [was] 381 Reached. 383 If a router implementation does not formally support Formal Anycast 384 addresses an operator should use packet filters to enforce the 385 Visible Scope boundary. A packet failing to pass the packet filter 386 should cause the router to generate a Destination Unreachable 387 Communication with destination administratively prohibited message 388 [RFC4443] (Code 1) message, which is semantically similar to the 389 formal Edge of Visibile Scope Reached message. 391 Note that ICMPv6 messages are not sent reliably, so Formal Anycast 392 packet senders will need to be able to handle not receiving a ICMPv6 393 Destination Unreachable message in response to a packet reaching the 394 edge of the visibility domain. 396 There may be situations where silently discarding Formal Anycast 397 packets at the Visible Scope boundary may be preferred. In this 398 case, a packet discard route, covering the Visible Scope prefix can 399 be installed in a router's forwarding table, saving router control 400 plane resources. 402 4.7. Default Address Selection 404 4.7.1. Formal Anycast Scope Comparison 406 As the Formal Anycast address scopes are defined to be the same as 407 Multicast address scopes, the same Multicast scope comparison 408 methods, described in [RFC6724], are also used with Formal Anycast 409 address scopes. 411 4.7.2. Source Address Selection 413 As mentioned in Appendix B. of [RFC6724], anycast addresses are 414 candidates during source address selection. 416 4.7.3. Destination Address Selection 418 An IPv6 implementation may be presented with a candidate set of 419 destination addresses that consists of both Formal Anycast and 420 unicast addresses. The implementation needs to make a choice or 421 choices as to which of these candidate addresses to attempt to use. 423 The decision to use a Formal Anycast address instead of a unicast 424 address by the destination is an active and conscious one. 425 Therefore, when a choice needs to be made between a Formal Anycast 426 address and a unicast address, the Formal Anycast address should be 427 preferred. 429 In terms of the Destinaton Address Selection algorithm described in 430 [RFC6724], this preference of Formal Anycast over unicast addresses 431 introduces a new rule between Rule 1 ("Avoid unusable destinations") 432 and Rule 2 ("Prefer matching scope"), specifically (using "1.5" here 433 to indicate the position): 435 Rule 1.5: Prefer Formal Anycast addresses. 437 If DA is a unicast address, and DB is a Formal Anycast address, 438 then prefer DB. 440 Note that there may be instances where an application would prefer to 441 use a unicast address over a Formal Anycast address. In this case, 442 Formal Anycast addresses can be easily identified and ignored using 443 the well known 8 bit Formal Anycast prefix. 445 4.8. Non-Local Anycast Forwarding 447 (MRS:This section is being left here for the moment, however this 448 idea should probaby be moved to a different memo, as it is describing 449 forwarding that isn't unicast forwarding (unicast forwarding is used 450 by conventional anycast)) 452 One possible use for Formal Anycast addresses is to represent a 453 function that is performed on the packet by the network that is 454 beyond conventional destination address based unicast IPv6 455 forwarding, as the packet traverses the path towards its final 456 delivery point. 458 Currently, hop-by-hop processing of an IPv6 packet as it traverses 459 the network is indicated using the Hop-by-Hop Options (Extension) 460 Header [RFC8200]. 462 Drawbacks of using the Hop-by-Hop Option Header are that some high 463 speed routers ignore them [RFC7045], and that packets with the Hop- 464 by-Hop Options Header may be dropped by transit Autonomous System 465 (AS) networks [RFC7872]. The dropping of these types of packets by 466 transit ASes may be due to a default deny policy for Extention Header 467 types other than those of TCP, UDP, ICMPv6 and possibly IPsec ESP. 469 Encoding the intent of hop-by-hop processing of a packet as an 470 anycast IPv6 destination address has the advantage of the packet 471 always being processed by all router implementations, including high 472 speed implementations, as processing a packet's IPv6 destination 473 address is required to perform IPv6 destination address based 474 forwarding. As there is no explicit Hop-by-Hop Options Header in the 475 packet, a transit AS is less likely to drop the packet, unless it 476 explicitly implements IPv6 Destination Address packet filters that 477 drop packets with Formal Anycast addresses. 479 Another advantage is that there may now be no need for the addition 480 of an Extension Header to the IPv6 packet for hop-by-hop processing, 481 increasing the packet's effective payload size. 483 Conventional unicast IPv6 forwarding based on destination address 484 prioritises a node's local addresses over all others. This means 485 that when a node originates a packet with one its own addresses as 486 the destination, the node will deliver the packet internally for 487 local processing, rather than sending it out one of the node's 488 network interfaces. 490 The functional requirements for Non-Local Anycast Forwarding are: 492 o When being sent by the node, the packet is not delivered 493 internally to the node's own instance of the Formal Anycast 494 address. 496 o After being submitted to the network for forwarding, the packet 497 must not be sent back towards its source, as this would 498 potentially cause the packet to follow a loop in its forwarding 499 path. 501 4.9. Advice on Structuring the Anycast Identifier Field Values 503 The Anycast Identifier Format field within a Formal Anycast address 504 specifies the format and structure of the 112 bit Anycast Identifier 505 field. The following is advice and guidelines to use when developing 506 a new Anycast Identifier field format and structure. 508 Forwarding towards anycast addresses is the same as forwarding 509 towards unicast addresses, which uses the longest match rule BCP 198 510 [RFC7608]. Longest match forwarding facilitates summarisation of 511 forwarding information, where a single more general forwarding route 512 can summarise a number of more specific forwarding routes. 513 Summarisation saves entries in forwarding tables outside of the 514 summarised forwarding domain, provides simpler destination based 515 filtering for security purposes, and facilitates easier destination 516 address based traffic analysis. 518 The use of route summarisation with anycast addresses effectively 519 creates an anycast domain that is being identified and summarised by 520 the anycast summary route. Outside of the anycast domain, a single 521 summary route exists, covering all anycast addresses within the 522 domain. Within the anycast domain, individual routes for individual 523 anycast addresses exist. 525 When designing a new Anycast Identifier field format and structure, 526 the following guidelines should be followed. These guidelines should 527 allow a set of more specific anycast routes to be summarised as well 528 as improving operator usability. 530 o The order of fields within the Anycast Identifier field should be 531 from the most general to most specific, in the direction following 532 the high order to low order bits of the Anycast Identifier field 533 and the broader IPv6 address. 535 o The order of bits within fields should also be from the most 536 general to most specific, matching the direction of high order to 537 low order of bits within the Anycast Identifier field. 539 o The bits in fields holding bits that are matched exactly, such as 540 flag fields or fields holding numeric values that are matched 541 exactly, can be orded to suit the field's use and application. 542 However, a hierarchial order, from most significant to least 543 significant bit, following Anycast Identifier field bit order, is 544 suggested. Although initially defined hierarchially, the order of 545 flags in flag fields may later deviate from this recommendation 546 due to later flag bit definition. 548 o End-users of the functions and services being provided using 549 Formal Anycast addresses are unlikely and ideally should never see 550 these addresses. However, operators of these functions and 551 services will deal with these addresses during planning, 552 configuration and troubleshooting. Where possible, fields and 553 their values should be ordered and structured to assist with these 554 tasks. Field boundaries within the Anycast Identifier field 555 should align with 16 bit word, 8 bit octet or 4 bit nibble 556 positions within the whole IPv6 address. For example, if part of 557 an IPv6 prefix is included in the Anycast Identifier, it should 558 start at a 16 bit "piece" boundary, where colons appear [RFC4291], 559 within the IPv6 address. Note that this guildeline should not 560 take precedence over any previous measures to faciliate more 561 specific anycast route summarisation. 563 o A further address usability recommendation is to set field and bit 564 values to zero for the likely most common or likely most secure 565 meaning for these fields or bit values. In IPv6 addresses zero 566 field values can be compressed [RFC5952], resulting in a shorter 567 address for an operator to type. A shorter address to enter 568 naturally reduces the opportunities for and likelihood of errors 569 in the address, and reduces the possibilities of security issues 570 caused by errors in the Formal Anycast address. 572 5. Functional Anycast Addresses 574 The first defined sub-class or sub-format of Formal Anycast addresses 575 is the Functional Anycast address sub-class. 577 5.1. Features 579 The following are the features of Functional Anycast addresses. In 580 many cases they're inspired by and mirror IPv6 multicast address 581 features [RFC4291][RFC3306]. 583 o Provides separate globally well known and local network defined 584 anycast function or service identifier spaces. Globally well 585 known identifiers can be encoded in applications during their 586 development as constants, avoiding the need for them to be 587 specified and configured during deployment of the application. 589 o Provides a minimum of 24 bits for use as identifiers for anycast 590 functions or services, supporting more than 16 million values. 592 o Provides 8 bits for the identification of up to 256 local 593 instances, versions or revisions of the same function or service, 594 assisting with function or service deployment or maintenance. 595 These 8 bits can also be used to increase the size of the function 596 or service identifier space to 32 bits where useful, increasing 597 the range of values to more than 4 billion. 599 o Identifies an anycast function or service identifier space, known 600 as an anycast domain, using an IPv6 unicast address prefix of up 601 to 64 bits in length. 603 A network can create multiple distinct anycast domains by using 604 multiple of its IPv6 prefixes, from its Global [RFC4291] or Unique 605 Local [RFC4193] address spaces (the Link-Local prefix could be 606 used to create a distinct anycast domain, however it can only be 607 used once, despite the network having many instances of the Link- 608 Local prefix (as many as it has links)). 610 A "unspecified" anycast domain is supported using an all zeros 64 611 bit IPv6 prefix. 613 External to the anycast domain, the identifying 64 bit prefix can 614 be used to create a single summary route for the anycast function 615 or service identifier space, which will help routing scaling for 616 anycast functions or services. The anycast domain boundary could 617 also correspond to routing protocol scaling boundaries, such as 618 OSPFv3 areas [RFC5340] or IS-IS level [RFC5308] boundaries, when 619 useful. 621 5.2. Address Format 623 The format of Functional Anycast addresses is modelled on the IPv6 624 multicast address format [RFC4291]. 626 The format of an Functional Anycast address is as follows: 628 DIAGRAM TO COME 630 The address fields are as follows: 632 o Anycast Domain Prefix - a 64 bit field holding a IPv6 unicast 633 address prefix identifying the anycast domain that is either the 634 provider and possible authority for the following Anycast Function 635 Identifier space. 637 The length of the prefix is specified in the following Prefix- 638 Length field, with the remaining bits of the field set to zero. 640 An all zero Anycast Domain Prefix means an unspecified Anycast 641 Function Identifier provider. An all zeros Prefix in effect means 642 "this" provider, with "this" meaning the current anycast domain. 644 Link-Local, Unique-Local [RFC4193], Global and possible future 645 other unicast prefixes [RFC4291] identify a specific Anycast 646 Function Identifier provider (MRS: Need to think about more about 647 using Link-Local prefix, as it really isn't specific - perhaps 648 either prohibit, or make it all zeros "current" equivalent). 649 Within an anycast function domain, this allows multiple anycast 650 function sub-domains to be created, identified by different 651 unicast prefixes in this field. 653 o Reserved - a 2 bit reserved field. 655 Set to zero upon transmission, ignored upon receipt. 657 o Prefix-Length - An 6 bit field specifying the length of the 658 previous Anycast Domain Prefix. 660 A value of zero means a 64 bit length prefix, while prefix lengths 661 of 1 through 63 (0x01 through 0x3f) are encoded natively. 663 The unspecified Anycast Domain Prefix of all zeros is considered 664 to be 64 bits in length, meaning a Prefix-Length value of 0 for 665 this prefix. 667 This is an informational field to assist with operation and 668 troubleshooting. 670 (MRS: This field is inspired by the equivlent field when IPv6 671 multicast addresses contain a unicast prefix per [RFC3306]. I'm 672 not entirely sure it is necessary, as we don't embed prefix length 673 in unicast addresses, and unicast routing protocols, also used for 674 anycast, carry prefix length information separately.) 676 o Flags - A 8 bit flag field. 678 The lower 7 flags are reserved and must be set to zero upon 679 transmission, and ignored upon receipt. 681 The high order flag is the 'T' or Transient flag. T=0 indicates 682 that the later Anycast Function Identifier is well known and 683 assigned by the Internet Assigned Numbers Authority (IANA). T=1 684 indicates that the Anycast Function Identifier is transient or 685 dyamically assigned, and has been assigned by the Functonal 686 Anycast domain's local authority. 688 (MRS: is there a way to avoid this flag field? Some of the flags 689 that are used in IPv6 multicast addresses could instead be 690 accomodated by defining an entirely new 112 bit Anycast Identifier 691 Format. Avoiding this field and the Prefix-Length field frees up 692 16 bits which makes this Anycast Identifier Format simpler and 693 would provide 16 more bits for the following fields, which may be 694 useful.) 696 o Local Instance - An 8 bit field holding a identifier of the 697 instance, version or revision of the function identified by the 698 following Anycast Function Identifier field, local to the current 699 anycast domain. 701 The default value of this field is zero, indicating the default 702 and first instance of the anycast function. 704 Non-default values are chosen by the local anycast domain 705 operator, even when the following Anycast Function Identifier is 706 using a well-known IANA Anycast Function Identifier value. 708 An anycast domain operator may chose to assign other semantics to 709 this field, as long as they're both less significant than the 710 previous fields and more sigificant than the following Anycast 711 Function Identifier field. 713 When the 'T' bit in the Flags field is set to 1, meaning transient 714 Anycast Function Identifiers, this field could be used to 715 effectively increase the size of the following Anycast Function 716 Identifier field to 32 bits, increasing the value range of Anycast 717 Function Identifiers from in the order of 16 million to in the 718 order of 4 billion. 720 o Anycast Function Identifier - A 24 bit field identifying the 721 anycast function to be performed on the packet when it arrives at 722 a host that has been configured with the Functional Anycast 723 address. 725 When the 'T' bit in the Flags field is set to zero, the Anycast 726 Function Identifiers values are from a well known Anycast Function 727 Identifier registry maintained by IANA, with initial entries 728 specified later in this memo. 730 When the 'T'bit in the Flags field is set to 1, the values in the 731 Anycast Function Identifier field are local to and assigned by the 732 authority identified in the Prefix field in any manner that suits 733 their purposes and requirements. 735 5.3. Assignment of Anycast Function Identifiers 737 In the history of the Internet, it has been common to conflate a 738 function or service with a protocol. 740 For example, historically, the TELNET protocol [RFC0854] had been the 741 most popular "Network Virtual Terminal" protocol. In more recent 742 times, the SSH protocol [RFC4252] has become the de facto network 743 virtual terminal protocol. Accessing the network virtual terminal 744 service has either been referred to as "TELNETting in" or "SSHing in" 745 to the host providing the service, using the protocol being used to 746 refer to the service being accessed. 748 In either case, TELNET and SSH protocols are being used to access a 749 remote network virtual terminal service. Functionally, from the 750 perspective of network virtual terminal access, the differences are 751 relatively minor; data security and integrity via encryption and 752 authentication is where the primary differences between TELNET and 753 SSH are - in TELNET authentication [RFC2941] and encryption [RFC2946] 754 of the data stream is optional, where as with SSH it is mandatory. 756 When both IANA and local anycast domain operators assign Anycast 757 Function Identifiers, it is recommended that they're allocated and 758 identified by protocol agnostic function or service type rather than 759 to a specific protocol that provides that function or service. As 760 the particular protocol being used to access the function or service 761 will be encoded in the upper transport layer protocols and ports in 762 the IPv6 packet, service or function based Anycast Function 763 Identifers can support and stay constant across the use and evolution 764 of different function or service access protocols. 766 For example, with a well-known Anycast Function Identifier 767 specifically allocated to a Network Virtual Terminal (NVT) [RFC0318] 768 service, the hosts providing the NVT service could initially support 769 both TELNET (assuming TELNET is considered secure enough) and SSH. 770 If both TELNET and SSH become deprecated, and a new NVT access 771 protocol is developed, the same Anycast Function Identifier for the 772 NVT service could be used to reach a node supporting this new access 773 protocol. 775 Another example is the domain name service. Currently domain name 776 resolution commonly takes place using the Domain Name Service 777 protocol [RFC1035], carried directly over UDP and TCP, using port 53. 778 More recently, work has been taking place to operate DNS over TLS 779 [RFC7858] and HTTPS [RFC8484] to enhance the security of the domain 780 name resolution function. The use of multiple protocols to access 781 fundamentally the same domain name resolution function suggests a 782 protocol agnostic domain name resolution Anycast Function Identifier. 784 This doesn't preclude Anycast Function Identifiers being used to 785 support and identify specific protocols (examples of this occur 786 later). There may be current and future cases where the allocation 787 and use of an Anycast Function Identifier for a specific protocol is 788 the better choice. This should be considered and evaluated on a case 789 by case basis. 791 5.4. Assigned Anycast Function Identifiers 793 A number of past RFCs have reserved anycast addresses and 794 identifiers. These addresses and indentifiers are mapped to the 795 following corresponding and well known Anycast Function Identifiers, 796 and are to be listed in the IANA Anycast Function Address Identifier 797 registery if it is created. 799 [RFC2526] reserves the highest 127 values of a subnet prefix 800 Interface Identifier for anycast addresses. The equivalent values 801 for Functional Anycast addresses are the highest 127 values of the 32 802 bit Anycast Function Identifier, a range of (in IPv6 address format, 803 excluding the high order 96 bits) :ffff:fff8 through :ffff:ffff. The 804 IANA Internet Protocol Version 6 (IPv6) Anycast Addresses registry 805 [IANA-IPV6ANYC] records assignments for subnet prefix anycast 806 addresses within the Interface Identifier space. The current and 807 future values of these anycast subnet prefix Interface Identifier 808 values are to also be recorded in the Anycast Function Address 809 Identifier registry. 811 [RFC4291] reserves an Interface Identifer of all zeros within a 812 unicast prefix as the Subnet-Router anycast address. The equivalent 813 32 bit Anycast Function Identifier value for Functional Anycast 814 addresses is also all-zeros. 816 [RFC7723] reserves the IPv6 address 2001:1::1/128 for the use as the 817 Port Control Protocol Anycast address. The equivalent 32 bit Anycast 818 Function Identifier value is (in IPv6 address format, excluding the 819 high order 96 bits) :0001:0001. 821 [RFC8155] reserves the IPv6 address 2001:1::2/128 for the use as the 822 Traversal Using Relays around NAT Anycast address. The equivalent 32 823 bit Anycast Function Identifier value is (in IPv6 address format, 824 excluding the high order 96 bits) :0001:0002. 826 5.5. Sources of Inspiration for Anycast Function Identifiers 828 A future possible source of inspiraton for well known assigned 829 Anycast Function Identifiers could be DHCPv6 [RFC8415] options that 830 encode IPv6 addresses for services. 832 A number of these options encode multiple IPv6 addresses as 833 candidates for access to the service (for example, the SIP Servers 834 IPv6 Address List option [RFC3310]). The use of anycast for service 835 resiliance would allow a single Anycast Function Identifier value to 836 provide equivalent service, although this wouldn't preclude defining 837 multiple different Anycast Function Identifiers to the service to 838 provide the service client concurrent access to multiple service 839 instances. For example, 3 Functional Anycast addresses could be 840 allocated for DNS resolvers, providing a client with seperately 841 verifiable DNS resolver services from up to 3 different resolvers, 842 and allowing the client to distribute requests across all 3 843 resolvers. 845 Another source of inspiration for well known assigned Anycast 846 Function Identifiers could be the IANA IPv6 Multicast Address Space 847 [IANA-IPV6MCAST] registry, where some of the multicast addresses 848 represent services that could also be useful when provided via 849 anycast. 851 While using these possible source of inspiration, the recommendation 852 to choose protocol agnostic function or service identifiers still 853 stands. DHCPv6 or multicast groups can be used to inspire more 854 generic function or service identifiers. 856 5.6. Global Scope Functional Anycast Addresses on the Internet 858 (MRS: Need to fully review this idea and section. An idea to help 859 overcome the /48 prefix length constraint would be to have all Formal 860 Anycast addresses that are going to be used on the Internet come from 861 an IANA reserved prefix within the existing GUA address space e.g. 862 20e0::/12 (i.e. operators would accept a prefix announcement of 863 length of up to /80 within 20e0::/12). aa::/8 would still be used for 864 smaller than global scope anycast, because a prefix of "aa" is very 865 helpful to identify anycast addresses.) 867 Functonal Anycast addresses could be used to provide anycast services 868 across the Internet, by using the the Global scope. 870 When being used on the Internet, many of the possible values of the 871 Prefix field are ambiguous, meaning that they wouldn't unambiguously 872 identify the party using the Functional Anycast address to provide 873 the service or function. Examples of ambiguous prefixes are the all- 874 zeros unspecified prefix, any ULA [RFC4193] prefixes, and the Link- 875 Local [RFC4291] prefix. Other ambiguous prefixes are those in the 876 IPv6 reserved address registry [IANA-IPV6RESA] that are not valid on 877 the Internet. 879 To overcome this ambiguity, if Global scope Functional Addresses are 880 used over the Internet, the Prefix field MUST be set to a GUA 881 [RFC4291] prefix value assigned to the party providing the anycast 882 service to Internet clients. A network either accepting or 883 originating a Global scope Functional Address prefix for announcement 884 from a downstream stub autonomous system for announcement onto the 885 Internet MUST only accept or originate a route announcement for a 886 Global scope Functional Anycast prefix that includes an explicitly 887 identified GUA prefix. All other Global scope Functional Anycast 888 prefix announcements with ambiguous or non-explicitly identified GUA 889 prefixes MUST be ignored. 891 As forwarding towards anycast addresses is functionally the same as 892 forwarding towards unicast addresses, Functional Anycast prefixes 893 would be announced into the Internet's unicast forwarding route 894 table. These Functional Anycast prefixes SHOULD BE aggregate 895 announcements with the aggregation boundary occurring directly after 896 the Anycast Domain Prefix. 898 It is common practice today to limit the prefix length of unicast 899 IPv6 Internet routes accepted to a length of no more than 48 bits 900 i.e. a /48. This is a blunt and simple way to attempt to somewhat 901 limit the number of IPv6 routes in the Internet route table. It is 902 imposing this limit by enforcing a minimal level of aggregation at 903 the /48 boundary. Networks using prefix lengths longer than /48 are 904 expected to aggregate those networks into a route advertisement that 905 is /48 or shorter. 907 This practice of limiting advertised unicast route prefix lengths to 908 48 bits will limit the size of the Prefix included in Global scope 909 Functional Anycast announcements to 32 bits, as the high order 16 910 bits of the Functional Anycast prefix are used to encode the 911 Functional Address type prefix and address scope. This would limit 912 the use of Global scope Functional Anycast addresses to provide 913 global Internet anycast services to those organisations who have a 914 /32 or shorter assignment from an RIR. 916 As Functional Anycast addresses are a separate class of addresses, 917 and are all identified by a unique /8 prefix, this /48 prefix length 918 limit could be specifically relaxed for Functional Anycast routes. A 919 /48 prefix, when included in a Functional Anycast, results in a 920 Functional Anycast prefix length of /64. Imposing a /64 prefix 921 length limit on Functional Anycast routes, identified by a high order 922 prefix of aae0::/16, and a GUA anycast domain prefix, would achieve 923 the same outcome of attempting to reducing the number of entries in 924 the IPv6 Internet route table. 926 Wide acceptance of Functional Anycast prefixes of up to 64 bits in 927 length on the Internet may take same time to occur. Use of Global 928 scope Functional Anycast addresses by organisations who have RIR /32 929 assignments, which will be accepted by unicast /48 prefix filters 930 present today, would raise awareness of Functional Anycast addresses. 931 This increased awareness could be leveraged to motivate the changing 932 of prefix filters to accept Global scope Functional Anycast prefixes 933 up to 64 bits in length. 935 5.7. Example Use Cases 937 This section provides some example use cases of Functional Anycast 938 addresses that would suit the described scenarios. 940 5.7.1. Devices Factory Configured with NTP Functional Anycast Addresses 942 Assume IANA has allocated a set of well-known Anycast Function 943 Identifier values of 0x004440, 0x004441, 0x004442 and 0x004443 for 944 use with the Network Time Protocol [RFC5905], to facilitate meeting 945 the NTP best practice of having a minimum of 4 NTP time sources 946 [RFC8633]. 948 A device manufacturer uses this set of well-known Anycast Function 949 Identifier to set factory default Functional Anycast addresses for 950 access to a device customer's NTP servers. 952 The corresponding Functional Anycast address is constructed as 953 follows: 955 o 8 bit Formal Anycast Prefix value (0xaa proposed). 957 o 4 bit Visible Scope value of 0x8, corresponding to Organization- 958 Local [RFC7346], as the manufacturer is unlikely to have any 959 knowledge of device customers' use of or preference for smaller 960 scopes. 962 o 4 bit Anycast Identifier Format value of 0x0, corresponding to the 963 Functional Anycast format. 965 o 112 bit Anycast Identifier in the Functional Anycast format: 967 o 969 * 64 bit Anycast Domain Prefix value of the all zeros unspecified 970 prefix. 972 * 2 bit reserved field set to zero. 974 * 6 bit Prefix-Length field set to zero, meaning a 64 bit length 975 Anycast Domain Prefix value. 977 * 8 bit Flags field set to all zeros. The upper 7 bits are zero 978 as they're served, while the lowest 'T' or Transcient flag is 979 set to zero indicating an IANA assigned well known Anycast 980 Function Identifier. 982 * 8 bit Local Instance flag set to the default value of zero. 984 * 24 bit Anycast Function Identifier field set to either 985 0x004440, 0x004441, 0x00442 or 0x004443; one of the IANA 986 assigned well known Anycast Function Identifier values for the 987 NTP protocol. 989 All of the above mean that the NTP server Functional Anycast 990 addresses the device manufacturer sets as the defaults would be (in 991 IPv6 address compressed format): 993 o aa80::4440 995 o aa80::4441 996 o aa80::4442 998 o aa80::4443 1000 5.7.2. Branch Office DNS Resolvers 1002 An enterprise network operator decides to use Functional Anycast 1003 addresses to provide DNS resolver service to end-user devices, 1004 located in various corporate offices. 1006 Specifically for a single mid-sized branch office, with in the order 1007 of 200 staff, the operator decides to provide two DNS resolvers 1008 located in the office. This will provide lower latency DNS 1009 resolution through DNS caching, reducing perceiveable application 1010 response time [NORMNEIL]. Access to a third, geographically close, 1011 off-site DNS resolver is provided for redundancy. This off-site DNS 1012 resolver will be one of the other branch office's local DNS 1013 resolvers. 1015 All three DNS resolvers will provide their services to clients via 1016 Functional Anycast addresses. Different clients will receive the on- 1017 site DNS resolver addresses in alternating order, both before the 1018 off-site DNS resolver address. This provides rudimentry on-site DNS 1019 resolver load balancing and keeps both DNS resolvers' lookup caches 1020 populated to reduce the client visible performance impact of the 1021 fail-over to the remaining on-site DNS resolver, should its sibling 1022 fail. The on-site DNS resolvers will watch each others' 1023 availablility, taking over its sibling's Functional Anycast address 1024 if the sibling becomes unavailable. Should both on-site DNS 1025 resolvers become unavailable, clients will resort to using the 1026 remaining off-site DNS resolver. 1028 Assume IANA have allocated the well known Anycast Function Identifier 1029 values of 5300, 5301 and 5302 for use with anycast DNS resolvers. 1031 The operator allocates decimal identifiers of 703, 9556, 4739, 38809 1032 and 2764 to the corporate offices, with the order reflecting 1033 geographic proximity. Each office will have its own unicast /48 from 1034 within a globally unique address space of 2001:db8::/32, meaning that 1035 the office prefixes are 2001:db8:2bf::/48, 2001:db8:2554::/48, 1036 2001:db8:9779::/48 and 2001:db8:acc::/48. 1038 The corresponding Functional Anycast address is constructed as 1039 follows: 1041 o 1042 The Visibiliity Scope for for these DNS resolvers' Functional Anycast 1043 addresses will be Organization-Local (8). 1045 For office 9556, using offic 4739 as an off-site backup, the 1046 Functional Anycast addresses for the three DNS resolvers will be: 1048 1. aa80:2001:db8:2554::5301 1050 2. aa80:2001:db8:2554::5302 1052 3. aa80:2001:db8:9779::5303 1054 5.7.3. Automatic eBGP Session Establishment 1056 Assume IANA has allocated a well-known Anycast Function Identifier 1057 value of 0x000179 for use with automatic eBGP [RFC4271] session 1058 establishement. 1060 Smaller, stub site routers are preconfigured with a Functional 1061 Anycast address to attempt to automatically establish an eBGP session 1062 with a one or two upstream eBGP peer aggregation routers over one or 1063 two different designated ("WAN") links upon initialisation. 1065 The eBGP Functional Anycast address would be a Link-Local Visible 1066 scope address. The stub router would use its link's, SLAAC generated 1067 [RFC4861] and link unique Link-Local address [RFC4291] as the source 1068 address to reach the eBGP Functional Anycast address. Using Link- 1069 Local scope Formal Anycast and unicast addresses for this eBGP 1070 session would provide a basic level of eBGP access security. 1072 The stub site router will need to also be preconfigured or somehow 1073 automatically generate an Autonomous System Number (ASN) to use for 1074 establishing the eBGP session or sessions. How the ASN is 1075 preconfigured or generated is out of scope for this memo, and is left 1076 to future work. 1078 Once the eBGP session is established, the peer eBGP routers trade 1079 routes. These traded routes could include the upstream eBGP 1080 providing a default route or other more specific routes, and the 1081 downstream stub site router providing a route to its downstream 1082 prefix or prefixes. 1084 The downstream prefix or prefixes could be those the stub site router 1085 has learned via DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633]. An 1086 advantage of having the stub site router inject DHCPv6-PD prefixes 1087 into the BGP routing domain is that the route information for this or 1088 these prefixes within the BGP routing domain would more accurately 1089 reflect the state and therefore the availability of the prefixes at 1090 the site they've been assigned and are being used it. Stub site 1091 routers announcing their own prefixes would also distribute the 1092 announcement processing load across the stub site routers rather than 1093 concentrating it at the upstream aggregation router(s). This also 1094 avoids the upstream aggregation router having to process the 1095 DHCPv6-PD response to determine the assigned delegated prefix for 1096 subsequent BGP announcement [RFC3633], meaning it can act as a much 1097 simpler and pure DHCPv6 relay [RFC8415]. 1099 The upstream link(s) that a stub site is attached to does not have to 1100 be limitied to being a true link-layer point-to-point link, meaning 1101 that the link only supports a single router pair of a stub and 1102 upstream aggregation router. The link could be a multi-access link, 1103 with the single link supporting many stub site routers and a number 1104 of upstream aggregation routers. 1106 As the eBGP Functional Anycast address is a Link-Local Visible Scope 1107 address, the address is configured as an anycast address on the 1108 upstream aggregation routers' stub site facing network interface. 1109 This results in the receiver of the Neighbor Advertisements for this 1110 address using the information received in the first received Neighbor 1111 Advertisement to update its neighbor cache, rather than the last and 1112 most recently received Neighbor Advertisement. These types of 1113 Neighbor Advertisements are known as "Anycast Neighbor 1114 Advertisements" in [RFC4861]. 1116 [RFC4861] says that Anycast Neighbor Advertisements should be delayed 1117 a random amount of time between 0 and MAX_ANYCAST_DELAY_TIME, a 1118 variable with a default value of 1 second. This random delay is to 1119 reduce the probability of loss of the Neighbor Advertisement due to 1120 network congestion. 1122 Specific to this eBGP use case, the Anycast Neighbor Advertisements 1123 delay could include other metrics in the calculation to more 1124 intelligently distribute the eBGP sessions across the set of upstream 1125 aggregation routers. For example, the number of existing eBGP 1126 sessions could be a metric, where an upstream aggregation router 1127 delays its Anycast Neighbor Advertisement longer when it has more 1128 established eBGP sessions. 1130 An operator set router preference metric could be considered, 1131 allowing the operator to more gracefully phase out a legacy upstream 1132 aggregation router by setting it preference lower than the newer 1133 upstream aggregation routers. The operator would then manually 1134 terminate the eBGP sessions individually on the legacy upstream 1135 aggregation router, at a rate of something like one ever 3 seconds, 1136 causing them to be restablished on the higher preference and newer 1137 upstream aggregation routers. This would be more graceful than 1138 terminating all eBGP sessions at once on the legacy upstream 1139 aggregation router by, for example, switching it off. 1141 Branch office stub router, automatically attempts to establish a BGP 1142 session with a well-known functional anycast address "out of the box" 1143 over the default WAN interface. 1145 IANA assigned well-known BGP Anycast Function Identifier 1147 Link-local scope Functional Anycast address. Provides a minimum 1148 level of security, as only possible to establish BGP sessions between 1149 direct link peers. 1151 Use unspecified prefix (comment that fe80::/64 could be used, 1152 although unnecessary) 1154 Well-known AS Number used by all stub routers. This makes the BGP 1155 sessions eBGP sessions. Routers will reject routes from other stub 1156 routers using the same ASN, however this is both fine and ideal as 1157 this is a stub router - default only plus announcing its local 1158 prefix(es). 1160 Sub router acquires a delegated prefix via DHCPv6-PD 1162 The delegated prefix is announced via the BGP session. Stops the 1163 upstream aggregation router needing to observe a DHCPv6 server's 1164 relayed response to then announce the delegated prefix into the 1165 network. 1167 Upstrem router accepts and establishes BGP sessions with any link- 1168 local address from the well known ASN, to the Functional Anycast BGP 1169 address. 1171 There are potential trust issues here. BGPsec? Use the first BGP 1172 session to bootstrap connectivity to then establish a more trusted 1173 connection of some sort via PKI. Requirement for being link-local 1174 peers adds a minimal level of security and trust, but not much. 1176 5.7.4. An ISP's Anycast DNS Resolvers 1178 ISPs' IPv4 DNS resolvers have been the target of Distributed Denial 1179 of Service attacks (DDoS) [REF], with the attacks launched from the 1180 Internet. 1182 These attacks have been possible because ISPs' have assigned their 1183 DNS resolvers public IPv4 addresses, with the public IPv4 addresses 1184 being both globally unique and globally reachable. 1186 The need for global uniqueness comes from the requirement for the DNS 1187 resolvers to have an addresses that are not present within the ISP's 1188 customers' networks. Inherent with global uniqueness of a public 1189 IPv4 address is global reachability. To protect the DNS resolvers 1190 from DDoS attacks, an ISP has to actively configure protection 1191 mechanisms such as packet filters that discard traffic from the 1192 Internet, while continuing to allow the ISP's customers to use the 1193 DNS resolver. 1195 There are two drawbacks of having to use purposely configured 1196 protection mechanisms such as packet filters once the DNS resolver 1197 has a publically unique and reachable address. Firstly, as the 1198 public IPv4 address is normally reachable, an error in configuring 1199 the packet filter means a "fail unsafe" consequence. 1201 Secondly, packet filters can only be applied within the local 1202 network. This means that the large volume of DDoS traffic will reach 1203 the local network before it can be discarded. This discarded DDoS 1204 traffic consumes network capacity on paths towards the network that 1205 should instead be available to legitimate traffic towards the 1206 network. 1208 Ideally, the ISP could assign its DNS resolvers addresses that should 1209 be unique within both the ISP's network and all of its customers' 1210 networks. The addresses should be reachable from the customers' 1211 networks while not being reachable from the Internet. Inherently, 1212 these customer and ISP only visible addresses would protect the DNS 1213 resolvers from Internet launched DDoS attacks. There would be no 1214 need for the ISP to configure packet filters to protect the DNS 1215 resolvers from the Internet, and as the DNS resolvers addresses are 1216 unreachable from the Internet, it would not be possible to send large 1217 volumes of DDoS traffic towards them. The ISP's Internet transit 1218 capacity would be more available for legitimate traffic. 1220 Unique Local Addresses (ULA) [RFC4193] would appear to be addresses 1221 that could be used for this purpose. They are intended to be 1222 globally unique, due to their embedded 41 bit random number, meaning 1223 that they should not collide with any of the ISP's customers 1224 network's addresses. They are also not intended to be reachable 1225 globally across the Internet. 1227 However, the ISP's ULA addresses assigned to its DNS resolvers would 1228 be unlikely be realiably reachable from all of its customers' 1229 networks. The IPv6 source address selection algorithm tries to pick 1230 source addresses that have high order prefix address bits that match 1231 those of the destination [RFC6724]. Consequently, to reach an ISP's 1232 ULA addressed DNS resolvers, customers' hosts would pick their ULA 1233 source addresses, should they have them. These packets may reach the 1234 ISP's DNS resolvers, due to customers' default routes, however the 1235 DNS response return packets are unlikely to reach the customers' 1236 hosts as the ISP is unlikely to know customers' ULA routing prefixes, 1237 due to trading of ULA routing prefixes being prohibited by default 1238 [RFC4193]. 1240 So the source addresses that customers' hosts use when sending to the 1241 ISP's DNS resolvers need to be of greater scope and reachability than 1242 ULA addresses, while the ISP's DNS resolvers need to have addresses 1243 that have a greater scope and reachability than ULA addresses, yet 1244 are not IPv6 Globally Unique Addresses [RFC4291]. 1246 Customers' GUA addresses would meet this customer host source address 1247 requirement, while IPv6 Functional Anycast addresses with a Network 1248 Service Provider Visibility Scope would meet the ISP's DNS resolver 1249 address requirements. 1251 5.7.5. Microservices Architecture Applications 1253 (MRS: Any possible application here? Perhaps service redundancy and 1254 service anycast service addresses. 1256 5.7.6. Global Time Distribution Network 1258 We Have The Time Company (WHTT) are an enterprise who specialise in 1259 providing accurate time to global clients across the Internet, via 1260 the Network Time Protocol. 1262 To provide robust time across they Internet, they provide access to 1263 their NTP servers via Functional Anycast addresses. 1265 WHTT have a GUA /32 assignment from their Regional Internet Registry. 1266 They provide time to clients via the following Global scope 1267 Functional Anycast address, with a Global scope, an anycast domain 1268 prefix of 2001:db8::/32, a Prefix Length of 32 (0x20), and the well 1269 known NTP Anycast Function Identifier of 0x101. 1271 o aae0:2001:db8:0:0:2000::101 1273 5.7.7. Multipath Transport Layer Protocols 1275 Multipath transport layer protocols, such as MPTCP [RFC6824] and SCTP 1276 [RFC3286], establish a full multipath session between hosts in three 1277 stages, using multiple connections. 1279 Stage one involves establishing an initial connection between the 1280 hosts. During stage two, the hosts' remaining set of IP addresses 1281 are exchanged. Finally, in stage three, the full multipath session 1282 is established, with the hosts establishing further connections 1283 between the alternative IP addresses exchanged during stage two. 1284 Note that during the multipath session, any of the connections could 1285 fail or could be purposely torn down, and as long as at least one 1286 connection persists, the multipath session continues. 1288 When multipath transport protocols are used for client-server 1289 applications, a single common IPv6 anycast address could be used by 1290 multiple servers, and then for the initial connection between the 1291 clients and servers during stage one. 1293 During stage two, the server limits the set of alternative IP 1294 addresses it supplies to clients to its unicast addresses, excluding 1295 its one or more anycast addresses. 1297 Subsequent connections that establish the full multipath session 1298 during stage three would then be limited to only being established 1299 between the unicast addresses of the clients and server. 1301 Once any of these stage three unicast address connections is 1302 established, the server could actively tear down the initial 1303 connection to its anycast address, meaning that all of the now 1304 remaining connections are established with the individual server's 1305 unicast address or addresses. 1307 Switching to using only unicast connections for the remainder of the 1308 multipath session overcomes one of the significant limitations of the 1309 use of anycast with connection oriented transport layer protocols 1310 [RFC1546]; the limitation that where the anycast address instance's 1311 packets are delivered to depends on the network's forwarding domains 1312 topology, and if the network topology changes, packets may be 1313 delivered to a different anycast instance that is unaware of and has 1314 not previously been involved in the transport layer connection. 1316 With this use of both anycast and unicast addresses in combination 1317 with multipath transport protocols, the effects of this anycast 1318 limitation are reduced to the time between establishment of the 1319 initial client-server connection to the server's anycast address, and 1320 when the first client-server connection is established using 1321 exclusively unicast addresses. This is in contrast to this risk 1322 possibility existing for the entire duration of a single path 1323 transport layer protocol connection to an anycast address. 1325 The benefit of the above use of anycast in combination with multipath 1326 transport layer protocols applies to all types of anycast addresses 1327 discussed in this memo. 1329 There is a further advantage if Formal Anycast addresses are used. 1330 This is that as a Formal Anycast address is easily identified due to 1331 its well known prefix, the multipath transport layer protocol 1332 implementation does not have to be configured with which of the 1333 server's IPv6 addresses are its anycast addresses, so they can be 1334 excluded from the IPv6 address exchange that occurs during stage two. 1336 6. Security Considerations 1338 Functional Anycast addresses should not introduce any new security 1339 concerns in comparison to the use of addresses from within the 1340 unicast address space as anycast addresses. [RFC7094] provides 1341 considerable anycast related security discussion and references. 1343 The ability to identify a Functional Anycast address using its well 1344 known 8 bit prefix, and the inclusion of forwarding scopes in the 1345 addresses, provide opportunies to enhance security of anycast 1346 services. 1348 7. IANA Considerations 1350 IANA are requested to register the aa00::/8 prefix in the Internet 1351 Protocol Version 6 Address Space registry for use with Formal Anycast 1352 addresses. If aa00::/8 is not chosen, then fa00::/8 is a proposed 1353 alternative. 1355 IANA are requested to update the use of the IPv6 multicast scopes 1356 registry to also record use with Formal Anycast IPv6 addresses. 1358 IANA are requested to record a new IPv6 multicast and Formal Anycast 1359 scope named the "Network Service Provider" scope, with a scope value 1360 of B in hexidecimal. 1362 IANA are requested to register a new ICMPv6 Destination Unreachble 1363 code for Edge of Visible Scope Reached. 1365 IANA are requested to establish a registry for the Flags field of 1366 Functional Anycast addresses, and to reserve the T flag to indicate 1367 transient Anycast Function Identifiers. 1369 IANA are requested to establish a registry for well known Anycast 1370 Function Identifiers, and to reserve the values described previously 1371 in the "Assigned Anycast Function Identifers" section of this memo. 1373 8. Acknowledgements 1375 Gavin Owen prompted the lunch time conversation where the author 1376 joined together and immedidately recognised the benefits of using of 1377 anycast addresses in combination with multipath transport layer 1378 protocols to provide more robust anycast services. 1380 Review and comments were provided by YOUR NAME HERE! 1382 This memo was prepared using the xml2rfc tool. 1384 9. Change Log [RFC Editor please remove] 1386 draft-smith-6man-form-func-anycast-addresses-00, initial version, 1387 2018-10-22 1389 draft-smith-6man-form-func-anycast-addresses-01, updates, 2019-11-03 1391 o Fixed scope location error in addresses used throughout 1393 o Added section on the idea of an anycast address registration 1394 protocol 1396 o Reference updates 1398 10. References 1400 10.1. Normative References 1402 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 1403 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1404 1983, . 1406 [RFC1035] Mockapetris, P., "Domain names - implementation and 1407 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1408 November 1987, . 1410 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1411 (IPv6) Specification", STD 86, RFC 8200, 1412 DOI 10.17487/RFC8200, July 2017, 1413 . 1415 10.2. Informative References 1417 [IANA-IPV6ANYC] 1418 "Internet Protocol Version 6 (IPv6) Anycast Addresses", 1419 . 1422 [IANA-IPV6MCAST] 1423 "IPv6 Multicast Address Space Registry", 1424 . 1427 [IANA-IPV6RESA] 1428 "IPv6 Multicast Address Space Registry", 1429 . 1432 [RFC0318] Postel, J., "Telnet Protocols", RFC 318, 1433 DOI 10.17487/RFC0318, April 1972, 1434 . 1436 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 1437 Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, 1438 November 1993, . 1440 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 1441 Addresses", RFC 2526, DOI 10.17487/RFC2526, March 1999, 1442 . 1444 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1445 Listener Discovery (MLD) for IPv6", RFC 2710, 1446 DOI 10.17487/RFC2710, October 1999, 1447 . 1449 [RFC2941] Ts'o, T., Ed. and J. Altman, "Telnet Authentication 1450 Option", RFC 2941, DOI 10.17487/RFC2941, September 2000, 1451 . 1453 [RFC2946] Ts'o, T., "Telnet Data Encryption Option", RFC 2946, 1454 DOI 10.17487/RFC2946, September 2000, 1455 . 1457 [RFC3286] Ong, L. and J. Yoakum, "An Introduction to the Stream 1458 Control Transmission Protocol (SCTP)", RFC 3286, 1459 DOI 10.17487/RFC3286, May 2002, 1460 . 1462 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1463 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 1464 August 2002, . 1466 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1467 Protocol (HTTP) Digest Authentication Using Authentication 1468 and Key Agreement (AKA)", RFC 3310, DOI 10.17487/RFC3310, 1469 September 2002, . 1471 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1472 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1473 DOI 10.17487/RFC3633, December 2003, 1474 . 1476 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1477 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1478 DOI 10.17487/RFC3810, June 2004, 1479 . 1481 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1482 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1483 . 1485 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1486 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 1487 January 2006, . 1489 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1490 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1491 DOI 10.17487/RFC4271, January 2006, 1492 . 1494 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1495 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1496 2006, . 1498 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1499 Control Message Protocol (ICMPv6) for the Internet 1500 Protocol Version 6 (IPv6) Specification", STD 89, 1501 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1502 . 1504 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1505 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1506 December 2006, . 1508 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1509 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1510 DOI 10.17487/RFC4861, September 2007, 1511 . 1513 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1514 Address Autoconfiguration", RFC 4862, 1515 DOI 10.17487/RFC4862, September 2007, 1516 . 1518 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1519 DOI 10.17487/RFC5308, October 2008, 1520 . 1522 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1523 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1524 . 1526 [RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, 1527 "Principles of Internet Host Configuration", RFC 5505, 1528 DOI 10.17487/RFC5505, May 2009, 1529 . 1531 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1532 "Network Time Protocol Version 4: Protocol and Algorithms 1533 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1534 . 1536 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 1537 Model: The Relationship between Links and Subnet 1538 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 1539 . 1541 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1542 Address Text Representation", RFC 5952, 1543 DOI 10.17487/RFC5952, August 2010, 1544 . 1546 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1547 "Default Address Selection for Internet Protocol Version 6 1548 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1549 . 1551 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1552 "TCP Extensions for Multipath Operation with Multiple 1553 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1554 . 1556 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1557 of IPv6 Extension Headers", RFC 7045, 1558 DOI 10.17487/RFC7045, December 2013, 1559 . 1561 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1562 "Architectural Considerations of IP Anycast", RFC 7094, 1563 DOI 10.17487/RFC7094, January 2014, 1564 . 1566 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 1567 DOI 10.17487/RFC7346, August 2014, 1568 . 1570 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 1571 Length Recommendation for Forwarding", BCP 198, RFC 7608, 1572 DOI 10.17487/RFC7608, July 2015, 1573 . 1575 [RFC7723] Kiesel, S. and R. Penno, "Port Control Protocol (PCP) 1576 Anycast Addresses", RFC 7723, DOI 10.17487/RFC7723, 1577 January 2016, . 1579 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1580 and P. Hoffman, "Specification for DNS over Transport 1581 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1582 2016, . 1584 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1585 "Observations on the Dropping of Packets with IPv6 1586 Extension Headers in the Real World", RFC 7872, 1587 DOI 10.17487/RFC7872, June 2016, 1588 . 1590 [RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays 1591 around NAT (TURN) Server Auto Discovery", RFC 8155, 1592 DOI 10.17487/RFC8155, April 2017, 1593 . 1595 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1596 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1597 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1598 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1599 . 1601 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1602 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1603 . 1605 [RFC8633] Reilly, D., Stenn, H., and D. Sibold, "Network Time 1606 Protocol Best Current Practices", BCP 223, RFC 8633, 1607 DOI 10.17487/RFC8633, July 2019, 1608 . 1610 Author's Address 1612 Mark Smith 1613 PO BOX 521 1614 HEIDELBERG, VIC 3084 1615 AU 1617 Email: markzzzsmith@gmail.com