From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6915.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc6915.txt (limited to 'doc/rfc/rfc6915.txt') diff --git a/doc/rfc/rfc6915.txt b/doc/rfc/rfc6915.txt new file mode 100644 index 0000000..0db1520 --- /dev/null +++ b/doc/rfc/rfc6915.txt @@ -0,0 +1,507 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Bellis +Request for Comments: 6915 Nominet UK +Updates: 6155 April 2013 +Category: Standards Track +ISSN: 2070-1721 + + + Flow Identity Extension for HTTP-Enabled Location Delivery (HELD) + +Abstract + + RFC 6155 specifies an extension for the HTTP-Enabled Location + Delivery (HELD) protocol, allowing the use of an IP address and port + number to request a Device location based on an individual packet + flow. + + However, certain kinds of NAT require that identifiers for both ends + of the packet flow must be specified in order to unambiguously + satisfy the location request. + + This document specifies an XML Schema and a URN Sub-Namespace for a + Flow Identity Extension for HELD to support this requirement. + + This document updates RFC 6155 by deprecating the port number + elements specified therein. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6915. + + + + + + + + + + + + +Bellis Standards Track [Page 1] + +RFC 6915 Flow Identity for HELD April 2013 + + +Copyright Notice + + Copyright (c) 2013 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 + 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 Used in This Document . . . . . . . . . . . . . . 3 + 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 + 5.1. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:held:flow . . . . . . . . . 6 + 5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 7 + 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 7 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 + + + + + + + + + + + + + + + + + + + + +Bellis Standards Track [Page 2] + +RFC 6915 Flow Identity for HELD April 2013 + + +1. Introduction + + Work at the Emergency Location Task Group of NICC Standards Limited + (the UK's telecoms industry standards body) prompted the addition of + port number identifiers in HELD Identity [RFC6155] to allow HELD + [RFC5985] requests for Devices that are behind NAT devices. + + Subsequent analysis has determined that in the presence of particular + types of NAT devices, and in particular Carrier Grade NATs, it is + necessary to know the complete tuple of (Layer 3 protocol, Layer 4 + protocol, source address, source port, destination address, + destination port) in order to unambiguously identify a flow, and + subsequently the true Device. + + This document specifies an XML Schema and a URN Sub-Namespace for a + Flow Identity Extension to support this requirement and provides a + more generally applicable means of identifying a Device based on the + parameters of a network flow of which it is an endpoint. + + Since the Location Recipient may not know in advance whether the + Device is behind a NAT device, the port number elements from Section + 3.3 of [RFC6155] are deprecated and MUST NOT be used in new client + implementations. Note that server implementations of this + specification may still encounter requests formed by clients that + have implemented only [RFC6155], and those requests might contain the + deprecated port element. + + For implementation details not specified in this document, please + refer to [RFC6155] and [RFC5985]. + +2. Conventions Used in This Document + + 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 [RFC2119]. + + The terms "Device" and "Target" are used as defined in [RFC6280]. + + + + + + + + + + + + + + +Bellis Standards Track [Page 3] + +RFC 6915 Flow Identity for HELD April 2013 + + +3. Usage + + An example HELD request is shown below: + + + geodetic + + +
192.0.2.25
+ 1024 + + +
198.51.100.238
+ 80 + + + + + The element MUST contain: + + o a "layer3" attribute with a value of "ipv4" or "ipv6". + + o a "layer4" attribute with a value of "udp" [RFC0768], "tcp" + [RFC0793], "sctp" [RFC4960], "dccp" [RFC4340], or a decimal + integer representing any applicable protocol from the IANA + Assigned Internet Protocol Numbers Registry. + + o an element and a element whose child elements contain + the Layer 3 address (which MUST conform to the relevant + "IPv4address" or "IPv6address" grammar as defined in [RFC3986]) + and the Layer 4 port number of each end of the flow. + + and MAY optionally contain: + + o a "target" attribute with a value of "src" (default) or "dst" to + indicate which end of the flow corresponds to the Target of the + with respect to the HELD protocol. + + + + + + + + + + + + +Bellis Standards Track [Page 4] + +RFC 6915 Flow Identity for HELD April 2013 + + +4. XML Schema + + + + + + + HELD Flow Identity + + This document defines Flow Identity elements for HELD. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bellis Standards Track [Page 5] + +RFC 6915 Flow Identity for HELD April 2013 + + + + + + + + + + + + + + + + + + + + +5. IANA Considerations + +5.1. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:held:flow + + This section registers a new XML namespace, + "urn:ietf:params:xml:ns:geopriv:held:flow", as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:ns:geopriv:held:flow + + Registrant Contact: IETF GEOPRIV Working Group (geopriv@ietf.org), + Ray Bellis (ray.bellis@nominet.org.uk) + + + + + + + + + + + + + + + + + + + + +Bellis Standards Track [Page 6] + +RFC 6915 Flow Identity for HELD April 2013 + + + XML: + + BEGIN + + + + + HELD Flow Identity Parameters + + +

Namespace for HELD Flow Identity Parameters

+

urn:ietf:params:xml:ns:geopriv:held:flow

+

See + RFC 6915.

+ + + END + +5.2. XML Schema Registration + + This section registers an XML Schema as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:ns:geopriv:held:flow + + Registrant Contact: IETF GEOPRIV Working Group (geopriv@ietf.org), + Ray Bellis (ray.bellis@nominet.org.uk) + + Schema: The XML for this schema can be found as the entirety of + Section 4 of this document. + +6. Privacy Considerations + + All of the considerations in [RFC6155] apply to the use of the + mechanism defined in this document. Like [RFC6155], this + specification assumes that the Location Server being queried already + has access to the internal state of the network near one end of the + flow being queried (for instance, access to the bindings in a NAT in + the path of the flow). Clients making queries using this + specification in environments where that assumption may not be true + should be aware that the request provides information about that + client's communications that the Location Server would not otherwise + be able to discern and may represent additional privacy exposure for + that client. + + + + + + +Bellis Standards Track [Page 7] + +RFC 6915 Flow Identity for HELD April 2013 + + +7. Security Considerations + + This document introduces no new security considerations beyond those + in [RFC6155]. + +8. Acknowledgements + + The author wishes to thank the members of the NICC Emergency Location + Task Group, the IETF GeoPriv Working Group, and the authors of + [RFC6155], from which the text for the URN and XML Schema + Registrations were derived. + +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. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, January 2005. + + [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC + 5985, September 2010. + + [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. + Barnes, "Use of Device Identity in HTTP-Enabled Location + Delivery (HELD)", RFC 6155, March 2011. + +9.2. Informative References + + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram + Congestion Control Protocol (DCCP)", RFC 4340, March 2006. + + [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC + 4960, September 2007. + + + + + +Bellis Standards Track [Page 8] + +RFC 6915 Flow Identity for HELD April 2013 + + + [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., + Tschofenig, H., and H. Schulzrinne, "An Architecture for + Location and Location Privacy in Internet Applications", + BCP 160, RFC 6280, July 2011. + +Author's Address + + Ray Bellis + Nominet UK + Edmund Halley Road + Oxford OX4 4DQ + United Kingdom + + Phone: +44 1865 332211 + EMail: ray.bellis@nominet.org.uk + URI: http://www.nominet.org.uk/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bellis Standards Track [Page 9] + -- cgit v1.2.3