ISO/DIS 25750

ISO/TC 8/SC 26

Secretariat: SAC

Date: 2025-11-25

Ships and maritime technology — Secured Ship Network (SSN)

DIS stage

Warning for WD’s and CD’s

This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

© ISO 2025

All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.

ISO copyright office

CP 401 • Ch. de Blandonnet 8

CH-1214 Vernier, Geneva

Phone: + 41 22 749 01 11

E-mail: copyright@iso.org

Website: www.iso.org

Published in Switzerland

Contents

Foreword v

Introduction vi

1 Scope 1

2 Normative references 1

3 Terms and definitions 3

4 Abbreviated terms 6

5 Requirements for the Device Architecture 7

5.1 Scope 7

5.2 Device architecture 7

5.3 Network protocol stack 8

5.4 Device and application requirements 12

5.5 Service announcement 12

6 Physical layer 13

6.1 Scope 13

6.2 Environmental 14

6.3 Radio frequency interference 14

6.4 Device power requirements 14

6.5 Physical interfaces 14

7 Requirements for the application information 14

7.1 Scope 14

7.2 General requirements 15

8 Requirements for the datagram protocol 15

8.1 Scope 15

8.2 Datagram service 16

8.3 ISO smart ship datagram service (ISO-SSDS) 19

8.4 Proprietary datagram services 20

9 Requirements for interoperation with IPv4 device 20

9.1 Scope 20

9.2 Migration to IPv6 21

9.3 Router running network address translator (NAT64) 22

9.4 Interoperability with IEC 61162-450 network 25

9.5 Interoperation with Modbus 29

9.6 Interoperation with IEC 61162-3 , SAE J1939and ISO 11783 31

9.7 Generic Gateway 35

10 Requirements for the Application Security 36

10.1 Scope 36

10.2 General 36

10.3 TLS 1.3 and DTLS 1.3 support 5 cipher suites. Generating and transmitting master key 36

10.4 Secure network ID 36

10.5 Secure network service 36

10.6 Changing securing properties 37

10.7 Securing process 37

10.8 Open mode process 37

11 Requirements for the datagram security 38

11.1 Scope 38

11.2 General requirements 38

11.3 DTLS 1.3 record layer 38

11.4 DTLS encapsulating security payload (ESP) packets 40

11.5 Encryption and decryption process 42

11.6 Securing multicast datagram 45

11.7 Key Updating 45

Annex A (informative) NMEA OneNet 46

Bibliography 48

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 document 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).

ISO draws attention to the possibility that the implementation of this document may involve the use of (a) patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent rights in respect thereof. As of the date of publication of this document, ISO [had/had not] received notice of (a) patent(s) which may be required to implement this document. However, implementers are cautioned that this may not represent the latest information, which may be obtained from the patent database available at www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.

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 [or Project Committee] ISO/TC 8, SC 26.

A list of all parts in the ISO 25750 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.

Introduction

Smart Shipping in concert with E-Navigation and Autonomous Ship is being developed globally. Further, advancements in Information and Communication Technology (ICT) are being made to enhance navigation safety, improve the protection of the sea environment, expand economic opportunities, and optimize the commerce of the shipping industry. Successful implementation of Smart Shipping, e-Navigation and Autonomous Ship includes:

• information exchange between ship to shore, ship to ship, and shore to ship;
• ship automation using advanced technologies such as the Internet of Things (IoT), Ocean of Things (OoT), and Machine to Machine (M2M);
• situational monitoring and remote ship infrastructure monitoring and control;
• big data analysis for optimal ship operation and cyber security for the protection of data. Big data analytics can provide fault detection and diagnosis;
• predictive maintenance of engines, systems, and equipment.

These technologies can be implemented under the assumption of secure network operation and fast information exchange. An IPv6 network infrastructure supports the future needs of big data transfers between ship and shore.

IPv6 was developed from the onset to provide enhancements to IPv4 resulting in a more robust, secure, and extensible protocol, including native Quality of Service (QoS) functionality. IPv6 Ethernet network is being utilized in the maritime logistics and shipping industries due to increasing close relations between land and maritime such as the trend of smart shipping and autonomous ships. To integrate big data, secure communication, and remote control between ship and shore to ship, vessels of all sizes including SOLAS class ships will need IPv6 in future very shortly.

This document contains the minimum requirements for the implementation of the secured interconnection of marine electronic equipment on board the ship using IPv6 and integrating legacy IPv4 networks.

This document will demonstrate flexibility to support connectivity and data transfer to and from all existing international standards on shipboard sensors and network interfaces including but not limited to IEC 61162-1 based on ASCII and, IEC 61162-450 based on IPv4 Ethernet network.

The utilization of IPv6 allows this ISO standard to provide a robust, secure, and huge amount of data communication on the ship, between ship to ship, ship to shore, and shore to ship. It supports bi-directional data communication between multi-talker and/or multi-listeners at a speed of 1Gbps to 100Gbps.

This document covers interfacing and connection of all ship systems including bridge equipment, engine, cargo, and other ship systems. Equipment designed to this standard will have the ability to share secured data, including command and status.

This ISO Smart Shipping document was originally derived from 1.000 NMEA OneNet, a published standard currently maintained by the National Marine Electronics Association (NMEA), and utilizes IPv6 and security methods based on RFCs published by the Internet Engineering Task Force (IETF).The OneNet Standard was originally created for recreational marine electronics and such innovations are shared with the international standards community for enhanced safety of life at sea using marine electronics. NMEA maintains the OneNet standards publication and administers the OneNet certification program. See Annex A.

Identification of patent holders: the following text shall be included if patent rights have been identified.

The International Organization for Standardization (ISO) [and/or] International Electrotechnical Commission (IEC) draw[s] attention to the fact that it is claimed that compliance with this document may involve the use of a patent.

ISO [and/or] IEC take[s] no position concerning the evidence, validity and scope of this patent right.

The holder of this patent right has assured ISO [and/or] IEC that he/she is willing to negotiate licences under reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of the holder of this patent right is registered with ISO [and/or] IEC. Information may be obtained from the patent database available at www.iso.org/patents.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights other than those in the patent database. ISO [and/or] IEC shall not be held responsible for identifying any or all such patent rights.

Ships and maritime technology — Secured Ship Network (SSN)

This document specifies the minimum requirements for a secured ship network over Ethernet protocols that is used to collect data from the bridge, engine room, and cargo system based on Ethernet protocols of IPv6, even if the data are collected with different protocols based on IPv4 or IEC 61162- series, other ISO, and industrial standards.

To communicate with different IP address families, this document uses NAT64 network address translation specified in RFC 6144 (Framework for NAT), and RFC 6146 (Stateful NAT64). But utilizing NAT 64 may not be the only method, the other method such as the utilization of dual stack, tunneling and other methods may be utilized by the shipbuilder, ship owner, or system integrator with consideration of the effectiveness of the ship networks communications and data collections and integrations.

If a device has a Dual Stack, then devices are able to run IPv4 and IPv6 in parallel. It allows hosts to simultaneously reach IPv4 and IPv6 content, so it offers a very flexible coexistence strategy. However there are some constraints in interoperability.

Address Family Translation (AFT) may not be a long-term support strategy. However it is a medium-term coexistence strategy for integrating IPv6 and IPv4 networks on board. Almost all network standards in the maritime domain are based on IPv4, but this standard may be able to maintain interoperability with IPv4 standards and other industrial standards such as Modbus, which may be used for SCADA systems, SAE J1939 which may be used for the internal combustion engine systems.

ISA99 Cyber security on board has become vital, especially in smart and autonomous ships. This document specifies how to build up security in data acquisition through the network by authentication, integrity checking and confidentiality by utilizing recent encryption algorithms.

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 11783-1:2017, Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 1: General standard for mobile data communication

ISO 11783-3:2014, Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 3: Data link layer

ISO 11783-7:2022, Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 7: Implement messages application layer

IEC 60945:2002, Maritime navigation and radiocommunication equipment and systems - General requirements - Methods of testing and required test results

IEC 61162-3:2008, Maritime navigation and radiocommunication equipment and systems - Digital interfaces - Part 3: Serial data instrument network

EN IEC 61162-1:2024, Maritime navigation and radiocommunication equipment and systems - Digital interfaces - Part 1: Single talker and multiple listeners

EN IEC 61162-450:2018, Maritime navigation and radiocommunication equipment and systems - Digital interfaces - Part 450: Multiple talkers and multiple listeners - Ethernet interconnection

IEEE 802.1Q:2011, : Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks,

IEEE 802.3:2018, IEEE standard for Ethernet

RFC 4291:2006, IP Version 6 Addressing Architecture

RFC 1340:1992, Assigned Number

RFC 2409:1998, The Internet key Exchange

RFC 3315:2003, Dynamic Host Configuration Protocol for IPv6 (DHCPv6),

RFC 3740:2004, The multicast group security architecture

RFC 4086:2005, Randomness Requirements for Security

RFC 4291:2006, IP Version 6 Addressing Architecture

RFC 4303:2005, IP encapsulating security payloas

RFC 4443:2006, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version6 (IPv6) Specification,

RFC 4862:2007, IPv6 Stateless Address Autoconfiguration

RFC 4862:2007, , IPv6 Stateless Address Autoconfiguration

RFC 5952:2010, A Recommendation for IPv6 Address Text Representation

RFC 6052:2010, IPv6 addressing of IPv4/IPv6 Translator

RFC 6052:2010, IPv6 Addressing of IPv4/IPv6 Translator

RFC 6144:2011, Framework for IPv4/IPv6 Translation

RFC 6145:2011, IP/ICMP Translation algorithm

RFC 6146:2011, Statful NAT 64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers

RFC 6146:2011, Stateful NAT64

RFC 6742:2012, Default Address Selection for Internet Protocol Version 6 (IPv6

RFC 6970:2013, Universal Plug and Play (UPnP) Internet Gateway Device -Port Control Protocol Interworking Function (IGD-PCP IWF)

RFC 7230:2014, Hypertext Transfer Protocol (HTTP /1.1): Message Syntax and Routing,

RFC 7346:2014, IPv6 Multicast Address Scopes

RFC 7371:2014, Updates to the IPv6 Multicast Address Architecture

RFC 7404:2014, Using Only Link-Local Addressing inside an IPv6 Network

RFC 8085:2017, UDP Usage Guidelines

RFC 8200:2017, Internet Protocol, Version 6 (IPv6) Specification

RFC 8446:2018, Transport Layer Security protocol version 1.3

RFC 9146:2021, the solted challenge response authentication mechanism SASL and GSS-API mechanism

RFC 9147:2022, The Datagram Transport layer Security protocol version 1.3

RFC 9293:2022, Transmission Control Protocol

For the purposes of this document, the following terms and definitions 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/

CAN (Control Area Network)

a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other’s applications without a host computer. It is a message-based protocol, designed originally in 1983 at Robert Bosch GmbH

compliant device

a device that conforms to the requirements within this document

compliant application

an application installed on the compliant device is compliant with this document

dual stack

devices are able to run IPv4 and IPv6 in parallel

headless device

application device without Human Interface

human interface device (HID)

application device with capability of Human Interface which can commune with humans by input and output of the character

JSON (JavaScript object notation)

a lightweight data-interchange format

JSON objects

a collection of name/value pairs

mapped

a virtual representation or things corresponds with the original when the system is converted, managed by a gateway, or converting device

multicast forwarder

a Device, which forwards multicast packets between Ipv4 and IPv6 networks

well known port (WKP)

a TCP or UDP port with a number in the range 0 ~ 1023, which is assigned by the IANA

PGN

abbreviation for Parameter Group Number defined in ISO 11783-3. Identifies a specific network message

secure network

network protected by a cryptographic infrastructure

tunneling

a method for transporting data across a network using protocols that are not supported by that network

modbus

an application layer messaging protocol that provides client/server communication between devices connected on different types of buses or networks

IPv4 compatible IP address

IPv6 address of the device when the device is going to send a packet to the IPv4 device

IPv4 mapping IPv6 address

IPv6 address when an IPv4 device is going to send a packet to an IPv6 device

NAT64 prefix

network address prefix of device to perform network address translation between IPv4 and IPv6. The NAT64 prefix can be a Network specific prefix (NSP) or a Well Known Prefix (WKP). An NSP is assigned or determined by an organization. WKP for NAT64 is 64:FF9B::/96

NAT64 router

it advertises the NAT64 prefix into the IPv6-Only network and performs the translation between the IPv6-Only and IPv4-Only networks

DNS64 server

the DNS64 server is that the DNS server can provide an IPv6 address for the IPv6 host when the IPv6 host wants to connect the IPv4 host via domain name

Modbus TCP/IP ADU

application data unit for Modbus TCP/IP

SPN (Suspect parameter number)

19 bits numbers used to identify a particular element, component, or parameter associated with a control function

TLS (Transport layer security)

a cryptographic protocol designed to provide communication security using TCP protocol over the computer network

DTLS (Datagram TLS)

a cryptographic protocol designed to provide communication security using UDP protocol over the computer network

EUI-64 (Extended Unique Identifier)

allows a host to assign itself a unique 64 bit IP Version 6 interface identifier

MAC (Media access control) address

the unique identifier assigned to a Network interface card (NIC)

INI file

a configuration file for computer software that consists of a text-based content with a structure and syntax comprising key-value pairs for properties and sections that organize the properties

YAML

human readable data serialization language that is often used for writing configuration files

RAW

Raw image file used in digital camera

EPS

encapsulated PostScript file, a type of vector image file

SVG

scalable Vector Graphics, XML-based vector image format for defining two-dimensional graphics

AVI

aproprietary multimedia container format, windows standard was introduced by Microsoft

H.264 or MPEC4

advanced video coding (AVC), a video compression standard based on block-oriented, motion-compensated coding

H.265 (HEVC)

high-efficiency video coding (HEVC), or MPEC-H part2, Video compression standard

H.266 (VVC)

versatile video coding (VCC), ISO/IEC 23090-3, or MPEC-I Part 3, Video compression standard

A compliant device is hardware that provides the platform to run compliant applications. The compliant device may also contain communication components supporting IPv4 standards, including industrial standards and other general image transmission devices. This section introduces principal architecture to be compliant with the requirement of this document.

A device may be installed with several applications. Each application may include software modules which have several specific functional capabilities.

Some compliant applications may have a function to exchange information with different data transmission protocols and different address families (e.g., standards based on IPv4), thus functioning as an IP gateway or other protocol gateway. This topic is addressed in 9.7 Generic gateway.

Some compliant devices which collect information from other devices on a network compliant with this standard, extract information from the collected data and calculate and create new useful information with which to supply to a device on another network, such as a collision avoidance system.

All compliant devices shall provide the following two services.

• Service announcement (see 5.5) which broadcasts (i.e., advertises) the device’s services on the network, so that the other devices on the network may utilize these services.
• Secure Mode Service (see Clause 10, Clause 11) which operates in a secured mode on the network.

Each compliant application may contain one or more datagram services that are responsible for transmitting and receiving application data (see Clause 8). Each datagram service may have its own unique fixed or ephemeral UDP port to send and receive unicast messages and multicast messages.

The form of datagram service currently defined shall be the JSON objects. A compliant device may send and receive binary types or other IP packet types of information defined by other standards utilizing this document network. The IEC datagram device may exchange application data formatted as IEC 61162-450 on IPv4 Ethernet through NAT64 or another IP gateway mentioned in 9.7. The modbus devices which are frequently used in engine room machinery and SCADA systems may exchange information with the compliant devices on this network, which is mentioned in 9.5.

An image and streaming data with a compression algorithm may exchange the information depending on the type of payload field in the extension header.

The datagram service based on IPv4 shall communicate with the compliant device of this document via NAT64 (see Clause 9).

Datagram services for the compliant device share designated UDP ports described in 8.2.1 to receive multicast messages.

Datagram services for the Modbus TCP device share UDP port 502 to communicate over ethernet.

Simple service discovery protocol (SSDP) for service announcement described in 5.5 shares UDP port 1900 with multicast address FF0x::C IPv6 link-local.

The various components that comprise a compliant device are shown in Figure 1 as an example.

Figure 1 — Example compliant device architecture including applications for this document and other legacy standards

In Figure 1 UDP and TCP ports are as follows:

• UDP Ports nX : Fixed UDP port or ephemeral UDP port assigned by IPv6 stack.
• UDP Ports xxxx: Multicast Listen ports (See 8.2.1).
• TCP Port aX: Fixed TCP port or ephemeral. TCP port assigned by IPv6 stack.
• UDP Port 1900: Multicast SSDP port specified by UPnP.
• UDP Port 502: UDP port specified by Modbus.
• UDP Port eX: UDP port specified by IEC 61162-450 standard and this standard. (See 9.4).

Datagram services for the IEC 61162-450 device share UDP port and multicast address depends on that standard. (See 9.4.3).

This document shall utilize the IPv6 protocol. IPv6 was developed by the internet engineering task force (IETF) to cope with the exhaustion of the IPv4 address space. The advantage of IPv6 is not only the extension of IP address space, but also the use of multicast addressing is expanded, and simplified. In addition, The IPv6 Header format has been optimized and simplified, and supports better device mobility and, information security

All data transmission shall use IEEE 802.3:2018 ethernet frames. Additionally, when the standard is applied to the VLANs, devices shall support IEEE 802.1Q:2011 to address the problem of how to break large networks into smaller subnets so that broadcast and multicast traffic will not consume more bandwidth than necessary.

The following functionality described in IETF RFCs shall be supported:

• Internet protocol version 6(IPv6) as described in RFC 8200:2017.
• ICMPv6 general message format and message type described in RFC 4443:2006.
• SSDP described in UPnP.
• Using Only link-local addressing inside an IPv6 as described in RFC 7404:2014.
• IPv6 stateless address autoconfiguration as described in RFC 4862:2007.
• Dynamic host configuration protocol described in RFC 3315:2003.
• IPv6 addressing architecture described in RFC 4291:2006 and recommendation for IPv6 address text representation updated as RFC 5952:2010.
• Default address selection for IPv6 described in RFC 6742:2012 if the system uses the dual stack.

For communication with IPv4 devices, NAT 64 shall be installed on the network or all compliant devices shall have dual stack for IPv4 and IPv6 communication. The network layer of the protocol stack for NAT 64 shall support the following functionality:

• Stateful NAT64 described in RFC 6146:2011.

IPv6 link-local addressing

An IPv6 link-local address is an address that is valid only within the local broadcast domain. This address is not routable.

All compliant devices shall have at least one IPv6 Link-Local unicast address starting with FE80::/64 as described in RFC 4291:2006. Before a device starts using IPv6 stateless autoconfiguration, it needs to check whether the address is already being used by any other device. This can be achieved by the duplicate address detection (DAD) method described in the IPv6 stateless address autoconfiguration specification in RFC 4862.

At start-up, a compliant application shall select only one of these addresses to be used for that application’s communications.

An IPv6 link-local address is fixed by using the MAC address of the NIC, which is divided into two parts by the EUI-64 technique. For example, a NIC with the MAC address 00:19:80:fd:48:de will have an EUI-64 value of 001980FFFEfd48de, yielding an IPv6 link-local address of fe80::0019:80ff:fefd:48de/64 after adding the IPv6 link-local prefix of fe80::/64.

IPv6 multicast address

The structure of an IPv6 multicast address is divided into eight groups of bits as Figure 2 described in RFC 7371:2014 and RFC 7346:2014 multicast prefix 8 bits is fixed as ff00::/8.

Figure 2 — Format of IPv6 multicast address

Flag Field 1 (ff1) is a set of 4 flags, X, Y, P, T:

• P = 0 indicates a multicast address that is not assigned based on the network prefix. This indicates a multicast address as defined in RFC 4291:2006.
• P = 1 indicates a multicast address that is assigned based on the network prefix.
• If P = 1, T must be set to 1, otherwise, the setting of the T bit is defined in § 2.7 of RFC 4291.

Flag Field 2 (ff2) is a set of 4 flags, r, r, r, r, :

• 4 Flag r, r, r, r, are for future assignment.
• 4 r flags shall be set as zero and shall be ignored on receipt.

Multicast address scope is defined in RFC 7346:2014 as shown in Figure 3.

Figure 3 — Scope of multicast address

The multicast prefix is defined as follows:

• Link-local multicast address prefix; ff02::
• Site-local multicast address prefix; ff05::
• Organizational scope multicast address prefix; ff08::
• Global scope multicast address prefix assigned by IANA and valid worldwide; ff0e::
• Interface local multicast address prefix which is equivalent of the loopback address of Ipv4 ; ff01::

Multicast address for dedicating this standard shall be ff0x::ee10:0000 ~ ff0x::ee10:001f (ff0x means variable site multicast address registered to IANA).

Multicast receive UDP port is from25750 to 25781 for this document.

Anycast

An anycast address is a unicast address assigned to multiple devices around the world. Instead of identifying the individual device itself, the anycast address identifies the services it offers. This allows other devices to point to that service and reach the nearest device to offer that service without knowledge of what is the nearest device. An example might be to define an anycast address for a DNS server; the requesting device merely needs the DNS service and does not care from what actual server the service is provided. Anycast addressing is a conceptual combination of unicast and multicast.

Unicast address

The same network interface in IPv6 may have multiple unicast addresses from the same prefix by adding anycast address and a single link-local address. The IANA assigned addresses only from the 2000::/3 prefix, but the 2001:db8::/32 prefix is reserved for documentation purposes and may not be used.

The transport layer supports communication between applications running on different devices.

The IPv6 transport layer service is offered by the transmission control protocol (TCP) and user datagram protocol (UDP) described in RFC 9293:2022 and RFC 8085:2017, respectively.

Port identifiers, classified as well-known, reserved, and dynamic or private, employ different numeric ranges as shown in Table 1 and described in RFC 1340:1992.

Table 1 — Port identifiers of IPv6

An ephemeral port is a temporary communication hub used for internet protocol (IP) communications. It is created from a set range of port numbers by the IP software and used as an end client’s port assignment in direct communication with a well-known port used by a server.

All devices on the network may run proprietary protocols alongside the network as long as proprietary protocol communication does not interfere with the purpose of this standard.

Data transmission employed by a proprietary protocol shall not use the broadcast and multicast addresses specified in this standard.

If the network is operated in a dual stack environment, with IPv4 and IPv6, then it probably makes sense to use DHCPv4 and DHCPv6. To configure DHCPv6, the following limitations on IPv6 prefixes shall apply:

• IP addresses starting with 2002, unless bit 17-48 specify a valid IPv4 address.
• IP addresses starting with FE80, because this specifies a link local address.
• IP addresses starting with FEC0, because this specifies a site local address.
• IP addresses starting with FF, because this is used for IPv6 multicast addresses.

Network neutrality is the fundamental principle that all compliant applications on the network are treated as the same, without regard to the application or manufacturer. All compliant applications shall be able to work equally on the network.

All compliant applications shall contain functions for producing many cryptographically strong random quantities in order to operate the network in a secure mode. Guidance on these subjects is described in RFC 4086:2005.

Content negotiation is the mechanism used for serving different representations of a resource to the same URI to help the user agent specify which representation is the best suited for the user, e.g., which document language, which image format, which content encoding., etc.

A compliant application shall support HTTP 1.1 described in RFC 7230:2014 and also support negotiation by format (Accept), negotiation by character encoding (Accept-Charset), negotiation by natural language (Accept-Language), and negotiation by compression (Accept-Encoding).

Refer to https://wiki.whatwg.org/wiki/Why_not_conneg.

The compliant device shall announce its services using simple service discovery protocol (SSDP), which is a network protocol used to find network services or information. It is already widely used as a basic protocol for Universal Plug and Play (UPnP) in general residential and small office environments described in RFC 6970:2013 and UPnP Device Architecture 1.1 of UPnP Forum.

SSDP is defined using the header field format part that complies with the Generic Message of HTTP 1.1 and uses UDP instead of TCP, or HTTPU. Each SSDP message shall have one start line at first and be at least one of the following three.

NOTIFY *HTTP/1.1

• M-SEARCH *HTTP/1.1
• HTTP/1.1 200 OK

NOTIFY method is used for the advertisement of device service and M-SEARCH method is for search requests using multicast.

HTTP/1.1 200 OK is the response of M-SEARCH method.

• Universally unique identifier (UUID) is unique fixed value for identifying a device, which is 128 bit size as the following format described in RFC 4122.
• 4* <HexOctat> “-“ 2 * < HexOctat> “-“ 2 * < HexOctat> “-“2 * < HexOctat> “-“ 6* < HexOctat>

SSDP uses multicast address FF02::C for link-local address and UDP port 1900.

Compliant applications shall implement a minimum set of core services.

Compliant applications shall publish the set of core services through the unique service name (USN) of the SSDP format by Table 2.

Table 2 — List of required services

The Physical layer of this standard shall comply with the IEEE 802.3 standard, otherwise specifically mentioned.

Device components and circuits shall be compliant with the rules of the ship’s classification society dependent on the place of device location. All environmental requirements for the device and device components shall be compliant with IEC 60945:2002 Section 8.

Device components and circuits should be compliant with the rules of the ship’s classification society dependent on the place of device location.

Compliant devices may use the power over ethernet Type 2 (PoE+) with the approval of the ship’s classification society dependent on the place of device location.

The physical interface is described below.

The compliant devices shall use connectors that is approved by her ship classification society depending on the position in which the device is placed.

The compliant devices shall use cabling that is approved by her ship classification society depending on the position in which the cable is placed.

All interfaces of the compliant device shall support auto-MDIX so that cable connection type and configuration are appropriate to the device automatically.

The compliant device shall support auto-negotiation as defined in IEEE 802.3 clause 28.

Physical layer of the compliant devices, PoE equipment, cables, and connectors on the network shall be used with compliance of proper IEEE 802.3 series standards dependent upon the decision of the signalling rate to be used.

This section describes information and function which the compliant application shall have. An application can find where it can communicate with IPv4 network and IPv4 standard, and use the service provided by neighbour device. All compliant devices on the network shall be able to use the service of the device on the network depending on the purpose of the devices.

All compliant applications shall provide and publish the compliant application information service through simple service discovery protocol (SSDP), which is able to gather various information required for network communication including the configuration of local connections and the domain name servers and gateways. All devices shall be able to run over HTTP 1.1 compatible server or equivalent.

Each compliant application shall publish an application information resource using extension field of SSDP.

SSDP has a standard extension field specified by UPnP. UPnP also allows a vendor to add their own fields. The extended fields shall be in the format of the domain including “.” such as BOOTID.UPNP.ORG described in UPnP as a dedicated extended field. So application information resource shall be able to use this such as SHIP_NAME.SMARTSHIP.COM: “content of the resource”.

The content of this resource shall be formatted as JSON (see RFC 7159) using UTF-8 encoding with a unique name.

Application information resource shall include the following information at least listed in Table 3.

Table 3 — Required name/value pairs

This section describes how the datagram being transmitted through the network.

Each Datagram Service shall open a multicast listening socket with port numbers from 25750 to 25765 for ISO 25750 dedicated and from 25766 to 25781 for interoperability with other standard and joined the appropriate multicast group.

ISO 25750 dedicated multicast address shall be used from FF0x::EE10:0000 to FF0x::EE10:000F. For interoperability with other standard from FF0x::EE10:0010 to FF0x::EE10:001F shall be used according to the applied site (IANA registered).

The system integrator may configure multicast addresses and ports which are allocated in this standard to interoperate with another standard.

The configuration of dedicated multicast addresses and ports which are allocated in this document are as Table 4.

Table 4 — Allocation of multicast addresses and ports depending on the usage

Specific ports for interoperability with other standards are described from 9.4 to 9.7.

The multicast listener socket shall only receive multicast packets being sent from that multicast group. Compliant Applications shall use an allocated multicast listener socket for Datagram Services or shall use separate or grouped multicast listener sockets for each Datagram Service depending on the categorized data group, based on manufacturer design.

Each Datagram Service shall open a socket bound to a fixed port to listen to multicast packets or an ephemeral port to exchange Datagram service. These Datagram Service sockets are used to transmit unicast and multicast packets including data, image, and streaming.

Multicast messages

Multicast address and port number shall use a dedicate address and port dependent on the device function and datagram service in the application of the device. Multicast addresses for the datagram service range and UDP port number are assigned in this document described in 8.2.1.

Multicast addresses and ports for the standard on the IEC 61162-450 IPv4 network shall be mapped to IPv6 multicast addresses by Multicast Forwarder via NAT64 Router or dual stack described in 9.3.3 and 9.4, or other methods.

Multicast messages shall be sent from the datagram service port to the allocated port and the appropriate multicast address.

Unicast message

Unicast message of IPv6 shall be sent from datagram service port to the correspondent destination port and address depending on the device function.

Unicast messages to communicate with the application on the IPv4 network shall be sent from the datagram service port of the compliant application to the IPv4 Application via NAT64 Router or other methods.

Each smart ship datagram service (SSDS) shall publish its presence by SSDP of IPv6. Service type of application to publish as an advertisement depends on the function of its datagram service such as _smartship-ds._udp and others described in 5.5.4.

A smart ship datagram protocol message is a UDP packet that includes smartship fixed header, one or more extension headers, and a payload as specified at Table 5.

Table 5 — Structure of ISO smart ship datagram protocol message

ISO Smart ship fixed header and all extension header shall be expressed by the network byte order (big endian) unless otherwise specified.

The payload is initiated after the final extension header.

The Structure of the ISO smart ship fixed header is as Table 6. All ISO smart ship datagram service shall include ISO smart ship fixed header.

Table 6 — Structure of ISO smart ship fixed header

ISO smart ship fixed header identifies ISO smart ship datagram message, which presents ‘isosmartship’.

Header version indicates format of datagram message for this document.

The current version is 1.

The message sequence counter indicates a number of datagram services to every destination address. The message sequence counter is 16 bits unsigned integer and shall maintain a separate counter for each destination address and datagram message and for each unicast and multicast message. The message sequence counter shall increase by one after datagram message being sent. If counter is full, then shall return to zero.

Message sequence counter may learn whether lost message may exist.

Extension header increases interoperability between the different datagram protocol formats. Extension header identifies what kinds of payloads are followed. The format of the extension header is specified in Table 7.

Table 7 — Structure of ISO smart Ship extension header

Header attribute is used to provide compatibility with extension header which is not specified in this version of document or for future version of document.

Final header indicates that this extension header is final. All extension header fields of this extension header are applied to the payload.

The contents of header fields apply to interpret payload to increase interoperability between this standard and others. Clause 9 describes the structure of the extension header for interoperability with other standards based on iPv4.

Header length indicates the length of this extension header, payload not included.

This indicates the type of pay load. This document defines header type as Table 8.

Extension header details for interoperability with other standards described in Clause 9.

Extension headers for secure network operation are described at the correspondent chapter of secure operation.

Table 8 — Header type of extension header

*1 When interoperability is necessary to keep with IEC 61162-450, see EN IEC 61162-450:2018 standard.

*2 When interoperability is necessary to keep with ISO 11783-3:2014 PGN, SAE J1939, IEC 61162-3:2008, see relevant standard.

*3 When interoperability is necessary to keep with Modbus TCP, see Modbus TCP.

ISO smart ship datagram service (ISO-SSDS) protocol uses JSON data object. JSON object comprised with pair of variable name and value. Many IT development tools include a JSON parser, facilitating easy to conversion of various data types between data input and output. ISO datagram service can transmit command data, monitoring data, alarm data and image data for Radar, ECDIS, and CCTV from the engine room, bridge and other IoT sensors for awareness of navigation environment and ship safety such as fire and flooding of compartments.

The structure of extension header format for ISO smart ship datagram service (ISO-SSDS) is as follows Table 9.

Table 9 — Structure of extension header for ISO smart ship datagram service

Header type of ISO datagram service (ISO-SSDS) is 0 (see Table 8).

Header version is to keep backward interoperability.

Data naming entity is which data variable names are used in Datagram service in the payload. Different data naming entities for datagram service may be used by shipbuilders or network system manufacturers defined by this field. The unit of data is dependent on the data naming entity.

0: KOSHIPA https://www.koshipa.or.kr/

1: JSTRA https://www.jsmea.or.jp/ssap/topics/jsmea_iso19848.html

2: DNVGL https://www.data.dnvgl.com

3: Other data naming entities

There may be various types of ISO smart ship datagram service according to that of payload, almost it may be JSON object, but especially the other file format in smart ship such as XML, CSV, INI and YAML for system configuration, image file and streaming file for ECDIS, Radar and CCTV for navigation environment.

Compression algorithm to help play streaming data for application just after receiving the data from the network.

Manufacturer can transmit their own information to their devices on this network to configure or calibrate the devices. For this, manufacturer shall keep the extension header format of this document and guarantee transmission of proprietary datagram service does not prevent normal network operation of this document.

Proprietary datagram service can be transmitted by unicast only and shall not be transmitted by multicast.

This section specifies how the IPv4 and IPv6 devices can access each other devices. These requirements include IPv4 compatible IP address, IPv4 mapping IP address and multicast IP address to interoperate with standards using IPv4 address scheme.

There are some methods to exchange IP packets between IPv4 and IPv6 networks. If the device on the IPv4 network uses the dual stack to communicate with the IPv6 device, each device can be compliant with each standard of IPv4 and IPv6 simultaneously.

The address translation method is not a long-term support strategy, it is a medium-term coexistence strategy that can be used to facilitate a long-term program of IPv6 transition on board.

This standard shall not constrain the method of interoperation with the IPv4 network but recommend the examples of best practice. This chapter may be utilized optionally when specified cases are necessary to keep interoperability with standards based on IPv4 internet standards.

Scenarios for IPv6/IPv4 translation are:

• An IPv6 network to the IPv4 internet
• The IPv4 internet to an IPv6 network
• The IPv6 internet to an IPv4 network
• An IPv4 network to the IPv6 internet
• An IPv6 network to an IPv4 network
• An IPv4 network to an IPv6 network
• The IPv6 internet to the IPv4 internet
• The IPv4 internet to the IPv6 internet

In this document only the interoperation of the network between IPv6-only and IPv4-only (identified in bold text above) host by NAT64 performing IP header and address translation of two host are considered.

Stateless NAT64 defined in RFC 6145:2011 is a translation mechanism for algorithmically mapping IPv6 addresses to IPv4 addresses, and IPv4 addresses to IPv6 addresses, while NAT64 defined in RFC 6146:2011 is for the stateful translation mechanism.

IP header translation between the two address families using an algorithm is defined in RFC 6145 (IP/ICMP Translation Algorithm). IP address translation between the two address families using an algorithm is defined in RFC 6052:2010 (IPv6 Addressing of IPv4/IPv6 Translators).

There are 3 methods to migrate to IPv6: dual stack network, tunneling, and translation. The technical overview is described in RFC 6144:2011.

Dual stack is a transition technology in which IPv4 and IPv6 operate in tandem over shared or dedicated links. In a dual stack network, both IPv4 and IPv6 are fully deployed across the infrastructure, so that configuration and routing protocols handle both IPv4 and IPv6 addressing and adjacencies independently.

Although dual stack may appear to be an ideal solution, it presents two major deployment challenges to enterprises and ISPs:

• It requires a current network infrastructure that is capable of deploying IPv6. In many cases, however, the current network may not be ready and may require hardware and software upgrades.
• IPv6 needs to be activated on almost all the network elements. To meet this requirement, the existing network may need to be redesigned, posing business continuity challenges.

Using the tunneling option, organizations build an overlay network that tunnels one protocol over the other by encapsulating IPv6 packets within IPv4 packets and IPv4 packets within IPv6 packets. The advantage of this approach is that the new protocol can work without disturbing the old protocol, thus providing connectivity between users of the new protocol.

Tunneling has two disadvantages, as discussed in RFC 6144:

• Users of the new architecture cannot use the services of the underlying infrastructure.
• Tunnelling does not enable users of the new protocol to communicate with users of the old protocol without dual-stack hosts, which negates interoperability.

Address family translation (AFT), or simply translation, facilitates communication between IPv6-only and IPv4-only hosts and networks (whether in transit, an access, or an edge network) by performing IP header and address translation between the two address families.

AFT is not a long-term support strategy; it is a medium-term coexistence strategy that can be used to facilitate a long-term program of IPv6 transition by both enterprises and ISPs.

Translation offers two major advantages, as discussed in RFC 6144:

• Translation provides a gradual migration to IPv6 by providing seamless internet experience to green field IPv6-only users, accessing IPv4 internet services.
• Existing content providers and content enablers can provide services transparently to IPv6 Internet users by using translation technology, with little or no change in the existing network infrastructure, thus maintaining IPv4 business continuity.

Specific protocols such as file transfer protocol (FTP) and session initiation protocol (SIP) that embed IP address information within the payload require application-layer gateway (ALG) support for translation.

When a host located in IPv6-Only network address 2001:1234:5678:abcd::a wants to access the host located in IPv4-Only network address 10.10.10.10, the following procedure is performed shown in Figure 4. In this case the host is located on the internet (www.example.com), but it will be the same even though the host is located in the IPv4 network, if the information of the host exists in the IPv4 DNS server.

Step 1: Host A contacts the DNS64 server first, asking for an IPv6 address for the server www.example.com.

Step 2: Suppose the DNS64 server has no such record. The DNS64 server forwards the query to its forwarder, the IPv6 DNS server.

Step 3: Suppose the IPv6 DNS also has not no such record. The DNS server forwards the query to its forwarder, the IPv4 DNS server.

Step 4: IPv4 DNS server replies with the IPv4 address of www.example.com 10.10.10.10.

Step 5: This address is forwarded to the DNS64 server.

Step 6: Then the DNS64 server makes a NAT64 address for www.example.com server by prefix 2800:1503:2000:1:1::/96 to the IPv4 address in hexadecimal numbers, 0A0A:0A0A, which altogether the NAT64 address for www.example.com is 2800:1503:2000:1:1::0A0A:0A0A.

Step 7: The DNS64 server gives this address to host A.

Step 8: Host A uses this address as the destination IPv6 address to www.example.com.

Step 9: The NAT64 router translates between the IPv6 and IPv4 header.

Step 10: After the NAT64 translation, the translated IPv4 packet is forwarded to www.example.com.

Step 11: The www.example.com server replies to the NAT 64 router with an IPv4 packet.

Step 12: Then the NAT64 router translates the IPv4 packet into an IPv6 packet.

Step 13: After translation, the IPv6 packet is forwarded to host A.

When a host located in IPv4-Only network address 10.10.10.10 wants to access to Host A located in IPv6-Only network address 2001:1234:5678:abcd::a, the following procedure is performed shown in Figure 5.

Step 1: example.com send a packet to NAT 64 192.168.1.1.

Step2: NAT64 translates the address of www.example.com to IPv4 mapped IPv6 address 2800:1503:2000:1:1::0a0a:0a0a and destination address 192.168.1.1 to 2001:1234:5678:abcd::a.

Step 3: NAT64 sends the packet to Host A.

Step 4: Host A response to NAT 64 address 2800:1503:2000:1:1::0a0a:0a0a IPv6 mapped IPv4 address of www.example.com.

Step 5: The NAT64 router translates the address between the IPv6 and IPv4.

Step 6: NAT64 192.168.1.1 send packet to www.example.com 10.10.10.10.

The address prefix of NAT64 has a well-known prefix (WKP) 64:ff9b::/96 which is not used to represent a non-global IPv4 address defined in RFC 6052:2010, RFC 1918 and network specific prefix (NSP) which is assigned by an organization such as an example in the Figure 4, 2001:1234:5678::/96.

IPv6 address used to represent IPv4 nodes 10.10.10.10 in an IPv6 network using NSP 2001:1234:5678::0a0a:0a0a, which represent the same IPv4 node 10.10.10.10.

Figure 4 — Description of procedure for A host located in IPv6-Only network to communicate with www.example.com located in IPv4-only network

Figure 5 — Description of procedure for www.example.com 10.10.10.10 host located in IPv4-Only network to communicate with Host A located in IPv6-only network

Lots of information on the ship network is shared by multicast, but NAT couldn’t transmit multicast packets. It may be possible by two (2) methods which use dual stack and Multicast Forwarder.

A dual-stack device has two network interface cards (NICs) for IPv4 and IPv6 independently, so it receives multicast packet and sends it to another IP network after converting the multicast address and header. (See Figure 6).

The other way may be using a Multicast Forwarder, which receives multicast packets at each network and sends them to NAT 64 after converting them to unicast packets. NAT 64 sends the packet to the device located on the other network. The device which receives the unicast packets via NAT 64, converts to multicast packets of its network and sends them with multicast packets to the network. (See Figure 7).

Address 2800:1503:2000:1:1::0a0a:0afe is IPv4 mapped IPv6 address by the NAT 64 in Figure 7.

Figure 6 — Example for multicast transmission using dual stack device

Figure 7 — Example for multicast transmission using multicast forwarder by NAT64

The header type value of IEC 61162-450 is 1, so Table 10 shows the structure of the extension header for IEC 61162-450.

Table 10 — Structure of extension header for IEC 61162-450

Transmission of UDP multicast message specifies in chapter 6 of IEC 61162-450 standard.

Multicast address and destination port number for the transmission group are defined in Tables 4, 5, 6 in section 6.2 of the IEC 61162-450 standard.

Multicast addresses defined in the IEC 61162-450 standard are translated in the NAT 64 router defined in 9.3.3 of this standard.

Multicast addresses and ports number of IEC 61162-450 are grouped described in section 6.2 Table 4, 5, 6 of IEC 61162-450 (see IEC 61162-450 standard) to transmit IPv4 multicast packet to IPv6 network, dual stack device or Multicast Forwarder by NAT 64 may be used described in 9.3.3 with allocated multicast addresses and ports described in 8.2.1 by shipbuilder, ship owner or system integrator with consideration of network load by grouped multicast.

Table 11 — Multicast address and port numbers in IPv6 network for multicast transmission group of IEC 61162-450

Table 12 defines multicast address and destination port numbers that shall be used when transmitting binary file data. If provided by the equipment, the default multicast address or destination port number can be changed by the parameter setup system of the equipment to the multicast addresses or destination port numbers of the transmission group USR1 to USR8, RCOM, PROP in Table 11 or any in Table 12 (for example to support use of same transmission group for both “binary file” and related sentences) (see IEC 61162-450 standards).

Syslog service (see IEC 61162-450 standard) may use UDP unicast port 514 or multicast depending on the system design in Table 13.

Table 12 — Multicast addresses and port numbers in IPv6 network for multicast binary data transfer of IEC 61162-450

Table 13 — Lists other multicast addresses and port numbers in IPv6 network for other multicast services of IEC 61162-450

UDP checksum is specified in section 6.2.3 of the IEC 61162-450.

The datagram size of the UDP packet is specified in section 6.2.4 of the IEC 61162-450.

If data type in IEC 61162-450 extension header is the transmission of binary file, the structure of a binary file to transmit is specified in Table 8 of section 7.3.2 of the IEC 61162-450.

The header format to transmit binary files is defined in Table 9 of section 7.3.3.1 of the IEC 61162-450.

If the data type in IEC 61162-450 extension header is the transmission of the IEC 61162-3 PGN message, the structure of the message to transmit is specified in Table 13 of section 7.4 of the IEC 61162-450.

If the data type in IEC 61162-450 extension header is a transmission of binary file using TCP point-to-point connection, the structure of message to transmit is specified in Table 16 of section 7.6 of the IEC 61162-450.

IP address and port are specified in section 7.6.4 of the IEC 61162-450.

Modbus is an application layer messaging protocol for use with its programmable logic controllers (PLC). Modbus has become a de facto standard communication protocol and is commonly available means of connecting industrial electronic devices. Modbus is mainly implemented with Modbus RTU (remote terminal unit) using serial communication such as RS 485 and with Modbus TCP/IP using Ethernet. In industrial society, the supervisory control and data acquisition (SCADA) system which Modbus RTU and Modbus TCP are combined is often used. In this section interoperation with Modbus TCP/IP is described (see Modbus).

The header type value of Modbus TCP/IP is 4, so Table 13 shows the structure of the extension header for Modbus TCP.

Each field is encoded in big endian.

All Modbus TCP/IP ADU are sent via TCP to port 502.

Table 14 — Structure of extension header for Modbus TCP

Transaction identifier is used for transaction pairing, the Modbus server copies in the response the transaction identifier of the request.

Protocol Identifier is used for intra-system multiplexing. The MODBUS protocol is identified by the value 0.

The length field is a byte count of the following fields, including the unit identifier and data fields.

Unit identifier is used for intra-system routing purposes. It is typically used to communicate to a Modbus+ or a Modbus serial line slave through a gateway between an ethernet TCP-IP network and a Modbus serial line. This field is set by the Modbus client in the request and must be returned with the same value in the response by the server.

Modbus ADU is composed of additional address, function code, data, and error check. Modbus application protocol (MBAP) header is included in the extension header, so payload of Modbus TCP/IP is PDU (protocol data unit) as shown in Figure 8 and Figure 9.

Figure 8 — General Modbus frame

Figure 9 — Modbus TCP/IP frame

The size of Modbus PDU is limited by the size constraint inherited from the first Modbus implementation on the serial line network (max. RS485 ADU is 256 bytes including server address 1 byte and 2 bytes CRC). Therefor the size of Modbus TCP/IP ADU is 260 bytes including MBAP header 7 bytes.

The Modbus protocol defines three PDUs which are:

• Modbus Request PDU, mb_req_pdu
• Modbus Response PDU, mb_rsp_pdu
• Modbus Exception Response PDU, mb_excep_resp_pdu

Standard function codes used on the Modbus application layer protocol are described in detail in the Modbus application protocol specification.

There are three categories of Modbus function code. They are:

• Public function codes
• User defined function codes
• Reserved function codes

Public function codes are defined and validated by the Modbus.org community, which are well defined, guaranteed to be unique and publicly documented.

User defined function codes are two ranges of user defined function codes, which is from 65 to 72 and from 100 to 110 decimal. User can select and implement a function code that is not supported by the specification (See Figure 10).

Reserved function codes are currently used by some companies for legacy products and that are not available for public use.

Figure 10 — Modbus function code categories

Function codes are specified in § 6 Function codes description of Modbus Application Protocol v1.1b3.

Interoperability with PGN (parameter group number) as an application layer messaging protocol is described in this section. Those standards using PGN are IEC 61162-3 , SAE J1939 and ISO 11783. The physical layer using the PGN format is almost always CAN Bus, but some standards may use an ethernet network. This section describes the structure of the extension header to keep interoperable with standards using PGN. If its physical layer is CAN Bus, it needs a proper converting device to change the physical layer, but that physical layer conversion is outside the scope of this document.

The header type value of PGN is 2, so Table 15 shows the structure of the extension header for SAE J1939.

Each field is encoded in little endian.

Table 15 — Structure of extension header for SAE J1939

PGNs of SAE J1939 may be used in ISO 11783 and or IPv4/IPv6 ethernet. If these standards use ethernet, the length of the PGN number may be 4 bytes.

If these PGNs are used on the CAN bus, then information can be interoperable via proper gateway, e.g. CAN/IP gateway.

If PGNs are used on the IPv4 Ethernet, then information can be exchanged by this extension header with this network via NAT64 Router, which translates IPv4 address to mapped IP address to IPv6, or others.

If PGNs are used on this IPv6 ethernet, then information can be exchanged directly by this extension header.

PGN Sequence Number shall be maintained for each PGN. If the Sequence Number is overflow, then return to zero.

The specific standard type is for parsing payload effectively. If the specific standard type is 1, PGN is in SAE J1939. The network system using SAE J1939, which is mainly a diesel engine control/monitoring system, uses PGN and SPN (suspect parameter number) for detailed engine control/monitoring and DM (diagnosis message) for engine fault diagnosis.

The standard derived from SAE J1939 such as ISO 11783 shall have the NAME in order to have a functional description and numerical value that can be used in address arbitration. Table 16 shows the specific NAME field in SAE J1939.

Manufacturer code shall be issued from the proper organization.

Table 16 — ISO NAME fields

DM1 (active diagnostics) and DM2 (previously active diagnostics) are commonly used in J1939 DM (diagnostic messages). SPN is included in specific PGN. For example, PGN 65226 is the active diagnostic trouble Codes and various SPN are included in the 8 bytes PGN data field and located at the specific position according to SPN.

The structure of DTC (diagnostic trouble code) as used in a DM1 PGN is shown in Table 17.

Table 17 — Structure of DTC

The FMI (failure mode identifier) code is used along with SPN to provide specific information that relates to diagnostic trouble codes. The FMI may indicate that a problem with an electronic circuit or an electronic component has been detected.

There are several methods to communicate with applications and devices of different physical layers and data protocols. This clause describes how to communicate with different physical layers and data protocols by using dedicated gateway.

To communicate with different IP Address families, it shall use an address family translation (AFT) device or dual stack system. In addition, it shall convert the IP Header. In using dual stack, because the IPv6 and IPv4 networks are operated quite separately, the dual stack device must receive an IPv4 packet and send an IPv6 packet after converting to an IPv6 packet by himself when information flows IPv4 network to the IPv6 network.

For the discovery transition gateway shall manage two SSDPs for IPv6 and IPv4 networks each.

If each IP network is operated in secure mode, the gateway shall decrypt receiving encrypted IP packets and encrypt the decrypted IP packet for another IP network.

When using an IP gateway, devices on the IPv6 network shall be compliant with this document.

If the PGN message is transferred as an IPv4 IP packet, the gateway shall transmit packets properly to the IPv6 network.

The PGN is transferred on the CAN Bus, a dedicated CAN to IPv6 gateway shall be necessary. The IPv6 side of the gateway shall be compliant with this document.

The gateway shall announce service to the IPv6 network for the device on the CAN Bus through the SSDP of the gateway.

When the IPv6 network operates in secure mode, the gateway shall encrypt the IP packet and decrypt the IP packet to transfer information to the device on the CAN Bus.

If the gateway receives a sentence of EN IEC 61162-1:2024 through serial communication, the IPv6 side of the gateway shall be compliant with this document.

The gateway shall announce service to the IPv6 network for the device on the serial communication through the SSDP of the gateway.

When the IPv6 network operates in secure mode, the gateway shall encrypt the IP packet and decrypt the IP packet to transfer information to the device on the serial communication.

This section specifies how an Application in the device can communicate in secure mode. These requirements include the generation of the master key, network ID, changing operation mode, and human interface device (HID) requirements to change operating mode.

All compliant applications shall have functionality to generate 32 bytes client random or server random and 48 bytes premaster secret and master secret to carry out only TLS 1.3 or later and only DTLS 1.3 or later Handshake described in RFC 8446:2018.

This standard shall use TLS 1.3 handshake for all compliant applications.

HID which is used for network management to change network operating mode shall have the functionality to generate 256 bytes master key and network ID.

When HID tries to change the network operating mode from open mode to secure mode, first, the HID shall carry out the TLS 1.3 handshake process with applications to transmit the master key.

During the handshake process, the Application shall use Certificate Request, Certificate and Certificate Verify options. After exchanging the Finished Message, the HID transmits the Master Key and Network ID to the application. This process shall repeat with every application to operate in secure mode on the network.

The Master Key is generated by the pseudorandom number generator. The HID uses only the first 256 bits of the generated Master Key for the Master Key. See 11.5.1.

The network ID is a 32-bits. The network ID shall be used to distinguish secure network in the overall network. The several different secure networks may be operated separately in an overall network. The network ID is generated by the pseudorandom number generator of the HID and uses only first 32-bit as network ID.

The network ID and Master Key shall be used as a pair. The HID shall maintain the pair of network ID and Master Key.

All compliant application shall provide ISO secure network service, which announces through service announcement described in 5.5 Service announcement.

This service runs on a HTTP 1.1 server and is secured with TLS -1.3 (see RFC 8446).

The SSDP service type _smartship-securing._tcp shall be used with id and path in Table 18 described in 7.2.2 Application information resource.

Table 18 — Required SSDP key/value pairs

The value of id depends on the securing state of the network:

• Applications in the unsecured state shall set id to “unsecured”.
• Applications in the secured state shall set id to secured network ID encoded as lower-case hexadecimal string eight characters long.

Each compliant application shall publish an attribute of compliant securing service over HTTP with application/Json type in the SSDP extension field described in Table 18. The application information shall include application information specified in Table 3 at 7.2.3. Each compliant application shall be able to change securing properties by HID remotely which controls network operation status.

To change the network operation over securing mode, one of HIDs on the network, which manages network operation, shall confirm whether the compliant device or compliant application is certified or not during the TLS 1.3 handshake process one by one. During TLS 1.3 handshake, the application shall use CertificateRequest, Certificate, and CertificateVerify and the HID shall respond with Certificate and CertificateVerify. The HID and Application shall continue to process after receiving the Finished Message from each other.

Step 1: The HID shall generate the Master Key and network ID as a pair.

Step 2: The HID as a client starts Client Hello handshake with a compliant application.

Step 3: After establishing a secure network with a compliant application and receiving a Finished Message from a compliant application, HID sends the Master Key and network ID to a compliant application by HTTP PUT request to the resource in the path designated by SSDP extension field encrypted with negotiated cipher suite. The HID encodes the Master Key and network ID with application/Json type name/value pairs:

• network ID: encoded as a low-case hexadecimal string eight characters long
• Master Key: encoded with base64

If this process is successful, a compliant application shall return HTTP status code 20 and close the connection.

Step 4: The HID repeats Client Hello handshake with other compliant applications one by one above steps.

The HID changes secure network over open mode, the HID shall use the SSDP service type smartship-securing._tcp with network ID set open and delete Master Key using HTTP DELETE request.

This section describes how encapsulation of payloads are carried out for secure datagram transmission. These requirements include secure operation for unicast and multicast transmission by TLS 1.3 (RFC 8446) and DTLS 1.3 (RFC 9147:2022) protocols.

When the network operates in secure mode, all datagram protocol messages shall be secured with TLS/DTLS 1.3 or later (see RFC 9147) as described in this chapter. Unsecured datagram protocol messages with TLS/DTLS 1.3 or later shall be ignored.

DTLS uses the same handshake message as TLS 1.3. However, before transmission they are converted to DTL shandshake messages, which contain extra data needed to support message loss, reordering, and message fragmentation.

In DTLS 1.3, the message transcript is computed over the original TLS 1.3 style handshake message without the message_seq, fragment_offset, and fragment_length values.

Even though DTLS 1.3 keeps backward interoperability with DTLS 1.2, this standard shall use DTLS 1.3.

Fixed length of DTLS connection_id (CID) shall be used as described in RFC 9146. The CID value, cid_length bytes long as agreed at the time the extension has been negotiated shall be used.

In order to avoid IP fragmentation, clients of the DTLS record layer should attempt to size records so that they fit within any path MTU (PMTU) estimates obtained from the record layer.

The DTLS epoch is initially zero and incremented on every KeyUpdate.

The sequence counter is incremented in every DTLS transmission. The sequence counter is reset to 0 for each epoch.

The DTLS 1.3 unified header is as shown in Figure 11, because this standard uses fixed CID described in RFC 9146:2021, 6 bytes sequence counter, 2 bytes length, and epoch.

Figure 11 — DTLS 1.3 Unified Header

Where C is CID present bit, S sequence number length bit, L length present bit, E epoch bit.

High 3 bits 001 are set for DTLS 1.3. The S bit 1 means low order 16 bits of the record sequence number and 0 for 8 bits number of it. The Presence bit 1 means present. Length is identical to the length field in a TLS 1.3 record.

So DTLS 1.3 structure for DTLSPlaintext, and DTLSCiphertext (full) are illustrated in Figure 12.

Figure 12 — DTLS 1.3 Structure for DTLSPlaintext and DTLSCiphertext (full): (a) Structure for DTLSPlaintext (b) Structure for DTLSCiphertext (full)

The first byte of the DTLS 1.3 Unified Header is the content type of DTLSPlaintext, which determines how an incoming DTLS record is demultiplexed as described in section 4.1 of the RFC 9147.

For the minimal structure of DTLSCiphertext, see Figure 4 of RFC 9147.

Sequence numbers shall be maintained separately for each epoch, with each sequence number initially being 0 for each epoch.

The epoch number is initially zero and is incremented each time keying material changes and a sender aims to rekey.

Epoch values 0 to 3 are used for special messages described in section 6.1 of the RFC 9147.

Epoch values 4 to 2^{^64}-1 are used for payloads protected using, has been used to encrypt and integrity protect a message.

When the Sequence number is full, then a new key shall be generated and transferred by DTLS Handshake. It may use Zero-RTT handshake.

The IPv6 packet is composed of the IPv6 Header, ISO smart ship fixed header (ISO SSFH), ISO smart ship datagram service header (ISO SSDSH), and ISO smart ship datagram service contents. All headers and ISO smart ship datagram service contents except the IPv6 header are located in the IPv6 payload.

DTLS 1.3 encrypts overall of the payload. The structure of DTLS cipertext is as Figure 13.

Figure 13 — Structure of DTLS cipher text

The fragment of the DTLS plaintext record in Figure 13 includes the ISO smart ship fixed header, ISO smart ship datagram service header, and ISO smart ship datagram service contents.

Content type is the first byte of DTLS 1.3 unified header, which is used to distinguish the following contents as in Table 19.

Table 19 — Meaning of content type value

This document shall use integrity combined mode algorithms, which combine encryption and integrity into a single operation, so the structure of ESP is shown in Figure 14 described in RFC 4303:2005. The combined mode algorithm provides integrity for the payload and for the SPI and sequence number fields.

Figure 14 — Detail structure of ESP

This unsigned 32-bit field contains a counter value that increases by one for each packet sent. For a unicast security association (SA) or a single sender multicast SA, the sender shall increment this field for every transmitted packet.

This document shall use anti-replay disabled.

When an SA is established newly, this field shall be initialized to zero (0).

The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. For a unicast SA, the SPI may be used by itself to specify an SA. Because the SPI value is generated by the receiver for a unicast SA, whether the value is sufficient to identify an SA by itself is described in RCF 4303 §2.1.

This document uses authenticated encryption with an associated data (AEAD) algorithm to encrypt and decrypt plaintext.

The cipher suite shall be used with DTLS_AES_256_GCM_SHA384 selected one when it is decided during the TLS handshake process.

The authenticated encryption operation has four inputs, each of which is an octet string:

• A secret key K, which shall be generated in a way that is uniformly random or pseudorandom.
• A nonce N. Each nonce provided to distinct invocations of the authenticated encryption operation must be distinct, for any particular value of the key.
• A plaintext P, which contains the data to be encrypted and authenticated.
• The associated data A, which contains the data to be authenticated, but not encrypted.

A single output is:

• A ciphertext C, which is at least as long as the plaintext, or an indication that the requested encryption operation could not be performed.

This document shall use a 256-bit secret key. To generate keying material and salt values, AES-GCM-ESP uses Internet Key Exchange (IKE) described in RFC 2409:1998. IKE makes use of a pseudo-random function (PRF) to derive keying material. The PRF is used iteratively to derive keying material of arbitrary size, called KEYMAT. The size of the KEYMAT for AES-GCM-ESP must be four octets longer than is needed for the associated AES key, so for 256-bit secret key 36 octets KEYMAT is necessary. The first 32 octets are the 256-bit AES key, and the remaining four octets are used as the salt value in the nonce.

Session key for unicast transmission and Group key for multicast shall be generated by each device and encrypted with AES_256_GCM_SHA384 using master secret key and shared with each other.

Group key and session key shall be regenerated for every new SA because keys are invalid by the sequence number reset.

This document shall not use zero-length nonce.

The length of the nonce shall be 12 bytes and composed of 4 bytes Salt and 8 bytes initial vector (IV).

Salt value for sender and receiver shall be different. The nonce is composed of as Figure 15.

Figure 15 — Structure of nonce

Salt 4 bytes may be a fixed-common value designated by the ship owner, shipbuilding company, system integrator of ship network, or correspondent ship classification society. The IV 8 bytes are the counter value of the message to be transmitted.

The IV shall not be used repeat with the same secret key K.

In this standard the same key for encrypting and decrypting packets shall be used, so two peers shall be assigned different salt values to the security association SA described in RFC 4106.

Plain text is to be both confidentiality and message authentication. The plaintext input contains all data that followed the ISO smart ship fixed header in original plaintext packet including all extension headers and payload.

Associated data A is concatenated from the followings:

• 4 bytes SPI
• 4 bytes extended Sequence Number from DTLSPlaintext

Using the above nonce N and associated data A, plain text shall be encrypted using proper secret key K described in 11.5.1 and AES_256_GCM_SHA384 algorithm shown as in Figure 16.

Figure 16 — Encryption process for ESP message encapsulation

Using above nonce N and associated data A, ciphertext shall be decrypted using proper secret key K described in 11.5.1 and AES_256_GCM_SHA384 algorithm shown as in Figure 17.

Figure 17 — Decryption process for ESP message encapsulation

ISO Smart ship Network uses the concept of multicast group security architecture described in RFC 3740:2004.

This section describes how to establish security of multicast Datagram by modification of centralized design in RFC 3740 for the scope of this document.

Mostly there is only one multicast group on board, but there may be some multicast groups in ocean plant and special ship (see Figure 18).

Figure 18 — GSA (group security association) and SAs

Each host shall generate a GK (group key) and send his own GK to the member of the group. When the host sends a multicast message to the group, GK is used to encrypt and decrypt the message. Whenever a multicast message is sent, the sequence counter increases by one. When the sequence counter overflows, then the sequence counter reset to zero (0) then GK is not valid anymore. Before the GK is invalid, a compliant application shall regenerate his own GK and send it to the member of the group. When a compliant application sends a new GK to the member of the group, he encrypts a new GK with a master key. Master key has been shared when the network changes over to secure mode.

When the multicast group is not many and not too big, management of GSA (group security association), and GK may be considered.

The management of GSA and GK are not used separately, a compliant application shall have those functionalities.

When the HID begins to change operating from open mode to secure mode, the HID (Client) shall generate the master key described in 10.3 and connect to each device (Server) to be included in secure network operation using TLS 1.3 handshake process and transmit generated master key. After that, the circumstance is needed to change the master key, the HID may use PSK directly by ZRTT.

Session key, group key, and other materials for the secure process such as new session ticket, and new connection ID shall be updated by DTLS 1.3 post-handshake messages using NewSessionTicket, KeyUpdate, NewConnectionID, RequestConnectionID or Post-handshake client authentication.

1. 
   (informative)
   
   NMEA OneNet
   1. Introduction

The NMEA ONENET® standard was created by an international consortium of marine electronic manufacturers, government and private industries, and the OneNet Standards Committee. It represents the natural, technological evolution of marine interface standards from NMEA 0183 to NMEA 2000 to OneNet. The OneNet standard is maintained by the OneNet Standard Committee and interested marine electronics manufacturer expert groups like the United States Coast Guard and other interested organizations for the primary purpose of boating safety. NMEA 0183 (IEC 61162-1) provides serial-data distribution from a single transmitter to multiple receivers. NMEA 2000 (IEC 61162-3) is an open, real-time, deterministic networking standard for the maritime industry based on Controller Area Network (CAN).

The OneNet Standard for IP Networking of Marine Electronic Devices is an open industry standard based on Internet Protocol, Version 6 (IPv6) and the IEEE 802.3 Ethernet Local Area Network. OneNet provides a common network infrastructure for marine devices and services on IPv6. All OneNet application protocols, such as PGN Messages, are designed to use a standard IPv6 network protocol stack. This allows OneNet to co-exist with other protocols and services that operate in parallel on the same network (including other marine standards such as IEC 61162-450).

Finally, the standard also specifies mechanisms for connecting OneNet networks, NMEA 2000 networks, and other networks via gateway devices.

• • 1. OneNet Goals
• To specify the transport of NMEA Network Messages over IPv6
• To utilize standard IP network and addressing infrastructure
• To facilitate the safe and secure communication and operations among equipment
• To co-exist with other IP protocols/services on the same cable
• To discover devices and services automatically to create an extendible and scalable network architecture
• To define an open interface to interoperate with current and upcoming open services
• To deliver interoperability with the established industry standards including NMEA 2000 (i.e., establishing gateway rules between NMEA 2000 and OneNet and other protocols)
• To support high-bandwidth applications such as audio/video data transport
  • 1. NMEA Message Database

NMEA Network Message Database, National Marine Electronic Association, www.nmea.org.

The NMEA message database consists of Marine-Specific binary messages with specific number assignments associated -with Marine use located within the SAE J1939 Digital Annex.

These messages are used amongst devices that meet a certification requirement for marine use.

• • • 1. NMEA Message list

Message Categories:

• Alerts
• Vessel
• System
• Sub-System
• Propulsion
• External Environment
• Internal Environment
• Identification
• Safety
• Position
• Speed
• Electrical Distribution
• Energy Storage
• Radar
• Lighting
• Cargo
• Elevator

List is maintained by the NMEA/IMEA.

• • 1. Message Database Application Guidance

NMEA messages carry requirements for Query and Commands using industry supported methods. NMEA Message Database Appendix D Application Notes contains the proper methods when using messages approved by the NMEA (1.2.1 NMEA Message list). NMEA certified devices must be used for proper use of NMEA /IMEA protocols.

Bibliography

[1] 1.000:2020, NMEA OneNet

[2] ISA99, Industrial automation and control system security