idnits 2.17.1 draft-smith-6man-form-func-anycast-addresses-00.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 218: '...aning the packet MUST be discarded at ...' RFC 2119 keyword, line 221: '...described below, SHOULD be generated a...' RFC 2119 keyword, line 255: '... implementations SHOULD BE updated to ...' RFC 2119 keyword, line 261: '... MUST NOT use SLAAC [RFC4862] to generate an automatic address from...' RFC 2119 keyword, line 290: '... (as this prefix MUST NOT be used by t...' (4 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 (October 22, 2018) is 2013 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: 'RFC4443' is mentioned on line 318, but not defined == Missing Reference: 'RFC4862' is mentioned on line 261, but not defined == Missing Reference: 'RFC6724' is mentioned on line 365, but not defined == Missing Reference: 'RFC7608' is mentioned on line 377, but not defined == Missing Reference: 'RFC5952' is mentioned on line 433, but not defined == Missing Reference: 'RFCxxxx' is mentioned on line 755, but not defined == Missing Reference: 'RFCxxx' is mentioned on line 603, but not defined == Missing Reference: 'NORMNEIL' is mentioned on line 822, but not defined == Missing Reference: 'RFC3633' is mentioned on line 898, but not defined ** Obsolete undefined reference: RFC 3633 (Obsoleted by RFC 8415) == Unused Reference: 'RFC4786' is defined on line 1118, but no explicit reference was found in the text == Unused Reference: 'RFC5905' is defined on line 1127, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 2 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 October 22, 2018 4 Updates: RFC4291, RFC4443, RFC6724 (if 5 approved) 6 Intended status: Standards Track 7 Expires: April 25, 2019 9 IPv6 Formal Anycast Addresses and Functional Anycast Addresses 10 draft-smith-6man-form-func-anycast-addresses-00 12 Abstract 14 IPv6 anycast addresses are chosen from within the existing IPv6 15 unicast address space, with the addresses nominated as anycast 16 addresses through configuration. An alternative scheme is to have a 17 special class of addresses for use as anycast addresses. This memo 18 proposes a distinct general anycast addressing class and a more 19 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 April 25, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . 5 62 4.2.2. Visible Scope . . . . . . . . . . . . . . . . . . . . 5 63 4.2.3. Anycast Identifier Format . . . . . . . . . . . . . . 5 64 4.2.4. Anycast Identifier . . . . . . . . . . . . . . . . . 6 65 4.3. Link-Local Visible Scope . . . . . . . . . . . . . . . . 6 66 4.4. ICMPv6 Destination Unreachable Message . . . . . . . . . 7 67 4.5. Default Address Selection . . . . . . . . . . . . . . . . 8 68 4.5.1. Destination Address Selection . . . . . . . . . . . . 8 69 4.5.2. Formal Anycast Scope Comparison . . . . . . . . . . . 8 70 4.6. Advice on Structuring the Anycast Identifier Field Values 8 71 5. Functional Anycast Addresses . . . . . . . . . . . . . . . . 10 72 5.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 10 73 5.2. Address Format . . . . . . . . . . . . . . . . . . . . . 11 74 5.3. Assignment of Anycast Function Identifiers . . . . . . . 12 75 5.4. Assigned Anycast Function Identifiers . . . . . . . . . . 13 76 5.5. Sources of Inspiration for Anycast Function Identifiers . 14 77 5.6. Global Scope Functional Anycast Addresses on the Internet 15 78 5.7. Example Use Cases . . . . . . . . . . . . . . . . . . . . 16 79 5.7.1. Devices Factory Configured with NTP Functional 80 Anycast Addresses . . . . . . . . . . . . . . . . . . 16 81 5.7.2. Branch Office DNS Resolvers . . . . . . . . . . . . . 18 82 5.7.3. Automatic eBGP Session Establishment . . . . . . . . 19 83 5.7.4. ISP's Anycast DNS Resolvers . . . . . . . . . . . . . 21 84 5.7.5. Microservices Architecture Applications . . . . . . . 22 85 5.7.6. Global Time Distribution Network . . . . . . . . . . 22 86 5.7.7. Example3 . . . . . . . . . . . . . . . . . . . . . . 22 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 90 9. Change Log [RFC Editor please remove] . . . . . . . . . . . . 23 91 10. Informative References . . . . . . . . . . . . . . . . . . . 23 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 94 1. Introduction 96 [RFC1546] was the first description of host anycast services, and 97 proposed two ways of supporting them in terms of addressing: 99 o using parts of the existing address space 101 o create a special class of addresses for anycast use 103 The first method of supporting anycast addresses, by using parts of 104 the existing (unicast) address space, could be described as informal. 105 From the address itself, it is not possible to determine that the 106 apparent unicast address is actually being used as an anycast 107 address. 109 As the second method would create a special class of addresses for 110 anycast use, it could be described as formal. Encoded within the 111 addresses would be a value and perhaps other attributes that 112 indicates they are anycast addresses, regardless of context. 114 In terms of a spectrum of delivery ranging from to a single or to 115 multiple destinations, anycast addresses are a distinct class of 116 addresses when compared to unicast and multicast addresses. Packets 117 sent to a unicast destination are intended to be delivered to one and 118 only one unique destination host. Packets sent to a multicast 119 destination are intended to be delivered to a group of interested 120 destination hosts, with the interested group consisting of one or 121 more members, and the packets being duplicated by the network when 122 and where necessary. Packets sent to an anycast destination are 123 intended to be delivered to only one of a set of hosts sharing the 124 same anycast address. As a type of address, anycast addresses can be 125 imagined to fall between unicast and multicast address types on the 126 delivery spectrum. 128 IPv6 anycast addresses [RFC4291] are currently from within the 129 existing unicast address address space. Therefore, this memo gives 130 these IPv6 anycast addresses the name "Informal Anycast" addresses. 132 This memo proposes a special and formal class of IPv6 addresses for 133 anycast use, calling them "Formal Anycast" addresses. 135 The described IPv6 Formal Anycast address class can support a total 136 of 16 sub-classes of anycast address formats and structures. 137 Following the description of Formal Anycast address class, this memo 138 then proposes the first sub-class called "Functional Anycast" 139 addresses. 141 There are some existing reserved and well known anycast addresses 142 within the existing Informal Anycast address space. While well 143 known, they do not have any of the formal attributes that the 144 proposed formal Functional Anycast addresses have, other than having 145 specified and well known values; they could be described as semi- 146 formal. Well known Functional Anycast addresses are proposed that 147 correspond to these existing semi-formal anycast addresses. 149 2. Terminology 151 Anycast Domain 153 Formal Anycast Address 155 Functional Anycast Address 157 Informal Anycast Address 159 Semi-Formal Anycast Address 161 3. Drawbacks of Informal Anycast Addresses 163 There are drawbacks and limitions of IPv6 Informal Anycast addresses: 165 o As mentioned in the Introduction, there is nothing specifically 166 encoded in an Informal Anycast address to distinguish it from a 167 unicast address, such as being from within a well known address 168 prefix. In some situations, this unintentional obfuscation may be 169 of use, however in others, such as while troubleshooting, it can 170 be detrimental. For example, duplicate routes for an address 171 appearing in a route table with different and distinct announcing 172 routers may be a fault if unintentional, meaning it is a duplicate 173 unicast address assignment. Alternatively, it may be the intended 174 configuration if the routes are Informal Anycast routes i.e., the 175 address from within the unicast address space is being used an 176 anycast address. The duplicate routes and the addresses 177 themselves provide no indication of whether the configuration is 178 intentional or not. 180 o Constraining the visibility and reachability of an anycast 181 provided service or function may be useful for security reasons, 182 which can be fundamentally enforced by encoding and limiting the 183 scope of or domain where packets are intended and able to be 184 forwarded. Informal Anycast addresses can only have one of three 185 fundamental forwarding scopes encoded in the address, matching 186 those of the three types of IPv6 unicast addresses - limited to a 187 link scope (Link-Local Address), limited to a network scope 188 (Unique Local Address) or having global Internet scope (Global 189 Unicast Address) [RFC4291][RFC4193]. These scopes are coarse. 190 More fine grained scopes, such as those used in IPv6 multicast 191 [RFC7346], would provide much more control over anycast service or 192 function visibility. 194 4. Formal Anycast Addresses 196 4.1. Address Format 198 The following diagram shows the structure of an IPv6 Formal Anycast 199 address. 201 4.2. Address Fields 203 4.2.1. Formal Anycast Prefix 205 A 8 bit prefix value of TBD (aa00::/8 preferred, indicating a Anycast 206 Address; fa00::/8 an alternative, indicating a Formal Anycast 207 address), identifying this address as a Formal Anycast address. 209 4.2.2. Visible Scope 211 A 4 bit Visible Scope field used to express and enforce visibility 212 and assumed reachability of the Formal Anycast address. The values 213 and meanings of the values of this field are the same as those for 214 the IPv6 multicast address scope field [RFC4291][RFC7346]. 216 When packets with a Formal Anycast destinaton address are being 217 forwarded, this field's value takes precedence over a non-zero Hop 218 Limit field value, meaning the packet MUST be discarded at the edge 219 of the indicated visibility domain even though it may have a non-zero 220 Hop Limit value. A specific ICMPv6 Destination Unreachable [RFC4443] 221 message, described below, SHOULD be generated and returned to the 222 packet's sender indicating the packet was discarded as it reached the 223 edge of its Visible Scope. 225 4.2.3. Anycast Identifier Format 227 A 4 bit field identifying the format of the following Anycast 228 Identifier field, holding digits in the range of 0x0 through 0xf in 229 hexidecimal. 231 The first assigned value is 0, specifying that the following Anycast 232 Identifier Format is that of a Functional Anycast addresses, which is 233 described later in this memo. 235 Other values will be assigned by IANA as future Anycast Identifier 236 Formats are specified. 238 4.2.4. Anycast Identifier 240 A 112 bit field holding the Anycast Identifier value. The format and 241 structure of this field is encoded in the previous Anycast Identifier 242 Format field. 244 4.3. Link-Local Visible Scope 246 One of the possible Visible Scope values is the Link-Local scope, 247 specifying that the Formal Anycast address's visibility is limited to 248 a link that the host is directly attached to. 250 Nodes on the link will need to consider Formal Anycast addresses with 251 a Link-Local Visible Scope on-link, so that they perform Neighbor 252 Discovery [RFC4861] for these addresses. 254 Similar to the unicast Link-Local prefix [RFC5942], IPv6 255 implementations SHOULD BE updated to consider the Formal Anycast 256 prefix with a Link-Local Visible Scope on-link. Using the 257 (preferred, IANA TBA) aa00::/8 Formal Anycast prefix, this means IPv6 258 implementations will consider aa02::/16 to be on-link. 260 Unlike the unicast Link-Local prefix, updated IPv6 implemenations 261 MUST NOT use SLAAC [RFC4862] to generate an automatic address from 262 within this Formal Anycast Link-Local Visible Scope prefix (MRS: Need 263 to further consider this, is there a case I've missed where this 264 could be useful? Hmm, what about, for example, the router subnet 265 anycast address? Perhaps anycast providing applications could/should 266 resister their anycast addresses similar to multicast. Hmm, there 267 really needs to be any "Anycast Listener Discovery" protocol similar 268 or same as MLD.). 270 Note that unlike the unicast Link-Local prefix, IPv6 nodes may not 271 and typically would not have an address from within the Formal 272 Anycast Link-Local Visible Scope prefix. One of the node's Link- 273 Local addresses on the same link should be used as a source address 274 when sending to a Formal Anycast Link-Local Visible Scope 275 destination. This does not preclude using other greater scope 276 unicast source addresses. (MRS: probably need to update source/ 277 destinaton address selection RFC - I think that is already somewhere 278 in this draft?) 280 In the interrim IPv6 implementation update period, IPv6 nodes can be 281 informed that the Formal Anycast Link-Local Visible Scope prefix is 282 on-link in one of two ways: 284 o A manually configured entry in the host's Prefix List [RFC4861]. 286 o A dynamic update to nodes' Prefix Lists using a Router 287 Advertisement Prefix Information Option (PIO) for the Formal 288 Anycast Link-Local Visible Scope prefix, with the 'L' or on-link 289 flag set to on, and the 'A' or autonomous address-configuration 290 flag set to off (as this prefix MUST NOT be used by the node to 291 automatically generate an address for its use within this prefix). 292 The Valid and Preferred Lifetimes for the Formal Anycast Link- 293 Local Visible Scope prefix in the PIO are set to infinity. 295 4.4. ICMPv6 Destination Unreachable Message 297 As mentioned prevously, if a packet with a Formal Anycast destination 298 address reaches the edge of the Visible Scope for the address, a 299 ICMPv6 Destination Unreachable [RFC4443] message SHOULD be generated 300 and sent back to trigger packet's sender. 302 Note that if the router at the edge of the visibility domain is also 303 assigned the Formal Anycast address, the packet is host processed 304 locally rather than being discarded, and an ICMPv6 Destination 305 Unreachable message IS NOT generated and returned to the packet's 306 sender. 308 When a router implementation formally supports Formal Anycast 309 addresses, the ICMPv6 Code for the Destination Unreachble message is 310 IANA-TBD, indicating that the Edge of the Visible Scope [was] 311 Reached. 313 If a router implementation does not formally support Formal Anycast 314 addresses an operator should use packet filters to enforce the 315 Visible Scope boundary. A packet failing to pass the packet filter 316 should cause the router to generate a Destination Unreachable 317 Communication with destination administratively prohibited message 318 [RFC4443] (Code 1) message, which is semantically similar to the 319 formal Edge of Visibile Scope Reached message. 321 Note that ICMPv6 messages are not sent reliably, so Formal Anycast 322 packet senders will need to be able to handle not receiving a ICMPv6 323 Destination Unreachable message in response to a packet reaching the 324 edge of the visibility domain. 326 There may be situations where silently discarding Formal Anycast 327 packets at the Visible Scope boundary may be preferred. In this 328 case, a packet discard route, covering the Visible Scope prefix can 329 be installed in a router's forwarding table. 331 4.5. Default Address Selection 333 4.5.1. Destination Address Selection 335 An IPv6 implementation may be presented with a candidate set of 336 destination addresses that consists of both Formal Anycast and 337 unicast addresses. The implementation needs to make a choice or 338 choices as to which of these candidate addresses to attempt to use. 340 The decision to use a Formal Anycast address instead of a unicast 341 address is an active and conscious one. Therefore, when a choice 342 needs to be made between a Formal Anycast address and a unicast 343 address, the Formal Anycast address should always be preferred. 345 In terms of the Destinaton Address Selection algorithm described in 346 [RFC6724], this preference of Formal Anycast over unicast addresses 347 introduces a new rule between Rule 1 ("Avoid unusable destinations") 348 and Rule 2 ("Prefer matching scope"), specifically (using "1.5" here 349 to indicate the position): 351 Rule 1.5: Prefer Formal Anycast addresses. 353 If DA is a unicast address, and DB is a Formal Anycast address, 354 then prefer DB. 356 Note that there may be instances where an application would prefer to 357 use a unicast address over a Formal Anycast address. In this case, 358 Formal Anycast addresses can be identified and ignored using the well 359 known 8 bit Formal Anycast prefix. 361 4.5.2. Formal Anycast Scope Comparison 363 As the Formal Anycast address scopes are defined to be the same as 364 Multicast address scopes, the same Multicast scope comparison 365 methods, described in [RFC6724], are used with Formal Anycast address 366 scopes. 368 4.6. Advice on Structuring the Anycast Identifier Field Values 370 The Anycast Identifier Format field within a Formal Anycast address 371 specifies the format and structure of the 112 bit Anycast Identifier 372 field. The following is advice and guidelines to use when developing 373 a new Anycast Identifier field format and structure. 375 Forwarding towards anycast addresses is the same as forwarding 376 towards unicast addresses, which uses the longest match rule BCP 198 377 [RFC7608]. Longest match forwarding facilitates summarisation of 378 forwarding information, where a single more general forwarding route 379 can summarise a number of more specific forwarding routes. 380 Summarisation saves entries in forwarding tables outside of the 381 summarised forwarding domain, provides simpler destination based 382 filtering for security purposes, and facilitates easier destination 383 address based traffic analysis. 385 The use of route summarisation with anycast addresses effectively 386 creates an anycast domain that is being identified and summarised by 387 the anycast summary route. Outside of the anycast domain, a single 388 summary route exists, covering all anycast addresses within the 389 domain. Within the anycast domain, individual routes for individual 390 anycast addresses exist. 392 When designing a new Anycast Identifier field format and structure, 393 the following guidelines should be followed. These guidelines should 394 allow a set of more specific anycast routes to be summarised as well 395 as improving operator usability. 397 o The order of fields within the Anycast Identifier field, should be 398 from the most general to most specific, in the direction following 399 the high order to low order bits of the Anycast Identifier field 400 and the broader IPv6 address. 402 o The order of bits within fields should also be from the most 403 general to most specific, matching the direction of high order to 404 low order of bits within the Anycast Identifier field. 406 o The bits in fields holding bits that are matched exactly, such as 407 flag fields or fields holding numeric values that are matched 408 exactly, can be orded to suit the field's use and application. 409 However, a hierarchial order, from most significant to least 410 significant bit, following Anycast Identifier field bit order, is 411 suggested. Although initially defined hierarchially, the order of 412 flags in flag fields may later deviate from this recommendation 413 due to later flag bit definition. 415 o End-users of the functions and services being provided using 416 Formal Anycast addresses are unlikely and ideally should never see 417 these addresses. However, operators of these functions and 418 services will deal with these addresses during planning, 419 configuration and troubleshooting. Where possible, fields and 420 their values should be ordered and structured to assist with these 421 tasks. Field boundaries within the Anycast Identifier field 422 should align with 16 bit word, 8 bit octet or 4 bit nibble 423 positions within the whole IPv6 address. For example, if part of 424 an IPv6 prefix is included in the Anycast Identifier, it should 425 start at a 16 bit "piece" boundary, where colons appear [RFC4291], 426 within the IPv6 address. Note that this guildline should not take 427 precedence over any previous measures to faciliate more specific 428 anycast route summarisation. 430 o A further address usability recommendation is to set field and bit 431 values to zero for the likely most common or likely most secure 432 meaning for these fields or bit values. In IPv6 addresses zero 433 field values can be compressed [RFC5952], resulting in a shorter 434 address for an operator to enter. A shorter address to enter 435 naturally reduces the opportunities for and likelihood of errors 436 in the address, and reduces the possibilities of security issues 437 caused by errors in the Formal Anycast address.. 439 5. Functional Anycast Addresses 441 The first defined sub-class or sub-format of Formal Anycast addresses 442 is the Functional Anycast address sub-class. 444 5.1. Features 446 The following are the features of Functional Anycast addresses. In 447 many cases they're inspired by and mirror IPv6 multicast address 448 features [RFC4291][RFC3306]. 450 o Provides separate globally well known and local network defined 451 anycast function or service identifier spaces. Globally well 452 known identifiers can be encoded in applications during their 453 development as constants, avoiding the need for them to be 454 specified and configured during deployment of the application. 456 o Provides a minimum of 24 bits for use as identifiers for anycast 457 functions or services, supporting more than 16 million values.. 459 o Provides 8 bits for the identification of up to 256 local 460 instances, versions or revisions of the same function or service, 461 assisting with function or service deployment or maintenance. 462 These 8 bits can also be used to increase the size of the function 463 or service identifier space to 32 bits where useful, increasing 464 the range of values to more than 4 billion. 466 o Identifies an anycast function or service identifier space, known 467 as an anycast domain, using an IPv6 unicast address prefix of up 468 to 64 bits in length. A network can create multiple distinct 469 anycast domains by using multiple of its IPv6 prefixes, from its 470 Global [RFC4291] or Unique Local [RFC4193] address spaces (the 471 Link-Local prefix could be used to create a distinct anycast 472 domain, however it can only be used once, despite the network 473 having many instances of the Link-Local prefix (as many as it has 474 links)). A "unspecified" anycast domain is supported using an all 475 zeros 64 bit IPv6 prefix. External to the anycast domain, the 476 identifying 64 bit prefix can be used to create a single summary 477 route for the anycast function or service identifier space, which 478 will help routing scaling for anycast functions or services. The 479 anycast domain boundary could also correspond to routing protocol 480 scaling boundaries, such as OSPF areas [RFCxxxx] or IS-IS level 481 [RFCxxxx] boundaries, when useful. 483 5.2. Address Format 485 The format of Functional Anycast addresses is modelled on the IPv6 486 multicast address format [RFC4291]. 488 The format of an Functional Anycast address is as follows: 490 [diagram to come] 492 The address fields are as follows: 494 o Anycast Domain Prefix - a 64 bit field holding a IPv6 unicast 495 address prefix identifying the anycast domain that is either the 496 provider and possible authority for the following Anycast Function 497 Identifier space. The length of the prefix is specified in the 498 following Prefix-Length field, with the remaining bits of the 499 field set to zero. An all zero Anycast Domain Prefix means an 500 unspecified Anycast Function Identifier provider. An all zeros 501 Prefix in effect means "this" provider, with "this" meaning the 502 current anycast domain. Link-Local, Unique-Local [RFC4193], 503 Global and possible future other unicast prefixes [RFC4291] 504 identify a Anycast Function Identifier provider. Within an 505 anycast function domain, this allows multiple anycast function 506 sub-domains to be created, identified by different unicast 507 Prefixes in this field. 509 o Reserved - a 2 bit reserved field. Set to zero upon transmission, 510 ignored upon receipt. 512 o Prefix-Length - An 6 bit field specifying the length of the 513 previous Anycast Domain Prefix. A value of zero means a 64 bit 514 length prefix, while prefix lengths of 1 through 63 (0x01 through 515 0x3f) are encoded natively. The unspecified Anycast Domain Prefix 516 of all zeros is considered to be 64 bits in length, meaning a 517 Prefix-Length value of 0 for this prefix. This is an 518 informational field to assist with operation and troubleshooting. 520 o Flags - A 8 bit flag field. The lower 7 flags are reserved and 521 must be set to zero upon transmission, and ignored upon receipt. 522 The high order flag is the 'T' or Transient flag. T=0 indicates 523 that the later Anycast Function Identifier is well known and 524 assigned by the Internet Assigned Numbers Authority (IANA). T=1 525 indicates that the Anycast Function Identifier is transient or 526 dyamically assigned, and has been assigned by the Functonal 527 Anycast domain's local authority. 529 o Local Instance - An 8 bit field holding a identifier of the 530 instance, version or revision of the function identified by the 531 following Anycast Function Identifier field, local to the current 532 anycast domain. The default value of this field is zero, 533 indicating the default and first instance of the anycast function. 534 Non-default values are chosen by the local anycast domain 535 operator, even when the following Anycast Function Identifier is 536 using a well-known IANA Anycast Function Identifier value. An 537 anycast domain operator may chose to assign other semantics to 538 this field, as long as they're both less significant than the 539 previous fields and more sigificant than the following Anycast 540 Function Identifier field. When the 'T' bit in the Flags field is 541 set to 1, meaning transient Anycast Function Identifiers, this 542 field could be used to effectively increase the size of the 543 following Anycast Function Identifier field to 32 bits, increasing 544 the value range of Anycast Function Identifiers from in the order 545 of 16 million to in the order of 4 billion. 547 o Anycast Function Identifier - A 24 bit field identifying the 548 anycast function to be performed on the packet when it arrives at 549 a host that has been configured with the Functional Anycast 550 address. When the 'T' bit in the Flags field is set to zero, the 551 Anycast Function Identifiers values are from a well known Anycast 552 Function Identifier registry maintained by IANA, with initial 553 entries specified later in this memo. When the 'T'bit in the 554 Flags field is set to 1, the values in the Anycast Function 555 Identifier field are local to and assigned by the authority 556 identified in the Prefix field in any manner that suits their 557 purposes and requirements. 559 5.3. Assignment of Anycast Function Identifiers 561 In the history of the Internet, it has been common to conflate a 562 function or service with a protocol. 564 For example, historically, the telnet protocol [RFCxxxx] had been the 565 most popular remote virtual terminal protocol. In more recent times, 566 the SSH protocol [RFCxxx] has become the de facto remote virtual 567 terminal protocol. Accessing the remote virtual terminal service has 568 either been referred to as "telnet in" or "SSH in" to the host 569 providing the service, using the protocol being used to refer to the 570 service being accessed. 572 In either case, telnet and SSH protocols are being used to access a 573 remote virtual terminal service. Functionally, from the perspective 574 of remote virtual terminal access, the differences are relatively 575 minor; data security and integrity via encryption and authentication 576 is where the primary differences between telnet and SSH are - in 577 telnet encryption of the data stream is optional [RFCxxx], where as 578 with SSH it is mandatory. 580 When both IANA and local anycast domain operators assign Anycast 581 Function Identifiers, it is recommended that they're allocated and 582 identified by protocol agnostic function or service type rather than 583 to a specific protocol that provides that function or service. As 584 the particular protocol being used to access the function or service 585 will be encoded in the upper transport layer protocols and ports in 586 the IPv6 packet, service or function based Anycast Function 587 Identifers can support and stay constant across the use and evolution 588 of different function or service access protocols. 590 For example, with a well-known Anycast Function Identifier 591 specifically allocated to a Network Virtual Terminal service (NVT) 592 [RF852?], the hosts providing the NVT service could initially support 593 both telnet (assuming telnet is considered secure enough) and SSH. 594 If both telnet and SSH become deprecated, and a new NVT access 595 protocol is developed, the same Anycast Function Identifier for the 596 NVT service could be used to reach a node supporting this new access 597 protocol. 599 Another example is the domain name service. Currently domain name 600 resolution takes place using the Domain Name Service protocol 601 [RFCxxx], natively carried over UDP and TCP, using port 53. More 602 recently, work has been taking place to operate DNS over TLS [RFCxxx] 603 and HTTP [RFCxxx] to enhance the security of the domain name 604 resolution function. The use of multiple protocols to access 605 fundamentally the same domain name resolution function suggests a 606 protocol agnostic domain name resolution Anycast Function Identifier. 608 This doesn't preclude Anycast Function Identifiers being used to 609 support and identify specific protocols (examples of this occur 610 later). There may be current and future cases where the allocation 611 and use of an Anycast Function Identifier for a specific protocol is 612 the better choice. This should be considered and evaluated on a case 613 by case basis. 615 5.4. Assigned Anycast Function Identifiers 617 A number of past RFCs have reserved anycast addresses and 618 identifiers. These addresses and indentifiers are mapped to the 619 following corresponding and well known Anycast Function Identifiers, 620 and are to be listed in the IANA Anycast Function Address Identifier 621 registery if it is created. 623 [RFC2526] reserves the highest 127 values of a subnet prefix 624 Interface Identifier for anycast addresses. The equivalent values 625 for Functional Anycast addresses are the highest 127 values of the 32 626 bit Anycast Function Identifier, a range of (in IPv6 address format, 627 excluding the high order 96 bits) :ffff:fff8 through :ffff:ffff. The 628 IANA Internet Protocol Version 6 (IPv6) Anycast Addresses registry 629 [IANA-IPV6ANYC] records assignments for subnet prefix anycast 630 addresses within the Interface Identifier space. The current and 631 future values of these anycast subnet prefix Interface Identifier 632 values are to also be recorded in the Anycast Function Address 633 Identifier registry. 635 [RFC4291] reserves an Interface Identifer of all zeros within a 636 unicast prefix as the Subnet-Router anycast address. The equivalent 637 32 bit Anycast Function Identifier value for Functional Anycast 638 addresses is also all-zeros. 640 [RFC7723] reserves the IPv6 address 2001:1::1/128 for the use as the 641 Port Control Protocol Anycast address. The equivalent 32 bit Anycast 642 Function Identifier value is (in IPv6 address format, excluding the 643 high order 96 bits) :0001:0001. 645 [RFC8155] reserves the IPv6 address 2001:1::2/128 for the use as the 646 Traversal Using Relays around NAT Anycast address. The equivalent 32 647 bit Anycast Function Identifier value is (in IPv6 address format, 648 excluding the high order 96 bits) :0001:0002. 650 5.5. Sources of Inspiration for Anycast Function Identifiers 652 A future possible source of inspiraton for well known assigned 653 Anycast Function Identifiers could be DHCPv6 [RFC3315] options that 654 encode IPv6 addresses for services. A number of these options encode 655 multiple IPv6 addresses as candidates for access to the service (for 656 example, the SIP Servers IPv6 Address List option [RFC3310]). The 657 use of anycast for service resiliance would allow a single Anycast 658 Function Identifier value to provide equivalent service, although 659 this wouldn't preclude defining multiple different Anycast Function 660 Identifiers to the service to provide the service client concurrent 661 access to multiple service instances. For example, 3 Functional 662 Anycast addresses could be allocated for DNS resolvers, providing a 663 client with verifiable DNS resolver services from up to 3 different 664 resolvers, and allowing the client to distribute requests across all 665 3 resolvers. 667 Another source of inspiration for well known assigned Anycast 668 Function Identifiers could be the IANA IPv6 Multicast Address Space 669 [IANA-IPV6MCAST] registry, where some of the multicast addresses 670 represent services that could also be useful when provided via 671 anycast. 673 While using these possible source of inspiration, the recommendation 674 to choose protocol agnostic function or service identifiers still 675 stands. DHCPv6 or multicast groups can be used to inspire more 676 generic function or service identifiers. 678 5.6. Global Scope Functional Anycast Addresses on the Internet 680 Functonal Anycast addresses could be used to provide anycast services 681 across the Internet, by using the the Global scope. 683 When being used on the Internet, many of the possible values of the 684 Prefix field are ambiguous, meaning that they wouldn't unambiguously 685 identify the party using the Functional Anycast address to provide 686 the service or function. Examples of ambiguous prefixes are the all- 687 zeros unspecified prefix, any ULA [RFC4193] prefixes, and the Link- 688 Local [RFC4291] prefix. Other ambiguous prefixes are those in the 689 IPv6 reserved address registry [IANA-IPV6RESA] that are not valid on 690 the Internet. 692 To overcome this ambiguity, if Global scope Functional Addresses are 693 used over the Internet, the Prefix field MUST be set to a GUA 694 [RFC4291] prefix value assigned to the party providing the anycast 695 service to Internet clients. A network either accepting or 696 originating a Global scope Functional Address prefix for announcement 697 from a downstream stub autonomous system for announcement onto the 698 Internet MUST only accept or originate a route announcement for a 699 Global scope Functional Anycast prefix that includes an explicitly 700 identified GUA prefix. All other Global scope Functional Anycast 701 prefix announcements with ambiguous or non-explicitly identified GUA 702 prefixes MUST be ignored. 704 As forwarding towards anycast addresses is functionally the same as 705 forwarding towards unicast addresses, Functional Anycast prefixes 706 would be announced into the Internet's unicast forwarding route 707 table. 709 It is common practice today to limit the prefix length of unicast 710 IPv6 Internet routes accepted to a length of no more than 48 bits 711 i.e. a /48. This is a blunt and simple way to attempt to somewhat 712 limit the number of IPv6 routes in the Internt route table. It is 713 imposing this limit by enforcing a minimal level of aggregation at 714 the /48 boundary. Networks using prefix lengths longer than /48 are 715 expected to aggregate those networks into a route advertisement that 716 is /48 or shorter. 718 This practice of limiting advertised unicast route prefix lengths to 719 48 bits will limit the size of the Prefix included in Global scope 720 Functional Anycast announcements to 32 bits, as the high order 16 721 bits of the Functional Anycast prefix are used to encode the 722 Functional Address type prefix and address scope. This would limit 723 the use of Global scope Functional Anycast addresses to provide 724 global Internet anycast services to those organisations who have a 725 /32 or shorter assignment from an RIR. 727 As Functional Anycast addresses are a separate class of addresses, 728 and are all identified by a unique /8 prefix, this /48 prefix length 729 limit could be specifically relaxed for Functional Anycast routes. A 730 /48 prefix, when included in a Functional Anycast, results in a 731 Functional Anycast prefix length of /64. Imposing a /64 prefix 732 length limit on Functional Anycast routes, identified by a high order 733 prefix of aa0e::/16, and a GUA anycast domain Prefix, would achieve 734 the same outcome of attempting to reducing the number of entries in 735 the IPv6 Internet route table. 737 Wide acceptance of Functional Anycast prefixes of up to 64 bits in 738 length on the Internet may take same time to occur. Use of Global 739 scope Functional Anycast addresses by organisations who have RIR /32 740 assignments, which will be accepted by unicast /48 prefix filters 741 present today, would raise awareness of Functional Anycast addresses. 742 This increased awareness could be leveraged to motivate the changing 743 of prefix filters to accept Global scope Functional Anycast prefixes 744 up to 64 bits in length. 746 5.7. Example Use Cases 748 This section provides some example use cases of Functional Anycast 749 addresses that would suit the described scenarios. 751 5.7.1. Devices Factory Configured with NTP Functional Anycast Addresses 753 Assume IANA has allocated a set of well-known Anycast Function 754 Identifier values of 0x004440, 0x004441, 0x004442 and 0x004443 for 755 use with the Network Time Protocol [RFCxxxx], to facilitate meeting 756 the NTP best practice of having a minimum of 4 NTP time sources [NTP 757 best practices ID]. 759 A device manufacturer uses this set of well-known Anycast Function 760 Identifier to set factory default Functional Anycast addresses for 761 access to a device customer's NTP servers. 763 The corresponding Functional Anycast address is constructed as 764 follows: 766 o 8 bit Formal Anycast Prefix value (0xaa proposed). 768 o 4 bit Visible Scope value of 0x8, corresponding to Organization- 769 Local [RFC7346], as the manufacturer is unlikely to have any 770 knowledge of device customers' use of or preference for smaller 771 scopes. 773 o 4 bit Anycast Identifier Format value of 0x0, corresponding to the 774 Functional Anycast format. 776 o 112 bit Anycast Identifier in the Functional Anycast format: 778 o 780 * 64 bit Anycast Domain Prefix value of the all zeros unspecified 781 prefix. 783 * 2 bit reserved field set to zero. 785 * 6 bit Prefix-Length field set to zero, meaning a 64 bit length 786 Anycast Domain Prefix value. 788 * 8 bit Flags field set to all zeros. The upper 7 bits are zero 789 as they're served, while the lowest 'T' or Transcient flag is 790 set to zero indicating an IANA assigned well known Anycast 791 Function Identifier. 793 * 8 bit Local Instance flag set to the default value of zero. 795 * 24 bit Anycast Function Identifier field set to either 796 0x004440, 0x004441, 0x00442 or 0x004443; one of the IANA 797 assigned well known Anycast Function Identifier values for the 798 NTP protocol. 800 All of the above mean that the NTP server Functional Anycast 801 addresses the device manufacturer sets as the defaults would be (in 802 IPv6 address compressed format): 804 o aa08::4440 806 o aa08::4441 808 o aa08::4442 810 o aa08::4443 812 5.7.2. Branch Office DNS Resolvers 814 An enterprise network operator decides to use Functional Anycast 815 addresses to provide DNS resolver service to end-user devices, 816 located in various corporate offices. 818 Specifically for a single mid-sized branch office, with in the order 819 of 200 staff, the operator decides to provide two DNS resolvers 820 located in the office. This will provide lower latency DNS 821 resolution through DNS caching, reducing perceiveable application 822 response time [NORMNEIL]. Access to a third, geographically close, 823 off-site DNS resolver is provided for redundancy. This off-site DNS 824 resolver will be one of the other branch office's local DNS 825 resolvers. 827 All three DNS resolvers will provide their services to clients via 828 Functional Anycast addresses. Different clients will receive the on- 829 site DNS resolver addresses in alternating order, both before the 830 off-site DNS resolver address. This provides rudimentry on-site DNS 831 resolver load balancing and keeps both DNS resolvers' lookup caches 832 populated to reduce the client visible performance impact of the 833 fail-over to the remaining on-site DNS resolver, should its sibling 834 fail. The on-site DNS resolvers will watch each others' 835 availablility, taking over its sibling's Functional Anycast address 836 if the sibling becomes unavailable. Should both on-site DNS 837 resolvers become unavailable, clients will resort to using the 838 remaining off-site DNS resolver. 840 Assume IANA have allocated the well known Anycast Function Identifier 841 values of 5300, 5301 and 5302 for use with anycast DNS resolvers. 843 The operator allocates decimal identifiers of 703, 9556, 4739, 38809 844 and 2764 to the corporate offices, with the order reflecting 845 geographic proximity. Each office will have its own unicast /48 from 846 within a globally unique address space of 2001:db8::/32, meaning that 847 the office prefixes are 2001:db8:2bf::/48, 2001:db8:2554::/48, 848 2001:db8:9779::/48 and 2001:db8:acc::/48. 850 The corresponding Functional Anycast address is constructed as 851 follows: 853 o 855 The Visibiliity Scope for for these DNS resolvers' Functional Anycast 856 addresses will be Organization-Local (8). 858 For office 9556, using offic 4739 as an off-site backup, the 859 Functional Anycast addresses for the three DNS resolvers will be: 861 1. aa08:2001:db8:2554::5301 863 2. aa08:2001:db8:2554::5302 865 3. aa08:2001:db8:9779::5303 867 5.7.3. Automatic eBGP Session Establishment 869 Assume IANA has allocated a well-known Anycast Function Identifier 870 value of 0x000179 for use with automatic eBGP [RFC4271?] session 871 establishement. 873 Smaller, stub site routers are preconfigured with a Functional 874 Anycast address to attempt to automatically establish an eBGP session 875 with a one or two upstream eBGP peer aggregation routers over one or 876 two different designated ("WAN") links upon initialisation. 878 The eBGP Functional Anycast address would be a Link-Local Visible 879 scope address. The stub router would use its link's, SLAAC generated 880 [RFC4861] and link unique Link-Local address [RFC4291] as the source 881 address to reach the eBGP Functional Anycast address. Using Link- 882 Local scope Formal Anycast and unicast addresses for this eBGP 883 session would provide a basic level of eBGP access security. 885 The stub site router will need to also be preconfigured or somehow 886 automatically generate an Autonomous System Number (ASN) to use for 887 establishing the eBGP session or sessions. How the ASN is 888 preconfigured or generated is out of scope for this memo, and is left 889 to future work. 891 Once the eBGP session is established, the peer eBGP routers trade 892 routes. These traded routes could include the upstream eBGP 893 providing a default route or other more specific routes, and the 894 downstream stub site router providing a route to its downstream 895 prefix or prefixes. 897 The downstream prefix or prefixes could be those the stub site router 898 has learned via DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633]. An 899 advantage of having the stub site router inject DHCPv6-PD prefixes 900 into the BGP routing domain is that the route information for this or 901 these prefixes within the BGP routing domain would more accurately 902 reflect the state and therefore the availability of the prefixes at 903 the site they've been assigned and are being used it. Stub site 904 routers announcing their own prefixes would also distribute the 905 announcement processing load across the stub site routers rather than 906 concentrating it at the upstream aggregation router(s). This also 907 avoids the upstream aggregation router having to process the 908 DHCPv6-PD response to determine the assigned delegated prefix for 909 subsequent BGP announcement [RFC about doing this?], meaning it can 910 act as a much simpler and pure DHCPv6 relay [RFC3315]. 912 The upstream link(s) that a stub site is attached to does not have to 913 be limitied to being a true link-layer point-to-point link, meaning 914 that the link only supports a single router pair of a stub and 915 upstream aggregation router. The link could be a multi-access link, 916 with the single link supporting many stub site routers and a number 917 of upstream aggregation routers. 919 As the eBGP Functional Anycast address is a Link-Local Visible Scope 920 address, the address is configured as an anycast address on the 921 upstream aggregation routers' stub site facing network interface. 922 This results in the receiver of the Neighbor Advertisements for this 923 address using the information received in the first received Neighbor 924 Advertisement to update its neighbor cache, rather than the last and 925 most recently received Neighbor Advertisement. These types of 926 Neighbor Advertisements are known as "Anycast Neighbor 927 Advertisements" in [RFC4861]. 929 [RFC4861] says that Anycast Neighbor Advertisements should be delayed 930 a random amount of time between 0 and MAX_ANYCAST_DELAY_TIME, a 931 variable with a default value of 1 second. This random delay is to 932 reduce the probability of loss of the Neighbor Advertisement due to 933 network congestion. 935 Specific to this eBGP use case, the Anycast Neighbor Advertisements 936 delay could include other metrics in the calculation to more 937 intelligently distribute the eBGP sessions across the set of upstream 938 aggregation routers. For example, the number of existing eBGP 939 sessions could be a metric, where an upstream aggregation router 940 delays its Anycast Neighbor Advertisement longer when it has more 941 established eBGP sessions. 943 An operator set router preference metric could be considered, 944 allowing the operator to more gracefully phase out a legacy upstream 945 aggregation router by setting it preference lower than the newer 946 upstream aggregation routers. The operator would then manually 947 terminate the eBGP sessions individually on the legacy upstream 948 aggregation router, at a rate of something like one ever 3 seconds, 949 causing them to be restablished on the higher preference and newer 950 upstream aggregation routers. This would be more graceful than 951 terminating all eBGP sessions at once on the legacy upstream 952 aggregation router by, for example, switching it off. 954 Branch office stub router, automatically attempts to establish a BGP 955 session with a well-known functional anycast address "out of the box" 956 over the default WAN interface. 958 IANA assigned well-known BGP Anycast Function Identifier 960 Link-local scope Functional Anycast address. Provides a minimum 961 level of security, as only possible to establish BGP sessions between 962 direct link peers. 964 Use unspecified prefix (comment that fe80::/64 could be used, 965 although unnecessary) 967 Well-known AS Number used by all stub routers. This makes the BGP 968 sessions eBGP sessions. Routers will reject routes from other stub 969 routers using the same ASN, however this is both fine and ideal as 970 this is a stub router - default only plus announcing its local 971 prefix(es). 973 Sub router acquires a delegated prefix via DHCPv6-PD 975 The delegated prefix is announced via the BGP session. Stops the 976 upstream aggregation router needing to observe a DHCPv6 server's 977 relayed response to then announce the delegated prefix into the 978 network. 980 Upstrem router accepts and establishes BGP sessions with any link- 981 local address from the well known ASN, to the Functional Anycast BGP 982 address. 984 There are potential trust issues here. BGPsec? Use the first BGP 985 session to bootstrap connectivity to then establish a more trusted 986 connection of some sort via PKI. Requirement for being link-local 987 peers adds a minimal level of security and trust, but not much. 989 5.7.4. ISP's Anycast DNS Resolvers 991 ISP DNS anycast resolvers 993 Don't want it to be globally reachable across the Internet to 994 mitigate DDoS attacks on the DNS resolver i.e. don't use GUA 995 address(es) 997 Can't use a prefix that has the possibility of colliding with any of 998 the customers' prefixes. ULA addresses would meet this requirement. 1000 However, per [RFC4193], ULAs have a site scope. The boundaries of 1001 customers' networks correspond to site boundaries, and therefore the 1002 ISP's ULA prefix is not reachable from customers' networks unless 1003 customers' network boundary routers are explicitly configured to 1004 provide ISP ULA prefix access. 1006 Organisation Local Functional Anycast address meets all of the 1007 requirements. 1009 5.7.5. Microservices Architecture Applications 1011 5.7.6. Global Time Distribution Network 1013 We Have The Time Company (WHTT) are an enterprise who specialise in 1014 providing accurate time to global clients across the Internet, via 1015 the Network Time Protocol. 1017 To provide robust time across they Internet, they provide access to 1018 their NTP servers via Functional Anycast addresses. 1020 WHTT have a GUA /32 assignment from their Regional Internet Registry. 1021 They provide time to clients via the following Global scope 1022 Functional Anycast address, with a Global scope, an anycast domain 1023 Prefix of 2001:db8::/32, a Prefix Length of 32 (0x20), and the well 1024 known NTP Anycast Function Identifier of 0x101. 1026 o aa0e:2001:db8:0:0:2000::101 1028 5.7.7. Example3 1030 6. Security Considerations 1032 Functional Anycast addresses should not introduce any new security 1033 concerns in comparison to the use of addresses from within the 1034 unicast address space as anycast addresses. [RFC7094] provides 1035 considerable anycast related security discussion and references. 1037 The ability to identify a Functional Anycast address using its well 1038 known 8 bit prefix, and the inclusion of forwarding scopes in the 1039 addresses, provide opportunies to enhance security of anycast 1040 services. 1042 7. IANA Considerations 1044 IANA are requested to register the aa00::/8 prefix in the Internet 1045 Protocol Version 6 Address Space registry for use with Formal Anycast 1046 addresses. If aa00::/8 is not chosen, then fa00::/8 is a proposed 1047 alternative. 1049 IANA are requested to register a new ICMPv6 Destination Unreachble 1050 code for Edge of Visible Scope Reached. 1052 IANA are requested to establish a registry for the Flags field of 1053 Functional Anycast addresses, and to reserve the T flag to indicate 1054 transient Anycast Function Identifiers. 1056 IANA are requested to establish a registry for well known Anycast 1057 Function Identifiers, and to reserve the values described previously 1058 in the "Assigned Anycast Function Identifers" section of this memo. 1060 8. Acknowledgements 1062 Review and comments were provided by YOUR NAME HERE! 1064 This memo was prepared using the xml2rfc tool. 1066 9. Change Log [RFC Editor please remove] 1068 draft-smith-6man-form-func-anycast-addresses-00, initial version, 1069 2017-02-XX 1071 10. Informative References 1073 [IANA-IPV6ANYC] 1074 "Internet Protocol Version 6 (IPv6) Anycast Addresses", 1075 . 1078 [IANA-IPV6MCAST] 1079 "IPv6 Multicast Address Space Registry", 1080 . 1083 [IANA-IPV6RESA] 1084 "IPv6 Multicast Address Space Registry", 1085 . 1088 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 1089 Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, 1090 November 1993, . 1092 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 1093 Addresses", RFC 2526, DOI 10.17487/RFC2526, March 1999, 1094 . 1096 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1097 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 1098 August 2002, . 1100 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1101 Protocol (HTTP) Digest Authentication Using Authentication 1102 and Key Agreement (AKA)", RFC 3310, DOI 10.17487/RFC3310, 1103 September 2002, . 1105 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1106 C., and M. Carney, "Dynamic Host Configuration Protocol 1107 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1108 2003, . 1110 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1111 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1112 . 1114 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1115 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1116 2006, . 1118 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1119 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1120 December 2006, . 1122 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1123 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1124 DOI 10.17487/RFC4861, September 2007, 1125 . 1127 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1128 "Network Time Protocol Version 4: Protocol and Algorithms 1129 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1130 . 1132 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 1133 Model: The Relationship between Links and Subnet 1134 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 1135 . 1137 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1138 "Architectural Considerations of IP Anycast", RFC 7094, 1139 DOI 10.17487/RFC7094, January 2014, 1140 . 1142 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 1143 DOI 10.17487/RFC7346, August 2014, 1144 . 1146 [RFC7723] Kiesel, S. and R. Penno, "Port Control Protocol (PCP) 1147 Anycast Addresses", RFC 7723, DOI 10.17487/RFC7723, 1148 January 2016, . 1150 [RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays 1151 around NAT (TURN) Server Auto Discovery", RFC 8155, 1152 DOI 10.17487/RFC8155, April 2017, 1153 . 1155 Author's Address 1157 Mark Smith 1158 PO BOX 521 1159 HEIDELBERG, VIC 3084 1160 AU 1162 Email: markzzzsmith@gmail.com