doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc6142.txt b/doc/rfc/rfc6142.txt
new file mode 100644
index 0000000..6ac3a13
--- /dev/null
+++ b/doc/rfc/rfc6142.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Moise
+Request for Comments: 6142                                    J. Brodkin
+Category: Informational                              Future DOS R&D Inc.
+ISSN: 2070-1721                                               March 2011
+
+
+         ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP
+
+Abstract
+
+   This RFC provides a framework for transporting ANSI C12.22/IEEE
+   1703/MC12.22 Advanced Metering Infrastructure (AMI) Application Layer
+   Messages on an IP network.
+
+   This document is not an official submission on behalf of the ANSI
+   C12.19 and C12.22 working groups.  It was created by participants in
+   those groups, building on knowledge of several proprietary C12.22-
+   over-IP implementations.  The content of this document is an
+   expression of a consensus aggregation of those implementations.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6142.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+
+
+
+Moise & Brodkin               Informational                     [Page 1]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................3
+   3. Definitions .....................................................3
+   4. The C12.22 IP Network Segment ...................................6
+      4.1. Composition of a C12.22 IP Network Segment .................6
+      4.2. Native IP Address ..........................................7
+      4.3. Encoding of Native IP Addresses ............................7
+      4.4. Standardized Port Numbers ..................................9
+      4.5. Use of UDP Source Port 0 ...................................9
+      4.6. IP Multicast ..............................................10
+      4.7. IP Broadcast ..............................................12
+      4.8. Encoding of Multicast and Broadcast Addresses .............12
+   5. IP Message Transport ...........................................14
+      5.1. C12.22 Connection Types and TCP/UDP Transport Modes .......14
+      5.2. IP Message Transport Details ..............................15
+           5.2.1. TCP and UDP Port Use ...............................15
+           5.2.2. Active-OPEN UDP Mode (CL=1, CL Accept=0) ...........16
+           5.2.3. Passive-OPEN UDP Mode (CL=1, CL Accept=1) ..........17
+           5.2.4. Active-OPEN TCP Mode (CO=1, CO Accept=0) ...........17
+           5.2.5. Passive-OPEN TCP Mode (CO=1, CO Accept=1) ..........18
+           5.2.6. TCP and C12.22 Message Directionality ..............18
+      5.3. Using IP Broadcast/Multicast ..............................19
+      5.4. Transport Protocol Decisions ..............................20
+           5.4.1. Unicast Versus Multicast Versus Broadcast ..........20
+           5.4.2. Sending Large C12.22 APDUs Using UDP ...............20
+           5.4.3. Choice of Protocol for C12.22 Response APDUs .......20
+      5.5. Quality of Service ........................................20
+      5.6. Congestion Control ........................................21
+   6. Security Considerations ........................................21
+   7. IANA Considerations ............................................23
+   8. Acknowledgments ................................................23
+   9. References .....................................................23
+      9.1. Normative References ......................................23
+      9.2. Informative References ....................................25
+
+
+
+
+
+
+
+
+
+
+
+
+Moise & Brodkin               Informational                     [Page 2]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+1.  Introduction
+
+   The ANSI C12.22 standard [1] provides a set of application layer
+   messaging services that are applicable for the enterprise and End
+   Device components of an Advanced Metering Infrastructure (AMI) for
+   the Smart Grid.  The messaging services are tailored for, but not
+   limited to, the exchange of the Data Table Elements defined and
+   co-published in ANSI C12.19 [2], IEEE P1377 [3], and MC12.19 [23].
+   These standards were developed jointly by ANSI (ANSI C12.22 and ANSI
+   C12.19), IEEE (IEEE 1377 and IEEE 1703), and Measurement Canada
+   (MC12.19 and MC12.22).
+
+   ANSI C12.22, which is an application level messaging protocol, may be
+   transported over any underlying transport network.  This RFC defines
+   the requirements governing the transmission of ANSI C12.22 Messages
+   via the TCP and UDP transports in IP networks (whereby the OSI
+   Session, Presentation, and Application Layers of ANSI C12.22 are
+   collapsed into a single Application Layer).
+
+   Specifically, this RFC applies to the operational details of
+   Section 5, "C12.22 Node to C12.22 Network Segment Details", of ANSI
+   C12.22, and covers the mapping, encoding, and interpreting of ANSI
+   C12.19 Device Network Table Elements and Native Addresses for use on
+   IP networks.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [4].
+
+   Throughout this document, we use terms like "ANSI C12.22" or "ANSI
+   C12.19", as in "C12.22 Relay" or "ANSI C12.19 Device".  These terms
+   are interchangeable with the terms "IEEE 1703 Relay" and "IEEE 1377
+   Device", respectively.  However, the recent versions of the Utility
+   End Device communication standards were developed under the auspices
+   of ANSI C12 SC17 WG1 and ANSI C12 SC17 WG2.  For that reason, the
+   terminology used in this document expands on the ANSI C12.22-2008 [1]
+   and ANSI C12.19-2008 [2] definitions as revised by IEEE 1703-2010 [5]
+   and IEEE 1377-2010 [3].
+
+3.  Definitions
+
+   This specification uses a number of terms to refer to the roles
+   played by participants (actors) in, and objects of, the ANSI C12.22
+   [1], IEEE 1703 [5], and MC12.22 [24] protocol.  Any terms prefixed by
+   "C12.22" or "C12.19" that are not defined in this document can be
+   resolved in [1], [5], [24] or in [2], [3], [23].
+
+
+
+Moise & Brodkin               Informational                     [Page 3]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   ACSE
+
+      Association Control Service Element.  In the context of this
+      specification and of [1], ACSEs are encoded per ISO/IEC 10035-1
+      [6] using the ASN.1 Basic Encoding Rules (BER) [7].
+
+   Active-OPEN UDP
+
+      Active-OPEN UDP is a state used by a local C12.22 IP Node to
+      expect and receive incoming C12.22 Messages that it solicited from
+      a foreign C12.22 IP Node using UDP.  The local C12.22 IP Node MAY
+      exit the Active-OPEN UDP state when it has received all of the
+      expected C12.22 Messages or a C12.22 Message timeout has occurred.
+      The local C12.22 IP Node receives all C12.22 Response Messages
+      solicited from the foreign C12.22 IP Node that arrive at the local
+      port number that matches the source port number used to solicit
+      the C12.22 Messages from the foreign C12.22 IP Node.
+
+   Active-OPEN TCP
+
+      Active-OPEN TCP is a state used by a local C12.22 IP Node to
+      establish a TCP connection with a fully specified foreign C12.22
+      IP Node using TCP and the foreign C12.22 IP Node's registered
+      Native IP Address.  The Active-OPEN TCP state is identical to a
+      local "Active-OPEN" as defined in [9].
+
+   APDU
+
+      Application Protocol Data Unit.  In the context of the ANSI C12.22
+      Application, it is an ACSE C12.22 Message.
+
+   ACSE APDU
+
+      ACSE Application Protocol Data Unit; same as APDU.
+
+   ApTitle
+
+      An ANSI C12.22 Application-process Title.  An ApTitle is a name
+      for a system-independent application activity that exposes
+      application services to the application agent, e.g., a set of
+      application service elements that together perform all or part of
+      the communication aspects of an application process.  An ApTitle
+      is encoded as a unique registered (as per [1]) object identifier.
+
+   C12.22 IP Node
+
+      A C12.22 Node that is located on a C12.22 IP Network Segment and
+      communicates using the Internet Protocol.
+
+
+
+Moise & Brodkin               Informational                     [Page 4]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   C12.22 IP Network Segment
+
+      A collection of all C12.22 IP Nodes that implement the IP-based
+      protocols, as defined in this specification, and can communicate
+      with each other using IP routers, switches, and bridges and
+      without the use of a C12.22 Relay.
+
+   C12.22 IP Relay
+
+      A C12.22 IP Node that performs the functions of a C12.22 Relay.
+      A C12.22 IP Relay acts as a bridge between a C12.22 IP Network
+      Segment and an adjacent, C12.22 Network Segment.
+
+   C12.22 Message
+
+      An ACSE APDU that is fully assembled, or a segment of a C12.22
+      Request Message, or a segment of a C12.22 Response Message.  The
+      C12.22 Message described in this specification MUST be encoded
+      using [7].
+
+   C12.22 Request Message
+
+      A fully assembled C12.22 APDU that contains an ACSE user-
+      information element, which includes one or more EPSEM Service
+      Requests.
+
+   C12.22 Response Message
+
+      A fully assembled C12.22 APDU that contains an ACSE user-
+      information element, which includes one or more EPSEM service
+      responses.
+
+   Connection
+
+      A logical and physical binding between two or more users of a
+      service [1].
+
+   EPSEM
+
+      Extended Protocol Specification for Electronic Metering.  EPSEM
+      defines structures and services used to encode multiple requests
+      and responses for use by devices such as gas, water, electricity,
+      and related electronic modules or appliances.
+
+   Initiating C12.22 IP Node
+
+      A role of a C12.22 IP Node in which it initiates the transmission
+      of a C12.22 Request Message.
+
+
+
+Moise & Brodkin               Informational                     [Page 5]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   Native Address
+
+      The term "Native Address" refers to the transport address that may
+      be used to reach a C12.22 Node on its C12.22 Network Segment [1].
+      In this specification, the Native Address refers to the Native IP
+      Address.
+
+   Passive-OPEN UDP
+
+      Passive-OPEN UDP is a state used by a local C12.22 IP Node to
+      expect and receive incoming C12.22 Messages from any foreign
+      C12.22 IP Node using UDP.  When the Passive-OPEN UDP state is
+      active, the local C12.22 IP Node accepts all C12.22 Messages that
+      arrive at the local port number that was registered by the local
+      C12.22 IP Node.
+
+   Passive-OPEN TCP
+
+      Passive-OPEN TCP is a state used by a local C12.22 IP Node that
+      wants to establish a TCP connection with an unspecified foreign
+      C12.22 IP Node using TCP.  In this case, any foreign C12.22 IP
+      Node MAY connect to the local C12.22 IP Node as long as the local
+      port matches the port used by the foreign C12.22 IP Node.  The
+      Passive-OPEN TCP state is identical to "local passive OPEN"
+      defined in [9].
+
+   Responding C12.22 IP Node
+
+      A role of a C12.22 IP Node in which it responds to the reception
+      of a C12.22 Request Message.
+
+   Target C12.22 IP Node
+
+      The C12.22 IP Node that is the destination for a C12.22 Message.
+
+4.  The C12.22 IP Network Segment
+
+   This section defines the characteristics of the C12.22 IP Network
+   Segment.
+
+4.1.  Composition of a C12.22 IP Network Segment
+
+   A C12.22 Network Segment is a collection of C12.22 Nodes that can
+   communicate with each other directly -- without having to forward
+   C12.22 Messages through a C12.22 Relay.
+
+   A C12.22 IP Network Segment comprises C12.22 IP Nodes and the network
+   infrastructure that enables any one node to reach all other nodes on
+
+
+
+Moise & Brodkin               Informational                     [Page 6]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   the same segment.  All C12.22 IP Nodes on the C12.22 IP Network
+   Segment employ the same IP address encoding scheme (per Figures 1
+   and 2) and the same network and transport protocols in accordance
+   with this specification.
+
+   There is no restriction on the size of a C12.22 IP Network Segment.
+   It MAY be as small as a single LAN or subnet, or it MAY include
+   numerous, heterogeneous LANs and WANs connected by routers, bridges,
+   and switches.  The C12.22 IP Network Segment MAY be completely
+   private, or include communication across the global Internet.
+
+4.2.  Native IP Address
+
+   The term "Native IP Address" denotes a Native Address that MAY be
+   used to reach a C12.22 Node on its C12.22 IP Network Segment.  The
+   Native IP Address includes the binary IP address, and an OPTIONAL
+   port number that MAY be followed by an OPTIONAL protocol identifier.
+   The Native IP Address SHALL be encoded as described below in
+   Section 4.3, "Encoding of Native IP Addresses".
+
+   The IP address of the C12.22 IP Node MUST be configured before the
+   C12.22 IP Node attempts to send or receive any C12.22 Message on its
+   C12.22 IP Network Segment.  If the port number is not explicitly
+   configured by the controlling application, it SHALL be set to the
+   default port number, 1153 (see Section 4.4, "Standardized Port
+   Numbers", below).
+
+   It is beyond the scope of this specification to define the method of
+   configuration, the configuration parameters, or any administrative
+   controls that the system administrator may wish to implement to
+   assign an IP address.
+
+4.3.  Encoding of Native IP Addresses
+
+   ANSI C12.22 defines binary fields for encoding a C12.22 Native
+   Address for transport within C12.22 Messages and for storage in
+   C12.19 Device Tables.  In this RFC, the fields SHALL contain an IPv4
+   or an IPv6 binary native IP address that is followed by an OPTIONAL
+   two-byte TCP or UDP port number.  The TCP or UDP port number, when
+   present, MAY be followed by an OPTIONAL one-byte transport protocol
+   identifier ("Protocol" for IPv4 or "Next Header" for IPv6).  The
+   transport protocol identifier SHALL be set to 17 (0x11) for UDP
+   transport, or to 6 (0x06) for TCP transport, or not set (absent) for
+   both UDP and TCP transports.  The transport protocol values SHALL be
+   consistent with the C12.22 Node's registered attributes (see
+   Connectionless (CL) and Connection-Oriented (CO) flags in
+   Section 5.1, "C12.22 Connection Types and TCP/UDP Transport Modes",
+   below).
+
+
+
+Moise & Brodkin               Informational                     [Page 7]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   ANSI C12.22 allows the Native Address fields to be conveyed in select
+   ANSI C12.22 EPSEM service elements (e.g., ANSI C12.22 Registration
+   Service <native-address>, ANSI C12.22 Resolve Service response
+   <local-address>, and ANSI C12.19 INTERFACE_CTRL_TBL Element
+   NATIVE_ADDRESS).  The length of the C12.22 Native Address is
+   qualified by an ANSI C12.22 address length field (e.g., ANSI C12.22
+   Registration Service <address-length>, ANSI C12.22 Resolve Service
+   response <local-address-length>, and ANSI C12.19 ACT_NETWORK_TBL
+   Element NATIVE_ADDRESS_LEN).
+
+   The ANSI C12.22 Registration Service permits only one Native Address
+   to be recorded with each registered ApTitle.  For this reason, a
+   C12.22 IP Node that wishes to register different port numbers for UDP
+   and TCP MUST register twice using different ApTitles.
+
+   The binary Native IP Address fields SHALL be encoded in network byte
+   order, as shown in Figure 1.
+
+                             IP Address (ADDR), Port (P), Transport (T)
+                  Address
+                   Length                        Octet
+                               0                   1
+                               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       IPv4          4        | ADDR4 |
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       IPv4+Port     6        | ADDR4 | P |
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       IPv4+Port     7        | ADDR4 | P |T|
+       +Transport             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       IPv6         16        |             ADDR6             |
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       IPv6+Port    18        |             ADDR6             | P |
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       IPv6+Port    19        |             ADDR6             | P |T|
+       +Transport             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       Figure 1: Encoding of the Native IP Addresses for ANSI C12.22
+
+
+
+Moise & Brodkin               Informational                     [Page 8]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   When an ANSI C12.22 Native Address is encoded in the ANSI C12.19
+   Tables' BINARY data Elements, the size of the Native Address Element
+   is defined by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN (see Table 121 of
+   [1], and [2]).  This is the actual number of octets that are placed
+   inside the C12.19 BINARY Element.  This value is common to all of the
+   C12.22 Node's interfaces, including those that are not IP based (thus
+   not conforming to this specification).  For this reason, the
+   ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN MAY be greater than, and SHALL NOT
+   be smaller than, the actual length needed to encode a Native IP
+   Address per Figure 1.  When this is the case, the C12.22 Native IP
+   Address SHALL be padded with zero (0) to fill the Table's BINARY data
+   Element.
+
+   In instances where the Native IP Address length does not exactly
+   match any of the Address Lengths listed in Figure 1, the actual
+   Address Length SHALL be determined by stripping all trailing binary
+   zeros (0x00) and then adjusting the Address Length upwards to the
+   next largest value shown in Figure 1.
+
+4.4.  Standardized Port Numbers
+
+   IANA (Internet Assigned Numbers Authority) has assigned port 1153 for
+   UDP [8] and TCP [9] C12.22 IP Messages.
+
+   By default, C12.22 IP Nodes SHALL send all C12.22 Application
+   association initiation message requests with 1153 set as the
+   destination port number.
+
+   To ensure interoperability among C12.22 IP Nodes, all C12.22 IP
+   Relays and Master Relays SHALL monitor and accept UDP and TCP
+   messages destined to port 1153.
+
+   Any IP firewalls or Access Control Lists (ACLs) shielding C12.22
+   Nodes and the IP network MUST be configured to forward UDP and TCP
+   traffic destined to port 1153 and other ports that are assigned and
+   registered by the network administrator, in order to maintain the
+   continuity of the C12.22 IP Network Segment.
+
+4.5.  Use of UDP Source Port 0
+
+   Although RFC 768 [8] allows for a source port number of zero (0),
+   C12.22 IP Nodes SHALL NOT send datagrams on UDP with the source port
+   set to zero.  A C12.22 IP Node SHALL ignore and SHALL NOT respond to
+   any C12.22 Message that it receives from source port 0.
+
+   Further details of the C12.22 IP Node's use of UDP, and of TCP, are
+   given in Section 5, "IP Message Transport", below.
+
+
+
+
+Moise & Brodkin               Informational                     [Page 9]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+4.6.  IP Multicast
+
+   In addition to unicast, the ANSI C12.22 protocol requires the support
+   of a multicast message delivery service from the network.  In cases
+   where C12.22 IP Nodes MUST perform Native IP Address discovery (e.g.,
+   the discovery of the Native IP Address of C12.22 IP Relays that
+   provide a route out of the C12.22 IP Network Segment, or the
+   discovery of the Native IP Address of a C12.22 IP Master Relay on the
+   C12.22 IP Network), the C12.22 IP Nodes use IP multicast to send a
+   C12.22 Message that contains an EPSEM Resolve Service Request on the
+   IP LAN.
+
+   IP multicast is also desirable, for example, when a C12.22 Host needs
+   to read a multitude of C12.22 Nodes (e.g., meters) that are
+   configured with a common C12.22 multicast group ApTitle.  Using IP
+   multicast, the C12.22 Host MAY send a C12.22 Message containing an
+   EPSEM Read Service Request that reaches all C12.22 Nodes on the
+   C12.22 IP Network Segment.
+
+   For these reasons, all C12.22 IP Relays and Master Relays SHALL
+   support IP multicast, and it is RECOMMENDED that all C12.22 Nodes
+   support IP multicast.  Any IPv4 C12.22 IP Node that supports IP
+   multicast SHALL use the Internet Group Management Protocol version 1
+   (IGMPv1) [10] as a minimum, to report (i.e., request) membership in
+   the C12.22 multicast group to its local router(s).  It is RECOMMENDED
+   that C12.22 IP Nodes implement IGMPv3 [11].
+
+   Any IPv6 C12.22 IP Node that supports IP multicast SHALL use
+   Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [12]),
+   possibly within ICMPv6 (RFC 4443 [13]), to report membership.
+
+   Routers that interconnect C12.22 IP Nodes on the C12.22 IP Network
+   Segment MUST support Protocol Independent Multicast - Sparse Mode
+   (PIM-SM) (RFC 4601 [14]) along with IGMPv1 (RFC 1112 [10]) as a
+   minimum for IPv4, or MLDv2 for IPv6 (RFC 3810 [12]).  It is
+   RECOMMENDED that they implement IGMPv3 [11].  It is beyond the scope
+   of this specification to define the mechanism for selecting an
+   initial Rendezvous Point (RP) for the C12.22 multicast group, the use
+   of shared versus source trees, or the mechanism for inter-domain
+   multicast routing.
+
+   IANA has registered the "All C1222 Nodes" multicast group, and has
+   assigned the IPv4 multicast address of 224.0.2.4 and the IPv6
+   multicast address of FF0X::204, where X represents the Scope field as
+   defined in RFC 4291, "IP Version 6 Addressing Architecture" [15].
+
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 10]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   For IPv6, all C12.22 IP Relays, C12.22 IP Master Relays, and all
+   C12.22 IP Nodes configured to support broadcast and multicast (see
+   Section 5.3, "Using IP Broadcast/Multicast", below) SHALL join the
+   global-scope multicast address, FF0E::204, as well as all of the
+   assigned, reduced-scope, multicast addresses:
+
+                    link-local         -- FF02::204;
+                    admin-local        -- FF04::204;
+                    site-local         -- FF05::204; and
+                    organization-local -- FF08::204.
+
+   IPv6 C12.22 IP Nodes SHOULD use the minimum scope needed, when
+   initiating IP multicast messages to reach another C12.22 IP Node on
+   the C12.22 Network.  This practice allows the sender to limit
+   unnecessary propagation of C12.22 IP Multicast Messages.
+
+   To determine the minimum scope required to reach the closest C12.22
+   IP Relay on the C12.22 Node's IP Network Segment, this specification
+   RECOMMENDS the following simple steps:
+
+   1.  Starting with the smallest (local-most) scope (i.e., link-local
+       scope or another pre-configured scope), send the C12.22 EPSEM
+       Resolve Service Request for the purpose of C12.22 IP Relay
+       discovery.
+
+   2.  Listen for a response from a C12.22 IP Relay; then:
+
+       A.  If no response is received, assign the next wider scope
+           level, then repeat steps (1) and (2) at the newly assigned
+           scope.
+
+       B.  If a response is received, then record the scope level as the
+           minimum scope to use on the node's C12.22 IP Network Segment.
+
+   A C12.22 IPv6 Node that initiates any EPSEM Service Request SHOULD
+   use the minimum scope necessary to reach its Target C12.22 IP Nodes.
+   A C12.22 IPv6 Relay SHALL use the global scope for any C12.22 Message
+   destined for the global Internet.
+
+   This specification does not preclude the use of the unassigned scope
+   values defined in [15]; those scope values MAY be used on a private
+   basis, or through mutual operating agreements.
+
+   For IPv4, all C12.22 IP Relays, C12.22 IP Master Relays, and all
+   C12.22 IP Nodes configured to support broadcast/multicast SHALL join
+   the assigned multicast address of 224.0.2.4.  This global address
+   does not provide for the type of scoping discussed above for IPv6,
+   nor is it compatible with the administratively scoped IP multicast
+
+
+
+Moise & Brodkin               Informational                    [Page 11]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   specification in RFC 2365 [16].  Therefore, a different technique to
+   limit the propagation of C12.22 IP Multicast Messages is needed.  One
+   available technique to control IPv4 multicast scope is through the
+   use of the Time-to-Live (TTL) attribute in the IP packet header.
+   This attribute is not managed by the C12.22 protocol.
+
+   In the implementation of this technique, an administrative domain
+   MUST include at least one C12.22 IP Relay, and all C12.22 IP Nodes in
+   the administrative domain SHOULD be configured with a TTL
+   sufficiently large to reach that C12.22 IP Relay.
+
+   A C12.22 IPv4 Node that initiates any C12.22 Request Message SHOULD
+   use the minimum TTL needed to reach its Target C12.22 IP Nodes.
+
+4.7.  IP Broadcast
+
+   IP broadcast is not generally suitable as a replacement for, or an
+   alternative to, multicast in a C12.22 IP Network Segment.  IP
+   broadcast is not supported in IPv6, and it suffers from limited scope
+   in IPv4.  This specification, however, does not preclude the use of
+   IP network directed or limited/local scope (address 255.255.255.255)
+   broadcast within a controlled management domain (as per RFC 2644
+   [17]).
+
+4.8.  Encoding of Multicast and Broadcast Addresses
+
+   ANSI C12.22 Tables provide BINARY Elements for encoding a broadcast
+   or multicast Native IP Address for transport within a C12.22 Message.
+   The encoding of these Table Elements is identical to that defined in
+   Section 4.3, "Encoding of Native IP Addresses".  These fields SHALL
+   be used as shown in Figure 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 12]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+                             IP Address (ADDR), Port (P), Transport (T)
+                   Address
+                    Length                       Octet
+                               0                   1
+                               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
+       IPv4                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       Broadcast      4       |BADDR4 |
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       IPv4                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       Broadcast      6       |BADDR4 | P |
+       +Port                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       IPv4                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       Broadcast      7       |BADDR4 | P |T|
+       +Port+Transport        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       IPv4                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       Multicast      4       |MADDR4 |
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       IPv4                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       Multicast      6       |MADDR4 | P |
+       +Port                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       IPv4                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       Multicast      7       |MADDR4 | P |T|
+       +Port+Transport        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       IPv6                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       Multicast     16       |            MADDR6             |
+                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       IPv6                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       Multicast     18       |            MADDR6             | P |
+       +Port                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       IPv6                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       Multicast     19       |            MADDR6             | P |T|
+       +Port+Transport        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       Figure 2: Encoding of Broadcast/Multicast Native IP Addresses
+
+   The IPv4 and IPv6 multicast addresses -- MADDR4 and MADDR6,
+   respectively -- are those assigned by IANA for use by ANSI C12.22.
+
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 13]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   When a broadcast/multicast Native IP Address is encoded in the ANSI
+   C12.19 Tables' BINARY data Elements, the size of the Native Address
+   Element transmitted is defined by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN
+   (see Table 121 of [1], and [2]).  This is the actual number of octets
+   that are placed inside the C12.19 BINARY Element.  This value is
+   common to all of the C12.22 Node's interfaces, including those that
+   are not IP based (thus not conforming to this specification).  For
+   this reason, the ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN MAY be greater
+   than, and SHALL NOT be smaller than, the actual length needed to
+   encode a broadcast/multicast Native IP Address per Figure 2.  When
+   this is the case, the C12.22 Native IP Address SHALL be padded with
+   zero (0) to fill the Table's BINARY data Element.
+
+   The IPv4 network directed broadcast address can be computed by
+   performing a bitwise OR between the bit complement of the subnet mask
+   of the target IP subnet and the IP address of any host on that IP
+   subnet.
+
+5.  IP Message Transport
+
+   This section defines a C12.22 Node's usage of the Connection-Oriented
+   (CO) and Connectionless (CL) transport layer protocols -- TCP and
+   UDP, respectively.
+
+5.1.  C12.22 Connection Types and TCP/UDP Transport Modes
+
+   A C12.22 IP Node's use of TCP and UDP is based on its registered
+   capabilities as defined in its configuration parameters (flags) and
+   as expressed in the Node's accepted registration attributes [1]:
+
+         CL Flag = <connection-type>.CONNECTIONLESS_MODE_SUPPORTED;
+         CL Accept Flag = <connection-type>.ACCEPT_CONNECTIONLESS;
+         CO Flag = <connection-type>.CONNECTION_MODE_SUPPORTED; and
+         CO Accept Flag = <connection-type>.ACCEPT_CONNECTIONS.
+
+   The mapping of the connection-type parameters to the IP-based
+   transport variants that a C12.22 Node MAY support is defined in
+   Table 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 14]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   +------+------+----------+----------+-------------------------------+
+   |  CL  |  CO  |    CL    |    CO    | IP Transport Mode Supported   |
+   | Flag | Flag |  Accept  |  Accept  |                               |
+   |      |      |   Flag   |   Flag   |                               |
+   +------+------+----------+----------+-------------------------------+
+   |   0  |   0  |     x    |     x    | Invalid                       |
+   |   0  |   1  |     0    |     0    | TCP, Active-OPEN              |
+   |   0  |   1  |     0    |     1    | TCP, Passive- and Active-OPEN |
+   |   0  |   1  |     1    |     0    | Invalid                       |
+   |   0  |   1  |     1    |     1    | Invalid                       |
+   |   1  |   0  |     0    |     0    | UDP, Active-OPEN              |
+   |   1  |   0  |     0    |     1    | Invalid                       |
+   |   1  |   0  |     1    |     0    | UDP, Passive- and Active-OPEN |
+   |   1  |   0  |     1    |     1    | Invalid                       |
+   |   1  |   1  |     0    |     0    | UDP, Active-OPEN; TCP         |
+   |      |      |          |          | Active-OPEN                   |
+   |   1  |   1  |     0    |     1    | UDP, Active-OPEN; TCP,        |
+   |      |      |          |          | Passive- and Active-OPEN      |
+   |   1  |   1  |     1    |     0    | UDP, Passive- and             |
+   |      |      |          |          | Active-OPEN; TCP, Active-OPEN |
+   |   1  |   1  |     1    |     1    | UDP, Passive- and             |
+   |      |      |          |          | Active-OPEN; TCP, Passive-    |
+   |      |      |          |          | and Active-OPEN               |
+   +------+------+----------+----------+-------------------------------+
+
+          Table 1: C12.22 Node Parameters to IP Transport Mapping
+
+   Every C12.22 IP Node MUST support at least one of the unicast CO or
+   CL operating capabilities (as advertised in Decade 12, "Node Network
+   Control Tables" [1], where available, and as registered using the
+   C12.22 Registration Service [1]).
+
+5.2.  IP Message Transport Details
+
+5.2.1.  TCP and UDP Port Use
+
+   General rules:
+
+   1.  A C12.22 IP Node that implements [CL Accept=1] SHALL receive
+       incoming UDP C12.22 Messages on its registered Native IP Address
+       (IP address and port number).
+
+   2.  A C12.22 IP Node that implements [CO Accept=1] SHALL receive
+       incoming TCP connections on its registered Native IP Address (IP
+       address and port number).
+
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 15]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   3.  A C12.22 IP Relay that forwards a UDP C12.22 Message to a C12.22
+       IP Node on the C12.22 IP Network Segment SHALL send the C12.22
+       Message to the C12.22 IP Node's registered Native IP Address (IP
+       address and port number).
+
+   4.  A C12.22 IP Relay that forwards a TCP C12.22 Message to a C12.22
+       IP Node on the C12.22 IP Network Segment MAY use an established
+       TCP connection to that C12.22 IP Node, or it SHALL establish a
+       new TCP connection to the C12.22 IP Node's registered Native IP
+       Address (IP address and port number).
+
+   5.  A C12.22 IP Node that implements [CL=1] SHOULD set the source
+       port number in outbound UDP C12.22 Messages to its registered
+       port number.  When the target UDP C12.22 IP Node is reachable
+       using direct messaging (as defined in [1]), the C12.22 IP Node
+       MAY set the source port number to a UDP port number that is
+       different than its registered port number.
+
+   6.  When the registered Native IP Address of a C12.22 IP Node does
+       not include the OPTIONAL port number, then port 1153 SHALL be
+       assumed and used as the registered port number.
+
+   7.  All C12.22 IP Nodes SHOULD use port 1153 in their Native IP
+       Address when registering.
+
+5.2.2.  Active-OPEN UDP Mode (CL=1, CL Accept=0)
+
+   A C12.22 IP Node that supports this mode SHALL NOT monitor for
+   unsolicited incoming C12.22 Messages via UDP.  As a result, the
+   C12.22 IP Node is incapable of receiving unsolicited C12.22 Messages
+   using UDP.
+
+   The C12.22 IP Node MAY enter the Active-OPEN UDP state by initiating
+   an unsolicited UDP transmission to a Target C12.22 IP Node, which is
+   expected to implement the Passive-OPEN UDP mode.
+
+   C12.22 IP Nodes SHOULD use their registered UDP port number, or if
+   not yet registered, then they SHOULD use port 1153 as the source port
+   number for all UDP C12.22 IP Messages.
+
+
+
+
+
+
+
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 16]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+5.2.3.  Passive-OPEN UDP Mode (CL=1, CL Accept=1)
+
+   A C12.22 IP Node that operates in this mode SHALL be capable of
+   receiving solicited and unsolicited C12.22 Messages from other C12.22
+   IP Nodes.  The C12.22 Node MAY change the port number that it
+   monitors by using the <native-address> parameter of the ANSI C12.22
+   Registration Service.  The C12.22 IP Node MAY initiate unsolicited
+   Active-OPEN UDP transmissions to other C12.22 IP Nodes that implement
+   the Passive-OPEN UDP mode.
+
+   When operating in this mode, the C12.22 IP Nodes SHALL use their
+   registered UDP port number as the source port number for all UDP
+   C12.22 IP Messages.
+
+   All C12.22 IP Relays SHALL support the Passive-OPEN UDP mode.  C12.22
+   Authentication Hosts and C12.22 Notification Hosts that implement UDP
+   SHALL support the Passive-OPEN UDP mode.  For all other C12.22 IP
+   Nodes, the Passive-OPEN UDP mode is the RECOMMENDED mode when
+   implementing UDP.
+
+5.2.4.  Active-OPEN TCP Mode (CO=1, CO Accept=0)
+
+   A C12.22 IP Node that supports this mode SHALL NOT monitor for
+   inbound TCP connections.  As a result, the node is incapable of
+   accepting incoming connections via TCP.  The C12.22 IP Node MAY
+   initiate TCP connections to Target C12.22 IP Nodes, which are
+   expected to implement the Passive-OPEN TCP mode.
+
+   In this mode, C12.22 Messages exchanged by a pair of associated
+   C12.22 IP Nodes can only be communicated through any of the TCP
+   connections that were initiated by the C12.22 IP Node that implements
+   this mode.  The loss or closure of a connection SHALL NOT
+   automatically result in the termination of the C12.22 associations
+   between the peer nodes.  In order to continue exchanging C12.22
+   Messages without loss of association, the initiating C12.22 IP Node
+   MAY re-establish new TCP connections with the peer node, or use
+   existing connections to the peer node.  The termination of the C12.22
+   Application associations is dependent upon C12.22 Application timeout
+   attributes and C12.22 link management services (such as Procedure 25,
+   "Network Interface Control" [1]).
+
+
+
+
+
+
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 17]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+5.2.5.  Passive-OPEN TCP Mode (CO=1, CO Accept=1)
+
+   A C12.22 IP Node that operates in this mode SHALL monitor and accept
+   incoming TCP connections.  The C12.22 Node MAY change the port number
+   that it monitors by using the <native-address> parameter of the ANSI
+   C12.22 Registration Service.  The C12.22 IP Node MAY initiate Active-
+   OPEN TCP connections to other C12.22 IP Nodes that implement the
+   Passive-OPEN TCP mode.
+
+   In this mode, C12.22 Messages exchanged by a pair of associated
+   C12.22 IP Nodes can arrive through any of the TCP connections that
+   were established by either node.  The loss or closure of a connection
+   SHALL NOT automatically result in the termination of the C12.22
+   associations between the peer nodes.  In order to continue exchanging
+   C12.22 Messages without loss of association, either C12.22 IP Node
+   MAY re-establish new TCP connections with the peer node, or use
+   existing connections to the peer node.  The termination of the C12.22
+   Application associations is dependent upon C12.22 Application timeout
+   attributes and C12.22 link management services (such as Procedure 25,
+   "Network Interface Control" [1]).
+
+   All C12.22 IP Relays SHALL support the Passive-OPEN TCP mode.  C12.22
+   Authentication Hosts and C12.22 Notification Hosts that implement TCP
+   SHALL support Passive-OPEN TCP mode.  For all other C12.22 IP Nodes,
+   Passive-OPEN TCP mode is the RECOMMENDED mode when implementing TCP.
+
+5.2.6.  TCP and C12.22 Message Directionality
+
+   C12.22 IP Nodes MAY use TCP in one of two ways: bi-directional
+   traffic flow or uni-directional traffic flow.
+
+   When TCP connections are used, any new or established TCP connection
+   between the two C12.22 IP Nodes MAY be used equivalently by the
+   C12.22 IP Nodes to send and to receive C12.22 Messages.  This is the
+   RECOMMENDED and default mode of operation because ANSI C12.22
+   requires the transport network to be reliable and connectionless (per
+   connectionless-mode ACSE).  For this reason, ANSI C12.22 defines
+   peer-to-peer application associations and not peer-to-peer
+   connections.
+
+   It is known that some C12.22 implementations have been deployed in
+   which TCP is used for uni-directional traffic flow.  For these types
+   of implementations, an established TCP connection SHALL be used by
+   the initiator of that connection to send C12.22 Messages and by the
+
+
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 18]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   target node (that accepted the connection) to receive C12.22
+   Messages.  If a C12.22 IP Node wishes to send a C12.22 Message to a
+   peer C12.22 IP Node, it MUST establish and use a new TCP connection,
+   or use an existing TCP connection that it had previously initiated,
+   for its outbound uni-directional traffic flow.
+
+   For increased interoperability, the initiator of the connection
+   SHOULD accept incoming C12.22 Messages on that connection in case the
+   target node attempts to use the connection for bi-directional traffic
+   flow.
+
+   Uni-directional use of TCP is a special mode of operation; it is NOT
+   RECOMMENDED because multiple one-way channel communication is not
+   described by ANSI C12.22, and it utilizes one-half of the TCP
+   connection capability.  As a result, it doubles the number of TCP
+   connections used to communicate C12.22 Messages and thus could become
+   a burden when a large number of connections are required.
+
+5.3.  Using IP Broadcast/Multicast
+
+   A C12.22 IP Node's use of broadcast/multicast is based on its
+   capabilities as defined in its configuration parameters (flags) and
+   as expressed in the Node's accepted registration attributes [1]
+   (<connection-type>.BROADCAST_AND_MULTICAST_SUPPORTED).  The mapping
+   of the C12.22 IP Node's Broadcast/Multicast parameter (flag) to IP
+   broadcast/multicast usage is defined in Table 2.
+
+    C12.22 Broadcast and  IP Broadcast/Multicast Supported
+     Multicast Supported
+            Flag
+   ---------------------- ----------------------------------------------
+              0           The C12.22 IP Node does not accept IP
+                          broadcast, and it does not accept IP multicast
+                          messages.
+              1           The C12.22 IP Node accepts both IP broadcast
+                          (IPv4 only) and IP multicast messages (IPv4
+                          and IPv6).
+
+             Table 2: C12.22 to IP Broadcast/Multicast Mapping
+
+   If a C12.22 IP Node is configured to accept IP broadcast and
+   multicast messages, it SHALL join the "All C1222 Nodes" multicast
+   group (see Section 4.6, "IP Multicast", above), and SHALL use the
+   default port 1153.  In addition, it SHALL accept IP network directed
+   or limited (local scope) broadcast messages sent to port 1153.  Note
+   that successful communication using network directed broadcast
+   requires configuration of network routers, which by default SHALL NOT
+   forward directed broadcasts as per RFC 2644 [17].
+
+
+
+Moise & Brodkin               Informational                    [Page 19]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+5.4.  Transport Protocol Decisions
+
+5.4.1.  Unicast Versus Multicast Versus Broadcast
+
+   An initiating C12.22 IP Node MAY send any C12.22 Message using UDP or
+   TCP.  However, in accordance with Section 5.3.2.4.12, "Resolve
+   Service", of ANSI C12.22, it is RECOMMENDED that the C12.22 Resolve
+   Request Message be transported using UDP/IP multicast when the Native
+   IP Address of the Target C12.22 Node is not known.  The use of UDP/IP
+   multicast is preferred over the use of IP network directed or limited
+   broadcast; therefore, when UDP/IP multicast is supported, its use is
+   RECOMMENDED over network broadcast.
+
+5.4.2.  Sending Large C12.22 APDUs Using UDP
+
+   When sending via UDP a large C12.22 Message that exceeds the path
+   MTU, the sender SHALL segment the ACSE APDU in accordance with the
+   ANSI C12.22 Datagram Segmentation and Reassembly algorithm, such that
+   the size of the resulting IP datagram does not exceed the path MTU
+   and thus avoids UDP packet fragmentation.  The fundamental issue with
+   fragmentation exists for both IPv4 and IPv6.  Section 3.2 of RFC 5405
+   [18] provides additional guidelines for determining the appropriate
+   UDP message size.  When the path MTU is not known, the sender SHALL
+   follow the guidelines stipulated in Section 3.2 of RFC 5405 [18]: for
+   IPv4, use the smaller of 576 bytes and the first-hop MTU [19], and
+   for IPv6, use 1280 bytes [20].  Sending large APDUs via UDP may lead
+   to network congestion.  For more information on avoiding network
+   congestion see Section 5.6, "Congestion Control".
+
+5.4.3.   Choice of Protocol for C12.22 Response APDUs
+
+   When a Target C12.22 IP Node receives a C12.22 Request Message from
+   an initiating C12.22 IP Node, it SHALL send a C12.22 Response Message
+   using the same transport protocol (i.e., TCP to TCP, UDP to UDP).
+
+   In the case of UDP, the target SHALL send the C12.22 Response Message
+   to the source IP address and port number.
+
+5.5.  Quality of Service
+
+   The ANSI C12.22 standard provides a configuration parameter in the
+   APDU's <calling-AE-qualifier>.URGENT attribute to mark a message as
+   urgent.  There are numerous IP-based technologies that enable
+   enhanced levels of message delivery and quality of service.  This
+   specification does not define the technology to be used to send
+   urgent messages over IP.
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 20]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+5.6.  Congestion Control
+
+   Designers of unicast applications that implement the upper layers of
+   C12.22 messaging over UDP SHOULD follow the congestion control
+   guidelines in Section 3.1 of RFC 5405 [18].
+
+   For the transmission of C12.22 Messages that are greater than what
+   the TCP initial window would be over a given Internet path, TCP
+   SHOULD be used rather than UDP as the transport protocol.  TCP's
+   initial window depends on the maximum segment size (MSS), which in
+   turn depends on the path MTU, and is computed according to formula
+   (1) in RFC 3390 [21].  For unknown path MTUs, the smallest allowable
+   MSS MUST be used, and the C12.22 Application SHOULD assume the
+   maximum C12.22 Message size to be 2048 bytes.  By using TCP, the
+   C12.22 Application benefits from the built-in TCP congestion control
+   mechanism.
+
+   When UDP is the preferred transport mechanism, or when UDP multicast
+   or broadcast are the preferred modes of communication, then the
+   C12.22 Application SHOULD use C12.22 acknowledged Messages that are
+   smaller than TCP's initial window over the return path, as computed
+   by formula (1) in [21] and described above.  The size of the C12.22
+   Message MAY be managed through the use of ANSI C12.22 EPSEM Partial
+   Table Read/Write Service Requests and Responses.
+
+6.  Security Considerations
+
+   The ANSI C12.22 Application Layer Security is defined in
+   Section 5.3.4.13, "C12.22 Security Mechanism", of the ANSI C12.22
+   standard.  The security mechanisms include provisions for message
+   privacy and authentication, playback rejection, and message
+   acceptance windows, as well as ANSI C12.19 [2] role-based data access
+   and secured register mechanisms.  The ANSI C12.22 Application Layer
+   default security mechanism provides three options to choose from when
+   sending C12.22 Messages:
+
+   1.  Sending cleartext messages over the C12.22 Network [1], [5],
+       which MAY result in altered C12.22 Messages and exposure to
+       password sniffing attacks, as described in RFC 3552 [22].
+
+   2.  Sending of authenticated plaintext messages over the C12.22
+       Network [1], [5], which MAY result in password sniffing attacks
+       as described in RFC 3552 [22].
+
+   3.  Sending of authenticated ciphertext over the C12.22 Network,
+       providing for message and peer node authentication and privacy.
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 21]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   When option 1 is used, then it is RECOMMENDED that the network or
+   transport layer provide authentication and confidentiality service.
+   When option 2 is used, then it is RECOMMENDED that the network or
+   transport layer provide confidentiality services.  When option 3 is
+   used, then no additional network or transport layer security services
+   are necessary.
+
+   Additional transport or network layer security protocols are not
+   required by ANSI C12.22, but they MAY be provided transparently by
+   C12.22 IP Network Segment integrators (e.g., in C12.22 IP Relays) in
+   order to improve on the security provisions cited above.  However,
+   any added transport security (e.g., Transport Layer Security (TLS),
+   RFC 5246 [27]) or IP security (e.g., IPsec, RFC 4302 [25], RFC 4303
+   [26], RFC 5996 [28]) features SHALL act only to enhance (i.e., not be
+   a substitute for, or an alteration of) the interoperable ANSI C12.22
+   and ANSI C12.19 security provisions, and SHALL NOT corrupt and SHALL
+   NOT alter the C12.22 Message as presented by the C12.22 Application
+   Layer.
+
+   The ANSI C12.22 [1] and ANSI C12.19 [2] standards provide for the
+   transmission of keys and their storage in C12.19 End Devices (e.g.,
+   meters and head-end systems).  The key management protocol (when and
+   how keys are exchanged) is not described in the ANSI C12.22 [1] and
+   ANSI C12.19 [2] standards, except to state that keys MAY not be
+   readable from a C12.19 End Device (in response to a Read Service
+   Request).  It is RECOMMENDED that all C12.22 Nodes encrypt user
+   information element key fields and passwords.  It is also RECOMMENDED
+   that all C12.22 Nodes mask user information element key fields and
+   password fields of EPSEM Read Service Responses (e.g., by replacing
+   all key and password bytes with zeros (0x00) or spaces (0x20)).
+
+   Legacy deployments exist that are not connected to the Internet, so
+   there are some implementations that do not include security.  It is
+   likely that multi-homed C12.22 Nodes with interfaces to the Internet
+   will exist in future deployments, so security mechanisms MUST be used
+   by those C12.22 Nodes to ensure C12.22 Message authentication and
+   confidentiality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 22]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+7.  IANA Considerations
+
+   UDP and TCP port 1153, which is used for C12.22 communication over
+   IP, is registered with IANA.
+
+   Section 4.6, "IP Multicast", defines the use of multicast.  The
+   following multicast addresses have been registered by IANA for use by
+   the ANSI C12.22 standard:
+
+      IPv4 -- "All C1222 Nodes" address 224.0.2.4
+
+      IPv6 -- "All C1222 Nodes" address FF0X::204
+
+8.  Acknowledgments
+
+   The authors wish to recognize Alexander Shulgin for providing
+   valuable comments and for conducting feasibility testing in support
+   of this work.
+
+   The following people have improved this document through thoughtful
+   comments and suggestions: Fred Baker, Ralph Droms, Vijay Gurbani,
+   Michael Stuber, Spencer Dawkins, Alfred Hoenes, Russ Housley, Paul
+   Hoffman, Lars Eggert, and Sean Turner.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]   ANSI, "Protocol Specification for Interfacing to Data
+         Communication Networks", ANSI C12.22-2008, January 2009.
+
+   [2]   ANSI, "Utility Industry End Device Data Tables", ANSI C12.19-
+         2008, February 2009.
+
+   [3]   IEEE, "Draft Standard for Utility Industry Metering
+         Communication Protocol Application Layer (End Device Data
+         Tables)", IEEE P1377-2010, October 2010.
+
+   [4]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [5]   IEEE, "Standard for Local Area Network/Wide Area Network (LAN/
+         WAN) Node Communication Protocol to Complement the Utility
+         Industry End Device Data Tables", IEEE P1703-2010,
+         October 2010.
+
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 23]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   [6]   ISO/IEC, "Information Technology-Open Systems Interconnection-
+         Connectionless Protocol for the Association Control Service
+         Element: Protocol Specification", ISO/IEC 10035-1, 1995.
+
+   [7]   ISO/IEC, "Information Technology-ASN.1 Encoding Rules:
+         Specification of Basic Encoding Rules (BER), Canonical Encoding
+         Rules (CER) and Distinguished Encoding Rules (DER)", ISO/
+         IEC 8825-1, 2002.
+
+   [8]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+         August 1980.
+
+   [9]   Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
+         September 1981.
+
+   [10]  Deering, S., "Host extensions for IP multicasting", STD 5,
+         RFC 1112, August 1989.
+
+   [11]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+         Thyagarajan, "Internet Group Management Protocol, Version 3",
+         RFC 3376, October 2002.
+
+   [12]  Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery
+         Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+   [13]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control
+         Message Protocol (ICMPv6) for the Internet Protocol Version 6
+         (IPv6) Specification", RFC 4443, March 2006.
+
+   [14]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+         "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+         Protocol Specification (Revised)", RFC 4601, August 2006.
+
+   [15]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+         Architecture", RFC 4291, February 2006.
+
+   [16]  Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
+         RFC 2365, July 1998.
+
+   [17]  Senie, D., "Changing the Default for Directed Broadcasts in
+         Routers", BCP 34, RFC 2644, August 1999.
+
+   [18]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for
+         Application Designers", BCP 145, RFC 5405, November 2008.
+
+   [19]  Braden, R., Ed., "Requirements for Internet Hosts -
+         Communication Layers", STD 3, RFC 1122, October 1989.
+
+
+
+
+Moise & Brodkin               Informational                    [Page 24]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+   [20]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+         Specification", RFC 2460, December 1998.
+
+   [21]  Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
+         Initial Window", RFC 3390, October 2002.
+
+   [22]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
+         Security Considerations", BCP 72, RFC 3552, July 2003.
+
+9.2.  Informative References
+
+   [23]  Measurement Canada, "Specification for Utility Industry
+         Metering Communication Protocol Application Layer (End Device
+         Data Tables)", Draft MC12.19, 2011.
+
+   [24]  Measurement Canada, "Specification for Local Area Network/Wide
+         Area Network (LAN/WAN) Node Communication Protocol to
+         Complement the Utility Industry End Device Data Tables",
+         Draft MC12.22, 2011.
+
+   [25]  Kent, S., "IP Authentication Header", RFC 4302, December 2005.
+
+   [26]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
+         December 2005.
+
+   [27]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+         Protocol Version 1.2", RFC 5246, August 2008.
+
+   [28]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key
+         Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 25]
+
+RFC 6142          ANSI C12.22/IEEE 1703/MC12.22 Over IP       March 2011
+
+
+Authors' Addresses
+
+   Avygdor Moise
+   Future DOS R&D Inc.
+   #303 - 6707 Elbow Drive SW
+   Calgary, Alberta  T2V 0E5
+   Canada
+
+   EMail: avy@fdos.ca
+   URI:   http://www.fdos.ca
+
+
+   Jonathan Brodkin
+   Future DOS R&D Inc.
+   #303 - 6707 Elbow Drive SW
+   Calgary, Alberta  T2V 0E5
+   Canada
+
+   EMail: jonathan.brodkin@fdos.ca
+   URI:   http://www.fdos.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moise & Brodkin               Informational                    [Page 26]
+