idnits 2.17.1 draft-c1222-transport-over-ip-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (January 10, 2011) is 4852 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (ref. '11') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5405 (ref. '20') (Obsoleted by RFC 8085) ** Obsolete normative reference: RFC 2460 (ref. '22') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. '27') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (ref. '28') (Obsoleted by RFC 7296) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Moise 3 Internet-Draft J. Brodkin 4 Intended status: Informational Future DOS R&D Inc. 5 Expires: July 14, 2011 January 10, 2011 7 ANSI C12.22, IEEE 1703 and MC12.22 Transport Over IP 8 draft-c1222-transport-over-ip-08 10 Abstract 12 This RFC provides a framework for transporting ANSI C12.22/IEEE 1703/ 13 MC12.22 Advanced Metering Infrastructure (AMI) Application-Layer 14 Messages on an IP network. 16 This document is not an official submission on behalf of the ANSI 17 C12.19 and C12.22 working groups. It was created by participants in 18 those groups building on knowledge of several proprietary C12.22 over 19 IP implementations. The content of this document is an expression of 20 a consensus aggregation of those implementations. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 14, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. The C12.22 IP Network Segment . . . . . . . . . . . . . . . . 7 60 4.1. Composition of a C12.22 IP Network Segment . . . . . . . . 7 61 4.2. Native IP Address . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Encoding of Native IP Addresses . . . . . . . . . . . . . 8 63 4.4. Standardized Port Numbers . . . . . . . . . . . . . . . . 10 64 4.5. Use of UDP Source Port 0 . . . . . . . . . . . . . . . . . 10 65 4.6. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.7. IP Broadcast . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.8. Encoding of Multicast and Broadcast Addresses . . . . . . 13 68 5. IP Message Transport . . . . . . . . . . . . . . . . . . . . . 15 69 5.1. C12.22 Connection Types and TCP/UDP Transport Modes . . . 15 70 5.2. IP Message Transport Details . . . . . . . . . . . . . . . 16 71 5.2.1. TCP and UDP Port Use . . . . . . . . . . . . . . . . . 16 72 5.2.2. Active-OPEN UDP (CL=1, CL Accept=0) . . . . . . . . . 17 73 5.2.3. Passive-OPEN UDP (CL=1, CL Accept=1) . . . . . . . . . 17 74 5.2.4. Active-OPEN TCP Mode (CO=1, CO Accept=0) . . . . . . . 18 75 5.2.5. Passive-OPEN TCP Mode (CO=1, CO Accept=1) . . . . . . 18 76 5.2.6. TCP and C12.22 Message Directionality . . . . . . . . 19 77 5.3. Using IP Broadcast/Multicast . . . . . . . . . . . . . . . 19 78 5.4. Transport Protocol Decisions . . . . . . . . . . . . . . . 20 79 5.4.1. Unicast Versus Multicast Versus Broadcast . . . . . . 20 80 5.4.2. Sending Large C12.22 APDUs Using UDP . . . . . . . . . 20 81 5.4.3. Choice of Protocol for C12.22 Response APDUs . . . . . 21 82 5.5. Quality of Service . . . . . . . . . . . . . . . . . . . . 21 83 5.6. Congestion Control . . . . . . . . . . . . . . . . . . . . 21 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 92 1. Introduction 94 The ANSI C12.22 standard [1] provides a set of application layer 95 messaging services that are applicable for the enterprise and End 96 Device components of an Advanced Metering Infrastructure (AMI) for 97 the Smart Grid. The messaging services are tailored for, but not 98 limited to, the exchange of the data Tables Elements defined and co- 99 published in ANSI C12.19 [2], IEEE P1377 [3], and MC12.19 [4]. These 100 standards were developed jointly by ANSI (ANSI C12.22 and ANSI 101 C12.19), by IEEE (IEEE 1377 and IEEE 1703) and Measurement Canada 102 (MC12.19 and MC12.22). 104 ANSI C12.22, which is an application-level messaging protocol, may be 105 transported over any underlying transport network. This RFC defines 106 the requirements governing the transmission of ANSI C12.22 Messages 107 via the TCP and UDP transports in IP networks (whereby the OSI 108 Session, Presentation, and Application Layers of ANSI C12.22 are 109 collapsed into a single Application Layer). 111 Specifically, this RFC applies to the operational details of Section 112 5, C12.22 Node to C12.22 Network Segment Details, of ANSI C12.22, and 113 covers the mapping, encoding, and interpreting of ANSI C12.19 Device 114 Network Table Elements and Native Addresses for use on IP networks. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [5]. 122 Throughout this document we use terms like ANSI C12.22 or ANSI 123 C12.19, as in C12.22 Relay or ANSI C12.19 Device. These terms are 124 interchangeable with the terms IEEE 1703 Relay and IEEE 1377 Device, 125 respectively. However, the recent versions of the Utility End Device 126 communication standards were developed under the auspices of ANSI C12 127 SC17 WG1 and ANSI C12 SC17 WG2. For that reason, the terminology 128 used in this document expands on the ANSI C12.22-2008 [1] and ANSI 129 C12.19-2008 [2] definitions as revised by IEEE 1703-2009 [6] and IEEE 130 1377-2010 [3]. 132 3. Definitions 134 This specification uses a number of terms to refer to the roles 135 played by participants (actors) in, and objects of, the ANSI C12.22 136 [1], IEEE 1703 [6], and MC12.22 [7] protocol. Terms prefixed by 137 C12.22 or C12.19, which are not defined here, can be resolved in [1], 139 [6], [7] or [2], [3], [4]. 141 ACSE 143 Association Control Service Element. In the context of this 144 specification and of [1], ACSEs are encoded per ISO/IEC 10035-1 145 [8] using the ASN.1 BER [9]. 147 Active-OPEN UDP 149 Active-OPEN UDP is a state used by a local C12.22 IP Node to 150 expect and receive incoming C12.22 Messages that it solicited from 151 a foreign C12.22 IP Node using the UDP. The local C12.22 IP Node 152 MAY exit the Active-OPEN UDP state when it has received all of the 153 expected C12.22 Messages or a C12.22 Message timeout has occurred. 154 The local C12.22 IP Node receives all C12.22 Response Messages 155 solicited from the foreign C12.22 IP Node that arrive at the local 156 port number that matches the source port number used to solicit 157 the C12.22 Messages from the foreign C12.22 IP Node. 159 Active-OPEN TCP 161 Active-OPEN TCP is a state used by a local C12.22 IP Node to 162 establish a TCP connection with a fully-specified foreign C12.22 163 IP Node using TCP and the foreign C12.22 IP Node's registered 164 Native IP Address. The Active-OPEN TCP state is identical to 165 "local active OPEN" defined in [11]. 167 APDU 169 Application Protocol Data Unit. In the context of the ANSI C12.22 170 Application, it is an ACSE C12.22 Message. 172 ACSE APDU 174 ACSE Application Protocol Data Unit; same as APDU. 176 ApTitle 178 An ANSI C12.22 Application-process Title. An ApTitle is a name 179 for a system-independent application activity that exposes 180 application services to the application agent; e.g., a set of 181 application service elements that together perform all or part of 182 the communication aspects of an application process. An ApTitle 183 is encoded as a unique registered (as per [1]) object identifier. 185 C12.22 IP Node 187 A C12.22 Node that is located on a C12.22 IP Network Segment and 188 communicates using the IP protocol. 190 C12.22 IP Network Segment 192 A collection of all C12.22 IP Nodes that implement the IP-based 193 protocols, as defined in this specification, and can communicate 194 with each other using IP routers, switches, and bridges and 195 without the use of a C12.22 Relay. 197 C12.22 IP Relay 199 A C12.22 IP Node that performs the functions of a C12.22 Relay. 200 A C12.22 IP Relay acts as a bridge between a C12.22 IP Network 201 Segment and an adjacent, C12.22 Network Segment. 203 C12.22 Message 205 An ACSE APDU that is also a fully assembled or a segment of a 206 C12.22 Request Message or a C12.22 Response Message. The C12.22 207 Message described in this specification MUST be encoded using [9]. 209 C12.22 Request Message 211 A fully assembled C12.22 APDU that contains an ACSE user- 212 information element, which includes one or more EPSEM service 213 requests. 215 C12.22 Response Message 217 A fully assembled C12.22 APDU that contains an ACSE user- 218 information element, which includes one or more EPSEM service 219 responses. 221 Connection 223 A logical and physical binding between two or more users of a 224 service [1]. 226 EPSEM 228 Extended Protocol Specification for Electronic Metering. EPSEM 229 defines structures and services used to encode multiple requests 230 and responses for use by devices such as gas, water, electricity, 231 and related electronic modules or appliances. 233 Initiating C12.22 IP Node 235 A role of a C12.22 IP Node in which it initiates the transmission 236 of a C12.22 Request Message. 238 Native Address 240 The term Native Address refers to the transport address that may 241 be used to reach a C12.22 Node on its C12.22 Network Segment [1]. 242 In this specification the Native Address refers to the Native IP 243 Address. 245 Passive-OPEN UDP 247 Passive-OPEN UDP is a state used by a local C12.22 IP Node to 248 expect and receive incoming C12.22 Messages from any foreign 249 C12.22 IP Node using the UDP. When the Passive-OPEN UDP state is 250 active, the local C12.22 IP Node accepts all C12.22 Messages that 251 arrive at the local port number that was registered by the local 252 C12.22 IP Node. 254 Passive-OPEN TCP 256 Passive-OPEN TCP is a state used by a local C12.22 IP Node that 257 wants to establish a TCP connection with an unspecified foreign 258 C12.22 IP Node using TCP. In this case any foreign C12.22 IP Node 259 MAY connect to the local C12.22 IP Node as long as the local port 260 matches the port used by the foreign C12.22 IP Node. The Passive- 261 OPEN TCP state is identical to "local passive OPEN" defined in 262 [11]. 264 Responding C12.22 IP Node 266 A role of a C12.22 IP Node in which it responds to the reception 267 of a C12.22 Request Message. 269 Target C12.22 IP Node 271 The C12.22 IP Node that is the destination for a C12.22 Message. 273 4. The C12.22 IP Network Segment 275 This section defines the characteristics of the C12.22 IP Network 276 Segment. 278 4.1. Composition of a C12.22 IP Network Segment 280 A C12.22 Network Segment is a collection of C12.22 Nodes that can 281 communicate with each other directly - without having to forward 282 C12.22 Messages through a C12.22 Relay. 284 A C12.22 IP Network Segment comprises C12.22 IP Nodes and the network 285 infrastructure that enables any one node to reach all other nodes on 286 the same segment. All C12.22 IP Nodes on the C12.22 IP Network 287 Segment employ the same IP address encoding scheme (per Figures 1 and 288 2) and the same network and transport protocols in accordance with 289 this specification. 291 There is no restriction on the size of a C12.22 IP Network Segment. 292 It MAY be as small as a single LAN or subnet, or it MAY include 293 numerous, heterogeneous LANs and WANs connected by routers, bridges, 294 and switches. The C12.22 IP Network Segment MAY be completely 295 private, or include communication across the global Internet. 297 4.2. Native IP Address 299 The term Native IP Address denotes a Native Address that MAY be used 300 to reach a C12.22 Node on its C12.22 IP Network Segment. The Native 301 IP Address includes the binary IP address, and an OPTIONAL port 302 number that MAY be followed by an OPTIONAL protocol identifier. The 303 Native IP Address SHALL be encoded as described in Section 4.3, 304 Encoding of Native IP Addresses. 306 The IP address of the C12.22 IP Node MUST be configured before the 307 C12.22 IP Node attempts to send or receive any C12.22 Message on its 308 C12.22 IP Network Segment. If the port number is not explicitly 309 configured by the controlling application, it SHALL be set to the 310 default port number, 1153 (see Section 4.4, Standardized Port 311 Numbers). 313 It is beyond the scope of this specification to define the method of 314 configuration, the configuration parameters, or any administrative 315 controls that the system administrator may wish to implement to 316 assign an IP address. 318 4.3. Encoding of Native IP Addresses 320 ANSI C12.22 defines binary fields for encoding a C12.22 Native 321 Address for transport within C12.22 Messages and for storage in 322 C12.19 Device Tables. In this RFC the fields SHALL contain an IPv4 323 or an IPv6 binary native IP network address that is followed by an 324 OPTIONAL two-byte TCP or UDP port number. The TCP or UDP port 325 number, when present, MAY be followed by an OPTIONAL one-byte 326 transport protocol identifier ("Protocol" of IPv4 or "Next Header" of 327 IPv6). The transport protocol identifier SHALL be set to 17 (0x11) 328 for UDP transport, or to 6 (0x06) for TCP transport, or not set 329 (absent) for both UDP+TCP transports. The transport protocol values 330 SHALL be consistent with the C12.22 Node's registered attributes (see 331 CL and CO flags in Section 5.1, C12.22 Connection Types and TCP/UDP 332 Transport Modes). 334 ANSI C12.22 allows the Native Address fields to be conveyed in select 335 ANSI C12.22 EPSEM service elements (e.g., ANSI C12.22 Registration 336 Service parameter, ANSI C12.22 Resolve Service 337 response , and ANSI C12.19 INTERFACE_CTRL_TBL Element 338 NATIVE_ADDRESS). The length of the C12.22 Native Address is 339 qualified by an ANSI C12.22 address length field (e.g., ANSI C12.22 340 Registration Service parameter, ANSI C12.22 Resolve 341 Service response , and ANSI C12.19 342 ACT_NETWORK_TBL Element NATIVE_ADDRESS_LEN). 344 The ANSI C12.22 Registration Service permits only one Native Address 345 to be recorded with each registered ApTitle. For this reason, a 346 C12.22 IP Node that wishes to register different port numbers for UDP 347 and TCP MUST register twice using different ApTitles. 349 The binary Native IP Address fields SHALL be encoded in network byte 350 order as shown in Figure 1. 352 Address IP Address (ADDR), Port (P), Transport (T) 353 Length Octet 354 0 1 355 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 IPv4 4 | ADDR4 | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 IPv4+Port 6 | ADDR4 | P | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 IPv4+Port 7 | ADDR4 | P |T| 366 +Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 IPv6 16 | ADDR6 | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 IPv6+Port 18 | ADDR6 | P | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 IPv6+Port 19 | ADDR6 | P |T| 378 +Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 1: Encoding of the Native IP Addresses for ANSI C12.22 382 When an ANSI C12.22 Native Address is encoded in ANSI C12.19 Tables' 383 BINARY data Elements then the size of the native address Element is 384 defined by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN (See [1] and [2] Table 385 121). This is the actual number of octets that are placed inside the 386 C12.19 BINARY Element. This value is common to all of the C12.22 387 Node's interfaces, including those that are not IP based (thus not 388 conforming to this specification). For this reason the 389 ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN MAY be greater than, and SHALL NOT 390 be smaller than, the actual length needed to encode a Native IP 391 Address per Figure 1. When this is the case, the C12.22 Native IP 392 Address SHALL be padded with zero (0) to fill the Table's BINARY data 393 Element. 395 In instances where the Native IP Address length does not exactly 396 match any of the Address Lengths listed in Figure 1, the actual 397 Address Length SHALL be determined by stripping all trailing binary 398 zeros (0x00) and then adjusting the Address Length upwards to the 399 next largest value shown in Figure 1. 401 4.4. Standardized Port Numbers 403 IANA (Internet Assigned Numbers Authority) has assigned port 1153 for 404 UDP [10] and TCP [11] C12.22 IP Messages. 406 By default, C12.22 IP Nodes SHALL send all C12.22 Application 407 Association initiation message requests set with 1153 as the 408 destination port number. 410 To ensure interoperability among C12.22 IP Nodes, all C12.22 IP 411 Relays and Master Relays SHALL monitor and accept UDP and TCP 412 messages destined to port 1153. 414 Any IP firewalls or Access Control Lists (ACLs) shielding C12.22 415 Nodes and the IP network MUST be configured to forward UDP and TCP 416 traffic destined to port 1153 and other ports that are assigned and 417 registered by the Network administrator, in order to maintain the 418 continuity of the C12.22 IP Network Segment. 420 4.5. Use of UDP Source Port 0 422 Although RFC 768 [10] allows for a source port number of zero (0), 423 C12.22 IP Nodes SHALL NOT send datagrams on UDP with the source port 424 set to zero. A C12.22 IP Node SHALL ignore and SHALL NOT respond to 425 any C12.22 Message that it receives from source port 0. 427 Further details of C12.22 IP Node's use of UDP, and of TCP, are given 428 in Section 5, IP Message Transport. 430 4.6. IP Multicast 432 In addition to unicast, the ANSI C12.22 protocol requires the support 433 of a multicast message delivery service from the network. In cases 434 where C12.22 IP Nodes MUST perform Native IP Address discovery (e.g., 435 the discovery of the Native IP Address of C12.22 IP Relays that 436 provide a route out of the C12.22 IP Network Segment, or the 437 discovery of the Native IP Address of a C12.22 IP Master Relay on the 438 C12.22 IP Network), the C12.22 IP Nodes use IP Multicast to send a 439 C12.22 Message that contains an EPSEM Resolve Service Request on the 440 IP LAN. 442 IP multicast is also desirable, for example, when a C12.22 Host needs 443 to read a multitude of C12.22 Nodes (e.g., meters) that are 444 configured with a common C12.22 multicast group ApTitle. Using IP 445 multicast, the C12.22 Host MAY send a C12.22 Message containing an 446 EPSEM Read Service Request that reaches all C12.22 Nodes on the 447 C12.22 IP Network Segment. 449 For these reasons, all C12.22 IP Relays and Master Relays SHALL 450 support IP multicast and it is RECOMMENDED that all C12.22 Nodes 451 support IP multicast. Any IPv4 C12.22 IP Node that supports IP 452 multicast SHALL use the Internet Group Management Protocol IGMP 453 version 1 (IGMPv1) [12] as a minimum, to report (i.e., request) 454 membership in the C12.22 multicast group to its local router(s). 455 It is RECOMMENDED that C12.22 IP Nodes implement IGMPv3 [13]. 457 Any IPv6 C12.22 IP Node that supports IP multicast SHALL use 458 Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [14]) 459 possibly within ICMPv6 (RFC 4443 [15]) to report membership. 461 Routers that interconnect C12.22 IP Nodes on the C12.22 IP Network 462 Segment MUST support Protocol Independent Multicast Sparse Mode (PIM 463 SM) (RFC 4601 [16]) along with IGMPv1 (RFC 1112 [12]) as a minimum 464 for IPv4, or MLDv2 for IPv6 (RFC 3810 [14]). It is RECOMMENDED that 465 they implement IGMPv3 [13]. It is beyond the scope of this 466 specification to define the mechanism for selecting an initial 467 Rendezvous Point (RP) for the C12.22 multicast group, the use of 468 shared versus source trees, or the mechanism for inter-domain 469 multicast routing. 471 IANA has registered the "All C1222 Nodes" multicast group, and has 472 assigned the IPv4 multicast address of 224.0.2.4 and the IPv6 473 multicast address of FF0X::204, where X represents the Scope field as 474 defined in RFC 4291, the IP Version 6 Addressing Architecture [17]. 476 For IPv6, all C12.22 IP Relays, C12.22 IP Master Relays, and all 477 C12.22 IP Nodes configured to support broadcast and multicast (see 478 Section 5.3, Using IP Broadcast/Multicast) SHALL join the global 479 scope multicast address, FF0E::204, as well as all of the assigned, 480 reduced-scope, multicast addresses: 482 link-local - FF02::204; 483 admin-local - FF04::204; 484 site-local - FF05::204; and 485 organization-local - FF08::204. 487 IPv6 C12.22 IP Nodes SHOULD use the minimum scope needed, when 488 initiating IP multicast messages to reach another C12.22 IP Node on 489 the C12.22 Network. This practice allows the sender to limit 490 unnecessary propagation of C12.22 IP multicast Messages. 492 To determine the minimum scope required to reach the closest C12.22 493 IP Relay on the C12.22 Node's IP Network Segment, this specification 494 RECOMMENDS the following simple steps: 496 1. Starting with the smallest (local-most) scope, link-local (or a 497 pre-configured scope), send the C12.22 EPSEM Resolve Service 498 Request for C12.22 IP Relay discovery. 499 2. Listen for a response from a C12.22 IP Relay; then: 500 A. If no response is received, assign the next wider scope 501 level, then repeat steps (1) and (2) at the newly assigned 502 scope. 503 B. If a response is received then record the scope level as the 504 minimum scope to use on the node's C12.22 IP Network Segment. 506 A C12.22 IPv6 Node that initiates any EPSEM Service Request SHOULD 507 use the minimum scope necessary to reach its target C12.22 IP Nodes. 508 A C12.22 IPv6 Relay SHALL use the global scope for any C12.22 message 509 destined for the global Internet. 511 This specification does not preclude the use of the unassigned scope 512 values defined in [17]; those scope values MAY be used on a private 513 basis, or through mutual operating agreements. 515 For IPv4, all C12.22 IP Relays, C12.22 IP Master Relays, and all 516 C12.22 IP Nodes configured to support broadcast/multicast SHALL join 517 the assigned multicast address of 224.0.2.4. This global address 518 does not provide for the type of scoping discussed above for IPv6, 519 nor is it compatible with the administratively scoped IP multicast 520 specification in RFC 2365 [18]. Therefore, a different technique to 521 limit the propagation of C12.22 IP multicast Messages is needed. One 522 available technique to control IPv4 multicast scope is through the 523 use of the Time-to-Live (TTL) attribute in the IP packet header. 524 This attribute is not managed by the C12.22 protocol. 526 In the implementation of this technique, an administrative domain 527 MUST include at least one C12.22 IP Relay, and all C12.22 IP Nodes in 528 the administrative domain SHOULD be configured with a TTL 529 sufficiently large to reach that C12.22 IP Relay. 531 A C12.22 IPv4 Node that initiates any C12.22 Request Message SHOULD 532 use the minimum TTL needed to reach its target C12.22 IP Nodes. 534 4.7. IP Broadcast 536 IP broadcast is not generally suitable as a replacement for, or an 537 alternative to multicast in a C12.22 IP Network Segment. IP 538 broadcast is not supported in IPv6 and it suffers from limited scope 539 in IPv4. This specification, however, does not preclude the use of 540 IP network directed or limited/local scope (address 255.255.255.255) 541 broadcast within a controlled management domain (as per RFC 2644 542 [19]). 544 4.8. Encoding of Multicast and Broadcast Addresses 546 ANSI C12.22 Tables provide binary Elements for encoding a Native 547 Broadcast or Multicast Address for transport within a C12.22 Message. 548 The encoding of these Table Elements is identical to that defined in 549 Section 4.3, Encoding of Native IP Addresses. These fields SHALL be 550 used as shown in Figure 2. 552 Address IP Address (ADDR), Port (P), Transport (T) 553 Length Octet 554 0 1 555 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 556 IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Broadcast 4 |BADDR4 | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Broadcast 6 |BADDR4 | P | 562 +Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Broadcast 7 |BADDR4 | P |T| 566 +Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Multicast 4 |MADDR4 | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Multicast 6 |MADDR4 | P | 574 +Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Multicast 7 |MADDR4 | P |T| 578 +Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Multicast 16 | MADDR6 | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 Multicast 18 | MADDR6 | P | 586 +Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 Multicast 19 | MADDR6 | P |T| 590 +Port+Transport +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Figure 2: Encoding of broadcast/multicast native IP addresses 594 The IPv4 and IPv6 multicast addresses, MADDR4 and MADDR6, 595 respectively, are those assigned by IANA for use by ANSI C12.22. 597 When a broadcast/multicast Native IP Address is encoded in ANSI 598 C12.19 Tables' BINARY data Elements the size of the Native Address 599 Element transmitted is defined by ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN 600 (See [1] and [2] Table 121). This is the actual number of octets 601 that are placed inside the C12.19 BINARY Element. This value is 602 common to all of the C12.22 Node's interfaces, including those that 603 are not IP based (thus not conforming to this specification). For 604 this reason the ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN MAY be greater 605 than, and SHALL NOT be smaller than, the actual length needed to 606 encode a native IP broadcast/multicast address per Figure 2. When 607 this is the case, the C12.22 Native IP Address SHALL be padded with 608 zero (0) to fill the Table's BINARY data Element. 610 The IPv4 network directed broadcast address can be computed by 611 performing a bitwise OR between the bit complement of the subnet mask 612 of the target IP subnet and the IP address of any host on that IP 613 subnet. 615 5. IP Message Transport 617 This section defines a C12.22 Node's usage of the Connection-Oriented 618 (CO) and Connectionless (CL) transport layer protocols, TCP and UDP, 619 respectively. 621 5.1. C12.22 Connection Types and TCP/UDP Transport Modes 623 A C12.22 IP Node's use of TCP and UDP is based on its registered 624 capabilities as defined in its configuration parameters (flags) and 625 as expressed in the Node's accepted registration attributes [1]: 627 CL Flag = .CONNECTIONLESS_MODE_SUPPORTED; 628 CL Accept Flag = .ACCEPT_CONNECTIONLESS; 629 CO Flag = .CONNECTION_MODE_SUPPORTED; and 630 CO Accept Flag = .ACCEPT_CONNECTIONS. 632 The mapping of the connection-type parameters to the IP-based 633 transport variants that a C12.22 Node MAY support is defined in Table 634 1. 636 +------+------+----------+----------+-------------------------------+ 637 | CL | CO | CL | CO | IP Transport Mode Supported | 638 | Flag | Flag | Accept | Accept | | 639 | | | Flag | Flag | | 640 +------+------+----------+----------+-------------------------------+ 641 | 0 | 0 | x | x | Invalid | 642 | 0 | 1 | 0 | 0 | TCP, Active-OPEN | 643 | 0 | 1 | 0 | 1 | TCP, Passive- and Active-OPEN | 644 | 0 | 1 | 1 | 0 | Invalid | 645 | 0 | 1 | 1 | 1 | Invalid | 646 | 1 | 0 | 0 | 0 | UDP, Active-OPEN | 647 | 1 | 0 | 0 | 1 | Invalid | 648 | 1 | 0 | 1 | 0 | UDP, Passive- and Active-OPEN | 649 | 1 | 0 | 1 | 1 | Invalid | 650 | 1 | 1 | 0 | 0 | UDP, Active-OPEN; TCP | 651 | | | | | Active-OPEN | 652 | 1 | 1 | 0 | 1 | UDP, Active-OPEN; TCP, | 653 | | | | | Passive- and Active-OPEN | 654 | 1 | 1 | 1 | 0 | UDP, Passive- and | 655 | | | | | Active-OPEN; TCP, Active-OPEN | 656 | 1 | 1 | 1 | 1 | UDP, Passive- and | 657 | | | | | Active-OPEN; TCP, Passive- | 658 | | | | | and Active-OPEN | 659 +------+------+----------+----------+-------------------------------+ 661 Table 1: C12.22 Node Parameters to IP Transport Mapping 663 Every C12.22 IP Node MUST support at least one of unicast CO or CL 664 operating capabilities (as advertized in Decade 12, Network Tables 665 [1], where available, and as registered using the C12.22 Registration 666 Service [1]). 668 5.2. IP Message Transport Details 670 5.2.1. TCP and UDP Port Use 672 General rules: 673 1. A C12.22 IP Node that implements [CL Accept=1] SHALL receive 674 incoming UDP C12.22 Messages on its registered Native IP Address 675 (IP address and port number). 676 2. A C12.22 IP Node that implements [CO Accept=1] SHALL receive 677 incoming TCP connections on its registered Native IP Address (IP 678 address and port number). 679 3. A C12.22 IP Relay that forwards a UDP C12.22 Message to a C12.22 680 IP Node on the C12.22 IP Network Segment SHALL send the C12.22 681 Message to the C12.22 IP Node's registered Native IP Address (IP 682 address, port number). 684 4. A C12.22 IP Relay that forwards a TCP C12.22 Message to a C12.22 685 IP Node on the C12.22 IP Network Segment MAY use an established 686 TCP connection to that C12.22 IP Node, or it SHALL establish a 687 new TCP connection to the C12.22 IP Node's registered Native IP 688 Address (IP address and port number). 689 5. A C12.22 IP Node that implements [CL=1] SHOULD set the source 690 port number in outbound UDP C12.22 Messages to its registered 691 port number. When the target UDP C12.22 IP Node is reachable 692 using direct messaging (as defined in [1]), the C12.22 IP Node 693 MAY set the source port number to a UDP port number that is 694 different than its registered port number. 695 6. When the registered Native IP Address of a C12.22 IP Node does 696 not include the OPTIONAL port number, then port 1153 SHALL be 697 assumed and used as the registered port number. 698 7. All C12.22 IP Nodes SHOULD use port 1153 in their Native IP 699 Address when registering. 701 5.2.2. Active-OPEN UDP (CL=1, CL Accept=0) 703 A C12.22 IP Node that supports this mode SHALL NOT monitor for 704 unsolicited incoming C12.22 Messages via UDP. As a result, the 705 C12.22 IP Node is incapable of receiving unsolicited C12.22 Messages 706 using UDP. 708 The C12.22 IP Node MAY enter the Active-OPEN UDP state by initiating 709 an unsolicited UDP transmission to a Target C12.22 IP Node, which is 710 expected to implement the Passive-OPEN UDP mode. 712 C12.22 IP Nodes SHOULD use their registered UDP port number, or if 713 not yet registered then they SHOULD use port 1153, as the source port 714 number for all UDP C12.22 IP Messages. 716 5.2.3. Passive-OPEN UDP (CL=1, CL Accept=1) 718 A C12.22 IP Node that operates in this mode SHALL be capable of 719 receiving solicited and unsolicited C12.22 Messages from other C12.22 720 IP Nodes. The C12.22 Node MAY change the port number that it 721 monitors by using the parameter of the ANSI C12.22 722 Registration Service. The C12.22 IP Node MAY initiate unsolicited 723 Active-OPEN UDP transmissions to other C12.22 IP Nodes that implement 724 the Passive-OPEN UDP mode. 726 When operating in this mode, the C12.22 IP Nodes SHALL use their 727 registered UDP port number as the source port number for all UDP 728 C12.22 IP Messages. 730 All C12.22 IP Relays SHALL support the Passive-OPEN UDP mode. C12.22 731 Authentication Hosts and C12.22 Notification Hosts that implement UDP 732 SHALL support Passive-OPEN UDP mode. For all other C12.22 IP Nodes, 733 Passive-OPEN UDP mode is the RECOMMENDED mode when implementing UDP. 735 5.2.4. Active-OPEN TCP Mode (CO=1, CO Accept=0) 737 A C12.22 IP Node that supports this mode SHALL NOT monitor for 738 inbound TCP connections. As a result, the node is incapable of 739 accepting incoming connections via TCP. The C12.22 IP Node MAY 740 initiate TCP connections to Target C12.22 IP Nodes, which are 741 expected to implement the Passive-OPEN TCP mode. 743 In this mode, C12.22 Messages exchanged by a pair of associated 744 C12.22 IP Nodes can only be communicated through any of the TCP 745 connections that were initiated by the C12.22 IP Node that implements 746 this mode. The loss or closure of a connection SHALL NOT 747 automatically result in the termination of the C12.22 associations 748 between the peer nodes. In order to continue exchanging C12.22 749 Messages without loss of association, the initiating C12.22 IP Node 750 MAY re-establish new TCP connections with the peer node, or use 751 existing connections to the peer node. The termination of the C12.22 752 Application associations is dependent upon C12.22 application timeout 753 attributes and C12.22 link management services (such as Procedure 25 754 Network Interface Control [1]). 756 5.2.5. Passive-OPEN TCP Mode (CO=1, CO Accept=1) 758 A C12.22 IP Node that operates in this mode SHALL monitor and accept 759 incoming TCP connections. The C12.22 Node May change the port number 760 that it monitors by using the parameter of the ANSI 761 C12.22 Registration Service. The C12.22 IP Node MAY initiate Active- 762 OPEN TCP connections to other C12.22 IP Nodes that implement the 763 Passive-OPEN TCP mode. 765 In this mode, C12.22 Messages exchanged by a pair of associated 766 C12.22 IP Nodes can arrive through any of the TCP connections that 767 were established by either node. The loss or closure of a connection 768 SHALL NOT automatically result in the termination of the C12.22 769 associations between the peer nodes. In order to continue exchanging 770 C12.22 Messages without loss of association, either C12.22 IP Node 771 MAY re-establish new TCP connections with the peer node, or use 772 existing connections to the peer node. The termination of the C12.22 773 Application associations is dependent upon C12.22 application timeout 774 attributes and C12.22 link management services (such as Procedure 25 775 Network Interface Control [1]). 777 All C12.22 IP Relays SHALL support the Passive-OPEN TCP mode. C12.22 778 Authentication Hosts and C12.22 Notification Hosts that implement TCP 779 SHALL support Passive-OPEN TCP mode. For all other C12.22 IP Nodes, 780 Passive-OPEN TCP mode is the RECOMMENDED mode when implementing TCP. 782 5.2.6. TCP and C12.22 Message Directionality 784 C12.22 IP Nodes MAY use TCP in one of two ways: bi-directional 785 traffic flow or uni-directional traffic flow. 787 When TCP connections are used, any new or established TCP connection 788 between the two C12.22 IP Nodes MAY be used equivalently by the 789 C12.22 IP Nodes to send and to receive C12.22 Messages. This is the 790 RECOMMENDED and default mode of operation because ANSI C12.22 791 requires the transport network to be reliable and connectionless (per 792 connectionless-mode ACSE). For this reason ANSI C12.22 defines peer- 793 to-peer application associations and not peer-to-peer connections. 795 It is known that some C12.22 implementations have been deployed in 796 which TCP is used for uni-directional traffic flow. For these types 797 of implementations, an established TCP connection SHALL be used by 798 the initiator of that connection to send C12.22 Messages and by the 799 target node (who accepted the connection) to receive C12.22 Messages. 800 If a C12.22 IP Node wishes to send a C12.22 Message to a peer C12.22 801 IP Node, it MUST establish and use a new TCP connection or use an 802 existing TCP connection that it had previously initiated, for its 803 outbound uni-directional traffic flow. 805 For increased interoperability, the initiator of the connection 806 SHOULD accept incoming C12.22 Messages on that connection in case the 807 target node attempts to use the connection for bi-directional traffic 808 flow. 810 Uni-directional use of TCP is a special mode of operation; it is NOT 811 RECOMMENDED because multiple one-way channel communication is not 812 described by ANSI C12.22, and it utilizes one-half of the TCP 813 connection capability. As a result it doubles the number of TCP 814 connections used to communicate C12.22 Messages, and thus could 815 become a burden when a large number of connections is required. 817 5.3. Using IP Broadcast/Multicast 819 A C12.22 IP Node's use of Broadcast/Multicast is based on its 820 capabilities as defined in its configuration parameters (flags) and 821 as expressed in the Node's accepted registration attributes [1] 822 (.BROADCAST_AND_MULTICAST_SUPPORTED). The mapping 823 of the C12.22 IP Node's Broadcast/Multicast parameter (flag) to IP 824 Broadcast/Multicast usage is defined in Table 2. 826 C12.22 Broadcast and IP Broadcast/Multicast Supported 827 Multicast Supported 828 Flag 829 ---------------------- ---------------------------------------------- 830 0 The C12.22 IP Node does not accept IP 831 broadcast and it does not accept IP multicast 832 messages. 833 1 The C12.22 IP Node accepts both IP broadcast 834 (IPv4 only) and IP multicast messages (IPv4 835 and IPv6). 837 Table 2: C12.22 to IP Broadcast/Multicast Mapping 839 If a C12.22 IP Node is configured to accept IP broadcast and 840 multicast messages, it SHALL join the "All C1222 Nodes" multicast 841 group (see Section 4.6, IP Multicast), and SHALL use the default port 842 1153. In addition it SHALL accept IP Network directed or limited 843 (local scope) broadcast messages sent to port 1153. Note that 844 successful communication using network directed broadcast requires 845 configuration of network routers, which by default SHALL NOT forward 846 directed broadcasts as per RFC 2644 [19]. 848 5.4. Transport Protocol Decisions 850 5.4.1. Unicast Versus Multicast Versus Broadcast 852 An initiating C12.22 IP Node MAY send any C12.22 Message using UDP or 853 TCP. However, in accordance with Section 5.3.2.4.12, Resolve 854 Service, of ANSI C12.22, it is RECOMMENDED that the C12.22 Resolve 855 Request message be transported using UDP/IP multicast when the Native 856 IP Address of the Target C12.22 Node is not known. Use of UDP/IP 857 multicast is preferred over the use of IP network directed or limited 858 broadcast; therefore when UDP/IP multicast is supported its use is 859 RECOMMENDED over network broadcast. 861 5.4.2. Sending Large C12.22 APDUs Using UDP 863 When sending via UDP a large C12.22 Message that exceeds the path 864 MTU, the sender SHALL segment the ACSE APDU in accordance with ANSI 865 C12.22 Datagram Segmentation and Reassembly algorithm, such that the 866 size of the resulting IP datagram does not exceed the path MTU, and 867 thus avoids UDP packet fragmentation. The fundamental issue with 868 fragmentation exists for both IPv4 and IPv6. Section 3.2 of RFC 5405 869 [20] provides additional guidelines for determining the appropriate 870 UDP message side. When path MTU is not known, the sender SHALL 871 follow the guidelines stipulated in Section 3.2 of RFC 5405 [20]: for 872 IPv4 use the smaller of 576 bytes and the first-hop MTU [21], and for 873 IPv6 use 1280 bytes [22]. Sending large APDUs via UDP may lead to 874 network congestion. For more information on avoiding network 875 congestion see Section 5.6, Congestion Control. 877 5.4.3. Choice of Protocol for C12.22 Response APDUs 879 When a Target C12.22 IP Node receives a C12.22 Request Message from 880 an initiating C12.22 IP Node, it SHALL send a C12.22 Response Message 881 using the same transport protocol (i.e., TCP to TCP, UDP to UDP). 883 In the case of UDP, the target SHALL send the C12.22 Response Message 884 to the source IP address and port number. 886 5.5. Quality of Service 888 The ANSI C12.22 standard provides a configuration parameter in the 889 APDU's .URGENT to mark a message as urgent. 890 There are numerous IP-based technologies that enable enhanced levels 891 of message delivery and quality of service. This specification does 892 not define the technology to be used to send urgent messages over IP. 894 5.6. Congestion Control 896 Designers of unicast applications that implement the upper-layers of 897 C12.22 Messaging over UDP SHOULD follow the congestion control 898 guidelines in Section 3.1 of RFC 5405 [20]. 900 For the transmission of C12.22 Messages that are greater than what 901 the TCP initial window would be over a given Internet path, TCP 902 SHOULD be used rather than UDP as the transport protocol. TCP's 903 initial window depends on the MSS, which in turn depends on the path 904 MTU, and is computed according to formula (1) in RFC 3390 [23]. For 905 unknown path MTUs, the minimum-sized MSS MUST be used and the C12.22 906 Application SHOULD assume the maximum C12.22 Message size to be 2048 907 bytes. By using TCP the C12.22 Application benefits from the built- 908 in TCP congestion control mechanism. 910 When UDP is the preferred transport mechanism or when UDP multicast 911 or broadcast are the preferred modes of communication, then the 912 C12.22 application SHOULD use C12.22 acknowledged Messages that are 913 smaller than TCP's initial window over the return path, as computed 914 by formula (1) in [23] and described above. The size of the C12.22 915 Message MAY be managed through the use of ANSI C12.22 EPSEM Partial 916 Table Read/Write service requests and responses. 918 6. Security Considerations 920 The ANSI C12.22 Application layer security is defined in Section 921 5.3.4.13, C12.22 Security Mechanism, of the ANSI C12.22 standard. 922 The security mechanisms include provisions for message privacy and 923 authentication, playback rejection, and message acceptance windows as 924 well as ANSI C12.19 [2] role-based data access and secured register 925 mechanisms. The ANSI C12.22 Application layer default security 926 mechanism provides three options to choose from when sending C12.22 927 Messages: 929 1. Sending clear text messages over the C12.22 Network [1], [6], 930 which MAY result in altered C12.22 Messages and exposure to 931 password sniffing attacks, as described in RFC 3552 [24]. 932 2. Sending of authenticated plain text messages over the C12.22 933 Network [1], [6], which MAY result in password sniffing attacks 934 as described in RFC 3552 [24]. 935 3. Sending of authenticated cipher text over the C12.22 Network 936 providing for message and peer node authentication and privacy. 938 When option 1 is used then it is RECOMMENDED that the network or 939 transport layer provide authentication and confidentiality service. 940 When option 2 is used then it is RECOMMENDED that the network or 941 transport layer provide confidentiality services. When option 3 is 942 used then no additional network or transport layer security services 943 are necessary. 945 Additional Transport or Network layer security protocols are not 946 required by ANSI C12.22, but they MAY be provided transparently by 947 C12.22 IP Network Segment integrators (e.g., in C12.22 IP Relays) in 948 order to improve on the security provisions cited above. However, 949 any added Transport security (e.g., TLS, RFC 5246 [27]) or IP 950 security (e.g., IPsec, RFC 4302 [25], RFC 4303 [26], RFC 5996 [28]) 951 features SHALL act only to enhance (i.e., not be a substitute for, or 952 an alteration of) the interoperable ANSI C12.22 and ANSI C12.19 953 security provisions, and SHALL NOT corrupt and SHALL NOT alter the 954 C12.22 Message as presented by the C12.22 Application layer. 956 The ANSI C12.22 [1] and ANSI C12.19 [2] standards provide for the 957 transmission of keys and their storage in C12.19 End Devices (e.g., 958 meters and Head-end systems). The key management protocol (when and 959 how keys are exchanged) is not described in the ANSI C12.22 [1] and 960 ANSI C12.19 [2] standards, except to state that keys MAY not be 961 readable from a C12.19 End Device (in response to a read service 962 request). It is RECOMMENDED that all C12.22 Nodes encrypt user 963 information element key fields and passwords. It is also RECOMMENDED 964 that all C12.22 Nodes mask user information element key fields and 965 password fields of EPSEM Read Service Responses (e.g., by replacing 966 all key and password bytes with zeros (0x00) or spaces (0x20)). 968 Legacy deployments exist that are not connected to the Internet, so 969 there are some implementations that do not include security. It is 970 likely that multi-homed C12.22 Nodes with interfaces to the Internet 971 will exist in future deployments, so security mechanisms MUST be used 972 by those C12.22 Nodes to ensure C12.22 Message authentication and 973 confidentiality. 975 7. IANA Considerations 977 UDP and TCP port 1153, which is used for C12.22 communication over 978 IP, is registered with IANA. 980 Section 4.6, IP Multicast defines the use of multicast. The 981 following multicast addresses have been registered by IANA for use by 982 the ANSI C12.22 standard: 983 IPv4 - "All C1222 Nodes" address 224.0.2.4 984 IPv6 - "All C1222 Nodes" address FF0X::204 986 8. Acknowledgments 988 The authors wish to recognize Alexander Shulgin for providing 989 valuable comments and for conducting feasibility testing in support 990 of this work. 992 The following people have improved this document through thoughtful 993 comments and suggestions: Fred Baker, Ralph Droms, Vijay Gurbani, 994 Michael Stuber, Spencer Dawkins, Alfred Hoenes, Russ Housley, Paul 995 Hoffman, Lars Eggert and Sean Turner. 997 9. References 999 9.1. Normative References 1001 [1] ANSI, "Protocol Specification for Interfacing to Data 1002 Communication Networks", ANSI C12.22-2008, January 2009. 1004 [2] ANSI, "Utility Industry End Device Data Tables", ANSI C12.19- 1005 2008, February 2009. 1007 [3] IEEE, "Draft Standard for Utility Industry Metering 1008 Communication Protocol Application Layer (End Device Data 1009 Tables)", IEEE P1377-2010, October 2010. 1011 [4] Measurement Canada, "Specification for Utility Industry 1012 Metering Communication Protocol Application Layer (End Device 1013 Data Tables)", Draft MC12.19-2010. 1015 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1016 Levels", BCP 14, RFC 2119, March 1997. 1018 [6] IEEE, "Standard for Local Area Network/Wide Area Network (LAN/ 1019 WAN) Node Communication Protocol to Complement the Utility 1020 Industry End Device Data Tables", IEEE P1703-2010, 1021 October 2010. 1023 [7] Measurement Canada, "Specification for Local Area Network/Wide 1024 Area Network (LAN/WAN) Node Communication Protocol to 1025 Complement the Utility Industry End Device Data Tables", 1026 Draft MC12.19, 2010. 1028 [8] ISO/IEC, "Information Technology-Open Systems Interconnection- 1029 Connectionless Protocol for the Association Control Service 1030 Element: Protocol Specification", ISO/IEC 10035-1, 1995. 1032 [9] ISO/IEC, "Information Technology-ASN.1 Encoding Rules: 1033 Specification of Basic Encoding Rules (BER), Canonical Encoding 1034 Rules (CER) and Distinguished Encoding Rules (DER)", ISO/ 1035 IEC 8825-1, 2002. 1037 [10] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1038 August 1980. 1040 [11] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 1041 September 1981. 1043 [12] Deering, S., "Host extensions for IP multicasting", STD 5, 1044 RFC 1112, August 1989. 1046 [13] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1047 Thyagarajan, "Internet Group Management Protocol, Version 3", 1048 RFC 3376, October 2002. 1050 [14] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 1051 (MLDv2) for IPv6", RFC 3810, June 2004. 1053 [15] Conta, A., Deering, S., and M. Gupta, "Internet Control Message 1054 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1055 Specification", RFC 4443, March 2006. 1057 [16] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1058 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1060 Protocol Specification (Revised)", RFC 4601, August 2006. 1062 [17] Hinden, R. and S. Deering, "IP Version 6 Addressing 1063 Architecture", RFC 4291, February 2006. 1065 [18] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 1066 RFC 2365, July 1998. 1068 [19] Senie, D., "Changing the Default for Directed Broadcasts in 1069 Routers", BCP 34, RFC 2644, August 1999. 1071 [20] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for 1072 Application Designers", BCP 145, RFC 5405, November 2008. 1074 [21] Braden, R., "Requirements for Internet Hosts - Communication 1075 Layers", STD 3, RFC 1122, October 1989. 1077 [22] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1078 Specification", RFC 2460, December 1998. 1080 [23] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 1081 Initial Window", RFC 3390, October 2002. 1083 [24] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 1084 Security Considerations", BCP 72, RFC 3552, July 2003. 1086 9.2. Informative References 1088 [25] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 1090 [26] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1091 December 2005. 1093 [27] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1094 Protocol Version 1.2", RFC 5246, August 2008. 1096 [28] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key 1097 Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 1099 Authors' Addresses 1101 Avygdor Moise 1102 Future DOS R&D Inc. 1103 #303 - 6707 Elbow Drive SW 1104 Calgary, Alberta T2V 0E5 1105 Canada 1107 Email: avy@fdos.ca 1108 URI: http://www.fdos.ca 1110 Jonathan Brodkin 1111 Future DOS R&D Inc. 1112 #303 - 6707 Elbow Drive SW 1113 Calgary, Alberta T2V 0E5 1114 Canada 1116 Email: jonathan.brodkin@fdos.ca 1117 URI: http://www.fdos.ca