idnits 2.17.1 draft-ubillos-name-based-sockets-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 17, 2010) is 4960 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5533' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'RFC5534' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'I-D.cotton-tsvwg-iana-ports' is defined on line 400, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Ubillos 3 Internet-Draft Swedish Institute of Computer 4 Intended status: Experimental Science 5 Expires: March 21, 2011 M. Xu 6 Z. Ming 7 Tsinghua University 8 C. Vogt 9 Ericsson 10 September 17, 2010 12 Name-Based Sockets Architecture 13 draft-ubillos-name-based-sockets-03 15 Abstract 17 This memo defines Name-based sockets. name-based sockets allow 18 application developers to refer to remote hosts (and it self) by name 19 only, passing on all IP (locator) management to the operating system. 20 Applications are thus relieved of re-implementing features such as 21 multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and 22 address management in general. The operating system can in turn re- 23 use the same solutions for a whole set of guest applications. name- 24 based sockets aims to provide a whole set of features without adding 25 new indirection layers, new delays or other dependences while 26 maintaining transparent backwards compatibility. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 21, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.3. Compatibility goals . . . . . . . . . . . . . . . . . . . . 4 68 3.3.1. Network compatibility . . . . . . . . . . . . . . . . . 4 69 3.3.2. Application compatibility . . . . . . . . . . . . . . . 4 70 3.4. name-based sockets overview . . . . . . . . . . . . . . . . 4 71 3.5. Protocol overview . . . . . . . . . . . . . . . . . . . . . 5 72 4. Initial name exchange . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Name format . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.2. Service names (and port numbers) . . . . . . . . . . . . . 7 75 4.3. Transport selection . . . . . . . . . . . . . . . . . . . . 7 76 5. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 79 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 83 9.3. URL References . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Conventions 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. Terminology 93 Locator - An IP address (v4 or v6) on which a host can be reached. 95 Name - A character string (max 255 chars long) on which a host can be 96 identified. 98 3. Overview 100 3.1. Introduction 102 name-based sockets provide a unified interface which caters to the 103 application developers who wish to simply open up a communication to 104 a remote host by its name and have the operating system perform the 105 management of locators. 107 It does so by providing a new address family (AF_NAME) which allows 108 the developer to use a name instead of an IP (or other locator). 110 3.2. Motivation 112 Network communication has for very long been based on the assumption 113 that applications should deal with the IP (locator) management. This 114 is based on the legacy notion that an IP does not change during a 115 session and that a session is a communication between two given IPs 116 (locators). This situation has changed, locators change during a 117 session, and a device/host might have multiple locators, hosts may be 118 behind NA(P)Ts or be on different locator domains (e.g. IPv4/IPv6). 119 Today, this is mostly left to the individual applications to solve. 120 This adds complexity to the applications making it a challenge in it 121 self just to meet the networking demands of applications. 123 Name-based sockets aims to fix this by pushing the locator management 124 to the operating system, without introducing any new limitations or 125 delays. 127 By approaching the problem at the socket() level, existing 128 abstraction frameworks can easily benefit from a change. By allowing 129 the existing abstractions to simply pass along the name the whole way 130 down to the socket() call, the abstraction or whole framework are 131 able to benefit by name-based sockets. 133 Note that name-based sockets do not aim to replace all socket() based 134 communications. There are of course cases which are limited due to 135 obvious boot-strapping problems. E.g. a DHCP client, or an DNS- 136 querying client would do better in not using a name oriented 137 architecture. 139 3.3. Compatibility goals 141 3.3.1. Network compatibility 143 1. Minimal changes to "on the wire" protocol. 145 2. No changes to added 'features' 147 3.3.2. Application compatibility 149 The objective is to maintain the (BSD) socket() semantics commonly 150 used today. It is important that the transition for developers 151 should be trivial. 153 Maintaining these semantics allows existing abstraction frameworks to 154 integrate name-based sockets to their frameworks. Socket 155 abstractions are often used to simplify the use of a service e.g. 156 HTTP. In those cases, they do not add functionality at the network 157 or transport layer. These kinds of abstraction frameworks would 158 quickly be able to make use of the extra functionality provided by 159 name-based sockets. 161 3.4. name-based sockets overview 163 name-based sockets provide a new socket interface. It is implemented 164 using a new address family (AF_NAME). This means that the sockets 165 are only used by applications who explicitly invoke it. The result 166 is that applications that do use name based sockets are very aware of 167 the set of features they are provided with, hence they know not to 168 re-implement them. Current implementations are implemented as kernel 169 modules, however a user-space library implementation ought to work 170 just as well. 172 By using DNS as the ID/Locator mapping structure, we do not introduce 173 any new indirections. Please note that the responding host does not 174 need to do any reverse-DNS resolution (explained below). We part 175 from the assumption that most application network calls start with a 176 FQDN. 178 The exchange of names is performed in-band, by piggy-backing the 179 needed information on the first couple of packets exchanged. The 180 consequence is: 182 o No extra delays 184 o No extra features until the name exchange has ended. 186 o As a result of this, we also achieve backwards compatibility (a 187 name exchange which never completes) 189 3.5. Protocol overview 191 name-based sockets work by performing a name exchange in the 192 beginning of a communication. It does this in an non-blocking way. 193 In practice what happens is that the first few packets are exchanged 194 in a normal legacy fashion. However, to these packets, extra 195 information about the corresponding hosts names are piggy-backed. If 196 a name exchange is successful, the extra features provided by name- 197 based sockets are enabled. If the exchange does not succeed, normal 198 legacy communication continues unaffected. 200 The name of each host is either its FQDN, its IP in IPv6.arpa format 201 or an arbitrary nonce. It may or may not be authenticated. In the 202 ordinary case, the name is not authenticated, thus the receiver does 203 not need to perform a reverse or forward lookup, hence not adding any 204 further delays to the first packet(s). The motivation for this is to 205 avoid any additional "first-packet" delays. 207 Once the name exchange has been performed successfully the complete 208 feature set will be made available to the communication 209 automatically. 211 The expected API for a socket using AF_NAME is the same as for e.g. 212 TCP (SOCK_STREAM). This is also the case for SOCK_DGRAM and similar 213 protocols, for all practical purposes, the functionality remains 214 unchanged, however, as state is created in both ends, connection 215 oriented semantics are more intuitive. 217 4. Initial name exchange 219 When the sender sends the first packet to the receiver it appends its 220 own name as an IP-Option/IPv6-Extension header. It repeats this for 221 a predefined amount of time or packets. On the receiving end, if the 222 receiver supports name-based sockets it appends its own name in the 223 same fashion for a predefined amount of time or packets. Should the 224 receiver not be able to interpret the name, the option/extension 225 header is ignored and the legacy communication precedes as normal. 227 This kind of name exchange has two consequences. First and foremost 228 that there are no extra delays on the initial packets. Secondly that 229 the complete feature set provided by name based sockets will not be 230 available until a few packets have been exchanged. 232 In figure 1 the exchange is depicted. The first packet from the 233 sender has its own name appended to it. The next few packets sent 234 will also have the name appended to it for a predefined number of 235 packets (X in the figure) or until a reply including a name extension 236 is received. On the receiving end, should an incoming packet have a 237 name extension, the receiver begins to append its own name to the 238 sent packets. It does so for a predefined number of packets (X in 239 the figure). 241 .--------. .----------. 242 | Sender | | Receiver | 243 '--------' '----------' 244 | | 245 | | 246 | .-------------------. | 247 | ------| Data packet |-----> | Packet received. 248 | |+ name piggybacked | | The first response 249 | '-------------------' | packet will have 250 | ----------> | the receiver name 251 | -------> | piggy backed to it. 252 | ----> .-----------------------. | 253 | -> | name piggybacked | | 254 | | until reply or X pkts | | 255 | '-----------------------' | 256 | | 257 | | 258 | | 259 | .-------------------. | 260 | <------| Data packet |----- | 261 | |+ name piggybacked | | 262 | '-------------------' | 263 | <---------- | 264 | <------- | 265 | .------------------. <---- | 266 | | name piggybacked | <- | 267 | | until X pkts | | 268 | '------------------' | 269 | | 270 | | 272 Figure 1 274 4.1. Name format 276 Names can be provided in any of three ways. 278 o FQDN. The Fully Qualified Domain Name of the host. This will 279 allow e.g. DNSsec to provide authenticity of the name. 281 o ip6.arpa. Using one of the hosts interfaces addresses as a name. 283 o Nonce. A one-use only session identifier. 285 4.2. Service names (and port numbers) 287 Services are identified by a string. For compatibility reasons, it 288 is reasonable to use the "Keyword" field as an identifier of the 289 service in question. 291 Excerpt from http://www.iana.org/assignments/port-numbers 293 Keyword Decimal Description References 294 ------- ------- ----------- ---------- 295 http 80/tcp World Wide Web HTTP 296 http 80/udp World Wide Web HTTP 297 www 80/tcp World Wide Web HTTP 298 www 80/udp World Wide Web HTTP 299 www-http 80/tcp World Wide Web HTTP 300 www-http 80/udp World Wide Web HTTP 301 http 80/sctp HTTP 303 Keyword and port number mappings. 305 4.3. Transport selection 307 Often today, the transport protocol is implied by the service in 308 question. How this is handled remains to be defined. It is however 309 likely that a default transport protocol can be provided depending on 310 which service is requested. 312 5. API 314 The API follows the connection oriented model, e.g. TCP. The 315 available calls are: 317 listen(): Prep for incoming session 318 fd = listen( local_name, peer_name, service, transport ); 320 open(): Initiate outgoing session 322 fd = open( local_name, peer_name, service, transport ); 324 accept(): Receive incoming session 326 accept( peer_name, fd ); 328 read(): Receive data 330 data = read( fd ); 332 write(): Send data 334 write( fd, data ); 336 close(): Close session 338 close( fd ); 340 Note: In the above examples 342 local_name The local identifier. Either an explicit name or a 343 wildcard (*). As host may have multiple names, to choose which to 344 listen to, a name must be chosen or a wildcard may be used. In 345 the latter case, on listening, any destination name is accepted; 346 on send, an arbitrary name (valid for the host) may automatically 347 be chosen by the socket. 349 peer_name The remote identifier. Either an explicit name or a 350 wildcard (*). In the accept() function, a wildcard might be 351 inserted. In this case, all incoming packets will be accepted, 352 independent of sender name. 354 service The service to be run. In general this will correspond to 355 the keyword field in the IANA Port Numbers registry. E.g. http, 356 ftp and ssh. 358 transport Transport refers to the chosen transport protocol. This 359 could be e.g. 361 * TCP (SOCK_STREAM) 363 * UDP (SOCK_DGRAM) 364 * SCTP (SOCK_SCTP) 366 * DCCP (SOCK_DCCP) 368 * NORM ... 370 * And so on ... 372 6. Security Considerations 374 7. IANA Considerations 376 name-based sockets requires a new address family (AF_NAME) to be 377 defined. 379 8. Contributors 381 9. References 383 9.1. Normative References 385 [RFC2119] Bradner, S., "Key words for use in 386 RFCs to Indicate Requirement Levels", 387 BCP 14, RFC 2119, March 1997. 389 9.2. Informative References 391 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: 392 Level 3 Multihoming Shim Protocol for 393 IPv6", RFC 5533, June 2009. 395 [RFC5534] Arkko, J. and I. van Beijnum, "Failure 396 Detection and Locator Pair Exploration 397 Protocol for IPv6 Multihoming", 398 RFC 5534, June 2009. 400 [I-D.cotton-tsvwg-iana-ports] Cotton, M., Eggert, L., Mankin, A., 401 and M. Westerlund, "IANA Allocation 402 Guidelines for TCP and UDP Port 403 Numbers", 404 draft-cotton-tsvwg-iana-ports-00 (work 405 in progress), February 2008. 407 9.3. URL References 408 Authors' Addresses 410 Javier Ubillos 411 Swedish Institute of Computer Science 412 Kistagangen 16 413 Kista 414 Sweden 416 Phone: +46767647588 417 EMail: jav@sics.se 419 Mingwei Xu 420 Tsinghua University 421 FIT Building 4-104, Tsinghua University 422 Beijing 423 China 425 EMail: xmw@cernet.edu.cn 427 Zhongxing Ming 428 Tsinghua University 429 FIT Building 4-104, Tsinghua University 430 Beijing 431 China 433 EMail: mingzx@126.com 435 Christian Vogt 436 Ericsson 437 200 Holger Way 438 San Jose, CA 95134-1300 439 USA 441 EMail: christian.vogt@ericsson.com