Internet Engineering Task Force J. Ubillos Internet-Draft Swedish Institute of Computer Intended status: Experimental Science Expires: March 21, 2011 M. Xu Z. Ming Tsinghua University C. Vogt Ericsson September 17, 2010 Name-Based Sockets Architecture draft-ubillos-name-based-sockets-03 Abstract This memo defines Name-based sockets. name-based sockets allow application developers to refer to remote hosts (and it self) by name only, passing on all IP (locator) management to the operating system. Applications are thus relieved of re-implementing features such as multi-homing, mobility, NAT traversal, IPv6/IPv4 interoperability and address management in general. The operating system can in turn re- use the same solutions for a whole set of guest applications. name- based sockets aims to provide a whole set of features without adding new indirection layers, new delays or other dependences while maintaining transparent backwards compatibility. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Ubillos, et al. Expires March 21, 2011 [Page 1] Internet-Draft Name-Based Sockets Architecture September 2010 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Compatibility goals . . . . . . . . . . . . . . . . . . . . 4 3.3.1. Network compatibility . . . . . . . . . . . . . . . . . 4 3.3.2. Application compatibility . . . . . . . . . . . . . . . 4 3.4. name-based sockets overview . . . . . . . . . . . . . . . . 4 3.5. Protocol overview . . . . . . . . . . . . . . . . . . . . . 5 4. Initial name exchange . . . . . . . . . . . . . . . . . . . . . 5 4.1. Name format . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Service names (and port numbers) . . . . . . . . . . . . . 7 4.3. Transport selection . . . . . . . . . . . . . . . . . . . . 7 5. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 9.3. URL References . . . . . . . . . . . . . . . . . . . . . . 9 Ubillos, et al. Expires March 21, 2011 [Page 2] Internet-Draft Name-Based Sockets Architecture September 2010 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Terminology Locator - An IP address (v4 or v6) on which a host can be reached. Name - A character string (max 255 chars long) on which a host can be identified. 3. Overview 3.1. Introduction name-based sockets provide a unified interface which caters to the application developers who wish to simply open up a communication to a remote host by its name and have the operating system perform the management of locators. It does so by providing a new address family (AF_NAME) which allows the developer to use a name instead of an IP (or other locator). 3.2. Motivation Network communication has for very long been based on the assumption that applications should deal with the IP (locator) management. This is based on the legacy notion that an IP does not change during a session and that a session is a communication between two given IPs (locators). This situation has changed, locators change during a session, and a device/host might have multiple locators, hosts may be behind NA(P)Ts or be on different locator domains (e.g. IPv4/IPv6). Today, this is mostly left to the individual applications to solve. This adds complexity to the applications making it a challenge in it self just to meet the networking demands of applications. Name-based sockets aims to fix this by pushing the locator management to the operating system, without introducing any new limitations or delays. By approaching the problem at the socket() level, existing abstraction frameworks can easily benefit from a change. By allowing the existing abstractions to simply pass along the name the whole way down to the socket() call, the abstraction or whole framework are able to benefit by name-based sockets. Ubillos, et al. Expires March 21, 2011 [Page 3] Internet-Draft Name-Based Sockets Architecture September 2010 Note that name-based sockets do not aim to replace all socket() based communications. There are of course cases which are limited due to obvious boot-strapping problems. E.g. a DHCP client, or an DNS- querying client would do better in not using a name oriented architecture. 3.3. Compatibility goals 3.3.1. Network compatibility 1. Minimal changes to "on the wire" protocol. 2. No changes to added 'features' 3.3.2. Application compatibility The objective is to maintain the (BSD) socket() semantics commonly used today. It is important that the transition for developers should be trivial. Maintaining these semantics allows existing abstraction frameworks to integrate name-based sockets to their frameworks. Socket abstractions are often used to simplify the use of a service e.g. HTTP. In those cases, they do not add functionality at the network or transport layer. These kinds of abstraction frameworks would quickly be able to make use of the extra functionality provided by name-based sockets. 3.4. name-based sockets overview name-based sockets provide a new socket interface. It is implemented using a new address family (AF_NAME). This means that the sockets are only used by applications who explicitly invoke it. The result is that applications that do use name based sockets are very aware of the set of features they are provided with, hence they know not to re-implement them. Current implementations are implemented as kernel modules, however a user-space library implementation ought to work just as well. By using DNS as the ID/Locator mapping structure, we do not introduce any new indirections. Please note that the responding host does not need to do any reverse-DNS resolution (explained below). We part from the assumption that most application network calls start with a FQDN. The exchange of names is performed in-band, by piggy-backing the needed information on the first couple of packets exchanged. The consequence is: Ubillos, et al. Expires March 21, 2011 [Page 4] Internet-Draft Name-Based Sockets Architecture September 2010 o No extra delays o No extra features until the name exchange has ended. o As a result of this, we also achieve backwards compatibility (a name exchange which never completes) 3.5. Protocol overview name-based sockets work by performing a name exchange in the beginning of a communication. It does this in an non-blocking way. In practice what happens is that the first few packets are exchanged in a normal legacy fashion. However, to these packets, extra information about the corresponding hosts names are piggy-backed. If a name exchange is successful, the extra features provided by name- based sockets are enabled. If the exchange does not succeed, normal legacy communication continues unaffected. The name of each host is either its FQDN, its IP in IPv6.arpa format or an arbitrary nonce. It may or may not be authenticated. In the ordinary case, the name is not authenticated, thus the receiver does not need to perform a reverse or forward lookup, hence not adding any further delays to the first packet(s). The motivation for this is to avoid any additional "first-packet" delays. Once the name exchange has been performed successfully the complete feature set will be made available to the communication automatically. The expected API for a socket using AF_NAME is the same as for e.g. TCP (SOCK_STREAM). This is also the case for SOCK_DGRAM and similar protocols, for all practical purposes, the functionality remains unchanged, however, as state is created in both ends, connection oriented semantics are more intuitive. 4. Initial name exchange When the sender sends the first packet to the receiver it appends its own name as an IP-Option/IPv6-Extension header. It repeats this for a predefined amount of time or packets. On the receiving end, if the receiver supports name-based sockets it appends its own name in the same fashion for a predefined amount of time or packets. Should the receiver not be able to interpret the name, the option/extension header is ignored and the legacy communication precedes as normal. This kind of name exchange has two consequences. First and foremost that there are no extra delays on the initial packets. Secondly that the complete feature set provided by name based sockets will not be Ubillos, et al. Expires March 21, 2011 [Page 5] Internet-Draft Name-Based Sockets Architecture September 2010 available until a few packets have been exchanged. In figure 1 the exchange is depicted. The first packet from the sender has its own name appended to it. The next few packets sent will also have the name appended to it for a predefined number of packets (X in the figure) or until a reply including a name extension is received. On the receiving end, should an incoming packet have a name extension, the receiver begins to append its own name to the sent packets. It does so for a predefined number of packets (X in the figure). .--------. .----------. | Sender | | Receiver | '--------' '----------' | | | | | .-------------------. | | ------| Data packet |-----> | Packet received. | |+ name piggybacked | | The first response | '-------------------' | packet will have | ----------> | the receiver name | -------> | piggy backed to it. | ----> .-----------------------. | | -> | name piggybacked | | | | until reply or X pkts | | | '-----------------------' | | | | | | | | .-------------------. | | <------| Data packet |----- | | |+ name piggybacked | | | '-------------------' | | <---------- | | <------- | | .------------------. <---- | | | name piggybacked | <- | | | until X pkts | | | '------------------' | | | | | Figure 1 Ubillos, et al. Expires March 21, 2011 [Page 6] Internet-Draft Name-Based Sockets Architecture September 2010 4.1. Name format Names can be provided in any of three ways. o FQDN. The Fully Qualified Domain Name of the host. This will allow e.g. DNSsec to provide authenticity of the name. o ip6.arpa. Using one of the hosts interfaces addresses as a name. o Nonce. A one-use only session identifier. 4.2. Service names (and port numbers) Services are identified by a string. For compatibility reasons, it is reasonable to use the "Keyword" field as an identifier of the service in question. Excerpt from http://www.iana.org/assignments/port-numbers Keyword Decimal Description References ------- ------- ----------- ---------- http 80/tcp World Wide Web HTTP http 80/udp World Wide Web HTTP www 80/tcp World Wide Web HTTP www 80/udp World Wide Web HTTP www-http 80/tcp World Wide Web HTTP www-http 80/udp World Wide Web HTTP http 80/sctp HTTP Keyword and port number mappings. 4.3. Transport selection Often today, the transport protocol is implied by the service in question. How this is handled remains to be defined. It is however likely that a default transport protocol can be provided depending on which service is requested. 5. API The API follows the connection oriented model, e.g. TCP. The available calls are: listen(): Prep for incoming session Ubillos, et al. Expires March 21, 2011 [Page 7] Internet-Draft Name-Based Sockets Architecture September 2010 fd = listen( local_name, peer_name, service, transport ); open(): Initiate outgoing session fd = open( local_name, peer_name, service, transport ); accept(): Receive incoming session accept( peer_name, fd ); read(): Receive data data = read( fd ); write(): Send data write( fd, data ); close(): Close session close( fd ); Note: In the above examples local_name The local identifier. Either an explicit name or a wildcard (*). As host may have multiple names, to choose which to listen to, a name must be chosen or a wildcard may be used. In the latter case, on listening, any destination name is accepted; on send, an arbitrary name (valid for the host) may automatically be chosen by the socket. peer_name The remote identifier. Either an explicit name or a wildcard (*). In the accept() function, a wildcard might be inserted. In this case, all incoming packets will be accepted, independent of sender name. service The service to be run. In general this will correspond to the keyword field in the IANA Port Numbers registry. E.g. http, ftp and ssh. transport Transport refers to the chosen transport protocol. This could be e.g. * TCP (SOCK_STREAM) * UDP (SOCK_DGRAM) Ubillos, et al. Expires March 21, 2011 [Page 8] Internet-Draft Name-Based Sockets Architecture September 2010 * SCTP (SOCK_SCTP) * DCCP (SOCK_DCCP) * NORM ... * And so on ... 6. Security Considerations 7. IANA Considerations name-based sockets requires a new address family (AF_NAME) to be defined. 8. Contributors 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009. [I-D.cotton-tsvwg-iana-ports] Cotton, M., Eggert, L., Mankin, A., and M. Westerlund, "IANA Allocation Guidelines for TCP and UDP Port Numbers", draft-cotton-tsvwg-iana-ports-00 (work in progress), February 2008. 9.3. URL References Ubillos, et al. Expires March 21, 2011 [Page 9] Internet-Draft Name-Based Sockets Architecture September 2010 Authors' Addresses Javier Ubillos Swedish Institute of Computer Science Kistagangen 16 Kista Sweden Phone: +46767647588 EMail: jav@sics.se Mingwei Xu Tsinghua University FIT Building 4-104, Tsinghua University Beijing China EMail: xmw@cernet.edu.cn Zhongxing Ming Tsinghua University FIT Building 4-104, Tsinghua University Beijing China EMail: mingzx@126.com Christian Vogt Ericsson 200 Holger Way San Jose, CA 95134-1300 USA EMail: christian.vogt@ericsson.com Ubillos, et al. Expires March 21, 2011 [Page 10]