idnits 2.17.1 draft-bound-anycast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 126 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** 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 145: '... header and MUST be passed transpare...' RFC 2119 keyword, line 146: '... The transport layer MAY then take in...' RFC 2119 keyword, line 200: '...ansport protocol MAY take in account t...' RFC 2119 keyword, line 226: '...g an active open MAY then use the IP...' RFC 2119 keyword, line 229: '...ESTABLISHED it MUST then consider th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '... This docum...' == Line 13 has weird spacing: '...working docum...' == Line 14 has weird spacing: '... Note that ...' == Line 15 has weird spacing: '... groups may ...' == Line 19 has weird spacing: '... months and ...' == (121 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 1546 ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) -- Possible downref: Non-RFC (?) normative reference: ref. 'SVRLOC' Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Bound 2 IPv6 Work in Progress Digital Equipment Corp 3 P. Roque 4 Universidade de Lisboa 6 IPv6 Anycasting Service: Minimum requirements for end nodes 8 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 ``work in progress.'' 24 To learn the current status of any Internet-Draft, please 25 check the ``1id-abstracts.txt'' listing contained in the 26 Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), 27 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 28 ds.internic.net (US East Coast), or ftp.isi.edu (US West 29 Coast). 31 Abstract 33 This document proposes a minimum set of requirements for IPv6 34 hosts in order to achieve communication with nodes providing 35 services through IPv6 anycast addresses. We present a 36 mechanism that aims to allow TCP and UDP communication between 37 hosts where the packet exchange is initiated through the usage 38 of an anycast address, without requiring modifications to the 39 general definitions of the transport protocols. 41 Table of Contents: 43 1. Introduction.................................................3 44 2. Terminology and Definitions..................................3 45 3. Anycast address usage........................................4 46 4. Source Identification Option.................................5 47 5. Receipt of Source Identification Option......................5 48 6. Issues for Further Consideration.............................7 49 Acknowledgements................................................7 50 References......................................................7 51 Authors' Address................................................8 52 1. Introduction 54 IPv6 Anycast addresses [RFC-1883] allow a datagram to be 55 addressed to a group of hosts with delivery to one and 56 preferably only one semantic. This facility can be used to 57 facilitate traffic path selection when a group identifies the 58 set of routers of a particular traffic provider. Other 59 possible uses of anycast addresses are to provide a "Host 60 Anycasting Service" [RFC-1546], where a set of hosts can 61 represent a particular service. While the particular 62 mechanisms hosts can use to provide services via anycast 63 addresses are still to be defined, this document attempts to 64 define a minimum set of requirements that should be 65 implemented in all IPv6 hosts in order to use those services. 67 The authors view a "Host Anycasting Service" as complementary, 68 rather than orthogonal, to Service Discovery mechanisms 69 [SVRLOC] since they can be used to provide lightweight service 70 access without the need for previous configuration. For 71 instance, a well-known site-local address can be used to 72 communicate with a host that provides service discovery 73 services. 75 While it is expected that the particular specifications 76 regarding anycast address usage by application servers and 77 routing are defined as extensions to IPv6 and companion 78 protocols, the authors feel that mechanisms needed in every 79 host should be defined before the massive deployment of IPv6 80 hosts. 82 The problems pertaining to the usage of anycast addresses for 83 accessing application services can be clearly divided in three 84 distinct components: procedures for hosts providing services 85 via anycast addresses, routing, and procedures in hosts 86 accessing services via anycast. This document focuses solely 87 on the later problem, as the authors consider that it can be 88 solved independently of the previous two. 90 2. Terminology and Definitions 92 IP 94 Internet Protocol Version 6 (IPv6). The terms IPv4 95 and IPv6 are used only in contexts where necessary 96 to avoid ambiguity. 98 Anycast Address 100 An identifier for a set of interfaces (typically 101 belonging to different nodes). A packet sent to an 102 anycast address is delivered to one of the 103 interfaces identified by that address (the "nearest" 104 one, according to the routing protocols' measure of 105 distance). 107 Communication 109 Any packet exchange between nodes that requires that 110 the address of each node used in the exchange remain 111 the same for the duration of the packet exchange. 112 Examples are a TCP connection or UDP 113 request/response. 115 3. Anycast address usage 117 Anycast addresses are restricted to be used as the destination 118 address of a datagram. This requirement is imposed by 119 necessity to determine the originating node of a datagram in 120 error conditions. Current transport protocols [RFC-768] 121 [RFC-793] rely, however, on the source address of the IP 122 datagram to demultiplex incoming packets. 124 Independently of how the network delivers datagrams addressed 125 to an anycast group, it's usage in normal communication 126 depends on the ability of a host to accept a datagram 127 originating from a distinct unicast address as a reply to a 128 packet sent to an anycast address. 130 Also, as anycast addresses are syntacticly indistinguishable 131 from unicast addresses, the client of a service provided via 132 anycast should not need explicit knowledge of whenever a 133 particular address is unicast or anycast, much less the 134 particular group membership for a particular anycast address. 136 To fulfill the above stated goals, the authors propose the 137 definition of a Destination Option, named Source 138 Identification Option, to dynamically inform client hosts that 139 a particular communication initiated through the use of an 140 anycast address should proceed with the use of a unicast 141 address of one of the anycast group members. 143 This option requires no processing from the network layer 144 other than encoding and decoding the respective extension 145 header and MUST be passed transparently from the network layer 146 to the transport layer. The transport layer MAY then take in 147 to account this information when demultiplexing datagrams. 148 Section 5 of this document discusses in more detail the 149 expected behavior of transport protocols when receiving a 150 datagram with this option. 152 Although this document does not pretend to specify the 153 mechanisms to be used by hosts providing a service through 154 anycast addresses, we note that a reply to a datagram received 155 for an anycast address will not be correctly interpreted if a 156 Source Identification Option is not present. 158 4. Source Identification Option 160 The Source Identification Option provides a mechanism hosts 161 can use to inform it's communications peers that datagram 162 demultiplexing by transport protocols should be performed with 163 respect to the identifier present in this option. This option 164 is encoded in the Destination Options Extension Header of IP 165 datagrams as option type TBD. 167 0 1 2 3 168 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Option Type | Option Len | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 | Identifier | 174 | | 175 | | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Option Type 180 8-bit identifier of the type of option. The first three 181 bits of the option are 000, indicating first that a node 182 receiving the option may discard the option and still 183 process the rest of the packet, and second that the option 184 may not be modified enroute. 186 Option Length 188 8-bit unsigned integer. Length of the Option Data field of 189 this option, in octets. 191 Identifier 193 128-bit IP address. The anycast address known to the 194 receiver of the datagram as the destination address of a 195 particular communication. 197 5. Receipt of Source Identification Option 199 As previously stated in section 3 of this document, a 200 transport protocol MAY take in account the identifier received 201 in a Source Identification Option for purposes of datagram 202 demultiplexing. 204 TCP [RFC-793] communication depends on the knowledge of state 205 information by communicating peers, initialized on a 206 synchronization period referred to as the "three way 207 handshake". In terms of access to a service provided via the 208 use of anycast address, procedures must be provided to insure 209 correct synchronization between the client and a member of the 210 anycast group, and to maintain the same communication end- 211 points during the duration of the connection. 213 An IP node performing a TCP active open sends a segment to the 214 network addressed to the destination address of the 215 connection. It then expects to receive a segment from this 216 address confirming or rejecting the connection establishment 217 request. When the destination address of the connection is an 218 anycast address this condition cannot be met since the 219 responding host may not send datagrams using an anycast 220 address as source address in datagrams. In this scenario, the 221 responding node should use the Source Identification Option, 222 with the destination address on the received syn segment as an 223 identifier, in order to inform the node performing the active 224 open that the segment is related to this communication. 226 A TCP performing an active open MAY then use the IP address 227 present on the Source Identification Option to demultiplex the 228 incoming segment. If the segment causes TCP to proceed to 229 SYN-RECEIVED or ESTABLISHED it MUST then consider that the 230 destination address of the connection is the source address 231 present on the received segment. 233 Note that for TCP, the receipt of a Source Identification 234 Option is meaningful only when the segment refers to a 235 connection on the SYN-SENT state. Otherwise, this option 236 should be ignored by TCP. This will cause the received segment 237 to be interpreted as a segment to a connection in the CLOSED 238 state, assuming that no communication is taking place between 239 the same address/port pairs. 241 Datagram exchanges using UDP [RFC-768] constitute a more 242 problematic case. While UDP is itself connectionless, many 243 applications using this transport protocol require state to be 244 maintained. This implies that while some applications desire 245 to communicate with any of the members of the anycast group, 246 others can only tolerate anycast initiated communication 247 requiring subsequent packets to be delivered to the same host. 249 Since the appropriate semantics of anycast address usage on 250 UDP communication are application dependent, a UDP 251 implementation should only take in to account the Source 252 Identification Option when this behavior has been explicitly 253 requested by the application. When such option is selected by 254 the application incoming datagrams containing a Source 255 Identification Option shall be demultiplexed and delivered to 256 the application using the identifier contained in the option 257 as the source address of the datagram. Otherwise, the Source 258 Identification Option should be ignored by a UDP 259 implementation. 261 As UDP already provides a means for determination of the 262 originating node of a received datagram by applications, no 263 further modifications are required to allow the use of this 264 service with the desired semantics. 266 6. Issues for Further Consideration 268 Security considerations. 270 Receipt of a RST segment carried in a datagram containing a 271 Source Identification Option. 273 According to [RFC-793], a segment containing a valid 274 acknowledgement value and the RST bit on for a TCP 275 connection in SYN-SENT state, will cause the connection to 276 enter the CLOSED state. In the specific case of an active 277 open to an anycast address, this abortive termination could 278 be caused by a failure from one of the group members. The 279 appropriate action to take in this case is an issue for 280 further study. 282 Acknowledgements 284 We would like to thank Dan Harrington and Mike Shand who have 285 provided comments and review of an earlier version of this work. 287 References 289 [RFC-768] 290 J. Postel, "User Datagram Protocol", STD-6, August 1980. 292 [RFC-793] 293 J. Postel, "Transmission Control Protocol", STD-7, September 294 1981. 296 [RFC-1546] 297 C. Partridge, T. Mendez, W. Milliken, "Host Anycasting 298 Service", Informational Request for Comments, November 1993. 300 [RFC-1883] 301 S. Deering and R. Hinden, "Internet Protocol Version 6, 302 (IPv6) Specification" Proposed Standard, December 1995. 304 [SVRLOC] 305 J. Veizades, E. Guttman, C. Perkins and S. Kaplan, "Service 306 Location Protocol", Internet Draft, March 1996, 309 Authors' Address 311 Jim Bound 312 Digital Equipment Corporation 313 110 Spitbrook Road, ZKO3-3/U14 314 Nashua, NH 03062 315 Phone: (603) 881-0400 316 Email: bound@zk3.dec.com 318 Pedro Roque 319 Departamento de Inform'atica 320 Faculdade de Ciencias da Universidade de Lisboa 321 Campo Grande - Bloco C5 322 1700 Lisboa, Portugal 323 Email: roque@di.fc.ul.pt