<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-liu-mif-socket-api-00" ipr="trust200902">
  <front>
    <title abbrev="Abbreviated-Title">Socket API Extension for MIF PvD
    Architecture</title>

    <author fullname="Dapeng Liu" initials="D." surname="Liu">
      <organization> </organization>

      <address>
        <email>maxpassion@gmail.com</email>
      </address>
    </author>

    <date day="5" month="July" year="2015"/>

    <workgroup>MIF</workgroup>

    <abstract>
      <t>IETF MIF working group defines the multiple provisioning domain
      architecture. This document proposes API extension for the PvD-aware
      node to support the MIF PvD architecture.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>IETF MIF working group defines the multiple provisioning domain
      architecture in <xref
      target="mpvd-architecture">draft-ietf-mif-mpvd-arch-10</xref> . It
      defines three levels of PvD support in API: basic, intermediate and
      advanced. This document discusses the advanced PvD API for the PvD-aware
      node.</t>

      <t/>
    </section>

    <section title="Current PvD-related API implementation">
      <t>This section summarize the PvD related API implementations. The
      purpose of this section is to help analyzing the extension of current
      API implementation to support PvD architecture.</t>

      <section title="PvD-related API Implementation in Socket API">
        <t>The basic socket API includes the following:</t>

        <t>Socket API for a typical server:</t>

        <t><list style="symbols">
            <t>socket()</t>

            <t>bind()</t>

            <t>listen()</t>

            <t>recvmsg()</t>

            <t>sendmsg()</t>

            <t>close()</t>
          </list></t>

        <t>Socket API for a typical client:</t>

        <t><list style="symbols">
            <t>socket()</t>

            <t>connect()</t>

            <t>sendmsg()</t>

            <t>recvmsg()</t>

            <t>close()</t>
          </list></t>

        <t><xref target="RFC3493"/> extends the basic socket API to
        support IPv6. It defines the IPv6 Address Family and Protocol Family
        and also the socket address structure, socket options etc.</t>

        <t><xref target="RFC3542"/> defines the advanced sockets API for IPv6.
        It defines the socket API to access IPv6 specific parameters. For
        example, the IPv6 raw socket, the API to access IPv6 and extension
        headers etc.</t>

        <t><xref target="RFC5014"/> defines the IPv6 socket API extension for
        source address selection. It can be used to override the default
        source address selection method as defined in <xref target="RFC3484"/>
        . It defines an address preference flags that used for the source
        address selection. Developers can use this API to explicitly specify
        the source address to be used in the communication. Example of use
        cases of this source address selection API includes applications that
        supporting Mobile IPv6, IPv6 Privacy Extensions, Cryptographically
        Generated Addresses etc. It uses per-socket and per-packet flags to
        implement the source address selection. It adds a new socket option at
        the IPPROTO_IPV6 level. The new option is called
        IPV6_ADDR_PREFERENCES. It can be used with setsockopt() and
        getsockopt() calls to set and get the address selection preferences
        affecting all packets sent via a given socket.</t>

        <t/>
      </section>
    </section>

    <section title="Extension for PvD advanced API">
      <t>This section defines the extension of socket API to support PvD
      architecture as defined in <xref target="mpvd-architecture"/></t>

      <t>It belongs to the advanced PvD API discussed in section 6.3 of <xref
      target="mpvd-architecture"/>. The extension proposed in this document
      has the following types of API extension:<list style="symbols">
          <t>API to get current PvDs that been provided to the node</t>

          <t>API to explicitly select a PvD</t>

          <t>API for DNS resolution</t>
        </list>There are different design alternatives for the PvD API.
      Including:<list style="symbols">
          <t>Get PvDs and select PvD per-socket.</t>

          <t>Get PvDs and select PvD per-application.</t>

          <t>Get PvDs and select PvD per-node.</t>
        </list> This document propose the per-socket approach since it can
      provide the maximal flexibility for the application developers to meet
      all the kinds of use cases.</t>

      <t/>

      <section title="Get PvD Configuration API">
        <t>The following API is used to get the current PvD configuration of
        the node:</t>

        <t><list style="symbols">
            <t>getpvdinfo()</t>
          </list>The definition of this API is:</t>

        <t>int getpvdinfo(const char *nodename, const char *servname, struct
        pvdinfo **res);</t>

        <t>The structure of struct pvdinfo is:</t>

        <t>struct pvdinfo {</t>

        <t>int sockaddr * ai_addr;</t>

        <t>int sockaddr * gateway_addr;</t>

        <t>int sockaddr * dns_addr;</t>

        <t>struct addrinfo * ai_next;</t>

        <t>}</t>

        <t>The definition of parameters is as follows:</t>

        <t><list style="symbols">
            <t>nodename and servname: The nodename and servname parameter are
            pointers to null-terminated strings or NULL. One or both of these
            parameter must be a non-null pinter. A non-null nodename string
            can be a node name or a numeric host address string.</t>

            <t>res: The pvdinfo structure. The result is pointed to res
            structure.</t>
          </list></t>
      </section>

      <section title="Set PvD API">
        <t>The following API is used to select the specific PvD.</t>

        <t><list style="symbols">
            <t>setsockopt()</t>
          </list>setsockopt(int s, struct * pvdinfo pvd)</t>

        <t>The struct * pvdinfo pvd is a new parameter that used to specify the preferred PvD. The socket can be set to use the PvD that specified by
        pvdinfo parameter. </t>

        <t>All the socket related operation will be bind to this
        PvD. For example, The connect() API call should use the set of configuration parameters that
        contained in the pvdinfo (source address, gateway and
        DNS etc).</t>
      </section>

      <section title="DNS Resolution">
        <t>
          getaddrinfo() is the socket API used to resolve the IPv4 and IPv6
          address. This document proposes to extend getaddrinfo() socket API
          to allow it use PvD information as a parameter for DNS resolution.
        </t>
        <t>
          int getaddrinfo( const char * hostname, const char * service, const struct addrinfo * hints,struct * pvdinfo pvd, struct addrinfo ** result );
        </t>
        <t>
          The DNS resolution should use the DNS server that contained in the
          PvD parameter.
        </t>

      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t/>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
        The author would like to thank the PvD API design team.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="mpvd-architecture">
        <front>
          <title>Multiple Provisioning Domain Architecture</title>

          <author fullname="D. Anipko" initials="D. " surname="Anipko">
            <organization>Sun Microsystems, Inc.</organization>
          </author>

          <date day="09" month="February" year="2015"/>
        </front>
      </reference>

      <reference anchor="RFC3493">
        <front>
          <title>Basic Socket Interface Extensions for IPv6</title>

          <author fullname="R. Gilligan" initials="R." surname="Gilligan">
            <organization/>
          </author>

          <date month="February" year="2003"/>
        </front>
      </reference>

      <reference anchor="RFC5014">
        <front>
          <title>IPv6 Socket API for Source Address Selection</title>

          <author fullname="Erik Nordmark" initials="E. " surname="Nordmark">
            <organization/>
          </author>

          <date month="September" year="2007"/>
        </front>
      </reference>

      <reference anchor="RFC3542">
        <front>
          <title>Advanced Sockets Application Program Interface (API) for
          IPv6</title>

          <author fullname="W. Stevens" initials="W. " surname="Stevens">
            <organization/>
          </author>

          <date month="May" year="2003"/>
        </front>
      </reference>

      <reference anchor="RFC3484">
        <front>
          <title>Default Address Selection for Internet Protocol version 6
          (IPv6)</title>

          <author fullname="R. Draves" initials="R." surname="Draves">
            <organization/>
          </author>

          <date month="February" year="2003"/>
        </front>
      </reference>

      <?rfc include="reference.RFC.2119"?>
    </references>
  </back>
</rfc>
