I have previously submitted patches that implement NFS client and nfsd
support for the AF_VSOCK address family. In order for this to be
acceptable for merge the AF_VSOCK transport needs to be defined in an
IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
My patches use netid "vsock" but "tcpv" has also been suggested. This draft
RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
The uaddr format proposed in this RFC is not implemented yet. RPCBIND and the
NFSv4 callback were not supported in my previous patch submissions but it's
clear that a uaddr format is required for full ONC RPC support so I've
included it.
Discussion and pointers for getting this in shape for submission with
the IETF would be appreciated! I will apply final RFC formatting before
submission and am mostly concerned about content at this stage.
Thanks,
Stefan
---
Remote Procedure Call (RPC) Network Identifier and Universal Address Format
Definitions for the AF_VSOCK Transport
S. Hajnoczi
Red Hat, Inc.
October 2017
1. Introduction and Motivation
The AF_VSOCK address family facilitates socket communication between a
hypervisor and virtual machines running on the hypervisor. It was implemented
in Linux 3.9 with initial transport support for VMware. Further transports
were added for KVM and Hyper-V hypervisors later. AF_VSOCK services can
run on any supported hypervisor because the network address and semantics
remain the same across AF_VSOCK transports.
ONC RPC services are bound to transport addresses (RFC 1833 [1]). Transport
addresses are described by netid and universal address strings. This standard
representation of transport addresses allows address information to be
communicated between client programs and RPC services, including the RPCBIND
program.
It is necessary to define a network identifier and universal address
representation so that ONC RPC may be used over AF_VSOCK. This document
describes string representations for the AF_VSOCK netid and universal
addresses.
2. Requirements Language
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 [2].
3. Security Considerations
AF_VSOCK addresses are local to the hypervisor instance that the virtual
machine is running on. Source address spoofing is not possible because the
hypervisor enforces the assigned address of the virtual machine. RPC services
running on the hypervisor MAY use the source address for authorization if they
do not implement additional security features.
4. Intended Use
The intended use of this new ONC RPC transport is Network File System (NFS)
v4.1 (RFC5661 [3]) to export file systems from the hypervisor into virtual
machines. Other RPC services could also be used with the hypervisor offering
the service to the virtual machine or vice versa.
The need for an AF_VSOCK transport arises because management tools require the
ability to deploy RPC services for virtual machines in an automated fashion.
Existing TCP/IP network interface configuration, including firewall
configuration, is difficult to automate without risk of interfering with the
virtual machine owner's networking configuration. AF_VSOCK provides a
zero-configuration communications channel with the dedicated purpose of
communicating between a hypervisor and virtual machines without these
configuration difficulties.
5. Network addresses
AF_VSOCK addresses contain an unsigned 32-bit integer called the Context
Identifier (CID) that is the network address. An unsigned 32-bit integer port
number acts as the transport selector so that multiple services can be offered
on a single network address.
CID values in the range [0, 2] are reserved. Virtual machines are assigned
values outside this range. The hypervisor exposes services on the well-known
CID value 2.
Ports in the range [0, 1023] are privileged and can only be bound by programs
that have sufficient privilege.
6. Netid for AF_VSOCK
The netid for AF_VSOCK is given in Table 1.
+---------+----------+-------------------------------+------+------+
| Netid | Constant | RFC(s) and Description (if | PoC | CR |
| | Name | needed) | | |
+---------+----------+-------------------------------+------+------+
| "vsock" | NC_VSOCK | Netid for AF_VSOCK. | IESG | TBD1 |
| | | Section 6 of RFC TBD1. | | |
+---------+----------+----------------------------- -+------+------+
PoC: Point of Contact.
CR: Cross Reference to the Uaddr Format Registry.
Table 1: Netid for AF_VSOCK
7. Uaddr Format for AF_VSOCK
The format of the uaddr for AF_VSOCK is the US-ASCII string:
cid.port
The "cid" prefix is the ASCII-decimal representation of the CID network
address. The "port" suffix is the ASCII-decimal representation of the
port number transport selector.
+-------+------------------------------------+------+-------+
| Basis | Description and/or Reference | PoC | CR |
+-------+------------------------------------+------+-------+
| STDS | Uaddr format for AF_VSOCK. | IESG | TBD1 |
| | Section 7 of RFC TBD1. | | |
+-------+------------------------------------+------+-------+
Table 2: Uaddr format for AF_VSOCK
8. Record Marking
AF_VSOCK sockets of type SOCK_STREAM are used for connection-oriented,
in-order, guaranteed delivery semantics. These bytestream semantics require
that RPC messages are delimited so message boundaries can be detected.
The Record Marking Standard, defined in RFC 1831 Section 10 [4], is used for
this purpose.
9. References
[1] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, August 1995.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Eisler, M., "IANA Considerations for Remote Procedure Call (RPC)
Network Identifiers and Universal Address Formats", RFC 5665,
January 2010.
[4] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification
Version 2", RFC 1831, August 1995.
Hi Stefan,
On Thu, Oct 5, 2017 at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
> I have previously submitted patches that implement NFS client and nfsd
> support for the AF_VSOCK address family. In order for this to be
> acceptable for merge the AF_VSOCK transport needs to be defined in an
> IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
>
> My patches use netid "vsock" but "tcpv" has also been suggested. This draft
> RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
>
I think "vsock" is the appropriate netid, not "tcpv." Stream
orientation, if anything, is the general category containing TCP and
VSOCK, not the reverse. But really I think it's just more clear.
I think this draft needs to be sent to the IETF NFSv4 working group
alias, [email protected].
Matt
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-821-5101
fax. 734-769-8938
cel. 734-216-5309
> On Oct 5, 2017, at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
>
> I have previously submitted patches that implement NFS client and nfsd
> support for the AF_VSOCK address family. In order for this to be
> acceptable for merge the AF_VSOCK transport needs to be defined in an
> IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
>
> My patches use netid "vsock" but "tcpv" has also been suggested. This draft
> RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
>
> The uaddr format proposed in this RFC is not implemented yet. RPCBIND and the
> NFSv4 callback were not supported in my previous patch submissions but it's
> clear that a uaddr format is required for full ONC RPC support so I've
> included it.
>
> Discussion and pointers for getting this in shape for submission with
> the IETF would be appreciated! I will apply final RFC formatting before
> submission and am mostly concerned about content at this stage.
>
> Thanks,
> Stefan
> ---
>
> Remote Procedure Call (RPC) Network Identifier and Universal Address Format
> Definitions for the AF_VSOCK Transport
>
> S. Hajnoczi
> Red Hat, Inc.
> October 2017
>
> 1. Introduction and Motivation
>
> The AF_VSOCK address family facilitates socket communication between a
> hypervisor and virtual machines running on the hypervisor. It was implemented
> in Linux 3.9 with initial transport support for VMware. Further transports
> were added for KVM and Hyper-V hypervisors later. AF_VSOCK services can
> run on any supported hypervisor because the network address and semantics
> remain the same across AF_VSOCK transports.
>
> ONC RPC services are bound to transport addresses (RFC 1833 [1]). Transport
> addresses are described by netid and universal address strings. This standard
> representation of transport addresses allows address information to be
> communicated between client programs and RPC services, including the RPCBIND
> program.
>
> It is necessary to define a network identifier and universal address
> representation so that ONC RPC may be used over AF_VSOCK. This document
> describes string representations for the AF_VSOCK netid and universal
> addresses.
>
> 2. Requirements Language
>
> 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 [2].
>
> 3. Security Considerations
>
> AF_VSOCK addresses are local to the hypervisor instance that the virtual
> machine is running on. Source address spoofing is not possible because the
> hypervisor enforces the assigned address of the virtual machine. RPC services
> running on the hypervisor MAY use the source address for authorization if they
> do not implement additional security features.
>
> 4. Intended Use
>
> The intended use of this new ONC RPC transport is Network File System (NFS)
> v4.1 (RFC5661 [3]) to export file systems from the hypervisor into virtual
> machines. Other RPC services could also be used with the hypervisor offering
> the service to the virtual machine or vice versa.
>
> The need for an AF_VSOCK transport arises because management tools require the
> ability to deploy RPC services for virtual machines in an automated fashion.
> Existing TCP/IP network interface configuration, including firewall
> configuration, is difficult to automate without risk of interfering with the
> virtual machine owner's networking configuration. AF_VSOCK provides a
> zero-configuration communications channel with the dedicated purpose of
> communicating between a hypervisor and virtual machines without these
> configuration difficulties.
>
> 5. Network addresses
>
> AF_VSOCK addresses contain an unsigned 32-bit integer called the Context
> Identifier (CID) that is the network address. An unsigned 32-bit integer port
> number acts as the transport selector so that multiple services can be offered
> on a single network address.
>
> CID values in the range [0, 2] are reserved. Virtual machines are assigned
> values outside this range. The hypervisor exposes services on the well-known
> CID value 2.
>
> Ports in the range [0, 1023] are privileged and can only be bound by programs
> that have sufficient privilege.
>
> 6. Netid for AF_VSOCK
>
> The netid for AF_VSOCK is given in Table 1.
>
> +---------+----------+-------------------------------+------+------+
> | Netid | Constant | RFC(s) and Description (if | PoC | CR |
> | | Name | needed) | | |
> +---------+----------+-------------------------------+------+------+
> | "vsock" | NC_VSOCK | Netid for AF_VSOCK. | IESG | TBD1 |
> | | | Section 6 of RFC TBD1. | | |
> +---------+----------+----------------------------- -+------+------+
>
> PoC: Point of Contact.
>
> CR: Cross Reference to the Uaddr Format Registry.
>
> Table 1: Netid for AF_VSOCK
>
> 7. Uaddr Format for AF_VSOCK
>
> The format of the uaddr for AF_VSOCK is the US-ASCII string:
>
> cid.port
>
> The "cid" prefix is the ASCII-decimal representation of the CID network
> address. The "port" suffix is the ASCII-decimal representation of the
> port number transport selector.
>
> +-------+------------------------------------+------+-------+
> | Basis | Description and/or Reference | PoC | CR |
> +-------+------------------------------------+------+-------+
> | STDS | Uaddr format for AF_VSOCK. | IESG | TBD1 |
> | | Section 7 of RFC TBD1. | | |
> +-------+------------------------------------+------+-------+
>
> Table 2: Uaddr format for AF_VSOCK
>
> 8. Record Marking
>
> AF_VSOCK sockets of type SOCK_STREAM are used for connection-oriented,
> in-order, guaranteed delivery semantics. These bytestream semantics require
> that RPC messages are delimited so message boundaries can be detected.
>
> The Record Marking Standard, defined in RFC 1831 Section 10 [4], is used for
> this purpose.
>
> 9. References
>
> [1] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
> RFC 1833, August 1995.
>
> [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
> Levels", BCP 14, RFC 2119, March 1997.
>
> [3] Eisler, M., "IANA Considerations for Remote Procedure Call (RPC)
> Network Identifiers and Universal Address Formats", RFC 5665,
> January 2010.
>
> [4] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification
> Version 2", RFC 1831, August 1995.
Hi Stefan-
There's no need for a bulky Cc: list. Everyone (except perhaps
Daniel) is already on [email protected].
Please use xml2rfc to ensure the document is properly formatted,
and can be efficiently converted to HTML, PDF, and other forms.
https://xml2rfc.tools.ietf.org
There are XML versions of personal drafts that you can copy to
get started, at the bottom of this page:
https://datatracker.ietf.org/wg/nfsv4/documents/
You need to state somewhere that the VSOCK/SOCK_STREAM transport
guarantees reliable and ordered delivery of bytes. NFSv4 requires
this (see RFC 5661, Section 2.9.1).
AF_VSOCK is not a transport, it's an address family. A shorter
and more precise title might be "Remote Procedure Call (RPC) on
VSOCK Sockets". Ensure that the text (and any discussion of this
I-D) uses the term AF_VSOCK appropriately. I prefer the term
"VSOCK sockets" for this purpose.
The Security Considerations section needs a description of your
threat model, IMO, and it belongs at the end of the document,
not at the front of it. What kind of attacks is VSOCK designed
to prevent?
You need to mention what AUTH flavors are supported on this
transport, and which are not. Are there any changes expected to
the credentials for these supported formats? If no GSS flavors
are supported, please explain in the Security Considerations
section how deployments can avoid attacks.
An unchanging public reference to a specification of VSOCK is
important to cite. If you can't find one, you'll have to explain
why in the document. If the VSOCK specification is not an IETF
document, it will have to be an Informative reference, and this
I-D will also have to be Informative.
Sections 5, 6, and 7 should be made subsections of a single
section entitled "IANA Considerations", which should follow the
Security Considerations section. Especially the current section
5 needs to cite something that specifies the behavior and
structure of AF_VSOCK addresses, IMO.
You might want to make an explicit statement about whether RPC
functions with the SOCK_DATAGRAM flavor of VSOCK, or if this
mode of operation is explicitly not to be used. Or, you might
want to ensure it can be supported in the future by reserving
a netid for it in this document.
You must have your company's permission to contribute this
I-D to the IETF, and you must be clear about any existing
Intellectual Property related to VSOCK that you or your
company owns.
http://trustee.ietf.org/trust-legal-provisions.html
If you're not clear about what this means, consult your
company's legal counsel.
--
Chuck Lever
On Thu, Oct 05, 2017 at 04:53:07PM -0400, Chuck Lever wrote:
> > On Oct 5, 2017, at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
> >
> > I have previously submitted patches that implement NFS client and nfsd
> > support for the AF_VSOCK address family. In order for this to be
> > acceptable for merge the AF_VSOCK transport needs to be defined in an
> > IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
> >
> > My patches use netid "vsock" but "tcpv" has also been suggested. This draft
> > RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
> >
> > The uaddr format proposed in this RFC is not implemented yet. RPCBIND and the
> > NFSv4 callback were not supported in my previous patch submissions but it's
> > clear that a uaddr format is required for full ONC RPC support so I've
> > included it.
> >
> > Discussion and pointers for getting this in shape for submission with
> > the IETF would be appreciated! I will apply final RFC formatting before
> > submission and am mostly concerned about content at this stage.
> >
> > Thanks,
> > Stefan
> > ---
> >
> > Remote Procedure Call (RPC) Network Identifier and Universal Address Format
> > Definitions for the AF_VSOCK Transport
> >
> > S. Hajnoczi
> > Red Hat, Inc.
> > October 2017
> >
> > 1. Introduction and Motivation
> >
> > The AF_VSOCK address family facilitates socket communication between a
> > hypervisor and virtual machines running on the hypervisor. It was implemented
> > in Linux 3.9 with initial transport support for VMware. Further transports
> > were added for KVM and Hyper-V hypervisors later. AF_VSOCK services can
> > run on any supported hypervisor because the network address and semantics
> > remain the same across AF_VSOCK transports.
> >
> > ONC RPC services are bound to transport addresses (RFC 1833 [1]). Transport
> > addresses are described by netid and universal address strings. This standard
> > representation of transport addresses allows address information to be
> > communicated between client programs and RPC services, including the RPCBIND
> > program.
> >
> > It is necessary to define a network identifier and universal address
> > representation so that ONC RPC may be used over AF_VSOCK. This document
> > describes string representations for the AF_VSOCK netid and universal
> > addresses.
> >
> > 2. Requirements Language
> >
> > 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 [2].
> >
> > 3. Security Considerations
> >
> > AF_VSOCK addresses are local to the hypervisor instance that the virtual
> > machine is running on. Source address spoofing is not possible because the
> > hypervisor enforces the assigned address of the virtual machine. RPC services
> > running on the hypervisor MAY use the source address for authorization if they
> > do not implement additional security features.
> >
> > 4. Intended Use
> >
> > The intended use of this new ONC RPC transport is Network File System (NFS)
> > v4.1 (RFC5661 [3]) to export file systems from the hypervisor into virtual
> > machines. Other RPC services could also be used with the hypervisor offering
> > the service to the virtual machine or vice versa.
> >
> > The need for an AF_VSOCK transport arises because management tools require the
> > ability to deploy RPC services for virtual machines in an automated fashion.
> > Existing TCP/IP network interface configuration, including firewall
> > configuration, is difficult to automate without risk of interfering with the
> > virtual machine owner's networking configuration. AF_VSOCK provides a
> > zero-configuration communications channel with the dedicated purpose of
> > communicating between a hypervisor and virtual machines without these
> > configuration difficulties.
> >
> > 5. Network addresses
> >
> > AF_VSOCK addresses contain an unsigned 32-bit integer called the Context
> > Identifier (CID) that is the network address. An unsigned 32-bit integer port
> > number acts as the transport selector so that multiple services can be offered
> > on a single network address.
> >
> > CID values in the range [0, 2] are reserved. Virtual machines are assigned
> > values outside this range. The hypervisor exposes services on the well-known
> > CID value 2.
> >
> > Ports in the range [0, 1023] are privileged and can only be bound by programs
> > that have sufficient privilege.
> >
> > 6. Netid for AF_VSOCK
> >
> > The netid for AF_VSOCK is given in Table 1.
> >
> > +---------+----------+-------------------------------+------+------+
> > | Netid | Constant | RFC(s) and Description (if | PoC | CR |
> > | | Name | needed) | | |
> > +---------+----------+-------------------------------+------+------+
> > | "vsock" | NC_VSOCK | Netid for AF_VSOCK. | IESG | TBD1 |
> > | | | Section 6 of RFC TBD1. | | |
> > +---------+----------+----------------------------- -+------+------+
> >
> > PoC: Point of Contact.
> >
> > CR: Cross Reference to the Uaddr Format Registry.
> >
> > Table 1: Netid for AF_VSOCK
> >
> > 7. Uaddr Format for AF_VSOCK
> >
> > The format of the uaddr for AF_VSOCK is the US-ASCII string:
> >
> > cid.port
> >
> > The "cid" prefix is the ASCII-decimal representation of the CID network
> > address. The "port" suffix is the ASCII-decimal representation of the
> > port number transport selector.
> >
> > +-------+------------------------------------+------+-------+
> > | Basis | Description and/or Reference | PoC | CR |
> > +-------+------------------------------------+------+-------+
> > | STDS | Uaddr format for AF_VSOCK. | IESG | TBD1 |
> > | | Section 7 of RFC TBD1. | | |
> > +-------+------------------------------------+------+-------+
> >
> > Table 2: Uaddr format for AF_VSOCK
> >
> > 8. Record Marking
> >
> > AF_VSOCK sockets of type SOCK_STREAM are used for connection-oriented,
> > in-order, guaranteed delivery semantics. These bytestream semantics require
> > that RPC messages are delimited so message boundaries can be detected.
> >
> > The Record Marking Standard, defined in RFC 1831 Section 10 [4], is used for
> > this purpose.
> >
> > 9. References
> >
> > [1] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
> > RFC 1833, August 1995.
> >
> > [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
> > Levels", BCP 14, RFC 2119, March 1997.
> >
> > [3] Eisler, M., "IANA Considerations for Remote Procedure Call (RPC)
> > Network Identifiers and Universal Address Formats", RFC 5665,
> > January 2010.
> >
> > [4] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification
> > Version 2", RFC 1831, August 1995.
>
> Hi Stefan-
>
> There's no need for a bulky Cc: list. Everyone (except perhaps
> Daniel) is already on [email protected].
>
> Please use xml2rfc to ensure the document is properly formatted,
> and can be efficiently converted to HTML, PDF, and other forms.
>
> https://xml2rfc.tools.ietf.org
>
> There are XML versions of personal drafts that you can copy to
> get started, at the bottom of this page:
>
> https://datatracker.ietf.org/wg/nfsv4/documents/
Great, thanks for the links.
> You need to state somewhere that the VSOCK/SOCK_STREAM transport
> guarantees reliable and ordered delivery of bytes. NFSv4 requires
> this (see RFC 5661, Section 2.9.1).
That was my intention with "AF_VSOCK sockets of type SOCK_STREAM are
used for connection-oriented, in-order, guaranteed delivery semantics"
but I'll rephrase it to match the NFSv4 requirement wording.
> AF_VSOCK is not a transport, it's an address family. A shorter
> and more precise title might be "Remote Procedure Call (RPC) on
> VSOCK Sockets". Ensure that the text (and any discussion of this
> I-D) uses the term AF_VSOCK appropriately. I prefer the term
> "VSOCK sockets" for this purpose.
Will fix in v2.
> The Security Considerations section needs a description of your
> threat model, IMO, and it belongs at the end of the document,
> not at the front of it. What kind of attacks is VSOCK designed
> to prevent?
Okay, will revisit the Security Considerations section and move it to
the appropriate place. I saw that RFC 3552 "Guidelines for Writing RFC
Text on Security Considerations" exists so I'll study it.
> You need to mention what AUTH flavors are supported on this
> transport, and which are not. Are there any changes expected to
> the credentials for these supported formats? If no GSS flavors
> are supported, please explain in the Security Considerations
> section how deployments can avoid attacks.
Will fix in v2.
> An unchanging public reference to a specification of VSOCK is
> important to cite. If you can't find one, you'll have to explain
> why in the document. If the VSOCK specification is not an IETF
> document, it will have to be an Informative reference, and this
> I-D will also have to be Informative.
There is no formal specification. VMware has published developer
documentation that explains the use of VSOCK in the context of VMware
products.
I will submit a vsock(7) man page to the Linux man-pages project
(similar to ip(7), tcp(7), etc). It will document the semantics of the
AF_VSOCK address family. Maybe this can serve as a reference?
> Sections 5, 6, and 7 should be made subsections of a single
> section entitled "IANA Considerations", which should follow the
> Security Considerations section. Especially the current section
> 5 needs to cite something that specifies the behavior and
> structure of AF_VSOCK addresses, IMO.
Okay.
> You might want to make an explicit statement about whether RPC
> functions with the SOCK_DATAGRAM flavor of VSOCK, or if this
> mode of operation is explicitly not to be used. Or, you might
> want to ensure it can be supported in the future by reserving
> a netid for it in this document.
Good idea. Will fix in v2.
> You must have your company's permission to contribute this
> I-D to the IETF, and you must be clear about any existing
> Intellectual Property related to VSOCK that you or your
> company owns.
>
> http://trustee.ietf.org/trust-legal-provisions.html
>
> If you're not clear about what this means, consult your
> company's legal counsel.
Thanks, will double-check the requirements.
Stefan
On Thu, Oct 05, 2017 at 04:50:55PM -0400, Matt Benjamin wrote:
> On Thu, Oct 5, 2017 at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
> > I have previously submitted patches that implement NFS client and nfsd
> > support for the AF_VSOCK address family. In order for this to be
> > acceptable for merge the AF_VSOCK transport needs to be defined in an
> > IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
> >
> > My patches use netid "vsock" but "tcpv" has also been suggested. This draft
> > RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
> >
>
> I think "vsock" is the appropriate netid, not "tcpv." Stream
> orientation, if anything, is the general category containing TCP and
> VSOCK, not the reverse. But really I think it's just more clear.
>
> I think this draft needs to be sent to the IETF NFSv4 working group
> alias, [email protected].
Thanks. Will send the next revision properly formatted to the NFSv4
working group.
Stefan
On Thu, Oct 12, 2017 at 12:40:20PM -0400, Chuck Lever wrote:
>
>
> > On Oct 12, 2017, at 8:08 AM, Stefan Hajnoczi <[email protected]> wrote:
> >
> >> On Thu, Oct 05, 2017 at 04:50:55PM -0400, Matt Benjamin wrote:
> >>> On Thu, Oct 5, 2017 at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
> >>> I have previously submitted patches that implement NFS client and nfsd
> >>> support for the AF_VSOCK address family. In order for this to be
> >>> acceptable for merge the AF_VSOCK transport needs to be defined in an
> >>> IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
> >>>
> >>> My patches use netid "vsock" but "tcpv" has also been suggested. This draft
> >>> RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
> >>>
> >>
> >> I think "vsock" is the appropriate netid, not "tcpv." Stream
> >> orientation, if anything, is the general category containing TCP and
> >> VSOCK, not the reverse. But really I think it's just more clear.
> >>
> >> I think this draft needs to be sent to the IETF NFSv4 working group
> >> alias, [email protected].
> >
> > Thanks. Will send the next revision properly formatted to the NFSv4
> > working group.
>
> Don’t do that. Please submit a personal draft via:
>
> https://datatracker.ietf.org/submit/
>
> once you have appropriate permission from RH legal
> counsel to contribute to the IETF. Then approach the
> working group to introduce your submitted document.
Okay, thanks!
Stefan
> On Oct 12, 2017, at 8:17 AM, Stefan Hajnoczi <[email protected]> wrote:
>
> On Thu, Oct 05, 2017 at 04:53:07PM -0400, Chuck Lever wrote:
>>> On Oct 5, 2017, at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
>
>> An unchanging public reference to a specification of VSOCK is
>> important to cite. If you can't find one, you'll have to explain
>> why in the document. If the VSOCK specification is not an IETF
>> document, it will have to be an Informative reference, and this
>> I-D will also have to be Informative.
>
> There is no formal specification. VMware has published developer
> documentation that explains the use of VSOCK in the context of VMware
> products.
If there is nothing else, this is the most appropriate reference
to cite. It provides a description of the technology made by the
agent who invented and ultimately controls it (we believe: it
may be that someone else did, and VMware is just taking credit;
I think we need to know that too).
You should contact VMware to see if they have anything more, and
to ask if they already have NFS on VSOCK. Let them know you are
submitting standards in this area.
> I will submit a vsock(7) man page to the Linux man-pages project
> (similar to ip(7), tcp(7), etc). It will document the semantics of the
> AF_VSOCK address family. Maybe this can serve as a reference?
The IESG will ultimately decide, but IMO citing a man page that
you wrote would not be adequate unless you yourself invented the
VSOCK technology.
--
Chuck Lever
On Fri, Oct 13, 2017 at 10:13:18AM -0400, Chuck Lever wrote:
>
> > On Oct 12, 2017, at 8:17 AM, Stefan Hajnoczi <[email protected]> wrote:
> >
> > On Thu, Oct 05, 2017 at 04:53:07PM -0400, Chuck Lever wrote:
> >>> On Oct 5, 2017, at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
> >
> >> An unchanging public reference to a specification of VSOCK is
> >> important to cite. If you can't find one, you'll have to explain
> >> why in the document. If the VSOCK specification is not an IETF
> >> document, it will have to be an Informative reference, and this
> >> I-D will also have to be Informative.
> >
> > There is no formal specification. VMware has published developer
> > documentation that explains the use of VSOCK in the context of VMware
> > products.
>
> If there is nothing else, this is the most appropriate reference
> to cite. It provides a description of the technology made by the
> agent who invented and ultimately controls it (we believe: it
> may be that someone else did, and VMware is just taking credit;
> I think we need to know that too).
>
> You should contact VMware to see if they have anything more, and
> to ask if they already have NFS on VSOCK. Let them know you are
> submitting standards in this area.
>
> > I will submit a vsock(7) man page to the Linux man-pages project
> > (similar to ip(7), tcp(7), etc). It will document the semantics of the
> > AF_VSOCK address family. Maybe this can serve as a reference?
>
> The IESG will ultimately decide, but IMO citing a man page that
> you wrote would not be adequate unless you yourself invented the
> VSOCK technology.
Okay. I'll check with Jorgen Hansen (VMware), Linux net/vmw_vsock/
maintainer, and see what the best reference is.
Stefan
On Thu, 2017-10-05 at 16:50 -0400, Matt Benjamin wrote:
> Hi Stefan,
>
> On Thu, Oct 5, 2017 at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
> > I have previously submitted patches that implement NFS client and nfsd
> > support for the AF_VSOCK address family. In order for this to be
> > acceptable for merge the AF_VSOCK transport needs to be defined in an
> > IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
> >
> > My patches use netid "vsock" but "tcpv" has also been suggested. This draft
> > RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
> >
>
> I think "vsock" is the appropriate netid, not "tcpv." Stream
> orientation, if anything, is the general category containing TCP and
> VSOCK, not the reverse. But really I think it's just more clear.
>
Agreed. VSOCK is its own thing. It bears some resemblance to TCP, but
calling it tcpv would be confusing. IIRC, Chuck only proposed that when
we were discussing an alternative transport that would look more like a
typical network.
BTW: Does VSOCK have a connectionless mode, analogous to UDP? If so,
then it may be nice to consider what the netid for that might look like
as well, before we settle on any names.
--
Jeff Layton <[email protected]>
On Fri, Oct 27, 2017 at 09:16:42AM -0400, Jeff Layton wrote:
> On Thu, 2017-10-05 at 16:50 -0400, Matt Benjamin wrote:
> > Hi Stefan,
> >
> > On Thu, Oct 5, 2017 at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
> > > I have previously submitted patches that implement NFS client and nfsd
> > > support for the AF_VSOCK address family. In order for this to be
> > > acceptable for merge the AF_VSOCK transport needs to be defined in an
> > > IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
> > >
> > > My patches use netid "vsock" but "tcpv" has also been suggested. This draft
> > > RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
> > >
> >
> > I think "vsock" is the appropriate netid, not "tcpv." Stream
> > orientation, if anything, is the general category containing TCP and
> > VSOCK, not the reverse. But really I think it's just more clear.
> >
>
> Agreed. VSOCK is its own thing. It bears some resemblance to TCP, but
> calling it tcpv would be confusing. IIRC, Chuck only proposed that when
> we were discussing an alternative transport that would look more like a
> typical network.
>
> BTW: Does VSOCK have a connectionless mode, analogous to UDP? If so,
> then it may be nice to consider what the netid for that might look like
> as well, before we settle on any names.
Yes, you can use SOCK_STREAM or SOCK_DGRAM when using vsock.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Hi Jeff,
This doc says they are:
https://vmsplice.net/~stefan/stefanha-kvm-forum-2015.pdf
But only stream sockets are mentioned here:
https://wiki.qemu.org/Features/VirtioVsock
Trond and Chuck suggested in an offline conversation a few weeks ago
that they could imagine a datagram version of the transport being
useful. It's probably worth passing that alone.
Matt
On Fri, Oct 27, 2017 at 9:16 AM, Jeff Layton <[email protected]> wrote:
> On Thu, 2017-10-05 at 16:50 -0400, Matt Benjamin wrote:
>> Hi Stefan,
>>
>> On Thu, Oct 5, 2017 at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
>> > I have previously submitted patches that implement NFS client and nfsd
>> > support for the AF_VSOCK address family. In order for this to be
>> > acceptable for merge the AF_VSOCK transport needs to be defined in an
>> > IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
>> >
>> > My patches use netid "vsock" but "tcpv" has also been suggested. This draft
>> > RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
>> >
>>
>> I think "vsock" is the appropriate netid, not "tcpv." Stream
>> orientation, if anything, is the general category containing TCP and
>> VSOCK, not the reverse. But really I think it's just more clear.
>>
>
> Agreed. VSOCK is its own thing. It bears some resemblance to TCP, but
> calling it tcpv would be confusing. IIRC, Chuck only proposed that when
> we were discussing an alternative transport that would look more like a
> typical network.
>
> BTW: Does VSOCK have a connectionless mode, analogous to UDP? If so,
> then it may be nice to consider what the netid for that might look like
> as well, before we settle on any names.
> --
> Jeff Layton <[email protected]>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-821-5101
fax. 734-769-8938
cel. 734-216-5309
> useful. It's probably worth passing that alone.
Sorry, I meant, "along."
Matt
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-821-5101
fax. 734-769-8938
cel. 734-216-5309
I agree -- that could be useful later. Given that, maybe we should call
the netids something like:
vsockc: connected vsock
vsockd: datagram vsock
AIUI, netids are just something we inherited from Sun when we got the
TI-RPC library. I don't think they are governed by any sort of
names+numbers authority, are they?
If not then we're probably define it to whatever we wish, though it
might be a good idea to talk to the Solaris folks and see if they have
any input as to the naming.
-- Jeff
On Fri, 2017-10-27 at 09:27 -0400, Matt Benjamin wrote:
> Hi Jeff,
>
> This doc says they are:
> https://vmsplice.net/~stefan/stefanha-kvm-forum-2015.pdf
>
> But only stream sockets are mentioned here:
> https://wiki.qemu.org/Features/VirtioVsock
>
> Trond and Chuck suggested in an offline conversation a few weeks ago
> that they could imagine a datagram version of the transport being
> useful. It's probably worth passing that alone.
>
> Matt
>
> On Fri, Oct 27, 2017 at 9:16 AM, Jeff Layton <[email protected]> wrote:
> > On Thu, 2017-10-05 at 16:50 -0400, Matt Benjamin wrote:
> > > Hi Stefan,
> > >
> > > On Thu, Oct 5, 2017 at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
> > > > I have previously submitted patches that implement NFS client and nfsd
> > > > support for the AF_VSOCK address family. In order for this to be
> > > > acceptable for merge the AF_VSOCK transport needs to be defined in an
> > > > IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
> > > >
> > > > My patches use netid "vsock" but "tcpv" has also been suggested. This draft
> > > > RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
> > > >
> > >
> > > I think "vsock" is the appropriate netid, not "tcpv." Stream
> > > orientation, if anything, is the general category containing TCP and
> > > VSOCK, not the reverse. But really I think it's just more clear.
> > >
> >
> > Agreed. VSOCK is its own thing. It bears some resemblance to TCP, but
> > calling it tcpv would be confusing. IIRC, Chuck only proposed that when
> > we were discussing an alternative transport that would look more like a
> > typical network.
> >
> > BTW: Does VSOCK have a connectionless mode, analogous to UDP? If so,
> > then it may be nice to consider what the netid for that might look like
> > as well, before we settle on any names.
> > --
> > Jeff Layton <[email protected]>
>
>
>
--
Jeff Layton <[email protected]>
> On Oct 27, 2017, at 1:59 PM, Jeff Layton <[email protected]> wrote:
>
> I agree -- that could be useful later. Given that, maybe we should call
> the netids something like:
>
> vsockc: connected vsock
> vsockd: datagram vsock
>
> AIUI, netids are just something we inherited from Sun when we got the
> TI-RPC library. I don't think they are governed by any sort of
> names+numbers authority, are they?
Jeff, the relevant authority is IANA, and that's the whole
point of this I-D: to request netid assignments and specify
the universal address format for the VSOCK AF.
> If not then we're probably define it to whatever we wish, though it
> might be a good idea to talk to the Solaris folks and see if they have
> any input as to the naming.
>
> -- Jeff
>
> On Fri, 2017-10-27 at 09:27 -0400, Matt Benjamin wrote:
>> Hi Jeff,
>>
>> This doc says they are:
>> https://vmsplice.net/~stefan/stefanha-kvm-forum-2015.pdf
>>
>> But only stream sockets are mentioned here:
>> https://wiki.qemu.org/Features/VirtioVsock
>>
>> Trond and Chuck suggested in an offline conversation a few weeks ago
>> that they could imagine a datagram version of the transport being
>> useful. It's probably worth passing that alone.
>>
>> Matt
>>
>> On Fri, Oct 27, 2017 at 9:16 AM, Jeff Layton <[email protected]> wrote:
>>> On Thu, 2017-10-05 at 16:50 -0400, Matt Benjamin wrote:
>>>> Hi Stefan,
>>>>
>>>> On Thu, Oct 5, 2017 at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
>>>>> I have previously submitted patches that implement NFS client and nfsd
>>>>> support for the AF_VSOCK address family. In order for this to be
>>>>> acceptable for merge the AF_VSOCK transport needs to be defined in an
>>>>> IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
>>>>>
>>>>> My patches use netid "vsock" but "tcpv" has also been suggested. This draft
>>>>> RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
>>>>>
>>>>
>>>> I think "vsock" is the appropriate netid, not "tcpv." Stream
>>>> orientation, if anything, is the general category containing TCP and
>>>> VSOCK, not the reverse. But really I think it's just more clear.
>>>>
>>>
>>> Agreed. VSOCK is its own thing. It bears some resemblance to TCP, but
>>> calling it tcpv would be confusing. IIRC, Chuck only proposed that when
>>> we were discussing an alternative transport that would look more like a
>>> typical network.
>>>
>>> BTW: Does VSOCK have a connectionless mode, analogous to UDP? If so,
>>> then it may be nice to consider what the netid for that might look like
>>> as well, before we settle on any names.
>>> --
>>> Jeff Layton <[email protected]>
>>
>>
>>
>
> --
> Jeff Layton <[email protected]>
--
Chuck Lever
> On Oct 12, 2017, at 8:08 AM, Stefan Hajnoczi <[email protected]> wrote:
>
>> On Thu, Oct 05, 2017 at 04:50:55PM -0400, Matt Benjamin wrote:
>>> On Thu, Oct 5, 2017 at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
>>> I have previously submitted patches that implement NFS client and nfsd
>>> support for the AF_VSOCK address family. In order for this to be
>>> acceptable for merge the AF_VSOCK transport needs to be defined in an
>>> IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
>>>
>>> My patches use netid "vsock" but "tcpv" has also been suggested. This draft
>>> RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
>>>
>>
>> I think "vsock" is the appropriate netid, not "tcpv." Stream
>> orientation, if anything, is the general category containing TCP and
>> VSOCK, not the reverse. But really I think it's just more clear.
>>
>> I think this draft needs to be sent to the IETF NFSv4 working group
>> alias, [email protected].
>
> Thanks. Will send the next revision properly formatted to the NFSv4
> working group.
Don’t do that. Please submit a personal draft via:
https://datatracker.ietf.org/submit/
once you have appropriate permission from RH legal
counsel to contribute to the IETF. Then approach the
working group to introduce your submitted document.
Thanks!
On Fri, Oct 27, 2017 at 02:23:18PM +0100, Daniel P. Berrange wrote:
> On Fri, Oct 27, 2017 at 09:16:42AM -0400, Jeff Layton wrote:
> > On Thu, 2017-10-05 at 16:50 -0400, Matt Benjamin wrote:
> > > Hi Stefan,
> > >
> > > On Thu, Oct 5, 2017 at 4:08 PM, Stefan Hajnoczi <[email protected]> wrote:
> > > > I have previously submitted patches that implement NFS client and nfsd
> > > > support for the AF_VSOCK address family. In order for this to be
> > > > acceptable for merge the AF_VSOCK transport needs to be defined in an
> > > > IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK.
> > > >
> > > > My patches use netid "vsock" but "tcpv" has also been suggested. This draft
> > > > RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
> > > >
> > >
> > > I think "vsock" is the appropriate netid, not "tcpv." Stream
> > > orientation, if anything, is the general category containing TCP and
> > > VSOCK, not the reverse. But really I think it's just more clear.
> > >
> >
> > Agreed. VSOCK is its own thing. It bears some resemblance to TCP, but
> > calling it tcpv would be confusing. IIRC, Chuck only proposed that when
> > we were discussing an alternative transport that would look more like a
> > typical network.
> >
> > BTW: Does VSOCK have a connectionless mode, analogous to UDP? If so,
> > then it may be nice to consider what the netid for that might look like
> > as well, before we settle on any names.
>
> Yes, you can use SOCK_STREAM or SOCK_DGRAM when using vsock.
VMware has implemented both SOCK_STREAM and SOCK_DGRAM.
The virtio-vsock and Hyper-V drivers implement only SOCK_STREAM at the
moment. In the future they may support SOCK_DGRAM if there are use
cases.
Stefan