doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc8464.txt b/doc/rfc/rfc8464.txt
new file mode 100644
index 0000000..ea757fb
--- /dev/null
+++ b/doc/rfc/rfc8464.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        R. Atarius
+Request for Comments: 8464                                September 2018
+Category: Informational
+ISSN: 2070-1721
+
+
+A URN Namespace for Device Identity and Mobile Equipment Identity (MEID)
+
+Abstract
+
+   This document defines a Uniform Resource Name (URN) namespace for the
+   Third Generation Partnership Project 2 (3GPP2) and a Namespace
+   Specific String (NSS) for the Mobile Equipment Identity (MEID).  The
+   structure of an MEID is 15 hexadecimal digits long and is defined in
+   the 3GPP2 to uniquely identify each individual mobile equipment
+   (e.g., a handset or mobile phone).  The 3GPP2 has a requirement to be
+   able to use an MEID as a URN.  This document fulfills that
+   requirement.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8464.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atarius                       Informational                     [Page 1]
+
+RFC 8464                     MEID-Based URN               September 2018
+
+
+Copyright Notice
+
+   Copyright (c) 2018 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
+   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Namespace Registration Template . . . . . . . . . . . . . . .   4
+   4.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   6
+     4.1.  MEID Parameters . . . . . . . . . . . . . . . . . . . . .   6
+     4.2.  MEID Format . . . . . . . . . . . . . . . . . . . . . . .   6
+       4.2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .   6
+       4.2.2.  Manufacturer Code . . . . . . . . . . . . . . . . . .   6
+       4.2.3.  Serial Number . . . . . . . . . . . . . . . . . . . .   7
+       4.2.4.  Check Digit . . . . . . . . . . . . . . . . . . . . .   7
+       4.2.5.  Hexadecimal Encoding  . . . . . . . . . . . . . . . .   7
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
+   6.  Security and Privacy Considerations . . . . . . . . . . . . .   8
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10
+
+1.  Introduction
+
+   Mobile equipment that is either a) single-mode 3GPP using only 3GPP
+   technology to transmit and receive voice or data or b) dual-mode
+   3GPP/3GPP2 using either 3GPP or 3GPP2 technology to transmit and
+   receive voice or data has an International Mobile station Equipment
+   Identity (IMEI) to identify it.  A URN namespace and an NSS for the
+   IMEI are defined in [RFC7254].  For cases where the mobile equipment
+   uses IMEI as an identity for dual-mode 3GPP/3GPP2 access, the IMEI
+   URN as defined in [RFC7254] can be used to identify the mobile
+   equipment.
+
+
+
+
+Atarius                       Informational                     [Page 2]
+
+RFC 8464                     MEID-Based URN               September 2018
+
+
+   However, single-mode 3GPP2 mobile equipment that supports only 3GPP2
+   access technology to transmit and receive voice or data has a
+   hexadecimal MEID.  Since there are fundamental differences between
+   MEID and IMEI (i.e., in encoding, format, and the ownership),
+   [RFC7254] cannot be employed to represent the hexadecimal MEID.
+
+   This document specifies a URN namespace for 3GPP2 and an NSS for the
+   MEID as per the namespace registration requirement in [RFC8141].  The
+   structure of an MEID is 15 hexadecimal digits long and is defined by
+   3GPP2 (see [S.R0048-A]) to uniquely identify each individual piece of
+   mobile equipment (e.g., a handset or mobile phone).  The 3GPP2 has a
+   requirement to be able to use an MEID as a URN.  This document
+   fulfills that requirement.  The Namespace Identifier (NID) '3gpp2' is
+   for identities used in 3GPP2 networks.  The MEID is managed by the
+   3GPP2, so this NID is managed by the 3GPP2.  This specification
+   defines only NSSs constructed from MEIDs under the '3gpp2' NID.
+   These NSSs start with "meid:" in order to identify them as such.  In
+   the future, the 3GPP2 may specify other types of NSSs under the
+   '3gpp2' NID.
+
+   The MEID is 15 hexadecimal digits long, includes a manufacturer code
+   of 8 hexadecimal digits, and includes the serial number of 6
+   hexadecimal digits plus a hexadecimal digit as a check digit.
+
+   The manufacturer code identifies the mobile equipment manufacturer.
+   A manufacturer can be assigned more than one manufacturer code.  The
+   serial number uniquely identifies each piece of mobile equipment
+   within the manufacturer code.  The check digit is used as assurance
+   of integrity in error-prone operations, e.g., when used with certain
+   types of readers during inventory-management operations.  The check
+   digit is not transmitted.  Therefore, the first 14 of the 15
+   hexadecimal digits are used for defining the MEID as a URN.
+
+   The information here is meant to be a concise guide for those wishing
+   to use the hexadecimal MEID as a URN.  Nothing in this document
+   should be construed to override [S.R0048-A], which defines the MEID.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+
+
+
+
+
+
+Atarius                       Informational                     [Page 3]
+
+RFC 8464                     MEID-Based URN               September 2018
+
+
+3.  Namespace Registration Template
+
+   A completed namespace registration follows.
+
+   Namespace Identifier:  '3gpp2'
+
+   Version:  1
+
+   Date:  2018-06-10
+
+   Registrant:
+      Standards Organization: Third Generation Partnership Project 2
+      (3GPP2)
+
+      Contact:
+
+      John Derr, MEID Global Hexadecimal Administrator,
+      JDerr@tiaonline.org
+
+      Gary Pellegrino, TIA TR-45 EUMAG Chair, gary@commflowresources.com
+      c/o Telecommunications Industry Association
+      1320 N.  Courthouse Rd., Suite 200
+      Arlington, Virginia 22201, United States of America
+
+   Purpose:  The '3gpp2' namespace is used to identify mobile equipment
+      that uses technologies defined by the Third Generation Partnership
+      Project 2 ((3GPP2); initially, such equipment is identified by a
+      URN that embeds a Mobile Equipment Identity (MEID) that is 15
+      hexadecimal digits long and unique to each individual piece of
+      mobile equipment (e.g., a handset or mobile phone).
+
+   Syntax:  The identifier is expressed in American Standard Code for
+      Information Interchange (ASCII) characters and has a hierarchical
+      expression using the Augmented Backus-Naur Form (ABNF) defined in
+      [RFC5234], as follows:
+
+      pp2-urn              = "urn:" pp2-NID ":" pp2-NSS
+      pp2-NID              = "3gpp2"
+      pp2-NSS              = meid-specifier / future-pp2-specifier
+      meid-specifier       = "meid:" meidval
+      future-pp2-specifier = future-specifier *[ ":" 1*( pchar / "/" )]
+      future-specifier     = 1*pp2-char
+      pp2-char             = ALPHA / DIGIT / "-" / "." / "_" /
+                             pct-encoded
+
+      where 'pchar' and 'pct-encoded' are defined in [RFC3986].  An NSS
+      for the MEID is defined under the '3gpp2' NID.  The representation
+      of the MEID is a specific number of hexadecimal digits, as
+
+
+
+Atarius                       Informational                     [Page 4]
+
+RFC 8464                     MEID-Based URN               September 2018
+
+
+      described in [S.R0048-A].  The formal definition of a URN with
+      'meid' NSS contains one meidval with the formal definition
+      according to the following ABNF [RFC5234]:
+
+      meidval           = Manufacturer-Code "-" Serial-Number
+      Manufacturer-Code = 8HEX
+      Serial-Number     = 6HEX
+      HEX               = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
+
+   Assignment:  The manufacturer code and serial number portions of the
+      MEID are permanently stored in the mobile equipment, so they
+      remain persistent as long as the mobile equipment exists.  The
+      process for manufacturer code and serial number assignment is
+      documented in [SC.R4002-0] and the manufacturer code and serial
+      number values once assigned are not reassigned to other pieces of
+      mobile equipment.
+
+      Identifiers in the '3gpp2' namespace are defined and assigned by
+      the 3GPP2 or an agency appointed by 3GPP2 after ensuring that the
+      URNs to be assigned are unique.  Procedures are in place to ensure
+      that each MEID is uniquely assigned by the mobile equipment
+      manufacturer so that it is guaranteed to uniquely identify that
+      particular piece of mobile equipment.
+
+   Security and Privacy:  See Section 6 of RFC 8464.
+
+   Interoperability:  Although both the 3GPP2 Mobile Equipment Identity
+      (MEID) and the 3GPP International Mobile station Equipment
+      Identity (IMEI) are used to identify mobile equipment, they are
+      separate identifiers and are not to be confused.
+      Internet implementations will not generally possess MEID
+      identifiers.  The identifiers generated by such implementations
+      will typically be URNs within namespaces other than '3gpp2', and
+      may, depending on context, even be non-URN URIs.  Implementations
+      are advised to be ready to process URIs other than '3gpp2'
+      namespace URNs, so as to aid in interoperability.
+
+   Resolution:  No resolution is envisioned.
+
+   Documentation:  Documentation can be found in the following
+      specifications:
+
+      *  "A URN Namespace for Device Identity and Mobile Equipment
+         Identity (MEID)" [RFC8464].
+
+      *  "3G Mobile Equipment Identifier (MEID) - Stage 1" [S.R0048-A].
+
+
+
+
+
+Atarius                       Informational                     [Page 5]
+
+RFC 8464                     MEID-Based URN               September 2018
+
+
+      *  "GHA (Global Hexadecimal Administrator) Assignment Guidelines
+         and Procedures for Mobile Equipment Identifier (MEID) and Short
+         Form Expanded UIM Identifier (SF_EUIMID)" [SC.R4002-0].
+
+   Additional Information:  Because the syntax of a 3GPP2 Mobile
+      Equipment Identity (MEID) differs from that of a 3GPP
+      International Mobile station Equipment Identity (IMEI), reuse of
+      the URN specified in RFC 7254 is not possible.
+
+   Revision Information:  N/A
+
+4.  Specification
+
+4.1.  MEID Parameters
+
+   Any future change to the format of the 'meid' NSS requires the use of
+   the procedure for URN NSS changes (currently through the publication
+   of a future Informational RFC approved by IETF consensus).
+
+   [RFC8465] specifies how the MEID URN can be used as an Instance ID as
+   specified in [RFC5626].  Any change to the Instance ID will require
+   an update to [RFC8465].  An example of 3GPP2 MEID URN is:
+
+   urn:3gpp2:meid:A04B0D56-02A7E3
+
+4.2.  MEID Format
+
+4.2.1.  Overview
+
+   The MEID format is 15 hexadecimal digits encoded in 8 octets as
+   defined in [S.R0048-A].  The first 8 hexadecimal digits constitute
+   the manufacturer code; the next 6 hexadecimal digits the serial
+   number within the manufacturer code.  The last hexadecimal digit is a
+   check digit.  For more details on the hexadecimal encoding, see
+   Section 4.2.5.
+
+4.2.2.  Manufacturer Code
+
+   The manufacturer code is a value of 8 hexadecimal digits.  The
+   manufacturer code identifies the mobile equipment manufacturer.  The
+   manufacturer code is chosen from a range of values allocated to the
+   mobile equipment manufacturer in order to uniquely identify the
+   mobile equipment.
+
+
+
+
+
+
+
+
+Atarius                       Informational                     [Page 6]
+
+RFC 8464                     MEID-Based URN               September 2018
+
+
+4.2.3.  Serial Number
+
+   The serial number is a value of 6 hexadecimal digits.  The serial
+   number identifies equipment within the manufacturer code.
+
+4.2.4.  Check Digit
+
+   This is a single hexadecimal digit (bits 1-4 of octet 8), and it is
+   used as assurance of integrity in error-prone operations, e.g., when
+   used with certain types of readers during inventory management
+   operations.  The check digit is not transmitted by the mobile
+   equipment and is not used in the MEID URN.
+
+4.2.5.  Hexadecimal Encoding
+
+   The MEID format is 15 hexadecimal digits encoded in 8 octets as
+   defined in [S.R0048-A].  The following figure is an abstract
+   representation of a hexadecimal-encoded MEID stored in memory (the
+   actual storage format in memory is implementation specific).  In this
+   figure, the most significant digit of the manufacturer code is
+   encoded in bits 1-4 of octet 1.  Bits 5-8 of octet 8 are zero-padded,
+   since bits 1-4 are only needed to encode the check digit.  The most
+   significant digit of the serial number is encoded in the bits 1-4 of
+   octet 5.  When MEID is included in a cellular signaling message, the
+   check digit is omitted and the first 7 Octets in the following figure
+   are only transmitted, [X.S0008-A].
+
+       14 13 12 11 10  9  8  7  6  5  4  3  2  1  0  Hexadecimal
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    Digits
+      |                       |                 |  |
+      |                       |                 |  |
+      |   Manufacturer Code   |  Serial Number  |CD|
+      |                       |                 |  |
+      |                       |                 |  |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+         1     2     3     4     5     6     7     8  Octets
+
+5.  IANA Considerations
+
+   In accordance with BCP 66 [RFC8141], IANA has registered the Formal
+   URN namespace '3gpp2' in the "Uniform Resource Name (URN) Namespaces"
+   registry, using the registration template presented in Section 3.
+
+
+
+
+
+
+
+
+
+Atarius                       Informational                     [Page 7]
+
+RFC 8464                     MEID-Based URN               September 2018
+
+
+6.  Security and Privacy Considerations
+
+   An MEID is usually printed outside of the box in which a mobile
+   device ships.  The MEID may also be printed under the battery on a
+   mobile device; however, very few devices have removable batteries
+   today.  One can retrieve the MEID via either settings or by dialing
+   *#06#.  Anyone with brief physical access to the mobile device or its
+   box can easily obtain the MEID.  Therefore, MEIDs MUST NOT be used as
+   security capabilities (identifiers whose mere possession grants
+   access).  Unfortunately, there are currently examples of some
+   applications that are using the MEID for authorization.  Also, some
+   service providers' customer service departments have been known to
+   use knowledge of the MEID as "proof" that the caller is the
+   legitimate owner of the mobile device.  Both of these are
+   inappropriate uses of the MEID.
+
+   Since the MEID is permanently assigned to the mobile equipment and is
+   not modified when the ownership of the mobile equipment changes (even
+   upon a complete software reload of the mobile equipment), the MEID
+   URN MUST NOT be used as a user identifier or user address by an
+   application.  Using the MEID to identify a user or as a user address
+   could result in communications destined for a previous owner of a
+   device being received by the new device owner or could allow the new
+   device owner to access information or services owned by the previous
+   device owner.
+
+   Additionally, since the MEID identifies the mobile equipment, it
+   potentially could be used to identify and track users for the
+   purposes of surveillance and call data mining if sent in the clear.
+
+   Since the MEID is personally identifiable information, uses of the
+   MEID URN with IETF protocols require a specification and IETF expert
+   review [RFC8126] in order to ensure that the privacy concerns are
+   appropriately addressed.  Protocols carrying the MEID URN SHOULD, at
+   a minimum, use strongly hop-by-hop encrypted channels, and it is
+   RECOMMENDED that end-to-end encryption be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atarius                       Informational                     [Page 8]
+
+RFC 8464                     MEID-Based URN               September 2018
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <https://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
+              Unique IDentifier (UUID) URN Namespace", RFC 4122,
+              DOI 10.17487/RFC4122, July 2005,
+              <https://www.rfc-editor.org/info/rfc4122>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5626]  Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
+              "Managing Client-Initiated Connections in the Session
+              Initiation Protocol (SIP)", RFC 5626,
+              DOI 10.17487/RFC5626, October 2009,
+              <https://www.rfc-editor.org/info/rfc5626>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
+              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
+              <https://www.rfc-editor.org/info/rfc8141>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [S.R0048-A]
+              3GPP2, "3G Mobile Equipment Identifier (MEID) - Stage 1,
+              Version 4.0", Stage 1, Version 4.0, 3GPP2 S.R0048-A, June
+              2005, <http://www.3gpp2.org/Public_html/specs/
+              S.R0048-A_v4.0_050630.pdf>.
+
+
+
+Atarius                       Informational                     [Page 9]
+
+RFC 8464                     MEID-Based URN               September 2018
+
+
+   [SC.R4002-0]
+              3GPP2, "GHA (Global Hexadecimal Administrator) Assignment
+              Guidelines and Procedures for Mobile Equipment Identifier
+              (MEID) and Short Form Expanded UIM Identifier
+              (SF_EUIMID)", 3GPP2 TS SC.R4002-0, Version 12.0, December
+              2016, <http://www.3gpp2.org/Public_html/Specs/SC.R4002-0_v
+              12.0_GHA_%20Guidelines_for_MEID_December_2016.pdf>.
+
+   [X.S0008-A]
+              3GPP2, "MAP Support for the Mobile Equipment Identity
+              (MEID)", 3GPP2 TS X.S0008-A, Version 2.0, March 2014,
+              <http://www.3gpp2.org/Public_html/Specs/
+              X.S0008-A_v2.0_20140321.PDF>.
+
+7.2.  Informative References
+
+   [RFC7254]  Montemurro, M., Ed., Allen, A., McDonald, D., and P.
+              Gosden, "A Uniform Resource Name Namespace for the Global
+              System for Mobile Communications Association (GSMA) and
+              the International Mobile station Equipment Identity
+              (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014,
+              <https://www.rfc-editor.org/info/rfc7254>.
+
+   [RFC8465]  Atarius, R., Ed., "Using the Mobile Equipment Identity
+              (MEID) URN as an Instance ID", RFC 8465,
+              DOI 10.17487/RFC8465, September 2018,
+              <https://www.rfc-editor.org/info/rfc8465>.
+
+Acknowledgements
+
+   This document draws heavily on the 3GPP2 work on Numbering,
+   Addressing, and Identification in [S.R0048-A] and also on the style
+   and structure used in [RFC7254] and [RFC4122].
+
+   The author thanks Ramachandran Subramanian, Alex Gogic, Randall
+   Gellens, and Peter Saint-Andre for detailed comments.
+
+Author's Address
+
+   Roozbeh Atarius
+
+   Email: ratarius@motorola.com
+
+
+
+
+
+
+
+
+
+Atarius                       Informational                    [Page 10]
+