Subject: [smartpower-interest] Diff: draft-baker-ietf-core-07.txt - sg-ietf-compendium.txt

From: Fred Baker <[email-masked]>
Date: Mon, 25 Oct 2010 11:53:11 -0700

On Oct 25, 2010, at 11:29 AM, IETF I-D Submission Tool wrote:

> 
> A new version of I-D, draft-baker-ietf-core-09.txt has been successfully submitted by Fred Baker and posted to the IETF repository.
> 
> Filename:	 draft-baker-ietf-core
> Revision:	 09
> Title:		 Internet Protocols for the Smart Grid
> Creation_date:	 2010-10-25
> WG ID:		 Independent Submission
> Number_of_pages: 57
> 
> Abstract:
> This note identifies the key protocols of the Internet Protocol Suite
> for use in the Smart Grid.  The target audience is those people
> seeking guidance on how to construct an appropriate Internet Protocol
> Suite profile for the Smart Grid.  In practice, such a profile would
> consist of selecting what is needed for Smart Grid deployment from
> the picture presented here.

< draft-baker-ietf-core-07.txt 		 sg-ietf-compendium.txt 	
 		
Network Working Group                                           F. Baker	 	Network Working Group                                           F. Baker	
Internet-Draft                                                  D. Meyer	 	Internet-Draft                                                  D. Meyer	
Intended status: Informational                             Cisco Systems	 	Intended status: Informational                             Cisco Systems	
Expires: February 18, 2011                               August 17, 2010	 	Expires: April 28, 2011                                 October 25, 2010	
 		
                 Internet Protocols for the Smart Grid	 	                 Internet Protocols for the Smart Grid	
                        draft-baker-ietf-core-07	 	                        draft-baker-ietf-core-09	
 		
Abstract	 	Abstract	
 		
   This note identifies the key protocols of the Internet Protocol Suite	 	   This note identifies the key protocols of the Internet Protocol Suite	
   for use in the Smart Grid.  The target audience is those people	 	   for use in the Smart Grid.  The target audience is those people	
   seeking guidance on how to construct an appropriate Internet Protocol	 	   seeking guidance on how to construct an appropriate Internet Protocol	
   Suite profile for the Smart Grid.  In practice, such a profile would	 	   Suite profile for the Smart Grid.  In practice, such a profile would	
   consist of selecting what is needed for Smart Grid deployment from	 	   consist of selecting what is needed for Smart Grid deployment from	
   the picture presented here.	 	   the picture presented here.	

skipping to change at page 1, line 35		skipping to change at page 1, line 35	
   Internet-Drafts are working documents of the Internet Engineering	 	   Internet-Drafts are working documents of the Internet Engineering	
   Task Force (IETF).  Note that other groups may also distribute	 	   Task Force (IETF).  Note that other groups may also distribute	
   working documents as Internet-Drafts.  The list of current Internet-	 	   working documents as Internet-Drafts.  The list of current Internet-	
   Drafts is at http://datatracker.ietf.org/drafts/current/.	 	   Drafts is at http://datatracker.ietf.org/drafts/current/.	
 		
   Internet-Drafts are draft documents valid for a maximum of six months	 	   Internet-Drafts are draft documents valid for a maximum of six months	
   and may be updated, replaced, or obsoleted by other documents at any	 	   and may be updated, replaced, or obsoleted by other documents at any	
   time.  It is inappropriate to use Internet-Drafts as reference	 	   time.  It is inappropriate to use Internet-Drafts as reference	
   material or to cite them other than as "work in progress."	 	   material or to cite them other than as "work in progress."	
 		
   This Internet-Draft will expire on February 18, 2011.	 	   This Internet-Draft will expire on April 28, 2011.	
 		
Copyright Notice	 	Copyright Notice	
 		
   Copyright (c) 2010 IETF Trust and the persons identified as the	 	   Copyright (c) 2010 IETF Trust and the persons identified as the	
   document authors.  All rights reserved.	 	   document authors.  All rights reserved.	
 		
   This document is subject to BCP 78 and the IETF Trust's Legal	 	   This document is subject to BCP 78 and the IETF Trust's Legal	
   Provisions Relating to IETF Documents	 	   Provisions Relating to IETF Documents	
   (http://trustee.ietf.org/license-info) in effect on the date of	 	   (http://trustee.ietf.org/license-info) in effect on the date of	
   publication of this document.  Please review these documents	 	   publication of this document.  Please review these documents	
 		
skipping to change at page 2, line 19		skipping to change at page 2, line 19	
   2.  The Internet Protocol Suite  . . . . . . . . . . . . . . . . .  5	 	   2.  The Internet Protocol Suite  . . . . . . . . . . . . . . . . .  5	
     2.1.  Internet Protocol Layers . . . . . . . . . . . . . . . . .  5	 	     2.1.  Internet Protocol Layers . . . . . . . . . . . . . . . . .  5	
       2.1.1.  Application  . . . . . . . . . . . . . . . . . . . . .  6	 	       2.1.1.  Application  . . . . . . . . . . . . . . . . . . . . .  6	
       2.1.2.  Transport  . . . . . . . . . . . . . . . . . . . . . .  7	 	       2.1.2.  Transport  . . . . . . . . . . . . . . . . . . . . . .  7	
       2.1.3.  Network  . . . . . . . . . . . . . . . . . . . . . . .  7	 	       2.1.3.  Network  . . . . . . . . . . . . . . . . . . . . . . .  7	
         2.1.3.1.  Internet Protocol  . . . . . . . . . . . . . . . .  8	 	         2.1.3.1.  Internet Protocol  . . . . . . . . . . . . . . . .  8	
         2.1.3.2.  Lower layer networks . . . . . . . . . . . . . . .  8	 	         2.1.3.2.  Lower layer networks . . . . . . . . . . . . . . .  8	
       2.1.4.  Media layers: Physical and Link  . . . . . . . . . . .  8	 	       2.1.4.  Media layers: Physical and Link  . . . . . . . . . . .  8	
     2.2.  Security issues  . . . . . . . . . . . . . . . . . . . . .  8	 	     2.2.  Security issues  . . . . . . . . . . . . . . . . . . . . .  8	
       2.2.1.  Physical security  . . . . . . . . . . . . . . . . . .  9	 	       2.2.1.  Physical security  . . . . . . . . . . . . . . . . . .  9	
       2.2.2.  Session identification . . . . . . . . . . . . . . . .  9	 	       2.2.2.  Session Authentication . . . . . . . . . . . . . . . .  9	
       2.2.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . 10	 	       2.2.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . 10	
     2.3.  Network Infrastructure . . . . . . . . . . . . . . . . . . 11	 	     2.3.  Network Infrastructure . . . . . . . . . . . . . . . . . . 11	
       2.3.1.  Domain Name System (DNS) . . . . . . . . . . . . . . . 11	 	       2.3.1.  Domain Name System (DNS) . . . . . . . . . . . . . . . 11	
       2.3.2.  Network Management . . . . . . . . . . . . . . . . . . 11	 	       2.3.2.  Network Management . . . . . . . . . . . . . . . . . . 11	
   3.  Specific protocols . . . . . . . . . . . . . . . . . . . . . . 11	 	   3.  Specific protocols . . . . . . . . . . . . . . . . . . . . . . 11	
     3.1.  Security solutions . . . . . . . . . . . . . . . . . . . . 12	 	     3.1.  Security solutions . . . . . . . . . . . . . . . . . . . . 12	
       3.1.1.  Session identification, authentication,	 	       3.1.1.  Session identification, authentication,	
               authorization, and accounting  . . . . . . . . . . . . 12	 	               authorization, and accounting  . . . . . . . . . . . . 12	
       3.1.2.  IP Security Architecture (IPsec) . . . . . . . . . . . 12	 	       3.1.2.  IP Security Architecture (IPsec) . . . . . . . . . . . 12	
       3.1.3.  Transport Layer Security (TLS) . . . . . . . . . . . . 12	 	       3.1.3.  Transport Layer Security (TLS) . . . . . . . . . . . . 13	
       3.1.4.  Secure/Multipurpose Internet Mail Extensions	 	       3.1.4.  Secure/Multipurpose Internet Mail Extensions	
               (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 13	 	               (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 14	
     3.2.  Network Layer  . . . . . . . . . . . . . . . . . . . . . . 13	 	     3.2.  Network Layer  . . . . . . . . . . . . . . . . . . . . . . 14	
       3.2.1.  IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 13	 	       3.2.1.  IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 14	
         3.2.1.1.  Dual Stack Coexistence . . . . . . . . . . . . . . 14	 	         3.2.1.1.  Dual Stack Coexistence . . . . . . . . . . . . . . 14	
         3.2.1.2.  Tunneling Mechanism  . . . . . . . . . . . . . . . 14	 	         3.2.1.2.  Tunneling Mechanism  . . . . . . . . . . . . . . . 15	
         3.2.1.3.  Translation between IPv4 and IPv6 Networks . . . . 14	 	         3.2.1.3.  Translation between IPv4 and IPv6 Networks . . . . 15	
       3.2.2.  Internet Protocol Version 4  . . . . . . . . . . . . . 15	 	       3.2.2.  Internet Protocol Version 4  . . . . . . . . . . . . . 16	
         3.2.2.1.  IPv4 Address Allocation and Assignment . . . . . . 16	 	         3.2.2.1.  IPv4 Address Allocation and Assignment . . . . . . 17	
         3.2.2.2.  IPv4 Unicast Routing . . . . . . . . . . . . . . . 16	 	         3.2.2.2.  IPv4 Unicast Routing . . . . . . . . . . . . . . . 17	
         3.2.2.3.  IPv4 Multicast Forwarding and Routing  . . . . . . 16	 	         3.2.2.3.  IPv4 Multicast Forwarding and Routing  . . . . . . 17	
       3.2.3.  Internet Protocol Version 6  . . . . . . . . . . . . . 17	 	       3.2.3.  Internet Protocol Version 6  . . . . . . . . . . . . . 18	
         3.2.3.1.  IPv6 Address Allocation and Assignment . . . . . . 17	 	         3.2.3.1.  IPv6 Address Allocation and Assignment . . . . . . 18	
         3.2.3.2.  IPv6 Routing . . . . . . . . . . . . . . . . . . . 18	 	         3.2.3.2.  IPv6 Routing . . . . . . . . . . . . . . . . . . . 19	
       3.2.4.  Routing for IPv4 and IPv6  . . . . . . . . . . . . . . 18	 	       3.2.4.  Routing for IPv4 and IPv6  . . . . . . . . . . . . . . 19	
         3.2.4.1.  Routing Information Protocol . . . . . . . . . . . 18	 	         3.2.4.1.  Routing Information Protocol . . . . . . . . . . . 19	
         3.2.4.2.  Open Shortest Path First . . . . . . . . . . . . . 19	 	         3.2.4.2.  Open Shortest Path First . . . . . . . . . . . . . 19	
         3.2.4.3.  ISO Intermediate System to Intermediate System . . 19	 	         3.2.4.3.  ISO Intermediate System to Intermediate System . . 20	
         3.2.4.4.  Border Gateway Protocol  . . . . . . . . . . . . . 19	 	         3.2.4.4.  Border Gateway Protocol  . . . . . . . . . . . . . 20	
         3.2.4.5.  Dynamic MANET On-demand (DYMO) Routing . . . . . . 20	 	         3.2.4.5.  Dynamic MANET On-demand (DYMO) Routing . . . . . . 20	
         3.2.4.6.  Optimized Link State Routing Protocol  . . . . . . 20	 	         3.2.4.6.  Optimized Link State Routing Protocol  . . . . . . 21	
         3.2.4.7.  Routing for Low power and Lossy Networks . . . . . 20	 	         3.2.4.7.  Routing for Low power and Lossy Networks . . . . . 21	
       3.2.5.  IPv6 Multicast Forwarding and Routing  . . . . . . . . 20	 	       3.2.5.  IPv6 Multicast Forwarding and Routing  . . . . . . . . 22	
         3.2.5.1.  Protocol-Independent Multicast Routing . . . . . . 21	 	         3.2.5.1.  Protocol-Independent Multicast Routing . . . . . . 22	
       3.2.6.  Adaptation to lower layer networks and link layer	 	       3.2.6.  Adaptation to lower layer networks and link layer	
               protocols  . . . . . . . . . . . . . . . . . . . . . . 21	 	               protocols  . . . . . . . . . . . . . . . . . . . . . . 23	
     3.3.  Transport Layer  . . . . . . . . . . . . . . . . . . . . . 22	 	     3.3.  Transport Layer  . . . . . . . . . . . . . . . . . . . . . 23	
       3.3.1.  User Datagram Protocol (UDP) . . . . . . . . . . . . . 22	 	       3.3.1.  User Datagram Protocol (UDP) . . . . . . . . . . . . . 23	
       3.3.2.  Transmission Control Protocol (TCP)  . . . . . . . . . 22	 	       3.3.2.  Transmission Control Protocol (TCP)  . . . . . . . . . 24	
       3.3.3.  Stream Control Transmission Protocol (SCTP)  . . . . . 23	 	       3.3.3.  Stream Control Transmission Protocol (SCTP)  . . . . . 24	
       3.3.4.  Datagram Congestion Control Protocol (DCCP)  . . . . . 23	 	       3.3.4.  Datagram Congestion Control Protocol (DCCP)  . . . . . 25	
     3.4.  Infrastructure . . . . . . . . . . . . . . . . . . . . . . 24	 	     3.4.  Infrastructure . . . . . . . . . . . . . . . . . . . . . . 25	
       3.4.1.  Domain Name System . . . . . . . . . . . . . . . . . . 24	 	       3.4.1.  Domain Name System . . . . . . . . . . . . . . . . . . 25	
       3.4.2.  Dynamic Host Configuration . . . . . . . . . . . . . . 24	 	       3.4.2.  Dynamic Host Configuration . . . . . . . . . . . . . . 26	
     3.5.  Service and Resource Discovery . . . . . . . . . . . . . . 24	 	       3.4.3.  Network Time . . . . . . . . . . . . . . . . . . . . . 26	
       3.5.1.  Service Discovery  . . . . . . . . . . . . . . . . . . 24	 	     3.5.  Network Management . . . . . . . . . . . . . . . . . . . . 26	
       3.5.2.  Resource     Discovery . . . . . . . . . . . . . . . . 25	 	       3.5.1.  Simple Network Management Protocol (SNMP)  . . . . . . 26	
     3.6.  Other Applications . . . . . . . . . . . . . . . . . . . . 26	 	       3.5.2.  Network Configuration (NETCONF) Protocol . . . . . . . 27	
       3.6.1.  Network Time . . . . . . . . . . . . . . . . . . . . . 26	 	     3.6.  Service and Resource Discovery . . . . . . . . . . . . . . 28	
       3.6.2.  Session Initiation Protocol  . . . . . . . . . . . . . 26	 	       3.6.1.  Service Discovery  . . . . . . . . . . . . . . . . . . 28	
       3.6.3.  Calendaring  . . . . . . . . . . . . . . . . . . . . . 27	 	       3.6.2.  Resource Discovery . . . . . . . . . . . . . . . . . . 28	
   4.  A simplified view of the business architecture . . . . . . . . 27	 	     3.7.  Other Applications . . . . . . . . . . . . . . . . . . . . 29	
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31	 	       3.7.1.  Session Initiation Protocol  . . . . . . . . . . . . . 29	
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 32	 	       3.7.2.  Calendaring  . . . . . . . . . . . . . . . . . . . . . 30	
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32	 	   4.  A simplified view of the business architecture . . . . . . . . 30	
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32	 	   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34	
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 32	 	   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 35	
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 32	 	   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35	
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44	 	   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 35	
 	     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 35	
 	     8.2.  Informative References . . . . . . . . . . . . . . . . . . 35	
 	   Appendix A.  Example: Advanced Metering Infrastructure . . . . . . 49	
 	     A.1.  How to structure a network . . . . . . . . . . . . . . . . 51	
 	       A.1.1.  HAN Routing  . . . . . . . . . . . . . . . . . . . . . 53	
 	       A.1.2.  HAN Security . . . . . . . . . . . . . . . . . . . . . 53	
 	     A.2.  Model 1: AMI with separated domains  . . . . . . . . . . . 54	
 	     A.3.  Model 2: AMI with neighborhood access to the home  . . . . 55	
 	     A.4.  Model 3: Collector is an IP router . . . . . . . . . . . . 56	
 	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57	
 		
1.  Introduction	 	1.  Introduction	
 		
   This document provides Smart Grid designers with advice on how to	 	   This document provides Smart Grid designers with advice on how to	
   best "profile" the Internet Protocol Suite (IPS) for use on with	 	   best "profile" the Internet Protocol Suite (IPS) for use on with	
   Smart Grids.  It provides an overview of the IPS and the key	 	   Smart Grids.  It provides an overview of the IPS and the key	
   protocols that are critical in integrating Smart Grid devices into an	 	   protocols that are critical in integrating Smart Grid devices into an	
   IP-based infrastructure.	 	   IP-based infrastructure.	
 		
   The IPS provides options for several key architectural components.	 	   The IPS provides options for several key architectural components.	
 		
skipping to change at page 4, line 45		skipping to change at page 4, line 45	
 		
   o  IPv6 Node Requirements [RFC4294],	 	   o  IPv6 Node Requirements [RFC4294],	
 		
   At this writing, RFC 4294 is in the process of being updated, in	 	   At this writing, RFC 4294 is in the process of being updated, in	
   [I-D.ietf-6man-node-req-bis].	 	   [I-D.ietf-6man-node-req-bis].	
 		
   This document is intended to provide Smart Grid architects and	 	   This document is intended to provide Smart Grid architects and	
   designers with a compendium of relevant RFCs (and to some extent	 	   designers with a compendium of relevant RFCs (and to some extent	
   Internet Drafts), and is organized as an annotated list of RFCs.  To	 	   Internet Drafts), and is organized as an annotated list of RFCs.  To	
   that end, the remainder of this document is organized as follows:	 	   that end, the remainder of this document is organized as follows:	
   Section 2 describes the Internet Architecture and its protocol suite.	 	                                                                         	
   Section 3 outlines the set of protocols that will be useful in Smart	 	   o  Section 2 describes the Internet Architecture and its protocol	
   Grid deployment.  Finally, Section 4 provides an overview of the	 	      suite.	
   business architecture embodied in the design and deployment of the	 	                                                                         	
   IPS.	 	   o  Section 3 outlines the set of protocols that will be useful in	
 	      Smart Grid deployment.	
 	                                                                         	
 	   o  Finally, Section 4 provides an overview of the business	
 	      architecture embodied in the design and deployment of the IPS.	
 		
2.  The Internet Protocol Suite	 	2.  The Internet Protocol Suite	
 		
   Before enumerating the list of Internet protocols relevant to Smart	 	   Before enumerating the list of Internet protocols relevant to Smart	
   Grid, we discuss the layered architecture of the IPS, the functions	 	   Grid, we discuss the layered architecture of the IPS, the functions	
   of the various layers, and their associated protocols.	 	   of the various layers, and their associated protocols.	
 		
2.1.  Internet Protocol Layers	 	2.1.  Internet Protocol Layers	
 		
   While Internet architecture uses the definitions and language similar	 	   While Internet architecture uses the definitions and language similar	
 		
skipping to change at page 8, line 49		skipping to change at page 8, line 49	
   At the lowest layer of the IP architecture, data is encoded in	 	   At the lowest layer of the IP architecture, data is encoded in	
   messages and transmitted over the physical media.  While the IETF	 	   messages and transmitted over the physical media.  While the IETF	
   specifies algorithms for carrying IPv4 and IPv6 various media types,	 	   specifies algorithms for carrying IPv4 and IPv6 various media types,	
   it rarely actually defines the media - it happily uses specifications	 	   it rarely actually defines the media - it happily uses specifications	
   from IEEE, ITU, and other sources.	 	   from IEEE, ITU, and other sources.	
 		
2.2.  Security issues	 	2.2.  Security issues	
 		
   While it is popular to complain about the security of the Internet,	 	   While it is popular to complain about the security of the Internet,	
   solutions to many Internet security problems already exist but have	 	   solutions to many Internet security problems already exist but have	
   not been widely deployed.  Internet security solutions attempt to	 	   either not been widely deployed, may impact critical performance	
   mitigate a set of known threats at a specified cost; addressing	 	   criteria, or require security measures outside the IPS.  Internet	
   security issues requires first a threat analysis and assessment and a	 	   security solutions attempt to mitigate a set of known threats within	
   set of mitigations appropriate to the threats.  Since we have threats	 	   the IPS domain at a specified cost; addressing security issues	
   at every layer, we should expect to find mitigations at every layer.	 	   requires first a threat analysis and assessment and a set of	
 	   mitigations appropriate to the threats.  Since we have threats at	
 	   every layer, we should expect to find mitigations at every layer.	
 		
2.2.1.  Physical security	 	2.2.1.  Physical security	
 		
   At the physical and data link layers, threats generally center on	 	   At the physical and data link layers, threats generally center on	
   physical attacks on the network - the effects of backhoes,	 	   physical attacks on the network - the effects of backhoes,	
   deterioration of physical media, and various kinds of environmental	 	   deterioration of physical media, and various kinds of environmental	
   noise.  Radio-based networks are subject to signal fade due to	 	   noise.  Radio-based networks are subject to signal fade due to	
   distance, interference, and environmental factors; it is widely noted	 	   distance, interference, and environmental factors; it is widely noted	
   that IEEE 802.15.4 networks frequently place a metal ground plate	 	   that IEEE 802.15.4 networks frequently place a metal ground plate	
   between the meter and the device that manages it.  Fiber was at one	 	   between the meter and the device that manages it.  Fiber was at one	
 		
skipping to change at page 9, line 26		skipping to change at page 9, line 28	
   learned to tap it by bending the fiber and collecting incidental	 	   learned to tap it by bending the fiber and collecting incidental	
   light, and we have learned about backhoes.  As a result, some	 	   light, and we have learned about backhoes.  As a result, some	
   installations encase fiber optic cable in a pressurized sheath, both	 	   installations encase fiber optic cable in a pressurized sheath, both	
   to quickly identify the location of a cut and to make it more	 	   to quickly identify the location of a cut and to make it more	
   difficult to tap.	 	   difficult to tap.	
 		
   While there are protocol behaviors that can detect certain classes of	 	   While there are protocol behaviors that can detect certain classes of	
   physical faults, such as keep-alive exchanges, physical security is	 	   physical faults, such as keep-alive exchanges, physical security is	
   generally not considered to be a protocol problem.	 	   generally not considered to be a protocol problem.	
 		
2.2.2.  Session identification	 	2.2.2.  Session Authentication	
 		
   At the transport and application layers and in lower layer networks	 	   At the transport and application layers and in lower layer networks	
   where dynamic connectivity such as ATM Switched Virtual Circuits	 	   where dynamic connectivity such as ATM Switched Virtual Circuits	
   (SVCs) or "dial" connectivity are in use, there tend to be several	 	   (SVCs) or "dial" connectivity are in use, there tend to be several	
   different classes of authentication/authorization requirements.  The	 	   different classes of authentication/authorization requirements.  The	
   basic requirements that must be satisfied are:	 	   basic requirements that must be satisfied are:	
 		
   1.  Verify that peers are appropriate partners; this generally means	 	   1.  Verify that peers are appropriate partners; this generally means	
       knowing "who" they are and that they have a "need to know" or are	 	       knowing "who" they are and that they have a "need to know" or are	
       trusted sources.	 	       trusted sources.	
 		
skipping to change at page 10, line 9		skipping to change at page 10, line 11	
       against modification attacks.	 	       against modification attacks.	
 		
   In other words, both the communications channel itself and message	 	   In other words, both the communications channel itself and message	
   exchanges (both by knowing the source of the information and to have	 	   exchanges (both by knowing the source of the information and to have	
   proof of its validity) must be secured.  Three examples suffice to	 	   proof of its validity) must be secured.  Three examples suffice to	
   illustrate the challenges.	 	   illustrate the challenges.	
 		
   One common attack against a TCP session is to bombard the session	 	   One common attack against a TCP session is to bombard the session	
   with reset messages.  Other attacks against TCP include the "SYN	 	   with reset messages.  Other attacks against TCP include the "SYN	
   flooding" attack, in which an attacker attempts to exhaust the memory	 	   flooding" attack, in which an attacker attempts to exhaust the memory	
   of the target by creating TCP state.  Experience has shown that by	 	   of the target by creating TCP state.  In particular, the attacker	
   including information in the transport header or a related protocol	 	   attempts to exhaust the target's memory by opening a large number of	
   like the IPsec (Section 3.1.2) or TLS (Section 3.1.3), a host can	 	   unique TCP connections, each of which is represented by a	
   identify legitimate messages and discard mitigate any damage that may	 	   Transmission Control Block (TCB).  The attack is successful if the	
   have been caused by the attack.	 	   attacker can cause the target to fill its memory with TCBs.	
 	   Experience has shown that by including information in the transport	
 	   header or a related protocol like the IPsec (Section 3.1.2) or TLS	
 	   (Section 3.1.3), a host can identify legitimate messages and discard	
 	   the others, thus mitigating any damage that may have been caused by	
 	   the attack.	
 		
   Another common attack involves unauthorized communication with a	 	   Another common attack involves unauthorized communication with a	
   router or a service.  For example, an unauthorized party might try to	 	   router or a service.  For example, an unauthorized party might try to	
   join the routing system.  To protect against such attacks, an	 	   join the routing system.  To protect against such attacks, an	
   Internet Service Provider (ISP) should not accept information from	 	   Internet Service Provider (ISP) should not accept information from	
   new peers without verifying that the peer is who it claims to be and	 	   new peers without verifying that the peer is who it claims to be and	
   that the peer is authorized to carry on the exchange of information.	 	   that the peer is authorized to carry on the exchange of information.	
 		
   More generally, in order to secure a communications channel, it must	 	   More generally, in order to secure a communications channel, it must	
   be possible to verify that messages putatively received from a peer	 	   be possible to verify that messages putatively received from a peer	
 		
skipping to change at page 11, line 7		skipping to change at page 11, line 11	
   there frequently a requirement for confidentiality.  Confidentiality	 	   there frequently a requirement for confidentiality.  Confidentiality	
   arises at several layers, sometimes simultaneously.  For example,	 	   arises at several layers, sometimes simultaneously.  For example,	
   providers of credit card transaction services want application layer	 	   providers of credit card transaction services want application layer	
   privacy, which can be supplied by encrypting application data or by	 	   privacy, which can be supplied by encrypting application data or by	
   an encrypted transport layer.  If an ISP (or other entity) wants to	 	   an encrypted transport layer.  If an ISP (or other entity) wants to	
   hide its network structure, it can to encrypt the network layer	 	   hide its network structure, it can to encrypt the network layer	
   header.	 	   header.	
 		
2.3.  Network Infrastructure	 	2.3.  Network Infrastructure	
 		
   While these are not critical to the design of a specific system, they	 	   While the following protocols are not critical to the design of a	
   are important to running a network, and as such are surveyed here.	 	   specific system, they are important to running a network, and as such	
 	   are surveyed here.	
 		
2.3.1.  Domain Name System (DNS)	 	2.3.1.  Domain Name System (DNS)	
 		
   The DNS' main function is translating names to numeric IP addresses.	 	   The DNS' main function is translating names to numeric IP addresses.	
   While this is not critical to running a network, certain functions	 	   While this is not critical to running a network, certain functions	
   are made a lot easier if numeric addresses can be replaced with	 	   are made a lot easier if numeric addresses can be replaced with	
   mnemonic names.  This facilitates renumbering of networks and	 	   mnemonic names.  This facilitates renumbering of networks and	
   generally improves the manageability and serviceability of the	 	   generally improves the manageability and serviceability of the	
   network.  DNS has a set of security extensions called DNSSEC, which	 	   network.  DNS has a set of security extensions called DNSSEC, which	
   can be used to provide strong cryptographic authentication to that	 	   can be used to provide strong cryptographic authentication to the	
   protocol.  DNS and DNSSEC are discussed further in Section 3.4.1.	 	   DNS.  DNS and DNSSEC are discussed further in Section 3.4.1.	
 		
2.3.2.  Network Management	 	2.3.2.  Network Management	
 		
   Network management has proven to be a difficult problem.  As such,	 	   Network management has proven to be a difficult problem.  As such,	
   various solutions have been proposed, implemented, and deployed.	 	   various solutions have been proposed, implemented, and deployed.	
   Each solution has its proponents, all of whom have solid arguments	 	   Each solution has its proponents, all of whom have solid arguments	
   for their viewpoints.  The IETF has two major network management	 	   for their viewpoints.  The IETF has two major network management	
   solutions for device operation: SNMP, which is ASN.1-encoded and is	 	   solutions for device operation: SNMP, which is ASN.1-encoded and is	
   primarily used for monitoring of system variables and is a polled	 	   primarily used for monitoring of system variables and is a polled	
   architecture, and NetConf [RFC4741], which is XML-encoded and	 	   architecture, and NetConf [RFC4741], which is XML-encoded and	
 		
skipping to change at page 11, line 47		skipping to change at page 12, line 5	
   While the IP Protocol Suite does not have specific solutions for	 	   While the IP Protocol Suite does not have specific solutions for	
   secure provisioning and configuration, these problems have been	 	   secure provisioning and configuration, these problems have been	
   solved using IP protocols in specifications such as DOCSIS 3.0	 	   solved using IP protocols in specifications such as DOCSIS 3.0	
   [SP-MULPIv3.0].	 	   [SP-MULPIv3.0].	
 		
3.  Specific protocols	 	3.  Specific protocols	
 		
   In this section, having briefly laid out the IP architecture and some	 	   In this section, having briefly laid out the IP architecture and some	
   of the problems that the architecture tries to address, we introduce	 	   of the problems that the architecture tries to address, we introduce	
   specific protocols that might be appropriate to various Smart Grid	 	   specific protocols that might be appropriate to various Smart Grid	
   use cases.  Use cases should be analyzed along privacy, AAA,	 	   use cases.  Use cases should be analyzed along privacy,	
   transport and network solution dimensions.  The following sections	 	   Authentication, Authorization, and Accounting (AAA), transport and	
   provide guidance for such analyzes.	 	   network solution dimensions.  The following sections provide guidance	
 	   for such analyzes.	
 		
3.1.  Security solutions	 	3.1.  Security solutions	
 		
   As noted, a key consideration in security solutions is a good threat	 	   As noted, a key consideration in security solutions is a good threat	
   analysis coupled with appropriate mitigation strategies at each	 	   analysis coupled with appropriate mitigation strategies at each	
   layer.  The following sections outline the security features of the	 	   layer.  The following sections outline the security features of the	
   IPS.	 	   IPS.	
 		
3.1.1.  Session identification, authentication, authorization, and	 	3.1.1.  Session identification, authentication, authorization, and	
        accounting	 	        accounting	
 		
skipping to change at page 12, line 34		skipping to change at page 12, line 39	
 		
   The Security Architecture for the Internet Protocol (IPsec) [RFC4301]	 	   The Security Architecture for the Internet Protocol (IPsec) [RFC4301]	
   is a set of control and data protocols that are implemented between	 	   is a set of control and data protocols that are implemented between	
   IPv4 and the chosen transport layer, or in IPv6's security extension	 	   IPv4 and the chosen transport layer, or in IPv6's security extension	
   header.  It allows transport layer sessions to communicate in a way	 	   header.  It allows transport layer sessions to communicate in a way	
   that is designed to prevent eavesdropping, tampering, or message	 	   that is designed to prevent eavesdropping, tampering, or message	
   forgery.  As is typical with IETF specifications, the architecture is	 	   forgery.  As is typical with IETF specifications, the architecture is	
   spelled out in a number of documents which specify the specific	 	   spelled out in a number of documents which specify the specific	
   components: the IP Authentication Header (AH) [RFC4302] Encapsulating	 	   components: the IP Authentication Header (AH) [RFC4302] Encapsulating	
   Security Payload (ESP) [RFC4303], Internet Key Exchange (IKEv2)	 	   Security Payload (ESP) [RFC4303], Internet Key Exchange (IKEv2)	
   [RFC4306], Cryptographic Algorithms [RFC4307], Cryptographic	 	   [RFC5996], Cryptographic Algorithms [RFC4307], Cryptographic	
   Algorithm Implementation Requirements for ESP and AH [RFC4835], and	 	   Algorithm Implementation Requirements for ESP and AH [RFC4835], and	
   the use of Advanced Encryption Standard (AES) [RFC4309].	 	   the use of Advanced Encryption Standard (AES) [RFC4309].	
 		
   IPsec provides two modes: Transport mode and tunnel mode.  In	 	   IPsec provides two modes: Transport mode and tunnel mode.  In	
   transport mode, IPsec ESP encrypts the transport layer and the	 	   transport mode, IPsec ESP encrypts the transport layer and the	
   application data.  In tunnel mode, the source IP datagram is	 	   application data.  In tunnel mode, the source IP datagram is	
   encrypted and encapsulated in a second IP header addressed to the	 	   encrypted and encapsulated in a second IP header addressed to the	
   intended decryptor.  As might be expected, tunnel mode is frequently	 	   intended decryptor.  As might be expected, tunnel mode is frequently	
   used for virtual private networks which need to securely transmit	 	   used for virtual private networks which need to securely transmit	
   data across networks with unknown (or no) other security properties.	 	   data across networks with unknown (or no) other security properties.	
   In both cases, authentication, authorization, and confidentiality	 	   In both cases, authentication, authorization, and confidentiality	
   extend from system to system, and apply to all applications that the	 	   extend from system to system, and apply to all applications that the	
   two systems use.	 	   two systems use.	
 		
 	   Note that IPsec can provide non-repudiation when an asymmetric	
 	   authentication algorithm is used with the AH header and both sender	
 	   and receiver keys are used in the authentication calculation.	
 	   However, the default authentication algorithm is keyed MD5, which	
 	   like all symmetric algorithms cannot provide non-repudiation by	
 	   itself (since the sender's key is not used in the computation).  So	
 	   while IPsec provides a means of authenticating network level objects	
 	   (packets), these objects are are ephemeral and not directly	
 	   correlated with a particular application.  As a result non-	
 	   repudiation is not generally applicable to network level objects such	
 	   as packets.	
 	                                                                         	
3.1.3.  Transport Layer Security (TLS)	 	3.1.3.  Transport Layer Security (TLS)	
 		
   Transport Layer Security [RFC5246] and Datagram Transport Layer	 	   Transport Layer Security [RFC5246] and Datagram Transport Layer	
   Security [RFC4347][I-D.ietf-tls-rfc4347-bis] are mechanisms that	 	   Security [RFC4347][I-D.ietf-tls-rfc4347-bis] are mechanisms that	
   travel within the transport layer protocol data unit, meaning that	 	   travel within the transport layer protocol data unit, meaning that	
   they readily traverse network address translators and secure the	 	   they readily traverse network address translators and secure the	
   information exchanges without securing the datagrams exchanged or the	 	   information exchanges without securing the datagrams exchanged or the	
   transport layer itself.  Each allows client/server applications to	 	   transport layer itself.  Each allows client/server applications to	
   communicate in a way that is designed to prevent eavesdropping,	 	   communicate in a way that is designed to prevent eavesdropping,	
   tampering, or message forgery.  Authentication, authorization, and	 	   tampering, or message forgery.  Authentication, authorization, and	
   confidentiality exist for a session between specific applications.	 	   confidentiality exist for a session between specific applications.	
 		
   When used in conjunction with IEEE 802.1X [IEEE802.1X], EAP-TLS	 	   In order to communicate securely, an TLS client and TLS server must	
   [RFC5216] is widely considered to offer excellent access security to	 	   agree on the cryptographic algorithms and keys that they will use on	
   a wired or wireless IEEE 802 LAN (IEEE 802.1X in conjunction with	 	   the secured connection.  In particular, they must agree on these	
   EAP-TLS is the baseline for Zigbee SEP 2.0).  Note that one potential	 	   items:	
   drawback of 802.1X technology is that it requires deployment of	 		
   client-side certificates, which is frequently seen as a deployment	 	   o  Key Establishment Algorithm	
   barrier.	 		
 	   o  Peer Authentication Algorithm	
 		
 	   o  Bulk Data Encryption Algorithm and key size	
 		
 	   o  Digest Algorithm	
 		
 	   Since each categories has multiple options, the number of possible	
 	   combinations is large.  As a result, TLS does not allow all possible	
 	   combinations of choices; rather it only allows certain well-defined	
 	   combinations known as Cipher Suites.  [IEC62351-3] outlines the use	
 	   of different TLS Cipher Suites for use in the Smart Grid.	
 	                                                                         	
 	   When used in conjunction with IEEE 802.1X [IEEE802.1X], both EAP-TLS	
 	   [RFC5216] and the Protocol for Carrying Authentication for Network	
 	   Access (PANA) [RFC5193] are widely considered to offer excellent	
 	   access security to a wired or wireless IEEE 802 LAN (IEEE 802.1X in	
 	   conjunction with EAP-TLS is the baseline for Zigbee SEP 2.0).	
 		
3.1.4.  Secure/Multipurpose Internet Mail Extensions (S/MIME)	 	3.1.4.  Secure/Multipurpose Internet Mail Extensions (S/MIME)	
 		
   The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049]	 	   The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049]	
   [RFC5750] [RFC5751] [RFC4262] specification was originally designed	 	   [RFC5750] [RFC5751] [RFC4262] specification was originally designed	
   as an extension to SMTP Mail to provide evidence that the putative	 	   as an extension to SMTP Mail to provide evidence that the putative	
   sender of an email message in fact sent it, and that the content	 	   sender of an email message in fact sent it, and that the content	
   received was in fact the content that was sent.  As its name	 	   received was in fact the content that was sent.  As its name	
   suggests, by extension this is a way of securing any object that can	 	   suggests, by extension this is a way of securing any object that can	
   be exchanged, by any means, and has become one of the most common	 	   be exchanged, by any means, and has become one of the most common	
 		
skipping to change at page 15, line 19		skipping to change at page 16, line 6	
      [I-D.ietf-behave-address-format]	 	      [I-D.ietf-behave-address-format]	
 		
   o  DNS extensions [I-D.ietf-behave-dns64]	 	   o  DNS extensions [I-D.ietf-behave-dns64]	
 		
   o  IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate]	 	   o  IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate]	
 		
   o  Translation from IPv6 Clients to IPv4 Servers	 	   o  Translation from IPv6 Clients to IPv4 Servers	
      [I-D.ietf-behave-v6v4-xlate-stateful]	 	      [I-D.ietf-behave-v6v4-xlate-stateful]	
 		
   As with IPv4/IPv4 Network Address Translation, translation between	 	   As with IPv4/IPv4 Network Address Translation, translation between	
   IPv4 and IPv6 has limited real world applicability: any application	 	   IPv4 and IPv6 has limited real world applicability for an application	
   protocol that carries IP addresses and expects them to be meaningful	 	   protocol which carry IP addresses in its payload and expects those	
   to both client and server or to both peers will have trouble when the	 	   addresses to be meaningful to both client and server.  However, for	
   addresses are transparently translated.  However, for those protocols	 	   those protocols that do not, protocol translation can provide a	
   that do not, protocol translation can provide a useful network	 	   useful network extension.	
   extension.	 		
 		
   Network-based translation provides for two types of services:	 	   Network-based translation provides for two types of services:	
   stateless (and therefore scalable and load-sharable) translation	 	   stateless (and therefore scalable and load-sharable) translation	
   between IPv4 and IPv6 addresses that embed an IPv4 address in them,	 	   between IPv4 and IPv6 addresses that embed an IPv4 address in them,	
   and stateful translation similar to IPv4/IPv4 translation between	 	   and stateful translation similar to IPv4/IPv4 translation between	
   IPv4 addresses.  The stateless mode is straightforward to implement,	 	   IPv4 addresses.  The stateless mode is straightforward to implement,	
   but due to the embedding, requires IPv4 addresses to be allocated to	 	   but due to the embedding, requires IPv4 addresses to be allocated to	
   an otherwise IPv6-only network, and is primarily useful for IPv4-	 	   an otherwise IPv6-only network, and is primarily useful for IPv4-	
   accessible servers implemented in the IPv6 network.  The stateful	 	   accessible servers implemented in the IPv6 network.  The stateful	
   mode allows clients in the IPv6 network to access servers in the IPv4	 	   mode allows clients in the IPv6 network to access servers in the IPv4	
   network, but does not provide such service for IPv4 clients accessing	 	   network, but does not provide such service for IPv4 clients accessing	
   IPv6 peers or servers with general addresses; it does however have	 	   IPv6 peers or servers with general addresses; it does however have	
   the advantage that it does not require that a unique IPv4 address be	 	   the advantage that it does not require that a unique IPv4 address be	
   embedded in the IPv6 address of hosts using this mechanism.	 	   embedded in the IPv6 address of hosts using this mechanism.	
 		
 	   Finally, note that some networks site networks are IPv6 only while	
 	   some transits 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	 	3.2.2.  Internet Protocol Version 4	
 		
   IPv4 [RFC0791] and the Internet Control Message Protocol [RFC0792]	 	   IPv4 [RFC0791] and the Internet Control Message Protocol [RFC0792]	
   comprise the IPv4 network layer.  IPv4 provides unreliable delivery	 	   comprise the IPv4 network layer.  IPv4 provides unreliable delivery	
   of datagrams.	 	   of datagrams.	
 		
   IPv4 also provides for fragmentation and reassembly of long datagrams	 	   IPv4 also provides for fragmentation and reassembly of long datagrams	
   for transmission through networks with small Maximum Transmission	 	   for transmission through networks with small Maximum Transmission	
   Units (MTU).  The MTU is the largest packet size that can be	 	   Units (MTU).  The MTU is the largest packet size that can be	
   delivered across the network.  In addition, the IPS provides the	 	   delivered across the network.  In addition, the IPS provides the	
 		
skipping to change at page 16, line 15		skipping to change at page 17, line 6	
   IPv4 originally supported an experimental type of service field that	 	   IPv4 originally supported an experimental type of service field that	
   identified eight levels of operational precedence styled after the	 	   identified eight levels of operational precedence styled after the	
   requirements of military telephony, plus three and later four bit	 	   requirements of military telephony, plus three and later four bit	
   flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2	 	   flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2	
   [RFC2328] interpreted as control traffic; this control traffic is	 	   [RFC2328] interpreted as control traffic; this control traffic is	
   assured of not being dropped when queued or upon receipt even if	 	   assured of not being dropped when queued or upon receipt even if	
   other traffic is being dropped..  These control bits turned out to be	 	   other traffic is being dropped..  These control bits turned out to be	
   less useful than the designers had hoped.  They were replaced by the	 	   less useful than the designers had hoped.  They were replaced by the	
   Differentiated Services Architecture [RFC2474][RFC2475], which	 	   Differentiated Services Architecture [RFC2474][RFC2475], which	
   contains a six bit code point used to select an algorithm (a "per-hop	 	   contains a six bit code point used to select an algorithm (a "per-hop	
   behavior") to be applied to the datagram.	 	   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	 	3.2.2.1.  IPv4 Address Allocation and Assignment	
 		
   IPv4 addresses are administratively assigned, usually using automated	 	   IPv4 addresses are administratively assigned, usually using automated	
   methods, and assigned using the Dynamic Host Configuration Protocol	 	   methods, and assigned using the Dynamic Host Configuration Protocol	
   (DHCP) [RFC2131].  On most interface types, neighboring equipment	 	   (DHCP) [RFC2131].  On most interface types, neighboring equipment	
   identify each other's addresses using Address Resolution Protocol	 	   identify each other's addresses using Address Resolution Protocol	
   (ARP) [RFC0826].	 	   (ARP) [RFC0826].	
 		
3.2.2.2.  IPv4 Unicast Routing	 	3.2.2.2.  IPv4 Unicast Routing	
 		
skipping to change at page 20, line 41		skipping to change at page 21, line 32	
   can be used in other forms of ad hoc networks.  It provides arbitrary	 	   can be used in other forms of ad hoc networks.  It provides arbitrary	
   connectivity between device within a distributed subnet.  As with	 	   connectivity between device within a distributed subnet.  As with	
   protocols designed for wired networks, routing is calculated and	 	   protocols designed for wired networks, routing is calculated and	
   maintained whenever changes are detected, and maintained in each	 	   maintained whenever changes are detected, and maintained in each	
   router's tables.  The set of nodes that operate as routers within the	 	   router's tables.  The set of nodes that operate as routers within the	
   subnet, however, are fairly fluid, and dependent on this	 	   subnet, however, are fairly fluid, and dependent on this	
   instantaneous topology of the subnet.	 	   instantaneous topology of the subnet.	
 		
3.2.4.7.  Routing for Low power and Lossy Networks	 	3.2.4.7.  Routing for Low power and Lossy Networks	
 		
   The RPL: IPv6 Routing Protocol for Low power and Lossy Networks	 	   The IPv6 Routing Protocol for Low power and Lossy Networks (RPL)	
   [I-D.ietf-roll-rpl] xxx	 	   [I-D.ietf-roll-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	
 	      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	 	3.2.5.  IPv6 Multicast Forwarding and Routing	
 		
   IPv6 specifies both unicast and multicast datagram exchange.  This	 	   IPv6 specifies both unicast and multicast datagram exchange.  This	
   uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710]	 	   uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710]	
   [RFC3590] [RFC3810] [RFC4604] to enable applications to join	 	   [RFC3590] [RFC3810] [RFC4604] to enable applications to join	
   multicast groups, and for most applications uses Source-Specific	 	   multicast groups, and for most applications uses Source-Specific	
   Multicast [RFC4607] for routing and delivery of multicast messages.	 	   Multicast [RFC4607] for routing and delivery of multicast messages.	
 		
   The mechanisms experimentally developed for reliable multicast in	 	   The mechanisms experimentally developed for reliable multicast in	
   IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well.	 	   IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well.	
 		
3.2.5.1.  Protocol-Independent Multicast Routing	 	3.2.5.1.  Protocol-Independent Multicast Routing	
 		
   xxx Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol	 	   A multicast routing protocol has two basic functions: Building the	
   Specification (Revised) [RFC3973] xxx Protocol Independent Multicast	 	   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.	
 		
 	   A the highest level, 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]	 	   - Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601]	
   xxx Source-Specific Multicast (SSM) [RFC3569] xxx Source-Specific	 	   were designed for the ASM model.	
   Protocol Independent Multicast [RFC4608] xxx Authentication and	 		
   Confidentiality in Protocol Independent Multicast Sparse Mode	 	   Many modern multicast deployments use Source-Specific Multicast (PIM-	
   (PIM-SM) Link-Local Messages [RFC5796] xxx	 	   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 tress are rooted 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 it is the responsibility of the	
 	   receivers (rather than the network) to find the (S,G) channel they	
 	   are interested in receiving.  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	 	3.2.6.  Adaptation to lower layer networks and link layer protocols	
 		
   In general, the layered architecture of the Internet enables the IPS	 	   In general, the layered architecture of the Internet enables the IPS	
   to run over any appropriate layer two architecture.  The ability to	 	   to run over any appropriate layer two architecture.  The ability to	
   change the link or physical layer without having to rethink the	 	   change the link or physical layer without having to rethink the	
   network layer, transports, or applications has been a great benefit	 	   network layer, transports, or applications has been a great benefit	
   in the Internet.	 	   in the Internet.	
 		
   Examples of link layer adaptation technology include:	 	   Examples of link layer adaptation technology include:	
 		
skipping to change at page 24, line 40		skipping to change at page 26, line 25	
   [RFC2131] or DHCPv6 [RFC3315].  The best argument for the use of	 	   [RFC2131] or DHCPv6 [RFC3315].  The best argument for the use of	
   autoconfiguration is a large number of systems that require little	 	   autoconfiguration is a large number of systems that require little	
   more than a random number as an address; the argument for DHCP is	 	   more than a random number as an address; the argument for DHCP is	
   administrative control.	 	   administrative control.	
 		
   There are other parameters that may need to be allocated to hosts	 	   There are other parameters that may need to be allocated to hosts	
   which require administrative configuration; examples include the	 	   which require administrative configuration; examples include the	
   addresses of DNS servers, keys for Secure DNS and Network Time	 	   addresses of DNS servers, keys for Secure DNS and Network Time	
   servers.	 	   servers.	
 		
3.5.  Service and Resource Discovery	 	3.4.3.  Network Time	
 		
 	   The Network Time Protocol was originally designed by Dave Mills of	
 	   the University of Delaware and CSNET, for the purpose of 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 as opposed to 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	 	   Service and resource discovery are among the most important protocols	
   for constrained resource self-organizing networks.  These include	 	   for constrained resource self-organizing networks.  These include	
   various sensor networks as well as the Home Area Networks (HANs),	 	   various sensor networks as well as the Home Area Networks (HANs),	
   Building Area Networks (BANs) and Field Area Networks (FANs)	 	   Building Area Networks (BANs) and Field Area Networks (FANs)	
   envisioned by Smart Grid architects.	 	   envisioned by Smart Grid architects.	
 		
3.5.1.  Service Discovery	 	3.6.1.  Service Discovery	
 		
   Service discovery protocols are designed for the automatic	 	   Service discovery protocols are designed for the automatic	
   configuration and detection of devices, and the services offered by	 	   configuration and detection of devices, and the services offered by	
   the discovered devices.  In many cases service discovery is performed	 	   the discovered devices.  In many cases service discovery is performed	
   by so-called "constrained resource" devices (i.e., those with limited	 	   by so-called "constrained resource" devices (i.e., those with limited	
   processing power, memory, and power resources).	 	   processing power, memory, and power resources).	
 		
   In general, service discovery is concerned with the assignment of	 	   In general, service discovery is concerned with the resolution and	
   network addresses (perhaps via Stateless Address Autoconfiguration	 	   distribution of hostnames via multicast DNS	
   [RFC4862]), resolution and distribution of hostnames via multicast	 	   [I-D.cheshire-dnsext-multicastdns] and the automatic location of	
   DNS [I-D.cheshire-dnsext-multicastdns] and the automatic location of	 		
   network services via DHCP (Section 3.4.2), the DNS Service Discovery	 	   network services via DHCP (Section 3.4.2), the DNS Service Discovery	
   (DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part of Apple's Bonjour	 	   (DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part of Apple's Bonjour	
   technology), and the Service Location Protocol (SLP) [RFC2608].	 	   technology) and the Service Location Protocol (SLP) [RFC2608].	
 		
3.5.2.  Resource     Discovery	 	3.6.2.  Resource Discovery	
 		
   Resource Discovery is concerned with the discovery resources offered	 	   Resource Discovery is concerned with the discovery of resources	
   by end-points and is extremely important in machine-to-machine	 	   offered by end-points and is extremely important in machine-to-	
   closed-loop applications (i.e., those with no humans in the loop).	 	   machine closed-loop applications (i.e., those with no humans in the	
   The goals of resource discover protocols include:	 	   loop).  The goals of resource discover protocols include:	
 		
      Simplicity of creation and maintenance of resources	 	      Simplicity of creation and maintenance of resources	
 		
      Commonly understood semantics	 	      Commonly understood semantics	
 		
      Conformance to existing and emerging standards	 	      Conformance to existing and emerging standards	
 		
      International scope and applicability	 	      International scope and applicability	
 		
      Extensibility	 	      Extensibility	
 		
      Interoperability among collections and indexing systems	 	      Interoperability among collections and indexing systems	
 		
   The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is	 	   The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is	
   being developed in IETF with these goals in mind.  In particular,	 	   being developed in IETF with these goals in mind.  In particular,	
   CoAP is designed for use in constrained resource networks and for	 	   CoAP is designed for use in constrained resource networks and for	
   machine-to-machine applications such as smart energy and building	 	   machine-to-machine applications such as smart energy and building	
   automation.  It provides a RESTful transfer protocol, a built-in	 	   automation.  It provides a RESTful transfer protocol [RESTFUL], a	
   resource discovery protocol, and includes web concepts such as URIs	 	   built-in resource discovery protocol, and includes web concepts such	
   and content-types.  CoAP provides both unicast and multicast resource	 	   as URIs and content-types.  CoAP provides both unicast and multicast	
   discovery and includes the ability to filter on attributes of	 	   resource discovery and includes the ability to filter on attributes	
   resource descriptions.  Finally, CoAP resource discovery can also be	 	   of resource descriptions.  Finally, CoAP resource discovery can also	
   used to discovery HTTP resources.	 	   be used to discovery HTTP resources.	
 		
   For simplicity, CoAP makes the assumption that all CoAP servers	 	   For simplicity, CoAP makes the assumption that all CoAP servers	
   listen on the default CoAP port or otherwise have been configured or	 	   listen on the default CoAP port or otherwise have been configured or	
   discovered using some general service discovery mechanism such as DNS	 	   discovered using some general service discovery mechanism such as DNS	
   Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd].	 	   Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd].	
 		
   Resource discovery in CoAP is accomplished through the use of well-	 	   Resource discovery in CoAP is accomplished through the use of well-	
   known resources which describe the links offered by a CoAP server.	 	   known resources which describe the links offered by a CoAP server.	
   CoAP defines a well-known URI for discovery: "/.well-known/r"	 	   CoAP defines a well-known URI for discovery: "/.well-known/r"	
   [RFC5785].  For example, the query [GET /.well-known/r] returns a	 	   [RFC5785].  For example, the query [GET /.well-known/r] returns a	
   list of links (representing resources) available from the queried	 	   list of links (representing resources) available from the queried	
   CoAP server.  A query such as [GET /.well-known/r?n=Voltage] returns	 	   CoAP server.  A query such as [GET /.well-known/r?n=Voltage] returns	
   the resources with the name Voltage.	 	   the resources with the name Voltage.	
 		
3.6.  Other Applications	 	3.7.  Other Applications	
 		
   There are several applications that are widely used but are not	 	   There are several applications that are widely used but are not	
   properly thought of as infrastructure.	 	   properly thought of as infrastructure.	
 		
3.6.1.  Network Time	 	3.7.1.  Session Initiation Protocol	
 		
   The Network Time Protocol was originally designed by Dave Mills of	 		
   the University of Delaware and CSNET, for the purpose of 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].	 		
 		
   NTP is currently being updated in [RFC5905].	 		
 		
3.6.2.  Session Initiation Protocol	 		
 		
   The Session Initiation Protocol	 	   The Session Initiation Protocol	
   [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is an	 	   [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is an	
   application layer control (signaling) protocol for creating,	 	   application layer control (signaling) protocol for creating,	
   modifying and terminating multimedia sessions on the Internet, meant	 	   modifying and terminating multimedia sessions on the Internet, meant	
   to be more scalable than H.323.  Multimedia sessions can be voice,	 	   to be more scalable than H.323.  Multimedia sessions can be voice,	
   video, instant messaging, shared data, and/or subscriptions of	 	   video, instant messaging, shared data, and/or subscriptions of	
   events.  SIP can run on top of TCP, UDP, SCTP, or TLS over TCP.  SIP	 	   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	 	   is independent of the transport layer, and independent of the	
   underlying IPv4/v6 version.  In fact, the transport protocol used can	 	   underlying IPv4/v6 version.  In fact, the transport protocol used can	
 		
skipping to change at page 27, line 10		skipping to change at page 30, line 11	
   designed to be SDP aware (i.e., looking into each packet far enough	 	   designed to be SDP aware (i.e., looking into each packet far enough	
   to discover what the IP address and port number is for this	 	   to discover what the IP address and port number is for this	
   particular session - and resetting it based on the Session Traversal	 	   particular session - and resetting it based on the Session Traversal	
   Utilities for NAT [RFC5389], the session established by SIP will not	 	   Utilities for NAT [RFC5389], the session established by SIP will not	
   result in RTP packets being sent to the proper endpoint (in SIP	 	   result in RTP packets being sent to the proper endpoint (in SIP	
   called a user agent, or UA).  It should be noted that SIP messaging	 	   called a user agent, or UA).  It should be noted that SIP messaging	
   has no issues with NATs, it is just the UA's inability to generally	 	   has no issues with NATs, it is just the UA's inability to generally	
   learn about the presence of the NATs that prevent the RTP packets	 	   learn about the presence of the NATs that prevent the RTP packets	
   from being received by the UA establishing the session.	 	   from being received by the UA establishing the session.	
 		
3.6.3.  Calendaring	 	3.7.2.  Calendaring	
 		
   Internet calendaring, as implemented in Apple iCal, Microsoft Outlook	 	   Internet calendaring, as implemented in Apple iCal, Microsoft Outlook	
   and Entourage, and Google Calendar, is specified in Internet	 	   and Entourage, and Google Calendar, is specified in Internet	
   Calendaring and Scheduling Core Object Specification (iCalendar)	 	   Calendaring and Scheduling Core Object Specification (iCalendar)	
   [RFC5545] and is in the process of being updated to an XML schema in	 	   [RFC5545] and is in the process of being updated to an XML schema in	
   iCalendar XML Representation [I-D.daboo-et-al-icalendar-in-xml]	 	   iCalendar XML Representation [I-D.daboo-et-al-icalendar-in-xml]	
   Several protocols exist to carry calendar events, including iCalendar	 	   Several protocols exist to carry calendar events, including iCalendar	
   Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the	 	   Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the	
   Message-Based Interoperability Protocol (iMIP) [RFC2447] , and open	 	   Message-Based Interoperability Protocol (iMIP) [RFC2447] , and open	
   source work on the Atom Publishing Protocol [RFC5023].	 	   source work on the Atom Publishing Protocol [RFC5023].	
 		
skipping to change at page 32, line 17		skipping to change at page 35, line 17	
   therefore be removed upon publication as an RFC at the RFC Editor's	 	   therefore be removed upon publication as an RFC at the RFC Editor's	
   discretion.	 	   discretion.	
 		
6.  Security Considerations	 	6.  Security Considerations	
 		
   Security is addressed in some detail in Section 2.2 and Section 3.1.	 	   Security is addressed in some detail in Section 2.2 and Section 3.1.	
 		
7.  Acknowledgements	 	7.  Acknowledgements	
 		
   Review comments were made by Andrew Yourtchenko, Ashok Narayanan,	 	   Review comments were made by Andrew Yourtchenko, Ashok Narayanan,	
   Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, Hemant	 	   Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, Don	
   Singh, James Polk, John Meylor, Joseph Salowey, Julien Abeille, Kerry	 	   Sturek, Francis Cleveland, Hemant Singh, James Polk, John Meylor,	
   Lynn, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman,	 	   Joseph Salowey, Julien Abeille, Kerry Lynn, Magnus Westerlund,	
   Ralph Droms, Russ White, Sheila Frankel, and Toerless Eckert.  Dave	 	   Murtaza Chiba, Paul Duffy, Paul Hoffman, Ralph Droms, Russ White,	
   McGrew, Vint Cerf, and Ralph Droms suggested text.	 	   Sheila Frankel, Tom Herbst, and Toerless Eckert.  Dave McGrew, Vint	
 	   Cerf, and Ralph Droms suggested text.	
 		
8.  References	 	8.  References	
 		
8.1.  Normative References	 	8.1.  Normative References	
 		
   [RFC1122]  Braden, R., "Requirements for Internet Hosts -	 	   [RFC1122]  Braden, R., "Requirements for Internet Hosts -	
              Communication Layers", STD 3, RFC 1122, October 1989.	 	              Communication Layers", STD 3, RFC 1122, October 1989.	
 		
   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application	 	   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application	
              and Support", STD 3, RFC 1123, October 1989.	 	              and Support", STD 3, RFC 1123, October 1989.	
 		
   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",	 	   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",	
              RFC 1812, June 1995.	 	              RFC 1812, June 1995.	
 		
   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,	 	   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,	
              April 2006.	 	              April 2006.	
 		
8.2.  Informative References	 	8.2.  Informative References	
 		
 	   [1822]     Bolt Beranek and Newman Inc., "Interface Message Processor	
 	              -- Specifications for the interconnection of a host and a	
 	              IMP, Report No. 1822", January 1976.	
 	                                                                         	
   [I-D.arkko-ipv6-transition-guidelines]	 	   [I-D.arkko-ipv6-transition-guidelines]	
              Arkko, J. and F. Baker, "Guidelines for Using IPv6	 	              Arkko, J. and F. Baker, "Guidelines for Using IPv6	
              Transition Mechanisms",	 	              Transition Mechanisms during IPv6 Deployment",	
              draft-arkko-ipv6-transition-guidelines-03 (work in	 	              draft-arkko-ipv6-transition-guidelines-06 (work in	
              progress), July 2010.	 	              progress), August 2010.	
 		
   [I-D.cheshire-dnsext-dns-sd]	 	   [I-D.cheshire-dnsext-dns-sd]	
              Cheshire, S. and M. Krochmal, "DNS-Based Service	 	              Cheshire, S. and M. Krochmal, "DNS-Based Service	
              Discovery", draft-cheshire-dnsext-dns-sd-06 (work in	 	              Discovery", draft-cheshire-dnsext-dns-sd-06 (work in	
              progress), March 2010.	 	              progress), March 2010.	
 		
   [I-D.cheshire-dnsext-multicastdns]	 	   [I-D.cheshire-dnsext-multicastdns]	
              Cheshire, S. and M. Krochmal, "Multicast DNS",	 	              Cheshire, S. and M. Krochmal, "Multicast DNS",	
              draft-cheshire-dnsext-multicastdns-11 (work in progress),	 	              draft-cheshire-dnsext-multicastdns-11 (work in progress),	
              March 2010.	 	              March 2010.	
 		
   [I-D.daboo-et-al-icalendar-in-xml]	 	   [I-D.daboo-et-al-icalendar-in-xml]	
              Daboo, C., Douglass, M., and S. Lees, "xCal: The XML	 	              Daboo, C., Douglass, M., and S. Lees, "xCal: The XML	
              format for iCalendar",	 	              format for iCalendar",	
              draft-daboo-et-al-icalendar-in-xml-05 (work in progress),	 	              draft-daboo-et-al-icalendar-in-xml-06 (work in progress),	
              July 2010.	 	              September 2010.	
 		
   [I-D.ietf-6lowpan-hc]	 	   [I-D.ietf-6lowpan-hc]	
              Hui, J. and P. Thubert, "Compression Format for IPv6	 	              Hui, J. and P. Thubert, "Compression Format for IPv6	
              Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-08	 	              Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-12	
              (work in progress), July 2010.	 	              (work in progress), September 2010.	
 		
   [I-D.ietf-6man-node-req-bis]	 	   [I-D.ietf-6man-node-req-bis]	
              Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node	 	              Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node	
              Requirements RFC 4294-bis",	 	              Requirements RFC 4294-bis",	
              draft-ietf-6man-node-req-bis-05 (work in progress),	 	              draft-ietf-6man-node-req-bis-05 (work in progress),	
              July 2010.	 	              July 2010.	
 		
   [I-D.ietf-behave-address-format]	 	   [I-D.ietf-behave-address-format]	
              Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.	 	              Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.	
              Li, "IPv6 Addressing of IPv4/IPv6 Translators",	 	              Li, "IPv6 Addressing of IPv4/IPv6 Translators",	
              draft-ietf-behave-address-format-10 (work in progress),	 	              draft-ietf-behave-address-format-10 (work in progress),	
              August 2010.	 	              August 2010.	
 		
   [I-D.ietf-behave-dns64]	 	   [I-D.ietf-behave-dns64]	
              Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,	 	              Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,	
              "DNS64: DNS extensions for Network Address Translation	 	              "DNS64: DNS extensions for Network Address Translation	
              from IPv6 Clients to IPv4 Servers",	 	              from IPv6 Clients to IPv4 Servers",	
              draft-ietf-behave-dns64-10 (work in progress), July 2010.	 	              draft-ietf-behave-dns64-11 (work in progress),	
 	              October 2010.	
 		
   [I-D.ietf-behave-v6v4-framework]	 	   [I-D.ietf-behave-v6v4-framework]	
              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for	 	              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for	
              IPv4/IPv6 Translation",	 	              IPv4/IPv6 Translation",	
              draft-ietf-behave-v6v4-framework-10 (work in progress),	 	              draft-ietf-behave-v6v4-framework-10 (work in progress),	
              August 2010.	 	              August 2010.	
 		
   [I-D.ietf-behave-v6v4-xlate]	 	   [I-D.ietf-behave-v6v4-xlate]	
              Li, X., Bao, C., and F. Baker, "IP/ICMP Translation	 	              Li, X., Bao, C., and F. Baker, "IP/ICMP Translation	
              Algorithm", draft-ietf-behave-v6v4-xlate-21 (work in	 	              Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in	
              progress), August 2010.	 	              progress), September 2010.	
 		
   [I-D.ietf-behave-v6v4-xlate-stateful]	 	   [I-D.ietf-behave-v6v4-xlate-stateful]	
              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful	 	              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful	
              NAT64: Network Address and Protocol Translation from IPv6	 	              NAT64: Network Address and Protocol Translation from IPv6	
              Clients to IPv4 Servers",	 	              Clients to IPv4 Servers",	
              draft-ietf-behave-v6v4-xlate-stateful-12 (work in	 	              draft-ietf-behave-v6v4-xlate-stateful-12 (work in	
              progress), July 2010.	 	              progress), July 2010.	
 		
   [I-D.ietf-core-coap]	 	   [I-D.ietf-core-coap]	
              Shelby, Z., Frank, B., and D. Sturek, "Constrained	 	              Shelby, Z., Frank, B., and D. Sturek, "Constrained	
              Application Protocol (CoAP)", draft-ietf-core-coap-01	 	              Application Protocol (CoAP)", draft-ietf-core-coap-02	
              (work in progress), July 2010.	 	              (work in progress), September 2010.	
 		
   [I-D.ietf-manet-dymo]	 	   [I-D.ietf-manet-dymo]	
              Chakeres, I. and C. Perkins, "Dynamic MANET On-demand	 	              Chakeres, I. and C. Perkins, "Dynamic MANET On-demand	
              (DYMO) Routing", draft-ietf-manet-dymo-21 (work in	 	              (DYMO) Routing", draft-ietf-manet-dymo-21 (work in	
              progress), July 2010.	 	              progress), July 2010.	
 		
   [I-D.ietf-roll-rpl]	 	   [I-D.ietf-roll-rpl]	
              Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing	 	              Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing	
              Protocol for Low power and Lossy Networks",	 	              Protocol for Low power and Lossy Networks",	
              draft-ietf-roll-rpl-11 (work in progress), July 2010.	 	              draft-ietf-roll-rpl-11 (work in progress), July 2010.	
 		
   [I-D.ietf-tls-rfc4347-bis]	 	   [I-D.ietf-tls-rfc4347-bis]	
              Rescorla, E. and N. Modadugu, "Datagram Transport Layer	 	              Rescorla, E. and N. Modadugu, "Datagram Transport Layer	
              Security version 1.2", draft-ietf-tls-rfc4347-bis-04 (work	 	              Security version 1.2", draft-ietf-tls-rfc4347-bis-04 (work	
              in progress), July 2010.	 	              in progress), July 2010.	
 		
 	   [IEC62351-3]	
 	              International Electrotechnical Commission Technical	
 	              Committee 57, "POWER SYSTEMS MANAGEMENT AND ASSOCIATED	
 	              INFORMATION EXCHANGE. DATA AND COMMUNICATIONS SECURITY --	
 	              Part 3: Communication network and system security Profiles	
 	              including TCP/IP", May 2007.	
 	                                                                         	
   [IEEE802.1X]	 	   [IEEE802.1X]	
              Institute of Electrical and Electronics Engineers, "IEEE	 	              Institute of Electrical and Electronics Engineers, "IEEE	
              Standard for Local and Metropolitan Area Networks - Port	 	              Standard for Local and Metropolitan Area Networks - Port	
              based Network Access Control", IEEE Standard 802.1X-2010,	 	              based Network Access Control", IEEE Standard 802.1X-2010,	
              February 2010.	 	              February 2010.	
 		
 	   [RESTFUL]  Fielding, "Architectural Styles and the Design of Network-	
 	              based Software Architectures", 2000.	
 	                                                                         	
   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,	 	   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,	
              August 1980.	 	              August 1980.	
 		
   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,	 	   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,	
              September 1981.	 	              September 1981.	
 		
   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,	 	   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,	
              RFC 792, September 1981.	 	              RFC 792, September 1981.	
 		
   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,	 	   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,	
 		
skipping to change at page 38, line 37		skipping to change at page 42, line 5	
              March 2002.	 	              March 2002.	
 		
   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,	 	   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,	
              and M. Carney, "Dynamic Host Configuration Protocol for	 	              and M. Carney, "Dynamic Host Configuration Protocol for	
              IPv6 (DHCPv6)", RFC 3315, July 2003.	 	              IPv6 (DHCPv6)", RFC 3315, July 2003.	
 		
   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.	 	   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.	
              Thyagarajan, "Internet Group Management Protocol, Version	 	              Thyagarajan, "Internet Group Management Protocol, Version	
              3", RFC 3376, October 2002.	 	              3", RFC 3376, October 2002.	
 		
 	   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An	
 	              Architecture for Describing Simple Network Management	
 	              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,	
 	              December 2002.	
 		
 	   [RFC3412]  Case, J., Harrington, D., Presuhn, R., and B. Wijnen,	
 	              "Message Processing and Dispatching for the Simple Network	
 	              Management Protocol (SNMP)", STD 62, RFC 3412,	
 	              December 2002.	
 		
 	   [RFC3413]  Levi, D., Meyer, P., and B. Stewart, "Simple Network	
 	              Management Protocol (SNMP) Applications", STD 62,	
 	              RFC 3413, December 2002.	
 		
 	   [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model	
 	              (USM) for version 3 of the Simple Network Management	
 	              Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.	
 		
 	   [RFC3415]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based	
 	              Access Control Model (VACM) for the Simple Network	
 	              Management Protocol (SNMP)", STD 62, RFC 3415,	
 	              December 2002.	
 		
 	   [RFC3416]  Presuhn, R., "Version 2 of the Protocol Operations for the	
 	              Simple Network Management Protocol (SNMP)", STD 62,	
 	              RFC 3416, December 2002.	
 		
 	   [RFC3417]  Presuhn, R., "Transport Mappings for the Simple Network	
 	              Management Protocol (SNMP)", STD 62, RFC 3417,	
 	              December 2002.	
 		
 	   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the	
 	              Simple Network Management Protocol (SNMP)", STD 62,	
 	              RFC 3418, December 2002.	
 	                                                                         	
   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral	 	   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral	
              Self-Address Fixing (UNSAF) Across Network Address	 	              Self-Address Fixing (UNSAF) Across Network Address	
              Translation", RFC 3424, November 2002.	 	              Translation", RFC 3424, November 2002.	
 		
   [RFC3436]  Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport	 	   [RFC3436]  Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport	
              Layer Security over Stream Control Transmission Protocol",	 	              Layer Security over Stream Control Transmission Protocol",	
              RFC 3436, December 2002.	 	              RFC 3436, December 2002.	
 		
   [RFC3453]  Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,	 	   [RFC3453]  Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,	
              M., and J. Crowcroft, "The Use of Forward Error Correction	 	              M., and J. Crowcroft, "The Use of Forward Error Correction	
 		
skipping to change at page 40, line 34		skipping to change at page 44, line 36	
 		
   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the	 	   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the	
              Internet Protocol", RFC 4301, December 2005.	 	              Internet Protocol", RFC 4301, December 2005.	
 		
   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,	 	   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,	
              December 2005.	 	              December 2005.	
 		
   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",	 	   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",	
              RFC 4303, December 2005.	 	              RFC 4303, December 2005.	
 		
   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",	 		
              RFC 4306, December 2005.	 		
                                                                         	 		
   [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the	 	   [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the	
              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,	 	              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,	
              December 2005.	 	              December 2005.	
 		
   [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM	 	   [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM	
              Mode with IPsec Encapsulating Security Payload (ESP)",	 	              Mode with IPsec Encapsulating Security Payload (ESP)",	
              RFC 4309, December 2005.	 	              RFC 4309, December 2005.	
 		
   [RFC4320]  Sparks, R., "Actions Addressing Identified Issues with the	 	   [RFC4320]  Sparks, R., "Actions Addressing Identified Issues with the	
              Session Initiation Protocol's (SIP) Non-INVITE	 	              Session Initiation Protocol's (SIP) Non-INVITE	
 		
skipping to change at page 41, line 23		skipping to change at page 45, line 23	
              Message Protocol (ICMPv6) for the Internet Protocol	 	              Message Protocol (ICMPv6) for the Internet Protocol	
              Version 6 (IPv6) Specification", RFC 4443, March 2006.	 	              Version 6 (IPv6) Specification", RFC 4443, March 2006.	
 		
   [RFC4487]  Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile	 	   [RFC4487]  Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile	
              IPv6 and Firewalls: Problem Statement", RFC 4487,	 	              IPv6 and Firewalls: Problem Statement", RFC 4487,	
              May 2006.	 	              May 2006.	
 		
   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session	 	   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session	
              Description Protocol", RFC 4566, July 2006.	 	              Description Protocol", RFC 4566, July 2006.	
 		
 	   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration	
 	              Guidelines for DiffServ Service Classes", RFC 4594,	
 	              August 2006.	
 	                                                                         	
   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,	 	   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,	
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):	 	              "Protocol Independent Multicast - Sparse Mode (PIM-SM):	
              Protocol Specification (Revised)", RFC 4601, August 2006.	 	              Protocol Specification (Revised)", RFC 4601, August 2006.	
 		
   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet	 	   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet	
              Group Management Protocol Version 3 (IGMPv3) and Multicast	 	              Group Management Protocol Version 3 (IGMPv3) and Multicast	
              Listener Discovery Protocol Version 2 (MLDv2) for Source-	 	              Listener Discovery Protocol Version 2 (MLDv2) for Source-	
              Specific Multicast", RFC 4604, August 2006.	 	              Specific Multicast", RFC 4604, August 2006.	
 		
   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for	 	   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for	
 		
skipping to change at page 41, line 46		skipping to change at page 45, line 50	
              Protocol Independent Multicast in 232/8", BCP 120,	 	              Protocol Independent Multicast in 232/8", BCP 120,	
              RFC 4608, August 2006.	 	              RFC 4608, August 2006.	
 		
   [RFC4614]  Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap	 	   [RFC4614]  Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap	
              for Transmission Control Protocol (TCP) Specification	 	              for Transmission Control Protocol (TCP) Specification	
              Documents", RFC 4614, September 2006.	 	              Documents", RFC 4614, September 2006.	
 		
   [RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,	 	   [RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,	
              December 2006.	 	              December 2006.	
 		
 	   [RFC4742]  Wasserman, M. and T. Goddard, "Using the NETCONF	
 	              Configuration Protocol over Secure SHell (SSH)", RFC 4742,	
 	              December 2006.	
 		
 	   [RFC4743]  Goddard, T., "Using NETCONF over the Simple Object Access	
 	              Protocol (SOAP)", RFC 4743, December 2006.	
 		
 	   [RFC4744]  Lear, E. and K. Crozier, "Using the NETCONF Protocol over	
 	              the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744,	
 	              December 2006.	
 	                                                                         	
   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,	 	   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,	
              "Multiprotocol Extensions for BGP-4", RFC 4760,	 	              "Multiprotocol Extensions for BGP-4", RFC 4760,	
              January 2007.	 	              January 2007.	
 		
   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation	 	   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation	
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,	 	              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,	
              RFC 4787, January 2007.	 	              RFC 4787, January 2007.	
 		
   [RFC4835]  Manral, V., "Cryptographic Algorithm Implementation	 	   [RFC4835]  Manral, V., "Cryptographic Algorithm Implementation	
              Requirements for Encapsulating Security Payload (ESP) and	 	              Requirements for Encapsulating Security Payload (ESP) and	
 		
skipping to change at page 43, line 10		skipping to change at page 47, line 25	
              PPP", RFC 5072, September 2007.	 	              PPP", RFC 5072, September 2007.	
 		
   [RFC5128]  Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-	 	   [RFC5128]  Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-	
              Peer (P2P) Communication across Network Address	 	              Peer (P2P) Communication across Network Address	
              Translators (NATs)", RFC 5128, March 2008.	 	              Translators (NATs)", RFC 5128, March 2008.	
 		
   [RFC5135]  Wing, D. and T. Eckert, "IP Multicast Requirements for a	 	   [RFC5135]  Wing, D. and T. Eckert, "IP Multicast Requirements for a	
              Network Address Translator (NAT) and a Network Address	 	              Network Address Translator (NAT) and a Network Address	
              Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.	 	              Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.	
 		
 	   [RFC5193]  Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and	
 	              A. Yegin, "Protocol for Carrying Authentication for	
 	              Network Access (PANA) Framework", RFC 5193, May 2008.	
 	                                                                         	
   [RFC5207]  Stiemerling, M., Quittek, J., and L. Eggert, "NAT and	 	   [RFC5207]  Stiemerling, M., Quittek, J., and L. Eggert, "NAT and	
              Firewall Traversal Issues of Host Identity Protocol (HIP)	 	              Firewall Traversal Issues of Host Identity Protocol (HIP)	
              Communication", RFC 5207, April 2008.	 	              Communication", RFC 5207, April 2008.	
 		
   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS	 	   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS	
              Authentication Protocol", RFC 5216, March 2008.	 	              Authentication Protocol", RFC 5216, March 2008.	
 		
   [RFC5238]  Phelan, T., "Datagram Transport Layer Security (DTLS) over	 	   [RFC5238]  Phelan, T., "Datagram Transport Layer Security (DTLS) over	
              the Datagram Congestion Control Protocol (DCCP)",	 	              the Datagram Congestion Control Protocol (DCCP)",	
              RFC 5238, May 2008.	 	              RFC 5238, May 2008.	
 		
   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security	 	   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security	
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.	 	              (TLS) Protocol Version 1.2", RFC 5246, August 2008.	
 		
 	   [RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event	
 	              Notifications", RFC 5277, July 2008.	
 	                                                                         	
   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,	 	   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,	
              October 2008.	 	              October 2008.	
 		
   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF	 	   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF	
              for IPv6", RFC 5340, July 2008.	 	              for IPv6", RFC 5340, July 2008.	
 		
   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,	 	   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,	
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,	 	              "Session Traversal Utilities for NAT (STUN)", RFC 5389,	
              October 2008.	 	              October 2008.	
 		
   [RFC5393]  Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen,	 	   [RFC5393]  Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen,	
              "Addressing an Amplification Vulnerability in Session	 	              "Addressing an Amplification Vulnerability in Session	
              Initiation Protocol (SIP) Forking Proxies", RFC 5393,	 	              Initiation Protocol (SIP) Forking Proxies", RFC 5393,	
              December 2008.	 	              December 2008.	
 		
   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines	 	   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines	
              for Application Designers", BCP 145, RFC 5405,	 	              for Application Designers", BCP 145, RFC 5405,	
              November 2008.	 	              November 2008.	
 		
 	   [RFC5539]  Badra, M., "NETCONF over Transport Layer Security (TLS)",	
 	              RFC 5539, May 2009.	
 	                                                                         	
   [RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling	 	   [RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling	
              Core Object Specification (iCalendar)", RFC 5545,	 	              Core Object Specification (iCalendar)", RFC 5545,	
              September 2009.	 	              September 2009.	
 		
   [RFC5546]  Daboo, C., "iCalendar Transport-Independent	 	   [RFC5546]  Daboo, C., "iCalendar Transport-Independent	
              Interoperability Protocol (iTIP)", RFC 5546,	 	              Interoperability Protocol (iTIP)", RFC 5546,	
              December 2009.	 	              December 2009.	
 		
 	   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,	
 	              "Routing Requirements for Urban Low-Power and Lossy	
 	              Networks", RFC 5548, May 2009.	
 	                                                                         	
   [RFC5569]  Despres, R., "IPv6 Rapid Deployment on IPv4	 	   [RFC5569]  Despres, R., "IPv6 Rapid Deployment on IPv4	
              Infrastructures (6rd)", RFC 5569, January 2010.	 	              Infrastructures (6rd)", RFC 5569, January 2010.	
 		
   [RFC5621]  Camarillo, G., "Message Body Handling in the Session	 	   [RFC5621]  Camarillo, G., "Message Body Handling in the Session	
              Initiation Protocol (SIP)", RFC 5621, September 2009.	 	              Initiation Protocol (SIP)", RFC 5621, September 2009.	
 		
 	   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,	
 	              "Industrial Routing Requirements in Low-Power and Lossy	
 	              Networks", RFC 5673, October 2009.	
 	                                                                         	
   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion	 	   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion	
              Control", RFC 5681, September 2009.	 	              Control", RFC 5681, September 2009.	
 		
 	   [RFC5717]  Lengyel, B. and M. Bjorklund, "Partial Lock Remote	
 	              Procedure Call (RPC) for NETCONF", RFC 5717,	
 	              December 2009.	
 	                                                                         	
   [RFC5740]  Adamson, B., Bormann, C., Handley, M., and J. Macker,	 	   [RFC5740]  Adamson, B., Bormann, C., Handley, M., and J. Macker,	
              "NACK-Oriented Reliable Multicast (NORM) Transport	 	              "NACK-Oriented Reliable Multicast (NORM) Transport	
              Protocol", RFC 5740, November 2009.	 	              Protocol", RFC 5740, November 2009.	
 		
   [RFC5750]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet	 	   [RFC5750]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet	
              Mail Extensions (S/MIME) Version 3.2 Certificate	 	              Mail Extensions (S/MIME) Version 3.2 Certificate	
              Handling", RFC 5750, January 2010.	 	              Handling", RFC 5750, January 2010.	
 		
   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet	 	   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet	
              Mail Extensions (S/MIME) Version 3.2 Message	 	              Mail Extensions (S/MIME) Version 3.2 Message	
              Specification", RFC 5751, January 2010.	 	              Specification", RFC 5751, January 2010.	
 		
   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known	 	   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known	
              Uniform Resource Identifiers (URIs)", RFC 5785,	 	              Uniform Resource Identifiers (URIs)", RFC 5785,	
              April 2010.	 	              April 2010.	
 		
   [RFC5796]  Atwood, W., Islam, S., and M. Siami, "Authentication and	 	   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation	
              Confidentiality in Protocol Independent Multicast Sparse	 	              Routing Requirements in Low-Power and Lossy Networks",	
              Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.	 	              RFC 5826, April 2010.	
 		
   [RFC5838]  Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.	 	   [RFC5838]  Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.	
              Aggarwal, "Support of Address Families in OSPFv3",	 	              Aggarwal, "Support of Address Families in OSPFv3",	
              RFC 5838, April 2010.	 	              RFC 5838, April 2010.	
 		
 	   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,	
 	              "Building Automation Routing Requirements in Low-Power and	
 	              Lossy Networks", RFC 5867, June 2010.	
 	                                                                         	
   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network	 	   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network	
              Time Protocol Version 4: Protocol and Algorithms	 	              Time Protocol Version 4: Protocol and Algorithms	
              Specification", RFC 5905, June 2010.	 	              Specification", RFC 5905, June 2010.	
 		
 	   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,	
 	              "Internet Key Exchange Protocol Version 2 (IKEv2)",	
 	              RFC 5996, September 2010.	
 	                                                                         	
   [SP-MULPIv3.0]	 	   [SP-MULPIv3.0]	
              CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols	 	              CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols	
              Interface Specification, CM-SP-MULPIv3.0-I10-090529",	 	              Interface Specification, CM-SP-MULPIv3.0-I10-090529",	
              May 2009.	 	              May 2009.	
 		
 	Appendix A.  Example: Advanced Metering Infrastructure	
 		
 	   This appendix provides a worked example of the use of the Internet	
 	   Protocol Suite in a network such as the Smart Grid's Advanced	
 	   Metering Infrastructure (AMI).  There are several possible models.	
 		
 	   Figure 6 shows the structure of the AMI as it reaches out towards a	
 	   set of residences.  In this structure, we have the home itself and	
 	   its Home Area Network (HAN), the Neighborhood Area Network (NAN) that	
 	   the utility uses to access the meter at the home, and the utility	
 	   access network that connects a set of NANs to the utility itself.	
 	   For the purposes of this discussion, assume that the NAN contains a	
 	   distributed application in a set collectors, which is of course only	
 	   one way the application could be implemented.	
 		
 	    ---	
 	    A        thermostats, appliances, etc	
 	    |  ------+-----------------------------------	
 	    |        |	
 	    |"HAN"   | <--- Energy Services Interface (ESI)	
 	    |    +---+---+	
 	    |    | Meter | Meter is generally an ALG between the AMI and the HAN	
 	    |    +---+---+	
 	    V         \	
 	    ---        \	
 	    A           \   |   /	
 	    |            \  |  /	
 	    | "NAN"    +--+-+-+---+  Likely a router but could	
 	    |          |Collector |  be an front-end application	
 	    V          +----+-----+  gateway for utility	
 	    ---              \	
 	    A                 \   |   /	
 	    |                  \  |  /	
 	    |"AMI"           +--+-+-+--+	
 	    |                |   AMI   |	
 	    |                | Headend |	
 	    V                +---------+	
 	    ---	
 		
 	       Figure 6: The HAN, NAN, and Utility in the Advanced Metering	
 	                              Infrastructure	
 		
 	   There are several questions that have to be answered in describing	
 	   this picture, which given possible answers yield different possible	
 	   models.  They include at least:	
 		
 	   o  How does Demand Response work?  Either:	
 		
 	      *  The utility presents pricing signals to the home,	
 		
 	      *  The utility presents pricing signals individual devices (e.g.,	
 	         a Pluggable Electric Vehicle),	
 		
 	      *  The utility adjusts settings on individual appliances within	
 	         the home.	
 		
 	   o  How does the utility access meters at the home?	
 		
 	      *  The AMI Headend manages the interfaces with the meters,	
 	         collecting metering data and passing it on to the appropriate	
 	         applications over the Enterprise Bus, or	
 		
 	      *  Distributed application support (collectors") might access and	
 	         summarize the information; this device might be managed by the	
 	         utility or by a service between the utility and its customers.	
 		
 	   In implementation, these models are idealized; reality may include	
 	   some aspects of each model in specified cases.	
 		
 	   The examples include:	
 		
 	   1.  Appendix A.2 presumes that the HAN, the NAN, and the utility's	
 	       network are separate administrative domains and speak application	
 	       to application across those domains.	
 		
 	   2.  Appendix A.3 repeats the first example, but presuming that the	
 	       utility directly accesses appliances within the HAN from the	
 	       collector".	
 		
 	   3.  Appendix A.4 repeats the first example, but presuming that the	
 	       collector directly forwards traffic as a router in addition to	
 	       distributed application chores.  Note that this case implies	
 	       numerous privacy and security concerns and as such is considered	
 	       a less likely deployment model.	
 		
 	A.1.  How to structure a network	
 		
 	   A key consideration in the Internet has been the development of new	
 	   link layer technologies over time.  The ARPANET originally used a BBN	
 	   proprietary link layer called BBN 1822 [1822].  In the late 1970's,	
 	   the ARPANET switched to X.25 as an interface to the 1822 network.	
 	   With the deployment of the IEEE 802 series technologies in the early	
 	   1980's, IP was deployed on Ethernet (IEEE 802.3), Token Ring (IEEE	
 	   802.5) and WiFi (IEEE 802.11), as well as Arcnet, serial lines of	
 	   various kinds, Frame Relay, and ATM.  A key issue in this evolution	
 	   was that the applications developed to run on the Internet use APIs	
 	   related to the IPS, and as a result require little or no change to	
 	   continue to operate in a new link layer architecture or a mixture of	
 	   them.	
 		
 	   The Smart Grid is likely to see a similar evolution over time.	
 	   Consider the Home Area Network (HAN) as a readily understandable	
 	   small network.  At this juncture, technologies proposed for	
 	   residential networks include IEEE P1901 (Homeplug), IEEE 802.15.4g	
 	   (Zigbee), and IEEE 802.11 (WiFi, commonly deployed today and used by	
 	   some high end appliances).  It is reasonable to expect other	
 	   technologies to be developed in the future.  As the Zigbee Alliance	
 	   has learned (and as a resulted incorporated the IPS in Secure Energy	
 	   Profile 2.0), there is significant value in providing a virtual	
 	   address that is mapped to interfaces or nodes attached to each of	
 	   those technologies.	
 		
 	   There are two possible communication models within the HAN, both of	
 	   which are likely to be useful.  Devices may communicate directly with	
 	   each other, or they may be managed by some central controller.  An	
 	   example of direct communications might be a light switch that	
 	   directly commands a lamp to turn on or off.  An example of indirect	
 	   communications might be a control application in a Customer or	
 	   Building that accepts telemetry from a thermostat, applies some form	
 	   of policy, and controls the heating and air conditioning systems.  In	
 	   addition, there are high end appliances in the market today that use	
 	   residential broadband to communicate with their manufacturers, and	
 	   obviously the meter needs to communicate with the utility.	
 		
 	                    Utility NAN	
 	                       /	
 	                      /	
 	                +----+-----+ +--+ +--+ +--+	
 	                |  Meter   | |D1| |D2| |D3|	
 	                +-----+----+ ++-+ ++-+ ++-+	
 	                      |       |    |    |	
 	                ----+-+-------+----+----+---- IEEE 802.15.4	
 	                    |	
 	                 +--+---+	
 	                 |Router+------/------ Residential Broadband	
 	                 +--+---+	
 	                    |	
 	                ----+---------+----+----+---- IEEE P1901	
 	                              |    |    |	
 	                             ++-+ ++-+ ++-+	
 	                             |D4| |D5| |D6|	
 	                             +--+ +--+ +--+	
 		
 	                        Figure 7: Home Area Network	
 		
 	   Figure 7 shows a simple network containing IEEE 802.15.4 and IEEE	
 	   1901 domains.  It shows the connectivity between them as a router	
 	   separate from the EMS.  This is for clarity; the two could of course	
 	   be incorporated into a single system, and one could imagine	
 	   appliances that want to communicate with their manufacturers	
 	   supporting both a HAN interface and a WiFi interface rather than	
 	   depending on the router.  These are all manufacturer design	
 	   decisions.	
 		
 	A.1.1.  HAN Routing	
 		
 	   The HAN can be seen as communicating with two kinds of non-HAN	
 	   networks.  One is the home LAN, which may in turn be attached to the	
 	   Internet, and will generally either derive its prefix from the	
 	   upstream ISP or use a self-generated ULA.  Another is the utility's	
 	   NAN, which through an ESI provides utility connectivity to the HAN;	
 	   in this case the HAN will be addressed by a self-generated ULA (note,	
 	   however, that in some cases ESI may also provide a prefix via DHCP	
 	   [RFC3315]).  In addition, the HAN will have link-local addresses that	
 	   can be used between neighboring nodes.  In general, an HAN will be	
 	   comprised of both 802.15.4, 802.11 (and possibly other) networks.	
 		
 	   The ESI is node on the user's residential network, and will not	
 	   typically provide stateful packet forwarding or firewall services	
 	   between the HAN and the utility network(s).  In general, the meter/	
 	   ESI is just a node on the home network.  However, the ESI must be	
 	   capable of understanding that most home networks are not 802.15.4	
 	   enabled (rather, they are typically 802.11 networks), and that it	
 	   must be capable of setting up ad-hoc networks between various sensors	
 	   in the home (e.g., betweeen the meter and say, a thermostat) in the	
 	   event there aren't other networks available.	
 		
 	A.1.2.  HAN Security	
 		
 	   In any network, we have a variety of threats and a variety of	
 	   possible mitigations.  These include, at minimum:	
 		
 	   Link Layer:  Why is your machine able to talk in my network?  The	
 	      WiFi SSIDs often use some form of authenticated access control,	
 	      which may be a simple encrypted password mechanism or may use a	
 	      combination of encryption and IEEE 802.1X+EAP-TLS Authentication/	
 	      Authorization to ensure that only authorized communicants can use	
 	      it.  If a LAN has a router attached, the router may also implement	
 	      a firewall to filter remote accesses.	
 		
 	   Network Layer:  Given that your machine is authorized access to my	
 	      network, why is your machine talking with my machine?  IPsec is a	
 	      way of ensuring that computers that can use a network are allowed	
 	      to talk with each other, may also enforce confidentiality, and may	
 	      provide VPN services to make a device or network appear to be part	
 	      of a remote network.	
 		
 	   Application:  Given that your machine is authorized access to my	
 	      network and my machine, why is your application talking with my	
 	      application?  The fact that your machine and mine are allowed to	
 	      talk for some applications doesn't mean they are allowed to for	
 	      all applications.  (D)TLS, https, and other such mechanisms enable	
 	      an application to impose application-to-application controls	
 	      similar to the network layer controls provided by IPsec.	
 		
 	   Remote Application:  How do I know that the data I received is the	
 	      data you sent?  Especially in applications like electronic mail,	
 	      where data passes through a number of intermediaries that one may	
 	      or may not really want munging it (how many times have you seen a	
 	      URL broken by a mail server?), we have tools (DKIM, S/MIME, and	
 	      W3C XML Signatures to name a few) to provide non-repudiability and	
 	      integrity verification.  This may also have legal ramifications:	
 	      if a record of a meter reading is to be used in billing, and the	
 	      bill is disputed in court, one could imagine the court wanting	
 	      proof that the record in fact came from that meter at that time	
 	      and contained that data.	
 		
 	   Application-specific security:  In addition, applications often	
 	      provide security services of their own.  The fact that I can	
 	      access a file system, for example, doesn't mean that I am	
 	      authorized to access everything in it; the file system may well	
 	      prevent my access to some of its contents.  Routing protocols like	
 	      BGP obsess with the question "what statements that my peer made am	
 	      I willing to believe".  And monitoring protocols like SNMP may not	
 	      be willing to answer every question they are asked, depending on	
 	      access configuration.	
 		
 	   Devices in the HAN want controlled access to the LAN in question for	
 	   obvious reasons.  In addition, there should be some form of mutual	
 	   authentication between devices - the lamp controller will want to	
 	   know that the light switch telling it to change state is the right	
 	   light switch, for example.  The EMS may well want strong	
 	   authentication of accesses - the parents may not want the children	
 	   changing the settings, and while the utility and the customer are	
 	   routinely granted access, other parties (especially parties with	
 	   criminal intent) need to be excluded.	
 		
 	A.2.  Model 1: AMI with separated domains	
 		
 	   With the background given in Appendix A.1, we can now discuss the use	
 	   of IP (IPv4 or IPv6) in the AMI.	
 		
 	   In this first model, consider the three domains in Figure 6 to	
 	   literally be separate administrative domains, potentially operated by	
 	   different entities.  For example, the NAN could be a WiMAX network	
 	   operated by a traditional telecom operator, the utility's network	
 	   (including the collector) is its own, and the residential network is	
 	   operated by the resident.  In this model, while communications	
 	   between the collector and the Meter are normal, the utility has no	
 	   other access to appliances in the home, and the collector doesn't	
 	   directly forward messages from the NAN upstream.	
 		
 	   In this case, as shown in Figure 7, it would make the most sense to	
 	   design the collector, the Meter, and the EMS as hosts on the NAN -	
 	   design them as systems whose applications can originate and terminate	
 	   exchanges or sessions in the NAN, but not forward traffic from or to	
 	   other devices.	
 		
 	   In such a configuration, Demand Response has to be performed by	
 	   having the EMS accept messages such as price signals from the "pole	
 	   top", apply some form of policy, and then orchestrate actions within	
 	   the home.  Another possibility is to have the EMS communicate with	
 	   the ESI located in the meter.  If the thermostat has high demand and	
 	   low demand (day/night or morning/day/evening/night) settings, Demand	
 	   Response might result in it moving to a lower demand setting, and the	
 	   EMS might also turn off specified circuits in the home to diminish	
 	   lighting.	
 		
 	   In this scenario, QoS issues reportedly arise when high precedence	
 	   messages must be sent through the collector to the home; if the	
 	   collector is occupied polling the meters or doing some other task,	
 	   the application may not yield control of the processor to the	
 	   application that services the message.  Clearly, this is either an	
 	   application or an OS problem; applications need to be designed in a	
 	   manner that doesn't block high precedence messages.  The collector	
 	   also needs to use appropriate NAN services, if they exist, to provide	
 	   the NAN QoS it needs.  For example, if WiMax is in use, it might use	
 	   a routine-level service for normal exchanges but a higher precedence	
 	   service for these messages.	
 		
 	A.3.  Model 2: AMI with neighborhood access to the home	
 		
 	   In this second model, let's imagine that the utility directly	
 	   accesses appliances within the HAN.  Rather than expect an EMS to	
 	   respond to price signals in Demand Response, it directly commands	
 	   devices like air conditioners to change state, or throws relays on	
 	   circuits to or within the home.	
 		
 	                +----------+ +--+ +--+ +--+	
 	                |  Meter   | |D1| |D2| |D3|	
 	                +-----+----+ ++-+ ++-+ ++-+	
 	                      |       |    |    |	
 	                ----+-+-------+----+----+---- IEEE 802.15.4	
 	                    |	
 	                 +--+---+	
 	                 |      +------/------ NAN	
 	                 |Router|	
 	                 |      +------/------ Residential Broadband	
 	                 +--+---+	
 	                    |	
 	                ----+---------+----+----+---- IEEE P1901	
 	                              |    |    |	
 	                             ++-+ ++-+ ++-+	
 	                             |D4| |D5| |D6|	
 	                             +--+ +--+ +--+	
 		
 	                        Figure 8: Home Area Network	
 		
 	   In this case, as shown in Figure 8, the Meter, and EMS as hosts on	
 	   the HAN, and there is a router between the HAN and the NAN.	
 		
 	   As one might imagine, there are serious security considerations in	
 	   this model.  Traffic between the NAN and the residential broadband	
 	   network should be filtered, and the issues raised in Appendix A.1.2	
 	   take on a new level of meaning.  One of the biggest threats may be a	
 	   legal or at least a public relations issue; if the utility	
 	   intentionally disables a circuit in a manner or at a time that	
 	   threatens life (the resident's kidney dialysis machine is on it, or a	
 	   respirator, for example) the matter might make the papers.	
 	   Unauthorized access could be part of juvenile pranks or other things	
 	   as well.  So one really wants the appliances to only obey commands	
 	   under strict authentication/authorization controls.	
 		
 	   In addition to the QoS issues raised in Appendix A.2, there is the	
 	   possibility of queuing issues in the router.  In such a case, the IP	
 	   datagrams should probably use the Low-Latency Data Service Class	
 	   described in [RFC4594], and let other traffic use the Standard	
 	   Service Class or other service classes.	
 		
 	A.4.  Model 3: Collector is an IP router	
 		
 	   In this third model, the relationship between the NAN and the HAN is	
 	   either as in Appendix A.2 or Appendix A.3; what is different is that	
 	   the collector may be an IP router.  In addition to whatever	
 	   autonomous activities it is doing, it forwards traffic as an IP	
 	   router in some cases.	
 		
 	   As and analogous to Appendix A.3, there are serious security	
 	   considerations in this model.  Traffic being forwarded should be	
 	   filtered, and the issues raised in Appendix A.1.2 take on a new level	
 	   of meaning - but this time at the utility mainframe.  Unauthorized	
 	   access is likely similar to other financially-motivated attacks that	
 	   happen in the Internet, but presumably would be coming from devices	
 	   in the HAN that have been co-opted in some way.  One really wants the	
 	   appliances to only obey commands under strict authentication/	
 	   authorization controls.	
 		
 	   In addition to the QoS issues raised in Appendix A.2, there is the	
 	   possibility of queuing issues in the collector.  In such a case, the	
 	   IP datagrams should probably use the Low-Latency Data Service Class	
 	   described in [RFC4594], and let other traffic use the Standard	
 	   Service Class or other service classes.	
 	                                                                         	
Authors' Addresses	 	Authors' Addresses	
 		
   Fred Baker	 	   Fred Baker	
   Cisco Systems	 	   Cisco Systems	
   Santa Barbara, California  93117	 	   Santa Barbara, California  93117	
   USA	 	   USA	
 		
   Email: [email-masked]	 	   Email: [email-masked]	
 		
   David Meyer	 	   David Meyer	
 		
 End of changes. 60 change blocks. 
149 lines changed or deleted		758 lines changed or added	

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 29 Oct 2010 04:46:00 +0900

I have a comment on the following paragraph in section 3.1.3:

"
"

I guess what the above paragraph actually wanted to convey is,
when used with EAP-TLS both 802.1X and PANA are widely considered to
offer excellent access security to a wired or wireless IEEE 802 LAN.
This is because both 802.1X and PANA are EAP transports.   Also,
AFAIK, PANA in conjuction with EAP-TLS is the baseline for ZigBee
SEP2.0 (I am working with ZigBee people on defining PANA relay
draft needed for ZigBee SEP2.0).  Finally, RFC5191 (PANA protocol
specification) is more appropriate reference for PANA than
RFC5193 (PANA framework).

Having said that, here is my suggested change:

"
   When used in conjunction with EAP-TLS [RFC5216], both IEEE 802.1X
   [IEEE802.1X] and the Protocol for Carrying Authentication for
   Network Access (PANA) [RFC5191] are widely considered
   to offer excellent access security to a wired or wireless IEEE 802
   LAN (PANA in conjunction with EAP-TLS is the baseline for Zigbee
   SEP 2.0).
"

Best Regards,
Yoshihiro Ohba

(2010/10/26 3:53), Fred Baker wrote:
>   	    |"HAN"   |<--- Energy Services Interface (ESI)	
>   	    |    +---+---+	
> _______________________________________________
> smartpower-interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smartpower-interest