3.  Specific Protocols

   In this section, having briefly laid out the IP architecture and some
   of the problems that the architecture tries to address, we introduce
   specific protocols that might be appropriate to various Smart Grid
   use cases.  Use cases should be analyzed along with privacy,
   Authentication, Authorization, and Accounting (AAA), transport, and
   network solution dimensions.  The following sections provide guidance
   for such analysis.

3.1.  Security Toolbox

   As noted, a key consideration in security solutions is a good threat
   analysis coupled with appropriate mitigation strategies at each
   layer.  The IETF has over time developed a number of building blocks
   for security based on the observation that protocols often demand
   similar security services.  The following sub-sections outline a few
   of those commonly used security building blocks.  Reusing them offers
   several advantages, such as availability of open source code,
   experience with existing systems, a number of extensions that have
   been developed, and the confidence that the listed technologies have
   been reviewed and analyzed by a number of security experts.

   It is important to highlight that in addition to the mentioned
   security tools, every protocol often comes with additional, often
   unique security considerations that are specific to the domain in
   which the protocol operates.  Many protocols include features
   specifically designed to mitigate these protocol-specific risks.  In
   other cases, the security considerations will identify security-
   relevant services that are required from other network layers to
   achieve appropriate levels of security.

3.1.1.  Authentication, Authorization, and Accounting (AAA)

   While the term AAA sounds generic and applicable to all sorts of
   security protocols, it has been, in the IETF, used in relation to
   network access authentication and is associated with the RADIUS
   ([RFC2865]) and the Diameter protocol ([RFC3588], [DIME-BASE]) in
   particular.

   The authentication procedure for network access aims to deal with the
   task of verifying that a peer is authenticated and authorized prior
   to accessing a particular resource (often connectivity to the
   Internet).  Typically, the authentication architecture for network
   access consists of the following building blocks: the Extensible

   Authentication Protocol (EAP [RFC4017]) as a container to encapsulate
   EAP methods, an EAP Method (as a specific way to perform
   cryptographic authentication and key exchange, such as described in
   RFC 5216 [RFC5216] and RFC 5433 [RFC5433]), a protocol that carries
   EAP payloads between the end host and a server-side entity (such as a
   network access server), and a way to carry EAP payloads to back-end
   server infrastructure (potentially in a cross-domain scenario) to
   provide authorization and accounting functionality.  The latter part
   is provided by RADIUS and Diameter.  To carry EAP payloads between
   the end host and a network access server, different mechanisms have
   been standardized, such as the Protocol for Carrying Authentication
   for Network Access (PANA) [RFC5191] and IEEE 802.1X [IEEE802.1X].
   For access to remote networks, such as enterprise networks, the
   ability to utilize EAP within IKEv2 [RFC5996] has also been
   developed.

   More recently, the same architecture with EAP and RADIUS/Diameter is
   being reused for application layer protocols.  More details about
   this architectural variant can be found in [ABFAB-ARCH].

3.1.2.  Network Layer Security

   IP security, as described in [RFC4301], addresses security at the IP
   layer, provided through the use of a combination of cryptographic and
   protocol security mechanisms.  It offers a set of security services
   for traffic at the IP layer, in both the IPv4 and IPv6 environment.
   The set of security services offered includes access control,
   connectionless integrity, data origin authentication, detection and
   rejection of replays (a form of partial sequence integrity),
   confidentiality (via encryption), and limited traffic-flow
   confidentiality.  These services are provided at the IP layer,
   offering protection in a standard fashion for all protocols that may
   be carried over IP (including IP itself).

   The architecture foresees a split between the rather time-consuming
   (a) authentication and key exchange protocol step that also
   establishes a security association (a data structure with keying
   material and security parameters) and (b) the actual data traffic
   protection.

   For the former step, the Internet Key Exchange protocol version 2
   (IKEv2 [RFC5996]) is the most recent edition of the standardized
   protocol.  IKE negotiates each of the cryptographic algorithms that
   will be used to protect the data independently, somewhat like
   selecting items a la carte.

   For the actual data protection, two types of protocols have
   historically been used, namely the IP Authentication Header (AH)

   [RFC4302] and the Encapsulating Security Payload (ESP) [RFC4303].
   The two differ in the security services they offer; the most
   important distinction is that ESP offers confidentiality protection
   while AH does not.  Since ESP can also provide authentication
   services, most recent protocol developments making use of IPsec only
   specify use of ESP and do not use AH.

   In addition to these base line protocol mechanisms a number of
   extensions have been developed for IKEv2 (e.g., an extension to
   perform EAP-only authentication [RFC5998]) and since the architecture
   supports flexible treatment of cryptographic algorithms a number of
   them have been specified (e.g., [RFC4307] for IKEv2, and [RFC4835]
   for AH and ESP).

3.1.3.  Transport Layer Security

   Transport Layer Security v1.2 [RFC5246] are security services that
   protect data above the transport layer.  The protocol allows client/
   server applications to communicate in a way that is designed to
   prevent eavesdropping, tampering, or message forgery.  TLS is
   application protocol independent.

   TLS is composed of two layers: the TLS Record protocol and the TLS
   Handshake protocol.  The TLS Record protocol provides connection
   security that has two basic properties: (a) confidentiality
   protection and (b) integrity protection.

   The TLS Handshake protocol allows the server and client to
   authenticate each other and to negotiate an encryption algorithm and
   cryptographic keys before the application protocol transmits or
   receives its first byte of data.  The negotiated parameters and the
   derived keying material is then used by the TLS Record protocol to
   perform its job.

   Unlike IKEv2/IPsec, TLS negotiates these cryptographic parameters in
   suites, so-called 'cipher suites'.  Examples of cipher suites that
   can be negotiated with TLS include Elliptic Curve Cryptography (ECC)
   [RFC4492] [RFC5289] [AES-CCM-ECC], Camellia [RFC5932], and the Suite
   B Profile [RFC5430].  [IEC62351-3] outlines the use of different TLS
   cipher suites for use in the Smart Grid.  The basic cryptographic
   mechanisms for ECC have been documented in [RFC6090].

   TLS must run over a reliable transport channel -- typically TCP.  In
   order to offer the same security services for unreliable datagram
   traffic, such as UDP, the Datagram Transport Layer Security (DTLS
   [RFC4347] [DTLS]) was developed.

3.1.4.  Application Layer Security

   In certain cases, the application layer independent security
   mechanisms described in the previous sub-sections are not sufficient
   to deal with all the identified threats.  For this purpose, a number
   of security primitives are additionally available at the application
   layer where the semantic of the application can be considered.

   We will focus our description on a few mechanisms that are commonly
   used throughout the Internet.

   Cryptographic Message Syntax (CMS [RFC5652]) is an encapsulation
   syntax to sign, digest, authenticate, or encrypt arbitrary message
   content.  It also allows arbitrary attributes, such as signing time,
   to be signed along with the message content, and it provides for
   other attributes such as countersignatures to be associated with a
   signature.  The CMS can support a variety of architectures for
   certificate-based key management, such as the one defined by the PKIX
   (Public Key Infrastructure using X.509) working group [RFC5280].  The
   CMS has been leveraged to supply security services in a variety of
   protocols, including secure email [RFC5751], key management [RFC5958]
   [RFC6031], and firmware updates [RFC4108].

   Related work includes the use of digital signatures on XML-encoded
   documents, which has been jointly standardized by W3C and the IETF
   [RFC3275].  Digitally signed XML is a good choice where applications
   natively support XML-encoded data, such as the Extensible Messaging
   and Presence Protocol (XMPP).

   More recently, the work on delegated authentication and authorization
   often demanded by Web applications have been developed with the Open
   Web Authentication (OAuth) protocol [RFC5849] [OAUTHv2].  OAuth is
   used by third-party applications to gain access to protected
   resources (such as energy consumption information about a specific
   household) without having the resource owner share its long-term
   credentials with that third-party.  In OAuth, the third-party
   application requests access to resources controlled by the resource
   owner and hosted by the resource server, and is issued a different
   set of credentials than those of the resource owner.  More
   specifically, the third-party applications obtain an access token
   during the OAuth protocol exchange.  This token denotes a specific
   scope, duration, and other access attributes.  As a result, it
   securely gains access to the protected resource with the consent of
   the resource owner.

3.1.5.  Secure Shell

   The Secure Shell (SSH) protocol [RFC4253] has been widely used by
   administrators and others for secure remote login, but is also usable
   for secure tunneling.  More recently, protocols have chosen to layer
   on top of SSH for transport security services; for example, the
   NETCONF network management protocol (see Section 3.5.2) uses SSH as
   its main communications security protocol.

3.1.6.  Key Management Infrastructures

   All of the security protocols discussed above depend on cryptography
   for security, and hence require some form of key management.  Most
   IETF protocols at least nominally require some scalable form of key
   management to be defined as mandatory to implement; indeed the lack
   of such key management features has in the past been a reason to
   delay approval of protocols.  There are two generic key management
   schemes that are widely used by other Internet protocols, PKIX and
   Kerberos, each of which is briefly described below.

3.1.6.1.  PKIX

   Public Key Infrastructure (PKI) refers to the kind of key management
   that is based on certification authorities (CAs) issuing public key
   certificates for other key holders.  By chaining from a trust anchor
   (a locally trusted copy of a CA public key) down to the public key of
   some protocol peer, PKI allows for secure binding between keys and
   protocol-specific names, such as email addresses, and hence enables
   security services such as data and peer authentication, data
   integrity, and confidentiality (encryption).

   The main Internet standard for PKI is [RFC5280], which is a profile
   of the X.509 public key certificate format.  There are a range of
   private and commercial CAs operating today providing the ability to
   manage and securely distribute keys for all protocols that use public
   key certificates, e.g., TLS and S/MIME.  In addition to the profile
   standard, the PKIX working group has defined a number of management
   protocols (e.g., [RFC5272] and [RFC4210]) as well as protocols for
   handling revocation of public key certificates such as the Online
   Certificate Status Protocol (OCSP) [RFC2560].

   PKI is generally perceived to better handle use-cases spanning
   multiple independent domains when compared to Kerberos.

3.1.6.2.  Kerberos

   The Kerberos Network Authentication System [RFC4120] is commonly used
   within organizations to centralize authentication, authorization, and
   policy in one place.  Kerberos natively supports usernames and
   passwords as the basis of authentication.  With Public Key
   Cryptography for Initial Authentication in Kerberos (PKINIT)
   [RFC4556], Kerberos supports certificate or public-key-based
   authentication.  This may provide an advantage by concentrating
   policy about certificate validation and mapping of certificates to
   user accounts in one place.  Through the GSS-API [RFC1964] [RFC2743]
   [RFC4121], Kerberos can be used to manage authentication for most
   applications.  While Kerberos works best within organizations and
   enterprises, it does have facilities that permit authentication to be
   shared between administrative domains.

3.2.  Network Layer

   The IPS specifies two network layer protocols: IPv4 and IPv6.  The
   following sections describe the IETF's coexistence and transition
   mechanisms for IPv4 and IPv6.

   Note that on 3 February 2011, the IANA's IPv4 free pool (the pool of
   available, unallocated IPv4 addresses) was exhausted, and the
   Regional Internet Registrars' (RIRs') free pools are expected to be
   exhausted during the coming year, if not sooner.  The IETF, the IANA,
   and the RIRs recommend that new deployments use IPv6, and that IPv4
   infrastructures be supported via the mechanisms described in
   Section 3.2.1.

3.2.1.  IPv4/IPv6 Coexistence Advice

   The IETF has specified a variety of mechanisms designed to facilitate
   IPv4/IPv6 coexistence.  The IETF actually recommends relatively few
   of them: the current advice to network operators is found in
   Guidelines for Using IPv6 Transition Mechanisms [RFC6180].  The
   thoughts in that document are replicated here.

3.2.1.1.  Dual Stack Coexistence

   The simplest coexistence approach is to

   o  provide a network that routes both IPv4 and IPv6,

   o  ensure that servers and their applications similarly support both
      protocols, and

   o  require that all new systems and applications purchased or
      upgraded support both protocols.

   The net result is that over time all systems become protocol
   agnostic, and that eventually maintenance of IPv4 support becomes a
   business decision.  This approach is described in the Basic
   Transition Mechanisms for IPv6 Hosts and Routers [RFC4213].

3.2.1.2.  Tunneling Mechanism

   In those places in the network that support only IPv4, the simplest
   and most reliable approach to coexistence is to provide virtual
   connectivity using tunnels or encapsulations.  Early in IPv6
   deployment, this was often done using static tunnels.  A more dynamic
   approach is documented in IPv6 Rapid Deployment on IPv4
   Infrastructures (6rd) [RFC5569].

3.2.1.3.  Translation between IPv4 and IPv6 Networks

   In those cases where an IPv4-only host would like to communicate with
   an IPv6-only host (or vice versa), a need for protocol translation
   may be indicated.  At first blush, protocol translation may appear
   trivial; on deeper inspection, it turns out that protocol translation
   can be complicated.

   The most reliable approach to protocol translation is to provide
   application layer proxies or gateways, which natively enable
   application-to-application connections using both protocols and can
   use whichever is appropriate.  For example, a web proxy might use
   both protocols and as a result enable an IPv4-only system to run HTTP
   across an IPv6-only network or to a web server that implements only
   IPv6.  Since this approach is a service of a protocol-agnostic
   server, it is not the subject of standardization by the IETF.

   For those applications in which network layer translation is
   indicated, the IETF has designed a translation mechanism, which is
   described in the following documents:

   o  Framework for IPv4/IPv6 Translation [RFC6144]

   o  IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]

   o  DNS extensions [RFC6147]

   o  IP/ICMP Translation Algorithm [RFC6145]

   o  Translation from IPv6 Clients to IPv4 Servers [RFC6146]

   As with IPv4/IPv4 Network Address Translation, translation between
   IPv4 and IPv6 has limited real world applicability for an application
   protocol that carries IP addresses in its payload and expects those
   addresses to be meaningful to both client and server.  However, for
   those protocols that do not, protocol translation can provide a
   useful network extension.

   Network-based translation provides for two types of services:
   stateless (and therefore scalable and load-sharable) translation
   between IPv4 and IPv6 addresses that embed an IPv4 address in them,
   and stateful translation similar to IPv4/IPv4 translation between
   IPv4 addresses.  The stateless mode is straightforward to implement,
   but due to the embedding, requires IPv4 addresses to be allocated to
   an otherwise IPv6-only network, and is primarily useful for IPv4-
   accessible servers implemented in the IPv6 network.  The stateful
   mode allows clients in the IPv6 network to access servers in the IPv4
   network, but does not provide such service for IPv4 clients accessing
   IPv6 peers or servers with general addresses; it has the advantage
   that it does not require that a unique IPv4 address be embedded in
   the IPv6 address of hosts using this mechanism.

   Finally, note that some site networks are IPv6 only while some
   transit networks are IPv4 only.  In these cases, it may be necessary
   to tunnel IPv6 over IPv4 or translate between IPv6 and IPv4.

3.2.2.  Internet Protocol Version 4

   IPv4 [RFC0791] and the Internet Control Message Protocol (ICMP)
   [RFC0792] comprise the IPv4 network layer.  IPv4 provides unreliable
   delivery of datagrams.

   IPv4 also provides for fragmentation and reassembly of long datagrams
   for transmission through networks with small Maximum Transmission
   Units (MTU).  The MTU is the largest packet size that can be
   delivered across the network.  In addition, the IPS provides ICMP
   [RFC0792], which is a separate protocol that enables the network to
   report errors and other issues to hosts that originate problematic
   datagrams.

   IPv4 originally supported an experimental type of service field that
   identified eight levels of operational precedence styled after the
   requirements of military telephony, plus three and later four bit
   flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2
   [RFC2328] interpreted as control traffic; this control traffic is
   assured of not being dropped when queued or upon receipt, even if
   other traffic is being dropped.  These control bits turned out to be
   less useful than the designers had hoped.  They were replaced by the
   Differentiated Services Architecture [RFC2474] [RFC2475], which

   contains a six-bit code point used to select an algorithm (a "per-hop
   behavior") to be applied to the datagram.  The IETF has also produced
   a set of Configuration Guidelines for DiffServ Service Classes
   [RFC4594], which describes a set of service classes that may be
   useful to a network operator.

3.2.2.1.  IPv4 Address Allocation and Assignment

   IPv4 addresses are administratively assigned, usually using automated
   methods, using the Dynamic Host Configuration Protocol (DHCP)
   [RFC2131].  On most interface types, neighboring systems identify
   each others' addresses using the Address Resolution Protocol (ARP)
   [RFC0826].

3.2.2.2.  IPv4 Unicast Routing

   Routing for the IPv4 Internet is accomplished by routing applications
   that exchange connectivity information and build semi-static
   destination routing databases.  If a datagram is directed to a given
   destination address, the address is looked up in the routing
   database, and the most specific ("longest") prefix found that
   contains it is used to identify the next-hop router or the end system
   to which it will be delivered.  This is not generally implemented on
   hosts, although it can be; a host normally sends datagrams to a
   router on its local network, and the router carries out the intent.

   IETF specified routing protocols include RIP Version 2 [RFC2453], OSI
   IS-IS for IPv4 [RFC1195], OSPF Version 2 [RFC2328], and BGP-4
   [RFC4271].  Active research exists in mobile ad hoc routing and other
   routing paradigms; these result in new protocols and modified
   forwarding paradigms.

3.2.2.3.  IPv4 Multicast Forwarding and Routing

   IPv4 was originally specified as a unicast (point to point) protocol,
   and was extended to support multicast in [RFC1112].  This uses the
   Internet Group Management Protocol [RFC3376] [RFC4604] to enable
   applications to join multicast groups, and for most applications uses
   Source-Specific Multicast [RFC4607] for routing and delivery of
   multicast messages.

   An experiment carried out in IPv4 that is not part of the core
   Internet architecture but may be of interest in the Smart Grid is the
   development of so-called "Reliable Multicast".  This is "so-called"
   because it is not "reliable" in the strict sense of the word -- it is
   perhaps better described as "enhanced reliability".  A best effort
   network by definition can lose traffic, duplicate it, or reorder it,
   something as true for multicast as for unicast.  Research in

   "Reliable Multicast" technology intends to improve the probability of
   delivery of multicast traffic.

   In that research, the IETF imposed guidelines [RFC2357] on the
   research community regarding what was desirable.  Important results
   from that research include a number of papers and several proprietary
   protocols including some that have been used in support of business
   operations.  RFCs in the area include The Use of Forward Error
   Correction (FEC) in Reliable Multicast [RFC3453], the Negative-
   acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
   [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP)
   [RFC4410].

3.2.3.  Internet Protocol Version 6

   IPv6 [RFC2460], with the Internet Control Message Protocol "v6"
   [RFC4443], constitutes the next generation protocol for the Internet.
   IPv6 provides for transmission of datagrams from source to
   destination hosts, which are identified by fixed-length addresses.

   IPv6 also provides for fragmentation and reassembly of long datagrams
   by the originating host, if necessary, for transmission through
   "small packet" networks.  ICMPv6, which is a separate protocol
   implemented along with IPv6, enables the network to report errors and
   other issues to hosts that originate problematic datagrams.

   IPv6 adopted the Differentiated Services Architecture [RFC2474]
   [RFC2475], which contains a six-bit code point used to select an
   algorithm (a "per-hop behavior") to be applied to the datagram.

   The IPv6 over Low-Power Wireless Personal Area Networks RFC [RFC4919]
   and the Compression Format for IPv6 Datagrams in 6LoWPAN Networks
   document [6LOWPAN-HC] addresses IPv6 header compression and subnet
   architecture in at least some sensor networks, and may be appropriate
   to the Smart Grid Advanced Metering Infrastructure or other sensor
   domains.

3.2.3.1.  IPv6 Address Allocation and Assignment

   An IPv6 Address [RFC4291] may be administratively assigned using
   DHCPv6 [RFC3315] in a manner similar to the way IPv4 addresses are.
   In addition, IPv6 addresses may also be autoconfigured.
   Autoconfiguration enables various models of network management that
   may be advantageous in different use cases.  Autoconfiguration
   procedures are defined in [RFC4862] and [RFC4941].  IPv6 neighbors
   identify each others' addresses using Neighbor Discovery (ND)
   [RFC4861].  SEcure Neighbor Discovery (SEND) [RFC3971] may be used to
   secure these operations.

3.2.3.2.  IPv6 Routing

   Routing for the IPv6 Internet is accomplished by routing applications
   that exchange connectivity information and build semi-static
   destination routing databases.  If a datagram is directed to a given
   destination address, the address is looked up in the routing
   database, and the most specific ("longest") prefix found that
   contains it is used to identify the next-hop router or the end system
   to which it will be delivered.  Routing is not generally implemented
   on hosts (although it can be); generally, a host sends datagrams to a
   router on its local network, and the router carries out the intent.

   IETF-specified routing protocols include RIP for IPv6 [RFC2080],
   IS-IS for IPv6 [RFC5308], OSPF for IPv6 [RFC5340], and BGP-4 for IPv6
   [RFC2545].  Active research exists in mobile ad hoc routing, routing
   in low-power networks (sensors and Smart Grids), and other routing
   paradigms; these result in new protocols and modified forwarding
   paradigms.

3.2.4.  Routing for IPv4 and IPv6

3.2.4.1.  Routing Information Protocol

   The prototypical routing protocol used in the Internet has probably
   been the Routing Information Protocol [RFC1058].  People that use it
   today tend to deploy RIPng for IPv6 [RFC2080] and RIP Version 2
   [RFC2453].  Briefly, RIP is a distance vector routing protocol that
   is based on a distributed variant of the widely known Bellman-Ford
   algorithm.  In distance vector routing protocols, each router
   announces the contents of its route table to neighboring routers,
   which integrate the results with their route tables and re-announce
   them to others.  It has been characterized as "routing by rumor", and
   suffers many of the ills we find in human gossip -- propagating stale
   or incorrect information in certain failure scenarios, and being in
   cases unresponsive to changes in topology.  [RFC1058] provides
   guidance to algorithm designers to mitigate these issues.

3.2.4.2.  Open Shortest Path First

   The Open Shortest Path First (OSPF) routing protocol is one of the
   more widely used protocols in the Internet.  OSPF is based on
   Dijkstra's well known Shortest Path First (SPF) algorithm.  It is
   implemented as OSPF Version 2 [RFC2328] for IPv4, OSPF for IPv6
   [RFC5340] for IPv6, and the Support of Address Families in OSPFv3
   [RFC5838] to enable [RFC5340] routing both IPv4 and IPv6.

   The advantage of any SPF-based protocol (i.e., OSPF and IS-IS) is
   primarily that every router in the network constructs its view of the

   network from first-hand knowledge rather than the "gossip" that
   distance vector protocols propagate.  As such, the topology is
   quickly and easily changed by simply announcing the change.  The
   disadvantage of SPF-based protocols is that each router must store a
   first-person statement of the connectivity of each router in the
   domain.

3.2.4.3.  ISO Intermediate System to Intermediate System

   The Intermediate System to Intermediate System (IS-IS) routing
   protocol is one of the more widely used protocols in the Internet.
   IS-IS is also based on Dijkstra's SPF algorithm.  It was originally
   specified as ISO DP 10589 for the routing of Connectionless Network
   Service (CLNS), and extended for routing in TCP/IP and dual
   environments [RFC1195], and more recently for routing of IPv6
   [RFC5308].

   As with OSPF, the positives of any SPF-based protocol and
   specifically IS-IS are primarily that the network is described as a
   lattice of routers with connectivity to subnets and isolated hosts.
   It's topology is quickly and easily changed by simply announcing the
   change, without the issues of "routing by rumor", since every host
   within the routing domain has a first-person statement of the
   connectivity of each router in the domain.  The negatives are a
   corollary: each router must store a first-person statement of the
   connectivity of each router in the domain.

3.2.4.4.  Border Gateway Protocol

   The Border Gateway Protocol (BGP) [RFC4271] is widely used in the
   IPv4 Internet to exchange routes between administrative entities --
   service providers, their peers, their upstream networks, and their
   customers -- while applying specific policy.  Multiprotocol
   Extensions [RFC4760] to BGP allow BGP to carry IPv6 Inter-Domain
   Routing [RFC2545], multicast reachability information, and VPN
   information, among others.

   Considerations that apply with BGP deal with the flexibility and
   complexity of the policies that must be defined.  Flexibility is a
   good thing; in a network that is not run by professionals, the
   complexity is burdensome.

3.2.4.5.  Dynamic MANET On-Demand (DYMO) Routing

   The Mobile Ad Hoc working group of the IETF developed, among other
   protocols, Ad hoc On-Demand Distance Vector (AODV) Routing [RFC3561].
   This protocol captured the minds of some in the embedded devices
   industry, but experienced issues in wireless networks such as

   802.15.4 and 802.11's Ad Hoc mode.  As a result, it is in the process
   of being updated in the Dynamic MANET On-demand (DYMO) Routing
   protocol [DYMO].

   AODV and DYMO are essentially reactive routing protocols designed for
   mobile ad hoc networks, and usable in other forms of ad hoc networks.
   They provide connectivity between a device within a distributed
   subnet and a few devices (including perhaps a gateway or router to
   another subnet) without tracking connectivity to other devices.  In
   essence, routing is calculated and discovered upon need, and a host
   or router need only maintain the routes that currently work and are
   needed.

3.2.4.6.  Optimized Link State Routing Protocol

   The Optimized Link State Routing Protocol (OLSR) [RFC3626] is a
   proactive routing protocol designed for mobile ad hoc networks, and
   can be used in other forms of ad hoc networks.  It provides arbitrary
   connectivity between systems within a distributed subnet.  As with
   protocols designed for wired networks, routing is calculated whenever
   changes are detected, and maintained in each router's tables.  The
   set of nodes that operate as routers within the subnet, however, are
   fairly fluid, and dependent on this instantaneous topology of the
   subnet.

3.2.4.7.  Routing for Low-Power and Lossy Networks

   The IPv6 Routing Protocol for Low power and Lossy Networks (RPL)
   [RPL] is a reactive routing protocol designed for use in resource
   constrained networks.  Requirements for resource constrained networks
   are defined in [RFC5548], [RFC5673], [RFC5826], and [RFC5867].

   Briefly, a constrained network is comprised of nodes that:

   o  Are built with limited processing power and memory, and sometimes
      energy when operating on batteries.

   o  Are interconnected through a low-data-rate network interface and
      are potentially vulnerable to communication instability and low
      packet delivery rates.

   o  Potentially have a mix of roles such as being able to act as a
      host (i.e., generating traffic) and/or a router (i.e., both
      forwarding and generating RPL traffic).

3.2.5.  IPv6 Multicast Forwarding and Routing

   IPv6 specifies both unicast and multicast datagram exchange.  This
   uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710]
   [RFC3590] [RFC3810] [RFC4604] to enable applications to join
   multicast groups, and for most applications uses Source-Specific
   Multicast [RFC4607] for routing and delivery of multicast messages.

   The mechanisms experimentally developed for reliable multicast in
   IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well.

3.2.5.1.  Protocol-Independent Multicast Routing

   A multicast routing protocol has two basic functions: building the
   multicast distribution tree and forwarding multicast traffic.
   Multicast routing protocols generally contain a control plane for
   building distribution trees, and a forwarding plane that uses the
   distribution tree when forwarding multicast traffic.

   The multicast model works as follows: hosts express their interest in
   receiving multicast traffic from a source by sending a Join message
   to their first-hop router.  That router in turn sends a Join message
   upstream towards the root of the tree, grafting the router (leaf
   node) onto the distribution tree for the group.  Data is delivered
   down the tree toward the leaf nodes, which forward it onto the local
   network for delivery.

   The initial multicast model deployed in the Internet was known as
   Any-Source Multicast (ASM).  In the ASM model, any host could send to
   the group and inter-domain multicast was difficult.  Protocols such
   as Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol
   Specification (Revised) [RFC3973] and Protocol Independent Multicast
   - Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601]
   were designed for the ASM model.

   Many modern multicast deployments use Source-Specific Multicast (PIM-
   SSM) [RFC3569][RFC4608].  In the SSM model, a host expresses interest
   in a "channel", which is comprised of a source (S) and a group (G).
   Distribution trees are rooted to the sending host (called an "(S,G)
   tree").  Since only the source S can send on to the group, SSM has
   inherent anti-jamming capability.  In addition, inter-domain
   multicast is simplified since finding the (S,G) channel they are
   interested in receiving is the responsibility of the receivers
   (rather than the networks).  This implies that SSM requires some form
   of directory service so that receivers can find the (S,G) channels.

3.2.6.  Adaptation to Lower-Layer Networks and Link Layer Protocols

   In general, the layered architecture of the Internet enables the IPS
   to run over any appropriate layer two architecture.  The ability to
   change the link or physical layer without having to rethink the
   network layer, transports, or applications has been a great benefit
   in the Internet.

   Examples of link layer adaptation technology include:

   Ethernet/IEEE 802.3:  IPv4 has run on each link layer environment
      that uses the Ethernet header (which is to say 10 and 100 MBPS
      wired Ethernet, 1 and 10 GBPS wired Ethernet, and the various
      versions of IEEE 802.11) using [RFC0894].  IPv6 does the same
      using [RFC2464].

   PPP:  The IETF has defined a serial line protocol, the Point-to-Point
      Protocol (PPP) [RFC1661], that uses High-Level Data Link Control
      (bit-synchronous or byte synchronous) framing.  The IPv4
      adaptation specification is [RFC1332], and the IPv6 adaptation
      specification is [RFC5072].  Current use of this protocol is in
      traditional serial lines, authentication exchanges in DSL networks
      using PPP Over Ethernet (PPPoE) [RFC2516], and the Digital
      Signaling Hierarchy (generally referred to as Packet-on-SONET/SDH)
      using PPP over SONET/SDH [RFC2615].

   IEEE 802.15.4:  The adaptation specification for IPv6 transmission
      over IEEE 802.15.4 Networks is [RFC4944].

   Numerous other adaptation specifications exist, including ATM, Frame
   Relay, X.25, other standardized and proprietary LAN technologies, and
   others.

3.3.  Transport Layer

   This section outlines the functionality of UDP, TCP, SCTP, and DCCP.
   UDP and TCP are best known and most widely used in the Internet
   today, while SCTP and DCCP are newer protocols that were built for
   specific purposes.  Other transport protocols can be built when
   required.

3.3.1.  User Datagram Protocol (UDP)

   The User Datagram Protocol [RFC0768] and the Lightweight User
   Datagram Protocol [RFC3828] are properly not "transport" protocols in
   the sense of "a set of rules governing the exchange or transmission
   of data electronically between devices".  They are labels that

   provide for multiplexing of applications directly on the IP layer,
   with transport functionality embedded in the application.

   Many exchange designs have been built using UDP, and many of them
   have not worked out.  As a result, the use of UDP really should be
   treated as designing a new transport.  Advice on the use of UDP in
   new applications can be found in Unicast UDP Usage Guidelines for
   Application Designers [RFC5405].

   Datagram Transport Layer Security [RFC5238] can be used to prevent
   eavesdropping, tampering, or message forgery for applications that
   run over UDP.  Alternatively, UDP can run over IPsec.

3.3.2.  Transmission Control Protocol (TCP)

   TCP [RFC0793] is the predominant transport protocol used in the
   Internet.  It is "reliable", as the term is used in protocol design:
   it delivers data to its peer and provides acknowledgement to the
   sender, or it dies trying.  It has extensions for Congestion Control
   [RFC5681] and Explicit Congestion Notification [RFC3168].

   The user interface for TCP is a byte stream interface -- an
   application using TCP might "write" to it several times only to have
   the data compacted into a common segment and delivered as such to its
   peer.  For message-stream interfaces, ACSE/ROSE uses the ISO
   Transport Service on TCP [RFC1006][RFC2126] in the application.

   Transport Layer Security [RFC5246] can be used to prevent
   eavesdropping, tampering, or message forgery.  Alternatively, TCP can
   run over IPsec.  Additionally, [RFC4987] discusses mechanisms similar
   to SCTP's and DCCP's "cookie" approach that may be used to secure TCP
   sessions against flooding attacks.

   Finally, note that TCP has been the subject of ongoing research and
   development since it was written.  The Roadmap for TCP Specification
   Documents [RFC4614] captures this history, and is intended to be a
   guide to current and future developers in the area.

3.3.3.  Stream Control Transmission Protocol (SCTP)

   SCTP [RFC4960] is a more recent reliable transport protocol that can
   be imagined as a TCP-like context containing multiple separate and
   independent message streams (unlike TCP's byte streams).  The design
   of SCTP includes appropriate congestion avoidance behavior and
   resistance to flooding and masquerade attacks.  As it uses a message
   stream interface, it may also be more appropriate for the ISO
   Transport Service than using RFC 1006/2126 to turn TCP's octet
   streams into a message interface.

   SCTP offers several delivery options.  The basic service is
   sequential non-duplicated delivery of messages within a stream, for
   each stream in use.  Since streams are independent, one stream may
   pause due to head-of-line blocking while another stream in the same
   session continues to deliver data.  In addition, SCTP provides a
   mechanism for bypassing the sequenced delivery service.  User
   messages sent using this mechanism are delivered to the SCTP user as
   soon as they are received.

   SCTP implements a simple "cookie" mechanism intended to limit the
   effectiveness of flooding attacks by mutual authentication.  This
   demonstrates that the application is connected to the same peer, but
   does not identify the peer.  Mechanisms also exist for Dynamic
   Address Reconfiguration [RFC5061], enabling peers to change addresses
   during the session and yet retain connectivity.  Transport Layer
   Security [RFC3436] can be used to prevent eavesdropping, tampering,
   or message forgery.  Alternatively, SCTP can run over IPsec.

3.3.4.  Datagram Congestion Control Protocol (DCCP)

   DCCP [RFC4340] is an "unreliable" transport protocol (e.g., one that
   does not guarantee message delivery) that provides bidirectional
   unicast connections of congestion-controlled unreliable datagrams.
   DCCP is suitable for applications that transfer fairly large amounts
   of data and that can benefit from control over the tradeoff between
   timeliness and reliability.

   DCCP implements a simple "cookie" mechanism intended to limit the
   effectiveness of flooding attacks by mutual authentication.  This
   demonstrates that the application is connected to the same peer, but
   does not identify the peer.  Datagram Transport Layer Security
   [RFC5238] can be used to prevent eavesdropping, tampering, or message
   forgery.  Alternatively, DCCP can run over IPsec.

3.4.  Infrastructure

3.4.1.  Domain Name System

   In order to facilitate network management and operations, the
   Internet community has defined the Domain Name System (DNS) [RFC1034]
   [RFC1035].  Names are hierarchical: a name like example.com is found
   registered with a .com registrar, and within the associated network
   other names like baldur.cincinatti.example.com can be defined, with
   obvious hierarchy.  Security extensions, which allow a registry to
   sign the records it contains and in so doing demonstrate their
   authenticity, are defined by the DNS Security Extensions [RFC4033]
   [RFC4034] [RFC4035].

   Devices can also optionally update their own DNS record.  For
   example, a sensor that is using Stateless Address Autoconfiguration
   [RFC4862] to create an address might want to associate it with a name
   using DNS Dynamic Update [RFC2136] or DNS Secure Dynamic Update
   [RFC3007].

3.4.2.  Dynamic Host Configuration

   As discussed in Section 3.2.2, IPv4 address assignment is generally
   performed using DHCP [RFC2131].  By contrast, Section 3.2.3 points
   out that IPv6 address assignment can be accomplished using either
   autoconfiguration [RFC4862] [RFC4941] or DHCPv6 [RFC3315].  The best
   argument for the use of autoconfiguration is a large number of
   systems that require little more than a random number as an address;
   the argument for DHCP is administrative control.

   There are other parameters that may need to be allocated to hosts
   requiring administrative configuration; examples include the
   addresses of DNS servers, keys for Secure DNS, and Network Time
   servers.

3.4.3.  Network Time

   The Network Time Protocol was originally designed by Dave Mills of
   the University of Delaware and CSNET, implementing a temporal metric
   in the Fuzzball Routing Protocol and generally coordinating time
   experiments.  The current versions of the time protocol are the
   Network Time Protocol [RFC5905].

3.5.  Network Management

   The IETF has developed two protocols for network management: SNMP and
   NETCONF.  SNMP is discussed in Section 3.5.1, and NETCONF is
   discussed in Section 3.5.2.

3.5.1.  Simple Network Management Protocol (SNMP)

   The Simple Network Management Protocol, originally specified in the
   late 1980's and having passed through several revisions, is specified
   in several documents:

   o  An Architecture for Describing Simple Network Management Protocol
      (SNMP) Management Frameworks [RFC3411]

   o  Message Processing and Dispatching [RFC3412]

   o  SNMP Applications [RFC3413]

   o  User-based Security Model (USM) for SNMP version 3 [RFC3414]

   o  View-based Access Control Model (VACM) [RFC3415]

   o  Version 2 of the SNMP Protocol Operations [RFC3416]

   o  Transport Mappings [RFC3417]

   o  Management Information Base (MIB) [RFC3418]

   It provides capabilities for polled and event-driven activities, and
   for both monitoring and configuration of systems in the field.
   Historically, it has been used primarily for monitoring nodes in a
   network.  Messages and their constituent data are encoded using a
   profile of ASN.1.

3.5.2.  Network Configuration (NETCONF) Protocol

   The NETCONF Configuration Protocol is specified in one basic
   document, with supporting documents for carrying it over the IPS.
   These documents include:

   o  NETCONF Configuration Protocol [RFC4741]

   o  Using the NETCONF Configuration Protocol over Secure SHell (SSH)
      [RFC4742]

   o  Using NETCONF over the Simple Object Access Protocol (SOAP)
      [RFC4743]

   o  Using the NETCONF Protocol over the Blocks Extensible Exchange
      Protocol (BEEP) [RFC4744]

   o  NETCONF Event Notifications [RFC5277]

   o  NETCONF over Transport Layer Security (TLS) [RFC5539]

   o  Partial Lock Remote Procedure Call (RPC) for NETCONF [RFC5717]

   NETCONF was developed in response to operator requests for a common
   configuration protocol based on ASCII text, unlike ASN.1.  In
   essence, it carries XML-encoded remote procedure call (RPC) data.  In
   response to Smart Grid requirements, there is consideration of a
   variant of the protocol that could be used for polled and event-
   driven management activities, and for both monitoring and
   configuration of systems in the field.

3.6.  Service and Resource Discovery

   Service and resource discovery are among the most important protocols
   for constrained resource self-organizing networks.  These include
   various sensor networks as well as the Home Area Networks (HANs),
   Building Area Networks (BANs), and Field Area Networks (FANs)
   envisioned by Smart Grid architects.

3.6.1.  Service Discovery

   Service discovery protocols are designed for the automatic
   configuration and detection of devices, and the services offered by
   the discovered devices.  In many cases service discovery is performed
   by so-called "constrained resource" devices (i.e., those with limited
   processing power, memory, and power resources).

   In general, service discovery is concerned with the resolution and
   distribution of host names via multicast DNS [MULTICAST-DNS] and the
   automatic location of network services via DHCP (Section 3.4.2), the
   DNS Service Discovery (DNS-SD) [DNS-SD] (part of Apple's Bonjour
   technology), and the Service Location Protocol (SLP) [RFC2608].

3.6.2.  Resource Discovery

   Resource Discovery is concerned with the discovery of resources
   offered by end-points and is extremely important in machine-to-
   machine closed-loop applications (i.e., those with no humans in the
   loop).  The goals of resource discovery protocols include:

   o  Simplicity of creation and maintenance of resources

   o  Commonly understood semantics

   o  Conformance to existing and emerging standards

   o  International scope and applicability

   o  Extensibility

   o  Interoperability among collections and indexing systems

   The Constrained Application Protocol (CoAP) [COAP] is being developed
   in IETF with these goals in mind.  In particular, CoAP is designed
   for use in constrained resource networks and for machine-to-machine
   applications such as smart energy and building automation.  It
   provides a RESTful transfer protocol [RESTFUL], a built-in resource
   discovery protocol, and includes web concepts such as URIs and
   content-types.  CoAP provides both unicast and multicast resource

   discovery and includes the ability to filter on attributes of
   resource descriptions.  Finally, CoAP resource discovery can also be
   used to discover HTTP resources.

   For simplicity, CoAP makes the assumption that all CoAP servers
   listen on the default CoAP port or otherwise have been configured or
   discovered using some general service discovery mechanism such as DNS
   Service Discovery (DNS-SD) [DNS-SD].

   Resource discovery in CoAP is accomplished through the use of well-
   known resources that describe the links offered by a CoAP server.
   CoAP defines a well-known URI for discovery: "/.well-known/r"
   [RFC5785].  For example, the query [GET /.well-known/r] returns a
   list of links (representing resources) available from the queried
   CoAP server.  A query such as [GET /.well-known/r?n=Voltage] returns
   the resources with the name Voltage.

3.7.  Other Applications

   There are many applications that rely on the IP infrastructure, but
   are not properly thought of as part of the IP infrastructure itself.
   These applications may be useful in the context of the Smart Grid.
   The choices made when constructing a profile of the Internet Profile
   Suite may impact how such applications could be used.  Some of them,
   not by any means an exhaustive list, are discussed here.

3.7.1.  Session Initiation Protocol

   The Session Initiation Protocol [RFC3261] [RFC3265] [RFC3853]
   [RFC4320] [RFC4916] [RFC5393] [RFC5621] is an application layer
   control (signaling) protocol for creating, modifying, and terminating
   multimedia sessions on the Internet, and is meant to be more scalable
   than H.323.  Multimedia sessions can be voice, video, instant
   messaging, shared data, and/or subscriptions of events.  SIP can run
   on top of TCP, UDP, SCTP, or TLS over TCP.  SIP is independent of the
   transport layer, and independent of the underlying IPv4/v6 version.
   In fact, the transport protocol used can change as the SIP message
   traverses SIP entities from source to destination.

   SIP itself does not choose whether a session is voice or video, nor
   does it identify the actual endpoints' IP addresses.  The Session
   Description Protocol (SDP) [RFC4566] is intended for those purposes.
   Within the SDP, which is transported by SIP, codecs are offered and
   accepted (or not), and the port number and IP address at which each
   endpoint wants to receive their Real-time Transport Protocol (RTP)
   [RFC3550] packets are determined.  The introduction of Network
   Address Translation (NAT) technology into the profile, whether IPv4/

   IPv4, IPv4/IPv6 as described in Section 3.2.1.3, or IPv6/IPv6,
   increases the complexity of SIP/SDP deployment.  This is further
   discussed in [RFC2993] and [RFC5626].

3.7.2.  Extensible Messaging and Presence Protocol

   The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is a
   protocol for streaming Extensible Markup Language (XML) elements in
   order to exchange structured information in close to real time
   between any two network endpoints.  Since XMPP provides a
   generalized, extensible framework for exchanging XML data, it has
   been proposed as an application structure for interchange between
   embedded devices and sensors.  It is currently used for Instant
   Messaging and Presence [RFC6121] and a wide variety of real-time
   communication modes.  These include multi-user chat, publish-
   subscribe, alerts and notifications, service discovery, multimedia
   session management, device configuration, and remote procedure calls.
   XMPP supports channel encryption using TLS [RFC5246] and strong
   authentication (including PKIX certificate authentication) using SASL
   [RFC4422].  It also makes use of Unicode-compliant addresses and
   UTF-8 [RFC3629] data exchange for internationalization.

   XMPP allows for End-to-End Signing and Object Encryption [RFC3923],
   access to objects named using Uniform Resource Names (URN) [RFC4854],
   use of Internationalized Resource Identifiers (IRIs) and Uniform
   Resource Identifiers (URIs) [RFC5122], and the presentation of
   Notifications [RFC5437].

3.7.3.  Calendaring

   Internet calendaring, as implemented in Apple iCal, Microsoft Outlook
   and Entourage, and Google Calendar, is specified in Internet
   Calendaring and Scheduling Core Object Specification (iCalendar)
   [RFC5545] and is in the process of being updated to an XML schema in
   iCalendar XML Representation [xCAL].  Several protocols exist to
   carry calendar events, including the iCalendar Transport-Independent
   Interoperability Protocol (iTIP) [RFC5546], the iCalendar Message-
   Based Interoperability Protocol (iMIP) [RFC6047], and open source
   work on the Atom Publishing Protocol [RFC5023].