MEID URN: A URN Namespace for Device Identity and Mobile Equipment Identity (MEID)
A standard URN name for the identity number that 3GPP2 mobile equipment carries.
Atarius, R., "A URN Namespace for Device Identity and Mobile Equipment Identity (MEID)", RFC 8464, DOI 10.17487/RFC8464, September 2018, <https://www.rfc-editor.org/info/rfc8464>.
@misc{rfc8464,
series = {Request for Comments},
number = 8464,
howpublished = {RFC 8464},
publisher = {RFC Editor},
doi = {10.17487/RFC8464},
url = {https://www.rfc-editor.org/info/rfc8464},
author = {R. Atarius},
title = {{A URN Namespace for Device Identity and Mobile Equipment Identity (MEID)}},
pagetotal = 10,
year = 2018,
month = sep,
} RFC text
Contents
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. 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. 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. 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 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]. * "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. 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. 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. 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>. [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
ISO Plain Language
On this page
§1Why 3GPP2 Needs Its Own Namespace
Mobile equipment that is single-mode 3GPP, using only 3GPP technology to transmit and receive voice or data, or dual-mode 3GPP/3GPP2, has an International Mobile station Equipment Identity (IMEI). A URN namespace and a namespace-specific string for the IMEI are defined in RFC 7254, and for dual-mode 3GPP2 access that IMEI URN can identify the equipment.
Single-mode 3GPP2 mobile equipment that supports only 3GPP2 access technology instead has a hexadecimal MEID. Because there are fundamental differences between the MEID and the IMEI, in encoding, format and ownership, the URN defined in RFC 7254 cannot be used to represent a hexadecimal MEID.
This document specifies a URN namespace for 3GPP2 and a namespace-specific string for the MEID, fulfilling the 3GPP2 requirement to be able to use an MEID as a URN. The Namespace Identifier is 3gpp2, for identities used in 3GPP2 networks, and it is managed by 3GPP2. The specification defines only namespace-specific strings constructed from MEIDs under this identifier; these start with meid: so that they can be recognized as such. The 3GPP2 may specify other kinds of namespace-specific string under the same identifier in the future.
The RFC also warns that the MEID and the IMEI are separate identifiers and are not to be confused, and that Internet implementations will not generally possess MEID identifiers. Identifiers generated by such implementations will typically be URNs in namespaces other than 3gpp2, and may in some contexts be non-URN URIs, so implementations are advised to be ready to process URIs outside this namespace.
Two mobile network standards identify handsets differently. The 3GPP number already has a standard name, but the 3GPP2 number is formatted differently, so it needed a namespace of its own before Internet protocols could pass it around.
| Aspect | IMEI (3GPP) | MEID (3GPP2) |
|---|---|---|
| Equipment it identifies | Single-mode 3GPP, or dual-mode 3GPP/3GPP2, mobile equipment | Single-mode 3GPP2 mobile equipment that supports only 3GPP2 access technology |
| URN namespace | Defined by RFC 7254 | The '3gpp2' namespace registered by this RFC |
| Form of the name | The IMEI URN of RFC 7254 | urn:3gpp2:meid:ManufacturerCode-SerialNumber |
§3The Registered Namespace and Its Syntax
The namespace identifier is 3gpp2, at version 1, registered on 2018-06-10 by the Third Generation Partnership Project 2, with the contact given as the MEID Global Hexadecimal Administrator and the TIA TR-45 EUMAG Chair. The purpose recorded in the registration is to identify mobile equipment using technologies defined by 3GPP2, initially by a URN that embeds a 15-digit MEID unique to each individual piece of equipment.
The identifier is expressed in ASCII characters and has a hierarchical expression using Augmented Backus-Naur Form (ABNF), as defined in RFC 5234. The ABNF is reproduced below.
The namespace-specific string for an MEID contains one meidval, which is the manufacturer code, a hyphen, and the serial number. The manufacturer code is 8HEX and the serial number is 6HEX, where HEX is a digit or an upper-case letter from A to F. The future-pp2-specifier production reserves room for other namespace-specific strings that 3GPP2 may define later under the same identifier.
Identifiers in the 3gpp2 namespace are defined and assigned by 3GPP2 or an agency appointed by it, after ensuring that the URNs to be assigned are unique. Procedures are in place to ensure that each MEID is uniquely assigned by the manufacturer. The manufacturer code and serial number are permanently stored in the mobile equipment, so they persist for as long as the equipment exists, and the values once assigned are never reassigned to other pieces of equipment. No resolution is envisioned for these URNs.
RFC 8465, published at the same time, specifies how the MEID URN can be used as an Instance ID. The RFC gives an example of a 3GPP2 MEID URN: urn:3gpp2:meid:A04B0D56-02A7E3.
The name follows a fixed grammar. It starts with urn, then the namespace 3gpp2, then meid, then the maker's 8-digit code, a hyphen and the 6-digit serial number. The two parts are written in upper-case hexadecimal, so they use the letters A to F as digits as well as 0 to 9.
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
meidval = Manufacturer-Code "-" Serial-Number
Manufacturer-Code = 8HEX
Serial-Number = 6HEX
HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"§4.2The Parts of an MEID
The MEID is 15 hexadecimal digits long and is defined by 3GPP2 to uniquely identify each individual piece of mobile equipment, such as a handset or mobile phone. It has three parts.
The manufacturer code is 8 hexadecimal digits and identifies the mobile equipment manufacturer. It is chosen from a range of values allocated to the manufacturer, so that the manufacturer is uniquely identified. A manufacturer can be assigned more than one manufacturer code.
The serial number is 6 hexadecimal digits and identifies equipment within the manufacturer code, so the pair of manufacturer code and serial number identifies one handset.
The check digit is a single hexadecimal digit, the first 4 bits of octet 8. It is used as assurance of integrity in error-prone operations, for example when the MEID is used with certain types of readers during inventory-management operations. The check digit is not transmitted by the mobile equipment, so the first 14 of the 15 hexadecimal digits are used when the MEID is written as a URN.
Any future change to the format of the meid namespace-specific string would require the URN NSS change procedure, currently the publication of a future Informational RFC approved by IETF consensus. A change to the Instance ID described in RFC 8465 would require an update to that RFC.
The identity number has three parts: 8 digits for the maker, 6 digits for the device within that maker, and one check digit. The check digit catches errors when the number is read by a scanner during inventory work, and it is not sent over the air, so it is left out of the URN.
- Manufacturer code8 hexadecimal digits. Identifies the mobile equipment manufacturer, chosen from a range allocated to it.
- Serial number6 hexadecimal digits. Identifies the equipment within the manufacturer code.
- Check digit1 hexadecimal digit. Catches errors when a MEID is read during inventory work. It is not transmitted and is not in the URN.
§4.2.5Hexadecimal Encoding in Eight Octets
The MEID format is 15 hexadecimal digits encoded in 8 octets. The most significant digit of the manufacturer code is encoded in the first 4 bits of octet 1, and the most significant digit of the serial number is encoded in the first 4 bits of octet 5. The check digit occupies the first 4 bits of octet 8, and the remaining 4 bits of octet 8 are zero-padded, because only 4 bits are needed to encode the check digit.
When the MEID is included in a cellular signaling message, the check digit is omitted and only the first 7 octets are transmitted.
The RFC presents a figure as an abstract representation of a hexadecimal-encoded MEID stored in memory, and notes that the actual storage format in memory is implementation specific. The information in the RFC is meant to be a concise guide for those wishing to use the hexadecimal MEID as a URN, and nothing in it overrides the 3GPP2 specification that defines the MEID itself.
Inside the handset the 15-digit number is held in 8 bytes. Each hexadecimal digit takes 4 bits, so the check digit needs only half of the last byte, and the other half is left as zero. On the network the check digit is dropped, so 7 bytes go out.
§6Security and Privacy Rules
An MEID is usually printed outside of the box in which the mobile device ships, and may also be printed under the battery, although very few devices have removable batteries today. It can be retrieved through the device settings or by dialing *#06#. Anyone with brief physical access to the device or its box can easily obtain the MEID. MEIDs MUST NOT therefore be used as security capabilities, meaning identifiers whose mere possession grants access. The RFC notes that there are currently examples of some applications using the MEID for authorization, and that 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 device. Both are described as inappropriate uses of the MEID.
Since the MEID is permanently assigned to the mobile equipment and is not modified when the ownership of the equipment changes, even on a complete software reload, the MEID URN MUST NOT be used as a user identifier or user address by an application. Using it that way could result in communications destined for a previous owner being received by the new owner, or could let the new owner reach information or services owned by the previous owner.
Because the MEID identifies the mobile equipment, it could also 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, as described in RFC 8126, to ensure that the privacy concerns are addressed. Protocols carrying the MEID URN SHOULD, at a minimum, use strongly hop-by-hop encrypted channels, and end-to-end encryption is RECOMMENDED.
The number is printed on the box and can be read off the handset, so it is not a secret and must never be used to prove that someone owns the device. It also survives a change of owner, so it must not be used to identify a person or to address messages to them.