[smartpowerdir] Diff: draft-baker-ietf-core-04.txt

[smartpowerdir] Diff: draft-baker-ietf-core-04.txt - sg-ietf-compendium.txt

Fred Baker <fred@cisco.com> Fri, 18 June 2010 23:41 UTC
From: Fred Baker <fred@cisco.com>
Date: Fri, 18 Jun 2010 16:41:11 -0700
Message-Id: <A974FAD7-C3DA-4965-8BB1-1AAEEF74E043@cisco.com>
To: Vint Cerf <vint@google.com>
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-575-97044150"
Cc: "David H. Su" <david.su@nist.gov>, IETF SmartPower Directorate <smartpowerdir@ietf.org>
Subject: [smartpowerdir] Diff: draft-baker-ietf-core-04.txt - sg-ietf-compendium.txt
Precedence: list
Vint: look at these diffs and see if you agree with my edits. Some of these changes reflect boilerplate changes that rearranged the first page of an internet draft.

I have not added the section that integrates TLS and IPsec into the architecture. Still thinking about how best to do that. I intend to pull much of the application and MPLS discussion into appendices as "not really core". I want the main part of the document to be Internet Layer, Transport Layer, and security. But first your suggested edits.


< draft-baker-ietf-core-04.txt 		 sg-ietf-compendium.txt 	
 		
Network Working Group                                           F. Baker	 	Network Working Group                                           F. Baker	
Internet-Draft                                             Cisco Systems	 	Internet-Draft                                             Cisco Systems	
Intended status: Informational                          October 23, 2009	 	Intended status: Informational                             June 18, 2010	
Expires: April 26, 2010	 	Expires: December 20, 2010	
 		
             Core Protocols in the Internet Protocol Suite	 	                 Internet Protocols for the Smart Grid	
                        draft-baker-ietf-core-04	 	                        draft-baker-ietf-core-05	
 		
 	Abstract	
 		
 	   This note attempts to identify the key protocols of the Internet	
 	   Protocol Suite for use in the Smart Grid.  The target audience is who	
 	   want guidance on how to profile the Internet Protocol Suite.  In	
 	   general, that would mean selecting what they need from the picture	
 	   presented here.	
 		
Status of this Memo	 	Status of this Memo	
 		
   This Internet-Draft is submitted to IETF in full conformance with the	 	   This Internet-Draft is submitted in full conformance with the	
   provisions of BCP 78 and BCP 79.	 	   provisions of BCP 78 and BCP 79.	
 		
   Internet-Drafts are working documents of the Internet Engineering	 	   Internet-Drafts are working documents of the Internet Engineering	
   Task Force (IETF), its areas, and its working groups.  Note that	 	   Task Force (IETF).  Note that other groups may also distribute	
   other groups may also distribute working documents as Internet-	 	   working documents as Internet-Drafts.  The list of current Internet-	
   Drafts.	 	   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."	
 		
   The list of current Internet-Drafts can be accessed at	 	   This Internet-Draft will expire on December 20, 2010.	
   http://www.ietf.org/ietf/1id-abstracts.txt.	 		
 		
   The list of Internet-Draft Shadow Directories can be accessed at	 		
   http://www.ietf.org/shadow.html.	 		
                                                                         	 		
   This Internet-Draft will expire on April 26, 2010.	 		
 		
Copyright Notice	 	Copyright Notice	
 		
   Copyright (c) 2009 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 in effect on the date of	 	   Provisions Relating to IETF Documents	
   publication of this document (http://trustee.ietf.org/license-info).	 	   (http://trustee.ietf.org/license-info) in effect on the date of	
   Please review these documents carefully, as they describe your rights	 	   publication of this document.  Please review these documents	
   and restrictions with respect to this document.	 	   carefully, as they describe your rights and restrictions with respect	
                                                                         	 	   to this document.  Code Components extracted from this document must	
Abstract	 	   include Simplified BSD License text as described in Section 4.e of	
 	   the Trust Legal Provisions and are provided without warranty as	
   This note attempts to identify the core of the Internet Protocol	 	   described in the Simplified BSD License.	
   Suite.  The target audience is NIST, in the Smart Grid discussion, as	 		
   they have requested guidance on how to profile the Internet Protocol	 		
   Suite.  In general, that would mean selecting what they need from the	 		
   picture presented here.	 		
 		
Table of Contents	 	Table of Contents	
 		
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4	 	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4	
   2.  The Internet Protocol Suite  . . . . . . . . . . . . . . . . .  5	 	   2.  The Internet Protocol Suite  . . . . . . . . . . . . . . . . .  4	
     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  . . . . . . . . . . . . . . . .  7	 	         2.1.3.1.  Internet Protocol  . . . . . . . . . . . . . . . .  7	
         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  . . . . . . . . . . . . . . . . . .  8	 	       2.2.1.  Physical security  . . . . . . . . . . . . . . . . . .  8	
       2.2.2.  Session identification . . . . . . . . . . . . . . . .  9	 	       2.2.2.  Session identification . . . . . . . . . . . . . . . .  9	
       2.2.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . 10	 	       2.2.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . 10	
     2.3.  Network Infrastructure . . . . . . . . . . . . . . . . . . 10	 	     2.3.  Network Infrastructure . . . . . . . . . . . . . . . . . . 10	
       2.3.1.  Domain Name System (DNS) . . . . . . . . . . . . . . . 10	 	       2.3.1.  Domain Name System (DNS) . . . . . . . . . . . . . . . 10	
       2.3.2.  Network Management Issues  . . . . . . . . . . . . . . 10	 	       2.3.2.  Network Management Issues  . . . . . . . . . . . . . . 11	
   3.  Specific protocols . . . . . . . . . . . . . . . . . . . . . . 11	 	   3.  Specific protocols . . . . . . . . . . . . . . . . . . . . . . 11	
     3.1.  Security solutions . . . . . . . . . . . . . . . . . . . . 11	 	     3.1.  Security solutions . . . . . . . . . . . . . . . . . . . . 11	
       3.1.1.  Session identification, authentication,	 	       3.1.1.  Session identification, authentication,	
               authorization, and accounting  . . . . . . . . . . . . 11	 	               authorization, and accounting  . . . . . . . . . . . . 11	
       3.1.2.  IP Security Architecture (IPsec) . . . . . . . . . . . 11	 	       3.1.2.  IP Security Architecture (IPsec) . . . . . . . . . . . 12	
       3.1.3.  Transport Layer Security (TLS) . . . . . . . . . . . . 12	 	       3.1.3.  Transport Layer Security (TLS) . . . . . . . . . . . . 12	
       3.1.4.  Secure/Multipurpose Internet Mail Extensions	 	       3.1.4.  Secure/Multipurpose Internet Mail Extensions	
               (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 12	 	               (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 12	
     3.2.  Network Layer  . . . . . . . . . . . . . . . . . . . . . . 12	 	     3.2.  Network Layer  . . . . . . . . . . . . . . . . . . . . . . 13	
       3.2.1.  Internet Protocol Version 4  . . . . . . . . . . . . . 13	 	       3.2.1.  Internet Protocol Version 4  . . . . . . . . . . . . . 13	
         3.2.1.1.  IPv4 Address Allocation and Assignment . . . . . . 13	 	         3.2.1.1.  IPv4 Address Allocation and Assignment . . . . . . 13	
         3.2.1.2.  IPv4 Unicast Routing . . . . . . . . . . . . . . . 13	 	         3.2.1.2.  IPv4 Unicast Routing . . . . . . . . . . . . . . . 13	
         3.2.1.3.  IPv4 Multicast Forwarding and Routing  . . . . . . 14	 	         3.2.1.3.  IPv4 Multicast Forwarding and Routing  . . . . . . 14	
       3.2.2.  Internet Protocol Version 6  . . . . . . . . . . . . . 14	 	       3.2.2.  Internet Protocol Version 6  . . . . . . . . . . . . . 14	
         3.2.2.1.  IPv6 Address Allocation and Assignment . . . . . . 15	 	         3.2.2.1.  IPv6 Address Allocation and Assignment . . . . . . 15	
         3.2.2.2.  IPv6 Routing . . . . . . . . . . . . . . . . . . . 15	 	         3.2.2.2.  IPv6 Routing . . . . . . . . . . . . . . . . . . . 15	
         3.2.2.3.  IPv6 Multicast Forwarding and Routing  . . . . . . 15	 	         3.2.2.3.  IPv6 Multicast Forwarding and Routing  . . . . . . 16	
       3.2.3.  Adaptation to lower layer networks and link layer	 	       3.2.3.  Adaptation to lower layer networks and link layer	
               protocols  . . . . . . . . . . . . . . . . . . . . . . 16	 	               protocols  . . . . . . . . . . . . . . . . . . . . . . 16	
     3.3.  Transport Layer  . . . . . . . . . . . . . . . . . . . . . 16	 	     3.3.  Transport Layer  . . . . . . . . . . . . . . . . . . . . . 17	
       3.3.1.  User Datagram Protocol (UDP) . . . . . . . . . . . . . 17	 	       3.3.1.  User Datagram Protocol (UDP) . . . . . . . . . . . . . 17	
       3.3.2.  Transmission Control Protocol (TCP)  . . . . . . . . . 17	 	       3.3.2.  Transmission Control Protocol (TCP)  . . . . . . . . . 17	
       3.3.3.  Stream Control Transmission Protocol (SCTP)  . . . . . 18	 	       3.3.3.  Stream Control Transmission Protocol (SCTP)  . . . . . 18	
       3.3.4.  Datagram Congestion Control Protocol (DCCP)  . . . . . 18	 	       3.3.4.  Datagram Congestion Control Protocol (DCCP)  . . . . . 18	
     3.4.  Infrastructure . . . . . . . . . . . . . . . . . . . . . . 19	 	     3.4.  Infrastructure . . . . . . . . . . . . . . . . . . . . . . 19	
       3.4.1.  Domain Name System . . . . . . . . . . . . . . . . . . 19	 	       3.4.1.  Domain Name System . . . . . . . . . . . . . . . . . . 19	
       3.4.2.  Dynamic Host Configuration . . . . . . . . . . . . . . 19	 	       3.4.2.  Dynamic Host Configuration . . . . . . . . . . . . . . 19	
     3.5.  Other Applications . . . . . . . . . . . . . . . . . . . . 19	 	     3.5.  Other Applications . . . . . . . . . . . . . . . . . . . . 19	
       3.5.1.  Network Time . . . . . . . . . . . . . . . . . . . . . 19	 	       3.5.1.  Network Time . . . . . . . . . . . . . . . . . . . . . 19	
       3.5.2.  Session Initiation Protocol  . . . . . . . . . . . . . 20	 	       3.5.2.  Session Initiation Protocol  . . . . . . . . . . . . . 20	
       3.5.3.  Calendaring  . . . . . . . . . . . . . . . . . . . . . 20	 	       3.5.3.  Calendaring  . . . . . . . . . . . . . . . . . . . . . 20	
   4.  A simplied view of the business architecture . . . . . . . . . 21	 	   4.  A simplified view of the business architecture . . . . . . . . 21	
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25	 	   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25	
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26	 	   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26	
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26	 	   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26	
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26	 	   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26	
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 26	 	     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 26	
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 26	 	     8.2.  Informative References . . . . . . . . . . . . . . . . . . 26	
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36	 	   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36	
 		
1.  Introduction	 	1.  Introduction	
 		
   In the discussion of the Smart Grid, a question has arisen as to what	 	   In the discussion of the Smart Grid, a question has arisen as to how	
   the "core" protocols of the Internet Protocol Suite are.  In this	 	   best to "profile" the Internet Protocol Suite are.  In this note, I	
   note, I will attempt to identify the structure of the Internet	 	   will attempt to identify the structure of the Internet Protocol Suite	
   Protocol Suite and the key protocols that should be considered as	 	   and the key protocols that should be considered as critical in	
   critical in integrating Smart Grid devices into an IP-based	 	   integrating Smart Grid devices into an IP-based infrastructure.  In	
   infrastructure.  In many cases, the protocols are options - one might	 	   many cases, the protocols are options - one might choose, for	
   choose, for example, TCP, SCTP, DCCP, or some other transport, or use	 	   example, TCP, SCTP, DCCP, or some other transport, or use expand upon	
   UDP as a label and build the transport into the application itself.	 	   UDP, building the transport into the application itself.  In the	
   In the Transport layer, therefore, one is not limited to exactly one	 	   Transport layer, therefore, one is not limited to exactly one of	
   of those, nor is one required to implement them all.  One should,	 	   those, nor is one required to implement them all.  One should,	
   however, pick the right one for the purpose one intends.  This kind	 	   however, pick the right one for the purpose one intends.  This kind	
   of discussion will be had at every layer.	 	   of discussion will be had at every layer.	
 		
   The set of protocols defined in this document focus on the use of the	 	   The set of protocols defined in this document focus on the use of the	
   IP Protocol Suite in end systems, also known as hosts.  In the Smart	 	   IP Protocol Suite in end systems, also known as hosts.  In the Smart	
   Grid, these end systems will be various devices such as power meters,	 	   Grid, these end systems will be various devices such as power meters,	
   sensors and actuators.  These end systems can leverage infrastructure	 	   sensors and actuators.  These end systems can leverage infrastructure	
   built on networking components using the IP Protocol Suite, which	 	   built on networking components using the IP Protocol Suite, which	
   have well-proven implementations and deployments in the Internet.	 	   have well-proven implementations and deployments in the Internet.	
                                                                         	 	   That said, it also goes on to mention network-only technology	
   IETF participants in the Smart Grid discussion have been wary of the	 	   including routing protocols and circuit switching models, which may	
   desire to write a "profile", repeatedly expressed.  The IETF is all	 	   be useful in networks supporting the Smart Grid.	
   about interoperability, and in our experience attempts to "profile"	 		
   protocols and architectures has resulted in a failure to	 		
   interoperate.  Examples of such failures abound.  In IETF experience,	 		
   writing a conforming and interoperable implementation of the right	 		
   set of protocols works.  Selecting some options and deselecting	 		
   others within a defined protocol, however, is a dangerous course of	 		
   action.  So while this document is clearly a step in the direction of	 		
   writing a "Smart Grid Profile", such a profile should in our opinion	 		
   be a selected set of protocols, not of protocol subsets.	 		
 		
   For its own purposes, the IETF has written several documents that	 	   For its own purposes, the IETF has written several documents that	
   describe its expectations regarding implementations of the Internet	 	   describe its expectations regarding implementations of the Internet	
   Protocol Suite.  These include:	 	   Protocol Suite.  These include:	
 		
   o  Requirements for Internet Hosts - Communication Layers [RFC1122],	 	   o  Requirements for Internet Hosts - Communication Layers [RFC1122],	
 		
   o  Requirements for Internet Hosts - Application and Support	 	   o  Requirements for Internet Hosts - Application and Support	
      [RFC1123],	 	      [RFC1123],	
 		
 		
skipping to change at page 9, line 22		skipping to change at page 9, line 22	
   1.  Verify that the peers one exchanges data with are appropriate	 	   1.  Verify that the peers one exchanges data with are appropriate	
       partners; this generally means knowing "who" they are and that	 	       partners; this generally means knowing "who" they are and that	
       they have a "need to know" or are trusted sources.	 	       they have a "need to know" or are trusted sources.	
 		
   2.  Verify that information that appears to be from a trusted peer is	 	   2.  Verify that information that appears to be from a trusted peer is	
       in fact from that peer.	 	       in fact from that peer.	
 		
   3.  Validate the content of the data exchanged; it must conform to	 	   3.  Validate the content of the data exchanged; it must conform to	
       the rules of the exchange.	 	       the rules of the exchange.	
 		
   4.  One must also defend the channel against denial of service	 	   4.  Defend the channel against denial of service attacks.	
       attacks.	 		
 	   5.  Ensure the integrity of the information transported to defend	
 	       against modification attacks.	
 		
   In other words, there is a need to secure the channel that carries a	 	   In other words, there is a need to secure the channel that carries a	
   message, and there is a need to secure the exchanges, both by knowing	 	   message, and there is a need to secure the exchanges, both by knowing	
   the source of the information and to have proof of its validity.	 	   the source of the information and to have proof of its validity.	
   Three examples suffice to illustrate the challenges.	 	   Three examples suffice to illustrate the challenges.	
 		
   One common attack is to bombard a transport session (an application's	 	   One common attack is to bombard a transport session (an application's	
   channel) with reset messages.  If the attacker is lucky, he might	 	   channel) with reset messages.  If the attacker is lucky, he might	
   cause the session to fail.  Including information in the transport	 	   cause the session to fail.  Including information in the transport	
   header or a related protocol like IPsec or TLS that identifies the	 	   header or a related protocol like IPsec or TLS that identifies the	
 		
skipping to change at page 12, line 5		skipping to change at page 12, line 14	
 		
3.1.2.  IP Security Architecture (IPsec)	 	3.1.2.  IP Security Architecture (IPsec)	
 		
   The Security Architecture for the Internet Protocol [RFC4301] is a	 	   The Security Architecture for the Internet Protocol [RFC4301] is a	
   set of control and data protocols that are implemented between IPv4	 	   set of control and data protocols that are implemented between IPv4	
   and its Transport layer, or in IPv6's Security extension header.  It	 	   and its Transport layer, or in IPv6's Security extension header.  It	
   allows transport layer sessions (which underlie applications) to	 	   allows transport layer sessions (which underlie 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.  The architecture is spelled out in a	 	   tampering, or message forgery.  The architecture is spelled out in a	
   number of additional specifications for specific components: the IP	 	   number of additional specifications for specific components: the IP	
   Authentication Header [RFC4302] Encapsulating Security Payload (ESP)	 	   Authentication Header (AH) [RFC4302] Encapsulating Security Payload	
   [RFC4303], Internet Key Exchange (IKEv2) [RFC4306], Cryptographic	 	   (ESP) [RFC4303], Internet Key Exchange (IKEv2) [RFC4306],	
   Algorithms [RFC4307], Cryptographic Algorithm Implementation	 	   Cryptographic Algorithms [RFC4307], Cryptographic Algorithm	
   Requirements for ESP and AH [RFC4835], and the use of Advanced	 	   Implementation Requirements for ESP and AH [RFC4835], and the use of	
   Encryption Standard (AES) [RFC4309].	 	   Advanced Encryption Standard (AES) [RFC4309].	
 		
   In the transport mode, IPsec ESP encrypts the transport layer and the	 	   In the transport mode, IPsec ESP encrypts the transport layer and the	
   application data.  In the tunnel mode, which is frequently used for	 	   application data.  In the tunnel mode, which is frequently used for	
   Virtual Private Networks, one also encrypts the Internet Protocol,	 	   Virtual Private Networks, one also encrypts the Internet Protocol,	
   and encapsulates the encrypted data inside a second IP header	 	   and encapsulates the encrypted data inside a second IP header	
   directed to the intended decryptor.	 	   directed to the intended decryptor.	
 		
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	
 		
skipping to change at page 15, line 5		skipping to change at page 15, line 16	
   by the originating host, if necessary, for transmission through	 	   by the originating host, if necessary, for transmission through	
   "small packet" networks.  ICMPv6, which is a separate protocol	 	   "small packet" networks.  ICMPv6, which is a separate protocol	
   implemented along with IPv6, enables the network to report errors and	 	   implemented along with IPv6, enables the network to report errors and	
   other issues to hosts that originate problematic datagrams.	 	   other issues to hosts that originate problematic datagrams.	
 		
   IPv6 adopted the Differentiated Services Architecture	 	   IPv6 adopted the Differentiated Services Architecture	
   [RFC2474][RFC2475], which contains a six bit code point used to	 	   [RFC2474][RFC2475], which contains a six bit code point used to	
   select an algorithm (a "per-hop behavior") to be applied to the	 	   select an algorithm (a "per-hop behavior") to be applied to the	
   datagram.	 	   datagram.	
 		
 	   The IPv6 over Low-Power Wireless Personal Area Networks [RFC4919] RFC	
 	   and the Compression Format for IPv6 Datagrams in 6LoWPAN Networks	
 	   [I-D.ietf-6lowpan-hc] addresses IPv6 header compression and subnet	
 	   architecture in at least some sensor networks, and may be appropriate	
 	   to the Smart Grid AMI or other sensor domains.	
 	                                                                         	
3.2.2.1.  IPv6 Address Allocation and Assignment	 	3.2.2.1.  IPv6 Address Allocation and Assignment	
 		
   An IPv6 Address [RFC4291] may be administratively assigned using	 	   An IPv6 Address [RFC4291] may be administratively assigned using	
   DHCPv6 [RFC3315] in a manner similar to the way IPv4 addresses are,	 	   DHCPv6 [RFC3315] in a manner similar to the way IPv4 addresses are,	
   but may also be autoconfigured, facilitating network management.	 	   but may also be autoconfigured, facilitating network management.	
   Autoconfiguration procedures are defined in [RFC4862] and [RFC4941].	 	   Autoconfiguration procedures are defined in [RFC4862] and [RFC4941].	
   IPv6 neighbors identify each other's addresses using either Neighbor	 	   IPv6 neighbors identify each other's addresses using either Neighbor	
   Discovery (ND) [RFC4861] or SEcure Neighbor Discovery (SEND)	 	   Discovery (ND) [RFC4861] or SEcure Neighbor Discovery (SEND)	
   [RFC3971].	 	   [RFC3971].	
 		
 		
skipping to change at page 15, line 43		skipping to change at page 16, line 14	
 		
3.2.2.3.  IPv6 Multicast Forwarding and Routing	 	3.2.2.3.  IPv6 Multicast Forwarding and Routing	
 		
   From its initial design, IPv6 has specified both unicast and	 	   From its initial design, IPv6 has specified both unicast and	
   multicast datagram exchange.  This uses the Multicast Listener	 	   multicast datagram exchange.  This uses the Multicast Listener	
   Discovery Protocol (MLDv2) [RFC2710] [RFC3590] [RFC3810] [RFC4604] to	 	   Discovery Protocol (MLDv2) [RFC2710] [RFC3590] [RFC3810] [RFC4604] to	
   enable applications to join multicast groups, and for most	 	   enable applications to join multicast groups, and for most	
   applications uses Source-Specific Multicast [RFC4607] for routing and	 	   applications uses Source-Specific Multicast [RFC4607] for routing and	
   delivery of multicast messages.	 	   delivery of multicast messages.	
 		
   The IPv6 over Low-Power Wireless Personal Area Networks [RFC4919] RFC	 		
   addresses IPv6 header compression and subnet architecture in at least	 		
   some sensor networks, and may be appropriate to the Smart Grid AMI or	 		
   other sensor domains.	 		
                                                                         	 		
   The mechanisms experimentally developed for reliable multicast in	 	   The mechanisms experimentally developed for reliable multicast in	
   IPv4, discussed in Section 3.2.1.3, can be used in IPv6 as well.	 	   IPv4, discussed in Section 3.2.1.3, can be used in IPv6 as well.	
 		
3.2.3.  Adaptation to lower layer networks and link layer protocols	 	3.2.3.  Adaptation to lower layer networks and link layer protocols	
 		
   In general, the layered architecture enables the Internet Protocol	 	   In general, the layered architecture enables the Internet Protocol	
   Suite to run over any appropriate layer 2 architecture; with tongue	 	   Suite to run over any appropriate layer 2 architecture; with tongue	
   in cheek, specifications have been written and demonstrated to work	 	   in cheek, specifications have been written and demonstrated to work	
   for the carriage of IP by Carrier Pigeon [RFC1149][RFC2549] (perhaps	 	   for the carriage of IP by Carrier Pigeon [RFC1149][RFC2549] (perhaps	
   the most common carrier known to man) and on barbed wire [Chapman].	 	   the most common carrier known to man) and on barbed wire [Chapman].	
 		
skipping to change at page 20, line 24		skipping to change at page 20, line 29	
   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	
   change as the SIP message traverses SIP entities from source to	 	   change as the SIP message traverses SIP entities from source to	
   destination.	 	   destination.	
 		
   SIP itself does not choose whether a session is voice or video, the	 	   SIP itself does not choose whether a session is voice or video, the	
   SDP: Session Description Protocol [RFC4566].  Within the SDP, which	 	   SDP: Session Description Protocol [RFC4566] is intended for that	
   is transported by SIP, codecs are offered and accepted (or not), the	 	   purpose and to identify the actual endpoints' IP addresses.  Within	
   port number and IP address is decided for where each endpoint wants	 	   the SDP, which is transported by SIP, codecs are offered and accepted	
   to receive their RTP [RFC3550] packets.  This part is critical to	 	   (or not), the port number and IP address is decided for where each	
   understand because of the affect on NATs.  Unless a NAT (with or	 	   endpoint wants to receive their RTP [RFC3550] packets.  This part is	
   without a Firewall) is designed to be SDP aware (i.e., looking into	 	   critical to understand because of the affect on NATs.  Unless a NAT	
   each packet far enough to discover what the IP address and port	 	   (with or without a Firewall) is designed to be SDP aware (i.e.,	
   number is for this particular session - and resetting it based on the	 	   looking into each packet far enough to discover what the IP address	
   Session Traversal Utilities for NAT [RFC5389], the session	 	   and port number is for this particular session - and resetting it	
   established by SIP will not result in RTP packets being sent to the	 	   based on the Session Traversal Utilities for NAT [RFC5389], the	
   proper endpoint (in SIP called a user agent, or UA).  It should be	 	   session established by SIP will not result in RTP packets being sent	
   noted that SIP messaging has no issues with NATs, it is just the UA's	 	   to the proper endpoint (in SIP called a user agent, or UA).  It	
   inability to generally learn about the presence of the NATs that	 	   should be noted that SIP messaging has no issues with NATs, it is	
   prevent the RTP packets from being received by the UA establishing	 	   just the UA's inability to generally learn about the presence of the	
   the session.	 	   NATs that prevent the RTP packets from being received by the UA	
 	   establishing the session.	
 		
3.5.3.  Calendaring	 	3.5.3.  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	 	   Several protocols exist to carry calendar events, including	
   Transport-Independent Interoperability Protocol (iTIP) [RFC2446],	 	   Transport-Independent Interoperability Protocol (iTIP) [RFC2446],	
   (which has recently been updated in [I-D.ietf-calsify-2446bis]) , the	 	   (which has recently been updated in [I-D.ietf-calsify-2446bis]) , 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].	
 		
4.  A simplied view of the business architecture	 	4.  A simplified view of the business architecture	
 		
   The Internet was originally structured in such a way that any host	 	   The Internet was originally structured in such a way that any host	
   could directly connect to any other host for which it could determine	 	   could directly connect to any other host for which it could determine	
   an IP address.  That was very quickly found to have issues, and folks	 	   an IP address.  That was very quickly found to have issues, and folks	
   found ways to change that.  To understand the implications, one must	 	   found ways to change that.  To understand the implications, one must	
   understand, at a high level, the business structure of the Internet.	 	   understand, at a high level, the business structure of the Internet.	
 		
   The Internet, whose name implies that it is a network of networks,	 	   The Internet, whose name implies that it is a network of networks,	
   may be understood as a number of interconnected businesses.  Central	 	   may be understood as a number of interconnected and independently	
   to its business structure are the networks that provide connectivity	 	   operated networks.  Understanding "business" in an extended sense (a	
   to other networks, called "Transit Providers".  These networks sell	 	   legal entity, capable of entering into a contract, which includes	
   bulk bandwidth to each other, and to other networks as customers.	 	   wide variety of entities including those narrowly termed	
   Around the periphery of these networks, one finds companies, schools,	 	   "businesses"), this can be thought of as a "business structure" for	
   and other networks that provide services directly to individuals.	 	   the Internet.  Central to its business structure are the networks	
   These might generally be divided into "Enterprise Networks" and	 	   that provide connectivity to other networks, called "Transit	
   "Access Networks"; Enterprise networks provide "free" connectivity to	 	   Providers".  These networks sell bulk bandwidth and routing services	
   their own employees or members, and also provide them a set of	 	   to each other and to other networks as customers.  Around the	
   services including electronic mail, web services, and so on.  Access	 	   periphery of these networks, one finds companies, schools, and other	
   Networks sell broadband connectivity (DSL, Cable Modem, 802.11	 	   networks that provide services directly to individuals.  These might	
   wireless or 3GPP wireless), or "dial" services including PSTN dial-up	 	   generally be divided into "Enterprise Networks" and "Access	
   and ISDN, to subscribers.  The subscribers are typically either	 	   Networks"; Enterprise networks provide "free" connectivity to their	
   residential or small office/home office (SOHO) customers.	 	   own employees or members, and also provide them a set of services	
   Residential customers are generally entirely dependent on their	 	   including electronic mail, web services, and so on.  Access Networks	
   access provider for all services, while a SOHO buys some services	 	   sell broadband connectivity (DSL, Cable Modem, 802.11 wireless or	
   from the access provider and may provide others for itself.  Networks	 	   3GPP wireless), or "dial" services including PSTN dial-up and ISDN,	
   that sell transit services to nobody else - SOHO, residential, and	 	   to subscribers.  The subscribers are typically either residential or	
   enterprise networks - are generally refereed to as "edge networks";	 	   small office/home office (SOHO) customers.  Residential customers are	
   Transit Networks are considered to be part of the "core" of the	 	   generally entirely dependent on their access provider for all	
   Internet, and access networks are between the two.  This general	 	   services, while a SOHO buys some services from the access provider	
   structure is depicted in Figure 3.	 	   and may provide others for itself.  Networks that sell transit	
 	   services to nobody else - SOHO, residential, and enterprise networks	
 	   - are generally refereed to as "edge networks"; Transit Networks are	
 	   considered to be part of the "core" of the Internet, and access	
 	   networks are between the two.  This general structure is depicted in	
 	   Figure 3.	
 		
                           ------                  ------	 	                           ------                  ------	
                          /      \                /      \	 	                          /      \                /      \	
                /--\     /        \              /        \	 	                /--\     /        \              /        \	
               |SOHO|---+  Access  |            |Enterprise|	 	               |SOHO|---+  Access  |            |Enterprise|	
                \--/    |  Service |            | Network  |	 	                \--/    |  Service |            | Network  |	
                /--\    |  Provider|            |          |	 	                /--\    |  Provider|            |          |	
               |Home|---+          |   ------   |          |	 	               |Home|---+          |   ------   |          |	
                \--/     \        +---+      +---+        /	 	                \--/     \        +---+      +---+        /	
                          \      /   /        \   \      /	 	                          \      /   /        \   \      /	
 		
skipping to change at page 26, line 21		skipping to change at page 26, line 21	
 		
   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, Hemant	
   Singh, James Polk, John Meylor, Joseph Salowey, Julien Abeille, Kerry	 	   Singh, James Polk, John Meylor, Joseph Salowey, Julien Abeille, Kerry	
   Lynn, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman,	 	   Lynn, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman,	
   Ralph Droms, Russ White, Sheila Frankel, and Toerless Eckert.  Dave	 	   Ralph Droms, Russ White, Sheila Frankel, and Toerless Eckert.  Dave	
   McGrew and Ralph Droms suggested text.	 	   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.	
 		
skipping to change at page 26, line 45		skipping to change at page 26, line 45	
 		
   [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	
 		
   [Chapman]  Chapman, E., "Ethernet over Barbed Wire, Arcnet, 100MB	 	   [Chapman]  Chapman, E., "Ethernet over Barbed Wire, Arcnet, 100MB	
              Token Ring, 100Base-VGAnylan and iSCSI ...", 2007.	 	              Token Ring, 100Base-VGAnylan and iSCSI ...", 2007.	
 		
   [I-D.daboo-et-al-icalendar-in-xml]	 	   [I-D.daboo-et-al-icalendar-in-xml]	
              Daboo, C., Douglass, M., and S. Lees, "iCalendar XML	 	              Daboo, C., Douglass, M., and S. Lees, "xCal: The XML	
              Representation", draft-daboo-et-al-icalendar-in-xml-00	 	              format for iCalendar",	
              (work in progress), June 2009.	 	              draft-daboo-et-al-icalendar-in-xml-03 (work in progress),	
 	              April 2010.	
 		
 	   [I-D.ietf-6lowpan-hc]	
 	              Hui, J. and P. Thubert, "Compression Format for IPv6	
 	              Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-07	
 	              (work in progress), April 2010.	
 		
   [I-D.ietf-6man-node-req-bis]	 	   [I-D.ietf-6man-node-req-bis]	
              Loughney, J. and T. Narten, "IPv6 Node Requirements RFC	 	              Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node	
              4294-bis", draft-ietf-6man-node-req-bis-03 (work in	 	              Requirements RFC 4294-bis",	
              progress), July 2009.	 	              draft-ietf-6man-node-req-bis-04 (work in progress),	
 	              March 2010.	
 		
   [I-D.ietf-calsify-2446bis]	 	   [I-D.ietf-calsify-2446bis]	
              Daboo, C., "iCalendar Transport-Independent	 	              Daboo, C., "iCalendar Transport-Independent	
              Interoperability Protocol (iTIP)",	 	              Interoperability Protocol (iTIP)",	
              draft-ietf-calsify-2446bis-09 (work in progress),	 	              draft-ietf-calsify-2446bis-10 (work in progress),	
              April 2009.	 	              October 2009.	
 		
   [I-D.ietf-ntp-ntpv4-proto]	 	   [I-D.ietf-ntp-ntpv4-proto]	
              Burbank, J., "Network Time Protocol Version 4 Protocol And	 	              Kasch, W., Mills, D., and J. Burbank, "Network Time	
              Algorithms Specification", draft-ietf-ntp-ntpv4-proto-11	 	              Protocol Version 4 Protocol And Algorithms Specification",	
              (work in progress), September 2008.	 	              draft-ietf-ntp-ntpv4-proto-13 (work in progress),	
 	              October 2009.	
 		
   [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-03 (work	 	              Security version 1.2", draft-ietf-tls-rfc4347-bis-03 (work	
              in progress), October 2009.	 	              in progress), October 2009.	
 		
   [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,	
 		
 End of changes. 28 change blocks. 
119 lines changed or deleted		125 lines changed or added	

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



http://www.ipinc.net/IPv4.GIF
[smartpowerdir] Diff: draft-baker-ietf-core-04.tx… Fred Baker