ISO 13400-2:2012

INTERNATIONAL ISO
STANDARD 13400-2
First edition
2012-06-01
Road vehicles — Diagnostic
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
©
ISO 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO’s
member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved

Contents Page
Foreword .iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Symbols . 3
3.3 Abbreviated terms . 4
4 Conventions . 5
5 Document overview . 5
6 Basic requirements for implementation of internet protocols . 7
6.1 General considerations . 7
6.2 Network layer requirements . 8
6.3 Transport Layer requirements . 9
6.4 Application layer requirements — Dynamic host control protocol (DHCP) .14
6.5 Application layer requirements — Data transmission order .18
7 DoIP protocol — Technical description .19
7.1 IP-based vehicle communication protocol .19
7.2 Socket handling .41
7.3 Timing and communication parameters .48
7.4 Logical addressing .49
7.5 Communication environments and recommended timings .50
8 Transport layer services .50
8.1 General information .50
8.2 Specification of DoIP layer service primitives .52
8.3 Service data unit specification .53
9 DoIP protocol usage .54
9.1 General information .54
9.2 Connection establishment and vehicle discovery .54
9.3 DoIP session .56
9.4 Vehicle network integration .58
10 DoIP entity functional requirements .64
11 Communication example message sequence charts .64
Bibliography .67
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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
ISO 13400-2 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical
and electronic equipment.
ISO 13400 consists of the following parts, under the general title Road vehicles — Diagnostic communication
over Internet Protocol (DoIP):
— Part 1: General information and use case definition
— Part 2: Transport protocol and network layer services
— Part 3: Wired vehicle interface based on IEEE 802.3
The following parts are under preparation:
— Part 4: Ethernet diagnostic connector
— Part 5: Conformance test specification
iv © ISO 2012 – All rights reserved

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 electronic control units and the external test equipment 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 electronic control units, 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. New 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 external test equipment.
The intent of ISO 13400 (all parts) is to describe a standardized vehicle interface which
— separates in-vehicle network technology from the external test equipment 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, and
— can easily be adapted to new physical and data link layers, including wired and wireless connections, by
using existing adaptation layers.
To achieve this, all parts of ISO 13400 are 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. When mapped on this model, the services specified by ISO 14229-1, ISO 14229-2 and ISO 14229-5
are divided into
a) unified diagnostic services (layer 7), specified in ISO 14229-1, ISO 14229-5, ISO 27145-3,
b) presentation (layer 6):
1) for enhanced diagnostics, specified by the vehicle manufacturer,
2) for WWH-OBD (World-Wide Harmonized On-Board Diagnostics), specified in ISO 27145-2,
SAE J1930-DA, SAE J1939:2011, Appendix C (SPNs), SAE J1939-73:2010, Appendix A (FMI),
SAE J1979-DA, SAE J2012-DA,
c) session layer services (layer 5), specified in ISO 14229-2,
d) transport protocol (layer 4), specified in this part of ISO 13400,
e) network layer (layer 3) services, specified in this part of ISO 13400, and
f) physical and data link services (layers 1 and 2), specified in ISO 13400-3,
in accordance with Table 1.
Table 1 — Enhanced and legislated WWH-OBD diagnostic specifications applicable to the OSI layers
Vehicle manufacturer
Applicability OSI 7 layers WWH-OBD document reference
enhanced diagnostics
Application (layer 7) ISO 14229-1/ISO 14229-5 ISO 14229-1/ISO 27145-3
ISO 27145-2, SAE J1930-DA,
Vehicle manufacturer SAE J1939:2011, Appendix C (SPNs),
Presentation (layer 6)
specific SAE J1939-73:2010, Appendix A (FMIs),
Seven layers
SAE J1979-DA, SAE J2012-DA
according to
ISO/IEC 7498-1
Session (layer 5) ISO 14229-2 ISO 14229-2
and
Transport (layer 4)
ISO/IEC 10731
ISO 13400-2 ISO 13400-2
Network (layer 3)
Data link (layer 2)
ISO 13400-3 ISO 13400-3
Physical (layer 1)
The application layer services covered by ISO 14229-5 have been defined in compliance with diagnostic
services established in ISO 14229-1, but are not limited to use only with them.
The transport and network layer services covered by this part of ISO 13400 have been defined to be independent
of the physical layer implemented.
For other application areas, ISO 13400-3 can be used with any Ethernet physical layer.
vi © ISO 2012 – All rights reserved

INTERNATIONAL STANDARD ISO 13400-2:2012(E)
Road vehicles — Diagnostic communication over Internet
Protocol (DoIP) —
Part 2:
Transport protocol and network layer services
1 Scope
1.1 This part of ISO 13400 specifies the requirements for diagnostic communication between external test
equipment and vehicle electronic components 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 requirements (e.g. to detect and
establish communication with a vehicle).
1.2 This part of ISO 13400 specifies features that can be used to detect a vehicle in a network and enable
communication with the vehicle gateway as well as with its sub-components during the various vehicle states.
These features are separated into two types: mandatory and optional.
1.3 This part of ISO 13400 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 disconnect).
1.4 This part of ISO 13400 specifies the following optional features:
— DoIP entity status monitoring;
— DoIP entity firewall capabilities.
2 Normative references
The following referenced documents are indispensable for the application 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 3779, Road vehicles — Vehicle identification number (VIN) — Content and structure
ISO 13400-1, Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 1: General
information and use case definition
ISO 13400-3, Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 3: Wired
vehicle interface based on IEEE 802.3
IEEE 802.3, IEEE Standard for Information Technology — Telecommunications and information exchange
between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense
multiple access with collision detection (CSMA/CD) access method and physical layer specifications
IETF RFC 147, The Definition of a Socket
IETF RFC 768, User Datagram Protocol
IETF RFC 791 (September 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 2460, Internet Protocol, Version 6 (IPv6) — Specification
IETF RFC 2375, IPv6 Multicast Address Assignments
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 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
3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 13400-1 and the following apply.
3.1.1
diagnostic power mode
abstract vehicle internal power supply state which affects the diagnostic capabilities of all ECUs on the in-
vehicle networks and which identifies the state of all ECUs of all gateway sub-networks that allow diagnostic
communication
NOTE The intent is to provide information to the external test equipment 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 part of ISO 13400, the following states are relevant: Not Ready (not all ECUs accessible via
DoIP can communicate), Ready (all ECUs accessible via DoIP can communicate) and Not Supported (the Diagnostic
Information Power Mode Information Request message is not supported).
2 © ISO 2012 – All rights reserved

3.1.2
DoIP edge node
host 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
NOTE Adapted from ISO 13400-3:2011, 3.1.2.
3.1.3
network node
component which is connected to the IP-based network (e.g. Ethernet) and which communicates using Internet
Protocol but does not implement the DoIP protocol
NOTE 1 Ethernet is an example of an IP-based network.
NOTE 2 Some network nodes might also be connected to a vehicle sub-network, but they are not DoIP gateways as
they don’t implement the DoIP protocol. Consequently, these network nodes do not interact with (e.g. respond to) DoIP-
compliant external test equipment.
3.1.4
host
node connected to the IP-based network
3.1.5
invalid source address
source address that is outside the range reserved for testers
3.1.6
logical address
means of identifying a diagnostics application layer entity
3.1.7
socket
unique identification, as defined in IETF RFC 147, to or from which information is transmitted in the network
3.1.8
unknown source address
source address that is not listed in the connection table entry
3.1.9
vehicle sub-network
vehicle network which is not directly connected to the IP-based network
NOTE Data can only be sent to and from a vehicle sub-network through the connecting DoIP gateway.
3.2 Symbols
payload length, given in bytes
number of concurrent DoIP TCP sessions that the external test equipment 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 one up to n concurrent connections to one or more items of external test equipment
, number of individual ECUs in a vehicle sub-network
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
3.3 Abbreviated terms
Alt alternative
ARP address resolution protocol
ASCII American standard code for information interchange
Auto-MDI(X) automatic medium-dependent interface crossover
CAN controller area network
DHCP dynamic host control protocol
DNS domain name system
DoIP diagnostic communication over Internet Protocol
ECU electronic control unit
EID entity identification (see Table 19)
FMI failure mode indicator
GID group identification (see Table 19)
GUI graphical user interface
IANA internet assigned numbers authority (see References [13] and [14])
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)
MAC media access control
MSC message sequence chart
NDP neighbour discovery protocol
OEM original equipment manufacturer
OSI Open Systems Interconnection
SA source address
SDU service data unit
SPN suspect parameter number
TA target address
TCP transmission control protocol
UDP user datagram protocol
VIN vehicle identification number (see ISO 3779)
XOR exclusive or
4 © ISO 2012 – All rights reserved

4 Conventions
ISO 13400 is based on the conventions discussed in the OSI Service Conventions (as specified in ISO/IEC 10731)
as they apply to diagnostic services.
5 Document overview
All parts of ISO 13400 are applicable to vehicle diagnostic systems implemented on an IP communication network.
ISO 13400 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, ISO 13400 has been developed to also meet requirements
from other IP-based systems needing a transport protocol and network layer services.
Figure 1 illustrates the most applicable application implementations utilizing DoIP.
ISO 13400-1
DoIP
general information and
use case definition
Enhanced
WWH-OBD
diagnostics
ISO 14229-1 UDS
ISO 27145-3
specification and ISO 14229-5
WWH-OBD
subset
OSI layer 7
requirements UDSonIP common message
Application
dictionary
ISO 27145-2
Vehicle
WWH-OBD
manufacturer-
OSI layer 6
common data
specific
Presentation
dictionary
ISO 14229-2 UDS
ISO 14229-2 UDS
1 : 1
session layer
OSI layer 5
session layer services
services
Session
Standardized service primitive interface
Diagnostic communication over Internet Protocol (DoIP)
ISO 13400-2
OSI layer 4
DoIP
Transport
transport
protocol
and network
layer services
OSI layer 3
Network
OSI layer 2
ISO 13400-3
Data Link
DoIP
wired vehicle
interface
based on
IEEE 802.3
OSI layer 1
Physical
Figure 1 — DoIP document reference according to OSI model
6 © ISO 2012 – All rights reserved

. . .
. . .
6 Basic requirements for implementation of internet protocols
6.1 General considerations
Subclauses 6.2 to 6.5 specify the requirements that shall be implemented by a vehicle in order to allow for
communication between the vehicle and external test equipment. Usually, this protocol standard is implemented
by one or more DoIP entities, depending on the vehicle’s network architecture. Figure 2 shows an example of
the vehicle network architecture.
In this part of ISO 13400, the requirements are assigned a unique number of the form “DoIP-yyy”, allowing for
easier requirement tracking and test case specification in ISO 13400-5.
NOTE Requirements in this part of ISO 13400 are not numbered sequentially because the order of individual
requirements changed during document development.
Requirements formulated as “The vehicle shall implement…” imply that all DoIP entities shall implement the
required functionality if not explicitly stated otherwise. If multiple DoIP entities are present on a vehicle network,
implementation details may differ slightly for each DoIP entity (e.g. for identification purposes), so that the
external test equipment is able to identify the individual DoIP gateways that support this protocol standard.
Where reference is made to RFC documents, note that the forms “must/must not” are used to express
requirements in these documents.
Vehicle network
Vehicle sub-network 1Vehicle sub-network 2
ECU 1.1 ECU 2.1
ECU 1.2 ECU 2.2
ECU 1. ECU 2.
DoIP edge
DoIP Network Network DoIP DoIP
. . .
node
. . . . . .
gateway node 1 node node 1 node
gateway 1
IP-based network
External
IP-based network
network
Activation line External test Network Network
. . .
equipment node 2 node
Figure 2 — Vehicle network architecture schematics (functional view)
[DoIP-108] Each DoIP entity on a vehicle network shall implement the protocol standard specified in this
part of ISO 13400.
6.2 Network layer requirements
6.2.1 MAC-layer
[DoIP-146] MAC addresses shall be unique and in accordance with IEEE 802.3.
The MAC layer may limit the maximum transport unit (MTU). For IEEE 802.3 based systems, the limit is usually
approximately 1 500 Bytes. In IEEE 802.3 based systems, there is no provision for fragmentation at this layer,
so the upper layer (IP) will have to handle fragmentation (i.e. send a single data packet in multiple IP packets
which fit into the MTU size of the Ethernet frames).
6.2.2 Internet Protocol (IP)
The protocol specified in this part of ISO 13400 is based on the Internet Protocol standards known as IPv4
(see IETF RFC 791) and IPv6 (see IETF RFC 2460). Although the mandatory features of this part of ISO 13400
are intended to be based on IPv6 only, use of IPv4 is specified for applications of this communication protocol
in network areas where backward compatibility to IPv4 is required. The Internet Protocol is datagram based,
unreliable and located on the network layer in accordance with the OSI layered architecture model (see Table 2).
IP is the first transmission-medium-independent protocol.
The process of how a node acquires an IP address is described in 6.4.2.
Table 2 — IPv4/IPv6 on OSI layers
OSI layer Protocol
IPv4 (IETF RFC 791; for backward
Network IPv6 (IETF RFC 2460; preferred)
compatibility reasons only)
Data link / Physical e.g. Ethernet (IEEE 802.3)
[DoIP-109] All DoIP entities on a vehicle wireline network shall implement the same Internet Protocol version,
either IPv4 in accordance with IETF RFC 791 or IPv6 in accordance with IETF RFC 2460.
It is recommended that IPv6 be used in order to benefit from the advantages (e.g. link local IP address
assignment; faster forwarding through routers) of this protocol version. IPv4 may only be used for backward
compatibility reasons (e.g. for integration into existing dealership IP networks). The support of Jumbograms for
IPv6 is optional and consequently compliance with IETF RFCs related to Jumbograms is not required in this
part of ISO 13400.
NOTE Interaction of the vehicle wireline DoIP entities with a future wireless IPv6 entity will form the subject of future
International Standards.
In accordance with 6.2.1, the MAC layer is not responsible for fragmentation.
6.2.3 Address resolution protocol (IPv4) and neighbour discovery for IP version 6 (IPv6)
The address resolution protocol (ARP) and the neighbour discovery protocol (NDP) are methods for determining
a host’s hardware (MAC) address when only the host’s IP address is known. They are also used to verify
whether an IP address is in use by another host. ARP is located on the network layer, in accordance with the
OSI layered architecture model (see Table 3).
8 © ISO 2012 – All rights reserved

Table 3 — ARP on OSI layers
OSI layer Protocol
IPv4: ARP (IETF RFC 826)
Network
IPv6: NDP (IETF RFC 4861)
Data link / Physical e.g. Ethernet (IEEE 802.3)
[DoIP-110] If IPv4 is used, each DoIP entity shall implement ARP as defined in IETF RFC 826.
NOTE Usually, each host that implements IPv4 also implements ARP, as it is an essential part of IPv4 communication
over Ethernet-based networks. Implementation of the reverse address resolution protocol (RARP) is not required as this
requires a RARP server as part of the network, which is not mandatory in IPv4 networks.
[DoIP-111] If IPv6 is used, each DoIP entity shall implement NDP as defined in IETF RFC 4861.
6.2.4 Internet control message protocol (ICMP)
The internet control message protocol (ICMP) is part of the IP suite and is used to send error messages, e.g.
to indicate that a requested service is not available or that a host could not be reached. Consequently, ICMP
is a mandatory part of an IP stack implementation and is located on the network layer, in accordance with the
OSI layered architecture model (see Table 4).
Table 4 — ICMP on OSI layers
OSI layer Protocol
IPv4: ICMP (IETF RFC 792)
Network
IPv6: ICMP v6 (IETF RFC 4443)
Data link / Physical e.g. Ethernet (IEEE 802.3)
[DoIP-112] If IPv4 is used, each DoIP entity shall implement ICMP as specified in IETF RFC 792.
[DoIP-113] If IPv6 is used, each DoIP entity shall implement ICMPv6 as specified in IETF RFC 4443.
6.3 Transport Layer requirements
6.3.1 Transmission control protocol (TCP)
The transmission control protocol (TCP) is a connection-oriented protocol, where applications on networked
hosts can establish connections to one another, over which data can be exchanged. The protocol guarantees
reliable and in-order delivery of sender-to-receiver data. Additionally, TCP provides flow control and congestion
control and also provides for various algorithms in order to handle congestion and influence flow control. This
part of ISO 13400 does not specify the specific algorithm that should be used. TCP is located on the transport
layer, in accordance with the OSI layered architecture model (see Table 5).
Table 5 — TCP on OSI layers
OSI layer Protocol
Transport TCP (IETF RFC 793)
Network IP (IPv4, IPv6)
Data link / Physical e.g. Ethernet (IEEE 802.3)
[DoIP-114] Each DoIP entity (IPv4 and IPv6) shall implement TCP as specified in IETF RFC 793.
[DoIP-115] Each DoIP entity shall implement the TCP-related requirements specified in IETF RFC 1122.
[DoIP-145] Each DoIP entity (IPv6 only) shall implement the TCP retransmission timer computation defined
in IETF RFC 6298.
TCP uses a pair of port numbers (one sending, called remote port, and one receiving, called local port) to
identify a connection. The sending port on one host will be the receiving port on the other and vice versa.
The ports listed in Table 6 are the receiving ports on the DoIP entities that shall be used for TCP connections
between external test equipment and DoIP entities.
Table 6 — Supported TCP ports
Name Protocol Port number Description Support
condition
DoIP routing messages from the
external test equipment to the
TCP 13400 (see Reference [13] for further
TCP_DATA vehicle ECUs (e.g. diagnostic mandatory
(unicast) information)
requests) and vice versa
(e.g. diagnostic responses)
[DoIP-001] Each DoIP entity shall listen to port TCP_DATA as specified in Table 6 in order to establish
communication with external test equipment trying to connect on the TCP port.
[DoIP-002] Each DoIP entity shall support TCP data sockets, where is the number of concurrent
TCP data connections supported by the respective DoIP entity.
[DoIP-003] The external test equipment shall be capable of supporting TCP data connections (TCP
data sockets). The local port (i.e. source port) will usually be chosen automatically during socket
creation; the remote port is defined by the TCP_DATA port on the vehicle.
Figure 3 shows the TCP socket states.
10 © ISO 2012 – All rights reserved

External test Server
equipment
create socket create socket
bind
listen
connect
accept
connection established
Figure 3 — TCP socket states
6.3.2 User datagram protocol (UDP)
The user datagram protocol (UDP) is a connectionless protocol. UDP does not provide the reliability and
ordering guarantees that TCP does. Packets may arrive out of order or may be lost without notification of the
sender or receiver. However, UDP is faster and more efficient for many lightweight or time-sensitive purposes.
UDP is located on the transport layer of the OSI layered architecture model (see Table 7).
Table 7 — UDP on OSI layers
OSI layer Protocol
Transport UDP (IETF RFC 768)
Network IP (IPv4, IPv6)
Data link / Physical e.g. Ethernet (IEEE 802.3)
[DoIP-006] Each DoIP entity shall implement UDP as specified in IETF RFC 768.
[DoIP-007] Each DoIP entity shall implement the UDP-related requirements in IETF RFC 1122.
UDP ports are used to identify the specific usage of UDP packets. The UDP ports specified in Table 8 are
used for vehicle information services and control commands sent using UDP packets (e.g. when broadcasting
requests to a local network).
Table 8 — UDP ports
Support
Name Protocol Port number Description
condition
Used for vehicle information requests
and control commands from the
external test equipment to the
vehicle’s DoIP entities. This port is
used as the destination port in UDP
packets sent by the external test
equipment.
13400 (see
Used for UDP packets sent by
UDP_DISCOVERY UDP Reference [13] for mandatory
the DoIP entities without having
further information)
received a request (e.g. Vehicle
Announcement message). This
port is used as the destination port
in these UDP packets. The source
port for these UDP packets may be
UDP_DISCOVERY but can also be
assigned dynamically.
This port is assigned dynamically
by the external test equipment and
used as the source port in UDP
packets when transmitting messages
(destination port set to UDP_
DISCOVERY) to DoIP entities.
UDP_TEST_EQUIPMENT_ dynamically
UDP mandatory
This port will be used as the
REQUEST assigned
destination port in UDP packets sent
by the DoIP entities as response to
the corresponding message. The
source port for these UDP packets
may be set to UDP_DISCOVERY but
can also be assigned dynamically.
NOTE 1 Table 8 does not list the UDP ports which are needed to implement other standard protocols specified in this
part of ISO 13400. Only the additional ports utilized by DoIP communication are specified.
[DoIP-008] Each DoIP entity shall listen to port UDP_DISCOVERY as specified in Table 8.
[DoIP-009] Each DoIP entity shall transmit UDP packets with the destination port set to UDP_DISCOVERY
as specified in Table 8 in order to send unsolicited DoIP messages (e.g. Vehicle Announcement
message).
[DoIP-010] The external test equipment shall listen to port UDP_DISCOVERY as specified in Table 8 in
order to be able to receive unsolicited DoIP messages.
NOTE 2 As unsolicited messages will always be transmitted to the one listening port at the external test equipment
(i.e. UDP_DISCOVERY), some kind of middleware might be required to distribute the gathered information (e.g. Vehicle
Announcement) to all interested applications that can be reached by the same IP address. Alternatively, the local port
can be used by multiple applications located on the external test equipment by using a reuse port option (e.g. SO_
REUSEPORT) as long as only multicast messages are expected.
[DoIP-011] The external test equipment shall transmit UDP messages to the DoIP entity with the UDP
destination port set to UDP_DISCOVERY.
[DoIP-135] The external test equipment shall transmit UDP messages to the DoIP entity with the UDP
source port UDP_TEST_EQUIPMENT_REQUEST dynamically assigned within the dynamic
port range (49 152…65 535).
12 © ISO 2012 – All rights reserved

[DoIP-136] The external test equipment shall listen to port UDP_TEST_EQUIPMENT_REQUEST specified
in Table 8 for at least the time A_DoIP_Ctrl after the request has been transmitted in order to
be able to receive responses to the previous UDP request messages. The port UDP_TEST_
EQUIPMENT_REQUEST shall be in the listen state before sending a DoIP request message
on this port to DoIP entities.
[DoIP-137] Each DoIP entity shall transmit UDP packets with the destination port set to UDP_TEST_
EQUIPMENT_REQUEST as specified in Table 8 in order to respond to messages which were
received through port UDP_DISCOVERY.
Depending on the implementation of the external test equipment, either the dynamically assigned UDP_TEST_
EQUIPMENT_REQUEST port will be assigned once during or before the first transmission of a UDP packet to a
DoIP entity or it can be dynamically re-assigned for each individual UDP request message and response. Also,
depending on whether messages are sent repeatedly, response messages might arrive asynchronously and
might no longer be associated with the specific corresponding request. In this case, it is up to the application of the
external test equipment to ensure that it can handle these situations (e.g. keep transmitting vehicle identification
request messages until the first vehicle identification response message arrives and then ignore the remaining
arriving vehicle identification responses). In the case of multiple external test equipment instances behind
one IP address, it is recommended that the different applications select different UDP_TEST_EQUIPMENT_
REQUEST port numbers, in order to simplify mapping the response to the matching request message.
Figure 4 depicts the UDP port usage for unsolicited DoIP messages.
Application 1 on Application on Middleware TCP/ IP stack on DoIP entity
external test external test external test
equipment equipment equipment
Reuse port
Listen ( UDP_DISCOVERY )
Listen ( UDP_DISCOVERY )
UDP source port:
Unsolicited message()
UDP_DISCOVERY or dynamically
assigned
UDP destination port:
Unsolicited message()
UDP_DISCOVERY
Target IP address: limited boadcast
Unsolicited message()
address (IPv4) / link-local scope
Multicast address (IPv6)
Middleware
Listen ( UDP_DISCOVERY )
UDP source port:
UDP_DISCOVERY or dynamically
Unsolicited message()
assigned
Unsolicited message()
UDP destination port:
UDP_DISCOVERY
Unsolicited message()
Target IP address : limited broadcast
address (IPv4) / link-local scope
Unsolicited message()
Multicast address (IPv6)
Figure 4 — UDP port usage for unsolicited DoIP messages
Figure 5 depicts the UDP port usage for DoIP request and response messages.
External test DoIP entity 1.n
equipment
Listen to UDP_TEST_EQUIPMENT_REQUEST ()
Listen to UDP_DISCOVERY()
Request()
UDP source port :
UDP_TEST_EQUIPMENT_REQUEST
UDP source port : UDP_DISCOVERY or
UDP destination port :
dynamically assigned
Response ()
UDP_DISCOVERY
UDP destination port :
UDP_TEST_EQUIPMENT_REQUEST
Figure 5 — UDP port usage for DoIP request and response messages
6.4 Application layer requirements — Dynamic host control protocol (DHCP)
6.4.1 General
The dynamic host configuration protocol is a client-server networking protocol that provides a mechanism for
allocation of IP addresses using the UDP transport protocol. DHCP provides the mechanism for a client to acquire
all of the IP configuration parameters that it needs in order to communicate successfully over the local network.
DHCP is an application layer protocol in accordance with the OSI layered architecture model (see Table 9).
[DoIP-101] It shall be ensured that none of the DoIP entities provides DHCP server services on the link
that is connected to the external test equipment, in order to avoid disturbing the external test
equipment network (e.g. sending DHCP_OFFER messages and providing different IP gateway
and DNS server addresses).
Table 9 — DHCP on OSI layers
OSI layer Protocol
IPv4: DHCP (IETF RFC 2131)
Application
IPv6: DHCPv6 (IETF RFC 3315)
Transport UDP
Network IP (IPv4, IPv6)
Data link / Physical Ethernet (IEEE 802.3)
[DoIP-014] If IPv4 is used, each DoIP entity shall implement the DHCP client behaviour as specified in
IETF RFC 2131.
[DoIP-015] If IPv6 is used, each DoIP entity shall implement the DHCPv6 client behaviour as specified in
IETF RFC 3315.
NOTE 1 When supporting either DoIP-014 or DoIP-015, considering DoIP-109 is important.
14 © ISO 2012 – All rights reserved

[DoIP-016] Each DoIP entity shall implement either the “host name option” as defined in IETF RFC 2132,
or the “fully qualified domain name” as defined in IETF RFC 4702
[DoIP-017] The host name option shall contain at minimum “DoIP-”, where
the part can be replaced with any text that meets the specific
requirements of the manufacturer.
NOTE 2 The host name option is used to allow for detection of a DoIP-compliant vehicle in a network which currently
uses a DHCP-assigned IP address. An example of the implementation of requirement DoIP-017 is the host name option
“DoIP-VIN12345678901234567” or simply “DoIP-” if the manufacturer-specific part is left empty.
[DoIP-138] Each DoIP entity shall start the IP address assignment process when the DoIP activation line
is active as specified in ISO 13400-3.
NOTE 3 Additional mechanisms might be required for vehicle network architectures containing more than one DoIP
entity, in order to ensure that all DoIP entities start assigning a valid IP address once the activation line is activated.
6.4.2 IP address assignment
6.4.2.1 General
Subclause 6.4.2 specifies how a DoIP entity acquires a valid IP address in order to communicate over an IP-
based network. In general, the following parameters are needed for IP addressing:
— IP address (IPv4, IPv6);
— subnet mask (IPv4 only);
— prefix length (IPv6 only).
If the DoIP entity is integrated into a network infrastructure, the additional parameter default gateway address
(= IP address of the default router) (IPv4, IPv6) is needed.
Based on the communication scenarios specified in ISO 13400-1, the network infrastructure provides
dynamically assigned IP addresses or requires the DoIP entity to independently assign an IP address which
does not conflict with the IP addresses of other nodes on the local network.
6.4.2.2 IPv4 address assignment
Depending on whether a DoIP entity is in an infrastructure environment or whether it operates in a direct peer
to peer connection, IP addresses need to be assigned taking into consideration the specifics of IPv4. This
subclause describes how an IP address can be configured in a minimum of time, to ensure fast connection
establishment.
[DoIP-099] Each DoIP entity shall implement the dynamic configuration of IPv4 link-local addresses as
specified in IETF RFC 3927.
To speed up the process of assigning an IP address on a direct peer-to-peer connection, it is recommended
that the values listed in Table 10 be used by the DoIP entity when verifying the link-local IP address as specified
in IETF RFC 3927. In the best case scenario, when using the values from Table 10, the DoIP entity will
have an IP address configured in two seconds. For external test equipment using the performance values
recommended by this part of ISO 13400 (listed in Table 10), in the best case scenario an IP address will be
configured after seven seconds.
IMPORTANT — If the external test equipment is based on standard operating systems, the overall time
to acquire an IP address depends on the configuration and the IP address assignment algorithms of
these operation systems, and may range from several seconds up to minutes.
Table 10 defines the IETF RFC 3927 adapted timings.
Table 10 — IETF RFC 3927 adapted timings
ISO 13400-2
IETF RFC 3927
Parameter recommended Description/rationale
value
performance values
Time before first probe message after link
PROBE_WAIT 1 s 1 s
becomes active (initial delay)
PROBE_NUM 1 message 3 messages Number of probe messages
Minimum time between ARP probe
PROBE_MIN 1 s 1 s
messages
Maximum time between ARP probe
PROBE_MAX 1 s 2 s
messages
Delay before announcing locally
ANNOUNCE_WAIT 1 s 2 s
configured IP address
ANNOUNCE_NUM
...