Internet Engineering Task Force Ubillos Internet-Draft Swedish Institute of Computer Intended status: Historic Science Expires: January 4, 2011 Ming Tsinghua University July 3, 2010 Name Based Sockets draft-ubillos-name-based-sockets-00 Abstract This memo defines the name based sockets. A new address family (AF_NAME) allows the application developer to pass on all IP (locator) management to the operating system. Applications are thus relieved of re-implementing features such as multi-homing, mobility and general address management and allowing the operating system can re-use the same solutions for a whole set of guest applications. 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 January 4, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Ubillos & Ming Expires January 4, 2011 [Page 1] Internet-Draft Name Based Sockets July 2010 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. Protocol overview . . . . . . . . . . . . . . . . . . . . . 3 5. Initial name exchange . . . . . . . . . . . . . . . . . . . . . 4 5.1. Name format . . . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Names (FQDN & ip6.arpa) . . . . . . . . . . . . . . . . . . 4 6. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Mobility support . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1.1. Brief overview of changes . . . . . . . . . . . . . . . 5 7.1.2. The hand-shake with name exchange . . . . . . . . . . . 5 7.1.3. Identity change . . . . . . . . . . . . . . . . . . . . 5 7.1.4. Triggers of shim6 . . . . . . . . . . . . . . . . . . . 5 7.1.5. Establishing Shim6 context . . . . . . . . . . . . . . 5 7.1.6. Problems for Shim6 to support mobility . . . . . . . . 5 7.1.7. Changes to REAP . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 11.1. Normative References . . . . . . . . . . . . . . . . . . . 6 11.2. Informative References . . . . . . . . . . . . . . . . . . 6 11.3. URL References . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 6 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 6 Ubillos & Ming Expires January 4, 2011 [Page 2] Internet-Draft Name Based Sockets July 2010 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the [TEMPLATE TODO]. 2. 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]. 3. Terminology 4. Overview 4.1. Motivation Network communication has for very long been based on the assumption that applications should deal with the IP 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 NATs or be on different networks (IPv4/IPv6). Today, this is mostly left to the individual applications to solve. This added complexity to the applications makes it a challenge in it self just to meet the networking demands. 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. This without doing any worse than the offered solutions today. Note: 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. 4.2. 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 Ubillos & Ming Expires January 4, 2011 [Page 3] Internet-Draft Name Based Sockets July 2010 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 a state is created in both ends, a connection oriented model is more intuitive. 5. 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 available until a few packets have been exchanged. 5.1. Name format TBD 5.2. Names (FQDN & ip6.arpa) Names can be provided in any of three ways. FQDN. The Fully Qualified Domain Name of the host. This will allow e.g. DNSsec to provide authenticity of the name. ip6.arpa. Using one of the hosts interfaces addresses as a name. Ubillos & Ming Expires January 4, 2011 [Page 4] Internet-Draft Name Based Sockets July 2010 Nonce. A one-use only session identifier. 6. API TBD 7. Mobility support 7.1. Shim6 From RFC5533: "... The Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. " [RFC5533] 7.1.1. Brief overview of changes TBD 7.1.2. The hand-shake with name exchange TBD 7.1.3. Identity change TBD 7.1.4. Triggers of shim6 TBD 7.1.5. Establishing Shim6 context TBD 7.1.6. Problems for Shim6 to support mobility TBD Ubillos & Ming Expires January 4, 2011 [Page 5] Internet-Draft Name Based Sockets July 2010 7.1.6.1. DNS querying TBD 7.1.6.2. One peer moves TBD 7.1.6.3. Both peers move TBD 7.1.7. Changes to REAP TBD 8. Security Considerations 9. IANA Considerations This memo includes no request to IANA. 10. Contributors 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. 11.3. URL References Appendix A. Change Log Note to RFC Editor: if this document does not obsolete an existing RFC, please remove this appendix before publication as an RFC. Appendix B. Open Issues Note to RFC Editor: please remove this appendix before publication as an RFC. Ubillos & Ming Expires January 4, 2011 [Page 6] Internet-Draft Name Based Sockets July 2010 Authors' Addresses Javier Ubillos Swedish Institute of Computer Science Kistagangen 16 Kista Sweden Phone: +46767647588 EMail: jav@sics.se Zhongxing Ming Tsinghua University FIT Building 4-104, Tsinghua University Beijing China Phone: + EMail: mingzx@126.com Ubillos & Ming Expires January 4, 2011 [Page 7]