ISO 13400-2:2025

International
Standard
ISO 13400-2
Third edition
Road vehicles — Diagnostic
2025-06
communication over Internet
Protocol (DoIP) —
Part 2:
Transport protocol and network
layer services
Véhicules routiers — Communication de diagnostic au travers du
protocole internet (DoIP) —
Partie 2: Protocole de transport et services de la couche réseau
Reference number
All rights reserved.
ISO publications, in their entirety or in fragments, are owned by ISO. They are licensed, not sold, and are subject to the
terms and conditions set forth in the ISO End Customer License Agreement, the License Agreement of the relevant ISO
member body, or those of authorized third-party distributors.
Unless otherwise specified or required for its implementation, no part of this ISO publication may be reproduced,
distributed, modified, or used in any form or by any means, electronic or mechanical, including photocopying, scanning,
recording, or posting on any intranet, internet, or other digital platforms, without the prior written permission of ISO,
the relevant ISO member body or an authorized third-party distributor.
This publication shall not be disclosed to third parties, and its use is strictly limited to the license type and purpose
specified in the applicable license grant. Unauthorized reproduction, distribution, or use beyond the granted license is
prohibited and may result in legal action.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
Licensing and use terms
As stated above, ISO documents, as well as any updates and/or corrections, and any intellectual property or
other rights pertaining thereto, are owned by ISO. ISO documents are licensed, not sold. This document does
not in any way operate to assign or transfer any intellectual property rights from ISO to the user. ISO
documents are protected by copyright law, database law, trademark law, unfair competition law, trade secrecy
law, and any other applicable law. Users acknowledge and agree to respect ISO’s intellectual property rights
in the ISO documents.
The use of ISO documents is subject to the terms and conditions of the applicable licence agreement.
ISO documents are provided under different licensing agreement types (“Licence Type”) allowing a non-
exclusive, non-transferable, limited, revocable right to use/access the ISO documents for one or more of the
purposes described below (“Purpose”), which may be internal or external in scope. The applicable Purpose(s)
must be agreed in the purchase order and/or in the applicable licence agreement.
a) Licence Type:
1) Single registered end-user licence (watermarked in the user’s name) for the specified Purpose. Under
this license, the user cannot share the ISO document with a third party, including on a network.
2) Network licence for the specified Purpose. The network licence can be assigned to either unnamed
concurrent end-users or named concurrent end-users within the same organization.
ii
b) Purpose:
1) Internal Purpose. Internal use only within the user’s organization, including but not limited to own
implementation (“Internal Purpose”).
The scope of permitted internal use is specified at the time of purchase or through subsequent
agreement with ISO, the ISO member body in the user’s country, any other ISO member body or an
authorized third-party distributor, including any applicable internal use rights (such as for internal
meetings, internal training programmes, preparation of certification services, for integration or
illustration in internal manuals, internal training materials, and internal guidance documents). Each
internal use must be explicitly specified in the purchase order and/or in the applicable licence
agreement, and specific fees and requirements apply to each permitted use.
2) External Purpose. External use, including but not limited to:
— testing services;
— inspection services;
— certification services;
— auditing services;
— consulting services;
— conformity assessment scheme development and implementation;
— training services;
— education;
— research;
— software development and other digital platform or software-enabled digital services;
— any other services or activities conducted by the user or the user’s organization to third parties,
whether for commercial or non-commercial purposes (“External Purpose”).
The scope of permitted external use is specified at the time of purchase or through subsequent
agreement with ISO, the ISO member body in the user’s country, any other ISO member body or an
authorized third-party distributor, including any applicable external use rights (e.g. in publications,
products, or services marketed and sold by the user/the user’s organization). Each external use must
be explicitly specified in the purchase order and/or in the applicable licence agreement, and specific
fees and requirements apply to each permitted use.
Unless users have been granted use rights according to the above provisions, they are not granted the right to
share or sublicense ISO documents inside or outside their organization for either Purpose. If users wish to
obtain additional use rights for ISO documents or their content, users can contact ISO or the ISO member body
in their country to explore possible options.
If the user or the user’s organization is granted a licence for the External Purpose of providing any of the
following services to third parties:
— testing services;
— inspection services;
ii(bis)
— certification services;
— auditing services;
— consulting services,
and if any of these five (5) services reference, rely upon, incorporate, or otherwise make use of any aspect,
requirement, provision, or any other information of any ISO document, the user or the user’s organization
agrees to verify that the third party receiving such services has obtained from the ISO member body in their
country, any other ISO member body, ISO or an authorized third-party distributor, a valid licence for its own
implementation of such ISO document or other use related to such services. This verification obligation must
be included in the applicable licence agreement obtained by the user or the user’s organization.
ISO documents must not be disclosed to third parties, and users must use them solely for the purpose specified
in the purchase order and/or applicable licensing agreement. Unauthorized disclosure or use of ISO
documents beyond the licensed purpose is prohibited and can result in legal action.
Use restrictions
Except as provided for in the applicable licence agreement and subject to a separate licence by ISO, the ISO
member body in the user’s country, any other ISO member body or an authorized third-party distributor, users
are not granted the right to:
— use ISO documents for any purpose other than the Purpose;
— grant use or access rights to ISO documents beyond the Licence Type;
— disclose ISO documents beyond the intended Purpose and/or Licence Type;
— sell, lend, lease, reproduce, distribute, import/export or otherwise commercially exploit ISO documents.
In the case of documents that are joint publications (such as ISO/IEC documents), this clause applies to
the respective joint copyright ownership;
— assign or otherwise transfer ownership of ISO documents, in whole or in part, to any third party.
Regardless of the Licence Type or Purpose for which users are granted access and use rights for ISO
documents, users are not permitted to access or use any ISO documents, in whole or in part, for any machine
learning and/or artificial intelligence and/or similar purposes, including but not limited to accessing or using
them
a) as training data for large language or similar models, or
b) for prompting or otherwise enabling artificial intelligence or similar tools to generate responses.
Such use is only permitted if expressly authorized through a specific licence agreement by the ISO member
body in the requester’s country, another ISO member body, or ISO. Requests for such authorization are
considered on a case-by-case basis to ensure compliance with intellectual property rights. Specifically, it is not
possible to claim the benefit of copyright exception of Article 4 of the Directive (EU) 2019/790 of the European
Parliament and of the Council of 17 April 2019 on copyright and related rights in the Digital Single Market, for
the purpose of text and data mining on ISO documents, as ISO hereby opts out of this exception.
If ISO, or the ISO member body in the user’s country, has reasonable doubt that users are not compliant with
these terms, it can request in writing to perform an audit, or have an audit performed by a third-party auditor,
during business hours at the user’s premises or via remote access.
ii(ter)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Symbols and abbreviated terms. 4
4.1 Symbols .4
4.2 Abbreviated terms .4
5 Conformance . 6
6 DoIP introduction . 6
6.1 General information.6
6.2 Connection establishment and vehicle discovery .7
6.2.1 Direct connection scenario .7
6.2.2 Network connection scenario .8
6.2.3 Internal tester scenario (optional) .9
6.2.4 Unsecured DoIP session .9
6.2.5 Secured (TLS) DoIP session .11
6.3 Vehicle network integration . 12
6.3.1 Vehicle identification . 12
6.3.2 Multiple vehicles in a single network . 12
6.4 Communication examples using message sequence charts .14
6.5 IP-based vehicle communication protocol — General information . 15
7 Application (APP) .15
7.1 APP - Implementation of DoIP requirements . 15
7.2 APP - Data transmission order . 15
7.3 APP - DoIP entity synchronization of a vehicle's GID . 15
7.4 APP - Vehicle identification and announcement request message .18
7.5 APP - Diagnostic power mode information request and response . 23
7.6 APP - DoIP entity status information request and response .24
7.7 APP - Timing and communication parameters . 25
7.8 APP - Logical address assignment. 26
7.9 APP - Communication environments and recommended timings .27
7.10 APP - DoIP entity functional requirements .27
8 Service interface .28
8.1 General . 28
8.2 Abstrat service primitive (ASP) parameters . 29
8.2.1 ASP - Data type definitions . 29
8.2.2 ASP - DoIP_AI, address information . 29
8.2.3 ASP - Length, length of PDU. 30
8.2.4 ASP - PDU, protocol data unit . 30
8.2.5 ASP - DoIP_Result . 30
8.3 ASP - DoIP layer service interface . 30
8.3.1 ASP - DoIP_Data.request . 30
8.3.2 ASP - DoIP_Data.indication .31
8.3.3 ASP - DoIP_Data.confirm .31
9 Application layer (AL) .31
9.1 AL – Dynamic host control protocol (DHCP) .31
9.1.1 AL – General .31
9.1.2 AL – IP address assignment .32
9.1.3 AL – IP address validity and renewal . 36
9.2 AL – Generic DoIP protocol message structure .37

iii
9.3 AL – Handling of UDP packets and TCP data .42
9.4 AL – Supported payload types over TCP and UDP ports .42
9.5 AL – Diagnostic message and diagnostic message acknowledgement .43
9.6 AL – Alive check request and alive check response . 48
9.7 AL – Periodic response message structure . 49
9.8 AL – DoIP transport protocol payload type status message structure .51
10 Transport layer security (TLS) .55
10.1 TLS – Secure diagnostic communication . 55
10.2 TLS – DoIP security profile .57
10.2.1 TLS – General .57
10.2.2 TLS – Accepted TLS versions for DoIP . 58
10.2.3 TLS – Accepted cipher suites . 58
10.2.4 TLS – Accepted TLS extensions . 58
11 Transport layer (TL) .60
11.1 TL – Transmission control protocol (TCP) . 60
11.2 TL – User datagram protocol (UDP) .62
11.3 TL – Handling of UDP messages . 65
12 Network layer (NL) .65
12.1 NL – Internet protocol (IP) . 65
12.2 NL – IPv4 address resolution protocol (ARP) . 66
12.3 NL – IPv6 neighbour discovery protocol (NDP) . 66
12.4 NL – Internet control message protocol (ICMP) . 66
12.5 NL – IP-based vehicle communication protocol .67
12.6 NL – Socket handling . 72
12.6.1 NL – Connection states . 72
12.6.2 NL – General inactivity timer .74
12.6.3 NL – Initial inactivity timer . 75
12.6.4 NL – Socket handler and alive check . 75
13 Data link layer (DLL) . .78
13.1 DLL – General . 78
13.2 DLL – MAC-layer . 78
Bibliography .79

iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent
rights identified during the development of the document will be in the Introduction and/or on the ISO list of
patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31, Data
communication.
This third edition cancels and replaces the second edition (ISO 13400-2:2019), which has been technically
revised. It also incorporates ISO 13400-2:2019/Amd 1:2023.
The main changes are as follows:
— modified Figure 1 to show ISO 13400-2 DoIP payload type detection;
— specified the DoIP protocol version = 4 for this edition;
— updated subclause 7.7 APP - Timing and communication parameters, Table 12;
— added new requirement 7.DoIP-190 AL – DoIP entity diagnostic message NACK code set to 09 ;
— added new requirement 7.DoIP-191 AL – DoIP transport protocol payload type status and message
structure;
— added new requirement 7.DoIP-192 AL – DoIP entity checks for supported payload types over UDP Ports;
— modified Figure 16 to include 7.DoIP-192 new requirement;
— modified Figure 23 to include 7.DoIP-105, DoIP-193 and DoIP-194 new requirements;
— added new requirement 7.DoIP-195 AL – DoIP server supports one DoIP protocol version.
A list of all parts in the ISO 13400 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
Introduction
Vehicle diagnostic communication has been developed starting with the introduction of the first legislated
emissions-related diagnostics and has evolved over the years, now covering various use cases ranging from
emission-related diagnostics to vehicle-manufacturer-specific applications like calibration or electronic
component software updates.
With the introduction of new in-vehicle network communication technologies, the interface between
the vehicle's servers and the client DoIP entity has been adapted several times to address the specific
characteristics of each new network communication technology requiring optimized data link layer
definitions and transport protocol developments in order to make the new in-vehicle networks usable for
diagnostic communication.
With increasing memory size of servers, the demand to update this increasing amount of software and an
increasing number of functions provided by these control units, technology of the connecting network and
buses has been driven to a level of complexity and speed similar to computer networks. Various applications
(x-by-wire, infotainment) require high band-width and real-time networks (like FlexRay, MOST), which
cannot be adapted to provide the direct interface to a vehicle. This requires gateways to route and convert
messages between the in-vehicle networks and the vehicle interface to client DoIP entity.
All parts of the ISO 13400 series are applicable to vehicle diagnostic systems implemented on an IP
communication network.
The ISO 13400 series has been established in order to define common requirements for vehicle diagnostic
systems implemented on an IP communication link.
Although primarily intended for diagnostic systems, the ISO 13400 series has been developed to also meet
requirements from other IP-based systems needing a transport protocol and network layer services.
The intent of the ISO 13400 series is to describe a standardized vehicle interface which
— separates in-vehicle network technology from the client DoIP entity vehicle interface requirements to
allow for a long-term stable external vehicle communication interface,
— utilizes existing industry standards to define a long-term stable state-of-the-art communication standard
usable for legislated diagnostic communication as well as for manufacturer-specific use cases,
— can easily be adapted to new physical and data link layers, including wired and wireless connections, by
using existing adaptation layers, and
— allows connections of vehicle-internal and vehicle-external DoIP entities.
To achieve this, it is based on the open systems interconnection (OSI) basic reference model specified in
ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers.
Figure 1 illustrates an overview of communication frameworks beyond the scope of this document including
related standards:
— vehicle diagnostic communication framework, which is composed of ISO 14229-1, ISO 13400-2 (DoIP
payload type detection), ISO 14229-2, and ISO 14229-5;
— presentation layer standards, for example, vehicle manufacturer- (VM-) specific or ISO 22901 ODX;
— OSI lower layers framework, which is composed of ISO 13400-3 and ISO 13400-4.
The ISO 13400 series and ISO 14229-5 are based on the conventions specified in the OSI service conventions
(ISO/IEC 10731) as they apply for all layers and the diagnostic services.

vi
a
Definition of application layer payload types.
Figure 1 — DoIP document reference according to OSI model
Figure 2 illustrates vehicle network architecture schematics from a functional viewpoint.

vii
Figure 2 — Vehicle network architecture schematics (functional view)
This protocol standard is implemented by one or more DoIP entities, depending on the vehicle’s network
architecture. Figure 2 illustrates a client 1 (external client), which is connected to the DoIP edge node and a
client 2 (internal client) in the vehicle's internal network. If not stated otherwise, the DoIP client entities are
assumed to behave the same regardless to which network they are connected.
If necessary, this document distinguishes between an “internal client” and “external client” to apply a
requirement or statement.
In this document, the requirements are assigned a unique number of the form "X.DoIP-yyy", allowing for
easier requirement tracking and reference.
— X = OSI layer number; and
— DoIP-yyy = requirement number; and
— xL = x = OSI layer abbreviation [8 = APP, 7 = AL, 6 = PL, 5 = SL, 4 = TL, 3 = NL, 2 = DLL, 1 = PHY, 0 = ASP].
NOTE Requirements in this document are not numbered sequentially because the order of individual requirements
changed during document development.

viii
International Standard ISO 13400-2:2025(en)
Road vehicles — Diagnostic communication over Internet
Protocol (DoIP) —
Part 2:
Transport protocol and network layer services
1 Scope
This document specifies the requirements for secured and unsecured diagnostic communication between a
client DoIP entity and server(s) installed in the vehicle using Internet protocol (IP) as well as the transmission
control protocol (TCP) and user datagram protocol (UDP). This includes the definition of vehicle gateway
requirements (e.g. for integration into an existing computer network) and test equipment (client DoIP entity)
requirements (e.g. to detect and establish communication with a vehicle).
This document specifies features that are used to detect a vehicle in a network and enable communication
with the vehicle gateway as well as with its subcomponents during the various vehicle states. These features
are separated into two types: mandatory and optional.
This document specifies the following mandatory features:
— vehicle network integration (IP address assignment);
— vehicle announcement and vehicle discovery;
— vehicle basic status information retrieval (e.g. diagnostic power mode);
— connection establishment (e.g. concurrent communication attempts), connection maintenance and
vehicle gateway control;
— data routing to and from the vehicle's sub-components;
— error handling (e.g. physical network disconnects).
This document specifies the following optional features:
— DoIP entity status monitoring;
— transport layer security (TLS);
— DoIP entity firewall capabilities.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model
ISO/IEC/IEEE 8802-3, Information technology — Telecommunications and information exchange between
systems — Local and metropolitan area networks — Specific requirements — Part 3: Standard for Ethernet
ISO 13400-3, Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 3: Wired vehicle
interface based on IEEE 802.3
IETF RFC 768, User Datagram Protocol
IETF RFC 791:1981, Internet Protocol — DARPA Internet Program — Protocol Specification
IETF RFC 792, Internet Control Message Protocol — DARPA Internet Program — Protocol Specification
IETF RFC 793, Transmission Control Protocol — DARPA Internet Program — Protocol Specification
IETF RFC 826, An Ethernet Address Resolution Protocol
IETF RFC 1122, Requirements for Internet Hosts — Communication Layers
IETF RFC 2131, Dynamic Host Configuration Protocol
IETF RFC 2132, DHCP Options and BOOTP Vendor Extensions
IETF RFC 2375, IPv6 Multicast Address Assignments
IETF RFC 2460, Internet Protocol, Version 6 (IPv6) — Specification
IETF RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
IETF RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6)
IETF RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses
IETF RFC 4291, IP Version 6 Addressing Architecture
IETF RFC 4443, Internet Control Message Protocol (ICMP v6) for the Internet Protocol Version 6 (IPv6)
Specification
IETF RFC 4492, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
IETF RFC 4702, The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name
(FQDN) Option
IETF RFC 4861, Neighbor Discovery for IP version 6 (IPv6)
IETF RFC 4862, IPv6 Stateless Address Autoconfiguration
IETF RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2
IETF RFC 5289, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)
IETF RFC 7905, ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)
IETF RFC 7251, AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS
IETF RFC 8446:2018, The Transport Layer Security (TLS) Protocol Version 1.3
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 7498-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/

3.1
diagnostic power mode
abstract vehicle internal power supply state, which affects the diagnostic capabilities of all servers on the
in-vehicle networks and which identifies the state of all servers of all gateway sub-networks that allow
diagnostic communication
Note 1 to entry: The intent is to provide information to the client DoIP entity about whether diagnostics can be
performed on the connected vehicle or whether the vehicle needs to be put into a different diagnostic power mode
(i.e. technician interaction required). In this document, the following states are relevant: Not Ready (not all servers
accessible via DoIP can communicate), Ready (all servers accessible via DoIP can communicate) and Not Supported
(the Diagnostic Information Power Mode Information Request message is not supported).
3.2
DoIP edge node
host (3.4) inside the vehicle, where an Ethernet activation line in accordance with ISO 13400-3 is terminated
and where the link from the first node/host in the external network is terminated
[SOURCE: ISO 13400-3:2016, 3.1.2]
3.3
DoIP entity certificate
certificate issued by an intermediate certificate authority (3.5) to the DoIP entity presented during the TLS
handshake to the client DoIP entity to verify the authenticity of this DoIP entity
3.4
host
node connected to the IP-based network
3.5
intermediate certificate authority
intermediate CA
authority, which issues subordinal certificates to another intermediate CA or DoIP entities
3.6
intermediate certificate
certificate either stored in the client DoIP entity or presented during authentication together with the end
node certificate to complete the chain of trust
3.7
invalid source address
address outside the reserved range for client(s) DoIP entity
3.8
logical address
address identifying a diagnostic application layer entity
3.9
network node
device connected to the IP-based network (e.g. Ethernet) and which communicates using Internet protocol
but does not implement the DoIP protocol
Note 1 to entry: Some network nodes can also be connected to a vehicle subnetwork (3.14), but they are not DoIP
gateways as they do not implement the DoIP protocol. Consequently, these network nodes do not interact with (e.g.
respond to) a DoIP-compliant client DoIP entity.
3.10
root certificate authority
authority which acts as the root of trust
Note 1 to entry: Typically issues intermediate certificates (3.6) to allow an intermediate certificate authority (3.5) to
further submit certificates.
3.11
root certificate
certificate created by the root certificate authority (3.10) and used as the trust anchor
Note 1 to entry: It is securely stored and used by all entities that wants to validate end node certificates (e.g. from the
DoIP entity) together with all necessary intermediate certificates (3.6) in the chain of trust.
3.12
socket
[13]
unique identification, as defined in IETF RFC 147 , to or from which information is transmitted in the network
3.13
unknown source address
address not listed in the connection table entry
3.14
vehicle subnetwork
network not directly connected to the IP-based network
Note 1 to entry: Data can only be sent to and from a vehicle subnetwork through the connecting DoIP gateway.
4 Symbols and abbreviated terms
4.1 Symbols
payload length, given in bytes
number of concurrent DoIP TCP sessions that the client DoIP entity is required to support
in order to connect to one or more DoIP entities
number of concurrent DoIP TCP sessions that the DoIP entity needs to support in order to
accept 1 to N concurrent connections to one or more items of the client DoIP entity
, number of individual servers in a vehicle subnetwork
number of individual DoIP gateways in a vehicle network
number of individual in-vehicle network nodes
number of individual vehicle DoIP nodes in a vehicle network
number of individual vehicle external network nodes
4.2 Abbreviated terms
AEAD authenticated encryption with associated data
AL application layer
Alt alternative
APP application
ARP address resolution protocol
ASCII American standard code for information interchange
Auto-MDI(X) automatic medium-dependent interface crossover

C condition
CA certificate authority
CAN controller area network
CBC cypher block chaining
CF consecutive frame
Cvt convention: mandatory, optional
DHCP dynamic host control protocol
DLL data link layer
DNS domain name system
DoIP diagnostic communication over Internet protocol
EID entity identification
FC flow control
FF first frame
FMI failure mode indicator
GID group identification
GUI graphical user interface
GW gateway
IANA Internet assigned numbers authority
ICMP Internet control message protocol
IETF RFC Internet Engineering Task Force Request for Comments
IP Internet protocol
IPv4 Internet protocol version 4 (see IETF RFC 791)
IPv6 Internet protocol version 6 (see IETF RFC 2460)
M mandatory
MAC media access control
MCTS maximum concurrent TCP_DATA sockets
MDS maximum data size
MSC message sequence chart
MTU maximum transport unit
NCTS currently open TCP_DATA sockets
NDP neighbour discovery protocol

NL network layer
NT node type
O optional
OSI open systems interconnection
OTA over-the-air
PKI public key infrastructure
RX reception
SA source address
SDU service data unit
SF single frame
SOM start of message
SPN suspect parameter number
ASP abstract service primitive
TA target address
TCP transmission control protocol
TL transport layer
TLS transport layer security
TX transmission
UDP user datagram protocol
VIN vehicle identification number (see ISO 3779)
VM vehicle manufacturer
XOR exclusive or
5 Conformance
This document is based on the conventions discussed in the OSI service conventions as specified in
ISO/IEC 10731 as they apply to diagnostic services.
6 DoIP introduction
6.1 General information
This subclause gives an example of a standard workflow of a straightforward DoIP session. In order to
keep this introduction as helpful as possible for a reader new to DoIP, exceptions and errors that can occur
during a DoIP session are not covered here. Two possible network environments—networked and directly
connected—are explained. The figures provide a better understanding of the comprised DoIP components,
mechanisms and sequences that allow a proper DoIP session.
...